Hm, looks like something is still wrong, I'm getting "This user must be in one
of the following groups to be allowed to be added to this project: packager"
error when adding "yshestakov" to my project.
I'm using this page https://src.fedoraproject.org/rpms/ucx/adduser to add him
as admin, is
Hello team,
Could someone investigate the failure on Blender 2.83.2 as tested on the
scratch build?
https://koji.fedoraproject.org/koji/taskinfo?taskID=46849313
I don't know what exactly causes the issue. Here is the source files:
https://src.fedoraproject.org/rpms/blender/tree/master
On 08.07.20 23:47, Adam Williamson wrote:
> I think it's `efibootmgr -b -L DefinitelyNotFedora`, where is
> the number of the entry called 'Fedora', which you could find by just
> running `efibootmgr` to get a list of entries. -b selects the entry to
> operate on and -L changes the
I see you successfully added comaintainer :)
чт, 9 июл. 2020 г., 10:14 Vascom :
> Try again.
> You can see that packager group present
> https://admin.fedoraproject.org/accounts/user/view/yshestakov
>
> чт, 9 июл. 2020 г. в 10:09, Andrey Maslennikov >:
> >
> > Hm, looks like something is still
Try again.
You can see that packager group present
https://admin.fedoraproject.org/accounts/user/view/yshestakov
чт, 9 июл. 2020 г. в 10:09, Andrey Maslennikov :
>
> Hm, looks like something is still wrong, I'm getting "This user must be in
> one of the following groups to be allowed to be added
On 09. 07. 20 10:22, Dan Horák wrote:
On Thu, 9 Jul 2020 01:08:57 -0700
Luya Tshimbalanga wrote:
Hello team,
Could someone investigate the failure on Blender 2.83.2 as tested on
the scratch build?
https://koji.fedoraproject.org/koji/taskinfo?taskID=46849313
I don't know what exactly causes
On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote:
> On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr
> > wrote:
> > > needlessly disables a lot of kernel functionality
> >
> >
> > It disables functionality which
yshestakov had to re-login to https://src.fedoraproject.org/ to sync group
membership. Now everything is OK, thanks a lot!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr wrote:
> This is not something that's beneficial here, it's only
> harming our users.
That seems exceedingly myopic to me. I'm guessing you've not been
following the last few years of security research, where attacking the
firmware is now the best
On Thu, 9 Jul 2020 01:08:57 -0700
Luya Tshimbalanga wrote:
> Hello team,
>
> Could someone investigate the failure on Blender 2.83.2 as tested on
> the scratch build?
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=46849313
>
> I don't know what exactly causes the issue. Here is the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
One just noticed that `dnf autoremove` is trying to remove `fedora-
repos-modular` and `fedora-repos-rawhide-modular`.
tl;dr. fedora-repos-modular inherit installation reason from fedora-
repos (DEPENDENCY) and nothing depends on
On Thu, 2020-07-09 at 00:07 +0200, Sandro Mani wrote:
> I'm working on updating the mingw toolchain [1], and am hitting the
> situation [2] where I build with -fstack-protector in the ldflags, can
> confirm that -lssp and -lssp_nonshared are automatically added to the
> ldflags (seen via gcc -v
On 22. 06. 20 9:53, Clement Verna wrote:
One high level feature worth noting :
* you can now associate BZ tickets to the automatically created rawhide updates.
The bugs mentioned with the format "fix(es)|close(s)
(fedora|epel|rh|rhbz)#BUG_ID" in the changelog will be associated to the
On Wed, Jul 08, 2020 at 11:31:20AM -0400, Matthew Miller wrote:
> On Wed, Jul 08, 2020 at 03:48:23PM +0200, Till Maas wrote:
> > Just had another idea, how about instead of branch down from the rawhide
> > branch to new branched to make Rawhide always use the fxy version that
> > it develops. So
On Thu, Jul 09, 2020 at 12:55:44PM +0200, Igor Raits wrote:
> One just noticed that `dnf autoremove` is trying to remove `fedora-
> repos-modular` and `fedora-repos-rawhide-modular`.
>
[...]
> I don't know where / which the fix should be: DNF, comps or both.
> Simply putting the
John M. Harris Jr wrote:
> That's not what this discussion results from. This discussion results from
> somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing
> our applications at random, and ruining our desktop experience.
This is full of inaccurate statements
1. The KDE
El mar., 30 jun. 2020 a las 10:26, Ben Cotton ()
escribió:
> https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
>
> == Summary ==
> As [[Changes/EnableEarlyoom|Fedora Workstation did in F32]], install
> earlyoom package, and enable it by default. If both RAM and swap go below
> 10% free, earlyoom
On Tue, Jul 07, 2020 at 09:44:47PM +0200, Markus Larsson wrote:
>
>
> On 7 July 2020 21:20:22 CEST, Matthew Miller wrote:
> >On Tue, Jul 07, 2020 at 09:03:19PM +0200, Till Maas wrote:
> >> in https://pagure.io/fesco/issue/2410 I proposed to name the dist-git
> >> branch for Fedora Rawhide
Is there a better way to include local repos in mock builds than doing
something like this in my /etc/mock/default.cfg:
include('fedora-32-x86_64.cfg')
config_opts['dnf.conf'] = config_opts['dnf.conf'] + """
[my]
name=My repository
baseurl=http://jack/repos/$releasever/$basearch
enabled=1
Przemek Klosowski via devel wrote:
> * disk access is literally O(1) slower than RAM access
This notation is meaningless. By the definition of the O notation,
O(1)=O(1)=O(k) for any constant k.
Kevin Kofler
___
devel mailing list --
On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
> DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on
> a system upgrade, because we want that package to be prensented on the
> system. However I worry that DNF does not possess a capability for doing
> it.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
> > DNF should perform "dnf mark install fedora-repos-rawhide-modular"
> > action on
> > a system upgrade, because we want that
On Thursday, July 9, 2020 7:57:25 AM MST Reindl Harald (privat) wrote:
> Am 09.07.20 um 16:53 schrieb John M. Harris Jr:
> > On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote:
> >> +1 This would be a genuine improvement for end users!
> >
> > In what way do you believe this will be an
On Thu, Jul 9, 2020 at 7:51 am, John M. Harris Jr
wrote:
There's absolutely no justification for this, as I see it.
You're willfully ignoring what everybody else is telling you: we don't
want out-of-control applications to bring down the desktop. GNOME
doesn't want it, and KDE doesn't want
>You can limit the process with cgroups
In this case the process will be killed by OOM killer. Note that OOM killer
exists by default. Limiting cgroup means the OOM killer will be invoked in
the cgroup. With earlyoom you database server will get SIGTERM and maybe
will gracefully shutdown.
пт, 10
Hello Igor,
Sorry for the delay.
Igor Raits writes:
> On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
>>
>> == Summary ==
>> Network Security Services (NSS) historically supports 2 different
>> database backends, based on SQLite and
On Thu, 2020-07-09 at 07:46 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote:
> > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr <
> > joh...@splentity.com>
> > wrote:
> > > This is not something that's beneficial here, it's only
> > > harming our
On Thu, Jul 9, 2020 at 9:49 AM Rex Dieter wrote:
>
> part of some irc discussions on
> https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
>
> raised my attention to related item,
> https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>
> As it stands currently with earlyoom, it's default thresholds
On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote:
> On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote:
>
> > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> >
> > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr
> > > wrote:
> > >
> > > >
On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote:
> John M. Harris Jr wrote:
>
>
> > That's not what this discussion results from. This discussion results
> > from
> > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM killing
> > our applications at random, and ruining
On Thu, 2020-07-09 at 07:38 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote:
> > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote:
> >
> > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> > >
> > > > On
On 7/8/20 11:15 PM, John M. Harris Jr wrote:
>> * disk access is literally O(1) slower than RAM access
> This is just false, and you can prove that on your own system using only
> `dd`.
> In fact, if your system is newer than my Lenovo ThinkPad X200 Tablet, you'll
> probably have even
On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote:
> On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> > Unless I'm mistaken, it should only be present if the user manually
> > installed
> > it, and opted into modularity, right?
>
>
> No, it should be installed by default.
>By killing their software, while it's legitimately using RAM, as expected?
Memory usage causes system hang is not legitimately using RAM. Expected
behavior is killing memory hog.
чт, 9 июл. 2020 г. в 23:53, John M. Harris Jr :
> On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote:
> >
On Thu, Jul 9, 2020 at 8:52 AM John M. Harris Jr wrote:
> What's the KDE SIG's rationale behind supporting this? This actively limits
> the amount of RAM that end users are able to make use of. The more RAM the end
> user has, the more RAM is not available for use, because EarlyOOM will kill
>
On Thu, Jul 9, 2020 at 10:49 am, Rex Dieter
wrote:
Upon reading the SwapOnZRAM feature proposal, I see it is advocating
allocating 50% of ram for swap. I'd like folks to consider and
evaluate how
this impacts earlyoom. It effectively makes the earlyoom memory
threshold
double (right?). If
John M. Harris Jr wrote:
> On Thursday, July 9, 2020 5:25:36 AM MST Rex Dieter wrote:
>> John M. Harris Jr wrote:
>>
>>
>> > That's not what this discussion results from. This discussion results
>> > from
>> > somebody outside the KDE SIG deciding the KDE Spin needs EarlyOOM
>> > killing our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, 2020-07-09 at 07:35 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote:
> > I don't know where / which the fix should be: DNF, comps or both.
> > Simply putting the fedora-repos-modular in comps won't
part of some irc discussions on
https://fedoraproject.org/wiki/Changes/KDEEarlyOOM
raised my attention to related item,
https://fedoraproject.org/wiki/Changes/SwapOnZRAM
As it stands currently with earlyoom, it's default thresholds are 4% ram and
10% swap before it acts. That's fine and dandy.
On Thu, Jul 09, 2020 at 08:40:52AM -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 7:45:07 AM MST Igor Raits wrote:
> > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> > > Unless I'm mistaken, it should only be present if the user manually
> > > installed
> > > it, and
On Thu, Jul 9, 2020, at 10:36 AM, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
> > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on
> > a system upgrade, because we want that package to be prensented on the
> > system. However I
On Thursday, July 9, 2020 2:17:06 PM CEST Sam Varshavchik wrote:
> Is there a better way to include local repos in mock builds than doing
> something like this in my /etc/mock/default.cfg:
>
> include('fedora-32-x86_64.cfg')
>
> config_opts['dnf.conf'] = config_opts['dnf.conf'] + """
>
> [my]
On Thursday, July 9, 2020 8:17:50 AM MST you wrote:
> keep private mail private idiot
You're responding to my post on a mailing list. I don't see any reason to keep
this private. I'm not the only one on this list that you've attempted to
contact directly with this sort of comment either, and I
On Tue, 07 Jul 2020 21:11:31 +0200, Kevin Fenzi wrote:
> I am not sure what to tell you here. Perhaps you could describe the
> reason you are working on the chromium debuginfo? Is it broken? Missing?
> Less useful that normal?
Missing. Completely.
And it is not just about enabling it (=remove
I'm working on a spec, pulling source with forgemeta/scm
With known/supported scm sources (e.g., github), it works as expected, with no
issues.
Atm, I'm trying to pull from a different source,
git.kernel.org
with this 'ofono-test.spec'
OLD: Fedora-Rawhide-20200708.n.0
NEW: Fedora-Rawhide-20200709.n.0
= SUMMARY =
Added images:1
Dropped images: 1
Added packages: 13
Dropped packages:23
Upgraded packages: 135
Downgraded packages: 0
Size of added packages: 89.61 MiB
Size of dropped packages
On Thursday, July 9, 2020 3:55:44 AM MST Igor Raits wrote:
> I don't know where / which the fix should be: DNF, comps or both.
> Simply putting the fedora-repos-modular in comps won't help since DNF
> is only using them when running `group install/update/remove`.
What's to fix? Sounds like a
On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote:
> On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr
> wrote:
> > This is not something that's beneficial here, it's only
> > harming our users.
>
>
> That seems exceedingly myopic to me. I'm guessing you've not been
> following the
On Thursday, July 9, 2020 6:24:41 AM MST Sergio Belkin wrote:
> +1 This would be a genuine improvement for end users!
In what way do you believe this will be an improvement for end users? By
killing their software, while it's legitimately using RAM, as expected? How
exactly is that beneficial?
On Thu, Jul 9, 2020 at 10:50 AM Daiki Ueno wrote:
>
> Hello Igor,
>
> Sorry for the delay.
>
> Igor Raits writes:
>
> > On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
> >>
> >> == Summary ==
> >> Network Security Services (NSS)
On Thu, Jul 9, 2020 at 11:50 AM Rex Dieter wrote:
>
> Upon reading the SwapOnZRAM feature proposal, I see it is advocating
> allocating 50% of ram for swap. I'd like folks to consider and evaluate how
> this impacts earlyoom. It effectively makes the earlyoom memory threshold
> double (right?).
>75% and 6G
>for the cap might be better.
I agree. I think that 4GB cap is too small and 4 GB may be used quickly.
>I regularly see 3 to 1 and even 4 to 1.
It's true. It's easy to get 4:1 with browser. In fact, the compression
ratio is highly dependent on the workload. I get 1.4:1 with blender,
On Wed, Jul 08, 2020 at 02:20:06PM -0700, John M. Harris Jr wrote:
> > Yeah I guess for /usr the most relevant write metric is "does it slow down
> > DNF upgrades or install operations enough to be noticeable / annoying /
> > problematic"?
> More importantly, does it hurt the performance of
On Thursday, July 9, 2020 10:32:06 AM MST Matthew Miller wrote:
> On Thu, Jul 09, 2020 at 08:46:57AM -0700, John M. Harris Jr wrote:
>
> > On Thursday, July 9, 2020 8:17:50 AM MST you wrote:
> >
> > > keep private mail private idiot
> >
> >
> > You're responding to my post on a mailing list. I
On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
> > DNF should perform "dnf mark install fedora-repos-rawhide-modular" action on
> > a system upgrade, because we want that package to be prensented on the
> > system. However I
On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote:
> On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
> > > DNF should perform "dnf mark install fedora-repos-rawhide-modular"
> > > action on
> > > a system upgrade, because
On Thu, 2020-07-09 at 11:09 -0700, Adam Williamson wrote:
> On Thu, 2020-07-09 at 16:45 +0200, Igor Raits wrote:
> > On Thu, 2020-07-09 at 07:36 -0700, John M. Harris Jr wrote:
> > > On Thursday, July 9, 2020 5:24:59 AM MST Petr Pisar wrote:
> > > > DNF should perform "dnf mark install
On Thu, 09 Jul 2020 18:07:39 +0300
nick...@gmail.com wrote:
> Yes, that's why "secure boot" should only be an option and the user
> must have the option to turn it off. Otherwise, it wouldn't be
> possible to do any kernel development on that computer.
For my edification. I build custom
On Thu, Jul 09, 2020 at 11:09:57AM -0700, Adam Williamson wrote:
> What we're dealing with now is awkward consequences of this change for
> existing installs, where we'd probably want to *keep* modular repos,
> especially if any modules are actually enabled.
Is it a terrible idea to suggest that
On Thu, Jul 09, 2020 at 10:40:39AM -0700, John M. Harris Jr wrote:
> I briefly discussed the situation with bcotton, and that's how it'll handle
> that in the future. I wasn't aware of the particular situation.
Thanks John!
--
Matthew Miller
Fedora Project Leader
On 7/6/20 8:21 PM, Chris Murphy wrote:
...
> Yes. Also in fuzzing there is the concept of "when to stop fuzzing"
> because it's a rabbit hole, you have to come up for air at some point,
> and work on other things. But you raise a good and subtle point which
> is also that ext4 has a very good
On 7/9/20 12:24 PM, Alexey A. wrote:
I agree. I think that 4GB cap is too small and 4 GB may be used quickly.
Since the values being used seem to have been determined somewhat
heuristically for both EarlyOOM and SwapOnZRAM, I was wondering if there
was any prediction for how the values
On 7/6/20 12:07 AM, Chris Murphy wrote:
> On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
> wrote:
>>
>> On 7/3/20 1:41 PM, Chris Murphy wrote:
>>> SSDs can fail in weird ways. Some spew garbage as they're
>>> failing, some go read-only. I've seen both. I don't have stats on
>>> how common it is for
Il 09/07/20 15:12, Miro Hrončok ha scritto:
>
> Finally I got to testing this.
>
> The bugzilla was added to the update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-c1be13ded8
>
> But it was not closed:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1851519
>
> Should I report this as
On 7/9/20 1:51 PM, Eric Sandeen wrote:
On 7/6/20 12:07 AM, Chris Murphy wrote:
On Fri, Jul 3, 2020 at 8:40 PM Eric Sandeen
wrote:
On 7/3/20 1:41 PM, Chris Murphy wrote:
SSDs can fail in weird ways. Some spew garbage as they're
failing, some go read-only. I've seen both. I don't have stats
On Thu, Jul 9, 2020 at 12:53 PM Brandon Nielsen wrote:
>
> On 7/9/20 12:24 PM, Alexey A. wrote:
> > I agree. I think that 4GB cap is too small and 4 GB may be used quickly.
> >
>
>
> Since the values being used seem to have been determined somewhat
> heuristically for both EarlyOOM and
https://fedoraproject.org/wiki/Changes/ModularPolicy
== Summary ==
Establish a set of rules for Modular content in Fedora to ensure an
optimal user and packager experience.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@redhat.com
== Detailed Description ==
Over the
On Thu, Jul 09, 2020 at 08:46:57AM -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 8:17:50 AM MST you wrote:
> > keep private mail private idiot
>
> You're responding to my post on a mailing list. I don't see any reason to
> keep
> this private. I'm not the only one on this list
On Thursday, July 9, 2020 9:22:01 AM MST Alexey A. wrote:
> >You can limit the process with cgroups
>
> In this case the process will be killed by OOM killer. Note that OOM killer
> exists by default. Limiting cgroup means the OOM killer will be invoked in
> the cgroup. With earlyoom you database
On Thu, 09 Jul 2020 23:10:46 +0300
nick...@gmail.com wrote:
> On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
> > That is, isn't this only an issue if the person doing the kernel
> > development hasn't generated their own key, and isn't signing their
> > kernels locally?
>
> To be
On Thu, 9 Jul 2020 at 16:49, Chris Murphy wrote:
>
> On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote:
> >
> > On 7/9/20 2:11 PM, Josef Bacik wrote:
> > >>
> > >> From what I've gathered from these responses, btrfs is unique in that
> > >> it is
> > >> /expected/ that if anything goes wrong,
On 7/9/20 8:44 AM, Kevin Kofler wrote:
Przemek Klosowski via devel wrote:
* disk access is literally O(1) slower than RAM access
This notation is meaningless. By the definition of the O notation,
O(1)=O(1)=O(k) for any constant k.
Yes, you are right of course, but I just hope that
Once upon a time, nick...@gmail.com said:
> To be honest, I don't know. Do all UEFI secure boot implementations
> allow you to add your own keys to the list of trusted keys?
I believe that the Microsoft OEM Windows x86_64 distribution
requirements require UEFI, with Scure Boot enabled, and with
- Original Message -
> From: "Josef Bacik"
> To: devel@lists.fedoraproject.org
> Sent: Thursday, July 9, 2020 9:11:07 PM
> Subject: Re: Fedora 33 System-Wide Change proposal: Make btrfs the default
> file system for desktop variants
>
> On 7/9/20 1:51 PM, Eric Sandeen wrote:
> > On
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
> On Thu, 09 Jul 2020 18:07:39 +0300
> nick...@gmail.com wrote:
>
> > Yes, that's why "secure boot" should only be an option and the user
> > must have the option to turn it off. Otherwise, it wouldn't be
> > possible to do any kernel
On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote:
>
> On 7/9/20 2:11 PM, Josef Bacik wrote:
> >>
> >> From what I've gathered from these responses, btrfs is unique in that it
> >> is
> >> /expected/ that if anything goes wrong, the administrator should be
> >> prepared
> >> to scrape out
On Thu, Jul 9, 2020 at 3:06 PM Stephen John Smoogen wrote:
>
> That is because anyone who questions the perfection of ZFS is quickly
> burned at a stake.
I think Neal also has a good take on why, which is that it was mostly
a closed door development early on, wasn't used on heterogeneous
On 7/9/20 2:11 PM, Josef Bacik wrote:
>>
>> From what I've gathered from these responses, btrfs is unique in that it is
>> /expected/ that if anything goes wrong, the administrator should be prepared
>> to scrape out remaining data, re-mkfs, and start over. If that's acceptable
>> for the Fedora
On Thu, 2020-07-09 at 12:56 -0700, Eric Sandeen wrote:
> On 7/9/20 2:11 PM, Josef Bacik wrote:
> > > From what I've gathered from these responses, btrfs is unique in that it
> > > is
> > > /expected/ that if anything goes wrong, the administrator should be
> > > prepared
> > > to scrape out
On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote:
> However I have had bad kernels, power outages, loss of battery power
> (laptops on too long suspend) and other random reasons to force
> reboot
> a system. That has been the primary case of file system checks
> through
> my Fedora usage. And
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
> On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote:
>> However I have had bad kernels, power outages, loss of battery power
>> (laptops on too long suspend) and other random reasons to force
>> reboot
>> a system. That has been the primary case
On 7/9/20 3:38 PM, Chris Murphy wrote:
> On Thu, Jul 9, 2020 at 1:57 PM Eric Sandeen wrote:
>> On 7/9/20 2:11 PM, Josef Bacik wrote:
From what I've gathered from these responses, btrfs is unique in that it
is
/expected/ that if anything goes wrong, the administrator should be
On Thu, 2020-07-09 at 23:10 +0300, nick...@gmail.com wrote:
> On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
> > On Thu, 09 Jul 2020 18:07:39 +0300
> > nick...@gmail.com wrote:
> >
> > > Yes, that's why "secure boot" should only be an option and the user
> > > must have the option to
On Thu, 2020-07-09 at 13:32 -0700, Davide Cavalca via devel wrote:
> On Thu, 2020-07-09 at 16:15 -0400, Simo Sorce wrote:
> > However I have had bad kernels, power outages, loss of battery power
> > (laptops on too long suspend) and other random reasons to force
> > reboot
> > a system. That has
On Thu, Jul 9, 2020 at 4:16 PM Simo Sorce wrote:
>
> On Thu, 2020-07-09 at 12:56 -0700, Eric Sandeen wrote:
> > On 7/9/20 2:11 PM, Josef Bacik wrote:
> > > > From what I've gathered from these responses, btrfs is unique in that
> > > > it is
> > > > /expected/ that if anything goes wrong, the
On 7/9/20 4:27 PM, Eric Sandeen wrote:
> On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
>> As someone on one of the teams at FB that has to deal with that, I can
>> assure you all the scenarios you listed can and do happen, and they
>> happen a lot. While we don't have the "laptop's out
Hello!
I'm trying to add a co-maintainer to my project
(https://src.fedoraproject.org/rpms/ucx). User I want to add just recently
joined to Fedora environment (the name is yshestakov) and need a sponsor to
become a packager. I've tried to add him to the group, but he didn't get any
Richard Hughes writes:
> On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote:
>> As I understand it, there is a lot of evolving OS specific subtlety
>> involved, so I am asking specifically how this would look on current
>> Fedora and what to expect in the near future.
>
> Just a heads-up; the
Kevin Fenzi writes:
> What does 'support for clevis' there look like? you mean just binding a
> encrypted drive to look for clevis servers on boot?
Yes, currently we only support the "tang" pin.
> I think tpm2 might be good, but lots of machines don't have tpm2.
> So I would think it would
Are you sure that he will be a good maintainer?
If you want to follow this
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Become_a_co-maintainer
I can be a sponsor.
чт, 9 июл. 2020 г. в 09:01, Andrey Maslennikov :
>
> Hello!
>
> I'm trying to add a co-maintainer to my
Yes, I trust him completely on this matter.
@Vascom thank you for your help! Should I open a ticket for it?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of
Done.
Now you can add yshestakov as comaintainer.
чт, 9 июл. 2020 г. в 09:47, Andrey Maslennikov :
>
> Yes, I trust him completely on this matter.
>
> @Vascom thank you for your help! Should I open a ticket for it?
> ___
> devel mailing list --
> Yes, it's completely reasonable to not do it. It might seem like a big
> change on its own, but Btrfs has had native compression for 10+ years,
> and at least three years for most all of the workloads at Facebook. So
> it's quite safe.
But it has been eating data as recently as 2018 [1] and the
On 7/9/20 9:30 PM, Eric Sandeen wrote:
On 7/9/20 8:22 PM, Josef Bacik wrote:
On 7/9/20 7:23 PM, Eric Sandeen wrote:
On 7/9/20 4:27 PM, Eric Sandeen wrote:
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
As someone on one of the teams at FB that has to deal with that, I can
assure
On 7/9/20 7:23 PM, Eric Sandeen wrote:
On 7/9/20 4:27 PM, Eric Sandeen wrote:
On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
...
As someone on one of the teams at FB that has to deal with that, I can
assure you all the scenarios you listed can and do happen, and they
happen a lot. While
On 7/9/20 8:22 PM, Josef Bacik wrote:
> On 7/9/20 7:23 PM, Eric Sandeen wrote:
>> On 7/9/20 4:27 PM, Eric Sandeen wrote:
>>> On 7/9/20 3:32 PM, Davide Cavalca via devel wrote:
>>
>> ...
>>
As someone on one of the teams at FB that has to deal with that, I can
assure you all the scenarios
On 7/9/20 9:15 PM, Josef Bacik wrote:
> On 7/9/20 9:30 PM, Eric Sandeen wrote:
...
>>> This test is run constantly by us, specifically because it's the error
>>> cases that get you. But not for crash consistency reasons, because we're
>>> solid there. I run them to make sure I don't have
On Friday, July 10, 2020, Zachary Lym wrote:
> > Yes, it's completely reasonable to not do it. It might seem like a big
> > change on its own, but Btrfs has had native compression for 10+ years,
> > and at least three years for most all of the workloads at Facebook. So
> > it's quite safe.
>
>
On 7/9/20 10:46 AM, John M. Harris Jr wrote:
"Secure Boot" doesn't make root non-uid 0, and can't keep root from
controlling system devices, even uploading unsigned firmware to peripherals.
While it's true that a completely secure software chain doesn't really
exist yet, we are slowly going
https://bugzilla.redhat.com/show_bug.cgi?id=1853569
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
1 - 100 of 118 matches
Mail list logo
