rel-eng August 2014

rel-eng@lists.fedoraproject.org

8 participants
87 discussions

#5866: Create new channel for building Java packages
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#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

1 20

#5941: Requesting Koji user certificate for Koschei
by Fedora Release Engineering 27 Apr '15

27 Apr '15

#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

1 12

#5967: Enable source repo generation
by Fedora Release Engineering 30 Mar '15

30 Mar '15

#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

1 6

#5870: rawhide signing
by Fedora Release Engineering 23 Mar '15

23 Mar '15

#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

1 18

#5931: [Proposal] Move new branch and unretire requests to pkgdb2
by Fedora Release Engineering 23 Mar '15

23 Mar '15

#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

1 21

#5775: switch to partitioned image and "hd00" pvgrub akis for EC2; remove editing of menu.lst from image processing
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#5775: switch to partitioned image and "hd00" pvgrub akis for EC2; remove editing of menu.lst from image processing ----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ The "hd00 aki" is like the pvgrub kernel image we are using now, but meant for a partitioned device. If we switched to doing this, we could avoid editing the menu.lst file, and therefore would have a more-identical image. . See http://www.dowdandassociates.com/content/howto-amazon-ec2-kernel- images-pv-grub/ (or http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UserProvidedkernels.html, which seems to have vanished today) for more. You can find the images in each region with: euca-describe-images -o amazon --filter "manifest-location=*pv-grub- hd00*" and of course take the newest version. At this point, I doubt we want to change this by alpha, but maybe we could for beta? -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5775> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 6

#4985: Extend test image creation SOP to require notification of delays
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#4985: Extend test image creation SOP to require notification of delays ----------------------+----------------------------------------------------- Reporter: adamwill | Owner: rel-eng(a)lists.fedoraproject.org Type: task | Status: new Milestone: | Component: koji Keywords: | ----------------------+----------------------------------------------------- Working through the F16 QA retrospective here: https://fedoraproject.org/wiki/Fedora_16_QA_Retrospective One of the notes is: "jlaska - Alpha TC1 - Missed the Alpha-TC1 milestone by 1 week, little to no communication regarding status. With only two weeks Alpha ISO test time, losing 50% of time almost certainly results in a slip. See rel-eng ticket#4844 . None of the Alpha rel-eng release tickets have been filed at this time. adamw - perhaps releng image compose SOP should require updating of ticket with progress info, especially when image compose / delivery is delayed?" So: this ticket proposes that the releng 'Composing test images' SOP - https://fedoraproject.org/wiki/Composing_test_images - should be extended to require whoever is creating the images to post a comment on the image request ticket if the compose is delayed, explaining the reasons for the delay (so that any other interested party can attempt to contribute to resolving them) and giving a best estimate of an ETA if possible (so other groups can adjust their scheduling as best they can). Thanks! -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4985> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5836: Update gitolite to gitolite3
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#5836: Update gitolite to gitolite3 ------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: git Keywords: | Blocked By: Blocking: | ------------------+------------------------ The package gitolite3 in EPEL should be used to update gitolite for dist- git. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5836> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#5924: CPUID flags on buildvm-20.phx2.fedoraproject.org
by Fedora Release Engineering 09 Mar '15

09 Mar '15

#5924: CPUID flags on buildvm-20.phx2.fedoraproject.org -----------------------------+------------------------ Reporter: jakub | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 21 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ In the gcc-4.9.0-12.fc21 build logs I saw a weird error: /builddir/build/BUILD/gcc-4.9.0-20140619/obj-x86_64-redhat-linux/gcc/xgcc -B/builddir/build/BUILD/gcc-4.9.0-20140619/obj-x86_64-redhat-linux/gcc/ /builddir/build/BUILD/gcc-4.9.0-20140619/gcc/testsuite/gcc.target/i386/pr57275.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -march=native -lm -o ./pr57275.exe /builddir/build/BUILD/gcc-4.9.0-20140619/gcc/testsuite/gcc.target/i386/pr57275.c:1:0: error: CPU you selected does not support x86-64 instruction set and I'd like to debug that, but don't know of a way to force e.g. a scratch rpm build to a particular build host. Would it be possible for some release engineer to run gcc -v -march=native -S -xc /dev/null -o /tmp/foo.s cat /proc/cpuinfo in the F21 mock chroot on that box? Perhaps we are missing something in the -m{arch,tune}=native logic, a CPU which clearly does support x86_64 64-bit ISA should not be determined as one that does not. Thanks. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5924> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 3

#5959: Enable keep-alive connections for koji (primary and secondaries)
by Fedora Release Engineering 02 Mar '15

02 Mar '15

#5959: Enable keep-alive connections for koji (primary and secondaries) -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: meeting | Blocked By: Blocking: | -----------------------------+------------------------ Keeping connections alive will speed up koji acces when multiCall() is not used without a significant speed penalty. Therefore it is a good idea to support this. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5959> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng August 2014