= Proposed Self Contained Change: Replace Yumex-DNF with dnfdragora =
https://fedoraproject.org/wiki/Changes/Replace_yumex-dnf_with_dnfdragora
Change owner(s):
* Björn Esser <besser82 AT fedoraproject DOT org>
* Christian Dersch <lupinix AT fedoraproject DOT org>
Replace the current alternative graphical package manager.
== Detailed Description ==
Yumex-DNF needs a replacement, since upstream stopped development[1].
With dnfdragora[2] we have a versatile (Qt, GTK and NCurses interface)
replacement.
[1] https://github.com/timlau/yumex-dnf/blob/develop/README.md
[2] https://github.com/manatools/dnfdragora
== Scope ==
* Proposal owners:
- Adjust packaging of dnfdragora to properly obsolete/provides yumex-dnf.
* Other developers:
- Adjust default package-manager of alternative desktop-evironment's
packages, if applicable.
- Make needed changes to kickstarts and/or comps.
* Release engineering:
- Merge changes to kickstarts and/or comps.
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hi everyone. The Fedora Council holds monthly video-based meetings
where we host a report from one of our various subprojects or official
objectives. This month, Langdon White presented on Modularity.
If you're a Fedora contributor busy in other areas and haven't paid
much attention, you might be wondering what Modularity is, exactly.
Modularity is an effort to address the "moves too fast! moves too
slow!" issue that affects all operating systems, and an outgrowth of
Fedora.next and a sort of descendant of the "Environments and Stacks"
part of my "Fedora Rings" proposal from 2013.
This is a really nice, easy-to-understand presentation putting forward
the goals of the initiative, the current state, and where we hope to
have it for the upcoming Fedora 26 release and Fedora 27 later this
year. If you package software in Fedora — and, particularly, something
like a language or application stack where Fedora users might benefit
from choosing between several supported versions — I really recommend
checking this out.
Video:
-----
https://youtu.be/xqZftb2Wgi4https://mattdm.fedorapeople.org/council/2017-03-22-Fedora_Council-Modularit…
* when it's done encoding — VP9 is... apparently not speedy.
Slides:
------
https://langdon.fedorapeople.org/fedora-modularity-one-goal.pdfhttps://langdon.fedorapeople.org/fedora-council-modularity-update-20170322.…
Docs site:
---------
https://docs.pagure.org/modularity/
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 26
Alpha.
The meeting is going to be held on Thursday, March 23, 2017 at 17:00
UTC. Please check the [1] link for your time zone.
In the meantime, please keep also an eye on the Fedora 26 Alpha
Blocker list [2].
For more details about this meeting please follow the [3] link.
[1] https://apps.fedoraproject.org/calendar/meeting/5517/
[2] http://qa.fedoraproject.org/blockerbugs/milestone/26/alpha/buglist
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
Thank you in advance for your support.
Regards, Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
There was an issue[1] with GCC7 during the mass-rebuild. Despite the Fedora-wide
setting of -Werror=format-security, GCC did not process its command-line
properly and an unknown number of packages were built without this flag
appropriately set. As a result, all of those packages built successfully during
the mass-rebuild, where many should in fact have reported compilation errors and
been rejected.
As part of the modular builds that the Base Runtime is performing, we need to
rebuild all packages that are going into the base runtime (as well as the set of
packages required to self-host the base runtime). Because GCC has been updated
to properly handle the CLI arguments, somewhere between two and three dozen
packages now throw errors on building.
Because we are under time-constraints, Petr Šabata and myself will be using our
provenpackager privileges to apply patches to these packages without waiting for
maintainer correspondence. The patches will be very simple, as the fix for this
issue will be in most cases the equivalent of replacing printf(variable) with
printf("%s", variable)
In very rare cases where the fix is non-obvious, we may take the short-term
solution of setting -Wno-format-security for that package and open a Bugzilla
for the maintainer to fix it properly (or engage upstream to do the same).
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 26
Alpha Release Readiness Meeting meeting.
The meeting is going to be held on Thursday, March 16, 2017 at 19:00
UTC. Please check the [1] link for your time zone.
We will meet to make sure we are coordinated and ready for the Alpha
release of Fedora 26. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.
You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.
For more information please check the [2] link.
[1] https://apps.fedoraproject.org/calendar/meeting/5306/
[2] https://fedoraproject.org/wiki/Release_Readiness_Meetings
Thank you for your support,
Regards, Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Join us on irc.freenode.net in #fedora-meeting-2 for this important
meeting, wherein we shall determine the readiness of the Fedora 26
Alpha.
The meeting is going to be held on Thursday, March 16, 2017 at 17:00
UTC. Please check the [1] link for your time zone.
Before each public release Development, QA and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is called the Go/No-Go Meeting. Verifying that
the Release criteria are met is the responsibility of the QA Team.
Release Candidate (RC) availability and good QA coverage are
prerequisites for the Go/No-Go meeting. If you have any bug on the
list, please help us with Alpha release. If we won't be ready by
Thursday, we will use this meeting to review blockers and decide what
to do.
In the meantime, please keep also an eye on the Fedora 26 Alpha
Blocker list [2].
For more details about this meeting please follow the [3] link.
[1] https://apps.fedoraproject.org/calendar/meeting/5305/
[2] http://qa.fedoraproject.org/blockerbugs/milestone/26/alpha/buglist
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting
Thank you in advance for your support.
Regards, Jan
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic