oVirt infra daily report - unstable production jobs - 99

2016-10-06 Thread jenkins 
Good morning!

Attached is the HTML page with the jenkins status report. You can see it also 
here:
 - 
http://jenkins.ovirt.org/job/system_jenkins-report/99//artifact/exported-artifacts/upstream_report.html

Cheers,
Jenkins


upstream_report.html
Description: Binary data
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Piotr Kliczewski 
Martin,

With the fix it should be ok but without it it means we are not able to use
xmvn and jsva8.

Thanks,
Piotr

6 paź 2016 21:49 "Martin Perina"  napisał(a):

> Hi Sandro,
>
> does this means that we cannot use xmvn build with JDK 1.8? If so, then we
> would need to use same as engine (create Makefile which executes normal
> maven), right?
>
> For otopi/ovirt-host-deploy you are still using 1.7?
>
> Thanks
>
> Martin
>
> On Thu, Oct 6, 2016 at 5:45 PM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Thu, Oct 6, 2016 at 4:26 PM, Piotr Kliczewski 
>> wrote:
>>
>>>
>>>
>>> I added el7 [1] and simlink [2] but still the same [3] and I can see
>>> that the repo was added:
>>>
>>> *14:16:23* Adding repo centos -> 
>>> https://cbs.centos.org/repos/virt7-ovirt-41-candidate/x86_64/os/
>>>
>>>
>>>
>> The package is correctly installed: *00:02:20.007* xmvn.noarch
>> 0:1.3.0-5.1.el7
>>
>> So the provided patch is not fixing your issue.
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> 
>>
>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Martin Perina 
Hi Sandro,

does this means that we cannot use xmvn build with JDK 1.8? If so, then we
would need to use same as engine (create Makefile which executes normal
maven), right?

For otopi/ovirt-host-deploy you are still using 1.7?

Thanks

Martin

On Thu, Oct 6, 2016 at 5:45 PM, Sandro Bonazzola 
wrote:

>
>
> On Thu, Oct 6, 2016 at 4:26 PM, Piotr Kliczewski 
> wrote:
>
>>
>>
>> I added el7 [1] and simlink [2] but still the same [3] and I can see that
>> the repo was added:
>>
>> *14:16:23* Adding repo centos -> 
>> https://cbs.centos.org/repos/virt7-ovirt-41-candidate/x86_64/os/
>>
>>
>>
> The package is correctly installed: *00:02:20.007* xmvn.noarch
> 0:1.3.0-5.1.el7
>
> So the provided patch is not fixing your issue.
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> 
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: export ovirt-engine-dashboard gerrit repo to github?

2016-10-06 Thread Vojtech Szocs 
+1

Dashboard uses modern JS technologies and it would be
a nice showcase for anyone interested in UI plugins.

Vojtech


- Original Message -
> From: "Scott Dickerson" 
> To: infra@ovirt.org
> Cc: "Vojtech Szocs" 
> Sent: Thursday, October 6, 2016 5:53:17 PM
> Subject: export ovirt-engine-dashboard gerrit repo to github?
> 
> Hi,
> 
> What do we need to do in order to get the ovirt-engine-dashboard gerrit
> repo [1] mirrored/exported out to oVirt's github [2] in the same way
> ovirt-engine does?
> 
> [1] - https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=summary
> [2] - https://github.com/oVirt
> 
> Thanks,
> Scott
> 
> --
> Scott Dickerson
> Senior Software Engineer
> RHEV-M Engineering - UX Team
> Red Hat, Inc
> 
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build is back to stable : ovirt_4.0_he-system-tests #356

2016-10-06 Thread jenkins 
See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

export ovirt-engine-dashboard gerrit repo to github?

2016-10-06 Thread Scott Dickerson 
Hi,

What do we need to do in order to get the ovirt-engine-dashboard gerrit
repo [1] mirrored/exported out to oVirt's github [2] in the same way
ovirt-engine does?

[1] - https://gerrit.ovirt.org/gitweb?p=ovirt-engine-dashboard.git;a=summary
[2] - https://github.com/oVirt

Thanks,
Scott

-- 
Scott Dickerson
Senior Software Engineer
RHEV-M Engineering - UX Team
Red Hat, Inc
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Sandro Bonazzola 
On Thu, Oct 6, 2016 at 4:26 PM, Piotr Kliczewski 
wrote:

>
>
> I added el7 [1] and simlink [2] but still the same [3] and I can see that
> the repo was added:
>
> *14:16:23* Adding repo centos -> 
> https://cbs.centos.org/repos/virt7-ovirt-41-candidate/x86_64/os/
>
>
>
The package is correctly installed: *00:02:20.007* xmvn.noarch
0:1.3.0-5.1.el7

So the provided patch is not fixing your issue.


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Piotr Kliczewski 
On Thu, Oct 6, 2016 at 4:04 PM, Sandro Bonazzola 
wrote:

>
>
> On Thu, Oct 6, 2016 at 3:27 PM, Piotr Kliczewski 
> wrote:
>
>>
>>
>> On Thu, Oct 6, 2016 at 2:40 PM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 6, 2016 at 12:07 PM, Piotr Kliczewski 
>>> wrote:
>>>


 On Thu, Oct 6, 2016 at 11:56 AM, Sandro Bonazzola 
 wrote:

>
>
> On Wed, Oct 5, 2016 at 11:26 AM, Piotr Kliczewski  > wrote:
>
>> I talked to xmvn maintainer and it seems that xmvn uses asm 3 to
>> analyze the code after the build.
>> This library do not support java8 syntax. I was asked to open a BZ
>> for it [1]
>>
>> Now we are thinking how to workaround the issue before the fix will
>> be available.
>>
>> Thanks,
>> Piotr
>>
>> [1] https://bugzilla.redhat.com/1381883
>>
>
> I'll try to escalate the bug.
> The patch attached to the BZ looks simple enough, if it may help I can
> try to provide an updated version of xmvn within CentOS Virt SIG for 4.1
> candidate repos.
> May this help?
>
>
>
 I believe so, Thank you!

>>>
>>> Ok, did it, you need to add https://cbs.centos.org/rep
>>> os/virt7-ovirt-41-candidate/x86_64/os/ to your repos files in
>>> standard-ci automation directory
>>>
>>>
>>>
>>
>> I added it here [1] and run the build [2] and I saw the same issue.
>>
>>
>> [1] https://gerrit.ovirt.org/#/c/64481/7/automation/build-artifa
>> cts.repos.el6
>> [2] http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_check-
>> patch-el7-x86_64/51/console
>>
>>
> You added to el6 repo, you should have added it to el7
> :-) build-artifacts.repos.el7
>
>
I added el7 [1] and simlink [2] but still the same [3] and I can see that
the repo was added:

