date:20180601

On Fri, Jun 1, 2018 at 11:55 AM, Daniel P. Berrangé 
 wrote:
Yeah if you add the gnutls-glib-networking.config file in the RPM, 
that

defeats the point IMHO, as it'll never fallback to use @SYSTEM if this
file always exists with @GLIBNETWORKING defined in it.

The idea of the mechanism was that apps/libs build with @MYNAME,SYSTEM
priority but never define @MYNAME themselves, so it gives the local
sysadmin to customize the app/lib in isolation if they so wish, but
out of the box still respects @SYSTEM.


If @SYSTEM is changed as proposed, then glib-networking must not 
out-of-the-box respect @SYSTEM, because it needs to out-of-the-box 
work. :) So I guess we should just not use @SYSTEM then, yes?


I wonder what Tomas intends here.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UXJ6VAWQPN35HUHUCES4DKOQL32LWI5Y/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Chris Murphy

On Thu, May 31, 2018 at 10:53 AM, Matthew Miller
 wrote:
> On Thu, May 31, 2018 at 09:08:28AM -0400, Colin Walters wrote:
>> > I'm working on improving the Fedora boot experience, with the
>> > end goal being a user pressing the on button and then going
>> > to the graphical login manager without him seeing any
>> > text messages / menus filled with technical jargon.
>> Seems like this is implictly saying "Fedora" to mean (classic) "desktop", but
>> we have different editions now.   Further, one of those editions,
>> Atomic Host, has fully transactional updates via rpm-ostree that are 
>> reflected
>> in the bootloader order today - it's not just the kernel.  And we like that 
>> feature =)
>
>
> +1 -- I think we would probably also want the menu by default on
> server. (Although, conversely, it's pretty useless in cloud
> environments where there isn't an interactive console.)


Ironically, server, cloud, and VMs all benefit the most from the
feature. VMs are the least likely to run into kernel related
regressions, followed by bare metal servers. Workstation is more
likely. And maybe ARM and IoT related products even more likely (I'm
basing that on the much wider assortment of hardware, less
standardization, very active development, and less testing coverage).



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IDZFPHFRAL4JNP7EDBW2OD66CJSAEPHN/

Re: Can't fork in src.fedoraproject.org

2018-06-01 Thread Christopher

On Fri, Jun 1, 2018 at 5:35 AM Pierre-Yves Chibon 
wrote:

> On Wed, May 30, 2018 at 07:25:41PM -0400, Christopher wrote:
> >When I try to fork rpms/thrift, I get the error message:Â Repo
> >"forks/ctubbsii/thrift" already exists.
> >
> >However, it clearly does not exist. It is not listed
> >atÂ https://src.fedoraproject.org/user/ctubbsiiÂ , which shows 0
> forks.
> >
> >Perhaps I forked it in the past, and the delete did not get cleaned up
> >correctly? I don't know.
>
> That is basically it, the git repo still existed on disk so it couldn't
> create
> the new one.
>
> I nuked the one on disk and you should be able to fork rpms/thrift again :)
>
>
I think the problem might go deeper than that. I just tried again and got
the same error. I wonder if this failure (whatever caused it) created stuff
on disk again.


>
> Sorry for the inconvenience and the late reply, I was afk yesterday.
>
>
Not a problem. No rush.


> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/342JLX5LVZY4K5RLAODF6XKS2EQONQXF/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/STTUGERLVR2UJYIYZHG6UFM3JP4LRW4Y/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Peter Jones

On Thu, May 31, 2018 at 05:47:36PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 31-05-18 15:20, Robert Marcano wrote:
> > On 05/31/2018 06:52 AM, Hans de Goede wrote:
> > > ...
> > > This will basically get us back the F28 behavior of showing the
> > > menu but only after a failed boot, I think that is a good
> > > solution, do you agree?
> > 
> > What is the definition of a successful boot? I ask because a machine
> > could boot perfectly, and when you try to interact with it on the
> > login screen, bugs on the display driver can change the screen to
> > garbage (I have seen this kind on bug long time ago), or lockup. So,
> > the user will be unable to activate any kind of restart with menu
> > enabled in order to try an older kernel, or boot to rescue mode.
> > 
> > I think instead of only detecting a successful boot, a machine that
> > wasn't properly shutdown should enable the menu
> 
> A broken install may still shutdown properly after the using pressing
> the power-button and/or trying ctrl+alt+del.
> 
> But this is an interesting suggestion, I think we should track both
> separately, so successful shutdown and successful boot and show the
> menu if either one is not true. That should make the chance of not
> being able to get the menu a lot smaller.

