#5866: Create new channel for building Java packages
----------------------+------------------------
Reporter: mizdebsk | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
== Request ==
Please create a new Koji channel for building Java packages which
would exclude ARM builders, or implement an equivalent solution. My
goal is to be able to build noarch Java packages skipping any ARM
builders. Using custom koji command is not a problem for me.
== Justification ==
The great majority of Java packages are noarch. As such they are most
often pisked up by ARM builders.
Java performance on ARM is very poor. The situation got even worse
after JIT for ARM was disabled in JVM. ARM machines are often slower
by one to three orders of magnitude than x86_64. Some tests which
execute in a few seconds on x86_64 can take over half an hour on ARM.
Current state of Java on ARM combined with Koji configuration makes it
difficult to maintain Java packages in Fedora. A substantial amount
of human resources is wasted on waiting for builds to complete,
debugging tests which fail only on ARM, keeping track on builds and
resubmitting them. That resources could be utilised better and I
think that justifies my request.
== Alternative solutions ==
I have tried differnt alternative solutions since ARM became a primary
architecture and none of them is good enough.
One ad-hoc solution is submitting numerous dummy koji tasks for ARM
builders until their capacity is exhausted, then submitting Java
package build and canceling ARM tasks. This is obviously a hack and
should be avoided.
If Koji configuration is not improved the only remaining solution will
be converting Java packages from noarch to arch-specific and adding
ExcludeArch. I still hope that ARM situation will eventually improve,
so I would like to avoid doing drastic things like that, if possible.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5866>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5941: Requesting Koji user certificate for Koschei
-----------------------------+------------------------
Reporter: msimacek | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Koschei is a continuous integration tool for Fedora packages that does
scratch-builds of packages in rawhide as their dependencies change. Right
now it is using my personal certificate for initiating the scratch-builds,
but since we'd like to deploy it in the Fedora Infrastructure, we need a
separate Koji account for it. It will be used only for scratch-building,
no other permissions are needed.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5941>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6064: extend srpm-excluded-arch.py so it can read srpms from multiple dirs
-----------------------------+------------------------
Reporter: sharkcz | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 21 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Currently srpm-excluded-arch.py reads the srpm to generate the
"excludelist" for koji-shadow from a single directory. It limits its usage
to the times when buildrawhide/buildbranched are used (rawhide and
branched release). When the script is extended to read the srpms from
multiple directories it will be able to generate the excludelist also for
released Fedoras by reading the GA repo and the updates repo.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6064>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5967: Enable source repo generation
-------------------------+------------------------
Reporter: mizdebsk | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------------
Please enable source repository generation in kojira, at least for rawhide
(currently f22-build).
Justification: There are many use cases which require access to YUM source
repository. One of them is Koschei (a continous rebuild service), which
requires SRPM repo for resolving package build-dependencies.
Implementation of this feature should be simple - it just involves editing
kojira.conf file
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5967>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5870: rawhide signing
-----------------------------+------------------------
Reporter: kevin | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 21 Final | Component: koji
Keywords: meeting | Blocked By:
Blocking: |
-----------------------------+------------------------
We have talked a number of times about getting rawhide packages signed,
but haven't been able to come up with a solution that is secure and meets
our needs. We should try and do so. :)
This came up again today because gnome-software has different code paths
for signed/unsigned content and they would very much like rawhide to be
signed so it tests the same code as for stable releases.
* There is a koji plugin to sign all builds, but it's not implemented in a
very nice way and stores it's keys/passphrases in clear text files on the
hub.
* Manually signing with sigul could be done, but since there's no gating,
it would mean either large amounts of packages would go out unsigned or
composes would fail for unsigned packages often.
* Additional space would be taken up by more signed rpms/signatures.
* Any solution we come up with could possibly be also used by copr, which
also wishes to sign builds in an unattended manner.
Ideas welcome. ;)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5870>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5931: [Proposal] Move new branch and unretire requests to pkgdb2
-------------------------+------------------------
Reporter: pingou | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: | Component: git
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------------
Till suggested me recently that maybe we could port the new-branch
requests to pkgdb2, together with the requests that for a package to be
unretired.
I have been working with these ideas, they are simply a way for users to
ask an admin to perform an action (atm: request.branch and
request.unretire).
The output can be seen for admins via the UI at:
http://209.132.184.188/admin/actions/
Or for everyone via the API at:
http://209.132.184.188/api/admin/actions/
Note: the logic to change the status of a request isn't there yet but I
thought I would first run the idea by you guys to get some early feedback,
especially since if you like the idea, some tools will need adjustments.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5931>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Following up here on two patches that were:
- posted in a ticket in April https://bugzilla.redhat.com/show_bug.cgi?id=1082832
- mailed to this list in July https://lists.fedoraproject.org/pipermail/rel-eng/2014-July/018149.html
I've rebased them again to be sure they cleanly apply against the master branch
of the mash repo.
If there's anything I can do to modify them to make them acceptable or if I
need to deliver them in some other way, please let me know.
mash/__init__.py | 18 ++++++++++--------
mash/config.py | 14 ++++++++++++++
mash/multilib.py | 40 +++++++++++++++++++---------------------
3 files changed, 43 insertions(+), 29 deletions(-)
#6016: Use fedpkg-minimal in Fedora buildroots
----------------------+------------------------
Reporter: pbabinca | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: meeting | Blocked By:
Blocking: |
----------------------+------------------------
Speedup build root readiness for the builds by reducing dependencies
pulled into build root by fedpkg python package.
Use [http://koji.fedoraproject.org/koji/buildinfo?buildID=485120|fedora-
minimal] shell script which fetches sources only. Similar script is
currently used in EPEL 7 buildroot. Start with rawhide later to other
supported dists.
Original idea came in
[https://lists.fedoraproject.org/pipermail/devel/2014-July/201154.html|discu…
about slow buildSRPMFromSCM].
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6016>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6008: Fedora 21 Alpha .composeinfo should have family=Fedora
----------------------+------------------------
Reporter: dcallagh | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
The .composeinfo file for Fedora 21 Alpha Server currently has this:
{{{
[product]
family = Fedora-Server
name = Fedora-Server-21_Alpha
version = 21_Alpha
variants = Server
}}}
For future F21 composes please update it so that the family is just
"Fedora", with "Server" as the variant like it is currently.
This is consistent with how RHEL has been doing its variant products for
many years. It also just makes more sense -- all the new Fedora variants
are in the same family, that's the whole point of that field. And it will
make our lives easier in Beaker, where we use the family to figure out
which harness builds to use and which kickstart syntax to use.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6008>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6062: Deltas for kernel fc21.x86_64 seem missing
-----------------------------+------------------------
Reporter: abderrahman | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 21 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Since the update to Fedora 21 final, updating the kernel (kernel-core,
kernel-modules, kernel-modules-extra) no longer have DRPMs.
Update is through yum, and delta is on. Since the fresh install, there's
been 2 stable kernel updates (through @updates): 3.17.4-302.fc21.x86_64 &
3.17.6-300.fc21.x86_64, both of which didn't have a drpm so the full
packages were downloaded.
Is this an oversight, or are kernel package no longer built with drpms?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6062>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project