net-misc/ipmiview: New package

[ConiKost]

net-misc/ipmiview: New package

Closes: https://bugs.gentoo.org/601406

[gentoo-repo-qa-bot]

Pull Request assignment

Areas affected: ebuilds, other files, profiles
Packages affected: net-misc/ipmiview

net-misc/ipmiview: @gentoo/proxy-maint (new package)

Bugs linked: 601406

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

[ConiKost]

@mgorny: If you mind, you could here have also a look, since this package is very similar to sys-apps/smcipmitool in terms of the file structure.

[ConiKost]

As spoken with @mgorny, I would close these unreviewed PRs for now and reopen later.

[ConiKost]

@mgorny: Since you have merged all my other supermicro tools, could you review here? Thanks!

[mgorny]

Noooo, Java! @gentoo/java please? ;-)

[chewi]

Noooo indeed. java-vm-2.eclass is strictly for Java VMs, which this isn't, please don't use it here. I can see why you've done it the way you have but I suspect there's a better way. I'll have to take a closer look.

[ConiKost]

How about, I redirect the symlink to /etc/java-config-2/current-system-vm? This works here fine. I pushed a new one without using java-vm-2.

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2018-06-25 11:56 UTC
Newest commit scanned: 4a14a8c
Status: ✅ good

Issues already there before the PR (double-check them):
https://qa-reports.gentoo.org/output/gentoo-ci/9346fbd/output.html#dev-libs/spsdeclib

[chewi]

Holy mother, have you seen those shit scary launcher scripts? Thousands of lines of shit. I'll make some adjustments...

[chewi]

I ended up spending a couple of hours on this. I rejigged the ebuild a bit to make it simpler. Did you actually test on x86? I don't think that worked before but it does now.

I leveraged our Java infrastructure to install the jars and create hugely simpler launchers. This will also ensure that the right Java version is used. The upstream launchers were three identical Bash scripts of over 1500 lines each written in 2001 and included stuff to do with installation, a raft of different operating systems, and CD-ROMs. Yeah…

Some things to note. make_desktop_entry doesn't need a full path to the icon if it's in /usr/share/pixmaps. It also doesn't need to the category as this is derived from the package category. I put the new launchers in /usr/bin because I feel that /opt/bin is meant for standalone binaries rather than wrapper scripts.

If you're happy with my version of it, I'll get that pushed up. Would you still be okay to maintain it? I'll answer any Java questions you have.

[ConiKost]

I ended up spending a couple of hours on this. I rejigged the ebuild a bit to make it simpler. Did you actually test on x86? I don't think that worked before but it does now.

Nice, really, many thanks for your work! At least, some time ago, when I tested it on my old x86 Gentoo box, it was working. But to be honest, didn't tested with the latest eBuilds versions. Maybe something broke.

I leveraged our Java infrastructure to install the jars and create hugely simpler launchers. This will also ensure that the right Java version is used. The upstream launchers were three identical Bash scripts of over 1500 lines each written in 2001 and included stuff to do with installation, a raft of different operating systems, and CD-ROMs. Yeah…

So do I see this correctly, you dropped the whole supermicro launcher and the jars are started by an eBuild created "simple" launcher?

Some things to note. make_desktop_entry doesn't need a full path to the icon if it's in /usr/share/pixmaps. It also doesn't need to the category as this is derived from the package category.

Ok, I see with the full path, thanks! But I don't understand that with the category. Could you explain to me further?

I put the new launchers in /usr/bin because I feel that /opt/bin is meant for standalone binaries rather than wrapper scripts.

Hm, I understand what you mean. But since it's installed in /opt/ipmiview, I think, /opt/bin would be still better IMHO. But if you insist, we can keep this :-)

If you're happy with my version of it, I'll get that pushed up. Would you still be okay to maintain it? I'll answer any Java questions you have.

I will test tomorrow for myself, to see and understand all your changes. Yes, I am still fine with maintaining this package :-)

I'll answer any Java questions you have.

What's the difference installing a jar/so with java-pkg_dojar and java-pkg_regso instead of normal doins?

[chewi]

So do I see this correctly, you dropped the whole supermicro launcher and the jars are started by an eBuild created "simple" launcher?

Yes, it was using some ancient generic launching mechanism called LAX that included a jar as well as all that Bash. Lord knows what that did because you can simply launch the application jars with java -jar, plus -Dsystem.library.path needs to be set for a couple of them.

Our launcher creates very short (please have a look) files in /usr/bin and this sets up variables for /usr/share/java-config-2/launcher/launcher.bash. There's also a little bit of Python involved but bear in mind that this is geared towards source-based Java packages with many dependencies and associated classpath entries. It also the bit that figures out whether your preferred Java VM (eselect java-vm) is sufficient, otherwise it needs to override it.

What's the difference installing a jar/so with java-pkg_dojar and java-pkg_regso instead of normal doins?

Quite a lot! I won't bore you with the details but the end result is a file at /usr/share/ipmiview/package.env, which contains additional Java metadata about the package, including what jars it contains and what VM is required. In this case, it also has LIBRARY_PATH, which tells the launcher to add -Dsystem.library.path=/opt/ipmiview to the invocation.

It occurs to me that there's no great reason why this has to go under /opt/ipmiview. We could use the default locations with the jars going in /usr/share/ipmiview/lib, the .so libraries going in /usr/lib/ipmiview, and the rest could go wherever (probably /usr/share/ipmiview) and it would still work fine. This would separate the native and shared code appropriately. Up to you though.