Summary/Minutes from today's FESCo Meeting (2017-02-10)

[Justin Forbes]

===================================
#fedora-meeting: FESCO (2017-02-10)
===================================


Meeting started by jforbes at 16:00:31 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2017-02-10/fesco.2017-02...
.



Meeting summary
---------------
* init process  (jforbes, 16:01:10)

* #1672 F26 System Wide Change: Separate Subpackage and Source Debuginfo
  (jforbes, 16:05:20)
  * AGREED: Separate subpackage and source debuginfo is approved with
    the caveat that by default debuginfo subpackages "Recommends" the
    source package. (7,0,0)  (jforbes, 16:26:50)
  * AGREED: Allow the update, encourage everyone to work through the
    process better next time (7,0,0)  (jforbes, 16:51:10)
  * LINK: https://github.com/fedora-infra/bodhi/issues/1266   (nirik,
    16:52:24)

* #1674 F26 System Wide Change: Enable TRIM pass down to encrypted disks
  (jforbes, 16:54:36)
  * AGREED: System Wide Change: Enable TRIM pass down to encrypted disks
    is approved (5,2,0)  (jforbes, 17:00:38)

* #1635 F26 Self Contained Changes  (jforbes, 17:04:01)
  * AGREED: Minimal Container Image, LDC, and opensc are approved
    (+1:6,0:0,-1:0)  (jforbes, 17:12:33)
  * AGREED: make sudo pip safer is approved (+1:6,0:0,-1:0)  (jforbes,
    17:22:18)
  * AGREED: Discussion on anaconda LVM change is delayed until 2-17
    provided open questions get answered (+1:6,0:0,-1:0)  (jforbes,
    17:24:33)
  * AGREED: GNOME 3.24 is approved (+1:5,0:0,-1:0)  (jforbes, 17:26:27)
  * AGREED: Kerberos KCM credential cache by default (+1:6,0:0,-1:0)
    (jforbes, 17:32:07)

* #1678 F26 System Wide Change: Python Classroom Lab  (jforbes,
  17:32:37)
  * AGREED: Python Classroom Lab is approved (+1:5,0:0,-1:0)  (jforbes,
    17:38:43)

* #1679 F26 System Wide Change: SSSD fast cache for local users
  (jforbes, 17:38:59)
  * AGREED: SSSD fast cache for local users is approved (+1:5,0:0,-1:0)
    (jforbes, 17:42:01)

* #1680 Rebase tcpdump in Fedora 25  (jforbes, 17:42:10)
  * AGREED: tcpdump Rebase in F25 is approved (+1:5,0:0,-1:0)  (jforbes,
    17:44:23)

* #1681 Proposed Fedora 27 schedule  (jforbes, 17:44:37)
  * AGREED: jkurik's Fedora 27 schedule is approved with a removal of
    the "(not planned)' next to the rebuild (+1:6,0:0,-1:0)  (jforbes,
    17:55:22)

* Next week's chair  (jforbes, 17:58:24)
  * maxamillion to chair the 2017-02-17 meeting  (jforbes, 18:00:02)

* open floor  (jforbes, 18:00:06)
  * Mass rebuild is running currently, build queue is over 3000
    (jforbes, 18:01:46)

Meeting ended at 18:04:39 UTC.




Action Items
------------





Action Items, by person
-----------------------
* **UNASSIGNED**
  * (none)




