Re: [HEADS-UP] openexr so name bump heading Rawhide and f40
Just an observation... I'm very happy for the assist, I don't have the time I used to for packaging and the dependency chain for this particular package is "fun", but as the primary maintainer for openexr, you can imagine my surprise as this announcement. Perhaps it would be a good idea to contact the maintainer for a project prior to such announcements? Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: mock build for rawhide: Transaction failed: Signature verification failed.
On Tue, Feb 20, 2024 at 7:40 AM Brad Smith wrote: > I had this problem too. There is a new version of mock and > more-core-config (not sure of name still getting first cup of coffee) in > updates-testing that has the fix. > Ahh, updating mock didn't pull in mock-core-config. Both it and distribution-gpg-keys are updated and now everything seems fine. 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: mock build for rawhide: Transaction failed: Signature verification failed.
On Tue, Feb 20, 2024 at 7:00 AM Miro Hrončok wrote: > > > On 20. 02. 24 13:31, Richard Shaw wrote: > > For about a week I've been seeing this when trying to test build > packages for > > rawhide locally: > > > > Transaction failed: Signature verification failed. > > PGP check for package "bash-5.2.26-3.fc40.x86_64" > > > (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/bash-5.2.26-3.fc40.x86_64.rpm) > from repo "fedora" has failed: Import of the key didn't help, wrong key? > > > > I've already done a --scrub=all a few times to no avail. > > Do you have distribution-gpg-keys 1.101 installed? > Let me try that, I did an update of rpm and mock but I didn't want to do a full system upgrade just yet. Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
mock build for rawhide: Transaction failed: Signature verification failed.
For about a week I've been seeing this when trying to test build packages for rawhide locally: Transaction failed: Signature verification failed. PGP check for package "bash-5.2.26-3.fc40.x86_64" (/var/lib/mock/fedora-rawhide-x86_64/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/bash-5.2.26-3.fc40.x86_64.rpm) from repo "fedora" has failed: Import of the key didn't help, wrong key? I've already done a --scrub=all a few times to no avail. Anyone else seeing this? Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: HELP! What's up with OpenVDB?
Almost there but running into a build problem with Blender... https://koji.fedoraproject.org/koji/taskinfo?taskID=112606258 --- /builddir/build/BUILD/blender-4.0.2/intern/cycles/scene/image_vdb.cpp: In member function ‘bool ccl::ToNanoOp::operator()(const openvdb::v11_0::GridBase::ConstPtr&)’: /builddir/build/BUILD/blender-4.0.2/intern/cycles/scene/image_vdb.cpp:58:33: error: ‘openToNanoVDB’ is not a member of ‘nanovdb’ 58 | nanogrid = nanovdb::openToNanoVDB’ token 60 | nanovdb::FpN>(floatgrid); | ^ /builddir/build/BUILD/blender-4.0.2/intern/cycles/scene/image_vdb.cpp:64:33: error: ‘openToNanoVDB’ is not a member of ‘nanovdb’ 64 | nanogrid = nanovdb::openToNanoVDB’ token 66 | nanovdb::Fp16>(floatgrid); |^ /builddir/build/BUILD/blender-4.0.2/intern/cycles/scene/image_vdb.cpp:71:29: error: ‘openToNanoVDB’ is not a member of ‘nanovdb’ 71 | nanogrid = nanovdb::openToNanoVDB(floatgrid); | ^ --- Looking at openvdb I see this but it looks like it's only skipping nanovdb_convert, why I don't know... https://koji.fedoraproject.org/koji/buildinfo?buildID=2391613 --- -- - Configuring NanoVDB Cmd Tools -- CMake Warning at nanovdb/nanovdb/cmd/CMakeLists.txt:31 (message): - OpenVDB required to build nanovdb_convert. Skipping. --- Any help would be appreciated but I don't want to leave the side-tag open much longer. Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: runaway fork() in Lua script
On Mon, Jan 29, 2024 at 12:03 PM Jerry James wrote: > For the second time in two days, running "fedpkg build" gave me a few > dozen lines that say: > > warning: runaway fork() in Lua script > > before the usual build messages start appearing. Is this a known issue? > Just started seeing this after a `dnf update` and reboot... Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: HELP! What's up with OpenVDB?
On Mon, Jan 29, 2024 at 7:13 AM Sérgio Basto wrote: > > > > Well I just re-tried openvdb with _smp_build_ncpus 1 and it still > > failed so I don't think we have a choice at this point. Perhaps it > > was hitting the 4GB max per process due to being 32bit? > > > > Have you try set in build the ulimit [1] . > On copr, copr already set the max number of files already by default > [2] have you check if you can build it on copr ? > No, and I don't have the time, it's not even my package, I just need it "fixed" so I can build OpenImageIO and its dependencies in my side-tag that should have been merged already. Also, I'm not sure there's any compelling reason to "save" OpenVDB or its dependencies on i686 but if someone wants to go to the trouble I'll throw away my side tag and start over, again... Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: HELP! What's up with OpenVDB?
On Mon, Jan 29, 2024 at 4:16 AM Jonathan Wakely wrote: > On Sun, 28 Jan 2024 at 15:18, Richard Shaw wrote: > > > > Well I upped the memory to 10GB and got it to build but the issue on > i686 with the wrong tbb package being pulled in has not been corrected by > any of the 4 maintainers of the package. > > I fixed tbb to stop installing tbb32.pc so the underlying cause should > be fixed in tbb-2021.11.0-5.fc40 and rebuilding openvdb should get the > right tbb now. > Not sure why it didn't work then, but it doesn't change the fact that the BR hadn't been updated in a very long time, using version 3 instead of date type release format. The last standard version release was 4.4 in 2016. More than likely all of the BRs need a refresh to the cmake format if it's supported by the package. Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: HELP! What's up with OpenVDB?
On Sun, Jan 28, 2024 at 9:55 AM Ben Beasley wrote: > Blender already excludes i686: > > > https://src.fedoraproject.org/rpms/blender/blob/8088da10c20e53ab0e1dd5de6fd3a2344bd288aa/f/blender.spec#_207 > > So does prusa-slicer: > > > https://src.fedoraproject.org/rpms/prusa-slicer/blob/44359e4b53c503cb61a60842abf991a01d1cb9db/f/prusa-slicer.spec#_68 > > Packages depending directly on openvdb are: > > $ fedrq wrsrc -s openvdb > OpenImageIO-2.4.17.0-1.fc40.src > blender-1:4.0.2-1.fc40.src > luxcorerender-2.7-0.10.beta1.fc40.src > openvkl-2.0.0-5.fc40.src > prusa-slicer-2.4.2-13.fc40.src > usd-23.11-2.fc40.src > > Of these, it looks like only OpenImageIO builds on i686. Packages > depending on it are: > > $ fedrq wrsrc -s OpenImageIO > OpenColorIO-2.2.1-6.fc40.src > blender-1:4.0.2-1.fc40.src > embree-4.3.0-2.fc40.src > luxcorerender-2.7-0.10.beta1.fc40.src > oidn-2.1.0-1.fc40.src > openshadinglanguage-1.12.14.0-9.fc40.src > usd-23.11-2.fc40.src > > Of those, only OpenColorIO builds on i686. Packages depending on it are: > > $ fedrq wrsrc -s OpenColorIO > OpenImageIO-2.4.17.0-1.fc40.src > blender-1:4.0.2-1.fc40.src > calligra-3.2.1-25.fc39.src > krita-5.2.2-1.fc40.src > luxcorerender-2.7-0.10.beta1.fc40.src > usd-23.11-2.fc40.src > > Of those, only calligra builds on i686, and it’s a leaf package. So, if > I haven’t missed anything, as long as i686 support is dropped from all > of calligra, OpenColorIO, OpenImageIO, and openvdb, then it should be OK. > Well I just re-tried openvdb with _smp_build_ncpus 1 and it still failed so I don't think we have a choice at this point. Perhaps it was hitting the 4GB max per process due to being 32bit? Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: HELP! What's up with OpenVDB?
Well I upped the memory to 10GB and got it to build but the issue on i686 with the wrong tbb package being pulled in has not been corrected by any of the 4 maintainers of the package. So I did a minimal update and changed the tbb BR's from pkgconf to cmake and a scratch build completed pulling in the correct tbb-devel on i686, but now two attempts at real builds fail... I think it's time to retire openvdb on i686 but blender and prusa-slicer would need to stop building for i686 first as first level BRs, I didn't dig any deeper into the dependency chain. Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: HELP! What's up with OpenVDB?
On Wed, Jan 24, 2024 at 10:56 PM Mamoru TASAKA wrote: > Richard Shaw wrote on 2024/01/25 12:43: > > See: > > https://src.fedoraproject.org/rpms/build-constraints-rpm-macros/blob/rawhide/f/macros.build-constraints > > The macro attemps to reduce parallel make jobs when the build needs > more memory than usual. > I figured it was something like that... That should probably be linked to the CMake Packaging guidelines somewhere! > Your [2] ppc64le build log actually says: > > g++: fatal error: Killed signal terminated program cc1plus > compilation terminated. > gmake[2]: *** > [openvdb/openvdb/CMakeFiles/openvdb_shared.dir/build.make:625: > openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o] > Error 1 > gmake[2]: *** Deleting file > 'openvdb/openvdb/CMakeFiles/openvdb_shared.dir/instantiations/GridOperators.cc.o' > gmake[2]: Leaving directory > '/builddir/build/BUILD/openvdb-11.0.0/redhat-linux-build' > gmake[1]: *** [CMakeFiles/Makefile2:261: > openvdb/openvdb/CMakeFiles/openvdb_shared.dir/all] Error 2 > gmake[1]: *** Waiting for unfinished jobs > > So perhaps g++ process was killed by OOM. > So it looks like there needs to be further restrictions placed on ppc64le and s390x at a minimum and should probably look at discontinuing i686 builds long term. Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
HELP! What's up with OpenVDB?
So with the tbb[1] update OpenVDB is one of the stragglers having issues that need to be addressed before I can build OpenImageIO. Looking at the releng rebuilt attempt it failed on ppc64le. I kicked off the build again[2] and this time it failed on s390x: https://kojipkgs.fedoraproject.org//work/tasks/3860/112313860/build.log Just to check I did a local build for x86_64 and it completed, though I noted it only seemed to use about 3 cores of my 8 core / 12 thread processor. It had this on the cmake line: %cmake_build %limit_build -m 8192 But I haven been unable to decipher its exact purpose since google cannot find where `%limit_build` is documented. Thanks, Richard [1] https://bugzilla.redhat.com/show_bug.cgi?id=2036372 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=112313794 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Build error with GCC 14, not even a warning in GCC 13
On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin wrote: > Ah, I misread the include path. It's our package that is too old :( > https://src.fedoraproject.org/rpms/rapidjson/pull-request/4 should help. > It doesn't look like the pull request has gotten any attention. Perhaps it's time to initiate the non-responsive maintainer process? Thanks! Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Build error with GCC 14, not even a warning in GCC 13
I'm working on getting a new dependency of one of my packages into Fedora:
https://github.com/socketio/socket.io-client-cpp/releases
After doing successful test builds locally in mock (no error output at all)
I used fedora-create-review but all the builds failed with:
In file included from
/builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
/usr/include/rapidjson/document.h: In member function
‘rapidjson::GenericStringRef&
rapidjson::GenericStringRef::operator=(const
rapidjson::GenericStringRef&)’:
/usr/include/rapidjson/document.h:319:82: error: assignment of read-only
member ‘rapidjson::GenericStringRef::length’
319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s =
rhs.s; length = rhs.length; }
|
~~~^~~~
gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121:
CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
Is this a real error?
Thanks,
Richard
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
flrig: C++ warning help
While it's only a warning, I would like to "fix" it. When building flrig I'm seeing the following: widgets/font_browser.cxx: In member function '__ct_base .constprop': widgets/font_browser.cxx:202:52: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 202 | font_pairs = new font_pair[numfonts]; |^ The code can be found here: https://sourceforge.net/p/fldigi/flrig/ci/master/tree/src/widgets/font_browser.cxx#l201 Any hints would be appreciated. Thanks, Richard -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenImageIO 2.5.x w/ soname bump
I plan to build OpenImageIO 2.5.x in rawhide in the near future. Affected packages to be built in a side tag: $ fedrq wr -F "name" -s OpenImageIO-devel OpenColorIO blender embree luxcorerender oidn openshadinglanguage usd Thanks, Richard FAS: hobbes1069 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Fedora Change draft] Minizip transition to minizip-ng
On Mon, Oct 30, 2023 at 7:49 AM Lukas Javorsky wrote: > The possible remediation for this FTBFS packages are: > > Chromium -> Use bundled minizip library > Libdigidocpp -> Use bundled minizip library > OpenColorIO -> Don't upgrade minizip-ng to the new 4th version of API > (stay with minizip-ng-3.10.0). Not preferred as we want to have the latest > and greatest versions in Fedora. > > I've also included this in the change proposal in the *Impact* section. > > Most important are packages *blender, krita,* and *usd *which block the > upgrade [1] of OpenColorIO to the new version which supports the new > minizip API > As I mentioned in BZ, both krita and usd at least have PRs that fix building, but I did not test functionality. I haven't checked to see if they were merged upstream as of yet. So really it's just Blender that's the hold up. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to deal with COPR and RPMAutoSpec
Never mind, I hadn't realized fedpkg had grown the ability to do COPR builds. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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 deal with COPR and RPMAutoSpec
I'm trying to test build packages before actually creating a side tag and doing real builds. I'm using rpkg to do the test builds but openshading language uses RPMAutoSpec. I've tried creating empty commits to bump the release but it does not appear to be working. What's the work around? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenColorIO 2.3.0
Forgot to mention I'm doing the test builds here: https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/builds/ Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenColorIO 2.3.0
On Mon, Sep 25, 2023 at 2:11 AM Sandro wrote: > On 24-09-2023 03:26, Richard Shaw wrote: > > I haven't been able to find the new command in my email history to find > > dependencies but my old script shows the following need to be rebuilt: > > > > blender > > krita > > luxcorerender > > OpenImageIO > > usd > > This looks correct according to `fedrq`: > > $ fedrq wr -s OpenColorIO-devel > OpenImageIO-2.4.15.0-1.fc40.src > blender-1:3.6.2-1.fc40.src > calligra-3.2.1-25.fc39.src > krita-5.1.5-5.fc39.src > luxcorerender-2.7-0.5.beta1.fc39.src > usd-23.08-1.fc40.src > Thanks for confirming. Status update: usd, krita, and Blender need patching for API changes in OpenColorIO. Of the three, the first two already have pull requests in process[1,2] so I used those. Only blender doesn't build now, and per the issue[1], they don't plan to until next year. Anyone want to look at how usd and krita were updated and propose a patch for blender? Thanks, Richard [1] https://github.com/PixarAnimationStudios/OpenUSD/pull/2651/commits/9fe8cf65ed05ec53f5ddbb5ffb08851e02f4adc8 [2] https://invent.kde.org/graphics/krita/-/merge_requests/1942 [3] https://projects.blender.org/blender/blender/issues/109244 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenColorIO 2.3.0
I haven't been able to find the new command in my email history to find dependencies but my old script shows the following need to be rebuilt: blender krita luxcorerender OpenImageIO usd I'll try them in a COPR first to make sure there aren't any issues. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: zlib-ng as a compat replacement for zlib
On Fri, Sep 1, 2023 at 9:02 AM Richard W.M. Jones wrote: > On Fri, Sep 01, 2023 at 07:10:59AM -0500, Richard Shaw wrote: > > Drive by comment because I found this thread interesting... > > > > What compression level was used for zstd? My understanding is that higher > > levels take longer to compress but decompression time remains virtually > the > > same. > > Seems to be the default level? Or at least it doesn't seem like it is > being set. Can you tell from this code: > > > https://gitlab.com/qemu-project/qemu/-/blob/17780edd81d27fcfdb7a802efc870a99788bd2fc/block/qcow2-threads.c#L176 Yeah didn't see anything referencing the `compression_level` property, and the default is 3. If compression performance doesn't matter as much I would try increasing it to maybe 9? The levels are 1 to 22 but I'm sure there's a diminishing return. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: zlib-ng as a compat replacement for zlib
Drive by comment because I found this thread interesting... What compression level was used for zstd? My understanding is that higher levels take longer to compress but decompression time remains virtually the same. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Donate 1 minute of your time to test upgrades from F38 to F39
On Wed, Aug 23, 2023 at 1:41 PM Steven A. Falco wrote: > On 8/23/23 02:22 PM, Miroslav Suchý wrote: > > dnf --releasever=39 --setopt=module_platform_id=platform:f39 \ > > --enablerepo=updates-testing \ > > $(rpm -q fedora-repos-modular >/dev/null && echo > --enablerepo=updates-testing-modular) \ > > --assumeno distro-sync > Problem 1: problem with installed package freecad-1:0.20.2-3.fc38.x86_64 >- freecad-1:0.20.2-3.fc38.x86_64 from @System does not belong to a > distupgrade repository >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from fedora >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from fedora-modular >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from updates-modular >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from updates-testing-modular > Problem 2: problem with installed package > freecad-data-1:0.20.2-3.fc38.noarch >- package freecad-data-1:0.20.2-4.fc39.noarch from fedora requires > freecad = 1:0.20.2-4.fc39, but none of the providers can be installed >- package freecad-data-1:0.20.2-4.fc39.noarch from fedora-modular > requires freecad = 1:0.20.2-4.fc39, but none of the providers can be > installed >- package freecad-data-1:0.20.2-4.fc39.noarch from updates-modular > requires freecad = 1:0.20.2-4.fc39, but none of the providers can be > installed >- package freecad-data-1:0.20.2-4.fc39.noarch from > updates-testing-modular requires freecad = 1:0.20.2-4.fc39, but none of the > providers can be installed >- freecad-data-1:0.20.2-3.fc38.noarch from @System does not belong to > a distupgrade repository >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from fedora >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from fedora-modular >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from updates-modular >- nothing provides libboost_python311.so.1.81.0()(64bit) needed by > freecad-1:0.20.2-4.fc39.x86_64 from updates-testing-modular > Problem 3: problem with installed package > python3-shiboken2-1:5.15.7-2.fc38.x86_64 >- package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from @System > requires python(abi) = 3.11, but none of the providers can be installed >- package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from fedora requires > python(abi) = 3.11, but none of the providers can be installed >- package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from fedora-modular > requires python(abi) = 3.11, but none of the providers can be installed >- package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from updates-modular > requires python(abi) = 3.11, but none of the providers can be installed >- package python3-shiboken2-1:5.15.7-2.fc38.x86_64 from > updates-testing-modular requires python(abi) = 3.11, but none of the > providers can be installed >- python3-3.11.4-1.fc38.x86_64 from @System does not belong to a > distupgrade repository > Problem 4: problem with installed package > python3-pyside2-1:5.15.7-2.fc38.x86_64 >- package python3-pyside2-1:5.15.7-2.fc38.x86_64 from @System requires > python(abi) = 3.11, but none of the providers can be installed >- package python3-pyside2-1:5.15.7-2.fc38.x86_64 from fedora requires > python(abi) = 3.11, but none of the providers can be installed >- package python3-pyside2-1:5.15.7-2.fc38.x86_64 from fedora-modular > requires python(abi) = 3.11, but none of the providers can be installed >- package python3-pyside2-1:5.15.7-2.fc38.x86_64 from updates-modular > requires python(abi) = 3.11, but none of the providers can be installed >- package python3-pyside2-1:5.15.7-2.fc38.x86_64 from > updates-testing-modular requires python(abi) = 3.11, but none of the > providers can be installed >- package python3-3.11.4-1.fc38.x86_64 from @System requires > python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be > installed >- python3-libs-3.11.4-1.fc38.x86_64 from @System does not belong to a > distupgrade repository > FreeCAD is a known issue since the upgrade to Python 3.12. PySide2 is not compatible with Python 3.12 and upstream has no intention of making it compatible as they are only supporting PySide6 for Qt6 now. There's also a TBB dependency issue. For now it would be better to use the appimage. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: Problem with ffmpeg and chromaprint circular dependency
Specifically I think this needs to be addressed if possible: # dnf repoquery --whatrequires libchromaprint\* | grep x86_64 Last metadata expiration check: 0:02:55 ago on Sun 06 Aug 2023 10:10:31 AM CDT. acoustid-fingerprinter-0:0.6-31.fc38.x86_64 chromaprint-tools-0:1.5.1-8.fc38.x86_64 clementine-0:1.4.0~rc2-3.fc38.x86_64 ffmpeg-libs-0:6.0-11.fc38.x86_64 ffmpeg-libs-0:6.0-6.fc38.x86_64 gstreamer1-plugins-bad-free-extras-0:1.22.1-1.fc38.x86_64 gstreamer1-plugins-bad-free-extras-0:1.22.5-1.fc38.x86_64 kid3-common-0:3.9.2-3.fc38.x86_64 kid3-common-0:3.9.4-1.fc38.x86_64 libavformat-free-0:6.0-2.fc38.x86_64 libavformat-free-0:6.0-4.fc38.x86_64 libchromaprint-devel-0:1.5.1-8.fc38.x86_64 mixxx-0:2.3.4-2.fc38.x86_64 mixxx-0:2.3.5-1.fc38.x86_64 strawberry-0:1.0.15-1.fc38.x86_64 strawberry-0:1.0.18-1.fc38.x86_64 vlc-core-1:3.0.19-0.3.fc38.1.x86_64 # dnf repoquery --requires libchromaprint\* Last metadata expiration check: 0:03:19 ago on Sun 06 Aug 2023 10:10:31 AM CDT. /usr/bin/pkg-config libavcodec.so.60 libavcodec.so.60()(64bit) libavcodec.so.60(LIBAVCODEC_60) libavcodec.so.60(LIBAVCODEC_60)(64bit) libavutil.so.58 libavutil.so.58()(64bit) libavutil.so.58(LIBAVUTIL_58) libavutil.so.58(LIBAVUTIL_58)(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.4) libchromaprint(x86-32) = 1.5.1-8.fc38 libchromaprint(x86-64) = 1.5.1-8.fc38 libchromaprint.so.1 libchromaprint.so.1()(64bit) [SNIP] Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Problem with ffmpeg and chromaprint circular dependency
On Sun, Aug 6, 2023 at 9:44 AM Sérgio Basto wrote: > On Sun, 2023-08-06 at 08:04 -0500, Richard Shaw wrote: > > From what I can tell in the spec file[1] for chromaprint, the only thing > that's supposed to depend on ffmpeg is the tools package, but it seems to > have found its way into libchromaprint[2] as well. > > I'm trying to build a new version of codec2 with a soname change but I'm > hitting this: > DEBUG util.py:442: Problem: package > libchromaprint-devel-1.5.1-11.fc39.i686 from build requires > libchromaprint.so.1, but none of the providers can be installed > DEBUG util.py:442:- package libchromaprint-devel-1.5.1-11.fc39.i686 > from build requires libchromaprint(x86-32) = 1.5.1-11.fc39, but none of the > providers can be installed > DEBUG util.py:442:- package libchromaprint-1.5.1-11.fc39.i686 from > build requires libavcodec.so.60, but none of the providers can be installed > DEBUG util.py:442:- package libchromaprint-1.5.1-11.fc39.i686 from > build requires libavcodec.so.60(LIBAVCODEC_60), but none of the providers > can be installed > DEBUG util.py:442:- conflicting requests > DEBUG util.py:442:- nothing provides libcodec2.so.1.0 needed by > libavcodec-free-6.0-10.fc39.i686 from build > > I'm guessing I don't have a choice but to do a bootstrap build of > libchromaprint without ffmpeg first... > > > > no, see my fork > > https://src.fedoraproject.org/fork/sergiomb/rpms/chromaprint/commits/rawhide > and specially commit > > https://src.fedoraproject.org/fork/sergiomb/rpms/chromaprint/c/0e39e40877b404970ab024c579283e50851db20c?branch=rawhide > Let me know if I missed something but those commits don't seem to have made their way into SCM so doesn't really help. Also, as far as I know there's no way to pass general options or --with / --without options to Koji. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Problem with ffmpeg and chromaprint circular dependency
>From what I can tell in the spec file[1] for chromaprint, the only thing that's supposed to depend on ffmpeg is the tools package, but it seems to have found its way into libchromaprint[2] as well. I'm trying to build a new version of codec2 with a soname change but I'm hitting this: DEBUG util.py:442: Problem: package libchromaprint-devel-1.5.1-11.fc39.i686 from build requires libchromaprint.so.1, but none of the providers can be installed DEBUG util.py:442:- package libchromaprint-devel-1.5.1-11.fc39.i686 from build requires libchromaprint(x86-32) = 1.5.1-11.fc39, but none of the providers can be installed DEBUG util.py:442:- package libchromaprint-1.5.1-11.fc39.i686 from build requires libavcodec.so.60, but none of the providers can be installed DEBUG util.py:442:- package libchromaprint-1.5.1-11.fc39.i686 from build requires libavcodec.so.60(LIBAVCODEC_60), but none of the providers can be installed DEBUG util.py:442:- conflicting requests DEBUG util.py:442:- nothing provides libcodec2.so.1.0 needed by libavcodec-free-6.0-10.fc39.i686 from build I'm guessing I don't have a choice but to do a bootstrap build of libchromaprint without ffmpeg first... Thanks, Richard [1] https://src.fedoraproject.org/rpms/chromaprint/blob/rawhide/f/chromaprint.spec [2] https://koji.fedoraproject.org/koji/rpminfo?rpmID=35116382 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: codec2 1.5.0 coming
I plan to update codec2 to version 1.5.0 and will perform all rebuilds in a side tag. Affected packages: baresip ffmpeg freedv gnuradio lpcnetfreedv sdrangel sdrpp Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Direwolf FTBFS: Need C help
On Wed, Aug 2, 2023 at 7:14 AM Miroslav Lichvar wrote: > On Wed, Aug 02, 2023 at 06:47:58AM -0500, Richard Shaw wrote: > > I was poking around trying to fix the FTBFS problem with direwolf and it > > looks simple enough. As it has built before for years I assume it's > related > > to GCC 13. > > > > Here's the error: > > /builddir/build/BUILD/direwolf-1.6/src/direwolf.h:303:56: error: expected > > declaration specifiers or '...' before string constant > > 303 | #define strlcpy(dst,src,siz) > > strlcpy_debug(dst,src,siz,__FILE__,__func__,__LINE__) > > |^~~~ > > I think this is the new glibc 2.38 support of strlcpy. > > You need to modify direwolf.h to take the path of the other systems > #if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(__APPLE__) > > e.g. by replacing it with #if 1 > > For an upstream patch it would be better to check for the > __GLIBC_PREREQ macro and __GLIBC_PREREQ(2, 38)), but the current glibc > header in rawhide still claims to be 2.37. > That got it. Thanks! Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned qodem
I have orphaned qodem. I haven't used it in years and was only interested during a brief revival of the good ole' BBS days many years ago. https://src.fedoraproject.org/rpms/qodem Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Direwolf FTBFS: Need C help
I was poking around trying to fix the FTBFS problem with direwolf and it looks simple enough. As it has built before for years I assume it's related to GCC 13. Here's the error: /builddir/build/BUILD/direwolf-1.6/src/direwolf.h:303:56: error: expected declaration specifiers or '...' before string constant 303 | #define strlcpy(dst,src,siz) strlcpy_debug(dst,src,siz,__FILE__,__func__,__LINE__) |^~~~ And here's the code snippet in question: // These prevent /usr/include/gps.h from providing its own definition. #define HAVE_STRLCAT 1 #define HAVE_STRLCPY 1 #define DEBUG_STRL 1 #if DEBUG_STRL #define strlcpy(dst,src,siz) strlcpy_debug(dst,src,siz,__FILE__,__func__,__LINE__) #define strlcat(dst,src,siz) strlcat_debug(dst,src,siz,__FILE__,__func__,__LINE__) size_t strlcpy_debug(char *__restrict__ dst, const char *__restrict__ src, size_t siz, const char *file, const char *func, int line); size_t strlcat_debug(char *__restrict__ dst, const char *__restrict__ src, size_t siz, const char *file, const char *func, int line); #else #define strlcpy(dst,src,siz) strlcpy_debug(dst,src,siz) #define strlcat(dst,src,siz) strlcat_debug(dst,src,siz) size_t strlcpy_debug(char *__restrict__ dst, const char *__restrict__ src, size_t siz); size_t strlcat_debug(char *__restrict__ dst, const char *__restrict__ src, size_t siz); #endif /* DEBUG_STRL */ --- I tried moving the definitions above the #defines but that had no effect... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: python3-pyside2 and Python 3.12
On Thu, Jul 13, 2023 at 5:10 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Richard Shaw wrote: > > # FIXME This patch is completely meaningless in the context of C++. > > # It is a workaround for a pyside2 build failure with Qt 5.15.9, > > # pyside2 5.15.9, clang 16.0.1 -- the generated code thinks a > > # not otherwise specified "Type" is in fact a > > # QFlags, causing many functions > > # looking for a QEvent::Type to be bogus. > > # Since there are no side effects to superfluously specifying > > # QEvent::Type instead of plain "Type" in a QEvent derived class, > > # this workaround is acceptable, if not nice. > > Patch5: qtbase-5.15.9-work-around-pyside2-brokenness.patch > [snip] > > [1] > > > https://github.com/OpenMandrivaAssociation/qt5-qtbase/blob/master/qtbase-5.15.9-work-around-pyside2-brokenness.patch > > I think we can apply this, the extra disambiguation should not hurt indeed. > Any progress on this? I can submit a BZ ticket for tracking if needed. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: python3-pyside2 and Python 3.12
I was able to work around that error but now hitting the following, and the
crumb trail I followed seems to indicate that this needs to be fixed in
Qt5, not PySide2[1]
In file included from
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.10/redhat-linux-build/sources/pyside2/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp:63:
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.10/redhat-linux-build/sources/pyside2/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.h:55:220:
error: no member named 'DragMove' in 'QOpenGLShader'; did you mean simply
'DragMove'?QDragMoveEventWrapper(const QPoint & pos,
QFlags actions, const QMimeData * data,
QFlags buttons, QFlags modifiers,
QFlags type = QOpenGLShader::DragMove);
^~~
DragMove
/usr/include/qt5/QtCore/qcoreevent.h:107:9: note: 'DragMove' declared here
DragMove = 61, // drag moves in widget
^
In file included from
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.10/redhat-linux-build/sources/pyside2/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp:63:
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.10/redhat-linux-build/sources/pyside2/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.h:55:213:
error: no viable conversion from 'QEvent::Type' to
'QFlags'
QDragMoveEventWrapper(const QPoint & pos, QFlags
actions, const QMimeData * data, QFlags buttons,
QFlags modifiers,
QFlags type = QOpenGLShader::DragMove);
^
/usr/include/qt5/QtCore/qflags.h:89:7: note: candidate constructor (the
implicit copy constructor) not viable: no known conversion from
'QEvent::Type' to 'const QFlags &' for 1st argument
class QFlags
^
/usr/include/qt5/QtCore/qflags.h:89:7: note: candidate constructor (the
implicit move constructor) not viable: no known conversion from
'QEvent::Type' to 'QFlags &&' for 1st argument
/usr/include/qt5/QtCore/qflags.h:121:29: note: candidate constructor not
viable: no known conversion from 'QEvent::Type' to
'QOpenGLShader::ShaderTypeBit' for 1st argument
Q_DECL_CONSTEXPR inline QFlags(Enum flags) noexcept : i(Int(flags)) {}
^
/usr/include/qt5/QtCore/qflags.h:123:80: note: candidate constructor not
viable: no known conversion from 'QEvent::Type' to 'Zero' (aka 'int
(QFlags::Private::*)') for 1st argument
QT_DEPRECATED_X("Use default constructor instead") Q_DECL_CONSTEXPR
inline QFlags(Zero) noexcept : i(0) {}
^
/usr/include/qt5/QtCore/qflags.h:125:29: note: candidate constructor not
viable: no known conversion from 'QEvent::Type' to 'QFlag' for 1st argument
Q_DECL_CONSTEXPR inline QFlags(QFlag flag) noexcept : i(flag) {}
^
/usr/include/qt5/QtCore/qflags.h:127:29: note: candidate constructor not
viable: no known conversion from 'QEvent::Type' to
'std::initializer_list' for 1st argument
Q_DECL_CONSTEXPR inline QFlags(std::initializer_list flags)
noexcept
^
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.10/redhat-linux-build/sources/pyside2/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.h:55:213:
note: passing argument to parameter 'type' here
QDragMoveEventWrapper(const QPoint & pos, QFlags
actions, const QMimeData * data, QFlags buttons,
QFlags modifiers,
QFlags type = QOpenGLShader::DragMove);
^
/builddir/build/BUILD/pyside-setup-opensource-src-5.15.10/redhat-linux-build/sources/pyside2/PySide2/QtGui/PySide2/QtGui/qdragmoveevent_wrapper.cpp:103:240:
error: no matching constructor for initialization of 'QDragMoveEvent'
QDragMoveEventWrapper::QDragMoveEventWrapper(const QPoint & pos,
QFlags actions, const QMimeData * data,
QFlags buttons, QFlags modifiers,
QFlags type) : QDragMoveEvent(pos, actions,
data, buttons, modifiers, type)
^
/usr/include/qt5/QtGui/qevent.h:684:5: note: candidate constructor not
viable: no known conversion from 'QFlags' to
'Type' for 6th argument
QDragMoveEvent(const QPoint , Qt::DropActions actions, const
QMimeData *data,
In the OpenMandriva package they have the following:
# FIXME This patch is completely meaningless in the context of C++.
# It is a workaround for a pyside2 build failure with Qt 5.15.9,
# pyside2 5.15.9, clang 16.0.1 -- the generated code thinks a
# not otherwise specified "Type" is in fact a
# QFlags, causing many functions
# looking for a QEvent::Type to be bogus.
# Since there are no side effects to superfluously specifying
# QEvent::Type instead of plain "Type" in a QEvent derived class,
# this workaround is acceptable, if not nice.
Patch5: qtbase-5.15.9-work-around-pyside2-brokenness.patch
Thanks,
Richard
[1]
python3-pyside2 and Python 3.12
So it looks like upstream has no intention of supporting Python 3.12 in Pyside2 (5.15.x series), only in Pyside6 which AFAIK requires Qt6. https://bugreports.qt.io/browse/PYSIDE-2388 Porting is non-trivial and Python upstream does not provide a porting guide. https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_AS_UNICODE Says to replace PyUnicode_AS_UNICODE with PyUnicode_nBYTE_DATA which also requires use of the KIND and READY functions. So now what? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Modernize Thread Building Blocks for Fedora 39
On Thu, Jul 6, 2023 at 5:41 AM Jonathan Wakely wrote: > > > > Wouldn't it be better to just update OpenCascade to its new upstream > version in that sidetag as well instead of doing a compat package for it? > > Define better. > To be clear, I'm not "doing a compat package" for it. I'm just > changing one line in the spec file and rebuilding it against > tbb2020.3-devel (which is currently identical to tbb-devel). > That just means the OpenCascade package in rawhide won't be broken > when tbb gets updated. > > > The new OpenCascade actually requires the new TBB and can't be built > with the older version. See > https://bugzilla.redhat.com/show_bug.cgi?id=2217295. > > Yes, I'm aware of the bugzilla (it's blocked by #2036372 which is this > change). > There's no guarantee that the new version won't have new issues and not be a simple update and rebuild. I don't want to hold things up. For that reason I'm good with the plan as is. Once things have settled in Rawhide I can do test builds of the new version with latest TBB. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Intent to retire OpenCOLLADA
For anyone who didn't see discussion on the list OpenCOLLADA upstream hasn't seen a commit since 2018 and no one has stepped up to port it to pcre2. I tried to convert it to use the bundled pcre as a stop gap to keep it going a bit further but it installs the library instead of building statically. Anyone good with CMake could fix this but at this point I think it's just time to retire it. If anyone wants to take it over let me know otherwise I plan to retire early next week. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Announcing fmt library soversion bump
On Wed, Jun 28, 2023 at 6:37 AM Richard Shaw wrote: > On Wed, Jun 28, 2023 at 6:12 AM Vitaly Zaitsev via devel < > devel@lists.fedoraproject.org> wrote: > >> Results: 37 builds succeeded, 19 failed. >> >> gnuradio >> > > Issue filed upstream: > https://github.com/gnuradio/gnuradio/issues/6735 > I'm currently at work but if a proven packager wants to try the solution proposed in the above that would be helpful. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Announcing fmt library soversion bump
On Wed, Jun 28, 2023 at 6:12 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> Results: 37 builds succeeded, 19 failed.
>
> gnuradio
>
Issue filed upstream:
https://github.com/gnuradio/gnuradio/issues/6735
Also, not all the maintainers may review the devel list as closely. In the
past when I've had a lot of affected packages I wrote a simple bash script
that took the package names and output the -
maintain...@fedoraproject.org email so I could copy and paste it into my
email client.
Not quite the way I did it but ChatGPT came up with this:
```
#!/bin/bash
# Specify the input file containing package names (one per line)
input_file="package_names.txt"
# Initialize an empty string to store the email addresses
email_addresses=""
# Read each package name from the input file
while IFS= read -r package_name; do
# Construct the email address and append it to the string
email_address="${package_name}-maintain...@fedoraproject.org"
email_addresses+="${email_address};"
done < "$input_file"
# Remove the trailing semicolon, if any
email_addresses=${email_addresses%;}
# Print the final email addresses string
echo "$email_addresses"
```
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
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: F39 Change Proposal: Build Fedora Workstation live ISO with Image Builder (System-Wide)
On Mon, Jun 26, 2023 at 10:02 AM Michal Schorm wrote: > > Moreover, it's designed to give the end users a simple workflow to build > their own custom images. > > That's something I'd be interested in. > I always have an USB drive (or several) with Fedora ISO(s) lying > around, being handy from time to time. > Having them customized *easily*, sounds like a great thing to have. > Yes, one of the reasons I still keep System Rescue CD around is it already has gparted installed which is one of the rescue apps I use the most often. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: libftdi: Failure to create output directory (aarch64 only)
On Tue, Jun 6, 2023 at 4:17 AM Dan Horák wrote: > On Tue, 6 Jun 2023 11:00:39 +0200 > Dominik 'Rathann' Mierzejewski wrote: > > > On Tuesday, 06 June 2023 at 10:55, Dan Horák wrote: > > > On Tue, 6 Jun 2023 09:50:09 +0200 > > > Dan Horák wrote: > > > > > > > On Mon, 5 Jun 2023 17:53:59 -0500 > > > > Richard Shaw wrote: > > > > > > > > > I just saw this[1] on the packager dashboard: > > > > > > > > > > error: Could not create output directory > > > > > /builddir/build/BUILD/libftdi1-1.5/redhat-linux-build/doc/xml > > > > > > > > > > Full log: > > > > > > https://kojipkgs.fedoraproject.org/work/tasks/5182/101845182/build.log > > > > > > > > > > Is this a known issue? > > > > > > > > > > [1] > https://koschei.fedoraproject.org/package/libftdi?collection=f39 > > > > > > > > it is an interesting issue, because my fresh scratch build [2] runs > > > > well on aarch64, but fails on s390x with the same error as yours > > > > and with a different error on ppc64le ... I wonder if it could be a > > > > "parallel make" issue. > > > > > > > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=101861225 > > > > > > I think it is a parallel make issue, with an explicit "-j1" the builds > > > are passing OK > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=101862160 > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=101862632 > > > > > > Perhaps it explains also the previous failures seen by koschei ... > > > > Reporting these upstream is best. I've had a similar issue with INN for > > years, but it has been fixed: > > https://github.com/InterNetNews/inn/issues/206 . > > right, but the upstream mailing list looks like a black hole from a > contributor point of view. But thanks to the SUSE maintainer and > http://developer.intra2net.com/mailarchive/html/libftdi/2023/msg5.html > we have the fix I believe. > Thanks all! I'm not the primary maintainer but I didn't remember having this issue in the past so didn't even think it would be a parallel make issue. Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
libftdi: Failure to create output directory (aarch64 only)
I just saw this[1] on the packager dashboard: error: Could not create output directory /builddir/build/BUILD/libftdi1-1.5/redhat-linux-build/doc/xml Full log: https://kojipkgs.fedoraproject.org/work/tasks/5182/101845182/build.log Is this a known issue? [1] https://koschei.fedoraproject.org/package/libftdi?collection=f39 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenCOLLADA need a little c++ help
On Mon, May 29, 2023 at 8:26 AM Sam Varshavchik
wrote:
> Richard Shaw writes:
>
> > error: possibly dangling reference to a temporary [-Werror=dangling-
> > reference]
> > 315 | const auto & parents =
> > dae.root().selectNodes("//*[@sid]/..");
>
> The quickest solution is just add a pragma to shut it up.
>
> > The code in question[2] is:
> > // InstanceWithExtra and other with "url" attribute
> > const auto & instances = root().selectNodes(
>
> Find where selectNodes() is defined. Add
>
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wdangling-reference"
>
> before the definition, and
>
> #pragma GCC diagnostic pop
>
> after it.
>
That's what I ended up doing, it turns out there were structures like this
in about 7 places in that file and several more in another, it just got
through two before the build failed previously. I ended up using the
approach for the whole file and then fixed a couple of #include
since you don't get it for free anymore and the build completed.
Thanks!
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
OpenCOLLADA need a little c++ help
OpenCOLLADA has been failing to build with gcc 13 due to[1]:
error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
315 | const auto & parents =
dae.root().selectNodes("//*[@sid]/..");
The code in question[2] is:
// InstanceWithExtra and other with "url" attribute
const auto & instances = root().selectNodes(
xpath_all + Strings::instance_animation +
xpath_or_all + Strings::instance_camera +
xpath_or_all + Strings::instance_controller +
xpath_or_all + Strings::instance_effect +
xpath_or_all + Strings::instance_force_field +
xpath_or_all + Strings::instance_formula +
xpath_or_all + Strings::instance_geometry +
xpath_or_all + Strings::instance_image +
xpath_or_all + Strings::instance_joint +
xpath_or_all + Strings::instance_kinematics_model +
xpath_or_all + Strings::instance_kinematics_scene +
xpath_or_all + Strings::instance_light +
xpath_or_all + Strings::instance_node +
xpath_or_all + Strings::instance_physics_material +
xpath_or_all + Strings::instance_physics_model +
xpath_or_all + Strings::instance_physics_scene +
xpath_or_all + Strings::instance_visual_scene
);
for (auto instance : instances)
if (auto url = instance.attribute(Strings::url))
onAnyDAEURI(instance.line(), url.value());
There's a 2nd instance of the error but I think I can fix it once the path
forward on the first is addressed.
Thanks,
Richard
[1] https://github.com/KhronosGroup/OpenCOLLADA/issues/661
[2]
https://github.com/KhronosGroup/OpenCOLLADA/blob/master/DAEValidator/library/src/Dae.cpp#L78
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
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: OpenColorIO builds failing due to doxygen patch level update?
On Sat, May 27, 2023 at 4:48 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 26/05/2023 14:07, Richard Shaw wrote: > > Doxygen was updated from 1.9.6 to 1.9.7 which I would assume should be a > > pretty harmless update > > Some Doxygen minor updates breaks something. That's why I disabled docs > generation in all my packages. Users can easily view docs online. > That's unfortunate... I reported it to OpenColorIO first to get their take before reporting it to upstream doxygen. I need to be subscribed to another mailing list like I need another hole in my head. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenColorIO builds failing due to doxygen patch level update?
On a side note I love the packager dashboard! I noticed that OpenColorIO builds in rawhide were failing[1] and took a look at the logs and the errors seem to be around doxygen: In file included from /builddir/build/BUILD/OpenColorIO-2.2.1/src/bindings/python/PyOpenColorIO.h:18, from /builddir/build/BUILD/OpenColorIO-2.2.1/src/bindings/python/PyColorSpaceSet.cpp:4: /builddir/build/BUILD/OpenColorIO-2.2.1/src/bindings/python/PyColorSpaceSet.cpp: In function 'void OpenColorIO_v2_2::bindPyColorSpaceSet(pybind11::module&)': /builddir/build/BUILD/OpenColorIO-2.2.1/redhat-linux-build/docs/_doxygen/docstrings.h:14:58: error: '__doc_PyOpenColorIO_ConstColorSpaceSetRcPtr_operator_sub' was not declared in this scope 14 | #define __DOC4(n1, n2, n3, n4) __doc_##n1##_##n2##_##n3##_##n4 | ^~ Doxygen was updated from 1.9.6 to 1.9.7 which I would assume should be a pretty harmless update. I checked Bugzilla and there is only one bug open for doxygen which is unrelated. Anyone else noticed any issues? OpenColorIO version has not changed in some time... Thanks, Richard [1] https://koschei.fedoraproject.org/package/OpenColorIO?collection=f39 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
SPDX identifier for Expat license?
So subject kind of says it all, but to follow up, when I google Fedora known good licenses I get this: https://fedoraproject.org/wiki/Licensing:Main#SoftwareLicenses Which uses the old license identifiers, so there's that. And licensecheck is a PITA because I have to always add "--shortname-scheme=spdx" and it still doesn't give it to us in the format we want. Sure I could make my own script or alias to do this, and I hate to be a broken record but maybe people would adopt the new format faster if we gave them the tools to make it easy. I have about 5% of the time I used to be able to devote to packaging these days. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - ZX Spectrum edition
On Sun, Apr 23, 2023 at 4:09 AM Miroslav Suchý wrote: > New version of fedora-license-data and license-validate has been released. > > NEW: the package fedora-license-data now contains BNF grammar which you > can use. It is available in `/usr/share/fedora-license-data/grammar.lark` > You'll have to explain to me the significance of this. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: It’s time to transform the Fedora devel list into something new
On Fri, Apr 21, 2023 at 3:39 PM Ben Cotton wrote: > On Fri, Apr 21, 2023 at 4:05 PM Maxwell G wrote: > > > > What evidence shows that the group is ever shrinking? I often see Self > > Introduction posts and new people interacting with project. I suppose > > that whether they continue interacting afterwards is another question. > > I'm glad you asked. Earlier this week I decided to avoid doing other > work by putting together some quick charts of devel list > participation. Here's the number of unique participants per month from > 2004–2022: > https://bcotton.fedorapeople.org/images/devel-participation-monthly.png > > And for a less-noisy version, the median of the monthly numbers per year: > https://bcotton.fedorapeople.org/images/devel-participation-mean.png And on discourse you could have pasted these pictures directly in without having to upload them somewhere... ;) > There are a lot of questions left unanswered by this quick analysis, > but there's a clear trend in fewer participants over time. In fact, > last month had the second smallest participant count (tied with > October 2022). Of course, these charts don't show _why_, but they do > support the assertion that folks are dropping out of the conversation > faster than others are joining. > I think this is especially concerning because Fedora seems to be more popular than ever. If we had a way to measure that and include it in the graph (devel participants as a % of users?) I have a feeling the slope would be much more negative. Not that it proves Discourse would change that, but still... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: It’s time to transform the Fedora devel list into something new
Not quoting anything in particular, just my opinion and a +1. Being a solid Gen X'er I'm comfortable in both worlds. I will say that I've found the large volume of emails between Fedora and MythTV (though it's slowed in the last few years) occasionally overwhelming. The first thing I do almost every morning (still in my PJs with a cup of coffee) is to go through all the threads, archive what I'm not interested in, but keep just in case, and read the others. In my work world I frequently find myself in Discourse (or similar) forums, and I find it easy enough to find what I'm looking for, or if there's new threads or replies to threads I've posted to (usually at the top). A few months ago I spent a few hours cleaning up old emails in gmail because google (the search engine) lies. I perfected a query to only return list emails older than 1 year but even though I checked "include all emails" it would only delete about 500 at a time. Took a while to work through my 10+ year history as a packager 500 emails at a time! The reality is the future potential contributors are used to tools like Discourse. That's fine. I'll adapt. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX: Consistency of tools
On Tue, Apr 4, 2023 at 12:45 AM Miroslav Suchý wrote:
> Dne 04. 04. 23 v 3:20 Richard Shaw napsal(a):
>
> I have updated my licensecount script which summarises the licenses in a
> source and uses licensecheck to output SPDX licenses instead, but they
> output the "short" form as far as I can tell, not the form that we want in
> the SPEC file.
>
> Try:
>
> licensecheck --shortname-scheme=spdx -r .
>
> this gives me *almost* the wanted result:
>
> ./rpmconf.spec: *No copyright* GPL-3
> ./bin/rpmconf: GPL-3.0-or-later
> ./rpmconf/rpmconf.py: GPL-3.0-or-later
>
> Last two lines are correct. The first line still use the short form. I
> consider it a isolated bug of licensecheck - feel free to report issue
> there.
>
Weird, that's the option I added but my output is different. I recently
updated... Is there some kind of supplementary package I need to install?
$ cat /usr/local/bin/licensecount
#!/bin/bash
if [ $# -eq 0 ]
then dir=$pwd
else
dir=$1
fi
licensecheck --shortname-scheme=spdx -rm $dir | awk '{FS="\t"; print $2;}'
| sort | uniq -c | sort -gr
> Additionally, spectool does not complain that the short format for the
> license is used.
>
> I think that spectool does not complain about anything. Unless it is fatal
> parsing error. We have rpmlint and rpminspect for that. AFAIK both tool has
> been already migrated and will complain when you use short format.
>
Yeah...I should have gone to bed by then. I meant to use rpmlint. But it
still doesn't complain. For abi-compliance-checker:
$ grep License: *.spec
License:LGPL-2.1+
$ rpmlint *.spec
rpmlint session starts
===
rpmlint: 2.4.0
configuration:
/usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
/etc/xdg/rpmlint/fedora-legacy-licenses.toml
/etc/xdg/rpmlint/fedora-spdx-licenses.toml
/etc/xdg/rpmlint/fedora.toml
/etc/xdg/rpmlint/scoring.toml
/etc/xdg/rpmlint/users-groups.toml
/etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 1
If I can at least get these to problems fixed I don't mind resuming my
efforts.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
SPDX: Consistency of tools
WARNING: This is a small rant... I have tried to keep up with the emails on the devel list around this but I admit that I haven't been able to devote the time to GROK them all. I decided to look up my packages on src.fedoraproject.org (I'm still not sure if it's showing me all packages I'm admin of, or just main admin) and start working through them one by one. I have updated my licensecount script which summarises the licenses in a source and uses licensecheck to output SPDX licenses instead, but they output the "short" form as far as I can tell, not the form that we want in the SPEC file. For example in abi-dumper after executing `fedpkg prep` and cd'ing into the source directory I get: $ licensecount . 5 UNKNOWN 1 LGPL-2.1+ 1 LGPL-2.1 1 GPL But my current understanding is that the correct application (after inspecting what sources actually go into the resultant package) would be "LGPL-2.1-or-later". Additionally, spectool does not complain that the short format for the license is used. While no matter what we do, there are maintainers that are not going to proactively update their packages, until we unify the tools and documentation to "do the right thing", we're pissing in the wind. Googling only found: https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_process_used When we have consistent tools and documentation I will resume my efforts to update my package. On a side note, I keep seeing the statistics around what packages can be "trivially" converted to SPDX format, but I really think this is an opportunity to re-evaluate the licences on all packages to make sure they're correct. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Proposed integrated mingw packaging guidelines [Re: Planning to start unifying native and mingw packages]
On Wed, Mar 1, 2023 at 7:45 AM Daniel P. Berrangé wrote: > > Fast forward 6 months and evidentally no one else was enthusiastic about > updating the MinGW packaging guidelines, so I've taken on that task myself > :-) > Thanks for volunteering! I converted one of my packages but honestly I've had so little time for packaging that just keeping mine up to date has used all my spare cycles. PRs welcome! Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20
On Wed, Feb 22, 2023 at 6:05 PM Miro Hrončok wrote: > On 23. 02. 23 0:56, Richard Shaw wrote: > > On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers > <mailto:trodg...@redhat.com>> wrote: > > > > The f39-boost side tag builds have finished. > > > > The following packages FTBFS but the build logs provide no useful > information - > > - OpenImageIO > > [[ > https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log > < > https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log%5D%5Bbuild.log > >]] > > > > > > It may be true that the build logs weren't useful, but that's because > the > > problem was in root.log. Either deps need to be analyzed to determine > rebuild > > order, or after the initial build attempts have been done, they need to > be > > repeated. > > > > root.log shows the problem: > > DEBUG util.py:443: Error: > > DEBUG util.py:443: Problem: package openvdb-devel-10.0.1-1.fc38.x86_64 > > requires libopenvdb.so.10.0()(64bit), but none of the providers can be > installed > > DEBUG util.py:443:- package openvdb-devel-10.0.1-1.fc38.x86_64 > requires > > openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be > installed > > DEBUG util.py:443:- conflicting requests > > DEBUG util.py:443:- nothing provides > libboost_iostreams.so.1.78.0()(64bit) > > needed by openvdb-libs-10.0.1-1.fc38.x86_64 > > > > I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at > this point. > > It appears openvdb wasn't rebuilt because there was a missing dependency > (imath). But is should be possible to build openvdb now. > It's building now... https://koji.fedoraproject.org/koji/taskinfo?taskID=97878135 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20
On Wed, Feb 22, 2023 at 2:52 PM Thomas Rodgers wrote: > The f39-boost side tag builds have finished. > > The following packages FTBFS but the build logs provide no useful > information - > - OpenImageIO [[ > https://kojipkgs.fedoraproject.org//work/tasks/3952/97793952/build.log][build.log > ]] > It may be true that the build logs weren't useful, but that's because the problem was in root.log. Either deps need to be analyzed to determine rebuild order, or after the initial build attempts have been done, they need to be repeated. root.log shows the problem: DEBUG util.py:443: Error: DEBUG util.py:443: Problem: package openvdb-devel-10.0.1-1.fc38.x86_64 requires libopenvdb.so.10.0()(64bit), but none of the providers can be installed DEBUG util.py:443:- package openvdb-devel-10.0.1-1.fc38.x86_64 requires openvdb-libs(x86-64) = 10.0.1-1.fc38, but none of the providers can be installed DEBUG util.py:443:- conflicting requests DEBUG util.py:443:- nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by openvdb-libs-10.0.1-1.fc38.x86_64 I'm rebuilding OpenImageIO now, assuming openvdb has been rebuilt at this point. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
openexr: Any s390x people in the house?
I currently have to disable tests for s390x[1] (and ppc64le) for likely endianess issues. Troubleshooting these is more than a little outside of my wheelhouse. I hate keeping them disabled so I wanted to see if anyone could spare a few cycles to investigate. Thanks, Richard [1] https://github.com/AcademySoftwareFoundation/openexr/issues/1175 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: s390x emulation build woes
On Sat, Feb 11, 2023 at 12:13 AM John Reiser wrote: > On 2/10/23 19:57, Richard Shaw wrote: > > So I know the s390x builders are down but I have an active BZ for tests > failing with s390x so I figured what the heck, maybe doing a local > mocbuild attempt using qemu could help here like it did with aarch64. > > > > Well at first everything seemed to be working as normal but all of the > repo package GPG checks failed. > > Almost certainly an endian problem (or two, or three). > x390x is big endian; almost everything else is little ehdian. > Run the self tests of each crypto piece using the same emulator. > Well it looks like I mis-spoke slightly late last night... the GPG check didn't fail, it's saying they aren't available: Public key for zstd-1.5.2-4.fc38.s390x.rpm is not installed. Failing package is: zstd-1.5.2-4.fc38.s390x GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-38-primary, file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-37-primary Error: GPG check FAILED Perhaps this is a branching issue, I'm F37 now and it appears to be working, albeit quite slow :) Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
s390x emulation build woes
So I know the s390x builders are down but I have an active BZ for tests failing with s390x so I figured what the heck, maybe doing a local mocbuild attempt using qemu could help here like it did with aarch64. Well at first everything seemed to be working as normal but all of the repo package GPG checks failed. I wasn't 100% sure my experiment would work but I didn't expect that to be the failure mode. Any hints? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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] Planning to retire wxGTK3 (wxWidgets 3.0)
On Fri, Feb 10, 2023 at 9:41 AM Scott Talbert wrote: > Hi all, > > What I'm unclear about is whether there are any RPM Fusion users left - > I'm unsure of how to repoquery RPM Fusion. > I have both RPM Fusion Free and Non-Free enabled and ran my "needs_rebuilding" script against all the library packages of wxGTK3 and did not discover any additional dependencies. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Hints for manual upgrading from CentOS 8 Stream to CentOS / Alma / Rockey 9
I know upgrades are not supported but its for a small home server that really only does two things: BackupPC and Unifi (which I both maintain) Anyone had success doing manual upgrades or did you start with a reinstall? Thanks, Richard ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 38 mass rebuild is finished
On Tue, Jan 24, 2023 at 7:20 AM Richard Shaw wrote: > hobbes1069 (9): > cqrlog - Fails for some weird lazbuild issue I don't understand > flnet - Spec conditional oops. Fixed. > flrig - Needed cstdint. Fixed > freecad - Needs cstdint. Working on it. > gmsh - Needed cstdint. Fixed. > openCOLLADA - error: possibly dangling reference to a temporary. Don't > know how to fix this one. > opencascade - error: declaration of 'tbb::task& > tbb::internal::task_prefix::task()' changes meaning of 'task' > openexr - Needed cstdint. Fixed. > spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30 > I think I've gotten everything situated except openCOLLADA. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 38 mass rebuild is finished
hobbes1069 (9): cqrlog - Fails for some weird lazbuild issue I don't understand flnet - Spec conditional oops. Fixed. flrig - Needed cstdint. Fixed freecad - Needs cstdint. Working on it. gmsh - Needed cstdint. Fixed. openCOLLADA - error: possibly dangling reference to a temporary. Don't know how to fix this one. opencascade - error: declaration of 'tbb::task& tbb::internal::task_prefix::task()' changes meaning of 'task' openexr - Needed cstdint. Fixed. spnavcfg - https://github.com/FreeSpacenav/spnavcfg/issues/30 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When to close CVE's
On Fri, Jan 20, 2023 at 2:29 PM Demi Marie Obenour wrote: > > My general rule is that a security fix is worth backporting a SONAME change > for, if there is no way to backport the patch. > In this case all the Fedora branches are recent enough but EL 7 and EL 8 are not and are impractical to fix at this point. I've already been bitten in the past making major updates to EL branches. I believe this was also with OpenImageIO. Someone was using it at work for their project and had validated against the current version. Obviously in this case there is NO way to determine out of repo dependencies. The update was required to support a Review Request package so he ultimately re-validated against the newer version, but lesson learned. Since all of the severities are Medium and not High I think I will leave it as is. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When to close CVE's
On Fri, Jan 20, 2023 at 9:22 AM Gary Buhrmaster wrote: > On Fri, Jan 20, 2023 at 1:54 PM Richard Shaw wrote: > > > > So is it when a build is complete in Rawhide? Or must *ALL* active > releases get the "fix"? > > > > I am not sure it is official policy/practice, but in > theory I would think that the CVE is technically > closed when all impacted Fedora releases get > the fix, but if you use various "Resolves rhbz#1234567" > syntax in the change log (and I generally try to > do so in addition to referencing the CVE by it's > identifier) I seem to recall that as soon as the > package hits rawhide the issue gets closed. It > is therefore up to the packager to make sure they > have actually done the necessary builds/backports > to previous releases as appropriate (not all CVEs > may apply to previous Fedora releases as they > may have different package versions, of course). > I have mostly decided that in practice, as long as > I have done any appropriate builds/backports, and > one is just waiting for the usual distribution delays, > that it is good enough (although high severity > CVEs may need special handling). > > Or are you asking something different? > I think in practical terms that makes sense but our tools don't really help. Let's take the case of OpenImageIO[1][2], which is why I'm asking this question, I only update Rawhide when SONAME is bumped, so if a CVE is only fixed in the latest release, then only Rawhide, or Rawhide-1 (depending on when we branch) gets the fix. Typically in Bodhi you would mark the BZ as being fixed by the release which by default closes the bug. So I guess what I'm asking is if there is a specific policy around this? If not, should there be? Thanks, Richard [1] Actually not the best example, but the most immediate one. Upstream (Larry) is actually quite good at backporting changes when needed. [2] https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=OpenImageIO=Fedora=Fedora%20EPEL ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
When to close CVE's
So is it when a build is complete in Rawhide? Or must *ALL* active releases get the "fix"? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
On Thu, Jan 19, 2023 at 8:55 AM Michal Schorm wrote: > On Thu, Jan 19, 2023 at 3:36 PM Robbie Harwood > wrote: > > > Would you see a value in e.g. some kind of a robot reminding > > > maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI > > > check) > > > > Please don't. > > Would you mind expanding your answer a bit, please? > I'd like to learn why people would (not) like such a check or reminder. > I agree. I usually keep them around for a couple of releases especially when it has to do with preserving an upgrade path (support f-2) or for more recent EOL'd releases if someone wants to manually keep a package going for a while. But I see no purpose in keeping around conditionals for anything past 4 releases ago and I see them sometimes when rebuilding packages. I recently saw one for Fedora 24... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Bodhi slow with 504 gateway timeouts
On Tue, Jan 17, 2023 at 8:18 AM Arthur Bols wrote: > On 17/01/2023 14:57, Stephen Smoogen wrote: > > So bodhi and pagure are at different datacenters with hopefully different > > network paths. Could people do some mtr or traceroutes from their > locations > > so we can see if this can be ironed out. Currently the limited tools we > > have in Fedora Infra for checking this all show 'green' so the > > 'interconnects' between the services are working. > > > Fedora infra is usually very slow for me, but Bodhi seemed much slower > than usual (taking a full minute to load). > > After being really slow, I had a bunch of 503's (not 504) for a while, > but now it seems to work fine: > - /releases takes 10 seconds (and had a 500 error once) > - /updates seems fast with 2.2 seconds > I had some slow issues before the update to Bodhi but it looks like now I'm getting a different route and Bodhi is nice and snappy for me now. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Bodhi slow with 504 gateway timeouts
On Tue, Jan 17, 2023 at 7:58 AM Stephen Smoogen wrote: > > On Tue, 17 Jan 2023 at 08:55, Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > >> On Tue, Jan 17, 2023 at 07:49:48AM -0600, Richard Shaw wrote: >> > On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar wrote: >> > >> > > V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a): >> > > > Is anyone but me experiencing this? I want to know before I call C >> Spire. >> > > > >> > > Since yesterday I randomly experience long delays between sending a >> query >> > > and >> > > receiving the response. However, no HTTP errors. >> > > >> > >> > I only got the timeout once, but it's been very slow and not properly >> > loading completely. I'm trying bodhi command line for an update and >> having >> > similar issues but I think my update did finally get created though. >> > >> > One of the attempts from the command line it spit back HTML saying >> > "Application is not available". >> >> Bodhi is slow for me. Some pages loaded slowly and without icons and >> stuff. But >> I also had timeouts on pagure.io today, so I was suspecting some network >> issue. >> >> > So bodhi and pagure are at different datacenters with hopefully different > network paths. Could people do some mtr or traceroutes from their locations > so we can see if this can be ironed out. Currently the limited tools we > have in Fedora Infra for checking this all show 'green' so the > 'interconnects' between the services are working. > Does this help? Host Loss% Snt Last Avg Best Wrst StDev 1. _gateway1.5% 134 0.3 0.4 0.2 3.5 0.3 2. 136.239.67.3.static.cspire.com 0.0% 134 7.0 8.7 6.3 58.1 7.2 3. et-1-1-5.SKVLAR01.cspire.net0.0% 134 7.7 9.4 6.8 34.7 3.9 4. 198.28.137.84 0.0% 134 10.2 10.7 9.5 11.9 0.4 5. et-0-1-1.jcsncr01.cspire.net0.0% 134 11.0 11.7 9.9 47.2 4.3 6. hu0-0-0-0.rcr51.jan01.atlas.cogentco.com0.0% 134 10.4 10.5 9.5 11.6 0.3 7. be3520.rcr21.msy01.atlas.cogentco.com 0.0% 134 14.8 14.9 14.0 18.6 0.5 8. be3302.ccr42.iah01.atlas.cogentco.com 0.0% 134 21.5 23.7 20.7 76.2 8.1 9. be2418.rcr51.b023723-0.iah01.atlas.cogentco.com 0.0% 134 23.0 23.0 21.9 25.2 0.4 10. telia.iah01.atlas.cogentco.com 6.0% 134 49.9 23.2 21.0 51.8 5.0 11. dls-b24-link.ip.twelve99.net0.0% 134 31.6 31.5 30.6 32.4 0.3 12. dls-bb2-link.ip.twelve99.net 78.2% 134 29.6 29.8 28.7 30.5 0.4 13. (waiting for reply) 14. viawest-svc067149-ic350576.ip.twelve99-cust.net 0.0% 134 32.3 32.2 31.4 37.5 0.5 15. be23.bbrt01.dal01.flexential.net0.0% 134 49.1 49.1 48.2 49.9 0.2 16. be136.bbrt01.atl10.flexential.net 0.0% 134 49.2 49.3 48.4 55.5 0.6 17. be10.bbrt02.atl10.flexential.net0.0% 134 49.4 49.8 48.5 50.6 0.4 18. be166.bbrt01.atl03.flexential.net 0.0% 134 49.2 49.4 48.4 57.9 0.8 19. be170.bbrt02.clt01.flexential.net 0.0% 134 49.6 49.7 48.8 50.7 0.2 20. be10.bbrt01.clt01.flexential.net0.0% 133 49.6 49.8 48.8 56.3 0.6 21. be184.bbrt01.ral01.flexential.net 0.0% 133 49.3 49.4 48.6 50.3 0.3 22. be31.crrt01.ral01.flexential.net0.0% 133 49.4 49.7 48.7 51.1 0.4 23. 128.136.224.140 0.0% 133 47.1 53.9 46.4 89.2 10.5 24. 8.43.84.1 0.0% 133 53.0 73.2 53.0 172.1 18.1 25. 8.43.84.3 0.8% 133 47.8 53.2 46.8 91.7 10.3 26. 8.43.84.4 1.5% 133 69.4 77.6 53.3 176.2 25.6 27. ip-8-43-86-126.foo.bar 0.8% 133 50.7 71.7 48.6 226.7 36.6 28. proxy14.fedoraproject.org 0.8% 133 48.2 53.1 47.4 81.8 8.6 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Bodhi slow with 504 gateway timeouts
On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar wrote: > V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a): > > Is anyone but me experiencing this? I want to know before I call C Spire. > > > Since yesterday I randomly experience long delays between sending a query > and > receiving the response. However, no HTTP errors. > I only got the timeout once, but it's been very slow and not properly loading completely. I'm trying bodhi command line for an update and having similar issues but I think my update did finally get created though. One of the attempts from the command line it spit back HTML saying "Application is not available". Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bodhi slow with 504 gateway timeouts
Is anyone but me experiencing this? I want to know before I call C Spire. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Use cases for 'fedpkg scratch-build'
On Mon, Jan 16, 2023 at 8:06 AM Miro Hrončok wrote: > On 16. 01. 23 14:57, Richard Shaw wrote: > > > > Since `fedpkg scratch-build` bombs out with an error if you've made > local > > changes I propose a slight modification: > > > > If no changes are made then it does a normal scratch build for the "does > this > > still build / not build" 1% use case > > > > If there are local changes it automatically uploads an SRPM for the 99% > use case. > > I love this. > > $ fedpkg scratchbuild / $ fedpkg build --scratch > Uncommitted changes found, uploading SRPM... > > > If you end up in a weird state, i.e. made changes but for some reason > want to > > do a "normal" scratch build you have a few different ways to accomplish > that. > > That was already impossible: > > $ fedpkg --release rawhide scratch-build > Could not execute scratch_build: .../python3.9 has uncommitted changes. > Use > git status to see details > Try option --srpm to make scratch build from local changes. > Someone mentioned it's possible to specify a specific commit to build from? I don't know I haven't tried. The other option which is what I would use would to use `git stash` / scratch build / `git stash apply`. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Use cases for 'fedpkg scratch-build'
On Mon, Jan 16, 2023 at 3:38 AM Sandro wrote: > On 16-01-2023 08:56, Otto Liljalaakso wrote: > > Above change seems like a clear improvement to me, making the most used > > option the default. But I have noticed that workflows differ wildly > > between packagers, so before submitting any code for review, I would > > like to hear if somebody regularly uses the default form 'fedpkg > > scratch-build' and thinks it currently does the right thing. > > +1 for the PR. > > So far I haven't used the scratch-build command. I always use build, > since I need to supply extra options anyway to start a scratch build > from local HEAD. This change would make me use the scratch-build command > instead. > Since `fedpkg scratch-build` bombs out with an error if you've made local changes I propose a slight modification: If no changes are made then it does a normal scratch build for the "does this still build / not build" 1% use case If there are local changes it automatically uploads an SRPM for the 99% use case. If you end up in a weird state, i.e. made changes but for some reason want to do a "normal" scratch build you have a few different ways to accomplish that. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: libharu 2.4.3, mathgl 8.0.1, vtk 9.2.5 update coming to rawhide soon
On Sat, Jan 14, 2023 at 10:31 AM Orion Poplawski wrote: > On 1/9/23 07:43, Orion Poplawski wrote: > > I'm hoping to start updating libharu to 2.4.3, mathgl to 8.0.1, and vtk > > to 9.2.5 at the end of this week. Builds will be done in a side tag. > > Test builds are being done here: > > > > https://copr.fedorainfracloud.org/coprs/orion/libharu2.4/builds/ > > This is starting in f38-build-side-61967. There are some issues with > opencascade and mayavi, but I'm hopeful that they will be able to get > addressed relatively soon. > Careful, I just built opencascade 7.6.3 which is in Rawhide. Hopefully that helps? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: opencascade 7.6.3 coming to all releases
Unfortunately there are some bugs in the current version of Fedora causing serious usability issues for users of FreeCAD (not sure about other dependencies) that require all released versions of Fedora be updated. I'm currently about 80% through testing builds in COPR first and when complete will start with Rawhide and then work my way down. To minimize the time the side tag is open I will complete one before moving to the next. Affected packages: netgen-mesher smesh freecad gmsh kicad Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: New OpenColorIO 2.2 with soname bump
It appears that all the dependent packages are now compatible (i.e., they build). The plan is to build them in a side tag over the next few days. The dependencies are: OpenImageIO usd blender krita luxcorerender Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenColorIO 2.2.x coming to Rawhide
All dependent packages have successfully rebuilt in COPR and will be completed in a side tag. The following dependencies will be rebuilt: OpenImageIO usd blender krita luxcorerender Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Tue, Jan 10, 2023 at 11:48 AM Miro Hrončok wrote: > On 10. 01. 23 13:52, Richard Shaw wrote: > > Second, how exactly are you building the package? > > Looking at [1], you used "Source Type: SRPM or .spec file upload". > > How was it generated? > > > > [1] > https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/ > > < > https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/> > > > > Both 'fedpkg srpm' and uploading that to copr, and letting copr > build from > > dist-git should result in the expected release. (Though without > other steps > > it'll still be the same as the version in Fedora release, so you'll > need > > to tell dnf to install that specific build.) > > > > > > Looks like the problem is using `rpkg` but that's the easiest method and > has > > worked great until now... > > For the record I've reported several issues with the rpkg method over the > years. The distgit method was partially a response for those. tl;dr rpkg > "works > great" until it doesn't because it does not work like fedpkg, but instead > it is > a pre-processor for templated spec files that happens to work in most of > the > cases with bare spec files as well. > I didn't realize the fedpkg had grown the ability to do COPR builds. I will use that from now on. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Automation of Fedora SCM requests
On Tue, Jan 10, 2023 at 5:26 AM Michal Konecny wrote: > Hi everyone, > > this automation is now in place and new SCM requests will be processed > automatically. If you find any issue with the automation, please report it > to toddlers issue tracker [0]. > > On behalf of CPE Team, > Michal > > [0] - https://pagure.io/fedora-infra/toddlers/issues > While I'm hopeful I can find this email if needed but it would be better if this was documented here (and wherever else appropriate): https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote: > > Now I'm getting bit by the rpmautospec and COPR issue. > > Please be more precise. How are you building the rpms? > The SRPMS? I'm using "rpkg build " > If rpmautospec is used in COPR, and the build is started in a > compatible way, the release field should be the same as in koji. > > > I'm trying to test rebuilds of all dependent packages for a new > OpenColorIO > > release, but usd uses rpmautospec and in Fedora it's usd--16 but > > COPR is calculating it as usd--9 so the Fedora version has a > > higher NEVR. > > First of all, if you e.g. want to test the rebuilt packages on your system, > you can always install a lower version than the one currently released. > Dnf allows both downgrades and installations of a specific package and > a specific package version. > I don't want to test the packages per say, I just need COPR to pull in the rebuilt package instead of the one in Fedora, otherwise I get dnf conflicts: Problem: package usd-libs-22.05b-16.fc38.x86_64 requires libOpenColorIO.so.2.1()(64bit), but none of the providers can be installed - cannot install both OpenColorIO-2.1.2-5.fc38.1.x86_64 and OpenColorIO-2.2.0-1.fc38.x86_64 - package usd-devel-22.05b-16.fc38.x86_64 requires usd-libs(x86-64) = 22.05b-16.fc38, but none of the providers can be installed - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires libOpenColorIO.so.2.2()(64bit), but none of the providers can be installed - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires OpenColorIO(x86-64) = 2.2.0-1.fc38, but none of the providers can be installed - cannot install the best candidate for the job > Second, how exactly are you building the package? > Looking at [1], you used "Source Type: SRPM or .spec file upload". > How was it generated? > > [1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/ > > Both 'fedpkg srpm' and uploading that to copr, and letting copr build from > dist-git should result in the expected release. (Though without other steps > it'll still be the same as the version in Fedora release, so you'll need > to tell dnf to install that specific build.) > Looks like the problem is using `rpkg` but that's the easiest method and has worked great until now... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
Now I'm getting bit by the rpmautospec and COPR issue. I'm trying to test rebuilds of all dependent packages for a new OpenColorIO release, but usd uses rpmautospec and in Fedora it's usd--16 but COPR is calculating it as usd--9 so the Fedora version has a higher NEVR. Now what am I supposed to do? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote: > > * Vitaly Zaitsev via devel: > > > > > On 30/12/2022 20:01, Ben Cotton wrote: > > >> This document represents a proposed Change. As part of the Changes > > >> process, proposals are publicly announced in order to receive > > >> community feedback. This proposal will only be implemented if approved > > >> by the Fedora Engineering Steering Committee. > > > > > > -1 until these known issues[1] are fixed, especially with changelogs > > > and using rpmautospec in COPR or mock. > > > > > > [1]: > > > > https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known-constraints > > > > The page doesnt discuss COPR/mock? > > > > COPR seems to work in some cases, specifically with the dist-git build > > (but not just building from dist-git). > > > > A quick check suggests that rpmautospec does the right thing and > > produces a portable source RPM that doesn't depend on rpmautospec > > anymore. As a result, the compatibility impact won't be too severe, I > > hope. > > Also mock builds seem fine. I tested this now on F37 with a few different > scenarios: > - fedpkg mockbuild > - git commit --allow-empty -m Rebuild && fedpkg mockbuild > - fedpkg srpm && mock *.src.rpm > seem to generate the expected versions numbers and changelogs. > This is my problem with the proposal. Our tools haven't been fully integrated. For a typical update I do not need to run git directly, but for this workflow I do. For a typical bump all I need is: rpmdev-bumpspec -c "Change here" fedpkg commit -c -p fedpkg build Our tools need to handle this automagically. I shouldn't have to know I need to add "--allow-empty". It should just work. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Source download behind login?
On Wed, Dec 28, 2022 at 2:57 PM Richard Shaw wrote:
> On Wed, Dec 28, 2022 at 12:38 PM Ian McInerney via devel <
> devel@lists.fedoraproject.org> wrote:
>
>>
>> On Wed, Dec 28, 2022 at 5:42 PM Richard Shaw
>> wrote:
>>
>>> I'm working on updating the opencasecade package[1] but the main
>>> downloads require a login.
>>>
>>>
>> Is there a specific reason it needs to be their premade tarballs? If not,
>> it looks like you should be able to pull the tarball from the tag in their
>> git repo, which appears to be public.
>>
>> The git repo is here: https://git.dev.opencascade.org/gitweb/?p=occt.git
>> The link to pull the tarballs should be something like: "https://git.dev.
>> opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz"
>> (where you can replace the tag as needed with the one for the version
>> required)
>>
>
> That works for a browser, but I need a direct link with an archive name,
> no redirects. I tried appending #/%{name}-%{version}.tar.gz to the end like
> I used to have to do with github but it doesn't work...
>
>
> https://git.dev.opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz#/opencascade-7.7.0.tgz
>
> I tried looking for documentation for git-scm for what url options are
> available but didn't have any luck.
>
Scratch that... I'm on an iffy SSH connection and didn't notice it hang, it
did download.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
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: Source download behind login?
On Wed, Dec 28, 2022 at 12:38 PM Ian McInerney via devel <
devel@lists.fedoraproject.org> wrote:
>
> On Wed, Dec 28, 2022 at 5:42 PM Richard Shaw wrote:
>
>> I'm working on updating the opencasecade package[1] but the main
>> downloads require a login.
>>
>>
> Is there a specific reason it needs to be their premade tarballs? If not,
> it looks like you should be able to pull the tarball from the tag in their
> git repo, which appears to be public.
>
> The git repo is here: https://git.dev.opencascade.org/gitweb/?p=occt.git
> The link to pull the tarballs should be something like: "https://git.dev.
> opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz"
> (where you can replace the tag as needed with the one for the version
> required)
>
That works for a browser, but I need a direct link with an archive name, no
redirects. I tried appending #/%{name}-%{version}.tar.gz to the end like I
used to have to do with github but it doesn't work...
https://git.dev.opencascade.org/gitweb/?p=occt.git;a=snapshot;h=refs/tags/V7_7_0;sf=tgz#/opencascade-7.7.0.tgz
I tried looking for documentation for git-scm for what url options are
available but didn't have any luck.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Source download behind login?
I'm working on updating the opencasecade package[1] but the main downloads require a login. I tried moving to a mirror (or what I thought was a mirror) on github but discovered that the releases are not in sync. I guess I could download the source and then reupload to fedorapeople.org but that seems less than ideal. Ideas? Thanks, Richard [1] https://bugzilla.redhat.com/show_bug.cgi?id=2137719 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
dnf system-upgrade f36->f37: mlocate / plocate conflict
On my laptop when I tried to do a dnf system-upgrade from f36->37 I ended up getting a conflict with mlocate and plocate. Since I remember the thread I just did a "dnf swap" which solved the issue but it could be confusing to users not aware. Was this supposed to happen automagically? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Unannounced SONAME bump: wxGTK
On Thu, Dec 22, 2022 at 8:17 AM Scott Talbert wrote: > On Thu, 22 Dec 2022, Ian McInerney via devel wrote: > > > > > > > On Thu, Dec 22, 2022 at 1:55 PM Richard Shaw > wrote: > > I just had a chance to check out a bug[1] recently submitted > > against trustedqsl and it appears that a new version of wxGTK > > with a SONAME bump was built for f37+ but not all dependencies > > rebuilt. > > > > > > This was announced back in July while F37 was still Rawhide: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > /thread/PD3EWAYG6HGKSWU5T337AXU4ONSK53VZ/#LYLHTVJQMLOWFFRB25MVM4S4726KPWMR > > > > > > And looking at the commit history for the F37 branch of trustedqsl, it > has a > > commit referencing the wxGTK 3.2 version bump: > > https://src.fedoraproject.org/rpms/trustedqsl/commits/f37, and that was > > before the update you did to version 2.6.4. The build for 2.6.4 on F37( > https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.6.4/1.fc37/data/ > > logs/x86_64/build.log) also seems to have pulled the wxWidgets 3.2 dep > > correctly, with CMake reporting: > > > > Found wxWidgets: > -pthread;;;-lwx_gtk3u_core-3.2;-lwx_baseu-3.2;-lwx_gtk3u_ht > > ml-3.2 (found version "3.2.0") > > and the RPM dependency generator showing > > > > libwx_baseu-3.2.so.0()(64bit) libwx_baseu-3.2.so.0(WXU_3.2)(64bit) > libwx_gtk > > 3u_core-3.2.so.0()(64bit) libwx_gtk3u_core-3.2.so.0(WXU_3.2)(64bit) > libwx_gt > > k3u_html-3.2.so.0()(64bit) libwx_gtk3u_html-3.2.so.0(WXU_3.2)(64bit) > > > > I am therefore very confused how the user could have 2.6.4 with a 3.1.5 > > dependency when the koji build for 2.6.4-1 shows wxGTK 3.2 in the > buildroot > > and as a dependency. > > Agreed ^^^ > Ok, just weird then ¯\_(ツ)_/¯ Committed but never built somehow? I don't see the rebuild attempt: https://koji.fedoraproject.org/koji/packageinfo?packageID=6950 Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Unannounced SONAME bump: wxGTK
I just had a chance to check out a bug[1] recently submitted against trustedqsl and it appears that a new version of wxGTK with a SONAME bump was built for f37+ but not all dependencies rebuilt. I'm not too worried about trustedqsl since I'm about to take care of the build but it does have a long dependency list and I'm unsure whether the other builds have been completed: 0ad 4Pane audacity boinc-client CubicSDR diff-pdf erlang extrema fityk flamerobin freedink-dfarc freedv fwknop-gui gnuplot guayadeque hugin iaxclient kicad mathgl mediainfo mrpt openbabel openmsx OpenSceneGraph p7zip panoglview pcem phd2 plplot poedit python-wxpython4 rapidsvn saga scorched3d scummvm-tools sooperlooper spatialite-gui springlobby trustedqsl ucblogo vavoom visualboyadvance-m wxmacmolplt wxsqlite3 xchm xmlcopyeditor xylib Thanks, Richard [1] https://bugzilla.redhat.com/show_bug.cgi?id=2154622 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Advent edition
On Fri, Dec 16, 2022 at 8:52 AM Miroslav Suchý wrote: > The list of packages needed to be converted is again here: > > > https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt > I appreciate the effort so I hate to ask, but can we get a similar list but grouped by maintainer? I don't have a lot of free time these days and it would make my life easier :) Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Accidental conflicting packages: python mysql client
On Thu, Dec 15, 2022 at 11:57 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Mon, Dec 12, 2022 at 09:57:01PM -0600, Richard Shaw wrote: > > There's a python-mysql and python-mysqlclient packages and it's been an > > issue for a while but now causing upgrade issues. > > > > Can we get some help in BZ: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1929101 > > > > Please make sure I have not mis-spoken. > > Yes, Obsoletes/Provides should be added. This can (and should) be done > even in released Fedora (36, 37), and then the old package retired. > Since this is causing problems during upgrade paths, it'd be great to > do this quickly. > > Please let me know if you need some provenpackager help. > I'm PP as well, but it looked like the package owners were somewhat involved in the BZ ticket so I was hesitant to interfere, but that hasn't led to action as of yet... Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Accidental conflicting packages: python mysql client
There's a python-mysql and python-mysqlclient packages and it's been an issue for a while but now causing upgrade issues. Can we get some help in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1929101 Please make sure I have not mis-spoken. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: ImageMagick7
On Sun, Dec 4, 2022 at 6:32 PM Sérgio Basto wrote: > Final statement, instead of wasting my time and energy on arguments, > Imagemagick7 could already be built on rawhide if someone had done the > package review for me > I understand the sentiment as another person who has donated 1000s of hours to packaging on Fedora, but the "default" package SHOULD be the current latest package. It' just part of "Fedora First". So my vote (as much as it matters) is that all packages should be built with the latest version in COPR to verify compatibility, and the ones that don't, build with an ImageMagik 6 compat package. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: ImageMagick7
On Fri, Dec 2, 2022 at 5:31 PM Sérgio Basto wrote: > Hi, > > I think it's important to bring ImageMagick 7 to Fedora, and it should > have been done a long time ago . > The proposal now is to keep ImageMagick 6 and make a new package with > ImageMagick 7 , when we have all applications use only ImageMagick 7, > we move the sources from ImageMagick7 to ImageMagick > > https://bugzilla.redhat.com/show_bug.cgi?id=2150206 Wouldn't the correct way to handle this be to create an ImageMagick6 compat package and update the main package to version 7? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Fri, Dec 2, 2022 at 3:30 PM Adam Williamson wrote: > > What does everyone else think? Has the time come? Or is there more we > need to do to make side tags usable for all cases before getting rid of > overrides? > I wasn't aware of the CI issues so that seems like the last nail in the coffin. The only time I've used one recently is because I forgot about a package dependency and it was easier to create a buildroot override than look up how to re-tag the build into a side tag. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenCOLLADA dead upstream
On Fri, Dec 2, 2022 at 12:51 AM Luya Tshimbalanga wrote: > On 2022-11-30 17:55, Richard Shaw wrote: > > So it looks like the last commit was in 2018: > > https://github.com/KhronosGroup/OpenCOLLADA > > Before we go ripping it out of Fedora, is anyone aware of another active > upstream we can port to? > > A fork version is available on > https://github.com/RemiArnaud/OpenCOLLADA/releases > Thanks! That's very helpful. Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: OpenCOLLADA dead upstream
On Wed, Nov 30, 2022 at 10:28 PM Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote: > Richard Shaw wrote: > > Before we go ripping it out of Fedora, > > Just because a project is dead upstream does not mean it has to be removed > from Fedora. > No, but it will become more and more difficult to maintain. Right now it needs to be ported from pcre to pcre2 which is beyond my capabilities. That being said, I don't have immediate plans to orphan/retire but wanted to start the conversation before it was an issue. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
OpenCOLLADA dead upstream
So it looks like the last commit was in 2018: https://github.com/KhronosGroup/OpenCOLLADA Before we go ripping it out of Fedora, is anyone aware of another active upstream we can port to? It's a shame as this was one of my first (if not my first) projects I packaged for Fedora over 10 years ago. It looks like the only direct consumer is Blender (cc'd). Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Should the policy documents better reflect real package maintenance practice?
On Thu, Nov 24, 2022 at 9:12 AM Petr Pisar wrote: > V Thu, Nov 24, 2022 at 02:40:09PM +0100, Miroslav Suchý napsal(a): > > > > Does anyone else feel like the documentation should be updated, or > > > > am I making too much of this? > > > > +1 to update documentation. Or even better, document which packages has > the > > exception. And later ask QE to create tool which will warn if packages > > outside of this list bump up version. > > > Checking for a version bump does not make sense unless you want to force > maintainers to backport each fix. (Nonpaid maintainers won't do it.) > +1000... Also, I think keeping the version the same and adding a bunch of upstream commits that essentially makes it the new version is fundamentally dishonest. Plus if you do need to report a bug upstream, which version is it? There's not really an option for "Frankenstein". My packaging philosophy has largely been, try not to perform soname bumps in released versions unless absolutely necessary, and most people want the latest version of user facing apps. Also, most upstreams of my user facing app packages release incrementally and frequently. If I didn't update them, I could easily be 10 releases behind between Fedora releases. That doesn't make sense. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: yaml-cpp 0.7.0 soname bump for Rawhide is complete
On Tue, Nov 15, 2022 at 5:19 PM Mamoru TASAKA wrote: > Richard Shaw wrote on 2022/11/16 1:10: > > I had to back off updating OpenColorIO as it needed a newer version of > > minizip-ng than what's available. > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-518f2de934 > > > > The only fallout is supercollider which failed to build for other > reasons: > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2085987 > > supercollider is fixed in -7, backporting upstream fix for libsndfile > 1.1.x . > https://koji.fedoraproject.org/koji/buildinfo?buildID=2089036 > > repoquery says cantera also needs rebuilding for new yaml-cpp, so it's > done. > Thanks for following up! Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: koji down?
On Wed, Nov 16, 2022 at 11:32 AM Kevin Fenzi wrote: > Everything should be back up now... > > I'm watching it for a bit before I declare things are back fully to > normal though. ;) > > Do note that mailing list threads aren't a great place to report > outages. Please report them to the infrastructure ticket tracker: > https://pagure.io/fedora-infrastructure/ I recently switched internet providers so I was looking for an ACK that it wasn't just me. But on a related note, it can be somewhat difficult to remember all the different sites and which is appropriate for what when you don't deal with them on a regular basis.. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: 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: Are open codecs accelerated on F37? - was: Re: Mesa in F37- vaapi support disabled for h264/h265/vc1
On Wed, Nov 16, 2022 at 3:19 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Wednesday, 16 November 2022 at 09:22, Vitaly Zaitsev via devel wrote: > > On 15/11/2022 23:25, Gordon Messmer wrote: > > > I had thought that the Fedora 37 mesa packages retained accelerated > > > video for open codecs (for AMD hardware) > > > > To accelerate H.264/H.265, you need to replace the stripped Fedora > > versions with the full versions from the RPM Fusion repository: > > > > sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld --allowerasing > > sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld > --allowerasing > > > > > However, the Fedora wiki[1] indicates that even open codecs are no > > > longer accelerated without third party packages. Is that true? > > > > On Intel, you need to install the libva-intel-driver (i915) and > > intel-media-driver (iHD) packages. > > Actually, it's either one or the other as they don't support the same > CPUs. iHD driver is for Broadwell or newer CPUs, and the i915 is for > older ones (Ice Lake is the first one it doesn't support). See > > https://fedoraproject.org/wiki/Firefox_Hardware_acceleration#Configure_VA-API_Video_decoding_on_Intel > https://wiki.archlinux.org/title/Hardware_video_acceleration#VA-API_drivers The fact that it's this confusing on the -devel list means it's going to be VERY confusing to end users. We need good documentation, which unfortunately has been one of our weak points, and it needs to be broadcasted everywhere. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
