January 2015 - rel-eng - Fedora Mailing-Lists

#5866: Create new channel for building Java packages

by Fedora Release Engineering

#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

9 years

1
20
0 / 0

#5941: Requesting Koji user certificate for Koschei

by Fedora Release Engineering

#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

9 years

1
12
0 / 0

#6064: extend srpm-excluded-arch.py so it can read srpms from multiple dirs

by Fedora Release Engineering

#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

9 years

1
3
0 / 0

#5967: Enable source repo generation

by Fedora Release Engineering

#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

9 years, 1 month

1
6
0 / 0

#5870: rawhide signing

by Fedora Release Engineering

#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

9 years, 1 month

1
18
0 / 0

#5931: [Proposal] Move new branch and unretire requests to pkgdb2

by Fedora Release Engineering

#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

9 years, 1 month

1
21
0 / 0

mash patches to make blacklist/whitelist configurable (followup)

by Ralph Bean

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(-)

9 years, 1 month

1
3
0 / 0

#6016: Use fedpkg-minimal in Fedora buildroots

by Fedora Release Engineering

#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|dis... 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

9 years, 1 month

1
4
0 / 0

#6008: Fedora 21 Alpha .composeinfo should have family=Fedora

by Fedora Release Engineering

#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

9 years, 1 month

1
4
0 / 0

#6062: Deltas for kernel fc21.x86_64 seem missing

by Fedora Release Engineering

#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

9 years, 1 month

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng January 2015