Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Nicolas Mailhot via devel]

Le vendredi 26 juin 2020 à 12:30 -0400, Josef Bacik a écrit :
> On 6/26/20 11:15 AM, Matthew Miller wrote:
> > On Fri, Jun 26, 2020 at 11:13:39AM -0400, Josef Bacik wrote:
> > > Not Fedora land, but Facebook installs it on all of our root
> > > devices, so millions of machines.  We've done this for 5 years.
> > > It's worked out very well. Thanks,
> > 
> > Josef, I'd love to hear your comments on any differences between
> > that
> > situation and the typical laptop-user case for Fedora desktop
> > systems.
> > Anything we should consider?
> > 
> 
> We buy worse hardware than a typical laptop user uses, at least for
> our hard drives. 

The difference between an operation like Facebook and the Fedora user
base, it that Facebook will have a huge fleet of crap hardware, with
the support teams to baby-sit the crap hardware, and attention to
reducing the variety of crap hardware to limit the support matrix
breadth, while Fedora has to deal with a huge support matrix breadth,
without the support teams and the support team tooling to baby-sit
hardware. (Besides Facebook designs the levels of crapiness they allow
in their hardware, meaning they know exactly where they are pushing
limits to lower hardware costs).

And, it’s not always the crap hardware that hits bugs. Sometimes
expensive gamer hardware will fail first because its manufacturer has
pushed the limits to eke some performance points over the competition.

Therefore, using btrfs in Fedora, is inherently more ambitious, than
using it at Facebook.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Nicolas Mailhot via devel]

Le vendredi 26 juin 2020 à 23:28 +0100, Tomasz Kłoczko a écrit :
> On Fri, 26 Jun 2020 at 23:21, Alex Thomas 
> wrote:
> > Once question, are we looking at using a layout like openSUSE is
> > doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes,
> > or
> > are we looking at something like
> > 
> > /boot/efi > EFI (FAT32)
> > / > btrfs
> > 
> 
> BTW that layout.
> Anaconda still does not allow installing something like that because
> it does not allow /boot on btrfs (technically there is no any
> reasons to demand that and /boot can be just subvolume on the root
> btrfs pool).

Anaconda will detect you’re reusing an efi partition, and complain it
does not fit its requirements of the day, and force you to recreate it
from scratch, blowing up the EFI parts installed by other systems for
their own boot in the process.

Thus, Anaconda EFI support is terrible period.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

[Nicolas Mailhot via devel]

Le vendredi 26 juin 2020 à 07:41 -0700, PGNet Dev a écrit :
> hi,
> 
> On 6/25/20 11:58 PM, Nicolas Mailhot wrote:
> > forgemeta works in release mode, with release archives published
> > over
> > http(s). It does not talk at all to source projects using the git
> > protocol (and that is intentional, since a lot ot things tooling-
> > side
> > do not talk the git protocol and will never talk the git protocol,
> > starting with rpm itself, spectool, etc).
> 
> noted.  not clear initially from reading the docs; this helps. thx!

The documentation part of the initial redhat-rpm-config forge
implementation was never merged, and I gave up on refreshing it, so
you’re in traditional unwritten rpm lore land.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging firmwares

[Richard Hughes]

On Fri, 26 Jun 2020, 22:21 Florian Weimer,  wrote:

> Is FirmwareUpdate.efi really firmware in Fedora's sense?  Won't it run
> on the host CPU?
>

This is flashed hardware!? Can't mellanox just use the LVFS to distribute
firmware rather than having to install a package of blobs you're going to
use exactly once?

Richard

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Tomasz Torcz]

On Fri, Jun 26, 2020 at 05:49:03PM -0600, Chris Murphy wrote:
> 
> > For what it's worth, this is really needed, and overdue.  I have
> > repeatedly failed Fedora OS release upgrades on different machines by
> > running out of root fs space. I think the default / is around 50GB, and
> > it's too easy to fill: during OS update we need space for three copies
> > of each package: the old version, the downloaded new version, and the
> > space to install the new version.
> 
> 75G on new installs today but yes there are many folks still with a
> 50G root volume at /
> 
> And changing this to 80+G is sorta 'kick the can' but also as it turns
> out it doesn't really fix the problem that well and puts pressure on
> /home in cases where the laptop drive is kinda small. There are other
> valid ways to solve this single problem, e.g. a single plain ext4 or
> xfs volume. But both of those leave things on the table users benefit
> from.

  We cannot do anything for existing installs. It is up to owner to
juggle partitions.
  Also, with btrfs proposal we do not have to decide how to split space
between / and /home.  Boths are just a subvolumes and share all the
space.


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Fri, Jun 26, 2020 at 6:17 PM Peter Gordon  wrote:

> This is a good argument for having Fedora officially support BtrFS as a
> possible installation option, yes;

It already is a release blocking (supported) file system for install
time option. Has been for ~10 years.


> BtrFS might have significant feature advantage over Ext4, yes; but so
> far it has only seen production use from a handful of companies, and
> even then, not for very long. (The BtrFS wiki page [1] lists most of
> these users only as of late-2018 -- just under two years.)

Facebook since 2015. SUSE/openSUSE on the desktop and on servers since
2014, by default. Are you suggesting they can do it and we can't?


> In contrast to this, Ext4 has been the default FS in many enterprise
> systems for well over a decade: For instance, Google transitioned its
> systems to Ext4 in January 2010 [2], and transitioned Android to Ext4
> in December 2010 [3]. And most modern Linux distros made Ext4 their
> default filesystem at around the same time.

Google has been using btrfs as part of Crostini, which I mention up
thread, as the file system to support native Linux apps on Chrome OS.
It would appear they're choosing different things for different
purposes to solve specific problems.

And in Fedora we think users want to improve the life of their
hardware, get better efficiency with reflinks and snapshots for
containers, and improve the responsiveness of the desktop by including
IO isolation as part of a better resource control solution, and not
have corrupt data pass through to user space or to their backups,
silently. Btrfs provides all of these things, and helps solve users'
problems.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Fri, Jun 26, 2020 at 3:44 PM Matthew Miller  wrote:
>
> On Fri, Jun 26, 2020 at 03:22:07PM -0400, Josef Bacik wrote:
> > I described this case to the working group last week, because it hit
> > us in production this winter.  Somebody screwed up and suddenly
> > pushed 2 extra copies of the whole website to everybody's VM.  The
> > website is mostly metadata, because of the inline extents, so it
> > exhausted everybody's metadata space.  Tens of thousands of machines
> > affected.  Of those machines I had to hand boot and run balance on
> > ~20 of them to get them back.  The rest could run balance from the
> > automation and recover cleanly.
>
> Is there a way to mitigate this by reserving space or setting quotas? Users
> running out of space on their laptops because:
>
> * they downloaded a lot of media
> * they created huge vms
> * some sort of horrible log thing gone awry
>
> are pretty common in both a) my anecdotal experience helping people
> professionally and personally and b) um, me.
>

Real out of space can happen on any file system. Bogus enospc on btrfs
due to edge cases hitting bugs are less common than real enospc due to
the current partitioning arrangement creating competition between
/home and / free space - which won't exist with btrfs. I expect a net
reduction of out of space as a result of the change.

There is a reserve in btrfs to help make sure if you do get to a real
out of space condition, that the file system (a) stays read write and
(b) can be backed out of the full condition by deleting files and
successfully freeing up space. Edge cases where this doesn't work are
bugs, and there are some non-obvious ways to back out of it if someone
does hit one.

The old stories on #btrfs and linux-btrfs@ do include cases of a file
system that goes read-only, can't be remounted read-write, and you
have to backup->reformat->restore. And that is a PITA. But also not
data loss.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Peter Gordon]

On Fri, 2020-06-26 at 14:04 -0500, Michael Catanzaro wrote:
> [...] 
> 
> Surely if xfs is good enough for RHEL, and btrfs is 
> at least 10x more reliable than xfs, that suggests btrfs should 

This is a good argument for having Fedora officially support BtrFS as a
possible installation option, yes; but a _default_ filesystem needs to
be absolutely tried-and-true, and I believe that BtrFS has not yet been
put through its paces well enough for this. Ext4 should remain the
default FS for now.

BtrFS might have significant feature advantage over Ext4, yes; but so
far it has only seen production use from a handful of companies, and
even then, not for very long. (The BtrFS wiki page [1] lists most of
these users only as of late-2018 -- just under two years.)

In contrast to this, Ext4 has been the default FS in many enterprise
systems for well over a decade: For instance, Google transitioned its
systems to Ext4 in January 2010 [2], and transitioned Android to Ext4
in December 2010 [3]. And most modern Linux distros made Ext4 their
default filesystem at around the same time.

Moreover, putting aside any issues of stability, Ext4 peformance and
interactivity continues to beat that of BtrFS except in very specific
scenarios. For example, in this December 2019 Phoronix benchmark [4],
BtrFS was better under some RAID setups, but consistently slightly
worse than Ext4 for the single disk use cases; and considering that
most desktops and laptops (minus some workstation-class PCs and
laptops, like a ThinkPad P-series perhaps) use single disks instead of
RAID arrays, it does not make sense yet to suggest a default filesystem
that will hamper performance at the cost of features (like support for
16 EiB volumes and snapshots) that most users will probably not use or
care about.

In summary: Yes, it would be very cool for Fedora to support BtrFS; but
it should not yet be the default filesystem. It still needs a lot of
time to mature and stabilize. 


[1] htps://btrfs.wiki.kernel.org/index.php/Production_Users
[2] https://lists.openwall.net/linux-ext4/2010/01/04/8
[3] 
https://thunk.org/tytso/blog/2010/12/12/android-will-be-using-ext4-starting-with-gingerbread/

[4] 
https://www.phoronix.com/scan.php?page=article&item=linux54-hdd-raid
-- 
Peter Gordon (codergeek42) 
Who am I? :: http://thecodergeek.com/about-me


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Fri, Jun 26, 2020 at 3:22 PM Przemek Klosowski via devel
 wrote:
>
> I remember that two issues that made me apprehensive wrt. BTRFS were its
> handling of the 'disk full' situation, and lack of a staightforward
> 'fsck' workflow. I think the first issue has been resolved, and we
> probably just need some docs and scripts that handle file system
> corruption by remounting R/O and printing some suggestions what to do next.

A medium term goal is to make systemd and the desktop environment more
tolerant to starting up read-only, and even though this is a limited
environment the user isn't just stuck at a prompt. SUSE/openSUSE can
today boot read-only snapshots as part of its rollback strategy but
I'm not sure how/why it works or whether it's adaptable.

A short term goal, possibly even a requirement for the proposal, is
some kind of message at a dracut prompt to at least give the user
something to go on, in sequence, including even 'join us on
#fedora-btrfs' or whatever. A bigger problem is that right now (a) new
installs don't set a password for root user, and (b) systemd emergency
target requires a root user login to get to a prompt. It has to be a
mount *failure* to get to a dracut prompt where we could show some
messages. There is this middle area where the user is stuck no matter
the file system.

Some of these are long standing problems, but they're perhaps being
spotlit by the change.


> For what it's worth, this is really needed, and overdue.  I have
> repeatedly failed Fedora OS release upgrades on different machines by
> running out of root fs space. I think the default / is around 50GB, and
> it's too easy to fill: during OS update we need space for three copies
> of each package: the old version, the downloaded new version, and the
> space to install the new version.

75G on new installs today but yes there are many folks still with a
50G root volume at /

And changing this to 80+G is sorta 'kick the can' but also as it turns
out it doesn't really fix the problem that well and puts pressure on
/home in cases where the laptop drive is kinda small. There are other
valid ways to solve this single problem, e.g. a single plain ext4 or
xfs volume. But both of those leave things on the table users benefit
from.

Of course it isn't all about features. If it's just a feature contest
btrfs wins somewhat dramatically. What's going to make the feature
successful is the community backing it up. The change needs the desire
and resources of Fedora more than just features. A dozen owners on the
proposal hopefully gives confidence that it's serious, but it's going
to take more than that.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Josef Bacik]

On 6/26/20 5:44 PM, Matthew Miller wrote:

On Fri, Jun 26, 2020 at 03:22:07PM -0400, Josef Bacik wrote:

I described this case to the working group last week, because it hit
us in production this winter.  Somebody screwed up and suddenly
pushed 2 extra copies of the whole website to everybody's VM.  The
website is mostly metadata, because of the inline extents, so it
exhausted everybody's metadata space.  Tens of thousands of machines
affected.  Of those machines I had to hand boot and run balance on
~20 of them to get them back.  The rest could run balance from the
automation and recover cleanly.


Is there a way to mitigate this by reserving space or setting quotas? Users
running out of space on their laptops because:

* they downloaded a lot of media
* they created huge vms
* some sort of horrible log thing gone awry

are pretty common in both a) my anecdotal experience helping people
professionally and personally and b) um, me.



There's a difference between data ENOSPC and metadata ENOSPC.  And again, this 
is a pretty specific failure case.  Obviously it's not impossible to hit, but 
it's not something that's going to be a common occurrence.  The two times we've 
hit these issues in production was the thing that I mentioned, which had 750gib 
fs's completely full with 20gib of metadata completely filled up.


The second was a bad service that was spewing empty files onto the disk slowly 
filling up the metadata chunks, coupled with a bug in how we allocated data and 
metadata chunks.  The chunk allocation thing has been fixed for a year or two 
now.  This isn't something a normal user is going to hit most of the time.  It 
obviously does happen, I'm aware of it, and I've made progress on making it less 
likely to get you into a "call Josef" situation.  I'm sure there's still more 
work to be done, but there's continual progress on this particular edgecase. 
Thanks,


Josef
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Neal Gompa]

On Fri, Jun 26, 2020 at 6:37 PM Alex Thomas  wrote:
>
> On Fri, Jun 26, 2020 at 5:25 PM Neal Gompa  wrote:
> >
> > On Fri, Jun 26, 2020 at 6:11 PM Alex Thomas  wrote:
> > >
> > > Once question, are we looking at using a layout like openSUSE is
> > > doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
> > > are we looking at something like
> > >
> > > /boot/efi > EFI (FAT32)
> > > / > btrfs
> > >
> >
> > We are planning on using Fedora's current default layout, which has a
> > subvolume for / and a subvolume for /home.
> >
>
> Ok, I thought I saw a proposal by you to change the default btrfs
> layout to something like openSUSE's using subvolumes, but now, of
> course, I cannot find it.

I have, at various points in the past couple of years, considered
different subvolume configurations. Right now, I'm keeping it simple
to our currently tested configuration: /boot on ext4, / and /home as
btrfs subvolumes on a single btrfs volume.

The only modification I may consider would be moving /boot to be btrfs
volume or subvolume, but that's contingent on some discussion with the
installer and bootloader teams.

However, the existing configuration works *very* well right now.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Alex Thomas]

On Fri, Jun 26, 2020 at 5:31 PM Tomasz Kłoczko  wrote:
>
> On Fri, 26 Jun 2020 at 23:21, Alex Thomas  wrote:
>>
>> Once question, are we looking at using a layout like openSUSE is
>> doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
>> are we looking at something like
>>
>> /boot/efi > EFI (FAT32)
>> / > btrfs
>
>
> BTW that layout.
> Anaconda still does not allow installing something like that because it does 
> not allow /boot on btrfs (technically there is no any reasons to demand that 
> and /boot can be just subvolume on the root btrfs pool).
>
> kloczek
> --
> Tomasz Kłoczko |  LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Something to think about when trying to set up for snapshot/rollbacks, then.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Alex Thomas]

Ok, I thought I saw a proposal by you to change the default btrfs
layout to something like openSUSE's using subvolumes, but now, of
course, I cannot find it.

On Fri, Jun 26, 2020 at 5:25 PM Neal Gompa  wrote:
>
> On Fri, Jun 26, 2020 at 6:11 PM Alex Thomas  wrote:
> >
> > Once question, are we looking at using a layout like openSUSE is
> > doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
> > are we looking at something like
> >
> > /boot/efi > EFI (FAT32)
> > / > btrfs
> >
>
> We are planning on using Fedora's current default layout, which has a
> subvolume for / and a subvolume for /home.
>

Ok, I thought I saw a proposal by you to change the default btrfs
layout to something like openSUSE's using subvolumes, but now, of
course, I cannot find it.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Tomasz Kłoczko]

On Fri, 26 Jun 2020 at 23:21, Alex Thomas  wrote:

> Once question, are we looking at using a layout like openSUSE is
> doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
> are we looking at something like
>
> /boot/efi > EFI (FAT32)
> / > btrfs
>

