#6349: dist tag for SELinuxProject packages
by Fedora Release Engineering
#6349: dist tag for SELinuxProject packages
-----------------------------+------------------------
Reporter: plautrba | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hello,
I'd like to push SELinuxProject Release 2016-01-07 to Rawhide. It's
available in my COPR repository -
https://copr.fedorainfracloud.org/coprs/plautrba/selinux/ - now.
There are 8 packages which needs to be updated and they need to be built
in a given order - libsepol, libselinux, setools, libsemanage,
policycoreutils, checkpolicy, secilc, selinux-policy .
I don't want to cause problems with unsatisfied dependencies and broken
SELinux tools in Rawhide so I'd like to do it in a side tag. Could you
please prepare a tag for me?
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6349>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 7 months
Secondary arch build changes
by Josh Boyer
Hi All,
In a panel session at devconf this past weekend, Dennis mentioned some
possible plans to change how secondary architectures work. Primarily,
the builds for every arch included in a package's set would be
required to build successfully, even if the arch is a secondary arch.
However, the compose of that architecture could fail and the rest
would still be pushed. I hope I summarized that correctly.
That leaves me a bit confused. The major distinction from a
developer's perspective today is that build failures on a secondary
architecture do not fail the build on primary. The compose of a
secondary architecture is even one step further removed from their
workflow. With the proposed change, there is very much no distinction
between primary and secondary architectures for a package maintainer.
The assumption here seems to be that they can ExcludeArch a failing
architecture and then resubmit the build. That is certainly possible,
particularly with the proposed notification to the secondary
architecture maintainers helping. However, for packages which take a
significant amount of time to build in general, this is going to have
an impact. Even if we assume there is no difference between arches in
terms of build performance, waiting 3 or 4 hours for a build to fail
because a secondary arch fails is really irritating.
While it doesn't solve the overall irritation factor, I have a small
suggestion. Today, if an architecture fails to build the remainder of
the builds are immediately canceled. If this proposed change to koji
happens, I would like to suggest we not do that. Instead, I would
suggest letting all builds on the various architectures run to their
natural completion and if one fails, send a failure notification on a
per arch basis as soon as that task fails. This allows the maintainer
to verify which arches a package builds on and which it does not. If
they wish to cancel the build upon an arch failure notification, they
still can do so with koji cancel. The build as a whole could still be
failed, but only after all arch tasks are complete.
This might not seem like an issue to most packages, but I do know that
in the kernel we hit different failures on different arches at
different points in a single build quite often. E.g. a driver will
fail to build on arm and cancel the whole build early. Then perf will
fail to build on i686 but work on x86_64, which comes much later in
the build process. In a theoretical world of expanding architecture
support, I very much don't want to rinse and repeat a build any more
than is necessary. Allowing us to see how each arch fares
individually helps avoid that problem.
As an aside, I'm not fully convinced this koji change is a great idea.
ExcludeArch is the hammer that will get used most to "fix" failures,
and that isn't helping resolve the underlying issues. For things like
the kernel, gcc, or glibc, it isn't even really an option. Yes, we
can use ExcludeArch but if we do so then there is no possibility of
doing a successful _useful_ compose anyway. However, maybe it won't
be so bad. I prefer to focus on my suggested idea above for now, so
just log this paragraph as a note of caution perhaps.
josh
7 years, 7 months
#6312: Make Multidesktop ISO for Fedora Ambassadors North America
by Fedora Release Engineering
#6312: Make Multidesktop ISO for Fedora Ambassadors North America
-----------------------------+------------------------
Reporter: nb | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 23 Final | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
FAmNA decided we will produce a DVD-9 (AKA Dual Layer DVD) with
Gnome(Desktop), KDE, LXDE, XFCE, Cinnamon, and MATE-Compiz
Please create an ISO with 64 bit only of those live desktops.
We need this ASAP so we can get Fedora 23 media ordered.
Thank you.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6312>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
7 years, 7 months
Fedora Atomic Two Week Release Delay
by Adam Miller
Hello all,
Today we found an issue with the system that the Fedora Release
Engineering Two-Week Atomic Host release automation uses to query for
the latest builds that have passed testing. This is currently being
looked into and we hope to have a release out tomorrow (2016-02-10).
Apologies for any inconvenience this may have caused and thank you for
your patience while we work through this issue.
On behalf of Fedora Release Engineering,
-AdamM
7 years, 7 months