I hit a traceback where msg was NoneType and therefore didn't have a
`msg_id` attribute, I therefore wasn't able to see the real exception
that got me there in the first place.
I'm taking on #235. This is all stuff that came up while doing a
cursory package review myself.
- The source files all state that they are MIT, but the specfile and
repo claimed to be GPL. I switched everything to MIT (even though I
favor GPL.. the source was MIT first before it was incorrectly
labelled GPL).
- There are various bugs and lint issues in the specfile fixed here.
- Notably, the systemd service file is missing from the 1.0.0 tarball on
PyPI, so I'll need to do a new release after this.
Fixes#181.
When initializing the buildroot for a module build, we used to set up
some build 'groups' for the tag: `build` and `srpm-build`. These are
the lists of RPMs that koji is supposed to install into the buildroot
before anything else is done. Crucial stuff goes here, like `git` in
the `srpm-build` group so that koji can clone the repo in the first
place.
We had those lists hardcoded before. This list changes that to use the
`buildroot` and `srpm-buildroot` profiles of the modules which are our
dependencies (recursively).
This will allow people like @psabata and the base-runtime to make
changes to the build groups for the generational core and work around
their own problems, instead of having to ask us to expand that list.
There were a couple ways to do this:
- I could've cloned the SCM repos for all dependencies and gotten their
profiles from the modulemd source there. This seemed flimsy because
we only want to depend on the profiles of modules that were *really*
built.
- We could modify PDC to stuff the modulemd contents in there. We
already get some dep and tag info from PDC. My thought here was that
it would be too heavyweight to store every copy of the modulemd file
in PDC for every build ever. We already have it in MBS.
- Lastly, and this is what I did here, I just referred to MBS' own
database to get the profiles. This seems to work just fine.
One side-effect is that we need the build profiles from the manually
bootstrapped modules that were put together by hand, and were never
built in the MBS. In order to work around that, I added an alembic
upgrade script which pre-populates the database with one fake
bootstrapped base-runtime module. We can expand on that in the future
if we need.
