On Thu, Jan 02, 2020 at 12:27:46PM -0500, Neal Gompa wrote:
> > Would it make you feel better if I added a para to the Change page saying
> > that the sysusers.d definition may be split out into a separate package
> > if desired?
> >
>
> Yes, it would. Guidelines for these kinds of splits should a
But what about users which actually have ffmpeg installed? Do you think
they don't deserve having peek in menu?
On Fri, Jan 3, 2020, 04:02 John M. Harris Jr wrote:
> On Wednesday, January 1, 2020 7:34:27 PM MST Leigh Scott wrote:
> > > Why we should drop such useful app just because it doesn't w
On 1/2/20 5:29 PM, Neal Gompa wrote:
On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote:
For us, since we don't have the SUSE patches that make PreReq do
things, the way we'd declare this with upstream RPM features would be:
Please don't spread misinformation, openSUSE doesn't have patches to
On 1/2/20 6:55 PM, John M. Harris Jr wrote:
On Wednesday, January 1, 2020 7:34:27 PM MST Leigh Scott wrote:
Why we should drop such useful app just because it doesn't work on
Cinnamon? It works on GNOME without ffpmeg and rpm fusion repo, see
screenshot [1].
Please prevent your useless app fro
On 02. 01. 20 9:59, Miro Hrončok wrote:
Hello, this is just a heads up that we are about to update the Python RPM
dependency generators to support versions like 1.2.*, the ~= operator etc.
See the PR:
https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4
The code is tested a
Ugh, that is a bug in the generator. It should do something like ((x
with y) or (z with 0)).
On Fri, Jan 3, 2020 at 10:26 AM Miro Hrončok wrote:
>
> On 02. 01. 20 9:59, Miro Hrončok wrote:
> > Hello, this is just a heads up that we are about to update the Python RPM
> > dependency generators to s
On 03. 01. 20 10:26, Miro Hrončok wrote:
On 02. 01. 20 9:59, Miro Hrončok wrote:
Hello, this is just a heads up that we are about to update the Python RPM
dependency generators to support versions like 1.2.*, the ~= operator etc.
See the PR:
https://src.fedoraproject.org/rpms/python-rpm-gener
> But what about users which actually have ffmpeg installed? Do you think
> they don't deserve having peek in menu?
>
> On Fri, Jan 3, 2020, 04:02 John M. Harris Jr wrote:
NO, it's not required on cinnamon, users can use the screenshot+ Record desktop
applet instead.
___
On 1/3/20 10:49 AM, Leigh Scott wrote:
>> But what about users which actually have ffmpeg installed? Do you think
>> they don't deserve having peek in menu?
>>
>> On Fri, Jan 3, 2020, 04:02 John M. Harris Jr > wrote:
>
> NO, it's not required on cinnamon, users can use the screenshot+ Record
> de
On Thu, 2 Jan 2020 13:07:40 +0100, Vitaly Zaitsev via devel wrote:
> On 02.01.2020 10:05, Benson Muite wrote:
> > I suspect there would be interest in having a royalty free version of
> > FFMPEG
>
> No, please, don't do this. It will be a huge headache for RPM Fusion
> maintainers.
What sort
On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen wrote:
>
> On 1/2/20 5:29 PM, Neal Gompa wrote:
> > On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote:
>
> > For us, since we don't have the SUSE patches that make PreReq do
> > things, the way we'd declare this with upstream RPM features would be:
>
On 1/3/20 12:35 PM, Neal Gompa wrote:
On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen wrote:
On 1/2/20 5:29 PM, Neal Gompa wrote:
On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote:
For us, since we don't have the SUSE patches that make PreReq do
things, the way we'd declare this with upstre
On Fri, Jan 3, 2020 at 5:42 AM Panu Matilainen wrote:
>
> On 1/3/20 12:35 PM, Neal Gompa wrote:
> > On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen wrote:
> >>
> >> On 1/2/20 5:29 PM, Neal Gompa wrote:
> >>> On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote:
> >>
> >>> For us, since we don't have
On 03. 01. 20 10:33, Miro Hrončok wrote:
On 03. 01. 20 10:26, Miro Hrončok wrote:
On 02. 01. 20 9:59, Miro Hrončok wrote:
Hello, this is just a heads up that we are about to update the Python RPM
dependency generators to support versions like 1.2.*, the ~= operator etc.
See the PR:
https://s
On 1/3/20 12:43 PM, Neal Gompa wrote:
On Fri, Jan 3, 2020 at 5:42 AM Panu Matilainen wrote:
On 1/3/20 12:35 PM, Neal Gompa wrote:
On Fri, Jan 3, 2020 at 4:01 AM Panu Matilainen wrote:
On 1/2/20 5:29 PM, Neal Gompa wrote:
On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote:
For us, since
On Friday, 03 January 2020 at 11:14, Michael Schwendt wrote:
> On Thu, 2 Jan 2020 13:07:40 +0100, Vitaly Zaitsev via devel wrote:
>
> > On 02.01.2020 10:05, Benson Muite wrote:
> > > I suspect there would be interest in having a royalty free version of
> > > FFMPEG
> >
> > No, please, don't do
I do not understand this error message; i.e., I have no idea what the cause is ?
Looking at the informaiton for the build
https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178
The only failure message I see is
GenericError: cannot update build 1425936, state: COMPLETE
The output
On Fri, Jan 3, 2020 at 12:37 PM Brad Bell wrote:
> I do not understand this error message; i.e., I have no idea what the
> cause is ?
>
> Looking at the informaiton for the build
> https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178
>
> The only failure message I see is
> Gener
On Fri, 3 Jan 2020 12:14:37 +0100, Dominik 'Rathann' Mierzejewski wrote:
> > > > I suspect there would be interest in having a royalty free version of
> > > > FFMPEG
> > >
> > > No, please, don't do this. It will be a huge headache for RPM Fusion
> > > maintainers.
> >
> > What sort of "h
On Fri, Jan 3, 2020 at 5:00 AM František Šumšal wrote:
>
> On 1/3/20 10:49 AM, Leigh Scott wrote:
> >> But what about users which actually have ffmpeg installed? Do you think
> >> they don't deserve having peek in menu?
> >>
> >> On Fri, Jan 3, 2020, 04:02 John M. Harris Jr >> wrote:
> >
> > NO,
Hi
lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
needed by the package is not provided by any packages. The full
installation error is as follows:
```
sudo dnf install lv2-sorcer
Last metadata expiration check: 0:32:35 ago on Fri 03 Jan 2020 08:00:41 AM
EST.
Error:
Prob
I did draft package of vokoscreenNG if someone interesting
RR: https://bugzilla.redhat.com/show_bug.cgi?id=1787578
Works without ffmpeg. Thanks for tip @Neal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-l
On Fri, Jan 03, 2020 at 08:36:45AM -0500, Code Zombie wrote:
> Hi
>
> lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
> needed by the package is not provided by any packages. The full
> installation error is as follows:
>
> ```
> sudo dnf install lv2-sorcer
> Last metadata
Hi,
I tried:
$ fedpkg clone wdune
Cloning into 'wdune'...
muft...@pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute comman
On Fri, Jan 3, 2020 at 3:08 PM J. Scheurich wrote:
>
> Hi,
>
> I tried:
>
> $ fedpkg clone wdune
> Cloning into 'wdune'...
> muft...@pkgs.fedoraproject.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and
You might have to wait a bit until the changes have propagated.
If it still doesn't work, make sure the .ssh/id_rsa file has mode 600,
otherwise OpenSSH will give you errors.
Thanks, but it still do not work:
$ ls -l .ssh/id_rsa.pub
-rw---. 1 mufti mufti 575 Jan 3 13:41 .ssh/id_rsa.pub
[muf
On Friday, 03 January 2020 at 14:28, J. Scheurich wrote:
> > You might have to wait a bit until the changes have propagated.
> > If it still doesn't work, make sure the .ssh/id_rsa file has mode 600,
> > otherwise OpenSSH will give you errors.
> Thanks, but it still do not work:
>
> $ ls -l .ssh/i
On 1/3/20 3:55 PM, Dominik 'Rathann' Mierzejewski wrote:
What does
ssh -vvvmuft...@pkgs.fedoraproject.org
say?
$ ssh -vvv muft...@pkgs.fedoraproject.org
OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 Sep 2019
debug1: Reading configuration data /home/home/mufti/.ssh/config
debug1: Reading configuration
On 03.01.2020 11:14, Michael Schwendt wrote:
> What sort of "huge headache" would that be?
1. Most of ffmpeg-capable applications use compile-time checks for
available codecs presence.
2. Sync errors between repositories like chromium and
chromium-libs-media-freeworld.
> Third party repos like RP
On Friday, 03 January 2020 at 15:03, J. Scheurich wrote:
>
>
> On 1/3/20 3:55 PM, Dominik 'Rathann' Mierzejewski wrote:
> > What does
> > ssh -vvv muft...@pkgs.fedoraproject.org
> > say?
> $ ssh -vvv muft...@pkgs.fedoraproject.org
[...]
> debug1: Next authentication method: publickey
> debug1: Of
On Fri, Jan 03, 2020 at 08:36:45AM -0500, Code Zombie wrote:
> Hi
>
> lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
> needed by the package is not provided by any packages. The full
> installation error is as follows:
Looks like non-ntk library failed to build for last
Nico Kadel-Garcia writes:
> On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood wrote:
>> "John M. Harris Jr" writes:
>>> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
>>>
Issuing the command once per week harms no one
>>>
>>> Based on what's actual in the Change proposal, thi
On Fri, Jan 3, 2020 at 9:06 AM Robbie Harwood wrote:
>
> Nico Kadel-Garcia writes:
>
> > On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood wrote:
> >> "John M. Harris Jr" writes:
> >>> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
> >>>
> Issuing the command once per week ha
On Fri, Jan 03, 2020 at 11:05:43AM -0500, Robbie Harwood wrote:
> Nico Kadel-Garcia writes:
>
> > On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood wrote:
> >> "John M. Harris Jr" writes:
> >>> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
> >>>
> Issuing the command once pe
Chris Murphy writes:
> On Fri, Jan 3, 2020 at 9:06 AM Robbie Harwood wrote:
>> Nico Kadel-Garcia writes:
>>> On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood wrote:
"John M. Harris Jr" writes:
> On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote:
>
>> Issuing the co
Zbigniew Jędrzejewski-Szmek wrote:
> The dep was provided by non-ntk, which got retired about half a year
> ago [1] after FTBFSing since F29 [2].
Isn't it great when the policy designed to remove
breakage from the distribution actually CREATES breakage? Retiring packages
with no regards to their
On Fri, Jan 3, 2020, 19:25 Kevin Kofler wrote:
> Zbigniew Jędrzejewski-Szmek wrote:
> > The dep was provided by non-ntk, which got retired about half a year
> > ago [1] after FTBFSing since F29 [2].
>
> Isn't it great when the policy designed to remove
> breakage from the distribution actually CR
On Fri, 2020-01-03 at 10:21 -0700, Chris Murphy wrote:
> On Fri, Jan 3, 2020 at 9:06 AM Robbie Harwood
> wrote:
> > Nico Kadel-Garcia writes:
> >
> > > On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood <
> > > rharw...@redhat.com> wrote:
> > > > "John M. Harris Jr" writes:
> > > > > On Friday, Dece
On Fri, 3 Jan 2020 16:30:54 +0100, Vitaly Zaitsev via devel wrote:
> On 03.01.2020 11:14, Michael Schwendt wrote:
> > What sort of "huge headache" would that be?
>
> 1. Most of ffmpeg-capable applications use compile-time checks for
> available codecs presence.
Which is something you can only
No missing expected images.
Compose PASSES proposed Rawhide gating check!
All required tests passed
Failed openQA tests: 11/155 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-Rawhide-20200101.n.0):
ID: 506583 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.
https://fedoraproject.org/wiki/Changes/EnableEarlyoom
== Summary ==
Install earlyoom package, and enable it by default. This will cause
the kernel oomkiller to trigger sooner, but will not affect which
process it chooses to kill off. The idea is to recover from out of
memory situations sooner, rat
https://fedoraproject.org/wiki/Changes/Mono_6_6
== Summary ==
Update the Mono stack in Fedora from 5.20 to 6.6. We need to do again
a bootstrap build.
== Owner ==
* Name: [[User:tpokorra|Timotheus Pokorra]]
* Email: tpoko...@fedoraproject.org
== Detailed Description ==
Even between minor release
https://fedoraproject.org/wiki/Changes/BINUTILS234
== Summary ==
Rebase the binutils package from version 2.33 to version 2.34.
== Owner ==
* Name: Nick Clifton [https://fedoraproject.org/wiki/User:Nickc]
* Email: ni...@redhat.com
== Detailed Description ==
Switch the binutils package from bein
Paul Howarth wrote,
>
> perl-Time-Piece was obsoleted by the base perl package way back in> 5.10.0.
>
> perl-Time-Piece-MySQL is an extension to perl-Time-Piece.
Thanks for the info, Paul!
...Does that mean it no longer has any usefulness without perl-Time-Piece,and
should be similarly orphaned/
OLD: Fedora-Rawhide-20200101.n.0
NEW: Fedora-Rawhide-20200103.n.0
= SUMMARY =
Added images:3
Dropped images: 1
Added packages: 3
Dropped packages:4
Upgraded packages: 71
Downgraded packages: 0
Size of added packages: 112.70 MiB
Size of dropped packages
Robbie Harwood writes:
> Miro Hrončok writes:
>
>> The following packages are orphaned and will be retired when they
>> are orphaned for six weeks, unless someone adopts them. If you know for sure
>> that the package should be retired, please do so now with a proper reason:
>> https://fedoraproj
Ben Cotton writes:
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. The idea is to recover from out
Robbie Harwood writes:
> Ben Cotton writes:
>
>> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>>
>> == Summary ==
>> Install earlyoom package, and enable it by default. This will cause
>> the kernel oomkiller to trigger sooner, but will not affect which
>> process it chooses to kill off
On Friday, January 3, 2020 1:51:00 PM MST Robbie Harwood wrote:
> Robbie Harwood writes:
> > Ben Cotton writes:
> >> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
> >>
> >> == Summary ==
> >> Install earlyoom package, and enable it by default. This will cause
> >> the kernel oomkiller to
On Fri, Jan 3, 2020 at 11:48 AM Louis Lagendijk wrote:
>
> virt-manager does not enable discards on IDE or virtio disks. I think
> it DOES enable discard on SCSI disks. So strictly speaking the above is
> true as long as the default emulation layer is not SCSI but it is a
> matter of a few clicks
On Fri, Jan 3, 2020 at 1:35 PM Robbie Harwood wrote:
>
> The OOM killer is a kernel function.
Yes, this is indicated in the summary.
>I have no opinion on this proposal
> as it stands, but I would like it to include an explanation of why this
> requires a service in userspace to fix.
The 2nd fu
On Fri, Jan 3, 2020 at 10:14 PM John M. Harris Jr
wrote:
> Regardless, if this Change is accepted, it should probably be done on a
> per-
> spin basis. If the GNOME Spin wants this, that's one thing, but I don't
> believe this would be a good idea on servers.
>
Yes, and if you read the change wi
On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>
> == Summary ==
> Install earlyoom package, and enable it by default. This will cause
> the kernel oomkiller to trigger sooner, but will not affect which
> process it chooses to kill off. T
As some of you may know, we have been having issues with koji and bodhi
over the holidays. :( koji would sometimes not tag builds or error them
with odd error messages and bodhi wasn't pushing updates.
I'm happy to report that the underlying issue seems to be fixed now.
We hopefully will have a
Hello,
Can someone please explain why gdb dlopen()'s librpm instead of just
doing proper compile-time linking? Best I can tell, our patches to GDB
support both modes, and it seems to be unnecessarily painful for us to
have to track the soversion like that instead of just letting it pick
it up.
I
On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> Can someone please explain why gdb dlopen()'s librpm instead of just
> doing proper compile-time linking?
Because when it was written (2008) it was common to transfer /usr/bin/gdb
binary across OS versions (maybe incl. RHEL) as GDB had only v
On Fri, Jan 3, 2020 at 5:25 PM Jan Kratochvil wrote:
>
> On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> > Can someone please explain why gdb dlopen()'s librpm instead of just
> > doing proper compile-time linking?
>
> Because when it was written (2008) it was common to transfer /usr/bin/g
On Friday, January 3, 2020, Neal Gompa wrote:
> On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom
> >
> > == Summary ==
> > Install earlyoom package, and enable it by default. This will cause
> > the kernel oomkiller to trigger sooner,
On Fri, Jan 3, 2020 at 1:51 PM Robbie Harwood wrote:
>
> Another thought. Wouldn't some of the pain here be alleviated by
> setting vm.swappiness=0?
My sample size is not scientific. But, in my testing I can't tell any
difference for the swap under pressure case we're testing against. The
system
On Fri, Jan 3, 2020 at 3:41 PM drago01 wrote:
>
>
>
> On Friday, January 3, 2020, Neal Gompa wrote:
>>
>> On Fri, Jan 3, 2020 at 2:19 PM Ben Cotton wrote:
>> >
>> > https://fedoraproject.org/wiki/Changes/EnableEarlyoom
>> >
>> > == Summary ==
>> > Install earlyoom package, and enable it by defau
Kevin Fenzi wrote:
> However, due to the koji issues builds were in a state where bodhi
> ejected many of them from updates pushes. We are working on cleaning
> up the state of those updates and there's no need for maintainers to do
> anything with those updates at this time.
At least in this case
On Friday, January 3, 2020 3:48:50 PM MST Chris Murphy wrote:
> On Fri, Jan 3, 2020 at 1:51 PM Robbie Harwood wrote:
>
> >
> >
> > Another thought. Wouldn't some of the pain here be alleviated by
> > setting vm.swappiness=0?
>
>
> My sample size is not scientific. But, in my testing I can't te
drago01 wrote:
> The idea might be the implementation is not.
> Using a percentage to decide "almost out of memory" is going to hurt on
> systems with large amounts of memory be it a 32gb desktop or a 2tb server.
> You'd have plenty of memory left and it starts killing processes ...
And it will le
I think this would be a really big improvement for workstation and other
desktop spins, the handling of out of memory situations have been a consistent
paint point on Linux. However, may I ask why EarlyOOM was chosen over
something like NoHang [1]? I am a bit concerned that EarlyOOM's heuristi
John M. Harris Jr wrote:
> There is NO scenario in which hard shutdowns should occur, except battery
> failure on mobile devices. The state of the system on boot will vary
> wildly from what you may expect when it is hard powered off. I would
> suggest using SysRq in such events.
Unfortunately, Sy
On Fri, Jan 3, 2020 at 3:57 PM John M. Harris Jr wrote:
>
> There is NO scenario in which hard shutdowns should occur, except battery
> failure on mobile devices. The state of the system on boot will vary wildly
> from what you may expect when it is hard powered off. I would suggest using
> SysRq
On Fri, Jan 3, 2020 at 4:13 PM Tom Seewald wrote:
>
> I think this would be a really big improvement for workstation and other
> desktop spins, the handling of out of memory situations have been a
> consistent paint point on Linux. However, may I ask why EarlyOOM was chosen
> over something li
Fabio Valentini wrote:
> Don't blame Miro for doing the necessary things, just because you don't
> like the process.
The issue is that I do not agree that this process is necessary to begin
with.
> We have asked you multiple times to suggest a policy that works for you
> too, but you haven't don
On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> in the cases were I could issue syrq+b, responsiveness was so bad
> it'd take upwards of 15 minutes just to type out the command
In that case, I'd suggest waiting the 15 minutes, and then not bogging down
your system that badly the n
On Fri, Jan 03, 2020 at 11:55:27PM +0100, Kevin Kofler wrote:
> Kevin Fenzi wrote:
> > However, due to the koji issues builds were in a state where bodhi
> > ejected many of them from updates pushes. We are working on cleaning
> > up the state of those updates and there's no need for maintainers to
It no longer seems to be a part of libabigail (or available at all)...
I found it very useful.
Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Con
On Fri, Jan 3, 2020 at 9:15 PM Richard Shaw wrote:
>
> It no longer seems to be a part of libabigail (or available at all)...
>
> I found it very useful.
>
It moved to the libabigail-fedora package in Fedora 31.
--
真実はいつも一つ！/ Always, there's only one truth!
On Fri, Jan 3, 2020 at 8:41 PM Neal Gompa wrote:
> On Fri, Jan 3, 2020 at 9:15 PM Richard Shaw wrote:
> >
> > It no longer seems to be a part of libabigail (or available at all)...
> >
> > I found it very useful.
> >
>
> It moved to the libabigail-fedora package in Fedora 31.
>
Thanks, I tried
WINE worries me a lot. Why previous maintainer dropped it? I never have issues
with WINE package and it was always up to day. Hope someone will save package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le
Den lör 4 jan. 2020 kl 01:53 skrev John M. Harris Jr :
> On Friday, January 3, 2020 4:25:20 PM MST Chris Murphy wrote:
> > in the cases were I could issue syrq+b, responsiveness was so bad
> > it'd take upwards of 15 minutes just to type out the command
>
> In that case, I'd suggest waiting the 15
On 03.01.2020 20:18, Ben Cotton wrote:
> Workstation working group has discussed "better interactivity in
> low-memory situations" for some months. In certain use cases,
> typically compiling, if all RAM and swap are completely consumed,
> system responsiveness becomes so abysmal that a reasonable
On 03.01.2020 22:27, Neal Gompa wrote:
> and servers...
Admins will be very happy when such user-space killer will kill for
example PgSQL database server and cause DB corruption or loss of banking
transactions.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
__
On 03.01.2020 20:01, Michael Schwendt wrote:
> Which is something you can only fix with an RPM Fusion package,
> if you "control" (= build) all depending packages.
RPM Fusion will need to copy and rebuild all such packages and this is a
huge headache for maintainers and currently forbidden by repo
В Суб, 04/01/2020 в 08:27 +0100, Vitaly Zaitsev via devel пишет:
> I'm strongly against adding of any user-space OOM killers to Fedora
> default images. Users should explicitly enable them only when needed.
Just my 2 cents: i tested early versions of earlyoom and have weird
experience with it: it
79 matches
Mail list logo
