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

$releasever substitution not used in GPG key filename #1248

Closed
bcl opened this issue Feb 14, 2024 · 7 comments
Closed

$releasever substitution not used in GPG key filename #1248

bcl opened this issue Feb 14, 2024 · 7 comments
Assignees

Comments

@bcl
Copy link

bcl commented Feb 14, 2024

Fedora hit this problem after branching: weldr/lorax#1379

2024-02-14 01:07:47,941 ERROR pylorax.ltmpl: The transaction process has ended abruptly: cannot open file: (2) - No such file or directory [/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-x86_64]

I forget the exact series of events, but lorax is setting the basearch and releasever substitutions for each repo. ISTR having problems either finding how to set them or getting them to work at the time. Adam fixed this by setting it on Base().get_vars() so that appears to be a more correct way to do this and I'll switch to that after we confirm it works.

But I think this is still a bug, the gpg key filename should also be using the repo's variables if they exist.
And the documentation around .get_vars() could be improved, it's possible that I completely missed what it could be used for because it doesn't mention variable substitution in a way that I would search for.

@ppisar
Copy link
Contributor

ppisar commented Feb 15, 2024

Can you be more specific how you obtain the PGP filename? I quickly tested it with dnf5-5.1.12-20240213004754.0.gaad06db3.fc40.x86_64 from a command line dnf5 repo info REPO_ID and it expands $releasever in the PGP file name correctly. Maybe your invocation pointed DNF5 to a root file system tree where DNF5 was unable to determine $releasever.

@j-mracek
Copy link
Contributor

May I ask you whether the repository is created from .repo file or created from API? In case of API approach, may I ask you for the code that you use?

@bcl
Copy link
Author

bcl commented Feb 15, 2024

The filename comes from running lorax with the distribution repo file using --repo /etc/yum.repos.d/fedora.repo
Also, running dnf isn't going to reproduce this, I'm sure it does the right thing, otherwise people would have noticed before now :)

The --repo argument does this to add the file - https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L156

    if repos:
        reposdir = os.path.join(tempdir, "dnf.repos")
        if not os.path.isdir(reposdir):
            os.mkdir(reposdir)
        for r in repos:
            shutil.copy2(r, reposdir)
        conf.reposdir = reposdir

The code adding the basearch and releasever is here - https://github.com/weldr/lorax/blob/master/src/pylorax/dnfbase.py#L214

# Make sure there are enabled repos
    rq = dnf5.repo.RepoQuery(dnfbase)
    rq.filter_enabled(True)
    if len(rq) == 0:
        log.error("No enabled repos")
        return None
    log.info("Using repos: %s", ", ".join(r.get_id() for r in rq))

    # Add substitutions to all enabled repos
    for r in rq:
        # Substitutions used with the repo url
        r.set_substitutions({
                "releasever": releasever,
                "basearch": basearch,
        })

And I wasn't using get_vars() at all.

ETA: Adam came up with a fix for this that does seem to work in my testing - weldr/lorax#1380

@j-mracek
Copy link
Contributor

Thank you for the link to code. It seems that you modify substitutions to late and on incorrect place. Substitutions are applied at the time of loading repositories. Any modification after that point does not modify anything in repository.

@j-mracek
Copy link
Contributor

Because there is a patch in lorax that fix the issue, I am closing this report.

@j-mracek j-mracek self-assigned this Feb 16, 2024
@bcl
Copy link
Author

bcl commented Feb 16, 2024

Thank you for the link to code. It seems that you modify substitutions to late and on incorrect place. Substitutions are applied at the time of loading repositories. Any modification after that point does not modify anything in repository.

Ah, ok. Oddly enough though, this did work when substituting the baseurl/mirrorlist. I'd have noticed sooner if it was a complete failure :)

@j-mracek
Copy link
Contributor

Thank you for the link to code. It seems that you modify substitutions to late and on incorrect place. Substitutions are applied at the time of loading repositories. Any modification after that point does not modify anything in repository.

Ah, ok. Oddly enough though, this did work when substituting the baseurl/mirrorlist. I'd have noticed sooner if it was a complete failure :)

We have a plan to add locking substitution, but it is on TODO list.

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

No branches or pull requests

3 participants