In my mind, the mechanism here looks like what I've sketched out below,
and I think it encapsulates the above as well as most of what I've seen
on this thread already.

The workflow is something like this:

- user updates the OS[0]
  - we automatically set the new OS to be booted /once/.
- we have a successful-boot-test.service that depends on [getty.target
  or graphical.target].  Upon starting, it sets a timer for some
  relatively long amount of time, like say 5 minutes, and at the end of
  that time it decides if booting worked and sets some state to let us
  know.
  - we also provide a tool for an admin to set a specific state, since
they know best.
- if a user logs in and starts doing stuff before the timer expires,
  we booted successfully, and we set the new OS to be default and mark
  it as having succeeded.
- if the machine is rebooted *unexpectedly*[1] without any successful
  login before the timer expires, we reboot and get the previous OS, and
  we can detect that it failed during that boot and take whatever
  appropriate action
- if the timer expires without user activity, or if there's an
  expected intermediate reboot we need to do, it's indeterminate if it
  worked or not; we set the one-shot again[5].
  - in the case where it's an expected reboot, we re-set the count of
how many times we've reached the indeterminate state
  - otherwise we add one to the count
  - if the count is above some threshold (say 3) in some amount of time
(say a day), set a one-shot variable that says to show the menu.
  - on server[2] we're going to want some indicator of "is successfully
doing it's job" instead of login; that's probably a separate
feature.
  - It probably is worth having the power button be an indicator of how
we shut down, and make that be a reason to show the menu, at least
in some cases, if you haven't done things like gone into settings
and told the power button to do nothing.

And then concerning the actual menu+countdown (or more importantly, when
to probe for the keyboard), we don't show the menu or probe for key
state unless one of the following is the case:

- a persistent grub environment variable that says /not/ to show the
  menu is /absent/ or set to false.  (i.e. the user or some install
  class[3] disabled this feature, or if grubenv has been corrupted, or
  if we're on an architecture that insists on not having nice things[4],
  etc.)
- a one-shot grub environment variable, that says to show the menu, is
  set to true.  (i.e. user asked for the menu when they rebooted the
  machine)
- indeterminate boot count is > 1
- the previous boot is not marked as indeterminate or success

[ 0] I'm being deliberately vague here because I think I mean "updates
 stuff that runs between (inclusively) the bootloader and
 [getty.target, graphical.target]" for the traditional OS, and not
 exactly the same criteria for Atomic, but both can reasonably be
 captured in one description.
[ 1] There are cases like if we do an selinux relabel during boot and
 then reboot the machine, or other situations analogous to that,
 where the reboot is known to be unrelated to the success or failure
 of the update.
[ 2] We could reasonably ship this enabled on workstation+desktop+laptop
 environments with servers disabled until there's some less
 wishy-washy description here.  Despite what mattdm said above in
 this thread, I think ultimately we do want it on server, even
 though we care less about flicker-free booting there - the
 countdown and probing aren't an insignificant chunk of the boot
 time, and the time it takes to reboot can come to dominate
 downtime.
[ 3] See [2]

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Jason L Tibbitts III

> "TK" == Tomas Kovar  writes:

