Which VirtualBox repo to use?
I have been using VirtualBox for a long while. Looking at what rpms are available I see: $ dnf list '*VirtualBox*' Last metadata expiration check: 19 days, 23:03:27 ago on Thu Mar 15 14:29:34 2018. Installed Packages VirtualBox-5.2.x86_64 5.2.8_121009_fedora26-1 @virtualbox Available Packages VirtualBox.x86_64 5.2.6-2.fc26 rpmfusion-free-updates VirtualBox-5.1.x86_64 5.1.34_121010_fedora26-1 virtualbox VirtualBox-devel.i686 5.2.6-2.fc26 rpmfusion-free-updates VirtualBox-devel.x86_645.2.6-2.fc26 rpmfusion-free-updates VirtualBox-guest-additions.x86_64 5.2.6-2.fc26 rpmfusion-free-updates VirtualBox-kmodsrc.x86_64 5.1.22-1.fc26 rpmfusion-free VirtualBox-kmodsrc.noarch 5.2.6-2.fc26 rpmfusion-free-updates VirtualBox-server.x86_64 5.2.6-2.fc26 rpmfusion-free-updates VirtualBox-webservice.x86_64 5.2.6-2.fc26 rpmfusion-free-updates akmod-VirtualBox.x86_645.2.6-2.fc26 rpmfusion-free-updates kmod-VirtualBox.x86_64 5.2.6-2.fc26 rpmfusion-free-updates python-VirtualBox.x86_64 5.2.6-2.fc26 rpmfusion-free-updates Which repo [virtualbox (Oracle) or rpmfusion] should one use? Is Oracle simply a more up-to-date repo? Does rpmfusion packages actually fetch the Oracle rpm, or is rpmfusion a separate, full build? The size difference is significant: rpmfusion VirtualBox-5.2.8-2.fc26.x86_64.rpm 8.1MB virtualbox VirtualBox-5.2-5.2.8_121009_fedora26-1.x86_64.rpm 69 MB If the two are different: if I change to use the rpmfusion repo, will the VMs be compatible? TIA -- Eyal Lebedinsky (fed...@eyal.emu.id.au) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: evolution processes
On 04/03/2018 05:50 PM, home user via users wrote: I wouldn't want to "hit myself" with Joe's "Big Hammer", whatever that is. Disabling a process just prevents it from starting on its own. Masking it also prevents anything else from starting it, which is why I referred to it as a Big Hammer. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: evolution processes
On 04/03/2018 05:40 PM, home user via users wrote: Here is the result: - bash.34[~]: systemctl list-unit-files | grep -i evolution bash.35[~]: - So I get nothing. If you think the un-grepped output will help, I can fpaste it. No, I don't use Evolution so I wouldn't know what to look for. That was just my best guess. Sorry it didn't help. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: evolution processes
Since Mozilla first made Lightning built in to Thunderbird, and I learned the appointments, etc. I put there are stored locally rather than somewhere on the internet, I've been using that for all reminders, scheduling, etc. So I have no direct use for what the evolution-data-server is providing. Is evolution-data-server also providing anything "under the hood"? ...like interprocess communication, communication between processes and the kernel, or other things not visible to me? I wouldn't want to "hit myself" with Joe's "Big Hammer", whatever that is. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: evolution processes
Here is the result: - bash.34[~]: systemctl list-unit-files | grep -i evolution bash.35[~]: - So I get nothing. If you think the un-grepped output will help, I can fpaste it. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: OT:Question on NVME disk direct access?
On 04/02/2018 11:30 AM, Michael D. Setzer II wrote: The user though, with a real 256G disk doesn't seem to get any compression of the disk or partitions. Them resulting images are close to the same size as the disks or partitions?? Does the user have LUKS encrypted partitions? Encrypting the system is trivial, and I would imagine common. If the user had selected the option to encrypt their system, a direct disk image would compress very little. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
troubles with lyluatex package in Fedora
Hi I hope there's some savvy TeX user here who can help me to debug this problem: https://github.com/jperon/lyluatex/issues/180 https://lists.gnu.org/archive/html/lilypond-user/2018-03/msg00707.html I tried lyluatex using TexLive 2016 in a Debian container and it works fine. But for some reason it doesn't work on Fedora 27, which has also TexLive 2016. This was confirmed by another Fedora user (see above link to lilypond-user mailing list). I also tried upgrading TexLive to 2017¹ (in a container I use for testing), but then found another problem: https://lists.gnu.org/archive/html/lilypond-user/2018-03/msg00741.html It looks like I need a more recent version of TexLive 2017, containing these critical luatex fixes committed in June: http://git.preining.info/texlive/log/?h=branch2017 I'm Cc-ing spot, author of below copr repository. I was about to try to update his .spec file, but I see that the latest release of TexLive 2017 is dated 24th of May, while it seems I need a later version. Before investigating more, I'd like to know if someone is already working on it. Thanks in advance! Federico ¹ https://copr.fedorainfracloud.org/coprs/spot/texlive/ ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: gthumb crash (after enabling vdpau?)
On 04/02/2018 06:21 PM, Eyal Lebedinsky wrote: > I recently replaced my graphics card (with NVIDIA GT 710). > A newer nvidia module was installed > kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1 > I also enabled VDPAU which was incorrectly installed until now. > > I now have a failure of 'gthumb': > > $ gthumb -v > > (gthumb:7097): Gdk-ERROR **: The program 'gthumb' received an X Window > System error. > This probably reflects a bug in the program. > The error was 'BadLength (poly request too large or internal Xlib length > erro'. > (Details: serial 159 error_code 16 request_code 152 (DRI2) minor_code 1) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the GDK_SYNCHRONIZE environment > variable to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() > function.) > Trace/breakpoint trap (core dumped) > > and /var/log/messages includes a trace: > > Apr 2 15:03:32 e4 systemd-coredump[20472]: Process 20469 (gthumb) of > user 500 dumped core. > Stack trace of thread 20469: > 0 0x7f4312e31e51 _g_log_abort (libglib-2.0.so.0) > 1 0x7f4312e344a1 g_log_writer_default (libglib-2.0.so.0) > 2 0x7f4312e329ee g_log_structured_array (libglib-2.0.so.0) > 3 0x7f4312e32ce7 g_log_structured (libglib-2.0.so.0) > 4 0x7f43140ec351 _gdk_x11_display_error_event (libgdk-3.so.0) > 5 0x7f43140f9813 gdk_x_error (libgdk-3.so.0) > 6 0x7f43103da9ba _XError (libX11.so.6) > 7 0x7f43103d78eb handle_error (libX11.so.6) > 8 0x7f43103d8a94 _XReply (libX11.so.6) > 9 0x7f430cb27f2b DRI2Connect (libGL.so.1) > 10 0x7f430cb274a8 n/a (libGL.so.1) > 11 0x7f430cb0b5c0 n/a (libGL.so.1) > 12 0x7f430cb07c60 glXQueryVersion (libGL.so.1) > 13 0x7f4311c1f153 _cogl_winsys_renderer_connect (libcogl.so.20) > 14 0x7f4311bd822d cogl_renderer_connect (libcogl.so.20) > 15 0x7f4315237824 clutter_backend_real_create_context > (libclutter-1.0.so.0) > 16 0x7f4315250a13 _clutter_feature_init (libclutter-1.0.so.0) > 17 0x7f4315261ca9 clutter_init_real (libclutter-1.0.so.0) > 18 0x7f43155342f6 post_parse_hook (libclutter-gtk-1.0.so.0) > 19 0x7f4312e384f0 g_option_context_parse (libglib-2.0.so.0) > 20 0x5564d3a9661f gth_application_local_command_line (gthumb) > 21 0x7f43133e5e46 g_application_run (libgio-2.0.so.0) > 22 0x5564d3a1bcfe main (gthumb) > 23 0x7f431229d88a __libc_start_main (libc.so.6) > 24 0x5564d3a1bd6a _start (gthumb) > Stack trace of thread 20470: > 0 0x7f4312381a5d poll (libc.so.6) > 1 0x7f4312e2c579 g_main_context_iterate.isra.25 (libglib-2.0.so.0) > 2 0x7f4312e2c68c g_main_context_iteration (libglib-2.0.so.0) > 3 0x7f4312e2c6d1 glib_worker_main (libglib-2.0.so.0) > 4 0x7f4312e53516 g_thread_proxy (libglib-2.0.so.0) > 5 0x7f431265936d start_thread (libpthread.so.0) > 6 0x7f431238db4f __clone (libc.so.6) > > > I see that the gthumb package was updated in 2017, dnf.log says: > Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.3-1.fc24 will > be upgraded > Aug 19 18:09:33 DEBUG ---> Package gthumb.x86_64 1:3.4.5-1.fc26 will > be an upgrade > The update was part of a f24->f26 upgrade. There is no later version of > gthumb but I do see > version 3.6.0 in f27. > > I also see that this gthumb version is one year old: > $ ls -l /usr/bin/gthumb > -rwxr-xr-x 1 root root 988384 Apr 20 2017 /usr/bin/gthumb > > The gthumb package depends on the libvdpau package so I suspect some > incompatibility. > Reinstalling both packages does not improve the situation. > > Is gthumb still maintained? https://github.com/GNOME/gthumb suggests > perusing > https://wiki.gnome.org/Apps/gthumb which is not present. > > Still, too many packages are involved, not the least X/nvidia ones. > > Is anyone else seeing this problem? I do not want to log a bug if this > is the result > of my system long update history, but I do want to resolve this. > > I have another f26 machine that has no problems but does not use vdpau > (or nvidia card). Yes, for F27 the latest gthumb is 3.6.0-1 and the latest libvdpau is 1.1.1-6. I don't use gnome myself and don't even have gthumb installed so I can't speak to its operation. I'd go ahead and file a bugzilla with all the relevant data you have. The maintainers will make a determination as to if it's legit or not. I'd suggest upgrading to F27 if possible as it appears they aren't backporting the changes to F26. -- - Rick Stevens, Systems Engineer, AllDigitalri...@alldigital.com - - AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 - -- - NEWS FLASH! Intelligence of mankind decreasing! Details at... - -
Re: gthumb crash (after enabling vdpau?)
On 04/03/18 14:08, Eyal Lebedinsky wrote: > I do not know why the i686 is installed but 82 other packages depend on it so > I > left it alone. > > It may still be the case that the latest gthumb fixed an X API issue? Well, gthumb on my system doesn't appear to use vdpau. [egreshko@meimei vdpau]$ ldd -v /usr/bin/gthumb | grep vdpau [egreshko@meimei vdpau]$ unlike mplayer [egreshko@meimei vdpau]$ ldd -v /usr/bin/mplayer | grep vdpau libvdpau.so.1 => /lib64/libvdpau.so.1 (0x7f48839ea000) /lib64/libvdpau.so.1: Just for completeness [egreshko@meimei lib64]$ pwd /usr/lib64 [egreshko@meimei lib64]$ ll libvdpau.so.1* lrwxrwxrwx. 1 root root 17 Oct 12 20:12 libvdpau.so.1 -> libvdpau.so.1.0.0 -rwxr-xr-x. 1 root root 15360 Oct 12 20:12 libvdpau.so.1.0.0 [egreshko@meimei lib64]$ ll vdpau/ total 936 lrwxrwxrwx. 1 root root 25 Mar 19 23:09 libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.390.42 -rwxr-xr-x. 1 root root 893984 Mar 3 19:29 libvdpau_nvidia.so.390.42 lrwxrwxrwx. 1 root root 23 Oct 12 20:12 libvdpau_trace.so -> libvdpau_trace.so.1.0.0 lrwxrwxrwx. 1 root root 23 Oct 12 20:12 libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0 -rwxr-xr-x. 1 root root 57608 Oct 12 20:12 libvdpau_trace.so.1.0.0 -- Conjecture is just a conclusion based on incomplete information. It isn't a fact. signature.asc Description: OpenPGP digital signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org
Re: gthumb crash (after enabling vdpau?)
On 03/04/18 13:15, Ed Greshko wrote: On 04/03/18 09:21, Eyal Lebedinsky wrote: I recently replaced my graphics card (with NVIDIA GT 710). A newer nvidia module was installed kmod-nvidia-340xx-4.15.7-200 -> kmod-nvidia-390.42-1 I also enabled VDPAU which was incorrectly installed until now. I don't know what you mean by that. I thought the nVidia drivers had VDPAU enabled by default. Yes. My problem was a bad installation due to the many updates for many years. This is what I have now: $ ls -l /usr/lib64/*vdpau* lrwxrwxrwx 1 root root17 Apr 3 15:43 /usr/lib64/libvdpau.so.1 -> libvdpau.so.1.0.0 -rwxr-xr-x 1 root root 15248 Feb 11 2017 /usr/lib64/libvdpau.so.1.0.0 lrwxrwxrwx 1 root root19 Jun 5 2015 /usr/lib64/libvdpau_gallium.so.1 -> libvdpau_nouveau.so lrwxrwxrwx 1 root root27 Aug 26 2013 /usr/lib64/libvdpau_nouveau.so -> vdpau/libvdpau_nouveau.so.1 lrwxrwxrwx 1 root root26 Apr 3 15:41 /usr/lib64/libvdpau_nvidia.so -> vdpau/libvdpau_nvidia.so.1 lrwxrwxrwx 1 root root23 Sep 1 2013 /usr/lib64/libvdpau_trace.so -> vdpau/libvdpau_trace.so /usr/lib64/vdpau: total 23032 lrwxrwxrwx 1 root root 25 Nov 11 04:46 libvdpau_nouveau.so.1 -> libvdpau_nouveau.so.1.0.0 lrwxrwxrwx 1 root root 25 Nov 11 04:46 libvdpau_nouveau.so.1.0 -> libvdpau_nouveau.so.1.0.0 -rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_nouveau.so.1.0.0 lrwxrwxrwx 1 root root 25 Mar 20 02:11 libvdpau_nvidia.so.1 -> libvdpau_nvidia.so.390.42 -rwxr-xr-x 1 root root 893984 Mar 3 22:29 libvdpau_nvidia.so.390.42 lrwxrwxrwx 1 root root 22 Nov 11 04:46 libvdpau_r300.so.1 -> libvdpau_r300.so.1.0.0 lrwxrwxrwx 1 root root 22 Nov 11 04:46 libvdpau_r300.so.1.0 -> libvdpau_r300.so.1.0.0 -rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_r300.so.1.0.0 lrwxrwxrwx 1 root root 22 Nov 11 04:46 libvdpau_r600.so.1 -> libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 22 Nov 11 04:46 libvdpau_r600.so.1.0 -> libvdpau_r600.so.1.0.0 -rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_r600.so.1.0.0 lrwxrwxrwx 1 root root 26 Nov 11 04:46 libvdpau_radeonsi.so.1 -> libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 26 Nov 11 04:46 libvdpau_radeonsi.so.1.0 -> libvdpau_radeonsi.so.1.0.0 -rwxr-xr-x 4 root root 5656376 Nov 11 04:47 libvdpau_radeonsi.so.1.0.0 lrwxrwxrwx 1 root root 23 Feb 11 2017 libvdpau_trace.so -> libvdpau_trace.so.1.0.0 lrwxrwxrwx 1 root root 23 Feb 11 2017 libvdpau_trace.so.1 -> libvdpau_trace.so.1.0.0 -rwxr-xr-x 1 root root 57520 Feb 11 2017 libvdpau_trace.so.1.0.0 I added the /usr/lib64/libvdpau_nvidia.so which was missing. What do you get as the output of vpauinfo? You may have to install it. Looks OK to me: $ vdpauinfo display: :0 screen: 0 API version: 1 Information string: NVIDIA VDPAU Driver Shared Library 390.42 Sat Mar 3 03:29:48 PST 2018 Video surface: name width height types --- 420 4096 4096 NV12 YV12 422 4096 4096 UYVY YUYV Decoder capabilities: namelevel macbs width height MPEG1 0 65536 4032 4048 MPEG2_SIMPLE3 65536 4032 4048 MPEG2_MAIN 3 65536 4032 4048 H264_BASELINE 41 65536 4032 4080 H264_MAIN 41 65536 4032 4080 H264_HIGH 41 65536 4032 4080 VC1_SIMPLE 1 8190 2048 2048 VC1_MAIN2 8190 2048 2048 VC1_ADVANCED4 8190 2048 2048 MPEG4_PART2_SP 3 8192 2048 2048 MPEG4_PART2_ASP 5 8192 2048 2048 DIVX4_QMOBILE 0 8192 2048 2048 DIVX4_MOBILE0 8192 2048 2048 DIVX4_HOME_THEATER 0 8192 2048 2048 DIVX4_HD_1080P 0 8192 2048 2048 DIVX5_QMOBILE 0 8192 2048 2048 DIVX5_MOBILE0 8192 2048 2048 DIVX5_HOME_THEATER 0 8192 2048 2048 DIVX5_HD_1080P 0 8192 2048 2048 H264_CONSTRAINED_BASELINE 41 65536 4032 4080 H264_EXTENDED 41 65536 4032 4080 H264_PROGRESSIVE_HIGH 41 65536 4032 4080 H264_CONSTRAINED_HIGH 41 65536 4032 4080 H264_HIGH_444_PREDICTIVE 41 65536 4032 4080 HEVC_MAIN --- not supported --- HEVC_MAIN_10 --- not supported --- HEVC_MAIN_STILL--- not supported --- HEVC_MAIN_12 --- not supported --- HEVC_MAIN_444 --- not supported --- Output surface: name width height nat types B8G8R8A8 16384 16384y Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 R10G10B10A2 16384 16384y Y8U8V8A8 V8U8Y8A8 A4I4 I4A4 A8I8 I8A8 Bitmap surface: name width height
