======================================
#fedora-meeting-2: RELENG (2016-09-19)
======================================
Meeting started by dgilmore at 14:34:02 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-09-19/releng.
2016-09-19-14.34.log.html
.
Meeting summary
---------------
* init process (dgilmore, 14:34:05)
* init process (dgilmore, 14:38:31)
* full pagure migration (dgilmore, 14:43:26)
* will migrate tickets and get redirect in place from fedorahosted to
pagure when the showstopper bug is fixed (dgilmore, 14:46:52)
* Alternative Architectures updates (dgilmore, 14:50:04)
* s390 composes underway (dgilmore, 14:58:02)
* so far no complaints about aarch64 in koji (dgilmore, 14:58:44)
* open floor (dgilmore, 14:59:59)
* bodhi update to 2.2.0 tomorrow :D (dgilmore, 15:05:47)
* maxamillion dealling with issues with koji-containerbuild and nss
(dgilmore, 15:10:40)
Meeting ended at 15:13:48 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* dgilmore (52)
* zodbot (13)
* nirik (10)
* bowlofeggs (10)
* pbrobinson (9)
* maxamillion (8)
* mboddu (4)
* sharkcz (3)
* tyll (0)
* masta (0)
* bochecha (0)
* pingou (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
#6467: Consider splitting the ancient portions of the archive
-------------------+------------------------
Reporter: tibbs | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
-------------------+------------------------
In order to try and cut down on the amount of space on the mirrors, it
might be reasonable to consider splitting the archive module. Some of
that stuff is only of historical interest at this point, and there might
not even be any point in having it mirrored at all. (Given that we really
don't want people actually using it.)
I know that the older releases really aren't large compared with the
modern ones, but if we kept, say, only the last ten(?) releases in archive
and moved everything older off to either a "historical" rsync module or
just a separate server somewhere that isn't rsyncable, we'd save something
on the order of a terabyte, or nearly 10% of a full mirror load. Of
course, there's pretty much no churn of that content so there's no
bandwidth savings.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6467>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2016-09-19 from 09:30:00 to 10:30:00 US/Central
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Fedora Release Engineering weekly meeting
Source: https://apps.fedoraproject.org/calendar/meeting/4654/
#6480: Un-retirement of python-urllib3 for the epel7 branch
-----------------------------+------------------------
Reporter: abompard | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 25 Alpha | Component: epel
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
python-urllib3 has been retired on epel7 because RHEL/CentOS 7 ships it.
However, it only ships the Python 2.7 version. I am working on bringing
more packages to the new Python 3.4 stack in EPEL7, including this one, so
I would like to un-retire it.
I will restore the same version that is used in RHEL7/CentOS7 and change
the specfile so that the Python 2 version is not build, in order to avoid
a potential conflict with the base distro.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6480>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6473: Please create a epel7-mono side tag
----------------------+------------------------
Reporter: tpokorra | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: epel
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
Hi,
Please create a new epel7-mono side tag and build target. We'll use it for
building Mono4.2 and depending packages before submitting them to testing.
Thanks, Timotheus
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6473>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Hello all,
Currently there is a ticket filed in Taiga[0] that is lacking in
details mostly because I'm not entirely sure what all we need in there
so I wanted to start that discussion here.
The motivation behind this is that we're moving towards a future where
we are shipping content that is in the format of a Docker Layered
Image and I can imagine that we will want to include these as
installable artifacts at compose time for certain things such as
Atomic Host. An example of why we'd want that is so that on a fresh
install from the ISO image there can be a set of services and/or
applications installed without them needing to be pre-baked into the
ostree. This would hopefully allow for more flexibility with the
services and applications to be lifecycled independently of the
operating system.
There's definitely a lot of details to sort out through the entire
stack, but the concept of bringing Layered Images into the fold as
compose artifacts is something I wanted to start discussing among the
group to find out if it is needed and if so, if it's most
appropriately handled by pungi or potentially some other tool.
Thank you,
-AdamM
[0] https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-too…
#6478: Update stuck in pending state for 5 days
--------------------+------------------------
Reporter: ellert | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: mash
Keywords: | Blocked By:
Blocking: |
--------------------+------------------------
Hi!
The update https://bodhi.fedoraproject.org/updates/FEDORA-2016-c5afb50d8a
submitted for Fedora 24 testing has been in pending state for 5 days and
has not been pushed. During these days there have been several successful
mashes of fedora-24-updates-testing, and other updates submitted to this
repo after this update have already been pushed.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6478>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#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