#6230: sign our docker images
-------------------------+------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
-------------------------+------------------------
This is a long-term task -- I just wanted to throw it somewhere. Docker
1.8 includes the ability to sign images, and we should do that.
https://blog.docker.com/2015/08/docker-1-8-content-trust-toolbox-registry-
orchestration/
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6230>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6196: Please build F22 Atomic images nightly
-----------------------------+------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
This is a followup to mailing list conversation
https://lists.fedoraproject.org/pipermail/cloud/2015-May/005351.html — see
that for some background.
In short, as per normal, F22 image builds stopped at F22 release. However,
for Atomic, we'd like to actually keep going, with new images built with
the released installer but pointing at the latest, new Atomic tree every
night.
Basically, run the same task as
http://koji.fedoraproject.org/koji/taskinfo?taskID=9832787 nightly, with
all of the same options, except use the latest Atomic kickstart in the
spin-kickstarts F22 branch.
(This would be for both fedora-cloud-atomic.ks and fedora-cloud-atomic-
vagrant.ks.)
The kickstarts will be updated to point at the correct new nightly tree.
I know there's work on a better world where this is done with Pungi 4, but
I hope we can find a quick solution which doesn't block on that.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6196>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6206: Bugzilla message used for updates
----------------------------+------------------------
Reporter: mooninite | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: bodhi bugzilla | Blocked By:
Blocking: |
----------------------------+------------------------
It is time to update the Bugzilla update message text.
# su -c 'yum update --enablerepo=updates-testing...'
to
# su -c 'dnf update --enablerepo=updates-testing...'
;)
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6206>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6218: Request to unretire python-qpid and perl-qpid packages
-----------------------------+------------------------
Reporter: irina | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
In addition, please create new package git(s) for these packages:
qpid-tools
qpid-tests
These changes should apply to master (f24) and f23 branches.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6218>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6239: blocking pidgin from EPEL-7
-----------------------------+------------------------
Reporter: mcepl | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
There is a conflict between package with src.rpm pidgin in RHEL-7 (which
provides libpurple, but not pidgin binary subpackage) and pidgin-epel
(providing binary subpackage pidgin, but not libpurple).
{{{
(15:32:59) nirik: kalev / mcepl: we now need to block the old pigdin in
epel... I can do that now.
(15:33:44) nirik: mcepl: can you file a releng ticket on that for record
keeping?
(15:44:11) mcepl: nirik: on what? On blocking pidgin or Workstation?
(15:45:22) nirik: mcepl: blocking pidgin, and https://fedorahosted.org
/rel-eng/
(15:45:39) nirik: we aren't going to add workstation, that adds it's own
bundle of problems
(15:46:49) mcepl: nirik: so effectively, RHEL/CentOS-7 users won't have
/usr/bin/pidgin? That sounds bad.
(15:47:15) nirik: huh? doesn't your pigdin-epel provide that?
(15:49:16) mcepl: my original question ... which probably got lost ...
what to do with bitlbee still not getting libpurple-devel even with
pidgin-epel being in buildroot overrie?
(15:49:41) nirik: mcepl: because nothing has changed yet until we block
the pidgin package in EPEL
(15:49:53) mcepl: see
http://koji.fedoraproject.org/koji/taskinfo?taskID=10893881
(15:51:20) dgilmore: mcepl: we have to untag all the pidgin builds
(15:51:32) dgilmore: which happens as part of the retiring
[...]
(16:10:41) kalev: nirik: what's the problem with adding workstation?
(16:12:30) nirik: it's been a long time since I looked, but as I recall it
had things like different versions of packages from server. Also, if we
build and depend on things only in workstation, some epel rpms would be
uninstallable on just server without adding workstation, etc. etc.
(16:14:40) kalev: ah yes, I can see how these can lead to problems
(16:16:20) kalev: I am not sure versions actually differ in practice;
maybe sometimes one channel gets a hotfix that the other one doesn't
(16:17:13) kalev: not entirely sure
(16:17:40) kalev: I don't want to have a situation where epel packages
replace core workstation packages though
(16:17:52) kalev: this can lead to an endless amount of trouble
}}}
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6239>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6235: Request for f24-boost side tag
---------------------+------------------------
Reporter: jwakely | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
---------------------+------------------------
Hi Boost 1.59.0 has now been released, too late for F23 (as originally
intended by https://fedoraproject.org/wiki/Changes/F23Boost159) but I
would like to upgrade rawhide to it now, and resolve any problems ASAP.
There was an f24-boost side tag created for https://fedorahosted.org/rel-
eng/ticket/6197 -- could I have that back again please?
I will do all the required rebuilds in the next 2-3 weeks.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6235>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6238: Package stuck in Bodhi on its way to Testing
----------------------+------------------------
Reporter: jsbackus | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
Hi,
I submitted a package to testing for F21, F22, and F23 on the 8/21. The
updates for F21 and F23 were pushed to testing on the 22nd, however, the
update for F22 is still waiting. Not sure if it just got lost in the
shuffle or what.
Package is lua-argparse-0.4.1-1.fc22.
Link:
https://bodhi.fedoraproject.org/updates/lua-argparse-0.4.1-1.fc22
Thanks!
Regards,
Jeff
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6238>
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 2015-08-31 from 15:30:00 to 16:30:00 UTC
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/2026/
#5886: need method for distributing urgent fixes... urgently
------------------------------+------------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: Fedora 23 Alpha | Component: mash
Resolution: | Keywords: meeting planning
Blocked By: | Blocking:
------------------------------+------------------------------
Comment (by kevin):
Sadly, alpha has come and gone... ;(
I have updated my proposal based on discussions:
https://fedoraproject.org/wiki/Urgent_updates_policy
The only outstanding questions in my mind on this are:
a) How much bodhi work will be needed.
b) if we should relax the requirements some. For example some updates are
security related, but cannot be marked as such when submitted due to
waiting for CVE, etc.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5886#comment:32>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project