subject:"Re\: Proposal to deprecated `fedpkg local`"

Dne 28. 01. 21 v 19:36 Simo Sorce napsal(a):

On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote:

Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a):

Vít Ondruch writes:

Thx everybody for their responses and sorry for such controversial
topic. I am not going to propose this upstream after all. However I have
few takeaways:

1) I see responses of Fedora long timers and I understand that you
have polished workflows. But I really think that for newcomers, mock
should be the preferred way. I'd love to see documentation adjusted to
prefer mock everywhere.

2) I would really love you to stop using VMs for your build/testing.
With exception of Kernel and Kernel related issues, the argument of
"mock being slow" can't stand. Every VM will be more resources hungry
then mock, slowing every your task.

3) The argument of mock being slow can't stand, because in one of my
examples I posted elsewhere in this thread, I picked up the simplest
package I could and the build took 7 seconds. This is certainly not
slow, in this time you can't even switch to your email client to check
your emails.

So far on this thread, you've asked feedback on a proposal, and then
when provided with feedback you didn't like, repeatedly argued with our
comments and told us we're wrong. This is not a good way to engage with
feedback.

I have provided the numbers here:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/

where I tried to point out that I don't perceive build of trivial
package done in 7s to be slow. For nontrivial package the mock overhead
is negligible. Nobody replied (in constructive way). On various places,
I have suggested to use "--no-clean" option for repeated builds. But in
the whole thread, there was no confirmation that anyone would use it.

Yet I am repetitively told that mock is slow, you repeat it down bellow
once again without any evidence. Your only argument to this discussion
is that mock is slow, because you believe so and other people have said
so. I would really appreciate if I was given some specific
counterargument supported by numbers.

That "mock is slow" is just one of the claims, and not the prevalent
one at that.
It is also inconvenient.
Takes disk space and bandwidth I do not care for.
It is complex to use when what you care is to fit the current running
systems.
And in general, for those that do not use it is yet another thing to
learn to use that I personally do not care for learning as I have no
need for it.

You are claiming that "fedpkg local" is bad, we are responding it is
not, we use it and it works better for us.

As for many other things there isn't just one true way, mock works best
for you, and local works best for others, why is that a problem ?

I have started the thread reflecting on experience of fresh packager
coming to Fedora. First issue was that `fedpkg local` pollutes the work
directory. There is also second issue, that `fedpkg local` is polluting
the whole system with build dependencies (and this is my concern). I
don't think that anybody should have polluted work directory and their
system by packagers work. If experienced packages are fine with that, so
be it. But I am concerned, that these practices are possibly suggested
to fresh coming people.

I have already withdrew the original proposal, but that does not mean I
am less concerned.

Vít

Simo.

Vít

In particular, *numerous* people have told you that mock builds are
slow for us. Instead of telling us that we're wrong about our own
experience because it doesn't match yours, make an effort to understand
what the difference is between them. Or accept it for what it is:
feedback that *you asked for*.

Thanks,
--Robbie

___
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

OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Simo Sorce

On Thu, 2021-01-28 at 19:26 +0100, Vít Ondruch wrote:
> Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a):
> > Vít Ondruch  writes:
> > 
> > > Thx everybody for their responses and sorry for such controversial
> > > topic. I am not going to propose this upstream after all. However I have
> > > few takeaways:
> > > 
> > > 1) I see responses of Fedora long timers and I understand that you
> > > have polished workflows. But I really think that for newcomers, mock
> > > should be the preferred way. I'd love to see documentation adjusted to
> > > prefer mock everywhere.
> > > 
> > > 2) I would really love you to stop using VMs for your build/testing.
> > > With exception of Kernel and Kernel related issues, the argument of
> > > "mock being slow" can't stand. Every VM will be more resources hungry
> > > then mock, slowing every your task.
> > > 
> > > 3) The argument of mock being slow can't stand, because in one of my
> > > examples I posted elsewhere in this thread, I picked up the simplest
> > > package I could and the build took 7 seconds. This is certainly not
> > > slow, in this time you can't even switch to your email client to check
> > > your emails.
> > So far on this thread, you've asked feedback on a proposal, and then
> > when provided with feedback you didn't like, repeatedly argued with our
> > comments and told us we're wrong.  This is not a good way to engage with
> > feedback.
> 
> I have provided the numbers here:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/
> 
> where I tried to point out that I don't perceive build of trivial 
> package done in 7s to be slow. For nontrivial package the mock overhead 
> is negligible. Nobody replied (in constructive way). On various places, 
> I have suggested to use "--no-clean" option for repeated builds. But in 
> the whole thread, there was no confirmation that anyone would use it.
> 
> Yet I am repetitively told that mock is slow, you repeat it down bellow 
> once again without any evidence. Your only argument to this discussion 
> is that mock is slow, because you believe so and other people have said 
> so. I would really appreciate if I was given some specific 
> counterargument supported by numbers.

That "mock is slow" is just one of the claims, and not the prevalent
one at that.
It is also inconvenient.
Takes disk space and bandwidth I do not care for.
It is complex to use when what you care is to fit the current running
systems.
And in general, for those that do not use it is yet another thing to
learn to use that I personally do not care for learning as I have no
need for it.

You are claiming that "fedpkg local" is bad, we are responding it is
not, we use it and it works better for us.

As for many other things there isn't just one true way, mock works best
for you, and local works best for others, why is that a problem ?

Simo.

> 
> Vít
> 
> 
> > In particular, *numerous* people have told you that mock builds are
> > slow for us.  Instead of telling us that we're wrong about our own
> > experience because it doesn't match yours, make an effort to understand
> > what the difference is between them.  Or accept it for what it is:
> > feedback that *you asked for*.
> > 
> > Thanks,
> > --Robbie
> 
> ___
> 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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
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

Re: Proposal to deprecated `fedpkg local`



Dne 28. 01. 21 v 15:51 Robbie Harwood napsal(a):

Vít Ondruch  writes:


Thx everybody for their responses and sorry for such controversial
topic. I am not going to propose this upstream after all. However I have
few takeaways:

1) I see responses of Fedora long timers and I understand that you
have polished workflows. But I really think that for newcomers, mock
should be the preferred way. I'd love to see documentation adjusted to
prefer mock everywhere.

2) I would really love you to stop using VMs for your build/testing.
With exception of Kernel and Kernel related issues, the argument of
"mock being slow" can't stand. Every VM will be more resources hungry
then mock, slowing every your task.

3) The argument of mock being slow can't stand, because in one of my
examples I posted elsewhere in this thread, I picked up the simplest
package I could and the build took 7 seconds. This is certainly not
slow, in this time you can't even switch to your email client to check
your emails.

So far on this thread, you've asked feedback on a proposal, and then
when provided with feedback you didn't like, repeatedly argued with our
comments and told us we're wrong.  This is not a good way to engage with
feedback.



I have provided the numbers here:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4RSZSVMHLIGEYIHLC6NOH3BEWWFQ7JQY/

where I tried to point out that I don't perceive build of trivial 
package done in 7s to be slow. For nontrivial package the mock overhead 
is negligible. Nobody replied (in constructive way). On various places, 
I have suggested to use "--no-clean" option for repeated builds. But in 
the whole thread, there was no confirmation that anyone would use it.


Yet I am repetitively told that mock is slow, you repeat it down bellow 
once again without any evidence. Your only argument to this discussion 
is that mock is slow, because you believe so and other people have said 
so. I would really appreciate if I was given some specific 
counterargument supported by numbers.



Vít




In particular, *numerous* people have told you that mock builds are
slow for us.  Instead of telling us that we're wrong about our own
experience because it doesn't match yours, make an effort to understand
what the difference is between them.  Or accept it for what it is:
feedback that *you asked for*.

Thanks,
--Robbie




OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread David Sommerseth


