From matias.nicolas.zc at gmail.com Wed Dec 1 16:45:12 2021 From: matias.nicolas.zc at gmail.com (=?UTF-8?B?TWF0w61hcyBaw7rDsWlnYQ==?=) Date: Wed, 1 Dec 2021 12:45:12 -0300 Subject: [packman] Leap 15.3 VLC Message-ID: Hi! VLC builds for Leap 15.3 have been failing since the beginning [1], and so there is no version of vlc-stable offered from packman. There has been a patch available for a long time for fixing the build with the new version of live555, and it has been used in multimedia:libs for some months [2]. Is i possible to include that patch on A_15.3-vlc to offer the latest vlc on 15.3? Thanks, Matías Zúñiga ---------- [1] https://pmbs.links2linux.de/package/show/Essentials/A_15.3-vlc [2] https://build.opensuse.org/package/view_file/multimedia:libs/vlc/vlc-get-addr-by-ref-from-getConnectionEndpointAddress.patch From aloisio at gmx.com Wed Dec 1 18:56:17 2021 From: aloisio at gmx.com (Luigi Baldoni) Date: Wed, 1 Dec 2021 18:56:17 +0100 Subject: [packman] Leap 15.3 VLC In-Reply-To: References: Message-ID: Sent: Wednesday, December 01, 2021 at 4:45 PM From: "Matías Zúñiga" > > VLC builds for Leap 15.3 have been failing since the beginning [1], and > so there is no version of vlc-stable offered from packman. > > There has been a patch available for a long time for fixing the build > with the new version of live555, and it has been used in multimedia:libs > for some months [2]. Is i possible to include that patch on A_15.3-vlc > to offer the latest vlc on 15.3? All we need is the one in openSUSE:Backports:SLE-15-SP3:Update, for some reason openSUSE:Leap:15.3:Update does not inherit from it. I'd link it myself, but I don't know how not to mess up thing in Staging. Could someone please do it? Regards From stefan.seyfried at googlemail.com Thu Dec 2 11:41:23 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Thu, 2 Dec 2021 11:41:23 +0100 Subject: [packman] Staging project howto? (was: Leap 15.3 VLC) In-Reply-To: References: Message-ID: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> On 01.12.21 18:56, Luigi Baldoni wrote: > Sent: Wednesday, December 01, 2021 at 4:45 PM > From: "Matías Zúñiga" >> >> VLC builds for Leap 15.3 have been failing since the beginning [1], and >> so there is no version of vlc-stable offered from packman. >> >> There has been a patch available for a long time for fixing the build >> with the new version of live555, and it has been used in multimedia:libs >> for some months [2]. Is i possible to include that patch on A_15.3-vlc >> to offer the latest vlc on 15.3? > > All we need is the one in openSUSE:Backports:SLE-15-SP3:Update, for some reason > openSUSE:Leap:15.3:Update does not inherit from it. > > I'd link it myself, but I don't know how not to mess up thing in Staging. > Could someone please do it? I would just do it (change the link in Essentials/A_15.3-vlc), but now that I see we have also a "Staging" project with no description, I'm not so sure I should just do it. Can someone explain how "Staging" is supposed to work? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From stefan.seyfried at googlemail.com Thu Dec 2 11:44:34 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Thu, 2 Dec 2021 11:44:34 +0100 Subject: [packman] Staging project howto? (was: Leap 15.3 VLC) In-Reply-To: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> References: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> Message-ID: <7bda5227-942c-d6ff-1d62-5e8681ae53c8@message-id.googlemail.com> On 02.12.21 11:41, Stefan Seyfried wrote: > On 01.12.21 18:56, Luigi Baldoni wrote: >> I'd link it myself, but I don't know how not to mess up thing in Staging. >> Could someone please do it? > > I would just do it (change the link in Essentials/A_15.3-vlc), but now > that I see we have also a "Staging" project with no description, I'm not > so sure I should just do it. Heck, it's broken anyway right now, so I'll just do it ;-) It can't get worse. > Can someone explain how "Staging" is supposed to work? Would still be interesting how this is intended to be used. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From aloisio at gmx.com Sun Dec 5 07:49:23 2021 From: aloisio at gmx.com (Luigi Baldoni) Date: Sun, 5 Dec 2021 07:49:23 +0100 Subject: [packman] Staging project howto? (was: Leap 15.3 VLC) In-Reply-To: <7bda5227-942c-d6ff-1d62-5e8681ae53c8@message-id.googlemail.com> References: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> <7bda5227-942c-d6ff-1d62-5e8681ae53c8@message-id.googlemail.com> Message-ID: Sent: Thursday, December 02, 2021 at 11:44 AM From: "Stefan Seyfried" > > Can someone explain how "Staging" is supposed to work? > > Would still be interesting how this is intended to be used. It's, well, a staging area to test some critical packages before they are merged into Essentials. Regards From stefan.seyfried at googlemail.com Sun Dec 5 09:33:03 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Sun, 5 Dec 2021 09:33:03 +0100 Subject: [packman] Staging project howto? (was: Leap 15.3 VLC) In-Reply-To: References: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> <7bda5227-942c-d6ff-1d62-5e8681ae53c8@message-id.googlemail.com> Message-ID: On 05.12.21 07:49, Luigi Baldoni wrote: > Sent: Thursday, December 02, 2021 at 11:44 AM > From: "Stefan Seyfried" >>> Can someone explain how "Staging" is supposed to work? >> >> Would still be interesting how this is intended to be used. > > It's, well, a staging area to test some critical packages before they are merged into Essentials. That does not answer the question ;-) Essentials/A_15.3-vlc links to openSUSE.org:$SOMEWHERE/vlc Staging/A_15.3-vlc links to Essentials/A_15.3-vlc Now how am I supposed to test something in Staging and, more important, how am I supposed to submit it then to Essentials with those links? If I just copypac it to staging and then sr to essentials, the whole linking will probably just break horribly :-) I probably would have changed the link in Staging to also point to openSUSE.org:..., but as Essentials had never built before, I just fixed it directly there. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From terjejhanssen at gmail.com Wed Dec 8 00:44:03 2021 From: terjejhanssen at gmail.com (Terje J. Hanssen) Date: Wed, 8 Dec 2021 00:44:03 +0100 Subject: [packman] [PM] ffmpeg-4 4.4-pm153.2.8 (openSUSE_Leap 15.3/x86_64) and Message-ID: <1a180aa3-60e8-7722-a05f-47d45f3316f5@gmail.com> Hello I want to suggest and request the audio pcm stuff (like pcm_bluray) which are enabled in ffmpeg for Tumbleweed, and opposite all video stuff like mpeg2/x264/x265/bluray in ffmpeg for Tumbleweed. Optional merge merge all multimedia tools in both if possible? Regards Terje J. Hanssen From Jens_Westemeier at web.de Wed Dec 8 12:19:34 2021 From: Jens_Westemeier at web.de (Jens Westemeier) Date: Wed, 8 Dec 2021 12:19:34 +0100 Subject: [packman] lxdvdrip requires pvm, which is not available Message-ID: <3bb8841f-a57a-9b41-ab1c-5e4385ad8bd1@web.de> Hello, I'm running OpenSuSE Tumbleweed on x86_44 architecture. I'm trying to install lxdvdrip-1.77-6.93.x86_64.rpm , which requires pvm. For Tumbleweed x86_64, pvm is not available in any of the (Packman / OpenSuSE) repositories, so the install fails. Greetings, Jens. From olaf at aepfle.de Wed Dec 8 21:12:41 2021 From: olaf at aepfle.de (Olaf Hering) Date: Wed, 8 Dec 2021 21:12:41 +0100 Subject: [packman] lxdvdrip requires pvm, which is not available In-Reply-To: <3bb8841f-a57a-9b41-ab1c-5e4385ad8bd1@web.de> References: <3bb8841f-a57a-9b41-ab1c-5e4385ad8bd1@web.de> Message-ID: <20211208211241.530171a5.olaf@aepfle.de> Am Wed, 8 Dec 2021 12:19:34 +0100 schrieb Jens Westemeier : > trying to install lxdvdrip See https://build.opensuse.org/request/show/610472 Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: Digitale Signatur von OpenPGP URL: From olaf at aepfle.de Wed Dec 8 21:22:29 2021 From: olaf at aepfle.de (Olaf Hering) Date: Wed, 8 Dec 2021 21:22:29 +0100 Subject: [packman] Staging project howto? (was: Leap 15.3 VLC) In-Reply-To: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> References: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> Message-ID: <20211208212229.2c06c659.olaf@aepfle.de> Am Thu, 2 Dec 2021 11:41:23 +0100 schrieb Stefan Seyfried : > Can someone explain how "Staging" is supposed to work? It is meant to verify new library versions of x264/x265 and the like actually work with the consumers. Otherwise a new SONAME is published, which breaks consumers. Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: Digitale Signatur von OpenPGP URL: From stefan.seyfried at googlemail.com Thu Dec 9 13:13:42 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Thu, 9 Dec 2021 13:13:42 +0100 Subject: [packman] Staging project howto? (was: Leap 15.3 VLC) In-Reply-To: <20211208212229.2c06c659.olaf@aepfle.de> References: <349dc2c8-28de-7e56-eb61-5ef4e873c9ae@message-id.googlemail.com> <20211208212229.2c06c659.olaf@aepfle.de> Message-ID: <94281194-f22a-ce5a-cd30-f46672e316ea@message-id.googlemail.com> On 08.12.21 21:22, Olaf Hering wrote: > Am Thu, 2 Dec 2021 11:41:23 +0100 > schrieb Stefan Seyfried : > >> Can someone explain how "Staging" is supposed to work? > > It is meant to verify new library versions of x264/x265 and the like actually work with the consumers. Otherwise a new SONAME is published, which breaks consumers. So not for Staging of VLC/mplayer/whatever, but for staging of dependencies of VLC/mplayer/...? Then this link staging/vlc -> essentials/vlc makes sense :-) Thanks, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From Jens_Westemeier at web.de Thu Dec 9 13:57:28 2021 From: Jens_Westemeier at web.de (Jens Westemeier) Date: Thu, 9 Dec 2021 13:57:28 +0100 Subject: [packman] lxdvdrip requires pvm, which is not available In-Reply-To: <20211208211241.530171a5.olaf@aepfle.de> References: <3bb8841f-a57a-9b41-ab1c-5e4385ad8bd1@web.de> <20211208211241.530171a5.olaf@aepfle.de> Message-ID: Is it probably a mistake in the spec file? - How could lxdvdrip been build without pvm available? - I installed lxdvdrip by breaking the dependencies - it works (at least for my limited use cases)! My objective is to help the Packman Team to provide clean packages. Greetings, Jens. Am 08.12.21 um 21:12 schrieb Olaf Hering: > Am Wed, 8 Dec 2021 12:19:34 +0100 > schrieb Jens Westemeier : > >> trying to install lxdvdrip > See https://build.opensuse.org/request/show/610472 > > Olaf From olaf at aepfle.de Thu Dec 9 17:53:04 2021 From: olaf at aepfle.de (Olaf Hering) Date: Thu, 9 Dec 2021 17:53:04 +0100 Subject: [packman] lxdvdrip requires pvm, which is not available In-Reply-To: References: <3bb8841f-a57a-9b41-ab1c-5e4385ad8bd1@web.de> <20211208211241.530171a5.olaf@aepfle.de> Message-ID: <20211209175304.39abde07.olaf@aepfle.de> Am Thu, 9 Dec 2021 13:57:28 +0100 schrieb Jens Westemeier : > - How could lxdvdrip been build without pvm available? There are various 'Requires:' listed in lxdvdrip.spec, which means they are required at runtime, not at build time. I think it is safe to drop 'pvm'. Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: Digitale Signatur von OpenPGP URL: From sb56637 at gmail.com Fri Dec 10 15:07:33 2021 From: sb56637 at gmail.com (S.) Date: Fri, 10 Dec 2021 09:07:33 -0500 Subject: [packman] [PM] vlc 3.0.16-4.42 (openSUSE Tumbleweed/x86_64) not installable Message-ID: <6932a31d-3190-a048-dbad-0e843cc27461@gmail.com> Hi there, VLC 3.0.16 is currently not installable from Packman on a new Tumbleweed system due to a missing dependency: > Problem: nothing provides 'libliveMedia.so.97()(64bit)' needed by the to be installed vlc-noX-3.0.16-4.42.x86_64 > Solution 1: do not install vlc-3.0.16-4.42.x86_64 > Solution 2: break vlc-noX-3.0.16-4.42.x86_64 by ignoring some of its dependencies Thanks a lot! From erefinius at gmx.de Fri Dec 10 18:03:05 2021 From: erefinius at gmx.de (Eduard Refinius) Date: Fri, 10 Dec 2021 18:03:05 +0100 Subject: [packman] mplayer dvd://1 "Bad stream state, please report as bug!" In-Reply-To: <5e2b51a6-0579-759d-23ea-d5abdbfea5d0@gmx.de> References: <5e2b51a6-0579-759d-23ea-d5abdbfea5d0@gmx.de> Message-ID: I've updated to new MPlayer-1.2.r38304-2.31.x86_64. The DVD bug still exists. # mplayer dvd://1 MPlayer 1.2.r38304-Packman-11 (C) 2000-2021 MPlayer Team Playing dvd://1. There are 24 titles on this DVD. There are 1 angles in this DVD title. libdvdread: Attempting to retrieve all CSS keys libdvdread: This can take a _long_ time, please be patient libdvdread: Get key for /VIDEO_TS/VIDEO_TS.VOB at 0x0000b050 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_01_0.VOB at 0x0000b148 libdvdread: Elapsed time 1 libdvdread: Get key for /VIDEO_TS/VTS_01_1.VOB at 0x000103e6 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_02_1.VOB at 0x003adefb libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_03_1.VOB at 0x003ae2f3 libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_04_1.VOB at 0x003ae6eb libdvdread: Elapsed time 0 libdvdread: Get key for /VIDEO_TS/VTS_05_1.VOB at 0x003aeae2 libdvdread: Elapsed time 0 libdvdread: Found 5 VTS's libdvdread: Elapsed time 1 audio stream: 0 format: ac3 (stereo) language: en aid: 128. audio stream: 1 format: ac3 (stereo) language: de aid: 129. audio stream: 2 format: ac3 (stereo) language: es aid: 130. number of audio channels on disk: 3. subtitle ( sid ): 0 language: en subtitle ( sid ): 1 language: de subtitle ( sid ): 2 language: es subtitle ( sid ): 3 language: de subtitle ( sid ): 4 language: es number of subtitles on disk: 5 Cache fill: 0.00% (0 bytes) MPEG-PS file format detected. VIDEO: MPEG2 720x576 (aspect 2) 25.000 fps 7500.0 kbps (937.5 kbyte/s) libva info: VA-API version 1.13.0 libva info: Trying to open /usr/lib64/dri/r600_drv_video.so libva info: Found init function __vaDriverInit_1_13 libva info: va_openDriver() returns 0 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family libavcodec version 58.134.100 (external) [mpeg2video @ 0x7f22203402e0]Requested frame threading with a custom get_buffer2() implementation which is not marked as thread safe. This is not supported anymore, make your callback thread-safe. Selected video codec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2) ========================================================================== ========================================================================== Trying to force audio codec driver family libmad... Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 48000 Hz, 2 ch, floatle, 192.0 kbit/6.25% (ratio: 24000->384000) Selected audio codec: [ffac3] afm: ffmpeg (FFmpeg AC-3) ========================================================================== AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample) Starting playback... Bad stream state, please report as bug! Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [vdpau] 720x576 => 768x576 Planar YV12 [zoom] [mpeg2video @ 0x7f22203402e0]ac-tex damaged at 21 15 [mpeg2video @ 0x7f22203402e0]Warning MVs not available [mpeg2video @ 0x7f22203402e0]concealing 945 DC, 945 AC, 945 MV errors in I frame Bad stream state, please report as bug! Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [vdpau] 720x576 => 768x576 Planar YV12 [zoom] A: 0.2 V: 0.2 A-V: 0.058 ct: -0.004 3/ 3 ??% ??% ??,?% 1 0 87% Bad stream state, please report as bug! A: 0.2 V: 0.2 A-V: 0.018 ct: 0.002 7/ 7 ??% ??% ??,?% 1 0 80% Bad stream state, please report as bug! A: 0.4 V: 0.4 A-V: 0.022 ct: 0.009 11/ 11 ??% ??% ??,?% 1 0 78% Bad stream state, please report as bug! A: 0.9 V: 0.5 A-V: 0.375 ct: 0.015 14/ 14 14% 50% 0.5% 2 0 73% Bad stream state, please report as bug! A: 0.9 V: 0.5 A-V: 0.361 ct: 0.019 15/ 15 13% 49% 0.5% 3 0 68% Bad stream state, please report as bug! A: 1.0 V: 0.6 A-V: 0.415 ct: 0.023 16/ 16 12% 55% 0.5% 4 0 68% Bad stream state, please report as bug! A: 1.1 V: 0.7 A-V: 0.417 ct: 0.031 18/ 18 11% 56% 0.4% 6 0 68% Bad stream state, please report as bug! A: 1.2 V: 0.8 A-V: 0.394 ct: 0.045 22/ 22 9% 54% 0.4% 9 0 66% Bad stream state, please report as bug! A: 1.3 V: 1.0 A-V: 0.369 ct: 0.054 26/ 26 8% 53% 0.3% 13 0 66% Bad stream state, please report as bug! A: 1.4 V: 1.1 A-V: 0.354 ct: 0.059 29/ 29 7% 53% 0.3% 16 0 63% Bad stream state, please report as bug! A: 1.5 V: 1.1 A-V: 0.340 ct: 0.060 30/ 30 7% 53% 0.3% 16 0 63% Bad stream state, please report as bug! A: 1.6 V: 1.2 A-V: 0.387 ct: 0.062 31/ 31 7% 56% 0.3% 17 0 63% Bad stream state, please report as bug! A: 1.6 V: 1.3 A-V: 0.381 ct: 0.064 33/ 33 6% 56% 0.3% 19 0 63% Bad stream state, please report as bug! A: 1.8 V: 1.4 A-V: 0.340 ct: 0.067 37/ 37 6% 55% 0.3% 23 0 58% Bad stream state, please report as bug! A: 1.9 V: 1.6 A-V: 0.296 ct: 0.068 41/ 41 5% 54% 0.3% 26 0 57% Bad stream state, please report as bug! A: 2.0 V: 1.7 A-V: 0.271 ct: 0.069 44/ 44 5% 54% 0.2% 28 0 57% Bad stream state, please report as bug! A: 2.0 V: 1.7 A-V: 0.239 ct: 0.070 45/ 45 5% 55% 0.2% 29 0 57% Bad stream state, please report as bug! A: 2.0 V: 1.8 A-V: 0.199 ct: 0.070 46/ 46 5% 56% 0.2% 30 0 57% Bad stream state, please report as bug! A: 2.0 V: 1.9 A-V: 0.152 ct: 0.070 48/ 48 5% 56% 0.2% 31 0 57% Bad stream state, please report as bug! A: 2.1 V: 1.9 A-V: 0.245 ct: 0.070 49/ 49 4% 56% 0.2% 32 0 39% Bad stream state, please report as bug! A: 2.2 V: 2.0 A-V: 0.191 ct: 0.071 51/ 51 4% 57% 0.2% 34 0 47% Bad stream state, please report as bug! A: 2.2 V: 2.0 A-V: 0.151 ct: 0.071 52/ 52 4% 57% 0.2% 34 0 47% Bad stream state, please report as bug! A: 2.2 V: 2.1 A-V: 0.111 ct: 0.071 53/ 53 4% 58% 0.2% 35 0 47% Bad stream state, please report as bug! A: 2.2 V: 2.1 A-V: 0.071 ct: 0.071 54/ 54 4% 58% 0.2% 35 0 47% Bad stream state, please report as bug! A: 2.3 V: 2.1 A-V: 0.209 ct: 0.071 55/ 55 4% 59% 0.2% 36 0 47% Bad stream state, please report as bug! A: 2.4 V: 2.2 A-V: 0.179 ct: 0.071 56/ 56 4% 58% 0.2% 37 0 47% Bad stream state, please report as bug! A: 2.4 V: 2.2 A-V: 0.142 ct: 0.071 57/ 57 4% 58% 0.2% 37 0 47% Bad stream state, please report as bug! A: 2.4 V: 2.3 A-V: 0.102 ct: 0.071 58/ 58 4% 59% 0.2% 38 0 47% Bad stream state, please report as bug! A: 2.4 V: 2.3 A-V: 0.062 ct: 0.071 59/ 59 4% 59% 0.2% 38 0 47% Bad stream state, please report as bug! A: 2.4 V: 2.3 A-V: 0.022 ct: 0.072 60/ 60 4% 59% 0.2% 38 0 47% Bad stream state, please report as bug! A: 2.5 V: 2.4 A-V: 0.130 ct: 0.072 61/ 61 4% 59% 0.2% 39 0 47% Bad stream state, please report as bug! A: 2.5 V: 2.4 A-V: 0.118 ct: 0.072 62/ 62 4% 59% 0.2% 39 0 47% Bad stream state, please report as bug! A: 2.5 V: 2.5 A-V: 0.094 ct: 0.072 63/ 63 4% 59% 0.2% 40 0 47% Bad stream state, please report as bug! A: 2.5 V: 2.5 A-V: 0.054 ct: 0.072 64/ 64 4% 60% 0.2% 40 0 44% From stefan.seyfried at googlemail.com Fri Dec 10 18:46:37 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Fri, 10 Dec 2021 18:46:37 +0100 Subject: [packman] [PM] vlc 3.0.16-4.42 (openSUSE Tumbleweed/x86_64) not installable In-Reply-To: <6932a31d-3190-a048-dbad-0e843cc27461@gmail.com> References: <6932a31d-3190-a048-dbad-0e843cc27461@gmail.com> Message-ID: <33af0659-a791-2427-76b8-6f342bd97e74@message-id.googlemail.com> On 10.12.21 15:07, S. wrote: > Hi there, VLC 3.0.16 is currently not installable from Packman on a new > Tumbleweed system due to a missing dependency: > >> Problem: nothing provides 'libliveMedia.so.97()(64bit)' needed by the >> to be installed vlc-noX-3.0.16-4.42.x86_64 works for me. Now it requires libliveMedia102, probably you hit the short timeframe until the rebuilt package was published ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From masterpatricko at gmail.com Fri Dec 10 19:31:59 2021 From: masterpatricko at gmail.com (Tejas Guruswamy) Date: Fri, 10 Dec 2021 12:31:59 -0600 Subject: [packman] packman.inode.at keeps giving 403 error In-Reply-To: References: <0ec8edc6-e2ba-59dc-8e45-e03fb9c14ffe@jweber-online.de> <3420054.AWBIRObb4E@komascript.de> <20211007083010.4uvzmv5qy6bpoul4@schiffbauer.net> Message-ID: <19a67532-7480-115c-6cf8-6ddcf5966c38@gmail.com> On 07/10/2021 12:29, Tejas Guruswamy wrote: > On 07/10/2021 03:30, Marc Schiffbauer wrote: >> When you try a dedicated file (no browsing), do you still get a 403? >> If yes, I will contact them... -Marc > > Yes, it is a 403 using all user agents I can think off, including ZYpp > itself. I think the entire mirror really is dead. > >> curl > http://packman.inode.at/suse/openSUSE_Tumbleweed/Essentials/repodata/repomd.xml > > >         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > > >  403 - Forbidden > > >  

403 - Forbidden

