4 ms·

The issue is that mock does nothing for moving sources in place, it's just rpmbuild and a chroot. From what I could figure out, fedpkg is more about working wit

The issue is that mock does nothing for moving sources in place, it's just rpmbuild and a chroot. From what I could figure out, fedpkg is more about working with existing Fedora packages shipped as part of the official repositories, and less about "Here's how to get this random project you don't own into copr".

bravetraveler 4y ago
I don't work with mock much, but fedpkg is perfectly capable for introducing new things -- that's exactly why I know about/use it. I draft up specs, build {s,}rpm with fedpkg (indirectly mock), test locally, then ship them off with copr-cli
- YorickPeterse 4y ago
  Ah interesting. Do you have any guides about fedpkg that you'd recommend?
  - bravetraveler 4y ago
    I wish I did! It's very skewed towards those wanting to contribute to Fedora, so the part before makes sense. The doc above (and a former roommate) are the best resources I have! I've had to expend a bit of trial/error to familiarize myself with a number of quirks... the rough process looks like this: fedpkg mockbuild copr-cli build $ProjectName ./results_$PKGNAME/path/to/project.srpm -r $mock_root This assumes there's an RPM spec file in your working directory and proper handling of sources within/nearby. Fedpkg will create a 'results' directory with the SRPM and RPMs The -r $mock_root part can be repeated if you want to build against multiple targets in COPR
    - mroche 4y ago
      My typical workflow usually looks like the following: 1) Make spec file # Gather sources and generate source rpm 2) spectool -gS <specfile> 3) rpkg srpm --outdir . # The following depends on what I'm trying to do 4a) mock --rebuild -r <chroot> <srpm> 4b) copr build [chroot params] <project> <srpm> I use fedpkg primarily for dealing with existing packages rather than making my own, where I use rpkg/mock/copr directly.
      - bravetraveler 4y ago
        Oh my, how could I forget spectool!? Thank you for sharing, I somehow was completely unaware of rpkg

bravetraveler 4y ago

I don't work with mock much, but fedpkg is perfectly capable for introducing new things -- that's exactly why I know about/use it. I draft up specs, build {s,}rpm with fedpkg (indirectly mock), test locally, then ship them off with copr-cli

YorickPeterse 4y ago
Ah interesting. Do you have any guides about fedpkg that you'd recommend?
- bravetraveler 4y ago
  I wish I did! It's very skewed towards those wanting to contribute to Fedora, so the part before makes sense. The doc above (and a former roommate) are the best resources I have! I've had to expend a bit of trial/error to familiarize myself with a number of quirks... the rough process looks like this: fedpkg mockbuild copr-cli build $ProjectName ./results_$PKGNAME/path/to/project.srpm -r $mock_root This assumes there's an RPM spec file in your working directory and proper handling of sources within/nearby. Fedpkg will create a 'results' directory with the SRPM and RPMs The -r $mock_root part can be repeated if you want to build against multiple targets in COPR
  - mroche 4y ago
    My typical workflow usually looks like the following: 1) Make spec file # Gather sources and generate source rpm 2) spectool -gS <specfile> 3) rpkg srpm --outdir . # The following depends on what I'm trying to do 4a) mock --rebuild -r <chroot> <srpm> 4b) copr build [chroot params] <project> <srpm> I use fedpkg primarily for dealing with existing packages rather than making my own, where I use rpkg/mock/copr directly.
    - bravetraveler 4y ago
      Oh my, how could I forget spectool!? Thank you for sharing, I somehow was completely unaware of rpkg