copr-mocks are only for python3 at the moment so requiring python2 packages for epel won't do any good.

Thank you for this. Support for EPEL7 is something we would like to have. The commits could be squashed into one. And also you could perhaps avoid incrementing the release. These are only minor objections.

Hi

I'm not a experienced git-user.. How do I squash the commits??

In regards to the release numbers... should I just leave them at 1?? and what version should I write in the changelog??

Hmmm.. The package builds and seems to work with these dependencies on RHEL/CentOS.. without python3...???

I'm not very experienced tito user, but I don't usually bump version/release or add changelog. That's done automatically when new tarball is released. I usually do git rebase -i HEAD^^ when I want to squash two commits into one.

I consider that very strange when the main script (app.py) has #!/usr/bin/env python3 at the beginning. How exactly did you test it?

I have just tried installing the package, and the complete system is now running.. there is also installed some python3 packages from the RHSCL... so that might be why it works...

I'll invistigate...

copr-mocks (this package) is just for testing purposes. It is used in beaker-tests. So COPR can build without it and no problems.

Ahhh.. that might explain it.. Haven't tested that.. I'll keep to the build-required packages for now..

I have COPR running on a RHEL7 machine now...

Could we enable build of EL7 packages, so I can see which packages breaks, and correct them???

I have COPR running on a RHEL7 machine now...
Could we enable build of EL7 packages, so I can see which packages breaks, and correct them???

It actually is enabled in @copr/copr-dev. It would be great if building worked in el7!

Ok, great...

I have COPR running here on a RHEL7 machine.. working on commiting the changes (they are minor...)