[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
8 years, 8 months
New Koji Setup - regen-repo task fails
by Kirk Harr
Hello,
When setting up a new Koji setup, I submit a regen-repo task which is picked up by the single builder host that I have setup, which fails with a message in the kojid.log file:
<snip>
2015-02-12 14:48:35,496 [WARNING] koji.TaskManager: TRACEBACK: Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1161, in runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 157, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 139, in call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 3536, in handler
raise koji.GenericError, "Repo directory missing: %s" % path
GenericError: Repo directory missing: /mnt/koji/repos/dist-centos6-build/1085
</snip>
This directory /mnt/koji/repos/dist-centos6-build/1085 does exist on the host inside /mnt/koji which is a GlusterFS share which the Kojira/Koji-hub/Koji-web host and the builder host share with each other. Is there any cause for this error to occur when the directory referenced as missing does actually exist?
Thanks,
Kirk Harr
Systems and Network Engineer
End Point Corporation
9 years
[PATCH] Read some defaults from an optional config file
by Pat Riehecky
From: Pat Riehecky <riehecky(a)fnal.gov>
Pungi's highly customizable behavior lends itself to some fairly long
execution lines. The attached patch will allow setting some defaults
in a ~/.pungirc while still allowing the end user to override them
on the command line.
I hope to eventually expand this to cover more of the pungi options.
But first things first, are there any objections to this patch?
Pat Riehecky (1):
Allow for setting some defaults via a .pungirc
src/pypungi/config.py | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
9 years
[PATCH] package hub.conf.d and web.conf.d
by Mike McLean
---
hub/Makefile | 1 +
koji.spec | 2 ++
www/conf/Makefile | 1 +
3 files changed, 4 insertions(+)
diff --git a/hub/Makefile b/hub/Makefile
index ccd84db..b6ef1c7 100644
--- a/hub/Makefile
+++ b/hub/Makefile
@@ -31,6 +31,7 @@ install:
mkdir -p $(DESTDIR)/etc/koji-hub
install -p -m 644 hub.conf $(DESTDIR)/etc/koji-hub/hub.conf
+ mkdir -p $(DESTDIR)/etc/koji-hub/hub.conf.d
mkdir -p $(DESTDIR)/$(SERVERDIR)
for p in $(PYFILES) ; do \
diff --git a/koji.spec b/koji.spec
index 064f14a..c2b1af4 100644
--- a/koji.spec
+++ b/koji.spec
@@ -156,6 +156,7 @@ rm -rf $RPM_BUILD_ROOT
%config(noreplace) %{_sysconfdir}/httpd/conf.d/kojihub.conf
%dir %{_sysconfdir}/koji-hub
%config(noreplace) %{_sysconfdir}/koji-hub/hub.conf
+%dir %{_sysconfdir}/koji-hub/hub.conf.d
%files hub-plugins
%defattr(-,root,root)
@@ -184,6 +185,7 @@ rm -rf $RPM_BUILD_ROOT
%dir %{_sysconfdir}/kojiweb
%config(noreplace) %{_sysconfdir}/kojiweb/web.conf
%config(noreplace) %{_sysconfdir}/httpd/conf.d/kojiweb.conf
+%dir %{_sysconfdir}/kojiweb/web.conf.d
%files builder
%defattr(-,root,root)
diff --git a/www/conf/Makefile b/www/conf/Makefile
index c57c4f5..f87e381 100644
--- a/www/conf/Makefile
+++ b/www/conf/Makefile
@@ -17,3 +17,4 @@ install:
mkdir -p $(DESTDIR)/etc/kojiweb
install -p -m 644 web.conf $(DESTDIR)/etc/kojiweb/web.conf
+ mkdir -p $(DESTDIR)/etc/kojiweb/web.conf.d
--
1.9.3
9 years
[PATCH] we xz compress the docker base image, make sure it is named correctly
by Dennis Gilmore
Signed-off-by: Dennis Gilmore <dennis(a)ausil.us>
---
builder/kojid | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builder/kojid b/builder/kojid
index a1b3a11..3df0588 100755
--- a/builder/kojid
+++ b/builder/kojid
@@ -3382,7 +3382,7 @@ class BaseImageTask(OzImageTask):
if 'ova' in format or format == 'raw-xz':
newname = self.imgname + '.' + format.replace('-', '.')
elif format == 'docker':
- newname = self.imgname + '.' + 'tar.gz'
+ newname = self.imgname + '.' + 'tar.xz'
else:
newname = self.imgname + '.' + format
if format != 'docker':
--
2.3.1
9 years, 1 month
how to build with java -8 in epel-6?
by Farkas Levente
hi,
i'm try to build a java package for epel-6 which use java-8.
unfortunately it seem it's not enough to simple add
BuildRequires: java-1.8.0-openjdk-devel
since it's install it, but also still install during the mock setup
session old java packages ie:
java-1.5.0-gcj x86_64 1.5.0.0-29.1.el6 os
137 k
java-1.6.0-sun x86_64 1:1.6.0.45-1jpp.1.el6 os
25 M
java-1.7.0-ibm x86_64 1:1.7.0.5.0-1jpp.2.el6_4 os
73 M
java-1.7.0-ibm-devel x86_64 1:1.7.0.5.0-1jpp.2.el6_4 os
7.5 M
java-1.7.0-oracle x86_64 1:1.7.0.45-1jpp.2.el6_4 os
28 M
and i'm not bale to exclude them. in rpm the is a Obsoletes: but there
is no such thing as "BuildRequiresObsoletes":-(
what's more i can't run system-switch-java since it's required root
access and there is no command line option to switch to a given specific
java version.
so during build the system use the default javac which is not java8 but
ibm's java7 (IBM J9 VM (build 2.6, JRE 1.7.0).
is there any way to force java8? or is there any way to exclude other
java vm jre to install into mock during build?
thanks in advance.
regards.
--
Levente "Si vis pacem para bellum!"
9 years, 1 month
[rpkg] A new format for 'sources' files
by Mathieu Bridon
As part of the move away from MD5 for the source files hashes in the lookaside
cache, we have decided to change the format of the 'sources' files, so it
includes the hash type, to make it easier to identify which hash was used.
We agreed on using the BSD-style format, as returned on Linux by passing the
extra --tag option to commands like md5sum, sha512sumn, etc.
In addition, we decided to forbid mixing hash types in a single sources file,
forcing maintainers to use `fedpkg new-sources` the first time they upload an
additional source file.
This 4 patches series implements all that, with loads of unit tests, and some
code cleanup.
src/pyrpkg/__init__.py | 60 ++++-----
src/pyrpkg/sources.py | 123 ++++++++++++------
test/test_sources.py | 334 ++++++++++++++++++++++++++++++++++--------------
3 files changed, 359 insertions(+), 158 deletions(-)
https://fedorahosted.org/rel-eng/ticket/5846
9 years, 1 month
Koji Automated Build from Git
by Anthony Boccia
Hello All,
I wanted to share with the community a simple git-hook + listener I wrote
to automate koji builds from git. A post-receive hook analyzes commit
messages for any trigger flags, it then sends the necessary info over to a
listener on the koji-hub which in turn triggers a build via the Koji API.
It is something I wrote for my own use and in the spirit of opensource I
wanted to toss it out there so that others may make use of it as well. The
code currently lives on my public github repo @
https://github.com/aeboccia/koji-buildfromgit .
Sincerely,
Anthony Boccia
9 years, 1 month
[PATCH 0/3] pungi patches for lorax-dnf support
by Brian C. Lane
I took a look at pungi and decided that with the state it is in, and my lack of
deep understanding of it, I don't want to tackle converting it to DNF. So, in
order to support the ability to independently move lorax to DNF and Python3
I've converted the library call to run lorax as a process.
I'm still undecided about moving lorax to DNF for F22 or not. I'll probably
make a decision on that after tomorrow's Anaconda DNF test day.
I *am* going to make the switch for rawhide on Friday though, so these changes
will need to be in the rawhide version of pungi soon.
I've done multiple test runs and things look good, at least on x86_64. The only
issues I have right now are that the boot.iso is about 200M larger than the F21
one, and DNF doesn't log transaction decisions yet so it's hard to track down
what's getting pulled in by what.
Brian C. Lane (3):
Close child fds when using subprocess
Call lorax as a process not a library
Add the option to pass a custom path for the multilib config files
src/bin/pungi.py | 3 ++
src/pypungi/__init__.py | 83 +++++++++++++++++++++++++++----------------------
src/pypungi/config.py | 1 +
src/pypungi/multilib.py | 52 +++++++++++++++++++++----------
src/pypungi/util.py | 5 +--
5 files changed, 88 insertions(+), 56 deletions(-)
--
2.1.0
9 years, 1 month
Re: Mock, autosigning
by Julien Ballet
Thank you for reviewing the patch and sorry for the late reply.
Here’s a fixed version. Also I’ve a question :)
On 2/16/15, 2:16 PM, "Miroslav Suchy" <msuchy(a)redhat.com> wrote:
>
>>On 02/16/2015 09:11 PM, Clark Williams wrote:
[ I changed the api to passed to results of the current build to Œpost
build¹ hook ]
>>I do not understand the necessity of changing API. The result dir is
>>defined in buildroot.resultdir in __init__() of plugin and stored to
>>instance variable and then just walk() that directory.
The problem with that approach is that you will end up trying to sign
the srpm twice, and/or signing packages you have built in previous run
but you actually don¹t want to sign. For larger packages, that might be
an issue. What is your opinion on that ?
9 years, 1 month