TK> - this one is on the polish side of things:
[don't keep bouncing to text mode]

I might also add that as part of this, we'd also need to get rid of the
very early message about EFI secure boot being enabled.  Then we'd be
left only with the random kernel message spew that some machines have
just before X starts up.  (For me it's usually something complaining
about ACPI tables or somesuch.)  But I'm sure Hans has already thought
of all of that.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSXVCVYM2V7B43L6CXR26WPSM5TV3RWW/

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 01, 2018 at 11:49:51AM -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 10:34 AM, Daniel P. Berrangé 
> wrote:
> > IIUC,  glib-networking uses GNUTLS. If so, a while ago I added ability
> > to
> > specify an ordered list of named priority aliases to GNUTLS that might
> > handle
> > the kind of scenario you describe.
> > 
> > https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/
> > 
> > eg in libvirt we now use the string  "@LIBVIRT,SYSTEM" in Fedora builds
> > which
> > tells GNUTLS to find the policy "LIBVIRT" and if that is not present,
> > fall
> > back to the "SYSTEM" policy.
> > 
> > We do this so libvirt respects system policy by default, but admins can
> > then set an alternative system wide policy for libvirt connections that
> > uses something stricter (or weaker), without affecting TLS usage for
> > non-libvirt connections. We've done the same for QEMU which
> > "@QEMU,SYSTEM"
> > as its default policy now, for VNC and its other TLS services.
> 
> OK... so we could add a @GLIBNETWORKING,SYSTEM policy, I suppose, and
> install a file /etc/crypto-policies/local.d/gnutls-glib-networking.config.
> The difference is that file would need to be packaged, not controlled by the
> system administrator. Seems almost like an abuse of a local.d?

Yeah if you add the gnutls-glib-networking.config file in the RPM, that
defeats the point IMHO, as it'll never fallback to use @SYSTEM if this
file always exists with @GLIBNETWORKING defined in it.

The idea of the mechanism was that apps/libs build with @MYNAME,SYSTEM
priority but never define @MYNAME themselves, so it gives the local
sysadmin to customize the app/lib in isolation if they so wish, but
out of the box still respects @SYSTEM.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O6DJNBJYYNN2CLDZIOTZMK7OZVN3OJBA/

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 1, 2018 at 10:34 AM, Daniel P. Berrangé
wrote:
IIUC, glib-networking uses GNUTLS. If so, a while ago I added
ability to
specify an ordered list of named priority aliases to GNUTLS that
might handle

the kind of scenario you describe.

https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/

eg in libvirt we now use the string "@LIBVIRT,SYSTEM" in Fedora
builds which
tells GNUTLS to find the policy "LIBVIRT" and if that is not present,
fall

back to the "SYSTEM" policy.

We do this so libvirt respects system policy by default, but admins
can
then set an alternative system wide policy for libvirt connections
that

uses something stricter (or weaker), without affecting TLS usage for
non-libvirt connections. We've done the same for QEMU which
"@QEMU,SYSTEM"

as its default policy now, for VNC and its other TLS services.

OK... so we could add a @GLIBNETWORKING,SYSTEM policy, I suppose, and
install a file
/etc/crypto-policies/local.d/gnutls-glib-networking.config. The
difference is that file would need to be packaged, not controlled by
the system administrator. Seems almost like an abuse of a local.d?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IVHDIPPI4BNACLRQS6TKJ5LA5QT4KMSJ/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Rex Dieter

Michael Watters wrote:

> What about users that don't use a graphical login manager?  Personally I
> *like* seeing boot messages so that I know what is going on.
> 
> Having the menu available is also quite useful for booting into rescue
> mode or selecting a different kernel.

Note, this is all about defaults.  If *you* like something, you can always 
modify the configuration to bring it back.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IWCYXCVAFNQB7DBKYDNYJLHD3PGXLPZ4/

Re: Hiding the grub menu by default on single OS installs

On Thu, May 31, 2018 at 12:23:35PM +0200, Hans de Goede wrote:
> Hi All,
> 
> I'm working on improving the Fedora boot experience, with the
> end goal being a user pressing the on button and then going
> to the graphical login manager without him seeing any
> text messages / menus filled with technical jargon.
> 
> IIRC we used to hide the grub-menu by default on single
> OS installs, but we seemed to have stopped doing that,
> for new Fedora 29 installs I would like us to start
> hiding the menu by default on single OS installs again,
> see:
> 
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
> 
> The goal if this email is to:
> 1) Give people an advance warning about the plan to change
> this so we can discuss this early on
> 
> 2) See if anyone knows why we stopped doing this, I think
> we may simply have stopped doing this to simplify to bootconfig
> code in anaconda and because we did not always identify the
> single OS case correctly, but I wonder if there were other
> reasons?

I vaguely recall we lost the hidden menu feature during the
grub1 -> grub2 transition, but it has been so long I can't
be sure.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UZSISMCLMOUVWOCN6NINEWWFP4HPRIHQ/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Michael Watters

