Help understanding mock/make-rpms

Development
1

I’m wanting to get such development processes as I have a little more streamlined, and to follow whatever best practices there are to make my job easier/better. Not sure what else needs to be done to my nethserver-automx and nethserver-acme-dns packages, but there’s no way they’re bug-free. So time to learn at least a little bit of git and see how I can make that work for me.

I see https://wiki.nethserver.org/doku.php?id=developer:developer_howto that talks about installing mock and using the make-rpms command to build things. I’m not sure what benefit that has other than saving the tedium of building a new tarball every time I change something in the source, but that’s enough for now. I’m having some trouble with that, but before I really get into troubleshooting, I want to see if I understand how it’s supposed to work (and fill in gaps in that understanding).

Environment: A Neth 7.5 VM, up to date, with nethserver-mock installed, a non-root user created and added to the mock group.

It looks like the make-rpms command expects to work on the root of a git repository. Right now I have individual subdirectories for my different projects (~/nethserver-automx, ~/nethserver-acme-dns, etc.), with the .spec file in ~/rpm-build/SPECS. When I need to build a RPM, I tar up (for example) ~/nethserver-automx, put that in ~/rpm-build/SOURCES, and rpmbuild -ba --sign nethserver-automx.spec.

If I now want to use mock, it looks like I copy nethserver-automx.spec to ~/nethserver-automx, change to that directory, git init, git add -A, git commit -m "Initial commit". Then make-rpms nethserver-automx.spec.

  • Do I have it right so far?
  • Does make-rpms sign the RPMs as well, or would I need to do that myself?

When make-rpms finishes, it puts a number of new files into the working directory. The RPMS themselves, of course, as well as a couple of log files, and I think a couple of others (from memory, as I’m not logged in to that environment at the moment). Git sees them, of course.

  • Do I just leave those files there and never add/commit them?
2 Likes
2

Yes.

For your own repo you have to sign it, for packages.nethserver.org it’s done automatically:

http://docs.nethserver.org/projects/nethserver-devel/en/v7/building_rpms.html#signing-rpms

You may ignore them:

1 Like
3

That’s an obvious solution I totally should have thought of. :blush:

Edit: I notice when building that I get a message saying Failed to set locale, defaulting to C. Should I worry about this?

I also notice that when my .spec file refers to the source as being in .tar.bz2, building the RPM fails, and there’s a new subdirectory of the repo created. The subdirectory has the same name as specified for the source in the .spec file. If I use .tar.gz, it works fine. Shouldn’t it work with other compression methods?

Edit again: Should this work for anything, or only for nethserver-* packages?

4

This is introduced since mock builds in a systemd-nspawn container; did not notice any side effects. So you should not worry about it.

If it really annoys you, you can revert to the old type of chroot by editing /etc/mock/nethserver-7-x86_64.cfg and add to the mock config-section:

config_opts['use_nspawn'] = False

Note: whenever you touch a mock configuration file you root-cache is rebuild the next time.

To be honest i like the old type of chroot more for building something manually. It has network enabled by default. Just for fun you can play with it:

mock -r nethserver-7-x86_64 --init
mock -r nethserver-7-x86_64 --shell
cd ~/build
ls -l

You probably recognize the directory structure here :grinning:

1 Like
5

Never had to deal with this, bz2 can be uncompressed with bzip2 isn’t it?
bzip2 should be in the chroot.

I think you find your answer in /bin/prep-sources , did not have a good look at it my-self

As long as all your Sources / Patches are in the root of your working dir or can be downloaded (spec-tool is invoked before building starts) it will work.

Sorry for the EDITS, sunday morning :sunglasses:

6

Yep. It’s not a critical thing, but I prefer to use bz2 as it seems to compress more efficiently.

Interesting–it isn’t building automx for me. I’ll see if I can come up with more detail.

On the positive side, pushing to my Phabricator installation via SSH is working just fine.

1 Like
7

Yes, you can ignore it.

It should work with most of the packages, but not all.

You need to add to the spec:

BuildRequires: bzip2

And then manually invoke bunzip2, see this example.

2 Likes