BTW that layout.
Anaconda still does not allow installing something like that because it
does not allow /boot on btrfs (technically there is no any reasons to
demand that and /boot can be just subvolume on the root btrfs pool).

kloczek
-- 
Tomasz Kłoczko |  LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Neal Gompa]

On Fri, Jun 26, 2020 at 6:11 PM Alex Thomas  wrote:
>
> Once question, are we looking at using a layout like openSUSE is
> doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
> are we looking at something like
>
> /boot/efi > EFI (FAT32)
> / > btrfs
>

We are planning on using Fedora's current default layout, which has a
subvolume for / and a subvolume for /home.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging firmwares

[Robert-André Mauchin]

On Friday, 26 June 2020 23:20:38 CEST Florian Weimer wrote:
> * Robert-André Mauchin:
> > I have a review request for a firmware: Boot firmware (ATF, UEFI...) for
> > Mellanox BlueField:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1846139
> > 
> > I would like some opinions on whether this is acceptable firmware. The
> > binary contains open source code for which the license are documented,
> > but no code source is provided, only the resulting binary firmware.
> 
> Is FirmwareUpdate.efi really firmware in Fedora's sense?  Won't it run
> on the host CPU?
> 
> In the Git repository
> 
>   
> 
> Mellanox does not provide permission to redistribute the firmware, only
> required notices of components that they have used to build it.  Just
> saying that something has been derived (in part) from open source
> software does not make it open source, or even redistributable.
> 
> Thanks,
> Florian

Right, the Mellanox people are CC to the bug so I assume they want it 
packaged. I will ask for further clarifications.

Thanks.


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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Alex Thomas]

Once question, are we looking at using a layout like openSUSE is
doing? ( https://en.opensuse.org/SDB:BTRFS ) utilizing subvolumes, or
are we looking at something like

/boot/efi > EFI (FAT32)
/ > btrfs



On Fri, Jun 26, 2020 at 4:45 PM Matthew Miller  wrote:
>
> On Fri, Jun 26, 2020 at 03:22:07PM -0400, Josef Bacik wrote:
> > I described this case to the working group last week, because it hit
> > us in production this winter.  Somebody screwed up and suddenly
> > pushed 2 extra copies of the whole website to everybody's VM.  The
> > website is mostly metadata, because of the inline extents, so it
> > exhausted everybody's metadata space.  Tens of thousands of machines
> > affected.  Of those machines I had to hand boot and run balance on
> > ~20 of them to get them back.  The rest could run balance from the
> > automation and recover cleanly.
>
> Is there a way to mitigate this by reserving space or setting quotas? Users
> running out of space on their laptops because:
>
> * they downloaded a lot of media
> * they created huge vms
> * some sort of horrible log thing gone awry
>
> are pretty common in both a) my anecdotal experience helping people
> professionally and personally and b) um, me.
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Matthew Miller]

On Fri, Jun 26, 2020 at 03:22:07PM -0400, Josef Bacik wrote:
> I described this case to the working group last week, because it hit
> us in production this winter.  Somebody screwed up and suddenly
> pushed 2 extra copies of the whole website to everybody's VM.  The
> website is mostly metadata, because of the inline extents, so it
> exhausted everybody's metadata space.  Tens of thousands of machines
> affected.  Of those machines I had to hand boot and run balance on
> ~20 of them to get them back.  The rest could run balance from the
> automation and recover cleanly.

Is there a way to mitigate this by reserving space or setting quotas? Users
running out of space on their laptops because:

* they downloaded a lot of media
* they created huge vms
* some sort of horrible log thing gone awry

are pretty common in both a) my anecdotal experience helping people
professionally and personally and b) um, me.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

The ship on POSIX mandating vi (and defining it's behavior) sailed years
ago.

On Fri, Jun 26, 2020, 4:11 PM Orcan Ogetbil  wrote:

> On Fri, 26 Jun 2020 at 10:55, Jonathan Wakely wrote:
> >
> > > I came here with peace. Let's face it. It's always between the two. I
> > > respect vim and I learned quite some things in vim. But I'm an emacs
> > > user and I find the original decision between vim and emacs for 'git
> > > commit' unfair.
> >
> > Git doesn't use vim by default, it uses vi, and it's got nothing to do
> with fairness. vi is specified by the POSIX standard, emacs is not. Using
> vi as the default when EDITOR is not set is consistent with POSIX utilities
> like crontab, using emacs is not.
> >
> > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
> >
> > But this isn't about your preference (emacs) or my preference (vim), or
> what POSIX can portably assume is present. Fedora can assume nano is
> present, because Fedora controls that and already makes it present.
>
> Thank you again for the reference. vi and vim are the same thing for
> most people.
>
> I think it's best if POSIX stays away from taking sides on a deep
> religious dilemma.
>
> Make it neutral (e.g. nano). Both sides get hurt the same amount.
>
> Best,
> Orcan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

PVECLIB version bump (with new IFUNC runtime libraries)

[Steven Munroe]

So I think I am ready to release version 1.0.4 of the Power Vector Library.

The big addition is multiple (128-bit) vector quadword arithmetic
introduced with the new vec_int512_ppc.h. This header actually provides
support for 2048x2048 bit multiplies with all intermediate values held in
(64x128-bit) vector registers.

This eliminates memory side channel exposure which may be of interest to
the crypto folks.

Of course a straight-line implementation of a 2048x2048 bit multiply can
get a little large. So creating callable runtime libraries is appropriate.
As the PowerISA has evolved, the optimum instructions and instruction
sequences vary across power7/8/9

So PVECLIB now builds runtime libraries containing multiple (platform
specific) implementations of the int512 arithmetic operations. Both a
static archive
(with platform specific suffixes) and DSO with IFUNC resolvers are provided.

So working some last minute details for the build system and doxygen for
building the multiple platform libraries.

So guidance on the next steps will be appreciated.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Michael Catanzaro]

One thing that hasn't been mentioned yet is that btrfs is also 
important for our plans to preserve system responsiveness under heavy 
load, https://pagure.io/fedora-workstation/issue/154.


On Fri, Jun 26, 2020 at 5:22 pm, Przemek Klosowski via devel 
 wrote:

For what it's worth, this is really needed, and overdue.  I have
repeatedly failed Fedora OS release upgrades on different machines by
running out of root fs space. I think the default / is around 50GB, 
and

it's too easy to fill: during OS update we need space for three copies
of each package: the old version, the downloaded new version, and the
space to install the new version.


We raised it to 70 GB, but it's still too small. I keep running out of 
space too, most recently just a couple days ago. This is a problem 
we're determined to solve, and raising the size of / further just 
increases the chance of the user running out of space on /home 
currently, so if btrfs doesn't pass, we will (very likely) switch to 
single-partition ext4 (or maybe xfs). See 
https://pagure.io/fedora-workstation/issue/152.


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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 6/26/20 1:43 PM, Neal Gompa wrote:

One issue that I have
seen mentioned as an issue within the last week is still the problem of
running out of space when it still looks like there's space free.  I
didn't read the responses, so not sure of the resolution, but I remember
that being a "thing" with btrfs.  Is that still the case?  What are the
causes, and if so, how can we keep from getting a lot of the same
question on mailing lists/forums/etc.?


Josef gave a fairly detailed answer upthread:


In this reply, he does not specifically address the disk-full issue, but 
I seem to remember that it was resolved. I couldn't however find a 
reference---could someone authoritatively say something one way or another?


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

Re: [Fedora-legal-list] Re: Packaging firmwares

[Richard Fontana]

On Fri, Jun 26, 2020 at 5:21 PM Florian Weimer  wrote:

> In the Git repository
>
>   
>
> Mellanox does not provide permission to redistribute the firmware, only
> required notices of components that they have used to build it.  Just
> saying that something has been derived (in part) from open source
> software does not make it open source, or even redistributable.

Right, if that is how the explicit license information in that
repository should be interpreted, then this is not OK for Fedora.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Przemek Klosowski via devel]

On 6/26/20 12:31 PM, Chris Murphy wrote:

That pattern will change with btrfs. There will be fewer of some problems,
more of others, and the messages will be different. fsck.ext4 is
pretty much all we have, all we're used to, and it's a binary
pass/fail. Even though we're talking about edge cases at this level,
those who get unlucky for whatever reason are going to need a
community of user to user support giving them good advice. Will Fedora?


Well said. BTRFS is more complex and will require getting used to.

In case of FS trouble, everyone knows 'fsck' but as Josef wrote

    With btrfs you are just getting started.  You have several built in 
mount options for recovering different failures, all read only.  But you 
have to know that they are there and how to use them.


which is both encouraging and terrifying :)

I remember that two issues that made me apprehensive wrt. BTRFS were its 
handling of the 'disk full' situation, and lack of a staightforward 
'fsck' workflow. I think the first issue has been resolved, and we 
probably just need some docs and scripts that handle file system 
corruption by remounting R/O and printing some suggestions what to do next.




It's also important to talk about what's left on the table*without*
this change. The potential to almost transparently drop in a new file
system that extends the life of user's hardware, eliminates the free
space competition problem between /home and /, and allocates it more
efficiently.  And asks*less*  of day to day users, while inviting
*more*  from those who want to explore more features. On the same file
system.


For what it's worth, this is really needed, and overdue.  I have 
repeatedly failed Fedora OS release upgrades on different machines by 
running out of root fs space. I think the default / is around 50GB, and 
it's too easy to fill: during OS update we need space for three copies 
of each package: the old version, the downloaded new version, and the 
space to install the new version.


Even though technically dnf system-upgrade can --download-dir to a 
location off / it doesn't seem to work with the actual upgrade, so the 
only way I know is to delete largest packages (flightGear*, piglit*, 
KiCAD*, ...) and reinstall them after update.

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

Re: Packaging firmwares

[Florian Weimer]

* Robert-André Mauchin:

> I have a review request for a firmware: Boot firmware (ATF, UEFI...) for 
> Mellanox BlueField:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1846139
>
> I would like some opinions on whether this is acceptable firmware. The
> binary contains open source code for which the license are documented,
> but no code source is provided, only the resulting binary firmware.

Is FirmwareUpdate.efi really firmware in Fedora's sense?  Won't it run
on the host CPU?

In the Git repository

  

Mellanox does not provide permission to redistribute the firmware, only
required notices of components that they have used to build it.  Just
saying that something has been derived (in part) from open source
software does not make it open source, or even redistributable.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [Fedora-legal-list] Packaging firmwares

[Richard Fontana]

On Fri, Jun 26, 2020 at 4:36 PM Robert-André Mauchin  wrote:
>
> Hello,
>
> I have a review request for a firmware: Boot firmware (ATF, UEFI...) for
> Mellanox BlueField:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1846139
>
> I would like some opinions on whether this is acceptable firmware. The binary
> contains open source code for which the license are documented, but no code
> source is provided, only the resulting binary firmware.

Assuming these are all the applicable licenses:
https://github.com/Mellanox/bootimages/tree/master/licenses (I looked
at the review request very quickly) these standard FOSS licenses are
all acceptable licenses for Fedora firmware.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Packaging firmwares

[Robert-André Mauchin]

Hello,

I have a review request for a firmware: Boot firmware (ATF, UEFI...) for 
Mellanox BlueField:

https://bugzilla.redhat.com/show_bug.cgi?id=1846139

I would like some opinions on whether this is acceptable firmware. The binary 
contains open source code for which the license are documented, but no code 
source is provided, only the resulting binary firmware.

Thanks for any help,

Robert-André

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Solomon Peachy]

On Fri, Jun 26, 2020 at 12:38:40PM -0400, Ben Rosser wrote:
> The -t/--tempfile switch for nano (and pico) does exactly this:
> https://linux.die.net/man/1/nano

Yeah, I've had EDITOR='nano -t -r 72' set in my .profile for as long as 
I can remember.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Przemek Klosowski via devel]

On 6/26/20 10:33 AM, Neil Horman wrote:

If I google how to quit vi, I see a full 10 pages of the answer to the question
documented in detail


The fact that people have to google their way out of such a mundane 
circumstance is in my opinion enough to give this proposal a:


+1

As background, I am well familiar with vi and I rarely change the EDITOR 
to emacs, even though it's my own preference.


There are two  reasons:

 * vi starts instantly and emacs doesn't,

 * emacs leaves the *~ files around, and most contexts in which 'vi' is 
being used is simple enough that my knowledge of vi is sufficient and I 
don't need the backup files.


Nano comes out favorably in both cases, so even though I have never used 
it before I think it's a better choice than both vi and emacs.

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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Justin Forbes]

On Fri, Jun 26, 2020 at 2:05 PM Michael Catanzaro  wrote:
>
> On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson 
> wrote:
> > I strongly agree. BTRFS has been 5 years from production ready for
> > almost a decade now, please don't force this on users that doesn't
> > know any better.
>
> This is hard to square with the fact that it's already being used in
> production on millions of systems. It's also hard to square with the
> data presented by Josef -- the only hard evidence I've seen on the
> topic of filesystem reliability -- which shows btrfs is an order of
> magnitude more reliable than xfs (although we don't know how it
> compares to ext4). Surely if xfs is good enough for RHEL, and btrfs is
> at least 10x more reliable than xfs, that suggests btrfs should
> probably be good enough for Fedora?
>

Saying production on millions of systems is a bit misleading here,
when you are talking about millions of systems at a single company.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Orcan Ogetbil]

On Fri, 26 Jun 2020 at 10:55, Jonathan Wakely wrote:
>
> > I came here with peace. Let's face it. It's always between the two. I
> > respect vim and I learned quite some things in vim. But I'm an emacs
> > user and I find the original decision between vim and emacs for 'git
> > commit' unfair.
>
> Git doesn't use vim by default, it uses vi, and it's got nothing to do with 
> fairness. vi is specified by the POSIX standard, emacs is not. Using vi as 
> the default when EDITOR is not set is consistent with POSIX utilities like 
> crontab, using emacs is not.
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html
>
> But this isn't about your preference (emacs) or my preference (vim), or what 
> POSIX can portably assume is present. Fedora can assume nano is present, 
> because Fedora controls that and already makes it present.

Thank you again for the reference. vi and vim are the same thing for
most people.

I think it's best if POSIX stays away from taking sides on a deep
religious dilemma.

Make it neutral (e.g. nano). Both sides get hurt the same amount.

Best,
Orcan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Markus Larsson]

On 26 June 2020 21:32:31 CEST, Igor Raits  
wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512

>> 
>> Josef's server parks is a bit of a different use case than laptops as
>> other people has already pointed out.
>> If you want data on how it works in a desktop/laptop scenario talk to
>> openSUSE users about how many times the "btrfs randomly ate my
>> volume"-bug was "fixed".
>> 
>> When I ran an environment of about 4500 SLES and about 5000 RHEL
>> servers btrfs failed about 3 times as often as xfs (this from our own
>> in-house statistics). That was 3 years ago but filesystems takes long
>> to mature and I have been keeping ear near openSUSE to see where it
>> goes.
>> Is this as big as Josef's environment? No but it is first hand data
>> to me (to you it is of course just anecdotal evidence)
>
>Keep in mind that SLES does backport btrfs patches because they support
>it. RHEL does not. And we are talking about Fedora here anyway.

We didn't use BTRFS on any RHEL machines only on the SLES ones. 
>
>> BTRFS has the potential to become great, I just think it isn't there
>> yet and it'll take 5 years of smooth sailing to convince me.
>
>Probably you should try it with Fedora's kernel?

Oh I will, when BTRFS has had smooth sailing for 5 years. I have no problem 
with others running btrfs, I just think it should be the default since we seem 
to be all about not creating problems for new users. That's at least what the 
recent changes tell me :)