Well said.  Seems like Fedora is slowly turning into Fisher Price My
First Linux instead of being a distro that actually respects its users. 
IME people that run Fedora usually know what they're doing and trying to
obfuscate and hide things simply makes the distro *harder* to use.


On 06/01/2018 12:52 AM, Kyle Marek wrote:
> I think going through this effort to shave a few seconds off of the boot
> time is just going to make everything harder *especially* when the shit
> hits the fan... I don't think it's worth perpetuating the
> Windows-ification of Fedora, either.
>
> Regards,
>
>     Kyle
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CZ2QOYTYAVBYWGRU5Q2WWFD54VNIHVEJ/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DGHN5MGVVJLXLJVUWQELFFZBYNZJP54C/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Michael Watters

What about users that don't use a graphical login manager?  Personally I
*like* seeing boot messages so that I know what is going on.

Having the menu available is also quite useful for booting into rescue
mode or selecting a different kernel.


On 05/31/2018 06:23 AM, Hans de Goede wrote:
> Hi All,
>
> I'm working on improving the Fedora boot experience, with the
> end goal being a user pressing the on button and then going
> to the graphical login manager without him seeing any
> text messages / menus filled with technical jargon.
>
> IIRC we used to hide the grub-menu by default on single
> OS installs, but we seemed to have stopped doing that,
> for new Fedora 29 installs I would like us to start
> hiding the menu by default on single OS installs again,
> see:
>
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
>
> The goal if this email is to:
> 1) Give people an advance warning about the plan to change
> this so we can discuss this early on
>
> 2) See if anyone knows why we stopped doing this, I think
> we may simply have stopped doing this to simplify to bootconfig
> code in anaconda and because we did not always identify the
> single OS case correctly, but I wonder if there were other
> reasons?
>
> Regards,
>
> Hans
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ILRC44ESGWKWZ6DNOCTK4KPQGVIQY5AM/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EB7R5RYWJR3PUUKRJ26YYQRTGMBTPGC4/

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 01, 2018 at 10:25:42AM -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé 
> wrote:
> > What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
> > ie how likely is this to break the ability of users to access websites
> > they care about ?
> 
> Yeah... this has been discussed on this list before. If this change is made,
> then we will need to drop our glib-networking patch that causes
> glib-networking to respect Fedora's system crypto policy, since we simply
> cannot afford to be more restrictive than major browsers. I believe the
> system crypto policy developers should consider how this is really intended
> to work, because there's no point in having a system policy if software
> stops using it.
> 
> It could be doable if glib-networking was able to specify a priority string
> like @SYSTEMLEGACY insetad of just @SYSTEM, but the current design of the
> system crypto  policy prevents applications from choosing between the three
> policies.

IIUC,  glib-networking uses GNUTLS. If so, a while ago I added ability to
specify an ordered list of named priority aliases to GNUTLS that might handle
the kind of scenario you describe.

  
https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/
  
eg in libvirt we now use the string  "@LIBVIRT,SYSTEM" in Fedora builds which
tells GNUTLS to find the policy "LIBVIRT" and if that is not present, fall
back to the "SYSTEM" policy.

We do this so libvirt respects system policy by default, but admins can
then set an alternative system wide policy for libvirt connections that
uses something stricter (or weaker), without affecting TLS usage for
non-libvirt connections. We've done the same for QEMU which "@QEMU,SYSTEM"
as its default policy now, for VNC and its other TLS services.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EXNUSAZ4VQTKDUDTX7DOYVO3ZLLK2ML6/

Re: F29 System Wide Change: Strong crypto settings: phase 2

On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé 
 wrote:

What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
ie how likely is this to break the ability of users to access websites
they care about ?


Yeah... this has been discussed on this list before. If this change is 
made, then we will need to drop our glib-networking patch that causes 
glib-networking to respect Fedora's system crypto policy, since we 
simply cannot afford to be more restrictive than major browsers. I 
believe the system crypto policy developers should consider how this is 
really intended to work, because there's no point in having a system 
policy if software stops using it.


It could be doable if glib-networking was able to specify a priority 
string like @SYSTEMLEGACY insetad of just @SYSTEM, but the current 
design of the system crypto  policy prevents applications from choosing 
between the three policies.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A64V3LCMZALUDK4BFBKIXTEG2QC3EZVM/

Re: Firefox with native Wayland backend at updates