> > > > Related sites like mirror.inode.at are also down for a long time. > > T I'm sorry to keep bringing this up but it is *still* a problem and no-one outside of the packman admins can do anything about it so all I can do is email. inode.at is still listed as a mirror at http://packman.links2linux.org/mirrors packman.repo still refers to inode.at -- on *all* mirrors, so even if you do 'zypper ar gwdg.de/.../packman.repo' you actually get inode.at T From olaf at aepfle.de Fri Dec 10 22:33:15 2021 From: olaf at aepfle.de (Olaf Hering) Date: Fri, 10 Dec 2021 22:33:15 +0100 Subject: [packman] mplayer dvd://1 "Bad stream state, please report as bug!" In-Reply-To: References: <5e2b51a6-0579-759d-23ea-d5abdbfea5d0@gmx.de> Message-ID: <20211210223315.19d8d249.olaf@aepfle.de> Fri, 10 Dec 2021 18:03:05 +0100 Eduard Refinius : > MPlayer This package is unmaintained. Apparently you rely on it, would you like to maintain it? Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: Digitale Signatur von OpenPGP URL: From tmoldt at gmail.com Sat Dec 11 08:27:13 2021 From: tmoldt at gmail.com (Thomas Moldt) Date: Sat, 11 Dec 2021 08:27:13 +0100 Subject: [packman] packman.inode.at keeps giving 403 error In-Reply-To: <19a67532-7480-115c-6cf8-6ddcf5966c38@gmail.com> References: <0ec8edc6-e2ba-59dc-8e45-e03fb9c14ffe@jweber-online.de> <3420054.AWBIRObb4E@komascript.de> <20211007083010.4uvzmv5qy6bpoul4@schiffbauer.net> <19a67532-7480-115c-6cf8-6ddcf5966c38@gmail.com> Message-ID: Well, last week I managed to add the packman repository and install vlc and the codecs on a newly installed Leap 15.3 as described here: https://en.opensuse.org/SDB:Installing_codecs_from_Packman_repositories#Option_2:_Zypper I did not observe any issues. Cheers, Thomas Am 10.12.21 um 19:31 schrieb Tejas Guruswamy: > On 07/10/2021 12:29, Tejas Guruswamy wrote: >> On 07/10/2021 03:30, Marc Schiffbauer wrote: >>> When you try a dedicated file (no browsing), do you still get a 403? >>> If yes, I will contact them... -Marc >> >> Yes, it is a 403 using all user agents I can think off, including ZYpp >> itself. I think the entire mirror really is dead. >> >>> curl >> http://packman.inode.at/suse/openSUSE_Tumbleweed/Essentials/repodata/repomd.xml >> >> >> >         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >> >> >>  403 - Forbidden >> >> >>  

403 - Forbidden

>> >> >> >> Related sites like mirror.inode.at are also down for a long time. >> >> T > > > I'm sorry to keep bringing this up but it is *still* a problem and > no-one outside of the packman admins can do anything about it so all I > can do is email. > > inode.at is still listed as a mirror at > http://packman.links2linux.org/mirrors > packman.repo still refers to inode.at -- on *all* mirrors, so even if > you do 'zypper ar gwdg.de/.../packman.repo' you actually get inode.at > > T > > > _______________________________________________ > Packman mailing list > Packman at links2linux.de > https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman From masterpatricko at gmail.com Sat Dec 11 17:58:24 2021 From: masterpatricko at gmail.com (Tejas Guruswamy) Date: Sat, 11 Dec 2021 10:58:24 -0600 Subject: [packman] packman.inode.at keeps giving 403 error In-Reply-To: References: <0ec8edc6-e2ba-59dc-8e45-e03fb9c14ffe@jweber-online.de> <3420054.AWBIRObb4E@komascript.de> <20211007083010.4uvzmv5qy6bpoul4@schiffbauer.net> <19a67532-7480-115c-6cf8-6ddcf5966c38@gmail.com> Message-ID: On 11/12/2021 01:27, Thomas Moldt wrote: > Am 10.12.21 um 19:31 schrieb Tejas Guruswamy: >> On 07/10/2021 12:29, Tejas Guruswamy wrote: >>> On 07/10/2021 03:30, Marc Schiffbauer wrote: >>>> When you try a dedicated file (no browsing), do you still get a >>>> 403? If yes, I will contact them... -Marc >>> >>> Yes, it is a 403 using all user agents I can think off, including >>> ZYpp itself. I think the entire mirror really is dead. >>> >>>> curl >>> http://packman.inode.at/suse/openSUSE_Tumbleweed/Essentials/repodata/repomd.xml >>> >>> >>> >>         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> >>> >>> >>>  403 - Forbidden >>> >>> >>>  

403 - Forbidden

