openSUSE Factory December 2015

factory@lists.opensuse.org

98 participants
90 discussions

How can calibre be allowed access through YaST firewall?

by Chan Ju Ping

Unlike rsync, or KDE Connect, there is no option to automatically allow the Calibre ebook manager to open ports so external devices can connect to it. So far, my solution has been to disable the firewall before connecting my device to Calibre via the Calibre Companion app on Android. For those unfamiliar with the process, Calibre Companion can sync ebooks from the desktop's library to the Android device's library, thus eliminating the need for wires and further organization of books. If I know I am using port 9090 for Calibre, is there a way to allow this connection in the Firewall? Has anyone else attempted this setup? Running netstat shows this additional parameter enabled when my tablet is connected to the computer. tcp 0 0 10.42.0.1%2457529:39858 10.42.0.250%328:sesi-lm ESTABLISHED

4 years, 2 months

Use pvops-enabled kernel for Xen (fate#315712)

by Michal Marek

Hi, you have probably noticed that the SUSE virtualization developers have been working on porting features from the kernel-source patches.xen series to the upstream Xen implementation. This mostly works nowadays, so at the SUSE Labs Conference last month, we agreed to finally get rid of kernel-xen in Factory and instead use kernel-default with CONFIG_XEN (the mainline option) enabled. I prepared a branch on github https://github.com/michal42/kernel-source stable-noxen which does exactly this. Test packages are building here: https://build.opensuse.org/project/show/home:michal-m:kernel-stable-noxen The kernel boots and works on my machine, both on bare metal and under the hypervisor (*), but there is some integration work to be done before it can be submitted to Factory: - The installer needs to cope with kernel-xen not available and choose kernel-default. Something like the attached patch should fix it (untested). - perl-Bootloader: Right now, it creates a Xen multiboot entry if the kernel is named -xen, otherwise it creates a regular linux entry. Create both entries if the Xen hypervisor is installed? - kernel-xen needs to be dropped from the patterns, but that's trivial - We have been building a kernel-obs-build-xen package for the OBS workers, which now disappears. Of course, there is lot more work to be done in making the xen -> pvops transition seamless in all corner cases. But that should not be a barrier to pushing the kernel to factory. (*) With the -default kernel, I do not see the kernel messages on the serial console with kernel /boot/xen.gz com1=115200 console=com1,vga module /boot/vmlinuz-4.2.2-0.g980fcdb-default ... console=tty0 console=ttyS0,115200 while I see them with kernel-xen. Michal

4 years, 10 months

Okular lost ability read PNG format

by ellanios82

Hello List , Okular seems to have lost ability read PNG format : perhaps something gone wrong with Konsole output calligra-extras-okular - did anyone else experience this ? I have tried re-installing okular but no joy - still unable read png format ......... thanks regards -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 10 months

openSUSE maintainer finder tool

by Bernhard M. Wiedemann

Hi, during our Hackweek at SUSE I spent a day or two to improve my tool to help finding the maintainer for software in Factory, which comes in handy for bugzilla-screening (getting bugs to the right people). You can use the tool at http://maintainer.zq1.de/ You can give it command names, full filepath, or package names (exact matches (including case) only) If you want to run or extend it, the code is all open on https://github.com/bmwiedemann/susepkginfo and the databases can be fetched from http://aw.zq1.de/db.suse/ The actual maintainer information comes from OBS, so is always current. Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 10 months

Is there a problem with "kernel-syms" at OBS

by Larry Finger

Oracle just released VirtualBox 5.0.12. When I tried to do the normal local test build with osc, I get the message "unresolvable: nothing provides kernel-pv-devel = 4.3.0-2 needed by kernel-syms, nothing provides kernel-xen-devel = 4.3.0-2 needed by kernel-syms". Removing the "BuildRequires: kernel-syms" line allows the build to get past this point, but it fails later. Any suggestions or comments? Thanks, Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 10 months

VA-API support in Mesa and chromium video acceleration

by Jimmy Berry

There had been a prior attempt to enable VA-API support in Mesa (back in Feb 2015), but it was reverted due to a build dependency cycle. The cycle was caused by: libva -> Mesa-libEGL-devel, Mesa-libGL-devel Mesa-libva -> libva-devel I decided to follow the format of libvdpau-va and libvdpau-va-gl packages. Their source seems to be broken up so it was probably natural to break the package up like that. For libva I split off a linked package called libva-gl. - libva: builds everything except gl related - libva-gl: builds libva-egl1 and libva-glx1 This changes the dependency cycle to the following libva -> [nothing mesa related] libva-gl -> Mesa-libEGL-devel, Mesa-libGL-devel Mesa-libva -> libva-devel As you can see this solves the cycle issue. The remaining concern I have is that the Mesa libva driver only generates one file: /usr/lib64/dri/gallium_drv_video.so. When utilizing (for example with vainfo) one needs to specify LIBVA_DRIVER_NAME. LIBVA_DRIVER_NAME=gallium vainfo On intel cards the libva support is provided by a separate (already existing package) instead of through gallium. The driver file it provides is named appropriately that it should just be picked up. Having to set the environment variable seems sub-optimal and is even documented on arch wiki (https://wiki.archlinux.org/index.php/VA-API). Instead providing symbolic links for each of the drivers seems to properly fit the paradigm used by vdpau and base drivers. For example creating the following works on my radeon setup. radeonsi_drv_video.so -> gallium_drv_video.so Setting the environment variable is troublesome: 1) where to set it 2) would need to test for other drivers installed (like intel) Instead it seems like the symbolic links are the way to go. If agreed they could either be added directly in .spec %install, or patched to make install (and perhaps upstreamed). Which seems like the most appropriate solution? I'll hop in #dri-devel and perhaps mesa-dev list and get their thoughts. Finally, I spent many hours searching around the interwebz to figure out the history and state of chromium video acceleration via VA-API. - vdpau is not supported and issues about it have not gone anywhere - va-api works on chromeos so the code is there - support was temporarily enable by intel commit, but quickly reverted There is a out-of-tree patch to change the build flags to look for LINUX instead of CHROMEOS and a tweak to remove the hard coded paths and allow for libva discovery. I managed to get the patch to apply after forward porting it and branching my patched package to build chromium-ffmpeg patch on packman build service (pmbs). Once all the components were installed locally I was able to start chromium and confirm it worked by playing a 4k video on youtube. The 4k video has the most noticable cpu usage and it was clear it dropped significantly. I also used gallium hud to verify increase gpu usage. The end result was the video played the same as if downloaded (via youtube-dl) and played locally in vlc!! Some notes: - installed h264ify chrome extension to force html5 video to use h264 codec instead of h265 or vp9 which are not supported by VA-API yet - previously flipped two flags in chrome while testing a while back - Override software rendering list - Enable GPU rasterization -> enabled I can not set LIBVA_DRIVER_NAME and chromium reverts back to extra cpu usage (also comepare with google-chrome which doesn't have va-api). I need to verify if the patch makes that redundant (I believe it does). Otherwise, it would be good to add that to the patch or change the default values shipped in openSUSE chromium package. My plan going forward then was to add recommends Mesa-libva to chromium along with the patch and submit an SR once the rest of the dust settles. For those interested in following along (SR requests pending). libva - https://build.opensuse.org/request/show/349285 - https://build.opensuse.org/request/show/349402 libva-gl (new) - https://build.opensuse.org/request/show/349403 Mesa - https://build.opensuse.org/request/show/349404 I will followup with the chromium SR assuming these make it in. With luck all this will be accepted/worked out over the next few days. Enjoy! -- Jimmy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 10 months

debuginfo packages and debug repo?

by Jon Nelson

Greetings! I tried getting debuginfo / debug packages for some packages that have been updated. The http://download.opensuse.org/debug/update/leap/42.1/oss/ hierarchy appears to point to the *non* debug packages. Am I doing this wrong or is this an oversight? -- Jon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 10 months

And gapcmon no longer displays, re: New Tw snapshot 20151217

by Patrick Shanahan

* Ludwig Nussel <ludwig.nussel(a)suse.de> [12-18-15 21:59]: > > Please note that this mail was generated by a script. > The described changes are computed based on the x86_64 DVD. > The full online repo contains too many changes to be listed here. > > Packages changed: > Mesa-demo (8.2.0 -> 8.3.0) > kdebase4-workspace > kdelibs4 gapcmon no longer displays but is running. and there are still no icons in system tray and no blank spaces where the icons *should* display -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 10 months

Installing Sun jdk it's a pain

by Daniele

HI guys, is there a easy way to install sun jsdk on opensuse/leap ? Are 2 days that I'm trying on 13.2 but at the end, there is always something that does not work. There are dozen of tutorial, forum thread, video, script but they are outdated not working. There are tutorial for Leap too so things are not better. I know that the sun jdk cannot be shipped with the distro. OpenJdk is not the answer. What about at working spec file ? Or an src that download jdk from sun website and rebuild it locally ? Do we want to be one of the worst distro for working with java ? Thanks, Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 11 months

new package: suil

by Roman Evstifeev

Hi/ I wanted to revive Ardour (digital audio workstation) and managed to push some new needed libraries in multimedia:libs project. So here is one of them: suil It is a library for wrapping non-native GUI applications to be embedded and displayed inside host window (using XEmbed). Currently supports Gtk 2, Qt 4, and X11 I am willing to push this to factory to eventually make Ardour available there too. I can do the maintenance of the suil in the multimedia:libs devel project. (I am new here, but i hope i will get to know the business in time) suil is composed of the library itself with few "wrap modules" - these are packaged separately as libsuil-plugins Upstream package website: http://drobilla.net/software/suil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 years, 11 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

openSUSE Factory December 2015