Re: dav1d SONAME bump

On Mon, Dec 14, 2020 at 12:24 AM Jeff Law wrote: > > > On 12/13/20 10:04 PM, Robert-André Mauchin wrote: > > > > - VLC: Fails with error: 'numeric_limits' is not a member of 'std' > > Reported upstream: > > https://trac.videolan.org/vlc/ticket/25325 > > I have a patch to try for this. > > I have

Re: dav1d SONAME bump

On Mon, Dec 14, 2020, 12:04 AM Robert-André Mauchin wrote: > > FeRD, I haven't touched your package, you should be able to rebuild > cinelerra-gg now. > Thanks, I'll submit the builds now. ___ rpmfusion-developers mailing list -

Re: dav1d SONAME bump

On Sat, Dec 5, 2020, 6:22 AM Robert-André Mauchin wrote: > Hello, > > I plan on updating dav1d to 0.8.0 next week. This triggers a soname bump > (libdav1d.so.5). > That's actually perfect, I need to put together new Cinelerra-GG packages anyway, I already have the 2020-10 release built locally

Re: Update koji certificate

On Sat, Nov 21, 2020 at 6:05 AM Nicolas Chauvet wrote: > Le ven. 13 nov. 2020 à 15:27, Nicolas Chauvet a écrit > : > > > > Step3: > > Update rpmfusion-package not to rely on serverca parameter. (and drop > > the deprecated ca parameter that was unused for client certificates). > > > > I'm mostly

Re: Moving fdk-aac to -free?

On Wed, Sep 30, 2020, 10:21 AM Tobias Girstmair wrote: > On Wed, Sep 30, 2020 at 09:56:50AM +, Gary Buhrmaster wrote: > > It was my interpretation that the request > > (from rpmfusion-nonfree to rpmfusion-free) > > had to do with the source license (and > > did not address the entire IP minef

Re: F33 FTBFS list

On Thu, Aug 20, 2020 at 9:00 PM FeRD wrote: > > On Wed, Aug 19, 2020 at 8:06 AM Leigh Scott > wrote: > >> free FTBFS >> >> libopenshot >> > > I'll have that fixed in a few minutes, and a PR opened upstream. > I spoke too soon — fixing the

Re: F33 FTBFS list

On Wed, Aug 19, 2020 at 8:06 AM Leigh Scott wrote: > free FTBFS > > libopenshot > I'll have that fixed in a few minutes, and a PR opened upstream. The issue is a unit test that attempts to test a Settings singleton by changing settings and reading them back again, which then affects the rest of

Re: [mixxx] Delete obsolete .gitignore file

On Sun, Aug 16, 2020 at 10:56 AM Nicolas Chauvet wrote: > Le dim. 16 août 2020 à 12:07, Uwe Klotz a écrit : > > > > commit 7bf13054f5baaee42026813b9784bccba571188a > > Author: Uwe Klotz > > Date: Sun Aug 16 11:57:04 2020 +0200 > > > > Delete obsolete .gitignore file > > > > .gitignore |

Re: Please tests your packages in rawhide

On Sun, Aug 9, 2020 at 2:13 PM Leigh Scott wrote: > That was way easier than I thought :-) > > https://pkgs.rpmfusion.org/cgit/free/ffmpeg.git/tree/ffmpeg.spec#n348 Heh. AKA %configure --prefix ... *--build-correctly* ___ rpmfusion-developers maili

Re: Please tests your packages in rawhide

On Wed, Aug 5, 2020 at 1:22 AM Gary Buhrmaster wrote: > On Wed, Aug 5, 2020 at 4:20 AM FeRD wrote: > > > I haven't merged my changes back beyond master yet, but the impression I > got was, at least once F33 is released, I could. No? > > Your interpretation is the sam

Re: Please tests your packages in rawhide

On Tue, Aug 4, 2020, 6:35 AM Leigh Scott wrote: > None of your changes for openshot are going to work on f32, f31 or el8 > Are you sure? The change announcement said, regarding older releases, "Additionally, %cmake_build, %cmake_install and %ctest macro will be created (and backported to the ol

Re: Please tests your packages in rawhide

