[releng] Issue #6721 `Fedora Media Writer build changes`
by Martin Bříza
mbriza reported a new issue against the project: `releng` that you are following:
``
Hello,
for testing, I have released FMW 4.0.95. To accommodate the changes I'll list below you can use that, however I'd like to ship 4.1.0 (when it's done) as the release for F26.
Mac builds:
======
Homebrew ( https://brew.sh/ ) or an other package manager is required. Use it to install xz (to provide /usr/lib/liblzma.dylib and the required headers).
It's then necessary to include the liblzma.dylib file inside the package (in Contents/Frameworks) and change the rpath pointing at it with install_name_tool. See https://github.com/MartinBriza/MediaWriter/blob/master/dist/mac/build.sh#L38 to see how it's done. No special signing is required for this file.
If you're using macdeployqt with the --always-overwrite argument, you need to stop using it or the compose will fail.
Windows builds:
======
It's necessary to build using F26 or Rawhide. There is a multitude of bugs solved by updating to Qt 5.7.1 which is now included only in F26 and above.
No extra build steps are required, however there's more dynamic libraries to include in the package. See https://github.com/MartinBriza/MediaWriter/blob/master/dist/win/build.sh#L34 .
Also please note that when your code signing certificate for Windows expires, it's now necessary to get a "secure flash drive" from Unizeto with a new one, making it now more than €100 instead of €14 - we should probably change the certificate provider.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6721
6 years, 10 months
[releng] Issue #6756: "ActionNotAllowed" when attempting "koji untag-build
f27"
by Mat Booth
mbooth reported a new issue against the project: `releng` that you are following:
``
I used to be able to untag rawhide builds I'd just built, but when I tried today I get:
"ActionNotAllowed: tag requires autosign permission"
The command I attempted was:
"koji untag-build f27 eclipse-ecf-3.13.3-3.fc27 eclipse-emf-2.12.0-5.fc27"
I am trying to untag eclipse-ecf-3.13.3-3.fc27 and eclipse-emf-2.12.0-5.fc27
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6756
6 years, 10 months
[releng] Issue #6617 `consider cron script for bodhi updates pushes`
by Kevin Fenzi
kevin reported a new issue against the project: `releng` that you are following:
``
Right now we have a list of releng folks that trade off weekly handling bodhi updates pushes. Because all these folks are in different locations and have different workdays and business, updates pushes happen as they are able throughout the day. Additionally some folks are able to push on weekends and holidays and others are not.
Since we no longer need a human release engineer to sign packages before pushing updates, we should consider moving this to just a cron script that runs at the same time every day. This would have the advantage of making the pushes much more predictable and would also save time of busy release engineers.
The script would need to have a bit of error handling and check for existing lock files and error out if any exist. It would also need to be adjustable during freezes to not push the stable updates for the frozen release. Any issues or problems would need to follow a process of filing a ticket on the issue and all release engineers communicating on that ticket so no one is duplicating efforts.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6617
6 years, 10 months
[releng] Issue #6819: RFE: arch-dependent SRPMs
by Igor Gnatenko
ignatenkobrain reported a new issue against the project: `releng` that you are following:
``
As of now we publish only one version of src.rpm which was built on random architecture in koji which is enough for end-users to get source code and do something with it. However, there are more use-cases for SRPMs like getting its requires remotely (what yum-builddep/dnf-builddep and other tools are doing). For example, people report bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1402784.
In base-runtime we query for runtime and build dependencies for packages recursively and we have to regenerate SRPMs for architecture we are looking for the dependencies, so either we should take all srpms and regenerate them for each architecture (which is not really fast) or try-and-guess which packages use %ifarch or similar.
I would like to ask releng to find solution how to share srpms which are different on different architectures.
Thanks in advance!
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6819
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
[releng] Issue #6770: ABRT back in Fedora 26
by Matej Habrnal
mhabrnal reported a new issue against the project: `releng` that you are following:
``
You've temporarily removed ABRT from Fedora 26 Alfa release because of hawkey dependency and service migration from abrt-ccpp.service to abrt-journal-core.service (see https://bugzilla.redhat.com/show_bug.cgi?id=1436941)
ABRT package is now ready (abrt-2.10.2-2.fc26) to be returned back to Fedora release. It has no dependency to hawkey and also spec files contains scriplets which do the migration from abrt-ccpp.service to abrt-journal-core.service.
Making the ticket just for sure :)
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6770
6 years, 10 months