Re: Node.js 22.x coming to Rawhide/F41
I also get a crash when running npm install: https://bugzilla.redhat.com/show_bug.cgi?id=2282103 Sandro On 21.05.24 09:57, Vít Ondruch wrote: It seems that it breaks at least two of my packages unfortunately: https://koschei.fedoraproject.org/package/rubygem-ejs https://koschei.fedoraproject.org/package/rubygem-execjs The former is using the latter, so the real issue is likely in the latter. I don't have cycles to investigate more :( BTW these are likely used in some other components of Ruby on Rails, so the potential for breakage is higher. But Koschei is experiencing some issue, so hard to tell. Vít Dne 17. 05. 24 v 14:28 Stephen Gallagher napsal(a): As of today, I have built Node.js 22.2.0 for Fedora Rawhide. It is currently available as a non-default package (Node.js 20 remains the default during this short transition period). If you maintain a package that depends on Node.js (either runtime or build-time), please take some time in the next week or so to verify whether it continues to work properly with Node.js 22. I plan to switch the default in Rawhide over to 22.x as per the recently-approved Change[1] on or shortly after May 27th. If you encounter a significant problem with Node.js 22, please contact the nod...@fedoraproject.org mailing list and we will try to help you. [1] https://fedoraproject.org/wiki/Changes/Nodejs22 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: gdal-3.9.0 coming to rawhide
Hi I've now merged the side tag. Three packages failed to build: - bes: FTBFS due to multiple causes (lxml2, hdf5 incompatibilities, incompatible-pointer-type errors, missing flex/bison BR - I gave up on the hdf5 incompatibilities) - python-fiona: Test failures related to the parquet file format, I'll try to investigate further - python-rasterio: Test failures, possibly also related to GDAL, I'll also try to investigate further Sandro On 13.05.24 14:32, Sandro Mani wrote: Hi I'll be building gdal-3.9.0 for rawhide shortly, which carries a soname bump. I'll be submitting the builds to the f41-build-side-89329 side tag, and rebuild all of the dependent packages as well: GMT mapserver liblas python-fiona postgis merkaartor bes qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo I expect this to be done within two or three days. Thanks Sandro -- ___ 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: gdal-3.9.0 coming to rawhide
Hi I'll be building gdal-3.9.0 for rawhide shortly, which carries a soname bump. I'll be submitting the builds to the f41-build-side-89329 side tag, and rebuild all of the dependent packages as well: GMT mapserver liblas python-fiona postgis merkaartor bes qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo I expect this to be done within two or three days. Thanks Sandro -- ___ 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
Review request: python-libgravatar
Hi pgadmin4 grew a dependency on python-libgravatar, which I've posted for review here: https://bugzilla.redhat.com/show_bug.cgi?id=2279493 Happy to review in exchange. Thanks Sandro -- ___ 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
Planning to orphan freeimage
Hi I intend to orphan freeimage. Probably, the package should rather just be retired. Upstream is effectively dead, and there is a constant stream of CVEs getting filed against the package which are not addressed upstream. Over the past two years I've fixed many of those CVEs downstream, but the most recent batch of 15 CVEs is leading me to capitulate. Currently, the following packages require freeimage: PerceptualDiff allegro5 cegui06 deepin-image-viewer gazebo imv ogre photoqt A minimal impact check: PerceptualDiff: freeimage is a hard dependency. PerceptualDiff itself has seen its last commit 4 years ago, last release 8 years ago allegro5: freeimage is an optional dependency cegui06: freeimage is an optional dependency deepin-image-viewer: freeimage is a hard dependency gazebo: freeimage is a hard dependency. (The fedora package is for "gazebo-classic" https://github.com/gazebosim/gazebo-classic, which points to https://github.com/gazebosim/gz-sim as the "latest version", which does not appear to require freeimage) imv: freeimage is an optional dependency ogre: freeimage is an optional dependency photoqt: freeimage is an optional dependency Thanks Sandro -- ___ 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: QGIS rebuild needed after GRASS GIS update
Hi Markus I'm happy to help coordinating the grass update. Note however that: - If the update does not carry ABI changes (and hence soname bumps), a rebuild of QGIS is not needed - If The update does carry a soname bump, it should be avoided in stable releases Sandro On 19.03.24 13:44, Markus Neteler wrote: Hi, While being a maintainer of the GRASS GIS rpms for years, I am not fully sure about the procedure to get QGIS rebuilds triggered (in a side-tag with GRASS GIS). I have updated GRASS GIS to the latest stable: https://bugzilla.redhat.com/show_bug.cgi?id=2268514 and submitted it to - https://src.fedoraproject.org/rpms/grass/commits/rawhide - https://src.fedoraproject.org/rpms/grass/commits/f40 - https://src.fedoraproject.org/rpms/grass/commits/f39 What would be the next step? I don't have write access for QGIS (https://src.fedoraproject.org/rpms/qgis). Sorry if this is RTFM, the procedure isn't fully clear to me :) Thanks, Markus -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review requests: mingw-directxmath, python-jsonformatter
Hi I'd apprechiate a review of the following two packages: - mingw-directxmath: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2268585 (required for mingw-gstreamer1-plugins-bad-free 1.24.0) - python-jsonformatter: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2268579 (required for pgadmin4 8.4) Both are very simple packages. Happy to review in exchange. Thanks Sandro -- ___ 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: Fw: [Bug 2066129] mingw-libgsf-1_14_52 is available
On 06.02.24 8:50 AM, Marc-André Lureau wrote: Hi On Mon, Feb 5, 2024 at 8:52 PM Daniel P. Berrangé wrote: On Mon, Feb 05, 2024 at 05:34:06PM +0100, Dan Horák wrote: Hi, could someone in the mingw team look at mingw-libgsf / libgsf (please see the bug forwarded below)? If I see right, then the standalone mingw-libgsf package should be retired as there are mingw builds from the regular libgsf package, which seems to be regularly updated. Copying Marc-André who added the mingw sub-RPMs to the native package. The mingw-libgsf should have been retired on rawhide, as soon as the libgsf native had a successful build with mingw packages. At this point I guess it'll need retiring on both rawhide and f39 Correct, I missed that. Geg, Sandro, can you retire the mingw-libgsf package? I've retired the package, but not sure if it worked 100% as I'm not listed as package admin. Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mingw packaging: equivalent of %cmake_build, %cmake_install macros?
On 29.01.24 10:38 PM, Eric Smith wrote: On Mon, Jan 29, 2024, 02:32 Sandro Mani wrote: For mingw, the most common approach is %build %mingw_cmake %mingw_make_build %install %mingw_make_install # Don't forget this one |%mingw_debug_install_post| Thank you, but as I said in my request, that is exactly what I already tried. It worked fine for pugixml and zipios, but failed for fmt. In the fmt.spec you posted, I see %mingw_cmake -G Ninja [...] this means that you are generating ninja build scripts, not Makefiles. If you want to use ninja, you should call %mingw_ninja after %mingw_cmake -G Ninja. To generate Makefiles, call %mingw_cmake without the -G Ninja, and after this %mingw_make_build Sandro -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mingw packaging: equivalent of %cmake_build, %cmake_install macros?
For mingw the more recent "%cmake_build" and "%cmake_install" have never
been implemented (one could add them [1]).
For mingw, the most common approach is
%build
%mingw_cmake
%mingw_make_build
%install
%mingw_make_install
# Don't forget this one
|%mingw_debug_install_post|
See also [1] for an example.
Hope this helps
Sandro
[1] https://src.fedoraproject.org/rpms/proj/blob/rawhide/f/proj.spec
[1]
https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/macros.mingw64
On 29.01.24 10:13 AM, Eric Smith wrote:
I'm trying to add mingw build support to the fmt package spec. I've
done this previously with the pugixml and zipios packages, and
submitted the spec diffs to the package maintainer of those.. Both
packages use cmake. Both in the %build section use %cmake then
%cmake_build, and in the %install section use %cmake_install. As
expert neither on cmake nor on mingw, I'm somewhat baffled as to why
there are %cmake_build and %cmake_install macros, but no corresponding
%mingw_cmake_build and %mingw_cmake_install macros. Is there some
equivalent that just happens to not be obvious to me? What I found
worked for both pugixml and zipios was:
original: %cmake; %cmake_build
original install: %cmake_install
added for mingw build: %mingw_cmake (and did not add anything
equivalent to %cmake_build)
added for mingw install: %mingw_make_install; %{?mingw_debug_install_post)
Unfortunately this simple attempt failed for fmt. The %mingw_cmake
doesn't cause an error, but also doesn't build fmt. The attempted
%mingw_make_install results in: "make: *** No rule to make target
'install'. Stop." Perhaps this has to do with the fmt build also
using Ninja, which pugixml and zipios do not.
If anyone can offer advice, it would be much appreciated. I started
from the specs from the packages:
pugixml-1.13-4
zipios-2.2.5.0-7
fmt-10.0.0-3
My modified spec files are at:
http://www.brouhaha.com/~eric/fedora-packaging-test/
Best regards,
Eric
@brouhaha
--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: HEADS UP: update to tesseract-5.3.4
On 28.01.24 10:48 AM, Sandro Mani wrote: On 28.01.24 4:21 AM, Yaakov Selkowitz wrote: On Sat, 2024-01-27 at 23:20 +0100, Sandro Mani wrote: I'll be updating to tesseract-5.3.4 in rawhide shortly, which carries a soname bump (despite it being a minor version, unfortunately upstream versions the SO with the package version). I'll rebuild the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract skanpage zathura-pdf-mupdf Since it's not clear from your email, please be sure to do this in a side tag. Yes, the builds will be submitted to f40-build-side-82395 This is now done, except for ffmpeg which was already FTBFS. Sandro -- ___ 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: update to tesseract-5.3.4
On 28.01.24 4:21 AM, Yaakov Selkowitz wrote: On Sat, 2024-01-27 at 23:20 +0100, Sandro Mani wrote: I'll be updating to tesseract-5.3.4 in rawhide shortly, which carries a soname bump (despite it being a minor version, unfortunately upstream versions the SO with the package version). I'll rebuild the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract skanpage zathura-pdf-mupdf Since it's not clear from your email, please be sure to do this in a side tag. Yes, the builds will be submitted to f40-build-side-82395 Thanks Sandro -- ___ 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: update to tesseract-5.3.4
Hi I'll be updating to tesseract-5.3.4 in rawhide shortly, which carries a soname bump (despite it being a minor version, unfortunately upstream versions the SO with the package version). I'll rebuild the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract skanpage zathura-pdf-mupdf Thanks Sandro -- ___ 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
Review Request: mingw-python-blinker
Hi I'd appreciate a review of mingw-python-blinker [1] which is a new dependency of mingw-python-flask-3.0.0. Happy to review in exchange. Thanks Sandro [1] https://bugzilla.redhat.com/show_bug.cgi?id=2257095 -- ___ 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: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On 05.01.24 17:57, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Dec 17, 2023 at 04:44:36PM +, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 15, 2023 at 11:56:56PM +0200, Sandro Mani wrote: Hi I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test builds here [1], according to which scribus, vfrnav and pdfsign currently do not support podofo-0.10.x. To keep these functional, I've prepared a podofo-compat package with the previous 0.9.x library. The review request is here [2]. Happy to review in exchange. Hi, we have the opposite situation with calibre: it builds fine in rawhide with podofo-0.10, but does not compile against podofo-0.9.8 in F39. I just built calibre-7.2.0 in rawhide, and would like to do the same update for F39. Is there any chance you can also push podofo-0.10.x + podofo-compat-0.9.x also to F39? I think that'd be OK, because we can keep the packages that need the old version building, possibly after adjusting some BuildRequires line. Bump in the new year. PTAL. Hi Zbyszek I already took care of this: https://koji.fedoraproject.org/koji/buildinfo?buildID=2334737 Sandro -- ___ 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: upgrade to shapelib-1.6.0
Hello I'll be updating to shapelib-1.6.0 in the coming days, which carries a soname bump from libshp.so.2 to libshp.so.4, rebuilding the following dependent packages: cloudcompare cyrus-imapd gdl gpsbabel marble plplot xastir Thanks and happy holidays Sandro -- ___ 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: armadillo soname bump to version 12
On 22.12.23 10:41, Florian Weimer wrote: * Ryan Curtin: Hello there, I plan to bump the major version of the Armadillo linear algebra library to version 12 for rawhide next week; this will be an ABI/API change. I will rebuild the package and its dependencies (looks like gdal and mlpack only) in the side tag 'f40-build-side-79101'. Looks like this was partially merged into rawhide? | Failed to resolve the transaction: | No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans-Bold.ttf | No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf | Problem: package gdal-devel-3.8.2-1.fc40.x86_64 requires libgdal.so.34()(64bit), but none of the providers can be installed | - package gdal-devel-3.8.2-1.fc40.x86_64 requires gdal-libs(x86-64) = 3.8.2-1.fc40, but none of the providers can be installed | - cannot install the best candidate for the job | - nothing provides libarmadillo.so.10()(64bit) needed by gdal-libs-3.8.2-1.fc40.x86_64 Seen while trying to rebuild mapserver with unchanged sources. There is gdal-3.8.2-2.fc40 which is correctly built against libarmadillo.so.12 Sandro -- ___ 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: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
On 17.12.23 17:44, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 15, 2023 at 11:56:56PM +0200, Sandro Mani wrote: Hi I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test builds here [1], according to which scribus, vfrnav and pdfsign currently do not support podofo-0.10.x. To keep these functional, I've prepared a podofo-compat package with the previous 0.9.x library. The review request is here [2]. Happy to review in exchange. Hi, we have the opposite situation with calibre: it builds fine in rawhide with podofo-0.10, but does not compile against podofo-0.9.8 in F39. I just built calibre-7.2.0 in rawhide, and would like to do the same update for F39. Is there any chance you can also push podofo-0.10.x + podofo-compat-0.9.x also to F39? I think that'd be OK, because we can keep the packages that need the old version building, possibly after adjusting some BuildRequires line. Hi I've done so: https://bodhi.fedoraproject.org/updates/FEDORA-2023-e8f9188f10 Sandro -- ___ 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: gdal-3.8.0 coming to rawhide
This is now done, there are two unrelated failures: - gazebo: graphviz 9.x incompatibility - vfrnav: broken build dependencies (nothing provides libsundials_sunlinsolklu.so.4.6.1()(64bit) needed by octave-6:8.4.0-1.fc40.x86_64 from build) Sandro On 15.11.23 11:42, Sandro Mani wrote: Hi I'll be building gdal-3.8.0 in the f40-build-side-77750 side tag. It carries a soname bump, and I'll rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo Thanks Sandro ___ 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: gdal-3.8.0 coming to rawhide
Hi I'll be building gdal-3.8.0 in the f40-build-side-77750 side tag. It carries a soname bump, and I'll rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo Thanks Sandro ___ 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: broken dependencies due to gdal-3.6.2-7.fc37
On 07.11.23 12:17, Sandro Mani wrote: Hi Due to an unfortunate oversight of an incorrect branch merge a couple of months ago, a recently backported security fix caused an unwanted gdal soname bump in F37, due to an update from the 3.5.x series to the 3.6.x series. I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't rebuild any dependencies in the meantime, as the new package will bring back the previous soname. The new update is now pushed to testing: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c0ac8784e8 ___ 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: broken dependencies due to gdal-3.6.2-7.fc37
Hi Due to an unfortunate oversight of an incorrect branch merge a couple of months ago, a recently backported security fix caused an unwanted gdal soname bump in F37, due to an update from the 3.5.x series to the 3.6.x series. I'm preparing a gdal-3.6.2-8.really3.5.3.fc37 to address this, please don't rebuild any dependencies in the meantime, as the new package will bring back the previous soname. Apologies for the troubles. Sandro ___ 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: PEP-668, cmake FindPython Python_SITEARCH and rpm_prefix
On 25.10.23 02:20, Neal Gompa wrote:
On Tue, Oct 24, 2023 at 5:18 PM Sandro Mani wrote:
Hi
Since some time, Fedora's cmake FindPython will return
Python_SITEARCH=/usr/local/lib64/pythonX.Y/site-packages, which results in
possible failure to find python libraries below the system site packages dir
(aka shipped by RPMs). A workaround(?) is to call
EXECUTE_PROCESS(COMMAND ${Python_EXECUTABLE} -c "import sysconfig;print(sysconfig.get_path(\"platlib\",
\"rpm_prefix\"), end=\"\")" OUTPUT_VARIABLE Python_SITEARCH)
and such workarounds are starting to appear in applications [1]. Any opinions
on whether this is indeed the best way to handle the issue, whether Fedoras
FindPython needs fixing, or whether there already is a cleaner solution?
This needs to be fixed in FindPython.cmake to detect whether cmake is
running in a package build environment to get the correct path.
Though this also concerns the case where I build the application locally
say for development, not necessarily just when building the rpm?
Shouldn't FindPython just always return the rpm_prefix paths, since you
are most-likely attempting to find the system python?
Sandro
___
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
PEP-668, cmake FindPython Python_SITEARCH and rpm_prefix
Hi
Since some time, Fedora's cmake FindPython will return
Python_SITEARCH=/usr/local/lib64/pythonX.Y/site-packages, which results
in possible failure to find python libraries below the system site
packages dir (aka shipped by RPMs). A workaround(?) is to call
EXECUTE_PROCESS(COMMAND ${Python_EXECUTABLE} -c "import
sysconfig;print(sysconfig.get_path(\"platlib\", \"rpm_prefix\"),
end=\"\")" OUTPUT_VARIABLE Python_SITEARCH)
and such workarounds are starting to appear in applications [1]. Any
opinions on whether this is indeed the best way to handle the issue,
whether Fedoras FindPython needs fixing, or whether there already is a
cleaner solution?
Thanks
Sandro
[1] https://github.com/qgis/QGIS/pull/55039/files
___
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
Review request: python-simple-websocket
Hi python-socketio / python-engineio grew a new dependency on python-simple-websocket. I've submitted it for review at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2244587. Happy to review in exchange. Thanks Sandro ___ 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: Why does mingw-filesystem depend on mingw-binutils-generic?
Hi I'd say, as least as it stands now, this is because the dependency generators require mingw-objdump, see mingw.req [1]. Sandro [1] https://src.fedoraproject.org/rpms/mingw-filesystem/blob/rawhide/f/mingw.req On 30.08.23 10:30, Richard W.M. Jones wrote: https://src.fedoraproject.org/rpms/virt-v2v/pull-request/2 mingw-binutils-generic contains a random selection of binaries: $ rpm -ql mingw-binutils-generic /usr/bin/mingw-nm /usr/bin/mingw-objcopy /usr/bin/mingw-objdump /usr/bin/mingw-strip For unclear reasons, mingw32-filesystem depends on mingw-binutils-generic since this commit: https://src.fedoraproject.org/rpms/mingw-filesystem/c/de21385695148a980c81d68396ffc883988fce74 but it's not explained why. It seems off that the base "-filesystem" package should need these binaries (why these are not others? why at all?) It seems like mingw-binutils-generic was added back in 2012 when we added 64 bit support, and contains "Utilities which are needed for both the Win32 and Win64 toolchains". Which is fair enough but it's unclear why they need to be in the filesystem dependencies. Rich. ___ 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: Request to review a MinGW subpackges in libsodium
Hi
Please check out [1] for a sample unified native/mingw spec with
autotools build. Specific remarks:
- Add %{?mingw_debug_package}
- Explicit BR on mingw-binutils probably unnecessary
- Try %global _configure ../configure instead of cloning the entire
source tree
- Add %mingw_debug_install_post
Sandro
[1]
https://src.fedoraproject.org/rpms/gtkspell3/blob/rawhide/f/gtkspell3.spec
On 21.08.23 15:17, Marián Konček wrote:
I opened a PR adding mingw subpackages to libsodium according to my
best knowledge (which is not too large related to mingw packaging):
https://src.fedoraproject.org/rpms/libsodium/pull-request/3
I talked with the maintainer and it could be accepted, but I would
like someone more experienced from
https://fedoraproject.org/wiki/MinGW to take a look and tell me if i
missed some simplifications.
Thanks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
This is now done. Sandro On 15.08.23 23:56, Sandro Mani wrote: Hi I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test builds here [1], according to which scribus, vfrnav and pdfsign currently do not support podofo-0.10.x. To keep these functional, I've prepared a podofo-compat package with the previous 0.9.x library. The review request is here [2]. Happy to review in exchange. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/podofo-0.10.1/builds/ [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2232243 ___ 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
Planning to update to podofo-0.10.1 + review request for podofo-compat for legacy 0.9.x library
Hi I'm planning to update to podofo-0.10.1 in rawhide. I did a series of test builds here [1], according to which scribus, vfrnav and pdfsign currently do not support podofo-0.10.x. To keep these functional, I've prepared a podofo-compat package with the previous 0.9.x library. The review request is here [2]. Happy to review in exchange. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/podofo-0.10.1/builds/ [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2232243 ___ 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: Update to geos-3.12.0 in rawhide
On 06.07.23 16:02, Remi Collet wrote: Le 06/07/2023 à 15:53, Sandro Mani a écrit : Hi I'm updating to geos-3.12.0 in rawhide, which carries a soname bump. I'm building geos-3.12.0 in f39-build-side-69654 and will rebuild the following dependencies: osgearth vfrnav mingw-osgearth It seems you miss some, On Fedora 37 # dnf repoquery --whatrequires 'libgeos_c.so.1()(64bit)' GMT-0:6.4.0-2.fc37.x86_64 R-rgeos-0:0.5.9-1.fc37.x86_64 gdal-libs-0:3.5.2-1.fc37.x86_64 geos-devel-0:3.11.0-2.fc37.x86_64 grass-0:8.2.1-1.fc37.x86_64 grass-libs-0:8.2.1-1.fc37.x86_64 librttopo-0:1.1.0-10.fc37.x86_64 libspatialite-0:5.0.1-15.fc37.x86_64 mapserver-libs-0:7.6.4-19.fc37.x86_64 osgearth-0:3.2-10.fc37.x86_64 php-geos-0:1.0.0-24.fc37.x86_64 player-0:3.1.0-41.fc37.x86_64 postgis-0:3.2.2-1.fc37.x86_64 postgis-client-0:3.2.2-1.fc37.x86_64 postgis-gui-0:3.2.2-1.fc37.x86_64 postgis-upgrade-0:3.2.2-1.fc37.x86_64 python3-basemap-0:1.3.7-1.fc37.x86_64 python3-cartopy-0:0.21.1-1.fc37.x86_64 python3-shapely-0:1.8.5.post1-1.fc37.x86_64 qgis-0:3.26.1-2.fc37.x86_64 spatialite-gui-0:2.1.0-0.14.beta1.fc37.x86_64 I only listed the ones built against the C++ api, the C api remains stable and I don't believe a rebuild is necessary for those? Sandro ___ 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: Update to geos-3.12.0 in rawhide
Hi I'm updating to geos-3.12.0 in rawhide, which carries a soname bump. I'm building geos-3.12.0 in f39-build-side-69654 and will rebuild the following dependencies: osgearth vfrnav mingw-osgearth Thanks Sandro ___ 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: cgnslib-4.4.0 update
Hi I'm updating to cgnslib-4.4.0 in rawhide, which carries a soname bump. I've built cgnslib-4.4.0 in f39-build-side-69646 and will rebuild the following dependencies: gmsh paraview vtk Thanks Sandro ___ 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
Review requests: gtksourceviewmm3, mingw-qt6-qtlocation
Hi I'd appreciate a review of the following packages: https://bugzilla.redhat.com/show_bug.cgi?id=2215251 - gtksourceviewmm3 - Review to revive retired package, which I need as a dependency for gimagereader https://bugzilla.redhat.com/show_bug.cgi?id=2211959 - mingw-qt6-qtlocation - Review to revive retired package, this qt module was dropped upstream in the qt-6.3.x series, but re-introduced in qt-6.5.1 Happy to review in exchange. Thanks Sandro ___ 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: gdal-3.7.0 coming to rawhide
On 12.05.23 15:48, Orion Poplawski wrote: Well, not completely - my paraview build in the side tag has not yet completed: https://koji.fedoraproject.org/koji/taskinfo?taskID=101035225 Do I submit a separate update for that once it is done? Whops sorry, got over-excited seeing the x86_64 build succeed - possibly I will be able to submit the tag with just that one build as an update? ___ 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: gdal-3.7.0 coming to rawhide
On 11.05.23 05:42, Sandro Mani wrote: Hi I'm preparing the gdal-3.7.0 update which carries a soname bump. Il build it in the f39-build-side-67536 side-tag, and rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes saga qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo This is now done, all completed except for: vfrnav: preexisting FTBFS mingw-opencv: mingw related issue, need to investigate Sandro ___ 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: gdal-3.7.0 coming to rawhide
Hi I'm preparing the gdal-3.7.0 update which carries a soname bump. Il build it in the f39-build-side-67536 side-tag, and rebuild the following dependencies: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes saga qmapshack PDAL ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv osgearth qgis gazebo Sandro ___ 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: nodejs broken?
On 02.05.23 11:24, Iñaki Ucar wrote:
On Tue, 4 Apr 2023 at 16:23, Stephen Gallagher wrote:
On Tue, Apr 4, 2023 at 9:45 AM Sérgio Basto wrote:
On Thu, 2023-03-16 at 11:19 -0400, Stephen Gallagher wrote:
On Wed, Mar 15, 2023 at 1:16 PM Jerry James
...
I found a problem related with yarnpkg rpm, the macro % __find_requires
finds that yarn scripts uses and needs /usr/bin/node , which is added
to the requires of rpm [1] and this makes yarnpkg pull nodejs (18) even
when nodejs20 is installed .
To avoid this rpm automatic requires, we may add to yarnpkg.spec [2]
[2]
%global __script_requires %{nil}
[1]
dnf repoquery yarnpkg --available --requires -q
/usr/bin/bash
/usr/bin/node
/usr/bin/sh
I'm not sure what you think is a bug here? Do you think `yarnpkg`
should use *any* nodejs version that's installed? The whole point of
the way this is broken down is that we have a default version (18, in
this case) with the option to install 16 and 20 in parallel, but you
have to do extra work if you want to *use* those non-default versions
(such as patching shebang lines).
This is broken again in rawhide:
$ dnf -qy install yarnpkg
$ ll /usr/bin/node*
lrwxrwxrwx. 1 root root 7 Apr 28 00:00 /usr/bin/node -> node-20
-rwxr-xr-x. 1 root root 28272 Apr 28 00:00 /usr/bin/node-20
lrwxrwxrwx. 1 root root39 Mar 21 00:00 /usr/bin/nodejs-yarn ->
../lib/node_modules_19/yarn/bin/yarn.js
If yarn should be pinned to a node version, please rebuild yarn when
there's a major version change. And it would be nice if there's a
mechanism to detect such a breakage. I.e. a nodejs(abi) version or
something like that.
AFAICS nodejs is generally broken in rawhide (both nodejs20 and
nodejs18), i.e. just
$ node
>
Segmentation fault (core dumped)
gdb:
Thread 3 "node" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x72ffe6c0 (LWP 1565850)]
0x757db195in
v8::internal::compiler::SpecialRPONumberer::ComputeAndInsertSpecialRPO(v8::internal::compiler::BasicBlock*,
v8::internal::compiler::BasicBlock*)() from /lib64/libnode.so.115
Sandro
___
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
How to handle updates with large python dependency chains?
Hi I'm working on packaging pgadmin4-7.0, which bumped several python dependencies, requiring multiple updates of existing fedora packages. I started by building newer version of all direct dependencies in copr [1], and then investigating the dependencies trees of the direct dependencies. So here come the questions: - It is kinda hard to know which python dependencies are really affected. What is the best practice? Just limiting to checking those which have a version-constrained dependency which would not be satisfied by the update? - So far I've filed multiple PRs for the various dependencies, but it is fairly unrealistic to have these all processed in a timely manner. I'm assuming the best way forward is a self-contained change? Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/pgadmin4-7.0/builds/ ___ 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
I've taken the following: mingw-gstreamer1 mingw-gstreamer1-plugins-base python-flask-login I'd also pick up the following if the gtk maintainers are not interested: gtksourceviewmm3 Sandro ___ 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: tesseract-5.3.0 landing in rawhide with soname bump
On 06.04.23 23:43, Adam Williamson wrote: On Thu, 2023-04-06 at 23:26 +0200, Sandro Mani wrote: On 06.04.23 22:37, Miro Hrončok wrote: On 23. 12. 22 16:00, Sandro Mani wrote: Hi I'll be landing tesseract 5.3.0 in rawhide, building it in the f38-build-side-61405 side tag, along with the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract zathura-pdf-mupdf Thanks Sandro Hey Sandro, a new soname bump landed recently: https://src.fedoraproject.org/rpms/tesseract/c/cc010cab233fe1da5f614d7dc0afde3a5e2e8d2d?branch=rawhide Will you please also handle the rebuilds? E.g. https://bugzilla.redhat.com/show_bug.cgi?id=2185098 https://bugzilla.redhat.com/show_bug.cgi?id=2185090 https://bugzilla.redhat.com/show_bug.cgi?id=2185099 Apologies for this, evidently I failed somehow in my repoquery check. Will fix right away. To be clear, Sandro already was rebuilding dependencies, but just missed some. The tesseract build was done on a side tag and the update is https://bodhi.fedoraproject.org/updates/FEDORA-2023-3e0758623d . As of now it has only tesseract, ffmpeg and opencv builds, it needs the others from the list. Should now be okay. I had executed dnf repoquery --whatrequires libtesseract.so.5.3.0 rather than dnf repoquery --whatrequires libtesseract.so.5.3.0* ... ___ 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: tesseract-5.3.0 landing in rawhide with soname bump
On 06.04.23 22:37, Miro Hrončok wrote: On 23. 12. 22 16:00, Sandro Mani wrote: Hi I'll be landing tesseract 5.3.0 in rawhide, building it in the f38-build-side-61405 side tag, along with the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract zathura-pdf-mupdf Thanks Sandro Hey Sandro, a new soname bump landed recently: https://src.fedoraproject.org/rpms/tesseract/c/cc010cab233fe1da5f614d7dc0afde3a5e2e8d2d?branch=rawhide Will you please also handle the rebuilds? E.g. https://bugzilla.redhat.com/show_bug.cgi?id=2185098 https://bugzilla.redhat.com/show_bug.cgi?id=2185090 https://bugzilla.redhat.com/show_bug.cgi?id=2185099 Apologies for this, evidently I failed somehow in my repoquery check. Will fix right away. Sandro ___ 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
Review requests: python-flask-mailman, python-flask-mongoengine, mingw-gsettings-desktop-schemas
Hi I'd appreciate review of the following packages: Needed for updating python-flask-security-too (https://bugzilla.redhat.com/show_bug.cgi?id=2171671): - python-flask-mailman: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2184588 - python-flask-mongoengine: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2184590 Needed for updating mingw-glib-networking: - mingw-gsettings-desktop-schemas: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2184592 Should all be pretty straight forward reviews. Happy to review in exchange. Thanks Sandro ___ 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
Review request: perl-String-License, perl-Test2-Tools-Command
Hi licensecheck-3.3.8 once again grew some new dependencies, reviews here: perl-Test2-Tools-Command - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2165335 perl-String-License - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2165336 Happy to review in exchange. Thanks Sandro ___ 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
Review request: mingw-python-pyproject-hooks
Hi I'd need mingw-python-pyproject-hooks reviewed: it is required by mingw-python-build, which is currently FTI and hence preventing any mingw-python-* package from getting built. Review is here: https://bugzilla.redhat.com/show_bug.cgi?id=2163339 Should be a very easy one. Happy to review in exchange. Thanks Sandro ___ 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
Review requests: perl-Feature-Compat-Class, perl-Feature-Compat-Try (needed for licensecheck update)
Hi licensecheck-3.3.1 grew two new dependencies, reviews here: perl-Feature-Compat-Class: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2158741 perl-Feature-Compat-Try: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2158742 Happy to review in exchange. Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: mingw-pcre (was: Re: Orphaned packages looking for new maintainers)
On 04.01.23 14:16, Richard W.M. Jones wrote: On Mon, Dec 19, 2022 at 04:43:23PM +0100, Miro Hrončok wrote: mingw-pcreorphan 3 weeks ago Note this is PCRE not PCRE2. Lots of packages, mainly Qt related, seem to depend on it, and they should move to PCRE2 (packaged as mingw-pcre2), although this is not a straightforward change. I suggest we leave this as an orphan, and encourage packages to move as soon as possible. There should be no consumers of mingw-pcre left as I believe I've already moved them all to pcre2? A quick repoquery --whatrequires check for the mingw-pcre dlls shows no matches. Sandro ___ 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: Planning to start unifying native and mingw packages
On 01.01.23 21:48, Jonathan Billings wrote:
On Wed, Aug 24, 2022 at 02:49:21PM +0100, Daniel P. Berrangé wrote:
I've done the same with all the mingw packages I maintained just
before Fedora 37 branched. So the following native packages now
just contain mingw sub-RPMs:
libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
I don't know if this is a bug in the spec or in the %find_lang RPM
macro, but I've noticed that these packages have files out of the
mingw sys-root included in the non-mingw packages:
$ find /usr/*mingw32/ -type f | xargs rpm -qf | sort -u
gvnc-1.3.0-5.fc37.x86_64
gvncpulse-1.3.0-5.fc37.x86_64
libosinfo-1.10.0-4.fc37.x86_64
libvirt-glib-4.0.0-6.fc37.x86_64
osinfo-db-tools-1.10.0-4.fc37.x86_64
All the files in those packages look like:
/usr/{arch}-w64-mingw32/sys-root/mingw/share/locale/{lang}/LC_MESSAGES/{package}.mo
There's a thread on the users list about the existence of
/usr/i686-w64-mingw32/ and /usr/x86_64-w64-mingw32/ directories on
systems without any mingw* packages installed, and it looks like on my
system it's all due to the most recent commits to these packages to
include mingw subpackages.
I suspect the %find_lang macro's shell script
(/usr/lib/rpm/find_lang.sh) needs to know not to include the mingw
sysroot, or at least filter it out as part of the spec file %install.
That is how the files are getting included in the non-mingw subpackages.
They have: %files -n ... -f %{name}.lang in the %files section.
This should be fixed as of [1] (plus [2]). Simply rebuilding the
packages against a current mingw-filesystem should fix the issue.
[1]
https://src.fedoraproject.org/rpms/mingw-filesystem/c/846156c1bda9bcff98c850714fa5da688a55e66a?branch=rawhide
[2]
https://src.fedoraproject.org/rpms/mingw-filesystem/c/d897e0bb98731e5536c551be2cf401f1ced71138?branch=rawhide
___
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: tesseract-5.3.0 landing in rawhide with soname bump
Hi I'll be landing tesseract 5.3.0 in rawhide, building it in the f38-build-side-61405 side tag, along with the following dependent packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF qpdfview R-tesseract zathura-pdf-mupdf Thanks Sandro ___ 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
(Late) HEADS UP: qwt-6.2.0 landed in rawhide with soname bump
Hi I built qwt-6.2.0 two days ago but missed the fact that the Provides changed from to libqwt-qt5.so.6() to libqwt-qt5.so.6.2(). I'll proceed with rebuilding the following packages to fix the resulting broken dependencies: COPASI gazebo gnuradio qgis qsstv Apologies for the disruption. Sandro ___ 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: update to leptonica-1.83.0 in rawhide
Hi I'll be updating to leptonica-1.83.0, which brings a soname bump. I'll perform the build in the side tag f38-build-side-61349, rebuilding also the following dependencies: mupdf python-PyMuPDF tesseract zathura-pdf-mupdf Thanks Sandro ___ 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.
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? Thanks Sandro On 16.12.22 15:57, Sandro Mani wrote: Welcome! On 16.12.22 15:15, h-k...@hotmail.com wrote: Hello everyone This mail should serve as my self introduction to the devel community. I am a (soon to be) computer science graduate, that has been working in the Linux / open source world for about 6 years. I first started working as a python developer in the GIS (geographic information system) domain. After some time I also began to perform some system administration tasks. And before I knew I started to do a bit of everything. So to describe my current work, I do - Python development - System administration - Kubernetes administration (or whatever you want to call it) - A little bit of javascript - Devops (Automatic deployments via CI / CD pipelines, mainly using Gitlab CI) Oh, I also picked up rust a couple years ago and have been using it for Uni and private projects. Now the reason for why I want to get more involved in the Fedora package maintainer community is because I want to get a better understanding on how applications are packaged and distributed to end-users in a secure and stable manner. And from my experience, the best way to learn, is to get your hands dirty. Naturally, I also want to give back to the community, that has doing amazing work at developing Fedora and keeping everything working, and I want to become a part of it. In the last week, I have been reading a lot of documentation on RPM packaging and I have created my first package. I am currently looking for a sponsor to help me with my first package review: https://bugzilla.redhat.com/show_bug.cgi?id=2154124 This concludes my introduction and I hope this was not too much to read :D Best wishes Hussein K. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Hussein K.
Welcome! On 16.12.22 15:15, h-k...@hotmail.com wrote: Hello everyone This mail should serve as my self introduction to the devel community. I am a (soon to be) computer science graduate, that has been working in the Linux / open source world for about 6 years. I first started working as a python developer in the GIS (geographic information system) domain. After some time I also began to perform some system administration tasks. And before I knew I started to do a bit of everything. So to describe my current work, I do - Python development - System administration - Kubernetes administration (or whatever you want to call it) - A little bit of javascript - Devops (Automatic deployments via CI / CD pipelines, mainly using Gitlab CI) Oh, I also picked up rust a couple years ago and have been using it for Uni and private projects. Now the reason for why I want to get more involved in the Fedora package maintainer community is because I want to get a better understanding on how applications are packaged and distributed to end-users in a secure and stable manner. And from my experience, the best way to learn, is to get your hands dirty. Naturally, I also want to give back to the community, that has doing amazing work at developing Fedora and keeping everything working, and I want to become a part of it. In the last week, I have been reading a lot of documentation on RPM packaging and I have created my first package. I am currently looking for a sponsor to help me with my first package review: https://bugzilla.redhat.com/show_bug.cgi?id=2154124 This concludes my introduction and I hope this was not too much to read :D Best wishes Hussein K. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: split package cgnslib-common into ui and none-ui part
Hi Like so? https://koji.fedoraproject.org/koji/taskinfo?taskID=95082476 Sandro On 08.12.22 10:38, Marius Schwarz wrote: Hi all, the package "cgnslib-common" contains libs necessary to do some calculations i.e. Libreoffice Openshot, Shotcut etc. etc. It comes packed with some UI Apps, that look like something from the 80ties and are most likely never used as cgnslib-common is a just a dependency install and the apps are very special: /usr/share/applications/cgnscalc.desktop /usr/share/applications/cgnsnodes.desktop /usr/share/applications/cgnsplot.desktop /usr/share/applications/cgnsview.desktop /usr/share/applications/unitconv.desktop As I can image someone could still make use of them, I suggest to split the package into the ui and none-ui parts. This way, the depending apps are happy, and users do not get borrowed with apps they did not want and suddenly popped up on theire app panel. best regards, Marius Schwarz ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaned packages looking for new maintainers
Taking these mingw-dbus orphan 1 weeks ago mingw-qt5-qtquickcontrols orphan, smani 1 weeks ago mingw-xerces-c orphan 1 weeks ago Can take this if no-one else is interested (@Sergio Basto?) > docker-compose lsm5, orphan, ttomecek 1 weeks ago This one > enchant orphan 0 weeks ago is a dependency for gtkspell, which is dead and superseded by gtkspell3 and I'd be tempted to also let go. Dependencies are: emelfm2 gummi logjam ocaml-lablgtk perl-Gtk2-Spell pidgin purple-plugin_pack-pidgin sylpheed -- Sandro smilner: python-oauthlib, buildbot snits: tss2 spot: alure, python-requests-oauthlib, enchant, libbonoboui, libbonobo, ibus-table-others ssp: libgnome, enchant, libbonoboui, gtkhtml3, liboil, gconf-editor, libbonobo, ibus-table-others, libgnomeui stahnma: rubygem-syntax, rubygem-yard stefw: seahorse-nautilus steve: nqp, libgnome, gl-117, rakudo, libbonoboui, moarvm, libgnomeui stevetraylen: python-django-tastypie, python-argon2-cffi, python-requests-oauthlib stingray: enchant supakeen: python-argon2-cffi survient: holland tagoh: ibus-table-others tartare: libgnomeui, libgnome, libbonoboui tchaikov: python-isodate tdawson: rubygem-yard, rubygem-memcache-client, rubygem-ZenTest, python-multilib, rubygem-archive-tar-minitar, python-argon2-cffi tdecacqu: nvml terjeros: nvml thalman: python-requests-oauthlib than: amor, bluecurve-kde-theme, enchant thm: libbonobo, libbonoboui thofmann: bibtex2html thunderbirdtr: qconf tingping: enchant tlavocat: nvml tomegun: nvml tomh: mingw-xerces-c, mingw-pcre totol: python-argon2-cffi tpokorra: libgnomeui, libbonobo, libgnome, libbonoboui trb143: hunspell-kn ttomecek: python-dockerpty, docker-compose, python-multilib twaugh: python-multilib ueno: fcitx valtri: rubygem-yard vanessakris: mingw-xerces-c, mingw-pcre vascom: nvml, perl-Term-ShellUI, enchant virtmaint-sig: nvml vkmc: python-oauthlib vokac: libmacaroons vondruch: rubygem-yard vpavlin: biosdevname vpv: hunspell-kn vrutkovs: python-multilib wsato: ibus-table-others wwoods: nvml, python-multilib xavierb: perl-File-KeePass, perl-Term-ShellUI, ibus-table-others, python-requests-mock, ejabberd yaneti: perl-Test-POE-Server-TCP yanqiyu: kcm-fcitx, golang-github-fvbommel-sortorder, fcitx, fcitx-cloudpinyin, golang-github-containerd-stargz-snapshotter, fcitx-unikey, fcitx-m17n, golang-github-mitchellh-cli, golang-github-tonistiigi-rosetta, fcitx-chewing, fcitx-configtool, enchant, fcitx-fbterm, fcitx-sunpinyin, sunpinyin, fcitx-table-extra, fcitx-table-other, fcitx-hangul, golang-github-hanwen-fuse, fcitx-ui-light ykarel: python-requests-mock yunyings: tboot zaitcev: python-oauthlib zaneb: python-oauthlib zawertun: nvml zbyszek: nvml zuul: nvml, python-argon2-cffi ___ 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: moby-engine (also known as Docker) maintenance in Fedora
On 01.12.22 23:16, Sérgio Basto wrote: On Tue, 2022-11-29 at 19:31 +, Sérgio Basto wrote: On Tue, 2022-11-29 at 19:10 +0100, Sandro Mani wrote: Hi everyone, The moby-engine package [1] (also known as Docker) has been orphaned in Fedora and is looking for a new maintainer. The waiting period will soon be over and the package will be retired if nobody steps in. This means that the package will be unavailable starting with the next release of Fedora (Fedora 38) that should happen in approximately 5 to 6 months. If you are using this package and are interested in helping maintaining it, now is the time to come forward! I'm using docker for $dayjob and would be willing to help out a bit, but I will not be the main maintainer, as I don't feel comfortable taking such a huge package and lack the cycles for that. As I also heavily use docker for my dayjob, and I see that moby- engine is still unmaintained (and I guess a couple of days away from retirement), I intend to give it a shot to keep the package alive. I don't have expertise in this specific field beyond regular docker and docker-compose usage, so clearly help is very much appreciated. I'd proceed by taking the package by the end of the week if it still unmaintained at that point. I also would like keep moby-engine (also known as Docker) and I will help if you need . After analyze go packages, I think we got the same kind of problems of nodejs, which is, too many packages and each package has very few lines of code and make other packages have enormous number of dependencies . In conclusion to maintain it, we will spend a lot of time. I'm thinking for example docker should include all other specific deps like golang- github-containerd-* , golang-github-moby-* So we should try to solve this problem. I'm against this fragmentation of the packages, i.e. in packages guidelines allow may have different sources same package . I took moby-engine and fedora-dockerfiles because orphans [1] report alert for more than 6 weeks orphan Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: moby-engine (also known as Docker) maintenance in Fedora
Hi everyone, The moby-engine package [1] (also known as Docker) has been orphaned in Fedora and is looking for a new maintainer. The waiting period will soon be over and the package will be retired if nobody steps in. This means that the package will be unavailable starting with the next release of Fedora (Fedora 38) that should happen in approximately 5 to 6 months. If you are using this package and are interested in helping maintaining it, now is the time to come forward! I'm using docker for $dayjob and would be willing to help out a bit, but I will not be the main maintainer, as I don't feel comfortable taking such a huge package and lack the cycles for that. As I also heavily use docker for my dayjob, and I see that moby-engine is still unmaintained (and I guess a couple of days away from retirement), I intend to give it a shot to keep the package alive. I don't have expertise in this specific field beyond regular docker and docker-compose usage, so clearly help is very much appreciated. I'd proceed by taking the package by the end of the week if it still unmaintained at that point. Sandro ___ 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: gdal-3.6.0 landing in rawhide
On 14.11.22 17:22, Sandro Mani wrote: On 14.11.22 00:13, Sandro Mani wrote: This is done now and the side tag merged. Two packages failed to build: > python-rasterio which fails to build due to test failures, I'll investigate whether they are gdal related Reported at https://github.com/rasterio/rasterio/issues/2653 Fixed in python-rasterio-1.3.3-3.fc38___ 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: gdal-3.6.0 landing in rawhide
On 14.11.22 00:13, Sandro Mani wrote: This is done now and the side tag merged. Two packages failed to build: > python-rasterio which fails to build due to test failures, I'll investigate whether they are gdal related Reported at https://github.com/rasterio/rasterio/issues/2653 ___ 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: gdal-3.6.0 landing in rawhide
This is done now and the side tag merged. Two packages failed to build: python-rasterio which fails to build due to test failures, I'll investigate whether they are gdal related kealib which fails to build because it is incompatible with gdal-3.6.0, reported at https://github.com/ubarsc/kealib/issues/26 Sandro ___ 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: Scotch-7.0/PETSc-3.18.1 upgrade
On 12.11.22 12:19, Antonio Trande wrote: Hi Some time ago I've started working on updating to scotch-7.x, with some initial test builds here [1]. To finalize the update, I'd like to gather some opinions (potentially affected maintainers in CC): Hi all. Hi Sandro. PETSc is ready/tested for Scotch-7* with the release 3.18.1 They could be compiled in Rawhide now. Do you agree to syncronize the upgrades of these libraries and related dependencies? Hi Antonio Yes sure - I've just checked where I left off, I'd have this build [1] ready, with scotchmetis disabled by default. Let me know how you want to proceed. Thanks Sandro [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=94094209 ___ 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: gdal-3.6.0 landing in rawhide
Hi Markus Actually kealib fails to build [1] because OldSetGCPsFromNew and others were removed. Do you have any suggestions? Sandro [1]https://koji.fedoraproject.org/koji/buildinfo?buildID=2087861 On 12.11.22 12:06, Markus Neteler wrote: Hi Sandro, If you like you may enable the KEA driver which I recently added to rawhide: https://src.fedoraproject.org/rpms/kealib Best, Markus Sandro Mani schrieb am Sa., 12. Nov. 2022, 09:47: Hi I'll be updating to gdal-3.6.0 in rawhide in the f38-build-side-60042 side tag. I'll be rebuilding all affected packages: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes saga qmapshack PDAL osgearth ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv qgis gazebo Thanks Sandro ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-le...@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
HEADS UP: gdal-3.6.0 landing in rawhide
Hi I'll be updating to gdal-3.6.0 in rawhide in the f38-build-side-60042 side tag. I'll be rebuilding all affected packages: GMT mapserver liblas python-fiona postgis merkaartor R-rgdal bes saga qmapshack PDAL osgearth ncl vfrnav python-rasterio vtk paraview kealib OpenSceneGraph cloudcompare grass mapnik opencv mingw-opencv qgis gazebo Thanks Sandro ___ 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: Review requests: mingw-python-pip, mingw-python-wheel, mingw-pyproject-rpm-macros
Hi I'd still appreciate a review of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136236 - mingw-python-flit-core It is the last dependency required to finish the effort of landing mingw-python-3.11 in rawhide. Thanks! Sandro On 19.10.22 19:32, Sandro Mani wrote: Hi Based on the discussion in #2134021 (mingw-pyproject-rpm-macros review), I've abbandoned the pyproject approach and instead switched to python-build + python-installer. For this, I'd need the following new packages reviewed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136235 - mingw-python-build https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136236 - mingw-python-flit-core https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136237 - mingw-python-installer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136238 - mingw-python-pep517 Happy to review in exchange. Thanks! Sandro On 12.10.22 09:27, Sandro Mani wrote: Hi To bring the mingw python build macros on par with the native python package, I'd need the following reviewed: * mingw-python-pip: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134019 * mingw-python-wheel: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134020 * mingw-pyproject-rpm-macros: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134021 They are all pretty trivial specfiles. I'm test-building the entire mingw-python package set against these new macros and with python-3.11 here [1]. Happy to review in exchange. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-python3-3.11/builds/ ___ 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: Review requests: mingw-python-pip, mingw-python-wheel, mingw-pyproject-rpm-macros
Hi Based on the discussion in #2134021 (mingw-pyproject-rpm-macros review), I've abbandoned the pyproject approach and instead switched to python-build + python-installer. For this, I'd need the following new packages reviewed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136235 - mingw-python-build https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136236 - mingw-python-flit-core https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136237 - mingw-python-installer https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2136238 - mingw-python-pep517 Happy to review in exchange. Thanks! Sandro On 12.10.22 09:27, Sandro Mani wrote: Hi To bring the mingw python build macros on par with the native python package, I'd need the following reviewed: * mingw-python-pip: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134019 * mingw-python-wheel: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134020 * mingw-pyproject-rpm-macros: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134021 They are all pretty trivial specfiles. I'm test-building the entire mingw-python package set against these new macros and with python-3.11 here [1]. Happy to review in exchange. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-python3-3.11/builds/ ___ 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
Review requests: mingw-python-pip, mingw-python-wheel, mingw-pyproject-rpm-macros
Hi To bring the mingw python build macros on par with the native python package, I'd need the following reviewed: * mingw-python-pip: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134019 * mingw-python-wheel: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134020 * mingw-pyproject-rpm-macros: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2134021 They are all pretty trivial specfiles. I'm test-building the entire mingw-python package set against these new macros and with python-3.11 here [1]. Happy to review in exchange. Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-python3-3.11/builds/ ___ 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: Planning to retire mkdocs, python-mkdocs-redirects
mkdocs and python-mkdocs-redirects are now retired for rawhide and f37. Sandro On 16.09.22 01:56, Ben Beasley wrote: I support this plan, and I will retire mkdocs-markdownextradata-plugin as well. – Ben Beasley (FAS music) On Thu, Sep 15, 2022, at 4:14 AM, Sandro Mani wrote: Hi I'm planning to retire mkdocs and python-mkdocs-redirects the coming weekend. mkdocs is currently FTI in F37 and F38. The reason is incompatibility with python-markdown-3.4.x, which upstream will not address in the immediate future [1]. Given that mkdocs is a leaf package and no other package depends on it (except for its plugins), pip + virtualenv is the better choice for users. The only packages depending on mkdocs are python-mkdocs-redirects, and mkdocs-markdownextradata-plugin (cc @music). Thanks Sandro [1] https://github.com/mkdocs/mkdocs/issues/2892#issuecomment-1200518008 ___ 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
Planning to retire mkdocs, python-mkdocs-redirects
Hi I'm planning to retire mkdocs and python-mkdocs-redirects the coming weekend. mkdocs is currently FTI in F37 and F38. The reason is incompatibility with python-markdown-3.4.x, which upstream will not address in the immediate future [1]. Given that mkdocs is a leaf package and no other package depends on it (except for its plugins), pip + virtualenv is the better choice for users. The only packages depending on mkdocs are python-mkdocs-redirects, and mkdocs-markdownextradata-plugin (cc @music). Thanks Sandro [1] https://github.com/mkdocs/mkdocs/issues/2892#issuecomment-1200518008 ___ 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
Review request: python-qt6
Hi I've put up python-qt6 for review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2124098 Happy to review in exchange. Thanks Sandro ___ 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: Planning to start unifying native and mingw packages
On 03.09.22 17:10, Richard Shaw wrote: I'm trying to migrate fltk right now and running into an issue: Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64 RPM build warnings: RPM build errors: error: Could not open %files file /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No such file or directory Building the mingw packages seems to be interfering with the native build. Can you point to the SPEC? Sandro ___ 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: Planning to start unifying native and mingw packages
On 01.09.22 17:18, Richard Shaw wrote:
I'd like to unify fltk but there are a couple of things I'm still
unclear about...
1. If I build the x86_64 package locally via fedpkg or mock, will it
build both the linux and mingw artifacts by default?
Unless you have any specific %ifarch etc, yes.
2. Since mingw packages are considered "noarch" in infrastructure, I
assume there's some magic to prevent arches other than x86_64 from
attempting to build the mingw packages?
Not really, but if builders on separate arches produce different
artifacts for the noarch packages, the build will fail with a
corresponding message like "package XXX built differently on arches YYY"
I would like some clear documentation, that if I'm troubleshooting
either the x86_64 or mingw builds, that it's trivial to disable the
one I'm not working on to speed up build iterations.
You can add
%bcond_without mingw
wrap the %package, %files, and portions inside %build and %install with
%if %{with mingw}
...
%endif
and if you'd like to disable the mingw build, just change the bcond to
%bcond_with mingw
HTH
Sandro
___
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: Planning to start unifying native and mingw packages
On 26.08.22 05:30, Michael Cronenworth wrote:
On 8/25/22 11:42 AM, Sandro Mani wrote:
You might also want to add the mingw debuginfo packages to those.
Ah, thanks. I'm used to the debuginfo packages being automatically
added thanks to %{mingw_package_header}.
I wonder if we could have the install macros updated to handle this in
a native package scenario.
Would be nice, it's IMO the only "ugly" part of unification that remains.
Sandro
___
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: Planning to start unifying native and mingw packages
On 25.08.22 18:40, Michael Cronenworth wrote: On 8/25/22 1:33 AM, Marián Konček wrote: I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? FAudio vkd3d You might also want to add the mingw debuginfo packages to those. Sandro ___ 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: Planning to start unifying native and mingw packages
On 25.08.22 08:33, Marián Konček wrote: I noticed this thread, I develop a personal project where I use about 10 C libraries, I noticed that "glfw", "libsodium" and "libevent" do not have their corresponding mingw packages. I was considering trying to package them but unifying them with the native packages would be better. Of course, this would put more pressure on the maintainers. I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration? Yes, quite a few actually, to list the ones I adapted: eigen3 enchant2 freeimage gdal GeographicLib geos giflib gtkspell3 gtkspellmm30 jxrlib leptonica libgeotiff libimagequant libkml librttopo libspatialite libwebp openjpeg2 OpenSceneGraph osgearth podofo proj python-pillow qtspell shapelib svg2svgt tesseract uriparser Sandro ___ 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: tesseract-5.2.0 coming to rawhide
On 08.07.22 09:46, Sandro Mani wrote: Hi I'll update to tesseract-5.2.0 in rawhide, and rebuild affected packages as listed below. I'll do the work in the side tag f37-build-side-54886. Done now, all build succeeded. Sandro ___ 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
HEADS UP: tesseract-5.2.0 coming to rawhide
Hi I'll update to tesseract-5.2.0 in rawhide, and rebuild affected packages as listed below. I'll do the work in the side tag f37-build-side-54886. Thanks Sandro --- Affected packages: ffmpeg gimagereader mupdf opencv python-PyMuPDF R-tesseract zathura-pdf-mupdf ___ 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: Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide
On 20.06.22 12:11, Michael J Gruber wrote: Hi I've now merged the side tag. Remarks: ... - python-PyMuPDF test fail due to a corrupted double-linked list assertion. I've disabled the test for now, and will investigate further. - python-fiona test fail due to a segmentation fault. I've disabled the test for now, and will investigate further. Has there been any progress in the investigation? That corrupted double-linked list in the test suite occurs only on rawhide and only since some larger side-tags merged. Disabling the test suite permanently is not a god thing if we think about the py3.11 rebuild, for example, as well as the upcoming update for mupdf 1.20.0. That issue has some Heisenbug flavor, by the way, and typically shows up on 50% of the archs only (but not with a reliable pattern). It does not show up on f36. Since we cannot work with f37 chroot from before the side-tag merge any more, I tried with F36 in copr and adding (rebuilding) F37 package versions from the side-tag one-by-one to narrow down the issue: https://copr.fedorainfracloud.org/coprs/mjg/PyMuPDF-corruption/ (The f37 fails are the expected ones) Unfortunately, python-pillow didn't build on s390x (neither on F37 nor F36), and I don't want to exclude even more arches in the testing ground. Have you faired better? Unfortunately not. I had looked into it and despite a rawhide koji i686 build pretty reliably failing, I was not able to reproduce the issue locally in a i686 rawhide chroot. I've looked into it again now and the behavior so far is still the same... ___ 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: Review request: ssr - SimpleScreenRecorder, a screen recorder for Linux
On 13.06.22 16:22, Artur Frenszek-Iwicki wrote: SSR is available in RPM Fusion under the name "simplescreenrecorder", so you may want to coordinate this with the Fusion maintainer - maybe do something similar to Audacity and Chromium, where the Fedora package is named "foobar" and the RPM Fusion one is "foobar-freeworld". Oh ups missed it, I had only checked ssr, thanks for the heads up. FWIW, freeworld vs non-freeworld shouldn't actually be necessary here AFAICT, as ssr will just pick up the available ffmpeg library, whether it's the Fedora ffmpeg-free or the rpmfusion one. In any case I'll close the request then, and leave it to the rpmfusion maintainer (CCed) to decide whether to move it to Fedora proper. Thanks Sandro ___ 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
Review request: ssr - SimpleScreenRecorder, a screen recorder for Linux
Hi Now that there is ffmpeg in Fedora, I'd like to add ssr [1], a useful screen recording app similar to RecordMyDesktop back in the days, to the repos. Review is here: https://bugzilla.redhat.com/show_bug.cgi?id=2096304 It's a simple C++/CMake/Qt application. Happy to review in exchange. Thanks Sandro [1] https://github.com/MaartenBaert/ssr/ ___ 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
Thoughts on updating to scotch-7.x
Hi Some time ago I've started working on updating to scotch-7.x, with some initial test builds here [1]. To finalize the update, I'd like to gather some opinions (potentially affected maintainers in CC): - Should metis get retired? Scotch has a scotchmetis compatibility library which is advertised as a faster drop-in replacement for metis, and indeed ships a metis.h which would conflict with the one from the original metis package. - Should I be adding 64-bit index builds for i686? There is a metis64 package, but since i686 is expected to go away soonish, is it worth the effort? This is of interest to petsc which currently BRs metis64-devel. Side note: I don't really recall how I ended up maintaining scotch, but if someone who is actively using the package is willing to step up and (co-)maintain it, please let me know! Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/scotch-7.0.0 ___ 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: Thoughts on updating to scotch-7.x
(apparently the -ow...@fedoraproject.org mails don't work anymore?) On 22.05.22 20:57, Sandro Mani wrote: Hi Some time ago I've started working on updating to scotch-7.x, with some initial test builds here [1]. To finalize the update, I'd like to gather some opinions (potentially affected maintainers in CC): - Should metis get retired? Scotch has a scotchmetis compatibility library which is advertised as a faster drop-in replacement for metis, and indeed ships a metis.h which would conflict with the one from the original metis package. - Should I be adding 64-bit index builds for i686? There is a metis64 package, but since i686 is expected to go away soonish, is it worth the effort? This is of interest to petsc which currently BRs metis64-devel. Side note: I don't really recall how I ended up maintaining scotch, but if someone who is actively using the package is willing to step up and (co-)maintain it, please let me know! Thanks Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/scotch-7.0.0 ___ 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: Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide
Hi I've now merged the side tag. Remarks: - opencv failed to build due to noarch -doc subpackage building differently on different arches. This caused by the intel_va sample only being included on x86 arches. I've made the -doc subpackge arched to solve this. - python-PyMuPDF test fail due to a corrupted double-linked list assertion. I've disabled the test for now, and will investigate further. - python-fiona test fail due to a segmentation fault. I've disabled the test for now, and will investigate further. - gazebo fails to build due to "cannot convert 'ALCdevice*' to 'ALCdevice_struct*' in assignment", which looks like an openal-soft-1.21 incompatibility. Possibly updating gazebo from the currently packaged v10.1.0 to current upstream version 11.10.2 might help. Sandro On 20.05.22 22:42, Sandro Mani wrote: Hi I'll build openjpeg2-2.5.0 and gdal-3.5.0 for rawhide in the side tag f37-build-side-53899. I've switched gdal to the new cmake based build, and at the same time merged the mingw package with the native one. I'll rebuild affected packages as listed below. Thanks Sandro --- lizams bes blender cloudcompare compat-ffmpeg4 darktable dcm2niix eccodes efl engauge-digitizer ffmpeg freeimage gazebo gdal gdcm geeqie ghostscript gimp GMT gpac grass gstreamer1-plugins-bad-free ImageMagick liblas librasterlite2 mapnik mapserver merkaartor mingw-freeimage mingw-gstreamer1-plugins-bad-free mingw-opencv mingw-poppler mtpaint mupdf ncl opencv OpenImageIO OpenSceneGraph openslide osgearth paraview PDAL poppler postgis python-fiona python-pillow python-PyMuPDF python-rasterio qgis qmapshack qsstv R-rgdal saga vfrnav vips vtk webkit2gtk3 zathura-pdf-mupdf ___ 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
Heads up: openjpeg2-2.5.0 and gdal-3.5.0 coming to rawhide
Hi I'll build openjpeg2-2.5.0 and gdal-3.5.0 for rawhide in the side tag f37-build-side-53899. I've switched gdal to the new cmake based build, and at the same time merged the mingw package with the native one. I'll rebuild affected packages as listed below. Thanks Sandro --- lizams bes blender cloudcompare compat-ffmpeg4 darktable dcm2niix eccodes efl engauge-digitizer ffmpeg freeimage gazebo gdal gdcm geeqie ghostscript gimp GMT gpac grass gstreamer1-plugins-bad-free ImageMagick liblas librasterlite2 mapnik mapserver merkaartor mingw-freeimage mingw-gstreamer1-plugins-bad-free mingw-opencv mingw-poppler mtpaint mupdf ncl opencv OpenImageIO OpenSceneGraph openslide osgearth paraview PDAL poppler postgis python-fiona python-pillow python-PyMuPDF python-rasterio qgis qmapshack qsstv R-rgdal saga vfrnav vips vtk webkit2gtk3 zathura-pdf-mupdf ___ 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
Review request: liblerc
Hi I've packaged liblerc which I'd like to use for the upcoming gdal-3.5.0. Review request is here [1]. It's a simple cmake/c++ library, and I've also added the mingw subpackages. Happy to review in exchange. Thanks Sandro [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2082662 ___ 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
HEADS UP: podofo-0.9.8 coming to rawhide
Hi I'm landing podofo 0.9.8 which carries a soname bump. I'll build it and rebuild the following dependent packages in f37-build-side-53387: calibre gimagereader krename pdfsign scribus vfrnav Sandro ___ 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: "The system is going down for suspend NOW!" broadcast messages
On 27.04.22 10:29, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Apr 27, 2022 at 09:36:47AM +0200, Petr Pisar wrote: V Mon, Apr 25, 2022 at 11:45:44AM -0400, Simo Sorce napsal(a): On Mon, 2022-04-25 at 16:28 +0200, Petr Pisar wrote: V Mon, Apr 25, 2022 at 12:54:10PM +0200, Sandro Mani napsal(a): Since some recent update (can't pinpoint which exactly), everytime the system suspends, it sends a "The system is going down for suspend NOW!" broadcast message to all terminals. Any idea anyone how to switch this off? (Running up-to-date rawhide). How is the suspend triggered (i.e. by some explicit command, or key press, or a desktop environment timer…)? Also please describe your enviroment, so it's easier to reproduce. On my part it's a current fedora rawhide with systemd-251~rc1-3.fc37.x86_64, and triggered when closing the laptop lid or pressing the suspend button. Thanks Sandro ___ 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
"The system is going down for suspend NOW!" broadcast messages
Hi Since some recent update (can't pinpoint which exactly), everytime the system suspends, it sends a "The system is going down for suspend NOW!" broadcast message to all terminals. Any idea anyone how to switch this off? (Running up-to-date rawhide). Thanks Sandro ___ 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: NodeJS help: updating python-pydata-sphinx-theme
Facing a similar situation a while ago, it was suggested to use a script like [1] to prepare an offline cache of all dependencies, and point yarn to that folder in the package spec. Other example is pgadmin4 [2]. Sandro [1] https://src.fedoraproject.org/rpms/qgis/blob/rawhide/f/prepare_vendor.sh [2] https://src.fedoraproject.org/rpms/pgadmin4/tree/rawhide On 11.04.22 23:41, Jerry James wrote: The latest version of python-networkx requires version 0.8 or later of python-pydata-sphinx-theme to build its documentation. That version of python-pydata-sphinx-theme needs 3 new python packages, which I can handle, but it also comes with a new requirement: using node to build the theme files (CSS and JavaScript). I ran a mock build with --enable-network. The build downloaded 759 node modules, all so that it can embed 2 of them (bootstrap and popper.js) in the theme files. There are only 25 direct node dependencies (see below), so I assume the other 734 are transitive dependencies. The guidelines (https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/) suggest that I need to add 759 Source tarballs, which is a non-starter. Is there a realistic way to handle this situation? Direct node dependencies: @fortawesome/fontawesome-free (which we unbundle) bootstrap clean-webpack-plugin copy-webpack-plugin css-loader dedent extract-loader file-loader html-webpack-plugin imports-loader jquery mini-css-extract-plugin node-sass optimize-css-assets-webpack-plugin pa11y-ci pa11y-ci-reporter-html popper.js sass-loader style-loader webpack webpack-cli webpack-dev-server webpack-merge webpack-shell-plugin webpack-watch-files-plugin ___ 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
Review requests: mingw-qt6-qtwebchannel, mingw-qt6-qttranslations
Hi I've got two more mingw-qt6-* packages which are up for review, both are straight forward mingw/c++ packages. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2009269 - mingw-qt6-qtwebchannel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2070708 - mingw-qt6-qttranslations Happy to review in exchange Thanks Sandro ___ 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: Is mingw-llvm useful? (was Re: Dropping wine from ARM)
On 30.03.22 15:31, Sandro Mani wrote: On 30.03.22 15:26, Neal Gompa wrote: On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth wrote: On 3/30/22 7:38 AM, Sandro Mani wrote: Hi What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package. Thanks Sandro It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain. The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this. This makes me wonder, is mingw-llvm actually useful? I took interest into it way back when I thought it was necessary to get mingw-rust building, but this turned out not to be the case (resp mingw targets are now built directly in the main rust package). So any point in keeping mingw-llvm around? To add to this: as I understand it's just the llvm backend which could be used on a Windows host, but serve no purpose in cross-compiling from linux to mingw? ___ 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
Is mingw-llvm useful? (was Re: Dropping wine from ARM)
On 30.03.22 15:26, Neal Gompa wrote: On Wed, Mar 30, 2022 at 9:25 AM Michael Cronenworth wrote: On 3/30/22 7:38 AM, Sandro Mani wrote: Hi What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package. Thanks Sandro It is a complete, cross-compiling, Windows PE building toolchain[1][2] that uses llvm instead of gcc. The 'mingw-llvm' package is the llvm backend in PE form and not the complete toolchain. The main llvm package should be capable of this already, as it's a retargetable compiler. The clang package provides a clang program that's capable of this. This makes me wonder, is mingw-llvm actually useful? I took interest into it way back when I thought it was necessary to get mingw-rust building, but this turned out not to be the case (resp mingw targets are now built directly in the main rust package). So any point in keeping mingw-llvm around? ___ 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: Dropping wine from ARM
Hi What does llvm-mingw mean exactly? FWIW, there is a mingw-llvm package. Thanks Sandro On 30.03.22 14:33, Michael Cronenworth wrote: Hi, Fedora currently ships Wine 7.3 released February 25th, 2022. Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64 builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a 'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does not bundle one and does not allow for an alternative compiler. I will need to drop ARM from Wine in order to continue shipping new updates. I do not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have the time right now to discuss this with upstream. Thanks, Michael ___ 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 ___ 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: mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide
On 24.03.22 09:49, Sandro Mani wrote:
On 14.03.22 23:50, Sandro Mani wrote:
Hi
As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38
towards the end of the week. I've completed test-builds here [2].
Looks like there is an ABI incompatibility (std::__once_functor went
away), I'll need to rebuild all dependent mingw packages:
[...]
This is now done. These failures remain to be resolved:
mingw-freeimage: error: '__mingw_uuidof' was not declared in this scope
=> needs further investigation
mingw-libvirt: runtime error: file ../docs/page.xsl line 223 element
element => would be fixed by updating to libvirt-8.1.0
mingw-llvm: malloc(): invalid size (unsorted); collect2: fatal error: ld
terminated with signal 6 [Aborted], core dumped => needs further
investigation, possible binutils bug?
mingw-qt5-qtdeclarative: undefined reference to
`QQmlPrivate::Constructorstrue>::createSingletonInstance' => will attempt to merge patches of
native package
wine: /usr/bin/x86_64-w64-mingw32-dlltool:
{dlls/winmm/libwinmm.cross.a,dlls/winmm/libwinmm.delay.a,dlls/oleaut32/liboleaut32.delay.a,dlls/oleaut32/liboleaut32.cross.a}:
No such file or directory => possible parallel build issue, -j1 attempt
ongoing https://koji.fedoraproject.org/koji/taskinfo?taskID=84810799
Sandro___
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: mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide
On 14.03.22 23:50, Sandro Mani wrote: Hi As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38 towards the end of the week. I've completed test-builds here [2]. Looks like there is an ABI incompatibility (std::__once_functor went away), I'll need to rebuild all dependent mingw packages: eigen3 enchant2 GeographicLib geos giflib gtkspell3 gtkspellmm30 jxrlib leptonica libgeotiff libkml librttopo libspatialite libwebp mingw-adwaita-icon-theme mingw-adwaita-qt mingw-angleproject mingw-antlr mingw-atk mingw-atkmm mingw-biblesync mingw-boost mingw-brotli mingw-bzip2 mingw-cairo mingw-cairomm mingw-c-ares mingw-cfitsio mingw-clucene mingw-cmocka mingw-colord mingw-crt mingw-curl mingw-Cython mingw-dbus mingw-dbus-glib mingw-djvulibre mingw-dlfcn mingw-drmingw mingw-exiv2 mingw-expat mingw-fcgi mingw-fftw mingw-flac mingw-fltk mingw-fontconfig mingw-freeglut mingw-freeimage mingw-freetype mingw-freexl mingw-fribidi mingw-ftplib mingw-g2clib mingw-GConf2 mingw-gdal mingw-gdb mingw-gdbm mingw-gdk-pixbuf mingw-gettext mingw-glew mingw-glib2 mingw-glibmm24 mingw-glib-networking mingw-glslang mingw-gmp mingw-gnutls mingw-goocanvas2 mingw-graphene mingw-graphite2 mingw-gsl mingw-gsm mingw-gstreamer mingw-gstreamer1 mingw-gstreamer1-plugins-bad-free mingw-gstreamer1-plugins-base mingw-gstreamer1-plugins-good mingw-gtk2 mingw-gtk3 mingw-gtkmm24 mingw-gtkmm30 mingw-gtksourceview3 mingw-gtksourceviewmm3 mingw-gtk-vnc mingw-hamlib mingw-harfbuzz mingw-hidapi mingw-hunspell mingw-icu mingw-id3lib mingw-imath mingw-jansson mingw-jasper mingw-jimtcl mingw-jsoncpp mingw-json-glib mingw-lcms mingw-lcms2 mingw-libarchive mingw-libcharset mingw-libconfuse mingw-libcroco mingw-libepoxy mingw-libffi mingw-libftdi mingw-libgamerzilla mingw-libgcrypt mingw-libglade2 mingw-libglademm24 mingw-libgnurx mingw-libgpg-error mingw-libgsf mingw-libgta mingw-libgusb mingw-libid3tag mingw-libIDL mingw-libidn mingw-libidn2 mingw-libimagequant mingw-libjpeg-turbo mingw-libltdl mingw-libmicrohttpd mingw-libmng mingw-libogg mingw-libosinfo mingw-libpng mingw-libpsl mingw-LibRaw mingw-librsvg2 mingw-libsigc++20 mingw-libsigc++30 mingw-libsqlite3x mingw-libssh2 mingw-libtasn1 mingw-libtheora mingw-libtiff mingw-libunistring mingw-libusbx mingw-libvirt mingw-libvorbis mingw-libxml++ mingw-libxml2 mingw-libxslt mingw-libzip mingw-llvm mingw-log4c mingw-mediawriter mingw-minizip mingw-mpfr mingw-nettle mingw-numpy mingw-openal-soft mingw-opencv mingw-openexr mingw-openssl mingw-opus mingw-opusfile mingw-orc mingw-osinfo-db-tools mingw-p11-kit mingw-pango mingw-pangomm mingw-pcre mingw-pcre2 mingw-pdcurses mingw-physfs mingw-pixman mingw-plotmm mingw-polyclipping mingw-poppler mingw-portablexdr mingw-portaudio mingw-postgresql mingw-protobuf mingw-python3 mingw-python-ephem mingw-python-lxml mingw-python-markupsafe mingw-python-psycopg2 mingw-python-pyproj mingw-python-pyyaml mingw-python-qt5 mingw-python-shapely mingw-qca mingw-qextserialport mingw-qscintilla mingw-qt5-qtbase mingw-qt5-qtdeclarative mingw-qt5-qtquickcontrols mingw-qt5-qtquickcontrols2 mingw-qt5-qttools mingw-qt5-qtwebkit mingw-qt6-qt3d mingw-qt6-qtactiveqt mingw-qt6-qtbase mingw-qt6-qtcharts mingw-qt6-qtdeclarative mingw-qt6-qtimageformats mingw-qt6-qtmultimedia mingw-qt6-qtpositioning mingw-qt6-qtsensors mingw-qt6-qtshadertools mingw-qt6-qtsvg mingw-qt6-qttools mingw-qt6-qtwebsockets mingw-qtkeychain mingw-qtspell mingw-qwt mingw-qwtpolar mingw-readline mingw-rest mingw-sane-backends mingw-sdl12-compat mingw-SDL2 mingw-SDL2_image mingw-SDL2_mixer mingw-SDL2_ttf mingw-SDL_image mingw-SDL_mixer mingw-SDL_ttf mingw-sparsehash mingw-spatialindex mingw-speex mingw-speexdsp mingw-spice-gtk mingw-spirv-headers mingw-spirv-tools mingw-sqlite mingw-taglib mingw-tcl mingw-termcap mingw-tk mingw-twaindsm mingw-usbredir mingw-vulkan-loader mingw-vulkan-tools mingw-vulkan-validation-layers mingw-wavpack mingw-windows-default-manifest mingw-wine-gecko mingw-win-iconv mingw-winpthreads mingw-winstorecompat mingw-wpcap mingw-wxWidgets mingw-wxWidgets3 mingw-xerces-c mingw-xz mingw-yaml-cpp mingw-zfstream mingw-zlib mingw-zstd openjpeg2 OpenSceneGraph osgearth podofo proj python-pillow samba shapelib svg2svgt tesseract uriparser wine wine-mono I'd fire these off over the weekend. Sandro ___ 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: Heads up: cgnslib 4.3 coming to rawhide with soname bump
On 22.03.22 08:47, Sandro Mani wrote: Hi I'll be updating to cgnslib-4.3 in rawhide in f37-build-side-52152, rebuilding the following dependencies: gmsh paraview pcl petsc vtk This is now done and the side-tag merged. Sandro ___ 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
I took mingw-llvm as I already defacto maintained it. On 22.03.22 09:27, 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 Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-03-22.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change atomic-reactor cverna, infra-sig, 0 weeks ago maxamillion, orphan, twaugh, vrutkovs augeas-vala orphan 3 weeks ago beanstalk-client orphan 2 weeks ago gela-asis orphan, reznik 0 weeks ago gimp-fourier-plugin orphan 3 weeks ago gocl orphan 3 weeks ago golang-github-mdlayher-wifi go-sig, orphan 1 weeks ago javahelp2 orphan 6 weeks ago lua-ldap orphan 2 weeks ago matreshka orphan, reznik, rombobeorn 0 weeks ago mingw-llvm orphan 0 weeks ago python-aiohttp-cors orphan, python-sig 2 weeks ago python-aiohttp-negotiate orphan 2 weeks ago python-blessings orphan 2 weeks ago python-fastimport orphan 2 weeks ago python-hkdf orphan 3 weeks ago python-lrparsing orphan 2 weeks ago python-magic-wormhole orphan 3 weeks ago python-magic-wormhole-mailbox- orphan 3 weeks ago server python-magic-wormhole-transit- orphan 3 weeks ago relay python-ofxparse orphan 2 weeks ago python-plyvel orphan 2 weeks ago python-pystalk orphan 2 weeks ago python-spake2 orphan 3 weeks ago python-txtorcon orphan 3 weeks ago qcommandline orphan 2 weeks ago qt5-qtcanvas3d kde-sig, orphan 0 weeks ago qt5-qtenginio kde-sig, lupinix, orphan 0 weeks ago rpg-cli orphan, rust-sig 5 weeks ago rubygem-database_cleaner orphan 4 weeks ago rust-diffus orphan, rust-sig 0 weeks ago rust-diffus-derive orphan, rust-sig 0 weeks ago rust-newsblur_api orphan, rust-sig 0 weeks ago rust-opml orphan, rust-sig 0 weeks ago rust-xmltree orphan, rust-sig 0 weeks ago sems orphan 0 weeks ago w_scan orphan 5 weeks ago yecht orphan 1 weeks ago The following packages require above mentioned packages: Report too long, see the full version at https://churchyard.fedorapeople.org/orphans-2022-03-22.txt See dependency chains of your packages at https://packager-dashboard.fedoraproject.org/ See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan Affected (co)maintainers (either directly or via packages' dependencies): cverna: atomic-reactor eclipseo: golang-github-mdlayher-wifi go-sig: golang-github-mdlayher-wifi ignatenkobrain: rust-xmltree, rust-diffus, rust-diffus-derive, rust-newsblur_api, rust-opml infra-sig: atomic-reactor kde-sig: qt5-qtcanvas3d, qt5-qtenginio kwizart: python-aiohttp-cors lupinix: qt5-qtenginio maxamillion: atomic-reactor, python-blessings nucleo: python-aiohttp-cors python-sig: python-aiohttp-cors reznik: gela-asis, matreshka rkuska: python-blessings rombobeorn: matreshka rust-sig: rust-xmltree, rpg-cli, rust-diffus, rust-diffus-derive, rust-newsblur_api, rust-opml salimma: python-blessings terjeros: python-blessings twaugh: atomic-reactor vrutkovs: atomic-reactor ___ 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
Heads up: cgnslib 4.3 coming to rawhide with soname bump
Hi I'll be updating to cgnslib-4.3 in rawhide in f37-build-side-52152, rebuilding the following dependencies: gmsh paraview pcl petsc vtk Sandro ___ 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
mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide
Hi As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38 towards the end of the week. I've completed test-builds here [2]. Sandro [1] https://fedoraproject.org/wiki/Changes/F37MingwEnvToolchainUpdate [2] https://copr.fedorainfracloud.org/coprs/smani/mingw-gcc-12/ ___ 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: Planning to start unifying native and mingw packages
On 14.03.22 14:13, Daniel P. Berrangé wrote: On Mon, Mar 14, 2022 at 01:06:34PM +, Daniel P. Berrangé wrote: On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: Hi Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants: Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run. I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos. Sandro [1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/ Seems to be a 404 - is it marked private perhaps ? Never mind, I was blinded by the other response into thinking this was a new thread, where as the orignal mail was actually weeks old. Right, I already went ahead and merged the work ;) So far I've not seen any side-effects directly related to unifying the two builds. Sandro ___ 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: Planning to start unifying native and mingw packages
On 14.03.22 14:02, Michael Cronenworth wrote: On 2/20/22 3:13 PM, Sandro Mani wrote: Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. What do you feel about native packages depending on MinGW packages? As far as I can judge, I don't see any problem. Sandro ___ 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: Upcoming tesseract and proj updates with soname bumps
On 09.03.22 21:50, Sandro Mani wrote: On 03.03.22 11:29, Sandro Mani wrote: Hi I'm planing on landing tesseract-5.1.0 and proj-9.0.0 in rawhide and F36 in the coming days. I'm doing a test run in these COPR repos: tesseract: https://copr.fedorainfracloud.org/coprs/smani/tesseract5/ (all builds already complete) proj: https://copr.fedorainfracloud.org/coprs/smani/proj9/ (starting now) Once done there, I plan to move ahead building all of these in a side-tag for F37 and then F36. Probably some time this weekend to beginning of next week. It took me a while to hunt down a python-cartopy test failure [1], I'll now proceed with the builds in the side-tag f37-build-side-51749. I won't be pushing this to F36. I'll be building the following packages: tesseract-5.1.0 proj-9.0.0 and then rebuilding the following dependencies: [...] This is now done and the side-tag has been submitted. Sandro___ 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
