#1107: auto-cleanup rawhide trees
-------------------------+--------------------------------------------------
Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: koji
Keywords: |
-------------------------+--------------------------------------------------
Rawhide tree expiry is manual at the moment, unless I missed something.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/1107>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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
#2025: Too hard to build dependent packages in stable
-------------------------+--------------------------------------------------
Reporter: hadess | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: koji
Keywords: |
-------------------------+--------------------------------------------------
It's too complicated, human-dependent, and time-consuming to build
interdependent package updates in stable releases.
Two cases:
* gstreamer and gstreamer-plugins-base are released at the same time, and
so are pre-releases of those. They soft-depend on each other (gstreamer
can be updated on its own). It's currently not possible for me to offer
both pre-releases of gstreamer and gsteamer-plugins-base without either:
1. asking for a package to be tagged into the build roots
2. pushing gstreamer into stable (takes a few days at best), and push the
gstreamer-plugins-base package separately
* gnome-bluetooth and gnome-phone-manager, where I need to ask for gnome-
bluetooth to be pushed into the buildroot tree. Sometimes that just
doesn't work (as could have been seen in
http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7140 /
https://fedorahosted.org/rel-eng/ticket/1945 and
http://koji.fedoraproject.org/koji/buildinfo?buildID=112091 )
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/2025>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#859: updates-newkey doesn't have group_gz member
-------------------------------------+--------------------------------------
Reporter: james(a)fedoraproject.org | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
-------------------------------------+--------------------------------------
I assume the createrepo instance that generates the Fedora 9 updates-
newkey/updates-testing-newkey is the RHEL-5 version?
Can we change this to be the Fedora 9 version so that we'll get group_gz
as well as group (ie. comps.xml.gz as well as comps.xml). This makes for
much less data to download, to get group information.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/859>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3565: Please Tag libproxy-0.3.1-4.fc13 for F-13 Beta - default install of
libproxy modules
----------------------------+-----------------------------------------------
Reporter: kwizart | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: Fedora 13 Beta | Component: koji
Keywords: |
----------------------------+-----------------------------------------------
Hello,
I request libproxy-0.3.1-4.fc13 to be tagged as F-13 Beta.
This is the last update before the ABI change of the 0.4.0 version that
has already appeared in F-14.
Here is the Changelog between 0.2.3 and 0.3.1:
http://code.google.com/p/libproxy/source/browse/trunk/ChangeLog
On a side note, installing libproxy on a default desktop install of F-13
Alpha will, lead to have:
libproxy
libproxy-bin
libproxy-python
With this package, the default will lead to have:
libproxy
And that will be all, as all unneeded dependencies have been dropped as
described in:
https://bugzilla.redhat.com/show_bug.cgi?id=537569
Once that said, it would be more valuable to have libproxy-gnome installed
as soon as the gnome desktop is selected on install. (1)
Upstream advice is to use Rpm's 'Suggests' instead of 'Requires', as
requires would imply some circle dependencies.
But we don't use Suggests much if possible. So I think it would be better
handled by comps for now.
(1)
Same for:
libproxy-kde and KDE desktop
libproxy-mozjs and firefox
libproxy-webkit and WebKit-gtk
libproxy-networkmanager and NetworkManager
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3565>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3507: Secondary arche only packages need to be unblocked in primary arch koji
---------------------+------------------------------------------------------
Reporter: ausil | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: meeting |
---------------------+------------------------------------------------------
Blocking secondary arch only packages causes two issues
1) they do not get branched at mass branch time
2) they get blocked in secondary arches when they sync blocked packages
I recommend that we unblock them on the primary arches.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3507>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3561: metadata_expire=7d in branched Fedora repo files
---------------------+------------------------------------------------------
Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org
Type: defect | Status: new
Milestone: | Component: other
Keywords: |
---------------------+------------------------------------------------------
We put:
metadata_expire=7d
in the 'main' fedora repo files. This works great with the release tree,
as it doesn't change. This doesn't work well with the branched repo,
however, as we push it every day.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3561>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3239: deltarpm missing for eclipse update (F12) - 3.5.1-20 => -21
--------------------+-------------------------------------------------------
Reporter: bbaetz | Owner: rel-eng(a)lists.fedoraproject.org
Type: defect | Status: new
Milestone: | Component: other
Keywords: |
--------------------+-------------------------------------------------------
An update to eclipse was pushed today, however the eclipse packages don't
have the appropriate drpms available.
A drpm is available from the 'base' eclipse-jdt-3.5.1-4.fc12, but not from
the last update to -20
(https://admin.fedoraproject.org/updates/F12/FEDORA-2009-11860)
For example, I had eclipse-jdt-3.5.1-20.fc12.x86_64.rpm installed.
/fedora/linux/updates/12/x86_64/drpms/ on my local mirror has eclipse-
jdt-3.5.1-4.fc12_3.5.1-21.fc12.x86_64.drpm but no other relevant file.
I can generate a drpm locally using makedeltarpm, and apply it to the koji
(unsigned) -20 package to get an identical package. This means that I have
to download a 24M package rather than a 94k drpm. (Similarly for the 27M
eclipse-platform package)
Some packages (eg NetworkManager) do have a drpm from both the initial
version and the previous updated version.
I've seen this happen before (missing drpm) with other packages (internet
caps in .au means I notice large package updates), but haven't previously
looked into why.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3239>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#2555: handle invalid build ID in sigulsign_unsigned
----------------------+-----------------------------------------------------
Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org
Type: defect | Status: new
Milestone: | Component: other
Keywords: |
----------------------+-----------------------------------------------------
Right now the whole process dies if one of the n-v-rs don't match. We
should handle that better.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/2555>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project