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
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
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
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
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
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
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
* 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
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
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