On Fri, Jun 1, 2018 at 7:23 AM, Martin Stransky  
wrote:

Okay and can I apply somewhere for that?


You could apply by creating an issue here:

https://pagure.io/fedora-workstation/issues

Still, I'm not likely to vote in favor, myself. If you're not satisifed 
with adding a new action to the desktop file, I would subpackage it so 
that testers can install a new subpackage to get the experimental 
desktop file. That way it should be easy for testers to opt-in, without 
making the rest of our users guinea pigs.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QSQKHNT2VI6BUNZD3YSIZWBU2LJXLWGP/

Schedule for Friday's FESCo Meeting (2018-06-01)

2018-06-01 Thread Dennis Gilmore

Following is the list of topics that will be discussed in the
FESCo meeting Friday at 15:00UTC in #fedora-meeting on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-06-01 15:00 UTC'


Links to all issues below can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #1893 Non-responsive maintainer for libinvm-i18n,libinvm-cli,
libinvm-cim
.fesco 1893
https://pagure.io/fesco/issue/1893

= New business =

#topic #1901 F29 System Wide Change: Perl Move to MetaCPAN
.fesco 1901
https://pagure.io/fesco/issue/1901

#topic #1899 F29 System Wide Change: Move /usr/bin/python into a
separate package
.fesco 1899
https://pagure.io/fesco/issue/1899

#topic #1898 F29 System Wide Change: The tzdata transition to
'vanguard' format
.fesco 1898
https://pagure.io/fesco/issue/1898

#topic #1897 F29 System Wide Change: Perl 5.28
.fesco 1897
https://pagure.io/fesco/issue/1897


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EGUMR4VQWGIKCTAUXY642AHRTUBQV4QO/

Re: Hiding the grub menu by default on single OS installs

On 06/01/2018 10:29 AM, David Sommerseth wrote:
> 
> So the menu could look something like
> 
> -
>   Fedora
>   Recovery options
>  |`- Fedora (older kernel, 4.13.0-103)
>  |`- Fedora (older kernel, 4.14.5-300)
>  |`- Fedora (older kernel, 4.15.3-304)
>  \-- System recover mode (expert)
> -

%s/Fedora/Fedora %version/ and I like it better.

However, I think this is trending away from the
'don't show/allow grub menu with single kernel'
patch discussion> 
-- 
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOAEHJZT5AANVJCHJ7FF6TJB4K4XQP3C/

Re: Hiding the grub menu by default on single OS installs

On 06/01/2018 04:04 AM, Hans de Goede wrote:
> 
> For F30, single OS Fedora Workstation install install we get:
> 
> 1) grub menu not shown, 0 second timeout, no way to get to the menu
^

This scares me and I would not like to see it implemented.

What is the impetus for this change?  What outside
requests are satisfied by it?  Or is this from internal
developer opinions and discussions with no input from
end users?  (*Not* meant as an insult!)
-- 
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PM6LDIVZLCZNRU4YR35STE7GHJMBL6MI/

Re: F29 System Wide Change: Hide the grub menu

On 06/01/2018 05:06 AM, Vít Ondruch wrote:
> 
> It is irony, that people, who are capable to get into the grub menu if
> they need, complain about it being hidden. So to say, I am 100% for
> hiding the grub menu, speeding up the boot process, and if need it, I'll
> find a way to get it.

I fail to see any irony here.  When I need to get into the
grub menu, it's usually an emergency (or at least highly-stressful)
situation, with no documentation handy, and flailing about
trying to figure out how to make it appear just adds to the
stress and the blue tinge of the air in my vicinity.

What *exactly* is this trying to solve?

IIRC, the patch is to hide the grub menu IFF there's only one
kernel because 'it serves no useful function.'  A number of
people (myself included) have disputed that assertion.  If
the assertion is invalid, the patch shouldn't be applied.
Correct?  That seems simple enough.  Or maybe I don't understand
the process, lacking sufficient Fedora-devel-fu karma.

How many non-tech end users install Fedora straight
from the distro, as opposed to those who install a frobbed
version, with different defaults, from a repackager?
_I.e._, repackagers can set grub up however they like.

Is Fedora's goal to be end-user friendly, tech friendly, or
the all-singing all-dancing Linux distro?
-- 
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VZMJFSW4BX63THDFN525SKRKGYHOB6GX/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread David Sommerseth

On 31/05/18 12:23, Hans de Goede wrote:
> Hi All,
> 
> I'm working on improving the Fedora boot experience, with the
> end goal being a user pressing the on button and then going
> to the graphical login manager without him seeing any
> text messages / menus filled with technical jargon.

Making the boot process less "magical" by not presenting "text messages /
menus filled with technical jargon" sounds like a nice user experience - when
everything works.

But we need to account for all the times things do not work too well.  Diving
into a menu by pressing a button or key within a reasonable time window is
challenging for many non-techs.  So this would be a worse user experience if
they struggle to enter this "hidden menu".

I'd rather consider a different approach.  Rather have a closer look at this
"technical jargon" being presented.   Just a quick example from one of my
Fedora VMs:

   'Fedora (4.15.8-300.fc27.x86_64) 27 (Cloud Edition)'

Why not just say:  "Fedora 27"
Or even just "Fedora", as it's not possible to boot into, say, "Fedora 26"
unless lots of tweaks at the install/upgrade time has been done.

Then have a sub-menu called "Recovery options", where you can list older
kernels specifying kernel versions - but make that simpler too.  Instead of
"4.15.8-300.fc27.x86_64" just say: "4.15.8-300"

So the menu could look something like

-
  Fedora
  Recovery options
 |`- Fedora (older kernel, 4.13.0-103)
 |`- Fedora (older kernel, 4.14.5-300)
 |`- Fedora (older kernel, 4.15.3-304)
 \-- System recover mode (expert)