*14:16:23* Adding repo centos ->
https://cbs.centos.org/repos/virt7-ovirt-41-candidate/x86_64/os/


[1]
https://gerrit.ovirt.org/#/c/64481/8/automation/build-artifacts.repos.el7
[2] https://gerrit.ovirt.org/#/c/64481/8/automation/check-patch.repos.el7
[3]
http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_check-patch-el7-x86_64/52/consoleFull


>
>
>>
>>
>>>

>
>
>>
>>
>> On Wed, Oct 5, 2016 at 10:00 AM, Piotr Kliczewski <
>> pklic...@redhat.com> wrote:
>>
>>> Actually I saw f24 output, sorry. Still looking into it.
>>>
>>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski <
>>> pklic...@redhat.com> wrote:
>>>


 On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski <
 pklic...@redhat.com> wrote:

> Sandro,
>
> Thank you, changing java dept in spec to
>
>
 BuildRequires: java-1.8.0-openjdk-devel >= 1:1.8.0

 helped

>
> On Wed, Oct 5, 2016 at 9:35 AM, Sandro Bonazzola <
> sbona...@redhat.com> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 9:34 AM, Piotr Kliczewski <
>> pklic...@redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 9:01 AM, Sandro Bonazzola <
>>> sbona...@redhat.com> wrote:
>>>
 make[1]: Leaving directory `/home/jenkins/workspace/vdsm-
 jsonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java
 /rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master'
 + xmvn-install -R .xmvn-reactor -n vdsm-jsonrpc-java -d
 /home/jenkins/workspace/vdsm-jsonrpc-java_master_check-patch
 -el7-x86_64/vdsm-jsonrpc-java/rpmbuild/BUILDROOT/vdsm-jsonrp
 c-java-1.3.1-master.el7.centos.x86_64
 [INFO] ===
 [INFO] SOURCE ARTIFACT:
 [INFO] groupId: org.ovirt.vdsm-jsonrpc-java
 [INFO]  artifactId: root
 [INFO]   extension: pom
 [INFO]  classifier:
 [INFO] version: 1.3.1-SNAPSHOT
 [INFO]  stereotype: pom
 [INFO]   namespace:
 [INFO]file: /home/jenkins/workspace/vdsm-j
 sonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java/
 rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master/pom.xml
 [INFO] ---
 [INFO] TARGET ARTIFACT:
 [INFO] groupId: JPP/vdsm-jsonrpc-java
 [INFO]  artifactId: root
 [INFO]   extension: pom
 [INFO]  classifier:
 [INFO] version: SYSTEM
 [INFO]  stereotype: pom
 [INFO]   namespace:
 [INFO]file: usr/share/maven-poms/JPP.vdsm-
 jsonrpc-java-root.pom
 [INFO] ===
 java.lang.ArrayIndexOutOfBoundsException: 4648
 at

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Sandro Bonazzola 
On Thu, Oct 6, 2016 at 3:27 PM, Piotr Kliczewski 
wrote:

>
>
> On Thu, Oct 6, 2016 at 2:40 PM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Thu, Oct 6, 2016 at 12:07 PM, Piotr Kliczewski 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 6, 2016 at 11:56 AM, Sandro Bonazzola 
>>> wrote:
>>>


 On Wed, Oct 5, 2016 at 11:26 AM, Piotr Kliczewski 
 wrote:

> I talked to xmvn maintainer and it seems that xmvn uses asm 3 to
> analyze the code after the build.
> This library do not support java8 syntax. I was asked to open a BZ for
> it [1]
>
> Now we are thinking how to workaround the issue before the fix will be
> available.
>
> Thanks,
> Piotr
>
> [1] https://bugzilla.redhat.com/1381883
>

 I'll try to escalate the bug.
 The patch attached to the BZ looks simple enough, if it may help I can
 try to provide an updated version of xmvn within CentOS Virt SIG for 4.1
 candidate repos.
 May this help?



>>> I believe so, Thank you!
>>>
>>
>> Ok, did it, you need to add https://cbs.centos.org/rep
>> os/virt7-ovirt-41-candidate/x86_64/os/ to your repos files in
>> standard-ci automation directory
>>
>>
>>
>
> I added it here [1] and run the build [2] and I saw the same issue.
>
>
> [1] https://gerrit.ovirt.org/#/c/64481/7/automation/build-
> artifacts.repos.el6
> [2] http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_
> check-patch-el7-x86_64/51/console
>
>
You added to el6 repo, you should have added it to el7 :-) build-
artifacts.repos.el7



>
>
>>
>>>


>
>
> On Wed, Oct 5, 2016 at 10:00 AM, Piotr Kliczewski  > wrote:
>
>> Actually I saw f24 output, sorry. Still looking into it.
>>
>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski > > wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski <
>>> pklic...@redhat.com> wrote:
>>>
 Sandro,

 Thank you, changing java dept in spec to


>>> BuildRequires: java-1.8.0-openjdk-devel >= 1:1.8.0
>>>
>>> helped
>>>

 On Wed, Oct 5, 2016 at 9:35 AM, Sandro Bonazzola <
 sbona...@redhat.com> wrote:

>
>
> On Wed, Oct 5, 2016 at 9:34 AM, Piotr Kliczewski <
> pklic...@redhat.com> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 9:01 AM, Sandro Bonazzola <
>> sbona...@redhat.com> wrote:
>>
>>> make[1]: Leaving directory `/home/jenkins/workspace/vdsm-
>>> jsonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java
>>> /rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master'
>>> + xmvn-install -R .xmvn-reactor -n vdsm-jsonrpc-java -d
>>> /home/jenkins/workspace/vdsm-jsonrpc-java_master_check-patch
>>> -el7-x86_64/vdsm-jsonrpc-java/rpmbuild/BUILDROOT/vdsm-jsonrp
>>> c-java-1.3.1-master.el7.centos.x86_64
>>> [INFO] ===
>>> [INFO] SOURCE ARTIFACT:
>>> [INFO] groupId: org.ovirt.vdsm-jsonrpc-java
>>> [INFO]  artifactId: root
>>> [INFO]   extension: pom
>>> [INFO]  classifier:
>>> [INFO] version: 1.3.1-SNAPSHOT
>>> [INFO]  stereotype: pom
>>> [INFO]   namespace:
>>> [INFO]file: /home/jenkins/workspace/vdsm-j
>>> sonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java/
>>> rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master/pom.xml
>>> [INFO] ---
>>> [INFO] TARGET ARTIFACT:
>>> [INFO] groupId: JPP/vdsm-jsonrpc-java
>>> [INFO]  artifactId: root
>>> [INFO]   extension: pom
>>> [INFO]  classifier:
>>> [INFO] version: SYSTEM
>>> [INFO]  stereotype: pom
>>> [INFO]   namespace:
>>> [INFO]file: usr/share/maven-poms/JPP.vdsm-
>>> jsonrpc-java-root.pom
>>> [INFO] ===
>>> java.lang.ArrayIndexOutOfBoundsException: 4648
>>> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
>>> at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>> at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.uses
>>> NativeCode(DefaultInstaller.java:545)
>>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
>>> allArtifact(DefaultInstaller.java:574)
>>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
>>> all(DefaultInstaller.java:758)
>>> at org.fedoraproject.maven.tools.installer.InstallerCli.run(Ins
>>> tallerCli.java:174)
>>> at

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Piotr Kliczewski 
On Thu, Oct 6, 2016 at 2:40 PM, Sandro Bonazzola 
wrote:

