February 2011 - rel-eng - Fedora Mailing-Lists

#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, 9 months

1
7
0 / 0

#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, 9 months

1
5
0 / 0

#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, 10 months

1
10
0 / 0

#4057: Update gitolite build

by Fedora Release Engineering

#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

11 years, 6 months

1
3
0 / 0

#3802: Symlink for latest branched and rawhide mash

by Fedora Release Engineering

#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

11 years, 6 months

1
8
0 / 0

#2025: Too hard to build dependent packages in stable

by Fedora Release Engineering

#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

11 years, 6 months

1
2
0 / 0

#4139: Fedora Hosted gitweb invalid URLs

by Fedora Release Engineering

#4139: Fedora Hosted gitweb invalid URLs -----------------------+---------------------------------------------------- Reporter: mschwendt | Owner: rel-eng(a)lists.fedoraproject.org Type: defect | Status: new Milestone: | Component: git Keywords: | -----------------------+---------------------------------------------------- https://admin.fedoraproject.org/pkgdb/acls/name/mash -> http://pkgs.fedoraproject.org/gitweb/?p=mash.git -> http://pkgs.fedoraproject.org/git/mash.git -> 404 not found Seems to affect all projects listed at http://pkgs.fedoraproject.org/gitweb/ http://pkgs.fedoraproject.org/gitweb/?p=zlib.git;a=summary -> http://pkgs.fedoraproject.org/git/zlib.git -> 404 not found -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/4139> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

11 years, 6 months

1
6
0 / 0

#4056: Update sigul systems

by Fedora Release Engineering

#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

12 years, 1 month

1
2
0 / 0

#3740: fix critpath generation to be per branch and properly import into pkgdb

by Fedora Release Engineering

#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

12 years, 3 months

1
14
0 / 0

[Fedora Release Engineering] #859: updates-newkey doesn't have group_gz member

by Fedora Release Engineering

#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

12 years, 3 months

1
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng February 2011