#4057: Update gitolite build
----------------------+-----------------------------------------------------
Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: cvs
Keywords: |
----------------------+-----------------------------------------------------
Need to do a new gitolite build from upstream and get it into el6 and test
it on pkgs.stg then move it to pkgs. This should allow us to remove some
of our custom hacks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4057>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3802: Symlink for latest branched and rawhide mash
--------------------+-------------------------------------------------------
Reporter: jlaska | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: mash
Keywords: |
--------------------+-------------------------------------------------------
== Problem Space ==
Currently, the [http://fedoraproject.org/wiki/Critical_Path_Packages
Critical Path Packages] wiki page links to most recently branched and
rawhide critpath.txt files. However, depending on the status of the
compose/mash/pungi, or the timing of the branched schedule, these log
files may not be available. In order to eliminate confusion and 404 links
from the wiki, it would be helpful to provide a link to an ''always''
available critpath.log URL.
== Proposal ==
Create a symlink for the latest successful branched and rawhide
pungi/mash/compose. This symlink will be referenced when directing users
to the latest definition of the critical path. For example:
* http://kojipkgs.fedoraproject.org/mash/rawhide-latest ->
http://kojipkgs.fedoraproject.org/mash/rawhide-20100618/
* http://kojipkgs.fedoraproject.org/mash/branched-latest ->
http://kojipkgs.fedoraproject.org/mash/branched-20100518/
The symlink would be updated upon successful mashing of rawhide or
branched.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3802>
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
#4056: Update sigul systems
----------------------+-----------------------------------------------------
Reporter: jkeating | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
----------------------+-----------------------------------------------------
there is new python-nss stuff we should built up and look at. Might also
setup a staging environment on el6 and see if things work (better?) there.
Also need to make a change to the user environment so that v3 sigs are
preferred by default.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4056>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3740: fix critpath generation to be per branch and properly import into pkgdb
---------------------+------------------------------------------------------
Reporter: notting | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: koji
Keywords: |
---------------------+------------------------------------------------------
As I understand it, critical path generation should work like this:
{{{
* Lists are generated at rawhide, branched, or updates compose time
* These lists are synced into pkgdb for that branch
* bodhi then reads these from pkgdb
}}}
Where are we currently? For the first item, we only generate critpath
during rawhide/branched compose.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3740>
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
#4054: Add regular FTBFS handling to each cycle
-------------------+--------------------------------------------------------
Reporter: kevin | Owner: rel-eng(a)lists.fedoraproject.org
Type: task | Status: new
Milestone: | Component: other
Keywords: |
-------------------+--------------------------------------------------------
Each cycle Matt Domsch runs a mass rebuild against all fedora packages:
http://fedoraproject.org/wiki/FTBFS
Those that fail to build from source have bugs filed on them to be fixed.
After the Alpha we should orphan all packages that have FTBFS bugs that
are in "NEW" state (ie, not looked at by the maintainer). This would give
other folks a chance to pick up the package and fix it so it builds. In
the event that the package is not taken over or fixed, it would be dropped
at the same time as all the other orphans are dropped.
Timing for this should be determined and added to the rel-eng calendar and
list of tasks as well as a SOP written up to handle how to do this.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4054>
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