>
>
> On Thu, Oct 6, 2016 at 12:07 PM, Piotr Kliczewski 
> wrote:
>
>>
>>
>> On Thu, Oct 6, 2016 at 11:56 AM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 11:26 AM, Piotr Kliczewski 
>>> wrote:
>>>
 I talked to xmvn maintainer and it seems that xmvn uses asm 3 to
 analyze the code after the build.
 This library do not support java8 syntax. I was asked to open a BZ for
 it [1]

 Now we are thinking how to workaround the issue before the fix will be
 available.

 Thanks,
 Piotr

 [1] https://bugzilla.redhat.com/1381883

>>>
>>> I'll try to escalate the bug.
>>> The patch attached to the BZ looks simple enough, if it may help I can
>>> try to provide an updated version of xmvn within CentOS Virt SIG for 4.1
>>> candidate repos.
>>> May this help?
>>>
>>>
>>>
>> I believe so, Thank you!
>>
>
> Ok, did it, you need to add https://cbs.centos.org/repos/virt7-ovirt-41-
> candidate/x86_64/os/ to your repos files in standard-ci automation
> directory
>
>
>

I added it here [1] and run the build [2] and I saw the same issue.


[1]
https://gerrit.ovirt.org/#/c/64481/7/automation/build-artifacts.repos.el6
[2]
http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_check-patch-el7-x86_64/51/console



>
>>
>>>
>>>


 On Wed, Oct 5, 2016 at 10:00 AM, Piotr Kliczewski 
 wrote:

> Actually I saw f24 output, sorry. Still looking into it.
>
> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski > > wrote:
>>
>>> Sandro,
>>>
>>> Thank you, changing java dept in spec to
>>>
>>>
>> BuildRequires: java-1.8.0-openjdk-devel >= 1:1.8.0
>>
>> helped
>>
>>>
>>> On Wed, Oct 5, 2016 at 9:35 AM, Sandro Bonazzola <
>>> sbona...@redhat.com> wrote:
>>>


 On Wed, Oct 5, 2016 at 9:34 AM, Piotr Kliczewski <
 pklic...@redhat.com> wrote:

