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.
>
> Bu
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 in
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 stup
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 yo
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 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
> 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 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 o
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
hardware
- 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 7/6
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 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 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 ad
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 t
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
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 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, t
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 hon
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 remai
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 lu
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 tur
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 rema
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 develo
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, 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 SwapOnZRAM
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 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
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 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 migh
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 fsc
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 fedora-repos
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 kernels,
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 M
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 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
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 l
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
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, 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 that
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 install
>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 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 s
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 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
> so
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'
>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
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 a
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 it
>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 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?).
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) histo
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 opt
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 b
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.
Wh
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 fast
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 i
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 i
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 user
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 app
-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
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? I
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 Wed,
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 ou
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 d
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 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 last
-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 p
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 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:
> > >
> > > > nee
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. (Except
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 featu
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 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 update
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 -- d
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 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 "rawhi
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 SI
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 in
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 fedora-repos-modula
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
gpg
-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 fedora-repo
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 wa
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 w
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 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 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 so
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
Thank
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 'label
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
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
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 th
93 matches
Mail list logo