>
>> > 
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct:  
>> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines:  
>> > https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:  
>> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:  
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:  
>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:  
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>- -- 
>Igor Raits 
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72TU8ACgkQEV1auJxc
>Hh759w//XHCXloEj6QAUNpVxCEljVwm1WQVl1jfH3p+mex1a5Dan242COXkVaEzy
>6zR79EZf7ONg1dTU41fq1mg3gWkFAE/q+OD4cSJ/Jbwyt/L+L40MgD1h7UmNo0/P
>uytLZYC3BUIq9ARAH2DlYMHSQUcYZ8TOyrlxWUmkyqPnc99D9CkkqReRjWA/EtYi
>mVNOzCQwdMefSJu6+HZlFIhyYeyBbmfu/Q0v5uQE9CQbmN/AuyTHmWG3jRYTINxg
>7w8vFPLwjUEmUno+i0Jvkdr4EqSZihV4ljoA0MO8OEADHamjnUOWX8HiFN6E6y+V
>cDXPvVTqdf7v+Hz6j6F2cUDbm6PQrbd5fODMeCVibuE5knDB587jRcrqXYfSp+wL
>66VRnHXYrOAMHXKlcs+XpPxkqfy5AdgvkP63PUZTWb4yb4wElVVpFNsBf2wk7TXu
>kp9cKSf+1CSaIq0oD1uY9YB4Xm9elI3pRJJHuH8TrOKI4RsxnmjXdpXB+pzNf8BH
>8PQex0mAwcvefiK0MfaJcl6cP9PgIvvAb75OoWulEsXGG9uPT1ZknYwgXPFN+eDs
>T5Wr/7957eiDDgYDtxPXQfliI58AtnCh1ysNcEf5vRLEARs3HLT8Mo+Z+o78ZvpG
>ZNYkixPYKGrGrUdLJzwXqlQAy6wlNXDzTIxPtrXy5DHMkuAAAqo=
>=2hBc
>-END PGP SIGNATURE-
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives: 
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Fri, Jun 26, 2020 at 11:30 AM Chris Adams  wrote:
>
> Once upon a time, Ben Cotton  said:
> > For laptop and workstation installs of Fedora, we want to provide file
> > system features to users in a transparent fashion. We want to add new
> > features, while reducing the amount of expertise needed to deal with
> > situations like [https://pagure.io/fedora-workstation/issue/152
> > running out of disk space.] Btrfs is well adapted to this role by
> > design philosophy, let's make it the default.
>
> So... I freely admit I have not looked closely at btrfs in some time, so
> I could be out of date (and my apologies if so).  One issue that I have
> seen mentioned as an issue within the last week is still the problem of
> running out of space when it still looks like there's space free.  I
> didn't read the responses, so not sure of the resolution, but I remember
> that being a "thing" with btrfs.  Is that still the case?  What are the
> causes, and if so, how can we keep from getting a lot of the same
> question on mailing lists/forums/etc.?

There's different kinds of enospc. Most have been bugs that are long
since fixed (practically the entire enospc infrastructure was
rewritten circa 2016, which itself then exposed some prior fixes that
became new bugs). But like any bug we'd need to see more info: kernel
version and the conditions. That's just sorta how a bug hunt goes, and
they're all tedious.

I haven't experienced enospc on btrfs in years. I also do not do any
special incantations or scheduled maintenance to avoid it. I just use
the file system normally, and if I were to hit enospc I'd collect a
bunch of info and file a good bug report. And I know some folks aren't
into that, and that's fine.

Those I've seen elsewhere, the typical manifestation is it's a one off
transient enospc and you try again and things are fine. The file
system stays read-write, and there is no other side effect. Since
Btrfs is copy-on-write it takes free space to delete files. A file
deletion *consumes* free space in the form of metadata being read,
modified to indicate the delete, and then written. Only after that
succeeds is space freed up as a result of the delete.

I have a few file systems I intentionally keep around at 99% full just
because I'm a file system saboteur but also if I hit enospc, it's
still a bug. I'm still gonna report it. I'm not going to make excuses
like "oh it's 99% full, no wonder!" We'll probably hit some enospc
edge cases somewhere in Fedora. It does even happen on ext4 and xfs
sometimes, though less common because they don't need free space to
update metadata.

My inclination is always to not fix problems, collect data, and report
them. So it's a valid question to say "no thanks, what is the
incantation to fix it, please? i have work to do, not bug reports"
should you run into it. And yes there are those things, and they can
be done online without repairs or reboots.

> I remember when btrfs was going to be the
> one FS to rule them all, but then had issues, and specific weird cases
> (like with VM images IIRC at one point),

nodatacow on VM images, whether raw or qcow2 is still recommended.
This can be done with 'chattr +C' on either the file while still zero
length or on the directory and then it's inherited (for new files as
created or copied). So the details of how to do this, who does it, is
very much on-topic and a question.

Should the installer set +C on /var/lib/libvir/timages? Or should libvirtd?

What happens if you don't? Well depending on the guest, the image can
get pretty fragmented. Curiously the *least* problematic combination
is btrfs guest on raw on btrfs. And the worst is NTFS guest on qcow2
on btrfs (in a week, 51000+ extents for that one file). I can't say I
notice the performance hit anecdotally but would a benchmark prove
it's slower? Maybe, probably. That's a lot of extent tracking and it's
only one week of aging.

Technically it's in the category of a recommended optimization. The
community can escalate this and say, it's a must have. Same for the
compression option in the proposal. Same for anything really, it's a
discussion.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, 2020-06-26 at 21:22 +0200, Markus Larsson wrote:
> 
> On 26 June 2020 21:04:00 CEST, Michael Catanzaro <
> mcatanz...@gnome.org> wrote:
> > On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson
> >  
> > wrote:
> > > I strongly agree. BTRFS has been 5 years from production ready
> > > for 
> > > almost a decade now, please don't force this on users that
> > > doesn't 
> > > know any better.
> > 
> > This is hard to square with the fact that it's already being used
> > in 
> > production on millions of systems. It's also hard to square with
> > the 
> > data presented by Josef -- the only hard evidence I've seen on the 
> > topic of filesystem reliability -- which shows btrfs is an order of
> > magnitude more reliable than xfs (although we don't know how it 
> > compares to ext4). Surely if xfs is good enough for RHEL, and btrfs
> > is 
> > at least 10x more reliable than xfs, that suggests btrfs should 
> > probably be good enough for Fedora?
> > 
> > Do you have any real evidence for your claim that would be more 
> > convincing than what Josef has presented?
> 
> Josef's server parks is a bit of a different use case than laptops as
> other people has already pointed out.
> If you want data on how it works in a desktop/laptop scenario talk to
> openSUSE users about how many times the "btrfs randomly ate my
> volume"-bug was "fixed".
> 
> When I ran an environment of about 4500 SLES and about 5000 RHEL
> servers btrfs failed about 3 times as often as xfs (this from our own
> in-house statistics). That was 3 years ago but filesystems takes long
> to mature and I have been keeping ear near openSUSE to see where it
> goes.
> Is this as big as Josef's environment? No but it is first hand data
> to me (to you it is of course just anecdotal evidence)

Keep in mind that SLES does backport btrfs patches because they support
it. RHEL does not. And we are talking about Fedora here anyway.

> BTRFS has the potential to become great, I just think it isn't there
> yet and it'll take 5 years of smooth sailing to convince me.

Probably you should try it with Fedora's kernel?

> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:  
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:  
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:  
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:  
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:  
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:  
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl72TU8ACgkQEV1auJxc
Hh759w//XHCXloEj6QAUNpVxCEljVwm1WQVl1jfH3p+mex1a5Dan242COXkVaEzy
6zR79EZf7ONg1dTU41fq1mg3gWkFAE/q+OD4cSJ/Jbwyt/L+L40MgD1h7UmNo0/P
uytLZYC3BUIq9ARAH2DlYMHSQUcYZ8TOyrlxWUmkyqPnc99D9CkkqReRjWA/EtYi
mVNOzCQwdMefSJu6+HZlFIhyYeyBbmfu/Q0v5uQE9CQbmN/AuyTHmWG3jRYTINxg
7w8vFPLwjUEmUno+i0Jvkdr4EqSZihV4ljoA0MO8OEADHamjnUOWX8HiFN6E6y+V
cDXPvVTqdf7v+Hz6j6F2cUDbm6PQrbd5fODMeCVibuE5knDB587jRcrqXYfSp+wL
66VRnHXYrOAMHXKlcs+XpPxkqfy5AdgvkP63PUZTWb4yb4wElVVpFNsBf2wk7TXu
kp9cKSf+1CSaIq0oD1uY9YB4Xm9elI3pRJJHuH8TrOKI4RsxnmjXdpXB+pzNf8BH
8PQex0mAwcvefiK0MfaJcl6cP9PgIvvAb75OoWulEsXGG9uPT1ZknYwgXPFN+eDs
T5Wr/7957eiDDgYDtxPXQfliI58AtnCh1ysNcEf5vRLEARs3HLT8Mo+Z+o78ZvpG
ZNYkixPYKGrGrUdLJzwXqlQAy6wlNXDzTIxPtrXy5DHMkuAAAqo=
=2hBc
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Josef Bacik]

On 6/26/20 2:58 PM, James Szinger wrote:

On Fri, 26 Jun 2020 12:30:02 -0500
Chris Adams  wrote:

So... I freely admit I have not looked closely at btrfs in some time,
so I could be out of date (and my apologies if so).  One issue that I
have seen mentioned as an issue within the last week is still the
problem of running out of space when it still looks like there's
space free.  I didn't read the responses, so not sure of the
resolution, but I remember that being a "thing" with btrfs.  Is that
still the case?  What are the causes, and if so, how can we keep from
getting a lot of the same question on mailing lists/forums/etc.?


Yes, it happened to me last week.  The workstation has been upgraded
since F25 and is now at F31.  A yum update last week ran a restorecon
-r / which filled up the filesystem and RAM and swap.  The 460 GB
filesystem had about 140GB of real data, 100 GB of data bloat from
underfull blocks, and the rest (200GB) was metadata.  I had to boot
from a live USB and run btrfs balance to free up the bloat.  I expect
to reformat it to ext4 when the quarantine is over.

This is my last BTRFS filesystem.  One was on a laptop hard disk that
was painfully slow, especially when compared with it's ext4 twin
sitting next to it.  It was reformatted to ext4.  I also had a BTRFS
RAID 0 hard disk array.  It was also slow and also ended up needing
rescue.  I converted it over to xfs on MD raid and it's been faster
and perfectly reliable ever since.

While I like subvolumes and snapshots, I find the maintenance,
reliability, and performance overhead to be not worth it.

Not recommended.



Generally speaking btrfs performance has been the same if not better for our 
workloads.  This is millions of boxes with thousands of different workloads and 
performance requirements.


That being said I can make btrfs look really stupid on some workloads.  There's 
going to be cases where Btrfs isn't awesome.  We still use xfs for all our 
storage related tiers (think databases).  Performance is always going to be 
workload dependent, and Btrfs has built in overhead out the gate because of 
checksumming and the fact that we generate far more metadata.


As for your ENOSPC issue, I've made improvements on that area.  I see this in 
production as well, I have monitoring in place to deal with the machine before 
it gets to this point.  That being said if you run the box out of metadata space 
things get tricky to fix.  I've been working my way down the list of issues in 
this area for years, this last go around of patches I sent were in these corner 
cases.


I described this case to the working group last week, because it hit us in 
production this winter.  Somebody screwed up and suddenly pushed 2 extra copies 
of the whole website to everybody's VM.  The website is mostly metadata, because 
of the inline extents, so it exhausted everybody's metadata space.  Tens of 
thousands of machines affected.  Of those machines I had to hand boot and run 
balance on ~20 of them to get them back.  The rest could run balance from the 
automation and recover cleanly.


It's a shit user experience, and its a shitty corner case that still needs work. 
 It's a top priority of mine.  Thanks,


Josef
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Markus Larsson]

On 26 June 2020 21:04:00 CEST, Michael Catanzaro  wrote:
>On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson  
>wrote:
>> I strongly agree. BTRFS has been 5 years from production ready for 
>> almost a decade now, please don't force this on users that doesn't 
>> know any better.
>
>This is hard to square with the fact that it's already being used in 
>production on millions of systems. It's also hard to square with the 
>data presented by Josef -- the only hard evidence I've seen on the 
>topic of filesystem reliability -- which shows btrfs is an order of 
>magnitude more reliable than xfs (although we don't know how it 
>compares to ext4). Surely if xfs is good enough for RHEL, and btrfs is 
>at least 10x more reliable than xfs, that suggests btrfs should 
>probably be good enough for Fedora?
>
>Do you have any real evidence for your claim that would be more 
>convincing than what Josef has presented?

Josef's server parks is a bit of a different use case than laptops as other 
people has already pointed out.
If you want data on how it works in a desktop/laptop scenario talk to openSUSE 
users about how many times the "btrfs randomly ate my volume"-bug was "fixed".

When I ran an environment of about 4500 SLES and about 5000 RHEL servers btrfs 
failed about 3 times as often as xfs (this from our own in-house statistics). 
That was 3 years ago but filesystems takes long to mature and I have been 
keeping ear near openSUSE to see where it goes.
Is this as big as Josef's environment? No but it is first hand data to me (to 
you it is of course just anecdotal evidence)

BTRFS has the potential to become great, I just think it isn't there yet and 
it'll take 5 years of smooth sailing to convince me.

>
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives: 
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200626.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200624.n.0
NEW: Fedora-Rawhide-20200626.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  14
Dropped packages:0
Upgraded packages:   241
Downgraded packages: 0

Size of added packages:  27.40 MiB
Size of dropped packages:0 B
Size of upgraded packages:   4.37 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   59.96 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: bst-external-0.20.0-2.fc33
Summary: Additional BuildStream plugins
RPMs:bst-external
Size:93.45 KiB

Package: gnucobol-3.1-3.fc33
Summary: COBOL compiler
RPMs:gnucobol libcob
Size:3.50 MiB

Package: golang-github-elves-elvish-0.13.1-1.fc33
Summary: Friendly Interactive Shell and Expressive Programming Language
RPMs:golang-github-elves-elvish golang-github-elves-elvish-devel
Size:18.59 MiB

Package: golang-github-mingrammer-commonregex-1.0.1-1.fc33
Summary: A collection of common regular expressions for Go
RPMs:golang-github-mingrammer-commonregex-devel
Size:14.78 KiB

Package: libsoundio-2.0.0-2.fc33
Summary: C library for cross-platform real-time audio input and output
RPMs:libsoundio libsoundio-devel libsoundio-doc libsoundio-utils
Size:737.30 KiB

Package: luv-icon-theme-0.4.9.31-2.20200623git42387fe9.fc33
Summary: Flat, but complex, icon theme
RPMs:luv-icon-theme luv-wallpapers
Size:1.79 MiB

Package: mingw-python-itsdangerous-1.1.0-2.fc33
Summary: MinGW Windows Python itsdangerous library
RPMs:mingw32-python3-itsdangerous mingw64-python3-itsdangerous
Size:67.80 KiB

Package: mingw-python-jinja2-2.11.2-2.fc33
Summary: MinGW Windows Python jinja2 library
RPMs:mingw32-python3-jinja2 mingw64-python3-jinja2
Size:445.37 KiB

Package: mkdocs-bootswatch-1.1-2.fc33
Summary: Bootswatch themes for MkDocs
RPMs:mkdocs-bootswatch
Size:118.32 KiB

Package: nodejs-pg-protocol-1.2.4-1.fc33
Summary: The postgres client/server binary protocol
RPMs:nodejs-pg-protocol
Size:21.77 KiB

Package: odhcp6c-0-0.5.20200416gitf575351.fc33
Summary: Embedded DHCPv6 and RA client
RPMs:odhcp6c
Size:248.92 KiB

Package: python-textwrap3-0.9.2-1.fc33
Summary: Text wrap backport
RPMs:python3-textwrap3
Size:20.95 KiB

Package: rust-ostree-0.7.2-1.fc33
Summary: Rust bindings for libostree
RPMs:rust-ostree+default-devel rust-ostree+dox-devel 
rust-ostree+v2014_9-devel rust-ostree+v2015_7-devel rust-ostree+v2016_14-devel 
rust-ostree+v2016_4-devel rust-ostree+v2016_5-devel rust-ostree+v2016_6-devel 
rust-ostree+v2016_7-devel rust-ostree+v2016_8-devel rust-ostree+v2017_1-devel 
rust-ostree+v2017_10-devel rust-ostree+v2017_11-devel 
rust-ostree+v2017_12-devel rust-ostree+v2017_13-devel 
rust-ostree+v2017_15-devel rust-ostree+v2017_2-devel rust-ostree+v2017_3-devel 
rust-ostree+v2017_4-devel rust-ostree+v2017_6-devel rust-ostree+v2017_7-devel 
rust-ostree+v2017_8-devel rust-ostree+v2017_9-devel rust-ostree+v2018_2-devel 
rust-ostree+v2018_3-devel rust-ostree+v2018_5-devel rust-ostree+v2018_6-devel 
rust-ostree+v2018_7-devel rust-ostree+v2018_9-devel rust-ostree+v2019_2-devel 
rust-ostree+v2019_3-devel rust-ostree+v2019_4-devel rust-ostree+v2019_6-devel 
rust-ostree+v2020_1-devel rust-ostree-devel
Size:294.07 KiB

