- Infra - oVirt List Archives

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by Martin Sivak (oVirt JIRA) 05 Apr '17

05 Apr '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jira.… ] Martin Sivak edited comment on OVIRT-1299 at 4/5/17 1:00 PM: ------------------------------------------------------------- Do not make this more complex than it has to be. A simple text or ini file (in ovirt specific repository, not in the project itself!) where the maintainer can say which build (a link to jenkins, copr, koji, github, ...) should go to which release is enough. The same for source tarball. Just let us provide a link (git hash url, gitweb export or github for example). All your tooling like publishers or CI or anything else can then consume this configuration without forcing us to use a fixed tag or branch structure. The maintainer should be in control of the releases or platform, not the automation. oVirt is a distribution of pieces and some pieces have slightly different development model. Even some core oVirt project use GitHub as the primary source now. This has been discussed couple of times already, for example here http://lists.ovirt.org/pipermail/devel/2017-February/029439.html and here http://lists.ovirt.org/pipermail/devel/2017-January/029161.html was (Author: msivak(a)redhat.com) Do not make this more complex than it has to be. A simple text or ini file where the maintainer can say which build (a link to jenkins, copr, koji, github, ...) should go to which release is enough. The same for source tarball. Just let us provide a link (git hash url, gitweb export or github for example). All your tooling like publishers or CI or anything else can then consume this configuration without forcing us to use a fixed tag or branch structure. The maintainer should be in control of the releases or platform, not the automation. oVirt is a distribution of pieces and some pieces have slightly different development model. Even some core oVirt project use GitHub as the primary source now. This has been discussed couple of times already, for example here http://lists.ovirt.org/pipermail/devel/2017-February/029439.html and here http://lists.ovirt.org/pipermail/devel/2017-January/029161.html > Please provide a koji (and if possible bodhi) instance for ovirt repositories > ----------------------------------------------------------------------------- > > Key: OVIRT-1299 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Repositories Mgmt > Reporter: sbonazzo > Assignee: infra > > Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it. > They would like to have a dist-git + koji like developer experience. > A bodhi instance would help reviewing the package before it lands on repositories. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by Martin Sivak (oVirt JIRA) 05 Apr '17

05 Apr '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jira.… ] Martin Sivak commented on OVIRT-1299: ------------------------------------- Do not make this more complex than it has to be. A simple text or ini file where the maintainer can say which build (a link to jenkins, copr, koji, github, ...) should go to which release is enough. The same for source tarball. Just let us provide a link (git hash url, gitweb export or github for example). All your tooling like publishers or CI or anything else can then consume this configuration without forcing us to use a fixed tag or branch structure. The maintainer should be in control of the releases or platform, not the automation. oVirt is a distribution of pieces and some pieces have slightly different development model. Even some core oVirt project use GitHub as the primary source now. This has been discussed couple of times already, for example here http://lists.ovirt.org/pipermail/devel/2017-February/029439.html and here http://lists.ovirt.org/pipermail/devel/2017-January/029161.html > Please provide a koji (and if possible bodhi) instance for ovirt repositories > ----------------------------------------------------------------------------- > > Key: OVIRT-1299 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Repositories Mgmt > Reporter: sbonazzo > Assignee: infra > > Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it. > They would like to have a dist-git + koji like developer experience. > A bodhi instance would help reviewing the package before it lands on repositories. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by sbonazzo (oVirt JIRA) 05 Apr '17

05 Apr '17

sbonazzo created OVIRT-1299: ------------------------------- Summary: Please provide a koji (and if possible bodhi) instance for ovirt repositories Key: OVIRT-1299 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299 Project: oVirt - virtualization made easy Issue Type: New Feature Components: Repositories Mgmt Reporter: sbonazzo Assignee: infra Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it. They would like to have a dist-git + koji like developer experience. A bodhi instance would help reviewing the package before it lands on repositories. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories
by sbonazzo (oVirt JIRA) 05 Apr '17

05 Apr '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jira.… ] sbonazzo updated OVIRT-1299: ---------------------------- Epic Link: OVIRT-411 > Please provide a koji (and if possible bodhi) instance for ovirt repositories > ----------------------------------------------------------------------------- > > Key: OVIRT-1299 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1299 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: Repositories Mgmt > Reporter: sbonazzo > Assignee: infra > > Some of the maintainers of oVirt project wants to have control on the builds going into the release repositories without 3rd party intervention on it. > They would like to have a dist-git + koji like developer experience. > A bodhi instance would help reviewing the package before it lands on repositories. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #6201 - SUCCESS!
by jenkins＠jenkins.phx.ovirt.org 05 Apr '17

05 Apr '17

------=_Part_209_779165259.1491381851774 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6201/, Build Number: 6201, Build Status: SUCCESS ------=_Part_209_779165259.1491381851774--

1 0