On 28/01/2021 10:39, Vít Ondruch wrote:


2) I would really love you to stop using VMs for your build/testing. 
With exception of Kernel and Kernel related issues, the argument of 
"mock being slow" can't stand. Every VM will be more resources hungry 
then mock, slowing every your task.


I'd love to.  But then we need to ensure that it is possible to mock 
build future Fedora 45+ packages from a RHEL-8 installation without 
issues; due to yum/dnf/rpm being too old, not able to parse the .rpm or 
.spec files due to new features in use, etc, etc.


And add some simple approaches so you can easily access the source code 
failing to build, so you can add some tweaks and test out manually 
before diffing and patching up the .spec file for another run.


With "simple approaches", I mean to not needing to add additional 
arguments to mock build so the buildroot doesn't get wiped on errors and 
that you don't have to dig deep into the /var/lib/mock directories to 
find the source location


For me, this is where fedpkg local excels over mock build


--
kind regards,

David Sommerseth
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Robbie Harwood

Vít Ondruch  writes:

> Thx everybody for their responses and sorry for such controversial 
> topic. I am not going to propose this upstream after all. However I have 
> few takeaways:
>
> 1) I see responses of Fedora long timers and I understand that you
> have polished workflows. But I really think that for newcomers, mock
> should be the preferred way. I'd love to see documentation adjusted to
> prefer mock everywhere.
>
> 2) I would really love you to stop using VMs for your build/testing.
> With exception of Kernel and Kernel related issues, the argument of
> "mock being slow" can't stand. Every VM will be more resources hungry
> then mock, slowing every your task.
>
> 3) The argument of mock being slow can't stand, because in one of my
> examples I posted elsewhere in this thread, I picked up the simplest
> package I could and the build took 7 seconds. This is certainly not
> slow, in this time you can't even switch to your email client to check
> your emails.

So far on this thread, you've asked feedback on a proposal, and then
when provided with feedback you didn't like, repeatedly argued with our
comments and told us we're wrong.  This is not a good way to engage with
feedback.

In particular, *numerous* people have told you that mock builds are
slow for us.  Instead of telling us that we're wrong about our own
experience because it doesn't match yours, make an effort to understand
what the difference is between them.  Or accept it for what it is:
feedback that *you asked for*.

Thanks,
--Robbie


signature.asc
Description: PGP 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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Robbie Harwood

Vít Ondruch  writes:

> Dne 27. 01. 21 v 23:21 Gwyn Ciesla via devel napsal(a):
>>> On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
>>>
 Hi, I wonder, what would be the sentiment if I proposed to
 deprecated the `fedpkg local` command. I don't think it should be
 used. Mock should be the preferred way. Would there be anybody
 really missing this functionality?
>>>
>>> Why? I use it all the time. While I understand that it's not as
>>> complete a local test as mock, it a lot quicker and less disruptive.
>>> And if I want a real test I'll use a scratch build (because that's
>>> the only way to test a build across architectures).
>>>
>> Agreed. Santa didn't bring me the s390x I asked for this year. :(
>
> Just FTR, mock supports `--arch=ARCH` which will use emulation to
> allow you build whatever architecture localy. I have never used it
> myself, but I wanted to mention this.

I recommend you try.  Prepare to be underwhelmed by speed :)

Thanks,
--Robbie


signature.asc
Description: PGP 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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread David Sommerseth


On 27/01/2021 21:47, Zbigniew Jędrzejewski-Szmek wrote:


+1 to everything that Gwyn said.

'fedpkg local' is just so immensely useful for initial package developement.

I also use it a lot for systemd & friends: I *want* to build packages
against the local environment and install them locally without pulling
in any other package updates, and I want to be able to debug build or
test failures in the host environment.

(I also use mock in various configurations, and copr, and scratch
builds, etc. I find mock immensely useful too, but in a later phase of
package development. Different tools have different tradeoffs.)



All of this +1.  I don't do this for systemd, but for OpenVPN related 
packaging.


Also, mock against newer Fedora distros gets more and more complicated 
as time flies, as I usually do all of this on RHEL [*].  I've recently 
upgraded to RHEL-8 (from RHEL-7), so I'm not sure how that changes in 
this aspect, but looking forward to test it out properly.


But doing OpenVPN related packaging for quite some years has taught me 
to not fully trust mock to be capable to builds on more recent Fedora 
releases (from a RHEL host).  The rescue has always been to use fedpkg 
local (on RHEL) to iron out the build issues before spinning of a VM and 
run a fedpkg mockbuild in the VM (with a recent Fedora), and then koji 
build in the end for the broader platform builds.



[*] I always try to do main development on an older distribution, as
forward porting fixes for issues are always more convenient than
backwards porting them.  Especially when writing new code and
features for a project.


--
kind regards,

David Sommerseth
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Richard W.M. Jones

On Thu, Jan 28, 2021 at 01:40:08PM +0100, Miroslav Suchý wrote:
> Dne 28. 01. 21 v 11:54 Daniel P. Berrangé napsal(a):
> >Thus mock ends up using the slower storage since it isn't using /home.
> 
> A performance tips:
> http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html

For the RISC-V builders I wrote an nbdkit plugin to be mounted on
/var/lib/mock which should achieve similar performance while having
the benefit of using filesystem space instead of RAM+swap.

https://libguestfs.org/nbdkit-tmpdisk-plugin.1.html

Note the performance advantage is not immediately obvious - it's
because the plugin intentionally discards flush and FUA requests, thus
maximizing the amount that can be cached in RAM, but not requiring
RAM+swap as a tmpfs does.

(It would be nice for someone to integrate this more closely with mock
so that the individual /var/lib/mock/ directories would be
loop mounted as tmpdisk on demand and discarded when mock does a clean
operation.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Otto Urpelainen


Gwyn Ciesla via devel kirjoitti 28.1.2021 klo 0.09:


If the user doesn't 'git add .', or has a correct .gitignore, this should be a 
non issue.


Me being the quoted person with a workflow issue, I still think there is
a workflow issue.

Setting .gitignore is possible of course, but rather annoying and
repetitive. Each package has its own repository, so there are a lot of
.gitignore files to configure. Also, the names that need to be ignored
depend on package version, so it is either messy globbing (or perhaps
regexing, if that is supported?) or updating every time version
increases. And 'fedpkg local' generates multiple files and directories
at repository root, yet another multiplier. Doing it manually every time
means spending time with ignore rules instead of packaging software.

The other option of not using 'git add .' can also be described as
mentally filtering out all the irrelevant unstaged changes to find the
ones that should actually be added. That adds cognitive burden, slows
things down and leads to mistakes every now and then. It does not help
to say "do not make mistakes" if the task is inherently error-prone.
Such filtering is something a computer should do, which leads us back to
.gitignore.

Perhaps a script could create the correct ignore globs for all
repositories in one go and that would be it, and have it in the template
for new repositories, too? Just an idea, perhaps not worth the effort
and complexity.

It would help much if 'fedpkg local' would only generate anything in a
single directory with constant name - 'build' or whatever.

(Oh, and for the original question about deprecating 'fedpkg local' - I
don't know. Before this discussion started, I was happily using 'fedpkg
local' and did not even know what mock was. I have to get in terms with
mock to form an opinion.)



The only times I use the git command in fedpkg is to merge between branches, or 
add/remove packages. If you're just doing changes to things already tracked, 
such as the spec, sources, patches, scripts, etc, fedpkg commit will add them 
for you. It also spits out a warning if you commit a spec with a Patch not 
tracked in git, which is nice.


Thank you for this advice Gwyn, and the same goes for Josh for useful 
git option in another response. I will certainly try these suggestions 
and see if they can make things easier for me.


Otto
___
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

Re: Proposal to deprecated `fedpkg local`



Dne 28. 01. 21 v 11:35 Thomas Moschny napsal(a):

3) The argument of mock being slow can't stand, because in one of my examples I 
posted elsewhere in this thread, I picked up the simplest package I could and 
the build took 7 seconds. This is certainly not slow, in this time you can't 
even switch to your email client to check your emails.

