Re: qt6-qtwebengine-freeworld?
Ankur Sinha via rpmfusion-developers wrote: >> That said, Chromium also uses a bundled OpenH264 to encode H.264 for >> WebRTC. If that is not patched to support dlopening, then we still need a >> qt6- qtwebengine-freeworld built with the bundled OpenH264 enabled. We >> are not allowed to ship OpenH264 directly in Fedora, only through that >> Cisco arrangement. > > I have these packages: > > ``` > $ rpm -qa \*264\* > x264-libs-0.164-8.20220602gitbaee400f.fc39.x86_64 > openh264-2.3.1-2.fc39.x86_64 > mozilla-openh264-2.3.1-2.fc39.x86_64 > gstreamer1-plugin-openh264-1.22.1-1.fc39.x86_64 > ``` > > > Again, not sure if stuff works as it should. I just haven't noticed any > issues in normal usage yet. Does "normal usage" include WebRTC use? Though even there, you can probably get away with only VP8/VP9 support in most cases. But if you do not have working H.264 encoding and the other end supports only H.264 (e.g., Safari 11 or 12.0, they added VP8 support in 12.1 according to Wikipedia), you are stuck. So it is kinda hard to test it in daily use until problems happen. You can use this page to test: https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html though that might be testing only what the browser CLAIMS to support and not what actually works. That said, dlopening OpenH264 should work in qt6-qtwebengine thanks to these downstream patches: https://src.fedoraproject.org/rpms/qt6-qtwebengine/blob/rawhide/f/qtwebengine-blink-dlopen-h264.patch https://src.fedoraproject.org/rpms/qt6-qtwebengine/blob/rawhide/f/qtwebengine-webrtc-dlopen-h264.patch (We do not have these in qt5-qtwebengine, only in qt6-qtwebengine.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt6-qtwebengine-freeworld?
Ankur Sinha via rpmfusion-developers wrote: > I upgraded here, so maybe I've done this in the past and it's still > there. I see this in my qutebrowser config: > > ``` > ppapi-widevine-path=/opt/google/chrome/libwidevinecdm.so > ``` So you have the proprietary google-chrome installed? That includes the DRM blob, and I guess it is one of the locations the QtWebEngine looks for it by default. If you want just Widevine without all of Google Chrome, then it is a game of finding and extracting the blob manually. I do not have Widevine at all, which means things like Netflix are just going to fail with an error message. > If there's a way to get the list or test out the supported codecs, I can > do that and report back. I assume at least H.264 works or Netflix would probably not work, would it? Though have you tried it with the FFmpeg from Fedora or only with the one from RPM Fusion? (In principle, both should support H.264 decoding, the one from Fedora through dlopened OpenH264 with a downstream Fedora patch, the one from RPM Fusion through the built-in decoder in FFmpeg.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt6-qtwebengine-freeworld?
Ankur Sinha via rpmfusion-developers wrote: > I'm not really sure. How would one test this? (Things like Netflix seem > to work fine here for me) Netflix works for you?! I would have expected it to work only if you manually install the widevine DRM blob into the correct directory. > I do see that `-DFeature_webengine_proprietary_codecs` is set to ON in > the spec: > > https://src.fedoraproject.org/rpms/qt6-qtwebengine/blob/rawhide/f/qt6-qtwebengine.spec#_441 Then the Fedora package is probably overreporting the supported codecs. Though on the other hand, at least H.264 is mostly supported by the Fedora FFmpeg if OpenH264 is available for dlopening (though I have not tested whether that feature actually works in Chromium/QtWebEngine, it works only if the application does not hardcode the FFmpeg codec name), so the list might not be all that wrong even in Fedora. That said, Chromium also uses a bundled OpenH264 to encode H.264 for WebRTC. If that is not patched to support dlopening, then we still need a qt6- qtwebengine-freeworld built with the bundled OpenH264 enabled. We are not allowed to ship OpenH264 directly in Fedora, only through that Cisco arrangement. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt6-qtwebengine-freeworld?
Ankur Sinha via rpmfusion-developers wrote: > No freeworld package is needed for qt6-qtwebengine. It is linked > against Fedora's system ffmpeg and will gracefully upgrade when > libavcodec-freeworld is installed. It will pick up the FFmpeg library, yes, but will it actually report the proper list of supported codecs to the websites? I doubt it. The list has always been hardcoded at compile time (picked from one of two manually hardcoded lists depending on the "use_proprietary_codecs" compilation option) in Chromium. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld is still maintained ?
Hi Ankur, Ankur Sinha via rpmfusion-developers wrote: > Just saw your new build for F38. I thought I had rebuilt the F38 package > for qt 5.15.9 already---my local mock build here certainly shows it > (it's the package I'm using now): > > $ rpm -qi qt5-qtwebengine-freeworld --requires | grep qt > Name: qt5-qtwebengine-freeworld > Source RPM : qt5-qtwebengine-freeworld-5.15.12-3.fc38.src.rpm > URL : http://www.qt.io > config(qt5-qtwebengine-freeworld) = 5.15.12-3.fc38 > qt5-qtbase(x86-64) = 5.15.9 > qt5-qtwebengine(x86-64) = 5.15.12 > > and yet, on koji, it still says 5.15.8: > https://koji.rpmfusion.org/koji/rpminfo?rpmID=898575 Yes. See also the root.log, where it shows which version of Qt it has picked up. See: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6658#c1 > I don't quite understand this---shouldn't koji and mock do the same > thing? As I understand it, RPM Fusion has its own Fedora mirrors which can be slightly out of date at times. > Anyway, sorry about that. I'll remember to check koji in the future to > confirm. Thanks. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld is still maintained ?
Nicolas Chauvet via rpmfusion-developers wrote: > According to pkgdb, this is still the case, but none has updated this > package for qt5-5.15.9 > https://admin.rpmfusion.org/pkgdb/package/free/qt5-qtwebengine-freeworld/ If QtBase gets updated, we can only rebuild QtWebEngine against it after the Fedora update reaches stable. > Does this package still worth it (with ffmpeg-free in fedora ?) Yes, QtWebEngine 5.15 LTS does not build against FFmpeg 5 and hence uses a bundled FFmpeg. In addition, the codec lists reported by Chromium are hardcoded at compile time based on the "proprietary_codecs" compile-time configuration flag and hence just swapping out FFmpeg is not sufficient to fully support the patent-encumbered codecs. > Can we properly obsoletes it instead ? No, we cannot. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Packages to be retired by f38
Frank Dana via rpmfusion-developers wrote: > To respond to Kevin, more generally: Removing packages *can *be a > disservice to users*,* *if there even are any*, but a package simply being > in the repo does not mean that there are. And every package in the repo, > no matter how frequently used and no matter how frequently updated, is a > maintenance burden. I no longer agree (though I used to) that including a > package is always better than not including it, nor do I feel that being > able to keep it limping along always means that we *should*. We are not going to agree then, because I definitely think that including a package is almost always better than not including it. (In my view, that applies even to unmaintained packages, i.e., I do not think being orphaned is a valid reason for a package to get retired either. Though I think I am in the minority there.) Only if the package is entirely unusable for some reason (e.g., because it depends on a server-side service that was discontinued, or because it has broken dependencies and cannot be successfully rebuilt to fix them), it makes sense to retire it. Nobody forces you to use a package if it does not work for you, so why does it hurt to have it there? > Over at Fedora, I recently[1] bumped my head up against a bug in the > RapidJSON package that, as it turns out, has already been fixed in the > upstream repo. SIX YEARS AGO. Why is the bug still present in Fedora's > builds? Because the Fedora package, rapidjson-devel-1.1.0-20.fc37.rpm (the > "20" on the release should be a red flag) is based on the latest official > release: RapidJSON 1.1.0, from August 2016. Despite the fact that there > have been *hundreds* of commits to the upstream repo since, and despite > endless requests/pleas/complaints from users,[2] the maintainer has made > absolutely no moves towards producing a new release. As a result, Fedora > is carrying around a 7-year-old, buggy package that its upstream > maintainers seem to have washed their hands of. That is an issue with the upstream maintenance status more than with the Fedora package. I can see why the Fedora maintainer would only ship official releases from upstream. Though in this case, I think it would make sense to upgrade the Fedora package to a snapshot, have you tried requesting that? But if upstream does not do releases anymore, it may be time to just fork the upstream and get the fork into Fedora. In any case, I do not see how it is relevant to this discussion. If the Fedora rapidjson package were retired, you would not be able to build Octave against it at all. > See also: The qt4 and even qt3(!) packages that still haunt Fedora's > repos. Which (because they're based on 10+-year-old sources) actually > break quite frequently. But people just keep *fixing* them, instead of > pulling the "retire" trigger. (The Qt 4 packages are qt-*-4.8.7-69.fc37, > and the Qt 3 ones are qt3-*-3.3.8b-91.fc37. Again, release numbers like 69 > and 91 should be a major red flag. As should this): > > $ ls qt3/*.patch |wc -l > 52 > $ ls qt/*.patch |wc -l > 54 I am one of those who keep these packages working, and I do not plan to stop doing that any time soon. Those packages are required to keep applications working that have not been ported to newer Qt versions for various reasons. I use several of them daily. (KSensors even *always* runs and that's a kdelibs3 application.) So there is no way I am going to let those packages be retired. Compatibility libraries are the kind of packages that needs to persist basically forever. And again, nobody forces you to use Qt 3 or Qt 3 applications. Retiring Qt 3 would also not get those applications magically ported to Qt 5 or 6, they would just have to be retired too. I do not see how that would be an improvement. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Packages to be retired by f38
Oh, so, AFTER I resend this by e-mail, the message I had sent through Gmane actually goes through. Seems to just have been delayed rather than eaten. Sorry for the double post. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Packages to be retired by f38
Frank Dana via rpmfusion-developers wrote: > There are an AWFUL lot of DVD-authoring and -conversion tools still in the > REPOs, considering how infrequently most people even encounter physical > media these days. > > Do we really need a half-dozen different ways to create menus and disc > images, so we can party like it's 1997? Yes. People use them. I have used both dvdstyler and devedeng recently. (They have their strengths and weaknesses. In particular, when automatically generating menus, they generate very different menu styles.) > Plus the DVD- and BD-specific libraries. (Though most of these are > probably still dependencies of other packages like ffmpeg, or are useful > with data discs as well.): Those are definitely needed to play back such media. > There are also a few... *slightly esoteric* (I'm being charitable) > emulators for old systems and game consoles. If people genuinely still > find them useful and valuable, then great! But I think it's worth at least > asking the question: Does anyone actually use these? Are there any that > NOBODY actually uses? Emulators have their users too, though you will find few people publicly admitting they use them because you can hardly get the required ROMs legally. As a general answer (to all categories above): I do not see why you want to mass-retire entire categories of software just because you do not have a use for them. As long as packages are maintained, they should NOT be retired! Unmaintained packages will get retired eventually anyway. Removing packages is always a disservice to users and should only be done if absolutely necessary. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Packages to be retired by f38
Frank Dana via rpmfusion-developers wrote: > There are an AWFUL lot of DVD-authoring and -conversion tools still in the > REPOs, considering how infrequently most people even encounter physical > media these days. > > Do we really need a half-dozen different ways to create menus and disc > images, so we can party like it's 1997? Yes. People use them. I have used both dvdstyler and devedeng recently. (They have their strengths and weaknesses. In particular, when automatically generating menus, they generate very different menu styles.) > Plus the DVD- and BD-specific libraries. (Though most of these are > probably still dependencies of other packages like ffmpeg, or are useful > with data discs as well.): Those are definitely needed to play back such media. > There are also a few... *slightly esoteric* (I'm being charitable) > emulators for old systems and game consoles. If people genuinely still > find them useful and valuable, then great! But I think it's worth at least > asking the question: Does anyone actually use these? Are there any that > NOBODY actually uses? Emulators have their users too, though you will find few people publicly admitting they use them because you can hardly get the required ROMs legally. As a general answer (to all categories above): I do not see why you want to mass-retire entire categories of software just because you do not have a use for them. As long as packages are maintained, they should NOT be retired! Unmaintained packages will get retired eventually anyway. Removing packages is always a disservice to users and should only be done if absolutely necessary. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Nice News
--- Begin Message ---
Thomas Stephen Lee wrote:
> https://developer.nvidia.com/blog/nvidia-releases-open-source-gpu-kernel-modules/
Keep in mind that:
* this is only the kernel module, not the userspace,
* the module is not compatible with the current FOSS userspace drivers (the
current version of Nouveau),
* the current version is only tested for CUDA computations, not for
graphics, and
* the kernel module only supports the latest GPU generations and there is no
plan to support older ones (which will continue to use Nouveau),
so this is a step in the right direction, but pretty useless in the current
state, the benefits will become visible only in the long term (but
eventually they will, just not now).
See also Christian F.K. Schaller's blog post:
https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: [ffmpeg] Add patch for chrome
--- Begin Message --- Dominik 'Rathann' Mierzejewski wrote: > I don't think it's a good idea to carry this patch. It was rejected by > FFmpeg upstream: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-September/285401.html I do not think this trivial accessor is going to be a maintenance burden of any kind, so I do not see a good reason not to carry this patch. Judging from my experience with how Chromium development works, I doubt they will ever change their code to work the way the FFmpeg developers want, they will just stop supporting unbundling FFmpeg altogether. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
Re: ffmpeg-4.x compat package
--- Begin Message ---
Leigh Scott wrote:
> This should make it possible to build chrome with ffmpeg.
>
>
https://pkgs.rpmfusion.org/cgit/free/ffmpeg.git/commit/?id=afe251ab706f9a81a446ffb28dac43d8091f3a31
This patch on its own is not going to work for the current qt5-qtwebengine,
the QtWebEngine/Chromium code needs to be modified too to build with FFmpeg
5, because:
1. this patch does not address the "error: invalid conversion from 'const
AVCodec*' to 'AVCodec*'" and "error: cannot convert 'int*' to 'size_t*' {aka
'long unsigned int*'} […] initializing argument 3 of 'uint8_t*
av_packet_get_side_data(const AVPacket*, AVPacketSideDataType, size_t*)'"
that I am also getting, and
2. the patch adds an accessor function for first_dts, whereas QtWebEngine
wants to use the member variable directly.
I guess the latest Chromium has support for FFmpeg 5, but I would have to
backport it to the version (Chromium 87) used in Qt5WebEngine.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: ffmpeg-4.x compat package
--- Begin Message ---
Nicolas Chauvet wrote:
> There is a consensus to have a compat-ffmpeg4 package starting with
> ffmpeg 4.3.x (rather than 4.4.x for compatibility reason with one or
> another package preferring that version), then later go to
> ffmpeg-4.4.x when possible.
Don't we have everything in RPM Fusion building against 4.4 already? Why go
backwards?
qt5-qtwebengine-freeworld should build fine both with 4.3 and with 4.4. Not
with 5.0 though.
I could also switch qt5-qtwebengine-freeworld to bundled FFmpeg though.
Shall I do this for now, until the compat package is ready? Or is bundled
even entirely preferred over using the compat package?
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: F36 Free repo broken deps.
--- Begin Message ---
Kevin Kofler via rpmfusion-developers wrote:
> Rebuilding now:
> https://koji.rpmfusion.org/koji/taskinfo?taskID=523888
>
> I had actually done the release bump the previous weekend (Sat Jan 29
> 2022), but I was unable to do the rebuild because there was no Rawhide
> compose and hence libvpx was not updated in the RPM Fusion buildroot. Now
> it is.
Unfortunately, it does not build due to FFmpeg incompatibilities:
In file included from gen/media/filters/filters_jumbo_5.cc:6:
./../../3rdparty/chromium/media/filters/audio_file_reader.cc: In member
function 'bool media::AudioFileReader::OpenDecoder()':
./../../3rdparty/chromium/media/filters/audio_file_reader.cc:88:40: error:
invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
88 | AVCodec* codec = avcodec_find_decoder(codec_context_->codec_id);
|^~
||
|const AVCodec*
In file included from gen/media/filters/filters_jumbo_5.cc:9:
./../../3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc: In member
function 'bool media::FFmpegAudioDecoder::ConfigureDecoder(const
media::AudioDecoderConfig&)':
./../../3rdparty/chromium/media/filters/ffmpeg_audio_decoder.cc:332:40:
error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
332 | AVCodec* codec = avcodec_find_decoder(codec_context_->codec_id);
|^~
||
|const AVCodec*
In file included from gen/media/filters/filters_jumbo_5.cc:10:
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc: In function
'base::TimeDelta media::ExtractStartTime(AVStream*)':
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc:101:15: error:
'AVStream' {aka 'struct AVStream'} has no member named 'first_dts'
101 | if (stream->first_dts != kNoFFmpegTimestamp &&
| ^
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc:106:56: error:
'AVStream' {aka 'struct AVStream'} has no member named 'first_dts'
106 | ConvertFromTimeBase(stream->time_base, stream->first_dts);
|^
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc: In member
function 'void
media::FFmpegDemuxerStream::EnqueuePacket(media::ScopedAVPacket)':
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc:413:54: error:
cannot convert 'int*' to 'size_t*' {aka 'long unsigned int*'}
413 | packet.get(), AV_PKT_DATA_WEBVTT_IDENTIFIER, &id_size);
| ^~~~
| |
| int*
In file included from /usr/include/ffmpeg/libavcodec/avcodec.h:45,
from
../../3rdparty/chromium/media/ffmpeg/ffmpeg_common.h:28,
from
./../../3rdparty/chromium/media/filters/audio_file_reader.cc:19:
/usr/include/ffmpeg/libavcodec/packet.h:598:42: note: initializing
argument 3 of 'uint8_t* av_packet_get_side_data(const AVPacket*,
AVPacketSideDataType, size_t*)'
598 | size_t *size);
| ^~~~
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc:417:52: error:
cannot convert 'int*' to 'size_t*' {aka 'long unsigned int*'}
417 | packet.get(), AV_PKT_DATA_WEBVTT_SETTINGS, &settings_size);
|^~
||
|int*
/usr/include/ffmpeg/libavcodec/packet.h:598:42: note: initializing
argument 3 of 'uint8_t* av_packet_get_side_data(const AVPacket*,
AVPacketSideDataType, size_t*)'
598 | size_t *size);
| ^~~~
./../../3rdparty/chromium/media/filters/ffmpeg_demuxer.cc:429:61: error:
cannot convert 'int*' to 'size_t*' {aka 'long unsigned int*'}
429 | packet.get(), AV_PKT_DATA_MATROSKA_BLOCKADDITIONAL,
&side_data_size);
|
^~~
| |
| int*
/usr/include/ffmpeg/libavcodec/packet.h:598:42: note: initializing
argument 3
Re: F36 Free repo broken deps.
--- Begin Message ---
Leigh Scott wrote:
> package: qt5-qtwebengine-freeworld
Rebuilding now:
https://koji.rpmfusion.org/koji/taskinfo?taskID=523888
I had actually done the release bump the previous weekend (Sat Jan 29 2022),
but I was unable to do the rebuild because there was no Rawhide compose and
hence libvpx was not updated in the RPM Fusion buildroot. Now it is.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: RPMFusion el8 buildroot broken?
--- Begin Message --- Gary Buhrmaster wrote: > I will note that while I have not tested in the past > few months, I have experienced certain artifacts(*) > when trying to use mock builds with Alma (their > use of modularity breaks some existing dependency > resolution for existing package builds) Try setting module_hotfixes=true for all repos in the mock config. (But it sounds like a problem on their end that Alma needs to address.) > and Rocky (when using gcc-toolset-10 the annobin invocation > results in numerous build errors for a package I > have). That sounds like the annobin package needs to be rebuilt by Rocky. (As a workaround, you could remove -fplugin=annobin from the compiler flags.) In any cases, such issues need to be reported to the rebuild that has them. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
Re: RPMFusion el8 buildroot broken?
--- Begin Message ---
Nicolas Chauvet wrote:
> CentOS has moved the content to vault, so I've found a more suitable
> mirror until we migrate to rhel/Stream kind of repos.
Why not use Alma or Rocky?
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: qt5-qtwebengine-freeworld vs. aarch64
--- Begin Message ---
Vitaly Zaitsev via rpmfusion-developers wrote:
> On 24/01/2022 17:50, Kevin Kofler wrote:
>> Do you have any idea how we can resolve the issue or should I just go
>> back to building the package on x86_64 only?
>
> Take a look at the Telegram Desktop hacks:
> https://github.com/rpmfusion/telegram-desktop/blob/master/telegram-desktop.spec#L21-L25
Thank you for the pointer!
With these settings (under %ifarch aarch64):
# the RPM Fusion ARM builder runs out of memory during linking with the full
# setting below, and even with just force_debug_info, so omit all debuginfo
%global debug_config %{nil}
# reduce debug info even for the Qt parts to a minimum
%global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
# tune down SMP to reduce memory use further
%global _smp_build_ncpus 6
I obtained a successful build of qt5-qtwebengine-freeworld on aarch64 in
5:38:48, less than half the 13:40:15 that chromium-freeworld took. So qt5-
qtwebengine-freeworld is no longer the slowest build in RPM Fusion. :-p
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: F35 builds failing consistently (F34 too)
--- Begin Message --- F34 also fails, on different files: Error: Error downloading packages: Status code: 500 for http://dl.fedoraproject.org/pub/fedora/linux/updates/34/Everything/x86_64/Packages/j/jsoncpp-devel-1.9.4-5.fc34.x86_64.rpm (IP: 192.168.182.1) Error: Error downloading packages: Status code: 500 for http://dl.fedoraproject.org/pub/fedora/linux/releases/34/Everything/aarch64/os/Packages/f/flex-2.6.4-7.fc34.aarch64.rpm (IP: 192.168.182.1) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
F35 builds failing consistently
--- Begin Message --- Hi, for the last few hours, F35 build attempts have kept failing with: Error: Error downloading packages: Status code: 500 for http://dl.fedoraproject.org/pub/fedora/linux/updates/35/Everything/x86_64/Packages/s/shadow-utils-4.9-9.fc35.x86_64.rpm (IP: 192.168.182.1) Should I report this to fedora-infrastructure? Or is this not from the real dl.fedoraproject.org (but from some local proxy or mirror at RPM Fusion)? Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
Re: qt5-qtwebengine-freeworld vs. aarch64
clude - I../../3rdparty/chromium/third_party/crashpad/crashpad - I../../3rdparty/chromium/third_party/crashpad/crashpad/compat/non_mac - I../../3rdparty/chromium/third_party/crashpad/crashpad/compat/linux - I../../3rdparty/chromium/third_party/crashpad/crashpad/compat/non_win - I../../3rdparty/chromium/third_party/zlib - I../../3rdparty/chromium/third_party/mesa_headers - I../../3rdparty/chromium/third_party/libwebm/source - I../../3rdparty/chromium/third_party/leveldatabase - I../../3rdparty/chromium/third_party/leveldatabase/src - I../../3rdparty/chromium/third_party/leveldatabase/src/include - I../../3rdparty/chromium/v8/include -Igen/v8/include -fno-strict-aliasing -- param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno- asynchronous-unwind-tables -fPIC -pipe -pthread -Wall -U_FORTIFY_SOURCE - D_FORTIFY_SOURCE=2 -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno- deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments -Wno- packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers -Wno- unused-parameter -O2 -fno-ident -fdata-sections -ffunction-sections -fno- omit-frame-pointer -g0 -fvisibility=hidden -pipe -O2 -flto=auto -ffat-lto- objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format- security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS - specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong - specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch-protection=standard - fasynchronous-unwind-tables -fstack-clash-protection -fno-exceptions -Wall - Wextra -D_REENTRANT -I/usr/include/nss3 -I/usr/include/nspr4 -std=gnu++14 - Wno-narrowing -Wno-class-memaccess -Wno-attributes -Wno-class-memaccess - Wno-subobject-linkage -Wno-invalid-offsetof -Wno-return-type -Wno- deprecated-copy -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -pipe -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,- D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack- protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -mbranch- protection=standard -fasynchronous-unwind-tables -fstack-clash-protection - std=gnu++1y -fno-exceptions -Wall -Wextra -D_REENTRANT -Wno-unused-parameter -Wno-unused-variable -Wno-deprecated-declarations -c /builddir/build/BUILD/qtwebengine-everywhere- src-5.15.8/src/core/content_browser_client_qt.cpp -o obj/QtWebEngineCore/content_browser_client_qt.o Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
qt5-qtwebengine-freeworld vs. aarch64
--- Begin Message --- Hi, since chromium-freeworld, which is based on the same codebase and takes almost twice as long to build on x86_64 as qt5-qtwebengine-freeworld, has had several successful builds on aarch64: https://koji.rpmfusion.org/koji/packageinfo?packageID=506 I have decided to give qt5-qtwebengine-freeworld on aarch64 another try. Unfortunately, my 2 attempts so far have hit strange errors: 1. The first attempt built all the files coming from upstream Chromium, including several *jumbo*.cc ones that had caused trouble in the past, just fine, but then failed near the end building the Qt glue code: at 23703/23802, the build hit an OOM kill building obj/QtWebEngineCore/content_browser_client_qt.o: g++: fatal error: Killed signal terminated program cc1plus (This is one of the last files built as part of the Chromium build, then a successful build would move on to files built using qmake-qt5, which are not counted. But still, this is close to the end of the build process, and the heavy Chromium stuff has already been built at that point.) 2. The second attempt is even stranger: the aarch64 build task: https://koji.rpmfusion.org/koji/taskinfo?taskID=521517 got stuck in a really strange state where there is no log output anymore (there was at the beginning of the build, so it has vanished somewhere in the process). It looks like the builder crashed altogether. Do you have any idea how we can resolve the issue or should I just go back to building the package on x86_64 only? Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
Re: About pulseaudio-module*-freeworld on f34+
--- Begin Message ---
Vitaly Zaitsev via rpmfusion-developers wrote:
> APTX/AAC/LDAC support patches were merged[1] into the PulseAudio
> upstream and part of 15.0 release.
>
> I think we need pulseaudio-freeworld package now.
As far as I can see, the patch touches only the bluetooth module, so you
need to replace only that module and not the entire library.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: NVIDIA 470 Series To Be The Last Supporting GTX 600/700 Series Kepler.
--- Begin Message --- Leigh Scott wrote: > nvidia-470.xx will be the last release to support GTX 600/700 Series > Kepler cards. > > https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-470-Ends-Kepler > > I don't intend to do 470.xx support, someone else will need to do a review > and maintenance of it Those cards are well-supported by the Nouveau driver by now, aren't they? Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org --- End Message ---
Re: IRC channel
--- Begin Message ---
Tomasz Torcz wrote:
> If we decide to move out of freenode, we should decide if sticking
> with IRC is worth. Nothing beats irssi, but nowadays I would prefer
> new channels to be created on Matrix network.
Matrix channels can and should be bridged to IRC. It's not an either-or.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: [mythtv] Update to latest fixes/31.
--- Begin Message ---
Sérgio Basto wrote:
> IMHO, Please use `rfpkg new-sources v31.0..b6ddf202a4.patch` to avoid
> at least send 28K bytes of text in email, btw sometimes it breaks my
> gnome evolution
IMHO, patches normally do not belong in the lookaside cache. They are text
files, can be diffed, and are normally part of the packaging rather than the
upstream source code (so it is useful to track them in downstream git). The
size does not matter there: I actually used to maintain downstream a 1 MB,
30292 line patch (qtwebengine-everywhere-src-5.10.1-no-sse2.patch), which
was imported in both Fedora and RPM Fusion dist-git.
That said, this particular case, where the patch is actually a cumulative
patch from the release to the current upstream git, is a corner case where
it can be argued both ways (either: it's a text file, import it directly
into git, or: it's an upstream source, import it to the lookaside cache).
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
--- End Message ---
Re: Moving fdk-aac to -free?
Nicolas Chauvet wrote: > Le mar. 29 sept. 2020 à 17:38, Tobias Girstmair a > écrit : >> >> Hi, >> >> While looking at my local packages I noticed fdk-aac installed from >> rpmfusion-nonfree. The Review Request[1] mentions that (at the time) the >> FSF and Debian[2] considered this license non-free. But since then, both >> the FSF[3] and Fedora[4] have deemed the FDK-AAC license free but GPL >> incompatible. > > > Hi there, > I would like to have view from others contributor on the topic, not > only my own point of view... I agree that this should move to -free, considering that the copyright license is considered free by both the FSF and Fedora (and that only patents prevent shipping this unrestricted version of fdk-aac in Fedora itself). I used to have some reservations about the freeness of the license, but since the license has been ruled free by both the FSF and the Fedora Project, I no longer see a valid reason for RPM Fusion to decide any differently. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
FeRD wrote: > A data point I just learned about regarding this very old discussion, not > really directly applicable to RPM Fusion (as we all always agreed, it > never really was) but IMHO interesting in the same way at least I found > Kevin's original aside about the Qt model (which I was then unfamiliar > with) to be interesting: > > It seems that at their 2019 Contributors Summit last fall (within just a > couple of weeks of our conversation, coincidentally), the Qt project > decided to *abandon* their forward-merging model, and move to a more > familiar all-changes-target-the-dev-branch workflow. As of November, an > updated Branch Policy document[1] superseded the one presenting the model > Kevin describes above. > > [1]: http://quips-qt-io.herokuapp.com/quip-0016-branch-policy.html As far as I know, several core KDE projects still follow the forward-merging model though. So it is not something "no project" would do as you originally claimed. :-) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Aw: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
Martin Gansser wrote:
> f31 [1]:
> Checking for pkg-config opengl ... no
> Checking for opengl ... yes
> adding -lGL to LIBS_X11
> adding -lGLU to LIBS_X11
>
> f32[2]:
> Checking for pkg-config opengl ... adding -lOpenGL to LIBS_X11
> yes
So the issue is the use of pkg-config opengl. That new pkg-config module
does not do what the code (in the handwritten configure) actually expects.
Up to F31, there was no "opengl" pkg-config file at all, so the code falled
back to the hardcoded list of libraries, but on F32, there is no an "opengl"
pkg-config file, and it returns -lOpenGL, not -lGL -lGLU.
The problem is that the handwritten configure script invokes this function:
test_library(){
subsys="$1"
libname="$2"
hdr="$3"
lib="$4"
func="$5"
inc="$6"
feature=$(toupper $libname)
# do not test if disabled from command-line
if disabled $feature; then
log "Not checking for $libname"
disable $feature
return 1
fi
disable $feature
# try pkg-config first
if enabled pkgconfig; then
test_library_pc "$subsys" "$libname" && enable "$feature"
fi
# compile/link test as fallback
if disabled $feature; then
test_library_c "$subsys" "$libname" "$hdr" "$lib" "$func" "$inc" &&
enable $feature
fi
}
(contained in the script) as follows (line 404, I compacted the spaces):
test_library X11 opengl "GL/glx.h" "-lGL -lGLU" "glXQueryVersion(0,0,0)"
Changing that to:
test_library X11 OpenGL "GL/glx.h" "-lGL -lGLU" "glXQueryVersion(0,0,0)"
(i.e., s/opengl/OpenGL/ in that line) should fix it, because then it will
look for an OpenGL pkg-config module instead, hopefully not find one
(because pkg-config is case-sensitive), and then use the "-lGL -lGLU" flags
instead.
The second argument of test_library is only used 1. as the pkg-config module
name, 2. for the console output, and 3. fully upper-cased as the feature
name, so it should be safe to change the case to something that does not
happen to be the name of a wrong pkg-config module (while still mapping to
the feature name OPENGL).
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Pre-built java dependencies
Leigh Scott wrote:
>> What about adding that as nonfree package?
>
> That doesn't make any difference.
Well, most nonfree packages are binary blobs to begin with.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Devedeng license change
Andrea Musuruane wrote:
>Devedeng license has changed from GPLv3+ to GPLv3 only in v4.16.0.
>
> I don't thing there is any problem since this is a leaf package.
That, and there is not even a GPLv4 with which this change could cause
conflicts yet. So of course this is a non-issue.
(I think this Fedora rule of having to announce every license change even in
cases like this makes no sense whatsoever. But RPM Fusion is only following
Fedora rules here, so it would need to be discussed in Fedora.)
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
Dominik 'Rathann' Mierzejewski wrote:
> It's not fine. Older branches will get a completely confusing changelog
> entry saying they were rebuilt for a change in a dependency that never
> happened there. If there were other changes on master (like the dropping
> of python2 subpackage, for example), it would get merged to the older
> branches, too, which would be completely wrong.
I don't think a "rebuild for x" changelog entry is so confusing that it
warrants maintaining separate changelogs for each branch, with the resulting
merge conflicts. If you really think it is confusing, then just be specific,
e.g.:
- Rebuild for new libfoo-2.3.4 in Rawhide
or:
- F32+: Rebuild for new libfoo-2.3.4
As for Rawhide-only or generally Fn+-only changes, you can simply put
something like:
- F32+: drop -python2 subpackage
in your changelog, corresponding to the %if 0%{?fedora} > 31 conditional
actually implementing the change.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
FeRD wrote: > The primary difference seems to be that Qt maintains a LTS release > (currently Qt 5.6), so they have to worry about fixing bugs in > feature-frozen 3-year-old code. That's not an issue for Fedora's package > maintenance strategy. The LTS releases are actually the only ones that get cherry-picked to though. They remove the LTS releases from the merge chain and switch them to cherry-pick mode once the next release branch (which is of course not LTS) goes EOL (e.g., Qt 5.6 was switched to cherry-pick mode once Qt 5.7 went EOL). So, at that point, bug fixes would be submitted against, e.g., Qt 5.8, and merged from there all the way to dev, and would have to be explicitly cherry-picked to Qt 5.6 LTS if wanted. Also, Qt 5.6 is not the only LTS release branch, Qt 5.9 and 5.12 are also LTS, and Qt 5.15 will be the next LTS (and the last Qt 5.x release branch, then there will be Qt 6.0). Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [x264/f30: 7/7] Merge branch 'f29' into f30
I am NOT arguing that merging from older to newer branches makes sense in a dist-git context (in fact, I'd argue that it does not, because changes should be built for Rawhide first and dist-git requires them to be pushed to master to be built for Rawhide), but: FeRD wrote: > If you were developing a bugfix or a new feature to submit to an upstream > project, would you develop against the code from three releases ago, > submit it as a patch or PR against that code, and tell them to merge it > forward to their current development tree? Of course not, and no project > would accept such a patch. This is not true. Qt and parts of KDE actually work that way: Bug fixes that should go into the release branches should be targeted at the oldest supported release branch and will be merged to the newer releases by upstream. Features should typically go only into dev (Qt) or master (KDE) and so should be targeted against that branch. Kevin Kofle ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [unifi] Change requirement from policycoreutils-python to policycoreutils-python-utils so Python 3 is used
Gary Buhrmaster wrote: > IRT mongod, see the discussion in > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5252 > which would appear to leave Richard between a rock > and a hard place as mongoDB is no longer packageable > by Fedora/EL due to the license changes. > > Not including a Requires: that forces one to install > the mongoDB upstream package will result in a > RPMFusion package that is no longer complete > (and usable) either causing different confusion > (bugzilla's about "it does not start!" seem likely). > > I would guess if a Requires is not allowed it would > be better to not include unifi at all to minimize the > confusion? I think mongodb should be packageable in RPM Fusion nonfree. It is under a non-Free license (which is why Fedora does not accept it and also why it does not belong in the free section), but it is redistributable. A Requires on an external package is not acceptable. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: About multilibs support in RPM Fusion
Nicolas Chauvet wrote:
> For information, RHEL8 is obviously building i686 with -m32
> -march=x86_64 by default, so I assume the i686 packages are already
> built using a x86_64 userspace there.
-m32 has always been in the RPM %{_optflags} for 32-bit. This does not mean
the RPMs are actually built with a 64-bit compiler by default.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Leigh Scott wrote: > If you don't do it your package will sit in update-testing forever, I > don't have time to monitor bodhi for shit I don't use! Either that or it's > get pushed whenever regardless or the matching fedora package. I don't > give a damn if it breaks, It's your job to coordinate not mine! I appreciate the work you are doing on RPM Fusion, but could you please be less aggressive? It is quite rude to call any package you don't use yourself "shit". That you don't have time to monitor Bodhi for the Fedora updates is one thing (and Nicolas is right that the solution would ultimately be to script this somehow, if somebody finds the time to implement that), but your rude reaction to the explicit request to move the F29 package (which would have been a one-line command) was already unnecessary. I was simply not aware that I can run the command myself and could have been told so politely. I have never actually asked you to watch Bodhi, just to move the package on my explicit request. Now, the reason I think the self-service approach is not ideal is because there are necessarily some restrictions (e.g., random packagers should not be allowed to mess with the GA repos for already released versions), so handling prereleases like currently F31 leaves room for mistakes. I hope that we can continue working with each other rather than against each other. Hopefully, we can get the infrastructure warts that make this painful for you and/or for us individual packagers sorted out. I realize that we are all very busy. I am, too (which is why I am not yet promising to look into the infrastructure scripts). That said, thanks for moving the F31 package on to the proper tag! Kind regards, Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Nicolas Chauvet wrote:
> There is a need to adapt the koji policy in this case. Or do you
> managed to move it to updates once the package was moved back to
> testing ?
The Koji policy allows moving from updates-testing to updates, but not from
updates to f31-free (GA) nor from updates back to updates-testing.
In this case, Leigh moved it from f31-free-updates to f31-free, so it should
be where it belongs now, thanks!
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Kevin Kofler wrote:
> I have submitted http://koji.rpmfusion.org/koji/taskinfo?taskID=358046 .
The build succeeded on Tuesday:
http://koji.rpmfusion.org/koji/buildinfo?buildID=12008
and went out to the updates-testing repo.
Now, I accidentally moved it to f31-free-updates, which was not a good idea
because it should really be in f31-free GA, I think. I only realized this
when I had already run the tag move. But now I can't move it to f31-free nor
even back to f31-free-updates-testing, so I need an admin to move it to the
proper tag.
(I think it would be better if you did not tell non-admins to mess with
koji-rpmfusion move-tag at all and just let the admins do all the moves as
in the past.)
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Nicolas Chauvet wrote:
> I really hope someone can deal with this rebuild.
I have submitted http://koji.rpmfusion.org/koji/taskinfo?taskID=358046 .
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Testing upgrade to F31: qt5-qtwebengine-freeworld errors
Ankur Sinha wrote:
> Would this be a known issue please, and is there a fix/workaround we can
> help test?
It is known: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5384 –
qt5-qtwebengine-freeworld needs a rebuild.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: [mjpegtools] Disable use of SDL_gfx on EL8
FeRD wrote: > On cursory inspection of the API docs I also don't see any obvious reason > why it would need mjpegtools, but I admit I didn't look very hard. It is the other way round: mjpegtools needs SDL_gfx, not the opposite. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld-5.12.4-2.fc29
Leigh Scott wrote: > Can't you move it when it needed?, I haven't got the time to monitor stuff > I don't use. > > koji-rpmfusion move-build f29-free-updates-testing f29-free-updates > qt5-qtwebengine-freeworld-5.12.4-2.fc29 I wasn't aware that this can be done self-service. (The Fedora Koji definitely doesn't allow that.) I have moved it now, what happens next? I guess somebody needs to run the push script? So it isn't that self-service after all, is it? Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
qt5-qtwebengine-freeworld-5.12.4-2.fc29
Hi, can you please let this go through to stable? (It was already included twice in the automated push reports, but the package must have been filtered out manually. It is not in the repo, at least.) The corresponding Fedora update https://bodhi.fedoraproject.org/updates/FEDORA-2019-5e4316109b went stable on Sunday at 03:09:13 UTC. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: gnustep-base 1.26.0
Antonio Trande wrote:
> 'gnustep-base' 1.26.0 will be pushed on Fedora Rawhide in 10 days.
>
> Package involved: unrar
Nope. As was already pointed out on the Fedora devel mailing list, there is
a confusion here: unrar is in RPM Fusion and does not use gnustep-base.
unar, the Unarchiver, which has reverse engineered RAR uncompression support
as its main feature, is in Fedora and uses gnustep-base. (It was originally
developed for macOS and ported to GNUstep.)
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: What are trusted repositories ?
Michael Cronenworth wrote:
> Plus coprs are built per Fedora release. There is no automatic release
> promotion and the maintainer has no incentive to release it for every
> Fedora release.
Copr now has an option to automatically create branches from the Rawhide
branch. So if you build the Copr for Rawhide and have that option enabled,
it actually does automatically support new Fedora releases as they happen.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: What are trusted repositories ?
Leigh Scott wrote: > I don't trust copr, they aren't long term and could disappear without > warning, we could fork any copr repo and maintain it for stability. I > don't favour this option as we have plenty to do already. Repo's like > Adobe, Dropbox, Google and any other respectable repo's are OK IMO I trust a Copr shipping Free Software (anything else would be in violation of the Copr usage guidelines!) way more than any proprietary software vendor (who can hide any arbitrary misfeatures in their proprietary code). Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion: F31 FTBFS
Sérgio Basto wrote:
> 12008 qt5-qtwebengine-freeworld-5.12.4-3.fc31
This probably needs the same workaround as qt5-qtwebengine in Fedora:
https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/4be2cf030b67b001b3fc7b733723ea12143f5c2a?branch=master
See: https://bugzilla.redhat.com/show_bug.cgi?id=1729806
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: LiVES-3.0.0
Nicolas Chauvet wrote: > There is also something (libprojectM) that bring qt4 by default ! I > think I've dropped support for this in vlc because of this reason (and > to avoid the clash of using qt5 application with a library using qt4). > Please consider to drop projectM unless it's mandatory. I don't think > this project is very well maintained. The current projectM git master supports Qt 5, see: https://github.com/projectM-visualizer/projectm/issues/8 (closed) https://github.com/projectM-visualizer/projectm/pull/42 (merged) So the package maintainer should just upgrade it to a snapshot. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Fwd: [Fedora-legal-list] MPEG-1 and MPEG-2 Video
Michael Cronenworth wrote: > On 4/28/19 3:39 PM, Dominik 'Rathann' Mierzejewski wrote: >> Could you point to the discussion? > > https://twitter.com/cfkschaller/status/1121061262107054080 > > The only way I knew about this is from a Phoronix post. I don't have a > Twitter account nor do I want one. > > There are plenty of official channels to discuss Fedora development > (fedora-devel, fedora-desktop, discussion.fedoraproject.org) and none of > those channels are being used. Sad! This discussion does NOT belong on proprietary social media! In any case, the OpenMandriva patch that was linked to: https://github.com/OpenMandrivaAssociation/ffmpeg/blob/master/ffmpeg-4.1-dlopen-faac-mp3lame-opencore-x264-x265-xvid.patch does NOT solve the problem because it covers only third-party libraries and not native FFmpeg codecs, some of which are also patent-encumbered, and which cannot be dlopened that easily. Those would still only be addable by recompiling FFmpeg. So the dlopening is entirely useless because RPM Fusion would have to replace FFmpeg anyway. In addition, it also adds dlopening for libraries that are no longer patent-encumbered, such as libmp3lame. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Fwd: [Fedora-legal-list] MPEG-1 and MPEG-2 Video
David Timms wrote: > It sounds like Fedora doesn't isn't happy with doing an mp3/mpeg2 only > ffmpeg (which is all dvbcut needs).. but last I saw still to be decided > (I hope they go with cutting the non-happy parts and enabling the code > to dlopen parts which could be built elsewhere). The latter part, dlopening the censored codecs, is unfortunately not practical due to the way FFmpeg is designed. It is always a monolithic build, and the codecs have to be selected at compile time. Codec plugins that can be dlopened would be a major change, to which upstream is actively hostile. (And no, the Libav fork is not any better for this aspect, unfortunately.) What MIGHT work is to ship an ffmpeg-freeworld replacement library using ld.so.conf.d tricks the same way qt5-qtwebengine-freeworld works, freetype-freeworld (which is now obsolete because the Fedora freetype package enables both bytecode hinting and subpixel rendering these days) used to work, etc. Though binary compatibility may be an issue (e.g., if software tries to detect at compile time which codecs are supported by the FFmpeg it is linking to, or if enabling or disabling codecs even changes the FFmpeg library ABI somewhere), it would have to be checked. I am not convinced that having such an FFmpeg build in Fedora would be an improvement over the status quo. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Fwd: [Fedora-legal-list] MPEG-1 and MPEG-2 Video
Xavier Bachelot wrote:
> A trimmed naive dnf search brought me this :
Looks like only the packages showing up with .src in your list are actually
from RPM Fusion, the .x86_64 and i686 ones are actually already in Fedora.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: OpenShot dependencies not in EL7: rpmfusion or Fedora/EPEL?
FeRD wrote:
> *My question now becomes, are these modified packages eligible for
> inclusion in... I don't even really know how EL7 packaging works, would it
> be inclusion in Fedora? Inclusion in EPEL? Or can they live in rpmfusion?*
https://fedoraproject.org/wiki/EPEL/FAQ#Is_it_possible_to_get_a_package_only_into_EPEL_and_not_Fedora.3F
https://lists.fedorahosted.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/HVFU2GAEUOUE4KYHLJKPFDUDGU3WKCW6/
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Orphaning qt5-qtwebengine-freeworld
Hi, I intend to orphan qt5-qtwebengine-freeworld, along with the Fedora qt5-qtwebengine package. Please see: https://www.spinics.net/lists/fedora-devel/msg247677.html for the full story. I think it would be best if it were picked up by the same person also picking up qt5-qtwebengine in Fedora. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPM Fusion mediacenter Spin
Nicolas Chauvet wrote: > Github with the kickstart: > https://github.com/rpmfusion-infra/rpmfusion-kickstarts I see the following: > @firefox > chromium (with chromium-libs-media-freeworld) > qt5-qtwebengine-freeworld How many browsers are you going to ship? Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Cannot post to this list through Gmane anymore
Hi,
I normally use KNode and Gmane to post to mailing lists. This used to work on
this list, too. But the last message that made it through that way was from
January 4! None of the 11 mails I tried to send since then made it through
according to the HyperKitty "user posting activity" history.
Yes, I am subscribed, with mail delivery disabled. (I use KNode and Gmane
(NNTPS) to read the mails.)
I am sending this message with HyperKitty as a workaround.
Can this please be fixed?
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Hi,
Nicolas Chauvet wrote:
> For this specific issue, I (one?) can probably find the option to
> raise the koji task timeout.
Is the increased timeout implemented now? My second build attempt also
failed with a timeout, so I'll only resubmit it if the timeout has been
increased.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Gael STEPHAN wrote:
> Hm and what about cross-compiling ? I work in the embedded software ( we
> build mips and arm targets ), and we never ever considered native build,
> linaro provides excellent cross toolchains for arm ( we cross compile on
> a forked gentoo)
AFAIK, OpenSUSE does that in their OBS, but Koji does not support it.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Karel Volný wrote: > wouldn't "more of them" work better than "faster"? > > - once upon a time, I had been using distcc successfully ... > > but I don't know how hard it would be to set it up ... just an idea It is surely not easy to set up something like distcc with Koji. Also, parallelization helps only so much. The linking also takes a couple hours, and that cannot be parallelized. More physical RAM (!) and a faster CPU are the ways to speed that up. (I have been told that the armv7hl builders have only 2 GiB RAM. If that is correct, then having 4 GiB would surely help. More is not all that useful on 32-bit though.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Nicolas Chauvet wrote: > What's annoying in this situation is more that the armv7hl build > failed than that it took time to build. Well, the long build times can also be an annoyance, particularly when I'm trying to get out security updates to all releases in a timely manner… > For this specific issue, I (one?) can probably find the option to > raise the koji task timeout. … but if you are fine with builds running more than 2 days and if you're willing to raise the timeout accordingly (I'd put it at 72 hours to be safe), I can work with that. At least, 5.10.0 is not a security update, the security fixes are also in 5.9.3 that is already out in all supported releases (and even in F25, I got it through just before the EOL). But 5.10.1 or 5.9.4 builds will surely be needed soon for security. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: qt5-qtwebengine-freeworld
Sérgio Basto wrote: > Build of qt5-qtwebengine-freeworld failed with EXCEPTION: > [commandTimeoutExpired()] [1], when it was almost build after 48 hours > ... > I notice that only in arm, the build took more than 24 hours in others > builders in less of 5 hours, package is done. May you sometimes not > build in arm builder ? (just one ideia) . I don't know how to handle this mess. If I can't get this thing building without hitting timeouts, I'll have to ExcludeArch it on armv7hl, unfortunately. I am already turning off ALL Chromium debuginfo (because the linker runs out of memory otherwise), I don't think there's much more I can do to speed up things. Compiling with -Os instead of -O2, maybe? (-O0 would be fastest to compile, but then I guess it will fail to link again because of the increased size.) Building only some builds for ARM is not a workable solution: I will still end up with those builds running into timeouts (builds are only getting longer with every release, surely not shorter: we went from 24 hours in 5.8 to 36 hours in 5.9 and now 48 hours in 5.10), and in addition, the qt5- qtwebengine-freeworld version must match the qt5-qtwebengine version (because otherwise, qt5-qtwebengine-freeworld would have to include its own copy of the huge data files). The only other solution would be for RPM Fusion to get faster 32-bit ARM builders, but it doesn't look like that is going to happen any time soon, unfortunately. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPM Fusion update report 2017-12-04
Nicolas Chauvet wrote:
> FYI, I've moved dvdstyler and wxsvg along in stable (same for f26).
You can also move qt5-qtwebengine-freeworld-5.9.3-1.fc2[567] through to
stable, the Fedora updates went stable a few hours ago (through positive
karma, and because I wanted to make sure that the F25 update will not miss
the EOL).
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPM Fusion is near 10 years old
Nicolas Chauvet wrote: > http://blog.kwizart.fr/post/2017/09/26/169-RPM-Fusion-is-near-10-years-old > > FYI, I've setup the new root certificate, if you want to grab it > > curl -o ~/.rpmfusion-server-ca.crt > https://admin.rpmfusion.org/accounts//rpmfusion-server-ca.cert Unfortunately, the error message we get from rfpkg build in this situation is really unhelpful, it only says: > Deprecation warning: kojiconfig is deprecated. Instead, kojiprofile should > be used. > Certificate is revoked or expired. > You might want to run rpmfusion-packager-setup to regenerate SSL > certificate. For more info see > https://fedoraproject.org/wiki/Using_the_Koji_build_system#Fedora_Account_System_.28FAS2.29_Setup > Could not execute build: Could not auth with koji. Login failed: [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661) "Certificate is revoked or expired." crucially does not tell you which one. I tried regenerating a new user certificate several times with 4 different browsers (QupZilla, Konqueror, Lynx, Firefox) only to realize that that was not the problem. (So, I am sorry for the several revoked certificates that I generated today.) The other messages are also not helpful: * rpmfusion-packager-setup does not regenerate certificates at all. It can only download the upload-ca and server-ca certificates and output the link for how to manually regenerate the user certificate, and it does even these things only if a file is actually missing, not if the certificate has expired. * The linked Fedora wiki page no longer contains any mention of certificates because Fedora switched to Kerberos for authentication. We really need better error messages in rfpkg. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: VLC missing chain of trust
Germano Massullo wrote:
> VLC package shipped by RPMFusion is missing a chain of trust with
> upstream developers.
HTTP Source URLs are very common in packages (there are probably dozens of
upstreams still not even supporting HTTPS at all, or using a self-signed or
otherwise invalid certificate), and most upstreams do not sign their
releases at all. So why are you singling out VLC in particular? This is just
how things are in the real world, not much we as downstream can do about it.
Kevin Kofler
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
Nicolas Chauvet wrote: > The question about the need of openh264 in rpmfusion is probably how > the route to either openh264/ffmpeg/x264 is setup in your application: > - If your app route the content that can be decoded by openh264 only > to openh264, then it will expect to always have the library. (and we > will probably need to find a long term solution to avoid bundling). > - If it's smart enough to route content that can be decoded by > openh264 to ffmpeg (if available), then it's a safer path and we will > probably not have to worry about openh264 ourselves. Chromium (and therefore also QtWebEngine) uses OpenH264 (currently a bundled copy, which is why repoquery does not turn up any dependencies on the shared library for you) for encoding in WebRTC. Chromium does not use x264 at all, it uses FFmpeg for decoding and OpenH264 for encoding. (There is also no support for using only OpenH264, decoding always uses FFmpeg.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Using openh264 repository by default in RPM Fusion
Nicolas Chauvet wrote: > I wonder if it would be relevant for us to rely on the openh264 > repository in our infra ? > > It seems at least that the chromium freeworld flavor rely on a builtin > version whereas it could use the fedora version, it's a case I wasn't > aware. qt5-qtwebengine-freeworld also uses a bundled openh264. As of 5.9.0, it cannot even officially be unbundled. They added support for that since, I am not sure in what release exactly that will ship. It could probably be backported, … … but the main issue I have with building against the openh264 repository is that this would then introduce a dependency on yet another repository for my users. I think that in this case, it may make more sense to just keep the bundled version (also in chromium-media-libs-freeworld, which is in the same situation). That, or actually ship openh264 in RPM Fusion free. It's not like RPM Fusion has to care about the patent issues that force that Cisco-hosted repo to begin with. (RPM Fusion free already ships at least one H.264 decoder (the builtin decoder in FFmpeg) and at least one H.264 encoder (x264), both of which support more of the standard than OpenH264, so shipping OpenH264 should not expose RPM Fusion to any additional liabilities.) Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: phonon-backend-vlc for EL7
Nicolas Chauvet wrote: > 2017-02-27 12:14 GMT+01:00 Kevin Kofler : >> Nicolas Chauvet wrote: >>> The split with vlc-core isn't about binaries vs libraries, but with >>> headless/server/core vs wayland/Xorg/display. >> >> … which is a split whose usefulness I doubt. All the applications with >> associated library are split into app and app-libs, not app (GUI) and >> app-core. > I don't buy this, so I'm not reading this message any further based on > your false premises. Please do. The remainder of the message explains exactly what you are missing. It is very impolite to stop reading after one paragraph. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: phonon-backend-vlc for EL7
Nicolas Chauvet wrote: > The split with vlc-core isn't about binaries vs libraries, but with > headless/server/core vs wayland/Xorg/display. … which is a split whose usefulness I doubt. All the applications with associated library are split into app and app-libs, not app (GUI) and app-core. > What you suggest is to add libvlc and libvlc-core to vlc and vlc-core. Yes, if you want to keep the -core split, we need a 4-way split, I have been saying that for months. See how other applications that can be embedded as a library are split, e.g.: http://pkgs.fedoraproject.org/cgit/rpms/avogadro.git/tree/avogadro.spec (avogadro-libs) http://pkgs.fedoraproject.org/cgit/rpms/marble.git/tree/marble.spec (marble-widget-qt5) http://pkgs.fedoraproject.org/cgit/rpms/konsole5.git/tree/konsole5.spec (konsole5-part) Even if the main package is small, it still makes sense to not drag in end user applications as dependencies of other applications. > That's not implemented, and IMO it doesn't worth either. What would be > the benefit not to rely on vlc itself ? > - not having the vlc desktop file? > - not having vlc binaries ? > - not having the qt4/qt5/skin2 vlc gui interfaces ? All of the above. A Phonon backend should not drag in a media player UI. Kaffeine should also not drag in the VLC application that serves the same purpose and clutters the menu. > I all theses cases, it could be to minimize the dependencies cost more > than additional size of few unneeded binaries. And speaking about > phonon, you should already have the qt4/qt5 libs. > But dependencies size matters most for embedeed/server use case, not > workstation. So it's doesn't bring any value and just make things more > complex to deal with. It brings the value of clean packaging and uncluttered menus. Kevin Kofler ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: RPMFusion or Fedora?
Ralf Corsepius wrote: > Anyway, in Fedora, we in general mandate "call homes" to be removed and > mandate packages to be "self-contained". Yet Fedora happily allows its default browser to use Google's web services to protect against web sites reported to be malicious by default. Fedora even ships a package that regularly phones home to its own servers to verify whether any given network is actually connected to the Internet: NetworkManager-config-connectivity-fedora. Kevin Kofler
Re: problem retiring package
Nicolas Chauvet wrote: > rfpkg retire doesn't work with our pkgdb because the way a > packagedb-cli enforce a particular IDP for login. > > You should be able to orphan, then to retire your package from the web > interface (it should be like fedora, IIRC). What about retiring specific branches? I cannot see an interface for that in the web interface. I would like to retire the phantom el* branches of freetype-freeworld that I never requested nor used. Kevin Kofler
Re: [akmods: 3/3] Merge branch 'el7'
Dominik 'Rathann' Mierzejewski wrote: > Only fast-forward merges should be done from non-master branches to > master. Otherwise we're getting junk "merge commits" unnecessarily. A single bidirectional merge is actually the most effective way to make the branches fast-forwardable again and avoid any future such merge commits. I always do that if somebody breaks fast-forwardability in my packages. The idea is, you merge master into el7, creating one last "Merge master into el7" merge commit, then you merge el7 fast-forward into master, which fast- forwards master to that merge commit. It makes the history in master a bit more messy, but it avoids polluting the branch history with more unnecessary merge commits in the future. And the fault for the messy master history lies not with whom did the bidirectional merge, but with whom made the branches diverge to begin with. Kevin Kofler
Re: [audacity-freeworld] fix mp3importexport conditional.
Sérgio Basto wrote: > bcond_with and bcond_without are pretty easy to use and works well, I > (personally) don't understand why we have another variants. Because bcond_with and bcond_without have one major flaw: They are "backwards" compared to how most people think. "%bcond_with foo" actually means to build WITHOUT foo by default, and to add a "--with foo" switch to build with foo. Likewise, "%bcond_without foo" actually means to build WITH foo by default, and to add a "--without foo" switch to build without foo. Many packagers find that really confusing. And the --with and --without switches cannot be used in Koji anyway, so you may as well hardcode the options in the specfile using %global. Kevin Kofler
Re: Update ffmpeg in F24 to 3.1.x ?
Julian Sikorski wrote: > Could you please point me to a reference for this? I looked around a bit > but couldn't find one. Thanks! The original post had a quote: | "There are no SONAME changes, only new symbols added to the libraries, | so they're backwards compatible and no rebuild of dependencies should | be required" but don't ask me where it comes from. Kevin Kofler
Re: Update ffmpeg in F24 to 3.1.x ?
Michael Cronenworth wrote:
> This is not ideal. The ffmpeg 3.0.x branch is not going unmaintained
> AFAIK. We can't push out a big rebuild of a major library so one, new
> package can be introduced into F24.
Huh? Upstream says 3.1 is API- and ABI-compatible to 3.0 (with only one
application needed fixing for some reason), so it should be perfectly
suitable as an update. This is similar to Qt upgrades that have often been
done in Fedora (where there are also a few odd packages that invariably need
rebuilding due to (ab)using private Qt APIs).
Introducing a second package for the new version is a horrible idea, it will
lead to symbol conflicts (in applications accidentally transitively linking
both versions) and a waste of space. I would just upgrade the existing
package to the new version.
Kevin Kofler
Re: [x264] Update to 0.148-20160924-86b7198 version
Sérgio Basto wrote: > I'd like point out 2 things, 1 - IMHO Package guidelines, is what it > says, one guide and is *not* the supreme truth, that I have to follow > strictly, 2 - I'm one of the official package maintainer of x264 [1] so > I felt that I have more property / authorization . Sorry, but the naming is misleading there (at least for us non-native English speakers – I cannot comment on how it sound to a US American). The Fedora Packaging "Guidelines" are actually not just informative guidelines, but policies that, for the most part, have to be followed strictly. Kevin Kofler
Re: [x264] Update to 0.148-20160924-86b7198 version
Sérgio Basto wrote:
> And what do you say about Version: 0.148.20160924-1.git86b7198 ?
That is also not compliant with the current Fedora packaging guidelines.
> Because when source change, version should change. The Release field is
> to counting the rebuilds.
Sorry, that is not how Fedora packaging works, in the case of snapshot
packages.
Please follow:
https://fedoraproject.org/wiki/Packaging:Versioning
exactly as written, and do not try to discuss that with us, we did not make
these guidelines, we just have to enforce them to ensure consistency across
the distribution.
There is a proposal that would change this:
https://fedorahosted.org/fpc/ticket/398
(by introducing Debian-style + and ~ suffixes in Version), but it has not
been approved yet. So you cannot use it at this time.
Kevin Kofler
Re: SSL on download1.rpmfusion.org
Stuart D. Gathman wrote:
> They verify all the SANs for free certs by reading a cookie from the
> website, and that would be impossible for a wildcard. So the SAN list
> is really the only way it could be done for that level of verification.
Right, it's hard to automatically verify wildcards, so they don't do it. You
don't want it to end up like the rogue CA that gave somebody a *.github.io
certificate after verifying control of ${NAME}.github.io.
> Also, letsencrypt only signs ICANN domains - mainly because they use
> the ICANN root to verify the domains. (I.e. they won't help with .bit
> domains among others.)
It is of course also necessary to restrict the possible roots if you want to
verify control of the domain name, or I could let it verify example.com on
my own (hypothetical) rogue .com root. And the easiest way to do that was to
just hardcode the ICANN roots, which are widely recognized as the "official"
ones.
Kevin Kofler
Re: SSL on download1.rpmfusion.org
Nicolas Chauvet wrote: > letsencrypt doesn't provide wildcard, and that will be a different > server (so a different cert). It doesn't allow wildcards, but it allows you to give up to 100 SANs (subject alternative names) for a certificate (the canonical one and 99 more). So you can use the same cert for all *.rpmfusion.org subdomains (unless there are more than 100), but of course you don't have to. Kevin Kofler
Re: Reverse weak dependencies in RPMFusion packages
Nicolas Chauvet wrote: > - firefox and multimedia plugins. npapi-vlc or xine-plugin might had > grow a Supplements: firefox, but then are we sure that we had vlc or > xine in the first step ? > if using RPM weak dependencies over yum groups, with yum it was > possible to involve groups belonging and conditional, so if vlc was > part of the extended KDE group and firefox was selected, then > npapi-vlc would be installed. > This is still an issue for end-users not wanting npapi-vlc but at > least it was possible to bring a coherency from the SIG maintainer. > With the current Supplement/Enhance situation, you can only have one > single conditional from the base package, so it would be better not to > add the Supplement in npapi-vlc and xine-plugin at all. You can use boolean dependencies now (e.g. "Supplements: (firefox and vlc)", which triggers the weak dependency only if both firefox and vlc are installed). They should already be safe in Supplements/Enhances. Kevin Kofler
Re: Reverse weak dependencies in RPMFusion packages
Ralf Corsepius wrote:
> Fedora must not know about any 3rd party repo.
> Fedora must not carry any deps of any kind to any 3rd party repo.
And that is exactly why RPM Fusion needs to carry reverse dependencies
instead.
> ... RPM Fusion doesn't have any reason to use weak deps instead of hard
> deps[1], but featuritis.
There are no reverse hard dependencies. (RPM deliberately decided to not
support them, because adding a repository must not introduce broken
dependencies on a system.) So the reverse dependencies must be weak.
Kevin Kofler
Re: Reverse weak dependencies in RPMFusion packages
Ralf Corsepius wrote: > On 09/03/2016 01:50 PM, Dominik 'Rathann' Mierzejewski wrote: >> Dear RPMFusion contributors! >> >> In light of https://fedorahosted.org/council/ticket/61 and >> https://fedoraproject.org/wiki/Workstation/Third_party_software_proposal >> should we start adding Supplements: or Enhances: weak dependencies >> to, say, ffmpeg and other packages? > > IMHO, no. This decision is severe mistake. Why? This use case is exactly what the reverse versions are for. The Fedora repository should not know about RPM Fusion, RPM Fusion should know about Fedora. So why should Fedora carry the weak dependencies on RPM Fusion packages? Kevin Kofler
Re: About chromium packaging
Neal Gompa wrote: > You really only need to recompile libmedia.so, which is where the > codec whitelist exists. Both this and the libffmpeg.so library are > provided by the chromium-libs-media package. I'm not sure if it would > work with the system ffmpeg library without a patch, so you may need > to recompile specifically the libmedia.so and libffmpeg.so components > from the Chromium sources into a new chromium-libs-media-freeworld > package. Replacing libmedia.so is unfortunately not enough. The USE_PROPRIETARY_CODECS compile-time flag is checked all over the place, even in the application layer. See e.g.: https://chromium.googlesource.com/chromium/src.git/+/master/chrome/common/chrome_content_client.cc#135 (QtWebEngine's equivalent has the same at: http://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_client_qt.cpp#n253 by the way.) You'll probably find more if you search all .cc files for the string. So either you patch all these usages in the Fedora Chromium package to look up the flag from libmedia at runtime, or there is no way around recompiling the whole Chromium. Kevin Kofler
Re: About chromium packaging
Hans de Goede wrote: > I don't understand why you keep repeating this. I'm sure we can > come-up with a patch to make the codec-lists a runtime configurable > thing, this is not rocket science. If you want to have a try at fixing this, look, e.g., at the member variable media::MimeUtil::allow_proprietary_codecs_, i.e., the way it is initialized (to a compile-time hardcoded value) and the way it is used (in several places). The right way would really be to remove the boolean variable (which only allows a binary all-or-nothing approach to patent-encumbered codecs) entirely and query for each individual codec at runtime. But then, you will likely be querying FFmpeg directly, whereas for Samsung's GStreamer backend (which is also affected by this issue, see https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), one would have to query GStreamer directly instead. You would also likely be touching several code places related to codec support. A less invasive approach would simply try to initialize media::MimeUtil::allow_proprietary_codecs_ to a runtime-detected value. Kevin Kofler
Re: Re: About chromium packaging
Nicolas Chauvet wrote: > libffmpeg.so is not provided anymore in the approved fedora build. > So I think there is nothing much to replace, but instead to provide > the shared library as a complement. If it's not build as a shared library, then it's statically linked and cannot be replaced at all (without recompiling the entire Chromium). And anyway, you are also going to run into issue 3 (the hardcoded codec lists) if you don't recompile the whole Chromium. Kevin Kofler
Re: Re: About chromium packaging
Jeremy Nouhaud wrote: > According to this comment from Spot it is possible to make, I quote, > "an rpmfusion addon package to replace the ffmpegsumo.so". And that comment is incorrect (or at least poorly formulated and incomplete): 1. There is no "ffmpegsumo.so" in his package (nor in any other current Chromium package). That file name was dropped in Chromium 45. Now, FFmpeg is either static, or shared as libffmpeg.so (in a private library directory). spot's package uses the latter (shared libffmpeg.so). 2. I don't see how you would replace the library, given that it is in a private library directory, thus referenced using RPATH. The ld.so.conf.d trick (as in freetype-freeworld) does not work on RPATH'd libraries. Using Conflicts: could work if the library were in a subpackage, but it is currently not. 3. While replacing the library will work if you have a solution to "2.", it will not necessarily do what you want. Websites will not be able to detect that your browser supports patent-encumbered codecs (such as H.264). You have to recompile the entire Chromium with the proprietary_codecs compile-time flag to make that work. Otherwise, the codec can be decoded if it gets sent, but querying for codec availability uses a hardcoded list determined only by that compile-time flag (i.e., one of 2 hardcoded lists, selected by the proprietary_codecs flag). Kevin Kofler
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
Sérgio Basto wrote:
> Thinking betterm since doesn't crash , and in pentium 2 we have a
> message to disable-asm , I think we should enable asm by default , and
> at most drop a note in wiki , that PII are not supported or something
> like that .
And I disagree with that solution, because it is not compliant with the
expected architecture support of the distribution.
If you want to enable the ASM, you will need to patch it to fix it to
properly runtime-detect also SSE 1 and MMX.
Kevin Kofler
Re: SIMD vs no SIMD on i686 (was: [Bug 3975] executable stack flag prevents use of libx264.so.148 with selinux in enforcing mode)
domi...@greysector.net wrote: > The only real concern here are applications linked against libx264, > which someone might want to run on low-end hardware, because I don't > think anyone would want to encode anything to H.264 on non-SSE2 capable > CPU (i.e. Pentium 3 or Athlon XP and older). Considering last non-SSE2 > CPUs went out of production about 8 years ago, I think it's fairly safe > to assume that the impact of doing SSE2-only builds would be negligible, > if any. There is an expectation that Fedora packages run on any CPU supported by Fedora. For i686, that is currently any i686 CPU with cmov. You are not allowed to assume ANY vector instructions, not SSE2, not SSE (1), not even MMX. (It is of course fine to use all of these with appropriate runtime detection.) I think it is very reasonable to expect the same from RPM Fusion packages, considering that RPM Fusion's policy is normally to follow Fedora policies except for licensing stuff and kernel modules. This is all the more true for a library package, where the library can end up being used in many applications. Those applications will not necessarily want to encode H.264 in real-time, it can be perfectly acceptable for something like the ffmpeg command line to take longer than the video's playing length to encode it. So for those stuck with such an old machine, it is better to have a library that works (slowly) than one that just crashes with a SIGILL (illegal instruction). I know some upstreams are uncooperative at this. Aggressive reverts of offending upstream patches are one solution, changing #ifdefs from something like: #ifdef __i686__ to something like: #if defined(__i686__) && defined(__SSE2__) are another. I did a combination of both to fix QtWebEngine: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qtwebengine-opensource-src-5.7.0-no-sse2.patch (The Chromium packaging should also use such a patch, but currently doesn't. Send your complaints about that to spot. :-) ) Kevin Kofler
Re: About chromium packaging
Nicolas Chauvet wrote: > Okay, good news, so we may have the chromium-ffmpeg under review. It might not be enough to replace the chromium-ffmpeg, you may need a complete chromium-freeworld rebuild with the enable_proprietary_codecs flag on. There is code in Chromium itself which hardcodes the list of available codecs (which is provided, e.g., to websites querying for supported codecs) depending on that compile-time flag. The GStreamer backend in Samsung's fork currently has the same issue, which pretty much defeats the point of using GStreamer. See also https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 If things like Pepper plugins and Widevine DRM support are not compiled in (as was mentioned elsewhere in this thread), that would be another possible reason for rebuilding the entire package. (For what it's worth, QtWebEngine actually enables support for both of them, there just aren't any blobs shipped – if you want Pepper Flash or the Widevine DRM blob (which is also shipped as a Pepper plugin), you need to get them from Chrome or elsewhere, downloading Chrome being probably the only legal way to get them.) That said, if you're going to install the proprietary Chrome anyway to get those proprietary blobs, why would you even bother with the Chromium package? (It makes more sense for QtWebEngine, which integrates the Chromium/Blink engine into native Qt applications.) > (unless this chromium use gstreamer ?) It doesn't. Spot's package is a package of upstream Chromium without Samsung's changes. Kevin Kofler
Re: new person
Simon Adams wrote:
> Hi, I am a long time windows developer and finally started developing in
> Linux. I have preferred Linux for years so I am not new to Linux. I have
> rewritten one of my utility programs from windows to use in Linux. I could
> use a sponser to help me get the package distributed for use. Steve
If this is all your own code (and not some external non-free and/or patent-
encumbered dependency), I would strongly recommend you to pick a license
acceptable for Fedora for your work, so that it can go into Fedora proper
rather than into RPM Fusion.
Kevin Kofler
Re: State of the RPM Fusion repository for f22
Nicolas Chauvet wrote: > I've headed a mass rebuid on my own koji instance for f22-free and it's > nearing completion. Unfortunately, a mass rebuild of the current CVS contents without separate branches for F21 and F22 does not help me at all for freetype-freeworld. I absolutely NEED a separate F21 branch to be able to do any work on the F22 version. The package ought to track the version of Freetype in Fedora. I cannot do this with one devel branch for 3 (!) different releases (F21, F22, Rawhide/F23). Why can we not have CVS branches for F21 and F22? Kevin Kofler
Livna broken
Hi,
rpm.livna.org has been broken for several days now. Does anybody know what's
up there? If Livna is not coming back, where should we get libdvdcss from
now?
Kevin Kofler
Re: ms-sys in rpmfusion?
I wrote: > IMHO, you should rather try to get > http://sourceforge.net/projects/ms-sys-free/ into Fedora instead. Actually, I'm not convinced this is really acceptable, either. E.g.: http://sourceforge.net/p/ms-sys-free/code/ci/master/tree/inc/br_fat32fd_0x52.h says: > /* br_fat32_0x52.h > // > // ANI > // substring gmbh/tw 14.9.04 > // modified bootstrap code 0x052 to support FreeDOS so it looks like this doesn't actually come from the FreeDOS project, but is a derivative work of the proprietary hexdump. Kevin Kofler
Re: ms-sys in rpmfusion?
Jaroslav Skarvada wrote: > ms-sys is a Linux program for writing boot records, including > Microsoft compatible boot records [1]. The code is under GPLv2+, > but it seems it embeds some Microsoft IP - hexdumps of MS boot > records stored in C header files. Fedora refused this package [2]. > My question is: is the ms-sys package eligible for rpmfusion? I don't think so. The hexdumps contained in there are not redistributable at all. RPM Fusion ships only what can be legally redistributed, at least by RPM Fusion itself. IMHO, you should rather try to get http://sourceforge.net/projects/ms-sys-free/ into Fedora instead. Kevin Kofler
Re: Branching of F-21 / ability to build packages for rawhide
Sérgio Basto wrote: > So I think ETA is 2015-02-10 ( Branch Fedora 22 from Rawhide ) from > https://fedoraproject.org/wiki/Releases/22/Schedule That's the date (which is now also past) at which Fedora branched Fedora 22 (!), RPM Fusion still hasn't even branched for Fedora 21 (!!!). We're over one release late! Kevin Kofler
Re: branch for F-21
solarflow99 wrote:
> BTW, I see a lot of F21 packages. How are they getting released then?
They are built from the devel branch, which is still in pre-branch state
(targeting the F21 release).
Kevin Kofler
Re: Change Mixxx package name
Tonet Jallo wrote:
> M, but this is not the problem, the problem is the version of mixxx
> already in rpmfusion and i need it name will changed to mixxx-freeworld
> same to audacity-freeworld.
> Sorry if you don't understand some parts, my english is not very good.
His point is, if mixxx can support plugins for the patent-encumbered codecs,
then it can MOVE to Fedora and RPM Fusion can ship a mixxx-freeworld plugin
that works with the Fedora mixxx (the preferred way to package support for
additional codecs in RPM Fusion) rather than a package that Conflicts (a
solution that is only used as a last resort).
Kevin Kofler
Re: little mass rebuild required Re: x264 so bump
Sérgio Basto wrote:
> thanks, kwizart all except mythtv rebuild well .
> Richard, mythtv fails to build with :
>
> ERROR! You must have FreeType installed to compile MythTV.
>
> seems you may need add a BR .
This is probably yet another casuality of upstream FreeType having moved
their headers around. The package will have to be patched to find the
headers at their new location.
Kevin Kofler
Re: FFmpeg bundling exception for XBMC
Ken Dreyer wrote: > Another thing to consider Ralf is that I intend to maintain the > package in such a way that it will be trivial to switch between using > the bundled FFmpeg and the non-bundled version using a build > conditional. It should be simple for you to continue building against > your own custom FFmpeg package - you will just need to flip the > "without external_ffmpeg" conditional to "with external_ffmpeg" when > you rebuild your XBMC. See the ongoing work at > http://fedorapeople.org/cgit/alexlan/public_git/xbmc-rpm.git If you're going through the effort of patching the code to work with the system FFmpeg anyway, why not make it the default? Kevin Kofler
Re: FFmpeg bundling exception for XBMC
Ken Dreyer wrote: > Alex Lancaster recently pointed out that XBMC upstream has completely > removed the option to use an external FFmpeg. > > https://github.com/xbmc/xbmc/pull/4005 Then it needs to be patched to revert these commits, or parts of them. It shall be noted that it is NOT necessary to use their "DLL loader" (presumably a cross-platform wrapper around dlopen) to load FFmpeg (the main stuff they removed), it is enough to link the system shared library directly. So the actual CODE does not need to be any different than for static linking, only the build setup needs to link the shared library. Kevin Kofler
