#2244: How to mass branch s390utils and other non-primary arch packages
--------------------+-------------------------------------------------------
Reporter: toshio | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
--------------------+-------------------------------------------------------
This is a rel-eng decision that I'll need input on. Currently the
packagedb branches packages which are not blocked in koji. Some packages
which are not built for the primary arch are blocked in koji -- s390utils
for instance. Does the packagedb need to whitelist these or should the
packages be unblocked as they are discovered?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/2244>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4605: bodhi crashes with 500 internal server error when i try to remove a build
from a ticket
---------------------+------------------------------------------------------
Reporter: lennart | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
---------------------+------------------------------------------------------
Wanted to edit https://admin.fedoraproject.org/updates/selinux-
policy-3.9.16-9.fc15,systemd-22-1.fc15
and replace selinux-policy-3.9.16-9.fc15 by selinux-policy-3.9.16-10.fc15,
and i couldn't, because bodhi crashed. Regardless whether I tried to
replace -9 with -10, or just tried to remove -9.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4605>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4986: Create a 'Deliverables' page / SOP listing exactly what images, torrent
files, signatures, checksums etc should be provided with (pre)-releases
----------------------+-----------------------------------------------------
Reporter: adamwill | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
----------------------+-----------------------------------------------------
Going through the F16 QA retrospective, there's this series of linked
points from Andre Robatino:
"robatino - Alpha and Beta torrents often have unsigned checksum files -
this just happened with 16 Alpha. It also happened during F13 and F14 -
see http://lists.fedoraproject.org/pipermail/test/2010-April/090106.html
for F13 Beta, and https://bugzilla.redhat.com/show_activity.cgi?id=638738
for F14 Alpha and Beta. When it's pointed out, we're told that it's not
feasible to change them once people have started downloading, but if this
is true, there needs to be better checking (at least as much as for mirror
content, which can be changed) to make sure the torrents are correct
before being posted. Filed https://fedorahosted.org/fedora-qa/ticket/237
and https://fedorahosted.org/rel-eng/ticket/4906 . No response from releng
as of yet. Unless QA is given access prior to public posting, it is
powerless to prevent this.
robatino - Also, it's possible that the checksum files can be signed more
than once. There are two versions of the signed checksum files for F15,
one on the torrents (the original ones) and a different one on the
mirrors. See http://robatino.fedorapeople.org/checksums/15-Final/ for the
two versions - for example, Fedora-15-i386-CHECKSUM.orig and
Fedora-15-i386-CHECKSUM. While not nearly as serious as the above issue
(since the checksums are the same and both signatures are good), it could
be confusing. "
A quick mail discussion prompted the suggestion from Andre that the best
way to cover all these issues would be for there to be a Deliverables wiki
page / SOP which clearly lists all the 'bits' that should be delivered for
each image drop - Alpha, Beta, Final, TC and RC. This would provide a
simple reference for whoever's doing the build to make sure everything has
been provided.
It would make most sense for this to live in releng's wiki space, I think,
so filing against releng trac, but a QA person could certainly take care
of creating the page in theory, I think.
We should have this in place prior to F17 Alpha TC1.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4986>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5450: Joining the release engineering team
-----------------------------+------------------------
Reporter: apinnt231 | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 19 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hello,
I would like to join the release engineering team. I have exp. with system
management and deployment. I have designed a few custom applications in
c++ and php. Email me for more info.
alan.pinnt(a)gmail.com and my username is apinnt231
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5450>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#4149: Need a way to point EC2 instances to specific mirrors
--------------------+-------------------------------------------------------
Reporter: gholms | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
--------------------+-------------------------------------------------------
To get Fedora working well on Amazon's EC2 cloud computing service ![1]
the Cloud SIG is working on creating yum mirrors inside Amazon's network.
Doing so provides a number of benefits:
* Faster updates for users
* People with hundreds of Fedora instances don't overload other public
mirrors
* No data transfer costs for users or those who fund the EC2 mirrors
(traffic within a given cloud region is free)
Unfortunately, data transfers are only free if they stay within a given
region. This, combined with the fact that EC2's IP addresses freely roam
between regions, makes normal IP-based direction via !MirrorManager
impossible. We therefore need another way of directing clients toward the
mirrors that reside within their own regions.
Our list of proposed solutions to this are posted in the "Client Access"
portion of my overall proposal for EC2 mirror infrastructure ![2]. Could
you folks (a) offer any feedback, or (b) choose which solution would be
best? I apologize if this is more of a FESCo question; I can take it to
them if that would be better.
![1] https://fedoraproject.org/wiki/Features/EC2
![2]
https://fedoraproject.org/wiki/User:Gholms/EC2_Mirror_Proposal#Client_Access
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4149>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5427: Clean obsoleted packages from repositories
-----------------------------+------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
See
http://lists.fedoraproject.org/pipermail/devel/2012-December/175557.html
Packages which are obsoleted by other packages effectively can't be
installed. (They can be added by hand, but will be replaced on yum update
in the default configuration.)
If they're obsolete, we shouldn't ship them, so they should be cleaned
from the F18 (and rawhide?) trees.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5427>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5181: i686 java-1.6.0-openjdk is in x86_64 repos
-----------------------------+------------------------
Reporter: dbhole | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 17 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The x86_64 repos for Fedora 17 currently contain the i686 versions of
java-1.7.0-openjdk. These should be removed as 32-bit on 64-bit packages
are not supported atm:
http://mirrors.kernel.org/fedora/development/17/x86_64/os/Packages/j/
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5181>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project