Dependency errors with yum update - libgpod

I tried to do a 'yum update' one day, a couple weeks had gone by so there was a big list of packages available. I know I can use yum-cron, but I like to be more in control and do it myself. Of course I used to do the same thing with Windows and eventually caved and let it update whenever, but for now I want to do it myself. :)  

Anyway, I was getting dependency errors on libgpod, which I don't need since I don't have Apple devices - it allows connections to an iPod. The following was the output:

yum update

[snip]

Errors:

Error: Package: libgpod-0.8.3-14.el7.x86_64 (@epel)

           Requires: libplist.so.1()(64bit)

           Removing: libplist-1.10-4.el7.x86_64 (@anaconda/7.2)

               libplist.so.1()(64bit)

           Updated By: libplist-1.12-3.el7.x86_64 (ol7_latest)

              ~libplist.so.3()(64bit)

Error: Package: libgpod-0.8.3-14.el7.x86_64 (@epel)

           Requires: libimobiledevice.so.4()(64bit)

           Removing: libimobiledevice-1.1.5-6.el7.x86_64 (@anaconda/7.2)

               libimobiledevice.so.4()(64bit)

           Updated By: libimobiledevice-1.2.0-1.el7.x86_64 (ol7_latest)

              ~libimobiledevice.so.6()(64bit)

Error: Package: libgpod-0.8.3-14.el7.x86_64 (@epel)

           Requires: libusbmuxd.so.2()(64bit)

           Removing: usbmuxd-1.0.8-11.el7.x86_64 (@anaconda/7.2)

               libusbmuxd.so.2()(64bit)

           Obsoleted By: usbmuxd-1.1.0-1.el7.x86_64 (ol7_latest)

               Not found

 You could try using --skip-broken to work around the problem

 You could try running: rpm -Va --nofiles --nodigest

I poked into it a bit, but in the end there was no working around the root of the problem. I tried the two options suggested:

yum update --skip-broken

Well this worked, but just avoids the issue and leaves the problem for next time.

rpm -Va --nofiles --nodigest

This will verify installed packages to check for anything wrong, the --nofiles and --nodigest refers to ignoring file attributes and digest problems. This didn't help in my case - nothing useful was discovered.

In the end, I removed the problem package:

rpm -e --nodeps --allmatches libgpod

yum update

The options are to ignore dependencies, and to remove all versions of the package.

Voila.  Now if I had an iPod, it would've meant actually resolving the root problem. Not too sure exactly what it is, but I suspect the libgpod package would have to be rebuilt in epel due to some issue with its dependencies.

Addendum: you may want to also exclude the package from epel repositories. You can add: 

exclude=libgpod*

to the file:

/etc/yum.repos.d/epel.repo

Three ways to determine the version of ADF libraries on a Weblogic server

Environment / assumptions for this post:

• Oracle Enterprise Linux 7.2 (OEL)
• Fusion Middleware Home with Weblogic 11.x or 12.x
• ADF runtime libraries installed

Sometimes it isn't clear what version of ADF is on the server you may be trying to deploy to. The differences between 12.2.1.0 and 12.2.1.1 may be small but Oracle does fix bugs and it may apply to you. One clue is to go to the weblogic console and it shows the version right on the screen. This may not be correct of course, so to get the actual runtime ADF libraries you need to dig a bit. 

A couple different ways of doing this:

1. Check the MANIFEST of adf-share-support.jar. 
• Easy way: find the jar and list the MANIFEST
• Easy but more fooferaw: use Oracle's printJarVersions script
2. Use the PrintVersion class in oracle.jbo.common package.
3. Examine ADF versions from Enterprise Manager -> deployments

First way: check MANIFEST of adf-share-support.jar

cd $MW_HOME/oracle_common/modules/oracle.adf.share
unzip -p adf-share-support.jar META-INF/MANIFEST.MF

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0RC1
Created-By: 25.40-b23 (Oracle Corporation)
Oracle-Version: 12.2.1.0.42.151011.0031
Oracle-Label: JDEVADF_MAIN_GENERIC_151011.0031.S
Oracle-Label-JDEVADF: JDEVADF_MAIN_GENERIC_151011.0031.S
Oracle-Builder: Official Builder
Oracle-Internal-Release: 12.2.1.0.0KMTEST-BP42
Oracle-BuildSystem: Linux - java - 1.8.0_40-ea-b19
Oracle-BuildTimestamp: 2015-10-11 04:35:53 -0700

This actually does the same thing, with slightly different output:

cd $MW_HOME/oracle_common/common/bin
./printJarVersions.sh  | grep 'adf-share-support.jar'

Second way: use PrintVersion class