To add some data points: I roughly see a factor of 2 (with already
populated caches). For one of the smaller packages (xml2) it's ~6
seconds for `fedpkg local` vs ~15-20 seconds for `fedpkg mockbuild`.



Are you using --no-clean option? I guess this would give you back ~10s, 
because the would skip the build root initialization.



Vít



For one of the larger packages (shotwell) it's ~1 minute vs. ~2
minutes. So, from my POV, the argument of mock being slow still
stands.

- Thomas
___
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




OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Miroslav Suchý


Dne 28. 01. 21 v 11:54 Daniel P. Berrangé napsal(a):

Thus mock ends up using the slower storage since it isn't using /home.


A performance tips:
http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html

--
Miroslav Suchy, RHCA
Red Hat, Associate Manager, Community Packaging Tools, #brno, #fedora-buildsys
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Daniel P . Berrangé

On Thu, Jan 28, 2021 at 10:39:16AM +0100, Vít Ondruch wrote:
> 2) I would really love you to stop using VMs for your build/testing. With
> exception of Kernel and Kernel related issues, the argument of "mock being
> slow" can't stand. Every VM will be more resources hungry then mock, slowing
> every your task.

The point of having a VM is to have a live installed OS so you can install
and test runtime functionality the builds after they have completed. Mock
is not generally a substitute for this because mock environment is not a
running OS, it is just a chroot, so only a subset of packages can be viably
tested inside mock.

> 3) The argument of mock being slow can't stand, because in one of my
> examples I posted elsewhere in this thread, I picked up the simplest package
> I could and the build took 7 seconds. This is certainly not slow, in this
> time you can't even switch to your email client to check your emails.

I don't see numbers anything like that good with 'fedpkg mockbuild',
Taking my "libvirt-glib" package as a test

'fedpkg local' - 30 seconds
'fedpkg mockbuild' - 60 seconds  (warm cache)
'fedpkg mockbuild' - 5 minutes  (no cache)

and that's on my fast laptop with fast SSD.

On my machine development server which is a few years older

'fedpkg local' - 48 seconds
'fedpkg mockbuild' - 2 minutes 30 seconds (warm cache)
'fedpkg mockbuild' - 6 minutes 50 seconds  (no cache)


In this case /home is on SSD, and / is HDD.

Thus mock ends up using the slower storage since it isn't using /home.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Thomas Moschny

> 3) The argument of mock being slow can't stand, because in one of my examples 
> I posted elsewhere in this thread, I picked up the simplest package I could 
> and the build took 7 seconds. This is certainly not slow, in this time you 
> can't even switch to your email client to check your emails.

To add some data points: I roughly see a factor of 2 (with already
populated caches). For one of the smaller packages (xml2) it's ~6
seconds for `fedpkg local` vs ~15-20 seconds for `fedpkg mockbuild`.
For one of the larger packages (shotwell) it's ~1 minute vs. ~2
minutes. So, from my POV, the argument of mock being slow still
stands.

- Thomas
___
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

Re: Proposal to deprecated `fedpkg local`

Thx everybody for their responses and sorry for such controversial 
topic. I am not going to propose this upstream after all. However I have 
few takeaways:


1) I see responses of Fedora long timers and I understand that you have 
polished workflows. But I really think that for newcomers, mock should 
be the preferred way. I'd love to see documentation adjusted to prefer 
mock everywhere.


2) I would really love you to stop using VMs for your build/testing. 
With exception of Kernel and Kernel related issues, the argument of 
"mock being slow" can't stand. Every VM will be more resources hungry 
then mock, slowing every your task.


3) The argument of mock being slow can't stand, because in one of my 
examples I posted elsewhere in this thread, I picked up the simplest 
package I could and the build took 7 seconds. This is certainly not 
slow, in this time you can't even switch to your email client to check 
your emails.



Vít


Dne 27. 01. 21 v 17:17 Vít Ondruch napsal(a):

Hi,

I wonder, what would be the sentiment if I proposed to deprecated the 
`fedpkg local` command. I don't think it should be used. Mock should 
be the preferred way. Would there be anybody really missing this 
functionality?



Vít



___
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


OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 23:21 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 4:17 PM, Richard W.M. Jones  
wrote:


On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:


Hi,
I wonder, what would be the sentiment if I proposed to deprecated
the `fedpkg local` command. I don't think it should be used. Mock
should be the preferred way. Would there be anybody really missing
this functionality?

Why? I use it all the time. While I understand that it's not as
complete a local test as mock, it a lot quicker and less disruptive.
And if I want a real test I'll use a scratch build (because that's the
only way to test a build across architectures).


Agreed. Santa didn't bring me the s390x I asked for this year. :(



Just FTR, mock supports `--arch=ARCH` which will use emulation to allow 
you build whatever architecture localy. I have never used it myself, but 
I wanted to mention this.



Vít





TL;DR don't drop it.

Rich.

---

Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

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


___
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


OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-28 Thread Petr Pisar

On Wed, Jan 27, 2021 at 06:58:05PM +0100, Vít Ondruch wrote:
> Dne 27. 01. 21 v 18:53 Petr Menšík napsal(a):
> > This would describe my usual workflow as well. fedpkg local is great for
> > checking soname did not change, patches apply, to debugging why my test
> > suites fail and how they behave. mock usual does not have even vim
> 
> You have vim on your host with your configuration, why would you need it in
> mock?
>
$ fedpkg local
failed.
$ cd foo-1.2.3/
$ make test
t/foo failed.
$ vim t/foo
make some changes
$ make test
here is you debugging output

I find

$ vim 
/var/lib/mock/SOME_GIBBERISH_I_NEVER_REMEMBER_AND_I_DONT_KNOW_WHICH_IS_THE_RIGHT_ONE/root/builddir/build/BUILD/foo-1.2.3/t/foo

less useable.

-- Petr


signature.asc
Description: PGP 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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Christoph Karl


Hello,

On 27.01.21 17:17, Vít Ondruch wrote:

I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be
the preferred way. Would there be anybody really missing this
functionality?


For me even a step further:
I definitely want to know, which settings in my local environment have
an influence on the build.
To find them and to either fix them or make the build stable towards them.

Christoph
___
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

Re: Proposal to deprecated `fedpkg local`




-- 
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 4:17 PM, Richard W.M. Jones  
wrote:

> On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> 

> > Hi,
> > I wonder, what would be the sentiment if I proposed to deprecated
> > the `fedpkg local` command. I don't think it should be used. Mock
> > should be the preferred way. Would there be anybody really missing
> > this functionality?
> 

> Why? I use it all the time. While I understand that it's not as
> complete a local test as mock, it a lot quicker and less disruptive.
> And if I want a real test I'll use a scratch build (because that's the
> only way to test a build across architectures).
> 

Agreed. Santa didn't bring me the s390x I asked for this year. :(

> TL;DR don't drop it.
> 

> Rich.
> 

> ---
> 

> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Richard W.M. Jones

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> Hi,
> 
> I wonder, what would be the sentiment if I proposed to deprecated
> the `fedpkg local` command. I don't think it should be used. Mock
> should be the preferred way. Would there be anybody really missing
> this functionality?

Why?  I use it all the time.  While I understand that it's not as
complete a local test as mock, it a lot quicker and less disruptive.
And if I want a real test I'll use a scratch build (because that's the
only way to test a build across architectures).

TL;DR don't drop it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Josh Stone

