completly breaks dnf and everything else dealing with updates like "fedora-easy-karma"
do you guys test your software local before fire up builds?
[root@testserver:~]$ dnf clean packages
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/init.py", line 31, in <module>
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module>
from dnf.module.metadata_loader import ModuleMetadataLoader
File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module>
gi.require_version('Modulemd', '1.0')
File "/usr/lib64/python3.6/site-packages/gi/init.py", line 134, in require_version
(namespace, version))
ValueError: Namespace Modulemd not available for version 1.0
[root@testserver:~]$ dnf upgrade
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/init.py", line 31, in <module>
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module>
from dnf.module.metadata_loader import ModuleMetadataLoader
File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module>
gi.require_version('Modulemd', '1.0')
File "/usr/lib64/python3.6/site-packages/gi/init.py", line 134, in require_version
(namespace, version))
ValueError: Namespace Modulemd not available for version 1.0
Traceback (most recent call last):
File "/usr/bin/dnf", line 57, in <module>
from dnf.cli import main
File "/usr/lib/python3.6/site-packages/dnf/__init__.py", line 31, in <module>
import dnf.base
File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module>
from dnf.module.metadata_loader import ModuleMetadataLoader
File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module>
gi.require_version('Modulemd', '1.0')
File "/usr/lib64/python3.6/site-packages/gi/__init__.py", line 134, in require_version
(namespace, version))
ValueError: Namespace Modulemd not available for version 1.0
@hreindl: The personal attacks aren't necessary. I did my testing on F29 and didn't realize there was an issue on F28. That's kind of what u-t is for: catching such issues before they get out in the wild.
The problem here is actually on the DNF side; python3-dnf on Fedora 28 has Requires: libmodulemd >= 1.3.0 instead of Requires: libmodulemd1 or, better, Requires: python3-libmodulemd1
The libmodulemd1 set of subpackages is meant to maintain compatibility with the old API (which was bad). We need to get an update to python3-dnf into this bodhi update that pulls in the correct libmodulemd.
and to make it clear: besdies users like me with more than 10 years expierince with Fedora when you kill the primary package manager which is dnf more than once you can forget your "updates-testing" people like me at all
@hreindl: You reported the issue. I responded by acknowledging it and saying it would be fixed.
Continuing to be rude and disrespectful to other members of the Fedora community yet again is not productive or helpful. Please discontinue this behavior.
blow untested stuff to fedora-n is also not helpful, that OS version is meant to run stable and breaking packages which are required by dnf untesteed is a bad joke
to be honest i have enough of that shitload of updates oftne containing not anything else than spec-cosmetic or bring regressions for no godd reason
This update has been submitted for testing by sgallagh.
This update has been pushed to testing.
completly breaks dnf and everything else dealing with updates like "fedora-easy-karma" do you guys test your software local before fire up builds?
[root@testserver:~]$ dnf clean packages Traceback (most recent call last): File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main File "/usr/lib/python3.6/site-packages/dnf/init.py", line 31, in <module> import dnf.base File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module> from dnf.module.metadata_loader import ModuleMetadataLoader File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module> gi.require_version('Modulemd', '1.0') File "/usr/lib64/python3.6/site-packages/gi/init.py", line 134, in require_version (namespace, version)) ValueError: Namespace Modulemd not available for version 1.0 [root@testserver:~]$ dnf upgrade Traceback (most recent call last): File "/usr/bin/dnf", line 57, in <module> from dnf.cli import main File "/usr/lib/python3.6/site-packages/dnf/init.py", line 31, in <module> import dnf.base File "/usr/lib/python3.6/site-packages/dnf/base.py", line 30, in <module> from dnf.module.metadata_loader import ModuleMetadataLoader File "/usr/lib/python3.6/site-packages/dnf/module/metadata_loader.py", line 25, in <module> gi.require_version('Modulemd', '1.0') File "/usr/lib64/python3.6/site-packages/gi/init.py", line 134, in require_version (namespace, version)) ValueError: Namespace Modulemd not available for version 1.0
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
WTF
[root@srv-rhsoft:~]$ dnf --exclude=libmodulemd upgrade Last metadata expiration check: 0:01:29 ago on Mon Jan 28 21:58:43 2019. Dependencies resolved. ============================================================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================================================== Installing dependencies: libmodulemd1 x86_64 1.8.2-1.fc28 updates-testing 174 k replacing libmodulemd.x86_64 1.7.0-1.fc28
Transaction Summary
Install 1 Package
Total download size: 174 k Installed size: 525 k Is this ok [y/N]: n Operation aborted.
Incompatible with python3-dnf-2.7.5-12.fc28.
This update has been obsoleted.
same bustage here too :(
@hreindl: The personal attacks aren't necessary. I did my testing on F29 and didn't realize there was an issue on F28. That's kind of what u-t is for: catching such issues before they get out in the wild.
The problem here is actually on the DNF side;
python3-dnfon Fedora 28 hasRequires: libmodulemd >= 1.3.0instead ofRequires: libmodulemd1or, better,Requires: python3-libmodulemd1The
libmodulemd1set of subpackages is meant to maintain compatibility with the old API (which was bad). We need to get an update to python3-dnf into this bodhi update that pulls in the correct libmodulemd.pinging @jmracek for assistance.
if you test your stuff only on F29 and blow it blindly to F28 they are necessary
and to make it clear: besdies users like me with more than 10 years expierince with Fedora when you kill the primary package manager which is dnf more than once you can forget your "updates-testing" people like me at all
@hreindl: You reported the issue. I responded by acknowledging it and saying it would be fixed.
Continuing to be rude and disrespectful to other members of the Fedora community yet again is not productive or helpful. Please discontinue this behavior.
blow untested stuff to fedora-n is also not helpful, that OS version is meant to run stable and breaking packages which are required by dnf untesteed is a bad joke
to be honest i have enough of that shitload of updates oftne containing not anything else than spec-cosmetic or bring regressions for no godd reason
sgallagh edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by sgallagh.
I've updated this so that it won't produce the 2.x subpackages on F28, just the libmodulemd1 ones (with appropriate Obsoletes/Provides).
This update has been pushed to testing.
sgallagh edited this update.
sgallagh edited this update.
This update has reached 7 days in testing and can be pushed to stable now if the maintainer wishes
This is technically ready for pushing to stable, but since we haven't seen any feedback, I'm going to give it some time.
@ppisar @rdieter: Have you seen any issues with this newer update?
fedpkg works for me with libmodulemd1-1.8.2-1.fc28.1. I also had an opportunity to build a module today and it worked.
no regressions noted
This update has been submitted for batched by sgallagh.
This update has been submitted for stable by bodhi.
This update has been pushed to stable.