People Present (lines said)
---------------------------
* jforbes (123)
* Pharaoh_Atem (71)
* sgallagh (68)
* dgilmore (60)
* maxamillion (56)
* kalev (47)
* nirik (41)
* Rathann (37)
* zodbot (26)
* jwb (23)
* jsmith_ (22)
* mjw (15)
* ajax (15)
* ignatenkobrain (10)
* torsava (7)
* cschalle (4)
* robclark (4)
* pviktori (3)
* jsmith (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

LVM RAID (was Re: Summary/Minutes from today's FESCo Meeting (2017-02-10))

[Chris Adams]

Once upon a time, Justin Forbes <jmforbes(a)linuxtx.org&gt; said:
>    * AGREED: Discussion on anaconda LVM change is delayed until 2-17
>      provided open questions get answered (+1:6,0:0,-1:0)  (jforbes,
>      17:24:33) 
So, not sure if this is in the "open questions", but on the mailing list
I brought up the fact that MD RAID has an automatic cron job to do
consistency checks and LVM RAID does not.  I don't see anything about
that in the change proposal, but IMHO that's a regression (and a
significant one, given studies that show undetected RAID failures are a
real thing).

I also don't know if LVM RAID can email (or otherwise notify admins)
about failures like MD RAID already does.
-- 
Chris Adams <linux(a)cmadams.net&gt;

LVM RAID (was Re: Summary/Minutes from today's FESCo Meeting (2017-02-10))

[Chris Murphy]

On Fri, Feb 10, 2017 at 12:27 PM, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Justin Forbes <jmforbes(a)linuxtx.org&gt; said:
> >   * AGREED: Discussion on anaconda LVM change is delayed until 2-17
> >     provided open questions get answered (+1:6,0:0,-1:0)  (jforbes,
> >     17:24:33)
>
>  So, not sure if this is in the "open questions", but on the mailing list
>  I brought up the fact that MD RAID has an automatic cron job to do
>  consistency checks and LVM RAID does not.  I don't see anything about
>  that in the change proposal, but IMHO that's a regression (and a
>  significant one, given studies that show undetected RAID failures are a
>  real thing). 
The cron job exists but as far as I can tell it is not doing anything
out of the box. I've never seen md scrubs happen on a schedule
automatically.

LVM does have a way to do scrubs, and it'd be fairly easy to make a
systemd timer that'd do it on a schedule. The lack of it existing or
enabled by default I'd say is not good. But as far as who's
responsibility it is? I'd say it's the GUI program that creates the
array. If a GUI program is going to get into the business of making it
easier to create arrays, then it needs to be in the business of
configuring preventative maintenance and warnings. But we don't even
have configuration for email warnings for mdadm arrays. And further
there's a rather significant kernel deficiency with SCSI command
timers being set by default to 30 seconds, which is totally contrary
to getting proper bad sector recoveries with the vast majority of
drives - whether they are in an array or not. And while the upstream
file system and md kernel developers know about this, there is an
incredible amount of resistance changing it. It's bad enough that this
often thwarts scrubs (whether mdadm, LVM, or Btrfs based).

So the net here is that there are all sorts of ways this can suck for
the uninitiated user out of the box. Is the lack of scrub happening
out of the box a problem? Yes but enabling it without fixing the
bullshit 30 second SCSI command timer default is a bigger problem, and
just enabling scrubs without fixing the timer means you end up with a
greater chance md is going to kick a drive out of the array for the
very simple problem of one bad sector, instead of fixing the bad
sector with a remap. And if we aren't getting device faulty
notifications in GNOME shell, now we're in a much net worse situation.

>  I also don't know if LVM RAID can email (or otherwise notify admins)
>  about failures like MD RAID already does. 
Nope. The monitoring works with dmeventd, but I'm not sure how
sophisticated the monitoring is or what messaging method it uses
(dbus?) or what monitors it (udisksd or storaged?). But again, the
loss of email notification is not a show stopper. I think email
notification is archaic anyway, I'd rather it support some kind of
ticketing system, reporting it all to storaged or other daemon of my
choice, where I can choose how I want to be notified: pop-up, email,
text message, tweet, light a match...etc.



-- 
Chris Murphy

LVM RAID (was Re: Summary/Minutes from today's FESCo Meeting (2017-02-10))

[Subhendu Ghosh]

On Feb 10, 2017 16:27, "Chris Murphy" <lists(a)colorremedies.com&gt; wrote:

On Fri, Feb 10, 2017 at 12:27 PM, Chris

Nope. The monitoring works with dmeventd, but I'm not sure how
sophisticated the monitoring is or what messaging method it uses
(dbus?) or what monitors it (udisksd or storaged?). But again, the
loss of email notification is not a show stopper. I think email
notification is archaic anyway, I'd rather it support some kind of
ticketing system, reporting it all to storaged or other daemon of my
choice, where I can choose how I want to be notified: pop-up, email,
text message, tweet, light a match...etc.



Light a match!

[Kevin Kofler]

Justin Forbes wrote:
>    * AGREED: Allow the update, encourage everyone to work through the
>      process better next time (7,0,0)  (jforbes, 16:51:10) 
The context:
https://pagure.io/fesco/issue/1675
#1675 Libglvnd update breaking F25
is missing there.

This is essentially giving the GNOME developers a blanket license to violate 
all Fedora policies, they can just go ahead with their policy violation, 
with only an "encouragement" to, you know, actually follow policies next 
time, maybe, if they're nice. And that even unanimously.

I expected better from FESCo!

        Kevin Kofler

[Justin Forbes]

On Feb 10, 2017 7:09 PM, "Kevin Kofler" <kevin.kofler(a)chello.at&gt; wrote:

Justin Forbes wrote:
>    * AGREED: Allow the update, encourage everyone to work through the
>      process better next time (7,0,0)  (jforbes, 16:51:10) 
The context:
https://pagure.io/fesco/issue/1675
#1675 Libglvnd update breaking F25
is missing there.

This is essentially giving the GNOME developers a blanket license to violate
all Fedora policies, they can just go ahead with their policy violation,
with only an "encouragement" to, you know, actually follow policies next
time, maybe, if they're nice. And that even unanimously.

I expected better from FESCo!


There are really no more technical road blocks in this update. There are
several advantages to having it.  To deny it at this point would be
entirely punitive. To me, that did not seem warranted at this time, though
if it is a continuing problem, it may well be the next time.

[Kevin Kofler]

Justin Forbes wrote:
>  There are really no more technical road blocks in this update. There
> are
>  several advantages to having it.  To deny it at this point would be
>  entirely punitive. To me, that did not seem warranted at this time, though
>  if it is a continuing problem, it may well be the next time. 
I don't see ANY advantage for the users of software actually in Fedora, only 
a risk of regressions. This only helps users of unsupported third-party 
blobs.

        Kevin Kofler

[Rob Clark]

On Sat, Feb 11, 2017 at 5:50 AM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Justin Forbes wrote:
> > There are really no more technical road blocks in this update. There are
> > several advantages to having it.  To deny it at this point would be
> > entirely punitive. To me, that did not seem warranted at this time, though
> > if it is a continuing problem, it may well be the next time.
>
>  I don't see ANY advantage for the users of software actually in Fedora, only
>  a risk of regressions. This only helps users of unsupported third-party
>  blobs. 
This doesn't "only" help users of unsupported third-party blobs,
although in most of the discussion that is perhaps the only feature
that is discussed.. it also:

1) introduces the new GL ABI which decouples libGL from GLX.. libGL is
still provided for backwards compat, but apps can start linking
against libOpenGL + libGLX or libOpenGL + libEGL instead (the latter
doesn't bring any GLX/X11 dependencies so useful for porting things to
wayland without dragging along unneeded/historical dependencies)

2) adds optimized generated asm dispatch functions for armv7 and armv8

(the first I mentioned on the other thread, the second I neglected to)

As a mesa developer who only ever uses the open source drivers (intel
on laptop, nouveau on desktop, and freedreno on arm), I am happy to
see the adoption of glvnd.. independent of blob drivers, it is a long
needed cleanup to how GL works on linux.

BR,
-R

[Jan Pokorný]

On 11/02/17 02:08 +0100, Kevin Kofler wrote:
>  Justin Forbes wrote:
> >   * AGREED: Allow the update, encourage everyone to work through the
> >     process better next time (7,0,0)  (jforbes, 16:51:10)
>  
>  The context:
>  https://pagure.io/fesco/issue/1675
>  #1675 Libglvnd update breaking F25
>  is missing there. 
Thanks for balancing the informational depth of the message out
(I sincerely hope it wasn't a case opportunistic obscurity).

>  This is essentially giving the GNOME developers a blanket license to
> violate 
>  all Fedora policies, they can just go ahead with their policy violation, 
>  with only an "encouragement" to, you know, actually follow policies next 
>  time, maybe, if they're nice. And that even unanimously.
>  
>  I expected better from FESCo! 
-- 
Jan (Poki)