On Tue, Aug 4, 2020 at 5:59 AM FeRD wrote: > > (assuming you don't already use a builddir, if so then remove it), > Actually, I take that back. According to the notice, if you're already using your own builddir you can probably just continue to do so. Read t

Re: Kodi 19 Rawhide build

On Thu, Jul 9, 2020 at 5:54 PM Michael Cronenworth wrote: > On 7/8/20 2:41 PM, Michael Cronenworth wrote: > > On 7/8/20 2:15 PM, Nicolas Chauvet wrote: > >> One way would be to lower the debug verbosity to lower link time > requirement. > >> This was picked from fedora chromium for ix86, but can

Re: koji out of space

On Wed, Jul 8, 2020 at 9:47 PM Michael Cronenworth wrote: > On 7/7/20 1:55 PM, Nicolas Chauvet wrote: > > I've clean-up a little space, but basically > > /dev/vda276G 7.3G 65G 11% / > > > > So if one build consumes that much space I can rise up the roofs a > > litt

Re: Kodi 19 Rawhide build

On Wed, Jul 8, 2020 at 3:15 PM Nicolas Chauvet wrote: > Le mer. 8 juil. 2020 à 17:36, Michael Cronenworth a > écrit : > > > > I saw the latest attempt failed. > > > > http://koji.rpmfusion.org/koji/taskinfo?taskID=420003 > > > > The 32-bit ARM build couldn't link. > > > > > http://koji.rpmfusion

Re: [SONAME BUMP] aom version 2.0.0

On Tue, Jul 7, 2020 at 2:01 PM Robert-André Mauchin wrote: > > I have bumped aom to 2.0.0 on Rawhide and rebuilt go-avif and gstreamer1- > plugins-bad-free Fedora side. > > Now the following packages need to be rebuilt on RPMFusion: > > > cinelerra-gg-5.1-58.20191231git3878a69.fc32.x86_64 libaom.

Re: [cinelerra-gg] Add patch to make all Python code use python3

On Mon, Jul 6, 2020 at 10:19 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Monday, 06 July 2020 at 12:48, FeRD wrote: > > > > several bundled > > libraries that are extracted and built as part of the cinelerra-gg build > — >

Re: [cinelerra-gg] Add patch to make all Python code use python3

On Mon, Jul 6, 2020 at 6:19 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > Have you tried unbundling waf instead of patching it? > > I haven't, primarily because it's bundled *in with* several bundled libraries that are extracted and built as part of the cinelerra-gg build

Re: Updated howto related to CUDA and nvidia-driver

On Wed, Jul 1, 2020 at 1:46 PM FeRD wrote: > > I discovered a while back (by reading the source, as this was totally > undocumented) that you can set the environment > variable CYCLES_CUDA_EXTRA_CFLAGS to add additional flags to the nvcc > command line Blender will use to com

Re: Updated howto related to CUDA and nvidia-driver

On Fri, Jun 26, 2020 at 6:24 AM Nicolas Chauvet wrote: > Hello, > > FYI, I've updated some nvidia howto related to CUDA: > https://rpmfusion.org/Howto/CUDA > Regarding the "Running blender" section, there's a simpler way to deal with compiling render kernels. I discovered a while back (by readi

Updating Cinelerra-GG version numbering

Robert-André mentioning Cinelerra-GG and reminding me of the need to update it also brought to mind another issue I wanted to raise. Since I inherited the package, and in strict accordance with the Fedora Packaging Guidelines, the package versioning has stored snapshot details in the RPM Release f

Re: [SONAME BUMP] aom version 2.0.0

On Wed, Jul 1, 2020 at 10:15 AM Robert-André Mauchin wrote: > > I intend to bump the SONAME of libaom from 0 to 2 next week. > > Affected packages are the following: > > PACKAGE DEPENDENT > DEPENDENCIES > libaom-1.0.0-9.20190

Re: [x264/f30: 7/7] Merge branch 'f29' into f30

On Fri, Oct 4, 2019 at 8:00 PM Kevin Kofler wrote: > > 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, a

Re: libopenshot and rebuild for ImageMagick on el7

On Mon, May 25, 2020 at 10:25 AM FeRD wrote: > > I hit that myself, yesterday, experimentally building libopenshot in a > manylinux2014 docker image (based on CentOS 7). > Correction, manylinux2014 is based on CentOS 6. (But I guess the codec issue exists

Re: libopenshot and rebuild for ImageMagick on el7

On Mon, May 25, 2020 at 11:07 AM Nicolas Chauvet wrote: > Le lun. 25 mai 2020 à 16:25, FeRD a écrit : > > > I hit that myself, yesterday, experimentally building libopenshot in a > manylinux2014 docker image (based on CentOS 7). > > > > It seems that the unit test in

Re: libopenshot and rebuild for ImageMagick on el7

On Sun, May 24, 2020 at 9:43 PM Sérgio Basto wrote: > Hello, > I tried rebuild libopenshot [1] and update to 0.2.5 with git merge > master with fast forward , but libopenshot 0.2.4 but we have an error > on root.log "No matching package to install: 'swig >= 3.0' " > The reason el7 had previously

Re: github interaction

On Sun, May 17, 2020 at 1:20 PM Sergio Pascual wrote: > > are we packagers supposed to be members of the rpmfusion organization? I > only see two people there > > Yeah, I'm kinda confused about that too. I knew about some of the rpmfusion-infra repos on Github, for some of RPM Fusion's own develo

Re: Anyone have access to a PPC64LE-based system?

On Tue, Apr 28, 2020, 10:07 PM Sérgio Basto wrote: > > Just to complete the options that we have to test in other arches, mock > also have forcearch feature . > > https://github.com/rpm-software-management/mock/wiki/Feature-forcearch > Ooh! I'll have to check that out. Though, I doubt it would'v

Re: An idea I just had re: RPM Fusion repo installation

On Mon, Apr 20, 2020 at 1:31 AM FeRD wrote: > > I overrode my first instinct of .../f31, .../f32, and .../el8, because > using just the number lets us keep the $(rpm -E %fedora) part of the > instructions, and we can just tell Fedora users to run: > > sudo dnf install https:/

An idea I just had re: RPM Fusion repo installation

As the wiki notes (with questionable formatting), our repos can be installed via the command line using: sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://download1.rpmfusion.org/nonfree/fe

Re: [libopenshot] Re-enable unit tests, ldconfig only RHEL < 8

On Wed, Mar 11, 2020, 7:19 AM Vascom wrote: > Need to create tickets in bugzilla with request to build these > packages for EPEL 8. > I'll see if I can get to that this week. Would that be in the RedHat bugzilla? (That stuff still hasn't moved to Pagure?) I honestly know nothing at all about E

Re: Volunteer to add appdata.xml

On Mon, Mar 9, 2020 at 6:23 AM Sérgio Basto wrote: > On Mon, 2020-03-09 at 09:50 +0100, Vitaly Zaitsev via rpmfusion- > developers wrote: > > I can help with this. We should start from creating the list of > > non-library RPM Fusion packages with missing appdata manifests. > > OK for me , the lis

Re: Volunteer to add appdata.xml

On Sat, Mar 7, 2020 at 2:01 PM Sérgio Basto wrote: > On Sat, 2020-03-07 at 12:49 +0100, Vitaly Zaitsev via rpmfusion-developers > wrote: > > On 07.03.2020 05:45, Sérgio Basto wrote: > > Yes, we can fork it and remove what is already updated, to be organized > > , after update all packages we don'

Re: Volunteer to add appdata.xml

On Fri, Mar 6, 2020 at 10:55 PM Sérgio Basto wrote: > On Thu, 2020-03-05 at 17:22 -0500, FeRD wrote: > > I'm not sure what that repo is supposed to represent, but plenty of the > data there is out of date. For example, OpenShot includes its own > up-to-date AppData file in t

Re: Volunteer to add appdata.xml

I'm not sure what that repo is supposed to represent, but plenty of the data there is out of date. For example, OpenShot includes its own up-to-date AppData file in the distribution (and therefore in the package). (The one there is 5 years old) On Thu, Mar 5, 2020, 5:07 PM Sérgio Basto wrote: >

Re: Anyone have access to a PPC64LE-based system?

On Sat, Feb 15, 2020 at 9:11 PM FeRD wrote: > > Which is why, now that I've just about finished building the library and test > programs, I'm expecting when I test them by hand I'm going to discover that > it doesn't work at all and never did. > > Heh. I w

Re: Anyone have access to a PPC64LE-based system?

On Sat, Feb 15, 2020 at 4:19 PM Leigh Scott wrote: > Maybe I broke something with my unittest-cpp update, > You mean for the libopenshot tests? Oh, no, no, not a chance. They've always been failing on ppc64le, and they fail now no matter what release they're built on. Which is the reason I suspec

Re: Anyone have access to a PPC64LE-based system?

ly took me two hours to finally figure out that I was getting rejected at every login attempt, because I need to be authenticating as "ferdnyc", *NOT* as "ferd". All sorted now. Thanks! Let's see what's up with this frickin' library... ___

Anyone have access to a PPC64LE-based system?

When building on ppc64le (see e.g. this scratch build[1]), libopenshot's unit tests fail spectacularly. Various other build issues have been consistently cropping up on that architecture, all dutifully kludged around. At this point, I'm far from convinced that the *library* is even remotely usable

Re: [libopenshot] Disable failing Ruby bindings on ppc64le

On Fri, Feb 14, 2020 at 5:49 AM Leigh Scott wrote: > > On Thu, Feb 13, 2020 at 11:43 PM Frank R Dana wrote: > > > (Unfortunately, EL7 is failing because libopenshot raised its minimum > SWIG > > version to 3.0. So I guess we're stuck at 0.2.3.) > > Does this build need untagging so it doesn't br

Re: [libopenshot] Disable failing Ruby bindings on ppc64le

On Thu, Feb 13, 2020 at 11:43 PM Frank R Dana wrote: > commit 818363a794e5edbb90048dc0205365fd214734c0 > Author: FeRD (Frank Dana) > Date: Thu Feb 13 23:43:19 2020 -0500 > > Disable failing Ruby bindings on ppc64le > So, this worked, to get libopenshot building on *mos

Re: f32-free ftbfs list

On Wed, Feb 5, 2020 at 1:30 PM Mamoru TASAKA wrote: > > Include the needed additional header before including the header making > trouble > in the source file? (or include the needed header at the top of the source > file?) > Yeah, that *should* work, just a #include before #include (or whatev

Re: aarch64 el8 build failing with http 403

On Mon, Dec 16, 2019 at 5:01 AM Nicolas Chauvet wrote: > Le dim. 15 déc. 2019 à 22:22, Andrew Bauer > a écrit : > > > > I did find this: > > https://pagure.io/koji/issue/1521 > > > > So it would seem setting "module_hotfixes=1" in yum config is the > current workaround. However, what I don't yet

Re: compat-ffmpeg needs a maintainer

On Thu, Dec 5, 2019, 9:39 AM Leigh Scott wrote: > compat-ffmpeg needs a maintainer as I orphaned it today. > > https://admin.rpmfusion.org/pkgdb/package/free/compat-ffmpeg28/ I just ran every one of its provides through a `dnf repoquery --whatrequires`, and... It looks like the ONLY package tha

Re: rpmfusion repo not available?

On Sat, Nov 30, 2019 at 7:21 PM Gary Buhrmaster wrote: > I am getting responses from the metalink that > include the following line: > > # Bad Request [Errno 28] No space left on device > Confirmed that there's an issue retrieving rpmfusion repo data, at least. Though not for all of the availabl

Re: libdvdread SONAME bump

On Fri, Nov 22, 2019 at 5:45 AM Xavier Bachelot wrote: > Le 21/11/2019 à 20:29, FeRD a écrit : > > > > > However, even without the ffmpeg issue, our current libdav1d on F31 and > > F30 is version 0.3.0, which is FAR below the version 0.5.1 that HB 1.3.0 > > is bu

Re: libdvdread SONAME bump

On Thu, Nov 21, 2019 at 7:37 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > Wow. Thanks for finding this. It looks like the fix is here (and also in > 1.3.0: https://github.com/HandBrake/HandBrake/pull/2310 > I'll try to backport this to our 1.2.2 package in the next few da

Re: libdvdread SONAME bump

Ah, it seems this is a well-known issue[1]. On Thu, Nov 21, 2019 at 5:40 AM FeRD wrote: > > I have no idea how this *ever* worked. Maybe hb.h is new-ish, on one side > or the other? > > Or, old-ish. The plot thins. From a comment[2] at that same GitHub issue: The problem seems t

Re: libdvdread SONAME bump

On Wed, Nov 20, 2019 at 5:41 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Friday, 15 November 2019 at 16:24, Dominik 'Rathann' Mierzejewski wrote: > > > > HandBrake > > This is failing to build and I can't figure out why. It's complaining > about missing hb_feature_t dec

Re: Pre-built java dependencies

On Tue, Nov 12, 2019 at 9:10 AM Richard Shaw wrote: > Maybe I'm over-simplifying things, but instead of trying to force a round > peg is a square hole (it may fit, but that's not the point!) > > How about submit a ticket for an exception? > Thank you! That's all I'm saying. _

Re: Pre-built java dependencies

On Tue, Nov 12, 2019 at 8:42 AM Nicolas Chauvet wrote: > Can you elaborate about why you consider it as a big leap ? > > IMO the firmware exeption exactly fit in all points mentioned above > for this case. It might not fit what we expect a firmware to be > (specially as many people consider firmw

Re: Pre-built java dependencies

Yeah, I don't know about that... I did see the firmware exception, and it reads[1] (in part): Some applications, drivers, and hardware require binary-only firmware to > boot Fedora or function properly. Fedora permits inclusion of these files > as long as they meet the following requirements: > >

Re: Pre-built java dependencies

On Mon, Nov 11, 2019 at 7:14 AM FeRD wrote: > > The ideal would be if they could get their device-side server binary > packaged and submitted to Google Play as a downloadable app. That's what > KDE Connect did, with their Android app. Then, the Linux side only needs to > req

Re: Pre-built java dependencies

On Mon, Nov 11, 2019 at 6:55 AM Leigh Scott wrote: > > > The JAR in question is apparently a server-side component of the tool, > and despite being built with the Android SDK as an APK file (Android app > package), they're not running it on Android, it's actually used on the > Linux side. > > The

Re: Pre-built java dependencies

On Mon, Nov 11, 2019, 5:53 AM Leigh Scott wrote: > > > What about adding that as nonfree package? > That doesn't make any difference. > I assume packaging the Android SDK has already been considered and rejected in the past, correct? I know its license imposes restrictions on (or just plain pr

Re: Pre-built java dependencies

On Mon, Nov 11, 2019 at 3:56 AM Vascom wrote: > > I am review package scrcpy > https://bugzilla.rpmfusion.org/show_bug.cgi?id=5450 > > It contain prebuilt jar file. To build this file needed Android SDK > and other 3rdparty software. > Which SOUNDS weird, and in fact it is weird. Assuming I got

Re: [x264/f30: 7/7] Merge branch 'f29' into f30

On Fri, Oct 4, 2019 at 8:00 PM Kevin Kofler wrote: > 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

Re: [x264/f30: 7/7] Merge branch 'f29' into f30

On Fri, Oct 4, 2019 at 4:47 AM Nicolas Chauvet wrote: > > NO, please re-evaluate, I'm not going to read further nor to discuss > it yet again. > I will! On Fri, Oct 4, 2019 at 4:34 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > > Cherry-picking only makes sense when the

Re: [libopenshot/f30] Exclude ppc64le till it can be fixed

On Wed, Oct 2, 2019 at 2:36 AM Nicolas Chauvet wrote: > Well, I think the issue is fixed. Probably caused by OOM errors on the > ppc64le builder. > Reboot solved the issue. > > Please merge the other patch that reverted this commit. > (and please escalate the issue in the future if you are blocke

Re: Rawhide-nonfree: Can't find krb5-libs

On Sun, Sep 29, 2019 at 5:17 PM Richard Shaw wrote: > > Error: Error downloading packages: >Status code: 404 for > http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/k/krb5-libs-1.17-44.fc32.x86_64.rpm > > > Looks like -45 release has been built fo

Re: Advice welcome - Broadcom STA wireless module

On Sun, Sep 15, 2019 at 12:21 PM Nicolas Viéville wrote: > > All the necessary files needed to understand this message are provided > as attachment. > I won't pretend I read any of that, TBH. > My questions are: > > - Do you think it is worth to add definitively to the rpmfusion > broadcom-wl

Re: [mjpegtools] Disable use of SDL_gfx on EL8

On Wed, Sep 11, 2019 at 4:40 AM Kevin Kofler wrote: > 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 S

Re: [mjpegtools] Disable use of SDL_gfx on EL8

On Tue, Sep 10, 2019 at 1:04 PM Sérgio Basto wrote: > On Tue, 2019-09-10 at 18:54 +0200, Xavier Bachelot wrote: > > > > Why ? Is there anything wrong with mjpegtools ? > > > I don't know if have any utility ... > latest version is from 2013-09-27, like libquicktime I think these > packages are a

Re: Dropping i686 userspace by default for f31+

On Mon, Sep 2, 2019 at 12:37 PM Gary Buhrmaster wrote: > Off topic: > > I do wonder a bit as to what will be the reaction > of those using Fedora as their daily driver, but > otherwise do not closely follow the development > process, when they find out they can't upgrade > to F31 on their trust o

Re: RPM Fusion is branched for f31

On Thu, Aug 22, 2019 at 9:54 AM Sérgio Basto wrote: > Thanks , > I saw that we already have F31 published [1], we may update RPMFusion > homepage and mock configurations . > > I'm in holidays until 2 September , may not have time to updated before ... > > [1] > > https://download1.rpmfusion.org/

Re: nonfree devel packages not signed?

On Mon, Aug 19, 2019 at 4:40 PM Nicolas Chauvet wrote: > Le lun. 19 août 2019 à 22:25, FeRD a écrit : > > ...Why would it only be off for the binary RPM repos? > > Probably because nobody cared to report when it was not signed ... > Fair enough, heck I never even NOTICED unt

Re: nonfree devel packages not signed?

On Mon, Aug 19, 2019 at 4:10 PM Hans de Goede wrote: > > One more remark, /etc/yum.repos.d/rpmfusion-[non]free-rawhide.repo > ship with gpgcheck=0 by default, but as my testing has just verified > the packages there are signed, so maybe we should change that to > gpgcheck=1 instead, as we do for

Re: RPM Fusion update report 2019-08-10

On Sat, Aug 10, 2019 at 10:06 AM Sérgio Basto wrote: > > First bug thanks for keeping RPMFusion alive. > > But sometimes this (update report) takes several hours to go online. > isn't it ? > Isn't kwizart in Budapest at FLOCK, like, *right now*? That might excuse a few hours' delay. 😉 __

Re: EL8 targets with modules fixed

On Sun, Aug 4, 2019 at 1:36 PM Sérgio Basto wrote: > > [2] > Subject:[EPEL-devel] Need testers to get EPEL-8 ready for > launch > Date: Sat, 3 Aug 2019 11:21:47 -0400 (03/08/2019 16:21:47) > > Hi we are in the point where we are getting ready for EPEL-8.0 to be > launched so we can star

Re: Scratch builds never work

On Sat, Aug 3, 2019 at 12:51 PM Antonio Trande wrote: > Hi all. > > Since some days i can't do scratch build both on f30-free and rawhide-free: > > > http://koji.rpmfusion.org/koji/getfile?taskID=340985&volume=DEFAULT&name=root.log&offset=-4000 > > Well, that URL it failed on genuinely does not e

Re: [openshot] Add appdata file moving, for EL7 (like old F27)

re. But I haven't tried it on real-EL7 yet. Once the dependencies are all in place on the EPEL side, I'll try a scratch build without the patch, and drop it if I can. > > On Mon, 2019-04-29 at 05:08 +0200, Frank R Dana wrote: > > commit e13c7c33fb2ef698c2a21a5775b5012a35a

Re: Buildroot overrides for (fc31) rawhide?

On Wed, Apr 10, 2019 at 5:27 PM Nicolas Chauvet wrote: > Le mer. 10 avr. 2019 à 22:19, Sérgio Basto a écrit : > > > > On Wed, 2019-04-10 at 15:33 -0400, FeRD wrote: > > > > I just tried to build[1] libopenshot for rawhide, and it failed due to > libopenshot-audio

Buildroot overrides for (fc31) rawhide?

I just tried to build[1] libopenshot for rawhide, and it failed due to libopenshot-audio not being available but I already built that[2] for rawhide. Do I need to tag the libopenshot-audio build for buildroot override? I thought that wasn't necessary for rawhide? [1]: http://koji.rpmfusion.org

Re: why broadcom-wl and wl-kmod aren't build in el7 ?

On Sun, Apr 7, 2019 at 1:51 PM Nicolas Viéville wrote: > > Hello, > > > why broadcom-wl and wl-kmod aren't build in el7 ? > > any particular reason ? doesn't build ? or just forgotten ? > > Packages broadcom-wl and wl-kmod were build for el7. > > Building for el6 failed with these errors: > > http

Re: RPM Fusion for Fedora 30 Freeze date

On Sat, Apr 6, 2019 at 11:48 AM Nicolas Chauvet wrote: > > Please consider to state which work is needed in the RPM Fusion repos > before to freeze the f30 GA repos. If a dependency needs to be updated > in Fedora side, please have the needed rebuild done by that date. As far as OpenShot goes (cu

Project name/branding (was Re: [Bug 5155] Review request: pulseaudio-module-bluetooth-freeworld - Bluetooth support for the PulseAudio sound server, supports extra codecs)

On Tue, Apr 2, 2019 at 3:01 AM RPM Fusion Bugzilla wrote: > *Comment # 37 on > bug 5155 from Nicolas > Chauvet * > > - Last point, the project is written RPM Fusion if case sensitive o

Re: Building new OpenShot (and libs) for branches only

On Sat, Mar 23, 2019 at 8:09 PM FeRD wrote: > > > On Sat, Mar 23, 2019 at 4:06 AM Nicolas Chauvet wrote: > >> Le sam. 23 mars 2019 à 07:30, FeRD a écrit : >> > >> > As an example, the createrepo task[1] for f29-free-build on armhfp >> reports a gree

Re: Building new OpenShot (and libs) for branches only

On Sat, Mar 23, 2019 at 4:06 AM Nicolas Chauvet wrote: > Le sam. 23 mars 2019 à 07:30, FeRD a écrit : > > > > On Fri, Mar 22, 2019 at 11:12 PM FeRD wrote: > >> > >> OpenShot released a new version 2.4.4 earlier this week, so I'm > readying new builds o

Re: Building new OpenShot (and libs) for branches only

On Fri, Mar 22, 2019 at 11:12 PM FeRD wrote: > OpenShot released a new version 2.4.4 earlier this week, so I'm readying > new builds of the libopenshot-audio, libopenshot, and openshot packages for > the f29 and f28 branches. > Well, I WAS... Unfortunately, though libope

Building new OpenShot (and libs) for branches only

OpenShot released a new version 2.4.4 earlier this week, so I'm readying new builds of the libopenshot-audio, libopenshot, and openshot packages for the f29 and f28 branches. libopenshot-audio is still FTBFS in rawhide due to GCC 9, so the new version *won't* be built there. I seem to recall that

Re: rpmfusion-FTBFS-f30

On Sun, Mar 10, 2019 at 4:53 PM FeRD wrote: > On Sun, Mar 10, 2019 at 1:42 AM Sérgio Basto wrote: > >> >> libopenshot >> libopenshot-audio >> > > I'll take a look tonight. > Unfortunately, both libraries are failing due to a compile error in heade

Re: rpmfusion-FTBFS-f30

On Sun, Mar 10, 2019 at 4:53 PM FeRD wrote: > I'm surprised that openshot isn't on the list as well, since it requires > this: > > >> qt5-qtwebengine-freeworld > > Wait, nope, sorry. openshot requires qt5-qtwebKIT-freeworld. __

Re: rpmfusion-FTBFS-f30

On Sun, Mar 10, 2019 at 1:42 AM Sérgio Basto wrote: > > libopenshot > libopenshot-audio > I'll take a look tonight. I'm surprised that openshot isn't on the list as well, since it requires this: > qt5-qtwebengine-freeworld > But I guess if the F29 version is present that should be fine. _

mp4tools broken with latest wxsvg

I just filed[1] bug #5166 in bugzilla about this: Looks like the newly-built mp4tools didn't pick up the correct version of the also-newly-built wxsvg, as it contains an incompatible symbol definition. With both installed: mp4tools-3.7-3.fc29.x86_64 wxsvg-1.5.16-1.fc29.x86_64 $ mp4joiner mp4join

Re: [Bug 5122] Review Request: omxplayer - Raspberry Pi command line OMX player

On Mon, Jan 7, 2019 at 9:02 PM RPM Fusion Bugzilla wrote: > *Comment # 7 on > bug 5122 from Andrew > Bauer * > > (In reply to Nicolas Chauvet from comment #4 >

Re: fedora-review always ends with ERROR

On Tue, Dec 11, 2018 at 8:38 AM Richard Shaw wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1409923 > > Filed over a year ago Ignored... > > Actually, it looks like Sérgio fixed this a year ago[1], the patch was even merged. Then Robert-André reported a bug with sub-dictionaries, and

Re: fedora-review always ends with ERROR

On Mon, Dec 10, 2018 at 2:47 AM Martin Gansser wrote: > Hi, > > fedora-review always ends with error message: > $ fedora-review --other-bz https://bugzilla.rpmfusion.org -b 5104 -m > fedora-rawhide-x86_64-rpmfusion_free > ... > ERROR: Exception down the road...(logs in > /home/martin/.cache/fedor

Re: rfpkg on silverblue throws a encoding declaration error!

On Sun, Dec 9, 2018 at 8:24 PM Sérgio Basto wrote: > On Sun, 2018-12-09 at 10:52 -0500, FeRD wrote: > > > > Well, agreed, and it'll need to be changed to #!/usr/bin/python3 > > anyway. I've already got the code ported and working in Py3, but for > > whatever

Re: rfpkg on silverblue throws a encoding declaration error!

On Sun, Dec 9, 2018 at 10:49 AM Sérgio Basto wrote: > On Sun, 2018-12-09 at 01:58 -0500, FeRD wrote: > > True. In the repo the code starts with #!/usr/bin/python, but the RPM > spec normalizes it to #!/usr/bin/python2 during packaging. > > > upstream source should be fixe

Re: rfpkg on silverblue throws a encoding declaration error!

On Sun, Dec 9, 2018 at 2:13 AM Akarshan Biswas wrote: > > Interesting! > Here is output on silverblue: > $ python2.7 -v /usr/bin/rpmfusion-cert |&egrep > '(^dlopen|^import).*(locale|encoding)' > dlopen("/usr/lib64/python2.7/lib-dynload/_localemodule.so", 2); > import _locale # dynamically loaded

Re: rfpkg on silverblue throws a encoding declaration error!

On Sun, Dec 9, 2018 at 12:42 AM Akarshan Biswas wrote: > Hi. Thanks for the response. > > >> How is it installed on the system? *.* >> > It is installed via package layering. ostrees are immutable. The extra > "rpm" packages that we add sits on top of the base layer. > rpm-ostree status > > State

Re: rfpkg on silverblue throws a encoding declaration error!

On Sat, Dec 8, 2018 at 6:09 AM Akarshan Biswas wrote: > I talked with otaylor yesterday about this and he told me that the #! > line(shebang) for rpmfusion-cert.py should specify a particular version. How is it installed on the system? Because, on my Fedora 29 box, it *does.* $ rpm -q rpmfusio

Re: [el7] Upgrading with newer ffmpeg/x264/x265

On Sat, Nov 24, 2018 at 8:09 PM FeRD wrote: > > It's a re-merge of two branches with a common ancestor, where the "target" > branch (the one which is being merged *into*) hasn't had any changes > since the "source" branch (the one *being* merged into

Re: [el7] Upgrading with newer ffmpeg/x264/x265

On Sat, Nov 24, 2018 at 4:30 PM Antonio Trande wrote: > On 24/11/18 20:00, Sérgio Basto wrote: > > > > If we can merge with ff (fast-forward ) from some branch is the best , > > if we can merge with ff (fast-forward ) (from some branch or master) and > > apply a minor is my 2nd choice . > > Else

Re: OpenShot dependencies not in EL7: rpmfusion or Fedora/EPEL?

On Mon, Nov 12, 2018 at 11:03 AM Kevin Kofler wrote: > 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

Re: Upgrading EL7 with a newer ffmpeg

On Sun, Nov 11, 2018 at 5:02 PM Antonio wrote: > ffmpeg, gpac, x264 are ready; just a question: ffmpeg and x264 are > interdependent (ffmpeg needs x264 and viceversa), how can be they > rebuilt/updated both if wish install ffmpeg-3.3.8 + x264-0.155? > > Sergio posted a link to a wiki page that co

OpenShot dependencies not in EL7: rpmfusion or Fedora/EPEL?

Since EL7 ffmpeg is getting some attention, I thought I'd take the opportunity to revisit something I've been sitting on for a couple of months now, because I'm at an impasse. This started with Sergio, but fell to me when I took over maintenance of OpenShot, and I've taken it as far as I can... but

Re: [chromium-vaapi] Re brand chromium-vaapi and update vaapi patch

On Wed, Nov 7, 2018 at 7:20 AM Akarshan Biswas wrote: > > Hi! > > > > On Wednesday, 07 November 2018 at 12:10, hellbanger wrote: > > [...] > > [...] > > > > This is wrong. All patches should end up in SRPM regardless of which > > Fedora version it's build on. Applying them can be conditional, but

Re: Fedora 28 openmpi dependency problem?

On Sat, Nov 3, 2018 at 8:29 AM Richard Shaw wrote: > > Why is there a difference? What is the significance of the appended > (openmpi-x86_64)? > > Is that the problem? > > My impression (and I really know next-to-nothing about this stuff) is that the (openmpi-x86_64) is there to differentiate the

Re: RPM Fusion schedule for f29

On Fri, Oct 19, 2018 at 7:21 PM Sérgio Basto wrote: > On Fri, 2018-10-19 at 18:25 -0400, FeRD wrote: > > > > On Fri, Oct 19, 2018 at 5:44 PM Sérgio Basto wrote: > > > Also I though that we might a good idea also show the tained repo

  1   2   >