>
>
> On Wed, Oct 5, 2016 at 9:01 AM, Sandro Bonazzola <
> sbona...@redhat.com> wrote:
>
>> make[1]: Leaving directory `/home/jenkins/workspace/vdsm-
>> jsonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java
>> /rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master'
>> + xmvn-install -R .xmvn-reactor -n vdsm-jsonrpc-java -d
>> /home/jenkins/workspace/vdsm-jsonrpc-java_master_check-patch
>> -el7-x86_64/vdsm-jsonrpc-java/rpmbuild/BUILDROOT/vdsm-jsonrp
>> c-java-1.3.1-master.el7.centos.x86_64
>> [INFO] ===
>> [INFO] SOURCE ARTIFACT:
>> [INFO] groupId: org.ovirt.vdsm-jsonrpc-java
>> [INFO]  artifactId: root
>> [INFO]   extension: pom
>> [INFO]  classifier:
>> [INFO] version: 1.3.1-SNAPSHOT
>> [INFO]  stereotype: pom
>> [INFO]   namespace:
>> [INFO]file: /home/jenkins/workspace/vdsm-j
>> sonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java/
>> rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master/pom.xml
>> [INFO] ---
>> [INFO] TARGET ARTIFACT:
>> [INFO] groupId: JPP/vdsm-jsonrpc-java
>> [INFO]  artifactId: root
>> [INFO]   extension: pom
>> [INFO]  classifier:
>> [INFO] version: SYSTEM
>> [INFO]  stereotype: pom
>> [INFO]   namespace:
>> [INFO]file: usr/share/maven-poms/JPP.vdsm-
>> jsonrpc-java-root.pom
>> [INFO] ===
>> java.lang.ArrayIndexOutOfBoundsException: 4648
>> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
>> at org.objectweb.asm.ClassReader.accept(Unknown Source)
>> at org.objectweb.asm.ClassReader.accept(Unknown Source)
>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.uses
>> NativeCode(DefaultInstaller.java:545)
>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
>> allArtifact(DefaultInstaller.java:574)
>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
>> all(DefaultInstaller.java:758)
>> at org.fedoraproject.maven.tools.installer.InstallerCli.run(Ins
>> tallerCli.java:174)
>> at org.fedoraproject.maven.tools.installer.InstallerCli.main(In
>> stallerCli.java:187)
>> error: Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
>>
>>
>> RPM build errors:
>> Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
>> Took 71 seconds
>>

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Sandro Bonazzola 
On Thu, Oct 6, 2016 at 12:07 PM, Piotr Kliczewski 
wrote:

>
>
> On Thu, Oct 6, 2016 at 11:56 AM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 11:26 AM, Piotr Kliczewski 
>> wrote:
>>
>>> I talked to xmvn maintainer and it seems that xmvn uses asm 3 to analyze
>>> the code after the build.
>>> This library do not support java8 syntax. I was asked to open a BZ for
>>> it [1]
>>>
>>> Now we are thinking how to workaround the issue before the fix will be
>>> available.
>>>
>>> Thanks,
>>> Piotr
>>>
>>> [1] https://bugzilla.redhat.com/1381883
>>>
>>
>> I'll try to escalate the bug.
>> The patch attached to the BZ looks simple enough, if it may help I can
>> try to provide an updated version of xmvn within CentOS Virt SIG for 4.1
>> candidate repos.
>> May this help?
>>
>>
>>
> I believe so, Thank you!
>

Ok, did it, you need to add
https://cbs.centos.org/repos/virt7-ovirt-41-candidate/x86_64/os/ to your
repos files in standard-ci automation directory



>
>
>>
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 10:00 AM, Piotr Kliczewski 
>>> wrote:
>>>
 Actually I saw f24 output, sorry. Still looking into it.

 On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
 wrote:

>
>
> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
> wrote:
>
>> Sandro,
>>
>> Thank you, changing java dept in spec to
>>
>>
> BuildRequires: java-1.8.0-openjdk-devel >= 1:1.8.0
>
> helped
>
>>
>> On Wed, Oct 5, 2016 at 9:35 AM, Sandro Bonazzola > > wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 9:34 AM, Piotr Kliczewski <
>>> pklic...@redhat.com> wrote:
>>>


 On Wed, Oct 5, 2016 at 9:01 AM, Sandro Bonazzola <
 sbona...@redhat.com> wrote:

> make[1]: Leaving directory `/home/jenkins/workspace/vdsm-
> jsonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java
> /rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master'
> + xmvn-install -R .xmvn-reactor -n vdsm-jsonrpc-java -d
> /home/jenkins/workspace/vdsm-jsonrpc-java_master_check-patch
> -el7-x86_64/vdsm-jsonrpc-java/rpmbuild/BUILDROOT/vdsm-jsonrp
> c-java-1.3.1-master.el7.centos.x86_64
> [INFO] ===
> [INFO] SOURCE ARTIFACT:
> [INFO] groupId: org.ovirt.vdsm-jsonrpc-java
> [INFO]  artifactId: root
> [INFO]   extension: pom
> [INFO]  classifier:
> [INFO] version: 1.3.1-SNAPSHOT
> [INFO]  stereotype: pom
> [INFO]   namespace:
> [INFO]file: /home/jenkins/workspace/vdsm-j
> sonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java/
> rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master/pom.xml
> [INFO] ---
> [INFO] TARGET ARTIFACT:
> [INFO] groupId: JPP/vdsm-jsonrpc-java
> [INFO]  artifactId: root
> [INFO]   extension: pom
> [INFO]  classifier:
> [INFO] version: SYSTEM
> [INFO]  stereotype: pom
> [INFO]   namespace:
> [INFO]file: usr/share/maven-poms/JPP.vdsm-
> jsonrpc-java-root.pom
> [INFO] ===
> java.lang.ArrayIndexOutOfBoundsException: 4648
> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.fedoraproject.maven.installer.impl.DefaultInstaller.uses
> NativeCode(DefaultInstaller.java:545)
> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
> allArtifact(DefaultInstaller.java:574)
> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
> all(DefaultInstaller.java:758)
> at org.fedoraproject.maven.tools.installer.InstallerCli.run(Ins
> tallerCli.java:174)
> at org.fedoraproject.maven.tools.installer.InstallerCli.main(In
> stallerCli.java:187)
> error: Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
>
>
> RPM build errors:
> Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
> Took 71 seconds
> ===
>
> No idea about why this happen, never seen it in other builds. I
> can only guess that something in the generated pom file is not 
> resolvable
> by the installer using JDK 1.7.
> Maybe try with JDK 1.8 as in Fedora?
>
>
 This issue started to occur when we moved from JDK 1.7 to 1.8. It
 would be good to add a bit of verbosity so maybe we would get more info

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves

2016-10-06 Thread Gil Shinar (oVirt JIRA) 

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21603#comment-21603
 ] 

Gil Shinar commented on OVIRT-751:
--

The default maven's cache is a .m2 folder under the user's home directory so 
the mount should be:
source: /.m2
destination: /.m2

Something like that.

> Persistent maven caches on the mock slaves
> --
>
> Key: OVIRT-751
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Anton Marchukov
>Assignee: infra
>
> I think we need to design a way to retain maven caches on the mocked jenkins 
> slaves. Currently it is stored inside the mock and thus maven downloads 
> packages from artifactory server each time. 
> However there is really no reason for that. Maven artifacts are designed to 
> be immutable so once artifact is in the repo there is no trivial way to 
> change it without creating a new version. In fact it should never be needed 
> and the correct solution for that is to always create a new version.
> SNAPSHOOT artifacts are in fact timestamped and each one have different file 
> name. It is just not visible since maven automatically takes the latest one. 
> But it is not related to caching as the new snapshoot will be a new artifact 
> still.
> So based on that point there is no reason to purge maven cache each time, but 
> there are reasons why not to purge. Not purging them will reduce the build 
> times of all java jobs and also reduce the network traffic we have. 



--
This message was sent by Atlassian JIRA
(v1000.383.2#100014)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves

2016-10-06 Thread Barak Korren (oVirt JIRA) 

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21601#comment-21601
 ] 

Barak Korren edited comment on OVIRT-751 at 10/6/16 3:20 PM:
-

This is something a project can decide to do on its own by simply bind-mounting 
a known location into the chroot (with the *.mounts file).
You can either have a per-job cache by mounting from under $WORKSPACE, or a 
global per-slave cache by mounting from under /home/jenkins


was (Author: bkor...@redhat.com):
This is something a project can decide to do on its own by simply bind-mounting 
a known location into the chroot (with the *.mounts) file.
You can either have a per-job cache by mounting from under $WORKSPACE, or a 
global per-slave cache by mounting from under /home/jenkins

> Persistent maven caches on the mock slaves
> --
>
> Key: OVIRT-751
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Anton Marchukov
>Assignee: infra
>
> I think we need to design a way to retain maven caches on the mocked jenkins 
> slaves. Currently it is stored inside the mock and thus maven downloads 
> packages from artifactory server each time. 
> However there is really no reason for that. Maven artifacts are designed to 
> be immutable so once artifact is in the repo there is no trivial way to 
> change it without creating a new version. In fact it should never be needed 
> and the correct solution for that is to always create a new version.
> SNAPSHOOT artifacts are in fact timestamped and each one have different file 
> name. It is just not visible since maven automatically takes the latest one. 
> But it is not related to caching as the new snapshoot will be a new artifact 
> still.
> So based on that point there is no reason to purge maven cache each time, but 
> there are reasons why not to purge. Not purging them will reduce the build 
> times of all java jobs and also reduce the network traffic we have. 



