[releng] Issue #6824: Permission for regen-repo f27-perl
by Jitka Plesnikova
jplesnik reported a new issue against the project: `releng` that you are following:
``
I want to run mass rebuild for Perl 5.26 <https://pagure.io/releng/issue/6821>
It is done by running our rebuild script, which counts build dependencies to run build of packages in correct order. It needs to get the built packages to repository and there is a problem. The createRepo is run rarely.
Is it possible to get permission for executing 'koji regen-repo f27-perl'?
The rebuild should take about 10 days.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6824
6 years, 10 months
[releng] Issue #6173: Same volume-id on all F22 ISOs
by Lubomír Sedlář
lsedlar added a new comment to an issue you are following:
``
I checked and current status is that there indeed are two different ISO images with identical volume ids. The netinst produced by lorax shares the same value with isos that Pungi create in `createiso` phase (which is basically the netinst with the yum repo).
[This commit](https://pagure.io/pungi/c/aa38eb1fd79121b9009d9eb5748d8b6cadf94e44?branch=master) added the ability to customize the `dvd` substring of the volume id, but it uses the same value for for both the above mentioned ones.
Maybe it should use `netinst` instead as for the lorax ones? I'm not sure if it would break something.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6173
6 years, 10 months
[releng] Issue #6771: Eclipse packages cannot be built since merging of
s390x into mainline koji
by Mat Booth
mbooth reported a new issue against the project: `releng` that you are following:
``
Problem 1: My builds were not being assigned to any builders:
<sharkcz> nirik: dgilmore: isn't there something special set for eclipse builds in koji? mbooth's tasks are waiting for s390 builder, but the builders accept and process other jobs without issue
<sharkcz> seems they need to be in "eclipse" channel
<sharkcz> is the eclipse channel still required?
<mbooth> sharkcz: It was created IIRC to make eclipse be built by faster 32bit arm builders
<mbooth> So that we can build it in less than 24hours, or something like that
<sharkcz> mboddu: yup, maybe the arm hw got updated since then
It could be that the "eclipse" channel is no longer necessary because when I build Eclipse using the new "aarch32" version of OpenJDK, which appears to have a real 32-bit arm JIT, the build is much quicker.
Problem 2:
<mbooth> sharkcz: Weird, I cancelled my task and submitted a new one -- this time I was given a builder: https://koji.fedoraproject.org/koji/taskinfo?taskID=19368896
<mbooth> sharkcz: It failed though and I don't know why -- No matching package to install: 'eclipse-pde' -- previous s390x eclipse builds should available in the buildroot, right?
<sharkcz> mbooth: seems we missed eclipse-4.7.0-0.6.fc27 in the s390x koji, because it finished after we did all the imports, we have -5, but -6 could be untagged by releng to allow -7 to build
I assume it's "too late" to untag at this point since the offending build is now a couple of days old. How can this be fixed?
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6771
6 years, 10 months
[releng] Issue #6599 `Koji build failed without a reason`
by Pagure
tpopela reported a new issue against the project: `releng` that you are following:
``
Hi,
the build https://koji.fedoraproject.org/koji/taskinfo?taskID=17391659 of webkitgtk4 failed without a reason on armv7hl and arm64. From the build logs it looks that it was still compiling. There is one error mentioned in notification:
<Fault 1: "<class 'pg.OperationalError'>: can't commit">
Here is some log from IRC with Dennis:
<tpopela> Hi everyone, can someone explain me why https://koji.fedoraproject.org/koji/taskinfo?taskID=17391659 failed? Is there now some time limit when the compilation have to succeed (if so, it's not enough for WebKitGTK+ ;))
<dgilmore> tpopela: there is a timeout of 48 hours
<tpopela> dgilmore, I know about that one :) but from the logs it looks like the task stopped without a reason..
<dgilmore> tpopela: I suspect it was killed for using too much memory
<dgilmore> it looks like it was linking on armv7hl
<tpopela> dgilmore, no it was building..
<dgilmore> though dmesg does not show that
<dgilmore> ps axf
<dgilmore> gahh
<dgilmore> 2017-01-23 17:23:14,950 [INFO] koji.TaskManager: Task 17391684 (pid 9103) exited with status 0
<dgilmore> 2017-01-23 17:23:15,157 [INFO] koji.TaskManager: Expiring subsession 26602149 (task 17391684)
<tpopela> dgilmore, what does that mean? That we have no clue? :)
<dgilmore> tpopela: that mock said it finished fine :(
<tpopela> dgilmore, hmm let me start a new build and we will see if it was some hiccup..
<dgilmore> thats my best suggestion
<dgilmore> the failure in koji is <class 'pg.OperationalError'>: can't commit
<dgilmore> which I think is because there was no rpms
<dgilmore> but the mock_output.log agrees the build completed okay
<dgilmore> which is clearly did not
<dgilmore> actually it says that the build started and nothing more
<tpopela> dgilmore, I will create a bug on pagure and maybe someone will chime in with some idea..
<dgilmore> tpopela: its either rpmbuild or mock that failed
<dgilmore> I suspect mock
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6599
6 years, 10 months
[releng] Issue #6688 `Enabling Atomic Host composes for ppc64le and aarch64
arches`
by Sinny Kumari
sinnykumari reported a new issue against the project: `releng` that you are following:
``
Right now, Atomic Host composes are created for x86_64 arch. With decreasing gap between x86_64 and other supported arches in Fedora, we (Alternative arches group) are looking towards enabling Atomic Host composes in Fedora for ppc64le and aarch64. We have also discussed with Dusty Mabe from Atomic working group to see the possibility of having Atomic Host on non x86_64 arches and we both groups are positive towards helping and working together to enable it on other arches.
In order to achieve that, it will be great help if rel-eng can enable Atomic Host composes for ppc64le and aarch64 as well which can be non-blocking in the beginning. With composes, it will be easier to test and see current situation of Atomic Host on asked arches and we can start working on fixing encountered problems.
Thanks
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6688
6 years, 10 months