[EPEL-devel] Proposed incompatible update of zeek in EPEL 8 and 9
Dear all, zeek, an open source network security monitoring tool, has an out of date version, 4.2.0 packaged for EPEL 8 and 9: https://src.fedoraproject.org/rpms/zeek/ It was also never built for Fedora. Per upstream documentation, https://github.com/zeek/zeek/wiki/Release-Cadence#types-of-releases - LTS releases (x.0.z) are made every year - LTS releases are supported until the first feature release after the following LTS ((x+1).1.0) - or roughly four months after the next LTS 6.0.0 just came out at the end of May. Since the Fedora branches are currently unused, my plan is: - use them to track feature releases (currently 6.0.0) - update EPEL 8 and 9 to track 6.0.z - for future updates, keep EPEL branches on the current LTS until it goes out of support, then do an incompatible upgrade to the next LTS - for new EPEL branches, start off with the last LTS build in rawhide (e.g. 6.0.3) and update it to the latest patch release in the same major version (e.g. 6.0.5) This is just a heads up right now, I plan to do a build for Rawhide tomorrow, and based on discussion here an update for EPEL 8/9 will, or will not, be built next week. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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] Retiring python-django in EPEL 7 and EPEL 8
Dear all, I'm proposing that we retire python-django in EPEL 7 and EPEL 8 The versions are really old and no longer supported; see https://www.djangoproject.com/download/ EPEL 7: 1.11.27 EPEL 8: 2.2.24 There are a lot of CVEs open, and upstream only patch the versions that are still supported, understandably: https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=product%2Ccomponent%2Cassigned_to%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cbug_severity=python-django=id%2C%20=Fedora%20EPEL_format=advanced For EPEL 8, python-django3 is a suitable replacement: https://src.fedoraproject.org/rpms/python-django3 - it reaches end of extended support in April 2024 though. It tracks the 3.2 LTS branch. python-django4.2 will be made available as well for Fedora, EPEL 9 and EPEL 8. I currently don't plan to make a replacement Django available for EPEL 7, but if you need it, please reply to this email. This proposal is open for discussion for a week, and will be reviewed at the next EPEL meeting, per https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/ Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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: zlib-ng as a compat replacement for zlib
On Mon, Aug 07, 2023 at 09:29:08AM -0300, Tulio Magno Quites Machado Filho
wrote:
> "Richard W.M. Jones" writes:
>
> > The background to this is I've spent far too long trying to optimize
> > the conversion of qcow2 files to raw files. Most existing qcow2 files
> > that you can find online are zlib compressed, including the qcow2
> > images provided by Fedora. Each cluster in the file is separately
> > compressed as a zlib stream, and qemu uses zlib library functions to
> > decompress them. When downloading and decompressing these files, I
> > measured 40%+ of the total CPU time is doing zlib decompression.
>
> This number may go even higher on s390x [1] because zlib-ng supports
> hardware acceleration.
>
> qatzip [2] and libnxz [3] should provide performance on the same order of
> magnitude for Intel and Power9 processors, with the negative side of not
> using a single library.
>
> > We already package zlib-ng in Fedora:
> >
> > https://src.fedoraproject.org/rpms/zlib-ng/blob/rawhide/f/zlib-ng.spec
> > https://github.com/zlib-ng/zlib-ng
> >
> > In my test zlib-ng is about 40% faster.
> >
> > Sadly zlib-ng is not compiled with the ZLIB_COMPAT option. What this
> > means in practice is that the zlib functions have different names
> > (eg. zng_inflateInit instead of inflateInit). It is not a drop-in
> > replacement for zlib and software would need to be adjusted to use it.
> >
> > However there is this bug / RFE to package the compat library.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2145239
> >
> > It literally replaces /usr/lib64/libz.so.1, so pretty high stakes. It
> > has the appropriate Provides/Conflicts.
> >
> > Anyway, 40% (or whatever, but significant) performance improvement
> > sounds good for a very widely used operation.
> >
> > So I'd like to ask Fedora ...
> >
> > What do we think about the opt in approach of adding a patch similar
> > to the one proposed in bug 2145239, where I think you could "simply"
> > install zlib-ng to get better performance with existing software?
> > ("simply" because it seems high risk of going wrong)
>
> Wearing my zlib-ng fedora maintainer hat:
> I like the idea of this patch, although I think it needs a few changes.
> I'd like to merge it and add another package with the same source code,
> but different value for compat, i.e. package zlib-ng would still
> distribute the zlib-ng API while the new package would distribute the
> zlib-compatible API.
Would it help with maintenance, security issues etc. if we keep a single
package, and simply perform the build twice?
e.g. ncurses does this:
https://src.fedoraproject.org/rpms/ncurses/blob/rawhide/f/ncurses.spec#_145-165
Best regards,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
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: RFC: PR to update exiv2 in Rawhide
On Mon, Aug 21, 2023 at 09:04:20PM +, Gary Buhrmaster wrote: > On Mon, Aug 21, 2023 at 7:02 PM Michel Alexandre Salim > wrote: > > > > Dear all, > > > > exiv2 has had a new release for a few months now - 0.28.0 - which causes > > an soname bump. > > > > I've put up a PR for the update - > > https://src.fedoraproject.org/rpms/exiv2/pull-request/3 - would > > appreciate people taking a close look at this; I'll also prepare a COPR > > with the dependent packages rebuilt > > > > In the meantime, there's a 0.27.7 bugfix release, any objection to > > getting that packaged for stable releases? > > > Per https://bugzilla.redhat.com/show_bug.cgi?id=1979565#c12 > there appears to still be a pending legal review issue and > you may need to scrub the sources of the BMFF parts before > uploading to dist-git. > > I believe legal was pinged recently as to the status of the > BMFF question. > > I have CC: the legal mailing list in case they have any > input. Hoo boy. Probably best to wait a bit to hear from legal before proceeding, agreed. Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: RFC: PR to update exiv2 in Rawhide
On Mon, Aug 21, 2023 at 02:01:37PM -0500, Michel Alexandre Salim wrote: > Dear all, > > exiv2 has had a new release for a few months now - 0.28.0 - which causes > an soname bump. > > I've put up a PR for the update - > https://src.fedoraproject.org/rpms/exiv2/pull-request/3 - would > appreciate people taking a close look at this; I'll also prepare a COPR > with the dependent packages rebuilt > > In the meantime, there's a 0.27.7 bugfix release, any objection to > getting that packaged for stable releases? > > https://exiv2.org/whatsnew.html > https://github.com/Exiv2/exiv2/pull/2567#issuecomment-1546701495 > Here's the PR for updating Fedora 38 to 0.27.7 - looks like this one is straightforward, no soname bump or any change needed apart from modifying the source URL (exiv2 stops hosting release tarballs on their site) Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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
RFC: PR to update exiv2 in Rawhide
Dear all, exiv2 has had a new release for a few months now - 0.28.0 - which causes an soname bump. I've put up a PR for the update - https://src.fedoraproject.org/rpms/exiv2/pull-request/3 - would appreciate people taking a close look at this; I'll also prepare a COPR with the dependent packages rebuilt In the meantime, there's a 0.27.7 bugfix release, any objection to getting that packaged for stable releases? https://exiv2.org/whatsnew.html https://github.com/Exiv2/exiv2/pull/2567#issuecomment-1546701495 $ rpmdistro-repoquery fedora rawhide --enablerepo=fedora-source --whatrequires exiv2-devel berry-0:1.0.0-19.fc39.src calligra-0:3.2.1-25.fc39.src darktable-0:4.4.2-1.fc40.src digikam-0:8.1.0-3.fc39.src geeqie-0:2.0.1-6.fc39.src gegl04-0:0.4.44-3.fc39.src gerbera-0:1.12.1-7.fc39.src gimp-lensfun-0:0.2.4-22.fc39.src gnome-commander-4:1.16.1-2.fc39.src gpscorrelate-0:2.0-8.fc39.src gthumb-1:3.12.2-9.fc39.src gwenview-1:23.04.3-2.fc39.src hugin-0:2022.0.0-4.fc39.src immix-0:1.3.2-44.fc39.src kde-runtime-0:17.08.3-28.fc39.src kf5-kfilemetadata-0:5.109.0-1.fc39.src kf5-libkexiv2-0:23.04.3-2.fc39.src kio-extras-0:23.04.3-2.fc39.src kphotoalbum-0:5.9.1-3.fc39.src krename-1:5.0.2-4.fc40.src krita-0:5.1.5-5.fc39.src libextractor-0:1.10-11.fc39.src libgexiv2-0:0.14.2-1.fc39.src libgexiv2-devel-0:0.14.2-1.fc39.i686 libgexiv2-devel-0:0.14.2-1.fc39.x86_64 luminance-hdr-0:2.6.1.1-59.fc39.src merkaartor-0:0.18.4-20.fc39.src nomacs-0:3.16-17.fc39.src pcmanfm-qt-0:1.3.0-1.fc39.src pdf2djvu-0:0.9.19-5.fc39.src photoqt-0:3.3-3.fc39.src phototonic-0:2.1.12-20190930gitd2176fe.fc39.src python3-exiv2-0:0.9.3-11.fc39.src qgis-0:3.32.1-2.fc40.src qimgv-0:1.0.3-10.fc39.src rawstudio-0:2.1-0.33.20210527.git58a8959.fc39.src rawtherapee-0:5.9-5.fc39.src siril-0:1.0.6-8.fc39.src taglib-sharp-0:2.1.0.0-21.fc39.src ufraw-0:0.23-0.17.20210425.fc39.src viewnior-0:1.8-7.fc39.src Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: [heads up] upcoming libplist soname bump
On Mon, Jul 31, 2023 at 06:48:14PM -0700, Adam Williamson wrote: > On Mon, 2023-07-31 at 16:45 -0500, Michel Alexandre Salim wrote: > > On Sat, Jul 29, 2023 at 08:59:18AM -0700, Adam Williamson wrote: > > > On Fri, 2023-07-28 at 21:41 -0500, Michel Alexandre Salim wrote: > > > > Dear all, > > > > > > > > As part of the Fedora Asahi SIG work, libimobiledevice and libplist are > > > > getting updated. > > > > > > > > The libplist update introduces an soname bump from 3 to 4: > > > > https://src.fedoraproject.org/rpms/libplist/c/68103e8e4f0783e2bfbd5d54040407eb3cc4c80c?branch=rawhide > > > > > > > > As such, the work is being done in a side tag, f39-build-side-70661 > > > > https://koji.fedoraproject.org/koji/builds?inherited=0=70661=-build_id=1 > > > > > > > > $ rpmdistro-repoquery fedora rawhide --whatrequires > > > > 'libplist-2.0.so.3()(64bit)' > > > > Last metadata expiration check: 0:05:50 ago on Fri Jul 28 21:28:27 2023. > > > > gvfs-afc-0:1.51.1-3.fc39.x86_64 > > > > idevicerestore-0:1.0.0-4.fc39.x86_64 > > > > ifuse-0:1.1.4-8.fc39.x86_64 > > > > kf5-solid-0:5.108.0-1.fc39.x86_64 > > > > libgpod-0:0.8.3-46.fc39.x86_64 > > > > libimobiledevice-0:1.3.0-9.fc39.x86_64 > > > > libimobiledevice-utils-0:1.3.0-9.fc39.x86_64 > > > > libplist-devel-0:2.2.0-11.fc39.x86_64 > > > > libusbmuxd-0:2.0.2-9.fc39.x86_64 > > > > python3-libplist-0:2.2.0-11.fc39.x86_64 > > > > upower-0:1.90.2-2.fc39.x86_64 > > > > usbmuxd-0:1.1.1-10.fc39.x86_64 > > > > > > > > > > > > $ rpmdistro-repoquery fedora rawhide --whatrequires > > > > 'libplist++-2.0.so.3()(64bit)' > > > > Last metadata expiration check: 0:06:02 ago on Fri Jul 28 21:28:27 2023. > > > > libplist-devel-0:2.2.0-11.fc39.x86_64 > > > > > > > > If any package is not on this list, please build it against the side > > > > tag; we are going to land this next week. > > > > > > Thanks very much for doing this properly on a side tag! > > > > Happy to oblige! I'll wait until Friday before landing the builds. > > > > For those who want to test, you can add this to /etc/yum.repos.d : > > > > [libplist] > > name='Rawhide sidetag for libplist' > > baseurl=https://kojipkgs.fedoraproject.org/repos/f39-build-side-70661/latest/$basearch/ > > cost=2000 > > enabled=False > > skip_if_unavailable=False > > I've fired the openQA update tests on this side tag, results should > come through at > https://openqa.stg.fedoraproject.org/tests/overview?distri=fedora=39=TAG_f39-build-side-70661-NOREPORT=2 > . If anything fails I'll look into it. Looks like there's one softfail, _console_avc_crash: https://openqa.stg.fedoraproject.org/tests/3027955 Probably a coincidence, since I can't imagine how the update causes this. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: [heads up] upcoming libplist soname bump
On Sat, Jul 29, 2023 at 08:59:18AM -0700, Adam Williamson wrote: > On Fri, 2023-07-28 at 21:41 -0500, Michel Alexandre Salim wrote: > > Dear all, > > > > As part of the Fedora Asahi SIG work, libimobiledevice and libplist are > > getting updated. > > > > The libplist update introduces an soname bump from 3 to 4: > > https://src.fedoraproject.org/rpms/libplist/c/68103e8e4f0783e2bfbd5d54040407eb3cc4c80c?branch=rawhide > > > > As such, the work is being done in a side tag, f39-build-side-70661 > > https://koji.fedoraproject.org/koji/builds?inherited=0=70661=-build_id=1 > > > > $ rpmdistro-repoquery fedora rawhide --whatrequires > > 'libplist-2.0.so.3()(64bit)' > > Last metadata expiration check: 0:05:50 ago on Fri Jul 28 21:28:27 2023. > > gvfs-afc-0:1.51.1-3.fc39.x86_64 > > idevicerestore-0:1.0.0-4.fc39.x86_64 > > ifuse-0:1.1.4-8.fc39.x86_64 > > kf5-solid-0:5.108.0-1.fc39.x86_64 > > libgpod-0:0.8.3-46.fc39.x86_64 > > libimobiledevice-0:1.3.0-9.fc39.x86_64 > > libimobiledevice-utils-0:1.3.0-9.fc39.x86_64 > > libplist-devel-0:2.2.0-11.fc39.x86_64 > > libusbmuxd-0:2.0.2-9.fc39.x86_64 > > python3-libplist-0:2.2.0-11.fc39.x86_64 > > upower-0:1.90.2-2.fc39.x86_64 > > usbmuxd-0:1.1.1-10.fc39.x86_64 > > > > > > $ rpmdistro-repoquery fedora rawhide --whatrequires > > 'libplist++-2.0.so.3()(64bit)' > > Last metadata expiration check: 0:06:02 ago on Fri Jul 28 21:28:27 2023. > > libplist-devel-0:2.2.0-11.fc39.x86_64 > > > > If any package is not on this list, please build it against the side > > tag; we are going to land this next week. > > Thanks very much for doing this properly on a side tag! Happy to oblige! I'll wait until Friday before landing the builds. For those who want to test, you can add this to /etc/yum.repos.d : [libplist] name='Rawhide sidetag for libplist' baseurl=https://kojipkgs.fedoraproject.org/repos/f39-build-side-70661/latest/$basearch/ cost=2000 enabled=False skip_if_unavailable=False Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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
[heads up] upcoming libplist soname bump
Dear all, As part of the Fedora Asahi SIG work, libimobiledevice and libplist are getting updated. The libplist update introduces an soname bump from 3 to 4: https://src.fedoraproject.org/rpms/libplist/c/68103e8e4f0783e2bfbd5d54040407eb3cc4c80c?branch=rawhide As such, the work is being done in a side tag, f39-build-side-70661 https://koji.fedoraproject.org/koji/builds?inherited=0=70661=-build_id=1 $ rpmdistro-repoquery fedora rawhide --whatrequires 'libplist-2.0.so.3()(64bit)' Last metadata expiration check: 0:05:50 ago on Fri Jul 28 21:28:27 2023. gvfs-afc-0:1.51.1-3.fc39.x86_64 idevicerestore-0:1.0.0-4.fc39.x86_64 ifuse-0:1.1.4-8.fc39.x86_64 kf5-solid-0:5.108.0-1.fc39.x86_64 libgpod-0:0.8.3-46.fc39.x86_64 libimobiledevice-0:1.3.0-9.fc39.x86_64 libimobiledevice-utils-0:1.3.0-9.fc39.x86_64 libplist-devel-0:2.2.0-11.fc39.x86_64 libusbmuxd-0:2.0.2-9.fc39.x86_64 python3-libplist-0:2.2.0-11.fc39.x86_64 upower-0:1.90.2-2.fc39.x86_64 usbmuxd-0:1.1.1-10.fc39.x86_64 $ rpmdistro-repoquery fedora rawhide --whatrequires 'libplist++-2.0.so.3()(64bit)' Last metadata expiration check: 0:06:02 ago on Fri Jul 28 21:28:27 2023. libplist-devel-0:2.2.0-11.fc39.x86_64 If any package is not on this list, please build it against the side tag; we are going to land this next week. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Retiring python-pytest-flake8
On Fri, Jul 28, 2023 at 11:39:56AM -0500, Michel Alexandre Salim wrote:
> On Fri, Jul 28, 2023 at 12:17:54AM +0200, Sandro wrote:
> > On 27-07-2023 22:57, Sandro wrote:
> > > On 27-07-2023 21:02, Michel Alexandre Salim wrote:
> > > > Thanks Miro!
> > > >
> > > > On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> > > > > On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > > > > > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > > > > > enablerepo=fedora-source --whatrequires python-pytest-flake8
> > > > >
> > > > > Always use the actual binary package name for queries like this, as
> > > > > only the
> > > > > actual package name will show all dependencies that happen to require
> > > > > a
> > > > > differetn virtual provide:
> > > > >
> > > > > $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> > > > > pytest-flake8
> > > > > cvise-0:2.4.0-3.fc36.src
> > > > > python-cssutils-0:2.6.0-2.fc38.src
> > > > > python-nashpy-0:0.0.37-1.fc39.src
> > > > > python-pyunicorn-0:0.6.1-12.fc38.src
> > > > >
> > > > >
> > > > nashpy is fixed, but I'll take a look at the others. Given the disttags
> > > > they look like they FTBFSed anyway (cvise is fc36, ouch!)
> > >
> > > I can take care of pyunicorn. It looks simple enough.
> >
> > Consider pyunicorn fixed. The package itself is still broken, but that's
> > numpy related not due to the removal of pytest-flake8.
> >
> Thank you!
>
> I'll check cvise and cssutils.
>
cvise has an open PR that fixes it (and get it to build again):
https://src.fedoraproject.org/rpms/cvise/pull-request/3
python-cssutils is fixed in
https://src.fedoraproject.org/rpms/python-cssutils/pull-request/2
python-pytest-flake8 is now retired. Thanks for everyone who patched the
dependent packages!
Best,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
___
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
Re: Retiring python-pytest-flake8
On Fri, Jul 28, 2023 at 11:39:56AM -0500, Michel Alexandre Salim wrote:
> On Fri, Jul 28, 2023 at 12:17:54AM +0200, Sandro wrote:
> > On 27-07-2023 22:57, Sandro wrote:
> > > On 27-07-2023 21:02, Michel Alexandre Salim wrote:
> > > > Thanks Miro!
> > > >
> > > > On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> > > > > On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > > > > > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > > > > > enablerepo=fedora-source --whatrequires python-pytest-flake8
> > > > >
> > > > > Always use the actual binary package name for queries like this, as
> > > > > only the
> > > > > actual package name will show all dependencies that happen to require
> > > > > a
> > > > > differetn virtual provide:
> > > > >
> > > > > $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> > > > > pytest-flake8
> > > > > cvise-0:2.4.0-3.fc36.src
> > > > > python-cssutils-0:2.6.0-2.fc38.src
> > > > > python-nashpy-0:0.0.37-1.fc39.src
> > > > > python-pyunicorn-0:0.6.1-12.fc38.src
> > > > >
> > > > >
> > > > nashpy is fixed, but I'll take a look at the others. Given the disttags
> > > > they look like they FTBFSed anyway (cvise is fc36, ouch!)
> > >
> > > I can take care of pyunicorn. It looks simple enough.
> >
> > Consider pyunicorn fixed. The package itself is still broken, but that's
> > numpy related not due to the removal of pytest-flake8.
> >
> Thank you!
>
> I'll check cvise and cssutils.
>
cvise has an open PR that fixes it (and get it to build again):
https://src.fedoraproject.org/rpms/cvise/pull-request/3
python-cssutils is fixed in
https://src.fedoraproject.org/rpms/python-cssutils/pull-request/2
python-pytest-flake8 is now retired. Thanks for everyone who patched the
dependent packages!
Best,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
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: Retiring python-pytest-flake8
On Fri, Jul 28, 2023 at 12:17:54AM +0200, Sandro wrote:
> On 27-07-2023 22:57, Sandro wrote:
> > On 27-07-2023 21:02, Michel Alexandre Salim wrote:
> > > Thanks Miro!
> > >
> > > On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> > > > On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > > > > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > > > > enablerepo=fedora-source --whatrequires python-pytest-flake8
> > > >
> > > > Always use the actual binary package name for queries like this, as
> > > > only the
> > > > actual package name will show all dependencies that happen to require
> > > > a
> > > > differetn virtual provide:
> > > >
> > > > $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> > > > pytest-flake8
> > > > cvise-0:2.4.0-3.fc36.src
> > > > python-cssutils-0:2.6.0-2.fc38.src
> > > > python-nashpy-0:0.0.37-1.fc39.src
> > > > python-pyunicorn-0:0.6.1-12.fc38.src
> > > >
> > > >
> > > nashpy is fixed, but I'll take a look at the others. Given the disttags
> > > they look like they FTBFSed anyway (cvise is fc36, ouch!)
> >
> > I can take care of pyunicorn. It looks simple enough.
>
> Consider pyunicorn fixed. The package itself is still broken, but that's
> numpy related not due to the removal of pytest-flake8.
>
Thank you!
I'll check cvise and cssutils.
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: PGP signature
___
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
Re: Retiring python-pytest-flake8
On Fri, Jul 28, 2023 at 12:17:54AM +0200, Sandro wrote:
> On 27-07-2023 22:57, Sandro wrote:
> > On 27-07-2023 21:02, Michel Alexandre Salim wrote:
> > > Thanks Miro!
> > >
> > > On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> > > > On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > > > > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > > > > enablerepo=fedora-source --whatrequires python-pytest-flake8
> > > >
> > > > Always use the actual binary package name for queries like this, as
> > > > only the
> > > > actual package name will show all dependencies that happen to require
> > > > a
> > > > differetn virtual provide:
> > > >
> > > > $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> > > > pytest-flake8
> > > > cvise-0:2.4.0-3.fc36.src
> > > > python-cssutils-0:2.6.0-2.fc38.src
> > > > python-nashpy-0:0.0.37-1.fc39.src
> > > > python-pyunicorn-0:0.6.1-12.fc38.src
> > > >
> > > >
> > > nashpy is fixed, but I'll take a look at the others. Given the disttags
> > > they look like they FTBFSed anyway (cvise is fc36, ouch!)
> >
> > I can take care of pyunicorn. It looks simple enough.
>
> Consider pyunicorn fixed. The package itself is still broken, but that's
> numpy related not due to the removal of pytest-flake8.
>
Thank you!
I'll check cvise and cssutils.
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
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: Retiring python-pytest-flake8
Thanks Miro!
On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > enablerepo=fedora-source --whatrequires python-pytest-flake8
>
> Always use the actual binary package name for queries like this, as
> only the
> actual package name will show all dependencies that happen to require
> a
> differetn virtual provide:
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> pytest-flake8
> cvise-0:2.4.0-3.fc36.src
> python-cssutils-0:2.6.0-2.fc38.src
> python-nashpy-0:0.0.37-1.fc39.src
> python-pyunicorn-0:0.6.1-12.fc38.src
>
>
nashpy is fixed, but I'll take a look at the others. Given the disttags
they look like they FTBFSed anyway (cvise is fc36, ouch!)
I won't retire pytest-flake8 until after checking the dependents, just
in case we still need to hotfix it (though my preference will be to
drop it as it should never have been run)
Best,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: This is a digitally signed message part
___
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
Re: Retiring python-pytest-flake8
Thanks Miro!
On Thu, 2023-07-27 at 19:28 +0200, Miro Hrončok wrote:
> On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
> > ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --
> > enablerepo=fedora-source --whatrequires python-pytest-flake8
>
> Always use the actual binary package name for queries like this, as
> only the
> actual package name will show all dependencies that happen to require
> a
> differetn virtual provide:
>
> $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-
> pytest-flake8
> cvise-0:2.4.0-3.fc36.src
> python-cssutils-0:2.6.0-2.fc38.src
> python-nashpy-0:0.0.37-1.fc39.src
> python-pyunicorn-0:0.6.1-12.fc38.src
>
>
nashpy is fixed, but I'll take a look at the others. Given the disttags
they look like they FTBFSed anyway (cvise is fc36, ouch!)
I won't retire pytest-flake8 until after checking the dependents, just
in case we still need to hotfix it (though my preference will be to
drop it as it should never have been run)
Best,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
signature.asc
Description: This is a digitally signed message part
___
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
Retiring python-pytest-flake8
Dear all, We are retiring python-pytest-flake8. It FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2226304 and abandoned upstream: https://github.com/tholo/pytest-flake8/issues/98 (some suggest using ruff instead) and in addition, running linters in %check is discouraged anyway: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters I did a dependency analysis a couple of days ago and only python-nashpy popped up, this was a leftover because of manually specified test dependencies since fixed in https://src.fedoraproject.org/rpms/python-nashpy/pull-request/2 And there are no more dependents. If I miss anything in this query -- your package is FTBFS already anyway after the mass rebuild, so please remove the dependency. ``` michel in fedora/reviews/other took 13m39s ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --enablerepo=fedora-source --whatrequires python-pytest-flake8 Fedora rawhide - x86_64 19 MB/s | 73 MB 00:03 Fedora rawhide - Source 7.2 MB/s | 8.1 MB 00:01 Fedora rawhide - x86_64 - Updates 1.2 MB/s | 1.7 MB 00:01 Last metadata expiration check: 0:00:01 ago on Thu Jul 27 11:21:52 2023. michel in fedora/reviews/other took 37s ⬢ [fedora-toolbox:38] ❯ ``` Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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
Retiring python-pytest-flake8
Dear all, We are retiring python-pytest-flake8. It FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=2226304 and abandoned upstream: https://github.com/tholo/pytest-flake8/issues/98 (some suggest using ruff instead) and in addition, running linters in %check is discouraged anyway: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters I did a dependency analysis a couple of days ago and only python-nashpy popped up, this was a leftover because of manually specified test dependencies since fixed in https://src.fedoraproject.org/rpms/python-nashpy/pull-request/2 And there are no more dependents. If I miss anything in this query -- your package is FTBFS already anyway after the mass rebuild, so please remove the dependency. ``` michel in fedora/reviews/other took 13m39s ⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide --enablerepo=fedora-source --whatrequires python-pytest-flake8 Fedora rawhide - x86_64 19 MB/s | 73 MB 00:03 Fedora rawhide - Source 7.2 MB/s | 8.1 MB 00:01 Fedora rawhide - x86_64 - Updates 1.2 MB/s | 1.7 MB 00:01 Last metadata expiration check: 0:00:01 ago on Thu Jul 27 11:21:52 2023. michel in fedora/reviews/other took 37s ⬢ [fedora-toolbox:38] ❯ ``` Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: fedora-review workarounds for dnf5
On Wed, Jul 26, 2023 at 05:36:04PM +0200, Jakub Kadlcik wrote: > Hello Sandro, > > > I noticed that in f39 builds in Copr the directory containing the > > results is now named after the package. Comparing that to the > > "traditional" fedora-review directory in f38 builds, I miss the > > `licensecheck.txt` file. > > It suddenly started happening and I don't know what is to blame yet. > You can follow > > https://github.com/FrostyX/fedora-review-service/issues/28 > https://pagure.io/FedoraReview/issue/486 > > I plan to work on it as soon as I can. > > Jakub > Thanks for your work on this Jakub! I'll cut another release once this is done. Will try to work on modernizing the build system more, but I'll probably not get to it for a couple of weeks - need to deal with my Rawhide FTBFSes first. Cheers, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: fedora-review workarounds for dnf5
On Mon, Jul 24, 2023 at 09:47:32PM -0500, Michel Alexandre Salim wrote:
> Hi all,
>
> On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote:
> > Like many of you, I have been quite inconvenienced because of
> > dnf5-related breakage of fedora-review. I've been monkeying with it
> > today and finally got a successful run of fedora-review after making
> > the following changes [*].
> >
> I'm happy (and relieved) to say that a fixed fedora-review is ready for
> testing:
>
> https://bodhi.fedoraproject.org/updates/?search==fedora-review=pending=testing
>
fedora-review-0.10.0-1.fc3{7,8} had shebang issues, for those who are
testing please retest fedora-review-0.10.0-2.fc3{7,8} that I just posted
to fix this, thanks!
Turns out we never touched the shebangs and they still had Python
2-isms, and %{py3_shebang_fix} just adds a duplicate -sP which is not
needed -- it's the -tt that was the issue.
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
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: fedora-review workarounds for dnf5
Hi all, On Mon, Jul 17, 2023 at 10:54:43AM -0600, Jerry James wrote: > Like many of you, I have been quite inconvenienced because of > dnf5-related breakage of fedora-review. I've been monkeying with it > today and finally got a successful run of fedora-review after making > the following changes [*]. > I'm happy (and relieved) to say that a fixed fedora-review is ready for testing: https://bodhi.fedoraproject.org/updates/?search==fedora-review=pending=testing This uses Jakub Kadlcik's initial PR to use dnf-3 instead of dnf, so we don't necessarily commit ourselves to using DNF 5 until the we know for sure if Fedora 39 will ship with DNF 5 or not. Thanks also to Benjamin A. Beasley, Miro Hrončok, Benson Muite, Jitka Plesnikova, Pavel Raiskup, and Sérgio M. Basto for contributing changes shipped in this release. 0.10.0 was supposed to have gone out 3 months ago, but blocked by changes in setuptools/distutils causing our release script to generate an incomplete tarball. I've done a more thorough fix that will hopefully hold until we rewrite our build process be PEP 517 compliant for the next release. Once this lands in F38, Fedora Review Service should be fixed, unless I'm missing something. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Orphaned packages looking for new maintainers
On Wed, Jul 19, 2023 at 01:08:32AM +0200, Alexander Ploumistos wrote: > Hello, > > On Mon, Jul 17, 2023 at 8:49 PM Miro Hrončok wrote: > > > > switcheroo-controlorphan 2 weeks > > ago > > Has anyone from the Workstation WG noticed this? Won't losing > switcheroo-control be a considerable usability regression? At the same > time, the upstream developer is/was Bastien, which complicates things. I've flagged it to the desktop@ list after claiming the package, and yeah, they are now aware and @gnome-sig has been added to the ACL. Cheers, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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
Need eyes on Django 4.2.3 PR
Dear all, I just put up a PR to update Django in Rawhide to 4.2.3: https://src.fedoraproject.org/rpms/python-django/pull-request/33 Also - Fedora 37 and 38 are on Django 4.0.x, which is no longer supported - should we just update them to 4.2.x as well? Any version before 4.1.10 and 4.2.3 are affected by this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2219383 https://nvd.nist.gov/vuln/detail/CVE-2023-36053 NIST NVD gave it a base score of 7.5; and once we switch series anyway, maybe we might as well jump to 4.2 which is an LTS, while 4.1 reaches end of extended support in Dec 2023 (when Fedora 38 will still be supported) https://www.djangoproject.com/download/ To update to 4.2, asgiref needs to be updated as well, but that seems to be the only dependency that is too old. If we decide against bumping Django on stable releases, we can see if the CVE fix can be easily backported to 4.0 or not. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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
Need eyes on Django 4.2.3 PR
Dear all, I just put up a PR to update Django in Rawhide to 4.2.3: https://src.fedoraproject.org/rpms/python-django/pull-request/33 Also - Fedora 37 and 38 are on Django 4.0.x, which is no longer supported - should we just update them to 4.2.x as well? Any version before 4.1.10 and 4.2.3 are affected by this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2219383 https://nvd.nist.gov/vuln/detail/CVE-2023-36053 NIST NVD gave it a base score of 7.5; and once we switch series anyway, maybe we might as well jump to 4.2 which is an LTS, while 4.1 reaches end of extended support in Dec 2023 (when Fedora 38 will still be supported) https://www.djangoproject.com/download/ To update to 4.2, asgiref needs to be updated as well, but that seems to be the only dependency that is too old. If we decide against bumping Django on stable releases, we can see if the CVE fix can be easily backported to 4.0 or not. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Orphaned packages looking for new maintainers
On Mon, Jul 17, 2023 at 08:48:56PM +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > iio-sensor-proxy orphan 2 weeks ago > malcontentorphan 2 weeks ago Taking these two. Note: these as well as switcheroo-control are dependencies of key GNOME packages (iio-sensor-proxy is also needed by Cinnamon). So - any comaintainer from @gnome-sig and the Cinnamon SIG very welcome, just let me know see: https://packager-dashboard.fedoraproject.org/dashboard?groups=gnome-sig Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Orphaned packages looking for new maintainers
On Mon, Jul 17, 2023 at 08:48:56PM +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > switcheroo-controlorphan 2 weeks ago I've taken this, since it looks like gnome-shell and budgie-desktop both depend on it. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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] [sali...@fedoraproject.org: Heads up: I'll be retiring python-django3 in Rawhide / django3 landing soon in EPEL 9]
Forgot to cc: epel-devel - but django3 will be available after the next compose tonight! Best regards, Michel - Forwarded message from Michel Alexandre Salim - Date: Wed, 19 Jul 2023 14:01:22 -0500 From: Michel Alexandre Salim To: Development discussions related to Fedora Subject: Heads up: I'll be retiring python-django3 in Rawhide / django3 landing soon in EPEL 9 Dear all, I've been maintaining python-django3 across EPEL8 to Rawhide as part of the effort to upgrade our mailing list infrastructure. Good news: everything is now ready to get this in EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2033064 Bad news: some additional tests are beginning to fail in Fedora (even just rebuilding the last successful build) Since the extended support for the 3.2 LTS series is ending next April: https://www.djangoproject.com/download/ it seems to not be worthwhile to continue fixing. Unless there's no objection, here's the plan: - release the latest python-django3 for: - EPEL 9 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e403913f49 - EPEL 8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a2b17fec79 - evaluate the new test failures in Fedora and if they are not critical, disable them - retire python-django3 in Rawhide this week - fork python-django4.2 from python-django and get missing dependencies branched for EPEL 9 Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 ___ devel mailing list -- de...@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/de...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue - End forwarded message - -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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
Heads up: I'll be retiring python-django3 in Rawhide / django3 landing soon in EPEL 9
Dear all, I've been maintaining python-django3 across EPEL8 to Rawhide as part of the effort to upgrade our mailing list infrastructure. Good news: everything is now ready to get this in EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2033064 Bad news: some additional tests are beginning to fail in Fedora (even just rebuilding the last successful build) Since the extended support for the 3.2 LTS series is ending next April: https://www.djangoproject.com/download/ it seems to not be worthwhile to continue fixing. Unless there's no objection, here's the plan: - release the latest python-django3 for: - EPEL 9 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e403913f49 - EPEL 8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a2b17fec79 - evaluate the new test failures in Fedora and if they are not critical, disable them - retire python-django3 in Rawhide this week - fork python-django4.2 from python-django and get missing dependencies branched for EPEL 9 Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Announcing fmt library soversion bump
On Fri, Jun 30, 2023 at 07:42:39AM +0200, Vitaly Zaitsev via devel wrote: > The side tag has been merged: > https://bodhi.fedoraproject.org/updates/FEDORA-2023-4e8e736635 > > FTBFS (final): > > arbor (not related to fmt, some tests failed on s390x) > CuraEngine > bout++ > cachelib > dolphin-emu > folly > mangohud (not related to fmt) > wasmedge > watchman > Going to fix folly, cachelib and watchman Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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
[Poll] For Rubberband users and downstream maintainers, do you want the 3.2.x release pushed to stable branches?
From Rubberband's NEWS page: https://www.breakfastquay.com/news.html > Version 3.2.0 contains significant improvements to output quality for certain > processing modes. Most notably, it updates the "centre-focus" mode for the R3 > engine (OptionChannelsTogether) so as to retain mono compatibility in the > resulting stereo output and to produce more coherent imaging in many > situations. There are also small fixes to latency calculation in some modes. > Version 3.2.0 may be downloaded from the main Rubber Band Library page. > > Meanwhile version 3.1.3 is a pure bugfix release whose output is otherwise > unchanged from 3.1.2. It is a recommended update for applications where > changes to audio output are undesirable, or at least without substantial > review. Version 3.1.3 may be downloaded from the download index page. The API is unchanged, and I’ve just updated Rawhide to 3.2.1 (a bugfix release for 3.2.x), but I’m going to wait a week to see if there is any objection to updating the stable branches given the changes. In the spirit of trying out Discourse, I've also posted it there with an actual poll: https://discussion.fedoraproject.org/t/poll-for-rubberband-users-and-downstream-maintainers-do-you-want-the-3-2-x-release-pushed-to-stable-branches/82344 Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: colm update breaking ragel
On Tue, Apr 25, 2023 at 08:50:42PM -0500, Michel Alexandre Salim wrote: > Update: it's .. looking more complicated than I anticipated: > > The new ragel can in theory be built against the updated colm, *but* > it expect colm to provide some *.la files (libtool archives), which... > our packaging guidelines require to be stripped out, and colm-devel > rightly does not ship. > > I'm adding this info to the FTI bug that got auto-filed against ragel: > https://bugzilla.redhat.com/show_bug.cgi?id=2189702 > Fixed now with https://koji.fedoraproject.org/koji/taskinfo?taskID=100913236 - colm-0.14.7-2.fc39 with a backported commit to make libfsm discoverable - ragel-7.0.4-1.fc39 with a backported commit to fallback to finding *.so Thanks to Mamoru Tasaka for identifying the ragel commits. Best regards, Michel > On Tue, Apr 25, 2023 at 07:10:12PM -0300, Filipe Rosset wrote: > > thanks, next time I'll coordinate with the ragel update. > > > > On Tue, Apr 25, 2023 at 6:45 PM Michel Alexandre Salim < > > sali...@fedoraproject.org> wrote: > > > > > Hi, > > > > > > I noticed when rebuilding mcrouter that it failed because ragel is not > > > installable, because colm was updated: > > > > > > DEBUG util.py:443: Error: > > > DEBUG util.py:443: Problem: conflicting requests > > > DEBUG util.py:443:- nothing provides libcolm-0.13.0.7.so()(64bit) > > > needed by ragel-7.0.0.12-9.fc38.x86_64 > > > > > > Looks like the latest version of ragel (7.0.4) expects the new colm > > > version, so I'll build it and resolve the breakage - only for Rawhide > > > (both colm and ragel > > > are maintained by the same upstream). > > > > > > CC:ing the colm and ragel maintainers so they can coordinate any update > > > for other branches. > > > > > > -- > > > Michel Alexandre Salim > > > identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > > > > > > ___ > > 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 > > > -- > Michel Alexandre Salim > identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > ___ > 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 -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: colm update breaking ragel
Update: it's .. looking more complicated than I anticipated: The new ragel can in theory be built against the updated colm, *but* it expect colm to provide some *.la files (libtool archives), which... our packaging guidelines require to be stripped out, and colm-devel rightly does not ship. I'm adding this info to the FTI bug that got auto-filed against ragel: https://bugzilla.redhat.com/show_bug.cgi?id=2189702 On Tue, Apr 25, 2023 at 07:10:12PM -0300, Filipe Rosset wrote: > thanks, next time I'll coordinate with the ragel update. > > On Tue, Apr 25, 2023 at 6:45 PM Michel Alexandre Salim < > sali...@fedoraproject.org> wrote: > > > Hi, > > > > I noticed when rebuilding mcrouter that it failed because ragel is not > > installable, because colm was updated: > > > > DEBUG util.py:443: Error: > > DEBUG util.py:443: Problem: conflicting requests > > DEBUG util.py:443:- nothing provides libcolm-0.13.0.7.so()(64bit) > > needed by ragel-7.0.0.12-9.fc38.x86_64 > > > > Looks like the latest version of ragel (7.0.4) expects the new colm > > version, so I'll build it and resolve the breakage - only for Rawhide > > (both colm and ragel > > are maintained by the same upstream). > > > > CC:ing the colm and ragel maintainers so they can coordinate any update > > for other branches. > > > > -- > > Michel Alexandre Salim > > identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > > > ___ > 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 -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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
colm update breaking ragel
Hi, I noticed when rebuilding mcrouter that it failed because ragel is not installable, because colm was updated: DEBUG util.py:443: Error: DEBUG util.py:443: Problem: conflicting requests DEBUG util.py:443:- nothing provides libcolm-0.13.0.7.so()(64bit) needed by ragel-7.0.0.12-9.fc38.x86_64 Looks like the latest version of ragel (7.0.4) expects the new colm version, so I'll build it and resolve the breakage - only for Rawhide (both colm and ragel are maintained by the same upstream). CC:ing the colm and ragel maintainers so they can coordinate any update for other branches. -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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] Re: Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)
On Wed, Feb 08, 2023 at 02:31:39PM -0800, Troy Dawson wrote: > > > > > > > > > > > > If I am reading this correctly, the only package affected would be > > > > drgn (from python-drgn). > > > > It should hopefully just need a rebuild. > > > > Is that correct? > > > > Were you planning on rebuilding python-drgn, or contacting the > > > > package maintainer and having them do it? > > > > > > > > > > He's a co-maintainer of python-drgn, so I assume he's going to > > > rebuild it himself. > > > > > Correct to both. Only drgn is affected, and Davide and I maintain it so > > we'll get it rebuilt as a set. > > > > Thanks, > > > > Sounds good. > Thank you for announcing it and following the steps. Per the discussion in the EPEL meeting today, this is good to go ahead; I have done the builds and put up Bodhi updates: https://bodhi.fedoraproject.org/updates/?search=0.5.1=libkdumpfile=EPEL-9=EPEL-8 Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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: fedrq - new repoquerying tool
Ah, in that case I think my best course of action is see if I can use fedrq as a library and possibly extend it to be able to override dnf options (like where repos are). Would such PRs be acceptable? Thanks, Michel ___ 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: Adding liboqs to Rawhide
On Mon, Feb 13, 2023 at 12:44:03PM +0100, Dmitry Belyavskiy wrote: > Dear colleagues, > > I'm currently working on bringing liboqs [1] to rawhide. > > According to [2], I've added the following line to the spec file: > > License: MIT and Apache 2.0 and BSD 3-Clause and CC0-1.0 and Unlicense > > I doubt about 2 licenses that are enumerated: [3] (BSD-like) and [4]. > What am I to do with them? They look quite permissive but I need > someone's evaluation. > > [1] https://github.com/open-quantum-safe/liboqs/ > [2] https://github.com/open-quantum-safe/liboqs/blob/main/README.md#license > [3] https://www.openssl.org/~appro/cryptogams/ > [4] > https://github.com/open-quantum-safe/liboqs/blob/40b01fdbb270f8614fde30e65d30e9da18c02393/src/common/rand/rand_nist.c#L1-L15 > > What is the proper line for the spec file and what are my next steps > to evaluate the licenses, if necessary? > [3] seems to be (BSD-3-Clause OR GPL) but unfortunately it does not specify which GPL to use, and the files don't actually carry copyright notices ... https://spdx.org/licenses/BSD-3-Clause.html You probably want to ask for review? https://docs.fedoraproject.org/en-US/legal/license-review-process/ Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: fedrq - new repoquerying tool
The subpackages command looks interesting, and potentially something I can use in ebranch! Can you use rpmdistro-repoquery's repo definitions? That would allow dropping the embedded repo configs Cheers, Michel ___ 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: Heads-up: OpenSSL update
On Fri, 2023-02-10 at 12:05 -0600, Michel Alexandre Salim wrote: > Dear Dmitry, > > On Fri, 2023-02-10 at 09:55 +0100, Dmitry Belyavskiy wrote: > > Dear Michel, > > > > In RHEL/CentOS we currently provide a double versioning for > > OPENSSL_strcasecmp and OPENSSL_strncasecmp functions. > > They were added in 3.0.1 downstream and 3.0.3 upstream. > > > > 0056-strcasecmp.patch in CentOS stream fixes the test in question. > > > Ah, interesting. I took a look at the history of that patch, and > narrowed down the issue: > > - with f2a49ef424f831aac988356fc8b2b910e443dc42 from Nov 25, > rebuilding > in EPEL 8 fails: > - > https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/f2a49ef424f831aac988356fc8b2b910e443dc42 > https://koji.fedoraproject.org/koji/taskinfo?taskID=97348528 > > - with that patch backed out, building 3.0.7-2 succeeds: > https://koji.fedoraproject.org/koji/taskinfo?taskID=97348707 > > Note that these are the exact openssl package from c9s, just rebuilt > with the g++ dependency replaced by gcc-c++. > > I suppose the easiest resolution here is for me to build openssl3 > (for > EPEL 8) with that commit backed out, but I'm a bit puzzled as to why > this happens. Any idea there? > I initially thought it's the addition of the linker option --allow- multiple-definition shows up in Alma 8's `ld --help`, so ... it's not that. Stumped, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Heads-up: OpenSSL update
Dear Dmitry, On Fri, 2023-02-10 at 09:55 +0100, Dmitry Belyavskiy wrote: > Dear Michel, > > In RHEL/CentOS we currently provide a double versioning for > OPENSSL_strcasecmp and OPENSSL_strncasecmp functions. > They were added in 3.0.1 downstream and 3.0.3 upstream. > > 0056-strcasecmp.patch in CentOS stream fixes the test in question. > Ah, interesting. I took a look at the history of that patch, and narrowed down the issue: - with f2a49ef424f831aac988356fc8b2b910e443dc42 from Nov 25, rebuilding in EPEL 8 fails: - https://gitlab.com/redhat/centos-stream/rpms/openssl/-/commit/f2a49ef424f831aac988356fc8b2b910e443dc42 https://koji.fedoraproject.org/koji/taskinfo?taskID=97348528 - with that patch backed out, building 3.0.7-2 succeeds: https://koji.fedoraproject.org/koji/taskinfo?taskID=97348707 Note that these are the exact openssl package from c9s, just rebuilt with the g++ dependency replaced by gcc-c++. I suppose the easiest resolution here is for me to build openssl3 (for EPEL 8) with that commit backed out, but I'm a bit puzzled as to why this happens. Any idea there? Thanks, Michel > On Thu, Feb 9, 2023 at 9:47 PM Michel Alexandre Salim > wrote: > > > > Hi Dmitry, > > > > On Thu, 2023-02-09 at 18:02 +0100, Dmitry Belyavskiy wrote: > > > Dear colleagues, > > > > > > I've just pushed updates of OpenSSL to the 3.0.8 version to > > > f36/37. > > > I will also push to f38 and rawhide later today. > > > > > > This is a security release, it fixes 8 MODERATE CVEs > > > (https://www.openssl.org/news/secadv/20230207.txt) > > > > > > I kindly ask you to test the version so it could be rolled up > > > earlier. > > > > > Would you happen to have any insight into why some tests are > > failing > > when rebuilt on EPEL 8? > > > > This is with a scratch build of EPEL 8's openssl3 (which is just a > > rebuild of openssl but renamed and with some subpackages removed) > > https://koji.fedoraproject.org/koji/taskinfo?taskID=97314920 > > > > The errors are all identical, so to be doubly sure I rebuilt the > > centos > > 9 srpm (only on x86_64), just slightly modified to change the g++ > > BR to > > gcc-c++, and it failed identically > > https://koji.fedoraproject.org/koji/taskinfo?taskID=97318473 > > > > # The following symbols are missing in libcrypto.so.3: > > # OPENSSL_strcasecmp > > # OPENSSL_strncasecmp > > # The following symbols are extra in libcrypto.so.3: > > # BIO_dgram_is_sctp > > # BIO_dgram_sctp_msg_waiting > > # BIO_dgram_sctp_notification_cb > > # BIO_dgram_sctp_wait_for_dry > > # BIO_new_dgram_sctp > > # BIO_s_datagram_sctp > > not ok 2 - check that there are no missing symbols in > > libcrypto.so.3 > > # - > > > > -03-test_internal_modes.t ... ok > > 03-test_internal_namemap.t . ok > > 03-test_internal_curve448.t ok > > 03-test_internal_poly1305.t ok > > # Looks like you failed 1 test of 4.01-test_symbol_presence.t > > .. > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/4 subtests > > 02-test_lhash.t ... > > > > Thanks, > > > > -- > > Michel Alexandre Salim > > identities: > > https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 > > ___ > > 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 > > > > -- > Dmitry Belyavskiy > _______ > 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 -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3
Re: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases
On Wed, 2023-02-08 at 22:24 -0500, Demi Marie Obenour wrote: > On 2/7/23 07:52, Peter Robinson wrote: > > On Tue, Feb 7, 2023 at 12:36 PM Lokesh Mandvekar > > wrote: > > > > > > On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson > > > wrote: > > > > > > > There are still active users of Fedora IoT 36 on armhfp using > > > > containers so I suspect they may be unhappy of they go away > > > > before the > > > > F-36 EOL in the late May/early June timeframe. > > > > > > I see. I guess we could leave armhfp be until then. Btw, just > > > curious > > > what happens to IoT on armhfp once f36 goes EOL. > > > Would users have to pick something else? > > > > Basically yes. > > Not sure if Debian supports armhfp, but in the long term the answer > is > going to be to find a distro that cross-compiles everything. > But of course: https://wiki.debian.org/SupportedArchitectures It also supports mips (both 32- and 64-bit) because... Cheers, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Heads-up: OpenSSL update
Hi Dmitry, On Thu, 2023-02-09 at 18:02 +0100, Dmitry Belyavskiy wrote: > Dear colleagues, > > I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. > I will also push to f38 and rawhide later today. > > This is a security release, it fixes 8 MODERATE CVEs > (https://www.openssl.org/news/secadv/20230207.txt) > > I kindly ask you to test the version so it could be rolled up > earlier. > Would you happen to have any insight into why some tests are failing when rebuilt on EPEL 8? This is with a scratch build of EPEL 8's openssl3 (which is just a rebuild of openssl but renamed and with some subpackages removed) https://koji.fedoraproject.org/koji/taskinfo?taskID=97314920 The errors are all identical, so to be doubly sure I rebuilt the centos 9 srpm (only on x86_64), just slightly modified to change the g++ BR to gcc-c++, and it failed identically https://koji.fedoraproject.org/koji/taskinfo?taskID=97318473 # The following symbols are missing in libcrypto.so.3: # OPENSSL_strcasecmp # OPENSSL_strncasecmp # The following symbols are extra in libcrypto.so.3: # BIO_dgram_is_sctp # BIO_dgram_sctp_msg_waiting # BIO_dgram_sctp_notification_cb # BIO_dgram_sctp_wait_for_dry # BIO_new_dgram_sctp # BIO_s_datagram_sctp not ok 2 - check that there are no missing symbols in libcrypto.so.3 # - -03-test_internal_modes.t ... ok 03-test_internal_namemap.t . ok 03-test_internal_curve448.t ok 03-test_internal_poly1305.t ok # Looks like you failed 1 test of 4.01-test_symbol_presence.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests 02-test_lhash.t ... Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Should python-mysql be retired in Fedora and EPEL?
cc-ing the epel-devel list too On Thu, 2023-02-09 at 14:39 -0600, Michel Alexandre Salim wrote: > Dear fellow Fedorans, > > It seems that python-mysqlclient will now transparently upgrade > python- > mysql since 2.1.1-2 (for Fedora): > https://src.fedoraproject.org/rpms/python-mysqlclient/c/1da9400c1c9c8eb8b044f6976e1a07f06226ed3e?branch=rawhide > and 1.4.6-6 (EPEL 8) > https://src.fedoraproject.org/rpms/python-mysqlclient/c/cc24faae44f40898ba87e93f9dfefbc9a7fb09e1?branch=epel8 > > (python-mysql was never in EPEL9) > > The two upstreams are the same (python-mysql points to > https://github.com/PyMySQL/mysqlclient-python but that just redirects > to https://github.com/PyMySQL/mysqlclient) > > However it seems that python-mysql itself is not retired -- should > it? > Seems like there's no release in which trying to install it won't > just > install python-mysqlclient instead anyway. > > The maintainers don't seem to overlap: > - python-mysql maintained by mschorm and hobbes1069 > - python-mysqlclient maintained by fab > > (the changes to make mysqlclient obsolete mysql are made by non- > maintainers) > > Best regards, > > ___ > devel mailing list -- de...@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/de...@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Should python-mysql be retired in Fedora and EPEL?
cc-ing the epel-devel list too On Thu, 2023-02-09 at 14:39 -0600, Michel Alexandre Salim wrote: > Dear fellow Fedorans, > > It seems that python-mysqlclient will now transparently upgrade > python- > mysql since 2.1.1-2 (for Fedora): > https://src.fedoraproject.org/rpms/python-mysqlclient/c/1da9400c1c9c8eb8b044f6976e1a07f06226ed3e?branch=rawhide > and 1.4.6-6 (EPEL 8) > https://src.fedoraproject.org/rpms/python-mysqlclient/c/cc24faae44f40898ba87e93f9dfefbc9a7fb09e1?branch=epel8 > > (python-mysql was never in EPEL9) > > The two upstreams are the same (python-mysql points to > https://github.com/PyMySQL/mysqlclient-python but that just redirects > to https://github.com/PyMySQL/mysqlclient) > > However it seems that python-mysql itself is not retired -- should > it? > Seems like there's no release in which trying to install it won't > just > install python-mysqlclient instead anyway. > > The maintainers don't seem to overlap: > - python-mysql maintained by mschorm and hobbes1069 > - python-mysqlclient maintained by fab > > (the changes to make mysqlclient obsolete mysql are made by non- > maintainers) > > Best regards, > > ___ > 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 -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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
Should python-mysql be retired in Fedora and EPEL?
Dear fellow Fedorans, It seems that python-mysqlclient will now transparently upgrade python- mysql since 2.1.1-2 (for Fedora): https://src.fedoraproject.org/rpms/python-mysqlclient/c/1da9400c1c9c8eb8b044f6976e1a07f06226ed3e?branch=rawhide and 1.4.6-6 (EPEL 8) https://src.fedoraproject.org/rpms/python-mysqlclient/c/cc24faae44f40898ba87e93f9dfefbc9a7fb09e1?branch=epel8 (python-mysql was never in EPEL9) The two upstreams are the same (python-mysql points to https://github.com/PyMySQL/mysqlclient-python but that just redirects to https://github.com/PyMySQL/mysqlclient) However it seems that python-mysql itself is not retired -- should it? Seems like there's no release in which trying to install it won't just install python-mysqlclient instead anyway. The maintainers don't seem to overlap: - python-mysql maintained by mschorm and hobbes1069 - python-mysqlclient maintained by fab (the changes to make mysqlclient obsolete mysql are made by non- maintainers) Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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
Heads up: lua-posix 36.1 headed to Rawhide
Dear all, Now that F38 is branched, it's probably a good time to upgrade lua- posix from 35.1 to 36.1. Packages potentially affected: ❯ rpmdistro-repoquery fedora rawhide --whatrequires lua-posix Last metadata expiration check: 0:02:18 ago on Thu Feb 9 13:15:29 2023. Lmod-0:8.7.18-1.fc38.x86_64 copy-jdk-configs-0:4.1-2.fc38.noarch lua-readline-0:3.2-2.fc38.x86_64 There are some breaking changes in 36.0, so I'm going to only update in Rawhide and we can revisit if we need to update in 38 and stable branches later, but I tend towards keeping them at 35.1 unless there's a major issue we can't fix without upgrading. https://github.com/luaposix/luaposix/releases Incompatible Changes posix.spawn always returns integer, string whether fork fails immediately, or whatever waiting for the spawned process reports. When the second result value is "exited", the first is the exit status; for "killed" or "stopped" second value, the first is the signal number that caused it; otherwise first the errno error number, followed by the associated error string. The documentation for posix.spawn has always been wrong up until now, but this small change to simplify the returned results will require checking whether the second result value is "exited", "killed", "stopped" or any other string before interpreting the first result... which was also necessary in prior versions too, but now the interpretion of non-zero status by clients is less messy and somewhat compatible with the happy path of using previous releases. Argument type errors for posix.sys.msg.msgctl, posix.sys.resource.setrlimit, posix.sys.socket.bind, posix.sys.socket.connect, posix.sys.socket.getaddrinfo, posix.sys.socket.sendto and posix.time.nanosleep all use "integer" in full rather than "int". Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Heads-up: OpenSSL update
Hi Dmitry, On Thu, 2023-02-09 at 18:02 +0100, Dmitry Belyavskiy wrote: > Dear colleagues, > > I've just pushed updates of OpenSSL to the 3.0.8 version to f36/37. > I will also push to f38 and rawhide later today. > > This is a security release, it fixes 8 MODERATE CVEs > (https://www.openssl.org/news/secadv/20230207.txt) > > I kindly ask you to test the version so it could be rolled up > earlier. > Thanks for the heads-up! Will test and rebase the openssl3 package in EPEL8 too. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)
On Wed, 2023-02-08 at 14:09 -0500, Neal Gompa wrote: > On Wed, Feb 8, 2023 at 12:37 PM Troy Dawson > wrote: > > > > On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim > > wrote: > > > > > > Hi all, > > > > > > Per the incompatible upgrade policy[1] I'm proposing upgrading > > > libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9. > > > > > > Bugzilla issues: > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 > > > in > > > general) > > > - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL) > > > > > > Up to 0.4.1, libkdumpfile was packaged without the test suite > > > being > > > run, and when I started work on packaging it in Debian I noticed > > > a lot > > > of test failures on non-x86_64 architectures: > > > https://github.com/ptesarik/libkdumpfile/issues/40 > > > > > > This is now fixed (0.5.0 is the first version to pass tests > > > cleanly > > > without additional patches on Fedora), but prior to its release > > > we were > > > basically building in Fedora from a post-0.4.1 snapshot > > > ( > > > https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af83 > > > 26562a155581d77f04f2ae84197/f/libkdumpfile.spec) > > > that is likely not ABI compatible with the original 0.4.1 anyway, > > > so > > > there's no reasonable way to backport the architecture fixes to > > > 0.4.1. > > > > > > Change in sonames: > > > > > > [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora > > > rawhide -- > > > provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos- > > > stream > > > 9 --provides libkdumpfile 2>/dev/null) > > > libaddrxlat.so.2()(64bit) > > > libaddrxlat.so.2(LIBADDRXLAT_0)(64bit) > > > libaddrxlat.so.3 > > > libaddrxlat.so.3()(64bit) > > > libaddrxlat.so.3(LIBADDRXLAT_0) > > > libaddrxlat.so.3(LIBADDRXLAT_0)(64bit) > > > libkdumpfile = 0.4.1-5.el9 > > > libkdumpfile = 0.5.0-3.fc38 > > > libkdumpfile(x86-32) = 0.5.0-3.fc38 > > > libkdumpfile(x86-64) = 0.4.1-5.el9 > > > libkdumpfile(x86-64) = 0.5.0-3.fc38 > > > libkdumpfile.so.10 > > > libkdumpfile.so.10()(64bit) > > > libkdumpfile.so.10(LIBKDUMPFILE_0) > > > libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit) > > > libkdumpfile.so.9()(64bit) > > > libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit) > > > > > > Only drgn currently depends on libkdumpfile, and I plan to > > > rebuild it > > > in the same updates: > > > > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 -- > > > whatrequires "libaddrxlat.so.2()(64bit)" > > > Last metadata expiration check: 0:12:30 ago on Wed Feb 8 > > > 11:02:35 > > > 2023. > > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64 > > > libkdumpfile-util-0:0.4.1-5.el9.x86_64 > > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64 > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 -- > > > whatrequires "libkdumpfile.so.9()(64bit)" > > > Last metadata expiration check: 0:12:40 ago on Wed Feb 8 > > > 11:02:35 > > > 2023. > > > drgn-0:0.0.22-1.el9.x86_64 > > > libkdumpfile-devel-0:0.4.1-5.el9.x86_64 > > > libkdumpfile-util-0:0.4.1-5.el9.x86_64 > > > python3-libkdumpfile-0:0.4.1-5.el9.x86_64 > > > > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream- > > > legacy 8 -- > > > whatrequires "libaddrxlat.so.2()(64bit)" > > > Last metadata expiration check: 0:00:08 ago on Wed Feb 8 > > > 11:15:35 > > > 2023. > > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64 > > > libkdumpfile-util-0:0.4.1-5.el8.x86_64 > > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64 > > > [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream- > > > legacy 8 -- > > > whatrequires "libkdumpfile.so.9()(64bit)" > > > Last metadata expiration check: 0:00:16 ago on Wed Feb 8 > > > 11:15:35 > > > 2023. > > > drgn-0:0.0.22-1.el8.x86_64 > > > libkdumpfile-devel-0:0.4.1-5.el8.x86_64 > > > libkdumpfile-util-0:0.4.1-5.el8.x86_64 > > > python3-libkdumpfile-0:0.4.1-5.el8.x86_64 > > > > > > [1]: > > > https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades
[EPEL-devel] Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)
Hi all, Per the incompatible upgrade policy[1] I'm proposing upgrading libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9. Bugzilla issues: - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 in general) - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL) Up to 0.4.1, libkdumpfile was packaged without the test suite being run, and when I started work on packaging it in Debian I noticed a lot of test failures on non-x86_64 architectures: https://github.com/ptesarik/libkdumpfile/issues/40 This is now fixed (0.5.0 is the first version to pass tests cleanly without additional patches on Fedora), but prior to its release we were basically building in Fedora from a post-0.4.1 snapshot (https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af8326562a155581d77f04f2ae84197/f/libkdumpfile.spec) that is likely not ABI compatible with the original 0.4.1 anyway, so there's no reasonable way to backport the architecture fixes to 0.4.1. Change in sonames: [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora rawhide -- provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-stream 9 --provides libkdumpfile 2>/dev/null) libaddrxlat.so.2()(64bit) libaddrxlat.so.2(LIBADDRXLAT_0)(64bit) libaddrxlat.so.3 libaddrxlat.so.3()(64bit) libaddrxlat.so.3(LIBADDRXLAT_0) libaddrxlat.so.3(LIBADDRXLAT_0)(64bit) libkdumpfile = 0.4.1-5.el9 libkdumpfile = 0.5.0-3.fc38 libkdumpfile(x86-32) = 0.5.0-3.fc38 libkdumpfile(x86-64) = 0.4.1-5.el9 libkdumpfile(x86-64) = 0.5.0-3.fc38 libkdumpfile.so.10 libkdumpfile.so.10()(64bit) libkdumpfile.so.10(LIBKDUMPFILE_0) libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit) libkdumpfile.so.9()(64bit) libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit) Only drgn currently depends on libkdumpfile, and I plan to rebuild it in the same updates: [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 -- whatrequires "libaddrxlat.so.2()(64bit)" Last metadata expiration check: 0:12:30 ago on Wed Feb 8 11:02:35 2023. libkdumpfile-devel-0:0.4.1-5.el9.x86_64 libkdumpfile-util-0:0.4.1-5.el9.x86_64 python3-libkdumpfile-0:0.4.1-5.el9.x86_64 [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 -- whatrequires "libkdumpfile.so.9()(64bit)" Last metadata expiration check: 0:12:40 ago on Wed Feb 8 11:02:35 2023. drgn-0:0.0.22-1.el9.x86_64 libkdumpfile-devel-0:0.4.1-5.el9.x86_64 libkdumpfile-util-0:0.4.1-5.el9.x86_64 python3-libkdumpfile-0:0.4.1-5.el9.x86_64 [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 -- whatrequires "libaddrxlat.so.2()(64bit)" Last metadata expiration check: 0:00:08 ago on Wed Feb 8 11:15:35 2023. libkdumpfile-devel-0:0.4.1-5.el8.x86_64 libkdumpfile-util-0:0.4.1-5.el8.x86_64 python3-libkdumpfile-0:0.4.1-5.el8.x86_64 [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 -- whatrequires "libkdumpfile.so.9()(64bit)" Last metadata expiration check: 0:00:16 ago on Wed Feb 8 11:15:35 2023. drgn-0:0.0.22-1.el8.x86_64 libkdumpfile-devel-0:0.4.1-5.el8.x86_64 libkdumpfile-util-0:0.4.1-5.el8.x86_64 python3-libkdumpfile-0:0.4.1-5.el8.x86_64 [1]: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Self Introduction: Hussein K.
On Tue, 2022-12-20 at 17:23 +0100, Sandro Mani wrote: > Hi > > I'd like to mentor Hussein (FAS: blinxen) in learning to become a > packager. He is a work colleague of mine. In particular, he's helping > me > getting libimagequant updated, which some time ago was ported to > rust. > As such, I'd like to add him as a co-maintainer of libimagequant and > help him getting the new dependencies reviewed. Is anyone willing to > sponsor Hussein? > Looks like someone already sponsored Hussein, but just one note - do join #rust:fedoraproject.org (or #fedora-rust via irc) and the Rust mailing list, a lot of the packaging work is coordinated there. https://www.fedoraproject.org/wiki/SIGs/Rust Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Self Introduction: Hussein K.
On Tue, 2022-12-20 at 17:23 +0100, Sandro Mani wrote: > Hi > > I'd like to mentor Hussein (FAS: blinxen) in learning to become a > packager. He is a work colleague of mine. In particular, he's helping > me > getting libimagequant updated, which some time ago was ported to > rust. > As such, I'd like to add him as a co-maintainer of libimagequant and > help him getting the new dependencies reviewed. Is anyone willing to > sponsor Hussein? > Welcome, Hussein! I'll sponsor Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Self Introduction: Neil Hanlon
Hi Neil, On Thu, 2023-01-26 at 16:34 -0500, Neil Hanlon wrote: > Hi folks! > > My name is Neil Hanlon and I was recently sponsored into the > packager's group by Michel Salim, adding python-sdnotify > [1] to Fedora and EPEL. sdnotify is a dependency for some other > packages I hope to contribute to Fedora. > > ... > I'm looking forward to getting to know more of the Fedora community, > and am thankful for the warm welcome I've received > so far. I'll also be at CentOS Connect and FOSDEM next week, so if > you're there, it would be great to meet folks in > person :) > I wish I could make CentOS Connect/FOSDEM in person, but anyway, glad to have you here with us! Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Automation of Fedora SCM requests
On Sat, 2023-01-21 at 20:52 +0100, Fabio Valentini wrote: > On Thu, Jan 19, 2023 at 11:18 AM Michal Konecny > wrote: > > > > I would say that the current way is OK, the bot asks fedora-scm- > > requests > > admins to validate the requests, because it is marked as exception. > > After being validated it gets created. > > > > Or if there should be an exception for Rust packages, we can add > > name > > validation and if the name of the package is rust something, we can > > skip > > the validation process. But this unfortunately let people create > > any > > repository with name rust with exception set to true without any > > validation and I'm not sure if we want this. > > I don't think there should be any special-casing of Rust packages. > The > same guidelines for compat packages apply to them as to any other > package, so I don't see why they should be processed differently > (i.e. > without human validation). > One half-way solution might be to allow different operators to approve certain requests -- e.g. if for rust-*[NUM] requests with exceptions, @rust-sig members also get pinged and can approve such requests. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Rawhide updates stuck for the past ~4 hours?
On Fri, 2023-01-20 at 22:44 +0100, Miro Hrončok wrote: > My Rawhide Bodhi updates are stuck in pending, so I've checked > > https://bodhi.fedoraproject.org/updates/?releases=F38 > > and it seems that everything created after 2023-01-20 17:35 UTC is > stuck. > > Is this a natural slowdown due to the mass rebuild or is something > broken? > Per nirik on #releng, looks like robosignatory is backlogged on signing packages. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: Automation of Fedora SCM requests
Hi Michal, On Wed, 2023-01-11 at 17:13 +0100, Michal Konecny wrote: > Hi everyone, > > all the remaining issues were solved and the bot is now processing > tickets as it should. I will watch the SCM request repository for > next few days to see if everything is working as it should. > Thanks for your patience. > Where can I direct feature requests? Per https://pagure.io/releng/fedora-scm-requests/issue/50507 seems like requesting repos with exceptions (e.g. for Rust compat packages) is currently not automated. Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Thu, Jan 12, 2023 at 06:46:17PM -0500, Siddhesh Poyarekar wrote: > On Thu, Jan 12, 2023 at 6:38 PM Jakub Jelinek wrote: > > But at least you don't need both -U_FORTIFY_SOURCE and > > -Wp,-U_FORTIFY_SOURCE, one of them is enough. And the latter I think > > better gets through libtool and other tools; especially if you put it > > into a single -Wp, option together with the redefinition... > > Uhmm, I could have sworn that I had needed -Wp,-U... for the -Wp-D... > and -U for the -D when I was fixing the test builds but you're right, > simply -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 appears to work > for both -D_FORTIFY_SOURCE=2 as well as -Wp,-D_FORTIFY_SOURCE=2. I'll > test this some more and post a PR for redhat-rpm-config. > Thanks, Sid and Jakub, for digging in and identifying the issue! Looking forward to being able to use ccache for my local Rawhide builds again. Glad this will end up making the change less brittle too. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Automation of Fedora SCM requests
Hi Michal and CPE, On Wed, Jan 11, 2023 at 05:13:47PM +0100, Michal Konecny wrote: > Hi everyone, > > all the remaining issues were solved and the bot is now processing tickets > as it should. I will watch the SCM request repository for next few days to > see if everything is working as it should. > Thanks for your patience. > > On behalf of CPE Team, > Michal > Thank you so much! As someone who does a lot of EPEL 9 branch requests, the branch request I did earlier today (the first after the automation landed) was a pleasant surprise. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, 2023-01-11 at 14:29 -0500, Siddhesh Poyarekar wrote: > On Wed, Jan 11, 2023 at 1:15 PM Michel Alexandre Salim > wrote: > > The warning seems to happen only in mock, the Koji build is clean: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=96015653 > > > > Let me paste the root.log and build.log from the local build (I'm > > now > > working on upgrading a second package that uses -Werror, so on that > > the > > FORTIFY_SOURCE issue actually fails the build - will have to > > locally > > test against fedora-37-x86_64 instead of Rawhide for now). > > > > build.log: https://paste.centos.org/view/ea89a51c > > root.log: https://paste.centos.org/view/c25c9b3f > > Can you tell me how you're doing the mock build? With my fedora 37 > laptop a `fedpkg mockbuild` went through just fine for rubberband and > I don't see any of the superfluous annobin messages: > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm` I have these additional knobs in ~/.config/mock.cfg: config_opts['plugin_conf']['ccache_enable'] = True config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G' # False: build from Koji, e.g. to grab packages just put into Rawhide # config_opts['mirrored'] = False HTH, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 01:04:45PM -0500, Siddhesh Poyarekar wrote: > On Wed, Jan 11, 2023 at 12:45 PM Michel Alexandre Salim > wrote: > > Is this supported yet? I'm doing a build of rubberband for Rawhide, and > > every file generates this warning: > > > > ../src/test/TestStretcher.cpp: warning: -D_FORTIFY_SOURCE defined but > > value is too low > > Yes the change is in, it even broke systemd once ;) Could you please > share the full build log? That looks like an annobin warning, which > may suggest an annobin bug but maybe something else is wrong. > The warning seems to happen only in mock, the Koji build is clean: https://koji.fedoraproject.org/koji/taskinfo?taskID=96015653 Let me paste the root.log and build.log from the local build (I'm now working on upgrading a second package that uses -Werror, so on that the FORTIFY_SOURCE issue actually fails the build - will have to locally test against fedora-37-x86_64 instead of Rawhide for now). build.log: https://paste.centos.org/view/ea89a51c root.log: https://paste.centos.org/view/c25c9b3f Thanks for looking! -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Mon, 2022-12-05 at 14:58 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if > approved > by the Fedora Engineering Steering Committee. > > > == Summary == > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to > improve mitigation of security issues arising from buffer overflows > in > packages in Fedora. > Is this supported yet? I'm doing a build of rubberband for Rawhide, and every file generates this warning: ../src/test/TestStretcher.cpp: warning: -D_FORTIFY_SOURCE defined but value is too low Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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: List of long term FTBFS packages to be retired in February
On Wed, Jan 11, 2023 at 01:58:51PM +0100, Miro Hrončok wrote: > Dear maintainers. > > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 38 approximately one week before branching. > > 5 weekly reminders are required, hence the retirement will happen > approximately in 5 weeks, i.e. around 2023-02-08. > Since this is unfortunately after the branching, > packages will be retired on rawhide and f38. > > I apologize for starting this process a bit later than required. > > Policy: > https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/ > > libgnome alexl, caolanm, gnome-sig, > mbarnes, rhughes, rstrode, > ssp, trawets I was initially thinking I should just retire grhino, which has not been updated since 2010 and will be affected by libgnome retirement, but... there's a lot of other packages that will be affected if libgnome is pulled. Is it still worth maintaining? If libgnome should be retired I guess we should proactively retire them now rather than waiting after the mass rebuild then having to untag packages from f38 too. > Depending on: libgnome (32), status change: 2022-11-29 (6 weeks ago) > GtkAda (maintained by: rombobeorn) > GtkAda-2.24.2-40.fc37.src requires libgnome-devel = > 2.32.1-23.fc35 > > alleyoop (maintained by: orphan) > alleyoop-0.9.8-20.fc37.x86_64 requires libgnome-2.so.0()(64bit) > > cbrpager (maintained by: mtasaka) > cbrpager-0.9.22-25.fc37.x86_64 requires libgnome-2.so.0()(64bit) > > celestia (maintained by: astro-sig, mattia, steve) > celestia-1.6.2-0.8.beta3.fc37.x86_64 requires > libgnome-2.so.0()(64bit) > > cellwriter (maintained by: limb) > cellwriter-1.3.6-4.fc37.src requires libgnome-devel = > 2.32.1-23.fc35 > > gnome-sharp (maintained by: caolanm, gnome-sig, laxathom, mbarnes, > rhughes, > rstrode, ssp, tpokorra) > gnome-sharp-2.24.2-31.fc37.x86_64 requires > libgnome-2.so.0()(64bit) > > gnome-translate (maintained by: buc) > gnome-translate-0.99-41.fc37.x86_64 requires > libgnome-2.so.0()(64bit) > > grhino (maintained by: salimma) > grhino-0.16.1-15.fc37.x86_64 requires libgnome-2.so.0()(64bit) > ... list continues for too long Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Orphaned packages looking for new maintainers
On Mon, Jan 02, 2023 at 05:02:41PM +0100, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > salimma: libstroke I don't even remember why I was maintaining libstroke - if there's anyone who still needs it, please pick it up. Looks like it's a build dependency for fvwm (cc:ing the maintainers). -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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] Re: EPEL-9 terrible updates (dav1d, libavif...)
Hi, This is entirely my fault, and I apologize. Will respond inline and discuss potential workarounds below. Also cc:ing epel-devel which is relevant. On Thu, Nov 17, 2022 at 02:18:48PM +0100, Fabio Valentini wrote: > On Thu, Nov 17, 2022 at 1:33 PM Bob Mauchin wrote: > > > > > > > > On Thu, 17 Nov 2022, 10:09 Remi Collet, wrote: > >> > >> > >> ** Please, manage EPEL-9 like a "stable" branch. ** > >> > >> soname change should be avoid, > >> if not possible (security exception ?) should be properly managed > >> and, at least, announced > >> That is indeed the policy: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ and I should have posted an announcement before putting up an update. > > > > Those are my packages but I don't recall authoring such changes? I remember > > considering David 1.0.0 for EPEL9 but didn't do so because of the > > dependency nightmare. > > I assume the dav1d 1.0.0 update was accidentally merged from Fedora > when building dependencies for rav1e. > I've pinged salimma on IRC / Matrix about this, he pushed these changes. > Indeed. When bringing up rust-rav1e, I did not notice the strict version dependency between rust-dav1d and dav1d until most of the rest have been built. This is the first mistake, had that been caught earlier I would have tried building an older version of rust-dav1d and other crates depending on it. In EPEL itself only libavif uses it, which is in turn is only used by kf5-kimageformats, which has a planned update going out soon, so between just rebuilding libavif or also rebasing it, it seems to be a good time to also update it: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-385df27ee1 Now this brings up two questions; I'll start with the more immediate one. ## Since dav1d update is already out though, what's the best path forward? - I can package a dav1d092 compatibility package to provide libdav1d.so.5 - I can also package a compatibility libavif package, but against which dav1d? - rebuild rpmfusion dependents against dav1d 1.0 and libavif 0.11 ## How do we better address (Fedora, EPEL) <=> RPM Fusion dependencies? On the Fedora side there is nothing currently that officially considers RPM Fusion (beyond the few allowlisted subsets like the Nvidia drivers). Amending the incompatible update policy to mention RPM Fusion is probably a no-go, but maybe mentioning "consider testing against well-known and popular third party repos" is doable? Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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: EPEL-9 terrible updates (dav1d, libavif...)
Hi, This is entirely my fault, and I apologize. Will respond inline and discuss potential workarounds below. Also cc:ing epel-devel which is relevant. On Thu, Nov 17, 2022 at 02:18:48PM +0100, Fabio Valentini wrote: > On Thu, Nov 17, 2022 at 1:33 PM Bob Mauchin wrote: > > > > > > > > On Thu, 17 Nov 2022, 10:09 Remi Collet, wrote: > >> > >> > >> ** Please, manage EPEL-9 like a "stable" branch. ** > >> > >> soname change should be avoid, > >> if not possible (security exception ?) should be properly managed > >> and, at least, announced > >> That is indeed the policy: https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ and I should have posted an announcement before putting up an update. > > > > Those are my packages but I don't recall authoring such changes? I remember > > considering David 1.0.0 for EPEL9 but didn't do so because of the > > dependency nightmare. > > I assume the dav1d 1.0.0 update was accidentally merged from Fedora > when building dependencies for rav1e. > I've pinged salimma on IRC / Matrix about this, he pushed these changes. > Indeed. When bringing up rust-rav1e, I did not notice the strict version dependency between rust-dav1d and dav1d until most of the rest have been built. This is the first mistake, had that been caught earlier I would have tried building an older version of rust-dav1d and other crates depending on it. In EPEL itself only libavif uses it, which is in turn is only used by kf5-kimageformats, which has a planned update going out soon, so between just rebuilding libavif or also rebasing it, it seems to be a good time to also update it: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-385df27ee1 Now this brings up two questions; I'll start with the more immediate one. ## Since dav1d update is already out though, what's the best path forward? - I can package a dav1d092 compatibility package to provide libdav1d.so.5 - I can also package a compatibility libavif package, but against which dav1d? - rebuild rpmfusion dependents against dav1d 1.0 and libavif 0.11 ## How do we better address (Fedora, EPEL) <=> RPM Fusion dependencies? On the Fedora side there is nothing currently that officially considers RPM Fusion (beyond the few allowlisted subsets like the Nvidia drivers). Amending the incompatible update policy to mention RPM Fusion is probably a no-go, but maybe mentioning "consider testing against well-known and popular third party repos" is doable? Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: SPDX Change update
On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote: > On 11. 11. 22 17:24, Sandro wrote: > > I'm not quite sure why pulling in an additional supplemental dependency > > would be considered a breaking change. Is it because rpmlint behaves > > differently with the new license definitions? > > Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I > use it to validate spec files for RHEL 9. When I install > rpmlint-fedora-license-data, a huge bulk of licenses that were not valid > when I started to use Fedora 36 and that are not valid for RHEL 9 are > suddenly valid. > To clarify -- while SPDX license strings are not valid for RHEL 9, are they valid for EPEL 9? Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]
Hi all, Just a note that over the summer, our intern did a project to try and address some of these issues (namely, that while it's trivial to convert a single crate to an RPM, trying to automate packaging all the dependencies and making sure that you don't break anything else while doing so is tedious and error-prone). Matt and Fabio might recall me getting their inputs on this several months ago. The tool: - recursively checking out packages - updating existing packages while carrying over manual changes - creating compatibility packages when upgrading packages with dependents - automate parallel COPR test builds of sets of packages in dependency order - chain-build all packages in Koji with requested side tag - merging and chain-building all packages across release branches - help review a rust update in Bodhi and verify no compatibility issues are introduced It does not automatically commit anything, of course, and right now is a bit opinionated in favor of picking the lowest satisfactory version possible, which is probably not what we want long term -- but it hopefully provides a nice foundation on which to build on I've finally gotten round to doing some polishing and getting it packaged: - updates for Fedora 36, 37, and Rawhide: https://bodhi.fedoraproject.org/updates/?search=rust-update-set-0.0.1=python-rust-update-set - Pagure repo: https://pagure.io/fedora-rust/rust-update-set There are some fixes for corner cases I encountered while trying to update our `below` packages with this, and some changes needed to get this packageable, but those are minor. It mostly works really well, and is at a stage where hopefully people can take a look and make suggestions for improvements. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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] Re: Should we retire weechat from EPEL 7?
On Thu, Oct 06, 2022 at 07:11:19PM +0200, Neal Gompa wrote: > On Thu, Oct 6, 2022 at 7:03 PM Michel Alexandre Salim > wrote: > > > > Hi all, > > > > We should probably retire weechat from EPEL 7 - it has multiple CVEs > > that can only be fixed by updating to versions >= 3.5, but the spec no > > longer works on EPEL 7 thanks to macros like `%cmake_build` not being > > available. > > > > https://bugz.fedoraproject.org/weechat > > > > I'm not sure either Paul or myself really care enough about EL7 to > > maintain a divergent spec. If someone does still care, PR appreciated to > > fix this, otherwise consider this the first notice that I'll retire this > > branch in a few days. > > > > The cmake3 package has all the macros from the mainline cmake package in > Fedora. > > It should be fully compatible, just swap %cmake_* for %cmake3_*. > > Oh thanks, that works. We can keep this going for now then: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e8cd6275b1 -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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] Should we retire weechat from EPEL 7?
Hi all, We should probably retire weechat from EPEL 7 - it has multiple CVEs that can only be fixed by updating to versions >= 3.5, but the spec no longer works on EPEL 7 thanks to macros like `%cmake_build` not being available. https://bugz.fedoraproject.org/weechat I'm not sure either Paul or myself really care enough about EL7 to maintain a divergent spec. If someone does still care, PR appreciated to fix this, otherwise consider this the first notice that I'll retire this branch in a few days. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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: [EPEL-devel] Selenium 4 tarball woes
Hi, On Sun, Oct 02, 2022 at 04:11:43PM -0500, Michel Alexandre Salim wrote: > When going over my packager dashboard, I noticed that Selenium has not > been updated for a while. > > I cleaned up and redid > https://src.fedoraproject.org/rpms/python-selenium/pull-request/3, and then > converted the package to rpmautospec to make future PRs easier to > merge, and also requested the epel 9 branch that's been requested > several times. > > But when looking at bumping the version for Rawhide, it turned out > that... selenium authors no longer upload their source tarballs to PyPI, > and on GitHub they now only provide giant multi-lingual blobs: > https://github.com/SeleniumHQ/selenium/releases > > Looks like Debian is also stuck, their Selenium is the first alpha of > Selenium 4: > https://packages.debian.org/sid/python3-selenium > > There's an upstream issue, and apparently it's now intermittently > working, so I'll build the last 3.x series for all active releases (the > last version finally has a LICENSE file) and then build the last 4.x > tarball I can find on PyPI for Rawhide. If it works for rebuilding > Django then I will also build that for EPEL 9. > Forgot to link the upstream issue: https://github.com/SeleniumHQ/selenium/issues/9917 alas, it seems no tarball was ever uploaded for any release since 4.0.0.a7: https://pypi.org/pypi/selenium/json -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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
[EPEL-devel] Re: Selenium 4 tarball woes
Hi, On Sun, Oct 02, 2022 at 04:11:43PM -0500, Michel Alexandre Salim wrote: > When going over my packager dashboard, I noticed that Selenium has not > been updated for a while. > > I cleaned up and redid > https://src.fedoraproject.org/rpms/python-selenium/pull-request/3, and then > converted the package to rpmautospec to make future PRs easier to > merge, and also requested the epel 9 branch that's been requested > several times. > > But when looking at bumping the version for Rawhide, it turned out > that... selenium authors no longer upload their source tarballs to PyPI, > and on GitHub they now only provide giant multi-lingual blobs: > https://github.com/SeleniumHQ/selenium/releases > > Looks like Debian is also stuck, their Selenium is the first alpha of > Selenium 4: > https://packages.debian.org/sid/python3-selenium > > There's an upstream issue, and apparently it's now intermittently > working, so I'll build the last 3.x series for all active releases (the > last version finally has a LICENSE file) and then build the last 4.x > tarball I can find on PyPI for Rawhide. If it works for rebuilding > Django then I will also build that for EPEL 9. > Forgot to link the upstream issue: https://github.com/SeleniumHQ/selenium/issues/9917 alas, it seems no tarball was ever uploaded for any release since 4.0.0.a7: https://pypi.org/pypi/selenium/json -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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
Selenium 4 tarball woes
When going over my packager dashboard, I noticed that Selenium has not been updated for a while. I cleaned up and redid https://src.fedoraproject.org/rpms/python-selenium/pull-request/3, and then converted the package to rpmautospec to make future PRs easier to merge, and also requested the epel 9 branch that's been requested several times. But when looking at bumping the version for Rawhide, it turned out that... selenium authors no longer upload their source tarballs to PyPI, and on GitHub they now only provide giant multi-lingual blobs: https://github.com/SeleniumHQ/selenium/releases Looks like Debian is also stuck, their Selenium is the first alpha of Selenium 4: https://packages.debian.org/sid/python3-selenium There's an upstream issue, and apparently it's now intermittently working, so I'll build the last 3.x series for all active releases (the last version finally has a LICENSE file) and then build the last 4.x tarball I can find on PyPI for Rawhide. If it works for rebuilding Django then I will also build that for EPEL 9. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature ___ 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
[EPEL-devel] Selenium 4 tarball woes
When going over my packager dashboard, I noticed that Selenium has not been updated for a while. I cleaned up and redid https://src.fedoraproject.org/rpms/python-selenium/pull-request/3, and then converted the package to rpmautospec to make future PRs easier to merge, and also requested the epel 9 branch that's been requested several times. But when looking at bumping the version for Rawhide, it turned out that... selenium authors no longer upload their source tarballs to PyPI, and on GitHub they now only provide giant multi-lingual blobs: https://github.com/SeleniumHQ/selenium/releases Looks like Debian is also stuck, their Selenium is the first alpha of Selenium 4: https://packages.debian.org/sid/python3-selenium There's an upstream issue, and apparently it's now intermittently working, so I'll build the last 3.x series for all active releases (the last version finally has a LICENSE file) and then build the last 4.x tarball I can find on PyPI for Rawhide. If it works for rebuilding Django then I will also build that for EPEL 9. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP 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: 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: CVE Tracking Bugs
Hi all,
On Wed, Sep 07, 2022 at 06:04:14PM +, Maxwell G via devel wrote:
> Hi Fedorians,
>
> I think the security tracking bug filing process needs to be amended. The
> current process is quite frustrating for me and other contributors. This is
> especially bad for Go CVEs, which there are lot of.
>
> Red Hat Product Security creates a single tracking bug for Fedora{, EPEL}
> _and_ all Red Hat products and CCs a bunch of Fedora maintainers. They then
> create separate bugs for each package that they deem affected. The affected
> packages are oftened determined in a manner that appears overzealous and
> arbitrary.
>
> After the bugs are created, we get spammed with a bunch of notifications
> about private bugs, RH product errata, and various other things that are
> completely irrelevant to Fedora. These messages flood my Bugzilla mailbox
> and obscure actual issues that I need to address. I do not really care
> whether a Go CVE has been mitigated in Red Hat Advanced Cluster Management
> for Kubernetes 2.4 for RHEL 8"
> or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8" or
> "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8."
>
An unrelated issue, but also not ideal:
some engineers at my company worked on fixing some Eternal Terminal
(package: et) security issues. Those are fixed, we pushed out updated
packages, then went through the CVE process...
Then CVEs get filed against both Fedora and EPEL, warning against
versions < 6.2.0 ... while 6.2.1 has been in stable updates for months.
https://bugzilla.redhat.com/buglist.cgi?bug_status=__closed__=Fedora=et_id=12953025=Fedora=Fedora%20EPEL_format=advanced_desc=CVE_desc_type=allwordssubstr
Feedback to RH prodsec people -- if the process right now assumes every
package built before the CVE is public is affected, this might not work
well for fixes released while under embargo.
Thanks,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
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
Orphaning Falcon Re: Schedule for Tuesday's FESCo Meeting (2022-09-20)
Dear all, On Mon, Sep 19, 2022 at 12:16:09PM +0200, Miro Hrončok wrote: > Following is the list of topics that will be discussed in the > FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on > irc.libera.chat. > > Change: pcre deprecation > https://pagure.io/fesco/issue/2862 > APPROVED (+3, 0, -0) > As a heads-up, I'm orphaning Falcon. It uses pcre, upstream has not had a commit for over 4 years, and disabling the module that requires pcre causes build failure because other core components depend on it. It shipped its own bundled pcre as an alternative, which sounds like an even worse idea than linking against a deprecated system library. If anyone want to take it up, be my guest, otherwise I suppose it will just get reaped automatically in a few weeks. Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: libFLAC soname bump
Hi Miroslav, On Mon, Sep 12, 2022 at 04:36:47PM +0200, Miroslav Lichvar wrote: > flac-1.4.0 changes the libFLAC and libFLAC++ sonames. There are also > some incompatible changes in the API, but I didn't see any packages > failing to built due to these changes. > > The following packages need to be rebuilt: > > I tried to rebuild them all except chromium which I suspect would take > too much space and time. Only ardour6, audacity, and xmms2 failed, for > unrelated reasons. > All the packages on your list except the 4 you listed in the paragraph above should be built now, please check if anything is missing: https://koji.fedoraproject.org/koji/builds?inherited=0=58420=-build_id=1 Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: libFLAC soname bump
On Tue, Sep 13, 2022 at 09:12:49AM +0200, Miroslav Lichvar wrote: > On Mon, Sep 12, 2022 at 12:24:34PM -0500, Maxwell G via devel wrote: > > On Mon Sep 12, 2022 at 11:29 AM CDT, Michel Alexandre Salim wrote: > > > > > > > > Would a proven packager be willing to take care of it? The new flac is > > > > now built in --target=f38-build-side-58420. libsndfile and audiofile > > > > need to be rebuilt next as some of the other packages depend on them. > > > > > > > > > > Sure, what do you need done? Just push an update from that sidetag, or > > > actually do some rebuilds as well? > > > > It sounds like they need all of those packages to be rebuilt: > > Yes, I'm looking for a proven packager to rebuild the packages and > submit an update for those that built successfully. Otherwise, we > would need to ask the individual maintainers and that would likely > take a long time to finish this. > Ack. I asked before checking, which I should have done. I can start going down the list - thanks for keeping it alphabetical. Need something for my machine to do while I'm watching conference talks anyway. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: libFLAC soname bump
Hi Miroslav, On Mon, Sep 12, 2022 at 04:36:47PM +0200, Miroslav Lichvar wrote: > flac-1.4.0 changes the libFLAC and libFLAC++ sonames. There are also > some incompatible changes in the API, but I didn't see any packages > failing to built due to these changes. > ... > > Would a proven packager be willing to take care of it? The new flac is > now built in --target=f38-build-side-58420. libsndfile and audiofile > need to be rebuilt next as some of the other packages depend on them. > Sure, what do you need done? Just push an update from that sidetag, or actually do some rebuilds as well? Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Joining Fedora Chat from own Homeserver
Hi Simon, On Mon, Sep 12, 2022 at 12:24:39PM +0200, Simon de Vlieger wrote: > > However, I'd like to join the Fedora Project Chat not from my FAS account but > from > my own homeserver; this homeserver is hosted by EMS. As far as I know I can't > login > to multiple accounts with the Element application I use as my Matrix client. > > Doing so seems excessively hard, I had to look around for quite a while to > find and > invite link to the Fedora 'Space' which I eventually found on the forums: > https://matrix.to/#/#fedora-space:fedoraproject.org (can someone let me know > if this > is the correct link to use to join the Fedora 'Space'?) > That's the correct link, yes. It's a bit unfortunate that even though spaces are just special rooms, trying to find the room name for a space is rather hard in the Element client > After that the problems begin, I've been able to join two channels > (Announcements and > Introductions) but joining those channels took about 60 seconds each. Joining > other > channels such as Devel or Social time out. The Python room also gives me > issues but in > my local Element client it tells me that the room does not exists on the > server. > That unfortunately seems typical -- I'm joining the space from a different server too (Element One, ironically *also* hosted by EMS). Joining from a different homeserver seems to be a bit unreliable no matter which two servers are involved, especially for larger rooms (getting this issue joining Debian, FOSDEM, and Linux Plumbers rooms too). (my use case is: both Element One and Fedora Chat use SSO, and Element is the only app that does SSO properly right now, so I can't have both on my phone without futzing around with Island or some other app to be able to run Element in a normal and 'work' context) > Aside from that any joined room does not show up under the 'Fedora' space nor > can I > move them there. > That part is weird though, mine show up just fine. > I'd like to know any tips and/or tricks people have for succesfully joining > channels > on the Fedora Chat through their own homeserver or if I am relegated to > keeping an > extra browser open for the Fedora Chat web-Element, or if I should ignore all > of the > fancy Matrix-ness and revert back to IRC. This guide is also super handy: https://kparal.wordpress.com/2021/06/01/connecting-to-libera-chat-through-matrix/ Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: liburing update
On Tue, Aug 23, 2022 at 08:07:13AM +0100, Richard W.M. Jones wrote: > io_uring (https://en.wikipedia.org/wiki/Io_uring) is an important > kernel facility, essentially an alternate way of dispatching system > calls more efficiently. It's used in a lot of high performance > situations. Although you can talk to it directly, most users should > be using liburing, a C library. > > We haven't updated liburing for "a while", since April 2021 to > liburing 2.0. There have been several upstream versions since then, > the latest is liburing 2.2, released in June. > > In theory this version is compatible and uses symbol versions: > > $ rpm -q --provides liburing > liburing = 2.2-1.fc38 > liburing(x86-64) = 2.2-1.fc38 > liburing.so.2()(64bit) > liburing.so.2(LIBURING_2.0)(64bit) > liburing.so.2(LIBURING_2.1)(64bit) > liburing.so.2(LIBURING_2.2)(64bit) > > so in theory this is not an ABI break. In practice I'm told that the > API of liburing is not very stable. > From my experience maintaining folly, the liburing API is definitely not very stable, and... this update might make it possible to compile more recent versions of folly again. So +1 for updating. Not sure if we should also reach out to upstream to do an ABI bump, but for neovim (which has a similar issue with tree-sitter having an internal API version that's not reflected in the soname) I just add additional versioned BR and R dependencies. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Orphaned packages looking for new maintainers
On Mon, Aug 22, 2022 at 01:07:26PM +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > mailman3 infra-sig, orphan, salimma 0 weeks ago > monkeytype orphan 0 weeks ago Picked these back up - will try and address the issues this week, sorry for the delay. > rubygem-asciidoctor-pdfabradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker > rubygem-chunky_png mmorsi, orphan, snecker 0 weeks ago > rubygem-css_parser abradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker > rubygem-font-awesome-rails abradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker > rubygem-prawn-icon abradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker > rubygem-prawn-manual_builder abradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker > rubygem-prawn-svg abradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker > rubygem-prawn-templatesabradshaw, ckyriakidou, evgeni, 0 weeks ago >fale, orphan, snecker ^ these will probably break a lot of documentation builds - one of my package (nickle) is affected. Not sure I have the bandwith to help fix this though. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: fedora-create-review error message
On Tue, Aug 09, 2022 at 03:34:56AM +, Davide Cavalca via devel wrote: > On Sun, 2022-08-07 at 20:27 -0500, Richard Shaw wrote: > > I'm working on a package review for libphidget22 (rename of > > libphidget), but after typing in my bugzilla credentials I get the > > following: > > > > > 32000: The method 'Bug.get' is not supported without using API keys > > and the the authentication header. See > > https://bugzilla.redhat.com/docs/en/html/api/core/v1/general.html#authentication > > for details on using the 'Authorization' header. at > > /usr/share/perl5/vendor_perl/SOAP/Lite.pm line 2855.\n"> > > > > Haven't seen this before, but I haven't submitted a new package in a > > while either. > > This should have been fixed in > https://pagure.io/FedoraReview/c/7330e7f1b47986211aeb2ce1059731ec6a9a1171?branch=master > but I don't think that's made it to a release yet. > Neal's made me a comaintainer, so I'll try and cut a release this week. Going to wait until I have some spare time so I don't accidentally make a hash of my first release! Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: Announcing fmt library soversion bump
Hi Vitaly, Will try and take care of folly ASAP - thanks! -- Michel ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
On Wed, 2022-06-29 at 20:09 +0200, Vitaly Zaitsev via devel wrote: > On 29/06/2022 18:47, Robbie Harwood wrote: > > I don't see how you got there. Nowhere does it say that the > > maintainer(s) are removed - just that one is added, and made > > contact for > > EPEL bugs. > > Newly added EPEL maintainers can make any changes to Fedora branches. > I > don't like that. > Rest assured, they cannot. The escalation process specifically documents granting the newly added maintainers collaborator access only on epel* branches. We actually made sure collaborator support is properly working before we document this policy. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Unresponsive maintainer: Alex Chernyakhovsky
Hi Robbie, On Wed, 2022-06-29 at 12:02 -0400, Robbie Harwood wrote: > In this case, because no one needinfo'd the maintainer, the EPEL > policy > can be slower (two weeks compared to the minimum ten days for > nonresponsive). Also, a literal reading of the EPEL policy says that > the same person needs to needinfo as opened the bug, so if that's the > case, then it would have been three weeks (because I didn't open > either > bug), unless I ask one of them to needinfo. I'm not sure if that's > intended? > I'm not sure that's intended. I'm involved in drafting that policy, and personally would not mind escalating a bug initially opened by someone else. Thanks for pointing out that the language is a bit unclear, we can probably iterate on this. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
RFC: squashfuse multi-threaded rewrite
Hi all, Kevin has a PR that rewrites squashfuse to be multi-threaded: https://github.com/vasi/squashfuse/pull/70 I've put up a PR backporting this on top of the recently released 0.1.105 which is now built for Rawhide: https://src.fedoraproject.org/rpms/squashfuse/pull-request/3 Does anyone have objections to having this in Fedora? We're trying to get this accepted upstream too, which should happen soon; once that happens we can start upstreaming the only remaining change we currently carry in our internal build. Thanks, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Installing ffmeg-free degrades firefox video support
On Thu, 2022-06-09 at 03:51 +0200, Kevin Kofler via devel wrote: > > In addition, that download offer actively promotes proprietary > software, > which used to be a no go in Fedora, but now (very sadly) even Fedora > itself > has started doing that by shipping pointers to all sorts of > proprietary > stuff ranging from NVidia drivers from RPM Fusion (whereas ironically > the > software in RPM Fusion that follows our licensing policies is > considered off > limits due to patents) to all sorts of proprietary Flatpaks. (It > shall also > be pointed out that it is disputed whether the NVidia drivers can > even be > legally distributed at all, because they are under a proprietary, > GPL- > incompatible license and therefore arguably cannot be legally linked > to the > GPLv2-licensed Linux kernel. But basically nobody cares about that.) The linking happens on the user machine, no? For Fedora only akmods are available, which generate kernel-specific kmod RPMs on the user machine. Which causes its own issues since that means you can't boot with Secure Boot anymore... RPM Fusion does produce binary kmods, but those target EL kernels only (so yeah, the legality of that is questionable). I'm not sure 'nobody' cares - and hopefully this gets resolved in the medium term once the open source driver is ready for desktop use. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Wed, 2022-06-08 at 15:06 -0500, Chris Adams wrote: > Once upon a time, Michel Alexandre Salim > said: > > This won't be ready until EPEL 10 or even 11, but one thing I've > > discussed with the DNF maintainer is the possibility of having > > something like /etc/yum.repos.d/reponame.repo.d/ where you can drop > > overrides, similar to how you can drop overrides for systemd unit > > files. > > I've wanted (and suggested) something like this for ages, for a > different reason: ability to drop-in local mirror configs, again > without > modifying the RPM-packaged config. > Nice! Yeah, there seems to be multiple use cases for this - come to think of it, we could use your use case in some of our internal systems too. I'll bring it up in our internal roadmap planning and try and allocate some time for this for the next few months. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sat, 2022-06-04 at 20:47 -0400, Stephen Smoogen wrote: > > > On Sat, 4 Jun 2022 at 18:54, Neal Gompa wrote: > > On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson > > wrote: > > > > > > When I first created the EPEL issue to auto-enable crb repo[1] I > > > was only thinking of CAN we do it. I wasn't thinking SHOULD we > > > do it. > > > We've come to the point that we actually can do it. But before > > > we go down that road, I wanted to take a step back and ask, > > > should we do it. > > > > > > The more I think about it, the more I think we shouldn't auto- > > > enable the crb repo for epel8 and epel9. Here are my reasons > > > why. > > > > > > 1 - The need to auto-enable crb isn't as big as it was before. > > > At the time that I wrote that issue, I was getting quite alot of > > > bugs / pings / emails about epel packages not being > > > installable. I think on average about 2 a month. > > > With epel being in fedora-docs, and with Carl's re-write of how > > > to enable epel, that number has dropped significantly. I > > > possibly still average one a month, but that's an average over a > > > year, with most of them being last year. > > > In short, I believe the documentation is better, and easier to > > > find, allowing people to enable crb on their own, without > > > automation. > > > > > > 2 - crb isn't an epel repo > > > We really shouldn't be messing with other repo's that we, epel, > > > don't own. > > > > > > 3 - We are taking the choice away from users > > > After I stopped and thought about it, there are plenty of > > > scenarios where people want epel for just one or two packages, > > > which do not require crb. > > > > > > 4 - All the many small side cases. > > > auto-enabling crb will have bugs. RHEL and it's clones are in > > > too many odd places for us to not hit some odd use cases we > > > didn't expect. We'd have to keep fixing the scripts. > > > > > > I could go into more explanation on each of those things, but in > > > the end, I've talked myself out of wanting to auto-enable crb for > > > epel8 and epel9. > > > But I also wanted to get others' thoughts before I close the bug > > > and pull request. > > > > > > What do others think? > > > > > > > Let me start with examples that I get *regularly*: Pagure fails to > > install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown > > is > > not available. KDE Plasma fails to install because of a mass of > > missing dependencies. > > > > > > To be crystal clear, I would like this fixed for at least the > > majority > > of cases and gracefully fail when it can't be fixed. > > > > > > > The issue is going to be that an RPM which changes outside > subscriptions will probably be an auditable finding for a lot of > sites. It is one of the reasons this has been considered bad form in > the past and would probably cause a lot of requests that it be made > optional, removed, OR epel black listed. It doesn't matter if we all > think that would be a silly finding, changes like this are considered > security issues at various sites especially if for the last 15 years, > epel-release has not done something like that and so had been > 'approved' for use. > > At best I could see an optional side package `epel-release-enable- > other-repo` or some similar name which just has these changes and is > not pulled in by default and requires epel-release. Thus you could > tell people to install `epel-release-enable-crb` and would get > packages and if people have reports of broken packages you tell them > to install this which will do the correct repo changes. > This won't be ready until EPEL 10 or even 11, but one thing I've discussed with the DNF maintainer is the possibility of having something like /etc/yum.repos.d/reponame.repo.d/ where you can drop overrides, similar to how you can drop overrides for systemd unit files. That would allow epel-release to just ship an override for crb.repo that toggles enabled=1, without messing with config files (which I hate, because that means newer crb.repo changes won't be picked up). Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self Introduction: Yizheng Xie
Welcome (again) Yizheng! On Fri, 2022-06-03 at 21:56 +, Yizheng Xie via devel wrote: > Hello, Fedora developer community! > > My name is Yizheng Xie (Fedora Project Username: yizhengxie). > Currently I am a Production Engineer Intern in Meta Kernel Team, > specifically in Linux Userspace projects. I am a first-year master > student in Boston University in Computer Science. My software > engineering skills are most solid in Python, Java, C++ and Golang. > > I will work on Rust Packaging Tooling this summer under the > guidance from Michel (Fedora Project Username:salimma). I am > happy to continue contributing as a package maintainer after my > internship! > Great having you here (both at Fedora and at Meta)! I sponsored Yizheng as a packager - he'll be co-maintaining some packages to get experience with packaging - and will be mentoring him throughout the process. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: This is a digitally signed message part ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Mon, May 16, 2022 at 02:12:12PM +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > golang-github-google-gopacket go-sig, orphan 1 weeks ago Picking this one up as a dependency of golang-github-facebook-time. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Change proposal: make Change proposals more obvious
On Thu, Apr 28, 2022 at 09:39:25AM -0400, Ben Cotton wrote:
> I'd be open to putting some boilerplate at the beginning, although I'm
> not convinced it would do much good for this particular problem.
> Still, I doubt it would *hurt* anything. Aleksandra's suggestion is a
> good approach.
>
>
> On Thu, Apr 28, 2022 at 9:01 AM Neal Gompa wrote:
> >
> > We could also start the email subject with "CHANGE PROPOSAL" instead of
> > "Change"
>
> I'm pretty sure I used to, but people were upset about how much space
> it took in the subject so that you couldn't see what the actual
> proposal was. And the word proposal *is* already in each subject line
> (just at the end).
>
I don't recall if this has been discussed before - probably has, so
apologies: do we know if projects like Python (with PEPs) and Swift
(with Swift Evolutions) have the same issue with inaccurate media
reporting?
Looking randomly at a Swift proposal:
https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md
The announcement looks like this:
https://forums.swift.org/t/se-0306-actors/45734
with the title being SE-{number}: {title}, with the text making it clear
that 'we are reviewing this proposal' and what a review entails, and the
proposal itself is just linked instead of inlined - and has a field
early on describing its current status.
(We don't number proposals, though maybe we should, but the rest could
probably be considered).
Best,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
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 on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Would it be useful to have a video call to discuss the "Deprecate Legacy BIOS" Change proposal?
On Wed, Apr 13, 2022 at 09:03:09PM +0200, Hans de Goede wrote: > Hi, > > > 1. I'm not sure if it is possible to setup group ownership > of pkgs in pagure? So to keep things simple the few packages which > are only necessary for BIOS boot can be handed over to me and then > I'll just add other people willing to help out as co-maintainers. > yup, Python, Rust, and Go SIG does this all the time > 2. Setup a mailinglist for this and have that in bugzilla + PR > Cc for all the relevant packages. > The group will get emailed just like a normal maintainer, IIRC. Someone will need to register that group's email in Bugzilla just like a normal account Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Fri, Apr 08, 2022 at 02:39:04PM -0400, Robbie Harwood wrote: > Michel Alexandre Salim writes: > > > - as I stated, there are offers to help with getting syslinux replaced > > with GRUB > > More generally, I'm concerned that folks think this'll help a lot more > than it actually will. There's a tendency to think in terms of packages > - they're contained units and therefore convenient to reason about. But > just being in a container is not an indication of complexity or size. > The obligatory example of this that is (I hope) generally understood is > the kernel. One source package, wildly different complexity than > anything else - to the point where it's more meaningful to talk about > the workflows enabled, subsystems, etc. than the rpms themselves. I've > mentioned this upthread as well, but this is the nature of the problem: > it's not about *packages*, it's about *use case*. > Right, not saying this is a viable long-term solution. But having everything being GRUB, *plus* using protective MBR, would allow us to not force people to reinstall when we finally kill off legacy BIOS. * yes, we still need to figure out how to convert existing systems to * protective MBR plus GPT, but at least we won't be creating new legacy * installs that will require reinstallation Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Fri, Apr 08, 2022 at 10:14:19PM +0800, Zamir SUN wrote: > > > Probably it isn't a problem for some users, but I'm still having bad > experience with UEFI on x86_64 now. Out of my 3 machines I only have 1 > system that works fine with UEFI. And my parents' laptop was purchased 2 > years ago and the UEFI firmware does not allow to boot anything other than > Windows on UEFI mode (regardless of turning secure boot on or off) and I > have to switch to BIOS mode to make Fedora work there. So in this situation, > I think it's way too aggressive to accept the change - this will probably > drive away some potential new users with decent laptop like my parents'. > I've encountered one such laptop - turning off secure boot was not enough, there's another option somewhere else for disabling key verification (IIRC). I agree that this means dropping legacy BIOS is premature, and we should focus more on future-proofing our installations to make the transition easier in the future. Cheers, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Fri, Apr 08, 2022 at 12:41:22PM -0400, Robbie Harwood wrote: > Michel Alexandre Salim writes: > > > I sympathize with the change owners' position that detractors need > > to assume their good intentions, but I feel like the same needs to be > > assumed for community contributions, > > That's not really a "position" so much as a restatement of the Fedora > Project's code of conduct. If you feel that our comportment is not up > to snuff, please provide specific feedback so we can improve. > (Otherwise, a statement like that just comes across as propagating FUD.) > Apologies if this came across that way, I'm actually trying to calm waters here. I'm rather surprised I came across as propagating FUD... As for specifics: - my general impression from reading this thread is this Change as originally written is too aggressive in its timeline, and too optimistic in assuming hardware, esp on the server side, is ready - let's ignore the unfortunate dispute over the "PR was disabled" issue, I think that was a red herring - as I stated, there are offers to help with getting syslinux replaced with GRUB. what I've not stated originally is Chris Murphy brought up protective MBR and switching all new installs to inst.gpt, which let us future proof new installations for when we do kill off legacy BIOS. What people who want to help needs, though, is some sense that our contributions are welcome. I've been at the receiving end of being FUD-ed as having a 'hidden agenda', so I know how that feels, and I'm definitely not trying to do that. What I'm trying to point out is that the perceived lack of contribution should not really be used as a reason to push this change right now: - Neal pointed out he has been working on addressing this for a while, and have not put up a Change Proposal because he thought it was premature - if the Change Proposal becomes "we can't support legacy BIOS long term, it's deprecated, community contributions welcome to help define the timeline and milestones" - that would probably get more people contributing rather than "this is our really fast timeline to deprecate this". Plus as many have stated, immediately breaking new installation is not deprecation, so I feel all subsequent discussion has been unfortunately tainted by that Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On Fri, Apr 08, 2022 at 11:46:50AM -0400, Jared Dominguez wrote: > On Thu, Apr 7, 2022, 19:46 Samuel Sieb wrote: > > > I don't understand why we're still using syslinux instead of grub for > > legacy boots, especially since I think now you can use the same grub.cfg > > file for both. > > > It's development and validation work for something that's not a priority > for those who are doing bootloader work, and no one else has stepped up to > put in the time to do this work. The change proposal being discussed in > this thread is calling for community contributors. > Would using Grub for legacy boot be more, or less work than continuing to support syslinux, assuming people step up to do the development and validation? As someone who is also interested in eventually phasing out legacy BIOS support, but think it's too early, I sense that this is a better way to deprecate - first future proof the legacy installations in such a way that at some future time you can simply upgrade the system, switch to UEFI and keep your system disk - is a much better transition for our users. *and* I have been hearing from people who are interested in doing this work. I sympathize with the change owners' position that detractors need to assume their good intentions, but I feel like the same needs to be assumed for community contributions, and we've unfortunately been talking past each other a bit in this thread. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Looking for provenpackager to update rapid-photo-downloader package
On Tue, Mar 29, 2022 at 05:57:52PM -, Damon Lynch wrote: > Greetings Fedora community, I am the developer of Rapid Photo Downloader. The > package for it in Fedora is about two years old, and crashes during start-up > under Python 3.10. > > As the subject says, I'm looking for a provenpackager to update the package. > I'm posting this message here at the suggestion of a fellow PyQt developer > who unlike myself is a Fedora expert. > > I filed a bug report last year but the maintainer has been unable to work on > it: https://bugzilla.redhat.com/show_bug.cgi?id=2031866 > Meanwhile, two months ago Neal Gompa made this pull request to update it: > https://src.fedoraproject.org/rpms/rapid-photo-downloader/pull-request/3 > I'm a provenpackager, but so is Neal, so I just pinged him to see if he wants to merge and push an update. > Unfortunately I'm unable to volunteer my time because I managed to injure my > hands while working on the code earlier this year. Serious typing injuries > are not fun. :-( > (I'm dictating this using a voice recognition program under Windows.) > Ouch, hope you recover soon! Also, I'm hugely impressed by how well the email is formatted, I hope you didn't have to do that much correction by hand. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages (incl. go-rpm-macros) looking for new maintainers
On Mon, Mar 28, 2022 at 10:52:21AM +0200, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > mcrouter dcavalca, filbranden, orphan 0 weeks ago Claimed this back, I accidentally left this package out when fixing the rest of the Folly stack. Sorry for the noise! Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Package downgrades on upgrade from F35 to F36 + categorized list
Hi Fabio, On Fri, Mar 18, 2022 at 02:32:13PM +0100, Fabio Valentini wrote: > - mcrouter-0:0.41.0.20220221-1.fc35 > > mcrouter-0:0.41.0-8.20211222git90d63a3.fc36 > Snapshot versioning scheme format was changed on F35 only (!), > resulting in an NVR downgrade (?). > Huh, somehow it got left off https://bodhi.fedoraproject.org/updates/FEDORA-2022-4cea2ebe6c - I'll push a new update. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Tue, Mar 22, 2022 at 09:27:31AM +0100, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > python-blessings orphan 2 weeks ago I'm taking this one, as bpython indirectly depends on it (via curtsies). I've also added python-sig with commit access. Best, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Problem with cmake 3.23.0
Sorry for the late reply, domain issue affected my email reception. The macros don't change between F36 and F37; I've filed https://gitlab.kitware.com/cmake/cmake/-/issues/23334 to see if upstream can shed a light on this. -- Michel ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Re: Problem with cmake 3.23.0
On Fri, Mar 04, 2022 at 09:26:04AM -0500, Steven A. Falco wrote: > There is a new FTBFS for KiCad [1]. I filed an issue with KiCad [2] and got > a comment from the project leader: > > This looks like cmake issue to me. For some reason cmake is creating an > incorrect build folder: > This is probably related: in cmake 3.22 (Fedora 36) and below, this works: ``` mkdir some-dir cd some-dir %cmake .. cd - mkdir other-dir cd other-dir %cmake .. cd - ``` Which is useful if you need to invoke `%cmake` several times, e.g. to build against different Lua runtimes (e.g. lua-luv) or to do both static and shared library builds (which we used to do for the folly stack). Also: if the CMakeLists.txt is not in the root of your project tarball, previously you can just do `%cmake actual-src-dir`. In F37's cmake 3.23, it seems that `cmake -S . ..` has the `-S .` trump the `..` when it comes to finding where CMakeLists.txt is, while previously `..` wins. I was working around it by simply `cd actual-src-dir` before `%cmake`, but it turns out simply passing an additional `-S` works, e.g.: ``` mkdir some-dir cd some-dir %cmake -S .. cd - ``` e.g. https://src.fedoraproject.org/rpms/lua-luv/pull-request/3 Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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 on the list, report it: https://pagure.io/fedora-infrastructure
