Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fedora 35 exception: no package metadata #156

Closed
raffaem opened this issue Apr 17, 2022 · 11 comments
Closed

Fedora 35 exception: no package metadata #156

raffaem opened this issue Apr 17, 2022 · 11 comments
Labels

Comments

@raffaem
Copy link

raffaem commented Apr 17, 2022

I have installed dangerzone with:

curl -s https://packagecloud.io/install/repositories/firstlookmedia/code/script.rpm.sh | sudo bash
sudo dnf install -y dangerzone

But the software throws an exception:

$ dangerzone
Traceback (most recent call last):
  File "/usr/bin/dangerzone", line 33, in <module>
    sys.exit(load_entry_point('dangerzone==0.3.1', 'console_scripts', 'dangerzone')())
  File "/usr/bin/dangerzone", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 957, in distribution
    return Distribution.from_name(distribution_name)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 548, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for dangerzone
@deeplow
Copy link
Contributor

deeplow commented Jul 27, 2022

I have followed the install instructions and it lead me to the same issue on a fedora-35 VM running under Qubes.

However, when I build the package from source on the v0.3.1 tag (which should be the same version) it works fine.

Will investigate.

@prdwyer
Copy link

prdwyer commented Jan 23, 2023

same issue on fedora 37 with the following error

~  dangerzone                    
Traceback (most recent call last):
  File "/usr/lib64/python3.11/importlib/metadata/__init__.py", line 563, in from_name
    return next(cls.discover(name=name))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/dangerzone", line 33, in <module>
    sys.exit(load_entry_point('dangerzone==0.4.0', 'console_scripts', 'dangerzone')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/bin/dangerzone", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
                       ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/importlib/metadata/__init__.py", line 981, in distribution
    return Distribution.from_name(distribution_name)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/importlib/metadata/__init__.py", line 565, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for dangerzone

@apyrgio
Copy link
Contributor

apyrgio commented Jan 25, 2023

Thanks a lot for the report @prdwyer, and especially for the traceback. It seems that another user (#307) has stumbled on this issue, so we looked into it.

Turns out that our CI runners were erroneously building RPM packages for Fedora 37 in Fedora 36. This means that the produced RPM package installs Dangerzone for Python 3.10, instead of 3.11, which is the root cause for the traceback you see.

We plan to upload a new Fedora 37 package in our repo, which you should be able to install with regular dnf commands. We'll ping you really soon about this.

apyrgio added a commit that referenced this issue Jan 25, 2023
When deploying packages, build the RPM package for Fedora 37 and deploy
only that.

Problem
=======

The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.

Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.

The end result is that users could not install Dangerzone on Fedora 37
through our official repo.

Remediation
===========

In order to help out Fedora 37 users, we plan to do the following:

1. Bump the Fedora patch level of our package to -2. This will help
   users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
   and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
   of the distros are not affected.

IMPORTANT: This is a hotfix that should never be merged back in the main
branch.

Fixes #156
apyrgio added a commit that referenced this issue Jan 25, 2023
When deploying packages, build the RPM package for Fedora 37 and deploy
only that.

Problem
=======

The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.

Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.

The end result is that users could not install Dangerzone on Fedora 37
through our official repo.

Remediation
===========

In order to help out Fedora 37 users, we plan to do the following:

1. Bump the Fedora patch level of our package to -2. This will help
   users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
   and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
   of the distros are not affected.

IMPORTANT: This is a hotfix that should never be merged back in the main
branch.

Fixes #156
apyrgio added a commit that referenced this issue Jan 25, 2023
When deploying packages, build the RPM package for Fedora 37 and deploy
only that.

Problem
=======

The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.

Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.

The end result is that users could not install Dangerzone on Fedora 37
through our official repo.

Remediation
===========

In order to help out Fedora 37 users, we plan to do the following:

1. Bump the Fedora patch level of our package to -2. This will help
   users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
   and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
   of the distros are not affected.

IMPORTANT: This is a hotfix that should never be merged back in the main
branch.

Fixes #156
apyrgio added a commit that referenced this issue Jan 25, 2023
When deploying packages, build the RPM package for Fedora 37 and deploy
only that.

Problem
=======

The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.

Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.

The end result is that users could not install Dangerzone on Fedora 37
through our official repo.

Remediation
===========

In order to help out Fedora 37 users, we plan to do the following:

1. Bump the Fedora patch level of our package to -2. This will help
   users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
   and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
   of the distros are not affected.

IMPORTANT: This is a hotfix that should never be merged back in the main
branch.

Fixes #156
apyrgio added a commit that referenced this issue Jan 25, 2023
When deploying packages, build the RPM package for Fedora 37 and deploy
only that.

Problem
=======

The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.

Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.

The end result is that users could not install Dangerzone on Fedora 37
through our official repo.

Remediation
===========

In order to help out Fedora 37 users, we plan to do the following:

1. Bump the Fedora patch level of our package to -2. This will help
   users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
   and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
   of the distros are not affected.

IMPORTANT: This is a hotfix that should never be merged back in the main
branch.

Fixes #156
apyrgio added a commit that referenced this issue Jan 25, 2023
When deploying packages, build the RPM package for Fedora 37 and deploy
only that.

Problem
=======

The v0.4.0 release introduced Fedora 37 support. We had tested building
an RPM package for Fedora 37 and installing it successfully, so we
assumed that we had the green light for the release.

Turns out however that our CI runners were not building packages for
each of our supported Fedora release, but solely for Fedora 35. It so
happened that Fedora 35 and Fedora 36 had similar Python versions, but
the same did not apply to Fedora 37.

The end result is that users could not install Dangerzone on Fedora 37
through our official repo.

Remediation
===========

In order to help out Fedora 37 users, we plan to do the following:

1. Bump the Fedora patch level of our package to -2. This will help
   users install the new package, once we release it.
2. Change our CI pipeline to build an RPM package for Fedora 37 instead,
   and deploy that to PackageCloud.
3. Comment out all the other deployments to PackageCloud, since the rest
   of the distros are not affected.

IMPORTANT: This is a hotfix that should never be merged back in the main
branch.

Fixes #156
@apyrgio
Copy link
Contributor

apyrgio commented Jan 25, 2023

Update: We have published a new package (dangerzone-0.4.0-2) in the Fedora 37 repos, and we tested that this new package fixes the error you have encountered.

You can install this package either with dnf update, or dnf install dangerzone specifically.

I'll close this issue, since it seems to be resolved. If this is not the case, please send us an update. Thanks again for your report!

@apyrgio apyrgio closed this as completed Jan 25, 2023
@prdwyer
Copy link

prdwyer commented Jan 26, 2023

i dont see the package on the repos yet but thanks for the action on this. i assume itll trickle in over time

@apyrgio apyrgio reopened this Jan 26, 2023
@apyrgio
Copy link
Contributor

apyrgio commented Jan 26, 2023

Hm, let's not leave this to chance, until we're sure we've resolved it. Running the following command on a fresh Fedora 37 system, I see the following:

# dnf --showduplicates list dangerzone
Last metadata expiration check: 0:00:20 ago on Thu Jan 26 07:42:40 2023.
Available Packages
dangerzone.noarch                                                                      0.4.0-1                                                                       firstlookmedia_code       
dangerzone.src                                                                         0.4.0-1                                                                       firstlookmedia_code-source
dangerzone.noarch                                                                      0.4.0-2                                                                       firstlookmedia_code       
dangerzone.src                                                                         0.4.0-2                                                                       firstlookmedia_code-source

Do you see the same?

@henryreed
Copy link

@prdwyer Be sure to use the --refresh argument in your dnf command if you updated recently, otherwise the new version of dangerzone won't be visible. E.g., # dnf --refresh update or # dnf --showduplicates --refresh list dangerzone

What I see on my end:

$ sudo dnf --showduplicates --refresh list dangerzone
Copr repo for PyCharm owned by phracek         6.0 kB/s | 3.6 kB     00:00    
Fedora 37 - x86_64                              28 kB/s |  22 kB     00:00    
Fedora 37 openh264 (From Cisco) - x86_64       1.5 kB/s | 989  B     00:00    
Fedora Modular 37 - x86_64                      32 kB/s |  22 kB     00:00    
Fedora 37 - x86_64 - Updates                    15 kB/s |  11 kB     00:00    
Fedora Modular 37 - x86_64 - Updates            49 kB/s |  23 kB     00:00    
firstlookmedia_code                            2.0 kB/s | 1.8 kB     00:00    
firstlookmedia_code-source                     2.0 kB/s | 1.8 kB     00:00    
google-chrome                                  3.6 kB/s | 1.3 kB     00:00    
RPM Fusion for Fedora 37 - Nonfree - NVIDIA Dr 3.4 kB/s | 3.8 kB     00:01    
RPM Fusion for Fedora 37 - Nonfree - Steam     3.2 kB/s | 3.7 kB     00:01    
Installed Packages
dangerzone.noarch              0.4.0-2               @firstlookmedia_code      
Available Packages
dangerzone.noarch              0.4.0-1               firstlookmedia_code       
dangerzone.src                 0.4.0-1               firstlookmedia_code-source
dangerzone.noarch              0.4.0-2               firstlookmedia_code       
dangerzone.src                 0.4.0-2               firstlookmedia_code-source

@prdwyer
Copy link

prdwyer commented Jan 27, 2023

im seeing this:

sudo dnf --showduplicates --refresh list dangerzone         
.....
.....

Installed Packages
dangerzone.noarch                    0.4.0-1                     @firstlookmedia_code      
Available Packages
dangerzone.noarch                    0.3.2-1                     firstlookmedia_code       
dangerzone.src                       0.3.2-1                     firstlookmedia_code-source
dangerzone.noarch                    0.4.0-1                     firstlookmedia_code       
dangerzone.src                       0.4.0-1                     firstlookmedia_code-source

@apyrgio
Copy link
Contributor

apyrgio commented Jan 27, 2023

Could it be that you had originally installed Fedora 35/36, and recently upgraded to Fedora 37? If so, then Dangerzone's RPM repo will point to the packages for the previous Fedora release, which explains why you don't receive updates.

Let's find out. This is what I see in a Fedora 37 system:

# cat /etc/yum.repos.d/firstlookmedia_code.repo 
[firstlookmedia_code]
name=firstlookmedia_code
baseurl=https://packagecloud.io/firstlookmedia/code/fedora/37/$basearch
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/firstlookmedia/code/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

[firstlookmedia_code-source]
name=firstlookmedia_code-source
baseurl=https://packagecloud.io/firstlookmedia/code/fedora/37/SRPMS
repo_gpgcheck=0
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/firstlookmedia/code/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

If you see something similar, but with a lower Fedora version, can you please update this file, either manually or via the script in our installation instructions?

@raffaem
Copy link
Author

raffaem commented Jan 28, 2023

I don't use this anymore

@raffaem raffaem closed this as completed Jan 28, 2023
@prdwyer
Copy link

prdwyer commented Jan 28, 2023

this fixed it. Thank you so much for your help i know you arent responsible for doing OS support like this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants