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://fedorapeople.org/groups/389ds/ci/nightly/2020/07/10/report-389-ds-base-1.4.4.4-20200709git318a3ce.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
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 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 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
The following Fedora EPEL 6 Security updates need testing:
Age URL
8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1a8a3c29a
putty-0.74-1.el6
4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-8c3e76982e
python-rsa-3.4.2-1.el6
4
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
The following Fedora EPEL 7 Security updates need testing:
Age URL
695 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d
condor-8.6.11-1.el7
434 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b
bubblewrap-0.3.3-2.el7
144
https://bugzilla.redhat.com/show_bug.cgi?id=1854141
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1149524
Package Review changed:
What|Removed |Added
Flags||needinfo?(dd...@cpan.org)
---
> 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
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
- 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 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
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
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
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,
Dear all,
You are kindly invited to the meeting:
EPEL Steering Committee on 2020-07-10 from 21:00:00 to 22:00:00 UTC
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.
A general agenda is the following:
#meetingname EPEL
#topic
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, 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, 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 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 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 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
https://bugzilla.redhat.com/show_bug.cgi?id=1854753
--- Comment #7 from Fedora Update System ---
FEDORA-2020-43a6a0fdca has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1854754
--- Comment #7 from Fedora Update System ---
FEDORA-2020-43a6a0fdca has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1854752
--- Comment #7 from Fedora Update System ---
FEDORA-2020-43a6a0fdca has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade
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
https://bugzilla.redhat.com/show_bug.cgi?id=1855334
Upstream Release Monitoring
changed:
What|Removed |Added
Summary|perl-Sereal-Encoder-4.016
https://bugzilla.redhat.com/show_bug.cgi?id=1855332
Upstream Release Monitoring
changed:
What|Removed |Added
Summary|perl-Sereal-4.016 is|perl-Sereal-4.017 is
https://bugzilla.redhat.com/show_bug.cgi?id=1855333
Upstream Release Monitoring
changed:
What|Removed |Added
Summary|perl-Sereal-Decoder-4.016
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
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
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
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 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 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
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 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
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
>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
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
>
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
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
>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)
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 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 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.
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: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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1855334
Bug ID: 1855334
Summary: perl-Sereal-Encoder-4.016 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Sereal-Encoder
Keywords: FutureFeature,
-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
https://bugzilla.redhat.com/show_bug.cgi?id=1855332
Bug ID: 1855332
Summary: perl-Sereal-4.016 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Sereal
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=1855333
Bug ID: 1855333
Summary: perl-Sereal-Decoder-4.016 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Sereal-Decoder
Keywords: FutureFeature,
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, 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 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
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 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
-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 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:
> > >
> > > >
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.
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
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
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 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
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
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
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
On 2020-07-07 19:54, Miro Hrončok wrote:
1) Add a custom --no-warn-root-privileges option
2) Hide the warning when $RPM_BUILD_ROOT is set.
3) Introduce an environment variable (e.g. PIP_NOWARN_ROOT)
4) Introduce our warning upstream, but make it opt-in only.
5) Hide the warning when --root is
-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
1 - 100 of 118 matches
Mail list logo
