OK, since I do a bunch of builds I just had to try this out. It took
me a while to get building again after moving from mock 0.4 to 0.5;
I'm still not sure where the buildsys-build package is supposed to
come from, so I just built the spec I found in mock CVS and stuck it
in my local repo.
Basic
With this and the "gzip by default" patch my build times are
down by another 40 seconds (to 1:30, repeatably). Time to build the
cache is down by 2:32 to 3:20.
I'll certainly be running this from now on.
- J<
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redh
Would it be reasonable to consider eliminating the "removed `/blah'"
lines from mock's debug output or perhaps moving them to another debug
level? They swamp the regular debug output (which is often quite
useful to watch) and crowd out other useful information in root.log.
I know I can always use
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> Is there a reason we do a yum resolvedeps prior to install?
I've wondered about that as well. Mock does the resolvedep, then goes
on to mount /proc and /dev/pts so perhaps it's trying to avoid those
two mounts if it doesn't need to. Bu
Christian Iseli and I were discussing the possibility of automatically
running rpmlint somehow. It seems that the end of the mock build
process is the ideal place for this. It has a chroot already set up
with the package's build requirements already installed. (Obviously
this doesn't include the
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> Why do you need to install the package? rpmlint works on the
JK> binary and srpm.
Because I was told that is the only way rpmlint can run certain
checks. The point is that in order to do a proper review, I should
install the package bu
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> This sounds like much more of a job of the Fedora Test Project
JK> software that Will Woods is talking about.
I'm not sure how this would help with reviews of packages which
haven't yet been accepted into Fedora. The idea is to lower th
> "TK" == Toshio Kuratomi <[EMAIL PROTECTED]> writes:
TK> I don't know what Andras had in mind but one potential problem is
TK> that BuildRequires might not pull in all of a package's Requires.
TK> Noarch packages would be the primary place you'll see this.
Obviously there's a working yum and
> "JLT" == Jason L Tibbitts, writes:
JLT> Because I was told that is the only way rpmlint can run certain
JLT> checks.
For an example of a check that only works if you actually install the
package, see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198835#c6
- J<
--
Fedora-buildsy
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> More to the point, there are two distinct tasks here, one is
JK> building the package, the other is testing.
Well, what I'm getting out of this is that you're telling me to ignore
what is pretty much a perfect time-saver in the form of e
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> You should be testing your package in a local mock rather than
JK> abusing the buildsystem resources to just test a build. We deal
JK> with this internally too.
I'm not sure where I gave the impression that this had anything to do
with
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> mock chroot will allow you to run a comand in the chroot.
Oh, awesome. Honestly, very many thanks. Might I be so bold as to
suggest something like the following patch?
Index: mock.py
===
OK, here's a first pass hack. This could be better written in Python
and could extract some bits from the mock configuration, but this does
at least work. It builds the package, installs rpmlint and all of the
newly-built binary RPMs and (hopefully) their dependencies into the
chroot. It then ru
> "CW" == Clark Williams <[EMAIL PROTECTED]> writes:
CW> Just so you know, I have a version of mock that takes a --rpmlint
CW> command line option which will add rpmlint to the chroot
CW> transaction set, install it in the chroot and then run rpmlint on
CW> the generated SRPM and RPMs, putting
> "CW" == Clark Williams <[EMAIL PROTECTED]> writes:
CW> Well dang, now you're going to make me work for it :).
Well, no big deal; I'm happy with what I have now, although I really
hope that I'll be able to continue to make it work somehow after
mockhelper goes away.
I think some type of fun
> "MEB" == Michael E Brown <[EMAIL PROTECTED]> writes:
MEB> I just caught up on the rpmlint discussion, and have a few
MEB> concerns.
MEB> Security of installing just-built RPM
Can't be any worse than actually building the package, can it?
MEB> Can rpmlint just be done outside of mock (usin
> "CW" == Chris Weyl <[EMAIL PROTECTED]> writes:
CW> A while ago and on a different list, tibbs proposed adding one
CW> last bit to the buildcycle:
Actually I think it was this list.
Honestly I don't think this needs to be in mock, but mock really needs
to continue to give me the means to do
> "AP" == Al Pacifico <[EMAIL PROTECTED]> writes:
AP> I have fifteen CPAN packages that I'm packaging as RPMs for FC5,
AP> and one (and only one) of them seems to hang mock. Is this an
AP> appropriate place to ask for advice?
I have seen this happen when packages using Module::Build are missi
> "MS" == Michael Schwendt <[EMAIL PROTECTED]> writes:
MS> Interesting would be any theory, where the .fc7 (for the generated
MS> src.rpm) can come from when nothing in the plague-client args
MS> contains "fc7".
Forgive me if it's already been covered in this discussion, but
doesn't the final
> "MD" == Matt Domsch <[EMAIL PROTECTED]> writes:
MD> The latest culprits was a few perl modules that ran for >2 days
MD> with no end in sight.
BTW, those are usually Module::Build-using modules which are running
with unsatisfied build dependencies. They will stop and prompt for
input when t
I'm not sure what to make of this so I haven't yet filed a bug. But I
noticed that one of spot's jobs was taking way longer than it should:
http://koji.fedoraproject.org/koji/buildinfo?buildID=31678
and so I grabbed the srpm and tried to build it on my local builder.
It hung at the same place th
> "CW" == Clark Williams <[EMAIL PROTECTED]> writes:
CW> [...] It looks like it's hanging while running the test
CW> t/06error.t:
Oh, crap; I never considered the possibility that it's actually made
it that far into the package build. Unfortunately the mock output
makes it look like it hasn'
> "BN" == Bill Nottingham <[EMAIL PROTECTED]> writes:
BN> So, the question would be... is this worth it? Do we want to keep
BN> supporting this?
I can't see how it's all that useful. And given that this is the kind
of weirdness that's going to be difficult to emulate using some other
version
Yes, I have seen many of these on my and other updates. It's quite
annoying to me that someone would try to do that. I mean, if you
really want an update and you've tested it, contact the maintainer and
make a request. But creating fake accounts just to bump karma is only
going to force people t
> "MB" == Mike Bonnet <[EMAIL PROTECTED]> writes:
MB> Koji builders have never downloaded packages via XMLRPC. All
MB> downloading is done by mock/yum, via http (previously nfs).
Well, mock can cache all sorts of things these days. If there are
multiple builders at one location then having
I do a large number of local mock builds as a part of the package
reviews that I do, and one problem I consistently run into is
executables and .so files coming out with mode 775, but a scratch
build in Fedora's koji instance showing the expected 755 permissions.
I thought it might be some local e
> "MM" == Mike McLean <[EMAIL PROTECTED]> writes:
MM> I believe the umask needs to be 002 in order for users in the mock
MM> group to be able to use mock effectively.
Which umask? My person one? If mock requires a specific umask value,
it should simply set one itself.
MM> Regardless, if th
> "JK" == Jesse Keating <[EMAIL PROTECTED]> writes:
JK> I do believe that sets it to "whatever owner permissions the file
JK> has on the filesystem, root owner, root group, whatever group
JK> permissions it has on the filesystem" or something close to that
JK> effect.
Well, yes, but obviously
> "MM" == Mike McLean <[EMAIL PROTECTED]> writes:
MM> It does. mock calls os.umask(002) at startup (and has for a
MM> while). The mock on the Fedora build hosts has this line. I'm not
MM> sure why you're seeing a difference. Can you point to a specific
MM> Fedora build whose results differ fro
> "OF" == Oliver Falk writes:
OF> And regarding your point: '... different arches build noarch
OF> subpackage with different contents'. Well, then it's definitly not
OF> *noarch*, is't it? :-)
It is quite possible for the contents to differ by, say, date, or by
timestamps being included in p
> "MB" == Mike Bonnet writes:
MB> There is some set of post-build checks we may want to run on these
MB> noarch subpackages to ensure they are in fact noarch, and that
MB> their content is sane.
I think it would be sufficient to collect all of the noarch packages
generated from the various a
> "MM" == Mike McLean writes:
MM> I suppose we should add a way to access the yum localinstall
MM> functionality through mock.
I have done this for years:
echo Installing built packages:
runmock -v --install $MOCKDIR/result/*{i386,x86_64,noarch}.rpm 2>&1
(dependent on the rest of the scrip
I'm having a problem building the current zsh srpm
(zsh-4.3.10-4.fc13.src.rpm) on my local builder, which runs F11-x86_64
and has mock-0.9.18-1.fc11.noarch. On IRC, a user reported the same
problem, only his builder runs CentOS 5.4 and has
mock-0.9.14-2.el5.noarch. Surprisingly, the same srpm wil
> "RM" == Roland McGrath writes:
RM> That is job control weirdness. Something about the state of tty
RM> magic is different in the two different contexts where you run the
RM> test.
Unfortunately that level of magic is mostly beyond me.
RM> The things to look at are whether the tests are u
34 matches
Mail list logo
