[Bug 5468] Review Request: gstreamer-ffmpeg - GStreamer FFmpeg-based plug-ins
https://bugzilla.rpmfusion.org/show_bug.cgi?id=5468 Dominik 'Rathann' Mierzejewski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominik 'Rathann' Mierzejewski --- Looks like the buildroot got synchronized and Leigh was able to build it for F32, too: http://koji.rpmfusion.org/koji/buildinfo?buildID=13242 . Closing. -- You are receiving this mail because: You are on the CC list for the bug.___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: aarch64 el8 build failing with http 403
As of today, the zoneminder x86_64 build is now failing with the same modular error as the other arches: > DEBUG util.py:596: No available modular metadata for modular package > 'mariadb-devel-3:10.3.11-2.module+el8+2885+7b8bb354.x86_64', it cannot be > installed on the system > DEBUG util.py:596: No available modular metadata for modular package > 'perl-DBD-MySQL-4.046-2.module+el8+2515+0650e81c.x86_64', it cannot be > installed on the system > DEBUG util.py:596: No available modular metadata for modular package > 'perl-DBI-1.641-2.module+el8+2701+8f20fb82.x86_64', it cannot be installed on > the system So it would seem I am forced to deal with this, rather than ignore it by excluding aarch64 and ppc64le. This whole module thing is completely new to me. Is there something I can add to the spec file to resolve this?? I have not yet found anything that indicates this might be the case. 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 understand is where this option gets set in a koji environment. Can I somehow pass this option on the command line during rfpkg build?? Could use a bump to get me going in the right direction Thanks, Andy From: Nicolas Chauvet Sent: Sunday, December 15, 2019 4:11 AM To: RPM Fusion developers discussion list Subject: Re: aarch64 el8 build failing with http 403 Le sam. 14 déc. 2019 à 17:08, Andrew Bauer a écrit : > > Zoneminder el8 build succeeds for x86_64, but the aarch64 build is failing to > download dependent packages with http 403: > > > DEBUG util.py:598: Downloading Packages: > > DEBUG util.py:596: Error: Error downloading packages: > > DEBUG util.py:596:Status code: 403 for > > http://koji.rpmfusion.org/buildsys-override/rhel/rhel-8-for-aarch64-baseos-rpms-staged/Packages/a/audit-libs-3.0-0.10.20180831git0047a6c.el8.aarch64.rpm > > (IP: 192.168.1.4) > > DEBUG util.py:744: Child return code was: 1 > > DEBUG util.py:763: child environment: None > > Full root.log is here: > http://koji.rpmfusion.org/kojifiles/work/tasks/4870/374870/root.log > > Thoughts? The 403 issue itself is fixed, but then it lead to another issue with modules not been able to install on aarch64 and ppc64le. For now I would recommend to disable the modular deps in el8 if possible or only to build for x86_64 for el8. I hope it could be fixed at a not so long future in our infra. Thx -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Aw: Re: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
Thank you for supporting me Regards Martin > Gesendet: Sonntag, 15. Dezember 2019 um 14:24 Uhr > Von: "Nicolas Chauvet" > An: "RPM Fusion developers discussion list" > > Betreff: Re: xine_sxfe_frontend.c:1865: undefined reference to > `glXQueryVersion' > Le dim. 15 déc. 2019 à 11:58, Martin Gansser a écrit : >> >> I see this difference in the build.log >> >> 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 > Then the upstream check looks incorrect > if using the new -lOpenGL links flag, but still using the > glXQueryVersion* symbols, one should also use the -lGLX link flag. > -lOpenGL is not a complete replacement of -lGL. > ___ > rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org > To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Aw: Re: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
Tank you for supporting me
Regards
Martin
> Gesendet: Sonntag, 15. Dezember 2019 um 13:03 Uhr
> Von: "Kevin Kofler"
> An: rpmfusion-developers@lists.rpmfusion.org
> Betreff: 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
___
rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org
To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
Le dim. 15 déc. 2019 à 11:58, Martin Gansser a écrit : > > I see this difference in the build.log > > 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 Then the upstream check looks incorrect if using the new -lOpenGL links flag, but still using the glXQueryVersion* symbols, one should also use the -lGLX link flag. -lOpenGL is not a complete replacement of -lGL. ___ 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
Aw: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
I see this difference in the build.log 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 the part in the code is: check_deps # need -lm for ceil/floor in HUD OSD enabled xrender && add_flags "LIBS_X11" "-lm" # need -ldl and -lpthread with opengl enabled opengl && add_flags "LIBS_X11" $LIBS_DLFCN $LIBS_PTHREAD # need -ldl for dlopen() in vdr plugin enabled vdr && add_flags "LIBS_VDR" $LIBS_DLFCN what is the easiest way to set the "LIBS_X11" for f32 and where should it be set? [1] http://koji.rpmfusion.org/kojifiles/packages/vdr-xineliboutput/2.1.0/16.20191117git32a5ffc.fc31/data/logs/x86_64/build.log [2] http://koji.rpmfusion.org/kojifiles/work/tasks/4826/374826/build.log Regards Martin > Gesendet: Sonntag, 15. Dezember 2019 um 11:09 Uhr > Von: "Leigh Scott" > An: "Martin Gansser" > Betreff: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion' > mesa and libglvnd changes are the reason why it fails in f32, you will > need to fix the broken opengl tests in your code. > > On 15/12/2019 09:49, Martin Gansser wrote: >>> Gesendet: Sonntag, 15. Dezember 2019 um 08:59 Uhr >>> Von: "Nicolas Chauvet" >>> An: "RPM Fusion developers discussion list" >>> Betreff: Re: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion' >>> Le dim. 15 déc. 2019 à 08:39, Martin Gansser a écrit : Hi, when running a koji build for rawhide koji-rpmfusion build --scratch rawhide-free ../SRPMS/vdr-xineliboutput-2.1.0-16.20191117git32a5ffc.fc31.src.rpm it get this errors [1]: /usr/bin/ld: xine_sxfe_frontend.o: in function `opengl_init': /builddir/build/BUILD/vdr-xineliboutput/xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion' >>> You are probably missing a -lGL link flag. >> but this only happens on f32 >> >> Regards >> Martin___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: aarch64 el8 build failing with http 403
Le sam. 14 déc. 2019 à 17:08, Andrew Bauer a écrit : > > Zoneminder el8 build succeeds for x86_64, but the aarch64 build is failing to > download dependent packages with http 403: > > > DEBUG util.py:598: Downloading Packages: > > DEBUG util.py:596: Error: Error downloading packages: > > DEBUG util.py:596:Status code: 403 for > > http://koji.rpmfusion.org/buildsys-override/rhel/rhel-8-for-aarch64-baseos-rpms-staged/Packages/a/audit-libs-3.0-0.10.20180831git0047a6c.el8.aarch64.rpm > > (IP: 192.168.1.4) > > DEBUG util.py:744: Child return code was: 1 > > DEBUG util.py:763: child environment: None > > Full root.log is here: > http://koji.rpmfusion.org/kojifiles/work/tasks/4870/374870/root.log > > Thoughts? The 403 issue itself is fixed, but then it lead to another issue with modules not been able to install on aarch64 and ppc64le. For now I would recommend to disable the modular deps in el8 if possible or only to build for x86_64 for el8. I hope it could be fixed at a not so long future in our infra. Thx -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Re: Re: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
Le dim. 15 déc. 2019 à 10:49, Martin Gansser a écrit : > > > Gesendet: Sonntag, 15. Dezember 2019 um 08:59 Uhr > > Von: "Nicolas Chauvet" > > An: "RPM Fusion developers discussion list" > > > > Betreff: Re: xine_sxfe_frontend.c:1865: undefined reference to > > `glXQueryVersion' > > Le dim. 15 déc. 2019 à 08:39, Martin Gansser a écrit : > > > > > > Hi, > > > > > > when running a koji build for rawhide > > > koji-rpmfusion build --scratch rawhide-free > > > ../SRPMS/vdr-xineliboutput-2.1.0-16.20191117git32a5ffc.fc31.src.rpm > > > > > > it get this errors [1]: > > > > > > /usr/bin/ld: xine_sxfe_frontend.o: in function `opengl_init': > > > /builddir/build/BUILD/vdr-xineliboutput/xine_sxfe_frontend.c:1865: > > > undefined reference to `glXQueryVersion' > > You are probably missing a -lGL link flag. > > but this only happens on f32 It might be a side effect of one or another update from f32, which lead to have -lGL, now if you don't have the -lGL link flag there is no way around, this is the fix. -- - Nicolas (kwizart) ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
Aw: Re: xine_sxfe_frontend.c:1865: undefined reference to `glXQueryVersion'
> Gesendet: Sonntag, 15. Dezember 2019 um 08:59 Uhr > Von: "Nicolas Chauvet" > An: "RPM Fusion developers discussion list" > > Betreff: Re: xine_sxfe_frontend.c:1865: undefined reference to > `glXQueryVersion' > Le dim. 15 déc. 2019 à 08:39, Martin Gansser a écrit : > > > > Hi, > > > > when running a koji build for rawhide > > koji-rpmfusion build --scratch rawhide-free > > ../SRPMS/vdr-xineliboutput-2.1.0-16.20191117git32a5ffc.fc31.src.rpm > > > > it get this errors [1]: > > > > /usr/bin/ld: xine_sxfe_frontend.o: in function `opengl_init': > > /builddir/build/BUILD/vdr-xineliboutput/xine_sxfe_frontend.c:1865: > > undefined reference to `glXQueryVersion' > You are probably missing a -lGL link flag. but this only happens on f32 Regards Martin ___ rpmfusion-developers mailing list -- rpmfusion-developers@lists.rpmfusion.org To unsubscribe send an email to rpmfusion-developers-le...@lists.rpmfusion.org
