Hello, Please note that this comment was generated automatically. If you feel that this output has mistakes, please contact me via email (mhroncok). Your package (pyparted) Fails To Install in Fedora 37: can't install python3-pyparted: - nothing provides python(abi) = 3.10 needed by python3-pyparted-1:3.12.0-2.fc37.x86_64 If you know about this problem and are planning on fixing it, please acknowledge so by setting the bug status to ASSIGNED. If you don't have time to maintain this package, consider orphaning it, so maintainers of dependent packages realize the problem. If you don't react accordingly to the policy for FTBFS/FTI bugs (https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/), your package may be orphaned in 8+ weeks. P.S. The data was generated solely from koji buildroot, so it might be newer than the latest compose or the content on mirrors. To reproduce, use the koji/local repo only, e.g. in mock: $ mock -r fedora-37-x86_64 --disablerepo='*' --enablerepo=local install python3-pyparted P.P.S. If this bug has been reported in the middle of upgrading multiple dependent packages, please consider using side tags: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages Thanks!
This bugzilla is likely a fallout from the Python 3.11 rebuild. If your package (or some of the dependencies it has) failed to rebuild during the Python 3.11 rebuild, they now fail to install. To fix this, packages need to be rebuilt in Rawhide. We will slowly triage the bugzillas, but we'd appreciate your help. If you know this is blocked by an existing reported build failure or another package not yet rebuilt with Python 3.11, please mark it as such by using the "Depends On"/"Blocks" bugzilla fields. That will help us determine what failures to prioritize. If this is not Python 3.11 related, please remove the PYTHON3.11 blocking tracker. Thank you and sorry for the inconvenience. Let me know if you need any help.
pyparted failed to build for 3.11 because of a test failure: ====================================================================== FAIL: runTest (tests.test__ped_disktype.DiskTypeStrTestCase.runTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/builddir/build/BUILD/pyparted-3.12.0/py3dir/tests/test__ped_disktype.py", line 78, in runTest self.assertEqual(str(self.disktype['msdos']), '_ped.DiskType instance --\n name: msdos features: 1') ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError: '_ped.DiskType instance --\n name: msdos features: 5' != '_ped.DiskType instance --\n name: msdos features: 1' _ped.DiskType instance -- - name: msdos features: 5? ^ + name: msdos features: 1? ^ ---------------------------------------------------------------------- I'm trying to look into this now. Not actually sure if it's due to Python 3.11 or rather perhaps due to parted 3.5 (which landed in Rawhide in April). This is blocking Rawhide composes, so it's an automatic Beta blocker.
OK, this is definitely a parted 3.4 vs. parted 3.5 thing. If you reproduce what the test does with parted 3.5 installed, - import `_ped`, do `ty = _ped.disk_type_get_next()`, then keep doing this: ty = _ped.disk_type_get_next(ty) print(ty) you get the expected results at first: _ped.DiskType instance -- name: amiga features: 2 _ped.DiskType instance -- name: bsd features: 0 _ped.DiskType instance -- name: dvh features: 3 But then you hit gpt and things go sideways: _ped.DiskType instance -- name: gpt features: 10 the test expects 2, not 10. If you downgrade to parted 3.4 and do the same thing, you get: _ped.DiskType instance -- name: gpt features: 2 this is all on my laptop, running an older Rawhide, with python3-pyparted-3.12.0-2.fc37.x86_64 . It looks like the issue affects only 'gpt' and 'msdos' types, which go from 2 to 10 (gpt) and 1 to 5 (msdos). Not sure why, yet.
Ah, I think I see it. This is kinda expected: upstream commit https://git.savannah.gnu.org/cgit/parted.git/commit/?id=61b3a9733c0e0a79ccc43096642d378c8706add6 adds a couple of new features , `PED_DISK_TYPE_PARTITION_TYPE_ID` (constant 4) and `PED_DISK_TYPE_PARTITION_TYPE_UUID` (constant 8). The number we're checking here is a bitmask (in decimal), not a count. The msdos type supports PED_DISK_TYPE_PARTITION_TYPE_ID and the gpt type supports PED_DISK_TYPE_PARTITION_TYPE_UUID , so these values are correct - we add 4 to msdos (so the bitmask goes from 1 to 5) and 8 to gpt (so the bitmask goes from 2 to 10). So we just need to adjust the tests in pyparted, I guess, to expect different values depending on the parted version.
Should be fixed with https://koji.fedoraproject.org/koji/taskinfo?taskID=88508441 . I dug out a rather large underlying problem here, but we can work on that upstream, see the upstream ticket for more details.
*** Bug 2099396 has been marked as a duplicate of this bug. ***
The problem isn't with parted upstream, it's with pyparted. Which is me. I've put together a patch for pyparted today to add support for PED_DISK_TYPE_PARTITION_TYPE_ID and PED_DISK_TYPE_PARTITION_TYPE_UUID. I'm putting it in rawhide first, then will work it upstream and cut a new release of pyparted.
Uh, did you read any of the issues I filed? There turn out to be a lot of problems. I've already sent patches for both pyparted and parted. Please review https://github.com/dcantrell/pyparted/issues/91 and the PR.
You seem to have written essentially the same patch I did and replaced mine with yours, for no obvious reason. It worked for you because I already patched parted; if I had not patched parted, you would have run into the same problem I did.
(In reply to Adam Williamson from comment #8) > Uh, did you read any of the issues I filed? There turn out to be a lot of > problems. I've already sent patches for both pyparted and parted. Please > review https://github.com/dcantrell/pyparted/issues/91 and the PR. Nope, I didn't see any of that until I had done all the work on my end too. I messaged you in IRC regarding that after the fact. I didn't know you also filed issues and sent a PR as that was not clear to me when you messaged me. I started talking with Brian and working through the problem. Sorry.