[PATCH] use createrepo_c instead of createrepo to make repos if it is available
by Dennis Gilmore
Signed-off-by: Dennis Gilmore <dennis(a)ausil.us>
---
builder/kojid | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builder/kojid b/builder/kojid
index 3a92ec3..4e53fb5 100755
--- a/builder/kojid
+++ b/builder/kojid
@@ -4252,7 +4252,11 @@ class CreaterepoTask(BaseTaskHandler):
def create_local_repo(self, rinfo, arch, pkglist, groupdata, oldrepo):
koji.ensuredir(self.outdir)
- cmd = ['/usr/bin/createrepo', '-vd', '-o', self.outdir]
+ if os.path.isfile('/usr/bin/createrepo_c'):
+ cmd = ['/usr/bin/createrepo_c']
+ else:
+ cmd = ['/usr/bin/createrepo']
+ cmd.extend(['-vd', '-o', self.outdir])
if pkglist is not None:
cmd.extend(['-i', pkglist])
if os.path.isfile(groupdata):
--
2.4.0
7 years, 7 months
koji and mergerepo_c
by Thomas
Hi Folks,
Quick question, would you consider to use mergerepo_c with option
--all [1] in koji ?
I am happy to work on a patch if it would be accepted. Maybe, we can
keep default behavior and enable with an option on the tag.
My use case is to be able to ship different release built against fix
external repo package that may not be latest version
(Buildrequires:pkg = 1.0.0 while external repo has already 1.1.0)
[1]:
--all
Include all packages with the same name and arch if version or
release is different. If used --method argument is ignored!
--
Thomas
7 years, 9 months
[PATCH] Drop tables and functions only if exist
by Pavol Babincak
At the time of first initialization of Koji database tables and
functions don't exist. This isn't really a problem as SQL commands later
in the script create them.
For non-existent tables or functions psql prints NOTICE instead of an
ERROR. Therefore one can check if database was initialized correctly
with ON_ERROR_STOP set (see psql(1)):
psql returns 3 if an error occurred in a script and the variable
ON_ERROR_STOP was set.
---
docs/schema.sql | 70 ++++++++++++++++++++++++++++-----------------------------
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/docs/schema.sql b/docs/schema.sql
index 56418c9..7a46f7f 100644
--- a/docs/schema.sql
+++ b/docs/schema.sql
@@ -1,56 +1,56 @@
-- vim:noet:sw=8
-- still needs work
-DROP TABLE build_notifications;
+DROP TABLE IF EXISTS build_notifications;
-DROP TABLE log_messages;
+DROP TABLE IF EXISTS log_messages;
-DROP TABLE buildroot_listing;
-DROP TABLE image_listing;
+DROP TABLE IF EXISTS buildroot_listing;
+DROP TABLE IF EXISTS image_listing;
-DROP TABLE rpminfo;
-DROP TABLE image_builds;
-DROP TABLE image_archives;
+DROP TABLE IF EXISTS rpminfo;
+DROP TABLE IF EXISTS image_builds;
+DROP TABLE IF EXISTS image_archives;
-DROP TABLE group_package_listing;
-DROP TABLE group_req_listing;
-DROP TABLE group_config;
-DROP TABLE groups;
+DROP TABLE IF EXISTS group_package_listing;
+DROP TABLE IF EXISTS group_req_listing;
+DROP TABLE IF EXISTS group_config;
+DROP TABLE IF EXISTS groups;
-DROP TABLE tag_listing;
-DROP TABLE tag_packages;
+DROP TABLE IF EXISTS tag_listing;
+DROP TABLE IF EXISTS tag_packages;
-DROP TABLE buildroot;
-DROP TABLE repo;
+DROP TABLE IF EXISTS buildroot;
+DROP TABLE IF EXISTS repo;
-DROP TABLE build_target_config;
-DROP TABLE build_target;
+DROP TABLE IF EXISTS build_target_config;
+DROP TABLE IF EXISTS build_target;
-DROP TABLE tag_config;
-DROP TABLE tag_inheritance;
-DROP TABLE tag;
+DROP TABLE IF EXISTS tag_config;
+DROP TABLE IF EXISTS tag_inheritance;
+DROP TABLE IF EXISTS tag;
-DROP TABLE build;
+DROP TABLE IF EXISTS build;
-DROP TABLE task;
+DROP TABLE IF EXISTS task;
-DROP TABLE host_channels;
-DROP TABLE host;
+DROP TABLE IF EXISTS host_channels;
+DROP TABLE IF EXISTS host;
-DROP TABLE channels;
-DROP TABLE package;
+DROP TABLE IF EXISTS channels;
+DROP TABLE IF EXISTS package;
-DROP TABLE user_groups;
-DROP TABLE user_perms;
-DROP TABLE permissions;
+DROP TABLE IF EXISTS user_groups;
+DROP TABLE IF EXISTS user_perms;
+DROP TABLE IF EXISTS permissions;
-DROP TABLE sessions;
-DROP TABLE users;
+DROP TABLE IF EXISTS sessions;
+DROP TABLE IF EXISTS users;
-DROP TABLE event_labels;
-DROP TABLE events;
-DROP FUNCTION get_event();
-DROP FUNCTION get_event_time(INTEGER);
+DROP TABLE IF EXISTS event_labels;
+DROP TABLE IF EXISTS events;
+DROP FUNCTION IF EXISTS get_event();
+DROP FUNCTION IF EXISTS get_event_time(INTEGER);
BEGIN WORK;
--
1.9.3
7 years, 9 months
[PATCH] Check that opts is not None before accessing.
by Ralph Bean
This should fix the periodic 500 error we get from koji-web in Fedora
Infra's staging environment.
Signed-off-by: Ralph Bean <rbean(a)redhat.com>
---
www/lib/kojiweb/util.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/www/lib/kojiweb/util.py b/www/lib/kojiweb/util.py
index 89a5ddb..6610beb 100644
--- a/www/lib/kojiweb/util.py
+++ b/www/lib/kojiweb/util.py
@@ -466,7 +466,7 @@ def taskScratchClass(task_object):
request = task_object['request']
if len(request) >= 3:
opts = request[2]
- if opts.get('scratch'):
+ if opts and opts.get('scratch'):
return "scratch"
return ""
--
2.1.0
7 years, 10 months
Switch to DNF in Koji?
by Miroslav Suchý
Hi,
several months ago I talked to dgilmore and probinso and we talked about using DNF in Koji and start building F22
packages using DNF resolver.
The conlusion was that it is quite late in cycle. And it is better to start with plain Mock and leave user to test it on
their local workstatations. Mock is using DNF for fedora-rawhide-* targets for some time already. And I received none
complaints.
Therefore I'm raising question: Can we switch Koji to use DNF for building rawhide targets?
Of course F22- will still use yum for building.
It would be great if we can make this change before mass rebuils for F23.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
7 years, 11 months
[PATCH] use mergerepo_c when available
by Dennis Gilmore
mergerepo_c has a --koji flag to use the behaviour of kojis inbuilt
fork of mergerepo. lets use it if it is available.
Signed-off-by: Dennis Gilmore <dennis(a)ausil.us>
---
builder/kojid | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/builder/kojid b/builder/kojid
index 4e53fb5..8c0b20d 100755
--- a/builder/kojid
+++ b/builder/kojid
@@ -4305,7 +4305,11 @@ class CreaterepoTask(BaseTaskHandler):
repos.append(ext_url)
blocklist = self.repodir + '/blocklist'
- cmd = ['/usr/libexec/kojid/mergerepos', '-a', arch, '-b', blocklist, '-o', self.outdir]
+ if os.path.isfile('/usr/bin/mergerepo_c'):
+ cmd = ['/usr/bin/mergerepo_c', '--koji']
+ else:
+ cmd = ['/usr/libexec/kojid/mergerepos']
+ cmd.extend(['-a', arch, '-b', blocklist, '-o', self.outdir])
if os.path.isfile(groupdata):
cmd.extend(['-g', groupdata])
for repo in repos:
--
2.4.0
8 years
[PATCH] (koji-web) Treat extra-footer as a template.
by Ralph Bean
The code previously would look for a file called extra-footer.html that a koji
admin could override to put some nice extra footer on their koji-web page.
If that file existed, koji-web would read it in verbatim and write it to the
bottom of each served page.
This change enhances that behavior and treats the extra-footer.html file as a
Cheetah template. This way, a koji admin could specify some conditional logic
in the extra-footer file to display this or that thing depending on the dynamic
contents of the page being served.
Note that this is backwards compatible. Static html extra-footer files
already out there in the wild will be interpreted as Cheetah templates and
should be included seamlessly.
---
www/kojiweb/includes/footer.chtml | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/www/kojiweb/includes/footer.chtml b/www/kojiweb/includes/footer.chtml
index 8dad310..684e5a4 100644
--- a/www/kojiweb/includes/footer.chtml
+++ b/www/kojiweb/includes/footer.chtml
@@ -8,8 +8,7 @@
#set $localfooterpath=$util.themePath("extra-footer.html", local=True)
#if os.path.exists($localfooterpath)
-#set $localfooter="".join(open($localfooterpath).readlines())
-$localfooter
+#include $localfooterpath
#end if
</div>
--
2.1.0
8 years
New Rpm-ecosystem Mailing List
by Florian Festi
Hi!
tl;td: Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem if
your interested in any part of the rpm ecosystem.
While there are quite some mailing lists already that deal with the
different tools around and including rpm we realized that there is no
good place to discuss issues that involve multiple parts of (our own)
package handling stack even less so to stay in contact with other rpm
based solutions. To solve this we create a new mailing list:
rpm-ecosystem(a)lists.rpm.org
Normal user questions and development talk is supposed to stay on the
per project mailing lists. The new list is for questions like:
* How do other implementations handle specific problems?
* Is this new feature interesting for downstream distributions?
* How do the different packaging guidelines treat a special topic?
* Anyone there to support our demand for this new rpm feature?
And it is for topics like:
* Packaging guide lines
* RPM features
* Build systems and compose tools
* Dependency solvers, installers and updaters
* RPM based image creation / non rpm based updates for rpm
based distributions
In short: It is meant to bind the rpm universe together.
Join at http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
Please forward this mail to anyone that might be interested - especially
to rpm related sub projects and groups.
Thanks!
Florian
--
Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters
8 years