Package: rust-ssh-key-dir-0.1.1-1.fc33
Summary: sshd AuthorizedKeysCommand to read ~/.ssh/authorized_keys.d
RPMs:ssh-key-dir
Size:1.51 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  COPASI-4.28.226-2.fc33
Old package:  COPASI-4.28.226-1.fc33
Summary:  Biochemical network simulator
RPMs: COPASI COPASI-data COPASI-doc COPASI-gui python3-COPASI
Size: 113.22 MiB
Size change:  -18.34 KiB
Changelog:
  * Wed Jun 24 2020 Antonio Trande  - 4.28.226-2
  - BuildRequires python-setuptools explicitly


Package:  ImageMagick-1:6.9.11.21-1.fc33
Old package:  ImageMagick-1:6.9.11.16-1.fc33
Summary:  An X application for displaying and manipulating images
RPMs: ImageMagick ImageMagick-c++ ImageMagick-c++-devel 
ImageMagick-devel ImageMagick-djvu ImageMagick-doc ImageMagick-libs 
ImageMagick-perl
Size: 40.06 MiB
Size change:  31.74 KiB
Changelog:
  * Mon Jun 22 2020 Jitka Plesnikova  - 1:6.9.11.16-2
  - Perl 5.32 rebuild

  * Thu Jun 25 2020 Michael Cronenworth  - 1:6.9.11.21-1
  - Update to 6.9.11.21


Package:  OpenMolcas-19.11-3.fc33
Old package:  OpenMolcas-19.11-2.fc33
Summary:  A multiconfigurational quantum chemistry software package
RPMs: OpenMolcas
Size: 78.06 MiB
Size change:  35.60 KiB
Changelog:
  * Thu Jun 25 2020 Susi Lehtola  - 19.11-3
  - Explicit buildrequire python3-setuptools.


Package:  ProDy-1.10.10-8.fc33
Old package:  ProDy-1.10.10-7.fc33
Summary:  Application for protein structure, dynamics and sequence analysis
RPMs: python3-ProDy
Size: 6.80 MiB
Size

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Michael Catanzaro]

On Fri, Jun 26, 2020 at 12:58 pm, James Szinger  
wrote:

Yes, it happened to me last week.  The workstation has been upgraded
since F25 and is now at F31.  A yum update last week ran a restorecon
-r / which filled up the filesystem and RAM and swap.  The 460 GB
filesystem had about 140GB of real data, 100 GB of data bloat from
underfull blocks, and the rest (200GB) was metadata.  I had to boot
from a live USB and run btrfs balance to free up the bloat.  I expect
to reformat it to ext4 when the quarantine is over.


Could the proposal owners comment on this, please? Sounds really bad.

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

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Michael Catanzaro]

On Fri, Jun 26, 2020 at 8:45 pm, Markus Larsson  
wrote:
I strongly agree. BTRFS has been 5 years from production ready for 
almost a decade now, please don't force this on users that doesn't 
know any better.


This is hard to square with the fact that it's already being used in 
production on millions of systems. It's also hard to square with the 
data presented by Josef -- the only hard evidence I've seen on the 
topic of filesystem reliability -- which shows btrfs is an order of 
magnitude more reliable than xfs (although we don't know how it 
compares to ext4). Surely if xfs is good enough for RHEL, and btrfs is 
at least 10x more reliable than xfs, that suggests btrfs should 
probably be good enough for Fedora?


Do you have any real evidence for your claim that would be more 
convincing than what Josef has presented?


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Todd Zullinger]

I wrote:
> Zdenek Dohnal wrote:
>> CCing Git maintainer to see whether it can be implemented or not.

I somehow forgot to say that I'm just one of several
maintainers for the git package.  :)

I've Cc'd the git-maintainers alias to include the other
folks.

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[James Szinger]

On Fri, 26 Jun 2020 12:30:02 -0500
Chris Adams  wrote:
> So... I freely admit I have not looked closely at btrfs in some time,
> so I could be out of date (and my apologies if so).  One issue that I
> have seen mentioned as an issue within the last week is still the
> problem of running out of space when it still looks like there's
> space free.  I didn't read the responses, so not sure of the
> resolution, but I remember that being a "thing" with btrfs.  Is that
> still the case?  What are the causes, and if so, how can we keep from
> getting a lot of the same question on mailing lists/forums/etc.?

Yes, it happened to me last week.  The workstation has been upgraded
since F25 and is now at F31.  A yum update last week ran a restorecon
-r / which filled up the filesystem and RAM and swap.  The 460 GB
filesystem had about 140GB of real data, 100 GB of data bloat from
underfull blocks, and the rest (200GB) was metadata.  I had to boot
from a live USB and run btrfs balance to free up the bloat.  I expect
to reformat it to ext4 when the quarantine is over.

This is my last BTRFS filesystem.  One was on a laptop hard disk that
was painfully slow, especially when compared with it's ext4 twin
sitting next to it.  It was reformatted to ext4.  I also had a BTRFS
RAID 0 hard disk array.  It was also slow and also ended up needing
rescue.  I converted it over to xfs on MD raid and it's been faster
and perfectly reliable ever since.

While I like subvolumes and snapshots, I find the maintenance,
reliability, and performance overhead to be not worth it.

Not recommended.

Jim
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Markus Larsson]

On 26 June 2020 16:58:19 CEST, Vitaly Zaitsev via devel 
 wrote:
>On 26.06.2020 16:42, Ben Cotton wrote:
>> For laptop and workstation installs of Fedora, we want to provide file
>> system features to users in a transparent fashion. We want to add new
>> features, while reducing the amount of expertise needed to deal with
>> situations like [https://pagure.io/fedora-workstation/issue/152
>> running out of disk space.] Btrfs is well adapted to this role by
>> design philosophy, let's make it the default.
>
>I'm strongly against this proposal. BTRFS is the most unstable file
>system I ever seen. It can break up even under an ideal conditions and
>lead to a complete data loss. There are lots of complaints and bug
>reports in Linux kernel bugzilla and Reddit.
>
>Such changes could affect Fedora reputation among other distributions.
>

I strongly agree. BTRFS has been 5 years from production ready for almost a 
decade now, please don't force this on users that doesn't know any better.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Package Review SELinux help

[Robert-André Mauchin]

Hello,


I know next to nothing about SELinux so I'd like some help about the Bitcoin 
Package Review by negativo17: 

https://bugzilla.redhat.com/show_bug.cgi?id=1834731

Notably: are the bitcoin.{te,fc,if} files are sane?
Are they installed properly in the SPEC? Especially these parts:

%post server
%systemd_post %{name}.service
for selinuxvariant in %{selinux_variants}
do
/usr/sbin/semodule -s ${selinuxvariant} -i \
%{_datadir}/selinux/${selinuxvariant}/%{name}.pp \
&> /dev/null || :
done
# FIXME This is less than ideal, but until dwalsh gives me a better way...
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8332 2> /dev/null
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 8333 2> /dev/null
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18332 2> /dev/null
/usr/sbin/semanage port -a -t %{name}_port_t -p tcp 18333 2> /dev/null
/sbin/fixfiles -R %{name}-server restore &> /dev/null || :
/sbin/restorecon -R %{_localstatedir}/lib/%{name} || :

%postun server
%systemd_postun_with_restart %{name}.service
if [ $1 -eq 0 ] ; then
# FIXME This is less than ideal, but until dwalsh gives me a better way...
/usr/sbin/semanage port -d -p tcp 8332
/usr/sbin/semanage port -d -p tcp 8333
/usr/sbin/semanage port -d -p tcp 18332
/usr/sbin/semanage port -d -p tcp 18333
for selinuxvariant in %{selinux_variants}
do
/usr/sbin/semodule -s ${selinuxvariant} -r %{name} \
&> /dev/null || :
done
/sbin/fixfiles -R %{name}-server restore &> /dev/null || :
[ -d %{_localstatedir}/lib/%{name} ] && \
/sbin/restorecon -R %{_localstatedir}/lib/%{name} \
&> /dev/null || :
fi

Please comment in the RR if you can help.

I find the documentation at https://fedoraproject.org/wiki/SELinux rather old 
and not really focused on the packaging side of it. Is there guidelines 
anywhere else?

Best regards,

Robert-André


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Markus Larsson]

On 26 June 2020 20:08:53 CEST, Robert Relyea  wrote:
>On 6/25/20 12:58 PM, Jonathan Wakely wrote:
>>
>>
>> Anyway, I find it hard to believe that serious developers are
>> unable/unwilling to set their own choice of EDITOR. A systemwide
>> default EDITOR=nano shouldn't cause them any real difficulty.
>
>
>I second that. I'm the guy who gets annoyed at non-vi editors because I 
>tend to fill files in them with hjkl's due to muscle memory of 40 years 
>of vi usage. You'll pull vi out of my cold dead hands. I'm still quite 
>capable of setting  $EDITOR in my own startup files. Pretty much anyone 
>that has figured out and prefers vi (or emacs or whatever) knows how to 
>set $EDITOR.

That's not really the point. The point is that yet again more or less fictional 
future users needs comes before the needs of current actual users.
As time goes by it seems the list of configuration changes needed to make a 
system usable (subjectively yes) grows.
What was default was changed and since doing it the easy way only annoyed 
current users the easy way was chosen.
I'm getting tired of this but I guess it's time to accept that I'm just one of 
those grumpy old neckbeard now.

Markus
>___
>devel mailing list -- devel@lists.fedoraproject.org
>To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>Fedora Code of Conduct: 
>https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>List Archives: 
>https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[niccolo . belli]

I couldn't believe it either when I saw the proposal, so 2010-ish :)

Anyway I'm in great favour of this proposal and I'd love to see btrfs the 
default.
I personally use it in all of my systems (desktops, laptops and workstations) 
except for servers, where it lacks the reliability on some raid configurations 
I use (instead I use zfs, which also supports native encryption).
I had my share of issues in the early days but it has proven to be extremely 
reliable lately.
My biggest complain nowadays is this: https://lwn.net/Articles/674865/
Not being able to mount partitions of my Raptor Talos Power 9 into my x86 
systems annoys me, but I guess it shouldn't bother many people. On the other 
side I had lots of hardware issues on my Raptor machine and my btrfs hourly 
snapshots already saved my day multiple times (latest one was while upgrading 
from Fedora 31 to 32). Would love to see it the default, possibly with full 
grub rollback integration.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 07:04:51PM +0100, Jonathan Wakely wrote:
> On 26/06/20 13:23 -0400, Neil Horman wrote:
> > Heres a thought that I hadn't considered before though, and it might be 
> > useful.
> > Apple at one point (and still may), shiped iphones without the itunes (or 
> > some
> > common) app on it,
> > and they did so intentionally, because they knew it was an app that people
> > wanted, and it forced them into a sort of 'training mission' in which they 
> > had
> > to use the app store on their phone to find and install the itunes app.  It 
> > gave
> > end users, after their initial disgruntledness, the skills to install new 
> > apps
> > on their phone, and explore how some of the system worked.
> 
> That's not about learning useful life skills, it's about forcing them
> to visit the money-making machine.
> 
ulterior motives asside, the goal was still to implicitly teach the end users
how to use a central tool in their environment.

> I don't think "I had to learn vi and it never did me any harm, new
> users should have to as well" is really the right approach for the
> distro.
> 
I'm not sure how you got that out of my comment above, but it certainly wasn't
my intent.  All I was trying to say was, orthogonal to the choice of default
editor, part of the frustration here seems to be not only understanding how vi
works but how to go about changing it if it doesn't work for you (as suggested
by the large number of searches for vi help, and the relatively non-existant
number of searches for "how do I change my default editor in linux".  I was
suggesting that some sort of introductory guide during install might mitigate
that.

> Shut up and learn vi, it's for your own good. And eat your vegetables
> or you won't get dessert.
Ok, that a bit over the line.  Please don't twist my words.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 12:50:52PM -0500, Michael Catanzaro wrote:
> That actually works really well, and we should seriously consider
> doing it. Or at least suggesting it to upstream.
> 
> It doesn't even take extra space. Only uses the bottom row that
> would otherwise be empty.

Fine :) https://github.com/gwsw/less/issues/72


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Robert Relyea]

On 6/25/20 12:58 PM, Jonathan Wakely wrote:



Anyway, I find it hard to believe that serious developers are
unable/unwilling to set their own choice of EDITOR. A systemwide
default EDITOR=nano shouldn't cause them any real difficulty.



I second that. I'm the guy who gets annoyed at non-vi editors because I 
tend to fill files in them with hjkl's due to muscle memory of 40 years 
of vi usage. You'll pull vi out of my cold dead hands. I'm still quite 
capable of setting  $EDITOR in my own startup files. Pretty much anyone 
that has figured out and prefers vi (or emacs or whatever) knows how to 
set $EDITOR.


bob
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 13:23 -0400, Neil Horman wrote:

Heres a thought that I hadn't considered before though, and it might be useful.
Apple at one point (and still may), shiped iphones without the itunes (or some
common) app on it,
and they did so intentionally, because they knew it was an app that people
wanted, and it forced them into a sort of 'training mission' in which they had
to use the app store on their phone to find and install the itunes app.  It gave
end users, after their initial disgruntledness, the skills to install new apps
on their phone, and explore how some of the system worked.


That's not about learning useful life skills, it's about forcing them
to visit the money-making machine.

I don't think "I had to learn vi and it never did me any harm, new
users should have to as well" is really the right approach for the
distro.

Shut up and learn vi, it's for your own good. And eat your vegetables
or you won't get dessert.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Jonathan Wakely]

On 26/06/20 19:15 +0200, David Kaufmann wrote:

On Fri, Jun 26, 2020 at 03:42:39PM +0100, Jonathan Wakely wrote:

"In the last year, How to exit the Vim editor has made up about .005%
of question traffic: that is, one out of every 20,000 visits to Stack
Overflow questions. That means during peak traffic hours on weekdays,
there are about 80 people per hour that need help getting out of Vim."


Please don't just simply take that number as "number of people trying to
exit vim"
One of those threads on stackoverflow was a highly popular meme and was
featured in quite many webpages.
I myself probably visited that thread about 5 to 10 times despite being
a vim user for about 10 years now, just because I was provided with the
link to that specific thread or because I wanted to show someone that
thread.


Agreed. I've never tried to use regular expressions to parse XML* but
I've visited https://stackoverflow.com/a/1732454/981959 dozens of
times.


* ok, maybe once or twice.

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Catanzaro]

On Fri, Jun 26, 2020 at 10:15 am, Adam Williamson 
 wrote:

On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:


 Also, have we asked the question, what default editor are other 
distros setting?

 I've honestly never looked.


I believe no major distro currently sets $EDITOR, so we would be the 
first.


Debian/Ubuntu/Mint use https://salsa.debian.org/debian/sensible-utils 
for this. I checked Ubuntu yesterday and they build git with 
DEFAULT_EDITOR=editor, which chooses nano. (They also use 
DEFAULT_PAGER=pager, which I guess is how you would allow configuring 
'most'.)


An earlier version of the change proposal involved packaging up these 
Debain tools, but I suggested that setting $EDITOR would be a whole lot 
easier.


On the other hand, if we were to package sensible-utils, it's likely 
other independent distros would follow, and we would turn it into a 
cross-distro standard. So it's worth considering.


Michael

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[David Cantrell]

On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote:

On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:

On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
> > From this thread you can find at least two people (me and Ben
> > Rosser)
> > who definitely didn't keep using vi (my very next questions were
> > "what's an easier editor to use?" and "how do I change the default
> > editor to something else?"), and are still sufficiently frazzled by
> > the
> > experience that we still refuse to. :P

> Right, and I acutally think thats great.  You had a problem, you
> asked the
> questions you needed answers to, and solved your problem.  I
> personally think
> the process of identifying whats bothering you, figuring out a
> solution (by
> asking questions, getting answers and experimenting), and then
> implementing your
> fix is actually a pretty good user experience in and of itself
> (though that may
> just be me). :)

That is not how it felt at the time :P

It's really the point about Unexpected Forcible Learning. If I sit down
at my computer and think "right, I'm going to learn to do X", that's
one thing. I am mentally prepared to spend some time stumbling around
working out how to do X.

The problem with this experience is that's not how it happens. You
don't sit down and thinking "today I'm going to learn how to use vi" or
"today I'm going to learn about console text editors and the $EDITOR
variable". You were intending to do something else, and you were
suddenly sandbagged by this fracking weird thing you have no idea what
it is that got in the way of the something else you were trying to do.

