Summary/Minutes from today's FESCo Meeting (2017-07-07)
by Justin Forbes
===================================
#fedora-meeting: FESCO (2017-07-07)
===================================
Meeting started by jforbes at 16:00:14 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2017-07-07/fesco.2017-07...
.
Meeting summary
---------------
* init process (jforbes, 16:00:14)
* #1725 F27 System Wide Change: Enable TRIM pass down to encrypted disks
(jforbes, 16:03:56)
* LINK: https://pagure.io/fesco/issue/1725 (jforbes, 16:03:57)
* AGREED: F27 System Wide Change: Enable TRIM pass down to encrypted
disks is approved (jforbes, 16:26:16)
* Many packages are not following the Guidelines for bundled libraries
(jforbes, 16:26:59)
* LINK: https://pagure.io/fesco/issue/1734 (jforbes, 16:27:19)
* AGREED: Wait two weeks for discussion on the mailing list, and then
vote (jforbes, 16:42:07)
* ACTION: maxamillion will initiate discussion on the mailing list
(jforbes, 16:42:42)
* next weeks chair (jforbes, 16:43:04)
* jforbes will chair next weeks meeting (jforbes, 16:46:02)
* open floor (jforbes, 16:46:07)
Meeting ended at 16:49:39 UTC.
Action Items
------------
* maxamillion will initiate discussion on the mailing list
Action Items, by person
-----------------------
* maxamillion
* maxamillion will initiate discussion on the mailing list
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* jforbes (52)
* maxamillion (48)
* nirik (26)
* kalev (17)
* jsmith (16)
* zodbot (11)
* dgilmore (3)
* linuxmodder (2)
* sgallagh (0)
* Rathann (0)
* jwb (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years, 10 months
F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL
by Jaroslav Reznik
= System Wide Change: Switch OpenLDAP from NSS to OpenSSL =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL
Change owner(s):
* Matus Honek <mhonek (at) redhat.com>
Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for
cypto. OpenLDAP is going to be compiled with OpenSSL, instead.
== Detailed Description ==
OpenLDAP in Fedora is has been compiled with NSS for crypto for
several years now. Support layer for NSS was added back in 2008 but
the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons
for keeping OpenLDAP compiled with NSS was to make it work with some
other packages (esp. 389DS) seamlessly. Fixing and keeping downstream
patches has become a burden, thus it was decided to switch to OpenSSL,
instead.
For more detailed description, check out Change page.
== Scope ==
* Proposal owners: write the Interception code.
* Other developers: ensure usage of OpenSSL-like TLS configuration
based on the Schedule.
* Release engineering: [1]
* List of deliverables: Not affected
* Policies and guidelines: none.
* Trademark approval: none.
[1] https://pagure.io/releng/issue/6891
Thanks,
Jaroslav
6 years, 10 months
F27 System Wide Change: Drop 256term.sh
by Jaroslav Reznik
= System Wide Change: Drop 256term.sh =
https://fedoraproject.org/wiki/Changes/Drop_256term.sh
Change owner(s):
* Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl >
Do not install /etc/profile.d/256term.sh and /etc/profile.d/256term.csh.
== Detailed Description ==
Currently Fedora installs some scripts to be executed every time a
shell is started which perform some heuristics to set $TERM based on
the terminal emulator being used. This is a work-around and it's
better to for the terminal emulator to set $TERM properly on its own.
Various terminal emulators have been updated to do that.
/etc/profile.d/256term.sh and /etc/profile.d/256term.csh will not be
installed anymore and the $TERM variable set by the terminal emulator
will be used.
[The change is trivial in and of itself. I'm making this a system wide
change, and a change at all, only because those scripts take part in
every shell startup, so it's possible they will have some unforeseen
impact or require adjustments in other components. If FESCo or
Wrangler think this does need a change page, I'm ready to drop it.]
== Scope ==
* Proposal owners: do the change in initscripts package, work with
other developers to fix any identified issues.
* Other developers: fix any identified issues
* Release engineering: [1]
* List of deliverables: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
[1] https://pagure.io/releng/issue/6885
Thanks,
Jaroslav
6 years, 10 months
[Modularity] A proposal for stream naming
by Matthew Miller
Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.
An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.
In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_st...
doesn't have any rules, so let's make one. Specifically:
* Modules which correspond primarily to a single application or
versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
use a stream label corresponding to the major version of that software
(e.g. 2.4 or 8)
* Such modules MAY additionally have a "latest" stream, which would be
"rolling release" of the latest stable version (as opposed to master,
which corresponds to rawhide and may be unstable).
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
Each such "collection" module MUST have one or both of the following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
to my dream of mixing and matching with CentOS modules....)
Additionally and for all of our sanity, I suggest:
* Valid module end-of-life dates are always either June or December,
corresponding to the Fedora schedule of early May / late October
base releases. So, f1806 or f1812, but not f1810 or f1901.
I know there is some work on stream-to-stream upgrades in modularity;
that work could take advantage of this convention.
So, we'd have:
httpd 2.4
httpd 2.6
nodejs 8
nodejs 10
sysadmin-tools latest
sysadmin-tools f1812
sysadmin-tools f1906
Does this make sense? Do you have improvements or entirely better
ideas?
I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.
With this alternate proposal, we'd have:
httpd 2.4:stable
httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
nodejs 8:f1912 (because that's upstream eol)
nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
nodejs 10:f2106 (or maybe e2012)
sysadmin-tools 1:latest
sysadmin-tools 1:f1812
sysadmin-tools 1:f1906
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 10 months
Unable to login to Wayland session on Fedora 26 Workstation
by Sumit Bhardwaj
Hi,
I am using Fedora 26 Workstation x86_64 right from the time of Alpha release, it was upgraded from Fedora 25 Workstation using dnf system upgrade.
I don't know when it happened, but today I noticed that on using any of the two sessions (Gnome or Gnome on X) from GDM, I always get an X session. I confirmed it by trying to do the Alt+F2 -> r command and shell restarted on both times, so it is confirmed that X is running.
I tried re-installing packages gdm, gnome-session, gnome-session-wayland-session, gnome-classic-session and gnome-session-xsession but the problem is still there.
On checking the .desktop files in /usr/share/xsessions, I found that for both gnome.desktop and gnome-xorg.desktop, the Exec line reads gnome-session only with no session name parameters etc. I don;t remember what should be the command lines for these, can anybody enlighten me?
Also, should this be reported as a blocker bug?
Regards,
Sumit Bhardwaj
6 years, 10 months
