#6304: ability to test spin-kickstars by doing throw away image builds in koji
-----------------------------+------------------------
Reporter: dustymabe | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
It would be nice to be able to create image builds in koji that are throw
away builds that are purely used for testing of changes to kickstart files
etc.. The idea is that we would use these as a way to test our changes
before officially commiting them to the spin-kickstarts repo.
Having this ability would mean it is much easier for contributors to test
changes and thus more likely to submit fixes and or suggestions back. We
can currently do an image build on our own machines but it does take some
setup and it is not the same environment as the one in koji. So, while we
can test on our own machines, is it a valid test? Not really.
I would love this functionality. I know it might not technically be
possible right now to do, but we shouldn't ignore its value and should
perhaps take steps to get there.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6304>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6432: Targeted rebuild of Python packages for Fedora 25
-----------------------------+------------------------
Reporter: torsava | Owner: torsava@…
Type: enhancement | Status: new
Milestone: Fedora 25 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hi!
I want to ask if it would be in any way possible to do a targeted
rebuild of Python packages for Fedora 25.
The RPM package just backported an important feature [0] that, upon
building Python packages, will automatically generate virtual Provides
with canonical name of the software from the Python Packaging Index
(PyPI), a central Python repository. And for this feature to be useful,
all Python packages need to be rebuild with the new version of RPM.
This change will significantly simplify Python packaging because the RPM
will be able to automatically figure out Python dependencies as well as
because maintainers will be able to declare dependencies using canonical
names from PyPI, just as they have been declared by the makers of the
software.
In addition it will improve functioning of the pyp2rpm tool [1] which has
the potential to greatly increase the amount of Python packages available
in Fedora as well as possibly to speed up the adoption of Python 3 among
the Fedora packages.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1340885
[1] https://github.com/fedora-python/pyp2rpm
Thank you for your time and consideration!
Tomas Orsava
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6432>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6422: f25-ghc sidetag request
----------------------+------------------------
Reporter: petersen | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
Hi RelEng,
Could you please create a Koji side tag for building ghc so that I can
build ghc-7.10.3 for F25 Rawhide?
Thanks!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6422>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6200: Cannot mirror Fedora drpms using OpenAFS
-----------------------------+------------------------
Reporter: tc01 | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: other
Keywords: meeting | Blocked By:
Blocking: |
-----------------------------+------------------------
I had (mistakenly) filed this against infrastructure:
https://fedorahosted.org/fedora-infrastructure/ticket/4798
To summarize: we'd like to run a Fedora mirror in an OpenAFS cell, but the
drpms/ directory is far larger than the 64K slot limit in OpenAFS and, as
a result, cannot mirror them.
We are currently just excluding the drpms, which works, but I'd like to be
able to mirror them if possible.
A couple of possible fixes are mentioned in the discussion on that ticket;
keeping fewer drpms, or organizing the drpms into alphabetical
subdirectories instead of one giant drpms/ directory.
How does rel-eng feel about this? Is this something that could be fixed in
some way or should we merely continue to exclude the drpms?
Thanks in advance.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6200>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6420: Hypothetical maximum speed mirroring
-----------------------------+------------------------
Reporter: tibbs | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Over the past few days I've put together something I cal quick-fedora-
mirror. It lives at https://pagure.io/quick-fedora-mirror and the
documentation there should describe how it works. But an executive
summary:
* There's a server-generated file list.
* It turns the "transferring file list" portion of a full rsync update of
fedora-buffet0 from eleven hours to a few seconds unless there has been a
large amount of updated content. In all cases except one (when the mirror
has no content at all) it is faster.
* I can poll every module in fedora-buffet0 every ten minutes and I don't
think the servers even notice. Each poll requires one rsync call to fetch
one file per rsync module, plus one to transfer everything. If there's no
changed content, the poll takes about six seconds.
* Yes, it correctly copies hardlinked content on the server as hardlinks
on the client. This works even between modules, assuming the client
actually mirrors those modules.
* It works for mirrors mirroring from other mirrors.
* It handles the bitflip and fetching files which are missing or deleted
on the client.
* The client needs only rsync and (currently) zsh. I believe it is
portable to bash4 without too much trouble. bash3 might be tough and
would need an expert. But the point is that clients don't need to have
any special software to do this.
I am looking at ways to leverage quick-fedora-mirror, fedmsg and perhaps
mirrormanager to maximize the speed at which we get content out to the
mirrors.
The first pass:
When an updated file list is generated on the master, emit a fedbus
message. I think this is easy to do. Tier 1 mirrors can just watch for
this message, sleep $((RANDOM*60/32768)) or whatever, and fire off a
transfer. They should all have, say, updated fedora updates content in
ten or fifteen minutes.
The second pass:
The server can tell mirrormanager that updated content is ready, and
mirrormanager can emit the message.
The third pass:
When a Tier 1 runs report-mirror, mirrormanager can emit a message to the
bus indicating the particular tier 1 is saying it now has updated content.
Tier 2 mirrors can listen for their upstream host (maybe even several of
them) and start their run. And so on.
I have a two-tiered system running right now. One mirror pulls from the
Fedora masters (by polling, currently) and then tickles two slave mirrors
to get the new content.
Questions:
* Does anyone see any flaws in this plan?
* Is this (i.e. fanning out new content quickly) something we would want?
* Is it reasonable for mirrormanager to do this? I know that currently
the master only informs it of new fedora/epel content, I don't know about
the other modules The master does know when they change (if only because a
cron job runs) and I don't think it would be hard to let mirrormanager
know. I don't know if mirrormanager can do anything with that
information.
* Is there any possibility of getting sufficient mirrors onboard to make
this useful? I tried to severely limit the dependencies on the client (to
a shell script, rsync, awk and the usual utilities). Even report_mirror
needs python.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6420>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6387: epel7-kde build target
---------------------+------------------------
Reporter: rdieter | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
---------------------+------------------------
kde-sig will soon begin work on bringing kde frameworks 5 to epel7, and
doing so would be much easier (avoiding ~40 manual overrides) if we had a
build target, similar to fedora's f23-kde, to make it happen.
Thanks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6387>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Following is the list of topics that will be discussed in the releng
meeting Monday at 14:30UTC in #fedora-meeting on irc.freenode.net.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2016-06-27 14:30 UTC'
Links to all tickets below can be found at:
https://fedorahosted.org/rel-eng/report/10
= New business =
#topic Move issues to pagure
= Secondary arches =
#topic Secondary Architectures update - ppc
#topic Secondary Architectures update - s390
#topic Secondary Architectures update - arm
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/rel-eng/report/10
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/rel-eng,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
#5215: Stage comps and spin-kickstarts during freezes
------------------------------+-----------------------
Reporter: adamwill | Owner: rel-eng@…
Type: task | Status: closed
Milestone: Fedora 23 Alpha | Component: git
Resolution: fixed | Keywords: planning
Blocked By: | Blocking:
------------------------------+-----------------------
Changes (by ausil):
* status: new => closed
* resolution: => fixed
Comment:
closing this ticket as I feel we have a way now to do staging and
controlled merges with pagure
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5215#comment:7>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6333: delete errant rhos-8.0-rhel-7 from erlang dist-git
----------------------+------------------------
Reporter: jeckersb | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: git
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
I accidentally pushed a rhos-8.0-rhel-7 branch to the fedora remote on the
erlang repo, and the commit hook won't let me delete it by pushing an
empty ref overtop. Please delete this branch manually (or better, tell me
how to delete it if I can do it myself!
http://pkgs.fedoraproject.org/cgit/rpms/erlang.git/log/?h=rhos-8.0-rhel-7
Thanks!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6333>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project