Yes, eventually you learn something, but it's not a "pretty good user
experience", it is a frustrating and annoying one.


But thats more or less the expectation of unix and unix like systems.  For all
the porcelain and chrome we've put around it, under the covers, its all still a
bag of parts, and the expectation is (or should be) when using a bag of parts,
you will have to learn how several of those parts work (be it vi or nano when
using git, or substitue your tool of choice here).  You start with a tool, you
relize it relies on another tool, so you have to push it down the stack and
figure out the new tool as part of the overall process.

I'll share a simmilar experience to commiserate.  During this thread, I went to
go confirm that eclipse actually used its own internal git editor for adding
commit messages. Thought it was going to be easy.  Quickly realized that eclipse
didn't come with git integration out of the box, so I had to go figure out how
to get git support in, then how to configure it, then how to interface to it.
It all felt like kinda the same tool, because it all happened in one of a few
related windows, but its really learning several disparate tools, and thats ok.
I still don't like using eclipse, but not because it made me go figure out
several new tools, I don't like it because it seems nuts to me to have an IDE
with a 400M Resident set size to edit ascii text. :)

Heres a thought that I hadn't considered before though, and it might be useful.
Apple at one point (and still may), shiped iphones without the itunes (or some
common) app on it,
and they did so intentionally, because they knew it was an app that people
wanted, and it forced them into a sort of 'training mission' in which they had
to use the app store on their phone to find and install the itunes app.  It gave
end users, after their initial disgruntledness, the skills to install new apps
on their phone, and explore how some of the system worked.


I'm not sure that's a good comparison.  Are we trying to force train new vi
users or gain new Fedora users and developers?  Fedora doesn't have a business
interest in users being forced to learn vi like Apple does with users learning
to use the App Store.


Would that be a possibility here?  I've upgraded my fedora workstation so many
times, I'm not sure what our firstboot screens look like anymore, but would it
be worthwhile to present users with some text, or a guide wizard, to point out
files like their ~/.bashrc file with some commented text that shows clearly what
some useful environment variables are, and how they might set them to customize
their experience?  Its not very 'just press the button to do something you may
or may not understand', but it targets new users as part of firstboot, and
introduces them in a somewhat friendly way to how things look under the covers,
so they can make adjustments as their needs dictate.  Even if they don't do it
immediately, they will have a reference to something they can recall if they
find later that their choice of editor is not something they are comfortable
with.


Sounds like something suitable for gnome-initial-setup.  I think /etc/motd
with that info would be useful on the non-workstation releases.  Slackware
always installed a "welcome" email to the root user with similar info.
OpenBSD has 'man afterboot'.  

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Michael Catanzaro]

On Fri, Jun 26, 2020 at 1:00 pm, Matthew Miller 
 wrote:
... that would actually be really easy to do, since a patch isn't 
necessary.


export LESS='-MPM?f%f .?n?m(%T %i of %m) ..?ltlines %lt-%lb?L/%L. 
:byte %bB?s/%s. .?e(END) ?x- Next\: %x.:?pB%pB\%..%t (h for help or q 
to quit)'


But let's not get ahead of ourselves. :)


That actually works really well, and we should seriously consider doing 
it. Or at least suggesting it to upstream.


It doesn't even take extra space. Only uses the bottom row that would 
otherwise be empty.


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 10:43:10AM -0700, Adam Williamson wrote:
> On Fri, 2020-06-26 at 13:37 -0400, Neil Horman wrote:
> > > 
> > > Mint's default seems to be nano, though like openSUSE, it is doing this
> > > some way other than by setting $EDITOR.
> > > 
> > Mints just a derivative of openSuse, isn't it?  It would make sense that 
> > this
> > followed.
> 
> I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it
> in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave
> like openSUSE, it doesn't have the weird mix - for all three tests I
> used (visudo, git, systemctl edit) I got nano.
> 
> > > So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using
> > > nano is pretty significant.
> > > 
> > Yeah, but significant in what way?  We have two fairly popular distributions
> > using nano, but over 1,000,000 people trying to figure out how to exit vi on
> > stackexchange.  Is the user base for other distros defaulting to vi just 
> > that
> > much bigger?
> 
> Dunno. Maybe if Debian and Ubuntu defaulted to vi there'd be 5,000,000
> people? :D
Possibly :)

I guess the real conclusion we can imply here is that new users just use
whatever the default is.

> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Randy Barlow]

On 6/25/20 1:54 PM, Randy Barlow wrote:

I would like to counter propose that we make ed the default editor :P


Just in case it wasn't clear, I was joking here. I support nano as a 
default. Let's make Fedora easier for new users, especially those who 
are new to the command line and/or Linux.

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neal Gompa]

On Fri, Jun 26, 2020 at 1:45 PM Adam Williamson
 wrote:
>
> On Fri, 2020-06-26 at 13:37 -0400, Neil Horman wrote:
> > >
> > > Mint's default seems to be nano, though like openSUSE, it is doing this
> > > some way other than by setting $EDITOR.
> > >
> > Mints just a derivative of openSuse, isn't it?  It would make sense that 
> > this
> > followed.
>
> I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it
> in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave
> like openSUSE, it doesn't have the weird mix - for all three tests I
> used (visudo, git, systemctl edit) I got nano.
>

Linux Mint is a derivative of Ubuntu, thus is a member of the Debian family.

> > > So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using
> > > nano is pretty significant.
> > >
> > Yeah, but significant in what way?  We have two fairly popular distributions
> > using nano, but over 1,000,000 people trying to figure out how to exit vi on
> > stackexchange.  Is the user base for other distros defaulting to vi just 
> > that
> > much bigger?
>
> Dunno. Maybe if Debian and Ubuntu defaulted to vi there'd be 5,000,000
> people? :D

Probably! :D


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 10:43:10AM -0700, Adam Williamson wrote:
> > Mints just a derivative of openSuse, isn't it? It would make sense that
> > this followed.
> I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it
> in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave
> like openSUSE, it doesn't have the weird mix - for all three tests I
> used (visudo, git, systemctl edit) I got nano.

It is an Ubuntu derivative, with a back-up version which pulls directly from
Debian.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Neal Gompa]

On Fri, Jun 26, 2020 at 1:31 PM Chris Adams  wrote:
>
> Once upon a time, Ben Cotton  said:
> > For laptop and workstation installs of Fedora, we want to provide file
> > system features to users in a transparent fashion. We want to add new
> > features, while reducing the amount of expertise needed to deal with
> > situations like [https://pagure.io/fedora-workstation/issue/152
> > running out of disk space.] Btrfs is well adapted to this role by
> > design philosophy, let's make it the default.
>
> So... I freely admit I have not looked closely at btrfs in some time, so
> I could be out of date (and my apologies if so).  One issue that I have
> seen mentioned as an issue within the last week is still the problem of
> running out of space when it still looks like there's space free.  I
> didn't read the responses, so not sure of the resolution, but I remember
> that being a "thing" with btrfs.  Is that still the case?  What are the
> causes, and if so, how can we keep from getting a lot of the same
> question on mailing lists/forums/etc.?
>

Josef gave a fairly detailed answer upthread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F5FYHGND4DHLN5R5ZIT2DF3VYI6TIAUR/

However, I'll give some of my own color on this, as well. I have not
personally experienced this issue on any of my systems in the past
three years. I experienced it a couple of times when I first started
out using it in 2014~2015, but it's not been a problem for me since.

We could stand to have some improved documentation here, and I hope
this is something we can build up to support our user community. I'm
sure there's some documentation from our friends at openSUSE that we
can borrow as well.

> I'm pretty neutral on this... I run a bunch of RHEL/CentOS systems, so I
> tend to stick close to that on my Fedora systems (so I'd probably stick
> with ext4/xfs on LVM myself).  I remember when btrfs was going to be the
> one FS to rule them all, but then had issues, and specific weird cases
> (like with VM images IIRC at one point), and kind of fell of my map
> then.  That is not intended as a criticism - filesystems are complex,
> and developing them hard... I think some of the reputation came from
> some people pushing btrfs before it was really ready.
>

I absolutely agree. I've often wondered if Btrfs would have a better
reputation if it was developed for a few years behind closed doors
before being unveiled. I think the way people perceive the filesysetm
would be very different then.

Thankfully, I think today we're in a very good place with Btrfs
upstream, and having Josef (an upstream Btrfs developer) helping drive
this in Fedora makes me very confident in this change.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Fri, 2020-06-26 at 13:37 -0400, Neil Horman wrote:
> > 
> > Mint's default seems to be nano, though like openSUSE, it is doing this
> > some way other than by setting $EDITOR.
> > 
> Mints just a derivative of openSuse, isn't it?  It would make sense that this
> followed.

I thought it was a derivative of Debian and/or Ubuntu? Wikipedia has it
in the 'Ubuntu derivatives' category. But anyhow, it doesn't behave
like openSUSE, it doesn't have the weird mix - for all three tests I
used (visudo, git, systemctl edit) I got nano.

> > So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using
> > nano is pretty significant.
> > 
> Yeah, but significant in what way?  We have two fairly popular distributions
> using nano, but over 1,000,000 people trying to figure out how to exit vi on
> stackexchange.  Is the user base for other distros defaulting to vi just that
> much bigger?

Dunno. Maybe if Debian and Ubuntu defaulted to vi there'd be 5,000,000
people? :D
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote:
> But thats more or less the expectation of unix and unix like systems. For
> all the porcelain and chrome we've put around it, under the covers, its
> all still a bag of parts, and the expectation is (or should be) when using
> a bag of parts, you will have to learn how several of those parts work (be
> it vi or nano when using git, or substitue your tool of choice here). You
> start with a tool, you relize it relies on another tool, so you have to
> push it down the stack and figure out the new tool as part of the overall
> process.

So *my* expectation is that as a distro, part of the value we add is
to take those parts and provide them to users in a coherent way that
addresses their problems. We want to provide a "bag of parts" to people _in
the Fedora Project_, but we want to enable those groups to provide assembled
sets to their users.

> Would that be a possibility here? I've upgraded my fedora workstation so
> many times, I'm not sure what our firstboot screens look like anymore, but
> would it be worthwhile to present users with some text, or a guide wizard,
> to point out files like their ~/.bashrc file with some commented text that
> shows clearly what some useful environment variables are, and how they
> might set them to customize their experience? Its not very 'just press the
> button to do something you may or may not understand', but it targets new
> users as part of firstboot, and introduces them in a somewhat friendly way
> to how things look under the covers, so they can make adjustments as their
> needs dictate. Even if they don't do it immediately, they will have a
> reference to something they can recall if they find later that their
> choice of editor is not something they are comfortable with.

I don't think this is the experience most Fedora Workstation users are
looking for. But I'd totally support the creation of a "Learn Linux!" Fedora
spin with this kind of pedagogical self-teaching focus.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Justin Forbes]

On Fri, Jun 26, 2020 at 10:30 AM Lennart Poettering
 wrote:
>
> On Fr, 26.06.20 10:42, Ben Cotton (bcot...@redhat.com) wrote:
>
> > https://fedoraproject.org/wiki/Changes/BtrfsByDefault
>
> If this is decided to be the way to go, please work with kernel
> maintainers to make btrfs.ko a built-in kernel module, so that
> initrd-less boots work... (it's kinda pointless anyway to have
> something as module that is now gonna used by most people anyway, it
> just slows things down for little benefit)
>

That would make sense if this were decided.  My big issue with this is
we have no internal RH expertise on btrfs, and would be entirely
dependent on the upstream community for support. There are instances
of CVEs that get ignored for long periods of time,  CVE-2019-19378 and
CVE-2019-19448 being the current examples, with the later being not a
huge deal, but still an outstanding CVE.  In general btrfs CVEs tend
to stick around longer than XFS and ext4 before a fix is pushed
upstream.   The Fedora kernel supports btrfs, it has for quite some
time, and that doesn't change regardless of the outcome of this
proposal.   I honestly cannot tell you what the stability would be
like spread across the majority of fedora users, because not being
default, the typical btrfs user probably currently has a better
understanding of what they are getting into.   While the lack of
internal RH expertise makes me lean against this proposal, I believe
the Desktop SIG with FESCo should be able to make the decisions for
defaults on the desktop spin.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 10:15:45AM -0700, Adam Williamson wrote:
> On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
> > 
> > Also, have we asked the question, what default editor are other distros 
> > setting?
> > I've honestly never looked.
> 
> The Change page says "More in line with the default editor of other
> distributions." But it doesn't give more detail, so I did a bit of
> research!
> 
Thanks!

> Ubuntu's default is nano, per various search results.
> 
> openSUSE's (I tested the Leap 15.1 GNOME live image) is...mostly vi,
> though this is implemented some other way than $EDITOR, because `echo
> $EDITOR` shows nothing. `visudo` and `git commit` run vi, but
> `systemctl edit` runs nano. Not sure what's going on there.
> 
I know git hard codes vi as the final default, so that tracks, I'm not sure how
visudo and systemctl pick an editor.  Etiher way, whatever we pick, we probably
shouldn't implement it like this.

> At least as of 2015, Arch considered changing to nano but stuck with
> vi, though one of their key arguments at the time was "everyone else
> uses vi", and it seems the issue was slightly complicated by the
> question of what packages would or wouldn't be in their 'core':
> https://lists.archlinux.org/pipermail/arch-dev-public/2015-April/027133.html
> As of 2019 it still seems to be vi:
> https://bbs.archlinux.org/viewtopic.php?id=245675
> 
> Mint's default seems to be nano, though like openSUSE, it is doing this
> some way other than by setting $EDITOR.
> 
Mints just a derivative of openSuse, isn't it?  It would make sense that this
followed.

> So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using
> nano is pretty significant.
> 
Yeah, but significant in what way?  We have two fairly popular distributions
using nano, but over 1,000,000 people trying to figure out how to exit vi on
stackexchange.  Is the user base for other distros defaulting to vi just that
much bigger?

> > > Don't focus on git. It's not just about git. git was just a convenient
> > > example of something that launches the default text editor.
> > > 
> > Sure, we can substitue any other tool here that has to fork an editor from 
> > the
> > command line, and some of those will be far more in line with what a novice
> > non-developer might use.  I just think for those users, nano likely isn't 
> > going
> > to move the needle much, and I'm not sure how many of those users Fedora 
> > gets,
> > or looses on this point.  I know we can't really get that data, but it sure
> > would be great to have.
> > 
> > > > So the user you are describing
> > > > 
> > > > 1) Isn't skilled in command line usage
> > > > 2) Chose to use the command line anyway, despite having a littany of 
> > > > IDE's
> > > > available
> > > > 3) Was sufficiently well versed in development process to chose to use 
> > > > an SCM,
> > > > and to search for commands to work with it (setting asside their lack of
> > > > understanding of what they were doing)
> > > > 4) But wasn't sufficiently well versed enough to go back and find out 
> > > > how to use
> > > > the editor that their scm choice chose to default to
> > > > 
> > > > I just don't see that that person really exists.
> > > 
> > > There are literally multiple people in the thread telling you this
> > > literally happened to them or to people they know who asked them for
> > > help. I am one of them.
> > I think thats an overstatement.  If it isnt, I apologize, but I really have 
> > a hard
> > time believing that they comply with 1-3 (those are entirely believable), 
> > but
> > then threw their hands up in the air when confronted with a window that they
> > could sort of edit text in.  As shown above, typing "I typed  in and this
> > wierd screen poped up that I could kind of edit" into google answered that
> > question in the top result.
> 
> Sure, like I wrote elsewhere in the thread, it's probably less of a
> complete roadblock than it used to be. But it's still an unnecessary
> pain point. Yes, people can probably get through it in fifteen minutes
> these days, but it's still unnecessarily annoying. Why cause them the
> trouble?
Thats a fair question.  I thinik the best answer I could give is one of balance.
I can't argue that it may be a pain point for new users, but for our existing
user base, the change to something else is a hassle (arguably less of a hassle
because they have learned how to set the default to what they want, but I never
like the idea of our creating more work for our existing users when we don't
know that an equally large portion of new users will benefit).  I say that
keeping in mind that we're assuming that new users will struggle with vi, I
think its also possible that new users will have my good experience with this
sort of roadblock, as much so as the negative experience you had.

Neil

> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 12:12:52PM -0500, Chris Adams wrote:
> I believe $EDITOR is supposed to just be an executable that can be
> passed directly to exec(), so I don't think you can include arguments in
> it.