On 1/27/21 2:04 PM, Otto Urpelainen wrote:
> The other option of not using 'git add .' can also be described as 
> mentally filtering out all the irrelevant unstaged changes to find the 
> ones that should actually be added. That adds cognitive burden, slows 
> things down and leads to mistakes every now and then. It does not help 
> to say "do not make mistakes" if the task is inherently error-prone. 
> Such filtering is something a computer should do, which leads us back to 
> .gitignore.

FWIW, 'git add -u' (--update) will limit you to files that are already
part of the repo. You still need to pay attention if there really are
new files though, like a new patch.
___
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

Re: Proposal to deprecated `fedpkg local`




-- 
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 4:04 PM, Otto Urpelainen  wrote:

> Gwyn Ciesla via devel kirjoitti 27.1.2021 klo 19.40:
> 

> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch vondr...@redhat.com 
> > wrote:
> > 

> > > Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):
> > > 

> > > > Question; What problem would be solved by removing fedpkg local that 
> > > > isn't addressed by documentation?
> > > 

> > > It would ensure, that people are using stable and predictable
> > > environment for Fedora development, keeping their system intact.
> > > This proposal was triggered specifically by comment from this ticket [1]:
> > > 

> > >  I still have a workflow issue, because running `fedpkg 
> > > local`generates a
> > >  huge amount of files that, in most repositories, are not in
> > >  `.gitignore`, leading to mistakes like this.
> > > 

> > > 

> > > This is simply not good user experience.
> > 

> > If the user doesn't 'git add .', or has a correct .gitignore, this should 
> > be a non issue.
> 

> Me being the quoted person with a workflow issue, I still think there is
> a workflow issue.
> 

> Setting .gitignore is possible of course, but rather annoying and
> repetitive. Each package has its own repository, so there are a lot of
> .gitignore files to configure. Also, the names that need to be ignored
> depend on package version, so it is either messy globbing (or perhaps
> regexing, if that is supported?) or updating every time version
> increases. And 'fedpkg local' generates multiple files and directories
> at repository root, yet another multiplier. Doing it manually every time
> means spending time with ignore rules instead of packaging software.
> 

> The other option of not using 'git add .' can also be described as
> mentally filtering out all the irrelevant unstaged changes to find the
> ones that should actually be added. That adds cognitive burden, slows
> things down and leads to mistakes every now and then. It does not help
> to say "do not make mistakes" if the task is inherently error-prone.
> Such filtering is something a computer should do, which leads us back to
> .gitignore.
> 

> Perhaps a script could create the correct ignore globs for all
> repositories in one go and that would be it, and have it in the template
> for new repositories, too? Just an idea, perhaps not worth the effort
> and complexity.
> 

> It would help much if 'fedpkg local' would only generate anything in a
> single directory with constant name - 'build' or whatever.
> 

> (Oh, and for the original question about deprecating 'fedpkg local' - I
> don't know. Before this discussion started, I was happily using 'fedpkg
> local' and did not even know what mock was. I have to get in terms with
> mock to form an opinion.)
> 


The only times I use the git command in fedpkg is to merge between branches, or 
add/remove packages. If you're just doing changes to things already tracked, 
such as the spec, sources, patches, scripts, etc, fedpkg commit will add them 
for you. It also spits out a warning if you commit a spec with a Patch not 
tracked in git, which is nice.


> Otto
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Simo Sorce

On Wed, 2021-01-27 at 17:17 +0100, Vít Ondruch wrote:
> Hi,
> 
> I wonder, what would be the sentiment if I proposed to deprecated the 
> `fedpkg local` command. I don't think it should be used. Mock should be 
> the preferred way. Would there be anybody really missing this functionality?

Sorry I a completely against this.

I use fedpkg local very often, and mock is something I never use.
If I need a clean build environemnt I simply launch a scratch build in koji.

When I used fedpkg local I very much do not care for a clena
environment and may *very* well depend on the actual packages I have
currently installed.

In short, I am not amused by this proposal, it is about removing an
extremely useful tool.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Otto Urpelainen


Gwyn Ciesla via devel kirjoitti 27.1.2021 klo 19.40:
 
‐‐‐ Original Message ‐‐‐

On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch  
wrote:


Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):


Question; What problem would be solved by removing fedpkg local that isn't 
addressed by documentation?


It would ensure, that people are using stable and predictable
environment for Fedora development, keeping their system intact.

This proposal was triggered specifically by comment from this ticket [1]:

 I still have a workflow issue, because running `fedpkg local`generates a
 huge amount of files that, in most repositories, are not in
 `.gitignore`, leading to mistakes like this.
 
This is simply not good user experience.




If the user doesn't 'git add .', or has a correct .gitignore, this should be a 
non issue.



Me being the quoted person with a workflow issue, I still think there is 
a workflow issue.


Setting .gitignore is possible of course, but rather annoying and 
repetitive. Each package has its own repository, so there are a lot of 
.gitignore files to configure. Also, the names that need to be ignored 
depend on package version, so it is either messy globbing (or perhaps 
regexing, if that is supported?) or updating every time version 
increases. And 'fedpkg local' generates multiple files and directories 
at repository root, yet another multiplier. Doing it manually every time 
 means spending time with ignore rules instead of packaging software.


The other option of not using 'git add .' can also be described as 
mentally filtering out all the irrelevant unstaged changes to find the 
ones that should actually be added. That adds cognitive burden, slows 
things down and leads to mistakes every now and then. It does not help 
to say "do not make mistakes" if the task is inherently error-prone. 
Such filtering is something a computer should do, which leads us back to 
.gitignore.


Perhaps a script could create the correct ignore globs for all 
repositories in one go and that would be it, and have it in the template 
for new repositories, too? Just an idea, perhaps not worth the effort 
and complexity.


It would help much if 'fedpkg local' would only generate anything in a 
single directory with constant name - 'build' or whatever.


(Oh, and for the original question about deprecating 'fedpkg local' - I 
don't know. Before this discussion started, I was happily using 'fedpkg 
local' and did not even know what mock was. I have to get in terms with 
mock to form an opinion.)


Otto
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Zbigniew Jędrzejewski-Szmek

+1 to everything that Gwyn said.

'fedpkg local' is just so immensely useful for initial package developement.

I also use it a lot for systemd & friends: I *want* to build packages
against the local environment and install them locally without pulling
in any other package updates, and I want to be able to debug build or
test failures in the host environment.

(I also use mock in various configurations, and copr, and scratch
builds, etc. I find mock immensely useful too, but in a later phase of
package development. Different tools have different tradeoffs.)

Zbyszek
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Ken Dreyer

On Wed, Jan 27, 2021 at 9:17 AM Vít Ondruch  wrote:
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?

Seems like this is a speed-vs-correctness thing.

I prefer "fedpkg mock" personally, because it's closer to what Koji
does, but it is definitely slower.

What if the pyrpkg --help text for the local sub-command steered new
users away from "local"? Or at least explained the caveats involved?

- Ken
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Robbie Harwood

Vít Ondruch  writes:

> Hi,
>
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should
> be the preferred way. Would there be anybody really missing this
> functionality?

I would miss it.  It's nontrivially faster to `fedpkg local` than
`fedpkg mockbuild` since I don't have to wait for dnf multiple times.
The overhead can be quite high.

Thanks,
--Robbie


signature.asc
Description: PGP 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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread David Howells

Vít Ondruch  wrote:

> I wonder, what would be the sentiment if I proposed to deprecated the `fedpkg
> local` command. I don't think it should be used. Mock should be the preferred
> way. Would there be anybody really missing this functionality?

Mock is waaay overkill a lot of the time.  It's a lot simpler and easier just
to do fedpkg local.  The main thing wrong with fedpkg local is that it likes
to put stuff in the user's homedir - something it shouldn't do unless it's
actually run there.  That's a pain if the user's homedir is on a network
filesystem.

David
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread J. Bruce Fields

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should
> be the preferred way. Would there be anybody really missing this
> functionality?

