В Суб, 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:
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
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: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
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
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
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
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!
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1778465
--- Comment #7 from Paul Howarth ---
(In reply to Emmanuel Seyman from comment #6)
> Re-submitted to stable.
I'm not convinced that's necessary. The package is in the repo (see
https://bugzilla.redhat.com/show_bug.cgi?id=1768303
--- Comment #5 from Paul Howarth ---
(In reply to claudio from comment #4)
> I am still experiencing this issue on RHEL 7.
> what does "updating perl-Dist-CheckConflicts package" mean?
yum update perl-Dist-CheckConflicts ?
--
You are
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.
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
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
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 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
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
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:
> 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:
>>
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1768303
claudio changed:
What|Removed |Added
CC||cmlomba...@ucsd.edu
--- Comment #4 from
https://bugzilla.redhat.com/show_bug.cgi?id=1778465
--- Comment #6 from Emmanuel Seyman ---
Re-submitted to stable.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list --
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
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
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
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,
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:
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
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,
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
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
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
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
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
Thank you for letting us know.
The need to inform epel-devel of adding a package is only if the
package is a "Limited Arch" package. Since your package is a noarch
package, and thus will be available for all arches, you do not need to
inform us, nor wait for our approval.
Please proceed with the
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,
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
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:
Hi,
I got the request to package `neofetch` for EPEL8 [1]. It's already in
Fedora for quite some time [2]. I have the intention to grant this
request. According to the EPEL packaging guidelines I need to inform
you first of this intention [3]. The package should work fine. If there
are no
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
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
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
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
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
On 2019-12-31 13:55, Fabian Affolter wrote:
Hi all,
I don't want to repeat myself, please take a look at my wiki page [1].
Why I want to join? I have one too many Python package and I started to
add the python-sig as admin. But it goes both ways, if the SIG has
access to my packages I want to
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1778465
Petr Pisar changed:
What|Removed |Added
CC||ppi...@redhat.com
--- Comment #5 from
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:
https://bugzilla.redhat.com/show_bug.cgi?id=1778465
Andrew Bauer changed:
What|Removed |Added
CC||zonexpertconsulting@outlook
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,
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
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
>
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 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
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 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:
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 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
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 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 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
>
> 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 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:
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1768799
Bug 1768799 depends on bug 1744690, which changed state.
Bug 1744690 Summary: [RFE] EPEL8 branch of perl-Plack
https://bugzilla.redhat.com/show_bug.cgi?id=1744690
What|Removed |Added
https://bugzilla.redhat.com/show_bug.cgi?id=1744690
Petr Pisar changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
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
https://bugzilla.redhat.com/show_bug.cgi?id=1751247
Paul Howarth changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=838679
Denis Fateyev changed:
What|Removed |Added
Status|NEW |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=1744690
--- Comment #15 from Denis Fateyev ---
Are these packages still on QA?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list --
https://bugzilla.redhat.com/show_bug.cgi?id=1751247
--- Comment #13 from Denis Fateyev ---
Are these packages still on QA?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list --
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
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
96 matches
Mail list logo
