#3883: more meaningful error if module isn't found
by Fedora Release Engineering
#3883: more meaningful error if module isn't found
-------------------------+--------------------------------------------------
Reporter: kalev | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: |
-------------------------+--------------------------------------------------
Right now fedpkg fails with access denied message if there is not such
module:
{{{
$ fedpkg clone gtkmm30
R access for gtkmm30 DENIED to kalev
}}}
Would be nice to get a more meaningful error in that case, perhaps "module
not found".
Filing it in releng trac as the error is coming from gitolite, just being
passed along by fedpkg.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3883>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 2 months
#3759: bad distro tags in Fedora 13/x86_64
by Fedora Release Engineering
#3759: bad distro tags in Fedora 13/x86_64
-------------------+--------------------------------------------------------
Reporter: james | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
-------------------+--------------------------------------------------------
From yum repolist -v fedora ...
Repo-id : fedora
Repo-name : Fedora 13 - x86_64
Repo-revision: 1274245576
Repo-tags : binary-x86_64
Repo-distro-tags: [cpe:/o:fedoraproject:fedora:13]: rawhide
...this isn't rawhide though.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3759>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 2 months
#2244: How to mass branch s390utils and other non-primary arch packages
by Fedora Release Engineering
#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
10 years, 2 months
#4986: Create a 'Deliverables' page / SOP listing exactly what images, torrent files, signatures, checksums etc should be provided with (pre)-releases
by Fedora Release Engineering
#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
10 years, 2 months
#4149: Need a way to point EC2 instances to specific mirrors
by Fedora Release Engineering
#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
10 years, 3 months
#4963: Remove delta RPMs from Everything before release
by Fedora Release Engineering
#4963: Remove delta RPMs from Everything before release
--------------------+-------------------------------------------------------
Reporter: gholms | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: mash
Keywords: |
--------------------+-------------------------------------------------------
F15's Everything tree contains around 4G of delta RPMs that are of limited
use when the release is finalized. If they aren't necessary, I would
appreciate the extra mirror space that removing them from F16 and beyond
would free up.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4963>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
10 years, 8 months