I tried it -- it works with git, crontab, and sudo -e. (And in all of these
situations is generally the behavior I'd want, although I guess the idea is
probably to prompt if a save is wanted but not for a filename. Ah well.)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Adams]

Once upon a time, Ben Cotton  said:
> For laptop and workstation installs of Fedora, we want to provide file
> system features to users in a transparent fashion. We want to add new
> features, while reducing the amount of expertise needed to deal with
> situations like [https://pagure.io/fedora-workstation/issue/152
> running out of disk space.] Btrfs is well adapted to this role by
> design philosophy, let's make it the default.

So... I freely admit I have not looked closely at btrfs in some time, so
I could be out of date (and my apologies if so).  One issue that I have
seen mentioned as an issue within the last week is still the problem of
running out of space when it still looks like there's space free.  I
didn't read the responses, so not sure of the resolution, but I remember
that being a "thing" with btrfs.  Is that still the case?  What are the
causes, and if so, how can we keep from getting a lot of the same
question on mailing lists/forums/etc.?

I'm pretty neutral on this... I run a bunch of RHEL/CentOS systems, so I
tend to stick close to that on my Fedora systems (so I'd probably stick
with ext4/xfs on LVM myself).  I remember when btrfs was going to be the
one FS to rule them all, but then had issues, and specific weird cases
(like with VM images IIRC at one point), and kind of fell of my map
then.  That is not intended as a criticism - filesystems are complex,
and developing them hard... I think some of the reputation came from
some people pushing btrfs before it was really ready.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
> On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
> > > From this thread you can find at least two people (me and Ben
> > > Rosser)
> > > who definitely didn't keep using vi (my very next questions were
> > > "what's an easier editor to use?" and "how do I change the default
> > > editor to something else?"), and are still sufficiently frazzled by
> > > the
> > > experience that we still refuse to. :P
> 
> > Right, and I acutally think thats great.  You had a problem, you
> > asked the
> > questions you needed answers to, and solved your problem.  I
> > personally think
> > the process of identifying whats bothering you, figuring out a
> > solution (by
> > asking questions, getting answers and experimenting), and then
> > implementing your
> > fix is actually a pretty good user experience in and of itself
> > (though that may
> > just be me). :)
> 
> That is not how it felt at the time :P
> 
> It's really the point about Unexpected Forcible Learning. If I sit down
> at my computer and think "right, I'm going to learn to do X", that's
> one thing. I am mentally prepared to spend some time stumbling around
> working out how to do X.
> 
> The problem with this experience is that's not how it happens. You
> don't sit down and thinking "today I'm going to learn how to use vi" or
> "today I'm going to learn about console text editors and the $EDITOR
> variable". You were intending to do something else, and you were
> suddenly sandbagged by this fracking weird thing you have no idea what
> it is that got in the way of the something else you were trying to do.
> 
> Yes, eventually you learn something, but it's not a "pretty good user
> experience", it is a frustrating and annoying one.

But thats more or less the expectation of unix and unix like systems.  For all
the porcelain and chrome we've put around it, under the covers, its all still a
bag of parts, and the expectation is (or should be) when using a bag of parts,
you will have to learn how several of those parts work (be it vi or nano when
using git, or substitue your tool of choice here).  You start with a tool, you
relize it relies on another tool, so you have to push it down the stack and
figure out the new tool as part of the overall process.

I'll share a simmilar experience to commiserate.  During this thread, I went to
go confirm that eclipse actually used its own internal git editor for adding
commit messages. Thought it was going to be easy.  Quickly realized that eclipse
didn't come with git integration out of the box, so I had to go figure out how
to get git support in, then how to configure it, then how to interface to it.
It all felt like kinda the same tool, because it all happened in one of a few
related windows, but its really learning several disparate tools, and thats ok.
I still don't like using eclipse, but not because it made me go figure out
several new tools, I don't like it because it seems nuts to me to have an IDE
with a 400M Resident set size to edit ascii text. :)

Heres a thought that I hadn't considered before though, and it might be useful.
Apple at one point (and still may), shiped iphones without the itunes (or some
common) app on it,
and they did so intentionally, because they knew it was an app that people
wanted, and it forced them into a sort of 'training mission' in which they had
to use the app store on their phone to find and install the itunes app.  It gave
end users, after their initial disgruntledness, the skills to install new apps
on their phone, and explore how some of the system worked.

Would that be a possibility here?  I've upgraded my fedora workstation so many
times, I'm not sure what our firstboot screens look like anymore, but would it
be worthwhile to present users with some text, or a guide wizard, to point out
files like their ~/.bashrc file with some commented text that shows clearly what
some useful environment variables are, and how they might set them to customize
their experience?  Its not very 'just press the button to do something you may
or may not understand', but it targets new users as part of firstboot, and
introduces them in a somewhat friendly way to how things look under the covers,
so they can make adjustments as their needs dictate.  Even if they don't do it
immediately, they will have a reference to something they can recall if they
find later that their choice of editor is not something they are comfortable
with.

Neil

> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> L

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Orcan Ogetbil]

On Fri, 26 Jun 2020 at 10:40, Jonathan Wakely wrote:
> Obeying EDITOR is required by POSIX e.g. see
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_08
>
> Note that POSIX says "The default editor shall be vi." But that means
> when EDITOR isn't set. If the system or a user sets EDITOR to
> something else, it's still POSIX-conforming.

Thank you for the clarification and the reference. Clearly the POSIX
standard is plain wrong. But this is not the right platform to discuss
this issue.

Cheers,
Orcan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neal Gompa]

On Fri, Jun 26, 2020 at 1:16 PM Adam Williamson
 wrote:
>
> On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
> >
> > Also, have we asked the question, what default editor are other distros 
> > setting?
> > I've honestly never looked.
>
> The Change page says "More in line with the default editor of other
> distributions." But it doesn't give more detail, so I did a bit of
> research!
>
> Ubuntu's default is nano, per various search results.
>

Debian's default is nano as well. Ubuntu inherits this setting from Debian.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Fri, 2020-06-26 at 12:10 -0500, Chris Adams wrote:
> Once upon a time, Adam Williamson  said:
> > But nano *tells you* about ctrl+o.
> 
> Well, it tells you about ^O - but when I hit SHIFT+6 O it doesn't do
> that! :P

Sure. It's not perfect. But it gives you a fighting chance. And it at
least tells you what it *is*. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[David Kaufmann]

On Fri, Jun 26, 2020 at 03:42:39PM +0100, Jonathan Wakely wrote:
> "In the last year, How to exit the Vim editor has made up about .005%
> of question traffic: that is, one out of every 20,000 visits to Stack
> Overflow questions. That means during peak traffic hours on weekdays,
> there are about 80 people per hour that need help getting out of Vim."

Please don't just simply take that number as "number of people trying to
exit vim"
One of those threads on stackoverflow was a highly popular meme and was
featured in quite many webpages.
I myself probably visited that thread about 5 to 10 times despite being
a vim user for about 10 years now, just because I was provided with the
link to that specific thread or because I wanted to show someone that
thread.

All the best,
David


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Fri, 2020-06-26 at 12:39 -0400, Neil Horman wrote:
> 
> Also, have we asked the question, what default editor are other distros 
> setting?
> I've honestly never looked.

The Change page says "More in line with the default editor of other
distributions." But it doesn't give more detail, so I did a bit of
research!

Ubuntu's default is nano, per various search results.

openSUSE's (I tested the Leap 15.1 GNOME live image) is...mostly vi,
though this is implemented some other way than $EDITOR, because `echo
$EDITOR` shows nothing. `visudo` and `git commit` run vi, but
`systemctl edit` runs nano. Not sure what's going on there.

At least as of 2015, Arch considered changing to nano but stuck with
vi, though one of their key arguments at the time was "everyone else
uses vi", and it seems the issue was slightly complicated by the
question of what packages would or wouldn't be in their 'core':
https://lists.archlinux.org/pipermail/arch-dev-public/2015-April/027133.html
As of 2019 it still seems to be vi:
https://bbs.archlinux.org/viewtopic.php?id=245675

Mint's default seems to be nano, though like openSUSE, it is doing this
some way other than by setting $EDITOR.

So, it's a bit of a mixed bag, overall. But Ubuntu and Mint both using
nano is pretty significant.

> > Don't focus on git. It's not just about git. git was just a convenient
> > example of something that launches the default text editor.
> > 
> Sure, we can substitue any other tool here that has to fork an editor from the
> command line, and some of those will be far more in line with what a novice
> non-developer might use.  I just think for those users, nano likely isn't 
> going
> to move the needle much, and I'm not sure how many of those users Fedora gets,
> or looses on this point.  I know we can't really get that data, but it sure
> would be great to have.
> 
> > > So the user you are describing
> > > 
> > > 1) Isn't skilled in command line usage
> > > 2) Chose to use the command line anyway, despite having a littany of IDE's
> > > available
> > > 3) Was sufficiently well versed in development process to chose to use an 
> > > SCM,
> > > and to search for commands to work with it (setting asside their lack of
> > > understanding of what they were doing)
> > > 4) But wasn't sufficiently well versed enough to go back and find out how 
> > > to use
> > > the editor that their scm choice chose to default to
> > > 
> > > I just don't see that that person really exists.
> > 
> > There are literally multiple people in the thread telling you this
> > literally happened to them or to people they know who asked them for
> > help. I am one of them.
> I think thats an overstatement.  If it isnt, I apologize, but I really have a 
> hard
> time believing that they comply with 1-3 (those are entirely believable), but
> then threw their hands up in the air when confronted with a window that they
> could sort of edit text in.  As shown above, typing "I typed  in and this
> wierd screen poped up that I could kind of edit" into google answered that
> question in the top result.

Sure, like I wrote elsewhere in the thread, it's probably less of a
complete roadblock than it used to be. But it's still an unnecessary
pain point. Yes, people can probably get through it in fifteen minutes
these days, but it's still unnecessarily annoying. Why cause them the
trouble?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bundled compiler conundrum

[Jonathan Wakely]

On 26/06/20 12:01 -0500, Michael Cronenworth wrote:

On 6/25/20 11:45 PM, Tom Stellard wrote:

Are you tying to build with mingw-gcc?  What errors are you getting?


Yes, mingw-gcc, as we do not ship the Clang based MinGW toolchain in Fedora.

Here's a sample:

cc1plus: error: unrecognized command line option 
'-Wno-implicit-int-float-conversion' [-Werror]

cc1plus: error: unrecognized command line option '-Wno-parentheses-equality' 
[-Werror]
cc1plus: error: unrecognized command line option '-Wno-undefined-var-template' 
[-Werror]
cc1plus: error: unrecognized command line option '-Wno-deprecated-register' 
[-Werror]
cc1plus: error: unrecognized command line option 
'-Wno-inconsistent-missing-override' [-Werror]

cc1plus: error: unrecognized command line option '-Wno-undefined-inline' 
[-Werror]
cc1plus: error: unrecognized command line option 
'-Wno-ignored-pragma-optimize' [-Werror]

cc1plus: error: unrecognized command line option '-Wno-inline-new-delete' 
[-Werror]


GCC does not complain about unrecognized -Wno-xxx options unless
another warning or error has ben issued.

So these are not the problem.

You seem to be using -Werror, which probably means that some other
(possibly innocuous) warning caused an error, and because compilation
had already failed, GCC decided to *also* tell you about the
unrecognized -Wno-xxx options.

Fix your real problem, and the -Wno-xxx warnings will go away.

Stop using -Werror and they'll just be warnings anyway.


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> Nice! I wonder if we could make EDITOR='nano --tempfile' the default? For git 
> and
> similar cases this would work nicely, but I'm not sure about all the other 
> cases
> where $EDITOR is used...

I believe $EDITOR is supposed to just be an executable that can be
passed directly to exec(), so I don't think you can include arguments in
it.

-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Chris Adams]

Once upon a time, Adam Williamson  said:
> But nano *tells you* about ctrl+o.

Well, it tells you about ^O - but when I hit SHIFT+6 O it doesn't do
that! :P
-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 12:38:40PM -0400, Ben Rosser wrote:
> On Fri, Jun 26, 2020 at 12:32 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> > > == Scope ==
> > > * Proposal owners:
> > > ** Modify comps to include nano Fedora wide.
> > > ** Create a new subpackage of nano, called
> > > nano-editor.
> > > ** nano-editor to include
> > > /usr/lib/environment.d/10-nano.conf, which sets
> > > $EDITOR to nano.
> >
> > There's one nitpick with using nano in 'git commit' and similar: it'll
> > ask about the name to save as:
> > ^X
> > Save modified buffer? Y
> > File Name to Write: 
> > /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
> >
> > Would it be possible to skip this last question in those scenarios?
> > It the answer is "no", that's OK, but if it would be easy, it'd make
> > usage a bit nicer. 'vi' and 'emacs -nw' don't ask.
> 
> The -t/--tempfile switch for nano (and pico) does exactly this:
> https://linux.die.net/man/1/nano
> 
Does that imply then, if we were to switch the default EDITOR variable to nano,
we would have to set it as:
EDITOR=nano -t
or some such?  That solves the problem for git, but may introduce other problems
for users, either by wanting to be promted when its opened from other cli tools,
or in the alternative, if we just set EDITOR=nano, are we going to encounter
questions when people change the save path and wonder why their commits fail?

Neil

> Ben Rosser
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bundled compiler conundrum

[Tom Stellard]

On 06/26/2020 10:01 AM, Michael Cronenworth wrote:
> On 6/25/20 11:45 PM, Tom Stellard wrote:
>> Are you tying to build with mingw-gcc?  What errors are you getting?
> 
> Yes, mingw-gcc, as we do not ship the Clang based MinGW toolchain in Fedora.
> 
> Here's a sample:
> 
> cc1plus: error: unrecognized command line option 
> '-Wno-implicit-int-float-conversion' [-Werror]
> cc1plus: error: unrecognized command line option '-Wno-parentheses-equality' 
> [-Werror]
> cc1plus: error: unrecognized command line option 
> '-Wno-undefined-var-template' [-Werror]
> cc1plus: error: unrecognized command line option '-Wno-deprecated-register' 
> [-Werror]
> cc1plus: error: unrecognized command line option 
> '-Wno-inconsistent-missing-override' [-Werror]
> cc1plus: error: unrecognized command line option '-Wno-undefined-inline' 
> [-Werror]
> cc1plus: error: unrecognized command line option 
> '-Wno-ignored-pragma-optimize' [-Werror]
> cc1plus: error: unrecognized command line option '-Wno-inline-new-delete' 
> [-Werror]
> 
> 

How different is the clang mingw toolchain shipped with wine-mono than the
vanilla clang we have in Fedora?  Looking at the wine-mono sources, it
looks like their mingw toolchain might just be a wrapper around a standard
build of clang, but I'm not really all that familiar with how mingw works.

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ben Rosser]

On Fri, Jun 26, 2020 at 12:46 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Jun 26, 2020 at 12:38:40PM -0400, Ben Rosser wrote:
> > On Fri, Jun 26, 2020 at 12:32 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> > > > == Scope ==
> > > > * Proposal owners:
> > > > ** Modify comps to include nano Fedora wide.
> > > > ** Create a new subpackage of nano, called
> > > > nano-editor.
> > > > ** nano-editor to include
> > > > /usr/lib/environment.d/10-nano.conf, which sets
> > > > $EDITOR to nano.
> > >
> > > There's one nitpick with using nano in 'git commit' and similar: it'll
> > > ask about the name to save as:
> > > ^X
> > > Save modified buffer? Y
> > > File Name to Write: 
> > > /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
> > >
> > > Would it be possible to skip this last question in those scenarios?
> > > It the answer is "no", that's OK, but if it would be easy, it'd make
> > > usage a bit nicer. 'vi' and 'emacs -nw' don't ask.
> >
> > The -t/--tempfile switch for nano (and pico) does exactly this:
> > https://linux.die.net/man/1/nano
>
> Nice! I wonder if we could make EDITOR='nano --tempfile' the default? For git 
> and
> similar cases this would work nicely, but I'm not sure about all the other 
> cases
> where $EDITOR is used...

Yeah, I'm not sure either. My guess is $EDITOR is mostly invoked to
edit temporary files/buffers or files that already exist somewhere,
but I have no data to back that up.

I did just try running "nano -t" on its own to see what happens; if
you enter some text and then try to quit, it complains that there's no
file name and then, after a short delay, prompts you for one with the
normal save dialog. It's not terrible, but the delay (to give you time
to read the error message, I guess) is a little annoying.