-

Just my 2cents.

-- 
kind regards,

David Sommerseth

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PMI6UPESGWUFWA5HPCFVW6M6H6TAQ4J2/

Summary/Minutes from last Friday's FESCo Meeting (2018-05-25)

2018-06-01 Thread Zbigniew Jędrzejewski-Szmek

Minutes: 
https://meetbot.fedoraproject.org/teams/fesco/fesco.2018-05-25-15.03.html
Full log: 
https://meetbot-raw.fedoraproject.org/teams/fesco/fesco.2018-05-25-15.03.log.html

Meeting summary
init process (maxamillion, 15:03:16)
Follow Ups (maxamillion, 15:04:27)
#1890 updating the FTBFS cleanup policy (maxamillion, 15:04:28)
https://pagure.io/fesco/issue/1890 (maxamillion, 15:04:29)
https://pagure.io/fesco/issue/1890#comment-513975 (zbyszek, 15:05:02)
ACTION: zbyszek to send out the announcement (zbyszek, 15:06:47)

#1892 F29 Self Contained Change: MySQL 8 (maxamillion, 15:07:17)
https://pagure.io/fesco/issue/1892 (maxamillion, 15:07:17)
AGREED: MySQL 8 is approved (+1:5, -1:0, +0:1) (maxamillion, 15:13:56)

New Business (maxamillion, 15:14:36)
#1893 Non-responsive maintainer for libinvm-i18n,libinvm-cli, libinvm-cim 
(maxamillion, 15:14:38)
https://pagure.io/fesco/issue/1893 (maxamillion, 15:14:39)
AGREED: Follow the documented process for unresponsive maintainer and 
reach out to devel list to see if anyone know how to contact the maintainer 
(+1:6, -1:0, +0:1) (maxamillion, 15:23:59)
ACTION: bowlofeggs will write devel to ask if they know how to contact 
nkothapa (bowlofeggs, 15:24:35)

#1894 F29 System Wide Change: Let's Label Our Variants! (maxamillion, 
15:24:53)
https://pagure.io/fesco/issue/1894 (maxamillion, 15:24:53)
AGREED: APPROVE: F29 System Wide Change: Let's Label Our Variants! 
(+1:7, -1:0, +0:0) (maxamillion, 15:29:02)

#1896 Election policy unclear on self-nomination (maxamillion, 15:29:18)
https://pagure.io/fesco/issue/1896 (maxamillion, 15:29:18)
AGREED: proposal #accepted we will update the text to that in 
https://pagure.io/fesco/issue/1896#comment-513999 (+1:7: -1:0, +0:0) 
(maxamillion, 15:39:51)