For what it's worth, when I do a search for "how to build a fedora
kernel", the first three hits I get are:

https://fedoraproject.org/wiki/Building_a_custom_kernel

https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/
https://fedoramagazine.org/building-fedora-kernel/

which all use "fedpkg local".

--b.
___
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

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 18:53 Petr Menšík napsal(a):

Hi,

This would describe my usual workflow as well. fedpkg local is great for
checking soname did not change, patches apply, to debugging why my test
suites fail and how they behave. mock usual does not have even vim


You have vim on your host with your configuration, why would you need it 
in mock?




, let
alone gdb or something better.



GDB works in mock just fine.

Vít




In other words, i use fedpkg local a lot and would miss it much. I
understand what mockbuild is for, but for any iterative improvements
done to my package, fedpkg local is much better. Don't remove it,
please. Especially in bind, which includes latex documentation building,
are installed dependencies slowing one iteration significantly.

On 1/27/21 5:43 PM, Daniel P. Berrangé wrote:

On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:

On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
 wrote:

It's needed for testing builds against versions of packages not yet in mock. I 
use it almost every day. Losing it would make things like testing solib bumps 
harder.

I've done local test builds for soname bumps and similar things lots
of times, and I've never used (or thought about using) fedpkg local
for that.
I used "mock --chain" or a combination of "mock --postinstall
--no-clean" for those builds ... which is much closer to what koji
will do with your builds, and gives every build the clean environment
it deserves >:-)

If you want to closely replicate that koji will do, then no disagreement
that use of mock is the right tool (or just a koji scratch-build). That
just isn't a requirement much of the time though.

For adhoc development and debugging of RPM spec changes/updates, mock
gets in the way and slows things down. I could easily do 10-20 "local"
runs while getting an complex change working, and then finish off with
just one or two mock build or koji scratch-build to validate it in a
pristine build root env at the end.


Regards,
Daniel



___
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


OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Justin Forbes

On Wed, Jan 27, 2021 at 10:18 AM Vít Ondruch  wrote:
>
> Hi,
>
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be
> the preferred way. Would there be anybody really missing this functionality?
>

I would greatly miss this functionality. Outside of the obvious speed
benefits of skipping mock setup, the bigger issue is various new
buildreqs get brought into packages, and comparing fedpkg local to
fedpkg mockbuild results are a great way to see if those buildreqs are
required, and what the impact is on the build with and without them.
Sure, I can just run rpmbuild commands by hand, but I have gotten used
to and appreciate the simplicity of fedpkg local.

Justin
___
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

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 06:00:42PM +0100, Vít Ondruch wrote:
> 
> Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):
> > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> > > Hi,
> > > 
> > > I wonder, what would be the sentiment if I proposed to deprecated the
> > > `fedpkg local` command. I don't think it should be used. Mock should be 
> > > the
> > > preferred way. Would there be anybody really missing this functionality?
> > While I understand that mock has the benefit of providing a well
> > defined build environment, with less scope for things going wrong,
> > that just isn't important to me most of the time. In fact I often
> > want to build against what I have installed locally, explicitly
> > *not* against what mock has in its build root.
> > 
> > So overall "fedpkg local" has the benefit that it is much faster
> > to run the build and simpler to get it to build what I want.
> 
> 
> While there is certainly penalty in using mock, running repetitive builds
> together with `--no-clean` option will hardly slow you down. Just a few
> numbers.
> 
> 1) Starging from scratch after `mock --scrub=all`, every package have to be
> downloaded and installed:
> 
> ~~~
> 
> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 
> ... snip ...
> 
> real    0m47,188s
> user    0m41,841s
> sys    0m6,040s
> 
> ~~~
> 
> 
> 2) With warm cache, only the BRs are installed, running right after the
> previous build:
> 
> ~~~
> 
> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 
> ... snip ...
> 
> real    0m13,182s
> user    0m9,885s
> sys    0m2,701s
> 
> ~~~
> 
> 
> 3) Without build root cleanup:
> 
> ~~~
> 
> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n
> 
> ... snip ...
> 
> real    0m7,563s
> user    0m6,139s
> sys    0m1,194s
> 
> ~~~
> 
> 
> I think this is acceptable penalty for keeping my system unpolluted and
> giving me easy opportunity to start from scratch if I messed up or if my
> dependencies have changed or what not.

"keep my system unpolluted" is not a goal that's relevant, so it
doesn't justify the overhead of using mock.

The act of doing a build doesn't pollute my system. Installing the
package I built and testing it can pollute it, but that part is the
same even if I'm using mock to perform the build.  None of this
takes place in my important host, it is in a throwaway VM because
I need a full running OS install for testing the resulting package
no matter how it is built.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Petr Menšík

Hi,

This would describe my usual workflow as well. fedpkg local is great for
checking soname did not change, patches apply, to debugging why my test
suites fail and how they behave. mock usual does not have even vim, let
alone gdb or something better.

In other words, i use fedpkg local a lot and would miss it much. I
understand what mockbuild is for, but for any iterative improvements
done to my package, fedpkg local is much better. Don't remove it,
please. Especially in bind, which includes latex documentation building,
are installed dependencies slowing one iteration significantly.

On 1/27/21 5:43 PM, Daniel P. Berrangé wrote:
> On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
>> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
>>  wrote:
>>>
>>> It's needed for testing builds against versions of packages not yet in 
>>> mock. I use it almost every day. Losing it would make things like testing 
>>> solib bumps harder.
>>
>> I've done local test builds for soname bumps and similar things lots
>> of times, and I've never used (or thought about using) fedpkg local
>> for that.
>> I used "mock --chain" or a combination of "mock --postinstall
>> --no-clean" for those builds ... which is much closer to what koji
>> will do with your builds, and gives every build the clean environment
>> it deserves >:-)
> 
> If you want to closely replicate that koji will do, then no disagreement
> that use of mock is the right tool (or just a koji scratch-build). That
> just isn't a requirement much of the time though.
> 
> For adhoc development and debugging of RPM spec changes/updates, mock
> gets in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end. 
> 
> 
> Regards,
> Daniel
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Petr Pisar

On Wed, Jan 27, 2021 at 04:43:35PM +, Daniel P. Berrangé wrote:
> On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
> > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> >  wrote:
> > >
> > > It's needed for testing builds against versions of packages not yet in 
> > > mock. I use it almost every day. Losing it would make things like testing 
> > > solib bumps harder.
> > 
> > I've done local test builds for soname bumps and similar things lots
> > of times, and I've never used (or thought about using) fedpkg local
> > for that.
> > I used "mock --chain" or a combination of "mock --postinstall
> > --no-clean" for those builds ... which is much closer to what koji
> > will do with your builds, and gives every build the clean environment
> > it deserves >:-)
> 
> If you want to closely replicate that koji will do, then no disagreement
> that use of mock is the right tool (or just a koji scratch-build). That
> just isn't a requirement much of the time though.
> 
> For adhoc development and debugging of RPM spec changes/updates, mock
> gets in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end. 
> 
Exactly. I also use "fedpkg local" in my pet virtual machine. Pretty often.
It's faster, more interactive, easier for debugging.

Does mock still need root (membership in mock group)?

-- Petr


signature.asc
Description: PGP 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

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 06:33:30PM +0100, Vít Ondruch wrote:
> 
> Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):
> > 
> > Question; What problem would be solved by removing fedpkg local that isn't 
> > addressed by documentation?
> > 
> 
> It would ensure, that people are using stable and predictable environment
> for Fedora development, keeping their system intact.

"keeping their system intact" isn't a goal for me.

My work is already inside a throwaway VM, because after doing a
local build, I want to install the package and actually attempt
to use it in a real running system.

