[gentoo-dev] Re: [PATCH] git-r3.eclass: Support more flexible EGIT_OVERRIDE_* APIs for user
Michał Górny posted on Sat, 18 Nov 2017 10:22:34 +0100 as excerpted: > Introduce a new, more flexible override API in git-r3, in replacement of > the LIVE_* API that was pretty much a legacy of git-2. This means to > solve the two major limitations of the old API: > > 1. The variables were based on package names without categories. > Therefore, they weren't suitable whenever two packages had the same > category. This is quite common when dealing with various programming > language bindings/reimplementations, and we can't really rely on every > new programming language inventing its own VCS. I always used package.env in any case, and always wished for a non- package-unique env var name variant to make it easier to simply clone the file and stuff the commit var as appropriate, instead of having to setup the file and fix up BOTH the var name and its value, when I needed to bisect a package the first time. So a variant without the repo OR package name would be my wish, here. > 2. The overrides weren't suitable for packages checking out multiple > repositories (LLVM, wine, glibc). Valid point there! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] OpenJDK bootstrap (Was: Java 9 on Gentoo)
Hi Roy, Roy Bamford writes: > You can start with gcc-5.4 with the gcj use flag. That will bootstrap > icedtea:7 icedtea:7 will bootstrap icedtea:8 Tested on arm64. Have my respect. It answers the question lurking in my mind for years. This opens the possibility to run full Java besids Android Runtime. Thank you! Benda signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] fdo-mime.eclass: Mark the eclass as deprecated
On Mon, Nov 13, 2017 at 03:30:11AM +0100, Jonas Stein wrote: > On 19/06/17 15:20, Michał Górny wrote: > > The GNOME team has committed the xdg-utils.eclass serving exactly > > the same purpose as fdo-mime.eclass, supposedly with the goal of > > replacing it. However, it seems that they have never bothered to > > actually hint the deprecation in the fdo-mime.eclass in any way. > > As a result, developers are still adding references to this eclass > > instead of using xdg-utils or xdg, and/or not working towards replacing > > them. > > > > Add an explicit deprecation notice to the fdo-mime.eclass to make it > > clear that the eclass should not be used in new packages, and what > > the replacement eclasses are. > > Packages and Ebuilds which are still using the fdo-mime are listed here: > > Packages: > https://qa-reports.gentoo.org/output/eclass-usage/fdo-mime.txt > > Ebuilds sorted by Maintainer or Package > http://gentoo.levelnine.at/simplechecks/fdo-mime-check/ > > If you see your name in the list, you find a list of your packages with > inherit fdo-mime. > > Thanks to Michael. For his script. > > -- > Best, > Jonas > Great tool! Super easy for maintainers to check their packages. I have fixes ready for x11-misc/spacefm, but I could not find a bug number to reference. Are we tracking this on bugzy or just pushing everyone to go ahead and update their ebuilds? I searched bugzy for 'fdo-mime' and the only relevant bug is 621914 [1], which I assume was the original discussion to get us onto xdg-utils since it's newer. If there's no tracker bug I need to reference, that's fine. Just wanted to be sure I'm not missing anything before pushing. [1]: https://bugs.gentoo.org/621914 -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: Digital signature
Re: [gentoo-dev] Java 9 on Gentoo
On Sat, 18 Nov 2017 14:11:11 + Roy Bamford wrote: > You can start with gcc-5.4 with the gcj use flag. > That will bootstrap icedtea:7 > icedtea:7 will bootstrap icedtea:8 > Tested on arm64. > > With icedtea:7 going and gcc-5.4 not having a very long future, > building icedtea for a new arch will be painful. If someone wants icedtea on a new arch then I'll do whatever I can to fudge a build together and create an icedtea-bin from it. It only has to be done once for each arch. This is essentially what binary distros do and given that this is good enough for Red Hat, they haven't spent effort on making icedtea bootstrappable some other way like JamVM. I think some choose the gcj route because they think it is purer but this is not really true. There are precompiled binaries involved, whichever route you take. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpI0jf0rTbGP.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Java 9 on Gentoo
Eating spam for breakfast! Glorious Spam! http://cdn.ipernity.com/142/50/59/32265059.4aebaf91.640.jpg https://landof1words.files.wordpress.com/2013/03/sir-can-a-lot.jpg On Sat, 18 Nov 2017 09:59:15 -0500 "William L. Thomson Jr." wrote: > > That is also the main reason for Icedtea project existence beyond > having a FOSS harness to build/boostrap OpenJDK/Java. Oracle JDK may > only support certain archs. If you want to build on another, that is > where Icedtea plays a role. Though again still have other issues, > Hotspot, Zero, OpenJ9, legacy JamVM, etc. Ideally these are like USE flags, some are already for icedtea. cacao, jamvm, and zero, in addition to default HotSpot. https://en.wikipedia.org/wiki/List_of_Java_virtual_machines No clue if icedtea/gnuandrew is looking to add support for OpenJ9. That would likely be a big one since its from IBM, and the core to their JDK for Power. IBM also has a JDK, not packaged on Gentoo. Everyone already hates Oracle so little interest in IBM. Ideally Gentoo should have it, though not sure if it will continue on beyond 8. Maybe why they released J9. It does support different archs. https://www.ibm.com/developerworks/java/jdk/ -- William L. Thomson Jr. pgp05SgGcZ0bA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Java 9 on Gentoo
Forgot something useful On Sat, 18 Nov 2017 09:50:51 -0500 "William L. Thomson Jr." wrote: > > Otherwise yes, unless icedtea-bin exist for that arch. Boostrapping > in a post gcc-jdk/java 7 world will be difficult, If not impossible > for some archs. That is also the main reason for Icedtea project existence beyond having a FOSS harness to build/boostrap OpenJDK/Java. Oracle JDK may only support certain archs. If you want to build on another, that is where Icedtea plays a role. Though again still have other issues, Hotspot, Zero, OpenJ9, legacy JamVM, etc. Me personally I wish Oracle/Sun had kept JRockit as an alternative as well. It was merged into HotSpot. Or released with Hotspot in OpenJDK https://en.wikipedia.org/wiki/JRockit Thus there is some reason for Icedtea project to exists beyond just legal/licensing. -- William L. Thomson Jr. pgpdnh0ALbobn.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Java 9 on Gentoo
On Sat, 18 Nov 2017 14:11:11 + Roy Bamford wrote: > > You can start with gcc-5.4 with the gcj use flag. > That will bootstrap icedtea:7 > icedtea:7 will bootstrap icedtea:8 > Tested on arm64. Your likely one of the few to do that :) That is good one does not have to go back to 1.5, and 1.6.. Not bad to get to 1.8, but once 9 is out. Not much fun going from 7 to 8 to 9. No real reason to do that unless you want to. Or don't trust Chewi/James icedtea-bin. He does like to spy :P j/k The main reason for icedtea/openjdk vs oracle is to build openjdk or java with open source licenses. I think if you build against oracle your accepting oracles license for their JDK. It does not really taint the result. But does mean java was built with non FOSS software. Oracle JDK is downloaded under a different license agreement. Its mostly a legal thing, and there is some slightly better system integration. Definitely if building from source. Still some using icedtea-bin, but thats a binary. So not sure as deps it was built against change, etc. From source is likely different there. Though I haven't really ever had issues with Oracle and system integration. Occasionally people will have fonts issues. Fonts tends to be one of the most noticeable visual difference between Oracle and Icedtea/OpenJDK I do not mess with openjdk/icedtea much if at all. I mostly run with Oracle for various reasons. Licensing is not a concern. I am used to Java long before it was FOSS. > With icedtea:7 going and gcc-5.4 not having a very long future, > building icedtea for a new arch will be painful. The main problem with arch support is HotSpot. There is not many replacements for other archs. https://en.wikipedia.org/wiki/IcedTea#Platform_support Not sure of OpenJ9 will change that. I think it will at min support Power archs, ppc64 etc. Not sure about ppc 32bit. https://github.com/eclipse/openj9 https://github.com/ibmruntimes/openj9-openjdk-jdk9 https://bugs.gentoo.org/631156 Otherwise yes, unless icedtea-bin exist for that arch. Boostrapping in a post gcc-jdk/java 7 world will be difficult, If not impossible for some archs. -- William L. Thomson Jr. pgpNM3IqwfZI6.pgp Description: OpenPGP digital signature
[gentoo-dev] Eclass up for grabs: sgml-catalog.eclass
Dear all, The following eclass is up for grabs: sgml-catalog.eclass after retirement of the herd SGML long time ago. It seems it was forgotten to reassign. It is still used by a few packages https://qa-reports.gentoo.org/output/eclass-usage/sgml-catalog.txt and a proxied maintainer is in progress to test and write a patch to fix https://bugs.gentoo.org/497052 It would be nice, if a project or a developer could take care of this eclass. -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Java 9 on Gentoo
On 2017.11.18 04:16, William L. Thomson Jr. wrote: > On Sat, 18 Nov 2017 02:40:14 + > Peter Stuge wrote: > > > William L. Thomson Jr. wrote: > > > > If you have any suggestions as to what I should look at to > better > > > > understand the OpenJDK build system I would very much appreciate > > > > them. > > .. > > > Build OpenJDK stand alone. Get familiar with that. > > > > It used to be that one could not build OpenJDK without already > having > > a working JDK. Has that changed with OpenJDK 9 (IIRC it was planned > > for OpenJDK 7 :) or not yet, and that is a reason for having icedtea > > in the mix? > > Yes you are correct, nothing has changed there to my knowledge. > [snip] > > -- > William L. Thomson Jr. > You can start with gcc-5.4 with the gcj use flag. That will bootstrap icedtea:7 icedtea:7 will bootstrap icedtea:8 Tested on arm64. With icedtea:7 going and gcc-5.4 not having a very long future, building icedtea for a new arch will be painful. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods pgpgyRdsSikdz.pgp Description: PGP signature
[gentoo-dev] [PATCH] git-r3.eclass: Support more flexible EGIT_OVERRIDE_* APIs for user
Introduce a new, more flexible override API in git-r3, in replacement
of the LIVE_* API that was pretty much a legacy of git-2. This means to
solve the two major limitations of the old API:
1. The variables were based on package names without categories.
Therefore, they weren't suitable whenever two packages had the same
category. This is quite common when dealing with various programming
language bindings/reimplementations, and we can't really rely on every
new programming language inventing its own VCS.
2. The overrides weren't suitable for packages checking out multiple
repositories (LLVM, wine, glibc).
The new mode for overrides uses the repository name (as guessed
by git-r3) transformed into correct variable name. The specifically
defined variables are:
- EGIT_OVERRIDE_REPO_${NAME} -- to override the repository URI,
- EGIT_OVERRIDE_BRANCH_${NAME} -- to override the branch,
- EGIT_OVERRIDE_COMMIT_${NAME} -- to override the commit id or tag,
- EGIT_OVERRIDE_COMMIT_DATE_${NAME} -- to request last commit older than
the specified date.
---
eclass/git-r3.eclass | 55 ++--
1 file changed, 49 insertions(+), 6 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index caf4e8d003e0..55a987b79545 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -553,6 +553,7 @@ _git-r3_is_local_repo() {
git-r3_fetch() {
debug-print-function ${FUNCNAME} "$@"
+ # process repos first since we create repo_name from it
local repos
if [[ ${1} ]]; then
repos=( ${1} )
@@ -562,12 +563,6 @@ git-r3_fetch() {
repos=( ${EGIT_REPO_URI} )
fi
- local branch=${EGIT_BRANCH:+refs/heads/${EGIT_BRANCH}}
- local remote_ref=${2:-${EGIT_COMMIT:-${branch:-HEAD}}}
- local local_id=${3:-${CATEGORY}/${PN}/${SLOT%/*}}
- local local_ref=refs/git-r3/${local_id}/__main__
- local commit_date=${4:-${EGIT_COMMIT_DATE}}
-
[[ ${repos[@]} ]] || die "No URI provided and EGIT_REPO_URI unset"
local r
@@ -591,6 +586,54 @@ git-r3_fetch() {
)
fi
+ # get the default values for the common variables and override them
+ local branch_name=${EGIT_BRANCH}
+ local commit_id=${2:-${EGIT_COMMIT}}
+ local commit_date=${4:-${EGIT_COMMIT_DATE}}
+
+ # support new override API for EAPI 6+
+ if ! has "${EAPI:-0}" 0 1 2 3 4 5; then
+ # get the name and do some more processing:
+ # 1) kill .git suffix,
+ # 2) underscore (remaining) non-variable characters,
+ # 3) add preceding underscore if it starts with a digit,
+ # 4) uppercase.
+ local override_name=${GIT_DIR##*/}
+ override_name=${override_name%.git}
+ override_name=${override_name//[^a-zA-Z0-9_]/_}
+ override_name=${override_name^^}
+
+ local varmap=(
+ REPO:repos
+ BRANCH:branch_name
+ COMMIT:commit_id
+ COMMIT_DATE:commit_date
+ )
+
+ local localvar livevar live_warn=
+ for localvar in "${varmap[@]}"; do
+ livevar=EGIT_OVERRIDE_${localvar%:*}_${override_name}
+ localvar=${localvar#*:}
+
+ if [[ -n ${!livevar} ]]; then
+ [[ ${localvar} == repos ]] && repos=()
+ live_warn=1
+ ewarn "Using ${livevar}=${!livevar}"
+ declare "${localvar}=${!livevar}"
+ fi
+ done
+
+ if [[ ${live_warn} ]]; then
+ ewarn "No support will be provided."
+ fi
+ fi
+
+ # set final variables after applying overrides
+ local branch=${branch_name:+refs/heads/${branch_name}}
+ local remote_ref=${commit_id:-${branch:-HEAD}}
+ local local_id=${3:-${CATEGORY}/${PN}/${SLOT%/*}}
+ local local_ref=refs/git-r3/${local_id}/__main__
+
# try to fetch from the remote
local success saved_umask
if [[ ${EVCS_UMASK} ]]; then
--
2.15.0
