Re: [blfs-support] Problems with xine-lib on intel and amdgpu
On 2020-08-14 17:00 +0100, Ken Moffat via blfs-support wrote: > On Fri, Aug 14, 2020 at 10:19:18AM -0500, Douglas R. Reno via blfs-support > wrote: > > On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote: > > > My second set of problems with video players ;) > > > > > > I know that xine has always been rather fragile, partly related to > > > CFLAGS I use in oe of the dependencies - but a year ago those > > > detined flags made it mostly work. With mov files and some of my > > > own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to > > > stutter (the picture jumps backwards). On downloads they usually > > > play ok. > > > > > > With my current (late July build) on my haswell, almost everything > > > that I try to play in xine crashes at startup. On my machine using > > > radeon r600, my own mov files crash but everything else plays fine. > > > On my machien with amdgpu, the mov files from my camera similarly > > > crash, but everything else plays *until I use the xine control > > > slider to move forward through the video* (I don't wish to spend > > > hours looking at the files I'm using for testing). As soon as I > > > touch the slider, xine crashes. > > > > > > Looking back at older systems, that behaviour with amdgpu was > > > present in BLFS-9.1. > > > > > > I've now reverted the string of packages I mentioned in my post > > > about parole (but again that has made no difference. > > > > > > Summary: For me xine (technically xine-ui) crashes on intel igpu, > > > mostly works on radeon, works on amdgpu if I don't use the controls > > > and let it play through. > > > > > > Again, I would be interested to hear of other people's successes. > > > Note that one or two files (one commercial mov, two commercial wmv) > > > do work with or without the reverts, other commercial wmv files > > > crash. > > > > > > ĸen > > > > Hi Ken, > > > > > > I wanted to let you know that I was able to get Xine to play > > big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I don't > > have any .mov files or any .wmv files sitting around here that I can use > > though, and I'm not sure converting would be much help here either. I did > > also scrub through the video using the slider, and watched it to completion. > > > > I am using Mesa-20.1.5, with the Intel Iris driver that's built into Mesa > > (newer Intel systems won't be able to use i965 properly, especially once the > > Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use too. The > > current driver loaded on my system is "iris". I did see an error regarding > > libvdpau_nvidia.so when starting though, but I don't think that's related. > > As far as I can tell, I do have the latest version of the related packages > > installed on this machine. > > > > Here is my console output: > > > > renodr [ /sources ]$ xine big_buck_bunny.mp4 > > This is xine (X11 gui) - a free video player > > v0.99.12. | > > (c) 2000-2019 The xine Team. > > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > > file: No such file or direct > > ory > > libva info: VA-API version 1.8.0 > > libva error: vaGetDriverNameByIndex() failed with unknown libva error, > > driver_name = (null) > > > > > > Is it possible that it could be permissions? My intel system here is a > > systemd box. I am working on my elogind system at the moment to check on a > > couple things, and it has a Radeon in it. I'll let you know how that works, > > it's on my list to try next. I know libva-intel-driver won't work with new Intel hardware. But I'm not sure if it would work with mesa Iris driver. Have you tried `MESA_LOADER_DRIVER_OVERRIDE=i965`? -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Parole breakage on intel gpu.
On 2020-08-14 16:53 +0100, Ken Moffat via blfs-support wrote: > On Fri, Aug 14, 2020 at 10:39:44AM -0500, Douglas R. Reno via blfs-support > wrote: > > On 8/9/20 6:35 PM, Ken Moffat via blfs-support wrote: > > > Two or three weeks ago I noticed a problem with parole on my latest > > > build on my haswell (LFS from 25th July, BLFS from the next day). > > > Whatever I try to view, the screen broken into horizontal stripes, > > > rather like venetian blinds but with a mix of colours not apparently > > > related to the video which should be visible. > > > > > > On a machine using radeon (R600-series) video, parole works fine. > > > > > > On my haswell, the following all work fine: ffplay, gst-play-1.0, > > > vlc. > > > > > > Other things have, of course, got in the way, but I'm now ready to > > > document what has changed between working and broken versions, and > > > to ask for suggestions. > > > > > > Looking back at previous builds on this machine, a build in May was > > > fine, the intermediate build in June showed the same problem. > > > > > > The following packages, and versions, are common to both the good > > > and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2, > > > fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1, > > > libvorbis-1.3.7 (I upgraded older systems to that version), > > > libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4, > > > libvdpau-va-gl-0.4.0, SDL2-2.0.12. > > > > > > Looking at what had changed: > > > > > > ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current. > > > > > > libva-2.7.1 on last working system and on June non-working, 2.8.0 on > > > latest. > > > > > > x265 3.3 on working, 3.4 on latest (now reverted to 3.3, symlink > > > fixed, gst-plugins-bad rebuilt) > > > > > > intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to > > > 2.4.0. > > > > > > xf86-video-intel 20200218 on good, 20200518 on latest, now reverted > > > to 20200218. > > > > > > Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout > > > these builds. > > > > > > At this stage, this is just a request for suggestions, and a > > > question whether parole is working on anyone's current intel > > > machiens with integrated graphics ? > > > > > > TIA > > > > > > ĸen > > > > I would say that I was able to get Parole working, but unfortunately I'm not > > able to: > > > > [Current thread is 1 (Thread 0x7fb5315b2a00 (LWP 6876))] > > (gdb) bt > > #0 0x7fb5325379c2 in _XInternAtom > > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > > ts=onlyIfExists@entry=1, psig=psig@entry=0x7ffedf8e53b8, > > pidx=pidx@entry=0x7ffedf8e53b0, pn=pn@entry=0x > > 7ffedf8e53b4) at IntAtom.c:76 > > #1 0x7fb532537cfb in XInternAtom > > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > > ts=onlyIfExists@entry=1) at IntAtom.c:175 > > #2 0x0041f4f6 in parole_player_set_wm_opacity_hint > > (widget=0x1a28510 [GtkWindow]) > > at parole-player.c:3071 > > #3 parole_player_init (player=0x1e98480 [ParolePlayer]) at > > parole-player.c:3734 > > #4 0x7fb5327d1571 in g_type_create_instance (type=) at > > ../gobject/gtype.c:1867 > > #5 0x7fb5327b8125 in g_object_new_internal > > (class=class@entry=0x1a77ed0, params=params@entry=0x7ffedf8e56a0, > > n_params=n_params@entry=1) > > at ../gobject/gobject.c:1937 > > #6 0x7fb5327b9bb4 in g_object_new_valist > > (object_type=, > > first_property_name=first_property_name@entry=0x438348 "client-id", v > > ar_args=var_args@entry=0x7ffedf8e57e8) at ../gobject/gobject.c:2262 > > #7 0x7fb5327b9f0c in g_object_new > > (object_type=, > > first_property_name=first_property_name@entry=0x438348 "client-id") > > at ../gobject/gobject.c:1780 > > #8 0x0042127e in parole_player_new (client_id=0x0) at > > parole-player.c:3739 > > #9 0x004182af in main (argc=, argv=) > > at main.c:340 > > (gdb) > > > > When I launch Parole, it crashes with a segmentation fault. This is on my > > Intel system, with Mesa-20.1.5, gst-*-1.16.2 of course, and > > libxfce4ui-4.14.1 with the rest of the stack. > > > > > > I'm not sure what's causing this. > > > > Ken, you are able to get it to start at least without a segfault, right? > > > > Yes. On elogind and i965. > > > I'll be building this on my elogind system later, will verify that it works > > there. Maybe it's something with the Iris driver. I'll research how to back > > down to i965 to see if I can fix it that way, but it's acting like its > > elsewhere. According to Arch wiki, i965 is still used by default on Haswell. Iris is the default on Broadwell and newer. So I don't think it's an Iris problem. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ:
Re: [blfs-support] Problems with xine-lib on intel and amdgpu
On Fri, Aug 14, 2020 at 10:19:18AM -0500, Douglas R. Reno via blfs-support wrote: > > On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote: > > My second set of problems with video players ;) > > > > I know that xine has always been rather fragile, partly related to > > CFLAGS I use in oe of the dependencies - but a year ago those > > detined flags made it mostly work. With mov files and some of my > > own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to > > stutter (the picture jumps backwards). On downloads they usually > > play ok. > > > > With my current (late July build) on my haswell, almost everything > > that I try to play in xine crashes at startup. On my machine using > > radeon r600, my own mov files crash but everything else plays fine. > > On my machien with amdgpu, the mov files from my camera similarly > > crash, but everything else plays *until I use the xine control > > slider to move forward through the video* (I don't wish to spend > > hours looking at the files I'm using for testing). As soon as I > > touch the slider, xine crashes. > > > > Looking back at older systems, that behaviour with amdgpu was > > present in BLFS-9.1. > > > > I've now reverted the string of packages I mentioned in my post > > about parole (but again that has made no difference. > > > > Summary: For me xine (technically xine-ui) crashes on intel igpu, > > mostly works on radeon, works on amdgpu if I don't use the controls > > and let it play through. > > > > Again, I would be interested to hear of other people's successes. > > Note that one or two files (one commercial mov, two commercial wmv) > > do work with or without the reverts, other commercial wmv files > > crash. > > > > ĸen > > Hi Ken, > > > I wanted to let you know that I was able to get Xine to play > big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I don't > have any .mov files or any .wmv files sitting around here that I can use > though, and I'm not sure converting would be much help here either. I did > also scrub through the video using the slider, and watched it to completion. > > I am using Mesa-20.1.5, with the Intel Iris driver that's built into Mesa > (newer Intel systems won't be able to use i965 properly, especially once the > Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use too. The > current driver loaded on my system is "iris". I did see an error regarding > libvdpau_nvidia.so when starting though, but I don't think that's related. > As far as I can tell, I do have the latest version of the related packages > installed on this machine. > > Here is my console output: > > renodr [ /sources ]$ xine big_buck_bunny.mp4 > This is xine (X11 gui) - a free video player > v0.99.12. | > (c) 2000-2019 The xine Team. > Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object > file: No such file or direct > ory > libva info: VA-API version 1.8.0 > libva error: vaGetDriverNameByIndex() failed with unknown libva error, > driver_name = (null) > > > Is it possible that it could be permissions? My intel system here is a > systemd box. I am working on my elogind system at the moment to check on a > couple things, and it has a Radeon in it. I'll let you know how that works, > it's on my list to try next. > > > - Doug > Hi Doug. First, thanks for looking at this. I will be very surprised if permissions are involved, because I'm using the same scripts (different xorg video drivers, and the intel-specific va only on intel) on haswell (broken), radeon (ok), amdgpu (ok until I use the slider to scroll forward or back). ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Parole breakage on intel gpu.
On Fri, Aug 14, 2020 at 10:39:44AM -0500, Douglas R. Reno via blfs-support wrote: > > On 8/9/20 6:35 PM, Ken Moffat via blfs-support wrote: > > Two or three weeks ago I noticed a problem with parole on my latest > > build on my haswell (LFS from 25th July, BLFS from the next day). > > Whatever I try to view, the screen broken into horizontal stripes, > > rather like venetian blinds but with a mix of colours not apparently > > related to the video which should be visible. > > > > On a machine using radeon (R600-series) video, parole works fine. > > > > On my haswell, the following all work fine: ffplay, gst-play-1.0, > > vlc. > > > > Other things have, of course, got in the way, but I'm now ready to > > document what has changed between working and broken versions, and > > to ask for suggestions. > > > > Looking back at previous builds on this machine, a build in May was > > fine, the intermediate build in June showed the same problem. > > > > The following packages, and versions, are common to both the good > > and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2, > > fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1, > > libvorbis-1.3.7 (I upgraded older systems to that version), > > libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4, > > libvdpau-va-gl-0.4.0, SDL2-2.0.12. > > > > Looking at what had changed: > > > > ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current. > > > > libva-2.7.1 on last working system and on June non-working, 2.8.0 on > > latest. > > > > x265 3.3 on working, 3.4 on latest (now reverted to 3.3, symlink > > fixed, gst-plugins-bad rebuilt) > > > > intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to > > 2.4.0. > > > > xf86-video-intel 20200218 on good, 20200518 on latest, now reverted > > to 20200218. > > > > Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout > > these builds. > > > > At this stage, this is just a request for suggestions, and a > > question whether parole is working on anyone's current intel > > machiens with integrated graphics ? > > > > TIA > > > > ĸen > > > I would say that I was able to get Parole working, but unfortunately I'm not > able to: > > [Current thread is 1 (Thread 0x7fb5315b2a00 (LWP 6876))] > (gdb) bt > #0 0x7fb5325379c2 in _XInternAtom > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > ts=onlyIfExists@entry=1, psig=psig@entry=0x7ffedf8e53b8, > pidx=pidx@entry=0x7ffedf8e53b0, pn=pn@entry=0x > 7ffedf8e53b4) at IntAtom.c:76 > #1 0x7fb532537cfb in XInternAtom > (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 > "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis > ts=onlyIfExists@entry=1) at IntAtom.c:175 > #2 0x0041f4f6 in parole_player_set_wm_opacity_hint > (widget=0x1a28510 [GtkWindow]) > at parole-player.c:3071 > #3 parole_player_init (player=0x1e98480 [ParolePlayer]) at > parole-player.c:3734 > #4 0x7fb5327d1571 in g_type_create_instance (type=) at > ../gobject/gtype.c:1867 > #5 0x7fb5327b8125 in g_object_new_internal > (class=class@entry=0x1a77ed0, params=params@entry=0x7ffedf8e56a0, > n_params=n_params@entry=1) > at ../gobject/gobject.c:1937 > #6 0x7fb5327b9bb4 in g_object_new_valist > (object_type=, > first_property_name=first_property_name@entry=0x438348 "client-id", v > ar_args=var_args@entry=0x7ffedf8e57e8) at ../gobject/gobject.c:2262 > #7 0x7fb5327b9f0c in g_object_new > (object_type=, > first_property_name=first_property_name@entry=0x438348 "client-id") > at ../gobject/gobject.c:1780 > #8 0x0042127e in parole_player_new (client_id=0x0) at > parole-player.c:3739 > #9 0x004182af in main (argc=, argv=) > at main.c:340 > (gdb) > > When I launch Parole, it crashes with a segmentation fault. This is on my > Intel system, with Mesa-20.1.5, gst-*-1.16.2 of course, and > libxfce4ui-4.14.1 with the rest of the stack. > > > I'm not sure what's causing this. > > Ken, you are able to get it to start at least without a segfault, right? > Yes. On elogind and i965. > I'll be building this on my elogind system later, will verify that it works > there. Maybe it's something with the Iris driver. I'll research how to back > down to i965 to see if I can fix it that way, but it's acting like its > elsewhere. > > > - Doug > Fun. ĸen -- Juliet's version of cleanliness was next to godliness, which was to say it was erratic, past all understanding and was seldom seen. -- Unseen Academicals -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Parole breakage on intel gpu.
On 8/9/20 6:35 PM, Ken Moffat via blfs-support wrote: Two or three weeks ago I noticed a problem with parole on my latest build on my haswell (LFS from 25th July, BLFS from the next day). Whatever I try to view, the screen broken into horizontal stripes, rather like venetian blinds but with a mix of colours not apparently related to the video which should be visible. On a machine using radeon (R600-series) video, parole works fine. On my haswell, the following all work fine: ffplay, gst-play-1.0, vlc. Other things have, of course, got in the way, but I'm now ready to document what has changed between working and broken versions, and to ask for suggestions. Looking back at previous builds on this machine, a build in May was fine, the intermediate build in June showed the same problem. The following packages, and versions, are common to both the good and bad builds: running kernel 5.7.2, gcc-10.1.0, gstreamer-1.16.2, fdk-aac-2.0.1, freetype-2.10.2, lame-3.100, libtheora-1.1.1, libvorbis-1.3.7 (I upgraded older systems to that version), libvpx-1.8.2, opus-1.3.1, x264-20200218, yasm-1.3.0, libvdpau-1.4, libvdpau-va-gl-0.4.0, SDL2-2.0.12. Looking at what had changed: ffmpeg 4.2.2 on previous good systems, 4.3 and 4.3.1 on current. libva-2.7.1 on last working system and on June non-working, 2.8.0 on latest. x265 3.3 on working, 3.4 on latest (now reverted to 3.3, symlink fixed, gst-plugins-bad rebuilt) intel-vaapi-driver 2.4.0 on good, 2.4.1 on latest, now reverted to 2.4.0. xf86-video-intel 20200218 on good, 20200518 on latest, now reverted to 20200218. Before Bruce asks: I've used the same CFLAGS, CXXFLAGS throughout these builds. At this stage, this is just a request for suggestions, and a question whether parole is working on anyone's current intel machiens with integrated graphics ? TIA ĸen I would say that I was able to get Parole working, but unfortunately I'm not able to: [Current thread is 1 (Thread 0x7fb5315b2a00 (LWP 6876))] (gdb) bt #0 0x7fb5325379c2 in _XInternAtom (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis ts=onlyIfExists@entry=1, psig=psig@entry=0x7ffedf8e53b8, pidx=pidx@entry=0x7ffedf8e53b0, pn=pn@entry=0x 7ffedf8e53b4) at IntAtom.c:76 #1 0x7fb532537cfb in XInternAtom (dpy=dpy@entry=0x7fb524003ee0, name=name@entry=0x438f75 "_NET_WM_WINDOW_OPACITY_LOCKED", onlyIfExis ts=onlyIfExists@entry=1) at IntAtom.c:175 #2 0x0041f4f6 in parole_player_set_wm_opacity_hint (widget=0x1a28510 [GtkWindow]) at parole-player.c:3071 #3 parole_player_init (player=0x1e98480 [ParolePlayer]) at parole-player.c:3734 #4 0x7fb5327d1571 in g_type_create_instance (type=) at ../gobject/gtype.c:1867 #5 0x7fb5327b8125 in g_object_new_internal (class=class@entry=0x1a77ed0, params=params@entry=0x7ffedf8e56a0, n_params=n_params@entry=1) at ../gobject/gobject.c:1937 #6 0x7fb5327b9bb4 in g_object_new_valist (object_type=, first_property_name=first_property_name@entry=0x438348 "client-id", v ar_args=var_args@entry=0x7ffedf8e57e8) at ../gobject/gobject.c:2262 #7 0x7fb5327b9f0c in g_object_new (object_type=, first_property_name=first_property_name@entry=0x438348 "client-id") at ../gobject/gobject.c:1780 #8 0x0042127e in parole_player_new (client_id=0x0) at parole-player.c:3739 #9 0x004182af in main (argc=, argv=out>) at main.c:340 (gdb) When I launch Parole, it crashes with a segmentation fault. This is on my Intel system, with Mesa-20.1.5, gst-*-1.16.2 of course, and libxfce4ui-4.14.1 with the rest of the stack. I'm not sure what's causing this. Ken, you are able to get it to start at least without a segfault, right? I'll be building this on my elogind system later, will verify that it works there. Maybe it's something with the Iris driver. I'll research how to back down to i965 to see if I can fix it that way, but it's acting like its elsewhere. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Problems with xine-lib on intel and amdgpu
On 8/9/20 6:57 PM, Ken Moffat via blfs-support wrote: My second set of problems with video players ;) I know that xine has always been rather fragile, partly related to CFLAGS I use in oe of the dependencies - but a year ago those detined flags made it mostly work. With mov files and some of my own mkv and (old: fmpeg-0.7!) mp4 conversions it has tended to stutter (the picture jumps backwards). On downloads they usually play ok. With my current (late July build) on my haswell, almost everything that I try to play in xine crashes at startup. On my machine using radeon r600, my own mov files crash but everything else plays fine. On my machien with amdgpu, the mov files from my camera similarly crash, but everything else plays *until I use the xine control slider to move forward through the video* (I don't wish to spend hours looking at the files I'm using for testing). As soon as I touch the slider, xine crashes. Looking back at older systems, that behaviour with amdgpu was present in BLFS-9.1. I've now reverted the string of packages I mentioned in my post about parole (but again that has made no difference. Summary: For me xine (technically xine-ui) crashes on intel igpu, mostly works on radeon, works on amdgpu if I don't use the controls and let it play through. Again, I would be interested to hear of other people's successes. Note that one or two files (one commercial mov, two commercial wmv) do work with or without the reverts, other commercial wmv files crash. ĸen Hi Ken, I wanted to let you know that I was able to get Xine to play big_buck_bunny.mp4 properly on my Intel Skylake system (i5-6600k). I don't have any .mov files or any .wmv files sitting around here that I can use though, and I'm not sure converting would be much help here either. I did also scrub through the video using the slider, and watched it to completion. I am using Mesa-20.1.5, with the Intel Iris driver that's built into Mesa (newer Intel systems won't be able to use i965 properly, especially once the Xe series of graphics cards comes out). FFMPEG-4.3.1 is in use too. The current driver loaded on my system is "iris". I did see an error regarding libvdpau_nvidia.so when starting though, but I don't think that's related. As far as I can tell, I do have the latest version of the related packages installed on this machine. Here is my console output: renodr [ /sources ]$ xine big_buck_bunny.mp4 This is xine (X11 gui) - a free video player v0.99.12. | (c) 2000-2019 The xine Team. Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or direct ory libva info: VA-API version 1.8.0 libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null) Is it possible that it could be permissions? My intel system here is a systemd box. I am working on my elogind system at the moment to check on a couple things, and it has a Radeon in it. I'll let you know how that works, it's on my list to try next. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Beyond Linux® From Scratch (System V Edition) - Version 9.1: LSB-Tools-0.6
Hi Scott, Am Freitag, den 14.08.2020, 07:24 -0400 schrieb Scott Andrews via blfs-support: > On Fri, 14 Aug 2020 08:18:09 +0200 > Christopher Gregory via blfs-support > wrote: > > > Hello, > > > > As a general rule we do not give assistance to people who are doing > > things outside the scope of the written book instructions. We do not > > use either the debian packaging system nor that of Redhat or whatever > > they like to call themselves these days. > > > > I know from personal experience that you have to have an expert grasp > > on the various package managers to be able to successfully create a > > working package, and that is on a system that natively uses such a > > system, which lfs/blfs does not. > > > > Christopher. > > My point is that the utility that you have has errors with it. That > doesn't have anything to do with a package manager. The rngd > package does come from debian but the init script is yours, ie it is > from the LFS template. Shouldn't the utility you have install and remove > the init symlinks correctly? Or should if fail? Should the utility > that you offer work after installation? After installation what does the > method used to install it have? If it is broke, it is broke. Also you > claim LSB support/conformity but LFS does not fully conform to LSB > specs. You have to have rpm installed to do so, Also LFS does not > conform to the LSB spec on langauges, particularly Python. i think that went a bit the wrong direction. I'm pretty sure that Chris didn't meant that you have to give up if there is a hickup when using (B)LFS. Using (B)LFS is definitly in scope of the group here - especially in this channel. I assume that came from partly really annoying support cases (mostly on the IRC) where ppl sometimes come up with really strange setups, huge deviations from the book and finally the expectation that we could fix their system right in the next minute by having a look in the crystal ball. > Again I see that I am abandoned by the LFS group and I am on my own. > Should I fix this myself? And if I do should I keep the fixes to > myself? Why should I fix and post the fixes to the package if I am > always abandoned by the LFS editors/group? As far as i can see, this issue has been tracked down to a typo in the LSB package (which already is fixed by a sed in the current instructions), so your report was definitly ok - while initially it was not that clear. Whenever you have found a bug, fixes in form of patches or of sed (if the fix is not that complex) are always welcome! So, keep calm and happy LFSing ;-) -- Thomas Btw, to which chapter in LSB are you referring in terms of RPM & Python? -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Beyond Linux® From Scratch (System V Edition) - Version 9.1: LSB-Tools-0.6
On Fri, 14 Aug 2020 08:18:09 +0200 Christopher Gregory via blfs-support wrote: > > Hello, > > As a general rule we do not give assistance to people who are doing > things outside the scope of the written book instructions. We do not > use either the debian packaging system nor that of Redhat or whatever > they like to call themselves these days. > > I know from personal experience that you have to have an expert grasp > on the various package managers to be able to successfully create a > working package, and that is on a system that natively uses such a > system, which lfs/blfs does not. > > Christopher. My point is that the utility that you have has errors with it. That doesn't have anything to do with a package manager. The rngd package does come from debian but the init script is yours, ie it is from the LFS template. Shouldn't the utility you have install and remove the init symlinks correctly? Or should if fail? Should the utility that you offer work after installation? After installation what does the method used to install it have? If it is broke, it is broke. Also you claim LSB support/conformity but LFS does not fully conform to LSB specs. You have to have rpm installed to do so, Also LFS does not conform to the LSB spec on langauges, particularly Python. Again I see that I am abandoned by the LFS group and I am on my own. Should I fix this myself? And if I do should I keep the fixes to myself? Why should I fix and post the fixes to the package if I am always abandoned by the LFS editors/group? -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Beyond Linux® From Scratch (System V Edition) - Version 9.1: LSB-Tools-0.6
> Sent: Friday, August 14, 2020 at 11:38 AM
> From: "Scott Andrews via blfs-support"
>
> To: blfs-support@lists.linuxfromscratch.org
> Cc: "Scott Andrews"
> Subject: Re: [blfs-support] Beyond Linux® From Scratch (System V Edition) -
> Version 9.1: LSB-Tools-0.6
>
> On Thu, 13 Aug 2020 18:08:52 -0500
> Bruce Dubbs via blfs-support
> wrote:
>
> > On 8/13/20 4:51 PM, Scott Andrews via blfs-support wrote:
> > > I have the following issues with this package:
> > >
> > > Error! Unable to locate Requried-Start dependency localnet for
> > > script: network warning: %post(rngd-14-1.armv7hnl) scriptlet
> > > failed, exit status 2
> > >
> > > Error! Unable to locate Requried-Start dependency localnet for
> > > script: sysklogd warning: %post(rngd-14-1.armv7hnl) scriptlet
> > > failed, exit status 2
> > >
> > > hangs on:
> > >
> > > /usr/sbin/install_initd /etc/rc.d/init.d/rngd
> > >
> > > Also I believe this script name is in error:
> > >
> > > /usr/sbin/remove_intid
> >
> > This does seem to be a typo in lsb-tools file setup.py. I'll fix it.
> >
> > > Does this thing even work?
> > >
> > > cat > %{buildroot}/etc/rc.d/init.d/rngd <<- EOF
> > > #!/bin/sh
> > >
> > > ### BEGIN INIT INFO
> > > # Provides:rngd
> > > # Required-Start: mountfs
> > > # Should-Start:
> > > # Required-Stop:
> > > # Should-Stop:
> > > # Default-Start: S
> > > # Default-Stop:0 6
> > > # Short-Description: Starts rngd daemon.
> > > # Description: Starts rngd daemon.
> > > # X-LFS-Provided-By: LFS
> > > ### END INIT INFO
> > >
> > > . /lib/lsb/init-functions
> > >
> > > case "\${1}" in
> > > start)
> > > if [ -c "/dev/hwrng" ] ; then
> > > log_info_msg "Starting rng
> > > daemon..." start_daemon /usr/sbin/rngd
> > > evaluate_retval
> > > fi
> > > ;;
> > > stop)
> > > log_info_msg "Stopping rng daemon..."
> > > killproc /usr/sbin/rngd
> > > evaluate_retval
> > > ;;
> > > restart)
> > > \${0} stop
> > > sleep 1
> > > \${0} start
> > > ;;
> > > status)
> > > statusproc /usr/sbin/rngd
> > > ;;
> > > *)
> > > echo "Usage: \${0}
> > > {start|stop|restart|status}" exit 1
> > > ;;
> > > esac
> > > exit 0
> > > EOF
> > >
> >
> > Where does rngd come from? It's not in LFS. The structure is
> > similar to ours, but there are differences. For instance we do not
> > escape dollar signs .
>
> The rngd is for a hardware entropy generator ( from debian ).
> Works with most hardware. I use it on the raspberry pi platform
> as the platform includes a hardware random number generator.
>
>
> The BCM2835 chip on the Pi contains a hardware entropy source that can
> be tapped by crypto-heavy applications to improve the quality of
> randomness and might even help speed up some operations
>
> http://ftp.de.debian.org/debian/pool/main/r/rng-tools/rng-tools_2-unofficial-mt.14.orig.tar.bz2
>
>
> I am using rpm and I have a "spec file" builder that reads a text file
> and generates a spec file for a "package". Being that it is a bash file
> the dollar signs need escaped. You should ignore the escape character
> as it is not in the file.
>
>
> >
> > The localnet dependency is provided in the LFS bootscript 'localnet'.
> >
>
> Yes and it is present in /etc/rc.d/init.d
>
> That is why I question if this thing actually works.
>
> I want to create a package out of the blfs-bootscripts and then use
> this package to "turn on" the daemons from a %post section of an rpm
> package.
>
> Like this:
>
> Post='/usr/sbin/install_initd /etc/rc.d/init.d/rngd'
>
> Preun='/usr/sbin/remove_intid /etc/rc.d/init.d/rngd'
>
> That brings up the error and hangs. It will give the errors when the
> package is installed but the "post scripts" are inhibited or not run.
> Manually running causes the same issue.
>
> Chkconfig works for all init scripts ( it doesn't hang ) that don't need
> a symlink in /etc/rcS.d, it doesn't support that.
>
>
> I will test this on exim and dovecot blfs init script but I believe it
> will fail here also. As a quick test I did the following
>
> /usr/sbin/remove_intid /etc/rc.d/init.d/network
> /usr/sbin/install_initd /etc/rc.d/init.d/network
>
> Those failed also.
>
> This was from a newly built/installed system.
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>
Hello,
As a general rule we do not give assistance to people who are doing things
outside the scope of the written book instructions. We do not use either the
debian packaging system nor that of Redhat or whatever they like to call