> 
> This proposal was triggered specifically by comment from this ticket [1]:
> 
> ~~~
> 
> I still have a workflow issue, because running `fedpkg local`generates a
> huge amount of files that, in most repositories, are not in `.gitignore`,
> leading to mistakes like this.
> 
> ~~~
> 
> This is simply not good user experience.

The fault in this case is not the existance of "fedpkg local", rather
it is a combination of poor default locations for "fedpkg local" when
unpacking the RPM, and poor .gitignore contents.

eg it'll create a .build-$SOMEVERSION.log file every time, and unpack
the tarball into the base directory, neither of which are in the git
ignore list. And the results get put into an x86_64/ (or other arch)
subdirectory which again isn't in the gitignore.

It should be easy to make fedpkg local only ever create files within
a "build/" sub-directory and have this subdir be in the dist-git
.gitignore file out of the box.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Proposal to deprecated `fedpkg local`




-- 
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:33 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):
> 

> > Question; What problem would be solved by removing fedpkg local that isn't 
> > addressed by documentation?
> 

> It would ensure, that people are using stable and predictable
> environment for Fedora development, keeping their system intact.
> 

> This proposal was triggered specifically by comment from this ticket [1]:
> 

> 

> I still have a workflow issue, because running `fedpkg local`generates a
> huge amount of files that, in most repositories, are not in
> `.gitignore`, leading to mistakes like this.
> 

> 

> 

> This is simply not good user experience.
> 


If the user doesn't 'git add .', or has a correct .gitignore, this should be a 
non issue.

> Vít
> 

> [1] https://src.fedoraproject.org/rpms/rubygem-jekyll/pull-request/4
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a):


Question; What problem would be solved by removing fedpkg local that isn't 
addressed by documentation?



It would ensure, that people are using stable and predictable 
environment for Fedora development, keeping their system intact.


This proposal was triggered specifically by comment from this ticket [1]:

~~~

I still have a workflow issue, because running `fedpkg local`generates a 
huge amount of files that, in most repositories, are not in 
`.gitignore`, leading to mistakes like this.


~~~

This is simply not good user experience.


Vít



[1] https://src.fedoraproject.org/rpms/rubygem-jekyll/pull-request/4




OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`




-- 
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  
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  
> > 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

Re: Proposal to deprecated `fedpkg local`




-- 
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:10 AM, Fabio Valentini  
wrote:

> On Wed, Jan 27, 2021 at 6:04 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org wrote:
> 

> > Great! And you can keep doing that! That's a good thing to have. fedpkg 
> > local also works without network access, like on a train, if you have all 
> > your BuildRequires in place.
> 

> If that's all you want, why not use plain rpmbuild (either -ba for
> .spec file or -ra for .src.rpm file)?
> 


That doesn't work in the fedpkg clone, it requires installing the SRPM locally.

> Additionally, with features like %generate_buildrequires becoming more
> widely used, mock is certainly the easiest way to build those packages
> ...
> 

> Fabio
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`



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 
 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.



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




OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`




-- 
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:16 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 18:03 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 11:00 AM, Vít Ondruch vondr...@redhat.com 
> > wrote:
> > 

> > > Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):
> > > 

> > > > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> > > > 

> > > > > Hi,
> > > > > I wonder, what would be the sentiment if I proposed to deprecated the
> > > > > `fedpkg local` command. I don't think it should be used. Mock should 
> > > > > be the
> > > > > preferred way. Would there be anybody really missing this 
> > > > > functionality?
> > > > > While I understand that mock has the benefit of providing a well
> > > > > defined build environment, with less scope for things going wrong,
> > > > > that just isn't important to me most of the time. In fact I often
> > > > > want to build against what I have installed locally, explicitly
> > > > > not against what mock has in its build root.
> > > > > So overall "fedpkg local" has the benefit that it is much faster
> > > > > to run the build and simpler to get it to build what I want.
> > > > > While there is certainly penalty in using mock, running repetitive
> > > > > builds together with `--no-clean` option will hardly slow you down. 
> > > > > Just
> > > > > a few numbers.
> > > 

> > > 1.  Starging from scratch after `mock --scrub=all`, every package have to
> > > be downloaded and installed:
> > > $ time mock -r fedora-rawhide-x86_64 
> > > rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> > > ... snip ...
> > > real    0m47,188s
> > > user    0m41,841s
> > > sys    0m6,040s
> > > 

> > > 

> > > 2.  With warm cache, only the BRs are installed, running right after the
> > > previous build:
> > > $ time mock -r fedora-rawhide-x86_64 
> > > rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> > > ... snip ...
> > > real    0m13,182s
> > > user    0m9,885s
> > > sys    0m2,701s
> > > 

> > > 3.  Without build root cleanup:
> > > $ time mock -r fedora-rawhide-x86_64 
> > > rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n
> > > ... snip ...
> > > real    0m7,563s
> > > user    0m6,139s
> > > sys    0m1,194s
> > > 

> > > 

> > > I think this is acceptable penalty for keeping my system unpolluted and
> > > giving me easy opportunity to start from scratch if I messed up or if my
> > > dependencies have changed or what not.
> > 

> > Great! And you can keep doing that! That's a good thing to have. fedpkg 
> > local also works without network access, like on a train, if you have all 
> > your BuildRequires in place.
> 

> No difference here. Mock works fine without network, if you have your
> caches populated.

True.

Question; What problem would be solved by removing fedpkg local that isn't 
addressed by documentation?

> Vít
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 18:03 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 11:00 AM, Vít Ondruch  
wrote:


Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):


On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:


Hi,
I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be the
preferred way. Would there be anybody really missing this functionality?
While I understand that mock has the benefit of providing a well
defined build environment, with less scope for things going wrong,
that just isn't important to me most of the time. In fact I often
want to build against what I have installed locally, explicitly
not against what mock has in its build root.

So overall "fedpkg local" has the benefit that it is much faster
to run the build and simpler to get it to build what I want.

While there is certainly penalty in using mock, running repetitive
builds together with `--no-clean` option will hardly slow you down. Just
a few numbers.

1.  Starging from scratch after `mock --scrub=all`, every package have to
 be downloaded and installed:
 
 
 $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
 
 ... snip ...
 
 real    0m47,188s

 user    0m41,841s
 sys    0m6,040s
 
 
2) With warm cache, only the BRs are installed, running right after the

previous build:

 
 $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
 
 ... snip ...
 
 real    0m13,182s

 user    0m9,885s
 sys    0m2,701s
 
 
3) Without build root cleanup:


 
 $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n
 
 ... snip ...
 
 real    0m7,563s

 user    0m6,139s
 sys    0m1,194s
 
 
I think this is acceptable penalty for keeping my system unpolluted and

giving me easy opportunity to start from scratch if I messed up or if my
dependencies have changed or what not.



Great! And you can keep doing that! That's a good thing to have. fedpkg local 
also works without network access, like on a train, if you have all your 
BuildRequires in place.



No difference here. Mock works fine without network, if you have your 
caches populated.



Vít





OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

Dne 27. 01. 21 v 17:59 Colin Walters napsal(a):

On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch 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.

Personally I spend 95% of my time inside an unprivileged pet "toolbox" style container
with podman; I very very rarely execute any commands on the "host" context.

I can imagine, I am using Mock as the "pet toolbox style container". For
Fedora development, `mock --init` is more convenient then `podman build`
or what is the right command.

And mock doesn't really nest well (nested containers in general are possible
but still involve some tricky compromises).

So I use `fedpkg local` a lot, and I also often install these packages into my
dev container *or* I just skip RPM entirely and `sudo make install`. For
CoreOS stuff I use
https://coreos.github.io/coreos-assembler/working/#using-overrides a lot which
makes it convenient to take these built binaries and launch them in qemu.

This of course gets into the broader overlap between mock/podman and
Koji/Kubernetes which is also touched on in
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
=)

It'd all be much more obvious if the RPM buildroot was just:
```
FROM registry.fedoraproject.org/fedora-buildroot:33
RUN yum builddep foo.spec
RUN fedpkg local