Build failed in Jenkins: system-sync_mirrors-epel-el7-x86_64 #214
by jenkins＠jenkins.phx.ovirt.org 05 Apr '17

05 Apr '17

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el7-x86_64/214/displa…> ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el7-x86_64/ws/> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision bdca0b5702e3f2058805edcff168947ee95b1996 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f bdca0b5702e3f2058805edcff168947ee95b1996 > git rev-list bdca0b5702e3f2058805edcff168947ee95b1996 # timeout=10 [system-sync_mirrors-epel-el7-x86_64] $ /bin/bash -xe /tmp/hudson6785463584392011933.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror epel-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Resyncing repo: epel-el7 Syncing yum repo epel-el7 for arch: x86_64 (2/18): check-mk-agent-1.2 0% [ ] 0.0 B/s | 0 B --:-- ETA check-mk-1.2.8p18-1.el7.x86_64 FAILED (2/18): check-mk-agent-1.2 0% [ ] 0.0 B/s | 0 B --:-- ETA check-mk-multisite-1.2.8p18-1. FAILED (2/18): check-mk-docs-1.2. 0% [ ] 0.0 B/s | 0 B --:-- ETA python2-fedmsg-atomic-composer FAILED (2/18): check-mk-docs-1.2. 0% [ ] 0.0 B/s | 0 B --:-- ETA gasnet-common-1.28.2-1.el7.x86 FAILED (2/18): check-mk-docs-1.2. 0% [ ] 0.0 B/s | 0 B --:-- ETA check-mk-agent-1.2.8p18-1.el7. FAILED (2/18): check-mk-docs-1.2. 0% [ ] 0.0 B/s | 0 B --:-- ETA (2/18): check-mk-livestatu 4% [- ] 0.0 B/s | 799 kB --:-- ETA (1/18): check-mk-livestatus-1.2.8p18-1.el7.x86_64.rpm | 222 kB 00:00 gasnet-common-1.28.2-1.el7.x86 FAILED (3/18): distribution-gpg-k 4% [- ] 0.0 B/s | 799 kB --:-- ETA (2/18): check-mk-docs-1.2.8p18-1.el7.noarch.rpm | 1.6 MB 00:01 (3/18): perl-Test-TCP-2.17-2.el7.noarch.rpm | 29 kB 00:00 (4/18): distribution-gpg-keys-1.10-1.el7.noarch.rpm | 126 kB 00:00 (5/18): gasnet-mpich-1.28.2-1.el7.x86_64.rpm | 1.0 MB 00:01 (6/18): check-mk-agent-1.2.8p18-1.el7.x86_64.rpm | 89 kB 00:00 (7/18): gasnet-common-1.28.2-1.el7.x86_64.rpm | 15 kB 00:00 (9/18): gasnet-1.28.2-1.el 20% [=== ] 4.4 MB/s | 3.5 MB 00:03 ETA (8/18): python34-scripttest-1.3.0-9.el7.noarch.rpm | 101 kB 00:00 (9/18): gasnet-openmpi-1.28.2-1.el7.x86_64.rpm | 1.0 MB 00:01 (10/18): python2-scripttest-1.3.0-9.el7.noarch.rpm | 101 kB 00:00 (11/18): reposurgeon-3.42-1.el7.noarch.rpm | 275 kB 00:01 (12/18): gasnet-1.28.2-1.el7.x86_64.rpm | 828 kB 00:01 (13/18): gasnet-devel-1.28.2-1.el7.x86_64.rpm | 194 kB 00:01 (15/18): gasnet-doc-1.28.2 56% [========= ] 5.3 MB/s | 9.5 MB 00:01 ETA (14/18): check-mk-multisite-1.2.8p18-1.el7.noarch.rpm | 3.5 MB 00:00 (15/18): distribution-gpg-keys-copr-1.10-1.el7.noarch.rpm | 6.1 MB 00:01 (16/18): check-mk-1.2.8p18-1.el7.x86_64.rpm | 1.1 MB 00:01 (17/18): python2-fedmsg-atomic-composer-2017.1-1.el7.noarc | 35 kB 00:00 (18/18): gasnet-doc-1.28.2-1.el7.noarch.rpm | 525 kB 00:01 Generating yum repo metadata for: epel-el7 Worker 0: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/c/check-mk-1.2.8p18-1.el7.x86_64.rpm: RPM Error opening Package Worker 0: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/p/python34-scripttest-1.3.0-9.el7.noarch.rpm: RPM Error opening Package Worker 1: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/c/check-mk-agent-1.2.8p18-1.el7.x86_64.rpm: RPM Error opening Package Worker 1: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/g/gasnet-devel-1.28.2-1.el7.x86_64.rpm: RPM Error opening Package Worker 1: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/r/reposurgeon-3.42-1.el7.noarch.rpm: RPM Error opening Package Worker 2: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/c/check-mk-docs-1.2.8p18-1.el7.noarch.rpm: RPM Error opening Package Worker 2: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/g/gasnet-doc-1.28.2-1.el7.noarch.rpm: RPM Error opening Package Worker 4: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/c/check-mk-multisite-1.2.8p18-1.el7.noarch.rpm: RPM Error opening Package Worker 4: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/g/gasnet-openmpi-1.28.2-1.el7.x86_64.rpm: RPM Error opening Package Worker 5: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/d/distribution-gpg-keys-1.10-1.el7.noarch.rpm: RPM Error opening Package Worker 6: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/d/distribution-gpg-keys-copr-1.10-1.el7.noarch.rpm: RPM Error opening Package Worker 7: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/g/gasnet-1.28.2-1.el7.x86_64.rpm: RPM Error opening Package Worker 7: Error: Could not open local rpm file: /var/www/html/repos/yum/epel-el7/base/p/python2-scripttest-1.3.0-9.el7.noarch.rpm: RPM Error opening Package Failed to process 13 package(s). Spawning worker 0 with 3 pkgs Spawning worker 1 with 3 pkgs Spawning worker 2 with 2 pkgs Spawning worker 3 with 2 pkgs Spawning worker 4 with 2 pkgs Spawning worker 5 with 2 pkgs Spawning worker 6 with 2 pkgs Spawning worker 7 with 2 pkgs Workers Finished Build step 'Execute shell' marked build as failure