--
This message was sent by Atlassian JIRA
(v1000.383.2#100014)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves

2016-10-06 Thread Barak Korren (oVirt JIRA) 

[ 
https://ovirt-jira.atlassian.net/browse/OVIRT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=21601#comment-21601
 ] 

Barak Korren commented on OVIRT-751:


This is something a project can decide to do on its own by simply bind-mounting 
a known location into the chroot (with the *.mounts) file.
You can either have a per-job cache by mounting from under $WORKSPACE, or a 
global per-slave cache by mounting from under /home/jenkins

> Persistent maven caches on the mock slaves
> --
>
> Key: OVIRT-751
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751
> Project: oVirt - virtualization made easy
>  Issue Type: Improvement
>Reporter: Anton Marchukov
>Assignee: infra
>
> I think we need to design a way to retain maven caches on the mocked jenkins 
> slaves. Currently it is stored inside the mock and thus maven downloads 
> packages from artifactory server each time. 
> However there is really no reason for that. Maven artifacts are designed to 
> be immutable so once artifact is in the repo there is no trivial way to 
> change it without creating a new version. In fact it should never be needed 
> and the correct solution for that is to always create a new version.
> SNAPSHOOT artifacts are in fact timestamped and each one have different file 
> name. It is just not visible since maven automatically takes the latest one. 
> But it is not related to caching as the new snapshoot will be a new artifact 
> still.
> So based on that point there is no reason to purge maven cache each time, but 
> there are reasons why not to purge. Not purging them will reduce the build 
> times of all java jobs and also reduce the network traffic we have. 



--
This message was sent by Atlassian JIRA
(v1000.383.2#100014)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build became unstable: ovirt_4.0_he-system-tests #355

2016-10-06 Thread jenkins 
See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

[JIRA] (OVIRT-751) Persistent maven caches on the mock slaves

2016-10-06 Thread Anton Marchukov (oVirt JIRA) 
Anton Marchukov created OVIRT-751:
-

 Summary: Persistent maven caches on the mock slaves
 Key: OVIRT-751
 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-751
 Project: oVirt - virtualization made easy
  Issue Type: Improvement
Reporter: Anton Marchukov
Assignee: infra


I think we need to design a way to retain maven caches on the mocked jenkins 
slaves. Currently it is stored inside the mock and thus maven downloads 
packages from artifactory server each time. 

However there is really no reason for that. Maven artifacts are designed to be 
immutable so once artifact is in the repo there is no trivial way to change it 
without creating a new version. In fact it should never be needed and the 
correct solution for that is to always create a new version.

SNAPSHOOT artifacts are in fact timestamped and each one have different file 
name. It is just not visible since maven automatically takes the latest one. 
But it is not related to caching as the new snapshoot will be a new artifact 
still.

So based on that point there is no reason to purge maven cache each time, but 
there are reasons why not to purge. Not purging them will reduce the build 
times of all java jobs and also reduce the network traffic we have. 



--
This message was sent by Atlassian JIRA
(v1000.383.2#100014)
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build is back to normal : ovirt_master_system-tests #622

2016-10-06 Thread jenkins 
See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_master_system-tests #621

2016-10-06 Thread jenkins 
See 

--
Started by user pkliczewski
[EnvInject] - Loading node environment variables.
Building remotely on ovirt-srv22.phx.ovirt.org (phx physical integ-tests fc24) 
in workspace 
Cloning the remote Git repository
Cloning repository git://gerrit.ovirt.org/ovirt-system-tests.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from git://gerrit.ovirt.org/ovirt-system-tests.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://gerrit.ovirt.org/ovirt-system-tests.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://gerrit.ovirt.org/ovirt-system-tests.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://gerrit.ovirt.org/ovirt-system-tests.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
No valid HEAD. Skipping the resetting
 > git clean -fdx # timeout=10
Pruning obsolete local branches
Fetching upstream changes from git://gerrit.ovirt.org/ovirt-system-tests.git
 > git -c core.askpass=true fetch --tags --progress 
 > git://gerrit.ovirt.org/ovirt-system-tests.git refs/changes/63/65063/2 --prune
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://gerrit.ovirt.org/ovirt-system-tests.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at 
org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true 
fetch --tags --progress git://gerrit.ovirt.org/ovirt-system-tests.git 
refs/changes/63/65063/2 --prune" returned status code 128:
stdout: 
stderr: fatal: Couldn't find remote ref refs/changes/63/65063/2

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:152)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to ovirt-srv22.phx.ovirt.org(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:252)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor512.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy60.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 12 more
ERROR: null
Performing Post build task...
Match found for :.* : True

Build failed in Jenkins: ovirt_master_system-tests #620

2016-10-06 Thread jenkins 
See 

--
[...truncated 5 lines...]
 > git config remote.origin.url git://gerrit.ovirt.org/ovirt-system-tests.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
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://gerrit.ovirt.org/ovirt-system-tests.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at 
org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned 
status code 1:
stdout: Removing basic_suite_master/LagoInitFile
Removing mocker-fedora-24-x86_64.fc24.cfg

stderr: warning: failed to remove deployment-basic_suite_master/default/uuid
warning: failed to remove deployment-basic_suite_master/default/id_rsa
warning: failed to remove deployment-basic_suite_master/default/id_rsa.pub
warning: failed to remove deployment-basic_suite_master/default/initialized
warning: failed to remove 
deployment-basic_suite_master/default/images/lago_basic_suite_master_host0_root.qcow2
warning: failed to remove 
deployment-basic_suite_master/default/images/lago_basic_suite_master_engine_root.qcow2
warning: failed to remove 
deployment-basic_suite_master/default/images/lago_basic_suite_master_engine_nfs.raw
warning: failed to remove 
deployment-basic_suite_master/default/images/lago_basic_suite_master_engine_export.raw
warning: failed to remove 
deployment-basic_suite_master/default/images/lago_basic_suite_master_engine_iscsi.raw
warning: failed to remove 
deployment-basic_suite_master/default/images/lago_basic_suite_master_host1_root.qcow2
warning: failed to remove 
deployment-basic_suite_master/default/scripts/_home_jenkins_workspace_ovirt_master_system-tests_ovirt-system-tests_basic_suite_master_.._common_deploy-scripts_add_local_repo.sh
warning: failed to remove 
deployment-basic_suite_master/default/scripts/_home_jenkins_workspace_ovirt_master_system-tests_ovirt-system-tests_basic_suite_master_.._common_deploy-scripts_setup_host_el7.sh
warning: failed to remove 
deployment-basic_suite_master/default/scripts/_home_jenkins_workspace_ovirt_master_system-tests_ovirt-system-tests_basic_suite_master_.._common_deploy-scripts_setup_storage_unified_el7.sh
warning: failed to remove 
deployment-basic_suite_master/default/scripts/_home_jenkins_workspace_ovirt_master_system-tests_ovirt-system-tests_basic_suite_master_.._common_deploy-scripts_setup_engine.sh
warning: failed to remove deployment-basic_suite_master/current
warning: failed to remove exported-artifacts/lago_logs/lago.log

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1616)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1612)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1254)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1266)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.clean(CliGitAPIImpl.java:621)
at hudson.plugins.git.GitAPI.clean(GitAPI.java:311)
at sun.reflect.GeneratedMethodAccessor818.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:884)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:859)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:818)
at hudson.remoting.UserRequest.perform(UserRequest.java:152)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at

