[packman] A segmentation fault in attempting to have the Qt window of vlc-beta-20211210.736213df13-pm153.17.1.x86_64 fully loaded in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox
Lawrence Patrick Somerville
spring2014day at gmail.com
Tue Dec 21 22:29:06 CET 2021
Especially for Masaru Nomiya, but allowing other people to read his
response:
Concerning your success in "building" a .rpm (RedHat package manager) file
for the software package vlc-beta and your success in installing and
working with the resulting vlc-beta software package, please give us some
details of your computer "environment," for example a 64-bit, openSUSE,
Leap-15.3, Linux operating system in Oracle (Corporation) VM (Virtual
Machine) VirtualBox or not and your computer's response to "inxi -G", if
you have the software package inxi installed in a Linux operating system
for the purpose of showing your computer's or "virtual "computer's"
"hardware". From which repositories did you obtain the required software
packages for an rpmbuild command? Did the command rpmbuild "accept"
package names similar to, but not exactly the same as the package names
between the parentheses of pkgconfig(...) output as "Failed build
dependencies" by "rpmbuild", for example gettext-tools in place of
gettext? I especially mention gettext-tools and gettext because I don't
know of a repository which can supply a software package named exactly
gettext for an x86_64 "architecture" in Leap 15.3.
On Mon, Dec 20, 2021 at 6:50 PM Lawrence Patrick Somerville <
spring2014day at gmail.com> wrote:
> Thank you, Olaf Hering, Jason Craig, and Masaru Nomiya for kindly taking
> some time to write some things relating to my problems with
> vlc-beta-20211210.736213df13-pm153.17.1-x86_64 and/or the software package
> vlc! After looking at my notes and Yet another Software Tool 2’s
> (YaST2’s) Software Management, Extras, Show History I could see that on
> August 18, 2021 I gratefully also had success playing a .mp4 (Moving or
> Motion Picture Experts Group, audio-layer-4) file in
> vlc-beta-20210812.fcba92731a… in my Leap-15.3 installation in VirtualBox
> 6.1.22, 6.1.24, or 6.1.26 using probably either the Linux kernel
> 5.3.18-59.16.1-preempt or 5.3.18-59.16.1-default.
>
>
> I made the switch from vlc-beta to vlc with the following commands as a
> "root" user:
>
>
> zypper refresh
>
> zypper rm vlc-beta vlc-beta-debuginfo vlc-beta-debugsource
>
> zypper refresh
>
> zypper install –repo http-ftp.gwdg.de-2f96c871 -f vlc vlc-lang vlc-codecs
> vlc-codecs-debuginfo vlc-debuginfo
>
>
> (Again http-ftp.gwdg.de-2f96c871 is the “alias” in my repository setup for
> the online Packman repository
> https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/ on
> the Internet.). In addition I was informed that the following software
> packages would also be installed: libvlc5 libvlccore9 vlc-noX vlc-qt, to
> which I entered “y” for probably “yes”. Afterward I double-clicked on the
> desktop icon I had for previously starting vlc-beta with the “target” file
> /usr/share/applications/vlc.desktop and which probably ultimately enabled
> the execution of /usr/bin/vlc. The result was that the main window of the
> VLC media player not only opened with “menu” items in it; but also I could
> gratefully play a .mp4 file in that version 3.0.16, Vetinari of the VLC
> media player with both audio and video signals!
>
>
> Masaru Nomiya wrote that he did not receive a segmentation fault while
> playing a .mp4 file in vlc-beta-20211210.736213-pm153.17.1.x86_64 in his
> computer “environment”, whatever it was. Therefore a reasonable conclusion
> may be that the segmentation fault I received in my Leap-15.3,
> in-VirtualBox-6.1.30 computer “environment” may somehow be attributable to
> my computer “environment” of my Leap-15.3 installation in VirtualBox. Olaf
> Hering reported that “any issue with upstream vlc.git#master should be
> reported directly on the upstream vlc devel mailing list.” So even though I
> have abandoned vlc-beta in favor of vlc-related software packages from the
> Packman repository, I reported my issues with vlc-beta in an
> electronic-mail letter to the electronic-mail address
> vlc-devel at videolan.org after joining the vlc-devel electronic-mailing
> list.
>
> On Sat, Dec 18, 2021 at 6:33 PM Masaru Nomiya <nomiya at galaxy.dti.ne.jp>
> wrote:
>
>> Hello,
>>
>> In the Message;
>>
>> Subject : Re: [packman] A segmentation fault in attempting to have
>> the Qt window of vlc-beta-20211210.736213df13-pm153.17.1.x86_64 fully
>> loaded in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed
>> in VirtualBox
>> Message-ID : <5a4cc332-6e68-4bb2-361f-06f7f8703639 at jacraig.com>
>> Date & Time: Sat, 18 Dec 2021 15:44:39 -0700
>>
>> [JC] == Jason Craig <os-dev at jacraig.com> has written:
>>
>> JC> On 12/17/2021 11:19, Lawrence Patrick Somerville wrote:
>> [...]
>>
>> JC> Do you really need a beta version of VLC to play an MP4? Is there
>> JC> some reason you can't just use the stable version (3.0.16)? I
>> JC> would expect the beta to not work at times, including having
>> JC> segmentation faults.
>>
>> I intalled vlc-beta-20211210.736213df13-pm153.17.1.x86_64.rpm, and
>> tested.
>> I've never got segmentation fault with playing mp4 files.
>> But, this vlc-beta can't play all mp4 files.
>> That is, it denpends on codec.
>> For example, when trying to play av1 codec video, just get no video
>> (=black screen).
>>
>> But, after recompiling vlc-beta;
>>
>> vlc-beta-20211210.736213df13-pm153.17.1.src.rpm
>>
>> with my environment, this can play all mp4 files flawlessly.
>>
>> In short, the same is true for vlc 3.0.16.
>>
>> openSUSE DOES NOT include codecs with patent issues.
>>
>> ---
>> ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp
>> ┃\/彡
>> ┗━━┛ Think.
>> -- The IBM slogan --
>>
>> _______________________________________________
>> Packman mailing list
>> Packman at links2linux.de
>> https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>
>
More information about the Packman
mailing list