You are not logged in.
I'm attempting to update my system, and I get the following error.
sudo pacman -Syu
...
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
:: jre7-openjdk-headless and jre7-openjdk-headless-infinality are in conflict. Remove jre7-openjdk-headless-infinality? [y/N]
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: jre7-openjdk-headless and jre7-openjdk-headless-infinality are in conflict
I presume pacman wants to remove jre7-openjdk-headless-infinality because it's 7.u65_2.5.1-3, while jre7-openjdk-headless is 7.u65_2.5.1-8. I presume jre7-openjdk-headless-infinality will be updated soon, and I won't get this error.
However, I was interested in what exactly was requesting this version bump in the first place. I presume that it's a package that jre7-openjdk-headless-infinality is a dependency for. I looked firstly at what needed to be updated on my system, noting jre7-openjdk.
$ pacman -Qu
calibre 1.206.0-1
device-mapper 2.02.108-1
ffmpeg 1:2.3.1-1
jdk7-openjdk 7.u65_2.5.1-3
jre7-openjdk 7.u65_2.5.1-3
lib32-krb5 1.12.1-2
lvm2 2.02.108-1
mesa-demos 8.2.0-1
xf86-input-synaptics 1.8.0-2
I had a look at the reverse dependencies for jre7-openjdk-headless-infinality, noting jre7-openjdk again.
$ pacman -Qii jre7-openjdk-headless-infinality
...
Provides : java-runtime-headless=7 jre7-openjdk-headless
Depends On : libjpeg-turbo lcms2 nss ca-certificates-java
...
Required By : jre7-openjdk
...
Conflicts With : openjdk6 jre7-openjdk-headless jre7-openjdk-headless-fontfix
...
I interpret that as pacman -Syu saying that jre7-openjdk needs an update, and this also depends on jre7-openjdk-headless-infinality. I double checked this.
$ pacman -Qi jre7-openjdk
...
Provides : java-runtime=7
Depends On : jre7-openjdk-headless xdg-utils hicolor-icon-theme
...
So I can see that jre7-openjdk actually depends on jre7-openjdk-headless, which can be provided by jre7-openjdk-headless-infinality (as above). However, I don't understand why a new version of jre7-openjdk requires a bump in version of jre7-openjdk-headless (or jre7-openjdk-headless-infinality). Have I misunderstood something?
Last edited by Salkay (2014-08-24 12:34:29)
Offline
Because jre7-openjdk requires jre7-openjdk-headless=7.u65_2.5.1-8 (this exact version)
Offline
jre7-openjdk and jre7-openjdk-headless are two of the five split packages created from the same upstream source, so clearly they will all get bumped at the same time. Have a look at the PKGBUILD for full details.
Offline
> I presume pacman wants to remove jre7-openjdk-headless-infinality because it's 7.u65_2.5.1-3, while jre7-openjdk-headless is 7.u65_2.5.1-8.
Yes. To be exact: pacman wants to remove it because **now** jre7-openjdk declares a dependency on jre7-openjdk-headless with version matching its own version. This is needed because of the new scheme for JVM packages to be able to work together without conflict. Unfortunately you did not have the official jre7-openjdjk-headless but this "infinality" one from AUR.
> However, I was interested in what exactly was requesting this version bump in the first place.
New official packages from extra now support multiple JVM installation and use as explained here. Thus the pkgrel bump.
To solve your issue, I would strongly advise you to use official jre7-openjdk-headless and maybe wait for AUR maintainer to fix its package dependencies.
Offline
Thanks for the replies. I was very stupid here. I realised I was doing pacman -Qi jre7-openjdk, when I should have been querying the remote repository instead.
$ pacman -Si jre7-openjdk
...
Version : 7.u65_2.5.1-8
...
Depends On : jre7-openjdk-headless=7.u65_2.5.1-8 xdg-utils hicolor-icon-theme
This is now clear.
New official packages from extra now support multiple JVM installation and use as explained here. Thus the pkgrel bump.
To solve your issue, I would strongly advise you to use official jre7-openjdk-headless and maybe wait for AUR maintainer to fix its package dependencies.
Ah, thanks for the link. This is a welcome change, obviously. However, in my case, I had jre7-openjdk-headless-infinality installed to fix unreadable fonts in Rubymine. There are other (slightly worse) alternatives though, so I will take your advice and look to those. Thanks again to everyone.
Offline
FYI I just checked and rubymine from AUR now works OK with nice clean fonts with official jre7-openjdk package.
Offline
Thanks for the info, but it's still horrible for me. I'm not sure if it's a result of using infinality fonts.
However, I can fix it by changing /opt/rubymine/bin/rubymine64.vmoptions from
-Dawt.useSystemAAFontSettings=lcd
to
-Dawt.useSystemAAFontSettings=on
I checked before these java upgrades, and text looked slightly better without this change, and with jre7-openjdk-headless-infinality instead, but it was a pretty minor difference.
Ah, so it looks rubbish with java-7-openjdk and java-8-openjdk/jre, but works with java-8-oracle/jre. However, it looks "spindly" with java-8-oracle/jre.
Here it is with java-7-openjdk and the vmoptions modified.
Last edited by Salkay (2014-08-18 13:06:56)
Offline
FYI here is what it looks like here with jre7-openjdk or jre8-openjdk with or without vmoptions.
Offline
FYI here is what it looks like here with jre7-openjdk or jre8-openjdk with or without vmoptions.
This is not good Wikimig, I've compiled the package and I have the same problem here, just look at these picture at 100% zoom (source):
without patch:
https://3.bp.blogspot.com/-VXFz8mPixU8/ … before.png
with patch:
https://3.bp.blogspot.com/-KiW2bpzcaco/ … -after.png
It's really affect eye sight. It would be great if patch this Infinality fix at official packages.
Offline
Wikimig, that looks great. Looks like you have perfect subpixel rendering, which I lose with the modifications to vmoptions.
Bersam, I don't see a massive difference in yours, at least not to the extent of my first screenshot above. For sure there are aliasing differences, but not the horribly broken subpixel rendering as in my first screenshot.
Offline
FWIW I've updated the PKGBUILD for jre7-openjdk-headless-infinality.
Here is an updated PKGBUILD that works for me. I downloaded the source files for jre7-openjdk-headless, swapped the PKGBUILD, and it worked fine.
I've asked the current maintainer if they are still interested in keeping this up to date, otherwise, I've offered to take over. I'll give them a couple of weeks to reply, but this has been flagged and commented as out-of-date for almost a week now.
Last edited by Salkay (2014-08-24 01:27:55)
Offline
I've asked the current maintainer if they are still interested in keeping this up to date, otherwise, I've offered to take over. I'll give them a couple of weeks to reply, but this has been flagged and commented as out-of-date for almost a week now.
Just for the record, I think this package is a bad idea. I substitutes jre7-openjdk-headless for its "-infinality" version without touching jre7-openjdk and jdk7-openjdk. Maintainer is doomed to follow official jre7-openjdk-headless releases and users are doomed to upgrade failing then wait for AUR packages to be pushed then re-update. That is why you got tricked in the first place when you opened this thread.
Last but not least: I have never been able to reproduce a situation where "infinality" fixes an issue (last example being with "rubymine" in this same thread).
Last edited by Wikimig (2014-08-24 08:01:05)
Offline
Just for the record, I think this package is a bad idea. I substitutes jre7-openjdk-headless for its "-infinality" version without touching jre7-openjdk and jdk7-openjdk. Maintainer is doomed to follow official jre7-openjdk-headless releases and users are doomed to upgrade failing then wait for AUR packages to be pushed then re-update. That is why you got tricked in the first place when you opened this thread.
That's a good point, and half the reason why I offered to maintain the package — so that I'd be on top of it at least! (The maintainer was on vacation and has since replied.) I guess the other option would be to follow upstream and keep all the split packages together. Hence, leave jre7-openjdk-headless (+infinality) bundled with jre7-openjdk and jdk7-openjdk, etc. The problem with this is that users would have to compile them individually. Already, jre7-openjdk-headless takes ~20 minutes on my system.
Last but not least: I have never been able to reproduce a situation where "infinality" fixes an issue (last example being with "rubymine" in this same thread).
Yes, I'm not sure how to interpret this. I also have the infinality repos enabled, so I wonder if that's a difference between our systems.
Offline
The problem with this is that users would have to compile them individually
This is a split package. One compilation for all these packages.
Yes, I'm not sure how to interpret this.
What I mean is: I think you don't even need Infinality patch (just like most of people using this package). I am pretty sure you can get to a nice clean look with official Arch Linux packages.
Anyway: have fun with this package!
Offline
This is a split package. One compilation for all these packages.
Ah okay. I think I misunderstood which part is the time-consuming step. I thought that building packages for the splitted parts would add much more time, whereas I think you are saying that the main time-consuming step is the initial overall build.
What I mean is: I think you don't even need Infinality patch (just like most of people using this package). I am pretty sure you can get to a nice clean look with official Arch Linux packages.
Yes, but obviously in my case there is a problem with the stock jre7-openjdk, which is why I need the patch.
Offline
Well, If you insist!
If you initial question is answered, you may want to mark this thread as "solved".
Offline
Ah yeah I always forget. This forum needs a "Mark thread as solved" button (KISS philosophy)…
Offline
EDIT: actually, when testing the different "useSystemAAFontSettings" parameters I somehow missed "on" - that one does indeed work well enough with the arch java packages. I still prefer the "--enable-infinality=yes" version, but you can scrap my whining below - PEBCAK.
What I mean is: I think you don't even need Infinality patch (just like most of people using this package). I am pretty sure you can get to a nice clean look with official Arch Linux packages.
I completely understand that the official package has to remove the infinality flag if it breaks (default) non-infinality setups - but:
You should definitely give fontconfig-infinality a try (very easy to install thanks to bohoomil's bundle). In my experience it massively improves font rendering. However, the current java7-openjdk really does not work with it, there is no way to get a nice clean look. I tried all the AA settings, and they were all terrible.
Best settings with vanilla java7
Same settings with --enable-infinality
It looks even worse in reality, but just zoom in all the way to the left upper corner and compare... these are some pretty sparkling rainbow fonts
Again, unfortunate, but I rather rebuild from ABS with "--enable-infinality=yes" than drop infinality completely.
Last edited by hokasch (2014-09-01 13:25:32)
Offline
hokash, is that vanilla java7 screenshot with subpixel rendering disabled [1]? It looks to me as if it's still doing subpixel rendering, whereas I can't see it in the second (in the main body at least).
[1] i.e. -Dawt.useSystemAAFontSettings=on
Also, for others, after discussion on the jre7-openjdk-headless-infinality, it now bundles jre7-openjdk and jdk7-openjdk.
Last edited by Salkay (2014-09-01 11:02:49)
Offline
is that vanilla java7 screenshot with subpixel rendering disabled [1]?
Both screenshots are with "Dawt.useSystemAAFontSettings=lcd", setting it to "off" is completely unreadable in both cases. But. I somehow missed simply setting it to "on" - with that setting the arch vanilla packages are definitely usable! Still prefer with --enable-infinality, but at least the anti-aliasing isn't screwed up with it.. oops. editing previous post.
Offline
Glad to help! In theory, subpixel rendering should look better. For me, jre7-openjdk-headless-infinality + "lcd" looks marginally better than vanilla jre7 + "on", presumably because it has subpixel rendering enabled.
Offline