(For what it's worth: this can also apparently be accomplished by a
nanorc setting ("set tempfile"), but presumably we wouldn't want to
set this there).

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
> > From this thread you can find at least two people (me and Ben
> > Rosser)
> > who definitely didn't keep using vi (my very next questions were
> > "what's an easier editor to use?" and "how do I change the default
> > editor to something else?"), and are still sufficiently frazzled by
> > the
> > experience that we still refuse to. :P

> Right, and I acutally think thats great.  You had a problem, you
> asked the
> questions you needed answers to, and solved your problem.  I
> personally think
> the process of identifying whats bothering you, figuring out a
> solution (by
> asking questions, getting answers and experimenting), and then
> implementing your
> fix is actually a pretty good user experience in and of itself
> (though that may
> just be me). :)

That is not how it felt at the time :P

It's really the point about Unexpected Forcible Learning. If I sit down
at my computer and think "right, I'm going to learn to do X", that's
one thing. I am mentally prepared to spend some time stumbling around
working out how to do X.

The problem with this experience is that's not how it happens. You
don't sit down and thinking "today I'm going to learn how to use vi" or
"today I'm going to learn about console text editors and the $EDITOR
variable". You were intending to do something else, and you were
suddenly sandbagged by this fracking weird thing you have no idea what
it is that got in the way of the something else you were trying to do.

Yes, eventually you learn something, but it's not a "pretty good user
experience", it is a frustrating and annoying one.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Bundled compiler conundrum

[Michael Cronenworth]

On 6/25/20 11:45 PM, Tom Stellard wrote:

Are you tying to build with mingw-gcc?  What errors are you getting?


Yes, mingw-gcc, as we do not ship the Clang based MinGW toolchain in Fedora.

Here's a sample:

cc1plus: error: unrecognized command line option 
'-Wno-implicit-int-float-conversion' [-Werror]

cc1plus: error: unrecognized command line option '-Wno-parentheses-equality' 
[-Werror]
cc1plus: error: unrecognized command line option '-Wno-undefined-var-template' 
[-Werror]
cc1plus: error: unrecognized command line option '-Wno-deprecated-register' 
[-Werror]
cc1plus: error: unrecognized command line option 
'-Wno-inconsistent-missing-override' [-Werror]

cc1plus: error: unrecognized command line option '-Wno-undefined-inline' 
[-Werror]
cc1plus: error: unrecognized command line option '-Wno-ignored-pragma-optimize' 
[-Werror]

cc1plus: error: unrecognized command line option '-Wno-inline-new-delete' 
[-Werror]

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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Matthew Miller]

On Fri, Jun 26, 2020 at 09:11:09AM -0700, Adam Williamson wrote:
> clearly we need to patch a help bar into less =)

... that would actually be really easy to do, since a patch isn't necessary.

export LESS='-MPM?f%f .?n?m(%T %i of %m) ..?ltlines %lt-%lb?L/%L. :byte 
%bB?s/%s. .?e(END) ?x- Next\: %x.:?pB%pB\%..%t (h for help or q to quit)'

But let's not get ahead of ourselves. :)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 08:54:42AM -0700, Adam Williamson wrote:
> On Fri, 2020-06-26 at 11:42 -0400, Neil Horman wrote:
> > is interesting, both for the explicit fact that 1,000,000 people had to ask
> > how to exit vi (bad), and for the more subtle implicit fact that, at least 
> > 1,000,000
> > people are using vi, got the answer to the question they were looking for 
> > (good), and
> > presumably kept using vi (unknown).
> 
> Also 1,000,000 people unnecessarily had to answer the same question
> again (bad).
> 
Not to nitpick, but 1,000,000 asked the question.  It only had to be answered 
once (or
only answered N times, where N << 10^6, and equal to the number of recorded
unique questions on stackexchange).  I only point it out because the effort in
answering the question is hard, asking the question is easy, especially when its
already been answered, as a quick answer provides, if not a great user
experience, a better one than having to answer it 10^6 times, or not being able
to find an answer at all.

> From this thread you can find at least two people (me and Ben Rosser)
> who definitely didn't keep using vi (my very next questions were
> "what's an easier editor to use?" and "how do I change the default
> editor to something else?"), and are still sufficiently frazzled by the
> experience that we still refuse to. :P
Right, and I acutally think thats great.  You had a problem, you asked the
questions you needed answers to, and solved your problem.  I personally think
the process of identifying whats bothering you, figuring out a solution (by
asking questions, getting answers and experimenting), and then implementing your
fix is actually a pretty good user experience in and of itself (though that may
just be me). :)  It suggests that I know what I'm doing, and I am in control of
the system that I'm working on.  I felt that way the first time that I
downloaded slackware around 1996 and had to figure out how to use ppp to
establish a dial up connection to my university (side note, in those days, the
bits had to travel over the phone line uphill.both ways) :)

Neil


> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Fri, Jun 26, 2020 at 8:45 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/BtrfsByDefault
>

Related: Chromebooks are using btrfs in a particular way. ChromeOS has
something called Crostini which is a set of technologies they use for
enabling native Linux app support. This is LXC/LXD based, and uses a
(I think per user) loop mounted file that is btrfs, and they leverage
btrfs snapshotting for the containers.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Josef Bacik]

On 6/26/20 12:43 PM, Matthew Miller wrote:

On Fri, Jun 26, 2020 at 12:30:35PM -0400, Josef Bacik wrote:

Obviously the Facebook scale, recoverability, and workload is going
to be drastically different from a random Fedora user.  But hardware
wise we are pretty close, at least on the disk side.  Thanks,


Thanks. I guess it's really recoverability I'm most concerned with. I expect
that if one of these nodes has a metadata corruption that results in an
unbootable system, that's really no big deal in the big scheme of things.
It's a bigger deal to home users. :)



Sure, I've answered this a few different times with various members of the 
working group committee (or whatever they're called nowadays).  I'll copy and 
paste what I said to them.  The context is "what do we do with bad drives that 
blow up at the wrong time".


Now as for what does the average Fedora user do?  I've also addressed that a 
bunch over the last few weeks, but instead of pasting like 9 emails I'll just 
summarize.


The UX of a completely fucked fs sucks, irregardless of the file system. 
Systemd currently (but will soon apparently) does not handle booting with a read 
only file system, which is essentially what you get when you have critical 
metadata corrupted.  You are dumped to a emergency shell, and then you have to 
know what to do from there.


With ext4/xfs, you mount read only or you run fsck.  With Btrfs you can do that 
too, but then there's like a whole level of other options depending on how bad 
the disk is.  I've written a lot of tools over the years (which are in 
btrfs-progs) to recover various levels of broken file systems.  To the point 
that you can pretty drastically mess up a FS and I'll still be able to pull data 
from the disk.


But, again, the UX for this _sucks_.  You have to know first of all that you 
should try mounting read only, and then you have to get something plugged into 
the box and copy it over.  And then assume the worst, you can't mount read only. 
 Now with ext4/xfs that's it, you are done.  With btrfs you are just getting 
started.  You have several built in mount options for recovering different 
failures, all read only.  But you have to know that they are there and how to 
use them.


These things are easily addressed with documentation, but that's only so good. 
This sort of scenario needs to be baked into Fedora itself, because it's the 
same problem no matter which file system you use.  Thanks,


Josef


Email elaborating my comments about btrfs's sensitivity to bad hardware and how 
we test.


---

The fact is I can make any file system unmountable with the right corruption.
The only difference with btrfs is that our metadata is completely dynamic, while
xfs and ext4 are less so.  So they're overwriting the same blocks over and over
again, and there is simply less of "important" metadata for the file system to
function.

The "problem" that btrfs has is it's main strength, it does COW.  That means our
important metadata is constantly being re-written to different segments of the
disk.  So if you have a bad disk, you are much more likely to get unlucky and
end up with some core piece of metadata getting corrupted, and thus resulting in
a file system that cannot be mounted read/write.

Now you are much more likely to hit this in a data segment, because generally
speaking there's more data writes than metadata writes.  The thing I brought up
in the meeting last week was a potential downside for sure, but not something
that will be a common occurrence.  I just checked the fleet for this week and
we've had to reprovision 20 machines out of 138 machines that threw crc errors,
out of N total machines with btrfs fs'es, which is in the millions.  In the same
time period I have 15 xfs boxes that needed to be reprovisioned because of
metadata corruption, out of <100k machines that have xfs.  I don't have data on
ext4 because it doesn't exist in our fleet anymore.

As for testing, there are 8 tests in xfstests that utilize my dm-log-writes
target.  These tests mount the file system, do a random workload, and then
replay the workload one write at a time to validate the file system isn't left
in some intermediate broken state.  This simulates the case of weird things
happening but in a much more concrete and repeatable manner.

There's 65 tests that utilize dm-flakey, which randomly corrupts or drops
writes, and again these are to test different scenarios that have given us
issues in the past.  There's more of these because up until a few years ago this
was our only mechanism for testing this class of failures.  I wrote
dm-log-writes to bring some determinism to our testing.

All of our file systems in linux are extremely thoroughly tested for a variety
of power fail cases.  The only area that btrfs is more likely to screw up is in
the case of bad hardware, and again we're not talking like huge percentage
points difference.  It's a trade off.  You are trading a slight increased
percenta

Re: SELinux question

[Zdenek Pytela]

On Thu, Jun 25, 2020 at 8:54 PM Samuel Sieb  wrote:

> On 6/24/20 12:03 PM, Iñaki Ucar wrote:
> > Thanks. I found another tutorial (from RedHat) which basically says:
> >
> > 1. Implement your service, give it a new SELinux type and run it.
> > 2. Collect all the complaints from SELinux.
> > 3. Use audit2allow to convert them to rules.
> > 4. Repeat until you don't get any more complaints.
> >
> > And I cannot believe my eyes. Is this *really* the way to implement
> > SELinux policies? It seems like a joke to me. Isn't there any notion
> > of inheritance or something like that? Like, I want my type to have
>
> I suppose that's the "easy" way.  The better way would be to figure out
> what permissions and transitions your service needs and write the rules
> for that.
>
You are right as nobody else but the developer can be aware of which
permissions are actually needed: SELinux can also help with finding bugs in
the app so it is not always reasonable to allow every permission audited.

There are tools which can support you in the beginning, like sepolicy
generate. Some of the audited denials are easy to understand, for some it
needs to be figured out what they mean:
https://selinuxproject.org/page/ObjectClassesPerms

If your goal is to confine the application, you should follow this
documentation:
https://fedoraproject.org/wiki/SELinux/IndependentPolicy
The selinux-policy devel package, e. g. the example.?? files, can work as a
source of inspiration.

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Zdenek Pytela
Security controls team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

[PGNet Dev]

On 6/26/20 9:35 AM, PGNet Dev wrote:
> that said, _can_ such bash-ism be used in "getting" a forge commit value?

nm, pebkac!

%( git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}' )

seems to work.

sry 4 the noise.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Markus Larsson]

On 26 June 2020 18:11:09 CEST, Adam Williamson  
wrote:
>On Fri, 2020-06-26 at 11:58 -0400, Matthew Miller wrote:
>> On Fri, Jun 26, 2020 at 09:24:44AM -0500, Chris Adams wrote:
>> > And visudo/sudoedit, systemctl edit, bash ^X^E, mysql \e, virsh edit,
>> > less v, mutt, edquota, and a number of bug-report type things like perlbug.
>> 
>> Less already has obscure vi-like keybindings, so that may not be the best
>> example. 
>
>quit from less is at least is a single key, which gives you a fighting
>chance. I think it only took me about five minutes to figure out how to
>quit less, the first time. :P
>
>I actually hadn't tried most before so I just did - the 'help' bar is a
>definitely improvement, but its search behaviour seems awful.
>
>clearly we need to patch a help bar into less =)

Please stop. I know you are joking but people will take you seriously. Fast 
forward 2 years and there will be a whole little novel taking up screen space 
when using less.
This never fails to happen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Matthew Miller]

On Fri, Jun 26, 2020 at 05:32:45PM +0100, Daniel P. Berrangé wrote:
> btrfs is not a 1-1 equivalent of ext4, because the scope of btrfs is
> much broader. It should likely be compared against some combo of
> existing functionality, such as ext4+devicemapper, to get a fairer
> picture.

Well, specifically, we should compare the existing default partitioning
scheme.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jun 26, 2020 at 12:38:40PM -0400, Ben Rosser wrote:
> On Fri, Jun 26, 2020 at 12:32 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> > > == Scope ==
> > > * Proposal owners:
> > > ** Modify comps to include nano Fedora wide.
> > > ** Create a new subpackage of nano, called
> > > nano-editor.
> > > ** nano-editor to include
> > > /usr/lib/environment.d/10-nano.conf, which sets
> > > $EDITOR to nano.
> >
> > There's one nitpick with using nano in 'git commit' and similar: it'll
> > ask about the name to save as:
> > ^X
> > Save modified buffer? Y
> > File Name to Write: 
> > /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
> >
> > Would it be possible to skip this last question in those scenarios?
> > It the answer is "no", that's OK, but if it would be easy, it'd make
> > usage a bit nicer. 'vi' and 'emacs -nw' don't ask.
> 
> The -t/--tempfile switch for nano (and pico) does exactly this:
> https://linux.die.net/man/1/nano

Nice! I wonder if we could make EDITOR='nano --tempfile' the default? For git 
and
similar cases this would work nicely, but I'm not sure about all the other cases
where $EDITOR is used...

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Matthew Miller]

On Fri, Jun 26, 2020 at 12:30:35PM -0400, Josef Bacik wrote:
> Obviously the Facebook scale, recoverability, and workload is going
> to be drastically different from a random Fedora user.  But hardware
> wise we are pretty close, at least on the disk side.  Thanks,

Thanks. I guess it's really recoverability I'm most concerned with. I expect
that if one of these nodes has a metadata corruption that results in an
unbootable system, that's really no big deal in the big scheme of things.
It's a bigger deal to home users. :)


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Neil Horman]

On Fri, Jun 26, 2020 at 08:50:09AM -0700, Adam Williamson wrote:
> On Fri, 2020-06-26 at 10:33 -0400, Neil Horman wrote:
> > On Fri, Jun 26, 2020 at 09:00:58AM -0400, Solomon Peachy wrote:
> > > On Fri, Jun 26, 2020 at 08:43:19AM -0400, Neil Horman wrote:
> > > > Do we have real stasitics on this (somthing in the form of bz reports or
> > > > comments on a list) indicating that users actually are frustrated with 
> > > > being
> > > > confronted with vi unexpectedly? 
> > > 
> > > Why would one file a bugzilla ticket over this?  vi, and the system 
> > > default, is working as intended.  "That's just the way Linux is," say 
> > > the folks having to answer "how to quit vi" for the umpteenth time.
> > > 
> > Ok, perhaps bugzilla is the wrong venue, but the point stands. Are people
> > actually asking how to quit vi (or some simmilar questions) somewhere?  If I
> > google how to quit vi, I see a full 10 pages of the answer to the question
> > documented in detail (which suggests lots of people had the question at some
> > point in time), but what I don't see are stackoverflow (or other message 
> > board
> > posts) asking the question currently.
> 
> In order to ask "how do I quit vi?" you have to know you're in vi.
> Which you don't (again, from personal experience).
> 
> I believe the question I eventually asked on IRC (later, because this
> was still in the days when you didn't connect to the internet until it
> was after 6pm and the phone call was cheaper :>) was something like "I
> did X and this weird screen popped up where I could kinda type stuff
> but some keys didn't work and I think maybe it was for editing text but
> I couldn't figure out how to do it properly or save anything or quit,
> what the hell was that?" or something along those lines.
> 
> If you can figure out how to search the internet for questions like
> that...=)
> 
Thats a funny example :)
https://www.google.com/search?q=I+did+git+commit+and+this+wierd+screen+popped+up+and+I+could+kind+of+edit&oq=I+did+git+commit+and+this+wierd+screen+popped+up+and+I+could+kind+of+edit&aqs=chrome..69i57j69i64l3.11632j0j4&sourceid=chrome&ie=UTF-8

The first result that pops up is a stack overflow thread explaining that the
wierd screen is vi, and how to work in it (as well as how to change it if you
would rather use something else)

> But Jonathan did in fact post a link to a detailed Stack Overflow 
> 
Yeah, he did, I commented on it somewhere else in this thread.