1 2

[JIRA] (OVIRT-1298) Mirrors sync jobs started to fail b/c of failed package signatures
by Barak Korren (oVirt JIRA) 05 Apr '17

05 Apr '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1298?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1298: ----------------------------------- Assignee: Barak Korren (was: infra) > Mirrors sync jobs started to fail b/c of failed package signatures > ------------------------------------------------------------------ > > Key: OVIRT-1298 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1298 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: Barak Korren > Priority: High > > This is happening for Fedora and EPEL repos, so probably the fedora signing keys were changed, and need to to be updated on the mirrors host. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[JIRA] (OVIRT-1298) Mirrors sync jobs started to fail b/c of failed package signatures
by Barak Korren (oVirt JIRA) 05 Apr '17

05 Apr '17

Barak Korren created OVIRT-1298: ----------------------------------- Summary: Mirrors sync jobs started to fail b/c of failed package signatures Key: OVIRT-1298 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1298 Project: oVirt - virtualization made easy Issue Type: Bug Components: Repositories Mgmt Reporter: Barak Korren Assignee: infra Priority: High This is happening for Fedora and EPEL repos, so probably the fedora signing keys were changed, and need to to be updated on the mirrors host. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[JIRA] (OVIRT-1298) Mirrors sync jobs started to fail b/c of failed package signatures
by Barak Korren (oVirt JIRA) 05 Apr '17

05 Apr '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1298?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1298: -------------------------------- Epic Link: OVIRT-403 > Mirrors sync jobs started to fail b/c of failed package signatures > ------------------------------------------------------------------ > > Key: OVIRT-1298 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1298 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: Repositories Mgmt > Reporter: Barak Korren > Assignee: infra > Priority: High > > This is happening for Fedora and EPEL repos, so probably the fedora signing keys were changed, and need to to be updated on the mirrors host. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0

[JIRA] (OVIRT-1296) review Rebase Always submit strategy on Gerrit
by Barak Korren (oVirt JIRA) 04 Apr '17

04 Apr '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1296?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1296: ------------------------------------- Using 'Rebase Always' will have indeed allowd us to meet some user's requests. But it has the downside where you will never be able to fast-forward over your own local commits because the merged commits will always be different then the submitted ones. Still, worth publishing to devel and seeing if anyone wants to try this in his project. BTW I seem to remember I already saw it as an option somewhere, was I looking at the staging instance? > review Rebase Always submit strategy on Gerrit > ---------------------------------------------- > > Key: OVIRT-1296 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1296 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Lowest > > A new submit strategy was included in recent builds of Gerrit: Rebase Always. > [Docs|https://gerrit-review.googlesource.com/Documentation/project-configura…] > {quote}Basically, the same as Rebase If Necessary, but it creates a new patchset even if fast forward is possible AND like Cherry Pick it ensures footers such as Change-Id, Reviewed-On, and others are present in resulting commit that is merged. > Thus, Rebase Always can be considered similar to Cherry Pick, but with the important distinction that Rebase Always does not ignore dependencies.{quote} > It is only available in [2.14|https://gerrit.googlesource.com/gerrit/+/stable-2.14/gerrit-server/src…] while we are still at 2.12 and [2.13|https://gerrit.googlesource.com/gerrit/+/stable-2.13/gerrit-server/src…] is the current stable branch. -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

1 0