Next week's chair (maxamillion, 15:39:59)
ACTION: dgilmore to chair next FESCo meeting (maxamillion, 15:41:39)

Open Floor (maxamillion, 15:41:40)

Meeting ended at 15:48:35 UTC (full logs).

Action items
zbyszek to send out the announcement
bowlofeggs will write devel to ask if they know how to contact nkothapa
dgilmore to chair next FESCo meeting
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JSG2VAVO7FUF5SJ5W4U7SYNJU2JILLY5/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Zdenek Kabelac


Dne 1.6.2018 v 15:51 Hans de Goede napsal(a):

Hi,

On 01-06-18 15:26, Chris Adams wrote:

Once upon a time, Hans de Goede  said:

For F30, single OS Fedora Workstation install install we get:

1) grub menu not shown, 0 second timeout, no way to get to the menu


What I haven't seen answered is this: what do we really gain from this?
Your initial message said that the EFI firmware scanning USB for a
keyboard "can be quite slow", but that's not explained.  For the typical
use cases, how long are we actually talking about?


It varies but it can easily be a couple of seconds.




It sounds like every Fedora user is doing nothing else then rebooting,
and 2 seconds is going to be a killer feature.

Personally I reboot once maybe twice a week (and just because I need to track 
recent kernels)



Is really the 2 second 'speedup' worth all the trouble with rescue ??


Regard

Zdenek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4HJB3YKCKCNBQORSOIKUM7K2DLFHKDUI/

Re: F29 System Wide Change: Hide the grub menu

On 05/31/2018 07:29 PM, Adam Williamson wrote:
> 
> Well, to unpack a bit: "let's just slap a choice in the installer!" is
> almost never the right answer.

I consider myself n00b-slapped.  My only defence is my ignorance
of discussions in this area.  Point taken. :-)
-- 
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A5E67JFUIYFQYFG37T757B3TLWTOXLRQ/

Re: F29 System Wide Change: Hide the grub menu

On 05/31/2018 06:06 PM, Chris Murphy wrote:
> On Thu, May 31, 2018 at 2:54 PM, Jason L Tibbitts III  
> wrote:
>>> "CM" == Chris Murphy  writes:
>>
>> Plus, there's an upside: if you're hammering F11 or F8 or F12 or Esc or
>> whatever to try and get into the BIOS, and you miss it, then at least
>> you stop in grub instead of going straight into the OS.
> 
> Ick.

Why 'ick'?  If you're playing Rachmaninoff on the keyboard
during the boot sequence, I think it's a pretty clear indicator
that you want to interrupt it somehow.  (Unless you're a cat.)
So I'd count any sort of interruption as a win, rather than
proceeding to a full boot.

>> Anyway, I don't really care what gets chosen here, but I sure would like
>> the option to actually configure what keys grub watches instead of just
>> having it be 'Esc' and maybe patched to include 'F8'.  Grub seems to be
>> so flexible so it seems odd that this bit is hardcoded.
> 
> That's a good point.

+1
-- 
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZX4E2ACEUGAUKGRXQT6C2S7ZT23SCNOE/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Hans de Goede


Hi,

On 01-06-18 15:26, Chris Adams wrote:

Once upon a time, Hans de Goede  said:

For F30, single OS Fedora Workstation install install we get:

1) grub menu not shown, 0 second timeout, no way to get to the menu


What I haven't seen answered is this: what do we really gain from this?
Your initial message said that the EFI firmware scanning USB for a
keyboard "can be quite slow", but that's not explained.  For the typical
use cases, how long are we actually talking about?


It varies but it can easily be a couple of seconds.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EH4VZ2ZYE2LPX6B3SKM2QPA3IXUMBOAU/

Re: Hiding the grub menu by default on single OS installs

2018-06-01 Thread Chris Adams

Once upon a time, Hans de Goede  said:
> For F30, single OS Fedora Workstation install install we get:
> 
> 1) grub menu not shown, 0 second timeout, no way to get to the menu

What I haven't seen answered is this: what do we really gain from this?
Your initial message said that the EFI firmware scanning USB for a
keyboard "can be quite slow", but that's not explained.  For the typical
use cases, how long are we actually talking about?

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IKNBDU7AS5SXHQP3USK7AAK5BRZGPYZW/

Re: F29 System Wide Change: Strong crypto settings: phase 2