Re: Decommissioning etherpad and old wiki

2016-10-06 Thread Dan Kenigsberg 
On Thu, Oct 06, 2016 at 05:53:54PM +0900, Marc Dequènes (Duck) wrote:
> Quack,
> 
> The wiki content was already converted into the website, and remaining
> broken links & co were fixed (thanks Garrett). It was merely kept in
> case some content was forgotten (read-only).
> 
> The Etherpad was barely used and a pain to upgrade/maintain, so the
> infra team with the last remaining user decided to close it.
> 
> They are to be removed soon. In fact we already stopped them to track
> the remaining users, and no one complained. It can be restarted on
> demand before the removal date.
> 
> On 2016-10-26 the resources will be purged. Backup has been made, so
> nothing is lost but unless there is a good reason it won't be used.
> 
> Btw, the wiki@ mailing-list was unused and is now read-only.

How much resources did old.ovirt.org take? I many occasions, the
migration to the new git-based site rendered pages almost unreadable. In
such occasions, I loved going back to old.ovirt.org, to see how a
feature page was meant to look like.

Can we keep old.ovirt.org for another year? I see that it is currently
down.
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Piotr Kliczewski 
On Thu, Oct 6, 2016 at 11:56 AM, Sandro Bonazzola 
wrote:

>
>
> On Wed, Oct 5, 2016 at 11:26 AM, Piotr Kliczewski 
> wrote:
>
>> I talked to xmvn maintainer and it seems that xmvn uses asm 3 to analyze
>> the code after the build.
>> This library do not support java8 syntax. I was asked to open a BZ for it
>> [1]
>>
>> Now we are thinking how to workaround the issue before the fix will be
>> available.
>>
>> Thanks,
>> Piotr
>>
>> [1] https://bugzilla.redhat.com/1381883
>>
>
> I'll try to escalate the bug.
> The patch attached to the BZ looks simple enough, if it may help I can try
> to provide an updated version of xmvn within CentOS Virt SIG for 4.1
> candidate repos.
> May this help?
>
>
>
I believe so, Thank you!


>
>
>>
>>
>> On Wed, Oct 5, 2016 at 10:00 AM, Piotr Kliczewski 
>> wrote:
>>
>>> Actually I saw f24 output, sorry. Still looking into it.
>>>
>>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
>>> wrote:
>>>


 On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
 wrote:

> Sandro,
>
> Thank you, changing java dept in spec to
>
>
 BuildRequires: java-1.8.0-openjdk-devel >= 1:1.8.0

 helped