I think this is problematic for Rawhide development, because I don't
think we have fresh image often enough. Once you have to used DNF/YUM,
you are loosing the advantage you could possibly get.

```
And so if you want a pristine build locally you just use a wrapper tool which
scripts unprivileged podman. (Yes, this loses RPM caching if done naively but
has other massive advantages, such as being able to trivially spin up a shell
on a remote Kube cluster that is *exactly* the build environment, etc.)

Thank you for sharing this perspective, because this is definitely
scenario I would have on my mind.

Vít

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Fabio Valentini

On Wed, Jan 27, 2021 at 6:04 PM Gwyn Ciesla via devel
 wrote:
> Great! And you can keep doing that! That's a good thing to have. fedpkg local 
> also works without network access, like on a train, if you have all your 
> BuildRequires in place.

If that's all you want, why not use plain rpmbuild (either -ba for
.spec file or -ra for .src.rpm file)?

Additionally, with features like %generate_buildrequires becoming more
widely used, mock is certainly the easiest way to build those packages
...

Fabio
___
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

Re: Proposal to deprecated `fedpkg local`




-- 
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:00 AM, Vít Ondruch  
wrote:

> Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):
> 

> > On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> > 

> > > Hi,
> > > I wonder, what would be the sentiment if I proposed to deprecated the
> > > `fedpkg local` command. I don't think it should be used. Mock should be 
> > > the
> > > preferred way. Would there be anybody really missing this functionality?
> > > While I understand that mock has the benefit of providing a well
> > > defined build environment, with less scope for things going wrong,
> > > that just isn't important to me most of the time. In fact I often
> > > want to build against what I have installed locally, explicitly
> > > not against what mock has in its build root.
> > 

> > So overall "fedpkg local" has the benefit that it is much faster
> > to run the build and simpler to get it to build what I want.
> 

> While there is certainly penalty in using mock, running repetitive
> builds together with `--no-clean` option will hardly slow you down. Just
> a few numbers.
> 

> 1.  Starging from scratch after `mock --scrub=all`, every package have to
> be downloaded and installed:
> 

> 

> 

> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 

> ... snip ...
> 

> real    0m47,188s
> user    0m41,841s
> sys    0m6,040s
> 

> 

> 

> 2) With warm cache, only the BRs are installed, running right after the
> previous build:
> 

> 

> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm
> 

> ... snip ...
> 

> real    0m13,182s
> user    0m9,885s
> sys    0m2,701s
> 

> 

> 

> 3) Without build root cleanup:
> 

> 

> $ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm 
> -n
> 

> ... snip ...
> 

> real    0m7,563s
> user    0m6,139s
> sys    0m1,194s
> 

> 

> 

> I think this is acceptable penalty for keeping my system unpolluted and
> giving me easy opportunity to start from scratch if I messed up or if my
> dependencies have changed or what not.
> 


Great! And you can keep doing that! That's a good thing to have. fedpkg local 
also works without network access, like on a train, if you have all your 
BuildRequires in place.

> Vít
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`

Actually, I forgot `mock --enablerepo=local some.srpm` which download 
the freshest packages for the build root directly from Koji.



Vít


Dne 27. 01. 21 v 17:50 Vít Ondruch napsal(a):


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.



Vít


Dne 27. 01. 21 v 17:37 Radovan Sroka napsal(a):
"fedpkg local lets me cycle through build failures faster in the 
early stages"


Totally agree.

On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel 
> wrote:





-- 
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:27 AM, Fabio Valentini
mailto:decatho...@gmail.com>> wrote:

> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org
 wrote:
>

> > It's needed for testing builds against versions of packages
not yet in mock. I use it almost every day. Losing it would make
things like testing solib bumps harder.
>

> I've done local test builds for soname bumps and similar things
lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean
environment
> it deserves >:-)

That's a great thing to do, but fedpkg local lets me cycle
through build failures faster in the early stages. I'd really
hate to see it go; If others don't use it, they can keep not
using it. :)

>

> Fabio
>

> 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



___
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





--
--
-

Radovan Sroka
Software Engineer | Security Technologies | Red Hat, Inc.

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


___
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


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list --

Re: Proposal to deprecated `fedpkg local`



Dne 27. 01. 21 v 17:38 Daniel P. Berrangé napsal(a):

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:

Hi,

I wonder, what would be the sentiment if I proposed to deprecated the
`fedpkg local` command. I don't think it should be used. Mock should be the
preferred way. Would there be anybody really missing this functionality?

While I understand that mock has the benefit of providing a well
defined build environment, with less scope for things going wrong,
that just isn't important to me most of the time. In fact I often
want to build against what I have installed locally, explicitly
*not* against what mock has in its build root.

So overall "fedpkg local" has the benefit that it is much faster
to run the build and simpler to get it to build what I want.



While there is certainly penalty in using mock, running repetitive 
builds together with `--no-clean` option will hardly slow you down. Just 
a few numbers.


1) Starging from scratch after `mock --scrub=all`, every package have to 
be downloaded and installed:


~~~

$ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm

... snip ...

real    0m47,188s
user    0m41,841s
sys    0m6,040s

~~~


2) With warm cache, only the BRs are installed, running right after the 
previous build:


~~~

$ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm

... snip ...

real    0m13,182s
user    0m9,885s
sys    0m2,701s

~~~


3) Without build root cleanup:

~~~

$ time mock -r fedora-rawhide-x86_64 rubygem-net-ssh-5.2.0-2.fc34.src.rpm -n

... snip ...

real    0m7,563s
user    0m6,139s
sys    0m1,194s

~~~


I think this is acceptable penalty for keeping my system unpolluted and 
giving me easy opportunity to start from scratch if I messed up or if my 
dependencies have changed or what not.




Vít





OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Colin Walters

On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch 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.

Personally I spend 95% of my time inside an unprivileged pet "toolbox" style 
container with podman; I very very rarely execute any commands on the "host" 
context.

And mock doesn't really nest well (nested containers in general are possible 
but still involve some tricky compromises).

So I use `fedpkg local` a lot, and I also often install these packages into my 
dev container *or* I just skip RPM entirely and `sudo make install`.  For 
CoreOS stuff I use 
https://coreos.github.io/coreos-assembler/working/#using-overrides a lot which 
makes it convenient to take these built binaries and launch them in qemu.

This of course gets into the broader overlap between mock/podman and 
Koji/Kubernetes which is also touched on in 
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
 =)

It'd all be much more obvious if the RPM buildroot was just:
```
FROM registry.fedoraproject.org/fedora-buildroot:33
RUN yum builddep foo.spec
RUN fedpkg local
```
And so if you want a pristine build locally you just use a wrapper tool which 
scripts unprivileged podman.  (Yes, this loses RPM caching if done naively but 
has other massive advantages, such as being able to trivially spin up a shell 
on a remote Kube cluster that is *exactly* the build environment, etc.)

___
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

Re: Proposal to deprecated `fedpkg local`




-- 
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  
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, and clone the LibRaw repo, update the spec, build, and 
install it. Then I clone the dependant repos, update their specs, and build 
them.  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, 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.

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.

> Vít
> 

> Dne 27. 01. 21 v 17:37 Radovan Sroka napsal(a):
> 

> > "fedpkg local lets me cycle through build failures faster in the early 
> > stages"
> > 

> > Totally agree.
> > 

> > On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel 
> >  wrote:
> > 

> > > -- 
> > > 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:27 AM, Fabio Valentini 
> > >  wrote:
> > > 

> > > > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> > > > devel@lists.fedoraproject.org wrote:
> > > >
> > > 

> > > > > It's needed for testing builds against versions of packages not yet 
> > > > > in mock. I use it almost every day. Losing it would make things like 
> > > > > testing solib bumps harder.
> > > >
> > > 

