The `peek` package has been approved in Fedora repositories [1], but it doesn't even start without ffmpeg installed [2], which is not distributed in Fedora repositories (but is available in rpmfusion):
$ peek Error: Child process exited with code 1 Unable to create default screen recorder.
The peek specfile contains a `Recommends: ffmpeg >= 3`, which is rather confusing... I think this package should never have passed the review process! It should really stay in rpmfusion repository.
Is this something allowed? Should I file a ticket against the package or against fedora-infra to suggest its retirement?
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1709029 [2] https://github.com/phw/peek/issues/485
Peek only relies on ffmpeg for screen recording on non-GNOME desktops on X11, afaik.
On GNOME, it uses the org.gnome.Shell.Screencast interface which offloads all of the heavy work to GNOME shell.
-- Carson Black [jan Pontaoski]
Am Mi., 1. Jan. 2020 um 09:51 Uhr schrieb Mattia Verga via devel devel@lists.fedoraproject.org:
The `peek` package has been approved in Fedora repositories [1], but it doesn't even start without ffmpeg installed [2], which is not distributed in Fedora repositories (but is available in rpmfusion):
$ peek Error: Child process exited with code 1 Unable to create default screen recorder.
The peek specfile contains a `Recommends: ffmpeg >= 3`, which is rather confusing... I think this package should never have passed the review process! It should really stay in rpmfusion repository.
Is this something allowed? Should I file a ticket against the package or against fedora-infra to suggest its retirement?
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1709029 [2] https://github.com/phw/peek/issues/485
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Wed, Jan 1, 2020, 15:51 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote:
The `peek` package has been approved in Fedora repositories [1], but it doesn't even start without ffmpeg installed [2], which is not distributed in Fedora repositories (but is available in rpmfusion):
$ peek Error: Child process exited with code 1 Unable to create default screen recorder.
The peek specfile contains a `Recommends: ffmpeg >= 3`, which is rather confusing... I think this package should never have passed the review process! It should really stay in rpmfusion repository.
Is this something allowed? Should I file a ticket against the package or against fedora-infra to suggest its retirement?
Requiring or even Recommending or Suggesting packages that are not satisfiable from the fedora repositories is definitely not allowed (there's a section in the Packaging Guidelines about this). Whether it is enough to remove the "Recommends" on ffmpeg from the package or if it has to be retired and / or obsoleted with fedora-obsolete-packages is something I don't know. So definitely file a ticket about this.
Fabio
Mattia
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1709029 [2] https://github.com/phw/peek/issues/485
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
The `peek` package has been approved in Fedora repositories [1], but it doesn't even start without ffmpeg installed [2], which is not distributed in Fedora repositories (but is available in rpmfusion):
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].
The peek specfile contains a `Recommends: ffmpeg >= 3`, which is rather confusing... I think this package should never have passed the review process! It should really stay in rpmfusion repository.
OK, this should been fixed. There was a proposal for this but it not passed https://pagure.io/packaging-committee/issue/914
Is this something allowed? Should I file a ticket against the package or against fedora-infra to suggest its retirement?
App works on GNOME. I can add hard dependency: gnome-shell in this case if you think this is better rather then installing ffmpeg.
On Wed, Jan 01, 2020 at 08:33:26PM -0000, Artem Tim wrote:
The `peek` package has been approved in Fedora repositories [1], but it doesn't even start without ffmpeg installed [2], which is not distributed in Fedora repositories (but is available in rpmfusion):
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].
The peek specfile contains a `Recommends: ffmpeg >= 3`, which is rather confusing... I think this package should never have passed the review process! It should really stay in rpmfusion repository.
OK, this should been fixed. There was a proposal for this but it not passed https://pagure.io/packaging-committee/issue/914
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependen...
"All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories."
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
"As with regular dependencies, weak dependencies MUST be satisfiable within the official Fedora repositories."
Also, the gstreamer1-plugins-ugly Recommends needs removed along with ffmpeg.
Is this something allowed? Should I file a ticket against the package or against fedora-infra to suggest its retirement?
App works on GNOME. I can add hard dependency: gnome-shell in this case if you think this is better rather then installing ffmpeg.
IMHO, the best thing would be for upstream to add some kind of error or information dialog saying why it wouldn't work in the places it wouldn't work and suggesting users install whatever to make it work?
Failing that perhaps adjust the desktop file to add a 'OnlyShowIn=Gnome'? But does it work only in Wayland sessions?
kevin
"All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories."
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
"As with regular dependencies, weak dependencies MUST be satisfiable within the official Fedora repositories."
Also, the gstreamer1-plugins-ugly Recommends needs removed along with ffmpeg.
Removed 'gstreamer1-plugins-ugly' and 'ffpmeg' as weak deps, just commented them as tip.
Failing that perhaps adjust the desktop file to add a But does it work only in Wayland sessions?
Works on both Xorg and Wayland session.
On Wed, Jan 01, 2020 at 09:13:28PM -0000, Artem Tim wrote:
"All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories."
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
"As with regular dependencies, weak dependencies MUST be satisfiable within the official Fedora repositories."
Also, the gstreamer1-plugins-ugly Recommends needs removed along with ffmpeg.
Removed 'gstreamer1-plugins-ugly' and 'ffpmeg' as weak deps, just commented them as tip.
Failing that perhaps adjust the desktop file to add a But does it work only in Wayland sessions?
Works on both Xorg and Wayland session.
Then OnlyShowIN=Gnome in the desktop file seems like a possible solution.
kevin
Then OnlyShowIN=Gnome in the desktop file seems like a possible solution.
@Kevin, i'll do shortly. Also i filed a bug in upstream https://github.com/phw/peek/issues/539
The problem with this approach is that when you install ffmpeg, it still won't be shown in those DEs.
On Thu, Jan 2, 2020, 01:57 Kevin Fenzi kevin@scrye.com wrote:
On Wed, Jan 01, 2020 at 09:13:28PM -0000, Artem Tim wrote:
"All package dependencies (build-time or runtime, regular, weak or
otherwise)
MUST ALWAYS be satisfiable within the official Fedora repositories."
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/
"As with regular dependencies, weak dependencies MUST be satisfiable within the official Fedora repositories."
Also, the gstreamer1-plugins-ugly Recommends needs removed along with ffmpeg.
Removed 'gstreamer1-plugins-ugly' and 'ffpmeg' as weak deps, just
commented them as tip.
Failing that perhaps adjust the desktop file to add a But does it work only in Wayland sessions?
Works on both Xorg and Wayland session.
Then OnlyShowIN=Gnome in the desktop file seems like a possible solution.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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 from displaying in cinnamon menu, I'm sure Mate, XFCE and LXDE would also like it removed from their menus as well.
Add this to it's desktop file!
'OnlyShowIn=Gnome'
Perhaps OP should not sneaky asking for retiring functional package? Maybe he should instead file a bug and ask maintainer first about this and discuss with it? I might have miss this thread and didn't even notice it. TBH all this just demotivating from packaging something at all.
Il 02/01/20 09:52, Artem Tim ha scritto:
Perhaps OP should not sneaky asking for retiring functional package? Maybe he should instead file a bug and ask maintainer first about this and discuss with it? I might have miss this thread and didn't even notice it. TBH all this just demotivating from packaging something at all. _______________________________________________
In my original post I had CC'ed `peek-maintainer@fedoraproject.org` and I supposed this would have reached you directly. I did not know this isn't working anymore (I later received an unreachable address in reply). So I didn't "sneaky ask" anything.
That said, if this is working for Gnome out of the box without external dependencies, I apologize. I've just seen that the project homepage lists ffmpeg as runtime dependency. Indeed, a more descriptive error would be nice (and, maybe, viewable in a window message, not only from CLI).
Mattia
On Thu, 02 Jan 2020 10:02:25 +0000, Mattia Verga via devel wrote:
In my original post I had CC'ed `peek-maintainer@fedoraproject.org` and I supposed this would have reached you directly. I did not know this isn't working anymore (I later received an unreachable address in reply). So I didn't "sneaky ask" anything.
It has _never_ worked before, because it is PACKAGENAME-owner@ instead.
On 02/01/2020 11:05, Michael Schwendt wrote:
On Thu, 02 Jan 2020 10:02:25 +0000, Mattia Verga via devel wrote:
In my original post I had CC'ed `peek-maintainer@fedoraproject.org` and I supposed this would have reached you directly. I did not know this isn't working anymore (I later received an unreachable address in reply). So I didn't "sneaky ask" anything.
It has _never_ worked before, because it is PACKAGENAME-owner@ instead.
Actually I believe PACKAGENAME-maintainers@ (with an s) is now the preferred form and -owner is regarded as deprecated.
The idea being to generally promote the idea of multiple maintainers and discourage the concept of ownership by an individual.
Tom
On Thu, 2 Jan 2020 11:24:08 +0000, Tom Hughes wrote:
Actually I believe PACKAGENAME-maintainers@ (with an s) is now the preferred form and -owner is regarded as deprecated.
Is this documented _anywhere_?
The following page still mentions the -owner alias https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb and would be a good place where to mention a switch to something else.
On 02. 01. 20 13:04, Michael Schwendt wrote:
On Thu, 2 Jan 2020 11:24:08 +0000, Tom Hughes wrote:
Actually I believe PACKAGENAME-maintainers@ (with an s) is now the preferred form and -owner is regarded as deprecated.
Is this documented _anywhere_?
The following page still mentions the -owner alias https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb and would be a good place where to mention a switch to something else.
Updating.
Il 02/01/20 12:05, Michael Schwendt ha scritto:
On Thu, 02 Jan 2020 10:02:25 +0000, Mattia Verga via devel wrote:
In my original post I had CC'ed `peek-maintainer@fedoraproject.org` and I supposed this would have reached you directly. I did not know this isn't working anymore (I later received an unreachable address in reply). So I didn't "sneaky ask" anything.
It has _never_ worked before, because it is PACKAGENAME-owner@ instead.
Ah, thanks! I was remembering the wrong format, then.
No prob. :) But i didn't received any notification so this could be upsetting a little bit if package was retired. Community barely fixed crash dump recently [1] and Fedora users before often write me on email with various questions, so this makes me believe that app is not useless and users interesting in it.
And as for Recommends in spec file yes, this my bad and this not allowed but i believed that soon this will be legal [2].
Indeed, a more descriptive error would be nice (and, maybe, viewable in a window message, not only from CLI).
Adding 'gnome-shell' as hard dependency could be easiest way to fix but i believe we don't want this because this install many gnome packages so let's try move in this direction [3] until we come up with something better.
[1] https://github.com/phw/peek/issues/419 [2] https://pagure.io/packaging-committee/issue/914#comment-607823 [3] https://github.com/phw/peek/issues/539
On Thu, Jan 2, 2020, 12:15 Artem Tim ego.cordatus@gmail.com wrote:
No prob. :) But i didn't received any notification so this could be upsetting a little bit if package was retired. Community barely fixed crash dump recently [1] and Fedora users before often write me on email with various questions, so this makes me believe that app is not useless and users interesting in it.
(snip)
And as for Recommends in spec file yes, this my bad and this not allowed
but i believed that soon this will be legal [2].
No, that is definitely not the case. W (the FPC and spot) concluded that specifying *any* requirements (be it hard or weak dependencies) that can only be fulfilled outside the fedora repos is a no-go, especially for patent-encumbered software like ffmpeg. Which is, for example, why the automatic dependency generator for R needed to be adjusted.
Fabio
Indeed, a more descriptive error would be nice (and, maybe, viewable in a window message, not only from
CLI).
Adding 'gnome-shell' as hard dependency could be easiest way to fix but i believe we don't want this because this install many gnome packages so let's try move in this direction [3] until we come up with something better.
[1] https://github.com/phw/peek/issues/419 [2] https://pagure.io/packaging-committee/issue/914#comment-607823 [3] https://github.com/phw/peek/issues/539 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Please prevent your useless app from displaying in cinnamon menu, I'm sure Mate, XFCE and LXDE would also like it removed from their menus as well.
What is alternative to Peek? OBS Studio is totally different beast. OBS more advanced, using Qt framework, available only in RPM Fusion repo. Users asked many time about this Peek and why it is not available in repo and they really like it because of their simplicity and ease to use.
Also this whole issue is more suitable for regular bug report, not for such drama in mailing list and salt.
On 1/2/20 9:18 AM, Artem Tim wrote:
What is alternative to Peek? OBS Studio is totally different beast. OBS more advanced, using Qt framework, available only in RPM Fusion repo. Users asked many time about this Peek and why it is not available in repo and they really like it because of their simplicity and ease to use.
Also this whole issue is more suitable for regular bug report, not for such drama in mailing list and salt.
There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 1/2/20 9:18 AM, Artem Tim wrote: There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well.
You have misread the ffmpeg spec file, compiling it with nonfree enabled would make ffmpeg undistributable at rpmfusion. It is only compiled with free code!
On 02/01/2020 06:53, Benson Muite wrote:
There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well.
Licenses are not the only issue.
The big issue with ffmpeg, like with many multimedia related things, is patents.
Tom
On 1/2/20 11:37 AM, Tom Hughes wrote:
On 02/01/2020 06:53, Benson Muite wrote:
There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well.
Licenses are not the only issue.
The big issue with ffmpeg, like with many multimedia related things, is patents.
Thanks for the clarification. FFMPEG seems not to have very many alternative software packages. Royalty free codecs are also being developed, for example AV1 (https://en.wikipedia.org/wiki/AV1), and adoption of these will likely grow. I suspect there would be interest in having a royalty free version of FFMPEG for use by content creators that satisfies Fedora packaging guidlines, though unclear if at present this would be useful for many of the multimedia related packages. This would also likely need some interaction with FFMPEG developers.
Tom
On 1/2/20 12:05 PM, Benson Muite wrote:
On 1/2/20 11:37 AM, Tom Hughes wrote:
On 02/01/2020 06:53, Benson Muite wrote:
There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well.
Licenses are not the only issue.
The big issue with ffmpeg, like with many multimedia related things, is patents.
Thanks for the clarification. FFMPEG seems not to have very many alternative software packages. Royalty free codecs are also being developed, for example AV1 (https://en.wikipedia.org/wiki/AV1), and adoption of these will likely grow. I suspect there would be interest in having a royalty free version of FFMPEG for use by content creators that satisfies Fedora packaging guidlines, though unclear if at present this would be useful for many of the multimedia related packages. This would also likely need some interaction with FFMPEG developers.
Relevant packaging guideline:
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Patented_Software
Tom
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Peek is on Flathub btw.
On Thu, Jan 2, 2020 at 2:08 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org 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.
-- Sincerely, Vitaly Zaitsev (vitaly@easycoding.org) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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 of "huge headache" would that be? Third party repos like RPM Fusion can still use package Epoch to replace base distribution packages.
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 this. It will be a huge headache for RPM Fusion maintainers.
What sort of "huge headache" would that be? Third party repos like RPM Fusion can still use package Epoch to replace base distribution packages.
We have a strict policy of not doing that. We do try to maintain add-on and alternative packages like chromium-libs-media-freeworld (alternative for chromium-libs-media built with all codecs) which is a headache to maintain in sync with Fedora's chromium.
Regards, Dominik
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 "huge headache" would that be? Third party repos like RPM Fusion can still use package Epoch to replace base distribution packages.
We have a strict policy of not doing that.
Which implies that the "huge headache" is self-induced.
This has been discussed years ago already for various 3rd party repos, who did override base dist packages. The policy could be less strict with regard to add-on packages, which would duplicate a Fedora dist package and fork it with more features built in.
No need to do that for core system libs like glibc, but sometimes it would reduce the maintenance requirements. For some apps and libs the feature set cannot be completed via add-ons/plugins. And RPM Fusion replaces some base dist packages via conflicts anyway in some cases. Example: audacity-freeworld vs. audacity
We do try to maintain add-on and alternative packages like chromium-libs-media-freeworld (alternative for chromium-libs-media built with all codecs) which is a headache to maintain in sync with Fedora's chromium.
Anything with inter-dependencies requires some maintenance. Forked "alternative packages", which implicitly or explicitly conflict with base dist packages, don't reduce the maintenance requirements.
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 RPM Fusion can still use package Epoch to replace base distribution packages.
RPM Fusion strictly forbid this.
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?
- Most of ffmpeg-capable applications use compile-time checks for
available codecs presence.
Which is something you can only fix with an RPM Fusion package, if you "control" (= build) all depending packages.
- Sync errors between repositories like chromium and
chromium-libs-media-freeworld.
Not any more "headaches" than ordinary add-on packages in a 3rd party repo with dependencies in the base dist repo(s).
Third party repos like RPM Fusion can still use package Epoch to replace base distribution packages.
RPM Fusion strictly forbid this.
And yet it would create less problems than conflicting replacement packages.
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's policy.
On Sat, 4 Jan 2020 08:36:07 +0100, Vitaly Zaitsev via devel 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's policy.
And yet it would be the only way to do it for some applications and/or libraries. That said, as an ex-livna packager I'm aware of the project goals, so it isn't necessary to refer to the current "policy".
You started the drama by picking on cinnamon!
Me started drama? Cinnamon mentioned by original poster and he even post a link on github issue where title is:
'Peek fails to start in Cinnamon on Fedora 30' https://github.com/phw/peek/issues/485
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 from displaying in cinnamon menu, I'm sure Mate, XFCE and LXDE would also like it removed from their menus as well.
Add this to it's desktop file!
'OnlyShowIn=Gnome'
Agreed, I'd like to see it removed from Plasma's menu by default as well.
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 johnmh@splentity.com 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 from displaying in cinnamon menu, I'm
sure
Mate, XFCE and LXDE would also like it removed from their menus as well.
Add this to it's desktop file!
'OnlyShowIn=Gnome'
Agreed, I'd like to see it removed from Plasma's menu by default as well.
-- John M. Harris, Jr. Splentity
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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 <johnmh(a)splentity.com> 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 <johnmh(a)splentity.com> wrote:
NO, it's not required on cinnamon, users can use the screenshot+ Record desktop applet instead.
Could you, please, stop with these definitely uncalled for shout outs? Users should definitely have a freedom of choice, and as Samuel pointed out in this thread, the package is not installed by default, so should you find it unsuitable for your system (either a different DE or missing ffmpeg), you can simply uninstall it and replace it with any of the numerous alternatives already previously mentioned.
Throwing tantrum because peek doesn't work in your DE won't help in any way apart from causing unnecessary flame wars.
Thank you.
On Fri, Jan 3, 2020 at 5:00 AM František Šumšal frantisek@sumsal.cz 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 <johnmh(a)splentity.com> wrote:
NO, it's not required on cinnamon, users can use the screenshot+ Record desktop applet instead.
Could you, please, stop with these definitely uncalled for shout outs? Users should definitely have a freedom of choice, and as Samuel pointed out in this thread, the package is not installed by default, so should you find it unsuitable for your system (either a different DE or missing ffmpeg), you can simply uninstall it and replace it with any of the numerous alternatives already previously mentioned.
Throwing tantrum because peek doesn't work in your DE won't help in any way apart from causing unnecessary flame wars.
Well, the truth is, it *does* work. We just don't have a crippled version of ffmpeg in Fedora. I wish we did, but I vaguely recall something indicating we can't have one. :(
Anyway, vokoscreen was rewritten to use GStreamer now, so that can be packaged and used everywhere... https://github.com/vkohaupt/vokoscreenNG
-- 真実はいつも一つ!/ Always, there's only one truth!
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.
vokoscreenNG packaged now. Nice to have such app available in official repos.
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21
Awesome!
On 1/8/20 10:09 AM, Artem Tim wrote:
vokoscreenNG packaged now. Nice to have such app available in official repos.
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Il 08/01/20 08:09, Artem Tim ha scritto:
vokoscreenNG packaged now. Nice to have such app available in official repos.
F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21 _______________________________________________
Thank you!
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 from displaying in cinnamon menu, I'm sure Mate, XFCE and LXDE would also like it removed from their menus as well.
Agreed, I'd like to see it removed from Plasma's menu by default as well.
What is the problem? It's not installed by default. If you don't want it, then don't install it. But don't block those that do have a use for it.