#5779: Build target for tcl-8.6.1
-----------------------------+------------------------
Reporter: jskarvad | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi, could we get a separate f21 build target to build tcl-8.6.1 and
rebuild packages which depend on it? It's cca. 100 packages. We can also
do it without the tag - it will take approx. 1 to 2 weeks with various
probably minor breakages.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5779>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5362: Use XZ for repository metadata compression
-------------------------+------------------------
Reporter: elad | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------------
See [https://bugzilla.redhat.com/show_bug.cgi?id=700020 bug #700020] for
details.
I was informed that yum and createrepo already support xz compression for
metadata, yet in Fedora still use bz2. We should probably switch
repositories to use xz as well.
I was told to talk with rel-eng, I hope this is the right place to do so.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5362>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5214: Setup koji tags and repo for Docs
-----------------------------+------------------------
Reporter: crantila | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 18 Alpha | Component: koji
Keywords: docs | Blocked By:
Blocking: |
-----------------------------+------------------------
Posted here as per [https://fedorahosted.org/fedora-
infrastructure/ticket/3320]
'''phenomenon'''
To support simpler and more robust updates to docs.fp.o, need to setup
koji to handle a new tag and repo for Docs.
'''implementation recommendation'''
<Sparks> What would be required to stand up a separate instance of koji
for Docs? <dgilmore> Sparks: why would you want a seperate instance?
<dgilmore> Sparks: i dont see any valid reason to do so <Sparks> dgilmore:
For the Docs website. Publican has the ability publish documentation from
packages (separate repo from the Fedora repo) for the website. We want to
replace the git repo that operates it now. <dgilmore> Sparks: and why does
that need a seperate koji? <Sparks> The git repo has gotten HUGE and is
becoming an issue. <dgilmore> Sparks: so, why does that mean a seperate
koji instance <dgilmore> Sparks: we could use a seperate tag and targets
in koji <dgilmore> i dont see why it would need its own koji <Sparks>
dgilmore: It's either that or try to get everyone setup as packagers.
<dgilmore> Sparks: get everyone setup as packagers <Sparks> dgilmore:
Except that they really won't be packagers. <dgilmore> Sparks: though you
dont need to be a a packager to get a koji cert <dgilmore> you just need
fas <dgilmore> Sparks: what would be the workflow? <Sparks> dgilmore:
Okay, and with that we can send packages through koji and tag them
separately? <Sparks> dgilmore: Basically we just tell Publican to build
the package and submit it to koji. The Publican software does all the
work. <dgilmore> Sparks: I still really dont know what your trying to do.
pretend im an idiot(not really that hard) and explain what it is and how
it should work <Sparks> dgilmore: I'm not far off... <Sparks> dgilmore: So
Publican will make an SRPM package, submit it to koji destined for a repo.
Our Publican backend will install those packages and publish the data to
the website. <Sparks> ...as I understand it <dgilmore> Sparks: so we would
need to set up seperate tags and tagets for it, defining a koji policy
allowing srpms to be built. likely we would add a new group to koji and
add people allowed to build docs to it and limit access to the
tags/targets to people in that group <dgilmore> Sparks: so its all doable
<Sparks> dgilmore: Well that's a lot easier. :) <Sparks> dgilmore: We
already have a group in FAS for people that should have access (docs-
publishers). Should I open a ticket? <dgilmore> Sparks: koji doesnt know
anything about fas <dgilmore> Sparks: please file a ticket. We wont be
able to make changes until after f17 is done <Sparks> dgilmore: That's
fine. We're not completely ready for the transition so after F17 would be
good. <Sparks> dgilmore: Thanks!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5214>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5761: f20-kde tag/target
-----------------------------+------------------------
Reporter: rdieter | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Please create a f20-kde tag/target, so we can start building kde-4.11.1
(and future releases potentially) without endangering f20 alpha freeze.
thanks.
(I may end up doing it myself, but may need handholding to get the new arm
arch bits right)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5761>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#3624: fullfilelist changes
-------------------------+--------------------------------------------------
Reporter: mmcgrath | Owner: rel-eng(a)lists.fedoraproject.org
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: |
-------------------------+--------------------------------------------------
After each push, we need to run the following command:
rsync -r . > fullfilelist
This should overwrite the fullfilelist that's there and isn't very useful
at the moment:
http://download.fedora.redhat.com/pub/fedora/fullfilelist
We can't do this via a cron job, it has to go out after each push so it
needs to be added to those scripts.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/3624>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5757: Please create a f20-gnome side tag
-----------------------------+------------------------
Reporter: kalev | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi,
Please create a f20-gnome koji side tag and buildroot. We'll be building
GNOME 3.9.91 this week and this would help make sure to not cause F20
instabilities around the Alpha freeze.
Thanks,
Kalev
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5757>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5762: Please blacklist java-1.8.0-openjdk.i686 from multilib
-----------------------------+------------------------
Reporter: omajid | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Alpha | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The default OpenJDK package (java-1.7.0-openjdk) is blacklisted from
multilib. Please also blacklist the new version of OpenJDK
(java-1.8.0-openjdk).
Users are surprised when one OpenJDK package is available but not the
others. An example of this can be seen on
[https://bugzilla.redhat.com/show_bug.cgi?id=1001964 bug 1001964]
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5762>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5418: Adopt policy that SCM request should be accepted from authorized users only
--------------------+------------------------
Reporter: ppisar | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: git
Keywords: SCM | Blocked By:
Blocking: |
--------------------+------------------------
FESCo ticket [https://fedorahosted.org/fesco/ticket/981] moved to rel-eng
quee.
= Phenomenon
Release engineers proceed SCM request from non-authorized applicants.
= Background Analysis
spot added SCM change request for 4 packages he does not own nor co-
maintain and release engineer has processed the requests. The requests
were to create new branches owned by master owners.
Example [https://bugzilla.redhat.com/show_bug.cgi?id=835544#c7]:
{{{
From: Tom "spot" Callaway 2012-12-11 21:50:00 GMT
Package Change Request
======================
Package Name: perl-Pod-Markdown
New Branches: f16 f17
Owners: jplesnik mmaslano ppisar psabata
InitialCC: perl-sig
From: Jon Ciesla 2012-12-12 13:14:20 GMT
Git done (by process-git-requests).
}}}
This undermines regular maintainers' rights and obligations because they
cannot even be sure which branches their packages exist and which they are
responsible for. This conflicts with current policy for creating
additional branches on behalf third persons (the third person, owner of
new branch, asks current owner and current owner submits SCM request.)
= Implementation recommendation
Release engineers will accept SCM changes only from requesters who own or
co-maintaint the package.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5418>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project