Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, 2 Feb 2017 16:06:02 +0100 Kristian Fiskerstrand wrote: > On 02/02/2017 03:11 PM, Michael Orlitzky wrote: > > Can we discourage IUSE defaults except for #1 and #2? I'm equally > > guilty of #3 and #4, but I now regret them. I would also like to see > > explanations in metadata.xml of why +flags are on by default. > > This presumes that the goal is minimal system in all cases, rather > than a good user experience for inter alia a desktop system or a > server-system. If a user requires a minimal system for whatever reason > (s)he is likely more prepared to understand the choices than the > average user. Exactly what I was going to say. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Guidelines for IUSE defaults
On Thu, 2 Feb 2017 10:36:51 -0500 Michael Orlitzky wrote: > On 02/02/2017 10:06 AM, Kristian Fiskerstrand wrote: > > On 02/02/2017 03:11 PM, Michael Orlitzky wrote: > >> Can we discourage IUSE defaults except for #1 and #2? I'm equally > >> guilty of #3 and #4, but I now regret them. I would also like to > >> see explanations in metadata.xml of why +flags are on by default. > > > > This presumes that the goal is minimal system in all cases, rather > > than a good user experience for inter alia a desktop system or a > > server-system. If a user requires a minimal system for whatever > > reason (s)he is likely more prepared to understand the choices than > > the average user. > > I'm not saying that we should have a minimal experience > out-of-the-box, only that the base profile should result in an > effectively-minimal set of USE flags. Adding IUSE defaults is > essentially adding defaults to the base profile. Why does > dev-java/icedtea try to pull in GTK (and thus X) on a headless > server? That stuff belongs in a desktop profile, not in the base one. I can appreciate the frustration with icedtea. It's complicated by the fact that I made it a somewhat negative USE flag, headless-awt. This decision wasn't taken lightly. USE=X didn't really make sense any more so I changed it to USE=awt but upstream, who does most of the ebuild work, objected on the basis that AWT is always present, even on headless systems. He wanted USE=headless as that is the commonly used term but there was also JavaFX to consider so I compromised with headless-awt. There was the expected handful of complaints from USE=-* users initially but I haven't heard anything regarding this in a long time. I suppose I could enable headless-awt by default and disable it in the desktop profile but I suspect it'll still trip somebody up. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] icedtea requiring X libs to build was -> Guidelines for IUSE defaults
On Thu, 2 Feb 2017 10:53:08 -0500 Michael Orlitzky wrote: > On 02/02/2017 10:51 AM, William L. Thomson Jr. wrote: > > On Thursday, February 2, 2017 10:36:51 AM EST Michael Orlitzky > > wrote: > >> Why does dev-java/icedtea try to pull in GTK (and thus X) > >> on a headless server? That stuff belongs in a desktop profile, not > >> in the base one. > > > > In that specific case it cannot be avoided. > > Yes it can. I just have to waste my time unsetting the stupid USE flag > that's on for no reason =P Actually he's right. Java can obviously be used without GTK and that's something we support but upstream hasn't taken the time to make it possible to build without it. Apparently that isn't a trivial thing to do. In my earlier mail, I was only talking about runtime. If you really want to avoid GTK on a server then you should stick to one of the -bin packages. Hopefully Java 9 will improve on this. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [PATCH v2] java-ant-2.eclass: Replace unnecessary evals with arrays
On Wed, 22 Feb 2017 22:54:22 +0100 Michał Górny wrote: > Replace the horrifying use of evals along with quoting to pass multiple > filenames whitespace-safe with much simpler bash arrays. While at it, > also simplify the find-read loop. I've given this a rough test. Some of the code paths are rarely used and I suspect some are never used now but it looks good anyway. Please go ahead. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpySOV3R0z6P.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Suggested sync method/Portage config for devs on ~arch?
On Mon, 27 Feb 2017 23:29:20 -0800 Daniel Campbell wrote: > Ever since we switched to Git, I've tried to use gentoo.git (or a > mirror) to sync from. I later found a configuration that hasufell used > at the time. [1] It works well so far, but I wanted to ask the greater > developer community what method(s) they employ to sync from our > repositories and why it's a good fit for them. I use hasufell's repo too. I'm surprised we haven't made it more official. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize
On Fri, 17 Mar 2017 18:14:12 +0100 Michał Górny wrote: > Hi, everyone. > > Since the bug about libtool.eclass [1] has not received any attention, I > hereby declare maintainer timeout and start working on improving > the eclass. > > The main goals are to: > > a. stop requiring every single autoconf ebuild to call elibtoolize > manually (and effectively having half-'broken' repository), Good! This will help immensely with cross-compiling. > 1.1. split the function into new eclass (PATCH already sent), The function itself is quite complex. Perhaps this should also go into a separate package? > 3. copy elibtoolize logic to Portage, and make it apply implicitly > on econf [do we need to apply it elsewhere?]; disable explicit > libtoolize when Portage supports that. Related to the above point, if you make it part of econf then it needs to be part of PMS and that's quite a complex beast to have in the spec. It has been suggested twice on this list (once quite recently) that the script itself should put into a separate package for this reason. Then PMS just needs to say "install and use this script" without any further detail. Back in September, I tried turning the eclass into an external script with very few changes to start with, just as a proof of concept. I removed the few references to other eclass helpers but still retained a little dependence on variables exported by Portage. I then stuck a call to this to near the top of econf() and tried out some packages, including those that had failed on me before. It worked very well indeed. I don't recall encountering any issues. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpUtDNJo7r8W.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Reverse use of Python/Ruby versions
On Sun, 9 Apr 2017 12:15:56 -0400 "William L. Thomson Jr." wrote: > Python 2.7 stuff aside. I am not sure how many Python and Ruby packages > break with a newer release. In pythons case I think once they support > Python 3.x, there is little chance if it breaking with further 3.x > releases. Not sure about Ruby. I'm not going to weigh heavily into this as I don't mind the current setup but as a professional Ruby developer, I can say that breakages between versions are usually overblown by those outside the community. Yeah, there usually are some but they tend to only affect the bigger libraries and frameworks that do some more exotic things. Even then, the changes required are generally very small, sometimes even just one line. People thought the sky would fall when 2.4 deprecated Fixnum and Bignum. It really didn't. It's still just a warning right now but I haven't seen that warning since it was dealt with in Rails. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpr0oLkm0YAA.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-java/jdbc-oracle-bin and dev-java/sun-j2ee-deployment-bin
# James Le Cuirot (14 Apr 2017) # Outdated and stuck behind a temperamental registration wall that I # have lost my patience with. Removal in 30 days if no one cares # enough to pick it up. dev-java/jdbc-oracle-bin # James Le Cuirot (14 Apr 2017) # Ancient, unused by anything, fetch restricted. Removal in 30 days. dev-java/sun-j2ee-deployment-bin -- James Le Cuirot (chewi) Gentoo Linux Developer pgp4b2KlnJoEg.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH] cdrom.eclass: Near rewrite
If you've been wondering why I've been quiet of late (you have, right?!) then this is partly why. I'm not sure why I spent so long on an eclass that hardly anyone uses but it's utilised by many of my old favourite games. The main bug that it fixes is one I filed a report for 10 years ago! There were also several duplicates. If you want something done... I realised part way through that I didn't have any multi-disc games that use this eclass any more. A former friend of mine lost my second UT99 disc with the high resolution textures. I couldn't rewrite the eclass without testing it thoroughly so I wrote a brand new "comi" (Curse of Monkey Island) ebuild for use with ScummVM! I'll get this committed when these changes go in. I've also revised all the Descent-related packages.
[gentoo-dev] [PATCH 02/14] cdrom.eclass: Simplify printing of CD_ROOT_# variable names
---
eclass/cdrom.eclass | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index de72f15563db..f1839b189ae9 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -122,12 +122,7 @@ cdrom_get_cds() {
einfo "If you do not have the CDs, but have the data files"
einfo "mounted somewhere on your filesystem, just export"
einfo "the following variables so they point to the right
place:"
- einfon ""
- cdcnt=0
- while [[ ${cdcnt} -lt ${CDROM_TOTAL_CDS} ]] ; do
- ((++cdcnt))
- echo -n " CD_ROOT_${cdcnt}"
- done
+ einfo $(printf "CD_ROOT_%d " $(seq ${#}))
echo
einfo "Or, if you have all the files in the same place, or"
einfo "you only have one cdrom, you can export CD_ROOT"
--
2.11.0
[gentoo-dev] [PATCH 03/14] cdrom.eclass: Rename CDROM_NAME_SET array to CDROM_NAMES
vapier seemed confused about what he wanted this variable to do as can
be seen in bug #139196. The eclass used it for the names of each disc,
regardless of the set, while ebuilds used it for the name of each
single-disc set. This was not helped by the fact that the set feature
has been totally undocumented. The former behaviour makes more sense
so let's rename the array to something less confusing.
This will not break ebuilds already using CDROM_NAME_SET. As they all
use just a single disc, they currently do not display the names given
in this variable anyway.
---
eclass/cdrom.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index f1839b189ae9..72250556e624 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -44,7 +44,7 @@ fi
# etc... If you want to give the cds better names, then just export
# the appropriate CDROM_NAME variable before calling cdrom_get_cds().
# Use CDROM_NAME for one cd, or CDROM_NAME_# for multiple cds. You can
-# also use the CDROM_NAME_SET bash array.
+# also use the CDROM_NAMES bash array.
#
# For those multi cd ebuilds, see the cdrom_load_next_cd() function.
cdrom_get_cds() {
@@ -102,12 +102,12 @@ cdrom_get_cds() {
einfo "export CD_ROOT=/mnt/cdrom"
echo
else
- if [[ -n ${CDROM_NAME_SET} ]] ; then
- # Translate the CDROM_NAME_SET array into CDROM_NAME_#
+ if [[ -n ${CDROM_NAMES} ]] ; then
+ # Translate the CDROM_NAMES array into CDROM_NAME_#
cdcnt=0
while [[ ${cdcnt} -lt ${CDROM_TOTAL_CDS} ]] ; do
((++cdcnt))
- export
CDROM_NAME_${cdcnt}="${CDROM_NAME_SET[$((${cdcnt}-1))]}"
+ export
CDROM_NAME_${cdcnt}="${CDROM_NAMES[$((${cdcnt}-1))]}"
done
fi
--
2.11.0
[gentoo-dev] [PATCH 04/14] cdrom.eclass: Allow CDROM_NAMES changes before each cdrom_load_next_cd
This works around the lack of per-set disc names. Once the first disc
has been detected, ebuilds can adjust CDROM_NAMES to contain just the
names from the matched CDROM_SET.
---
eclass/cdrom.eclass | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 72250556e624..9724c66ca2ce 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -102,15 +102,7 @@ cdrom_get_cds() {
einfo "export CD_ROOT=/mnt/cdrom"
echo
else
- if [[ -n ${CDROM_NAMES} ]] ; then
- # Translate the CDROM_NAMES array into CDROM_NAME_#
- cdcnt=0
- while [[ ${cdcnt} -lt ${CDROM_TOTAL_CDS} ]] ; do
- ((++cdcnt))
- export
CDROM_NAME_${cdcnt}="${CDROM_NAMES[$((${cdcnt}-1))]}"
- done
- fi
-
+ _cdrom_set_names
einfo "This package will need access to ${CDROM_TOTAL_CDS} cds."
cdcnt=0
while [[ ${cdcnt} -lt ${CDROM_TOTAL_CDS} ]] ; do
@@ -152,6 +144,8 @@ cdrom_load_next_cd() {
local var
((++CDROM_CURRENT_CD))
+ _cdrom_set_names
+
unset CDROM_ROOT
var=CD_ROOT_${CDROM_CURRENT_CD}
[[ -z ${!var} ]] && var="CD_ROOT"
@@ -258,4 +252,17 @@ _cdrom_glob_match() {
)
}
+# @FUNCTION: _cdrom_set_names
+# @INTERNAL
+# @DESCRIPTION:
+# Populate CDROM_NAME_# variables with the CDROM_NAMES array.
+_cdrom_set_names() {
+ if [[ -n ${CDROM_NAMES} ]] ; then
+ local i
+ for i in $(seq ${#CDROM_NAMES[@]}); do
+ export CDROM_NAME_${i}="${CDROM_NAMES[$((${i} - 1))]}"
+ done
+ fi
+}
+
fi
--
2.11.0
[gentoo-dev] [PATCH 05/14] cdrom.eclass: Remove ye olde Submount check
Submount was last-rited in 2007 and was already dead long before that.
---
eclass/cdrom.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 9724c66ca2ce..681683f9328c 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -181,9 +181,7 @@ _cdrom_locate_file_on_cd() {
while [[ -n ${cdset[${i}]} ]] ; do
local point= node= fs= foo=
while read point node fs foo ; do
- [[ " cd9660 iso9660 udf " != *" ${fs} "* ]] && \
- ! [[ ${fs} == "subfs" && ",${opts}," ==
*",fs=cdfss,"* ]] \
- && continue
+ [[ " cd9660 iso9660 udf " != *" ${fs} "* ]] &&
continue
point=${point//\040/ }
export CDROM_MATCH=$(_cdrom_glob_match
"${point}" "${cdset[${i}]}")
[[ -z ${CDROM_MATCH} ]] && continue
--
2.11.0
[gentoo-dev] [PATCH 01/14] cdrom.eclass: Detect case-insensitively and handle special characters
This eclass previously used "find -iname" but it only checked the file
case-insensitively and not the directories. There is "find -ipath" but
this does not intelligently skip non-matching paths, making it
slow. Globbing is used here instead.
The : character has always been used to delimit paths given to
cdrom_get_cds, which makes sense because : generally isn't allowed on
CDs, while whitespace is. Despite that, whitespace was not being
handled properly and neither were wildcard characters. Now all special
characters are automatically escaped.
---
eclass/cdrom.eclass | 48 ++--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 41488d2446c2..de72f15563db 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -79,12 +79,13 @@ cdrom_get_cds() {
export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
export CDROM_SET=-1
- for f in ${CDROM_CHECK_1//:/ } ; do
+ IFS=:
+ for f in ${CDROM_CHECK_1} ; do
+ unset IFS
((++CDROM_SET))
- [[ -e ${CDROM_ROOT}/${f} ]] && break
+ export CDROM_MATCH=$(_cdrom_glob_match "${CDROM_ROOT}"
"${f}")
+ [[ -n ${CDROM_MATCH} ]] && return
done
- export CDROM_MATCH=${f}
- return
fi
# User didn't help us out so lets make sure they know they can
@@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
local showedmsg=0 showjolietmsg=0
while [[ -z ${CDROM_ROOT} ]] ; do
- local i=0
- local -a cdset=(${*//:/ })
+ local i=0 cdset
+ IFS=: read -a cdset <<< "${*}"
+
if [[ -n ${CDROM_SET} ]] ; then
- cdset=(${cdset[${CDROM_SET}]})
+ cdset=( "${cdset[${CDROM_SET}]}" )
fi
while [[ -n ${cdset[${i}]} ]] ; do
- local dir=$(dirname ${cdset[${i}]})
- local file=$(basename ${cdset[${i}]})
-
local point= node= fs= foo=
while read point node fs foo ; do
[[ " cd9660 iso9660 udf " != *" ${fs} "* ]] && \
! [[ ${fs} == "subfs" && ",${opts}," ==
*",fs=cdfss,"* ]] \
&& continue
point=${point//\040/ }
- [[ ! -d ${point}/${dir} ]] && continue
- [[ -z $(find "${point}/${dir}" -maxdepth 1
-iname "${file}") ]] \
- && continue
+ export CDROM_MATCH=$(_cdrom_glob_match
"${point}" "${cdset[${i}]}")
+ [[ -z ${CDROM_MATCH} ]] && continue
export CDROM_ROOT=${point}
export CDROM_SET=${i}
- export CDROM_MATCH=${cdset[${i}]}
return
done <<< "$(get_mounts)"
@@ -243,4 +240,27 @@ _cdrom_locate_file_on_cd() {
done
}
+# @FUNCTION: _cdrom_glob_match
+# @USAGE:
+# @INTERNAL
+# @DESCRIPTION:
+# Locates the given path ($2) within the given root directory ($1)
+# case-insensitively and returns the first actual matching path. This
+# eclass previously used "find -iname" but it only checked the file
+# case-insensitively and not the directories. There is "find -ipath" but
+# this does not intelligently skip non-matching paths, making it
+# slow. Case-insensitive matching can only be applied to patterns so
+# extended globbing is used to turn regular strings into patterns. All
+# special characters are escaped so don't worry about breaking this. The
+# first person to make this work without an eval wins a cookie.
+_cdrom_glob_match() {
+ local p=\?\($(sed -e 's:[^A-Za-z0-9/]:\\\0:g' -e 's:/:)/?(:g' <<< "$2"
|| die)\)
+ (
+ cd "$1" 2>/dev/null || return
+ shopt -s extglob nocaseglob nullglob || die
+ eval "ARRAY=( ${p} )"
+ echo ${ARRAY[0]}
+ )
+}
+
fi
--
2.11.0
[gentoo-dev] [PATCH 08/14] cdrom.eclass: Fix important typo in the multiple disc instructions
If you have all the files within the same directory tree then you
should set CD_ROOT, not CD_ROOT_1.
---
eclass/cdrom.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 67f9b15d21e4..56032e084d01 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -121,7 +121,7 @@ cdrom_get_cds() {
einfo "for all the CDs."
echo
einfo "For example:"
- einfo "export CD_ROOT_1=/mnt/cdrom"
+ einfo "export CD_ROOT=/mnt/cdrom"
echo
fi
--
2.11.0
[gentoo-dev] [PATCH 09/14] cdrom.eclass: Change CDROM_CHECK_# variables to a CDROM_CHECKS array
---
eclass/cdrom.eclass | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 56032e084d01..10a19551161a 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -52,12 +52,8 @@ cdrom_get_cds() {
# the # of files they gave us
local cdcnt=0
local f=
- for f in "$@" ; do
- ((++cdcnt))
- export CDROM_CHECK_${cdcnt}="$f"
- done
export CDROM_TOTAL_CDS=${cdcnt}
- export CDROM_CURRENT_CD=1
+ export CDROM_CURRENT_CD=1 CDROM_CHECKS=( "${@}" )
# now we see if the user gave use CD_ROOT ...
# if they did, let's just believe them that it's correct
@@ -80,7 +76,7 @@ cdrom_get_cds() {
einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
export CDROM_SET=-1
IFS=:
- for f in ${CDROM_CHECK_1} ; do
+ for f in ${CDROM_CHECKS[0]} ; do
unset IFS
((++CDROM_SET))
export CDROM_MATCH=$(_cdrom_glob_match "${CDROM_ROOT}"
"${f}")
@@ -149,8 +145,7 @@ cdrom_load_next_cd() {
var=CD_ROOT_${CDROM_CURRENT_CD}
[[ -z ${!var} ]] && var="CD_ROOT"
if [[ -z ${!var} ]] ; then
- var="CDROM_CHECK_${CDROM_CURRENT_CD}"
- _cdrom_locate_file_on_cd ${!var}
+ _cdrom_locate_file_on_cd "${CDROM_CHECKS[${CDROM_CURRENT_CD}]}"
else
export CDROM_ROOT=${!var}
fi
--
2.11.0
[gentoo-dev] [PATCH 06/14] cdrom.eclass: Simplify loop with seq
---
eclass/cdrom.eclass | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 681683f9328c..b8fdb03ac535 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -104,10 +104,9 @@ cdrom_get_cds() {
else
_cdrom_set_names
einfo "This package will need access to ${CDROM_TOTAL_CDS} cds."
- cdcnt=0
- while [[ ${cdcnt} -lt ${CDROM_TOTAL_CDS} ]] ; do
- ((++cdcnt))
- var="CDROM_NAME_${cdcnt}"
+ local cdcnt
+ for cdcnt in $(seq ${#}); do
+ local var=CDROM_NAME_${cdcnt}
[[ ! -z ${!var} ]] && einfo " CD ${cdcnt}: ${!var}"
done
echo
--
2.11.0
[gentoo-dev] [PATCH 07/14] cdrom.eclass: We don't know for sure how many discs will be needed
The number of discs may vary between sets and ebuilds may not call
cdrom_load_next_cd() for every argument depending on USE flags and
other conditional factors.
---
eclass/cdrom.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index b8fdb03ac535..67f9b15d21e4 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -103,7 +103,7 @@ cdrom_get_cds() {
echo
else
_cdrom_set_names
- einfo "This package will need access to ${CDROM_TOTAL_CDS} cds."
+ einfo "This package may need access to ${CDROM_TOTAL_CDS} cds."
local cdcnt
for cdcnt in $(seq ${#}); do
local var=CDROM_NAME_${cdcnt}
--
2.11.0
[gentoo-dev] [PATCH 11/14] cdrom.eclass: Make CD_ROOT less of a special case, fixes #195868
CD_ROOT was intended to be a power user feature so the eclass didn't
try very hard to check the validity of the given location. This
difference in behaviour ultimately made the eclass larger and more
confusing.
It now uses the same matching loop as the regular case, making it
simpler and more consistent. The only differences are that it doesn't
show information or prompts about inserting discs and it dies
immediately if a match cannot be found.
---
eclass/cdrom.eclass | 126 +++-
1 file changed, 46 insertions(+), 80 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 95bf48829e14..f4ea2ff36400 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -48,44 +48,16 @@ fi
#
# For those multi cd ebuilds, see the cdrom_load_next_cd() function.
cdrom_get_cds() {
- # first we figure out how many cds we're dealing with by
- # the # of files they gave us
- local cdcnt=0
- local f=
- export CDROM_CURRENT_CD=1 CDROM_CHECKS=( "${@}" )
+ unset CDROM_SET
+ export CDROM_CURRENT_CD=0 CDROM_CHECKS=( "${@}" )
- # now we see if the user gave use CD_ROOT ...
- # if they did, let's just believe them that it's correct
+ # If the user has set CD_ROOT or CD_ROOT_1, don't bother informing
+ # them about which discs are needed as they presumably already know.
if [[ -n ${CD_ROOT}${CD_ROOT_1} ]] ; then
- local var=
- cdcnt=0
- while [[ ${cdcnt} -lt ${#} ]] ; do
- ((++cdcnt))
- var="CD_ROOT_${cdcnt}"
- [[ -z ${!var} ]] && var="CD_ROOT"
- if [[ -z ${!var} ]] ; then
- eerror "You must either use just the CD_ROOT"
- eerror "or specify ALL the CD_ROOT_X variables."
- eerror "In this case, you will need" \
- "${#} CD_ROOT_X variables."
- die "could not locate CD_ROOT_${cdcnt}"
- fi
- done
- export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
- einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
- export CDROM_SET=-1
- IFS=:
- for f in ${CDROM_CHECKS[0]} ; do
- unset IFS
- ((++CDROM_SET))
- export CDROM_MATCH=$(_cdrom_glob_match "${CDROM_ROOT}"
"${f}")
- [[ -n ${CDROM_MATCH} ]] && return
- done
- fi
+ :
- # User didn't help us out so lets make sure they know they can
- # simplify the whole process ...
- if [[ ${#} -eq 1 ]] ; then
+ # Single disc info.
+ elif [[ ${#} -eq 1 ]] ; then
einfo "This ebuild will need the ${CDROM_NAME:-cdrom for ${PN}}"
echo
einfo "If you do not have the CD, but have the data files"
@@ -96,6 +68,8 @@ cdrom_get_cds() {
einfo "For example:"
einfo "export CD_ROOT=/mnt/cdrom"
echo
+
+ # Multi disc info.
else
_cdrom_set_names
einfo "This package may need access to ${#} cds."
@@ -120,8 +94,7 @@ cdrom_get_cds() {
echo
fi
- export CDROM_SET=""
- export CDROM_CURRENT_CD=0
+ # Scan for the first disc.
cdrom_load_next_cd
}
@@ -135,57 +108,48 @@ cdrom_get_cds() {
# in the CD list, so make sure you only call this function when you're
# done using the current CD.
cdrom_load_next_cd() {
- local var
- ((++CDROM_CURRENT_CD))
-
- _cdrom_set_names
+ local showedmsg=0 showjolietmsg=0
unset CDROM_ROOT
- var=CD_ROOT_${CDROM_CURRENT_CD}
- [[ -z ${!var} ]] && var="CD_ROOT"
- if [[ -z ${!var} ]] ; then
- _cdrom_locate_file_on_cd "${CDROM_CHECKS[${CDROM_CURRENT_CD}]}"
- else
- export CDROM_ROOT=${!var}
- fi
-
- einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
-}
-
-# this is used internally by the cdrom_get_cds() and cdrom_load_next_cd()
-# functions. this should *never* be called from an ebuild.
-# all it does is try to locate a give file on a cd ... if the cd isn't
-# found, then a message asking for the user to insert the cdrom will be
-# displayed and we'll hang out here until:
-# (1) the file is found on a mounted cdrom
-# (2) the user hits CTRL+C
-_cdrom_locate_file_on_cd() {
- local mline=""
- local showedmsg=0 showjolietmsg=0
+ ((++CDROM_CURRENT_CD))
- while [[ -z ${CDROM_ROOT} ]] ; do
- local i=0 cdset
- IFS=: read -a cdset <<< "${*}"
+ _cdrom_set_names
- if [[ -n ${CDROM_SET} ]] ; then
- cdset=( "${cdset[${CDROM_SET}]}" )
- f
[gentoo-dev] [PATCH 10/14] cdrom.eclass: The CDROM_TOTAL_CDS variable is redundant now
This was never formally declared by the eclass or used by ebuilds.
---
eclass/cdrom.eclass | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 10a19551161a..95bf48829e14 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -52,7 +52,6 @@ cdrom_get_cds() {
# the # of files they gave us
local cdcnt=0
local f=
- export CDROM_TOTAL_CDS=${cdcnt}
export CDROM_CURRENT_CD=1 CDROM_CHECKS=( "${@}" )
# now we see if the user gave use CD_ROOT ...
@@ -60,7 +59,7 @@ cdrom_get_cds() {
if [[ -n ${CD_ROOT}${CD_ROOT_1} ]] ; then
local var=
cdcnt=0
- while [[ ${cdcnt} -lt ${CDROM_TOTAL_CDS} ]] ; do
+ while [[ ${cdcnt} -lt ${#} ]] ; do
((++cdcnt))
var="CD_ROOT_${cdcnt}"
[[ -z ${!var} ]] && var="CD_ROOT"
@@ -68,7 +67,7 @@ cdrom_get_cds() {
eerror "You must either use just the CD_ROOT"
eerror "or specify ALL the CD_ROOT_X variables."
eerror "In this case, you will need" \
- "${CDROM_TOTAL_CDS} CD_ROOT_X
variables."
+ "${#} CD_ROOT_X variables."
die "could not locate CD_ROOT_${cdcnt}"
fi
done
@@ -86,7 +85,7 @@ cdrom_get_cds() {
# User didn't help us out so lets make sure they know they can
# simplify the whole process ...
- if [[ ${CDROM_TOTAL_CDS} -eq 1 ]] ; then
+ if [[ ${#} -eq 1 ]] ; then
einfo "This ebuild will need the ${CDROM_NAME:-cdrom for ${PN}}"
echo
einfo "If you do not have the CD, but have the data files"
@@ -99,7 +98,7 @@ cdrom_get_cds() {
echo
else
_cdrom_set_names
- einfo "This package may need access to ${CDROM_TOTAL_CDS} cds."
+ einfo "This package may need access to ${#} cds."
local cdcnt
for cdcnt in $(seq ${#}); do
local var=CDROM_NAME_${cdcnt}
@@ -189,7 +188,7 @@ _cdrom_locate_file_on_cd() {
echo
if [[ ${showedmsg} -eq 0 ]] ; then
- if [[ ${CDROM_TOTAL_CDS} -eq 1 ]] ; then
+ if [[ ${#CDROM_CHECKS[@]} -eq 1 ]] ; then
if [[ -z ${CDROM_NAME} ]] ; then
einfo "Please insert+mount the cdrom
for ${PN} now !"
else
--
2.11.0
[gentoo-dev] [PATCH 13/14] cdrom.eclass: Update and improve documentation following changes
---
eclass/cdrom.eclass | 121 +---
1 file changed, 96 insertions(+), 25 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index 36d967d2f4cd..c95bb80325e9 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -6,13 +6,13 @@
# ga...@gentoo.org
# @BLURB: Functions for CD-ROM handling
# @DESCRIPTION:
-# Acquire cd(s) for those lovely cd-based emerges. Yes, this violates
-# the whole 'non-interactive' policy, but damnit I want CD support!
+# Acquire CD(s) for those lovely CD-based emerges. Yes, this violates
+# the whole "non-interactive" policy, but damnit I want CD support!
#
-# With these cdrom functions we handle all the user interaction and
-# standardize everything. All you have to do is call cdrom_get_cds()
-# and when the function returns, you can assume that the cd has been
-# found at CDROM_ROOT.
+# Do not call these functions in pkg_* phases like pkg_setup as they
+# should not be used for binary packages. Most packages using this
+# eclass will require RESTRICT="bindist" but the point still stands.
+# The functions are generally called in src_unpack.
if [[ -z ${_CDROM_ECLASS} ]]; then
_CDROM_ECLASS=1
@@ -24,8 +24,8 @@ inherit portability
# @DESCRIPTION:
# By default, the eclass sets PROPERTIES="interactive" on the assumption
# that people will be using these. If your package optionally supports
-# disc based installed, then set this to "yes", and we'll set things
-# conditionally based on USE=cdinstall.
+# disc-based installs then set this to "yes" and we'll set things
+# conditionally based on USE="cdinstall".
if [[ ${CDROM_OPTIONAL} == "yes" ]] ; then
IUSE="cdinstall"
PROPERTIES="cdinstall? ( interactive )"
@@ -34,19 +34,41 @@ else
fi
# @FUNCTION: cdrom_get_cds
-# @USAGE: [file on cd2] [file on cd3] [...]
+# @USAGE: [:alt cd1 file] [cd2 file[:alt cd2 file]] [...]
# @DESCRIPTION:
-# The function will attempt to locate a cd based upon a file that is on
-# the cd. The more files you give this function, the more cds the cdrom
-# functions will handle.
+# Attempt to locate a CD based upon a file that is on the CD.
#
-# Normally the cdrom functions will refer to the cds as 'cd #1', 'cd #2',
-# etc... If you want to give the cds better names, then just export
-# the appropriate CDROM_NAME variable before calling cdrom_get_cds().
-# Use CDROM_NAME for one cd, or CDROM_NAME_# for multiple cds. You can
-# also use the CDROM_NAMES bash array.
+# If the data spans multiple discs then additional arguments can be
+# given to check for more files. Call cdrom_load_next_cd() to scan for
+# the next disc in the set.
#
-# For those multi cd ebuilds, see the cdrom_load_next_cd() function.
+# Sometimes it is necessary to support alternative CD "sets" where the
+# contents differ. Alternative files for each disc can be appended to
+# each argument, separated by the : character. This feature is
+# frequently used to support installing from an existing installation.
+# Note that after the first disc is detected, the set is locked so
+# cdrom_load_next_cd() will only scan for files in that specific set on
+# subsequent discs.
+#
+# The given files can be within named subdirectories. It is not
+# necessary to specify different casings of the same filename as
+# matching is done case-insensitively. Filenames can include special
+# characters such as spaces. Only : is not allowed.
+#
+# If you don't want each disc to be referred to as "CD #1", "CD #2",
+# etc. then you can optionally provide your own names. Set CDROM_NAME
+# for a single disc, CDROM_NAMES as an array for multiple discs, or
+# individual CDROM_NAME_# variables for each disc starting from 1.
+#
+# Despite what you may have seen in older ebuilds, it has never been
+# possible to provide per-set disc names. This would not make sense as
+# all the names are initially displayed before the first disc has been
+# detected. As a workaround, you can redefine the name variable(s)
+# after the first disc has been detected.
+#
+# This function ends with a cdrom_load_next_cd() call to scan for the
+# first disc. For more details about variables read and written by this
+# eclass, see that function's description.
cdrom_get_cds() {
unset CDROM_SET
export CDROM_CURRENT_CD=0 CDROM_CHECKS=( "${@}" )
@@ -100,13 +122,62 @@ cdrom_get_cds() {
# @FUNCTION: cdrom_load_next_cd
# @DESCRIPTION:
-# Some packages are so big they come on multiple CDs. When you're done
-# reading files off a CD and want access to the next one, just call this
-# function. Again, all the messy details of user interaction are taken
-# care of for you. Once this returns, just read the variable CDROM_ROOT
-# for the location of the mounted CD. Note that you can only go forward
-# in the CD list, so make sure you only call this function when you're
-# done using the current CD.
+# If multiple arguments were given to cdrom_get_cds() then you can call
+# this
[gentoo-dev] [PATCH 14/14] cdrom.eclass: Update copyright year
--- eclass/cdrom.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass index c95bb80325e9..baf566ea415e 100644 --- a/eclass/cdrom.eclass +++ b/eclass/cdrom.eclass @@ -1,4 +1,4 @@ -# Copyright 1999-2014 Gentoo Foundation +# Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # @ECLASS: cdrom.eclass -- 2.11.0
[gentoo-dev] [PATCH 12/14] cdrom.eclass: Use consistent terminology in prompts and messages
---
eclass/cdrom.eclass | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
index f4ea2ff36400..36d967d2f4cd 100644
--- a/eclass/cdrom.eclass
+++ b/eclass/cdrom.eclass
@@ -58,7 +58,7 @@ cdrom_get_cds() {
# Single disc info.
elif [[ ${#} -eq 1 ]] ; then
- einfo "This ebuild will need the ${CDROM_NAME:-cdrom for ${PN}}"
+ einfo "This ebuild will need the ${CDROM_NAME:-CD for ${PN}}"
echo
einfo "If you do not have the CD, but have the data files"
einfo "mounted somewhere on your filesystem, just export"
@@ -72,7 +72,7 @@ cdrom_get_cds() {
# Multi disc info.
else
_cdrom_set_names
- einfo "This package may need access to ${#} cds."
+ einfo "This package may need access to ${#} CDs."
local cdcnt
for cdcnt in $(seq ${#}); do
local var=CDROM_NAME_${cdcnt}
@@ -85,7 +85,7 @@ cdrom_get_cds() {
einfo $(printf "CD_ROOT_%d " $(seq ${#}))
echo
einfo "Or, if you have all the files in the same place, or"
- einfo "you only have one cdrom, you can export CD_ROOT"
+ einfo "you only have one CD, you can export CD_ROOT"
einfo "and that place will be used as the same data source"
einfo "for all the CDs."
echo
@@ -150,31 +150,27 @@ cdrom_load_next_cd() {
die "unable to locate CD #${CDROM_CURRENT_CD} root at
${CDROM_ROOT}"
fi
- echo
if [[ ${showedmsg} -eq 0 ]] ; then
if [[ ${#CDROM_CHECKS[@]} -eq 1 ]] ; then
- if [[ -z ${CDROM_NAME} ]] ; then
- einfo "Please insert+mount the cdrom
for ${PN} now !"
- else
- einfo "Please insert+mount the
${CDROM_NAME} cdrom now !"
- fi
+ einfo "Please insert+mount the ${CDROM_NAME:-CD
for ${PN}} now !"
else
- if [[ -z ${CDROM_NAME_1} ]] ; then
- einfo "Please insert+mount cd
#${CDROM_CURRENT_CD}" \
- "for ${PN} now !"
+ local var="CDROM_NAME_${CDROM_CURRENT_CD}"
+ if [[ -z ${!var} ]] ; then
+ einfo "Please insert+mount CD
#${CDROM_CURRENT_CD} for ${PN} now !"
else
- local
var="CDROM_NAME_${CDROM_CURRENT_CD}"
- einfo "Please insert+mount the ${!var}
cdrom now !"
+ einfo "Please insert+mount the ${!var}
now !"
fi
fi
showedmsg=1
fi
- einfo "Press return to scan for the cd again"
+
+ einfo "Press return to scan for the CD again"
einfo "or hit CTRL+C to abort the emerge."
- echo
+
if [[ ${showjolietmsg} -eq 0 ]] ; then
showjolietmsg=1
else
+ echo
ewarn "If you are having trouble with the detection"
ewarn "of your CD, it is possible that you do not have"
ewarn "Joliet support enabled in your kernel. Please"
--
2.11.0
Re: [gentoo-dev] Re: Re: stable gcc 5.4.0 ??
On Tue, 18 Apr 2017 15:12:13 +0200 Jörg Schaible wrote: > As said, I synced the tree twice this morning (4 hours ago) and the > KEYWORDS in the ebuild do not declare amd64 as stable although it was > committed to GIT already yesterday. And this is no wonder, because > the stable branch of the GIT mirror is still not up-to-date: > https://github.com/gentoo-mirror/gentoo/tree/stable/sys-devel/gcc It's been held up by this outstanding issue: https://qa-reports.gentoo.org/output/gentoo-ci/58d678e2a/output.html#dev-db/psqlodbc -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite
On Tue, 18 Apr 2017 07:51:58 +0200 Ulrich Mueller wrote: > >>>>> On Mon, 17 Apr 2017, James Le Cuirot wrote: > > > If you've been wondering why I've been quiet of late (you have, > > right?!) then this is partly why. I'm not sure why I spent so long > > on an eclass that hardly anyone uses but it's utilised by many of my > > old favourite games. > > Wouldn't this be a good time to rethink the whole concept? By all our > standards, ebuilds shouldn't be interactive. AFAICS, cdrom.eclass is > the last remnant in the tree using PROPERTIES="interactive". mgorny makes good points, it is indeed not quite that simple. I didn't actually notice the --accept-properties=-interactive feature until just now, that's pretty cool. Although I agree it should be avoided, there may be other uses for it in future. I'd still like to go ahead with my lgogdownloader plan (probably via a new src_fetch) and that may need it for entering credentials on rare occasions though there are other possibilities. > Maybe the eclass could be replaced by a utility that extracts the ISO > image and places it into DISTDIR, so that ebuilds could use regular > non-interactive unpacking? The additional disk space used shouldn't be > an argument any more with today's large disks. Don't assume everyone has such huge disks. ;) My main system isn't bad but that doesn't mean I want to waste the space on something like this. Many have written optical media off but I still have two big flight cases full of discs of various kinds nearby. No one is forced to use this stuff and it is possible to use it in a non-interactive manner similar to how you suggest. You can copy the files from the disc(s) and point CD_ROOT to this location in a per-package env file. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpDGHji1Ztv1.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 01/14] cdrom.eclass: Detect case-insensitively and handle special characters
On Tue, 18 Apr 2017 08:08:44 +0200
Michał Górny wrote:
> On pon, 2017-04-17 at 22:53 +0100, James Le Cuirot wrote:
> > diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> > index 41488d2446c2..de72f15563db 100644
> > --- a/eclass/cdrom.eclass
> > +++ b/eclass/cdrom.eclass
> > @@ -79,12 +79,13 @@ cdrom_get_cds() {
> > export CDROM_ROOT=${CD_ROOT_1:-${CD_ROOT}}
> > einfo "Found CD #${CDROM_CURRENT_CD} root at ${CDROM_ROOT}"
> > export CDROM_SET=-1
> > - for f in ${CDROM_CHECK_1//:/ } ; do
> > + IFS=:
>
> 'local', please.
This line disappears later in the series but I've amended it for the
history anyway.
> > @@ -181,28 +182,24 @@ _cdrom_locate_file_on_cd() {
> > local showedmsg=0 showjolietmsg=0
> >
> > while [[ -z ${CDROM_ROOT} ]] ; do
> > - local i=0
> > - local -a cdset=(${*//:/ })
> > + local i=0 cdset
> > + IFS=: read -a cdset <<< "${*}"
>
> -r to avoid handling escapes; -d '' to avoid finishing on newline.
Good call.
> > @@ -243,4 +240,27 @@ _cdrom_locate_file_on_cd() {
> > done
> > }
> >
> > +# @FUNCTION: _cdrom_glob_match
> > +# @USAGE:
> > +# @INTERNAL
> > +# @DESCRIPTION:
> > +# Locates the given path ($2) within the given root directory ($1)
> > +# case-insensitively and returns the first actual matching path. This
> > +# eclass previously used "find -iname" but it only checked the file
> > +# case-insensitively and not the directories. There is "find -ipath" but
> > +# this does not intelligently skip non-matching paths, making it
> > +# slow. Case-insensitive matching can only be applied to patterns so
> > +# extended globbing is used to turn regular strings into patterns. All
> > +# special characters are escaped so don't worry about breaking this. The
> > +# first person to make this work without an eval wins a cookie.
> > +_cdrom_glob_match() {
> > + local p=\?\($(sed -e 's:[^A-Za-z0-9/]:\\\0:g' -e 's:/:)/?(:g' <<< "$2"
> > || die)\)
>
> Explanatory comment needed, i.e. what gets converted into what, and why.
I'll add this:
# The following line turns this:
# foo*foo/bar bar/baz/file.zip
#
# Into this:
# ?(foo\*foo)/?(bar\ bar)/?(baz)/?(file\.zip)
#
# This turns every path component into an escaped extended glob
# pattern to allow case-insensitive matching. Globs cannot span
# directories so each component becomes an individual pattern.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpkMgCgMuOu9.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 01/14] cdrom.eclass: Detect case-insensitively and handle special characters
On Wed, 19 Apr 2017 05:14:34 +0200
Michał Górny wrote:
> >> > @@ -243,4 +240,27 @@ _cdrom_locate_file_on_cd() {
> >> > done
> >> > }
> >> >
> >> > +# @FUNCTION: _cdrom_glob_match
> >> > +# @USAGE:
> >> > +# @INTERNAL
> >> > +# @DESCRIPTION:
> >> > +# Locates the given path ($2) within the given root directory ($1)
> >> > +# case-insensitively and returns the first actual matching path.
> >This
> >> > +# eclass previously used "find -iname" but it only checked the
> >file
> >> > +# case-insensitively and not the directories. There is "find
> >-ipath" but
> >> > +# this does not intelligently skip non-matching paths, making it
> >> > +# slow. Case-insensitive matching can only be applied to patterns
> >so
> >> > +# extended globbing is used to turn regular strings into patterns.
> >All
> >> > +# special characters are escaped so don't worry about breaking
> >this. The
> >> > +# first person to make this work without an eval wins a cookie.
> >> > +_cdrom_glob_match() {
> >> > +local p=\?\($(sed -e 's:[^A-Za-z0-9/]:\\\0:g' -e 's:/:)/?(:g'
> >> > <<<
> >"$2" || die)\)
> >>
> >> Explanatory comment needed, i.e. what gets converted into what, and
> >why.
> >
> >I'll add this:
> >
> ># The following line turns this:
> ># foo*foo/bar bar/baz/file.zip
> >#
> ># Into this:
> ># ?(foo\*foo)/?(bar\ bar)/?(baz)/?(file\.zip)
> >#
> ># This turns every path component into an escaped extended glob
> ># pattern to allow case-insensitive matching. Globs cannot span
> ># directories so each component becomes an individual pattern.
>
> Why do you escape pattern chars? Wasn't the variable supposed to be a
> pattern in the first place?
If you mean in the eclass before I changed it then no. In the non
CD_ROOT case, the basename was passed to "find -iname" but this was not
documented. In the CD_ROOT case, the whole thing was passed to
[[ -e ]] so patterns wouldn't have worked here.
You wouldn't want to use a pattern anyway as you're trying to uniquely
identify the disc using a very specific filename. Conversely, I relaxed
case-sensitivity because this can vary depending on whether we're
dealing with the original disc, a copy of some kind, or an existing
installation that may come from Windows.
The Curse of Monkey Island turned out to be a great example. Both discs
have some files in common like COMI.LA0, however, when mounted with the
default options, it appears upper-cased on the first disc but
lower-cased on the second. Why? The second disc doesn't use Joliet as
all the filenames have the old 8.3 format. Linux normalises these to
lower-case. The first disc does use Joliet because of a single file,
"Curse of Monkey Island - Manual.pdf" so all the other 8.3 filename are
left as upper-case by Linux.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpeNIjKYyVV0.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] cdrom.eclass: Near rewrite
On Mon, 17 Apr 2017 22:53:45 +0100 James Le Cuirot wrote: > If you've been wondering why I've been quiet of late (you have, > right?!) then this is partly why. I'm not sure why I spent so long on > an eclass that hardly anyone uses but it's utilised by many of my old > favourite games. > > The main bug that it fixes is one I filed a report for 10 years ago! > There were also several duplicates. If you want something done... > > I realised part way through that I didn't have any multi-disc games > that use this eclass any more. A former friend of mine lost my second > UT99 disc with the high resolution textures. I couldn't rewrite the > eclass without testing it thoroughly so I wrote a brand new "comi" > (Curse of Monkey Island) ebuild for use with ScummVM! I'll get this > committed when these changes go in. I've also revised all the > Descent-related packages. Merged with the suggested fixes. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpzdnqnXskZF.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] crossdev: installing _host_ build dependencies not automatic?
On Wed, 3 May 2017 17:56:43 +0200 Alexis Ballier wrote: > On Wed, 3 May 2017 12:05:48 +0200 > "Paweł Hajdan, Jr." wrote: > > > I encountered <https://bugs.gentoo.org/show_bug.cgi?id=617276> while > > working on some cross-compiling project. > > > > Admittedly, it may not be that easy to handle host package > > dependencies fully automatically. > > > > I'm wondering - is it documented what portage guarantees, and what I'm > > expected to just manually handle to provide host build dependencies? > > > > Any other advice about properly using crossdev would also be > > appreciated. I'd be happy to test and help improve things. > > > From man emerge: > > >--root-deps[=rdeps] > If no argument is given then build-time dependencies of >packages for ROOT are installed to ROOT instead of /. If the >rdeps argument is given then discard all build-time dependencies >of packages for ROOT. This option is only meaningful when used >together with ROOT and it should not be enabled under normal >circumstances! > > Does not affect EAPIs that support HDEPEND. Experimental > EAPI 5-hdepend provides HDEPEND as a new means to adjust > installation into "/" and ROOT. If ebuilds using EAPIs > which do not support HDEPEND are built in the same > emerge run as those using EAPIs which do support HDEPEND, > this option affects only the former. > > > crossdev wrappers set --root-deps=rdeps (read cross-emerge, this can be > overriden), but be careful: If you only care about getting all the deps > and maybe more then removing --root-deps might help you. However, when > cross compiling you will likely run into broken deps since / and ROOT > will not use the same keyword visibility. I was going to point to crossdev's use of --root-deps=rdeps too. I did wonder why on earth this was even added. I overrode it for quite a while and didn't have any issue. History showed that it was added by solar without much of an explanation. He's no longer around to ask. It wasn't until I tried to build a brand new ppc64le system recently that I finally found a reason for it, though I'm not sure it was the original reason. The multilib ABI USE flags start conflicting horribly in cross situations and this option seems to be the only way around it at present. I doubt keyword visibility is an issue. Portage uses a different configuration between / and ROOT when cross-compiling. I don't think it tries to force the same package versions beyond what is specified in the ebuild. For pure build-time dependencies, the package will only be installed to / anyway (i.e. you don't need cmake in ROOT) so there is nothing to enforce here. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpG_YTyPPSfi.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"
On Wed, 10 May 2017 08:20:32 -0500 Matthias Maier wrote: > On Wed, May 10, 2017, at 02:28 CDT, Martin Vaeth > wrote: > > > I am using gcc-6 since ages and tried to run a desktop with default > > pie for quite a while, but soon was forced to give up: > > > [...] > > I have pie enabled on a desktop for years. Almost all major linux > distribution have pie enabled as well nowadays. > > https://wiki.debian.org/Hardening/PIEByDefaultTransition This is less significant but I'd still like to add that I just updated gcc to 6 followed by @world with some 500 packages and I didn't hit a single PIE issue. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Last rites: www-apps/postfixadmin
On Thu, 08 Jun 2017 18:18:09 +0700
"Vadim A. Misbakh-Soloviov" wrote:
> Well, actually, I think that whole webapps structure in gentoo should
> be dropped or totally rewritten, despite of web applications packages
> state in the gentoo repo.
> It is unextendable, uncomfortable, no-gentoo-way'ish and so on.
>
> I think, it would even be better to just install apps
> in /usr/share/${PF} than current webapp behaviour.
Actually I quite like the way webapp-config works. Some improvements
are needed but nothing major. I would particularly like to see nginx
configuration snippets dynamically generated for a slightly more
out-of-the-box experience. There also doesn't seem to be a way to
protect configuration files containing sensitive credentials from local
users.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
[gentoo-dev] Profile-enforced big-endian USE flag
Hello devs, I'm currently adding ppc64le to the list of platforms supported by icedtea-bin before we lose gcj to save me fudging around later. This addition presents a small problem. I currently use the ARCH (e.g. amd64) and ABI (e.g. abi_x86_32) USE flags to fetch the relevant tarballs. The trouble is that there is no flag that decides the endianness. Both ppc64 and ppc64le share the "ppc64" ARCH and ABI. The only differing element between the two profiles is CHOST, which starts with powerpc64- and powerpc64le- respectively. This is sufficient when dealing with multilib-enabled source ebuilds. As far as I know, there is no such as thing as a mixed endian system on any architecture. They require different kernels. If a package doesn't work on one endian type, it can simply be masked in that profile. However, when dealing with binary ebuilds, you ideally want to split the different platforms into separate tarballs to reduce the download size. The platform-specific tarballs for icedtea-bin:8 currently weigh around 55MB each. It would be polite not to double this for ppc64. You can't use CHOST in SRC_URI so a new USE flag is the only way. I am therefore proposing a new global big-endian flag. This could be masked by default and unmasked + forced in the relevant profiles under arch. I will apply this according to the mapping defined in tc-endian of toolchain-funcs.eclass. There is just one package already this flag, dev-haskell/skein. I don't believe it would need to change though it might want to hard enable the force-endianness option or at least enable it by default. On the other hand, using tc-endian may be a better option here. If we're broadly agreed then I will submit a patch for review. On a side note, this problem also applies to soft vs hard float except that these can be mixed under the same kernel. We don't have profiles for these though and soft float seems to be a relic now anyway, at least on ARM. Cheers, -- James Le Cuirot (chewi) Gentoo Linux Developer pgpd5ujrDlhPv.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Profile-enforced big-endian USE flag
On Wed, 28 Jun 2017 17:52:26 -0400 Mike Gilbert wrote: > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot wrote: > > I am therefore proposing a new global big-endian flag. This could be > > masked by default and unmasked + forced in the relevant profiles under > > arch. I will apply this according to the mapping defined in tc-endian of > > toolchain-funcs.eclass. I've just been putting the patch together. I made it slightly simpler by masking *and* forcing it by default so that it only needs to be unmasked were necessary. > A possible alternative would be to create a new USE_EXPAND variable > for this. That would allow for easier expansion in case we ever > support something other than big/little endian machines. That way madness lies? Wikipedia talks about middle-endian as being the catch all for other random orderings that have appeared over the years but I don't think any of them were used on a system-wide basis. I can't imagine Linux ever supporting such a thing. Unless you're talking about dealing with soft vs hard float here too? -- James Le Cuirot (chewi) Gentoo Linux Developer pgpPckculHDJL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Profile-enforced big-endian USE flag
On Wed, 28 Jun 2017 23:29:03 +0100 James Le Cuirot wrote: > > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot wrote: > > > I am therefore proposing a new global big-endian flag. This could be > > > masked by default and unmasked + forced in the relevant profiles under > > > arch. I will apply this according to the mapping defined in tc-endian of > > > toolchain-funcs.eclass. > > I've just been putting the patch together. I made it slightly simpler > by masking *and* forcing it by default so that it only needs to be > unmasked were necessary. Feedback seems positive so here is the patch. I'll apply it late next week as I don't need it immediately and I will be away until then. --- From e6aaee518b5e7eab735116a2ea57d538a8e26c19 Mon Sep 17 00:00:00 2001 From: James Le Cuirot Date: Thu, 29 Jun 2017 22:11:49 +0100 Subject: [PATCH] profiles: Add profile-enforced global big-endian USE flag The flag is forced and masked by default and then unmasked where necessary. Note that there are some big endian host values listed in tc-endian() that we do not have profiles for. --- profiles/arch/alpha/use.mask | 4 profiles/arch/arm64/big-endian/use.mask | 6 ++ profiles/arch/base/use.force | 6 ++ profiles/arch/base/use.mask | 4 profiles/arch/hppa/use.mask | 4 profiles/arch/m68k/use.mask | 7 +++ profiles/arch/mips/mipsel/use.mask| 6 ++ profiles/arch/mips/use.mask | 4 profiles/arch/powerpc/ppc64/64le/use.mask | 4 profiles/arch/powerpc/use.mask| 7 +++ profiles/arch/s390/use.mask | 7 +++ profiles/arch/sparc/use.mask | 4 profiles/use.desc | 3 ++- 13 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 profiles/arch/arm64/big-endian/use.mask create mode 100644 profiles/arch/base/use.force create mode 100644 profiles/arch/mips/mipsel/use.mask diff --git a/profiles/arch/alpha/use.mask b/profiles/arch/alpha/use.mask index d488fe8a09f4..b17afe9d9d4d 100644 --- a/profiles/arch/alpha/use.mask +++ b/profiles/arch/alpha/use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2017 Gentoo Foundation. # Distributed under the terms of the GNU General Public License, v2 +# James Le Cuirot (29 Jun 2017) +# Unmask as this profile is big endian. +-big-endian + # Tobias Klausmann (03 March 2017) # There is no luajit support on alpha. Bugs #554376, #608322. luajit diff --git a/profiles/arch/arm64/big-endian/use.mask b/profiles/arch/arm64/big-endian/use.mask new file mode 100644 index ..0a4af0711f5c --- /dev/null +++ b/profiles/arch/arm64/big-endian/use.mask @@ -0,0 +1,6 @@ +# Copyright 1999-2017 Gentoo Foundation. +# Distributed under the terms of the GNU General Public License, v2 + +# James Le Cuirot (29 Jun 2017) +# Unmask as this profile is big endian. +-big-endian diff --git a/profiles/arch/base/use.force b/profiles/arch/base/use.force new file mode 100644 index ..7f213b9dd017 --- /dev/null +++ b/profiles/arch/base/use.force @@ -0,0 +1,6 @@ +# Copyright 1999-2017 Gentoo Foundation +# Distributed under the terms of the GNU General Public License v2 + +# James Le Cuirot (29 Jun 2017) +# Forced and masked by default. Unmask where necessary. +big-endian diff --git a/profiles/arch/base/use.mask b/profiles/arch/base/use.mask index 1a4a39cefc13..2ea1fb3d89fa 100644 --- a/profiles/arch/base/use.mask +++ b/profiles/arch/base/use.mask @@ -1,6 +1,10 @@ # Copyright 1999-2017 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 +# James Le Cuirot (29 Jun 2017) +# Forced and masked by default. Unmask where necessary. +big-endian + # Sven Wegener (31 May 2017) # libvirt is only supported on specific architectures libvirt diff --git a/profiles/arch/hppa/use.mask b/profiles/arch/hppa/use.mask index 7361e2c52af2..bd158162a449 100644 --- a/profiles/arch/hppa/use.mask +++ b/profiles/arch/hppa/use.mask @@ -3,6 +3,10 @@ # NOTE: When masking a USE flag due to missing keywords, please file a keyword # request bug for the hppa arch. +# James Le Cuirot (29 Jun 2017) +# Unmask as this profile is big endian. +-big-endian + # Andreas Sturmlechner (25 Feb 2017) # kwallet integration split from kde to distinct flag kwallet diff --git a/profiles/arch/m68k/use.mask b/profiles/arch/m68k/use.mask index aac0e46e97c2..646567111d56 100644 --- a/profiles/arch/m68k/use.mask +++ b/profiles/arch/m68k/use.mask @@ -1,6 +1,13 @@ +# Copyright 1999-2017 Gentoo Foundation. +# Distributed under the terms of the GNU General Public License, v2 + # Unmask the flag which corresponds to ARCH. -m68k +# James Le Cuirot (29 Jun 2017) +# Unmask as this profile is big endian. +-big-endian + hardened # Paul de Vrieze diff --git a/profiles/arch/mips/mipsel/use.mask b/profiles/arch/mips/mipsel/use.mas
Re: [gentoo-dev] [PATCH] Profile-enforced big-endian USE flag
On Thu, 29 Jun 2017 14:37:49 -0700 Matt Turner wrote: > On Thu, Jun 29, 2017 at 2:19 PM, James Le Cuirot wrote: > > On Wed, 28 Jun 2017 23:29:03 +0100 > > James Le Cuirot wrote: > > > >> > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot > >> > wrote: > >> > > I am therefore proposing a new global big-endian flag. This could be > >> > > masked by default and unmasked + forced in the relevant profiles under > >> > > arch. I will apply this according to the mapping defined in tc-endian > >> > > of > >> > > toolchain-funcs.eclass. > >> > >> I've just been putting the patch together. I made it slightly simpler > >> by masking *and* forcing it by default so that it only needs to be > >> unmasked were necessary. > > > > Feedback seems positive so here is the patch. I'll apply it late next > > week as I don't need it immediately and I will be away until then. > > > > --- > > > > diff --git a/profiles/arch/alpha/use.mask b/profiles/arch/alpha/use.mask > > index d488fe8a09f4..b17afe9d9d4d 100644 > > --- a/profiles/arch/alpha/use.mask > > +++ b/profiles/arch/alpha/use.mask > > @@ -1,6 +1,10 @@ > > # Copyright 1999-2017 Gentoo Foundation. > > # Distributed under the terms of the GNU General Public License, v2 > > > > +# James Le Cuirot (29 Jun 2017) > > +# Unmask as this profile is big endian. > > +-big-endian > > No. Alpha is little endian. Wikipedia says it is bi. tc-native() reports alpha* as big so I guess that's the only variant we support? Then again, this page says it is usually little. Is tc-native() wrong? https://kernelnewbies.org/EndianIssues > > --- /dev/null > > +++ b/profiles/arch/mips/mipsel/use.mask > > @@ -0,0 +1,6 @@ > > +# Copyright 1999-2017 Gentoo Foundation > > +# Distributed under the terms of the GNU General Public License v2 > > + > > +# James Le Cuirot (29 Jun 2017) > > +# Remask as this profile is little endian. > > +big-endian > > diff --git a/profiles/arch/mips/use.mask b/profiles/arch/mips/use.mask > > index 09ac8ca4b2cc..6caff81617cb 100644 > > --- a/profiles/arch/mips/use.mask > > +++ b/profiles/arch/mips/use.mask > > @@ -4,6 +4,10 @@ > > # Unmask the flag which corresponds to ARCH. > > -mips > > > > +# James Le Cuirot (29 Jun 2017) > > +# Unmask as this profile is big endian. > > +-big-endian > > I'm not sure if this one is correct. arch/mips/mipsel's 'parent' file > contains '..' > > I think if you re-mask big-endian in arch/mips/mipsel it'll work, and > that seems like the best way to solve it. That's what I did? pgpusFUoTbJJb.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha
Funny that no one noticed this for 10 years. :) Thanks to klausman for
clearing this up.
---
eclass/toolchain-funcs.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 121db46e62b5..777fce905f3e 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -572,7 +572,7 @@ tc-endian() {
case ${host} in
aarch64*be) echo big;;
aarch64)echo little;;
- alpha*) echo big;;
+ alpha*) echo little;;
arm*b*) echo big;;
arm*) echo little;;
cris*) echo little;;
--
2.13.1
Re: [gentoo-dev] [PATCH] Profile-enforced big-endian USE flag
On Thu, 29 Jun 2017 22:19:58 +0100 James Le Cuirot wrote: > On Wed, 28 Jun 2017 23:29:03 +0100 > James Le Cuirot wrote: > > > > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot > > > wrote: > > > > I am therefore proposing a new global big-endian flag. This could be > > > > masked by default and unmasked + forced in the relevant profiles under > > > > arch. I will apply this according to the mapping defined in tc-endian of > > > > toolchain-funcs.eclass. > > > > I've just been putting the patch together. I made it slightly simpler > > by masking *and* forcing it by default so that it only needs to be > > unmasked were necessary. > > Feedback seems positive so here is the patch. I'll apply it late next > week as I don't need it immediately and I will be away until then. > > --- > > diff --git a/profiles/arch/powerpc/use.mask b/profiles/arch/powerpc/use.mask > index 6f993c6628c0..02e97b16f06d 100644 > --- a/profiles/arch/powerpc/use.mask > +++ b/profiles/arch/powerpc/use.mask > @@ -1,6 +1,13 @@ > +# Copyright 1999-2017 Gentoo Foundation > +# Distributed under the terms of the GNU General Public License v2 > + > # PPC Specific use flags > # > > +# James Le Cuirot (29 Jun 2017) > +# Forced and masked by default. Unmask where necessary. > +big-endian > + > # Matt Turner (24 Mar 2017) > # virtual/opencl is not keyworded > opencl Just noticed a copy/pasta fail here. Obviously should be -big-endian. pgpqC_NlS_M57.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha
On Sat, 1 Jul 2017 09:55:29 +0100
James Le Cuirot wrote:
> Funny that no one noticed this for 10 years. :) Thanks to klausman for
> clearing this up.
> ---
> eclass/toolchain-funcs.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 121db46e62b5..777fce905f3e 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -572,7 +572,7 @@ tc-endian() {
> case ${host} in
> aarch64*be) echo big;;
> aarch64)echo little;;
> - alpha*) echo big;;
> + alpha*) echo little;;
> arm*b*) echo big;;
> arm*) echo little;;
> cris*) echo little;;
Merged.
pgp_U3Q7lKdS7.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Sets vs Meta ebuilds
On Fri, 7 Jul 2017 12:48:04 -0400 NP-Hardass wrote: > There is actually a huge functional difference between the two that you > are missing here. A meta package defines its dependencies in full > dependency syntax. This means you can specify versions, USE flag > dependencies, make packages dependent on USE flags, etc. A package set > is just a list of packages (potentially constrained by version. TTBOMK, > there is no inclusion of any USE flag functionality in sets. > Additionally, let's say you have a more complicated dependency like || ( > A B ), I don't think there is a way to describe that in a package set > at all. Actually you can specify basic USE dependencies in sets. You can also specify SLOTs. For example, this is valid. media-libs/tiff:3[abi_x86_32,jpeg,zlib,-cxx] -- James Le Cuirot (chewi) Gentoo Linux Developer pgpplbLJbE9bC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: taking a break from arches stabilization
On Tue, 11 Jul 2017 16:15:51 +0200 Kristian Fiskerstrand wrote: > On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote: > > On 07/11/2017 03:47 PM, Michael Palimaka wrote: > >> The main risk of breakage of a package moving from testing to > >> stable is always at build time anyway. > > > > citation needed > > > > Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will > happily sign a third party public keyblock's UID using signature > subkey on smartcard, which results in useless signature that doesn't > have any effect, but the application builds fine. > > This means gnupg 2.1.21 is not a candidate for stabilization, but it > certainly builds fine. This is a good opportunity to remind ourselves what stable means. Are we referring exclusively to our packaging or are upstream issues taken into account too? 30 days seems like a reasonable time for any upstream issues to be reported. Unfortunately security issues mean that new releases sometimes get stabilised immediately. Ideally these releases would carry just the security fixes but that isn't always the case. -- James Le Cuirot (chewi) Gentoo Linux Developer
[gentoo-dev] net-misc/r8168 up for grabs
I no longer have a motherboard with this hardware. Towards the end I found that the mainline r8169 driver worked anyway, even though it didn't used to. There are still some revisions of the hardware that don't work with the mainline driver. The package is fairly low maintenance. The driver sometimes breaks following new kernel releases but Realtek usually put out a new driver by the time the next release comes around. You can sometimes find patches floating around the community before that. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpUpnpE5WXDc.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] java-pkg-opt-2.eclass: fix java-pkg-opt-2_src_prepare to always call eapply_user for EAPI-6+
On Sun, 30 Jul 2017 14:32:53 +0300 Andrew Savchenko wrote: > For EAPI 6+ java-pkg-opt-2_src_prepare() has eapply_user call via > java-utils-2_src_prepare() from java-utils-2.eclass. But > java-utils-2_src_prepare() call is conditional and in case when > package is build with USE=-java java-utils-2_src_prepare() is not > called, hence eapply_user is not called in src_prepare phase and > ebuild fails. > > The following patch fixes this by calling eapply_user if java USE > is disabled _and_ EAPI is 6+. This makes sense so no problem here. > [pedantic mode on] > Strictly speaking when EAPI is other than [0-5]. The way java-* > eclasses are now, they assume ![0-5] == 6+. It may be speculated > that this is not entirely correct and many other eclasses > explicitly deny all unknown EAPIs. If someone is interesting in > fixing this issue, please handle it with the java team and do not > mix it into the problem described at the beginning. My goal now is > to fix eapply_user issue which cases trouble for any EAPI 6 > packages with optional java support and default src_prepare() at > the ebuild scope. > [pedantic mode off] Agreed. I don't think java-utils-2_src_prepare() should be changed in this regard as the behaviour may continue to be correct but the eclass should have a global EAPI check that forbids anything beyond 6 like other eclasses do. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpequPLcnucX.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-benchmarks/jmeter, java-virtuals/javamail, dev-java/{gnu-classpath-inetlib,gnu-javamail,sun-javamail}
# James Le Cuirot (29 Aug 2017) # The FOSS-friendly oracle-javamail has rendered other implementations # and the virtual obsolete. Removal in 30 days. See bug #553186. dev-java/gnu-classpath-inetlib dev-java/gnu-javamail dev-java/sun-javamail java-virtuals/javamail # James Le Cuirot (29 Aug 2017) # Old and holding up the removal of Java 7. Still alive upstream but # new versions have proven too tricky to package under our current # infrastructure. It may return one day. Removal in 30 days. app-benchmarks/jmeter -- James Le Cuirot (chewi) Gentoo Linux Developer pgpCOiWmM9xu2.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-benchmarks/jmeter, java-virtuals/javamail, dev-java/{gnu-classpath-inetlib,gnu-javamail,sun-javamail}
On Tue, 29 Aug 2017 18:26:33 -0400 "William L. Thomson Jr." wrote: > On Tue, 29 Aug 2017 22:35:25 +0100 > James Le Cuirot wrote: > > > # James Le Cuirot (29 Aug 2017) > > # The FOSS-friendly oracle-javamail has rendered other implementations > > # and the virtual obsolete. Removal in 30 days. See bug #553186. > > dev-java/gnu-classpath-inetlib > > dev-java/gnu-javamail > > dev-java/sun-javamail > > java-virtuals/javamail > > Oracle javamail is no more, so need to add a couple more > > +dev-java/oracle-javamail > +dev-java/javax-mail (duplicate package added by mistake) > > Both the same as sun-javamail and since renamed to just javamail. > Final name change > https://github.com/javaee/javamail Thanks for that. We started this ball rolling a while ago so I should have checked the current situation. This is getting a bit ridiculous but hopefully this really is the final time. I'll add javax-mail to the list and see if we can handle oracle-javamail -> javamail as a package move. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpaVO9UH3QbX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] PowerPC Resources at OSU
On Mon, 11 Sep 2017 23:29:10 -0500 R0b0t1 wrote: > 1) May I have access to a/the POWER server, or some other suitable > POWER resource? If not, > 2) is anyone available to verify that I am associated with the project > or that I will use the resources for project related work? > > My intent is to experiment with the PowerPC architecture, specifically > features found on newer POWER processors and servers. It is unlikely I > will ever get to do this on my own as the machines run $10k-$30k. I > requested services from OSU because GCC was not able to accommodate my > request for hypervisor access on their system. > > However, having finally found the resources I've been looking for this > whole time, it looks like OSU's nodes are virtualized and won't be > able to do exactly what I want anyway (i.e. the GCC sysadmin was > misinformed), so I may have accidentally wasted people's time and > potentially tarnished Gentoo's reputation. I will make amends as best > I can. As of a few months ago, we have two POWER8 guests, one big endian (timberdoodle) and one little endian (bogsucker). We would just have one but you can't mix big and little endian on the same system. After the old POWER7 timberdoodle died, I was responsible for creating these new instances with some help from prometheanfire. Replacing CentOS systems that had tied up all the storage from the other side of the world with no direct raw access was an interesting challenge! I didn't intend to manage the systems long term though as I only use them for building and testing Java stuff. I consider prometheanfire, blueness, and vapier to be in charge though you may struggle getting hold of the latter two. We generally only give access to devs but I am aware of one exception we made for gnu_andrew, who works for Red Hat and provides our icedtea ebuilds. Unfortunately I've only seen you on this list but hopefully someone can vouch for you. I don't know whether these guests will be suitable for your needs though. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpGPbYbQF_Ah.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Wed, 20 Sep 2017 12:08:01 +0200 Thomas Sachau wrote: > - dev-java/commons-compress: Needs a version bump, which requires > additional dependencies You may as well just stick this one under j...@gentoo.org. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On 30 September 2017 08:19:36 BST, "Michał Górny" wrote:
>W dniu sob, 30.09.2017 o godzinie 00∶20 -0400, użytkownik Walter Dnes
>napisał:
>> On Thu, Sep 28, 2017 at 04:27:31PM -0500, Austin English wrote
>> > (Note: serious discussion, please take systemd trolling elsewhere).
>> >
>> > While having the pleasure of working with some proprietary software
>> > recently, I was asked to run `service foo restart`, and was
>surprised to
>> > see:
>> > foobar ~ # service foo restart
>> > * service: service `foo' does not exist
>>
>> Ridiculous! We need to develop one universal standard that covers
>> everyone's use cases. https://xkcd.com/927/
>>
>> But if you insist, why not just set up a short bash script called
>> "service" rather than monkeying with every init system's internals?
>>
>>
>> #!/bin/bash
>> if [[ ]] ; then
>>systemctl ${2} ${1}
>> elif [[ ]] ; then
>>/etc/init.d/${1} ${2}
>> elif [[ ]] ; then
>>
>> else
>>echo "ERROR: Unsupported init system; 'service' call failed"
>> fi
>>
>>
>> This can handle a large number of different inits, with as many
>"elif"
>> lines as you care to add. But, how do we reliably detect the
>currently
>> running init system? Are there running processes, or entries in
>/sys/
>> or /proc/ or /dev that are unique to to each init system?
>>
>
>You forgot the huge mapping between different service names. Then
>complex mapping from services that are split/merged. Next we need a
>tool
>that will update conf.d for OpenRC services which are split in systemd,
>to allow people controlling them independently.
Names aren't consistent between Debian and Red Hat either so that isn't really
an issue.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] Package up for grabs: net-ftp/atftp
On Mon, 30 Oct 2017 09:32:17 +0100 Matthias Hanft wrote: > Tobias Klausmann wrote: > > > > I haven't used atftp in a *long* time and upstream is either dead > > or has entered a time capsule on SF.net. > > I am considering last-riting it right away > > I'm still using it every day (our PBX uploads its accounting tickets > to our Gentoo server using TFTP). If it's gone, which TFTP server > should I use? The only other server I can find by "emerge -s tftp" > is "net-ftp/tftp-hpa". Is this the "state-of-the-art" TFTP server? dnsmasq has a TFTP server though it's obviously not the main feature and I only use it occasionally. -- James Le Cuirot (chewi) Gentoo Linux Developer
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] Re: No more stable keywords for Games
On Sun, 19 Nov 2017 08:50:20 -0500 Philip Webb wrote: > 171118 David Seifert wrote: > > As the Games team does not have enough manpower to keep tabs on all > > games packages, we have dropped all games-* ebuilds to unstable > > keywords (modulo those required by stable non-games packages). > > > > While I accept that this will cause some irritation for the community, > > pretending we have a well supported games collection by having a wealth > > of stable games packages is misleading at best. By having 99% of games > > be unstable, we convey the expectation users should have - namely that > > games in Gentoo are not part of crucial Tier 1 packages. > > > > We welcome contributions from outsiders willing to polish up the games > > landscape in Gentoo. > > Isn't this overkill in the absence of widespread bug reports for games ? > 'Stable' doesn't mean well-maintained, > but in the tree for some time & no serious bug reports. There are plenty of bug reports for games. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp51gAhMDnf5.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: Dead Qt4-based games-*/
On Sun, 03 Dec 2017 20:41:56 +0100 Andreas Sturmlechner wrote: > # Andreas Sturmlechner (03 Dec 2017) > # Dead upstreams, depending on dead qt3support/qt4. > # Masked for removal in 30 days. Bug #631788 > ... > games-kids/crayon-physics This is a commercial game that I have played in the past and still have installed. I think you have to take special consideration over packages for things that people have paid money for. You can't so easily say "Oh just play another game then." You also can't expect "upstream" to address the issue. We have sometimes left vulnerable commercial games masked in the tree but in this case, the offender is the Qt4 dependency. I'm guessing that we won't be leaving Qt4 masked in the tree so I'm not sure what to suggest. The game does bundle some libraries but Qt4 isn't one of them, not that that would be a great idea anyway. I wondered if this would also affect Steam but Qt isn't in the Ubuntu-based runtime so any game using it would need to bundle it with the game itself. I haven't come across any other commercial games using Qt but this proves that there is at least one. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpFwMUAG9b_e.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] javaws always use icedtea
On Wed, 13 Dec 2017 22:25:51 + Samuel Bernardo wrote: > I'm using oracle jdk as default jvm, but when I review java-config > result after setting oracle-jdk-bin as prefered jvm, javaws continues to > start icedtea version. Disable the webstart flag against icedtea(-bin) and unmerge dev-java/icedtea-web. Job done. This used to be configurable through eselect but it was really overcomplicated for no benefit. This is all documented here and shown when you install icedtea-web the first time. https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/icedtea-web/files/README.gentoo-r1 -- James Le Cuirot (chewi) Gentoo Linux Developer pgpSfsyNWBm6Q.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/
On Thu, 14 Dec 2017 14:14:19 +0100 Fabian Groffen wrote: > > >On 14-12-2017 12:10:59 +, Andreas Hüttel wrote: > > >> Also other QA issues. > > Apart from that maintainer-needed has nothing to do with Quality of an > ebuild, you mentioned it as an QA issue, so I am interested in the > "other" QA issues, which seems to suggest 2+ problems in this > *ebuild*. I believe I found one. use man && doxygen || die This will die when "man" is disabled? While I do agree that the maintainer-needed issue was reason enough, if you're going to say there are other issues then you should have the decency to say what they are. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB
On Sun, 17 Dec 2017 20:23:21 +0100 "Andreas K. Huettel" wrote: > Am Sonntag, 17. Dezember 2017, 14:21:10 CET schrieb Michał Górny: > > Hello, everyone. > > > > It's my pleasure to announce that with a majority vote the QA team has > > accepted a new policy. The accepted wording is: > > > > Total size of 'files' subdirectory of a package should not be larger > > than 32 KiB. If the package needs more auxiliary files, they should > > be put into SRC_URI e.g. via tarballs. > > > > (the total size being computed as a sum of apparent file sizes) > > > > This is hard (but not impossible I guess) for toolchain stuff, even though we > have already most patches in external tarballs, since we want to keep some > old > versions of packages available. > > huettel@pinacolada ~/Gentoo/gentoo/sys-libs/glibc/files $ du -sh . > 152K. Is this the right measure? Actual disk usage will vary depending on block size. For me, this is only 94K. "du -bsh" gives the true byte total as 79K. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpeKx71coRMC.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Projects up for grabs: cron, m68k
On Wed, 20 Dec 2017 18:02:22 +0100 Michał Górny wrote: > Hello, everyone. > > Due to prolonged inactivity of Mike Frysinger (vapier), the following > projects have had effectively no members for 6 months already: > > https://wiki.gentoo.org/wiki/Project:M68k > > sys-apps/zorroutils [m] Aww, if only my (t)rusty old Amiga actually had a Zorro bus. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue
On Tue, 9 Jan 2018 18:07:41 -0600 William Hubbs wrote: > All, > > please take a look at the following issue. > > https://github.com/openrc/openrc/issues/195 > > The first part of the fix is committed to master as shown on the issue; > checkpath should *never* follow symbolic links when changing ownership, > so I have moved to the lchown call instead of chown. > > However, I'm not sure how to deal with the hard link issue in a way that > will not break service scripts. > > If anyone has any suggestions for this, let me know. I faced the hard link problem in another package (bug still restricted) recently. I'm about to push the fix out but I just want check what I've done is okay. The init script used to call chown/chmod -R, which is obviously bad. I've compromised by only calling these on the directories themselves (ignoring symlinks). I believe this is safe because it's not possible to create hard linked directories these days? Would you agree? -- James Le Cuirot (chewi) Gentoo Linux Developer pgptjfZgxZGvt.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] News Item: Portage Dynamic Deps
On Mon, 22 Jan 2018 11:28:21 +0100 "Andreas K. Huettel" wrote: > Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico: > > > > According to Gentoo policy, future ebuild dependency changes need > > to be accompanied by a revision bump in order to trigger rebuilds > > for users. Therefore, you should only need to use --changed-deps=y > > for a single deep @world update. After that, if you encounter > > installed packages with outdated dependencies in a future deep > > @world update, then you should report it as a bug. > > Did you come up with a solution how to handle eclass-generated > dependency changes then? > > I'd loathe to have to do identical revision bumps for, say, all perl- > module.eclass consumers... Isn't there a rule about allowing existing dependency version bumps? I can't remember exactly how it went. Something about subsets. ;) -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] as-needed patch for ltmain.sh
On Thu, 1 Feb 2018 11:55:46 +0100 Andreas Fink wrote: > Hello, > I have a question to the patch provided by the package > app-portage/elt-patches, namely the file as-needed/2.4.3 > > Here I can see the following being added to ltmain.sh: > + -Wl,--as-needed|-Wl,--no-as-needed) > + deplibs="$deplibs $arg" > + continue > + ;; > + > > In my understanding the order must be the opposite otherwise it has no > effect to $deplibs, i.e. the line should be deplibs="$arg $deplibs". It's been like that in every version of the patch so it's probably like that for a reason though I don't know what that reason is. This is interesting as I gather the whole reason for the patch is that an unpatched libtool inserts the flag in the wrong place. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] as-needed patch for ltmain.sh
On Fri, 2 Feb 2018 13:22:11 +0100 Andreas Fink wrote: > On Thu, 1 Feb 2018 11:06:52 + > James Le Cuirot wrote: > > > On Thu, 1 Feb 2018 11:55:46 +0100 > > Andreas Fink wrote: > > > > > Hello, > > > I have a question to the patch provided by the package > > > app-portage/elt-patches, namely the file as-needed/2.4.3 > > > > > > Here I can see the following being added to ltmain.sh: > > > + -Wl,--as-needed|-Wl,--no-as-needed) > > > + deplibs="$deplibs $arg" > > > + continue > > > + ;; > > > + > > > > > > In my understanding the order must be the opposite otherwise it has > > > no effect to $deplibs, i.e. the line should be deplibs="$arg > > > $deplibs". > > > > It's been like that in every version of the patch so it's probably > > like that for a reason though I don't know what that reason is. This > > is interesting as I gather the whole reason for the patch is that an > > unpatched libtool inserts the flag in the wrong place. > > > > Should I file a bug for this behaviour, or is this correct behaviour? I'm hoping someone more knowledgable will comment but everyone (except me!) is at FOSDEM at the moment. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpRrhuEfzWpX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 08 Feb 2018 16:51:52 +0200 Mart Raudsepp wrote: > On Thu, 2018-02-08 at 14:57 +0100, Michael Lienhardt wrote: > > > > From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 > > > > 00:00:00 2001 > > > > From: Matt Turner > > > > Date: Tue, 6 Feb 2018 14:02:59 -0800 > > > > Subject: x11-base/xorg-server: Remove dead x11- > > > > proto/xf86rushproto dependency > > > > > > > > rushproto hasn't been required since upstream commit > > > > 8ec79e05feac (in > > > > 2005!), and even then it wasn't actually needed! > > > > > > > > Package-Manager: Portage-2.3.19, Repoman-2.3.6 > > > > --- > > > > x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +-- > > > > x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +-- > > > > x11-base/xorg-server/xorg-server-.ebuild | 3 +-- > > > > 3 files changed, 3 insertions(+), 6 deletions(-) > > > > > > > > > > Please don't edit dependencies in-line like this. > > > > > > This warranted a revbump as users will be asking how to remove > > > x11-proto/xf86rushproto. It won't come up for depclean because of > > > xorg-server not being scheduled for rebuild automatically until > > > the next > > > time it is upgraded or --changed-deps option is used (uncommon). > > > > > > Brian > > > > Citing Kenneth Hoste at FOSDEM this year: modifying a package > > without changing its version is a bad idea. > > His presentation was very good (video included): > > https://fosdem.org/2 > > 018/schedule/event/how_to_make_package_managers_cry/ > > This isn't so clear cut simple. We build from source at user systems. > Think of the effect for something like webkit-gtk, chromium, > libreoffice, etc. Exactly and while this package isn't as big as those, it could be argued that xorg-server is bumped frequently enough that the lingering dependency would have been flushed out soon enough anyway. It's not like it's doing any harm. I also think that FOSDEM talk was making a different point, aimed at upstreams in order to help packagers rather than packagers themselves. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 8 Feb 2018 18:05:55 +0100 Michael Lienhardt wrote: > Il 08/02/2018 16:04, James Le Cuirot ha scritto: > >>> Citing Kenneth Hoste at FOSDEM this year: modifying a package > >>> without changing its version is a bad idea. > >>> His presentation was very good (video included): > >>> https://fosdem.org/2 > >>> 018/schedule/event/how_to_make_package_managers_cry/ > >> > >> This isn't so clear cut simple. We build from source at user > >> systems. Think of the effect for something like webkit-gtk, > >> chromium, libreoffice, etc. > > > > Exactly and while this package isn't as big as those, it could be > > argued that xorg-server is bumped frequently enough that the > > lingering dependency would have been flushed out soon enough > > anyway. It's not like it's doing any harm. > > > > I also think that FOSDEM talk was making a different point, aimed at > > upstreams in order to help packagers rather than packagers > > themselves. > > Thanks for the information and sorry for the noise. > I wasn't fully aware of the meaning of the --dynamics-deps and > --changed-deps option. I am still not entirely convinced that > changing a package after it is committed to the repository cannot do > harm: even as a user, I would like to know when and why a package's > dependencies changed. But I don't maintain packages so my opinion is > not very relevant, and the gentoo guidelines indeed allow to change > the dependencies inline. It's not like this stuff is totally invisible as it is noted in the git log. We just don't want to tie up several minutes of CPU time for the majority of users for no tangible benefit. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 8 Feb 2018 13:02:28 -0500 Brian Evans wrote: > On 2/8/2018 12:14 PM, James Le Cuirot wrote: > > On Thu, 8 Feb 2018 18:05:55 +0100 > > Michael Lienhardt wrote: > >> Thanks for the information and sorry for the noise. > >> I wasn't fully aware of the meaning of the --dynamics-deps and > >> --changed-deps option. I am still not entirely convinced that > >> changing a package after it is committed to the repository cannot do > >> harm: even as a user, I would like to know when and why a package's > >> dependencies changed. But I don't maintain packages so my opinion is > >> not very relevant, and the gentoo guidelines indeed allow to change > >> the dependencies inline. > > > > It's not like this stuff is totally invisible as it is noted in the git > > log. We just don't want to tie up several minutes of CPU time for the > > majority of users for no tangible benefit. > > > > The benefit is that portage won't yell at you for having a masked > package installed and no obvious way to clean it up. True, I had forgotten to consider the mask message. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpjiaWSnQdvq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] about commits in the future
On Wed, 21 Feb 2018 09:59:49 +0100 Patrice Clement wrote: > Every now and then, my commits get rejected from the Gentoo Git > server with an error saying that my clock is behind and that I need > to rewind it. I then run the command `ntpdate europe.pool.ntp.org' to > get my clock synced. Eventually, I rebase my latest commits with git > and push to the repo. Something might have gone wrong during the > clock sync and git rebase? I'm not too sure. A git rebase does not change the authored date unless you pass --ignore-date. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels
On Wed, 28 Feb 2018 11:10:13 +0100 "Andreas K. Huettel" wrote: > another option would be to (try to) revive glibc-2.5, 2.12, and 2.17 instead. > > Yes I know they are even older, but these are the versions that RHEL uses, > and > for which RH still provides support (until 2020 for 2.5, 2024 for 2.12)... > https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping > > That however would require that the RHEL patchsets are public somehwere. > Which > I doubt... after all there's an "E" in RHEL... You maybe won't get the full details of the changes but all the patches are here. This looks like a much better breakdown than you get with their kernel patches. https://git.centos.org/summary/rpms!glibc.git -- James Le Cuirot (chewi) Gentoo Linux Developer pgps0dqy2j8lW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo
On Thu, 08 Mar 2018 16:40:44 +0100 Michał Górny wrote: > So, developers, please *stop adding USE=static-libs* to random libraries > that have no reason whatever to be statically linked to. Sorry, I like a lot of your ideas but I'm with the others on this one. I have, on the rare occasion, used these flags for various reasons. They don't do any harm for the majority not using them. If someone does encounter issues through using them then they are free to deal with those themselves. Better that than not even having them available in the first place. They are welcome to provide fixes where necessary and maintainers are equally welcome to drop these flags as they see fit. Such a decision should not be forced upon maintainers. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp8q2QMSbjlX.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Integrating Portage with other package managers
On Wed, 7 Mar 2018 11:06:47 -0500 anote...@teknik.io wrote: > Having used Gentoo for a few years now, one thing that has been annoying > to me is the tremendous duplication of effort and uphill battle of > creating ebuilds (build recipes) for language-specific packages that > already have their own build systems. > > For example, many languages such as Python (pip), Node (npm), Ruby > (gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of > redistributing up-to-date dependencies and ensuring that they build > properly in most environments. I was expecting to see Java's Maven in this list. Gentoo Java is in trouble because we have basically given up trying to keep up with the ecosystem. The last time anything under dev-java was bumped, other than JVMs and Tomcat-related stuff, was January 20th. We could be bumping 5 packages a day and still not keep up, never mind all the things we haven't packaged at all yet. Java's problem is somewhat unique in that although you can have optional dependencies at runtime, unless you go out of your way (and nobody ever does), all these optional dependencies are required at build time. Suddenly a package that might normally only have 2 dependencies now has 20. But wait, that's just the first level of dependencies! This can repeat on and on and you end up battered and bruised having packaged 100 things but still not the one you actually wanted. I therefore put some thought into something along the lines of what you have suggested. Java is supposed to be write (or really build) once, run anywhere so why are we wasting time building things that we don't have to? That's certainly why upstreams look at us like we're crazy whenever we dare to contact them. If we can leverage Maven or whatever to grab the platform-neutral dependencies for us, we can focus attention on the few that have native libraries and also things like icons, desktop entries, etc, that Maven doesn't deal with. But how would this work? I thought perhaps the dependencies we don't care about could be installed into a Maven repository, essentially untracked by Portage but still self-contained, by fetching them in src_unpack (or src_fetch, which I'd like to introduce) and then installing them in pkg_preinst. However, unless src_fetch is implemented, it would not be possible to install Java packages offline. This approach would also break binary packages, effectively forcing Java packages to have RESTRICT="bindist", although there would arguably be little building to do anyway. Apart from the fact that I haven't had time to do any of this, is this even what Gentoo users want? I suspect not. But what's worse, this or a totally stale or practically empty package repository? Others have experimented with from-source ebuild generators but that doesn't change the fact that putting all these ebuilds into the tree is still a huge maintenance burden and because of the build time dependency issue, end users will still have to build hundreds of packages they don't even care about. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpui06L7uQ_G.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo
On Mon, 12 Mar 2018 13:53:34 + Andrey Utkin wrote: > On Thu, Mar 08, 2018 at 05:57:35PM +0100, Jeroen Roovers wrote: > > On Thu, 08 Mar 2018 16:40:44 +0100 > > Michał Górny wrote: > > > > > As part of that we also shouldn't deliver static libraries > > > > OK, so you want to absolutely kill dead the only current sane way > > for developers who use Gentoo to ship static binaries to their > > users' target systems? Drive them away to another Linux distro that > > does support being the build platform that they need? Or force > > everyone to use EXTRA_ECONF"--enable-static" and hope for them that > > it works for all packages? All just because static linking > > *between* ebuilds is bad? > > This is close to my current case. Trying (in my own time) to build a > (hopefully elegant) demo setup of Gentoo & crossdev with static libs > enabled, to present as an alternative to CentOS which is currently the > build env at my job (and static linkage is the way the product is > built now). I run into cross-compilation problems when I enable > USE=static-libs to any extent, despite the comment in Gentoo's fake > /usr/lib64/*.so files saying "And yes, this works in the cross- > compiling scenario as the sysroot-ed linker will prepend the real > path". But it's what I'd rather have resolved than have no > USE=static-libs at all. libtool often screws up relinking unless --with-sysroot is passed to configure, which is something we're adding for EAPI 7. I need to take a closer look at those fake .so files to see whether anything more needs to be done. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: How to deal with git sources?
On Fri, 16 Mar 2018 10:03:44 + (UTC) Martin Vaeth wrote: > So I would not worry too much about it: It is not worth the cost of > hosting a huge number of tarballs permanently (or to convince > upstream to let them be hosted by github for every single version, > only because one cannot theoretically exclude that a similar thing > won't ever happen again). Yes, for the transition period (until all > github servers use a new enough version) a solution for the few > involved tarballs has to be found (like temporarily hosting on > devspace). But after this period it is only a question of updating the > checksum once for the involved packages. Agreed. I use this GitHub feature quite a lot and I've only ever seen this happen maybe once? Even then, I think it might have been one of the additional downloads rather than the git archives, which upstream had probably replaced without bumping. -- James Le Cuirot (chewi) Gentoo Linux Developer
[gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work
The previous attempt actually broke ASM in media-libs/vulkan-loader
entirely so that it fell back to C code. After much experimentation
and combing through strace output, I found that -x assembler is needed
to handle non-standard file extentions and linking is done as a
separate step. CMAKE_ASM-ATT_LINK_FLAGS therefore needs to be defined
with -nostdlib to avoid errors about undefined main symbols.
Closes: https://bugs.gentoo.org/625844
---
One user has confirmed that this patch works for vulkan-loader and I'd
like a dev or two to also confirm this before I merge.
eclass/cmake-utils.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index f8853be502a1..f6952ec09efd 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -520,7 +520,8 @@ cmake-utils_src_configure() {
fi
cat > "${build_rules}" <<- _EOF_ || die
SET (CMAKE_ASM_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "ASM
compile command" FORCE)
- SET (CMAKE_ASM-ATT_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING
"ASM compile command" FORCE)
+ SET (CMAKE_ASM-ATT_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c -x assembler "
CACHE STRING "ASM-ATT compile command" FORCE)
+ SET (CMAKE_ASM-ATT_LINK_FLAGS "-nostdlib" CACHE STRING "ASM-ATT
link flags" FORCE)
SET (CMAKE_C_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "C
compile command" FORCE)
SET (CMAKE_CXX_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "C++
compile command" FORCE)
SET (CMAKE_Fortran_COMPILE_OBJECT "
${includes} ${FCFLAGS} -o -c " CACHE STRING
"Fortran compile command" FORCE)
--
2.16.1
Re: [gentoo-dev] [PATCH] cmake-utils.eclass: Make the new ASM-ATT rules actually work
On Mon, 19 Mar 2018 15:16:47 -0700 Matt Turner wrote: > Thanks for looking into this! > > I'm not sure I understand the -nostdlib portion. It's something about > working around a side-effect of -x assembler? It's not related to that option. I think it's because this is normally built with "as" and "ld" and by using "gcc" instead, it tries to link libc and friends, which otherwise wouldn't happen. It'll fail if you take it away and you'll find the error if you dig through tons of strace. Strangely you don't see the linking command in the regular build output. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpuEuFO3eBUW.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] bug queue size over time
On Mon, 19 Mar 2018 22:05:16 -0700 "Paweł Hajdan, Jr." wrote: > On 19/03/2018 21:33, Alec Warner wrote: > > I'd avoid the REST API here. If you want this data; I'd consider > > filing a bug. Infra can do stuff like run nightly reports for this > > information and hang them off of endpoints you can access. > > Would it only collect data going forward, or does this method also > support historical backfill? We used to have graphs for Java bugs from data that was collected over time but that all broke when the categories were reorganised. I recall it was possible to set these up through the web interface but I've totally forgotten how. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny
On Thu, 22 Mar 2018 20:03:46 +0100 Michał Górny wrote: > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. I hope you will continue with our efforts to drive regular Portage forwards too. It's been a long road but also very productive. I notice that your fork cannot be installed at the same time as regular Portage. I think this will really hinder any interest in it. As Gentoo developers, we obviously have to make sure things work with the official package manager and that goes for you too. Would it be possible for them to coexist? I'm not saying I'll try it though, just making a suggestion. :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgps9_fhr_B36.pgp Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/2] java-utils-2.eclass: Drop sys-apps/portage build dependency
It originates from 2006 and should arguably have never been added.
---
eclass/java-utils-2.eclass | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 25e35c33dd21..967050925245 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 2004-2017 Gentoo Foundation
+# Copyright 2004-2018 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: java-utils-2.eclass
@@ -25,21 +25,13 @@ export WANT_JAVA_CONFIG="2"
# Prefix variables are only available for EAPI>=3
has "${EAPI:-0}" 0 1 2 && ED="${D}" EPREFIX= EROOT="${ROOT}"
-# @VARIABLE: JAVA_PKG_PORTAGE_DEP
-# @INTERNAL
-# @DESCRIPTION:
-# The version of portage we need to function properly. Previously it was
-# portage with phase hooks support but now we use a version with proper env
-# saving. For EAPI 2 we have new enough stuff so let's have cleaner deps.
-has "${EAPI}" 0 1 && JAVA_PKG_PORTAGE_DEP=">=sys-apps/portage-2.1.2.7"
-
# @VARIABLE: JAVA_PKG_E_DEPEND
# @INTERNAL
# @DESCRIPTION:
# This is a convience variable to be used from the other java eclasses. This is
# the version of java-config we want to use. Usually the latest stable version
# so that ebuilds can use new features without depending on specific versions.
-JAVA_PKG_E_DEPEND=">=dev-java/java-config-2.2.0-r3 ${JAVA_PKG_PORTAGE_DEP}"
+JAVA_PKG_E_DEPEND=">=dev-java/java-config-2.2.0-r3"
has source ${JAVA_PKG_IUSE} && JAVA_PKG_E_DEPEND="${JAVA_PKG_E_DEPEND} source?
( app-arch/zip )"
# @ECLASS-VARIABLE: JAVA_PKG_WANT_BOOTCLASSPATH
--
2.16.1
[gentoo-dev] [PATCH 1/2] java-ant-2.eclass: Drop sys-apps/portage build dependency
This comes via java-utils-2.eclass. It originates from 2006 and should
arguably have never been added.
---
eclass/java-ant-2.eclass | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/eclass/java-ant-2.eclass b/eclass/java-ant-2.eclass
index 8da5971844a0..1fd4feb39134 100644
--- a/eclass/java-ant-2.eclass
+++ b/eclass/java-ant-2.eclass
@@ -56,12 +56,10 @@ if [[ $? != 0 ]]; then
die "java-pkg_ant-tasks-depend() failed"
fi
-# We need some tools from javatoolkit. We also need portage 2.1 for phase hooks
-# and ant dependencies constructed above. Python is there for
-# java-ant_remove-taskdefs
+# We need some tools from javatoolkit. We also need ant dependencies
+# constructed above.
JAVA_ANT_E_DEPEND="${JAVA_ANT_E_DEPEND}
${ANT_TASKS_DEPEND}
- ${JAVA_PKG_PORTAGE_DEP}
>=dev-java/javatoolkit-0.3.0-r2"
# this eclass must be inherited after java-pkg-2 or java-pkg-opt-2
--
2.16.1
Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"
On Fri, 30 Mar 2018 18:52:18 + (UTC) Farid BENAMROUCHE wrote: > Yes, two years ago I've posted here to notify you about the creattion of > users and groups when using "ROOT=". > As a reminder, if you currently emerge a package to a specific rootfs folder, > some packages will actually not create the user and groups correctly inside > this rootfs. > It will also not check for the existance of the user/group inside of the > rootfs. > Everytime, it will check "/". > > This very old gentoo issue (I have to find again the GLEP talking about this > issue). > > The solution is not possible without changing the behaviour of the tools used > by portage. For example, portage is using shadow in most systems (and shadow > is using the glibc). Hi, I have an interest this and was one of the early commenters in bug #541406. I made my own suggestions about how this might work. Your solution is cleaner in that it doesn't require modifying the users in the / system but it does require significant changes to tools, eclasses, and ebuilds so I'm on the fence about it. I did just have a lightbulb moment though. I've been playing with unshare recently and I wondered if we could leverage it here. First I tried this. $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc/group /etc/group && groupadd foo" groupadd: failure while writing changes to /etc/group It is possible to bind mount individual files but it doesn't work here because it tries to rename /etc/group to made a backup. Next I tried the whole directory but it gives a strange error. $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc /etc && groupadd foo" groupadd: Cannot determine your user name. This reveals more. $ sudo unshare -m /bin/sh -c "id && mount --bind /mnt/utilite/mnt/moi/etc /etc && id" uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) uid=0 gid=0 groups=0,1,2,3,4,6,10,11,20,26,27 I'm not sure why the IDs break like this and strace doesn't make it any clearer. This seems like a route worth pursuing though because you could create a bunch of wrappers for useradd, groupadd, chown and so on and it would then all work transparently, even when not using the eclass functions. Regards, -- James Le Cuirot (chewi) Gentoo Linux Developer pgp5TAk9z0pkh.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"
On Fri, 30 Mar 2018 20:23:49 +0100 James Le Cuirot wrote: > I did just have a lightbulb moment though. I've been playing with > unshare recently and I wondered if we could leverage it here. > > $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc /etc && > groupadd foo" > groupadd: Cannot determine your user name. Aha! I was trying to do this against an NFS share for a system with a different architecture. If I use a local mount with a compatible architecture, it actually does work. I'll explore this some more. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpi6lGElLSy7.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"
On Fri, 30 Mar 2018 20:47:20 +0100 James Le Cuirot wrote: > On Fri, 30 Mar 2018 20:23:49 +0100 > James Le Cuirot wrote: > > > I did just have a lightbulb moment though. I've been playing with > > unshare recently and I wondered if we could leverage it here. > > > > $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc /etc && > > groupadd foo" > > groupadd: Cannot determine your user name. > > Aha! I was trying to do this against an NFS share for a system with a > different architecture. If I use a local mount with a compatible > architecture, it actually does work. I'll explore this some more. Figured it out! The system I was doing this against has an ancient glibc (long story) with an old nsswitch.conf. I replaced this file with a newer one and it all started working. Do you agree this could be the way forwards? -- James Le Cuirot (chewi) Gentoo Linux Developer pgpXQVm8fnITq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"
On Sat, 31 Mar 2018 09:39:47 + (UTC) Farid BENAMROUCHE wrote: > interresting aproach. > this could work. however, i can see a few limitations: > - you must be root. Actually you don't if you add -r to unshare, which gives you what is sometimes called fakeroot. Obviously you still can't modify the files if they are really owned by root but that's true of any solution. > - this is specific to linux as of today. True and I am only interested in Linux but I like to play nice. Other platforms could potentially still briefly bind mount but it wouldn't be isolated from the other processes so it wouldn't be entirely safe. Safe enough though? You'd need to weigh this up against how many people use ROOT!=/ on other platforms. Not many at all, I imagine. > - if you want to hide the mechanism, i don't see how without doing > the same portage modifications as in my solution. You could handle this in the eclass functions but as you pointed out, many things call chown/chgrp directly. Usage by ebuilds themselves can be addressed but if a build system calls these then eclass functions will not help. What would work is adding some identically-named wrappers to the PATH. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpt1qN6u7M80.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] java-vm-2.eclass: fdo-mime->xdg-utils migration
On Sun, 8 Apr 2018 05:25:35 -0500 "Marty E. Plummer" wrote: > This is the only eclass left which uses it. Switch over. Merged, thank you. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpTVS3cm5lM2.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Package up for grabs: media-tv/tvheadend
On Tue, 10 Apr 2018 11:19:55 +1000 Sam Jorna wrote: > Due to not having as much time as I'd hoped, media-tv/tvheadend is > being dropped to maintainer-needed. Mine! :) As you know, I did some work on it last year. I haven't been using it quite as much as I expected to by this point but hopefully Kodi will be usable on my ARM box soon and I will then need it much more. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] multi-backend support for ssl/tls in curl
On Mon, 23 Apr 2018 17:47:27 +0200 Michał Górny wrote: > W dniu pon, 23.04.2018 o godzinie 02∶57 -0500, użytkownik Gordon > Pettey napisał: > > On Mon, Apr 23, 2018 at 1:26 AM, Michał Górny > > wrote: > > > W dniu nie, 22.04.2018 o godzinie 09∶34 -0500, użytkownik Matthew > > > Thode napisał: > > > > The short of it is that curl supports having multiple > > > > backends. I'd like to have that feature enabled so libraries > > > > and userland can choose the backend they wish to use. > > > > > > > > https://bugs.gentoo.org/653076 has the specifics, but I cannot > > > > see a reason why we are artifically limiting the backed to just > > > > one. > > > > > > How would you solve the problem of packages requiring specific SSL > > > backend? Currently they enforce it via USE dependency on cURL. > > > > Perhaps with exactly the same USE dependencies that already exists, > > just without the at-most-one limitation on curl itself? > > This doesn't guarantee that the required backend will actually be > used. Well, unless it blocks any other USE flag from being enabled > but that defeats the purpose. Proprietary software that's linked against a specific backend usually links to libcurl-gnutls.so.4 or whatever specifically as that's what Debian provides. If it points to just libcurl.so.4 but only works against a specific backend then we could use chrpath to change it to the specific name. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [PATCH] bzr.eclass: Support EAPI 7.
On Fri, 4 May 2018 07:11:47 +0200 Ulrich Müller wrote: > --- > eclass/bzr.eclass | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) LGTM! -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Last rites: net-misc/asterisk-g729, sci-libs/coinhsl, some games-*/* (BLAKE2B)
On Mon, 21 May 2018 09:30:34 +0100 Marek Szuba wrote: > On 2018-05-15 22:49, Michał Górny wrote: > > > # Michał Górny (15 May 2018) > > # Remaining fetch-restricted game packages missing BLAKE2B hashes. > > # Please provide updated hashes if you have the matching distfiles. > > # Bug #642876. Removal in 30 days. > > I have got access to several of these but it turns out that in most > cases one has to do more than merely recompute the digests. I reckon > it is up to the maintainers to decide whether to proceed after all or > let the packages quietly expire. Please visit the bug report to see the latest situation regarding these. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready
On Wed, 20 Jun 2018 21:03:44 +0800
Jason Zaman wrote:
> On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer wrote:
> > Use ${EROOT%/} whereever possible, as the tools and directories which
> > are used with it are already prefixed with a /
> >
> > Package-Manager: Portage-2.3.40, Repoman-2.3.9
> > ---
> > eclass/xdg-utils.eclass | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
> > index ac075185d8e..8dba5ed6861 100644
> > --- a/eclass/xdg-utils.eclass
> > +++ b/eclass/xdg-utils.eclass
> > @@ -66,7 +66,7 @@ xdg_environment_reset() {
> > # Updates the .desktop files database.
> > # Generates a list of mimetypes linked to applications that can handle them
> > xdg_desktop_database_update() {
> > - local updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
> > + local updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"
>
> Shouldn't things like this be $BROOT since they're being run? $EROOT
> might be a different architecture that may or may not run at all on the
> build machine.
+1
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpMOcu2KzK3k.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready
On Wed, 20 Jun 2018 17:21:09 -0500
"Marty E. Plummer" wrote:
> On Wed, Jun 20, 2018 at 09:03:44PM +0800, Jason Zaman wrote:
> > On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer wrote:
> > > Use ${EROOT%/} whereever possible, as the tools and directories which
> > > are used with it are already prefixed with a /
> > >
> > > Package-Manager: Portage-2.3.40, Repoman-2.3.9
> > > ---
> > > eclass/xdg-utils.eclass | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
> > > index ac075185d8e..8dba5ed6861 100644
> > > --- a/eclass/xdg-utils.eclass
> > > +++ b/eclass/xdg-utils.eclass
> > > @@ -66,7 +66,7 @@ xdg_environment_reset() {
> > > # Updates the .desktop files database.
> > > # Generates a list of mimetypes linked to applications that can handle
> > > them
> > > xdg_desktop_database_update() {
> > > - local updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
> > > + local updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"
> >
> > Shouldn't things like this be $BROOT since they're being run? $EROOT
> > might be a different architecture that may or may not run at all on the
> > build machine.
> >
> Good point, but here's a question; if EROOT=${ROOT%/}${EPREFIX}, how do
> we use BROOT here? EBROOT? Or longhand ${BROOT%/}${EPREFIX} ? I think
> that may be a use case that got missed in the EAPI 7 discussions.
BROOT is already prefixed as BROOT without a prefix would just be /.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgprmQy2bpUlk.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready
On Wed, 20 Jun 2018 22:09:21 -0500
"Marty E. Plummer" wrote:
> On Thu, Jun 21, 2018 at 03:41:02AM +0100, M. J. Everitt wrote:
> > On 21/06/18 03:38, Jason Zaman wrote:
> > > On Wed, Jun 20, 2018 at 06:01:10PM -0500, Marty E. Plummer
> > > wrote:
> > >> On Wed, Jun 20, 2018 at 11:33:53PM +0100, James Le Cuirot
> > >> wrote:
> > >>> On Wed, 20 Jun 2018 17:21:09 -0500
> > >>> "Marty E. Plummer" wrote:
> > >>>
> > >>>> On Wed, Jun 20, 2018 at 09:03:44PM +0800, Jason Zaman wrote:
> > >>>>> On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer
> > >>>>> wrote:
> > >>>>>> Use ${EROOT%/} whereever possible, as the tools and
> > >>>>>> directories which are used with it are already prefixed with
> > >>>>>> a /
> > >>>>>>
> > >>>>>> Package-Manager: Portage-2.3.40, Repoman-2.3.9
> > >>>>>> ---
> > >>>>>> eclass/xdg-utils.eclass | 10 +-
> > >>>>>> 1 file changed, 5 insertions(+), 5 deletions(-)
> > >>>>>>
> > >>>>>> diff --git a/eclass/xdg-utils.eclass
> > >>>>>> b/eclass/xdg-utils.eclass index ac075185d8e..8dba5ed6861
> > >>>>>> 100644 --- a/eclass/xdg-utils.eclass
> > >>>>>> +++ b/eclass/xdg-utils.eclass
> > >>>>>> @@ -66,7 +66,7 @@ xdg_environment_reset() {
> > >>>>>> # Updates the .desktop files database.
> > >>>>>> # Generates a list of mimetypes linked to applications that
> > >>>>>> can handle them xdg_desktop_database_update() {
> > >>>>>> -local
> > >>>>>> updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
> > >>>>>> +local
> > >>>>>> updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"
> > >>>>> Shouldn't things like this be $BROOT since they're being run?
> > >>>>> $EROOT might be a different architecture that may or may not
> > >>>>> run at all on the build machine.
> > >>>>>
> > >>>> Good point, but here's a question; if
> > >>>> EROOT=${ROOT%/}${EPREFIX}, how do we use BROOT here? EBROOT?
> > >>>> Or longhand ${BROOT%/}${EPREFIX} ? I think that may be a use
> > >>>> case that got missed in the EAPI 7 discussions.
> > >>> BROOT is already prefixed as BROOT without a prefix would just
> > >>> be /.
> > >> I don't follow. Its my understanding that BROOT ~= ROOT for most
> > >> situations. But consider this setup:
> > >> Ubuntu amd64 with Gentoo Prefix, emerging a native arm @system to
> > >> /mnt/arm EPREFIX = /home/user/gentoo.
> > >>
> > >> In this situation, ROOT=/mnt/arm, EROOT=/mnt/arm, but what is
> > >> BROOT? /, or /home/usr/gentoo?
> > > https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html#broot-variable-for-bdepend
> > >
> > > Basically BROOT already contains EPREFIX or BPREFIX or whatever
> > > it would be called. There is like no need for an un-prefixed
> > > BROOT so its just merged in. so you should just need
> > > "${BROOT}/usr/bin/update-mime-database"
> > >
> > Obligatory n00b question .. how does this work in EAPI <= 6 ?! :D
> >
> I would guess something like has eapi 7 || ROOT = BROOT or whatever.
> Use BROOT by default and if the EAPI doesn't support it set ROOT to
> BROOT or somat.
There was no variable for BROOT before EAPI 7, that's why we created
one! There was an internal Portage variable called
PORTAGE_OVERRIDE_EPREFIX, which is basically what BROOT gets set to now
but you should not use this in an eclass. I guess the safest fallback
would be EPREFIX. This would be technically wrong for cross-prefix
builds but unlikely to cause a problem in practise. Don't do
${BROOT-${EPREFIX}} though because BROOT is usually empty anyway.
--
James Le Cuirot (chewi)
Gentoo Linux Developer
[gentoo-dev] Last rites: app-eselect/eselect-maven
# James Le Cuirot (26 Jan 2016) # Now part of eselect-java. Removal in 30 days. app-eselect/eselect-maven -- James Le Cuirot (chewi) Gentoo Linux Developer pgp61k0Nno5iP.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-cdr/webcdwriter
# James Le Cuirot (26 Jan 2016) # No new release since 2008. Removal in 30 days. app-cdr/webcdwriter -- James Le Cuirot (chewi) Gentoo Linux Developer pgpk42l6SqYNs.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: app-cdr/webcdwriter
On Tue, 26 Jan 2016 21:55:15 +0100 Peter Stuge wrote: > James Le Cuirot wrote: > > # James Le Cuirot (26 Jan 2016) > > # No new release since 2008. Removal in 30 days. > > app-cdr/webcdwriter > > Is there a problem with it? I don't use it and have no interest in > this particular package but merely lack of release is not a valid > reason to remove the ebuild if everything else is all right. If it > isn't, then maybe that needs to be added to the lastrite comment? I must admit that I had to think twice about this one given its unusual nature. The overriding factor is that there is tons of dead Java software in the tree and we're struggling to even keep up with the live stuff. We're therefore trimming the fat down to a more manageable size. This package was brought to my attention because bugs had been assigned to the optical media herd, which has now been disbanded. There are only 3 open bugs, none of them serious, but apart from the lack of releases, I considered several points: * It's presented as a Java web applet or web start application. Applets are all but outlawed these days. Web start isn't dead and you don't strictly need a browser to use it but this isn't exactly a popular way to launch applications. * I'd be very dubious of the security around something like this. Even actively maintained software has seen tons of security vulnerabilities lately, not least in the Java space. * Optical media is on the decline. My main development machine doesn't even have a burner any more so I can't easily test it. * It was designed around cdrecord, which has seen many new releases since then and may not be entirely compatible any more. The cdrkit fork (which I use) may also have similar issues. I'll admit this is purely speculation on my part. * It's fugly. ;) Seriously, no one like Java's Swing and even Oracle and co have put it on life support, fixing critical bugs only. * The ebuild doesn't look like much fun. The project uses autotools, which is rarely a good thing in Java land. * There may be cleaner ways to achieve the same goal. If it were me, I'd try ATA over Ethernet with regular burning software, though I'm not entirely sure it would work. Am I off the hook now? ;) -- James Le Cuirot (chewi) Gentoo Linux Developer pgpMBPMkA3sJZ.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-java/{concurrent-util,dsiutils,sux4j}
# James Le Cuirot (03 Feb 2016) # Built into Java since 1.5. Ancient and doesn't build with # Java 8. Removal in 30 days. See bug #544038. dev-java/concurrent-util # James Le Cuirot (03 Feb 2016) # Old, unused, broken on Java 7 and up. These are still alive upstream # but bumping is likely non-trivial. Removal in 30 days. dev-java/dsiutils dev-java/sux4j -- James Le Cuirot (chewi) Gentoo Linux Developer pgpTbZTZeXomT.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: sci-biology/{biojava,mauve,mauvealigner}
# James Le Cuirot (07 Feb 2016) # BioJava depends on commons-dbcp:0, which requires Java 6. Even the # latest "legacy" version 1.9.1 does so and no one wants to do the # difficult bump to 4.1.0. Mauve depends on BioJava but being a very # outdated live SVN ebuild, it probably doesn't work anyway. This goes # for Mauve Aligner too. Removal in 30 days. See bug #556470. sci-biology/biojava sci-biology/mauve sci-biology/mauvealigner -- James Le Cuirot (chewi) Gentoo Linux Developer pgpF_8UDxsszy.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] New USE_EXPAND NGINX_MODULES_STREAM
On Tue, 9 Feb 2016 11:34:12 +1300 Kent Fredric wrote: > And I'm guessing you can't just make people install ebuilds for each > module people want instead? ( And maybe have a single USE flag on the > main nginx that turning on installs a bunch of good default things > that people appear to always want easily ) nginx is monolithic, if a package per module is what you meant. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpE9dsaaBLZp.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: supervise-daemon -- a lightweight openrc daemon supervisor
On Tue, 16 Feb 2016 12:51:17 -0600 William Hubbs wrote: > there is a branch in the OpenRC github repo called supervisor. Interesting! > It is still very rough, and not ready for production, but at this > point I would like to make everyone aware that it exists and ask > folks to go over the code and provide comments. I'm not really qualified to comment on the code but I'm aware that there are lot of ways to get this wrong so please do your homework if you haven't done so already. Your post seems like a good start. :) runit seems highly regarded and we use it at work on CentOS to allow users of the same UNIX group to manage a collection of processes without requiring root or sudo. I wasn't aware of s6 at the time but I've heard that's also good and this makes an interesting read. http://skarnet.org/software/s6/why.html I wonder if it might even make more sense to reuse one of these instead of reinventing the wheel. They are both extremely lightweight. If you feel you can do better though then go for it! Regards, -- James Le Cuirot (chewi) Gentoo Linux Developer pgp9qOD_XNjkz.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: supervise-daemon -- a lightweight openrc daemon supervisor
On Tue, 16 Feb 2016 16:04:42 -0600 William Hubbs wrote: > > I wonder if it might even make more sense to reuse one of these > > instead of reinventing the wheel. They are both extremely > > lightweight. If you feel you can do better though then go for it! > > We have s6 support in OpenRC, and I am looking at integrating runit > support as well. > > For s6 info, see the s6-guide.md file located in > /usr/share/doc/openrc-*. Oh, that's cool! Now I come to think of it, I believe it was this effort that made me aware of s6 in the first place but I'd forgotten about it since. Now I feel dumb. As you were then. You're doing great work and we're clearly spoilt for choice. :) -- James Le Cuirot (chewi) Gentoo Linux Developer pgpq_TKG59Wui.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
On Wed, 17 Feb 2016 12:19:52 -0500 Rich Freeman wrote: > Is dracut still not widely used? I know that it was all the fashion > for a decade or two for every distro to build their own initramfs, but > I don't get why anybody wouldn't just make the switch - it is far more > capable and configurable. Does anyone know what most Gentoo users are doing these days? I don't recall the handbook mentioning initramfs at all back in 2002 because it wasn't really needed back then. I did without for years until I finally put / on LVM. I used lvm2create_initrd for a while but that was still quite a manual process and I couldn't imagine going back to it now. I've switched to Dracut and it's great but I don't get the impression that Gentoo really endorses that option over the more laborious ones. Maybe it should? https://wiki.gentoo.org/wiki/Initramfs -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro
On Wed, 17 Feb 2016 22:11:42 -0500 Richard Yao wrote: > dracut does not assist those who do not want generic kernel > configurations. Unfortunately, the handbook does not do a good job in > saying that the initramfs generation and generic kernel configurations > are optional. Does Dracut's hostonly mode not count? I think this is even the default as I don't specify it here and I had to temporarily force non-hostonly mode on Fedora in order to fix a broken system. I certainly keep my Gentoo kernel configuration to a minimum. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpHzJLhLKgbr.pgp Description: OpenPGP digital signature
[gentoo-dev] Last-rites: www-servers/tomcat:6
# James Le Cuirot (19 Feb 2016) # Upstream EOL is December 2016. We would rather focus on other things # than support it until then. Removal in 30 days. www-servers/tomcat:6 -- James Le Cuirot (chewi) Gentoo Linux Developer pgpMAPTXX77Xh.pgp Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-java/xsd2jibx
# James Le Cuirot (21 Feb 2016) # No revdeps, no release since 2007, and upstream have even moved the # download to a hidden OldFiles directory in the parent SourceForge # project. Removal in 30 days. dev-java/xsd2jibx -- James Le Cuirot (chewi) Gentoo Linux Developer pgpAXQ5JeUW9V.pgp Description: OpenPGP digital signature
[gentoo-dev] Last-rites: sci-biology/readseq
# James Le Cuirot (29 Feb 2016) # Dead upstream and doesn't build with Java 8. Removal in 30 days. sci-biology/readseq -- James Le Cuirot (chewi) Gentoo Linux Developer pgpTFMwxmGcFo.pgp Description: OpenPGP digital signature
[gentoo-dev] Last-rites: dev-dotnet/ikvm, dev-java/jcharts
# James Le Cuirot (14 Mar 2016) # Our old ebuilds require Java 6/7 and are most likely # vulnerable. Upstream has a new version targeting Java 8 but no # response from dotnet team. I am leaving ikvm-bin alone but only # because it doesn't require Java. Removal in 30 days. dev-dotnet/ikvm # James Le Cuirot (14 Mar 2016) # Requires Java 6. No stable releases since 2003 and no longer # required by bt747. Removal in 30 days. dev-java/jcharts -- James Le Cuirot (chewi) Gentoo Linux Developer pgpeQzWFEMJvn.pgp Description: OpenPGP digital signature
