rel-eng October 2014

rel-eng@lists.fedoraproject.org

16 participants
143 discussions

#5218: block httpd-devel.i686, php-devel.i686 from x86_64 compose
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5218: block httpd-devel.i686, php-devel.i686 from x86_64 compose -----------------------------+------------------------ Reporter: jorton | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Could the .i686 packages for both httpd-devel and php-devel be blocked from inclusion in the x86_64 compose, we don't (can't/won't) support them biarch. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5218> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 2

#5215: Stage comps and spin-kickstarts during freezes
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5215: Stage comps and spin-kickstarts during freezes -----------------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: git Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As noted on the F17 QA retrospective by me and Bruno Wolff: https://fedoraproject.org/wiki/Fedora_17_QA_Retrospective it's a problem that we use git master of both comps and spin-kickstarts for composes - not the latest packaged version - and both these git repos are not frozen during freezes. During the 17 cycle, we had a concrete example of a comps change during a freeze causing considerable trouble: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=807879 - pulling Boxes into comps during the Beta freeze made that issue a serious problem. For spin-kickstarts, the same kind of thing is possible, and we also have a release criterion requiring a spin-kickstarts package which matches the .ks files used for the compose to be present in the release repository; obviously, the lack of a git freeze makes this tricky to ensure. So we would strongly recommend, at minimum, a mechanism for freezing spin- kickstarts and comps at Alpha, Beta and Final freeze. Post-freeze changes could be made following the same blocker/NTH process used for other post- freeze changes. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5215> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5971: kojipkgs shows a 403 error instead of 404 error for deleted scratch build RPMS
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5971: kojipkgs shows a 403 error instead of 404 error for deleted scratch build RPMS -----------------------------+------------------------ Reporter: till | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 20 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ This can currently be seen with https://kojipkgs.fedoraproject.org/work/tasks/507/7190507/libreport- plugin-logger-2.2.3-1.rhbz1122690.1.fc20.x86_64.rpm: {{{$ curl -I https://kojipkgs.fedoraproject.org/work/tasks/507/7190507 /libreport-plugin-logger-2.2.3-1.rhbz1122690.1.fc20.x86_64.rpm HTTP/1.0 403 Forbidden Date: Tue, 19 Aug 2014 17:31:13 GMT Server: Apache/2.2.15 (Red Hat) Content-Type: text/html; charset=iso-8859-1 X-Cache: MISS from kojipkgs02.phx2.fedoraproject.org X-Cache-Lookup: MISS from kojipkgs02.phx2.fedoraproject.org:80 Via: 1.0 kojipkgs02.phx2.fedoraproject.org (squid/3.1.10) Connection: keep-alive }}} -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5971> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#5223: F18 TODO: automate torrent generation
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5223: F18 TODO: automate torrent generation -----------------------------+------------------------ Reporter: ausil | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Torrent Releases Infrastructure SOP http://torrent.fedoraproject.org/ is our master torrent server for Fedora distribution. It runs out of ServerBeach. Contact Information Owner: Fedora Infrastructure Team Contact: #fedora-admin, sysadmin-torrent group Location: ibiblio Servers: torrent.fedoraproject.org Purpose: Provides the torrent master server for Fedora distribution Torrent Release When you want to add a new torrent to the tracker at http://torrent.fedoraproject.org you need to take the following steps to have it listed correctly: 1. login to torrent.fedoraproject.org. If you are unable to do so please contact the fedora infrastructure group about access. This procedure requires membership in the torrentadmin group. 2. upload the files you want to add to the torrent to torrent.fedoraproject.org:/srv/torrent/new/$yourOrg/ 3. use sha1sum and verify the file you have uploaded matches the source 4. organize the files into subdirs (or not) as you would like 5. run /srv/torrent/new/maketorrent [file-or-dir-to-torrent] ([file-or-dir-to-torrent]) to generate a .torrent file or files 6. copy the .torrent file(s) to: /srv/torrent/www/torrents/$yourOrg/ 7. cd to /srv/torrent/torrent-generator/ or /srv/torrent/spins- generator/ (depending on if it is an official release or spins release) 8. add a .ini file in this directory for the content you'll be torrenting. we use fedora-torrent-ini.py from fedora releng git repo to generate it 9. mv all files from /srv/torrent/new/$yourOrg into /srv/torrent/btholding/ - this includes the files you uploaded as well as the .torrent files you've created. Your files will be linked on the website and available on the tracker after this. $yourOrg is one of fedora or spins this all needs to be setup to be done via a single script. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5223> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 4

#5332: [RFE] Generate .composeinfo for Fedora secondary arches
by Fedora Release Engineering 29 Apr '15

29 Apr '15

#5332: [RFE] Generate .composeinfo for Fedora secondary arches -----------------------------+------------------------ Reporter: bpeck | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 18 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Please generate a .composeinfo for secondary arches. The secondary arches that we are interested in are: arm, ppc, and s390. Ideally we could get a .composeinfo when *all* these arches are complete. But I understand that they have different time schedules and may update at different times. Worst case we look to see if the datetime on the file changes and we can re-import again with the newly added arch. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5332> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

1 1

#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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng October 2014