> >   Clearly there was a time when this was a
> > problem (and access to all the online resources we have today wasn't 
> > available),
> 
> I'd agree it's likely to be less of a roadblock today as you're much
> more likely to be online 24/7 and have another device (phone!) you can
> ask the question from. But it's still an unnecessary pain point. (And
> *some* poor person on the internet has to explain this problem for the
> sixteen billionth collective time). Why not fix it?
> 
Oh, I completely agree with fixing it.  Somewhere else in this thread you
mentioned that the 1000 searches for exiting vim meant 10^6 people had to
needlessly search for the answer to that.  Thats probably an indicator that vi
could be improved to make it more discoverable (lots of opportunity there), but
I don't think its cause to change the default editor, because those 10^6 people
asked the question, and (I have to assume) kept using vi, so for whatever
questions they're asking, they don't (seem) to be rising to the level of
departing Fedora for another distro that offers something else as the default.

Also, have we asked the question, what default editor are other distros setting?
I've honestly never looked.

> > but now?  I'm just asking us not to make this decision by proxy.  Are there
> > users out there today that are complaining somewhere that vi is hard to 
> > use, and
> > can't either figure it out, or figure out how to use a different editor
> > 
> > > > I'm struggling with the notion that an individual user is sufficiently 
> > > > skilled to use git on the command line,
> > > 
> > > They actually aren't skilled on the cmdline.  At most they'll just 
> > > cut-n-paste something they found on stack overflow.  Instead, GUI git 
> > > frontends are the norm, generally embedded within IDEs.
> > > 
> > This just confuses me further.  For integrated IDEs, the selection of a 
> > default
> > editor for terminal usage is largely irrelevant, as the IDE typically 
> > provides
> > an editor built in (basing this assertion on eclipse behvior, but I'd be
> > suprised if an ide forks a terminal just to run the git default editor)
> 
> Don't focus on git. It's not just about git. git was just a convenient
> example of something that launches the default text editor.
> 
Sure, we can substitue any other tool here that has to fork an editor from the
command line, and some of those will be far more in line with what a novice
non-developer might use.  I just think for those users, nano likely isn't going
to mov

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Adam Williamson]

On Fri, 2020-06-26 at 16:31 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> > == Scope ==
> > * Proposal owners:
> > ** Modify comps to include nano Fedora wide.
> > ** Create a new subpackage of nano, called
> > nano-editor.
> > ** nano-editor to include
> > /usr/lib/environment.d/10-nano.conf, which sets
> > $EDITOR to nano.
> 
> There's one nitpick with using nano in 'git commit' and similar: it'll
> ask about the name to save as:
> ^X
> Save modified buffer? Y
> File Name to Write: 
> /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
> 
> Would it be possible to skip this last question in those scenarios?
> It the answer is "no", that's OK, but if it would be easy, it'd make
> usage a bit nicer. 'vi' and 'emacs -nw' don't ask.

So I poked at this a bit. nano has a -R which is documented thus:

   -R, --restricted
  Restricted mode: don't read or write to any file not specified on 
 the  command  line.   This  means:
  don't  read or write history files; don't allow suspending; don't 
allow spell checking; don't allow a
  file to be appended to, prepended to, or saved under a different 
name if  it  already  has  one;  and
  don't make backup files.  Restricted mode can also be activated 
by invoking nano with any name begin‐
  ning with 'r' (e.g. "rnano").

but the funny thing is, even if you use it, when you hit ctrl+O it
still asks you what filename to save under, it just doesn't let you
actually change the name at all. So that seems like it might help, but
doesn't really :/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Ben Rosser]

On Fri, Jun 26, 2020 at 12:32 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> > == Scope ==
> > * Proposal owners:
> > ** Modify comps to include nano Fedora wide.
> > ** Create a new subpackage of nano, called
> > nano-editor.
> > ** nano-editor to include
> > /usr/lib/environment.d/10-nano.conf, which sets
> > $EDITOR to nano.
>
> There's one nitpick with using nano in 'git commit' and similar: it'll
> ask about the name to save as:
> ^X
> Save modified buffer? Y
> File Name to Write: 
> /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
>
> Would it be possible to skip this last question in those scenarios?
> It the answer is "no", that's OK, but if it would be easy, it'd make
> usage a bit nicer. 'vi' and 'emacs -nw' don't ask.

The -t/--tempfile switch for nano (and pico) does exactly this:
https://linux.die.net/man/1/nano

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: %forgemeta support for `git` tasks in checked-out code?

[PGNet Dev]

while 'exploring' some of the limits of forge syntax/usage, trying to see 
if/how bash expansion might work, i find that:





neither



  %global forgeurl1 https://github.com/openresty/headers-more-nginx-module

  %global commit1   git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}'



nor




  %global forgeurl1 https://github.com/openresty/headers-more-nginx-module


  %global commit1   $( git ls-remote %{forgeurl1} | grep HEAD | awk '{print $1}'
 )





yes, i know this^ is not production-ideal ... and that there are other/better 
options.



that said, _can_ such bash-ism be used in "getting" a forge commit value?


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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Todd Zullinger]

Hi,

Zdenek Dohnal wrote:
> To be honest, I'm sad about the change.

It is just a default though, and I'll certainly change it on
my systems.  But like many others, I too can still recall
(decades ago) being dumped into vi and having no clue how to
do anything -- including just exiting.

> I'm not sure if which other applications use the default editor, I know
> only git from those. So let's say I will talk about the editor which
> git-commit spawns during committing a change.

Anywhere EDITOR or VISUAL isn't set, plenty of tools default
to /bin/vi.  It's much, much more than just git -- even if
that is a fairly common way for users to end up in vi these
days.

> What about this - Git could generate a message within the comments
> during commit:
> 
> 'Using editor: {message}'
> 
> In case of Vi:
> 
> 'Using editor: Vi , for more info type :help'
> 
> 
> Or nano:
> 
> 'Using editor: nano'
> 
> CCing Git maintainer to see whether it can be implemented or not.

Doing this would clutter the instructions for making the
commit itself and would be a distraction IMO.  I would also
be very hesitant to make such an adjustment to the default
git commit template anywhere but upstream.

While I very much prefer vim to nano myself, it's hard for
me to argue that dropping someone who's never used vi into
it is a great default.  It's not nearly as convenient or
useful as it could be for a new user.  It's wonderful and
powerful once you know it, but I don't think that makes it a
good default.

Since git is far from the only place a user might find
themselves in the default $EDITOR, we'd end up having to add
similar instructions for all (or many) of those tools.

(At that point, we'd be better off adding it to vi in some
manner -- and dealing with the inevatible fallout of what
that breaks.  That all seems like far more work than it's
worth.)

I think the fact that we'd even need to include such
instructions for how to use the editor is a sign that the
editor might not be a great _default_.

With this change adding a nano-default or such subpackage,
perhaps other editor packages will eventually offer a
similar subpackage to make them the default?  (Effectively
what Debian's got with the 'editor' alternative.)

Then users/admins who want to quickly deploy a different
system-wide default could do so (in a manner consistent with
how we're setting nano as the default)?

If the result is that more users learn about the wide
variety of useful and powerful editors available in Fedora,
that's a good outcome.

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Daniel P . Berrangé]

On Fri, Jun 26, 2020 at 04:58:19PM +0200, Vitaly Zaitsev via devel wrote:
> On 26.06.2020 16:42, Ben Cotton wrote:
> > For laptop and workstation installs of Fedora, we want to provide file
> > system features to users in a transparent fashion. We want to add new
> > features, while reducing the amount of expertise needed to deal with
> > situations like [https://pagure.io/fedora-workstation/issue/152
> > running out of disk space.] Btrfs is well adapted to this role by
> > design philosophy, let's make it the default.
> 
> I'm strongly against this proposal. BTRFS is the most unstable file
> system I ever seen. It can break up even under an ideal conditions and
> lead to a complete data loss. There are lots of complaints and bug
> reports in Linux kernel bugzilla and Reddit.

I don't have any info to either confirm or refute this assertion, but
I want to say we should be careful to actually compare apples to apples.

btrfs is not a 1-1 equivalent of ext4, because the scope of btrfs is
much broader. It should likely be compared against some combo of
existing functionality, such as ext4+devicemapper, to get a fairer
picture.

It isn't just a matter of whether the kernel parts are reliable. It
is also important how well the userspace tools fit together to form
the end user solution. This impacts how likely it is for the user
to shoot themselves in the foot when making changes to their storage
stack.

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Need help to contact: digimer mbartos, ignotusp

[Digimer]

On 2020-06-25 3:09 p.m., Pierre-Yves Chibon wrote:
> On Thu, Jun 25, 2020 at 12:37:41PM -0400, Digimer wrote:
>> digimer here, sorry, I'm not sure why my address was rejected. I can
>> also be reached at 'mke...@alteeve.ca'.
> 
> Could you update it in FAS and check if whichever account you use in FAS has a
> corresponding bugzilla account?
> 
> Thanks!
> 
> Pierre

Updated!

>> On 2020-06-25 9:08 a.m., Pierre-Yves Chibon wrote:
>>> Good Morning Everyone,
>>>
>>> As announced on devel-announce [1] I have sent an email to each account 
>>> listed
>>> on dist-git to be either point of contact or included in the CC list of 
>>> tickets
>>> opened on bugzilla.
>>>
>>> The following emails to the following account came back with and error:
>>> - digimer  (error: Recipient address rejected: alteeve.ca)
>>>   - Maintains: rpms/kronosnet
>>> - mbartos  (error: Recipient address rejected: Access denied)
>>>   - Maintains: rpms/libee, rpms/libestr, rpms/liblognorm
>>> - ignotusp (error:  No such user!)
>>>   - Maintains: rpms/wicd-kde
>>>
>>> Does anyone know how to contact these persons?
>>>
>>> If we have no way to contact them, we may have to ask FESCo to consider them
>>> unresponsive.
>>>
>>> Thanks in advance for your help!
>>>
>>> Pierre
>>>
>>>
>>> [1]: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VBMMXJT2M5TMWSH3DT3DY6VBPELSTQFV/
>>>
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>>
>>
>>
>> -- 
>> Digimer
>> Papers and Projects: https://alteeve.com/w/
>> "I am, somehow, less interested in the weight and convolutions of
>> Einstein’s brain than in the near certainty that people of equal talent
>> have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
>>


-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> == Scope ==
> * Proposal owners:
> ** Modify comps to include nano Fedora wide.
> ** Create a new subpackage of nano, called
> nano-editor.
> ** nano-editor to include
> /usr/lib/environment.d/10-nano.conf, which sets
> $EDITOR to nano.

There's one nitpick with using nano in 'git commit' and similar: it'll
ask about the name to save as:
^X
Save modified buffer? Y
File Name to Write: 
/home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG

Would it be possible to skip this last question in those scenarios?
It the answer is "no", that's OK, but if it would be easy, it'd make
usage a bit nicer. 'vi' and 'emacs -nw' don't ask.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Chris Murphy]

On Fri, Jun 26, 2020 at 8:58 AM Vitaly Zaitsev via devel
 wrote:
>
> I'm strongly against this proposal. BTRFS is the most unstable file
> system I ever seen. It can break up even under an ideal conditions and
> lead to a complete data loss. There are lots of complaints and bug
> reports in Linux kernel bugzilla and Reddit.

I've got a Samsung 840 EVO that I know has firmware bugs. Is that an
ideal condition? What about compiling webkitgtk and losing control of
the system under load (unresponsive GUI while the compiling continues
to write)? Is it an ideal condition? And because I'm notoriously
impatient, I often yank the power cord. Ideal condition? And I've done
this over 100 times in the last year. Ideal condition?

100% of the subsequent cold boots, boot identical to that of a prior
clean shutdown. Zero btrfs complaints. One person, one laptop, one
SSD. I'm not a totally disqualified scientific sample but it's a
really insignificant anecdote, other than even at this scale if there
were intrinsic file system defects, I think I'd have seen it.

Question is, what happens when the firmware has a hiccup and I also
get a power fail. What am I likely to see, and what do I do? When
there are problems, we're used to a particular pattern with ext4. That
pattern will change with btrfs. There will be fewer of some problems,
more of others, and the messages will be different. fsck.ext4 is
pretty much all we have, all we're used to, and it's a binary
pass/fail. Even though we're talking about edge cases at this level,
those who get unlucky for whatever reason are going to need a
community of user to user support giving them good advice. Will
Fedora?

It's also important to talk about what's left on the table *without*
this change. The potential to almost transparently drop in a new file
system that extends the life of user's hardware, eliminates the free
space competition problem between /home and /, and allocates it more
efficiently.  And asks *less* of day to day users, while inviting
*more* from those who want to explore more features. On the same file
system.

The fear/concern component is real, it has to be addressed and not
dismissed. But that component is already present with what we have.
We're just used to it. Is there enough of a sense of adventure and
bravery in Fedora to overcome the fear component, and in exchange we
get a modern file system that actually helps us solve problems we're
having today right now? And offers features that beg for future
creativity and innovation?

I think the answer is yes, but the Fedora community is going to have to decide.


-- 
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Josef Bacik]

On 6/26/20 11:15 AM, Matthew Miller wrote:

On Fri, Jun 26, 2020 at 11:13:39AM -0400, Josef Bacik wrote:

Not Fedora land, but Facebook installs it on all of our root
devices, so millions of machines.  We've done this for 5 years.
It's worked out very well. Thanks,


Josef, I'd love to hear your comments on any differences between that
situation and the typical laptop-user case for Fedora desktop systems.
Anything we should consider?



We buy worse hardware than a typical laptop user uses, at least for our hard 
drives.  Also we hit our disks harder than most typical Fedora users.  Consider 
the web tier for example, we push the entire website to every box in the web 
tier (measured in hundreds of thousands of machines) probably 6-10 times a day. 
This is roughly 40 gib of data, getting written to these truly terrible consumer 
grade flash drives (along with some spinning rust), 6-10 times a day.  In 
addition to the normal sort of logging, package updates, etc that happen.


Also keep in mind we pay really close attention to burn rates for our drives, 
because obviously at our scale it translates to millions of dollars.  Btrfs has 
improved our burn rates with the compression, as the write amplification goes 
drastically down, thus extending the life of the drives.


Obviously the Facebook scale, recoverability, and workload is going to be 
drastically different from a random Fedora user.  But hardware wise we are 
pretty close, at least on the disk side.  Thanks,


Josef
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1802607] perl-Net-DNS-1.25 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1802607



--- Comment #10 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.25-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=46211516


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jun 26, 2020 at 03:37:59PM +0100, Jonathan Wakely wrote:
> On 26/06/20 13:11 +, Zbigniew Jędrzejewski-Szmek wrote:
> >On Thu, Jun 25, 2020 at 01:59:39PM -0600, Chris Murphy wrote:
> >>On Thu, Jun 25, 2020 at 1:58 PM Chris Murphy  
> >>wrote:
> >>>
> >>> On Thu, Jun 25, 2020 at 1:48 PM Michael Catanzaro  
> >>> wrote:
> >>> >
> >>> > On Thu, Jun 25, 2020 at 2:45 pm, Michael Catanzaro
> >>> >  wrote:
> >>> > > Yes. I already fixed the wiki page to clarify that we don't need to
> >>> > > install nano, but I forgot to clarify that we will install
> >>> > > nano-editor by default.
> >>> >
> >>> > BTW maybe nano-editor is not the best name for the subpackage,
> >>> > considering it will not include the nano text editor, but rather a conf
> >>> > snippet to set $EDITOR. Any alternative naming proposals?
> >>>
> >>> nano-default ?
> >>
> >>We're using zram-generator-defaults for this.
> >>https://koji.fedoraproject.org/koji/buildinfo?buildID=1527737
> >>
> >>Which is better? default or defaults? I don't have a preference.
> >
> >I went with "-defaults" in this case because the package provides "the
> >default configuration", i.e. "defaults".
> >
> >This doesn't translate exactly to the nano case, which is about making
> >the program the default "plugin" in another program (git).
> 
> This is not really about Git, and it's certainly not a "plugin".

That's why I put the word in quotes. I think we all know what the
relationship between git and editor is in this case and I didn't want
to waste words to formulate this more precisely for no benefit.

> Obeying EDITOR is required by POSIX e.g. see
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_08
> 
> Note that POSIX says "The default editor shall be vi." But that means
> when EDITOR isn't set. If the system or a user sets EDITOR to
> something else, it's still POSIX-conforming.

Personally, I don't care so much about what POSIX says. But not to worry:
in this case $EDITOR *will* be set, so we're all POSIX-compliant ;)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org