changing the name of a package
I am a co-maintainer (I think at least, I used to be co-) of PyPDF2 at least for a while) or maintainer and I have noticed that the name has changed back to pypdf (upstream). Is there an easy way to update the name of the package (in the rpm) and importantly to make sure that the new pypdf rpm is pulled to replace the old PyPDF2 rpm? Thanks! ___ 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: Looking for new xfig package-maintainer
Did you find a co-maintainer for xfig? I use this package on and off and I would not like to lose it. On Tuesday, April 25, 2023 at 08:31:59 AM CDT, Hans de Goede wrote: Hi All, I have been keeping the Fedora xfig package alive all these years because I know that there are still users using xfig and xfig actually still has an active upstream. Lately I have not been able to spend any time on this, as can be seen from the currently open / unfixed CVE against xfig: https://bugz.fedoraproject.org/xfig Upstream has a patch available fixing this, so fixing this is easy. I just have not been able to make the time for this. As such I think the time has come to ask for help for maintaining xfig. If you can help by taking over or co-maintaining xfig, please let me know. Regards, Hans ___ 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: Questions about mingw static libraries
On 5/5/23 21:31, Orion Poplawski wrote:
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a
and for static libs:
%{mingw32_libdir}/libexample.a
so for example:
-rw-r--r--. 1 root root 7539008 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll
-rw-r--r--. 1 root root 13373318 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a
-rw-r--r--. 1 root root 6699310 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll: PE32
executable (DLL) (GUI) Intel 80386, for MS Windows, 12 sections
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a: current ar
archive
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a: current ar
archive
From what I've gleaned from some web searches is that the .dll.a file
is an "import" library which seems to encode a dependency on the .dll
library at runtime, while the plain .a file is a more "normal" static
library.
So to link a static executable it looks like I want to be using
libQt5Gui.a. However, when attempting to build the x2goclient
executable I'm ending up with the following link line:
i686-w64-mingw32-g++ -g -fstack-protector -static -static-libstdc++
-static-libgcc -Wl,-subsystem,windows -mthreads -o
release/x2goclient.exe @object_script.x2goclient.Release -lssh.dll
-lwinspool /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Svg.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Widgets.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a -lgdi32
-lcomdlg32 -loleaut32 -limm32 -luxtheme -ljpeg -lpng -lharfbuzz
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Network.dll.a -lcrypt32
-ldnsapi -liphlpapi
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Core.dll.a -lz -lpcre2-16
-lversion -lole32 -luuid -lwinmm -lws2_32 -ladvapi32 -lshell32 -luser32
-lkernel32 -lnetapi32 -luserenv -liconv release/x2goclient_res.o
-lmingw32 /usr/i686-w64-mingw32/sys-root/mingw/lib/libqt5main.a -lshell32
with lots of references to the .dll.a files. And from what I can tell,
the x2goclient.exe executable does appear to have runtime dependencies
on the various Qt dlls (e.g. Qt5Gui.dll, etc.).
I’m specifying a static config to qmake and QT is specified in the
x2goclient.pro simply with:
QT += svg network
So I really have no idea where the .dll.a references are coming from.
Some possibilities:
/usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl:
QMAKE_PRL_TARGET = libQt5Widgets.dll.a
$ rpm -qf /usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl
mingw32-qt5-qtbase-static-5.15.9-1.fc39.noarch
so that file is coming in as part of the -static package, but referring
to the dll import file not the static file. But I'm not finding similar
files for the other libraries.
I'm starting to think that the issue is that both the static and shared
builds of the libraries produce .prl files - but generally the static
build is installed first and then the shared build, so the .prl files
that are in the Fedora packages are for the shared libraries since they
have the same path.
So - is there a way for the static .prl files to be installed in a
different location for for qmake find them there?
Discovered a bit more information, and it's a bit more of a mess than
initially thought:
qmake appears to look for the presence of "staticlib" in the
module_config line of the .pri file to see if a static library is
present. e.g.:
/usr/i686-w64-mingw32/sys-root/mingw/share/qt5/mkspecs/modules/qt_lib_svg.pri:
QT.svg.module_config = v2 staticlib
Now at least for QtSvg, the only difference between the static and
shared version of the pri file is the presence of "staticlib". So we
might be able to get away with simply installing the static build after
the shared build.
Also, it appears that the .prl files are really only necessary for
static libraries, so we could just not build them for shared libraries
with the "no_install_prl" CONFIG option:
MINGW_BUILDDIR_SUFFIX=_static %mingw_qmake_qt5 ../%{qt_module}.pro
CONFIG+="static create_prl"
MINGW_BUILDDIR_SUFFIX=_static %mingw_make_build
MINGW_BUILDDIR_SUFFIX=_shared %mingw_qmake_qt5 ../%{qt_module}.pro
CONFIG+="no_install_prl"
MINGW_BUILDDIR_SUFFIX=_shared %mingw_make_build
Next comes the pkgconfig files. Again the only difference seems to be
the addition of Libs.private:
diff -ru
./qtsvg-everywhere-src-5.15.9/build_win32_shared/lib/pkgconfig/Qt5Svgd.pc
./qtsvg-everywhere-src-5.15.9/build_win32_static/lib/pkgconfig/Qt5Svgd.pc
---
./qtsvg-everywhere-src-5.15.9/build_win32_shared/lib/pkgconfig/Qt5Svgd.pc
2023-05-05 21:51:48.559526488 -0600
+++
./qtsvg-everywhere-src-5.15.9/build_win32_static/lib/pkgconfig/Qt5Svgd.pc
2023-05-05
Questions about mingw static libraries
I'm just starting to look into the mingw packages and building mingw
executables with them - and in particular static building. I'm hoping
someone can clarify some things for me.
For "regular" libs we seem to have:
%{mingw32_bindir}/libexample-0.dll
%{mingw32_libdir}/libexample.dll.a
and for static libs:
%{mingw32_libdir}/libexample.a
so for example:
-rw-r--r--. 1 root root 7539008 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll
-rw-r--r--. 1 root root 13373318 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a
-rw-r--r--. 1 root root 6699310 Apr 11 18:00
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/bin/Qt5Gui.dll: PE32
executable (DLL) (GUI) Intel 80386, for MS Windows, 12 sections
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a: current ar archive
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.a: current ar archive
From what I've gleaned from some web searches is that the .dll.a file
is an "import" library which seems to encode a dependency on the .dll
library at runtime, while the plain .a file is a more "normal" static
library.
So to link a static executable it looks like I want to be using
libQt5Gui.a. However, when attempting to build the x2goclient
executable I'm ending up with the following link line:
i686-w64-mingw32-g++ -g -fstack-protector -static -static-libstdc++
-static-libgcc -Wl,-subsystem,windows -mthreads -o
release/x2goclient.exe @object_script.x2goclient.Release -lssh.dll
-lwinspool /usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Svg.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Widgets.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Gui.dll.a -lgdi32
-lcomdlg32 -loleaut32 -limm32 -luxtheme -ljpeg -lpng -lharfbuzz
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Network.dll.a -lcrypt32
-ldnsapi -liphlpapi
/usr/i686-w64-mingw32/sys-root/mingw/lib/libQt5Core.dll.a -lz -lpcre2-16
-lversion -lole32 -luuid -lwinmm -lws2_32 -ladvapi32 -lshell32 -luser32
-lkernel32 -lnetapi32 -luserenv -liconv release/x2goclient_res.o
-lmingw32 /usr/i686-w64-mingw32/sys-root/mingw/lib/libqt5main.a -lshell32
with lots of references to the .dll.a files. And from what I can tell,
the x2goclient.exe executable does appear to have runtime dependencies
on the various Qt dlls (e.g. Qt5Gui.dll, etc.).
I’m specifying a static config to qmake and QT is specified in the
x2goclient.pro simply with:
QT += svg network
So I really have no idea where the .dll.a references are coming from.
Some possibilities:
/usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl:
QMAKE_PRL_TARGET = libQt5Widgets.dll.a
$ rpm -qf /usr/i686-w64-mingw32/sys-root/mingw/lib/Qt5Widgets.prl
mingw32-qt5-qtbase-static-5.15.9-1.fc39.noarch
so that file is coming in as part of the -static package, but referring
to the dll import file not the static file. But I'm not finding similar
files for the other libraries.
I'm starting to think that the issue is that both the static and shared
builds of the libraries produce .prl files - but generally the static
build is installed first and then the shared build, so the .prl files
that are in the Fedora packages are for the shared libraries since they
have the same path.
So - is there a way for the static .prl files to be installed in a
different location for for qmake find them there?
--
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/
smime.p7s
Description: S/MIME Cryptographic 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
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce apptainer-1.1.8-1.el9 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b59aa78f7e vtk-9.1.0-18.el9 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5114b71516 rust-below-0.6.3-4.el9 rust-cargo-c-0.9.12-4.el9 rust-pore-0.1.8-3.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing chromium-113.0.5672.63-1.el9 engrampa-1.26.1-1.el9 mate-session-manager-1.26.1-1.el9 Details about builds: chromium-113.0.5672.63-1.el9 (FEDORA-EPEL-2023-83071f7bea) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 113.0.5672.64. Fixes the following security issues: CVE-2023-2459 CVE-2023-2460 CVE-2023-2461 CVE-2023-2462 CVE-2023-2463 CVE-2023-2464 CVE-2023-2465 CVE-2023-2466 CVE-2023-2467 CVE-2023-2468 ChangeLog: * Wed May 3 2023 Than Ngo - 113.0.5672.63-1 - update to 113.0.5672.63 * Sun Apr 23 2023 Than Ngo - 112.0.5615.165-2 - make --use-gl=egl default for x11/wayland - enable WebUIDarkMode References: [ 1 ] Bug #2192762 - CVE-2023-2459 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192762 [ 2 ] Bug #2192763 - CVE-2023-2460 chromium-browser: Insufficient validation of untrusted input in Extensions https://bugzilla.redhat.com/show_bug.cgi?id=2192763 [ 3 ] Bug #2192764 - CVE-2023-2461 chromium-browser: Use after free in OS Inputs https://bugzilla.redhat.com/show_bug.cgi?id=2192764 [ 4 ] Bug #2192765 - CVE-2023-2462 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192765 [ 5 ] Bug #2192766 - CVE-2023-2463 chromium-browser: Inappropriate implementation in Full Screen Mode https://bugzilla.redhat.com/show_bug.cgi?id=2192766 [ 6 ] Bug #2192767 - CVE-2023-2464 chromium-browser: Inappropriate implementation in PictureInPicture https://bugzilla.redhat.com/show_bug.cgi?id=2192767 [ 7 ] Bug #2192768 - CVE-2023-2465 chromium-browser: Inappropriate implementation in CORS https://bugzilla.redhat.com/show_bug.cgi?id=2192768 [ 8 ] Bug #2192769 - CVE-2023-2466 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192769 [ 9 ] Bug #2192770 - CVE-2023-2467 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192770 [ 10 ] Bug #2192771 - CVE-2023-2468 chromium-browser: Inappropriate implementation in PictureInPicture https://bugzilla.redhat.com/show_bug.cgi?id=2192771 engrampa-1.26.1-1.el9 (FEDORA-EPEL-2023-8d71c1f742) MATE Desktop file archiver Update Information: - update to 1.26.1 release ChangeLog: * Thu May 4 2023 Wolfgang Ulbrich - 1.26.1-1 - update to 1.26.1 mate-session-manager-1.26.1-1.el9 (FEDORA-EPEL-2023-4e15b23a64) MATE Desktop session manager Update Information: - update to 1.26.1 ChangeLog: * Fri May 5 2023 Wolfgang Ulbrich - 1.26.1-1 - update to 1.26.1 ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23 apptainer-1.1.8-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-342b96903b zarafa-7.1.14-6.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c1088e0644 tinyproxy-1.8.4-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing chromium-113.0.5672.63-1.el7 Details about builds: chromium-113.0.5672.63-1.el7 (FEDORA-EPEL-2023-0989e83e8a) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 113.0.5672.64. Fixes the following security issues: CVE-2023-2459 CVE-2023-2460 CVE-2023-2461 CVE-2023-2462 CVE-2023-2463 CVE-2023-2464 CVE-2023-2465 CVE-2023-2466 CVE-2023-2467 CVE-2023-2468 ChangeLog: * Wed May 3 2023 Than Ngo - 113.0.5672.63-1 - update to 113.0.5672.63 * Sun Apr 23 2023 Than Ngo - 112.0.5615.165-2 - make --use-gl=egl default for x11/wayland - enable WebUIDarkMode References: [ 1 ] Bug #2192762 - CVE-2023-2459 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192762 [ 2 ] Bug #2192763 - CVE-2023-2460 chromium-browser: Insufficient validation of untrusted input in Extensions https://bugzilla.redhat.com/show_bug.cgi?id=2192763 [ 3 ] Bug #2192764 - CVE-2023-2461 chromium-browser: Use after free in OS Inputs https://bugzilla.redhat.com/show_bug.cgi?id=2192764 [ 4 ] Bug #2192765 - CVE-2023-2462 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192765 [ 5 ] Bug #2192766 - CVE-2023-2463 chromium-browser: Inappropriate implementation in Full Screen Mode https://bugzilla.redhat.com/show_bug.cgi?id=2192766 [ 6 ] Bug #2192767 - CVE-2023-2464 chromium-browser: Inappropriate implementation in PictureInPicture https://bugzilla.redhat.com/show_bug.cgi?id=2192767 [ 7 ] Bug #2192768 - CVE-2023-2465 chromium-browser: Inappropriate implementation in CORS https://bugzilla.redhat.com/show_bug.cgi?id=2192768 [ 8 ] Bug #2192769 - CVE-2023-2466 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192769 [ 9 ] Bug #2192770 - CVE-2023-2467 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192770 [ 10 ] Bug #2192771 - CVE-2023-2468 chromium-browser: Inappropriate implementation in PictureInPicture https://bugzilla.redhat.com/show_bug.cgi?id=2192771 ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: gimp license corrected
Josef Řídký wrote: > Based on the SPDX requirements, that should be correct. Some parts of the > package are available under GPL-2.0-only and some under GPL-3.0-only > license. And they are not linked together? Because if they are, we have a problem! Kevin Kofler ___ 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] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 50 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4 apptainer-1.1.8-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ae97901b58 vtk-9.0.1-10.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing chromium-113.0.5672.63-1.el8 engrampa-1.26.1-1.el8 mate-session-manager-1.26.1-1.el8 scorep-6.0-18.el8 Details about builds: chromium-113.0.5672.63-1.el8 (FEDORA-EPEL-2023-f44d817bc9) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 113.0.5672.64. Fixes the following security issues: CVE-2023-2459 CVE-2023-2460 CVE-2023-2461 CVE-2023-2462 CVE-2023-2463 CVE-2023-2464 CVE-2023-2465 CVE-2023-2466 CVE-2023-2467 CVE-2023-2468 ChangeLog: * Wed May 3 2023 Than Ngo - 113.0.5672.63-1 - update to 113.0.5672.63 * Sun Apr 23 2023 Than Ngo - 112.0.5615.165-2 - make --use-gl=egl default for x11/wayland - enable WebUIDarkMode References: [ 1 ] Bug #2192762 - CVE-2023-2459 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192762 [ 2 ] Bug #2192763 - CVE-2023-2460 chromium-browser: Insufficient validation of untrusted input in Extensions https://bugzilla.redhat.com/show_bug.cgi?id=2192763 [ 3 ] Bug #2192764 - CVE-2023-2461 chromium-browser: Use after free in OS Inputs https://bugzilla.redhat.com/show_bug.cgi?id=2192764 [ 4 ] Bug #2192765 - CVE-2023-2462 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192765 [ 5 ] Bug #2192766 - CVE-2023-2463 chromium-browser: Inappropriate implementation in Full Screen Mode https://bugzilla.redhat.com/show_bug.cgi?id=2192766 [ 6 ] Bug #2192767 - CVE-2023-2464 chromium-browser: Inappropriate implementation in PictureInPicture https://bugzilla.redhat.com/show_bug.cgi?id=2192767 [ 7 ] Bug #2192768 - CVE-2023-2465 chromium-browser: Inappropriate implementation in CORS https://bugzilla.redhat.com/show_bug.cgi?id=2192768 [ 8 ] Bug #2192769 - CVE-2023-2466 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192769 [ 9 ] Bug #2192770 - CVE-2023-2467 chromium-browser: Inappropriate implementation in Prompts https://bugzilla.redhat.com/show_bug.cgi?id=2192770 [ 10 ] Bug #2192771 - CVE-2023-2468 chromium-browser: Inappropriate implementation in PictureInPicture https://bugzilla.redhat.com/show_bug.cgi?id=2192771 engrampa-1.26.1-1.el8 (FEDORA-EPEL-2023-72c1526931) MATE Desktop file archiver Update Information: - update to 1.26.1 release ChangeLog: * Thu May 4 2023 Wolfgang Ulbrich - 1.26.1-1 - update to 1.26.1 mate-session-manager-1.26.1-1.el8 (FEDORA-EPEL-2023-8a49a490ef) MATE Desktop session manager Update Information: - update to 1.26.1 ChangeLog: * Fri May 5 2023 Wolfgang Ulbrich - 1.26.1-1 - update to 1.26.1 scorep-6.0-18.el8 (FEDORA-EPEL-2023-219b058a50) Scalable Performance Measurement Infrastructure for Parallel Codes Update Information: Fix building from source. ChangeLog: * Fri May 5 2023 - 6.0-18 - Add patch to fix FTBFS with current opari2 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora
[EPEL-devel] Re: apptainer 1.1.8-1 has an incompatible change for apptainer-suid users
The NVD analysis at https://nvd.nist.gov/vuln/detail/CVE-2023-30549 is now finished and they agreed with the impact score that I gave it. They ended up with an even higher rating because they said the attack complexity was low. I think the complexity is high, but in either case the overall severity is rated High. Dave On Thu, May 04, 2023 at 10:17:42AM -0500, Dave Dykstra wrote: > DT, > > I am not all arguing that CVE-2022-1184 impact score was incorrect. I can't > imagine why you think that. > > By itself, CVE-2022-1184 is not a privilege escalation, because it can > normally only be exploited by someone with write access to the filesystem > boots, that is, root. Only with setuid-root apptainer/singularity does it > become a privilege escalation. > > I have said that I think that CVE-2022-1184's "Privileges Required" was > incorrect. It was you who suggested USB automounts being available to users > may have been their reason for setting it to "low". If that's what they > meant, then I think it makes perfect sense that they don't count that as a > privilege escalation because physical access already gives privilege > escalation in much easier ways. I said that that's probably why they only > counted it as denial of service since that was the only thing new. > > Dave > > On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote: > > Dave, > > > > On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote: > > > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote: > > > > On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel > > > > wrote: > > > > > > > > > > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote: > > > ... > > > > > > The Red Hat CVSS score for CVE-2022-1184 has the same breakdown as > > > > > > the > > > > > > NVD CVSS score. Both rate the "privileges required" property as > > > > > > low. > > > > > > From what I can tell that property would be rated high if they > > > > > > considered root privileges to be required. How does apptainer's use > > > > > > of setuid change anything here? > > > > > > > > > > According to the explanation I received from the ext4 kernel > > > > > developer, > > > > > Red Hat's CVSS rating was incorrect on that property. Without > > > > > singularity > > > > > or apptainer it does require high privileges to exploit. > > > > > > > > Red Hat's CVSS score breakdown for CVE-2022-1184 is: > > > > > > > > CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H > > > > > > > > You're suggesting that Red Hat's rating should have been higher > > > > because they didn't factor in low privileges, but that is objectively > > > > false because they did score it with low privileges. If they had > > > > scored it for high privileges, that would have dropped the rating down > > > > from 5.5 to 4.4. > > > > > > As DT pointed out, perhaps Red Hat was thinking that low privileges could > > > have been used by automounts of a USB device, but since that requires > > > physical access and there are much easier ways to get privilege escalation > > > with physical access, the only additional capability that would give to > > > a user is a crash, a denial of service. > > > > Impact scoring for a CVE doesn't depend on how it is triggered, though. If > > CVE-2022-1184 can provably give privilege escalation then it should be > > scored high on the impact (confidentiality/integrity/availability) metrics. > > It is not relevant to the impact whether I need physical access. The ease > > of the exploit is covered by the exploitability metrics, not the impact > > metrics. > > > > https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator > > > > My comment about automounts etc. was only related to why Red Hat might hve > > set the 'Privileges Required' property to low, even though `mount` is > > usually a root-only operation. Here you are arguing that CVE-2022-1184 was > > mis-scored on impact (confidentiality/integrity/availability). This is not > > related to my point about privileges required. > > > > > > There is no reason to believe that CVE-2022-1184 > > > > should have been marked as higher impact than it was, and thus I see > > > > no reason to justify the likely duplicate CVE-2023-30549 as high. > > > > > > Now you seem to be missing the point of CVE-2023-30549. I agree that > > > there's no reason to believe that CVE-2022-1184 should have been marked > > > as higher impact than it was, but CVE-2023-30549 is about the extra > > > impact that setuid-root apptainer (prior to 1.1.8) gives to users. > > > It gives any user with a local account write access to the underlying > > > bits of a filesystem, and since the filesystem can be easily corrupted > > > by the user, and since CVE-2022-1184 is a memory corruption bug and not > > > a simple panic, it potentially allows privilege escalation. That's why > > > CVE-2023-30549 is high severity. > > > > Again, this is conflating scoring how difficult it is to
Re: SPDX Statistics - ZX Spectrum edition
> Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase > ORs. Yea. I've been reading through the spec lately, since I want to add proper SPDX support to my project, and it says joiners should be uppercase and parsers should match case-sensitively. > License expression operators (AND, OR and WITH) should be matched in a > case-sensitive manner. https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/#d2-case-sensitivity A.FI. ___ 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: SPDX Statistics - ZX Spectrum edition
On 05. 05. 23 17:09, Miroslav Suchý wrote: Dne 03. 05. 23 v 14:38 Daniel P. Berrangé napsal(a): given we're not doing license minimization any more, I'm curious what package is going to win the prize for the longest license tag :-) So far: rpm-specs/perl-Exporter-Tidy.spec: 0BSD or AAL or AFL-3.0 or AGPL-3.0-only or APSL-2.0 or Apache-1.1 or Apache-2.0 or Artistic-2. 0 or BSD-1-Clause or BSD-2-Clause or BSD-3-Clause or BSD-3-Clause-LBNL or BSL-1.0 or CATOSL-1.1 or CDDL-1.0 or CNRI-Python or CPAL-1.0 or CPL-1.0 or CUA-OPL-1 .0 or ECL-1.0 or ECL-2.0 or EFL-2.0 or EPL-1.0 or EPL-2.0 or EUDatagrid or EUPL-1.1 or EUPL-1.2 or Entessa or Fair or GPL-1.0-only or GPL-2.0-only or GPL-3.0- only or HPND or IPL-1.0 or ISC or Jam or LGPL-2.0-only or LGPL-2.1-only or LGPL-3.0-only or LPL-1.02 or MIT or MIT-0 or MPL-1.0 or MPL-1.1 or MPL-2.0 or MS-PL or MS-RL or MirOS or Motosoto or NCSA or NGPL or NTP or Naumen or Nokia or OLDAP-2.8 or OSL-1.0 or OSL-2.1 or OSL-3.0 or PHP-3.01 or PostgreSQL or QPL-1.0 or RPSL-1.0 or SISSL or SPL-1.0 or Sleepycat or UPL-1.0 or Unicode-DFS-2016 or Unlicense or VSL-1.0 or W3C or ZPL-2.0 or ZPL-2.1 or Zlib That is 861 characters. Note that that license was long even before SDPX. Now it uses SPDX identifiers, but lowercase ors, should probably be uppercase ORs. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: How to drop 32bit support from the scientific Python stack
There is already an ancient similar request upstream with some hints how to achieve that (it was to disable s390 buikders for noarch packages, though): https://pagure.io/koji/issue/2229 Inviato da Proton Mail mobile Messaggio originale Il 5 Mag 2023, 18:19, Kevin Fenzi ha scritto: > On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote: > On 04. 05. 23 > 23:58, Kevin Fenzi wrote: > > On Thu, May 04, 2023 at 11:44:33PM +0200, Miro > Hrončok wrote: > > > On 04. 05. 23 23:40, Kevin Fenzi wrote: > > > > On Thu, > May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > > > > Hello folks, > > > > > ...snip... > > > > > Would that be possible? > > > > I don't think it > currently is... but sounds like a reasonable RFE to > > > > koji to me. > > > > > > > > > The way koji handles noarch packages is that it builds them on all > > > > > arches, checks to make sure they are all the same and just picks one > to > > > > be the 'output' build. > > > This is true for noarch subpackages > of arched packages. > > > > > > For fully noarch packages, it just builds > them on one architecture. > > Yep. You are correct, sorry for confusing the > issue there. > > > > I still think it could be something that koji would let > us do. > > When Koji triggers a noarch build job, it somehow knows it can > select *any* > builder we have. Is this a matter of our configuration or > upstream code? As far as I can tell, upstream. I could be missing something, > but I think noarch tasks just get the 'default' channel and any builder from > any arch thats in it. > E.g. do I need to file an issue at pagure.io/koji or > infra or releng? Upstream pagure.io/koji. If I am missing something and we > can do it in config they should be able to tell us. ;) kevin > ___ 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: mingw missing debuginfo
On 5/5/23 10:30, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 10:29:07AM -0600, Orion Poplawski wrote:
On 5/5/23 09:45, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
I'm trying to add mingw builds to the libssh package here:
https://src.fedoraproject.org/rpms/libssh/pull-request/15
build is failing with:
Could not open %files file
/home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
file or directory
What am I doing wrong?
Missing call to:
%{?mingw_debug_install_post}
in the %install section, after installing the mingw build
With regards,
Daniel
Thanks. That seems to be missing from the example spec files in the docs:
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_example_integrated_package_specfile
Yeah my bad. I documented it earlier
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_debuginfo_subpackage
but missed it from the example. Will send a fix next week.
With regards,
Daniel
Great, thanks. While I'm looking - it also looks like the shared
example static packages are not defined as noarch as well.
--
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/
smime.p7s
Description: S/MIME Cryptographic 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: mingw missing debuginfo
On Fri, May 05, 2023 at 10:29:07AM -0600, Orion Poplawski wrote:
> On 5/5/23 09:45, Daniel P. Berrangé wrote:
> > On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
> > > I'm trying to add mingw builds to the libssh package here:
> > >
> > > https://src.fedoraproject.org/rpms/libssh/pull-request/15
> > >
> > > build is failing with:
> > >
> > > Could not open %files file
> > > /home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
> > > file or directory
> > >
> > > What am I doing wrong?
> >
> > Missing call to:
> >
> > %{?mingw_debug_install_post}
> >
> > in the %install section, after installing the mingw build
> >
> > With regards,
> > Daniel
>
> Thanks. That seems to be missing from the example spec files in the docs:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_example_integrated_package_specfile
Yeah my bad. I documented it earlier
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_debuginfo_subpackage
but missed it from the example. Will send a fix next week.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: mingw missing debuginfo
On 5/5/23 09:45, Daniel P. Berrangé wrote:
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
I'm trying to add mingw builds to the libssh package here:
https://src.fedoraproject.org/rpms/libssh/pull-request/15
build is failing with:
Could not open %files file
/home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
file or directory
What am I doing wrong?
Missing call to:
%{?mingw_debug_install_post}
in the %install section, after installing the mingw build
With regards,
Daniel
Thanks. That seems to be missing from the example spec files in the docs:
https://docs.fedoraproject.org/en-US/packaging-guidelines/MinGW/#_example_integrated_package_specfile
--
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/
smime.p7s
Description: S/MIME Cryptographic 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: mingw pkgconfig reqs/provides
On Fri, May 5, 2023 at 11:14 AM Orion Poplawski wrote: > > I've submitted a test version of autogenerating mingw pkgconfig provides > and reqs here: > > https://github.com/rpm-software-management/rpm/pull/2504 > > This generates provides like: > > Provides: mingw32(libtiff-5.dll) mingw32(libtiffxx-5.dll) > mingw32-libtiff = 4.4.0-2.fc39 mingw32-pkgconfig(libtiff-4) = 4.4.0 > > Provides: mingw64(libtiff-5.dll) mingw64(libtiffxx-5.dll) > mingw64-libtiff = 4.4.0-2.fc39 mingw64-pkgconfig(libtiff-4) = 4.4.0 > I think it would probably make sense to have that as part of the mingw-filesystem package for each mingw type (w32, ucrt, w64, etc.) rather than in the rpm pkgconfigdeps generator upstream. Otherwise it's a great idea! -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: SPDX Statistics - ZX Spectrum edition
This is a questionable representation though. The license in question is: "Pick your favourite OSI approved license :) http://www.opensource.org/licenses/alphabetical; It might be more appropriate to have a license identifier that consists of those two lines. On Fri, May 5, 2023 at 11:09 AM Miroslav Suchý wrote: > > Dne 03. 05. 23 v 14:38 Daniel P. Berrangé napsal(a): > > > given we're not doing license minimization any more, I'm curious > what package is going to win the prize for the longest license tag :-) > > > So far: > > rpm-specs/perl-Exporter-Tidy.spec:0BSD or AAL or AFL-3.0 or > AGPL-3.0-only or APSL-2.0 or Apache-1.1 or Apache-2.0 or Artistic-2. > 0 or BSD-1-Clause or BSD-2-Clause or BSD-3-Clause or BSD-3-Clause-LBNL or > BSL-1.0 or CATOSL-1.1 or CDDL-1.0 or CNRI-Python or CPAL-1.0 or CPL-1.0 or > CUA-OPL-1 > .0 or ECL-1.0 or ECL-2.0 or EFL-2.0 or EPL-1.0 or EPL-2.0 or EUDatagrid or > EUPL-1.1 or EUPL-1.2 or Entessa or Fair or GPL-1.0-only or GPL-2.0-only or > GPL-3.0- > only or HPND or IPL-1.0 or ISC or Jam or LGPL-2.0-only or LGPL-2.1-only or > LGPL-3.0-only or LPL-1.02 or MIT or MIT-0 or MPL-1.0 or MPL-1.1 or MPL-2.0 or > MS-PL > or MS-RL or MirOS or Motosoto or NCSA or NGPL or NTP or Naumen or Nokia or > OLDAP-2.8 or OSL-1.0 or OSL-2.1 or OSL-3.0 or PHP-3.01 or PostgreSQL or > QPL-1.0 or > RPSL-1.0 or SISSL or SPL-1.0 or Sleepycat or UPL-1.0 or Unicode-DFS-2016 or > Unlicense or VSL-1.0 or W3C or ZPL-2.0 or ZPL-2.1 or Zlib > > That is 861 characters. > > > NEW: the package fedora-license-data now contains BNF grammar which you can > use. It is available in `/usr/share/fedora-license-data/grammar.lark` > > Any guidance on how to use this grammar ? > > https://pagure.io/copr/license-validate/blob/main/f/license-validate.py > > https://lark-parser.readthedocs.io/en/latest/how_to_use.html > > Miroslav > ___ > 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: How to drop 32bit support from the scientific Python stack
On Fri, May 05, 2023 at 12:15:31PM +0200, Miro Hrončok wrote: > On 04. 05. 23 23:58, Kevin Fenzi wrote: > > On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote: > > > On 04. 05. 23 23:40, Kevin Fenzi wrote: > > > > On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: > > > > > Hello folks, > > > > ...snip... > > > > > Would that be possible? > > > > I don't think it currently is... but sounds like a reasonable RFE to > > > > koji to me. > > > > > > > > The way koji handles noarch packages is that it builds them on all > > > > arches, checks to make sure they are all the same and just picks one to > > > > be the 'output' build. > > > This is true for noarch subpackages of arched packages. > > > > > > For fully noarch packages, it just builds them on one architecture. > > Yep. You are correct, sorry for confusing the issue there. > > > > I still think it could be something that koji would let us do. > > When Koji triggers a noarch build job, it somehow knows it can select *any* > builder we have. Is this a matter of our configuration or upstream code? As far as I can tell, upstream. I could be missing something, but I think noarch tasks just get the 'default' channel and any builder from any arch thats in it. > E.g. do I need to file an issue at pagure.io/koji or infra or releng? Upstream pagure.io/koji. If I am missing something and we can do it in config they should be able to tell us. ;) 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-18a0e3fa23 apptainer-1.1.8-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-342b96903b zarafa-7.1.14-6.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c1088e0644 tinyproxy-1.8.4-2.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing singularity-ce-3.11.3-1.el7 Details about builds: singularity-ce-3.11.3-1.el7 (FEDORA-EPEL-2023-3b5f9c33da) Application and environment virtualization Update Information: Upgrade to 3.11.3 upstream version. This is a compatible upgrade to a new upstream patch version. Upgrade to 3.11.2 upstream version. This is a compatible upgrade to a new upstream patch version. ChangeLog: * Fri May 5 2023 David Trudgian - 3.11.3-1 - Upgrade to 3.11.3 upstream version. - This is a compatible upgrade to a new upstream patch version. * Tue May 2 2023 David Trudgian - 3.11.2-1 - Upgrade to 3.11.2 upstream version. - This is a compatible upgrade to a new upstream patch version. ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 49 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-44ff2475c4 apptainer-1.1.8-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ae97901b58 vtk-9.0.1-10.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing singularity-ce-3.11.3-1.el8 Details about builds: singularity-ce-3.11.3-1.el8 (FEDORA-EPEL-2023-a9b52cfd9f) Application and environment virtualization Update Information: Upgrade to 3.11.3 upstream version. This is a compatible upgrade to a new upstream patch version. Upgrade to 3.11.2 upstream version. This is a compatible upgrade to a new upstream patch version. ChangeLog: * Fri May 5 2023 David Trudgian - 3.11.3-1 - Upgrade to 3.11.3 upstream version. - This is a compatible upgrade to a new upstream patch version. * Tue May 2 2023 David Trudgian - 3.11.2-1 - Upgrade to 3.11.2 upstream version. - This is a compatible upgrade to a new upstream patch version. ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b31211e2ce apptainer-1.1.8-1.el9 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b59aa78f7e vtk-9.1.0-18.el9 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-5114b71516 rust-below-0.6.3-4.el9 rust-cargo-c-0.9.12-4.el9 rust-pore-0.1.8-3.el9 0 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b40368566f libheif-1.15.2-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing hcxtools-6.3.0-1.el9 nfdump-1.7.2-1.el9 rttr-0.9.7-0.1git7edbd58.el9 singularity-ce-3.11.3-1.el9 Details about builds: hcxtools-6.3.0-1.el9 (FEDORA-EPEL-2023-fb7763cc25) Portable solution for conversion WiFi dump files to hashcat formats Update Information: Update to latest version ChangeLog: * Fri May 5 2023 Artem Polishchuk - 6.3.0-1 - chore: Update to 6.3.0 nfdump-1.7.2-1.el9 (FEDORA-EPEL-2023-5d3e6de9ed) NetFlow collecting and processing tools Update Information: nfdump-1.7.2 --- Nfdump-1.7.2 removes old code, and got some new features. It fixes a few bugs and improves stability. As of nfdump-1.7.2, it is now the recommended version in production. For the full list of changes, see the ChangeLog file. ChangeLog: * Thu May 4 2023 Denis Fateyev - 1.7.2-1 - Update to version 1.7.2 * Thu Jan 19 2023 Fedora Release Engineering - 1.7.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild References: [ 1 ] Bug #2189254 - nfdump-1.7.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=2189254 rttr-0.9.7-0.1git7edbd58.el9 (FEDORA-EPEL-2023-96c24eb4d2) Run Time Type Reflection Update Information: Introduce for epel9 ChangeLog: * Mon Aug 16 2021 Nicolas Chauvet - 0.9.7-0.1git7edbd58 - Update to pre 0.9.7 * Fri Jul 23 2021 Fedora Release Engineering - 0.9.6-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Thu Feb 25 2021 Nicolas Chauvet - 0.9.6-3 - Drop main package - Split docs * Wed Feb 24 2021 Nicolas Chauvet - 0.9.6-2 - Backport patch for aarch64 * Mon Feb 8 2021 Nicolas Chauvet - 0.9.6-1 - Initial spec file References: [ 1 ] Bug #2163575 - Please branch and build rttr in EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2163575 singularity-ce-3.11.3-1.el9 (FEDORA-EPEL-2023-ec7f73ecd7) Application and environment virtualization Update Information: Upgrade to 3.11.3 upstream version. This is a compatible upgrade to a new upstream patch version. Upgrade to 3.11.2 upstream version. This is a compatible upgrade to a new upstream patch version. ChangeLog: * Fri May 5 2023 David Trudgian - 3.11.3-1 - Upgrade to 3.11.3 upstream version. - This is a compatible upgrade to a new upstream patch version. * Tue May 2 2023 David Trudgian - 3.11.2-1 - Upgrade to 3.11.2 upstream version. - This is a compatible upgrade to a new upstream patch version. ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mingw missing debuginfo
On Fri, May 05, 2023 at 09:41:01AM -0600, Orion Poplawski wrote:
> I'm trying to add mingw builds to the libssh package here:
>
> https://src.fedoraproject.org/rpms/libssh/pull-request/15
>
> build is failing with:
>
> Could not open %files file
> /home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such
> file or directory
>
> What am I doing wrong?
Missing call to:
%{?mingw_debug_install_post}
in the %install section, after installing the mingw build
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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
mingw missing debuginfo
I'm trying to add mingw builds to the libssh package here: https://src.fedoraproject.org/rpms/libssh/pull-request/15 build is failing with: Could not open %files file /home/orion/fedora/libssh/libssh-0.10.4/mingw32-debugfiles.list: No such file or directory What am I doing wrong? -- 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/ smime.p7s Description: S/MIME Cryptographic 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: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity
On Fri, May 5, 2023 at 9:56 AM Chris Kelley wrote: > > As a purely logical expression, this simplifies to "GPL-2.0-or-later AND > LGPL-2.1-or-later". Is that sort of simplification not allowed? The short answer is, these are not truly logical expressions and therefore they shouldn't necessarily simplify. Of course you could adopt some arbitrary convention for such simplification, which might or might not be well-grounded in some interpretation of the licenses at issue. In the past, there was no documented uniform set of conventions and basically each package maintainer applied their own assumptions about how license expressions could be simplified, leading to general inconsistency across different packages. The general trend in Fedora that I observed over many years was that license tags were getting more specific, i.e. less "simplification" was being done (or ignoring certain licenses was occurring less). This is actually shown by the fact that the Callaway system had a "Public Domain" which was widely used in packages with license tags containing references to other licenses. So we aren't actually changing policy here. Still, the cases involving public domain dedications are fairly extreme in this regard. If we *were* to adopt some system of simplification of license expressions that's probably where we'd start. Richard > > On Fri, 5 May 2023, 13:20 Miro Hrončok, wrote: >> >> python-rpm-generators License tag changes from GPLv2+ to: >> >> GPL-2.0-or-later AND LGPL-2.1-or-later AND (LicenseRef-Fedora-Public-Domain >> OR >> LGPL-2.1-or-later OR GPL-2.0-or-later) >> >> https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67 >> >> Funny thing is that the "(LicenseRef-Fedora-Public-Domain OR >> LGPL-2.1-or-later >> OR GPL-2.0-or-later)" thing was originally chosen to keep the License tag of >> the package simple while allowing others to grab the code from it without >> obligations :/ >> >> -- >> Miro Hrončok > ___ 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 1729976] Add perl-LWP-Protocol-connect to EPEL-7
https://bugzilla.redhat.com/show_bug.cgi?id=1729976 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2023-05-05 15:23:24 --- Comment #17 from Fedora Update System --- FEDORA-EPEL-2023-3df600316e has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1729976 ___ 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: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity
How fun! Thanks for the links and explanation. On Fri, 5 May 2023 at 16:09, Miro Hrončok wrote: > On 05. 05. 23 16:28, Mamoru TASAKA wrote: > > Chris Kelley wrote on 2023/05/05 22:55: > >> As a purely logical expression, this simplifies to "GPL-2.0-or-later AND > >> LGPL-2.1-or-later". Is that sort of simplification not allowed? > >> > > > > This is no longer allowed: > > > https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis > > Also > > https://docs.fedoraproject.org/en-US/legal/license-field/#_combined_disjunctive_and_conjunctive_license_expressions > which says: > > """ > The license expression must reflect the disjunctive license choice even if > one > or both of the license identifiers in the OR expression also appear > separately > in the composite license expression. > > ... > > License: (GPL-3.0-or-later OR MPL-1.1) AND GPL-3.0-or-later AND MIT > > Here we repeat GPL-3.0-or-later because for one binary component it > appears as > part of an OR subexpression. That is, OR expressions must be treated as > though > they were a single distinct license. > """ > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ 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 1933287] EPEL8 Request: perl-File-Touch
https://bugzilla.redhat.com/show_bug.cgi?id=1933287 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2023-05-05 15:14:09 --- Comment #8 from Fedora Update System --- FEDORA-EPEL-2023-7763f70d89 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1933287 ___ 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
mingw pkgconfig reqs/provides
I've submitted a test version of autogenerating mingw pkgconfig provides and reqs here: https://github.com/rpm-software-management/rpm/pull/2504 This generates provides like: Provides: mingw32(libtiff-5.dll) mingw32(libtiffxx-5.dll) mingw32-libtiff = 4.4.0-2.fc39 mingw32-pkgconfig(libtiff-4) = 4.4.0 Provides: mingw64(libtiff-5.dll) mingw64(libtiffxx-5.dll) mingw64-libtiff = 4.4.0-2.fc39 mingw64-pkgconfig(libtiff-4) = 4.4.0 Thoughts? -- 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/ smime.p7s Description: S/MIME Cryptographic 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: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity
On 05. 05. 23 16:28, Mamoru TASAKA wrote: Chris Kelley wrote on 2023/05/05 22:55: As a purely logical expression, this simplifies to "GPL-2.0-or-later AND LGPL-2.1-or-later". Is that sort of simplification not allowed? This is no longer allowed: https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis Also https://docs.fedoraproject.org/en-US/legal/license-field/#_combined_disjunctive_and_conjunctive_license_expressions which says: """ The license expression must reflect the disjunctive license choice even if one or both of the license identifiers in the OR expression also appear separately in the composite license expression. ... License: (GPL-3.0-or-later OR MPL-1.1) AND GPL-3.0-or-later AND MIT Here we repeat GPL-3.0-or-later because for one binary component it appears as part of an OR subexpression. That is, OR expressions must be treated as though they were a single distinct license. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: SPDX Statistics - ZX Spectrum edition
Dne 03. 05. 23 v 14:38 Daniel P. Berrangé napsal(a): given we're not doing license minimization any more, I'm curious what package is going to win the prize for the longest license tag :-) So far: rpm-specs/perl-Exporter-Tidy.spec: 0BSD or AAL or AFL-3.0 or AGPL-3.0-only or APSL-2.0 or Apache-1.1 or Apache-2.0 or Artistic-2. 0 or BSD-1-Clause or BSD-2-Clause or BSD-3-Clause or BSD-3-Clause-LBNL or BSL-1.0 or CATOSL-1.1 or CDDL-1.0 or CNRI-Python or CPAL-1.0 or CPL-1.0 or CUA-OPL-1 .0 or ECL-1.0 or ECL-2.0 or EFL-2.0 or EPL-1.0 or EPL-2.0 or EUDatagrid or EUPL-1.1 or EUPL-1.2 or Entessa or Fair or GPL-1.0-only or GPL-2.0-only or GPL-3.0- only or HPND or IPL-1.0 or ISC or Jam or LGPL-2.0-only or LGPL-2.1-only or LGPL-3.0-only or LPL-1.02 or MIT or MIT-0 or MPL-1.0 or MPL-1.1 or MPL-2.0 or MS-PL or MS-RL or MirOS or Motosoto or NCSA or NGPL or NTP or Naumen or Nokia or OLDAP-2.8 or OSL-1.0 or OSL-2.1 or OSL-3.0 or PHP-3.01 or PostgreSQL or QPL-1.0 or RPSL-1.0 or SISSL or SPL-1.0 or Sleepycat or UPL-1.0 or Unicode-DFS-2016 or Unlicense or VSL-1.0 or W3C or ZPL-2.0 or ZPL-2.1 or Zlib That is 861 characters. NEW: the package fedora-license-data now contains BNF grammar which you can use. It is available in `/usr/share/fedora-license-data/grammar.lark` Any guidance on how to use this grammar ? https://pagure.io/copr/license-validate/blob/main/f/license-validate.py https://lark-parser.readthedocs.io/en/latest/how_to_use.html Miroslav___ 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 2122556] please provide an epel 9 build too
https://bugzilla.redhat.com/show_bug.cgi?id=2122556 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Fixed In Version|perl-Excel-Writer-XLSX-1.11 |perl-Excel-Writer-XLSX-1.11 |-1.el9 |-1.el9 ||perl-Excel-Writer-XLSX-1.11 ||-2.el9 Last Closed||2023-05-05 14:52:22 --- Comment #7 from Fedora Update System --- FEDORA-EPEL-2023-bca9051b31 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2122556 ___ 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: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity
Chris Kelley wrote on 2023/05/05 22:55: As a purely logical expression, this simplifies to "GPL-2.0-or-later AND LGPL-2.1-or-later". Is that sort of simplification not allowed? This is no longer allowed: https://docs.fedoraproject.org/en-US/legal/license-field/#_no_effective_license_analysis Yes, so I am also re-checking the whole sources in the srpm I maintain... Regards, Mamoru On Fri, 5 May 2023, 13:20 Miro Hrončok, wrote: python-rpm-generators License tag changes from GPLv2+ to: GPL-2.0-or-later AND LGPL-2.1-or-later AND (LicenseRef-Fedora-Public-Domain OR LGPL-2.1-or-later OR GPL-2.0-or-later) https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67 Funny thing is that the "(LicenseRef-Fedora-Public-Domain OR LGPL-2.1-or-later OR GPL-2.0-or-later)" thing was originally chosen to keep the License tag of the package simple while allowing others to grab the code from it without obligations :/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 ___ 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 2171943] perl-SNMP-Info-3.92 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2171943 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-SNMP-Info-3.92-1.fc39 |perl-SNMP-Info-3.92-1.fc39 ||perl-SNMP-Info-3.92-1.fc38 Resolution|--- |ERRATA Status|ON_QA |CLOSED Last Closed||2023-05-05 14:20:38 --- Comment #6 from Fedora Update System --- FEDORA-2023-06a03c01a8 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2171943 ___ 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
[EPEL-devel] KDE on CentOS Stream 9
There is a new qt5 update in CentOS Stream 9. This update will be going out when RHEL 9.3 is released six months from now. Again, that is RHEL 9.3, NOT 9.2. I am currently rebuilding KDE for CentOS Stream 9. This will take some time to rebuild and make it through testing. I am suspecting it will not be in stable until May 18. It is a known issue that is being resolved. No need for further bugs. If you have already created a bug, please cc me (tdaw...@redhat.com) on it, because most of the bugs do not get assigned to me. Thank You Troy ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity
As a purely logical expression, this simplifies to "GPL-2.0-or-later AND LGPL-2.1-or-later". Is that sort of simplification not allowed? On Fri, 5 May 2023, 13:20 Miro Hrončok, wrote: > python-rpm-generators License tag changes from GPLv2+ to: > > GPL-2.0-or-later AND LGPL-2.1-or-later AND > (LicenseRef-Fedora-Public-Domain OR > LGPL-2.1-or-later OR GPL-2.0-or-later) > > https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67 > > Funny thing is that the "(LicenseRef-Fedora-Public-Domain OR > LGPL-2.1-or-later > OR GPL-2.0-or-later)" thing was originally chosen to keep the License tag > of > the package simple while allowing others to grab the code from it without > obligations :/ > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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
[EPEL-devel] Re: A CenOS Stream package missing during EPEL9 build: unresponsive CentOS Stream @redhat maintainers
On Thu, May 4, 2023 at 12:57 PM Marcin Dulak wrote: > Hi, > > I have a bugzilla opened about a CenOS Stream package missing during EPEL9 > builds > https://bugzilla.redhat.com/show_bug.cgi?id=2182460, for over a month > with no response. > > Can something be done about this, apart from trying to reach the > maintainers on their corporate emails? > Please do not try to contact the maintainers on their corporate emails. If you are in a rush, then consider creating an -epel package. Details are here. https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/ Troy ___ 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: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
PyPI name blocking request for vkbasalt-cli
On 27-04-2023 14:26, Sandro wrote: Well, I submitted the package for review [2] and have been told that vkbasalt not being published on PyPI is an issue wrt naming parity. So, I filed a bug requesting publication on PyPI [3], but I haven't heard back from upstream, yet. If upstream remains unresponsive, I would need to either publish it myself or get the name reserved as described in PyPI parity [4]. It has been almost two weeks and I haven't heard back from upstream regarding my request for publication on PyPI. What are the next steps I should take in line with PyPI parity? I'm leaning towards "Ask Python SIG to block the name on PyPI for you" and will consider publishing it myself at a later stage should upstream remain unresponsive. [2] https://bugzilla.redhat.com/show_bug.cgi?id=2188653 [3] https://gitlab.com/TheEvilSkeleton/vkbasalt-cli/-/issues/10 [4] https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_pypi_parity -- Sandro ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Changing the License tag of python-rpm-generators from GPLv2+ to a monstrosity
python-rpm-generators License tag changes from GPLv2+ to: GPL-2.0-or-later AND LGPL-2.1-or-later AND (LicenseRef-Fedora-Public-Domain OR LGPL-2.1-or-later OR GPL-2.0-or-later) https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/67 Funny thing is that the "(LicenseRef-Fedora-Public-Domain OR LGPL-2.1-or-later OR GPL-2.0-or-later)" thing was originally chosen to keep the License tag of the package simple while allowing others to grab the code from it without obligations :/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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: Koji: Could the initial side tag repo be copied from parent (to avoid worflow delays)?
On 06. 04. 23 21:51, Kevin Fenzi wrote: On Thu, Apr 06, 2023 at 08:21:36AM +0200, Miro Hrončok wrote: Hello, When using custom side tags like this: $ fedpkg request-side-tag $ fedpkg chain-build --target f38-build-side-... ... One of the obstacles is that the initial waitrepo for the job takes a lot of time, (e.g. 10+ minutes). That is not comfortable for the package maintainer -- it's faster to use buildroot overrides. I wonder if the initial createrepo could be skipped entirely by symlinking / copying / using the already available repository from the base (parent) tag. That could make this workflow more attractive. The sidetag plugin code is in upstream koji. This sounds like a great RFE for koji then? I don't know why it's not done that way, there might be a reason or might be an oversight, but please file a RFE on it? :) https://pagure.io/koji/issue/3808 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Fedora rawhide compose report: 20230505.n.0 changes
OLD: Fedora-Rawhide-20230504.n.0 NEW: Fedora-Rawhide-20230505.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 5 Dropped packages:0 Upgraded packages: 135 Downgraded packages: 0 Size of added packages: 3.75 MiB Size of dropped packages:0 B Size of upgraded packages: 2.59 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 18.86 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: perl-Test-Future-IO-Impl-0.14-2.fc39 Summary: Acceptance tests for Future::IO implementations RPMs:perl-Test-Future-IO-Impl Size:19.26 KiB Package: python-pyqt6-charts-6.4.0-1.fc39 Summary: Set of Python bindings for The Qt Charts library RPMs:python3-pyqt6-charts python3-pyqt6-charts-devel Size:1.12 MiB Package: python-pyqt6-webengine-6.4.0-1.fc39 Summary: Python bindings for Qt6WebEngine RPMs:python3-pyqt6-webengine python3-pyqt6-webengine-devel Size:374.36 KiB Package: python-setuptools-gettext-0.1.3-2.fc39 Summary: Setuptools gettext extension plugin RPMs:python3-setuptools-gettext Size:20.36 KiB Package: qt6-qtlanguageserver-6.5.0-1.fc39 Summary: Qt6 - LanguageServer component RPMs:qt6-qtlanguageserver qt6-qtlanguageserver-devel Size:2.23 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: GtkAda3-2:23.0.0-1.fc39 Old package: GtkAda3-2020-9.fc38 Summary: GTKada, an Ada binding to GTK+ 3 RPMs: GtkAda3 GtkAda3-devel GtkAda3-doc Dropped RPMs: GtkAda3-gl Size: 28.33 MiB Size change: -3.15 MiB Changelog: * Sun Feb 12 2023 Dennis van Raaij - 2:22.0.0-1 - Updated to v22.0.0, using the archive available on GitHub. - Changed the epoch, to mark the new upstream version scheme. - Removed year/version from the patch filenames; version control should suffice. - Added a build step to make the GtkAda User's Guide (in HTML and PDF). - Removed the GtkAda Reference Manual; build requires Gnatdoc which is not available yet on Fedora. - License fields now contain SPDX license expressions. - Use 'gprinstall' instead of 'make_install' to have better control of what goes where. - The file 'testgtk.gpr' is now updated during prep to handle the artifacts properly. - Fixed the package version and so-version. - The build is now staged to allow gtkada-dialog to be a position-independent executable. - Now using the python3 macro to reference the python3 interpreter (option to make generate). - Updated the doc package license. - Removed a reference to the GtkAda Reference Manual from the GNAT Studio plugin. - Improved spec file readability. * Tue Feb 14 2023 Dennis van Raaij - 2:23.0.0-1 - Updated to v23.0.0, using the archive available on GitHub. - The subpackage GtkAda3-gl and the library libgtkada_gl.so are gone because GTK.GLarea is now included in libgtkada.so. - Removed patch GtkAda3-3.14.2-libs.patch; the unused direct dependencies are no longer there. - Added a new build dependency: Sphinx theme from readthedocs.org (commit 7b446c4). - The version string in 'gtkada.gpr' (SOURCE4) is now updated automatically. Package: NetworkManager-1:1.43.7-1.fc39 Old package: NetworkManager-1:1.43.6-1.fc39 Summary: Network connection manager and user applications RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora NetworkManager-config-server NetworkManager-dispatcher-routing-rules NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi NetworkManager-wwan Size: 25.54 MiB Size change: -32.27 KiB Changelog: * Thu May 04 2023 Thomas Haller - 1:1.43.7-1 - Update to 1.43.7 release (development) Package: alsa-lib-1.2.9-1.fc39 Old package: alsa-lib-1.2.8-3.fc38 Summary: The Advanced Linux Sound Architecture (ALSA) library RPMs: alsa-lib alsa-lib-devel alsa-topology alsa-ucm Size: 7.13 MiB Size change: 25.32 KiB Changelog: * Thu May 04 2023 Jaroslav Kysela - 1.2.9-1 - update to 1.2.9 Package: alsa-utils-1.2.9-1.fc39 Old package: alsa-utils-1.2.8-2.fc38 Summary: Advanced Linux Sound Architecture (ALSA) utilities RPMs: alsa-topology-utils alsa-ucm-utils alsa-utils alsa-utils-alsabat Size: 5.12 MiB Size change: 49.49 KiB Changelog: * Thu May 04 2023 Jaroslav Kysela - 1.2.9-1 * Updated to 1.2.9 Package: awscli-1.27.127-1.fc39 Old package: awscli-1.27.126-1.fc39 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 3.31 MiB Size change: -330 B Changelog: * Thu May 04 2023 Gwyn Ciesla - 1.27.127-1 - 1.27.127 Package: bacula-13.0.3-1
[Bug 2189445] perl-DBIx-QueryLog-0.42-13.fc39 FTBFS: File not found: /builddir/build/BUILDROOT/perl-DBIx-QueryLog-0.42-13.fc39.noarch/usr/share/man/man1/*
https://bugzilla.redhat.com/show_bug.cgi?id=2189445 Denis Fateyev changed: What|Removed |Added Resolution|--- |RAWHIDE Status|NEW |CLOSED Last Closed||2023-05-05 11:25:05 --- Comment #1 from Denis Fateyev --- I've dropped unnecessary man files references https://koji.fedoraproject.org/koji/taskinfo?taskID=100765061 https://bodhi.fedoraproject.org/updates/FEDORA-2023-a33f8b305a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2189445 ___ 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: How to drop 32bit support from the scientific Python stack
On 04. 05. 23 23:58, Kevin Fenzi wrote: On Thu, May 04, 2023 at 11:44:33PM +0200, Miro Hrončok wrote: On 04. 05. 23 23:40, Kevin Fenzi wrote: On Thu, May 04, 2023 at 04:03:49PM +0200, Miro Hrončok wrote: Hello folks, ...snip... Would that be possible? I don't think it currently is... but sounds like a reasonable RFE to koji to me. The way koji handles noarch packages is that it builds them on all arches, checks to make sure they are all the same and just picks one to be the 'output' build. This is true for noarch subpackages of arched packages. For fully noarch packages, it just builds them on one architecture. Yep. You are correct, sorry for confusing the issue there. I still think it could be something that koji would let us do. When Koji triggers a noarch build job, it somehow knows it can select *any* builder we have. Is this a matter of our configuration or upstream code? E.g. do I need to file an issue at pagure.io/koji or infra or releng? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
[Test-Announce] Kernel 6.3 Test Week 2023-05-07
Hey All, I would like to invite all of you to participate in the Kernel 6.3 Test week is happening from 2023-05-07 to 2023-05-14. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-...@libera.chat for question and discussion. [0] http://fedoraproject.org/wiki/Test_Day:2023-05-07_Kernel_6.3_Test_Week [1] https://testdays.fedoraproject.org/events/157 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-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/test-annou...@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