>
> On Wed, Oct 5, 2016 at 9:35 AM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 9:34 AM, Piotr Kliczewski > > wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 9:01 AM, Sandro Bonazzola <
>>> sbona...@redhat.com> wrote:
>>>
 make[1]: Leaving directory `/home/jenkins/workspace/vdsm-
 jsonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java
 /rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master'
 + xmvn-install -R .xmvn-reactor -n vdsm-jsonrpc-java -d
 /home/jenkins/workspace/vdsm-jsonrpc-java_master_check-patch
 -el7-x86_64/vdsm-jsonrpc-java/rpmbuild/BUILDROOT/vdsm-jsonrp
 c-java-1.3.1-master.el7.centos.x86_64
 [INFO] ===
 [INFO] SOURCE ARTIFACT:
 [INFO] groupId: org.ovirt.vdsm-jsonrpc-java
 [INFO]  artifactId: root
 [INFO]   extension: pom
 [INFO]  classifier:
 [INFO] version: 1.3.1-SNAPSHOT
 [INFO]  stereotype: pom
 [INFO]   namespace:
 [INFO]file: /home/jenkins/workspace/vdsm-j
 sonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java/
 rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master/pom.xml
 [INFO] ---
 [INFO] TARGET ARTIFACT:
 [INFO] groupId: JPP/vdsm-jsonrpc-java
 [INFO]  artifactId: root
 [INFO]   extension: pom
 [INFO]  classifier:
 [INFO] version: SYSTEM
 [INFO]  stereotype: pom
 [INFO]   namespace:
 [INFO]file: usr/share/maven-poms/JPP.vdsm-
 jsonrpc-java-root.pom
 [INFO] ===
 java.lang.ArrayIndexOutOfBoundsException: 4648
 at org.objectweb.asm.ClassReader.readClass(Unknown Source)
 at org.objectweb.asm.ClassReader.accept(Unknown Source)
 at org.objectweb.asm.ClassReader.accept(Unknown Source)
 at org.fedoraproject.maven.installer.impl.DefaultInstaller.uses
 NativeCode(DefaultInstaller.java:545)
 at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
 allArtifact(DefaultInstaller.java:574)
 at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
 all(DefaultInstaller.java:758)
 at org.fedoraproject.maven.tools.installer.InstallerCli.run(Ins
 tallerCli.java:174)
 at org.fedoraproject.maven.tools.installer.InstallerCli.main(In
 stallerCli.java:187)
 error: Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)


 RPM build errors:
 Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
 Took 71 seconds
 ===

 No idea about why this happen, never seen it in other builds. I can
 only guess that something in the generated pom file is not resolvable 
 by
 the installer using JDK 1.7.
 Maybe try with JDK 1.8 as in Fedora?


>>> This issue started to occur when we moved from JDK 1.7 to 1.8. It
>>> would be good to add a bit of verbosity so maybe we would get more info
>>> about the failure.
>>>
>>
>> That may be the clue. the EL7 build is using jdk 1.7 not 1.8.
>>
>>
>>
>>
>>>
>>>


 On Tue, Oct 4, 2016 at 8:58 PM, Martin Perina 
 wrote:

> Hi Sandro,
>
> could you please take a look at the issue? Is this some bug in

Re: EL7 build issues for vdsm-jsonrpc-java

2016-10-06 Thread Sandro Bonazzola 
On Wed, Oct 5, 2016 at 11:26 AM, Piotr Kliczewski 
wrote:

> I talked to xmvn maintainer and it seems that xmvn uses asm 3 to analyze
> the code after the build.
> This library do not support java8 syntax. I was asked to open a BZ for it
> [1]
>
> Now we are thinking how to workaround the issue before the fix will be
> available.
>
> Thanks,
> Piotr
>
> [1] https://bugzilla.redhat.com/1381883
>

I'll try to escalate the bug.
The patch attached to the BZ looks simple enough, if it may help I can try
to provide an updated version of xmvn within CentOS Virt SIG for 4.1
candidate repos.
May this help?




>
>
> On Wed, Oct 5, 2016 at 10:00 AM, Piotr Kliczewski 
> wrote:
>
>> Actually I saw f24 output, sorry. Still looking into it.
>>
>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 9:58 AM, Piotr Kliczewski 
>>> wrote:
>>>
 Sandro,

 Thank you, changing java dept in spec to


>>> BuildRequires: java-1.8.0-openjdk-devel >= 1:1.8.0
>>>
>>> helped
>>>

 On Wed, Oct 5, 2016 at 9:35 AM, Sandro Bonazzola 
 wrote:

>
>
> On Wed, Oct 5, 2016 at 9:34 AM, Piotr Kliczewski 
> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 9:01 AM, Sandro Bonazzola > > wrote:
>>
>>> make[1]: Leaving directory `/home/jenkins/workspace/vdsm-
>>> jsonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java
>>> /rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master'
>>> + xmvn-install -R .xmvn-reactor -n vdsm-jsonrpc-java -d
>>> /home/jenkins/workspace/vdsm-jsonrpc-java_master_check-patch
>>> -el7-x86_64/vdsm-jsonrpc-java/rpmbuild/BUILDROOT/vdsm-jsonrp
>>> c-java-1.3.1-master.el7.centos.x86_64
>>> [INFO] ===
>>> [INFO] SOURCE ARTIFACT:
>>> [INFO] groupId: org.ovirt.vdsm-jsonrpc-java
>>> [INFO]  artifactId: root
>>> [INFO]   extension: pom
>>> [INFO]  classifier:
>>> [INFO] version: 1.3.1-SNAPSHOT
>>> [INFO]  stereotype: pom
>>> [INFO]   namespace:
>>> [INFO]file: /home/jenkins/workspace/vdsm-j
>>> sonrpc-java_master_check-patch-el7-x86_64/vdsm-jsonrpc-java/
>>> rpmbuild/BUILD/vdsm-jsonrpc-java-1.3.1_master/pom.xml
>>> [INFO] ---
>>> [INFO] TARGET ARTIFACT:
>>> [INFO] groupId: JPP/vdsm-jsonrpc-java
>>> [INFO]  artifactId: root
>>> [INFO]   extension: pom
>>> [INFO]  classifier:
>>> [INFO] version: SYSTEM
>>> [INFO]  stereotype: pom
>>> [INFO]   namespace:
>>> [INFO]file: usr/share/maven-poms/JPP.vdsm-
>>> jsonrpc-java-root.pom
>>> [INFO] ===
>>> java.lang.ArrayIndexOutOfBoundsException: 4648
>>> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
>>> at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>> at org.objectweb.asm.ClassReader.accept(Unknown Source)
>>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.uses
>>> NativeCode(DefaultInstaller.java:545)
>>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
>>> allArtifact(DefaultInstaller.java:574)
>>> at org.fedoraproject.maven.installer.impl.DefaultInstaller.inst
>>> all(DefaultInstaller.java:758)
>>> at org.fedoraproject.maven.tools.installer.InstallerCli.run(Ins
>>> tallerCli.java:174)
>>> at org.fedoraproject.maven.tools.installer.InstallerCli.main(In
>>> stallerCli.java:187)
>>> error: Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
>>>
>>>
>>> RPM build errors:
>>> Bad exit status from /var/tmp/rpm-tmp.KMxx5N (%install)
>>> Took 71 seconds
>>> ===
>>>
>>> No idea about why this happen, never seen it in other builds. I can
>>> only guess that something in the generated pom file is not resolvable by
>>> the installer using JDK 1.7.
>>> Maybe try with JDK 1.8 as in Fedora?
>>>
>>>
>> This issue started to occur when we moved from JDK 1.7 to 1.8. It
>> would be good to add a bit of verbosity so maybe we would get more info
>> about the failure.
>>
>
> That may be the clue. the EL7 build is using jdk 1.7 not 1.8.
>
>
>
>
>>
>>
>>>
>>>
>>> On Tue, Oct 4, 2016 at 8:58 PM, Martin Perina 
>>> wrote:
>>>
 Hi Sandro,

 could you please take a look at the issue? Is this some bug in
 maven-local on EL7?

 Thanks

 Martin


 On Fri, Sep 30, 2016 at 2:59 PM, Martin Perina 
 wrote:

>
>
> On Fri, Sep 30, 2016 at 2:56 PM, Piotr Kliczewski

Build failed in Jenkins: ovirt_master_system-tests #618

2016-10-06 Thread jenkins 
See 

--
Started by user pkliczewski
[EnvInject] - Loading node environment variables.
Building remotely on ovirt-srv23.phx.ovirt.org (physical integ-tests) in 
workspace 
Cloning the remote Git repository
Cloning repository git://gerrit.ovirt.org/ovirt-system-tests.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from git://gerrit.ovirt.org/ovirt-system-tests.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://gerrit.ovirt.org/ovirt-system-tests.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://gerrit.ovirt.org/ovirt-system-tests.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://gerrit.ovirt.org/ovirt-system-tests.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
No valid HEAD. Skipping the resetting
 > git clean -fdx # timeout=10
Pruning obsolete local branches
Fetching upstream changes from git://gerrit.ovirt.org/ovirt-system-tests.git
 > git -c core.askpass=true fetch --tags --progress 
 > git://gerrit.ovirt.org/ovirt-system-tests.git refs/changes/63/65063/2 --prune
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://gerrit.ovirt.org/ovirt-system-tests.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:766)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1022)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1053)
at 
org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:129)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true 
fetch --tags --progress git://gerrit.ovirt.org/ovirt-system-tests.git 
refs/changes/63/65063/2 --prune" returned status code 128:
stdout: 
stderr: fatal: Couldn't find remote ref refs/changes/63/65063/2

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:152)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to ovirt-srv23.phx.ovirt.org(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:252)
at hudson.remoting.Channel.call(Channel.java:781)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor512.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at com.sun.proxy.$Proxy60.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:764)
... 12 more
ERROR: null
Performing Post build task...
Match found for :.* : True
Logical