> > > > I've done local test builds for soname bumps and similar things lots
> > > > of times, and I've never used (or thought about using) fedpkg local
> > > > for that.
> > > > I used "mock --chain" or a combination of "mock --postinstall
> > > > --no-clean" for those builds ... which is much closer to what koji
> > > > will do with your builds, and gives every build the clean environment
> > > > it deserves >:-)
> > > 

> > > That's a great thing to do, but fedpkg local lets me cycle through build 
> > > failures faster in the early stages. I'd really hate to see it go; If 
> > > others don't use it, they can keep not using it. :)
> > > 

> > > >
> > > 

> > > > Fabio
> > > >
> > > 

> > > > 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
> > > 

> > > ___
> > > 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
> > 

> > --
> > 

> > --
> > -
> > 

> > Radovan Sroka
> > Software Engineer | Security Technologies | Red Hat, Inc.
> > 

> > ___
> > 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



signature.asc
Description: OpenPGP digital signature
___
devel mailing

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Dan Horák

On Wed, 27 Jan 2021 16:43:35 +
Daniel P. Berrangé  wrote:

> On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
> > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> >  wrote:
> > >
> > > It's needed for testing builds against versions of packages not yet in 
> > > mock. I use it almost every day. Losing it would make things like testing 
> > > solib bumps harder.
> > 
> > I've done local test builds for soname bumps and similar things lots
> > of times, and I've never used (or thought about using) fedpkg local
> > for that.
> > I used "mock --chain" or a combination of "mock --postinstall
> > --no-clean" for those builds ... which is much closer to what koji
> > will do with your builds, and gives every build the clean environment
> > it deserves >:-)
> 
> If you want to closely replicate that koji will do, then no disagreement
> that use of mock is the right tool (or just a koji scratch-build). That
> just isn't a requirement much of the time though.
> 
> For adhoc development and debugging of RPM spec changes/updates, mock
> gets in the way and slows things down. I could easily do 10-20 "local"
> runs while getting an complex change working, and then finish off with
> just one or two mock build or koji scratch-build to validate it in a
> pristine build root env at the end. 

that describes my workflow too :-)


Dan
___
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

Re: Proposal to deprecated `fedpkg local`

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.



Vít


Dne 27. 01. 21 v 17:37 Radovan Sroka napsal(a):
"fedpkg local lets me cycle through build failures faster in the early 
stages"


Totally agree.

On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel 
mailto:devel@lists.fedoraproject.org>> 
wrote:





-- 
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:27 AM, Fabio Valentini
mailto:decatho...@gmail.com>> wrote:

> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org
 wrote:
>

> > It's needed for testing builds against versions of packages
not yet in mock. I use it almost every day. Losing it would make
things like testing solib bumps harder.
>

> I've done local test builds for soname bumps and similar things lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean
environment
> it deserves >:-)

That's a great thing to do, but fedpkg local lets me cycle through
build failures faster in the early stages. I'd really hate to see
it go; If others don't use it, they can keep not using it. :)

>

> Fabio
>

> 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



___
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





--
--
-

Radovan Sroka
Software Engineer | Security Technologies | Red Hat, Inc.

___
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


OpenPGP_signature
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

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:27:12PM +0100, Fabio Valentini wrote:
> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
>  wrote:
> >
> > It's needed for testing builds against versions of packages not yet in 
> > mock. I use it almost every day. Losing it would make things like testing 
> > solib bumps harder.
> 
> I've done local test builds for soname bumps and similar things lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean environment
> it deserves >:-)

If you want to closely replicate that koji will do, then no disagreement
that use of mock is the right tool (or just a koji scratch-build). That
just isn't a requirement much of the time though.

For adhoc development and debugging of RPM spec changes/updates, mock
gets in the way and slows things down. I could easily do 10-20 "local"
runs while getting an complex change working, and then finish off with
just one or two mock build or koji scratch-build to validate it in a
pristine build root env at the end. 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Proposal to deprecated `fedpkg local`

On Wed, Jan 27, 2021 at 05:17:24PM +0100, Vít Ondruch wrote:
> Hi,
> 
> I wonder, what would be the sentiment if I proposed to deprecated the
> `fedpkg local` command. I don't think it should be used. Mock should be the
> preferred way. Would there be anybody really missing this functionality?

While I understand that mock has the benefit of providing a well
defined build environment, with less scope for things going wrong,
that just isn't important to me most of the time. In fact I often
want to build against what I have installed locally, explicitly
*not* against what mock has in its build root.

So overall "fedpkg local" has the benefit that it is much faster
to run the build and simpler to get it to build what I want.

I view these ways of building as targetting partially overlapping
sets - neither can handle all scenarios effectively, so both are
desirable to have.

IOW by all means steer people towards use of mock as the preferred
option to avoid less experienced people getting burnt by local
install problems, but please don't take away "fedpkg local" as I
use it practically every day.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Radovan Sroka

"fedpkg local lets me cycle through build failures faster in the early
stages"

Totally agree.

On Wed, Jan 27, 2021 at 5:34 PM Gwyn Ciesla via devel <
devel@lists.fedoraproject.org> wrote:

>
>
>
> --
> 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:27 AM, Fabio Valentini <
> decatho...@gmail.com> wrote:
>
> > On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> > devel@lists.fedoraproject.org wrote:
> >
>
> > > It's needed for testing builds against versions of packages not yet in
> mock. I use it almost every day. Losing it would make things like testing
> solib bumps harder.
> >
>
> > I've done local test builds for soname bumps and similar things lots
> > of times, and I've never used (or thought about using) fedpkg local
> > for that.
> > I used "mock --chain" or a combination of "mock --postinstall
> > --no-clean" for those builds ... which is much closer to what koji
> > will do with your builds, and gives every build the clean environment
> > it deserves >:-)
>
> That's a great thing to do, but fedpkg local lets me cycle through build
> failures faster in the early stages. I'd really hate to see it go; If
> others don't use it, they can keep not using it. :)
>
> >
>
> > Fabio
> >
>
> > 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
>
> ___
> 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
>


-- 
--
-

Radovan Sroka
Software Engineer | Security Technologies | Red Hat, Inc.
___
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

Re: Proposal to deprecated `fedpkg local`




-- 
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:27 AM, Fabio Valentini  
wrote:

> On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
> devel@lists.fedoraproject.org wrote:
> 

> > It's needed for testing builds against versions of packages not yet in 
> > mock. I use it almost every day. Losing it would make things like testing 
> > solib bumps harder.
> 

> I've done local test builds for soname bumps and similar things lots
> of times, and I've never used (or thought about using) fedpkg local
> for that.
> I used "mock --chain" or a combination of "mock --postinstall
> --no-clean" for those builds ... which is much closer to what koji
> will do with your builds, and gives every build the clean environment
> it deserves >:-)

That's a great thing to do, but fedpkg local lets me cycle through build 
failures faster in the early stages. I'd really hate to see it go; If others 
don't use it, they can keep not using it. :)

> 

> Fabio
> 

> 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



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

Re: Proposal to deprecated `fedpkg local`

2021-01-27 Thread Fabio Valentini

On Wed, Jan 27, 2021 at 5:24 PM Gwyn Ciesla via devel
 wrote:
>
> It's needed for testing builds against versions of packages not yet in mock. 
> I use it almost every day. Losing it would make things like testing solib 
> bumps harder.

I've done local test builds for soname bumps and similar things lots
of times, and I've never used (or thought about using) fedpkg local
for that.
I used "mock --chain" or a combination of "mock --postinstall
--no-clean" for those builds ... which is much closer to what koji
will do with your builds, and gives every build the clean environment
it deserves >:-)

Fabio
___
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

Re: Proposal to deprecated `fedpkg local`