Add F29 support, and made things default to F29.

@nphilipp - ping? this would be useful to merge.

@otaylor NIls should be back next week. Is this urgent?

@psabata - I want to send a "call for Flatpak packagers" out soon, and it
would be helpful to have a release of fedmod with these changes for that,
but I probably need the next couple of days to write docs and tie up some
loose ends, and Monday is a holiday in the US, so I think it can wait until
Nils is back. Hopefully he'll have a chance to look at it then!

Thanks! I'll make sure to remind him :)

I think it could be worthwhile to let people use the respective testing repos—updates-testing, updates-testing-modular—too, what do you think?

Not blocking this, but ultimately this should be configurable somewhere outside the source code.

Besides that, there shouldn't be spaces around = here because they're keyword parameter assignments.

It looks like if I commented all PEP8 issues it would clutter up the review too much. I'll just fix them afterwards. :wink:

Not sure it makes a real difference (since the ClickException is caught) but as we don't care for Python 2 compatibility this could be raise click.ClickException(e) from e.

It looks like if I commented all PEP8 issues it would clutter up the review too much. I'll just fix them afterwards. 😉

I think the only reasonably way to make sure that the code is PEP8 compliant is to have a policy of having zero errors from flake8. (Ideally set up CI - but at least contributors running flake8 manually.) Trying to spot commits that break PEP8 compliance by eye is no way to go.

Are you thinking of a config file in /etc, or just of a non-source file installed with Python code? The main advantage I see of a config file is that if you needed some custom dataset, you could create it. But some cleanups would be needed before we stabilized a config file format - e.g., the code:

   if "updates" in remote_prefix:
        remote_arch_path = arch + "/"
    else:
        remote_arch_path = os.path.join(arch, "os/")

Is not OK - you'd need yum style $basearch.

Sure.

The main use case I can think of is:

• You run rpm2flatpak
• You see a whole bunch of extra deps due to a packaging error (e.g., the app dependended on gvfs rather than gvfs -client)
• You fix the error in packaging and fire off a build
• You want to run rpm2flatpak and get the correct result

updates-testing makes that a ~6 hour wait instead of a week. It would be even nicer to be able to do --with-koji-build= or something - but a lot more work in fedmod. In any case, I think I'll hold off on this for now.

(What I have patched in locally here is a f29koji dataset that uses https://kojipkgs.fedoraproject.org/repos/f29-build/latest/ - in the current f29 freeze period the latest compose has diverged from the buildroot in a way that causes problems for my flatpak-runtime generation scripts. But not convinced yet this is a general need. Maybe a case for a configuration file!)

Pushed an update that fixes a few PEP8 issues and uses 'raise ... from'.

I think the only reasonably way to make sure that the code is PEP8 compliant is to have a policy of having zero errors from flake8. (Ideally set up CI - but at least contributors running flake8 manually.) Trying to spot commits that break PEP8 compliance by eye is no way to go.

Absolutely.

Are you thinking of a config file in /etc, or just of a non-source file installed with Python code? The main advantage I see of a config file is that if you needed some custom dataset, you could create it. But some cleanups would be needed before we stabilized a config file format - e.g., the code: if "updates" in remote_prefix: remote_arch_path = arch + "/" else: remote_arch_path = os.path.join(arch, "os/") Is not OK - you'd need yum style $basearch.

I'd like a configuration file (thinking of /etc + somewhere in the user's home), but you're right that this needs some fleshing out and is out of scope of this PR.

The main use case I can think of is:

• You run rpm2flatpak
• You see a whole bunch of extra deps due to a packaging error (e.g., the app dependended on gvfs rather than gvfs -client)
• You fix the error in packaging and fire off a build
• You want to run rpm2flatpak and get the correct result updates-testing makes that a ~6 hour wait instead of a week.

It would be even nicer to be able to do --with-koji-build= or something - but a lot more work in fedmod. In any case, I think I'll hold off on this for now. (What I have patched in locally here is a f29koji dataset that uses https://kojipkgs.fedoraproject.org/repos/f29-build/latest/ - in the current f29 freeze period the latest compose has diverged from the buildroot in a way that causes problems for my flatpak-runtime generation scripts. But not convinced yet this is a general need. Maybe a case for a configuration file!)

Yes, being able to use updates-testing or a specific koji build id (or maybe even local/remote git hashes/spec files though getting deps reliably out of that sounds like a headache) would be useful to minimize turnaround times.

I've found a typo in one of the commit logs which I'll fix before applying:

commit 713244c61d0a856eeb324dc001116076b236a54e
Author:     Owen W. Taylor <otaylor@fishsoup.net>
AuthorDate: Tue Aug 21 17:44:14 2018 -0400
Commit:     Owen W. Taylor <otaylor@fishsoup.net>
CommitDate: Wed Sep 5 13:55:51 2018 -0400
    Add a f29 release version
    Add a release definition for --dataset=rawhide.

This should rather be ... --dataset=f29.

Merged in commit d825276fac051a6e0b67f1417b9fb13ceedbca0c.

Corresponding Fedora updates:

• Fedora 29
• Fedora 28