RPM Fusion update report 2021-03-04
by noreply＠rpmfusion.org
RPM Fusion update report
------------------------
Section free:
-------------
Fedora 32
-------------
Pushed to testing:
vdr-markad-2.6.4-1.fc32
Pushed to stable:
vdr-mpv-1.0.0-1.fc32
welle-io-2.2-10.fc32
Fedora 33
-------------
Pushed to testing:
vdr-markad-2.6.4-1.fc33
Pushed to stable:
audacious-plugins-freeworld-4.1-1.fc33
vdr-mpv-1.0.0-1.fc33
welle-io-2.2-10.fc33
Fedora 34
-------------
Pushed to testing:
vdr-markad-2.6.4-1.fc34
Pushed to stable:
audacious-plugins-freeworld-4.1-1.fc34
vdr-mpv-1.0.0-1.fc34
vlc-3.0.12.1-7.fc34
welle-io-2.2-10.fc34
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
Section nonfree:
-------------
Fedora 32
-------------
Pushed to testing:
Pushed to stable:
megasync-4.4.0.0-1.fc32
Fedora 33
-------------
Pushed to testing:
Pushed to stable:
megasync-4.4.0.0-1.fc33
Fedora 34
-------------
Pushed to testing:
Pushed to stable:
xv-3.10a.jumbopatch.20070520-36.fc34
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
Theses packages will be available in main mirror in a few hours. Wait for local mirrors to sync
Please report any issue to https://bugzilla.rpmfusion.org
3 years, 9 months
RPM Fusion update report 2021-03-03
by noreply＠rpmfusion.org
RPM Fusion update report
------------------------
Section free:
-------------
Fedora 32
-------------
Pushed to testing:
vdr-mpv-1.0.0-1.fc32
welle-io-2.2-10.fc32
Pushed to stable:
mythtv-31.0-15.139.20210226gitb6ddf202a4.fc32
shotcut-21.02.27-1.fc32
vdr-markad-2.6.3-1.fc32
vdr-softhddevice-1.0.14-1.fc32
Fedora 33
-------------
Pushed to testing:
audacious-plugins-freeworld-4.1-1.fc33
vdr-mpv-1.0.0-1.fc33
welle-io-2.2-10.fc33
Pushed to stable:
mythtv-31.0-15.139.20210226gitb6ddf202a4.fc33
shotcut-21.02.27-1.fc33
vdr-markad-2.6.3-1.fc33
vdr-softhddevice-1.0.14-1.fc33
Fedora 34
-------------
Pushed to testing:
audacious-plugins-freeworld-4.1-1.fc34
vdr-mpv-1.0.0-1.fc34
vlc-3.0.12.1-7.fc34
welle-io-2.2-10.fc34
Pushed to stable:
bino-1.6.7-8.fc34
gstreamer1-libav-1.18.2-4.fc34
libopenshot-0.2.5-8.fc34
mythtv-31.0-15.139.20210226gitb6ddf202a4.fc34
rpmfusion-free-obsolete-packages-34-1.fc34
shotcut-21.02.27-1.fc34
vdr-markad-2.6.3-1.fc34
vdr-softhddevice-1.0.14-1.fc34
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
mythtv-31.0-15.139.20210226gitb6ddf202a4.el8
Section nonfree:
-------------
Fedora 32
-------------
Pushed to testing:
megasync-4.4.0.0-1.fc32
nvidia-340xx-kmod-340.108-11.fc32
Pushed to stable:
Fedora 33
-------------
Pushed to testing:
megasync-4.4.0.0-1.fc33
nvidia-340xx-kmod-340.108-11.fc33
Pushed to stable:
Fedora 34
-------------
Pushed to testing:
nvidia-340xx-kmod-340.108-11.fc34
xv-3.10a.jumbopatch.20070520-36.fc34
Pushed to stable:
EL 7
-------------
Pushed to testing:
Pushed to stable:
EL 8
-------------
Pushed to testing:
Pushed to stable:
Theses packages will be available in main mirror in a few hours. Wait for local mirrors to sync
Please report any issue to https://bugzilla.rpmfusion.org
3 years, 9 months
Re: MythTV maintainership
by Göran Uddeborg
Andrew Bauer skrev:
> hi Richard,
> I'll take it. I assume you mean all three packages: mythtv, mythweb, and
> mythtv-status.
Actually, I'm the maintainer of mythtv-status. If you wish to take
over, or just co-maintain, you're welcome; I won't hog it! :-)
But otherwise I can continue. It is a very small and trivial package,
surely nothing compared to MythTV itself.
3 years, 9 months
Re: [mythtv] Update to latest fixes/31.
by Sérgio Basto
On Tue, 2021-03-02 at 02:16 +0100, Kevin Kofler via rpmfusion-
developers wrote:
> Sérgio Basto wrote:
>
> > no, no, no :D , the text says "allows people to use standard tools
> to
>
> > visualize" (the patches) , sending a 28K file or even more (as you
>
> > suggest) in email just allow people have a bad mood, at least in
> may
>
> > case.
>
> > The text let we use common sense and sending a very large files in
>
> > email is not a good practice, IMHO , neither "allow people to use
>
> > standard tools to visualize the patch" .
>
>
>
> As I already wrote, that means the infrastructure needs to limit the
> size of
>
> commit e-mails, it is unreasonable to ask maintainers to work around
> that.
Don't see why is unreasonable .
> > Also if you can "visualize the patch" , let me know what tools do
> you
>
> > use ? please
>
>
>
>
> and use any local tools (e.g., qgit).
So , what prevent you to use lookaside cache instead asking the
infrastructure to limit the size of commit e-mails ?
--
Sérgio M. B.
3 years, 9 months
Re: [mythtv] Update to latest fixes/31.
by Sérgio Basto
On Sun, 2021-02-28 at 13:40 +0100, Kevin Kofler via rpmfusion-
developers wrote:
> Sérgio Basto wrote:
> > Maybe we should change the guidelines. This is common sense . Why
> you
> > want receive a patch with 28k , you going to read it ? or just to
> > fulfill the guideline .
>
> Then maybe the RPM Fusion git hook should do what other projects' git
> hooks
> do and just truncate the long changeset, and put a link to the full
> changeset in the web interface at a prominent place in the mail.
>
> Dealing with large text files is something git is perfectly designed
> and
> able to do, so we should not work around bugs and limitations in
> other
> infrastructure by not using git as designed.
My point of view is about readable emails and readable cgit web pages,
when we do a commit is sent an email to devel mailing list and very
large diff files shouldn't be send to email.
[1] which is not the case , 32k of patch file is a layer itself .
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_applying_patches
Storing the files in this way allows people to use standard tools to
visualize the changes between revisions of the files and track
additions
and removals without a layer of indirection (as putting them into
lookaside would do).
> Kevin Kofler
--
Sérgio M. B.
3 years, 9 months
Re: Telegram Desktop retirement notice
by Kevin Kofler
Vitaly Zaitsev via rpmfusion-developers wrote:
> Today is a great day. I finally decided to retire Telegram Desktop
> package from Fedora and RPM Fusion for the following reasons:
>
> 1. It has very toxic hostile to GNU/Linux maintainers upstream. All
> bugs, related to disributions will be instantly closed with "WONTFIX,
> use our half-proprietary binary, linked statically against Ubuntu 14.04
> LTS libraries, from the official website".
>
> 2. I have maintained lots of GNU/Linux packages for 16 years and have
> never seen such a hostile upstream before. They do their best to break
> packaged builds and you need to fix more and more on each release. They
> always say, "We only support static builds, if you need shared -> fix it
> yourself".
>
> 3. You cannot ask upstream for some help in packaged builds, they will
> ignore you. Eg. recently they removed builds support against Qt < 5.15.
>
> 4. If you a GNU/Linux maintainer, they treat you as an enemy. They hate
> you.
>
> If someone want to take it, feel free, but don't forget about 1-4.
This is quite sad. Unlike most of the competition, they actually went
through the trouble of creating a real desktop client using Qt libraries, as
opposed to just repackaging the web client with Electron. But then, they
make it a pain to actually distribute it like a desktop application. Their
blob distribution model is no different from what the Electron crowd does.
Kevin Kofler
3 years, 9 months
Re: Telegram Desktop retirement notice
by Nicolas Chauvet
Le lun. 1 mars 2021 à 12:44, Vitaly Zaitsev via rpmfusion-developers
<rpmfusion-developers(a)lists.rpmfusion.org> a écrit :
>
> Hello all!
>
> Today is a great day. I finally decided to retire Telegram Desktop
> package from Fedora and RPM Fusion for the following reasons:
Thanks for rising this point.
Please at least don't actually retire anything until we have time to
discuss the issue.
I understand you are really affected by the situation, and it really
shouldn't be the case for FLOSS contributors (either on your free time
or not).
So I would recommend you to keep away from this topic for some time.
(at least one week).
Thanks for rising such detailed points.
Have a nice day.
3 years, 9 months
Telegram Desktop retirement notice
by Vitaly Zaitsev
Hello all!
Today is a great day. I finally decided to retire Telegram Desktop
package from Fedora and RPM Fusion for the following reasons:
1. It has very toxic hostile to GNU/Linux maintainers upstream. All
bugs, related to disributions will be instantly closed with "WONTFIX,
use our half-proprietary binary, linked statically against Ubuntu 14.04
LTS libraries, from the official website".
2. I have maintained lots of GNU/Linux packages for 16 years and have
never seen such a hostile upstream before. They do their best to break
packaged builds and you need to fix more and more on each release. They
always say, "We only support static builds, if you need shared -> fix it
yourself".
3. You cannot ask upstream for some help in packaged builds, they will
ignore you. Eg. recently they removed builds support against Qt < 5.15.
4. If you a GNU/Linux maintainer, they treat you as an enemy. They hate you.
If someone want to take it, feel free, but don't forget about 1-4.
Some links:
[1]: https://github.com/telegramdesktop/tdesktop/issues/10257
[2]: https://github.com/desktop-app/tg_owt/issues/52
[3]: https://github.com/desktop-app/tg_owt/issues/48
[4]: https://github.com/telegramdesktop/tdesktop/issues/10398
[5]:
https://github.com/telegramdesktop/tdesktop/issues/10239#issuecomment-768...
[6]:
https://github.com/telegramdesktop/tdesktop/issues/8769#issuecomment-7046...
[7]:
https://github.com/telegramdesktop/tdesktop/issues/10182#issuecomment-763...
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3 years, 9 months
