Re: Rebuilding tesseract dependents in F42 for soversion change
On 01.10.24 00:06, Sandro Mani wrote: On 30.09.24 23:35, Neal Gompa wrote: On Wed, Sep 25, 2024 at 2:49 PM Michel Lind wrote: Dear all, This PR: https://src.fedoraproject.org/rpms/tesseract/pull-request/6 was recently merged and built: https://bodhi.fedoraproject.org/updates/FEDORA-2024-41b92bf172 It backports a PR that's merged upstream to change the Tesseract SOVERSION from maj.min.patch to only maj.min (Tesseract follows SemVer and already uses maj.min for its Windows build, so the Linux versioning was just a misconfiguration). So in the future, patch releases can be built without having to rebuild dependents! This also splits off tesseract-libs into a separate subpackage, which will make it easier in the future to have compat versions of tesseract since the libraries could coexist. Unfortunately I omitted to mention that tesseract dependencies have to be rebuilt - so we have to move slightly faster than usual to rebuild the dependents. This will be done in f42-build-side-96586 that's already created for updating ffmpeg (one of those packages that need tesseract). I attempted a rebuild to deal with a bodhi error where it wouldn't let me land it with the NVR reserved by another obsolete update, but I'm getting bizarre failures for the mingw builds. Can someone help, please? Here's the failed build task: https://koji.fedoraproject.org/koji/taskinfo?taskID=124237852 It seems like something has gone wrong with trying to use the C++ standard library in MinGW somehow? This is most likely due to the fact that mingw-crt-12.0.0 for the mingw32 and mingw64 variants was initially built with the incorrect default msvcrt. This has since been fixed, but mingw-gcc also needs to be rebuilt. I'm taking care of this now. Apologies for the trouble. This should now be ok, a scratch build of tesseract with the rebuilt mingw-gcc 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Rebuilding tesseract dependents in F42 for soversion change
On 30.09.24 23:35, Neal Gompa wrote: On Wed, Sep 25, 2024 at 2:49 PM Michel Lind wrote: Dear all, This PR: https://src.fedoraproject.org/rpms/tesseract/pull-request/6 was recently merged and built: https://bodhi.fedoraproject.org/updates/FEDORA-2024-41b92bf172 It backports a PR that's merged upstream to change the Tesseract SOVERSION from maj.min.patch to only maj.min (Tesseract follows SemVer and already uses maj.min for its Windows build, so the Linux versioning was just a misconfiguration). So in the future, patch releases can be built without having to rebuild dependents! This also splits off tesseract-libs into a separate subpackage, which will make it easier in the future to have compat versions of tesseract since the libraries could coexist. Unfortunately I omitted to mention that tesseract dependencies have to be rebuilt - so we have to move slightly faster than usual to rebuild the dependents. This will be done in f42-build-side-96586 that's already created for updating ffmpeg (one of those packages that need tesseract). I attempted a rebuild to deal with a bodhi error where it wouldn't let me land it with the NVR reserved by another obsolete update, but I'm getting bizarre failures for the mingw builds. Can someone help, please? Here's the failed build task: https://koji.fedoraproject.org/koji/taskinfo?taskID=124237852 It seems like something has gone wrong with trying to use the C++ standard library in MinGW somehow? This is most likely due to the fact that mingw-crt-12.0.0 for the mingw32 and mingw64 variants was initially built with the incorrect default msvcrt. This has since been fixed, but mingw-gcc also needs to be rebuilt. I'm taking care of this now. Apologies for the trouble. 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: scotch-7.0.4 landing in rawhide
Hi I'll be building scotch-7.0.4 for rawhide in the f42-build-side-94256 side tag. This is a minor update from 7.0.3, but the project has cleaned up the library versioning, so I'll also be rebuilding the following dependencies: freefem++ mmg MUMPS petsc qrmumps superlu_dist 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 request: mingw-vulkan-volk
Hi Probably yes, but that would need to be done also for spirv-{headers,tools}, glslang, and vulkan-{headers,validation-layers,tools,utility-libraries} to ensure that the entire vulkan-sdk is updated consistently. For now, with my current available cycles, I'd prefer to just import mingw-vulkan-volk as a separate package. Thanks Sandro On 04.08.24 19:15, Peter Lemenkov wrote: Hello! Would it be better to add MIngw-related bits to vulkan-volk package? On Sat, Aug 3, 2024 at 10:38 PM Sandro Mani wrote: Hi mingw-vulkan-tools grew a dependency on vulkan-volk, which I've prepared for review here: https://bugzilla.redhat.com/show_bug.cgi?id=2302650 It is a trivial cmake project which produces a single static library. 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 -- ___ 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-vulkan-volk
Hi mingw-vulkan-tools grew a dependency on vulkan-volk, which I've prepared for review here: https://bugzilla.redhat.com/show_bug.cgi?id=2302650 It is a trivial cmake project which produces a single static library. 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: intermittent RPM metadata regression
Hi See https://bugzilla.redhat.com/show_bug.cgi?id=2302033. The source of the issue is that the Requires: environment(modules) in rpm-mpi-hooks (which is a BuildRequirement of openmpi/mpich) did not result in environment-modules getting installed, which broke the dependency generation by rpm-mpi-hooks. I've worked around this by explicitly specifying Requires: environment-modules in rpm-mpi-hooks, and have now rebuilt openmpi. This should solve the broken dependencies. I haven't investigated the failure in resolving "Requires: environment(modules)", which I suspect might be a dnf5 issue. Sandro On 31.07.24 16:30, Sandro via devel wrote: Hi, It seems something is going on with RPM metadata generation. With the latest update of openmpi the generated metadata has changed: $ rpm -q --provides -p openmpi-5.0.5-1.fc41.x86_64.rpm config(openmpi) = 5.0.5-1.fc41 libmpi.so.40()(64bit) libmpi_java.so.40()(64bit) libmpi_mpifh.so.40()(64bit) libmpi_usempi_ignore_tkr.so.40()(64bit) libmpi_usempif08.so.40()(64bit) liboshmem.so.40()(64bit) mpi openmpi = 5.0.5-1.fc41 openmpi(x86-64) = 5.0.5-1.fc41 The previous build (during mass rebuild) had: $ rpm -q --provides -p openmpi-5.0.3-3.fc41.x86_64.rpm config(openmpi) = 5.0.3-3.fc41 libmpi.so.40()(64bit)(openmpi-x86_64) libmpi_java.so.40()(64bit)(openmpi-x86_64) libmpi_mpifh.so.40()(64bit)(openmpi-x86_64) libmpi_usempi_ignore_tkr.so.40()(64bit)(openmpi-x86_64) libmpi_usempif08.so.40()(64bit)(openmpi-x86_64) liboshmem.so.40()(64bit)(openmpi-x86_64) mpi openmpi = 5.0.3-3.fc41 openmpi(x86-64) = 5.0.3-3.fc41 The `(openmpi-x86_64)` part has been dropped, causing packages depending on OpenMPI to go FTI with a message like: can't install sandia-omega-h-openmpi: - nothing provides libmpi.so.40()(64bit)(openmpi-x86_64) needed by sandia-omega-h-openmpi-9.34.13-7.fc41.x86_64 I quick glance didn't show any changes to the rpm package between the two builds, suggesting something else is causing the issue. I'm at a loss as to where this issue needs to be reported and fixed. To make things even more complicated, my latest scratch build of 5.0.5-1 has the correct metadata just like the 5.0.3-3 build. 5.0.5-1 (broken): https://koji.fedoraproject.org/koji/buildinfo?buildID=2519082 5.0.3-3 (good): https://koji.fedoraproject.org/koji/buildinfo?buildID=2499148 5.0.5-1 (good): https://koji.fedoraproject.org/koji/taskinfo?taskID=121299407 Cheers, -- ___ 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.4.0 coming to rawhide
On 08.06.24 10:26, Michael J Gruber wrote: Am Sa., 8. Juni 2024 um 09:45 Uhr schrieb Sandro Mani : Hi I'll be building tesseract-5.4.0 for rawhide in the f41-build-side-90853 side tag. I'll also be rebuilding the following dependent packages: crow-translate ffmpeg gimagereader mupdf opencv R-tesseract skanpage Please don't do this until python-f41 has been merged! From this list, at least mupdf depends on python and produces python packages. If you rebuild against tesseract now that build will depend on python-3.12 and tesseract-5.4.0, whereas the build in pyth-nf41 depends on python-3.13 and tesseract as it is in rawhide right now. No matter which side-tag will get merged first, things will break. I'm already holding back a mupdf update because of the ongoing python-41 side-tag build, btw, and other depending ones. As coordinated with Michael, this is now done. ffmpeg is currently failing due to python dependencies which fail to build against py3.13, and opencv is consequently also failing since it requires ffmpeg. 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: tesseract-5.4.0 coming to rawhide
Hi I'll be building tesseract-5.4.0 for rawhide in the f41-build-side-90853 side tag. I'll also be rebuilding the following dependent packages: crow-translate ffmpeg gimagereader mupdf opencv R-tesseract skanpage 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: rpm-4.20 and __debug_install_post
On 04.06.24 10:12, Daniel P. Berrangé wrote: On Tue, Jun 04, 2024 at 08:40:15AM +0200, Sandro Mani wrote: Hi In rpm 4.20 as currently available in rawhide, defining __debug_install_post seems to have no effect. The %mingw_package_header sets __debug_install_post as follows %mingw_package_header \ %global __strip %{mingw_strip} \ %global __objdump %{mingw_objdump} \ FWIW, I don't think these two overrides should be required anymore. The standard strip/objdump commands in /usr/bin work with PE files these days, and for the pacakges where we have merged mingw+native specs these overrides aren't used. Given that, I'd question whether %mingw_package_header needs to continue to exist either ? it is no harder / great lines of code to simply call %mingw_debug_install_post in %install, thus avoiding the rpm 4.20 compat issue. We could indeed to that, as we already require for unified native/mingw specs. Perhaps there also exists a way to trigger this automatically with a mechanism similar to the %{_rpmconfigdir}/fileattrs/*.attr? 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
rpm-4.20 and __debug_install_post
Hi In rpm 4.20 as currently available in rawhide, defining __debug_install_post seems to have no effect. The %mingw_package_header sets __debug_install_post as follows %mingw_package_header \ %global __strip %{mingw_strip} \ %global __objdump %{mingw_objdump} \ %global __debug_install_post %%{mingw_debug_install_post} \ %{nil} but %mingw_debug_install_post is never executed. Manually running %mingw_debug_install_post in %install works however. Perhaps this is related to [1]? What is the correct way now to trigger the custom debug extraction script? Thanks Sandro [1] https://github.com/rpm-software-management/rpm/issues/2204 -- ___ 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: 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