cd $MW_HOME/oracle_common/modules/oracle.adf.model
java -cp adfm.jar oracle.jbo.common.PrintVersion

BC4J Version is:  12.2.1.0.31


This Oracle document 401694.1 has information on release version numbers - see the "42" in Oracle-Version of the first way, and "31" in the second way.

Third way: look at the deployment in Enterprise Manager

I'll use the Enterprise Manager application itself as an example. The Weblogic Console and the EM app change from version to version - these screenshots are from version 12.2.1. The trick here is to make sure you are in the "Application Deployments" part of the navigation tree, and not the "Weblogic Domain" part of the tree.

Step 1 - go to the correct part of the tree in Enterprise Manger:

Enterprise Manger Navigation Tree -
Start by selecting an ADF application deployment.

Step 2 - from the menu, select ADF -> Versions:

From the Deployments menu, select ADF and then Versions

Step 3 - filter to find what you're looking for.
I would try looking for *adfm* in the Jar name column, or maybe 12.2 in the "Oracle Version":

Filter on one of the important ADF jar files, such as adfm.jar.
You can try a filter like *adfm*.

Oracle Enterprise Linux side by side with Microsoft Windows using a software kvm

Environment / assumptions for this post:

• Oracle Enterprise Linux 7.2 (OEL)
• Windows 7
• Both OEL and Windows have their own monitor
• TigerVNC for Windows, version 1.7.1
• x2vnc version 1.7.2

Goal: to use one keyboard and mouse between two physical computers and monitors without any hardware.

I was excited to switch from Windows to Linux (in my case Oracle Enterprise Linux, basically RedHat) for development, although I wasn't too thrilled about having two mice and two keyboards on my desk. I kept doing things like moving the Linux mouse and then typing on the Windows keyboard. There are many cheap KVM solutions, but I wanted to try a software solution. 

To make this work, you need to run a piece of software on the Linux side, and a VNC server on the Windows side. 

Step 1 - installing a VNC server on Windows

There are a few freely available VNC servers around, but we need one that specifically is backwards compatible with protocol version 3.3 - the version used by x2vnc. I had issues with TightVNC, so I tried TigerVNC. I found a 64bit Windows binary here:

https://github.com/TigerVNC/tigervnc/releases

Install the normal way. Make sure to change the port if required (default is 5900), and add a connection password. If you install as a service, it will restart when you boot.

Step 2 - installing x2vnc on OEL

This is a program written by Fredrik Hubinette. It was based on vncviewer code, and uses the RFB protocol, specifically version 3.3. As of this writing, the version is up to 3.8. More on this below. The steps are as follows:

Download the code from:

http://fredrik.hubbe.net/x2vnc.html

Extract into a temp directory:

cd my_temp_folder

tar -xvf x2vnc-1.7.2.tar.gz

cd x2vnc-1.7.2

Run configure:

./configure

Run make:

make

Do the install:

sudo make install

Don't forget to put this in your .xinitrc if you want it to run every time you log in to your graphical environment.

It is probably a good idea to put the VNC server connection password into a file. The first time you run the program, if you specify the filename it will ask you for the password and create it for you. It will create the password with permissions 600. In the following, I use "west" since my physical Windows monitor is on the left of my Linux desktop, so I want my mouse to roll off to the left, or west direction.

x2vnc -passwdfile ~/.vncpasswd -west 192.168.88.88:0

Finally, to get this to run automatically when you log in (Gnome in my case), you need to add a .desktop file to the autostart folder. The location is here:

~/.config/autostart/filename.desktop

And the file should contain something like this:

[Desktop Entry]
Name=x2vnc
GenericName=Connects to VNC on another server for screen sharing
Comment=This is basically a software KVM, but for mouse and keyboard only. 
Exec=/home/jjames/scripts/x2vnc.sh
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true

And the x2vnc.sh file is the following.
Note: we need the sleep 5, since the script has to run only when the desktop is fully loaded.

sleep 5
echo hello >~/.x2vnc.log
x2vnc -passwdfile ~/.vncpasswd -west 192.168.5.5:0 >>~/.x2vnc.log 2>&1 &

I had a few little glitchy issues that had workarounds:

1. When sliding from Windows back to Linux, the Windows desktop program windows would appear as outlines. This may not matter, unless you are comparing files, or doing any other activity between the two monitors. I found a not-so-good solution was to click the Windows menu button in the bottom-left, and just leave it open. 
2. To slide from Linux to Windows, you simply move the mouse in the direction you specified e.g. I chose West, which is left side. But I had a Gnome toolbar loaded, so I had to make sure the pointer was above the bar to work. 
3. Occasionally, sliding over to Windows didn't work. The solution for me was to simply switch my Gnome from, say, desktop 2 to desktop 3 and try again.