>>> >>> >>> >>> Related sites like mirror.inode.at are also down for a long time. >>> >>> T >> >> >> I'm sorry to keep bringing this up but it is *still* a problem and >> no-one outside of the packman admins can do anything about it so all >> I can do is email. >> >> inode.at is still listed as a mirror at >> http://packman.links2linux.org/mirrors >> packman.repo still refers to inode.at -- on *all* mirrors, so even if >> you do 'zypper ar gwdg.de/.../packman.repo' you actually get inode.at >> >> T > Well, last week I managed to add the packman repository and install > vlc and the codecs on a newly installed Leap 15.3 as described here: > https://en.opensuse.org/SDB:Installing_codecs_from_Packman_repositories#Option_2:_Zypper > I did not observe any issues. > > Cheers, > Thomas Because those instructions have been updated to specifically avoid using the broken mirror and packman.repo files. T From marc at links2linux.de Sun Dec 12 09:20:39 2021 From: marc at links2linux.de (Marc Schiffbauer) Date: Sat, 11 Dec 2021 22:20:39 -1000 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <20211025052338.GA12291@monopoli.naic.edu> References: <20211025052338.GA12291@monopoli.naic.edu> Message-ID: <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> Hi Giacomo, we should really create a new gpg key for the repo. @Stefan: What do you think? -Marc * Giacomo Comes schrieb am 24.10.21 um 19:23 Uhr: > Hi, > On Leap 15.3 if I run: > rpm -K > the output is usually: > digests signatures OK > However if I do that with any rpm from the packman repository > the output is: > digests SIGNATURES NOT OK > This was not happening before but it started recently after > the package rpm was updated to version 4.14.3-40.1 > The reason is that since that version the packages contains a backport > patch meant to fix the following bug: > https://bugzilla.opensuse.org/show_bug.cgi?id=1185299 > and now all the rpms from packman fails the rpm -K test. > > The consequence is that when I try to build locally an rpm > using the command 'build' and the rpm I'm building has: > BuildRequires: > in the spec file, the build process fails with the error message: > rpm verify failed > > For the moment I overcome the problem by passing the option --nosignature to > the command init_buildsystem > > However I was wondering if there is any plan to fix the rpms in the packman repository. > > Regards, > Giacomo > > _______________________________________________ > Packman mailing list > Packman at links2linux.de > https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 From marc at links2linux.de Sun Dec 12 09:25:42 2021 From: marc at links2linux.de (Marc Schiffbauer) Date: Sat, 11 Dec 2021 22:25:42 -1000 Subject: [packman] packman.inode.at keeps giving 403 error In-Reply-To: References: Message-ID: <20211212082542.nyo74xd7twr6iggi@schiffbauer.net> I now removed inode.at from the mirrors list -Marc * Carlos E. R. schrieb am 26.04.21 um 01:07 Uhr: > > > Hi, > > I got asked why people get, since weeks: > > Permission to access 'http://packman.inode.at/suse/openSUSE_Leap_15.2/repodata/repomd.xml' denied. > > I checked with firefox, and the whole: > > http://packman.inode.at/ > > gives: > > 403 - Forbidden > > > Do you know what is going on? > > -- > Cheers / Saludos, > > Carlos E. R. > (from 15.2 x86_64 at Telcontar) > > -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From farcus at gmx.com Sun Dec 12 09:38:56 2021 From: farcus at gmx.com (Mark Fairbairn) Date: Sun, 12 Dec 2021 21:38:56 +1300 Subject: [packman] packman.inode.at keeps giving 403 error In-Reply-To: <20211212082542.nyo74xd7twr6iggi@schiffbauer.net> References: <20211212082542.nyo74xd7twr6iggi@schiffbauer.net> Message-ID: <3e234941-0926-579a-e884-a33cfd4e3be9@gmx.com> While you are at it . . . Perhaps also remove http://ftp.twaren.net/Linux/Packman/ It hasn't had an update in about four years. On 12/12/21 21:25, Marc Schiffbauer wrote: > I now removed inode.at from the mirrors list > > -Marc > > * Carlos E. R. schrieb am 26.04.21 um 01:07 Uhr: >> >> Hi, >> >> I got asked why people get, since weeks: >> >> Permission to access 'http://packman.inode.at/suse/openSUSE_Leap_15.2/repodata/repomd.xml' denied. >> >> I checked with firefox, and the whole: >> >> http://packman.inode.at/ >> >> gives: >> >> 403 - Forbidden >> >> >> Do you know what is going on? >> >> -- >> Cheers / Saludos, >> >> Carlos E. R. >> (from 15.2 x86_64 at Telcontar) >> >> > > _______________________________________________ > Packman mailing list > Packman at links2linux.de > https://lists.links2linux.de/cgi-bin/mailman/listinfo/packman From marc at links2linux.de Sun Dec 12 09:57:31 2021 From: marc at links2linux.de (Marc Schiffbauer) Date: Sat, 11 Dec 2021 22:57:31 -1000 Subject: [packman] packman.inode.at keeps giving 403 error In-Reply-To: <3e234941-0926-579a-e884-a33cfd4e3be9@gmx.com> References: <20211212082542.nyo74xd7twr6iggi@schiffbauer.net> <3e234941-0926-579a-e884-a33cfd4e3be9@gmx.com> Message-ID: <20211212085731.qjbncuyhcrqbwr6l@schiffbauer.net> * Mark Fairbairn schrieb am 11.12.21 um 22:38 Uhr: > While you are at it . . . > Perhaps also remove > http://ftp.twaren.net/Linux/Packman/ > It hasn't had an update in about four years. Ouch... done, thank! -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 From stefan.seyfried at googlemail.com Sun Dec 12 11:04:23 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Sun, 12 Dec 2021 11:04:23 +0100 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> Message-ID: <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> On 12.12.21 09:20, Marc Schiffbauer wrote: > Hi Giacomo, > > we should really create a new gpg key for the repo. > > @Stefan: What do you think? Another Stefan here, but still ;-) Changing the key should be advertised in advance, in prominent places. Really the best solution (if possible) would be if the new key could be signed by the old one and thus automatically accepted by zypper et al. I have no idea if this is even possible, nor how to implement it in OBS. A plain "osc signkey --create" will simply wipe the old one and create a new key, but that would cause a bad user experience :-( Maybe we should ask security-team at suse.de for help on how to handle this best? They surely must be prepared for updating a key. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From robin.listas at telefonica.net Sun Dec 12 11:55:33 2021 From: robin.listas at telefonica.net (Carlos E. R.) Date: Sun, 12 Dec 2021 11:55:33 +0100 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> Message-ID: On 12/12/2021 11.04, Stefan Seyfried wrote: > On 12.12.21 09:20, Marc Schiffbauer wrote: >> Hi Giacomo, >> >> we should really create a new gpg key for the repo. >> >> @Stefan: What do you think? > > Another Stefan here, but still ;-) > > Changing the key should be advertised in advance, in prominent places. > > Really the best solution (if possible) would be if the new key could be > signed by the old one and thus automatically accepted by zypper et al. > I have no idea if this is even possible, nor how to implement it in OBS. > A plain "osc signkey --create" will simply wipe the old one and create a > new key, but that would cause a bad user experience :-( I think you sign a key the same way you do for email. You must have both keys in a ring, and use the pgp command to sign one with the other. You need the private key of the old one to do this. And then, you upload this change to the key servers to propagate. something like: gpg2 --edit-key somekey sign -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From mirppc at gmail.com Sun Dec 12 01:47:34 2021 From: mirppc at gmail.com (Patrick Finie) Date: Sat, 11 Dec 2021 16:47:34 -0800 Subject: [packman] jacobs university mirror Message-ID: Is the Jacobs university mirror going to be back up? it was one of the best mirrors for my location and the only packman mirror i could use when at opensuse events at USC, UCLA or going to my local colleges. Any update would be appreciated. Mirppc on discord Mir on libera.chat From mirppc at gmail.com Sun Dec 12 01:48:53 2021 From: mirppc at gmail.com (Patrick Finie) Date: Sat, 11 Dec 2021 16:48:53 -0800 Subject: [packman] Update to the site's contact information Message-ID: Earlier this year freenode imploded and the official packman irc channel moved to liber.chat. Sadly the information on the website still points to freenode which is very problematic. From jsj at jsj.dyndns.org Sun Dec 12 13:04:11 2021 From: jsj at jsj.dyndns.org (Stefan Botter) Date: Sun, 12 Dec 2021 13:04:11 +0100 Subject: [packman] jacobs university mirror In-Reply-To: References: Message-ID: <03ed9a6317885519b060447b21e831206c159943.camel@jsj.dyndns.org> Hi Patrick, Am Samstag, den 11.12.2021, 16:47 -0800 schrieb Patrick Finie: > Is the Jacobs university mirror going to be back up? it was one of > the best mirrors for my location and the only packman mirror i could > use when at opensuse events at USC, UCLA or going to my local > colleges. > > Any update would be appreciated. I was promised a return of this machine. There are certain formalities to go through - create secure access for me and recovery of data, and I am still waiting for to go ahead. I will try asking again. Greetings, Stefan -- Stefan Botter zu Hause Bremen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From jsj at jsj.dyndns.org Sun Dec 12 13:20:55 2021 From: jsj at jsj.dyndns.org (Stefan Botter) Date: Sun, 12 Dec 2021 13:20:55 +0100 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> Message-ID: <252bba9c2c0e81ec9c0f990168b7e4eea2af9305.camel@jsj.dyndns.org> Hi Marc, Am Samstag, den 11.12.2021, 22:20 -1000 schrieb Marc Schiffbauer: > we should really create a new gpg key for the repo. > > @Stefan: What do you think? I am all for it! PMBS is not in the way, as you are re-signing all packages on the distribution host. As far as I understand, you have to create a new key, publish that with the Essentials/rpmkey-packman package a few days ahead of changing the signing step to the new key. Of course Stefan and Carlos have more insight in the key handling. Lets talk PM about any changes needed. As for the mirror issues, we should have a mirrorbrain somewhere to ease the problems with inconsistent, outdated or disappearing mirrors. Unfortunately my hosting machine is at capacity with both RAM and disk, so I cannot set up such a site. Greetings, Stefan -- Stefan Botter zu Hause Bremen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From comes at naic.edu Sun Dec 12 14:44:59 2021 From: comes at naic.edu (Giacomo Comes) Date: Sun, 12 Dec 2021 09:44:59 -0400 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> Message-ID: <20211212134459.GA30243@monopoli.naic.edu> On Sun, Dec 12, 2021 at 11:55:33AM +0100, Carlos E. R. wrote: > On 12/12/2021 11.04, Stefan Seyfried wrote: > >On 12.12.21 09:20, Marc Schiffbauer wrote: > >>Hi Giacomo, > >> > >>we should really create a new gpg key for the repo. > >> > >>@Stefan: What do you think? > > > >Another Stefan here, but still ;-) > > > >Changing the key should be advertised in advance, in prominent places. > > > >Really the best solution (if possible) would be if the new key could be > >signed by the old one and thus automatically accepted by zypper et al. > >I have no idea if this is even possible, nor how to implement it in OBS. A > >plain "osc signkey --create" will simply wipe the old one and create a new > >key, but that would cause a bad user experience :-( > > > I think you sign a key the same way you do for email. > > You must have both keys in a ring, and use the pgp command to sign one with > the other. You need the private key of the old one to do this. And then, you > upload this change to the key servers to propagate. > > something like: > > gpg2 --edit-key somekey sign I have more information about the key problem. Some time ago the package rpm in opensuse was patched with a pgp hardening changes from upstream (bsc#1185299) This caused a problem with the current packman key. However, the key itselt is not bad. It's just that the rpm code before patching and the code after patching will consider the same key as different. The solution for me was to delete the packman key (rpm -e gpg-pubkey-1abd1afb-54176598) and then, when asked, reimport the key. After that, everything worked fine. Giacomo From marc at links2linux.de Mon Dec 13 09:35:02 2021 From: marc at links2linux.de (Marc Schiffbauer) Date: Sun, 12 Dec 2021 22:35:02 -1000 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> Message-ID: <20211213083502.4d5wfzqkgnodti6q@schiffbauer.net> * Stefan Seyfried schrieb am 12.12.21 um 00:04 Uhr: > On 12.12.21 09:20, Marc Schiffbauer wrote: > > Hi Giacomo, > > > > we should really create a new gpg key for the repo. > > > > @Stefan: What do you think? > > Another Stefan here, but still ;-) > > Changing the key should be advertised in advance, in prominent places. > > Really the best solution (if possible) would be if the new key could be > signed by the old one and thus automatically accepted by zypper et al. > I have no idea if this is even possible, nor how to implement it in OBS. A > plain "osc signkey --create" will simply wipe the old one and create a new > key, but that would cause a bad user experience :-( > > Maybe we should ask security-team at suse.de for help on how to handle this > best? They surely must be prepared for updating a key. The signatures, that obs is attaching to the packages are not the same that the package sin the repo are signed with: All packages are being resigned in the release process to the mirrors. But yes, signing a new key with the old one is a good idea. -Marc -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 From marc at links2linux.de Mon Dec 13 09:43:07 2021 From: marc at links2linux.de (Marc Schiffbauer) Date: Sun, 12 Dec 2021 22:43:07 -1000 Subject: [packman] Update to the site's contact information In-Reply-To: References: Message-ID: <20211213084307.dbcgffnk7rwes3uf@schiffbauer.net> * Patrick Finie schrieb am 11.12.21 um 14:48 Uhr: > Earlier this year freenode imploded and the official packman irc channel > moved to liber.chat. Sadly the information on the website still points to > freenode which is very problematic. Thanks! fixed... -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 From marc at links2linux.de Mon Dec 13 09:48:43 2021 From: marc at links2linux.de (Marc Schiffbauer) Date: Sun, 12 Dec 2021 22:48:43 -1000 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <20211212134459.GA30243@monopoli.naic.edu> References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> <20211212134459.GA30243@monopoli.naic.edu> Message-ID: <20211213084843.zz5uagho5jv2qema@schiffbauer.net> * Giacomo Comes schrieb am 12.12.21 um 03:44 Uhr: > I have more information about the key problem. > > Some time ago the package rpm in opensuse was patched with > a pgp hardening changes from upstream (bsc#1185299) > This caused a problem with the current packman key. > However, the key itselt is not bad. It's just that > the rpm code before patching and the code after patching > will consider the same key as different. > > The solution for me was to delete the packman key > (rpm -e gpg-pubkey-1abd1afb-54176598) and then, > when asked, reimport the key. > > After that, everything worked fine. Thanks for that! So I guess we could leave the current key in place. Users just need to know the required steps. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 From manfred.e at freenet.de Mon Dec 13 10:53:27 2021 From: manfred.e at freenet.de (Manfred Eifler) Date: Mon, 13 Dec 2021 10:53:27 +0100 Subject: [packman] kim Message-ID: <5529863.DvuYhMxLoT@pc1a> Guten Morgen, ich vermisse kim für Leap 15.3. Für 15.2 ist es noch da. Würde das jemand für die 15.3 packen? -- Viele Grüße und bleibt ungeimpft Manfred ------------------- openSUSE Leap 15.3 KDE-Plasma 5.23.4 KDE-Frameworks: 5.89.0 QT 5.15.2 Kernel-5.3.18-59.37-default From stefan.seyfried at googlemail.com Mon Dec 13 21:03:10 2021 From: stefan.seyfried at googlemail.com (Stefan Seyfried) Date: Mon, 13 Dec 2021 21:03:10 +0100 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: <20211213083502.4d5wfzqkgnodti6q@schiffbauer.net> References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> <20211213083502.4d5wfzqkgnodti6q@schiffbauer.net> Message-ID: Hi Marc, On 13.12.21 09:35, Marc Schiffbauer wrote: > * Stefan Seyfried schrieb am 12.12.21 um 00:04 Uhr: >> Really the best solution (if possible) would be if the new key could be >> signed by the old one and thus automatically accepted by zypper et al. >> I have no idea if this is even possible, nor how to implement it in OBS. A >> plain "osc signkey --create" will simply wipe the old one and create a new >> key, but that would cause a bad user experience :-( >> >> Maybe we should ask security-team at suse.de for help on how to handle this >> best? They surely must be prepared for updating a key. > > > The signatures, that obs is attaching to the packages are not the same > that the package sin the repo are signed with: All packages are being > resigned in the release process to the mirrors. Ok, this at least saves us from having to teach OBS to use a very custom key ;-) > But yes, signing a new key with the old one is a good idea. ...only if the tools (zypper, yast, rpm) actually accept this "new key signed with old one" without crazy warnings ;-) If they still complain, then we do not win too much (but also will not lose anything) by signing the new key with te old one. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman From robin.listas at telefonica.net Mon Dec 13 23:02:39 2021 From: robin.listas at telefonica.net (Carlos E. R.) Date: Mon, 13 Dec 2021 23:02:39 +0100 Subject: [packman] digests SIGNATURES NOT OK In-Reply-To: References: <20211025052338.GA12291@monopoli.naic.edu> <20211212082039.u4rcjkqrcx56nija@schiffbauer.net> <76534de4-e443-86cc-0407-dacbc90a51ff@message-id.googlemail.com> <20211213083502.4d5wfzqkgnodti6q@schiffbauer.net> Message-ID: <035868ad-a5e7-934f-4478-6a27b1f46776@telefonica.net> On 13/12/2021 21.03, Stefan Seyfried wrote: > Hi Marc, > > On 13.12.21 09:35, Marc Schiffbauer wrote: >> * Stefan Seyfried schrieb am 12.12.21 um 00:04 Uhr: ... >> But yes, signing a new key with the old one is a good idea. > > ...only if the tools (zypper, yast, rpm) actually accept this "new key > signed with old one" without crazy warnings ;-) > > If they still complain, then we do not win too much (but also will not > lose anything) by signing the new key with te old one. It depends on zypper keeping a chain of trust like "normal" key signing which is done by gpg and stored in ~/.gnupg/, maybe file trustdb.gpg, I'm not sure. This might be somewhere in /var/lib/rpm/* (now /usr/lib/sysimage/rpm), but I don't know if it does and I suspect it doesn't. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From erefinius at gmx.de Tue Dec 14 14:10:20 2021 From: erefinius at gmx.de (Eduard Refinius) Date: Tue, 14 Dec 2021 14:10:20 +0100 Subject: [packman] mplayer dvd://1 "Bad stream state, please report as bug!" In-Reply-To: <20211210223315.19d8d249.olaf@aepfle.de> References: <5e2b51a6-0579-759d-23ea-d5abdbfea5d0@gmx.de> <20211210223315.19d8d249.olaf@aepfle.de> Message-ID: <1eae7c61-1e36-1272-3c53-02af8511fd02@gmx.de> > This package is unmaintained.Thank you for information! > Apparently you rely on it, would you like to maintain it? I'm not able to, because I don't have the skills. From writer at provocateach.com Wed Dec 15 07:36:41 2021 From: writer at provocateach.com (Noah from ProvocaTeach) Date: Tue, 14 Dec 2021 22:36:41 -0800 Subject: [packman] Missing package: obs-studio-27.1.3-1.20 on openSUSE Tumbleweed x86_64 Message-ID: <01cc1739-c0d9-469d-aa06-e873f49b7bca@www.fastmail.com> Hello, I was trying to update my packages on openSUSE Tumbleweed (x86_64 architecture) and it said an update was available for OBS Studio. But then Zypper wasn’t able to find the package on the Internet: Retrieving: obs-studio-27.1.3-1.20.x86_64.rpm ........................................................................................................................[not found] File './Multimedia/x86_64/obs-studio-27.1.3-1.20.x86_64.rpm' not found on medium 'http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving: obs-studio-27.1.3-1.20.x86_64.rpm ...............................................................................................................................................................................................................[not found] File './Multimedia/x86_64/obs-studio-27.1.3-1.20.x86_64.rpm' not found on medium 'http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/' Abort, retry, ignore? [a/r/i/...? shows all options] (a): I checked the Web page on this package , and I wasn’t able to find an up-to-date version for the x86_64 architecture on Tumbleweed. Are there any plans to add this package soon? Best wishes, Noah G. From writer at provocateach.com Wed Dec 15 07:40:28 2021 From: writer at provocateach.com (Noah from ProvocaTeach) Date: Tue, 14 Dec 2021 22:40:28 -0800 Subject: [packman] Missing package: obs-studio-27.1.3-1.20 on openSUSE Tumbleweed x86_64 In-Reply-To: <01cc1739-c0d9-469d-aa06-e873f49b7bca@www.fastmail.com> References: <01cc1739-c0d9-469d-aa06-e873f49b7bca@www.fastmail.com> Message-ID: <107cc929-2701-4224-9686-9a2d0f9f8751@www.fastmail.com> Hello, please disregard this message. I realize what happened – you guys upped the version while I was running the update. Thanks! On Tue, Dec 14, 2021, at 22:36, Noah from ProvocaTeach wrote: > Hello, > > I was trying to update my packages on openSUSE Tumbleweed (x86_64 architecture) and it said an update was available for OBS Studio. But then Zypper wasn’t able to find the package on the Internet: > > Retrieving: obs-studio-27.1.3-1.20.x86_64.rpm ........................................................................................................................[not found] > File './Multimedia/x86_64/obs-studio-27.1.3-1.20.x86_64.rpm' not found on medium 'http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/' > Abort, retry, ignore? [a/r/i/...? shows all options] (a): r > Retrieving: obs-studio-27.1.3-1.20.x86_64.rpm ...............................................................................................................................................................................................................[not found] > File './Multimedia/x86_64/obs-studio-27.1.3-1.20.x86_64.rpm' not found on medium 'http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/' > Abort, retry, ignore? [a/r/i/...? shows all options] (a): > > I checked the Web page on this package , and I wasn’t able to find an up-to-date version for the x86_64 architecture on Tumbleweed. Are there any plans to add this package soon? > > Best wishes, > Noah G. From spring2014day at gmail.com Wed Dec 15 22:34:53 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Wed, 15 Dec 2021 16:34:53 -0500 Subject: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox Message-ID: Hello. I have not knowingly received a reply by electronic mail (e-mail) from anyone on the e-mailing list of packman at links2linux.de to my November 12, 2021 e-mail letter sent to that e-mail address. Question: Am I supposed to join that e-mailing list of packman at links2linux.de in order for me to receive such a reply? I suppose not. A disadvantage of my joining that e-mailing list is that if I would join it I might receive lots of e-mail about matters irrelevant to my current computer-software problems. Here I present additional data and more diagnostic information than I presented on November 12, 2021, which hopefully will "spark" more ideas helpful to me among one or more expert readers of my electronic mail than following my November 12, 2021 e-mail letter. In a 64-bit, openSUSE, Leap-15.3, Linux operating system, which is installed as a so-called "guest" in Virtual "Machine" (VM) in Oracle (Corporation) VM VirtualBox, which in turn is installed in my so-called "host," Windows 10 Home Edition operating system, I have gratefully had success in the playing of a .mp4 (Moving or Motion Picture Experts Group, audio layer-4) file in vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 with the Linux kernel 5.3.18-59.27.1-default. But in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 I had only the audio signals and not the video signals in the playing of that video. And later in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 with the Linux kernel 5.3.18-59.37.2-default I attempted to open vlc-beta, or the Video Local Area Network (LAN) Client (VLC) multimedia player (VLC) by double-clicking on a desktop shortcut for it, but saw its main window only for a very brief period of time, accompanied probably a short time later with the message "Segmentation fault (core dumped)"; so I could not even attempt to play that .mp4 file normally with this version of vlc-beta when using its probably default, Qt interface. I at least began the process of preparation toward having a .rpm (RedHat package manager) file "built" for my Leap-15.3 installation using downloaded source code for vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1 or 20211104.b9e50b090c-pm153.10.1.16.1.x86_64 and an rpmbuild... command, but failed in that effort due to "Failed build dependencies". I started that kind of process also with vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 by starting to obtain some software packages missing in my Leap-15.3 installation. And that process for my Leap-15.3 installation not only required a list of some tens of software packages; but I discovered two other difficult factors: 1) The software package mentioned between the parentheses of a pkgconfig(...) "response" following an rpmbuild... command is sometimes different than the name of a software package I could obtain from an openSUSE or Packman online repository. And I don't know for certain if I can even obtain the exact package "requested" from somewhere on the Internet. 2) But in a "user-friendly" way it might be that sometimes rpmbuild might "accept" packages with names similar, but not exactly the same as the names of the packages between the parentheses of pkgconfig(...) (For example, I installed libnfs13, which has a name slightly different from the name of the required package libnfs for rpmbuild....). But if similar names would not be "accepted" by rpmbuild and I could not obtain the exact software packages requested, in that case I don't know what I should do to "satisfy" the "rpmbuild" computer code. Rather than try to find and obtain some tens of software packages required for the successful execution of an rpmbuild command using the downloaded source code for vlc-beta-20211206.07ed287157-pm153.16.1.x86_64, I read that it is possible to have such a .rpm file "built" online using the openSUSE Build Service of the Open Build Service (OBS, https://build.opensuse.org/ on the Internet). It seems to be reported that such "building" could ease the action of obtaining the software packages "required" by rpmbuild. But I have not learned how to use OBS or tried it to make a .rpm file. But even if I would be successful in somehow "building" such a .rpm file for vlc-beta-20211206.07ed287157-pm153.16.1.x86_64, it is possible that it might not eliminate the segmentation faults I have encountered, especially if it would be a change in the vlc-beta source code which would be needed to eliminate such segmentation faults. Although the .rpm installation file for version 20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 of the software package vlc-beta is probably unfortunately no longer available from http://packman.links2linux.de/package/vlc-beta or https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/Multimedia/x86_64/, fortunately I have the capability to restore my Leap-15.3 installation, including the installation of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 in it, from a previously written backup of the data on my Dell notebook computer's internal hard-disk drive. For a period of time I was able to "lock" or protect that version of vlc-beta, which has worked well for me, from being updated to a newer version of vlc-beta, which thus far has not worked for me when using its Qt interface. However, considering the likely future updates to some software packages and the Linux kernel elsewhere in my Leap-15.3 installation, the arrangement of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 working well with a number of newer software packages might at some time in the future no longer be a mutually well-working arrangement for me. At least by the time of an upgrade from version 15.3 to version 15.4 of Leap on or after June 8, 2022, there could be a possible software mismatch, since according to http://packman.links2linux.de/package/vlc-beta the version vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 saved in my hard-disk drive's backup data is reported to be suitable for a Leap-15.3 installation. So I have been attempting to find some way to make the version of vlc-beta released to the public on December 6, 2021, namely vlc-beta-20211206.07ed287157-pm153.16.1.x86_64, work in my Leap-15.3 installation. And the hope would be that after having made it to work in my Leap-15.3 installation that making later versions of vlc-beta to work in my Leap-15.3 installation might be easier than now for vlc-beta-20211206.07ed287157-pm153.16.1.x86_64. I have been able to play a .mp4 file in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 using a command of the form "vlc -I dummy FILE_NAME.mp4" in a directory containing the file with a name of the form FILE_NAME.mp4. Otherwise entering the command "vlc" or "gdb vlc", using the GNU's Not Unix (GNU) debugger (gdb), in the directory /usr/bin resulted in the main window for vlc-beta opening, but with most of it transparent; then very soon afterward I received the message "Segmentation fault (core dumped)". Those same two things occurred after I entered the command "vlc -I qt" in the directory /usr/bin. So my current problem is associated with Qt and the main window of vlc-beta, not the so-called "dummy interface" of vlc-beta. If the "menu" items and/or software controls on vlc-beta's main window are considered plugins, then it appears to me that the problem is in displaying those items on vlc-beta's main window. But in vlc-beta's code and its output and on the Internet this main window is called the main interface; or Qt has been called the default interface for VLC on https://wiki.videolan.org/Qt_Interface/. In some of my past executions of "vlc" I have seen the output "ReferenceError: mainInterface is not defined," but not on December 15, 2021, after having installed lots of software packages relating to the display protocol Wayland ( https://www.maketecheasier.com/what-is-wayland/) and/or the widget "tool kit" Qt, version 5, for making graphical user interfaces and applications suitable for use in various computer operating systems, which are otherwise called platforms [https://en.wikipedia.org/wiki/Qt_(software)]. Here is a listing of my virtual computer's "hardware" in my Leap-15.3 installation in VirtualBox on December 15, 2021. newbie at linux-hdi0:/usr/bin> inxi -G Graphics: Device-1: InnoTek Systemberatung VirtualBox Graphics Adapter driver: vboxvideo v: 6.1.30 r148432 Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa resolution: 1308x600 OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 20.2.4 newbie at linux-hdi0:/usr/bin> And here is a list of the online repositories to which I currently have set up access in my Leap-15.3 installation when it is online. To obtain this list I entered the command "zypper repos" as a "root" user. linux-hdi0:/usr/bin # zypper repos Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+-------- 1 | http-ftp.gwdg.de-2f96c871 | Packman Repository | Yes | (r ) Yes | Yes 2 | http-opensuse-guide.org-46cfd2d4 | libdvdcss repository | Yes | (r ) Yes | Yes 3 | openSUSE-Leap-15.3-1 | openSUSE-Leap-15.3-1 | Yes | (r ) Yes | No 4 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- 5 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | Yes 6 | repo-debug | Debug Repository | No | ---- | ---- 7 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- 8 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- 9 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ---- 10 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes 11 | repo-oss | Main Repository | Yes | (r ) Yes | Yes 12 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- 13 | repo-sle-update | Update repository with updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | Yes 14 | repo-source | Source Repository | No | ---- | ---- 15 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes 16 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes linux-hdi0:/usr/bin # With the help of a good teaching video on how to use the GNU’s Not Unix (GNU) debugger (gdb) on https://www.youtube.com/watch?v=bWH-nL7v5F4, by Doctor Chris Bourke of the University of Nebraska in Lincoln, Nebraska, The United States of America, I was able to proceed, statement-by-statement, in some of vlc-beta’s computer code with those statements looking to me like C-language statements, but more often looking like C-programming-language statements if I omitted the command within gdb of “layout next”; otherwise after entering the command “layout next” on December 14, 2021 I saw a number of lines in an upper panel each containing a hexadecimal address, a short word or phrase like “mov”, “test”, “call”, “je”, et cetera (Maybe it was assembly language??? But perhaps things looked strange instead of like C-language statements because I was missing some installed debugging packages, as the output below seemed to indicate.) Below the input “n” stands for “next” to instruct the computer program to go to the next statement to execute it in the computer code. So below are the results of some exploring of mine with vlc-beta on December 15, 2021 using the gdb. Despite "vlc" instead of vlc-beta appearing in the first command below, it is for vlc-beta. And I removed all of the VLC computer software and the VLC-based computer program caffeine from openSUSE in my Leap-15.3 installation. Instead I have vlc-beta computer software from the Packman online repository installed in my Leap-15.3 installation. newbie at linux-hdi0:~> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break libvlc_add_intf Breakpoint 1 at 0x1140 (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 4794)] [New Thread 0x7ffff4470700 (LWP 4795)] [New Thread 0x7ffff436f700 (LWP 4796)] [New Thread 0x7ffff426e700 (LWP 4797)] [New Thread 0x7ffff416d700 (LWP 4798)] [New Thread 0x7ffff2576700 (LWP 4799)] [New Thread 0x7fffedd75700 (LWP 4800)] [New Thread 0x7fffeda5f700 (LWP 4801)] Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at playlist.c:40 40 { Missing separate debuginfos, use: zypper install libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) print *p_instance $1 = {p_libvlc_int = 0x55555575dc40, ref_count = {refs = 1}, p_callback_list = 0x0, log = {cb = 0x0, data = 0x0}, dialog = {cbs = { pf_display_error = 0x0, pf_display_login = 0x0, pf_display_question = 0x0, pf_display_progress = 0x0, pf_cancel = 0x0, pf_update_progress = 0x0}, data = 0x0}} (gdb) print *Quit (gdb) print *0x55555575dc40 $2 = 1433787704 (gdb) print *p_libvlc_int No symbol "p_libvlc_int" in current context. (gdb) print name $3 = 0x0 (gdb) print p_libvlc_int No symbol "p_libvlc_int" in current context. (gdb) print *0x0 Cannot access memory at address 0x0 (gdb) quit A debugging session is active. Inferior 1 [process 4790] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:~> With some repetition, but going farther along than in the above sequence of entries: newbie at linux-hdi0:/usr/bin> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break libvlc_add_intf Breakpoint 1 at 0x1140 (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 6320)] [New Thread 0x7ffff4470700 (LWP 6321)] [New Thread 0x7ffff436f700 (LWP 6322)] [New Thread 0x7ffff426e700 (LWP 6323)] [New Thread 0x7ffff416d700 (LWP 6324)] [New Thread 0x7ffff2576700 (LWP 6325)] [New Thread 0x7ffff1d75700 (LWP 6326)] [New Thread 0x7ffff1a5f700 (LWP 6327)] Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at playlist.c:40 40 { Missing separate debuginfos, use: zypper install libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) n 40 { (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) n n[000055555575dc40] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [Detaching after vfork from child process 6328] [New Thread 0x7ffff0152700 (LWP 6335)] [New Thread 0x7fffcbe1f700 (LWP 6336)] [New Thread 0x7fffc1e03700 (LWP 6337)] [New Thread 0x7fffc1602700 (LWP 6338)] [New Thread 0x7fffc0e01700 (LWP 6339)] [New Thread 0x7fffb3dd5700 (LWP 6340)] [New Thread 0x7fffb26ad700 (LWP 6341)] [New Thread 0x7fff9bbfd700 (LWP 6342)] [New Thread 0x7fff9b3fc700 (LWP 6343)] [New Thread 0x7fff9abfb700 (LWP 6344)] [New Thread 0x7fff9a3fa700 (LWP 6345)] [New Thread 0x7fff99bf9700 (LWP 6346)] [New Thread 0x7fff993f8700 (LWP 6347)] [New Thread 0x7fff98bf7700 (LWP 6348)] [New Thread 0x7fff83fff700 (LWP 6349)] [New Thread 0x7fff837fe700 (LWP 6350)] [New Thread 0x7fff81ca4700 (LWP 6351)] 50 } Missing separate debuginfos, use: zypper install Mesa-dri-debuginfo-20.2.4-57.12.x86_64 Mesa-libGL1-debuginfo-20.2.4-57.13.x86_64 Mesa-libglapi0-debuginfo-20.2.4-57.13.x86_64 dbus-1-glib-debuginfo-0.108-1.29.x86_64 fcitx-qt5-debuginfo-1.2.5-bp153.2.2.1.x86_64 fontconfig-debuginfo-2.12.6-4.3.1.x86_64 gconf2-debuginfo-3.2.6-9.26.x86_64 gsettings-backend-dconf-debuginfo-0.34.0-2.27.x86_64 gtk2-theming-engine-adwaita-debuginfo-3.22.3-4.3.1.x86_64 gvfs-debuginfo-1.42.2-4.24.x86_64 kimageformats-debuginfo-5.76.0-bp153.3.2.1.x86_64 libHalf23-debuginfo-2.2.1-1.17.x86_64 libIex-2_2-23-debuginfo-2.2.1-1.17.x86_64 libIlmImf-2_2-23-debuginfo-2.2.1-3.38.1.x86_64 libIlmThread-2_2-23-debuginfo-2.2.1-1.17.x86_64 libKF5Archive5-debuginfo-5.76.0-bp153.2.2.1.x86_64 libLLVM11-debuginfo-11.0.1-1.26.x86_64 libQt5Core5-debuginfo-5.12.7-4.12.2.x86_64 libQt5DBus5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Gui5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Network5-debuginfo-5.12.7-4.12.2.x86_64 libQt5QuickControls2-5-debuginfo-5.12.7-1.53.x86_64 libQt5Svg5-debuginfo-5.12.7-3.3.1.x86_64 libQt5Widgets5-debuginfo-5.12.7-4.12.2.x86_64 libQt5X11Extras5-debuginfo-5.12.7-1.49.x86_64 libQtQuick5-debuginfo-5.12.7-4.2.1.x86_64 libSM6-debuginfo-1.2.2-1.23.x86_64 libX11-xcb1-debuginfo-1.6.5-3.21.1.x86_64 libXcomposite1-debuginfo-0.4.4-1.23.x86_64 libXcursor1-debuginfo-1.1.15-1.18.x86_64 libXext6-debuginfo-1.3.3-1.30.x86_64 libXi6-debuginfo-1.7.9-3.2.1.x86_64 libXinerama1-debuginfo-1.1.3-1.22.x86_64 libXrandr2-debuginfo-1.5.1-2.17.x86_64 libXrender1-debuginfo-0.9.10-1.30.x86_64 libblkid1-debuginfo-2.36.2-4.5.1.x86_64 libbz2-1-debuginfo-1.0.6-5.11.1.x86_64 libcairo2-debuginfo-1.16.0-1.55.x86_64 libcanberra-gtk0-debuginfo-0.30-3.2.3.x86_64 libcanberra-gtk2-module-debuginfo-0.30-3.2.3.x86_64 libdatrie1-debuginfo-0.2.9-1.25.x86_64 libdouble-conversion3-debuginfo-3.1.5-3.2.1.x86_64 libdrm_nouveau2-debuginfo-2.4.104-1.12.x86_64 libdrm_radeon1-debuginfo-2.4.104-1.12.x86_64 libedit0-debuginfo-3.1.snap20150325-2.12.x86_64 libelf1-debuginfo-0.168-4.5.3.x86_64 libexpat1-debuginfo-2.2.5-3.6.1.x86_64 libffi7-debuginfo-3.2.1.git259-10.8.x86_64 libfreetype6-debuginfo-2.10.1-4.8.1.x86_64 libfribidi0-debuginfo-1.0.5-3.3.1.x86_64 libgcc_s1-debuginfo-11.2.1+git610-1.3.9.x86_64 libglib-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libglvnd-debuginfo-1.3.2-1.49.x86_64 libgobject-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libgtk-2_0-0-debuginfo-2.24.32+67-2.28.x86_64 libharfbuzz0-debuginfo-2.6.4-1.56.x86_64 libicu-suse65_1-debuginfo-65.1-4.2.1.x86_64 libjasper4-debuginfo-2.0.14-3.19.1.x86_64 libjbig2-debuginfo-2.1-1.31.x86_64 libjpeg8-debuginfo-8.1.2-5.18.1.x86_64 liblcms2-2-debuginfo-2.9-3.3.1.x86_64 libltdl7-debuginfo-2.4.6-3.4.1.x86_64 libmodman1-debuginfo-2.0.1-1.27.x86_64 libmount1-debuginfo-2.36.2-4.5.1.x86_64 libopenssl1_1-debuginfo-1.1.1d-11.30.1.x86_64 libpango-1_0-0-debuginfo-1.44.7+11-1.25.x86_64 libpcre2-16-0-debuginfo-10.31-3.3.1.x86_64 libpng16-16-debuginfo-1.6.34-3.9.1.x86_64 libproxy1-debuginfo-0.4.15-12.41.x86_64 libqt5-qtimageformats-debuginfo-5.12.7-1.50.x86_64 libqt5-qtquickcontrols2-debuginfo-5.12.7-1.53.x86_64 libstdc++6-debuginfo-11.2.1+git610-1.3.9.x86_64 libthai0-debuginfo-0.1.27-1.16.x86_64 libuuid1-debuginfo-2.36.2-4.5.1.x86_64 libwayland-client0-debuginfo-1.18.0-1.19.x86_64 libwebp7-debuginfo-1.0.3-1.62.x86_64 libxcb-composite0-debuginfo-1.13-3.5.1.x86_64 libxcb-damage0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri2-0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri3-0-debuginfo-1.13-3.5.1.x86_64 libxcb-keysyms1-debuginfo-0.4.0-1.23.x86_64 libxcb-present0-debuginfo-1.13-3.5.1.x86_64 libxcb-render-util0-debuginfo-0.3.9-1.23.x86_64 libxcb-render0-debuginfo-1.13-3.5.1.x86_64 libxcb-shape0-debuginfo-1.13-3.5.1.x86_64 libxcb-shm0-debuginfo-1.13-3.5.1.x86_64 libxcb-sync1-debuginfo-1.13-3.5.1.x86_64 libxcb-util1-debuginfo-0.4.0-1.23.x86_64 libxcb-xfixes0-debuginfo-1.13-3.5.1.x86_64 libxkbcommon-x11-0-debuginfo-0.8.2-3.3.1.x86_64 libxml2-2-debuginfo-2.9.7-3.37.1.x86_64 libz1-debuginfo-1.2.11-3.21.1.x86_64 (gdb) n [Thread 0x7fffb26ad700 (LWP 6341) exited] main (argc=, argv=0x7fffffffdf28) at vlc.c:245 245 libvlc_playlist_play (vlc); Missing separate debuginfos, use: zypper install libqt5-qtgraphicaleffects-debuginfo-5.12.7-1.53.x86_64 (gdb) n 249 sigdelset (&set, SIGCHLD); (gdb) n 250 pthread_sigmask (SIG_SETMASK, &set, NULL); (gdb) n 253 if (signal_ignored (SIGHUP)) (gdb) n 256 sigdelset (&set, SIGPIPE); (gdb) n Thread 25 "QQmlThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff837fe700 (LWP 6350)] 0x00007fffdba86613 in ?? () from /usr/lib64/libQt5Qml.so.5 (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) quit A debugging session is active. Inferior 1 [process 6316] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:/usr/bin> I tried to follow numerous other people's postings on the Internet to enable the playing of a .mp4 file in the VLC. But unfortunately I failed in all of those efforts with a segmentation fault using vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 or else with the lack of a displayed video signal in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 when in each case using their Qt interfaces. So please help me eliminate the "Segmentation fault" error and to be able to play a .mp4 video in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 using its probably default, Qt interface. From spring2014day at gmail.com Fri Dec 17 01:04:24 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Thu, 16 Dec 2021 19:04:24 -0500 Subject: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox Message-ID: On December 16, 2021 I could not find evidence in my Gmail (Google mail), e-mail account's "Sent" folder of having sent the contents below this paragraph on December 15, 2021, excepting today's correction of a December 10, 2021 version number of the software package vlc-beta, to packman at links2linux.de; but, except for that mistake in the version number, I thought I did so on December 15, 2021. So I am sending those contents the second or first time to packman at links2linux.de, but including a correction to the December 10, 2021 version number of vlc-beta in this electronic-mail letter. Hello. I have not knowingly received a reply by electronic mail (e-mail) from anyone on the e-mailing list of packman at links2linux.de to my November 12, 2021 e-mail letter sent to that e-mail address. Question: Am I supposed to join that e-mailing list of packman at links2linux.de in order for me to receive such a reply? I suppose not. A disadvantage of my joining that e-mailing list is that if I would join it I might receive lots of e-mail about matters irrelevant to my current computer-software problems. Here I present additional data and more diagnostic information than I presented on November 12, 2021, which hopefully will "spark" more ideas helpful to me among one or more expert readers of my electronic mail than following my November 12, 2021 e-mail letter. In a 64-bit, openSUSE, Leap-15.3, Linux operating system, which is installed as a so-called "guest" in Virtual "Machine" (VM) in Oracle (Corporation) VM VirtualBox, which in turn is installed in my so-called "host," Windows 10 Home Edition operating system, I have gratefully had success in the playing of a .mp4 (Moving or Motion Picture Experts Group, audio layer-4) file in vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 with the Linux kernel 5.3.18-59.27.1-default. But in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 I had only the audio signals and not the video signals in the playing of that video. And later in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 with the Linux kernel 5.3.18-59.37.2-default I attempted to open vlc-beta, or the Video Local Area Network (LAN) Client (VLC) multimedia player (VLC) by double-clicking on a desktop shortcut for it, but saw its main window only for a very brief period of time, accompanied probably a short time later with the message "Segmentation fault (core dumped)"; so I could not even attempt to play that .mp4 file normally with this version of vlc-beta when using its probably default, Qt interface. I at least began the process of preparation toward having a .rpm (RedHat package manager) file "built" for my Leap-15.3 installation using downloaded source code for vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1 or 20211104.b9e50b090c-pm153.10.1.16.1.x86_64 and an rpmbuild... command, but failed in that effort due to "Failed build dependencies". I started that kind of process also with vlc-beta-20211210.736213df13-pm153.17.1.x86_64 by starting to obtain some software packages missing in my Leap-15.3 installation. And that process for my Leap-15.3 installation not only required a list of some tens of software packages; but I discovered two other difficult factors: 1) The software package mentioned between the parentheses of a pkgconfig(...) "response" following an rpmbuild... command is sometimes different than the name of a software package I could obtain from an openSUSE or Packman online repository. And I don't know for certain if I can even obtain the exact package "requested" from somewhere on the Internet. 2) But in a "user-friendly" way it might be that sometimes rpmbuild might "accept" packages with names similar, but not exactly the same as the names of the packages between the parentheses of pkgconfig(...) (For example, I installed libnfs13, which has a name slightly different from the name of the required package libnfs for rpmbuild....). But if similar names would not be "accepted" by rpmbuild and I could not obtain the exact software packages requested, in that case I don't know what I should do to "satisfy" the "rpmbuild" computer code. Rather than try to find and obtain some tens of software packages required for the successful execution of an rpmbuild command using the downloaded source code for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, I read that it is possible to have such a .rpm file "built" online using the openSUSE Build Service of the Open Build Service (OBS, https://build.opensuse.org/ on the Internet). It seems to be reported that such "building" could ease the action of obtaining the software packages "required" by rpmbuild. But I have not learned how to use OBS or tried it to make a .rpm file. But even if I would be successful in somehow "building" such a .rpm file for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, it is possible that it might not eliminate the segmentation faults I have encountered, especially if it would be a change in the vlc-beta source code which would be needed to eliminate such segmentation faults. Although the .rpm installation file for version 20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 of the software package vlc-beta is probably unfortunately no longer available from http://packman.links2linux.de/package/vlc-beta or https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/Multimedia/x86_64/, fortunately I have the capability to restore my Leap-15.3 installation, including the installation of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 in it, from a previously written backup of the data on my Dell notebook computer's internal hard-disk drive. For a period of time I was able to "lock" or protect that version of vlc-beta, which has worked well for me, from being updated to a newer version of vlc-beta, which thus far has not worked for me when using its Qt interface. However, considering the likely future updates to some software packages and the Linux kernel elsewhere in my Leap-15.3 installation, the arrangement of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 working well with a number of newer software packages might at some time in the future no longer be a mutually well-working arrangement for me. At least by the time of an upgrade from version 15.3 to version 15.4 of Leap on or after June 8, 2022, there could be a possible software mismatch, since according to http://packman.links2linux.de/package/vlc-beta the version vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 saved in my hard-disk drive's backup data is reported to be suitable for a Leap-15.3 installation. So I have been attempting to find some way to make the version of vlc-beta released to the public on December 6, 2021, namely vlc-beta-20211210.736213df13-pm153.17.1.x86_64, work in my Leap-15.3 installation. And the hope would be that after having made it to work in my Leap-15.3 installation that making later versions of vlc-beta to work in my Leap-15.3 installation might be easier than now for vlc-beta-20211210.7 36213df13-pm153.17.1.x86_64. I have been able to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.1 7.1.x86_64 using a command of the form "vlc -I dummy FILE_NAME.mp4" in a directory containing the file with a name of the form FILE_NAME.mp4. Otherwise entering the command "vlc" or "gdb vlc", using the GNU's Not Unix (GNU) debugger (gdb), in the directory /usr/bin resulted in the main window for vlc-beta opening, but with most of it transparent; then very soon afterward I received the message "Segmentation fault (core dumped)". Those same two things occurred after I entered the command "vlc -I qt" in the directory /usr/bin. So my current problem is associated with Qt and the main window of vlc-beta, not the so-called "dummy interface" of vlc-beta. If the "menu" items and/or software controls on vlc-beta's main window are considered plugins, then it appears to me that the problem is in displaying those items on vlc-beta's main window. But in vlc-beta's code and its output and on the Internet this main window is called the main interface; or Qt has been called the default interface for VLC on https://wiki.videolan.org/Qt_Interface/. In some of my past executions of "vlc" I have seen the output "ReferenceError: mainInterface is not defined," but not on December 15, 2021, after having installed lots of software packages relating to the display protocol Wayland ( https://www.maketecheasier.com/what-is-wayland/) and/or the widget "tool kit" Qt, version 5, for making graphical user interfaces and applications suitable for use in various computer operating systems, which are otherwise called platforms [https://en.wikipedia.org/wiki/Qt_(software)]. Here is a listing of my virtual computer's "hardware" in my Leap-15.3 installation in VirtualBox on December 15, 2021. newbie at linux-hdi0:/usr/bin> inxi -G Graphics: Device-1: InnoTek Systemberatung VirtualBox Graphics Adapter driver: vboxvideo v: 6.1.30 r148432 Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa resolution: 1308x600 OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 20.2.4 newbie at linux-hdi0:/usr/bin> And here is a list of the online repositories to which I currently have set up access in my Leap-15.3 installation when it is online. To obtain this list I entered the command "zypper repos" as a "root" user. linux-hdi0:/usr/bin # zypper repos Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+-------- 1 | http-ftp.gwdg.de-2f96c871 | Packman Repository | Yes | (r ) Yes | Yes 2 | http-opensuse-guide.org-46cfd2d4 | libdvdcss repository | Yes | (r ) Yes | Yes 3 | openSUSE-Leap-15.3-1 | openSUSE-Leap-15.3-1 | Yes | (r ) Yes | No 4 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- 5 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | Yes 6 | repo-debug | Debug Repository | No | ---- | ---- 7 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- 8 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- 9 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ---- 10 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes 11 | repo-oss | Main Repository | Yes | (r ) Yes | Yes 12 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- 13 | repo-sle-update | Update repository with updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | Yes 14 | repo-source | Source Repository | No | ---- | ---- 15 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes 16 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes linux-hdi0:/usr/bin # With the help of a good teaching video on how to use the GNU’s Not Unix (GNU) debugger (gdb) on https://www.youtube.com/watch?v=bWH-nL7v5F4, by Doctor Chris Bourke of the University of Nebraska in Lincoln, Nebraska, The United States of America, I was able to proceed, statement-by-statement, in some of vlc-beta’s computer code with those statements looking to me like C-language statements, but more often looking like C-programming-language statements if I omitted the command within gdb of “layout next”; otherwise after entering the command “layout next” on December 14, 2021 I saw a number of lines in an upper panel each containing a hexadecimal address, a short word or phrase like “mov”, “test”, “call”, “je”, et cetera (Maybe it was assembly language??? But perhaps things looked strange instead of like C-language statements because I was missing some installed debugging packages, as the output below seemed to indicate.) Below the input “n” stands for “next” to instruct the computer program to go to the next statement to execute it in the computer code. So below are the results of some exploring of mine with vlc-beta on December 15, 2021 using the gdb. Despite "vlc" instead of vlc-beta appearing in the first command below, it is for vlc-beta. And I removed all of the VLC computer software and the VLC-based computer program caffeine from openSUSE in my Leap-15.3 installation. Instead I have vlc-beta computer software from the Packman online repository installed in my Leap-15.3 installation. newbie at linux-hdi0:~> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break libvlc_add_intf Breakpoint 1 at 0x1140 (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 4794)] [New Thread 0x7ffff4470700 (LWP 4795)] [New Thread 0x7ffff436f700 (LWP 4796)] [New Thread 0x7ffff426e700 (LWP 4797)] [New Thread 0x7ffff416d700 (LWP 4798)] [New Thread 0x7ffff2576700 (LWP 4799)] [New Thread 0x7fffedd75700 (LWP 4800)] [New Thread 0x7fffeda5f700 (LWP 4801)] Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at playlist.c:40 40 { Missing separate debuginfos, use: zypper install libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) print *p_instance $1 = {p_libvlc_int = 0x55555575dc40, ref_count = {refs = 1}, p_callback_list = 0x0, log = {cb = 0x0, data = 0x0}, dialog = {cbs = { pf_display_error = 0x0, pf_display_login = 0x0, pf_display_question = 0x0, pf_display_progress = 0x0, pf_cancel = 0x0, pf_update_progress = 0x0}, data = 0x0}} (gdb) print *Quit (gdb) print *0x55555575dc40 $2 = 1433787704 (gdb) print *p_libvlc_int No symbol "p_libvlc_int" in current context. (gdb) print name $3 = 0x0 (gdb) print p_libvlc_int No symbol "p_libvlc_int" in current context. (gdb) print *0x0 Cannot access memory at address 0x0 (gdb) quit A debugging session is active. Inferior 1 [process 4790] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:~> With some repetition, but going farther along than in the above sequence of entries: newbie at linux-hdi0:/usr/bin> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break libvlc_add_intf Breakpoint 1 at 0x1140 (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 6320)] [New Thread 0x7ffff4470700 (LWP 6321)] [New Thread 0x7ffff436f700 (LWP 6322)] [New Thread 0x7ffff426e700 (LWP 6323)] [New Thread 0x7ffff416d700 (LWP 6324)] [New Thread 0x7ffff2576700 (LWP 6325)] [New Thread 0x7ffff1d75700 (LWP 6326)] [New Thread 0x7ffff1a5f700 (LWP 6327)] Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at playlist.c:40 40 { Missing separate debuginfos, use: zypper install libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) n 40 { (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) n n[000055555575dc40] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [Detaching after vfork from child process 6328] [New Thread 0x7ffff0152700 (LWP 6335)] [New Thread 0x7fffcbe1f700 (LWP 6336)] [New Thread 0x7fffc1e03700 (LWP 6337)] [New Thread 0x7fffc1602700 (LWP 6338)] [New Thread 0x7fffc0e01700 (LWP 6339)] [New Thread 0x7fffb3dd5700 (LWP 6340)] [New Thread 0x7fffb26ad700 (LWP 6341)] [New Thread 0x7fff9bbfd700 (LWP 6342)] [New Thread 0x7fff9b3fc700 (LWP 6343)] [New Thread 0x7fff9abfb700 (LWP 6344)] [New Thread 0x7fff9a3fa700 (LWP 6345)] [New Thread 0x7fff99bf9700 (LWP 6346)] [New Thread 0x7fff993f8700 (LWP 6347)] [New Thread 0x7fff98bf7700 (LWP 6348)] [New Thread 0x7fff83fff700 (LWP 6349)] [New Thread 0x7fff837fe700 (LWP 6350)] [New Thread 0x7fff81ca4700 (LWP 6351)] 50 } Missing separate debuginfos, use: zypper install Mesa-dri-debuginfo-20.2.4-57.12.x86_64 Mesa-libGL1-debuginfo-20.2.4-57.13.x86_64 Mesa-libglapi0-debuginfo-20.2.4-57.13.x86_64 dbus-1-glib-debuginfo-0.108-1.29.x86_64 fcitx-qt5-debuginfo-1.2.5-bp153.2.2.1.x86_64 fontconfig-debuginfo-2.12.6-4.3.1.x86_64 gconf2-debuginfo-3.2.6-9.26.x86_64 gsettings-backend-dconf-debuginfo-0.34.0-2.27.x86_64 gtk2-theming-engine-adwaita-debuginfo-3.22.3-4.3.1.x86_64 gvfs-debuginfo-1.42.2-4.24.x86_64 kimageformats-debuginfo-5.76.0-bp153.3.2.1.x86_64 libHalf23-debuginfo-2.2.1-1.17.x86_64 libIex-2_2-23-debuginfo-2.2.1-1.17.x86_64 libIlmImf-2_2-23-debuginfo-2.2.1-3.38.1.x86_64 libIlmThread-2_2-23-debuginfo-2.2.1-1.17.x86_64 libKF5Archive5-debuginfo-5.76.0-bp153.2.2.1.x86_64 libLLVM11-debuginfo-11.0.1-1.26.x86_64 libQt5Core5-debuginfo-5.12.7-4.12.2.x86_64 libQt5DBus5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Gui5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Network5-debuginfo-5.12.7-4.12.2.x86_64 libQt5QuickControls2-5-debuginfo-5.12.7-1.53.x86_64 libQt5Svg5-debuginfo-5.12.7-3.3.1.x86_64 libQt5Widgets5-debuginfo-5.12.7-4.12.2.x86_64 libQt5X11Extras5-debuginfo-5.12.7-1.49.x86_64 libQtQuick5-debuginfo-5.12.7-4.2.1.x86_64 libSM6-debuginfo-1.2.2-1.23.x86_64 libX11-xcb1-debuginfo-1.6.5-3.21.1.x86_64 libXcomposite1-debuginfo-0.4.4-1.23.x86_64 libXcursor1-debuginfo-1.1.15-1.18.x86_64 libXext6-debuginfo-1.3.3-1.30.x86_64 libXi6-debuginfo-1.7.9-3.2.1.x86_64 libXinerama1-debuginfo-1.1.3-1.22.x86_64 libXrandr2-debuginfo-1.5.1-2.17.x86_64 libXrender1-debuginfo-0.9.10-1.30.x86_64 libblkid1-debuginfo-2.36.2-4.5.1.x86_64 libbz2-1-debuginfo-1.0.6-5.11.1.x86_64 libcairo2-debuginfo-1.16.0-1.55.x86_64 libcanberra-gtk0-debuginfo-0.30-3.2.3.x86_64 libcanberra-gtk2-module-debuginfo-0.30-3.2.3.x86_64 libdatrie1-debuginfo-0.2.9-1.25.x86_64 libdouble-conversion3-debuginfo-3.1.5-3.2.1.x86_64 libdrm_nouveau2-debuginfo-2.4.104-1.12.x86_64 libdrm_radeon1-debuginfo-2.4.104-1.12.x86_64 libedit0-debuginfo-3.1.snap20150325-2.12.x86_64 libelf1-debuginfo-0.168-4.5.3.x86_64 libexpat1-debuginfo-2.2.5-3.6.1.x86_64 libffi7-debuginfo-3.2.1.git259-10.8.x86_64 libfreetype6-debuginfo-2.10.1-4.8.1.x86_64 libfribidi0-debuginfo-1.0.5-3.3.1.x86_64 libgcc_s1-debuginfo-11.2.1+git610-1.3.9.x86_64 libglib-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libglvnd-debuginfo-1.3.2-1.49.x86_64 libgobject-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libgtk-2_0-0-debuginfo-2.24.32+67-2.28.x86_64 libharfbuzz0-debuginfo-2.6.4-1.56.x86_64 libicu-suse65_1-debuginfo-65.1-4.2.1.x86_64 libjasper4-debuginfo-2.0.14-3.19.1.x86_64 libjbig2-debuginfo-2.1-1.31.x86_64 libjpeg8-debuginfo-8.1.2-5.18.1.x86_64 liblcms2-2-debuginfo-2.9-3.3.1.x86_64 libltdl7-debuginfo-2.4.6-3.4.1.x86_64 libmodman1-debuginfo-2.0.1-1.27.x86_64 libmount1-debuginfo-2.36.2-4.5.1.x86_64 libopenssl1_1-debuginfo-1.1.1d-11.30.1.x86_64 libpango-1_0-0-debuginfo-1.44.7+11-1.25.x86_64 libpcre2-16-0-debuginfo-10.31-3.3.1.x86_64 libpng16-16-debuginfo-1.6.34-3.9.1.x86_64 libproxy1-debuginfo-0.4.15-12.41.x86_64 libqt5-qtimageformats-debuginfo-5.12.7-1.50.x86_64 libqt5-qtquickcontrols2-debuginfo-5.12.7-1.53.x86_64 libstdc++6-debuginfo-11.2.1+git610-1.3.9.x86_64 libthai0-debuginfo-0.1.27-1.16.x86_64 libuuid1-debuginfo-2.36.2-4.5.1.x86_64 libwayland-client0-debuginfo-1.18.0-1.19.x86_64 libwebp7-debuginfo-1.0.3-1.62.x86_64 libxcb-composite0-debuginfo-1.13-3.5.1.x86_64 libxcb-damage0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri2-0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri3-0-debuginfo-1.13-3.5.1.x86_64 libxcb-keysyms1-debuginfo-0.4.0-1.23.x86_64 libxcb-present0-debuginfo-1.13-3.5.1.x86_64 libxcb-render-util0-debuginfo-0.3.9-1.23.x86_64 libxcb-render0-debuginfo-1.13-3.5.1.x86_64 libxcb-shape0-debuginfo-1.13-3.5.1.x86_64 libxcb-shm0-debuginfo-1.13-3.5.1.x86_64 libxcb-sync1-debuginfo-1.13-3.5.1.x86_64 libxcb-util1-debuginfo-0.4.0-1.23.x86_64 libxcb-xfixes0-debuginfo-1.13-3.5.1.x86_64 libxkbcommon-x11-0-debuginfo-0.8.2-3.3.1.x86_64 libxml2-2-debuginfo-2.9.7-3.37.1.x86_64 libz1-debuginfo-1.2.11-3.21.1.x86_64 (gdb) n [Thread 0x7fffb26ad700 (LWP 6341) exited] main (argc=, argv=0x7fffffffdf28) at vlc.c:245 245 libvlc_playlist_play (vlc); Missing separate debuginfos, use: zypper install libqt5-qtgraphicaleffects-debuginfo-5.12.7-1.53.x86_64 (gdb) n 249 sigdelset (&set, SIGCHLD); (gdb) n 250 pthread_sigmask (SIG_SETMASK, &set, NULL); (gdb) n 253 if (signal_ignored (SIGHUP)) (gdb) n 256 sigdelset (&set, SIGPIPE); (gdb) n Thread 25 "QQmlThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff837fe700 (LWP 6350)] 0x00007fffdba86613 in ?? () from /usr/lib64/libQt5Qml.so.5 (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) quit A debugging session is active. Inferior 1 [process 6316] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:/usr/bin> I tried to follow numerous other people's postings on the Internet to enable the playing of a .mp4 file in the VLC. But unfortunately I failed in all of those efforts with a segmentation fault using vlc-beta-20211210.7 36213df13-pm153.17.1.x86_64 or else with the lack of a displayed video signal in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 when in each case using their Qt interfaces. So please help me eliminate the "Segmentation fault" error and to be able to play a .mp4 video in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 using its probably default, Qt interface. Pat From spring2014day at gmail.com Fri Dec 17 01:06:29 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Thu, 16 Dec 2021 19:06:29 -0500 Subject: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox In-Reply-To: References: Message-ID: Hello again. I discovered that there was a folder /home/newbie (my user name)/.config /vlc, which had apparently been left over from previous installations of the Video LAN (Local-Area Network) Client (VLC) media or multimedia player or the VLC-based software package caffeine in my Leap-15.3 installation. So I entered the following set of commands mostly, if not entirely, as a "root" user. zypper rm vlc-beta vlc-beta-debuginfo vlc-beta-debugsource I moved /home/newbie/.config /vlc to "trash", but left /usr/src/packages/BUILD, BUILDROOT, RPMS, SOURCES, SPECS, and SRPMS intact for possible .rpm (RedHat package manager) "building" from source code. It was no surprise that by this time the directories /usr/lib64/vlc-beta and /usr*/*lib/vlc-beta had disappeared. zypper refresh zypper install –repo http-ftp.gwdg.de-2f96c871 -f vlc-beta vlc-beta-debuginfo vlc-beta-debugsource , with http-ftp.gwdg.de-2f96c871 being the alias for allowing access to the Packman online repository and "f" standing for probably "force" to force those installations to occur. Afterward a surprise was that no /home/newbie/.config/vlc or vlc-beta folder was found. Below I entered the command "gdb vlc", with gdb standing for the GNU's Not Unix (GNU) debugger, and had results similar to earlier with a segmentation fault, but this time with no notification of a core dump and this time with both "Welcome -VLC media player" and "VLC media player" mostly tranparent windows appearing. newbie at linux-hdi0:/usr/bin> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break pf_int Function "pf_int" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 6318)] [New Thread 0x7ffff4470700 (LWP 6319)] [New Thread 0x7ffff436f700 (LWP 6320)] [New Thread 0x7ffff426e700 (LWP 6321)] [New Thread 0x7ffff416d700 (LWP 6322)] [New Thread 0x7ffff2576700 (LWP 6323)] [New Thread 0x7fffedd75700 (LWP 6324)] [New Thread 0x7fffeda5f700 (LWP 6325)] [000055555575dc40] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [Detaching after vfork from child process 6326] [New Thread 0x7fffec152700 (LWP 6333)] [New Thread 0x7fffcbe1f700 (LWP 6334)] [New Thread 0x7fffc1e03700 (LWP 6336)] [New Thread 0x7fffc1602700 (LWP 6337)] [New Thread 0x7fffc0e01700 (LWP 6338)] [New Thread 0x7fffb3dd5700 (LWP 6339)] [New Thread 0x7fffb26ad700 (LWP 6340)] [New Thread 0x7fff9bbfd700 (LWP 6341)] [New Thread 0x7fff9b3fc700 (LWP 6342)] [New Thread 0x7fff9abfb700 (LWP 6343)] [New Thread 0x7fff9a3fa700 (LWP 6344)] [New Thread 0x7fff99bf9700 (LWP 6345)] [New Thread 0x7fff993f8700 (LWP 6346)] [New Thread 0x7fff98bf7700 (LWP 6347)] [New Thread 0x7fff83fff700 (LWP 6348)] [New Thread 0x7fff837fe700 (LWP 6349)] [New Thread 0x7fff81ca4700 (LWP 6350)] Thread 25 "QQmlThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff837fe700 (LWP 6349)] 0x00007fffdba86613 in ?? () from /usr/lib64/libQt5Qml.so.5 Missing separate debuginfos, use: zypper install Mesa-dri-debuginfo-20.2.4-57.12.x86_64 Mesa-libGL1-debuginfo-20.2.4-57.13.x86_64 Mesa-libglapi0-debuginfo-20.2.4-57.13.x86_64 dbus-1-glib-debuginfo-0.108-1.29.x86_64 fcitx-qt5-debuginfo-1.2.5-bp153.2.2.1.x86_64 fontconfig-debuginfo-2.12.6-4.3.1.x86_64 gconf2-debuginfo-3.2.6-9.26.x86_64 gsettings-backend-dconf-debuginfo-0.34.0-2.27.x86_64 gtk2-theming-engine-adwaita-debuginfo-3.22.3-4.3.1.x86_64 gvfs-debuginfo-1.42.2-4.24.x86_64 kimageformats-debuginfo-5.76.0-bp153.3.2.1.x86_64 libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libHalf23-debuginfo-2.2.1-1.17.x86_64 libIex-2_2-23-debuginfo-2.2.1-1.17.x86_64 libIlmImf-2_2-23-debuginfo-2.2.1-3.38.1.x86_64 libIlmThread-2_2-23-debuginfo-2.2.1-1.17.x86_64 libKF5Archive5-debuginfo-5.76.0-bp153.2.2.1.x86_64 libLLVM11-debuginfo-11.0.1-1.26.x86_64 libQt5Core5-debuginfo-5.12.7-4.12.2.x86_64 libQt5DBus5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Gui5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Network5-debuginfo-5.12.7-4.12.2.x86_64 libQt5QuickControls2-5-debuginfo-5.12.7-1.53.x86_64 libQt5Svg5-debuginfo-5.12.7-3.3.1.x86_64 libQt5Widgets5-debuginfo-5.12.7-4.12.2.x86_64 libQt5X11Extras5-debuginfo-5.12.7-1.49.x86_64 libQtQuick5-debuginfo-5.12.7-4.2.1.x86_64 libSM6-debuginfo-1.2.2-1.23.x86_64 libX11-xcb1-debuginfo-1.6.5-3.21.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libXcomposite1-debuginfo-0.4.4-1.23.x86_64 libXcursor1-debuginfo-1.1.15-1.18.x86_64 libXext6-debuginfo-1.3.3-1.30.x86_64 libXi6-debuginfo-1.7.9-3.2.1.x86_64 libXinerama1-debuginfo-1.1.3-1.22.x86_64 libXrandr2-debuginfo-1.5.1-2.17.x86_64 libXrender1-debuginfo-0.9.10-1.30.x86_64 libblkid1-debuginfo-2.36.2-4.5.1.x86_64 libbz2-1-debuginfo-1.0.6-5.11.1.x86_64 libcairo2-debuginfo-1.16.0-1.55.x86_64 libcanberra-gtk0-debuginfo-0.30-3.2.3.x86_64 libcanberra-gtk2-module-debuginfo-0.30-3.2.3.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdatrie1-debuginfo-0.2.9-1.25.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libdouble-conversion3-debuginfo-3.1.5-3.2.1.x86_64 libdrm_nouveau2-debuginfo-2.4.104-1.12.x86_64 libdrm_radeon1-debuginfo-2.4.104-1.12.x86_64 libedit0-debuginfo-3.1.snap20150325-2.12.x86_64 libelf1-debuginfo-0.168-4.5.3.x86_64 libexpat1-debuginfo-2.2.5-3.6.1.x86_64 libffi7-debuginfo-3.2.1.git259-10.8.x86_64 libfreetype6-debuginfo-2.10.1-4.8.1.x86_64 libfribidi0-debuginfo-1.0.5-3.3.1.x86_64 libgcc_s1-debuginfo-11.2.1+git610-1.3.9.x86_64 libglib-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libglvnd-debuginfo-1.3.2-1.49.x86_64 libgobject-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libgtk-2_0-0-debuginfo-2.24.32+67-2.28.x86_64 libharfbuzz0-debuginfo-2.6.4-1.56.x86_64 libicu-suse65_1-debuginfo-65.1-4.2.1.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 libjasper4-debuginfo-2.0.14-3.19.1.x86_64 libjbig2-debuginfo-2.1-1.31.x86_64 libjpeg8-debuginfo-8.1.2-5.18.1.x86_64 liblcms2-2-debuginfo-2.9-3.3.1.x86_64 libltdl7-debuginfo-2.4.6-3.4.1.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libmodman1-debuginfo-2.0.1-1.27.x86_64 libmount1-debuginfo-2.36.2-4.5.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libopenssl1_1-debuginfo-1.1.1d-11.30.1.x86_64 libpango-1_0-0-debuginfo-1.44.7+11-1.25.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpcre2-16-0-debuginfo-10.31-3.3.1.x86_64 libpng16-16-debuginfo-1.6.34-3.9.1.x86_64 libproxy1-debuginfo-0.4.15-12.41.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libqt5-qtgraphicaleffects-debuginfo-5.12.7-1.53.x86_64 libqt5-qtimageformats-debuginfo-5.12.7-1.50.x86_64 libqt5-qtquickcontrols2-debuginfo-5.12.7-1.53.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libstdc++6-debuginfo-11.2.1+git610-1.3.9.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libthai0-debuginfo-0.1.27-1.16.x86_64 libuuid1-debuginfo-2.36.2-4.5.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libwayland-client0-debuginfo-1.18.0-1.19.x86_64 libwebp7-debuginfo-1.0.3-1.62.x86_64 libxcb-composite0-debuginfo-1.13-3.5.1.x86_64 libxcb-damage0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri2-0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri3-0-debuginfo-1.13-3.5.1.x86_64 libxcb-keysyms1-debuginfo-0.4.0-1.23.x86_64 libxcb-present0-debuginfo-1.13-3.5.1.x86_64 libxcb-render-util0-debuginfo-0.3.9-1.23.x86_64 libxcb-render0-debuginfo-1.13-3.5.1.x86_64 libxcb-shape0-debuginfo-1.13-3.5.1.x86_64 libxcb-shm0-debuginfo-1.13-3.5.1.x86_64 libxcb-sync1-debuginfo-1.13-3.5.1.x86_64 libxcb-util1-debuginfo-0.4.0-1.23.x86_64 libxcb-xfixes0-debuginfo-1.13-3.5.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libxkbcommon-x11-0-debuginfo-0.8.2-3.3.1.x86_64 libxml2-2-debuginfo-2.9.7-3.37.1.x86_64 libz1-debuginfo-1.2.11-3.21.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) quit A debugging session is active. Inferior 1 [process 6314] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:/usr/bin> After I opened the files /usr/lib64/vlc-beta/plugins/plugins.dat and /usr/lib64/vlc-beta/plugins/gui /libqt_plugin.so in the Leap-15.3 application KWrite I found that they had automatically each been opened in the ISO-8859-15 encoding, with ISO standing for International Organization for Standardization ( https://www.nickcarverphotography.com/blog/what-is-iso-what-does-iso-mean/ on the Internet). Some recognizable Latin letters forming English-language words could be seen in those files. And in addition lots of traditional Mandarin Chinese-language characters could be seen in those files. In writing Fortran-computer-language codes I think I often used the 8-bit Uniform Transformation Format (UTF-8) encoding, which probably often appeared in KWrite, in writing data files with usually just numbers in them and in their file names used extensions such as "IN" or dat. I understand from https://fileinfo.com/extension/so that .so files are not meant to be opened for direct viewing by probably human beings. But a puzzle for me is how the file /usr/lib64/vlc-beta/plugins/plugins.dat, which contains the strange characters in either the ISO-8859-15 or UTF-8 encoding, could properly be read by my virtual "computer." Pat On Thu, Dec 16, 2021 at 7:04 PM Lawrence Patrick Somerville < spring2014day at gmail.com> wrote: > On December 16, 2021 I could not find evidence in my Gmail (Google mail), > e-mail account's "Sent" folder of having sent the contents below this > paragraph on December 15, 2021, excepting today's correction of a December > 10, 2021 version number of the software package vlc-beta, to > packman at links2linux.de; but, except for that mistake in the version > number, I thought I did so on December 15, 2021. So I am sending those > contents the second or first time to packman at links2linux.de, but > including a correction to the December 10, 2021 version number of vlc-beta > in this electronic-mail letter. > > Hello. I have not knowingly received a reply by electronic mail (e-mail) > from anyone on the e-mailing list of packman at links2linux.de to my > November 12, 2021 e-mail letter sent to that e-mail address. > > > Question: Am I supposed to join that e-mailing list of > packman at links2linux.de in order for me to receive such a reply? > > > I suppose not. A disadvantage of my joining that e-mailing list is that if > I would join it I might receive lots of e-mail about matters irrelevant to > my current computer-software problems. Here I present additional data and > more diagnostic information than I presented on November 12, 2021, which > hopefully will "spark" more ideas helpful to me among one or more expert > readers of my electronic mail than following my November 12, 2021 e-mail > letter. > > > In a 64-bit, openSUSE, Leap-15.3, Linux operating system, which is > installed as a so-called "guest" in Virtual "Machine" (VM) in Oracle > (Corporation) VM VirtualBox, which in turn is installed in my so-called > "host," Windows 10 Home Edition operating system, I have gratefully had > success in the playing of a .mp4 (Moving or Motion Picture Experts Group, > audio layer-4) file in > vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 with the Linux > kernel 5.3.18-59.27.1-default. But in > vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 I had only the audio > signals and not the video signals in the playing of that video. And later > in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 with the Linux kernel > 5.3.18-59.37.2-default I attempted to open vlc-beta, or the Video Local > Area Network (LAN) Client (VLC) multimedia player (VLC) by double-clicking > on a desktop shortcut for it, but saw its main window only for a very brief > period of time, accompanied probably a short time later with the message > "Segmentation fault (core dumped)"; so I could not even attempt to play > that .mp4 file normally with this version of vlc-beta when using its > probably default, Qt interface. > > > I at least began the process of preparation toward having a .rpm (RedHat > package manager) file "built" for my Leap-15.3 installation using > downloaded source code for vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1 or > 20211104.b9e50b090c-pm153.10.1.16.1.x86_64 and an rpmbuild... command, but > failed in that effort due to "Failed build dependencies". I started that > kind of process also with vlc-beta-20211210.736213df13-pm153.17.1.x86_64 > by starting to obtain some software packages missing in my Leap-15.3 > installation. And that process for my Leap-15.3 installation not only > required a list of some tens of software packages; but I discovered two > other difficult factors: 1) The software package mentioned between the > parentheses of a pkgconfig(...) "response" following an rpmbuild... command > is sometimes different than the name of a software package I could obtain > from an openSUSE or Packman online repository. And I don't know for certain > if I can even obtain the exact package "requested" from somewhere on the > Internet. 2) But in a "user-friendly" way it might be that sometimes > rpmbuild might "accept" packages with names similar, but not exactly the > same as the names of the packages between the parentheses of pkgconfig(...) > (For example, I installed libnfs13, which has a name slightly different > from the name of the required package libnfs for rpmbuild....). But if > similar names would not be "accepted" by rpmbuild and I could not obtain > the exact software packages requested, in that case I don't know what I > should do to "satisfy" the "rpmbuild" computer code. > > > Rather than try to find and obtain some tens of software packages required > for the successful execution of an rpmbuild command using the downloaded > source code for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, I read > that it is possible to have such a .rpm file "built" online using the > openSUSE Build Service of the Open Build Service (OBS, > https://build.opensuse.org/ on the Internet). It seems to be reported > that such "building" could ease the action of obtaining the software > packages "required" by rpmbuild. But I have not learned how to use OBS or > tried it to make a .rpm file. But even if I would be successful in somehow > "building" such a .rpm file for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, > it is possible that it might not eliminate the segmentation faults I have > encountered, especially if it would be a change in the vlc-beta source code > which would be needed to eliminate such segmentation faults. > > > Although the .rpm installation file for version > 20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 of the software package > vlc-beta is probably unfortunately no longer available from > http://packman.links2linux.de/package/vlc-beta or > https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/Multimedia/x86_64/, > fortunately I have the capability to restore my Leap-15.3 installation, > including the installation of > vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 in it, from a > previously written backup of the data on my Dell notebook computer's > internal hard-disk drive. For a period of time I was able to "lock" or > protect that version of vlc-beta, which has worked well for me, from being > updated to a newer version of vlc-beta, which thus far has not worked for > me when using its Qt interface. However, considering the likely future > updates to some software packages and the Linux kernel elsewhere in my > Leap-15.3 installation, the arrangement of > vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 working well with > a number of newer software packages might at some time in the future no > longer be a mutually well-working arrangement for me. At least by the time > of an upgrade from version 15.3 to version 15.4 of Leap on or after June 8, > 2022, there could be a possible software mismatch, since according to > http://packman.links2linux.de/package/vlc-beta the version > vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 saved in my > hard-disk drive's backup data is reported to be suitable for a Leap-15.3 > installation. So I have been attempting to find some way to make the > version of vlc-beta released to the public on December 6, 2021, namely > vlc-beta-20211210.736213df13-pm153.17.1.x86_64, work in my Leap-15.3 > installation. And the hope would be that after having made it to work in my > Leap-15.3 installation that making later versions of vlc-beta to work in my > Leap-15.3 installation might be easier than now for vlc-beta-20211210.7 > 36213df13-pm153.17.1.x86_64. > > > I have been able to play a .mp4 file in vlc-beta-20211210.736213df13 > -pm153.17.1.x86_64 using a command of the form "vlc -I dummy > FILE_NAME.mp4" in a directory containing the file with a name of the form > FILE_NAME.mp4. Otherwise entering the command "vlc" or "gdb vlc", using the > GNU's Not Unix (GNU) debugger (gdb), in the directory /usr/bin resulted in > the main window for vlc-beta opening, but with most of it transparent; then > very soon afterward I received the message "Segmentation fault (core > dumped)". Those same two things occurred after I entered the command "vlc > -I qt" in the directory /usr/bin. So my current problem is associated with > Qt and the main window of vlc-beta, not the so-called "dummy interface" of > vlc-beta. If the "menu" items and/or software controls on vlc-beta's main > window are considered plugins, then it appears to me that the problem is in > displaying those items on vlc-beta's main window. But in vlc-beta's code > and its output and on the Internet this main window is called the main > interface; or Qt has been called the default interface for VLC on > https://wiki.videolan.org/Qt_Interface/. In some of my past executions of > "vlc" I have seen the output "ReferenceError: mainInterface is not defined," > but not on December 15, 2021, after having installed lots of software > packages relating to the display protocol Wayland ( > https://www.maketecheasier.com/what-is-wayland/) and/or the widget "tool > kit" Qt, version 5, for making graphical user interfaces and applications > suitable for use in various computer operating systems, which are otherwise > called platforms [https://en.wikipedia.org/wiki/Qt_(software)]. > > > Here is a listing of my virtual computer's "hardware" in my Leap-15.3 > installation in VirtualBox on December 15, 2021. > > > newbie at linux-hdi0:/usr/bin> inxi -G > > Graphics: > > Device-1: InnoTek Systemberatung VirtualBox Graphics Adapter > > driver: vboxvideo v: 6.1.30 r148432 > > Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa > > resolution: 1308x600 > > OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 20.2.4 > > newbie at linux-hdi0:/usr/bin> > > > And here is a list of the online repositories to which I currently have > set up access in my Leap-15.3 installation when it is online. To obtain > this list I entered the command "zypper repos" as a "root" user. > > > linux-hdi0:/usr/bin # zypper repos > > Repository priorities are without effect. All enabled repositories share > the same priority. > > > # | Alias | Name | Enabled | GPG Check | Refresh > > > ---+----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+-------- > > 1 | http-ftp.gwdg.de-2f96c871 | Packman Repository | Yes | (r ) Yes | Yes > > 2 | http-opensuse-guide.org-46cfd2d4 | libdvdcss repository | Yes | (r ) > Yes | Yes > > 3 | openSUSE-Leap-15.3-1 | openSUSE-Leap-15.3-1 | Yes | (r ) Yes | No > > 4 | repo-backports-debug-update | Update repository with updates for > openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- > > 5 | repo-backports-update | Update repository of openSUSE Backports | Yes > | (r ) Yes | Yes > > 6 | repo-debug | Debug Repository | No | ---- | ---- > > 7 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- > > 8 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- > > 9 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | > ---- | ---- > > 10 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes > > 11 | repo-oss | Main Repository | Yes | (r ) Yes | Yes > > 12 | repo-sle-debug-update | Update repository with debuginfo for updates > from SUSE Linux Enterprise 15 | No | ---- | ---- > > 13 | repo-sle-update | Update repository with updates from SUSE Linux > Enterprise 15 | Yes | (r ) Yes | Yes > > 14 | repo-source | Source Repository | No | ---- | ---- > > 15 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes > > 16 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | > Yes > > linux-hdi0:/usr/bin # > > > With the help of a good teaching video on how to use the GNU’s Not Unix > (GNU) debugger (gdb) on https://www.youtube.com/watch?v=bWH-nL7v5F4, by > Doctor Chris Bourke of the University of Nebraska in Lincoln, Nebraska, The > United States of America, I was able to proceed, statement-by-statement, in > some of vlc-beta’s computer code with those statements looking to me like > C-language statements, but more often looking like C-programming-language > statements if I omitted the command within gdb of “layout next”; otherwise > after entering the command “layout next” on December 14, 2021 I saw a > number of lines in an upper panel each containing a hexadecimal address, a > short word or phrase like “mov”, “test”, “call”, “je”, et cetera (Maybe it > was assembly language??? But perhaps things looked strange instead of like > C-language statements because I was missing some installed debugging > packages, as the output below seemed to indicate.) Below the input “n” > stands for “next” to instruct the computer program to go to the next > statement to execute it in the computer code. So below are the results of > some exploring of mine with vlc-beta on December 15, 2021 using the gdb. > Despite "vlc" instead of vlc-beta appearing in the first command below, it > is for vlc-beta. And I removed all of the VLC computer software and the > VLC-based computer program caffeine from openSUSE in my Leap-15.3 > installation. Instead I have vlc-beta computer software from the Packman > online repository installed in my Leap-15.3 installation. > > > newbie at linux-hdi0:~> gdb vlc > > GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 > > Copyright (C) 2021 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "x86_64-suse-linux". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > . > > Find the GDB manual and other documentation resources online at: > > . > > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from vlc... > > Reading symbols from > /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... > > (gdb) break libvlc_add_intf > > Breakpoint 1 at 0x1140 > > (gdb) run > > Starting program: /usr/bin/vlc > > Missing separate debuginfos, use: zypper install > glibc-debuginfo-2.31-9.6.1.x86_64 > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib64/libthread_db.so.1". > > VLC media player 20211210 Otto Chriek (revision 736213df13) > > [New Thread 0x7ffff7f16700 (LWP 4794)] > > [New Thread 0x7ffff4470700 (LWP 4795)] > > [New Thread 0x7ffff436f700 (LWP 4796)] > > [New Thread 0x7ffff426e700 (LWP 4797)] > > [New Thread 0x7ffff416d700 (LWP 4798)] > > [New Thread 0x7ffff2576700 (LWP 4799)] > > [New Thread 0x7fffedd75700 (LWP 4800)] > > [New Thread 0x7fffeda5f700 (LWP 4801)] > > > Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf > (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at > playlist.c:40 > > 40 { > > Missing separate debuginfos, use: zypper install > libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 > libcap2-debuginfo-2.26-4.6.1.x86_64 > libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 > libgpg-error0-debuginfo-1.29-1.8.x86_64 > libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 > liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 > libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 > libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 > libspeex1-debuginfo-1.2-3.3.1.x86_64 > libsystemd0-debuginfo-246.16-7.21.1.x86_64 > libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 > libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 > libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 > > (gdb) n > > 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) > > (gdb) print *p_instance > > $1 = {p_libvlc_int = 0x55555575dc40, ref_count = {refs = 1}, > > p_callback_list = 0x0, log = {cb = 0x0, data = 0x0}, dialog = {cbs = { > > pf_display_error = 0x0, pf_display_login = 0x0, > > pf_display_question = 0x0, pf_display_progress = 0x0, pf_cancel = 0x0, > > pf_update_progress = 0x0}, data = 0x0}} > > (gdb) print *Quit > > (gdb) print *0x55555575dc40 > > $2 = 1433787704 > > (gdb) print *p_libvlc_int > > No symbol "p_libvlc_int" in current context. > > (gdb) print name > > $3 = 0x0 > > (gdb) print p_libvlc_int > > No symbol "p_libvlc_int" in current context. > > (gdb) print *0x0 > > Cannot access memory at address 0x0 > > (gdb) quit > > A debugging session is active. > > > Inferior 1 [process 4790] will be killed. > > > Quit anyway? (y or n) y > > newbie at linux-hdi0:~> > > > With some repetition, but going farther along than in the above sequence > of entries: > > > newbie at linux-hdi0:/usr/bin> gdb vlc > > GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 > > Copyright (C) 2021 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later < > http://gnu.org/licenses/gpl.html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > Type "show copying" and "show warranty" for details. > > This GDB was configured as "x86_64-suse-linux". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > . > > Find the GDB manual and other documentation resources online at: > > . > > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from vlc... > > Reading symbols from > /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... > > (gdb) break libvlc_add_intf > > Breakpoint 1 at 0x1140 > > (gdb) run > > Starting program: /usr/bin/vlc > > Missing separate debuginfos, use: zypper install > glibc-debuginfo-2.31-9.6.1.x86_64 > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib64/libthread_db.so.1". > > VLC media player 20211210 Otto Chriek (revision 736213df13) > > [New Thread 0x7ffff7f16700 (LWP 6320)] > > [New Thread 0x7ffff4470700 (LWP 6321)] > > [New Thread 0x7ffff436f700 (LWP 6322)] > > [New Thread 0x7ffff426e700 (LWP 6323)] > > [New Thread 0x7ffff416d700 (LWP 6324)] > > [New Thread 0x7ffff2576700 (LWP 6325)] > > [New Thread 0x7ffff1d75700 (LWP 6326)] > > [New Thread 0x7ffff1a5f700 (LWP 6327)] > > > Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf > (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at > playlist.c:40 > > 40 { > > Missing separate debuginfos, use: zypper install > libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 > libcap2-debuginfo-2.26-4.6.1.x86_64 > libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 > libgpg-error0-debuginfo-1.29-1.8.x86_64 > libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 > liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 > libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 > libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 > libspeex1-debuginfo-1.2-3.3.1.x86_64 > libsystemd0-debuginfo-246.16-7.21.1.x86_64 > libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 > libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 > libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 > > (gdb) n > > 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) > > (gdb) n > > 40 { > > (gdb) n > > 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) > > (gdb) n > > n[000055555575dc40] main libvlc: Running vlc with the default interface. > Use 'cvlc' to use vlc without interface. > > [Detaching after vfork from child process 6328] > > [New Thread 0x7ffff0152700 (LWP 6335)] > > [New Thread 0x7fffcbe1f700 (LWP 6336)] > > [New Thread 0x7fffc1e03700 (LWP 6337)] > > [New Thread 0x7fffc1602700 (LWP 6338)] > > [New Thread 0x7fffc0e01700 (LWP 6339)] > > [New Thread 0x7fffb3dd5700 (LWP 6340)] > > [New Thread 0x7fffb26ad700 (LWP 6341)] > > [New Thread 0x7fff9bbfd700 (LWP 6342)] > > [New Thread 0x7fff9b3fc700 (LWP 6343)] > > [New Thread 0x7fff9abfb700 (LWP 6344)] > > [New Thread 0x7fff9a3fa700 (LWP 6345)] > > [New Thread 0x7fff99bf9700 (LWP 6346)] > > [New Thread 0x7fff993f8700 (LWP 6347)] > > [New Thread 0x7fff98bf7700 (LWP 6348)] > > [New Thread 0x7fff83fff700 (LWP 6349)] > > [New Thread 0x7fff837fe700 (LWP 6350)] > > [New Thread 0x7fff81ca4700 (LWP 6351)] > > 50 } > > Missing separate debuginfos, use: zypper install > Mesa-dri-debuginfo-20.2.4-57.12.x86_64 > Mesa-libGL1-debuginfo-20.2.4-57.13.x86_64 > Mesa-libglapi0-debuginfo-20.2.4-57.13.x86_64 > dbus-1-glib-debuginfo-0.108-1.29.x86_64 > fcitx-qt5-debuginfo-1.2.5-bp153.2.2.1.x86_64 > fontconfig-debuginfo-2.12.6-4.3.1.x86_64 gconf2-debuginfo-3.2.6-9.26.x86_64 > gsettings-backend-dconf-debuginfo-0.34.0-2.27.x86_64 > gtk2-theming-engine-adwaita-debuginfo-3.22.3-4.3.1.x86_64 > gvfs-debuginfo-1.42.2-4.24.x86_64 > kimageformats-debuginfo-5.76.0-bp153.3.2.1.x86_64 > libHalf23-debuginfo-2.2.1-1.17.x86_64 > libIex-2_2-23-debuginfo-2.2.1-1.17.x86_64 > libIlmImf-2_2-23-debuginfo-2.2.1-3.38.1.x86_64 > libIlmThread-2_2-23-debuginfo-2.2.1-1.17.x86_64 > libKF5Archive5-debuginfo-5.76.0-bp153.2.2.1.x86_64 > libLLVM11-debuginfo-11.0.1-1.26.x86_64 > libQt5Core5-debuginfo-5.12.7-4.12.2.x86_64 > libQt5DBus5-debuginfo-5.12.7-4.12.2.x86_64 > libQt5Gui5-debuginfo-5.12.7-4.12.2.x86_64 > libQt5Network5-debuginfo-5.12.7-4.12.2.x86_64 > libQt5QuickControls2-5-debuginfo-5.12.7-1.53.x86_64 > libQt5Svg5-debuginfo-5.12.7-3.3.1.x86_64 > libQt5Widgets5-debuginfo-5.12.7-4.12.2.x86_64 > libQt5X11Extras5-debuginfo-5.12.7-1.49.x86_64 > libQtQuick5-debuginfo-5.12.7-4.2.1.x86_64 > libSM6-debuginfo-1.2.2-1.23.x86_64 > libX11-xcb1-debuginfo-1.6.5-3.21.1.x86_64 > libXcomposite1-debuginfo-0.4.4-1.23.x86_64 > libXcursor1-debuginfo-1.1.15-1.18.x86_64 > libXext6-debuginfo-1.3.3-1.30.x86_64 libXi6-debuginfo-1.7.9-3.2.1.x86_64 > libXinerama1-debuginfo-1.1.3-1.22.x86_64 > libXrandr2-debuginfo-1.5.1-2.17.x86_64 > libXrender1-debuginfo-0.9.10-1.30.x86_64 > libblkid1-debuginfo-2.36.2-4.5.1.x86_64 > libbz2-1-debuginfo-1.0.6-5.11.1.x86_64 > libcairo2-debuginfo-1.16.0-1.55.x86_64 > libcanberra-gtk0-debuginfo-0.30-3.2.3.x86_64 > libcanberra-gtk2-module-debuginfo-0.30-3.2.3.x86_64 > libdatrie1-debuginfo-0.2.9-1.25.x86_64 > libdouble-conversion3-debuginfo-3.1.5-3.2.1.x86_64 > libdrm_nouveau2-debuginfo-2.4.104-1.12.x86_64 > libdrm_radeon1-debuginfo-2.4.104-1.12.x86_64 > libedit0-debuginfo-3.1.snap20150325-2.12.x86_64 > libelf1-debuginfo-0.168-4.5.3.x86_64 libexpat1-debuginfo-2.2.5-3.6.1.x86_64 > libffi7-debuginfo-3.2.1.git259-10.8.x86_64 > libfreetype6-debuginfo-2.10.1-4.8.1.x86_64 > libfribidi0-debuginfo-1.0.5-3.3.1.x86_64 > libgcc_s1-debuginfo-11.2.1+git610-1.3.9.x86_64 > libglib-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 > libglvnd-debuginfo-1.3.2-1.49.x86_64 > libgobject-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 > libgtk-2_0-0-debuginfo-2.24.32+67-2.28.x86_64 > libharfbuzz0-debuginfo-2.6.4-1.56.x86_64 > libicu-suse65_1-debuginfo-65.1-4.2.1.x86_64 > libjasper4-debuginfo-2.0.14-3.19.1.x86_64 > libjbig2-debuginfo-2.1-1.31.x86_64 libjpeg8-debuginfo-8.1.2-5.18.1.x86_64 > liblcms2-2-debuginfo-2.9-3.3.1.x86_64 libltdl7-debuginfo-2.4.6-3.4.1.x86_64 > libmodman1-debuginfo-2.0.1-1.27.x86_64 > libmount1-debuginfo-2.36.2-4.5.1.x86_64 > libopenssl1_1-debuginfo-1.1.1d-11.30.1.x86_64 > libpango-1_0-0-debuginfo-1.44.7+11-1.25.x86_64 > libpcre2-16-0-debuginfo-10.31-3.3.1.x86_64 > libpng16-16-debuginfo-1.6.34-3.9.1.x86_64 > libproxy1-debuginfo-0.4.15-12.41.x86_64 > libqt5-qtimageformats-debuginfo-5.12.7-1.50.x86_64 > libqt5-qtquickcontrols2-debuginfo-5.12.7-1.53.x86_64 > libstdc++6-debuginfo-11.2.1+git610-1.3.9.x86_64 > libthai0-debuginfo-0.1.27-1.16.x86_64 > libuuid1-debuginfo-2.36.2-4.5.1.x86_64 > libwayland-client0-debuginfo-1.18.0-1.19.x86_64 > libwebp7-debuginfo-1.0.3-1.62.x86_64 > libxcb-composite0-debuginfo-1.13-3.5.1.x86_64 > libxcb-damage0-debuginfo-1.13-3.5.1.x86_64 > libxcb-dri2-0-debuginfo-1.13-3.5.1.x86_64 > libxcb-dri3-0-debuginfo-1.13-3.5.1.x86_64 > libxcb-keysyms1-debuginfo-0.4.0-1.23.x86_64 > libxcb-present0-debuginfo-1.13-3.5.1.x86_64 > libxcb-render-util0-debuginfo-0.3.9-1.23.x86_64 > libxcb-render0-debuginfo-1.13-3.5.1.x86_64 > libxcb-shape0-debuginfo-1.13-3.5.1.x86_64 > libxcb-shm0-debuginfo-1.13-3.5.1.x86_64 > libxcb-sync1-debuginfo-1.13-3.5.1.x86_64 > libxcb-util1-debuginfo-0.4.0-1.23.x86_64 > libxcb-xfixes0-debuginfo-1.13-3.5.1.x86_64 > libxkbcommon-x11-0-debuginfo-0.8.2-3.3.1.x86_64 > libxml2-2-debuginfo-2.9.7-3.37.1.x86_64 libz1-debuginfo-1.2.11-3.21.1.x86_64 > > (gdb) n > > [Thread 0x7fffb26ad700 (LWP 6341) exited] > > main (argc=, argv=0x7fffffffdf28) at vlc.c:245 > > 245 libvlc_playlist_play (vlc); > > Missing separate debuginfos, use: zypper install > libqt5-qtgraphicaleffects-debuginfo-5.12.7-1.53.x86_64 > > (gdb) n > > 249 sigdelset (&set, SIGCHLD); > > (gdb) n > > 250 pthread_sigmask (SIG_SETMASK, &set, NULL); > > (gdb) n > > 253 if (signal_ignored (SIGHUP)) > > (gdb) n > > 256 sigdelset (&set, SIGPIPE); > > (gdb) n > > > Thread 25 "QQmlThread" received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x7fff837fe700 (LWP 6350)] > > 0x00007fffdba86613 in ?? () from /usr/lib64/libQt5Qml.so.5 > > (gdb) n > > Cannot find bounds of current function > > (gdb) n > > Cannot find bounds of current function > > (gdb) n > > Cannot find bounds of current function > > (gdb) quit > > A debugging session is active. > > > Inferior 1 [process 6316] will be killed. > > > Quit anyway? (y or n) y > > newbie at linux-hdi0:/usr/bin> > > > I tried to follow numerous other people's postings on the Internet to > enable the playing of a .mp4 file in the VLC. But unfortunately I failed in > all of those efforts with a segmentation fault using vlc-beta-20211210.7 > 36213df13-pm153.17.1.x86_64 or else with the lack of a displayed video > signal in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 when in each > case using their Qt interfaces. So please help me eliminate the > "Segmentation fault" error and to be able to play a .mp4 video in > vlc-beta-20211210.736213df13-pm153.17.1.x86_64 using its probably > default, Qt interface. > > > Pat > From robin.listas at telefonica.net Fri Dec 17 11:21:20 2021 From: robin.listas at telefonica.net (Carlos E. R.) Date: Fri, 17 Dec 2021 11:21:20 +0100 Subject: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox In-Reply-To: References: Message-ID: <102b7ff4-f033-24f5-8b02-c65300e43000@telefonica.net> On 15/12/2021 22.34, Lawrence Patrick Somerville wrote: > Hello. I have not knowingly received a reply by electronic mail (e-mail) > from anyone on the e-mailing list of packman at links2linux.de to my November > 12, 2021 e-mail letter sent to that e-mail address. > > > Question: Am I supposed to join that e-mailing list of > packman at links2linux.de in order for me to receive such a reply? Yes, you should subscribe. Reasons: 1) Many of us only reply to the list, unless you ask specifically to get a direct reply. 2) You are using gmail. I will explain the later. Gmail has the silent policy of deleting duplicate emails, ie, those that have the same Message-ID header. Thus if someone replies to the mail list and to you directly, the post that arrives second will be deleted. Thus when you send email to the mail list you will not get evidence of the email having been posted on the list, and you react by sending duplicates. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.2 (Legolas)) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From nomiya at galaxy.dti.ne.jp Fri Dec 17 12:51:03 2021 From: nomiya at galaxy.dti.ne.jp (Masaru Nomiya) Date: Fri, 17 Dec 2021 20:51:03 +0900 Subject: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox In-Reply-To: References: Message-ID: <87sfurtpp4.wl-nomiya@galaxy.dti.ne.jp> Hello, In the Message; Subject : Re: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox Message-ID : Date & Time: Thu, 16 Dec 2021 19:06:29 -0500 [LPS] == Lawrence Patrick Somerville has written: [...] LPS> > I tried to follow numerous other people's postings on the Internet to LPS> > enable the playing of a .mp4 file in the VLC. But unfortunately I failed in LPS> > all of those efforts with a segmentation fault using vlc-beta-20211210.7 LPS> > 36213df13-pm153.17.1.x86_64 or else with the lack of a displayed video LPS> > signal in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 when in each LPS> > case using their Qt interfaces. So please help me eliminate the LPS> > "Segmentation fault" error and to be able to play a .mp4 video in LPS> > vlc-beta-20211210.736213df13-pm153.17.1.x86_64 using its probably LPS> > default, Qt interface. Please show the result of; $ mediainfo FILE_NAME.mp4 Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Tim Cook, the C.E.O. of Apple, said earlier this year that he would not let his nephew join social networks. Bill Gates banned cellphone until his children were teenagers, and Melinda Gates wrote that she wished they had waited even longer. Steve Jobs would not let his young children near iPads." -- The New York Times -- From spring2014day at gmail.com Fri Dec 17 19:19:20 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Fri, 17 Dec 2021 13:19:20 -0500 Subject: [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: Hello. In a 64-bit, openSUSE, Leap-15.3, Linux operating system, which is installed as a so-called "guest" in Virtual "Machine" (VM) in Oracle (Corporation) VM VirtualBox, which in turn is installed in my so-called "host," Windows 10 Home Edition operating system, I have gratefully had success in the playing of a .mp4 (Moving or Motion Picture Experts Group, audio layer-4) file in vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 with the Linux kernel 5.3.18-59.27.1-default. But in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 I had only the audio signals and not the video signals in the playing of that video. And later in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 with the Linux kernel 5.3.18-59.37.2-default I attempted to open vlc-beta, or the Video Local Area Network (LAN) Client (VLC) multimedia player (VLC) by double-clicking on a desktop shortcut for it, but saw its main window only for a very brief period of time, accompanied probably a short time later with the message "Segmentation fault (core dumped)"; so I could not even attempt to play that .mp4 file normally with this version of vlc-beta when using its probably default, Qt interface. I at least began the process of preparation toward having a .rpm (RedHat package manager) file "built" for my Leap-15.3 installation using downloaded source code for vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1 or 20211104.b9e50b090c-pm153.10.1.16.1.x86_64 and an rpmbuild... command, but failed in that effort due to "Failed build dependencies". I started that kind of process also with vlc-beta-20211210.736213df13-pm153.17.1.x86_64 by starting to obtain some software packages missing in my Leap-15.3 installation. And that process for my Leap-15.3 installation not only required a list of some tens of software packages; but I discovered two other difficult factors: 1) The software package mentioned between the parentheses of a pkgconfig(...) "response" following an rpmbuild... command is sometimes different than the name of a software package I could obtain from an openSUSE or Packman online repository. And I don't know for certain if I can even obtain the exact package "requested" from somewhere on the Internet. 2) But in a "user-friendly" way it might be that sometimes rpmbuild might "accept" packages with names similar, but not exactly the same as the names of the packages between the parentheses of pkgconfig(...) (For example, I installed libnfs13, which has a name slightly different from the name of the required package libnfs for rpmbuild....). But if similar names would not be "accepted" by rpmbuild and I could not obtain the exact software packages requested, in that case I don't know what I should do to "satisfy" the "rpmbuild" computer code. Rather than try to find and obtain some tens of software packages required for the successful execution of an rpmbuild command using the downloaded source code for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, I read that it is possible to have such a .rpm file "built" online using the openSUSE Build Service of the Open Build Service (OBS, https://build.opensuse.org/ on the Internet). It seems to be reported that such "building" could ease the action of obtaining the software packages "required" by rpmbuild. But I have not learned how to use OBS or tried it to make a .rpm file. But even if I would be successful in somehow "building" such a .rpm file for vlc-beta-20211210.736213df13-pm153.17.1.x86_64, it is possible that it might not eliminate the segmentation faults I have encountered, especially if it would be a change in the vlc-beta source code which would be needed to eliminate such segmentation faults. Although the .rpm installation file for version 20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 of the software package vlc-beta is probably unfortunately no longer available from http://packman.links2linux.de/package/vlc-beta or https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Leap_15.3/Multimedia/x86_64/, fortunately I have the capability to restore my Leap-15.3 installation, including the installation of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 in it, from a previously written backup of the data on my Dell notebook computer's internal hard-disk drive. For a period of time I was able to "lock" or protect that version of vlc-beta, which has worked well for me, from being updated to a newer version of vlc-beta, which thus far has not worked for me when using its Qt interface. However, considering the likely future updates to some software packages and the Linux kernel elsewhere in my Leap-15.3 installation, the arrangement of vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 working well with a number of newer software packages might at some time in the future no longer be a mutually well-working arrangement for me. At least by the time of an upgrade from version 15.3 to version 15.4 of Leap on or after June 8, 2022, there could be a possible software mismatch, since according to http://packman.links2linux.de/package/vlc-beta the version vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 saved in my hard-disk drive's backup data is reported to be suitable for a Leap-15.3 installation. So I have been attempting to find some way to make the version of vlc-beta released to the public on December 6, 2021, namely vlc-beta-20211210.736213df13-pm153.17.1.x86_64, work in my Leap-15.3 installation. And the hope would be that after having made it to work in my Leap-15.3 installation that making later versions of vlc-beta to work in my Leap-15.3 installation might be easier than now for vlc-beta-20211210.736213df13-pm153.17.1.x86_64. I have been able to play a .mp4 file in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 using a command of the form "vlc -I dummy FILE_NAME.mp4" in a directory containing the file with a name of the form FILE_NAME.mp4. Otherwise entering the command "vlc" or "gdb vlc", using the GNU's Not Unix (GNU) debugger (gdb), in the directory /usr/bin resulted in the main window for vlc-beta opening, but with most of it transparent; then very soon afterward I received the message "Segmentation fault (core dumped)". Those same two things occurred after I entered the command "vlc -I qt" in the directory /usr/bin. So my current problem is associated with Qt and the main window of vlc-beta, not the so-called "dummy interface" of vlc-beta. If the "menu" items and/or software controls on vlc-beta's main window are considered plugins, then it appears to me that the problem is in displaying those items on vlc-beta's main window. But in vlc-beta's code and its output and on the Internet this main window is called the main interface; or Qt has been called the default interface for VLC on https://wiki.videolan.org/Qt_Interface/. In some of my past executions of "vlc" I have seen the output "ReferenceError: mainInterface is not defined," but not on December 15, 2021, after having installed lots of software packages relating to the display protocol Wayland (https://www.maketecheasier.com/what-is-wayland/) and/or the widget "tool kit" Qt, version 5, for making graphical user interfaces and applications suitable for use in various computer operating systems, which are otherwise called platforms [https://en.wikipedia.org/wiki/Qt_(software )]. Here is a listing of my virtual computer's "hardware" in my Leap-15.3 installation in VirtualBox on December 15, 2021. newbie at linux-hdi0:/usr/bin> inxi -G Graphics: Device-1: InnoTek Systemberatung VirtualBox Graphics Adapter driver: vboxvideo v: 6.1.30 r148432 Display: x11 server: X.Org 1.20.3 driver: modesetting unloaded: fbdev,vesa resolution: 1308x600 OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 20.2.4 newbie at linux-hdi0:/usr/bin> And here is a list of the online repositories to which I currently have set up access in my Leap-15.3 installation when it is online. To obtain this list I entered the command "zypper repos" as a "root" user. linux-hdi0:/usr/bin # zypper repos Repository priorities are without effect. All enabled repositories share the same priority. # | Alias | Name | Enabled | GPG Check | Refresh ---+----------------------------------+---------------------------------------------------------------------------------------------+---------+-----------+-------- 1 | http-ftp.gwdg.de-2f96c871 | Packman Repository | Yes | (r ) Yes | Yes 2 | http-opensuse-guide.org-46cfd2d4 | libdvdcss repository | Yes | (r ) Yes | Yes 3 | openSUSE-Leap-15.3-1 | openSUSE-Leap-15.3-1 | Yes | (r ) Yes | No 4 | repo-backports-debug-update | Update repository with updates for openSUSE Leap debuginfo packages from openSUSE Backports | No | ---- | ---- 5 | repo-backports-update | Update repository of openSUSE Backports | Yes | (r ) Yes | Yes 6 | repo-debug | Debug Repository | No | ---- | ---- 7 | repo-debug-non-oss | Debug Repository (Non-OSS) | No | ---- | ---- 8 | repo-debug-update | Update Repository (Debug) | No | ---- | ---- 9 | repo-debug-update-non-oss | Update Repository (Debug, Non-OSS) | No | ---- | ---- 10 | repo-non-oss | Non-OSS Repository | Yes | (r ) Yes | Yes 11 | repo-oss | Main Repository | Yes | (r ) Yes | Yes 12 | repo-sle-debug-update | Update repository with debuginfo for updates from SUSE Linux Enterprise 15 | No | ---- | ---- 13 | repo-sle-update | Update repository with updates from SUSE Linux Enterprise 15 | Yes | (r ) Yes | Yes 14 | repo-source | Source Repository | No | ---- | ---- 15 | repo-update | Main Update Repository | Yes | (r ) Yes | Yes 16 | repo-update-non-oss | Update Repository (Non-Oss) | Yes | (r ) Yes | Yes linux-hdi0:/usr/bin # With the help of a good teaching video on how to use the GNU’s Not Unix (GNU) debugger (gdb) on https://www.youtube.com/watch?v=bWH-nL7v5F4, by Doctor Chris Bourke of the University of Nebraska in Lincoln, Nebraska, The United States of America, I was able to proceed, statement-by-statement, in some of vlc-beta’s computer code with those statements looking to me like C-language statements, but more often looking like C-programming-language statements if I omitted the command within gdb of “layout next”; otherwise after entering the command “layout next” on December 14, 2021 I saw a number of lines in an upper panel each containing a hexadecimal address, a short word or phrase like “mov”, “test”, “call”, “je”, et cetera (Maybe it was assembly language??? But perhaps things looked strange instead of like C-language statements because I was missing some installed debugging packages, as the output below seemed to indicate.) Below the input “n” stands for “next” to instruct the computer program to go to the next statement to execute it in the computer code. So below are the results of some exploring of mine with vlc-beta on December 15, 2021 using the gdb. Despite "vlc" instead of vlc-beta appearing in the first command below, it is for vlc-beta. And I removed all of the VLC computer software and the VLC-based computer program caffeine from openSUSE in my Leap-15.3 installation. Instead I have vlc-beta computer software from the Packman online repository installed in my Leap-15.3 installation. newbie at linux-hdi0:~> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break libvlc_add_intf Breakpoint 1 at 0x1140 (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 4794)] [New Thread 0x7ffff4470700 (LWP 4795)] [New Thread 0x7ffff436f700 (LWP 4796)] [New Thread 0x7ffff426e700 (LWP 4797)] [New Thread 0x7ffff416d700 (LWP 4798)] [New Thread 0x7ffff2576700 (LWP 4799)] [New Thread 0x7fffedd75700 (LWP 4800)] [New Thread 0x7fffeda5f700 (LWP 4801)] Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at playlist.c:40 40 { Missing separate debuginfos, use: zypper install libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) print *p_instance $1 = {p_libvlc_int = 0x55555575dc40, ref_count = {refs = 1}, p_callback_list = 0x0, log = {cb = 0x0, data = 0x0}, dialog = {cbs = { pf_display_error = 0x0, pf_display_login = 0x0, pf_display_question = 0x0, pf_display_progress = 0x0, pf_cancel = 0x0, pf_update_progress = 0x0}, data = 0x0}} (gdb) print *Quit (gdb) print *0x55555575dc40 $2 = 1433787704 (gdb) print *p_libvlc_int No symbol "p_libvlc_int" in current context. (gdb) print name $3 = 0x0 (gdb) print p_libvlc_int No symbol "p_libvlc_int" in current context. (gdb) print *0x0 Cannot access memory at address 0x0 (gdb) quit A debugging session is active. Inferior 1 [process 4790] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:~> With some repetition, but going farther along than in the above sequence of entries: newbie at linux-hdi0:/usr/bin> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break libvlc_add_intf Breakpoint 1 at 0x1140 (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 6320)] [New Thread 0x7ffff4470700 (LWP 6321)] [New Thread 0x7ffff436f700 (LWP 6322)] [New Thread 0x7ffff426e700 (LWP 6323)] [New Thread 0x7ffff416d700 (LWP 6324)] [New Thread 0x7ffff2576700 (LWP 6325)] [New Thread 0x7ffff1d75700 (LWP 6326)] [New Thread 0x7ffff1a5f700 (LWP 6327)] Thread 1 "vlc" hit Breakpoint 1, libvlc_add_intf (p_instance=p_instance at entry=0x55555575dbd0, name=name at entry=0x0) at playlist.c:40 40 { Missing separate debuginfos, use: zypper install libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) n 40 { (gdb) n 41 if( libvlc_InternalAddIntf( p_instance->p_libvlc_int, name )) (gdb) n n[000055555575dc40] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [Detaching after vfork from child process 6328] [New Thread 0x7ffff0152700 (LWP 6335)] [New Thread 0x7fffcbe1f700 (LWP 6336)] [New Thread 0x7fffc1e03700 (LWP 6337)] [New Thread 0x7fffc1602700 (LWP 6338)] [New Thread 0x7fffc0e01700 (LWP 6339)] [New Thread 0x7fffb3dd5700 (LWP 6340)] [New Thread 0x7fffb26ad700 (LWP 6341)] [New Thread 0x7fff9bbfd700 (LWP 6342)] [New Thread 0x7fff9b3fc700 (LWP 6343)] [New Thread 0x7fff9abfb700 (LWP 6344)] [New Thread 0x7fff9a3fa700 (LWP 6345)] [New Thread 0x7fff99bf9700 (LWP 6346)] [New Thread 0x7fff993f8700 (LWP 6347)] [New Thread 0x7fff98bf7700 (LWP 6348)] [New Thread 0x7fff83fff700 (LWP 6349)] [New Thread 0x7fff837fe700 (LWP 6350)] [New Thread 0x7fff81ca4700 (LWP 6351)] 50 } Missing separate debuginfos, use: zypper install Mesa-dri-debuginfo-20.2.4-57.12.x86_64 Mesa-libGL1-debuginfo-20.2.4-57.13.x86_64 Mesa-libglapi0-debuginfo-20.2.4-57.13.x86_64 dbus-1-glib-debuginfo-0.108-1.29.x86_64 fcitx-qt5-debuginfo-1.2.5-bp153.2.2.1.x86_64 fontconfig-debuginfo-2.12.6-4.3.1.x86_64 gconf2-debuginfo-3.2.6-9.26.x86_64 gsettings-backend-dconf-debuginfo-0.34.0-2.27.x86_64 gtk2-theming-engine-adwaita-debuginfo-3.22.3-4.3.1.x86_64 gvfs-debuginfo-1.42.2-4.24.x86_64 kimageformats-debuginfo-5.76.0-bp153.3.2.1.x86_64 libHalf23-debuginfo-2.2.1-1.17.x86_64 libIex-2_2-23-debuginfo-2.2.1-1.17.x86_64 libIlmImf-2_2-23-debuginfo-2.2.1-3.38.1.x86_64 libIlmThread-2_2-23-debuginfo-2.2.1-1.17.x86_64 libKF5Archive5-debuginfo-5.76.0-bp153.2.2.1.x86_64 libLLVM11-debuginfo-11.0.1-1.26.x86_64 libQt5Core5-debuginfo-5.12.7-4.12.2.x86_64 libQt5DBus5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Gui5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Network5-debuginfo-5.12.7-4.12.2.x86_64 libQt5QuickControls2-5-debuginfo-5.12.7-1.53.x86_64 libQt5Svg5-debuginfo-5.12.7-3.3.1.x86_64 libQt5Widgets5-debuginfo-5.12.7-4.12.2.x86_64 libQt5X11Extras5-debuginfo-5.12.7-1.49.x86_64 libQtQuick5-debuginfo-5.12.7-4.2.1.x86_64 libSM6-debuginfo-1.2.2-1.23.x86_64 libX11-xcb1-debuginfo-1.6.5-3.21.1.x86_64 libXcomposite1-debuginfo-0.4.4-1.23.x86_64 libXcursor1-debuginfo-1.1.15-1.18.x86_64 libXext6-debuginfo-1.3.3-1.30.x86_64 libXi6-debuginfo-1.7.9-3.2.1.x86_64 libXinerama1-debuginfo-1.1.3-1.22.x86_64 libXrandr2-debuginfo-1.5.1-2.17.x86_64 libXrender1-debuginfo-0.9.10-1.30.x86_64 libblkid1-debuginfo-2.36.2-4.5.1.x86_64 libbz2-1-debuginfo-1.0.6-5.11.1.x86_64 libcairo2-debuginfo-1.16.0-1.55.x86_64 libcanberra-gtk0-debuginfo-0.30-3.2.3.x86_64 libcanberra-gtk2-module-debuginfo-0.30-3.2.3.x86_64 libdatrie1-debuginfo-0.2.9-1.25.x86_64 libdouble-conversion3-debuginfo-3.1.5-3.2.1.x86_64 libdrm_nouveau2-debuginfo-2.4.104-1.12.x86_64 libdrm_radeon1-debuginfo-2.4.104-1.12.x86_64 libedit0-debuginfo-3.1.snap20150325-2.12.x86_64 libelf1-debuginfo-0.168-4.5.3.x86_64 libexpat1-debuginfo-2.2.5-3.6.1.x86_64 libffi7-debuginfo-3.2.1.git259-10.8.x86_64 libfreetype6-debuginfo-2.10.1-4.8.1.x86_64 libfribidi0-debuginfo-1.0.5-3.3.1.x86_64 libgcc_s1-debuginfo-11.2.1+git610-1.3.9.x86_64 libglib-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libglvnd-debuginfo-1.3.2-1.49.x86_64 libgobject-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libgtk-2_0-0-debuginfo-2.24.32+67-2.28.x86_64 libharfbuzz0-debuginfo-2.6.4-1.56.x86_64 libicu-suse65_1-debuginfo-65.1-4.2.1.x86_64 libjasper4-debuginfo-2.0.14-3.19.1.x86_64 libjbig2-debuginfo-2.1-1.31.x86_64 libjpeg8-debuginfo-8.1.2-5.18.1.x86_64 liblcms2-2-debuginfo-2.9-3.3.1.x86_64 libltdl7-debuginfo-2.4.6-3.4.1.x86_64 libmodman1-debuginfo-2.0.1-1.27.x86_64 libmount1-debuginfo-2.36.2-4.5.1.x86_64 libopenssl1_1-debuginfo-1.1.1d-11.30.1.x86_64 libpango-1_0-0-debuginfo-1.44.7+11-1.25.x86_64 libpcre2-16-0-debuginfo-10.31-3.3.1.x86_64 libpng16-16-debuginfo-1.6.34-3.9.1.x86_64 libproxy1-debuginfo-0.4.15-12.41.x86_64 libqt5-qtimageformats-debuginfo-5.12.7-1.50.x86_64 libqt5-qtquickcontrols2-debuginfo-5.12.7-1.53.x86_64 libstdc++6-debuginfo-11.2.1+git610-1.3.9.x86_64 libthai0-debuginfo-0.1.27-1.16.x86_64 libuuid1-debuginfo-2.36.2-4.5.1.x86_64 libwayland-client0-debuginfo-1.18.0-1.19.x86_64 libwebp7-debuginfo-1.0.3-1.62.x86_64 libxcb-composite0-debuginfo-1.13-3.5.1.x86_64 libxcb-damage0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri2-0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri3-0-debuginfo-1.13-3.5.1.x86_64 libxcb-keysyms1-debuginfo-0.4.0-1.23.x86_64 libxcb-present0-debuginfo-1.13-3.5.1.x86_64 libxcb-render-util0-debuginfo-0.3.9-1.23.x86_64 libxcb-render0-debuginfo-1.13-3.5.1.x86_64 libxcb-shape0-debuginfo-1.13-3.5.1.x86_64 libxcb-shm0-debuginfo-1.13-3.5.1.x86_64 libxcb-sync1-debuginfo-1.13-3.5.1.x86_64 libxcb-util1-debuginfo-0.4.0-1.23.x86_64 libxcb-xfixes0-debuginfo-1.13-3.5.1.x86_64 libxkbcommon-x11-0-debuginfo-0.8.2-3.3.1.x86_64 libxml2-2-debuginfo-2.9.7-3.37.1.x86_64 libz1-debuginfo-1.2.11-3.21.1.x86_64 (gdb) n [Thread 0x7fffb26ad700 (LWP 6341) exited] main (argc=, argv=0x7fffffffdf28) at vlc.c:245 245 libvlc_playlist_play (vlc); Missing separate debuginfos, use: zypper install libqt5-qtgraphicaleffects-debuginfo-5.12.7-1.53.x86_64 (gdb) n 249 sigdelset (&set, SIGCHLD); (gdb) n 250 pthread_sigmask (SIG_SETMASK, &set, NULL); (gdb) n 253 if (signal_ignored (SIGHUP)) (gdb) n 256 sigdelset (&set, SIGPIPE); (gdb) n Thread 25 "QQmlThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff837fe700 (LWP 6350)] 0x00007fffdba86613 in ?? () from /usr/lib64/libQt5Qml.so.5 (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) quit A debugging session is active. Inferior 1 [process 6316] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:/usr/bin> I tried to follow numerous other people's postings on the Internet to enable the playing of a .mp4 file in the VLC. But unfortunately I failed in all of those efforts with a segmentation fault using vlc-beta-20211210.736213df13-pm153.17.1.x86_64 or else with the lack of a displayed video signal in vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 when in each case using their Qt interfaces. So please help me eliminate the "Segmentation fault" error and to be able to play a .mp4 video in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 using its probably default, Qt interface. I discovered that there was a folder /home/newbie (my user name)/.config /vlc, which had apparently been left over from previous installations of the Video LAN (Local-Area Network) Client (VLC) media or multimedia player or the VLC-based software package caffeine in my Leap-15.3 installation. So I entered the following set of commands mostly, if not entirely, as a "root" user. zypper rm vlc-beta vlc-beta-debuginfo vlc-beta-debugsource I moved /home/newbie/.config /vlc to "trash", but left /usr/src/packages/BUILD, BUILDROOT, RPMS, SOURCES, SPECS, and SRPMS intact for possible .rpm (RedHat package manager) "building" from source code. It was no surprise that by this time the directories /usr/lib64/vlc-beta and /usr*/*lib/vlc-beta had disappeared. zypper refresh zypper install –repo http-ftp.gwdg.de-2f96c871 -f vlc-beta vlc-beta-debuginfo vlc-beta-debugsource , with http-ftp.gwdg.de-2f96c871 being the alias for allowing access to the Packman online repository and "f" standing for probably "force" to force those installations to occur. Afterward a surprise was that no /home/newbie/.config/vlc or vlc-beta folder was found. Below I entered the command "gdb vlc", with gdb standing for the GNU's Not Unix (GNU) debugger, and had results similar to earlier with a segmentation fault, but this time with no notification of a core dump and this time with both "Welcome -VLC media player" and "VLC media player" mostly tranparent windows appearing. newbie at linux-hdi0:/usr/bin> gdb vlc GNU gdb (GDB; SUSE Linux Enterprise 15) 11.1 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vlc... Reading symbols from /usr/lib/debug/usr/bin/vlc-20211210.736213df13-pm153.17.1.x86_64.debug... (gdb) break pf_int Function "pf_int" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) run Starting program: /usr/bin/vlc Missing separate debuginfos, use: zypper install glibc-debuginfo-2.31-9.6.1.x86_64 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". VLC media player 20211210 Otto Chriek (revision 736213df13) [New Thread 0x7ffff7f16700 (LWP 6318)] [New Thread 0x7ffff4470700 (LWP 6319)] [New Thread 0x7ffff436f700 (LWP 6320)] [New Thread 0x7ffff426e700 (LWP 6321)] [New Thread 0x7ffff416d700 (LWP 6322)] [New Thread 0x7ffff2576700 (LWP 6323)] [New Thread 0x7fffedd75700 (LWP 6324)] [New Thread 0x7fffeda5f700 (LWP 6325)] [000055555575dc40] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [Detaching after vfork from child process 6326] [New Thread 0x7fffec152700 (LWP 6333)] [New Thread 0x7fffcbe1f700 (LWP 6334)] [New Thread 0x7fffc1e03700 (LWP 6336)] [New Thread 0x7fffc1602700 (LWP 6337)] [New Thread 0x7fffc0e01700 (LWP 6338)] [New Thread 0x7fffb3dd5700 (LWP 6339)] [New Thread 0x7fffb26ad700 (LWP 6340)] [New Thread 0x7fff9bbfd700 (LWP 6341)] [New Thread 0x7fff9b3fc700 (LWP 6342)] [New Thread 0x7fff9abfb700 (LWP 6343)] [New Thread 0x7fff9a3fa700 (LWP 6344)] [New Thread 0x7fff99bf9700 (LWP 6345)] [New Thread 0x7fff993f8700 (LWP 6346)] [New Thread 0x7fff98bf7700 (LWP 6347)] [New Thread 0x7fff83fff700 (LWP 6348)] [New Thread 0x7fff837fe700 (LWP 6349)] [New Thread 0x7fff81ca4700 (LWP 6350)] Thread 25 "QQmlThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff837fe700 (LWP 6349)] 0x00007fffdba86613 in ?? () from /usr/lib64/libQt5Qml.so.5 Missing separate debuginfos, use: zypper install Mesa-dri-debuginfo-20.2.4-57.12.x86_64 Mesa-libGL1-debuginfo-20.2.4-57.13.x86_64 Mesa-libglapi0-debuginfo-20.2.4-57.13.x86_64 dbus-1-glib-debuginfo-0.108-1.29.x86_64 fcitx-qt5-debuginfo-1.2.5-bp153.2.2.1.x86_64 fontconfig-debuginfo-2.12.6-4.3.1.x86_64 gconf2-debuginfo-3.2.6-9.26.x86_64 gsettings-backend-dconf-debuginfo-0.34.0-2.27.x86_64 gtk2-theming-engine-adwaita-debuginfo-3.22.3-4.3.1.x86_64 gvfs-debuginfo-1.42.2-4.24.x86_64 kimageformats-debuginfo-5.76.0-bp153.3.2.1.x86_64 libFLAC8-debuginfo-1.3.2-3.6.1.x86_64 libHalf23-debuginfo-2.2.1-1.17.x86_64 libIex-2_2-23-debuginfo-2.2.1-1.17.x86_64 libIlmImf-2_2-23-debuginfo-2.2.1-3.38.1.x86_64 libIlmThread-2_2-23-debuginfo-2.2.1-1.17.x86_64 libKF5Archive5-debuginfo-5.76.0-bp153.2.2.1.x86_64 libLLVM11-debuginfo-11.0.1-1.26.x86_64 libQt5Core5-debuginfo-5.12.7-4.12.2.x86_64 libQt5DBus5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Gui5-debuginfo-5.12.7-4.12.2.x86_64 libQt5Network5-debuginfo-5.12.7-4.12.2.x86_64 libQt5QuickControls2-5-debuginfo-5.12.7-1.53.x86_64 libQt5Svg5-debuginfo-5.12.7-3.3.1.x86_64 libQt5Widgets5-debuginfo-5.12.7-4.12.2.x86_64 libQt5X11Extras5-debuginfo-5.12.7-1.49.x86_64 libQtQuick5-debuginfo-5.12.7-4.2.1.x86_64 libSM6-debuginfo-1.2.2-1.23.x86_64 libX11-xcb1-debuginfo-1.6.5-3.21.1.x86_64 libXau6-debuginfo-1.0.8-1.26.x86_64 libXcomposite1-debuginfo-0.4.4-1.23.x86_64 libXcursor1-debuginfo-1.1.15-1.18.x86_64 libXext6-debuginfo-1.3.3-1.30.x86_64 libXi6-debuginfo-1.7.9-3.2.1.x86_64 libXinerama1-debuginfo-1.1.3-1.22.x86_64 libXrandr2-debuginfo-1.5.1-2.17.x86_64 libXrender1-debuginfo-0.9.10-1.30.x86_64 libblkid1-debuginfo-2.36.2-4.5.1.x86_64 libbz2-1-debuginfo-1.0.6-5.11.1.x86_64 libcairo2-debuginfo-1.16.0-1.55.x86_64 libcanberra-gtk0-debuginfo-0.30-3.2.3.x86_64 libcanberra-gtk2-module-debuginfo-0.30-3.2.3.x86_64 libcap2-debuginfo-2.26-4.6.1.x86_64 libdatrie1-debuginfo-0.2.9-1.25.x86_64 libdbus-1-3-debuginfo-1.12.2-8.11.2.x86_64 libdouble-conversion3-debuginfo-3.1.5-3.2.1.x86_64 libdrm_nouveau2-debuginfo-2.4.104-1.12.x86_64 libdrm_radeon1-debuginfo-2.4.104-1.12.x86_64 libedit0-debuginfo-3.1.snap20150325-2.12.x86_64 libelf1-debuginfo-0.168-4.5.3.x86_64 libexpat1-debuginfo-2.2.5-3.6.1.x86_64 libffi7-debuginfo-3.2.1.git259-10.8.x86_64 libfreetype6-debuginfo-2.10.1-4.8.1.x86_64 libfribidi0-debuginfo-1.0.5-3.3.1.x86_64 libgcc_s1-debuginfo-11.2.1+git610-1.3.9.x86_64 libglib-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libglvnd-debuginfo-1.3.2-1.49.x86_64 libgobject-2_0-0-debuginfo-2.62.6-3.6.1.x86_64 libgpg-error0-debuginfo-1.29-1.8.x86_64 libgtk-2_0-0-debuginfo-2.24.32+67-2.28.x86_64 libharfbuzz0-debuginfo-2.6.4-1.56.x86_64 libicu-suse65_1-debuginfo-65.1-4.2.1.x86_64 libidn11-debuginfo-1.34-3.2.2.x86_64 libjasper4-debuginfo-2.0.14-3.19.1.x86_64 libjbig2-debuginfo-2.1-1.31.x86_64 libjpeg8-debuginfo-8.1.2-5.18.1.x86_64 liblcms2-2-debuginfo-2.9-3.3.1.x86_64 libltdl7-debuginfo-2.4.6-3.4.1.x86_64 liblz4-1-debuginfo-1.9.2-3.3.1.x86_64 liblzma5-debuginfo-5.2.3-4.3.1.x86_64 libmodman1-debuginfo-2.0.1-1.27.x86_64 libmount1-debuginfo-2.36.2-4.5.1.x86_64 libogg0-debuginfo-1.3.2-1.24.x86_64 libopenssl1_1-debuginfo-1.1.1d-11.30.1.x86_64 libpango-1_0-0-debuginfo-1.44.7+11-1.25.x86_64 libpcre1-debuginfo-8.45-20.10.1.x86_64 libpcre2-16-0-debuginfo-10.31-3.3.1.x86_64 libpng16-16-debuginfo-1.6.34-3.9.1.x86_64 libproxy1-debuginfo-0.4.15-12.41.x86_64 libpulse0-debuginfo-14.2-4.2.x86_64 libqt5-qtgraphicaleffects-debuginfo-5.12.7-1.53.x86_64 libqt5-qtimageformats-debuginfo-5.12.7-1.50.x86_64 libqt5-qtquickcontrols2-debuginfo-5.12.7-1.53.x86_64 libsndfile1-debuginfo-1.0.28-5.12.1.x86_64 libspeex1-debuginfo-1.2-3.3.1.x86_64 libstdc++6-debuginfo-11.2.1+git610-1.3.9.x86_64 libsystemd0-debuginfo-246.16-7.21.1.x86_64 libthai0-debuginfo-0.1.27-1.16.x86_64 libuuid1-debuginfo-2.36.2-4.5.1.x86_64 libvorbis0-debuginfo-1.3.6-4.3.1.x86_64 libvorbisenc2-debuginfo-1.3.6-4.3.1.x86_64 libwayland-client0-debuginfo-1.18.0-1.19.x86_64 libwebp7-debuginfo-1.0.3-1.62.x86_64 libxcb-composite0-debuginfo-1.13-3.5.1.x86_64 libxcb-damage0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri2-0-debuginfo-1.13-3.5.1.x86_64 libxcb-dri3-0-debuginfo-1.13-3.5.1.x86_64 libxcb-keysyms1-debuginfo-0.4.0-1.23.x86_64 libxcb-present0-debuginfo-1.13-3.5.1.x86_64 libxcb-render-util0-debuginfo-0.3.9-1.23.x86_64 libxcb-render0-debuginfo-1.13-3.5.1.x86_64 libxcb-shape0-debuginfo-1.13-3.5.1.x86_64 libxcb-shm0-debuginfo-1.13-3.5.1.x86_64 libxcb-sync1-debuginfo-1.13-3.5.1.x86_64 libxcb-util1-debuginfo-0.4.0-1.23.x86_64 libxcb-xfixes0-debuginfo-1.13-3.5.1.x86_64 libxcb1-debuginfo-1.13-3.5.1.x86_64 libxkbcommon-x11-0-debuginfo-0.8.2-3.3.1.x86_64 libxml2-2-debuginfo-2.9.7-3.37.1.x86_64 libz1-debuginfo-1.2.11-3.21.1.x86_64 libzstd1-debuginfo-1.4.4-1.6.1.x86_64 (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) n Cannot find bounds of current function (gdb) quit A debugging session is active. Inferior 1 [process 6314] will be killed. Quit anyway? (y or n) y newbie at linux-hdi0:/usr/bin> After I opened the files /usr/lib64/vlc-beta/plugins/plugins.dat and /usr/lib64/vlc-beta/plugins/gui /libqt_plugin.so in the Leap-15.3 application KWrite I found that they had automatically each been opened in the ISO-8859-15 encoding, with ISO standing for International Organization for Standardization ( https://www.nickcarverphotography.com/blog/what-is-iso-what-does-iso-mean/ on the Internet). Some recognizable Latin letters forming English-language words could be seen in those files. And in addition lots of traditional Mandarin Chinese-language characters could be seen in those files. In writing Fortran-computer-language codes I think I often used the 8-bit Uniform Transformation Format (UTF-8) encoding, which probably often appeared in KWrite, in writing data files with usually just numbers in them and in their file names used extensions such as "IN" or dat. I understand from https://fileinfo.com/extension/so that .so files are not meant to be opened for direct viewing by probably human beings. But a puzzle for me is how the file /usr/lib64/vlc-beta/plugins/plugins.dat, which contains the strange characters in either the ISO-8859-15 or UTF-8 encoding, could properly be read by my virtual "computer." From sb56637 at gmail.com Sat Dec 18 18:40:59 2021 From: sb56637 at gmail.com (S.) Date: Sat, 18 Dec 2021 12:40:59 -0500 Subject: [packman] digests SIGNATURES NOT OK Message-ID: <223f0435-871a-c91c-c5bc-5bf69f2e7ab2@gmail.com> On Mon Dec 13 09:48:43 CET 2021 Marc Schiffbauer wrote: > > * Giacomo Comes schrieb am 12.12.21 um 03:44 Uhr: > > I have more information about the key problem. > > > > Some time ago the package rpm in opensuse was patched with > > a pgp hardening changes from upstream (bsc#1185299) > > This caused a problem with the current packman key. > > However, the key itselt is not bad. It's just that > > the rpm code before patching and the code after patching > > will consider the same key as different. > > > > The solution for me was to delete the packman key > > (rpm -e gpg-pubkey-1abd1afb-54176598) and then, > > when asked, reimport the key. > > > > After that, everything worked fine. > Thanks for that! So I guess we could leave the current key in place. > Users just need to know the required steps. I haven't been able to build new images based on openSUSE that include a config script to import the Packman key because it fails: > > :~> rpm --import /etc/zypp/repos.d/repomd.xml.key > error: /etc/zypp/repos.d/repomd.xml.key: key 1 import failed. The cause of the error is the updated version of rpm in Tumbleweed and Leap: - https://1password.community/discussion/123891/rpm-gpg-key-is-not-accepted-by-new-rpm-versions - https://github.com/rpm-software-management/rpm/commit/f22499a05d0a01e35dd10d7644f8d74391ba4222 - https://itectec.com/unixlinux/yum-in-amazon-linux-2-still-asks-for-gpg-key-even-after-rpm-import-when-adding-kubernetes-repo/ They talk there in those threads about updating the key to remove the critical bit but keeping the same key, but that's all over my head. I think something needs to be done about the Packman key, even if it means creating a new one. From spring2014day at gmail.com Sat Dec 18 19:36:00 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Sat, 18 Dec 2021 13:36:00 -0500 Subject: [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 In-Reply-To: References: Message-ID: Sorry, I need to make a correction and addition. While lying on my bed I realized that I could have used yet another version of vlc-beta, namely one released on December 6, 2021. Looking at my notes I noticed that I briefly used version 20211206.07ed287157-pm153.16.1-x86_64 vlc-beta on December 6, 2021. My result in trying to get the default, Qt interface of vlc-beta-20211206.07ed287157-pm153.16.1-x86_64 loaded was "Segmentation fault (core dumped)" and with that main window for that version of vlc-beta appearing for a fraction of a second on my Leap-15.3 desktop. So below I provide you with a table of some of my results and some conditions using four versions of vlc-beta in my installation of the Leap-15.3, Linux operating system within Oracle (Corporation) VM (Virtual Machine) VirtualBox. Despite the fact that the VirtualBox versions I have been using have at least usually had amd64 associated with them, which probably stands for a 64-bit Advanced Micro Devices central processing unit (cpu), my Dell notebook computer actually has an Intel Corporation cpu in it. From within https://virtualbox.org/ on the Internet I generally just downloaded the Windows versions of VirtualBox for upgrading VirtualBox where, as I recall, there was no distinction made between AMD and Intel Corporation cpus.--So despite the amd64 label that I noticed, I suspect that those installation files for VirtualBox for Windows operating systems may be suitable for either AMD or Intel Corporation cpus. I think the label Qt 5.6.2 has been associated with VirtualBox versions since at least July of the year 2020. According to reference 99 of https://en.wikipedia.org/wiki/OpenSUSE#Releases, Qt 5 appears to date from about December 19, 2012. And lots of software packages installed in my Leap-15.3 installation which include "Qt" or "qt" in their names include "Qt5" or "qt5" in their names. Table 1. Some conditions and results obtained using four recent versions of the software package vlc-beta from the Packman repository. Version number of vlc-beta from the Packman, online repository vlc-beta version release date in the year 2021 VirtualBox version used Linux kernel version used in my Leap-15.3, Linux “guest” operating system A result while trying to fully load the Qt interface of vlc-beta and, if possible, play a .mp4 file via that interface 20211028.5ed8c5c794-pm153.9.1-x86_64 October 28 6.1.28r147628 (probably Qt 5.6.2 and amd64) and 6.1.30r148432 (Qt 5.6.2, amd64) 5.3.18-59.27.1-default with VirtualBox 6.1.28, 5.3.18-59.34.1-default and 5.3.18-59.37.2-default with VirtualBox 6.1.30 It gratefully fully worked well for me! 20211104.69e50b090c-pm153.10.1-x86_64 November 4 6.1.28r147628 (probably probably Qt 5.6.2 and amd64) 5.3.18-59.27.1-default Main window for vlc-beta invisible. A .mp4 file was opened via a tray icon for vlc-beta. Audio okay, video not displayed while playing that .mp4 file 20211206.07ed287157-pm153.16.1-x86_64 December 6 6.1.30r148432 (Qt 5.6.2, amd64) 5.3.18-59.37.2-default Segmentation fault (core dumped).The main Qt window briefly appeared. 20211210.736213df13-pm153.17.1-x86_64 December 10 6.1.30r148432 (Qt 5.6.2, amd64) 5.3.18-59.37.2-default Segmentation fault. The main Qt window was mostly transparent. From olaf at aepfle.de Sat Dec 18 22:44:57 2021 From: olaf at aepfle.de (Olaf Hering) Date: Sat, 18 Dec 2021 22:44:57 +0100 Subject: [packman] A segmentation fault in attempting to play a .mp4 file in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 in a 64-bit, openSUSE, Leap-15.3, Linux operating system installed in VirtualBox In-Reply-To: References: Message-ID: <20211218224457.4154f82a.olaf@aepfle.de> Wed, 15 Dec 2021 16:34:53 -0500 Lawrence Patrick Somerville : > So please help me eliminate the "Segmentation fault" error and to be able to play a .mp4 video in vlc-beta-20211206.07ed287157-pm153.16.1.x86_64 using its probably default, Qt interface. Any issue with upstream vlc.git#master should be reported directly on the upstream vlc devel mailing list. The vlc-beta package was created a couple of years ago to track the upcoming vlc 3 release. Today it is just a fun project which tracks vlc.git#master, which may become a vlc 4.0 release at some point. Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: Digitale Signatur von OpenPGP URL: From os-dev at jacraig.com Sat Dec 18 23:44:39 2021 From: os-dev at jacraig.com (Jason Craig) Date: Sat, 18 Dec 2021 15:44:39 -0700 Subject: [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 In-Reply-To: References: Message-ID: <5a4cc332-6e68-4bb2-361f-06f7f8703639@jacraig.com> On 12/17/2021 11:19, Lawrence Patrick Somerville wrote: > Hello. In a 64-bit, openSUSE, Leap-15.3, Linux operating system, which is > installed as a so-called "guest" in Virtual "Machine" (VM) in Oracle > (Corporation) VM VirtualBox, which in turn is installed in my so-called > "host," Windows 10 Home Edition operating system, I have gratefully had > success in the playing of a .mp4 (Moving or Motion Picture Experts Group, > audio layer-4) file in > vlc-beta-20211028.5ed8c5c794-pm153.9.1.x86_64.16.1.x86_64 with the Linux > kernel 5.3.18-59.27.1-default. But in > vlc-beta-20211104.b9e50b090c-pm153.10.1.16.1.x86_64 I had only the audio > signals and not the video signals in the playing of that video. And later > in vlc-beta-20211210.736213df13-pm153.17.1.x86_64 with the Linux kernel > 5.3.18-59.37.2-default I attempted to open vlc-beta, or the Video Local > Area Network (LAN) Client (VLC) multimedia player (VLC) by double-clicking > on a desktop shortcut for it, but saw its main window only for a very brief > period of time, accompanied probably a short time later with the message > "Segmentation fault (core dumped)"; so I could not even attempt to play > that .mp4 file normally with this version of vlc-beta when using its > probably default, Qt interface. Do you really need a beta version of VLC to play an MP4? Is there some reason you can't just use the stable version (3.0.16)? I would expect the beta to not work at times, including having segmentation faults. -- Jason Craig From nomiya at galaxy.dti.ne.jp Sun Dec 19 00:25:31 2021 From: nomiya at galaxy.dti.ne.jp (Masaru Nomiya) Date: Sun, 19 Dec 2021 08:25:31 +0900 Subject: [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 In-Reply-To: <5a4cc332-6e68-4bb2-361f-06f7f8703639@jacraig.com> References: <5a4cc332-6e68-4bb2-361f-06f7f8703639@jacraig.com> Message-ID: <874k75o5qs.wl-nomiya@galaxy.dti.ne.jp> 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 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 -- From aloisio at gmx.com Sun Dec 19 16:50:06 2021 From: aloisio at gmx.com (Luigi Baldoni) Date: Sun, 19 Dec 2021 16:50:06 +0100 Subject: [packman] youtube-dl replacement Message-ID: Hello, as you may have noticed, the youtube-dl package on OBS has switched to the yt-dlp source, since development on the original branch has been slow for some time now. Do you think it would make sense to do the same for Multimedia/youtube-dl? Regards From Mathias.Homann at opensuse.org Sun Dec 19 17:36:37 2021 From: Mathias.Homann at opensuse.org (Mathias Homann) Date: Sun, 19 Dec 2021 17:36:37 +0100 Subject: [packman] youtube-dl replacement In-Reply-To: References: Message-ID: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> I think I'll see if I can set up the same automated rebuilding job that I have for youtube-dl already, and maybe we can have both as alternatives? Cheers MH Am 19.12.2021 um 16:50 schrieb Luigi Baldoni: > Hello, > as you may have noticed, the youtube-dl package on OBS has switched to the yt-dlp source, since development on the original branch has been slow for some time now. > Do you think it would make sense to do the same for Multimedia/youtube-dl? > > Regards -- Mathias Homann Mathias.Homann at openSUSE.org Jabber (XMPP): lemmy at tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 From jdd at dodin.org Sun Dec 19 18:03:18 2021 From: jdd at dodin.org (jdd at dodin.org) Date: Sun, 19 Dec 2021 18:03:18 +0100 Subject: [packman] youtube-dl replacement In-Reply-To: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> References: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> Message-ID: <703ddda1-4a6a-eb40-4ef5-1abaf897c82d@dodin.org> Le 19/12/2021 à 17:36, Mathias Homann a écrit : > I think I'll see if I can set up the same automated rebuilding job that > I have for youtube-dl already, and maybe we can have both as alternatives? > specially if it's clear for the users, such switch can be very confusing :-) thanks jdd -- http://dodin.org http://valeriedodin.com From aloisio at gmx.com Sun Dec 19 20:40:37 2021 From: aloisio at gmx.com (Luigi Baldoni) Date: Sun, 19 Dec 2021 20:40:37 +0100 Subject: [packman] youtube-dl replacement In-Reply-To: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> References: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> Message-ID: Sent: Sunday, December 19, 2021 at 5:36 PM From: "Mathias Homann" > > I think I'll see if I can set up the same automated rebuilding job that > I have for youtube-dl already, and maybe we can have both as alternatives? I'm not sure it's worth it, since the main developer has seemingly abandoned the project (see https://github.com/ytdl-org/youtube-dl/commit/21b759057502c6e70d51011cfb3fb86d84055182). Perhaps we could add a shim to use the original switches by default, like they do on AUR. Regards From Mathias.Homann at openSUSE.org Mon Dec 20 08:36:28 2021 From: Mathias.Homann at openSUSE.org (Mathias Homann) Date: Mon, 20 Dec 2021 08:36:28 +0100 Subject: [packman] youtube-dl replacement In-Reply-To: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> References: <187ea4f1-d2ad-e3c3-cb04-dc2efd4986f7@opensuse.org> Message-ID: <968bf68536cf8f925bc7a0bf6b44140f@openSUSE.org> Am 2021-12-19 17:36, schrieb Mathias Homann: > I think I'll see if I can set up the same automated rebuilding job > that I have for youtube-dl already, and maybe we can have both as > alternatives? After a closer look as to how and why there is a yt-dlp now I think we should't offer both. I'm going to work on having my autobuild method work with the new sources as well - might take a few days or so. Cheers MH -- Mathias Homann Mathias.Homann at openSUSE.org Matrix: @mathias:eregion.de irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From manfred.e at freenet.de Mon Dec 20 09:10:59 2021 From: manfred.e at freenet.de (Manfred Eifler) Date: Mon, 20 Dec 2021 09:10:59 +0100 Subject: [packman] kim In-Reply-To: <5529863.DvuYhMxLoT@pc1a> References: <5529863.DvuYhMxLoT@pc1a> Message-ID: <4702219.31r3eYUQgx@pc1a> Am Montag, 13. Dezember 2021, 10:53:27 CET schrieb Manfred Eifler: > Guten Morgen, > > ich vermisse kim für Leap 15.3. Für 15.2 ist es noch da. > > Würde das jemand für die 15.3 packen? Schade, dass da niemand reagiert. Dieses wertvolle Werkzeug wurde sogar nur bis Leap 15.1 gepackt. Das hatte ich gar nicht bemerkt. http://packman.links2linux.de/package/kim/952067[1] -- Viele Grüße und bleibt ungeimpft Manfred ------------------- openSUSE Leap 15.3 KDE-Plasma 5.23.4 KDE-Frameworks: 5.89.0 QT 5.15.2 Kernel-5.3.18-59.37-default -------- [1] http://packman.links2linux.de/package/kim/952067 From olaf at aepfle.de Mon Dec 20 11:33:35 2021 From: olaf at aepfle.de (Olaf Hering) Date: Mon, 20 Dec 2021 11:33:35 +0100 Subject: [packman] kim In-Reply-To: <4702219.31r3eYUQgx@pc1a> References: <5529863.DvuYhMxLoT@pc1a> <4702219.31r3eYUQgx@pc1a> Message-ID: <20211220113335.29414d87.olaf@aepfle.de> Mon, 20 Dec 2021 09:10:59 +0100 Manfred Eifler : > Schade, dass da niemand reagiert. Ja, schade: https://www.linux-apps.com/p/1126887 Last changelog: 18 years ago Wer kümmert sich? Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: Digitale Signatur von OpenPGP URL: From gottfried.necker at gmx.de Mon Dec 20 11:50:58 2021 From: gottfried.necker at gmx.de (Gottfried Necker) Date: Mon, 20 Dec 2021 11:50:58 +0100 Subject: [packman] kim In-Reply-To: <20211220113335.29414d87.olaf@aepfle.de> References: <5529863.DvuYhMxLoT@pc1a> <4702219.31r3eYUQgx@pc1a> <20211220113335.29414d87.olaf@aepfle.de> Message-ID: <4727250.lxrUEJ0Fhx@ites-necker.ites.kit.edu> Am Montag, 20. Dezember 2021, 11:33:35 CET schrieb Olaf Hering: > Mon, 20 Dec 2021 09:10:59 +0100 Manfred Eifler : > > Schade, dass da niemand reagiert. > > Ja, schade: > > https://www.linux-apps.com/p/1126887 > Last changelog: > 18 years ago > https://github.com/caco3/kim5 There's a port to more recent KDE versions. I did't try it, but it seem to be maintained. Best regards, GN From jdd at dodin.org Mon Dec 20 13:21:40 2021 From: jdd at dodin.org (jdd at dodin.org) Date: Mon, 20 Dec 2021 13:21:40 +0100 Subject: [packman] kim In-Reply-To: <4727250.lxrUEJ0Fhx@ites-necker.ites.kit.edu> References: <5529863.DvuYhMxLoT@pc1a> <4702219.31r3eYUQgx@pc1a> <20211220113335.29414d87.olaf@aepfle.de> <4727250.lxrUEJ0Fhx@ites-necker.ites.kit.edu> Message-ID: <860c6c85-3195-d917-3693-b7a1e24f3d37@dodin.org> Le 20/12/2021 à 11:50, Gottfried Necker a écrit : > Am Montag, 20. Dezember 2021, 11:33:35 CET schrieb Olaf Hering: >> Mon, 20 Dec 2021 09:10:59 +0100 Manfred Eifler : >>> Schade, dass da niemand reagiert. >> >> Ja, schade: >> >> https://www.linux-apps.com/p/1126887 >> Last changelog: >> 18 years ago it's only a menu entry... >> > https://github.com/caco3/kim5 > > There's a port to more recent KDE versions. > I did't try it, but it seem to be maintained. > I use it nearly every day (Leap 15.3), it works. very small recent bug: an message window don't close alone, not even worth a bug report jdd -- http://dodin.org http://valeriedodin.com From manfred.e at freenet.de Mon Dec 20 14:18:31 2021 From: manfred.e at freenet.de (Manfred Eifler) Date: Mon, 20 Dec 2021 14:18:31 +0100 Subject: [packman] kim In-Reply-To: <5677246.8gRA5Vae50@komascript.de> References: <5529863.DvuYhMxLoT@pc1a> <4702219.31r3eYUQgx@pc1a> <5677246.8gRA5Vae50@komascript.de> Message-ID: <3329698.QJadu78ljV@pc1a> Am Montag, 20. Dezember 2021, 10:03:32 CET schrieben Sie: > Am Montag, 20. Dezember 2021, 09:10:59 CET schrieb Manfred Eifler: > > Dieses wertvolle Werkzeug > > ist total veraltet. Die letzte Version ist Jahre alt und für KDE 4.x. Die > Homepage http://bouveyron.free.fr/kim/ gibt sogar noch KDE 3.3.x an. Man > müsste also vermutlich min. zu kim5 https://github.com/caco3/kim5 wechseln. > > BTW: Packman lebt vom Mitmachen. Wenn Du das also haben willst, dann hat > sicher niemand etwas dagegen, wenn Du Dich darum kümmerst. Es braucht eben > immer jemand, der sich für etwas verantwortlich fühlt und bereit ist, Zeit zu > investieren. > > Markus Ich weiß, dass es veraltet ist. Aber es funktioniert trotzdem super und bis jetzt habe ich zumindest keine Alternative gefunden. BTW: Ich habe deinen Hinweis zur Kenntnis genommen. Nun nimm auch meinen zur Kenntnis. Viele Menschen engagieren sich irgendwo, wo sie nützlich ohne Geld dafür zu verlangen helfen können. Oder sie stellen ihre Arbeiten zur kostenlosen Nutzung für jedermann zur Verfügung. Und, das machen sie je nach ihren Fähigkeiten, ihren Kenntnisse, ihren Überzeugungen und ohne sich dafür zu rühmen. Denke mal darüber nach. Trotzdem, Danke für deine Antwort. -- Viele Grüße und bleibt ungeimpft Manfred ------------------- openSUSE Leap 15.3 KDE-Plasma 5.23.4 KDE-Frameworks: 5.89.0 QT 5.15.2 Kernel-5.3.18-59.37-default From markus.kohm at gmx.de Mon Dec 20 14:30:18 2021 From: markus.kohm at gmx.de (Markus Kohm) Date: Mon, 20 Dec 2021 14:30:18 +0100 Subject: [packman] kim In-Reply-To: <3329698.QJadu78ljV@pc1a> References: <5529863.DvuYhMxLoT@pc1a> <5677246.8gRA5Vae50@komascript.de> <3329698.QJadu78ljV@pc1a> Message-ID: <12618416.ssdGKZqy9B@komascript.de> Am Montag, 20. Dezember 2021, 14:18:31 CET schrieb Manfred Eifler: > Denke mal darüber nach. Sorry, aber mir ist es zu blöd, darüber nachzudenken, warum Du Dich von einer freundlichen Mitmacheinladung angegriffen fühlst. Das umso mehr als ich meine Einladung extra nicht öffentlich verschickt hatte, damit Du keinen Grund haben kannst, Dich irgendwie unter Druck gesetzt zu fühlen. Aber manche Leute sind einfach so dünnhäutig, dass sie sogar vor den Nadeln von Weihnachtsbäumen Angst haben. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From manfred.e at freenet.de Mon Dec 20 15:06:00 2021 From: manfred.e at freenet.de (Manfred Eifler) Date: Mon, 20 Dec 2021 15:06:00 +0100 Subject: [packman] kim In-Reply-To: <12618416.ssdGKZqy9B@komascript.de> References: <5529863.DvuYhMxLoT@pc1a> <3329698.QJadu78ljV@pc1a> <12618416.ssdGKZqy9B@komascript.de> Message-ID: <1778015.atdPhlSkOF@pc1a> Am Montag, 20. Dezember 2021, 14:30:18 CET schrieb Markus Kohm: > Am Montag, 20. Dezember 2021, 14:18:31 CET schrieb Manfred Eifler: > > Denke mal darüber nach. > > Sorry, aber mir ist es zu blöd, darüber nachzudenken, warum Du Dich von einer > freundlichen Mitmacheinladung angegriffen fühlst. Das umso mehr als ich meine > Einladung extra nicht öffentlich verschickt hatte, damit Du keinen Grund haben > kannst, Dich irgendwie unter Druck gesetzt zu fühlen. Aber manche Leute sind > einfach so dünnhäutig, dass sie sogar vor den Nadeln von Weihnachtsbäumen > Angst haben. > Tut mir leid, ich habe dir eine PN geschickt. -- Viele Grüße und bleibt ungeimpft Manfred ------------------- openSUSE Leap 15.3 KDE-Plasma 5.23.4 KDE-Frameworks: 5.89.0 QT 5.15.2 Kernel-5.3.18-59.37-default From edgar.aichinger at aon.at Mon Dec 20 09:34:27 2021 From: edgar.aichinger at aon.at (Edgar Aichinger) Date: Mon, 20 Dec 2021 09:34:27 +0100 Subject: [packman] kim In-Reply-To: <4702219.31r3eYUQgx@pc1a> References: <5529863.DvuYhMxLoT@pc1a> <4702219.31r3eYUQgx@pc1a> Message-ID: <1997582.VBgJ7oFkuf@asus> Am Montag, 20. Dezember 2021, 09:10:59 CET schrieb Manfred Eifler: > Am Montag, 13. Dezember 2021, 10:53:27 CET schrieb Manfred Eifler: > > Guten Morgen, > > > > ich vermisse kim für Leap 15.3. Für 15.2 ist es noch da. > > > > Würde das jemand für die 15.3 packen? > > Schade, dass da niemand reagiert. Dieses wertvolle Werkzeug wurde sogar nur bis Leap 15.1 gepackt. Das hatte ich gar nicht bemerkt. > > http://packman.links2linux.de/package/kim/952067[1] > > https://build.opensuse.org/package/show/home:bruno_friedmann/kim[1] https://build.opensuse.org/package/show/home:edogawa/kim5[2] Behalte deine Meinung zum Impfen doch bitte für dich, was hat das hier verloren? Edgar -------- [1] https://build.opensuse.org/package/show/home:bruno_friedmann/kim [2] https://build.opensuse.org/package/show/home:edogawa/kim5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From spring2014day at gmail.com Tue Dec 21 00:50:17 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Mon, 20 Dec 2021 18:50:17 -0500 Subject: [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 In-Reply-To: <874k75o5qs.wl-nomiya@galaxy.dti.ne.jp> References: <5a4cc332-6e68-4bb2-361f-06f7f8703639@jacraig.com> <874k75o5qs.wl-nomiya@galaxy.dti.ne.jp> Message-ID: 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 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 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 From spring2014day at gmail.com Tue Dec 21 22:29:06 2021 From: spring2014day at gmail.com (Lawrence Patrick Somerville) Date: Tue, 21 Dec 2021 16:29:06 -0500 Subject: [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 In-Reply-To: References: <5a4cc332-6e68-4bb2-361f-06f7f8703639@jacraig.com> <874k75o5qs.wl-nomiya@galaxy.dti.ne.jp> Message-ID: 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 > 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 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 > > From strm.50 at gmail.com Fri Dec 31 18:56:50 2021 From: strm.50 at gmail.com (Storm) Date: Fri, 31 Dec 2021 20:56:50 +0300 Subject: [packman] Perhaps, missing dependency for the Discord package Message-ID: Hello! Recently I've reinstalled openSUSE Tumbleweed. After installing preferred software into the fresh system Discord ( http://packman.links2linux.de/package/discord/1009448) was "broken" — it started, but showed a red panel with the inscription that the installation was corrupt. And there was impossible to select sound devices in its sound settings. Similar situation described here: https://www.reddit.com/r/discordapp/comments/8b6nf3/well_it_looks_like_your_discord_installation_is/ I've made `zypper in libatomic1` and after Discord restart it started working normally. I thought it might be worth adding libatomic1 to the list of dependencies for the Discord package? Installed package info: > LC_ALL=C zypper if discord Loading repository data... Reading installed packages... Information for package discord: -------------------------------- Repository : Packman Repository Name : discord Version : 0.0.16-68.3 Arch : x86_64 Vendor : http://packman.links2linux.de Installed Size : 175.6 MiB Installed : Yes Status : up-to-date Source package : discord-0.0.16-68.3.src …