April 2017 - Infra - Ovirt List Archives

[oVirt Jenkins] test-repo_ovirt_experimental_master - Build #6202 - FAILURE!

by jenkins＠jenkins.phx.ovirt.org

------=_Part_215_1852687810.1491384212001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Build: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6202/, Build Number: 6202, Build Status: FAILURE ------=_Part_215_1852687810.1491384212001--

7 years, 1 month

1
9
0 / 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories

by Michal Skrivanek (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ] Michal Skrivanek commented on OVIRT-1299: ----------------------------------------- +1 for ovirt-web-ui, we're going to use the same flow > 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)

7 years, 1 month

1
0
0 / 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories

by Martin Sivak (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ] Martin Sivak commented on OVIRT-1299: ------------------------------------- Exactly what I would like to achieve. With one improvement in step 3. I usually release in the same copr repo so in the ideal world I would just provide the repo url once and every time you do a compose (or nightly) the tooling would check for updates. > 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)

7 years, 1 month

1
0
0 / 0

[JIRA] (OVIRT-1302) Please merge my multiple gerrit identies

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1302?page=com.atlassian.jir... ] Barak Korren reassigned OVIRT-1302: ----------------------------------- Assignee: Barak Korren (was: infra) > Please merge my multiple gerrit identies > ---------------------------------------- > > Key: OVIRT-1302 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1302 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: vfeenstr > Assignee: Barak Korren > > I added new auth methods (Github and Gmail) and now I can't be assigned anymore by others to reviews etc. > vfeenstr @ RH -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

7 years, 1 month

1
0
0 / 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1299: ------------------------------------- {quote} The difference is that you depend on gerrit and on specific branch name to know which build-artifact script to execute. My requests does not require that, I will provide the git url and tarball url (or a dir with those) instead. {quote} It does not have to be in Gerrit, nor is there a need for specific branches ATM. The discussion about branches was trying to come up with a scheme to auto-detect things that are currently specified in the project YAML in the Jenkins repo. Since we did not implement that yet, you can use any branch names you'd like and map them to oVirt releases in the YAML file. The one thing we do strongly depend on, is that every change starts with a commit somewhere so that we can track it, and use the hash as a reliable unique identifier for the change. I think this is important. Without it you cannot track changes. {quote} Something very similar to what I want is the releng tools repository Sandro uses. An example: https://gerrit.ovirt.org/gitweb?p=releng-tools.git;a=blob;f=releases/ovir... The only issue we have with this is that it is not properly documented (inheritance rules, ...), does not support source tarballs and CI is probably not using it at all. {quote} That is a repoman configuration file. All it does is collect files together. This is not a reliable source of information, not is it located in the right place, because AFAIK deciding which package builds go to which oVirt releases is the responsibility of the individual package maintainers, not the integration team. But still, I'm not sure I understand where you are trying to go. Let me try to describe the process you are tying to get to as I understand it: # You merge a new commit to mom # You go and launch a build in copr manually. # When the build is done you go to some file in some repo, specify the url to the build in it and submit a new commit. # Once the new commit is merged the CY system downloads the new build and publishes it in the oVirt repos. > 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)

7 years, 1 month

1
0
0 / 0

[JIRA] (OVIRT-1302) Please merge my multiple gerrit identies

by vfeenstr (oVirt JIRA)

vfeenstr created OVIRT-1302: ------------------------------- Summary: Please merge my multiple gerrit identies Key: OVIRT-1302 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1302 Project: oVirt - virtualization made easy Issue Type: Task Reporter: vfeenstr Assignee: infra I added new auth methods (Github and Gmail) and now I can't be assigned anymore by others to reviews etc. vfeenstr @ RH -- This message was sent by Atlassian JIRA (v1000.883.0#100040)

7 years, 1 month

1
0
0 / 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories

by Martin Sivak (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ] Martin Sivak commented on OVIRT-1299: ------------------------------------- The difference is that you depend on gerrit and on specific branch name to know which build-artifact script to execute. My requests does not require that, I will provide the git url and tarball url (or a dir with those) instead. Something very similar to what I want is the releng tools repository Sandro uses. An example: https://gerrit.ovirt.org/gitweb?p=releng-tools.git;a=blob;f=releases/ovir... The only issue we have with this is that it is not properly documented (inheritance rules, ...), does not support source tarballs and CI is probably not using it at all. > 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)