Decommissioning etherpad and old wiki

2016-10-06 Thread Duck 
Quack,

The wiki content was already converted into the website, and remaining
broken links & co were fixed (thanks Garrett). It was merely kept in
case some content was forgotten (read-only).

The Etherpad was barely used and a pain to upgrade/maintain, so the
infra team with the last remaining user decided to close it.

They are to be removed soon. In fact we already stopped them to track
the remaining users, and no one complained. It can be restarted on
demand before the removal date.

On 2016-10-26 the resources will be purged. Backup has been made, so
nothing is lost but unless there is a good reason it won't be used.

Btw, the wiki@ mailing-list was unused and is now read-only.

If you have any concern, please contact the infra mailing-list.

\_o<



signature.asc
Description: OpenPGP digital signature
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Jenkins build is back to stable : ovirt_4.0_he-system-tests #354

2016-10-06 Thread jenkins 
See 

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Build failed in Jenkins: ovirt_master_system-tests #617

2016-10-06 Thread jenkins 
See 

Changes:

[Yaniv Kaul] Add 'non_operational' to the status that fail to add host.

--
[...truncated 689 lines...]
##  took 1561 seconds
##  rc = 1
##
##! ERROR v
##! Last 20 log enties: 
logs/mocker-fedora-24-x86_64.fc24.basic_suite_master.sh/basic_suite_master.sh.log
##!
+ true
+ env_cleanup
+ echo '#'
#
+ local res=0
+ local uuid
+ echo ' Cleaning up'
 Cleaning up
+ [[ -e 

 ]]
+ echo '--- Cleaning with lago'
--- Cleaning with lago
+ lago --workdir 

 destroy --yes --all-prefixes
+ echo '--- Cleaning with lago done'
--- Cleaning with lago done
+ [[ 0 != \0 ]]
+ echo ' Cleanup done'
 Cleanup done
+ exit 0
Took 1402 seconds
===
##!
##! ERROR ^^
##!
##
Build step 'Execute shell' marked build as failure
Performing Post build task...
Match found for :.* : True
Logical operation result is TRUE
Running script  : #!/bin/bash -xe
echo 'shell_scripts/system_tests.collect_logs.sh'

#
# Required jjb vars:
#version
#
VERSION=master
SUITE_TYPE=

WORKSPACE="$PWD"
OVIRT_SUITE="$SUITE_TYPE_suite_$VERSION"
TESTS_LOGS="$WORKSPACE/ovirt-system-tests/exported-artifacts"

rm -rf "$WORKSPACE/exported-artifacts"
mkdir -p "$WORKSPACE/exported-artifacts"

if [[ -d "$TESTS_LOGS" ]]; then
mv "$TESTS_LOGS/"* "$WORKSPACE/exported-artifacts/"
fi

[ovirt_master_system-tests] $ /bin/bash -xe /tmp/hudson4816102879131763275.sh
+ echo shell_scripts/system_tests.collect_logs.sh
shell_scripts/system_tests.collect_logs.sh
+ VERSION=master
+ SUITE_TYPE=
+ WORKSPACE=
+ OVIRT_SUITE=master
+ 
TESTS_LOGS=
+ rm -rf 

+ mkdir -p 

+ [[ -d 

 ]]
+ mv 

 

 

 

 

POST BUILD TASK : SUCCESS
END OF POST BUILD TASK : 0
Match found for :.* : True
Logical operation result is TRUE
Running script  : #!/bin/bash -xe
echo "shell-scripts/mock_cleanup.sh"

shopt -s nullglob


WORKSPACE="$PWD"

# Make clear this is the cleanup, helps reading the jenkins logs
cat 
+ cat
___
###
# #
#   CLEANUP   #
# #
###
+ logs=(./*log ./*/logs)
+ [[ -n ./ovirt-system-tests/logs ]]
+ tar cvzf exported-artifacts/logs.tgz ./ovirt-system-tests/logs
./ovirt-system-tests/logs/
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.basic_suite_master.sh/
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.basic_suite_master.sh/basic_suite_master.sh.log
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.install_packages/
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.install_packages/stdout_stderr.log
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.install_packages/root.log
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.install_packages/state.log
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.install_packages/build.log
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.init/
./ovirt-system-tests/logs/mocker-fedora-24-x86_64.fc24.init/stdout_stderr.log

Re: [Ftpcom] Fwd: ** PROBLEM Service Alert: ovirt-mirrorchecker/ftp.snt.utwente.nl/pub/software/ovirt mirror site last sync is WARNING **

2016-10-06 Thread Nadav Goldin 
My bad, I see it was fixed during the night,

Thanks!

Nadav.

On Thu, Oct 6, 2016 at 9:33 AM, Nadav Goldin  wrote:
> Hi again Maarten,
> any updates on this?
>
> Thanks,
> Nadav.
>
>
> On Tue, Oct 4, 2016 at 12:04 PM, Nadav Goldin  wrote:
>> Hi Maarten,
>> Thanks for the reply. It seems the synchronization is still broken,
>> from the logs I see an attempted rsync connection at:
>>> START:Tue Oct  4 02:00:24 UTC 2016
>>>END:Tue Oct  4 02:23:55 UTC 2016
>> But looking at the timestamps, all files I sampled still date back to
>> 29/09/2016.
>>
>>
>>> In other news; we have replacement hardware underway for the mirror, so
>>> I expect a maintenance window before the end of the year. If it'll
>>> impact the ovirt mirror in a meaningful way, we'll reach out.
>> Great, we'll appreciate that.
>>
>>
>> Nadav.
>>
>>
>>
>>
>> On Sun, Oct 2, 2016 at 9:34 PM, Maarten Aertsen  
>> wrote:
>>> Hi Nadav,
>>>
>>> On 2016-10-02 11:22, Nadav Goldin wrote:
 It looks like ovirt mirror site is not syncing for the past 48 hours
 or so. From the logs I see you are connecting and running rsync, but
 the files aren't synchronized.
>>>
>>> We're currently experiencing a pretty big spike for one of the other
>>> projects we're mirroring, so our own monitoring shows similar warnings.
>>> The rsync is currently running but proceeding very slowly. We expect
>>> traffic to slow down shortly; please let us know if things do not return
>>> to normal within one or two days.
>>>
>>> In other news; we have replacement hardware underway for the mirror, so
>>> I expect a maintenance window before the end of the year. If it'll
>>> impact the ovirt mirror in a meaningful way, we'll reach out.
>>>
>>> best regards, Maarten
>>>
>>> --
>>> Maarten Aertsen
>>> SNT FTPcom
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra