Extras build system back up
by Dan Williams
Hi,
We're back up and using the latest plague code. yum update your
plague-client and you should be good to go.
Dan
16 years, 7 months
Adding a lock file to plague server Repo.py _update_repo()
by Michael Schwendt
Currently, when we sign and push built packages, we move them out of a
"repodir" while the build server may be copying new packages to that
directory.
We have not cleaned up repodir for a long time either, because it could
not be done automatically without risk. The corresponding section in the
push script contains a "todo" comment only. [Recently I've used a separate
script, however, which cleans up the directory after a push, provided that
the build system is idle and no package is about to be copied into the
directory at the same time.]
I've looked at Repo.py _update_repo() where I see nothing which prevents
concurrent access to this repodir. Is there anything I'm missing when
thinking that it is possible to add a simple lock file at the root of
repodir in order to control access to this directory? The build master
would lock the file when copying new packages to it. And the push script
would lock the file when moving packages and when cleaning up. Both would
sleep when they cannot acquire the lock.
16 years, 12 months
[PATCH] autocache patche -- resend, updated
by Michael E Brown
Here is a resend/consolidation of the autocache patches from last week.
I have combined the patches sent last week. It now defaults to gzip
format. I have also made the following fixes:
-- integrate the mock permfix patch. This checks if cache was created
with UID != current user UID and adjusts permissions appropriately.
-- Integrate a couple of small fixes regarding permissions.
_prep_install() happens before the above fix, so I have changed two
chown calls from config['chrootuser'] to use config['chrootuid'] (as
well as corresponding group/gid). This ensures that cached yum.conf is
always up-to-date. Previously, a cached yum.conf would never be updated
until the cache expired and was rebuilt. This change means cached builds
will never use wrong configuration.
-- Use the -l option to tar when creating cache. This prevents tar from
saving /proc or /dev/pts/
-- cmdline usability: --rebuildcache implies --autocache
Feedback and comments welcome...
Usage:
Add --autocache to cmdline, or config_opts['use_cache'] = 1 to config
file to enable caching. Cache is automatically built and saved
to /var/lib/mock/root-cache/ on a per-config basis. Cache will be
rebuilt by default every 15 days, or when --rebuildcache is specified on
cmdline. This option is meant to be self-administering and low
overhead.
--
Michael
17 years
fast repo updates
by Mike McLean
I posted this patch to rpm-metadata-list, but I figure some folks here
might be interested as well.
http://people.redhat.com/mikem/software/createrepo-update2.patch
This patch allows createrepo to recycle existing metadata so that it
only has to scan the rpms that have been changed or added. For
situations where you might want to make small incremental changes to a
yum repo (e.g. mock), this can provide significant time savings.
17 years
more mounts in mock
by Mike McLean
Attached are a couple of patches that expand the mounts created in the
chroot by mock. These are mounts that we've used for builds within Red
Hat for years and some packages need them to compile properly.
more_mounts.patch is the larger patch, it refactors _mount() so that the
mounts to be created are specified in a list and looped over. I've also
changed to the unmounting code to make it more paranoid. In order to
allow these mounts, I had to make some changes to mock-helper.
bind_dev.patch builds on the the previous patch and provides an option
to have /dev bind mounted in the chroot (instead of the skeletal /dev
that mock sets up). The patch makes this an option with the original
behavior as the default.
17 years
[PATCH - RFC] config unify patch
by Michael E Brown
Here is a patch for discussion. It is similar to the patch sent last
week, with the exception that I have added two condition checks that
ensure the behaviour is the same with this patch as without. Net
reduction in code size is 4 lines, but it also moves all the config file
parsing to one loop.
My belief is that either one of the two condition checks are not
necessary. IMO, the condition check prior to the config parsing loop
where it checks for file existence can be removed. We will then rely on
the check after config parsing which tests for config_opts['root'] to
ensure a proper config is given.
Patch is for discussion. I can send an updated version after decisions
are made.
--
Michael
17 years
[PATCH] - cli usability: rebuildcache implies autocache
by Michael E Brown
Here is a two line patch to increase usability/user-friendliness of
cmdline.
Currently the --rebuildcache option doesn't do anything by itself, you
have to specify both --autocache and --rebuildcache. With this patch,
--rebuildcache will automatically turn on autocache.
--
Michael
<<mock-cli-userfriendly.patch>>
17 years
[PATCH - updated] Multiuser environment permissions
by Michael E Brown
Attached is the updated patch. There is a single line addition from the
previous patch, in which I delete the build group as well.
--
Michael
________________________________
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Michael_E_Brown(a)Dell.com
Sent: Friday, May 19, 2006 2:52 PM
To: fedora-buildsys-list(a)redhat.com
Subject: RE: [PATCH] Multiuser environment permissions
Ok, further testing indicates that I need to check group as
well. I'll send a corrected patch in a few mins.
--
Michael
________________________________
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Michael_E_Brown(a)Dell.com
Sent: Friday, May 19, 2006 2:45 PM
To: fedora-buildsys-list(a)redhat.com
Subject: [PATCH] Multiuser environment permissions
I have found one difficulty with the autocache patch,
not a showstopper, but annoying. The problem occurs when you have
multiple users on the same machine. If one user creates the cache,
several files inside will be owned by that user. The other user then
cannot access /builddir/ due to permissions. The attached patch fixes
this situation. Basically, it is very localized to the _make_our_user()
function. It checks to see if the user already exists with a different
UID from the current UID. If it detects this, it deletes and recreates
the user and chown's the appropriate files.
Feedback appreciated. If this is ok, please apply with
the autocache patches.
Other than this issue, we have been using the autocache
patch here for a few days with no other issues.
--
Michael
<<mock-permfix.patch>>
17 years
RE: [PATCH] Multiuser environment permissions
by Michael E Brown
Ok, further testing indicates that I need to check group as well. I'll
send a corrected patch in a few mins.
--
Michael
________________________________
From: fedora-buildsys-list-bounces(a)redhat.com
[mailto:fedora-buildsys-list-bounces@redhat.com] On Behalf Of
Michael_E_Brown(a)Dell.com
Sent: Friday, May 19, 2006 2:45 PM
To: fedora-buildsys-list(a)redhat.com
Subject: [PATCH] Multiuser environment permissions
I have found one difficulty with the autocache patch, not a
showstopper, but annoying. The problem occurs when you have multiple
users on the same machine. If one user creates the cache, several files
inside will be owned by that user. The other user then cannot access
/builddir/ due to permissions. The attached patch fixes this situation.
Basically, it is very localized to the _make_our_user() function. It
checks to see if the user already exists with a different UID from the
current UID. If it detects this, it deletes and recreates the user and
chown's the appropriate files.
Feedback appreciated. If this is ok, please apply with the
autocache patches.
Other than this issue, we have been using the autocache patch
here for a few days with no other issues.
--
Michael
<<mock-permfix.patch>>
17 years
[PATCH] Multiuser environment permissions
by Michael E Brown
I have found one difficulty with the autocache patch, not a showstopper,
but annoying. The problem occurs when you have multiple users on the
same machine. If one user creates the cache, several files inside will
be owned by that user. The other user then cannot access /builddir/ due
to permissions. The attached patch fixes this situation. Basically, it
is very localized to the _make_our_user() function. It checks to see if
the user already exists with a different UID from the current UID. If it
detects this, it deletes and recreates the user and chown's the
appropriate files.
Feedback appreciated. If this is ok, please apply with the autocache
patches.
Other than this issue, we have been using the autocache patch here for a
few days with no other issues.
--
Michael
<<mock-permfix.patch>>
17 years