7 years, 1 month

1
0
0 / 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #288

by jenkins＠jenkins.phx.ovirt.org

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_6...> Changes: [Eyal Edri] drop qmeu master merged job ------------------------------------------ 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-centos-updates-el7-x86_6...> > 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 c7f97c6100e0a53f679bd711bf05ca8f6a89a6a0 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f c7f97c6100e0a53f679bd711bf05ca8f6a89a6a0 > git rev-list bdca0b5702e3f2058805edcff168947ee95b1996 # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/hudson4269871197106904657.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML if self._latestRepoXML(local): File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1443, in _latestRepoXML repomd = self.metalink_data.repomd File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 916, in <lambda> metalink_data = property(fget=lambda self: self._getMetalink(), File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 912, in _getMetalink self._metalink = metalink.MetaLinkRepoMD(self.metalink_filename) File "/usr/lib/python2.7/site-packages/yum/metalink.py", line 189, in __init__ raise MetaLinkRepoErrorParseFail, "File %s is not XML" % filename yum.metalink.MetaLinkRepoErrorParseFail: File /home/jenkins/mirrors_cache/fedora-updates-fc24/metalink.xml is not XML Build step 'Execute shell' marked build as failure

7 years, 1 month

1
1
0 / 0

[JIRA] (OVIRT-1299) Please provide a koji (and if possible bodhi) instance for ovirt repositories

by Barak Korren (oVirt JIRA)

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1299?page=com.atlassian.jir... ] Barak Korren commented on OVIRT-1299: ------------------------------------- I'm not sure I understand the process, and how it differs from what we have now. A "build-artifacts" job can build in any way the developer chooses, including invoking remote build services. As long as it eventually leaves RPMs in exported-artifacts, they will be taken, system-tested and published. Every 'build-artifacts' job is also a package repository so you even get publishing "for free" without passing OST. If you want to separate the build/release process from source that is also easy to do, you just create a separate repo, place build scripts in it, and make them clone the "source" repo. This is essentially what the UX team did for various 3rd party dependencies. We will probably not further automate the use of specific build systems, nor is it probable that we will deploy any new build system. WRT GitHub - using it does not imply using a different process, we've been running a very oVirt-like process on GitHub for Lago for quite a long while now. And we've recently started doing this for other projects as well. > 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)

7 years, 1 month

1
0
0 / 0

Build failed in Jenkins: system-sync_mirrors-epel-el6-x86_64 #219

by jenkins＠jenkins.phx.ovirt.org

See <http://jenkins.ovirt.org/job/system-sync_mirrors-epel-el6-x86_64/219/disp...> Changes: [Eyal Edri] drop qmeu master merged job ------------------------------------------ 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-el6-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 c7f97c6100e0a53f679bd711bf05ca8f6a89a6a0 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f c7f97c6100e0a53f679bd711bf05ca8f6a89a6a0 > git rev-list bdca0b5702e3f2058805edcff168947ee95b1996 # timeout=10 [system-sync_mirrors-epel-el6-x86_64] $ /bin/bash -xe /tmp/hudson1605555710363075578.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror epel-el6 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Resyncing repo: epel-el6 Syncing yum repo epel-el6 for arch: x86_64 : php-horde-horde-5.2.14-1.el6.noarch.rpm | 1.6 MB 00:01 Removing php-horde-Horde-Image-2.4.0-1.el6.noarch.rpm due to failed signature check. Removing php-horde-horde-5.2.14-1.el6.noarch.rpm due to failed signature check. Removing php-horde-imp-6.2.18-1.el6.noarch.rpm due to failed signature check. Removing php-horde-kronolith-4.2.20-1.el6.noarch.rpm due to failed signature check. Removing php-horde-mnemo-4.2.13-1.el6.noarch.rpm due to failed signature check. Removing php-horde-nag-4.2.14-1.el6.noarch.rpm due to failed signature check. Removing php-horde-turba-4.2.19-1.el6.noarch.rpm due to failed signature check. Removing rhash-1.3.4-2.el6.i686.rpm due to failed signature check. Removing rhash-1.3.4-2.el6.x86_64.rpm due to failed signature check. Build step 'Execute shell' marked build as failure

7 years, 1 month

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Infra April 2017