-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, January 27, 2021 11:26 AM, Vít Ondruch <vondr...@redhat.com> wrote: > Dne 27. 01. 21 v 17:57 Gwyn Ciesla via devel napsal(a): > > > -- > > Gwyn Ciesla > > she/her/hers > > ------------------------------------------------ > > in your fear, seek only peace > > in your fear, seek only love > > -d. bowie > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Wednesday, January 27, 2021 10:50 AM, Vít Ondruch <vondr...@redhat.com> > > wrote: > > > > > You can do this in mock without messing with your system. You can use > > > `mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf command > > > you want to use`. You can use `mock your.srpm --short-circuit=install` > > > and similar. You can use `mock shell --unpriv` if you want to tinker > > > more. Mock is everything you ever wanted to develop for Fedora. > > > > > > So could you please share with us specifics of your workflow which makes > > > it unique and which really requires `fedpkg local`? I can't imaging that > > > intentionally breaking the host system due to testing soname bump is the > > > right thing to do. > > > > Ok, let's say I have to update a library, let's say LibRaw, and the soname > > changes. > > > > I fire up a rawhide VM > > This is the first difference, with Mock, you don't need to fire VM. > > > , and clone the LibRaw repo, update the spec > > Second difference is that you are cloning locally. > > > , build > > At this place, you call `fedpkg srpm` followed by `mock LibRaw.srpm` > > > , and install it > > `mock -i /var/lib/cache/mock/fedora-rawhide-x86_64/results/LibRaw.rpm` > > > . Then I clone the dependant repos, update their specs, and build them. These are all more cumbersome to type quickly. fedpkg mockbuild solves that but I doesn't support the options you use. fedpkg local does what I and apparently many others need. > You clone them locally and you call the `mock dependant.srpm --no-clean`. > Please note that the --no-clean is essential here, because otherwise the BR > would be cleaned up as well as the results directory previously used for > installation. But of course you can save the build results somewhere. > > > Failures are immediately apparent, and I can quickly work on patches or > > obtain logs of failures for sending upstream. I can easily get into the > > source tree to examine files > > Sure you can with mock, you have everything at > `/var/lib/cache/mock/fedora-rawhide-x86_64/root` > > > , quickly test tweaks to build commands, etc. Once it all builds, I do a > > mock chain build, then an srpm koji scratch build, and if all is well, I > > commit, push, and chain-build in koji. > > No difference here. > > > I always use mock for final smoketesting and rooting out missed > > BuildRequires, but being forced to use mock for the whole process would > > greatly lengthen the process. > > This is where I disagree. You would save you troubles using VM. Mock is more > lightweight providing you everything you need. > > BTW, I should note here that I am not user of `fedpkb mockbuild`. I believe > that using mock directly is not harder. The same way as I am using `git > commit` where others could prefer `fedpkg commit`. > > Vít
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
