Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-29 Thread James Le Cuirot
On Sun, 28 Mar 2021 19:46:32 -0400
Joshua Kinard  wrote:

> I've kinda come to this conclusion myself.  I could probably host an
> extracted, micro-initramfs on my NFS server that would be loaded by the
> kernel to jump to $REAL_ROOT.  Not *too* much of an issue on the Octane,
> because I can store the kernel command line args in a PROM variable so that
> all I have to do is type "$foo" at the PROM prompt to load something.  But,
> SGI did their best to be inconsistent, and IP27 systems cannot permanently
> save variables to NVRAM.  Once you power cycle, all user-defined PROM vars
> are lost.  And Linux's NFS Root command args are somewhat complicated from
> what I remember.  Upshot is I boot the IP27 over serial console, so I can
> just save bootp() args in a text file on my desktop and paste it into the
> console for those instances.

Have you seen CONFIG_CMDLINE? It lets you bake command line args into
the kernel image itself.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpjPj3Fv0z6w.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-28 Thread James Le Cuirot
On Sat, 27 Mar 2021 18:40:52 -0400
Joshua Kinard  wrote:

> On 3/27/2021 18:16, James Le Cuirot wrote:
> > On Sat, 27 Mar 2021 17:43:34 -0400
> > Joshua Kinard  wrote:
> >   
> >> I kinda wish the Linux kernel had an ability to partially boot, init the
> >> networking subsystem, then fetch an initramfs image over TFTP like it can 
> >> do
> >> with NFS Root.  That would solve the problem on my MIPS system(s) (and make
> >> install netboots better).  I've dug around, but this does not seem to be a
> >> capability currently in the kernel, unless I have over looked something.
> >>
> >> Otherwise in the future, I may just have to setup an initramfs into an NFS
> >> Root and teach the SGI's to somehow deal with it.  Which all still seems
> >> unnecessarily complicated because some other distro thinks it knows what's
> >> best for everyone else (but I digress...).  
> > 
> > NBD may be a slightly simpler alternative and a bit more like an
> > initramfs. nbdkit can do all sorts of weird things. I thought it might
> > have a plugin for cpio archives, allowing you to use a regular
> > initramfs generated by Dracut or similar directly. It doesn't appear to
> > but plugins are quite easy to write. Alternatively you could just
> > extract the initramfs and use nbdkit-linuxdisk-plugin.  
> 
> Can NBD be used like I described?  Never played with it before.  The MIPS
> machine has functioning local disk drives, and currently, it boots fine by
> just pulling a kernel off my TFTP server and booting from the local drive,
> no initramfs needed because I compiled everything into it.  If we ever force
> sep-usr to end, then I'll need a way to teach it to mount /usr before
> dropping into /bin/init (and nothing else).

Apologies, I went to experiment with this idea but I'd forgotten that
booting over NBD is not a built-in kernel feature and requires... an
initramfs. NFS looks like the only option with this general approach.

Rich is right though, the initramfs can be tiny. Dracut images are
heavy because they are very flexible and pack a lot of features but
none of that is required.

The kexec idea would be a nice bonus for you, if it works. Limiting
what kernel features you can enable must be frustrating.

It's also worth bearing in mind that you could just generate an image
with Dracut and extract it to a disk partition. That may seem a little
pointless if you're not using something like LVM or encryption but I
don't see the point in separate /usr either. ;) I'm guessing you don't
want to change your partition layout at this point though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAb6gauIo0N.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-27 Thread James Le Cuirot
On Sat, 27 Mar 2021 17:43:34 -0400
Joshua Kinard  wrote:

> I kinda wish the Linux kernel had an ability to partially boot, init the
> networking subsystem, then fetch an initramfs image over TFTP like it can do
> with NFS Root.  That would solve the problem on my MIPS system(s) (and make
> install netboots better).  I've dug around, but this does not seem to be a
> capability currently in the kernel, unless I have over looked something.
> 
> Otherwise in the future, I may just have to setup an initramfs into an NFS
> Root and teach the SGI's to somehow deal with it.  Which all still seems
> unnecessarily complicated because some other distro thinks it knows what's
> best for everyone else (but I digress...).

NBD may be a slightly simpler alternative and a bit more like an
initramfs. nbdkit can do all sorts of weird things. I thought it might
have a plugin for cpio archives, allowing you to use a regular
initramfs generated by Dracut or similar directly. It doesn't appear to
but plugins are quite easy to write. Alternatively you could just
extract the initramfs and use nbdkit-linuxdisk-plugin.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpGX8oMTiAmr.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-21 Thread James Le Cuirot
On Sun, 21 Mar 2021 05:18:52 +0100
Ulrich Mueller  wrote:

> >>>>> On Sat, 20 Mar 2021, William Hubbs wrote:  
> 
> > /etc/localtime should definitely be a symlink to the proper file in
> > /usr/share/zoneinfo.  
> 
> > This works fine if /usr is on a separate partition *and* you are using
> > an initramfs. The only time it doesn't work is if /usr is separate
> > without using an initramfs.  
> 
> > Council decided years ago that we don't support separate /usr without
> > an initramfs, but we haven't completed that transition yet.  
> 
> Which doesn't imply that we deliberately break things.

How about making emerge --config dynamic, copying if it's on a
different partition and symlinking if it's not? You can't accurately
determine the use of an initramfs but at least this is closer to what
we want.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppd9SmOxjcX.pgp
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

2021-02-21 Thread James Le Cuirot
On Sun, 21 Feb 2021 15:54:39 +0200
Joonas Niilola  wrote:

> Hey,
> 
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
> 
> app-arch/innoextract

I'll take this.

> net-irc/emech (b)
> net-misc/tigervnc (b)
> x11-misc/urxvtconfig (b)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpCz9mh0ZV9G.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread James Le Cuirot
On Mon, 08 Feb 2021 12:19:13 +0100
Michał Górny  wrote:

> Hi,
> 
> FYI the developers of dev-python/cryptography decided that Rust is going
> to be mandatory for 1.5+ versions.  It's unlikely that they're going to
> provide LTS support or security fixes for the old versions.
> 
> 
>
> Honestly, I don't think it likely that Rust will gain support for these
> platforms.  This involves a lot of work, starting with writing a new
> LLVM backend and getting it accepted (getting new code into LLVM is very
> hard unless you're doing that on behalf one of the big companies).  You
> can imagine how much effort that involves compared to rewriting the new
> code from Cryptography into C.

I do know that there is ongoing work to get Rust going on m68k but it's
very slow and I'm not entirely confident they'll get there. At least I
don't have this package on my m68k system!

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpEXub3MDL7c.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] eclass/lua-utils.eclass: remove EPREFIX from exported module paths

2021-01-13 Thread James Le Cuirot
On Mon, 11 Jan 2021 11:01:33 -0600
William Hubbs  wrote:

> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs 
> ---
>  eclass/lua-utils.eclass | 23 ++-
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..9fe4d22e93f 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,9 @@ _lua_get_library_file() {
>   die "Invalid implementation: ${impl}"
>   ;;
>   esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>  
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + 
>   debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
>   echo "${libdir}/${libname}"
>  }
> @@ -274,6 +275,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_CMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
> ${LUA_CMOD_DIR}"
> @@ -282,6 +284,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable includedir 
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_INCLUDE_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +301,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_LMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
> ${LUA_LMOD_DIR}"
> @@ -364,11 +368,14 @@ lua_get_CFLAGS() {
>  # @USAGE: []
>  # @DESCRIPTION:
>  # Obtain and print the name of the directory into which compiled Lua
> -# modules are installed, for the given implementation. If no implementation
> +# modules are installed for the given implementation. If no implementation
>  # is provided, ${ELUA} will be used.
>  #
> -# Please note that this function requires Lua and pkg-config installed,
> -# and therefore proper build-time dependencies need be added to the ebuild.
> +# Please note that this function requires Lua and pkg-config to be installed,
> +# and therefore proper build-time dependencies need to be added to the 
> ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
>  lua_get_cmod_dir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> @@ -385,6 +392,9 @@ lua_get_cmod_dir() {
>  #
>  # Please note that this function requires Lua and pkg-config installed,
>  # and therefore proper build-time dependencies need be added to the ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
>  lua_get_include_dir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> @@ -412,11 +422,14 @@ lua_get_LIBS() {
>  # @USAGE: []
>  # @DESCRIPTION:
>  # Obtain and print the name of the directory into which native-Lua
> -# modules are installed, for the given implementation. If no implementation
> +# modules are installed for the given implementation. If no implementation
>  # is provided, ${ELUA} will be used.
>  #
>  # Please note that this function requires Lua and pkg-config installed,
>  # and therefore proper build-time dependencies need be added to the ebuild.
> +#
> +# For prefix installations, this function does not include the offset in
> +# the path.
>  lua_get_lmod_dir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  

That's better, thanks. I would go a step further though and add a note
to lua_get_shared_lib() to say that this *does* include the SYSROOT and
prefix. It is slightly odd that this differs from lua_get_include_dir()
but I cannot find any examples where lua_get_shared_lib() is used in an
install phase.

Can you confirm that following this, you will go around and correct all
the ebuilds that use lua_get_include_dir() ? I count around 21 of them.
As I said, ${ESYSROOT} should be prepended when it is used in a build
phase. luaexpat is a good example of it being used in both a build and
an install phase.

Note that all of this is still slightly broken by the difference
between dev-util/pkgconfig and dev-util/pkgconf but I'll resolve that
as soon as I can. Most users, including most prefix users, won't notice.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpMZXQy_kycK.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread James Le Cuirot
On Fri, 8 Jan 2021 14:26:32 +0200
Joonas Niilola  wrote:

> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian

These are maintained by me and I'd like to keep them. They can be
pulled in by running the esteam tool in steam-overlay for games that
need them. They could potentially be used for other old or
Debian-oriented binary packages too.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp25epsm8vEo.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] eclass/lua.eclass: remove EPREFIX from exported paths

2021-01-07 Thread James Le Cuirot
On Thu,  7 Jan 2021 17:13:09 -0600
William Hubbs  wrote:

> Bug: https://bugs.gentoo.org/762769
> Signed-off-by: William Hubbs 
> ---
>  eclass/lua-utils.eclass | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..1e552da0848 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -212,8 +212,10 @@ _lua_get_library_file() {
>   die "Invalid implementation: ${impl}"
>   ;;
>   esac
> - libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
>  
> + libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
> + libdir="${libdir#${ESYSROOT#${SYSROOT}}}"
> + 
>   debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
>   echo "${libdir}/${libname}"
>  }
> @@ -274,6 +276,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_CMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_CMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_CMOD_DIR = 
> ${LUA_CMOD_DIR}"
> @@ -282,6 +285,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable includedir 
> ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_INCLUDE_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_INCLUDE_DIR = 
> ${LUA_INCLUDE_DIR}"
> @@ -298,6 +302,7 @@ _lua_export() {
>   local val
>  
>   val=$($(tc-getPKG_CONFIG) --variable 
> INSTALL_LMOD ${impl}) || die
> + val="${val#${ESYSROOT#${SYSROOT}}}"
>  
>   export LUA_LMOD_DIR=${val}
>   debug-print "${FUNCNAME}: LUA_LMOD_DIR = 
> ${LUA_LMOD_DIR}"

NACK.

The _lua_get_library_file() result is used for lua_get_shared_lib() and
this appears to be always used when building, not when installing. In
that case, you want it to return the prefixed (and sysrooted) path or
callers should always prepend ${ESYSROOT}.

Similarly, lua_get_include_dir() is often used for building but is
sometimes used for installing too. luaexpat uses it for both! If this
is returned unprefixed then luaexpat and similar should prepend
${ESYSROOT} when building and ${ED} when installing. 

I did suggest that you explicitly whether the paths are prefixed or not
in the function descriptions so please do that.

As discussed, I'll get back to you on the other sysroot issue.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp2lt1tHBLfK.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-06 Thread James Le Cuirot
On Mon, 4 Jan 2021 19:28:37 -0500
Mike Gilbert  wrote:

> On Mon, Jan 4, 2021 at 6:45 PM Mike Gilbert  wrote:
> >
> > On Mon, Jan 4, 2021 at 6:18 PM James Le Cuirot  wrote:  
> > > $ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > > /lib/udev
> > >
> > > The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
> > > And why would it be? The man page says that this variable is only
> > > applied to -I and -L flags. I don't know for sure but I suspect that
> > > pkg-config just sees this as some arbitrary variable with no special
> > > path handling at all. I wonder what led you to think that this fix was
> > > necessary?  
> >
> > Interesting!
> >
> > pkg-config behaves differently on my system:
> >
> > % PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev
> > /foo/lib/udev
> >
> > This appears to be a difference in behavior between dev-util/pkgconfig
> > and dev-util/pkgconf. I am using pkgconf, and I would guess you are
> > using pkgconfig.
> >
> > I guess I will ask pkgconf upstream for help on this; it seems like
> > this is probably an unintended behavior.  
> 
> It seems that the pkgconf behavior is intentional.
> 
> https://github.com/pkgconf/pkgconf/issues/69
> 
> I opened an issue to see if we can get some kind of opt-out.
> 
> https://github.com/pkgconf/pkgconf/issues/205

Hmmm. At this point, I'm thinking maybe we should just address this in
cross-pkg-config. It seems unfair to ask upstream to accommodate this
when the tool is just doing what we asked it to. Perhaps it could
respect PKG_CONFIG_SYSROOT_DIR if it is already set, even when empty.
It wouldn't allow to you set this differently for the build host but
you shouldn't ever have to. I think I'd prefer this over adding yet
another confusing variable. The same could be applied to
PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSTEM_LIBRARY_PATH for consistency.
What do you think?

On a side note, I think that what cross-pkg-config does should be part
of Portage or something rather than part of crossdev because there's
nothing really cross-compile-specific about it. You can set SYSROOT
when building natively, although that tends to run into even more
issues than you get with cross.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpNBAoelSf5e.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-04 Thread James Le Cuirot
On Sun, 3 Jan 2021 10:16:49 -0500
Mike Gilbert  wrote:

> On Sun, Jan 3, 2021 at 7:52 AM James Le Cuirot  wrote:
> >
> > On Sat,  2 Jan 2021 20:09:04 -0500
> > Mike Gilbert  wrote:
> >  
> > > When cross-compiling, users will typically have
> > > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> > >
> > > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > > output get prefixed with this value.
> > >
> > > Signed-off-by: Mike Gilbert 
> > > ---
> > >
> > > This patch has already been pushed, but I figured I would send it for
> > > review in case someone else can think of a failure case, or has a better
> > > solution.
> > >
> > >  eclass/systemd.eclass | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > > index 81065a0af79a..f6d1fa2d92d6 100644
> > > --- a/eclass/systemd.eclass
> > > +++ b/eclass/systemd.eclass
> > > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> > >
> > >   if $(tc-getPKG_CONFIG) --exists systemd; then
> > >   d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) 
> > > || die
> > > + d=${d#${SYSROOT}}
> > >   d=${d#${EPREFIX}}
> > >   else
> > >   d=${fallback}  
> 
> > The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> > for udev.eclass. It took a while to get this agreed and corrected in
> > PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> > EPREFIX; they may not be the same.  
> 
> Ugh, that "corrected" logic in PMS head is nasty.

I wish it could be simpler but that's just the nature of the beast. I
could give an example of why it matters, even in this context, but I
think you already know. There's some good news though...

> > If you just strip ESYSROOT then
> > it will always do the right thing but you'll need this fall back for
> > older EAPIs. I'm not sure why you didn't do it in one line?  
> 
> I was trying to accommodate older EAPIs that do not define ESYSROOT.
> This seemed like the simplest approach. It also allows for the case
> where someone is not using cross-pkg-config, and
> PKG_CONFIG_SYSROOT_DIR is unset. Since SYSROOT and EPREFIX are removed
> separately, if one of them is already missing, it will just be
> skipped.

I saw your new patch. I noticed that it sets the "d" variable but
doesn't make use of it. That aside, I thought perhaps I could come up
with something cleaner. That's when I made an amusing discovery.

$ PKG_CONFIG_SYSROOT_DIR=/foo pkg-config --variable=udevdir udev  
/lib/udev

The udevdir variable is not affected by PKG_CONFIG_SYSROOT_DIR at all.
And why would it be? The man page says that this variable is only
applied to -I and -L flags. I don't know for sure but I suspect that
pkg-config just sees this as some arbitrary variable with no special
path handling at all. I wonder what led you to think that this fix was
necessary?

That said, you'll still need special handling for EAPI 7. Unfortunately
there's no separate variable for the prefix alone but at least it's
simpler now. Something like this?

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c3..f10ea0de01a2 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,12 +50,19 @@ fi
 # @DESCRIPTION:
 # Get unprefixed udevdir.
 _udev_get_udevdir() {
-   if $($(tc-getPKG_CONFIG) --exists udev); then
-   local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
-   echo "${udevdir#${EPREFIX%/}}"
-   else
-   echo /lib/udev
+   local udevdir="/lib/udev"
+
+   if $(tc-getPKG_CONFIG) --exists udev; then
+   udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
+
+   if [[ ${EAPI:-0} == [0123456] ]]; then
+   udevdir=${udevdir#${EPREFIX}}
+   else
+   udevdir=${udevdir#${ESYSROOT#${SYSROOT}}}
+   fi
fi
+
+   echo "${udevdir}"
 }

One last question. Why is this dynamic at all? Shouldn't it just be
hardcoded to /lib/udev? Sure, a user could patch udev to make it
something different if they really wanted but there are plenty of other
paths we just assume. What makes this one special?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpSPRcvfw2Md.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-03 Thread James Le Cuirot
On Sun, 3 Jan 2021 12:52:08 +
James Le Cuirot  wrote:

> On Sat,  2 Jan 2021 20:09:04 -0500
> Mike Gilbert  wrote:
> 
> > When cross-compiling, users will typically have
> > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> > 
> > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > output get prefixed with this value.
> > 
> > Signed-off-by: Mike Gilbert 
> > ---
> > 
> > This patch has already been pushed, but I figured I would send it for
> > review in case someone else can think of a failure case, or has a better
> > solution.
> > 
> >  eclass/systemd.eclass | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > index 81065a0af79a..f6d1fa2d92d6 100644
> > --- a/eclass/systemd.eclass
> > +++ b/eclass/systemd.eclass
> > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> >  
> > if $(tc-getPKG_CONFIG) --exists systemd; then
> > d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> > +   d=${d#${SYSROOT}}
> > d=${d#${EPREFIX}}
> > else
> > d=${fallback}  
> 
> I was going to say this is not the best approach as it would be better
> to tell pkg-config to not add the SYSROOT in the first place. I now
> realise we have shot ourselves in the foot with cross-pkg-config as it
> uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
> and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
> had prefix-related fixes for cross-pkg-config lined up for over a year
> but unfortunately they do not address this. Trying to accommodate this
> use case would probably just make it more confusing though so maybe
> your approach is best after all.
> 
> The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> for udev.eclass. It took a while to get this agreed and corrected in
> PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> EPREFIX; they may not be the same. If you just strip ESYSROOT then
> it will always do the right thing but you'll need this fall back for
> older EAPIs. I'm not sure why you didn't do it in one line? I forget if
> EPREFIX is normalised to be / rather thank blank.
> 
> d=${d#${SYSROOT%/}/${EPREFIX#/}}

Had another minute to think. EPREFIX always strips the trailing slash
so it would be blank.

d=${d#${SYSROOT%/}${EPREFIX}}

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp0JKYoJYsgE.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output

2021-01-03 Thread James Le Cuirot
On Sat,  2 Jan 2021 20:09:04 -0500
Mike Gilbert  wrote:

> When cross-compiling, users will typically have
> PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> 
> When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> output get prefixed with this value.
> 
> Signed-off-by: Mike Gilbert 
> ---
> 
> This patch has already been pushed, but I figured I would send it for
> review in case someone else can think of a failure case, or has a better
> solution.
> 
>  eclass/systemd.eclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> index 81065a0af79a..f6d1fa2d92d6 100644
> --- a/eclass/systemd.eclass
> +++ b/eclass/systemd.eclass
> @@ -50,6 +50,7 @@ _systemd_get_dir() {
>  
>   if $(tc-getPKG_CONFIG) --exists systemd; then
>   d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> + d=${d#${SYSROOT}}
>   d=${d#${EPREFIX}}
>   else
>   d=${fallback}

I was going to say this is not the best approach as it would be better
to tell pkg-config to not add the SYSROOT in the first place. I now
realise we have shot ourselves in the foot with cross-pkg-config as it
uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
had prefix-related fixes for cross-pkg-config lined up for over a year
but unfortunately they do not address this. Trying to accommodate this
use case would probably just make it more confusing though so maybe
your approach is best after all.

The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
for udev.eclass. It took a while to get this agreed and corrected in
PMS but if SYSROOT points to / then the effective prefix is BROOT, not
EPREFIX; they may not be the same. If you just strip ESYSROOT then
it will always do the right thing but you'll need this fall back for
older EAPIs. I'm not sure why you didn't do it in one line? I forget if
EPREFIX is normalised to be / rather thank blank.

d=${d#${SYSROOT%/}/${EPREFIX#/}}

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpTmn9Lvd_4Y.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: media-libs/jpeg

2020-12-30 Thread James Le Cuirot
On Wed, 30 Dec 2020 12:54:59 +0100
Michał Górny  wrote:

> # Michał Górny  (2020-12-30)
> # Unmaintained.  Entirely replaced by media-libs/libjpeg-turbo,
> # to the point that reverse dependencies no longer build with
> # media-libs/jpeg.  The two libraries are binary-incompatible,
> # and the current method of switching between them is incorrect.
> # Removal in 30 days.  Bug #762634.
> media-libs/jpeg

It's worth noting that libjpeg-turbo is now an official reference
implementation. https://jpeg.org/items/20190204_press.html

Also of interest is the fact that libjpeg-turbo can be built to be
ABI-compatible with jpeg-7 and jpeg-8, though not the current jpeg-9. I
added a turbo-based media-libs/jpeg-compat for version 8 to
steam-overlay.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAmU8tbJTZQ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-17 Thread James Le Cuirot
On Thu, 17 Dec 2020 14:38:43 -0600
William Hubbs  wrote:

> On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote:

> > I don't really understand what you mean by this. I am converting one
> > internal bash function into an external script so that its python
> > dependencies can be better defined and managed.  
> 
> What I mean is, ebuilds should not be calling _meson_env_array at all
> since it is defined and documented as an eclass internal function.
> 
> I would like to know more about what the gallium-nine-standalone ebuild
> is doing and why it needs to call a meson.eclass internal function.
> 
> On the other hand, if _meson_env_array is meant to be called by ebuilds,
> we need to rename it and improve the documentation for it in the eclass.

I knew I spoke to someone about this on IRC and turns out it was you 2
years ago. :P The ebuild needs to render flags as a Meson array and
this eclass function is the best way to do it. You did not know why it
was private and said to go ahead anyway but file a bug so that this
situation could be improved. I admittedly didn't get around to filing a
bug but I was totally prepared to deal with the fall out if it broke.
Now floppym is improving the situation anyway and fixing the ebuild
too. I give my thanks to him. Job done?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpPbvZE71UX_.pgp
Description: OpenPGP digital signature


[gentoo-dev] Re: [PATCH 2/3] meson.eclass: use meson-array script

2020-12-11 Thread James Le Cuirot
On Fri, 11 Dec 2020 18:17:43 -0500
Mike Gilbert  wrote:

> This allows python-exec to pick a suitable interpreter when
> /usr/bin/python is missing.
> 
> Closes: https://bugs.gentoo.org/759433
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/meson.eclass | 100 +---
>  1 file changed, 39 insertions(+), 61 deletions(-)

That's cool. You forgot to remove the __MESON_ARRAY_PARSER definition
though.


pgpY5ngFuvHKB.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Pushing to distfiles?

2020-11-14 Thread James Le Cuirot
On Sun, 15 Nov 2020 11:03:29 +1300
Kent Fredric  wrote:

> On Wed, 11 Nov 2020 19:38:35 -0500
> Rich Freeman  wrote:
> 
> > I just host stuff like that on my dev webspace, or better yet on
> > github or something else that will auto-tarball stuff.  
> 
> Oh, yeah, and don't rely on github auto-tarball stuff.
> 
> History has demonstrated github sometimes "forgets" their cached copies
> of those tarballs, and then later when requested, it will regenerate
> them fresh ... but with different SHAsums.
> 
> If you're gonna use github for tarballs, roll that tarball yourself,
> and attach it to a "release", manually and explicitly, and then use the
> URL to the release asset.
> 
> Only then can you be sure: 
> 
> a) Of what the tarball actually contains
> b) Of what the tarballs SHAsum will be

I'm not claiming this has never actually happened but I use these
GitHub tarballs *a lot* and I don't recall ever seeing it. Does anyone
know for sure that it's happened in, say, the last 3 years?  It's a lot
of extra work for a problem that may no longer exist or is so rare that
it's just not worth the effort.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUsAXfBuNwo.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

2020-11-03 Thread James Le Cuirot
On Tue, 03 Nov 2020 22:32:11 +0100
Michał Górny  wrote:

> Additionally, the following packages are looking for a new maintainer:
> 
> net-misc/chrony

I may take this if no one else really wants it. I run a simple client
and server setup on Gentoo at home but I have no interest in the fancy
features.

> www-client/vivaldi
> www-client/vivaldi-snapshot

I'll take these but it may take me some time to get some kind of
automation going for the frequent bumps involved. I know that Opera is
a similar package but I really don't want it.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpBo6kggM2u6.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: games-board/spider

2020-10-03 Thread James Le Cuirot
# Alexey Sokolov  (2020-10-03)
# Package with no available HOMEPAGE, SRC_URI and multiple compilation issues.
# Bug #741468, removal in 30 days.
games-board/spider

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpzcRSFp1vbJ.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: app-arch/unarj

2020-09-13 Thread James Le Cuirot
# James Le Cuirot  (2020-09-13)
# License issues. app-arch/arj is a better alternative. Removal in 30
# days. See bug #694746.
app-arch/unarj

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpz225rDDqkd.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2020-09-13 Thread James Le Cuirot
On Sun, 30 Aug 2020 11:19:51 +0300
Joonas Niilola  wrote:

> here's a list of few packages dropped to maintainer-needed due to
> retirement of inactive    maintainers.
> 
> b = bugs open,
> v = new version available.
> 
> app-arch/lha

Taken. Amiga forever! ;)

> app-arch/unarj b

This is going to be last-rited. See https://bugs.gentoo.org/694746.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpa_05luHXpS.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] How to set CXX compiler?

2020-07-03 Thread James Le Cuirot
On Fri, 03 Jul 2020 22:35:30 +
Xianwen Chen (陈贤文)  wrote:

> In the Makefile, it is written that 
> 
> cc = g++ 
> 
> I would like to use sed to patch it so that it ebuild knows which g++ to
> use. For example, depending on whether ccache is set, ebuild shall know
> whether to use ccache. 

Rather than patch it, start the build with:

emake cc="$(tc-getCXX)"

You'll probably need to do more to respect CXXFLAGS and such though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUk0gHCJfvA.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-20 Thread James Le Cuirot
On Sat, 20 Jun 2020 14:58:22 +0300
Azamat Hackimov  wrote:

> > games-emulation/openmsx  
> 
> git version migrated to meson and python3

Yeah, don't worry, this has been on my TODO for a while and I'll step
it up the list. I was hoping they'd do a release but no such luck.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpuDKd84KFJF.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Looking for a co-maintainer: games-fps/gzdoom

2020-06-08 Thread James Le Cuirot
Hey William,

On Sun, 7 Jun 2020 15:13:13 -0400
William Breathitt Gray  wrote:

> I am looking for a co-maintainer for the games-fps/gzdoom package.
> GZDoom version 4.4.0 was just released and GZDoom has been refactored to
> move its audio code to a new external library called ZMusic:
> https://bugs.gentoo.org/727448
> 
> A games-fps/gzdoom-4.4.0 version bump will require the introduction of a
> new zmusic ebuild. Since GZDoom is one of the larger DOOM source ports,
> I figure it'll be good to have more than one person looking after these
> packages.
> 
> If anyone is interested in helping out, please let me know.

I'm happy for this to just go under the games umbrella. You're aware
that we're stretched pretty thin so I can understand why you're asking
for extra help but I'll gladly give this one extra attention, at least
in the short term. I've been using it on an almost daily basis
recently! My new map only really works with GZDoom. 3D floors are
awesome. ;)

Cheers,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpkLSR0yxhkq.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Gentoo/OpenBSD current status

2020-06-05 Thread James Le Cuirot
On Thu,  4 Jun 2020 23:54:44 + (UTC)
"Thomas Mueller"  wrote:

> > Benda Xu wrote:  
> > > > I was wondering if the openbsd prefix support is something
> > > > that is still garnering any interest from gentoo?  
>  
> > > There is still interest in Gentoo.  But no one seems to have energy to
> > > take care of it.  
> 
> > FWIW I have interest in this as well.  
> 
> 
> > > Your contribution is welcomed.  
> 
> > What contributions are known to be needed at the moment?  
> 
> 
> > Kind regards  
> 
> > //Peter  
> 
> What about NetBSD and FreeBSD?
> 
> I use NetBSD and FreeBSD but am not interested in OpenBSD, inside or outside 
> Gentoo.
> 
> I am also curious about whether crossdev could be used to cross-compile to 
> Linux (glibc, musl or uClibc-ng).

I don't see why not. If I can cross-build Windows binaries on Linux
then anything is possible!

> My impression, from Gentoo website, was that (Net, Open, Free)BSD prefix 
> support was no longer active.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpFtl0wWxRG8.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: media-libs/aldumb

2020-05-31 Thread James Le Cuirot
# James Le Cuirot  (2020-05-31)
# Now merged into media-libs/dumb with the allegro USE flag. This
# package was added before EAPI 2 and USE-dependencies.
media-libs/aldumb


pgp_vyqIs4GOF.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs

2020-05-28 Thread James Le Cuirot
On Tue, 26 May 2020 23:12:06 +0100
Andrey Utkin  wrote:

> Call for successors
> ===
> 
> The following are the packages I do not currently use myself so have the least
> motivation about. Dropping me from maintainers list is encouraged.
> 
> V4L:
> 
> * media-libs/libv4l
> * media-tv/v4l-utils

I'll somewhat reluctantly take these as no one else has. They're
loosely related to tvheadend, which I also maintain.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpurNYeQQwcU.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Should NATTkA reject keywordreqs for packages with -arch (-*) keywords?

2020-05-05 Thread James Le Cuirot
On Tue, 05 May 2020 22:19:59 +0200
Michał Górny  wrote:

> Hi,
> 
> TL;DR: should NATTkA reject request to keyword on arch if the ebuild has
> '-arch' (or '-*') in KEYWORDS already?
> 
> 
> Background: I've recently been rekeywording two packages that gained
> dependency on gevent.  When I was mass-requesting rekeywording, it
> escaped my attention that gevent is explicitly marked '-ia64'.  The arch
> team apparently got mad at me and added gevent to their package.mask to
> make its breakage more explicit.
> 
> I think it would make sense if NATTkA detected '-ia64' there and told me
> that the package is keyword-masked on ia64.
> 
> The flip side is that it would prevent people from using NATTkA to
> restore keywords that were marked '-arch' before.  Of course, if this
> would ever be necessary it could easily be resolved via removing '-arch' 
> first or adding some extra hack.
> 
> WDYT?

Play it safe. -* is frequently used for binary packages where an arch
will simply either work or it won't, with little likelihood of the
situation changing. -arch is so rare that I don't recall ever seeing
it. In either case, restoring an arch should be an explicit action.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpsWcCmYiPbG.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] */*: downgrade m68k down to ~m68k

2020-04-21 Thread James Le Cuirot
On Tue, 21 Apr 2020 08:10:15 +0100
Sergei Trofimovich  wrote:

> With
> 
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dce3dc0aa1341155a31407122e079632fcd07ca
> m68k does not have stable keywords in ::gentoo anymore and
> thus becomes ~arch-only Gentoo target.
> 
> """
> */*: downgrade m68k down to ~m68k
> m68k and ~m68k trees are inconsistent. Let's drop keywords
> down to ~m68k only. Profiles already accept both keywords:
> 
> ACCEPT_KEYWORDS="m68k ~m68k"
> """
> 
> Even basic packages don't have consistent ~m68k keywords. I don't
> think stable keywords have any use today.
> 
> I will pass through and un-CC/close all STABLEREQ bugs where m68k
> is CCed.

Thanks, I think this was inevitable really. I still hope to create a
new stage3 but not with sufficient regularity to use as a basis for a
stable @system.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpK6ym3Hrlf4.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] rpm.eclass: use BDEPEND for EAPI 7

2020-04-18 Thread James Le Cuirot
On Sat, 18 Apr 2020 11:15:49 -0400
David Michael  wrote:

> The build system's rpm2tar command is executed during unpack, so it
> must be install in /.
> 
> Signed-off-by: David Michael 
> ---
> 
> This patch fixes failures like this:
> >>> Unpacking source...
> >>> Unpacking urw-fonts-2.4-9.fc13.src.rpm to 
> /var/tmp/portage/media-fonts/urw-fonts-2.4.9/work  
> /var/tmp/portage/media-fonts/urw-fonts-2.4.9/temp/environment: line 850: 
> rpm2tar: command not found
> 
>  eclass/rpm.eclass | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/rpm.eclass b/eclass/rpm.eclass
> index 3a29c7e9f76..d27f0a386c7 100644
> --- a/eclass/rpm.eclass
> +++ b/eclass/rpm.eclass
> @@ -8,7 +8,10 @@
>  
>  inherit estack eutils
>  
> -DEPEND=">=app-arch/rpm2targz-9.0.0.3g"  
> +case "${EAPI:-0}" in
> + [0-6]) DEPEND=">=app-arch/rpm2targz-9.0.0.3g" ;;
> + *) BDEPEND=">=app-arch/rpm2targz-9.0.0.3g" ;;
> +esac
>  
>  # @FUNCTION: rpm_unpack
>  # @USAGE: 

+1

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpmzAsPzo17I.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Stabilizations and src_test

2020-04-12 Thread James Le Cuirot
On Sun, 12 Apr 2020 10:43:07 +0200
Agostino Sarubbo  wrote:

> If you work on the stabilization workflow you may have noticed that:
> 
> - There are people that rant if you don't run src_test against their packages;
> - There are people that rant if you open a test failure bug against their 
> packages and you block the stabilization.
> 
> So, unless there will be a clear policy about that, I'd suggest to introduce 
> a 
> way to establish if a package is expected to pass src_test or not.
> 
> A simple way to achieve this goal would be:
> introduce a new bugzilla custom flag (like "Runtime testing required" we 
> already have) maybe called "src_test pass" or similar, that, by default is 
> yes 
> and the maintainer should set it to no when needed.
> 
> In case of 'yes', the arch team member must compile with FEATURE="test" and 
> he 
> is allowed to block the stabilization in case of test-failure.
> 
> In case there will be a test-failure there are two choices:
> 1) The maintainer fixes the test failure;
> 2) The maintainer does not want to take care, so he can simply remove the 
> blocker and set "src_test pass" to no.
> 
> Both of the above are fine for me.
> 
> Obviously, if there are already test-failure bugs open, the flag "src_test 
> pass" should be set to 'no' when the stabilization bugs is filled.
> 
> I'm sure that this way would help to avoid wasting time on both sides.

Expecting the package to be marked stable while the tests fail seems
like a very odd stance to take. I would politely request that you flag
this up and if you get pushback but understandably don't want to fight
it then just add RESTRICT="test" yourselves, maybe filtered on a
particular USE flag if it only happens in specific situations. I think
the QA team would back you up here?

I understand the comments about only a few minor tests failing but if
the maintainer doesn't want to skip the entire suite then it is their
responsibility to limit the set of tests run by whatever means.
Unfortunately there is no universal method of doing this.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpS9YffxZvr0.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] ebuild life cycle review

2020-04-11 Thread James Le Cuirot
On Fri, 10 Apr 2020 18:21:00 +0200
Jonas Stein  wrote:

> > I would like to leave a suggestion for Gentoo portage ebuild review.
> > Since there are some ebuilds in portage that become outdated for more
> > than one year when there are new versions available, maybe could be
> > possible to add a new step in Gentoo QA service to generate an alarm
> > (send email to project and CI leaders) to request a human review.  
> 
> This service does already exist. Everybody can use repology [1], euscan
> [2] and others.
> 
> Bumping a package needs time - especially for testing. I work a lot on
> our bug tracker and my impression is that automatic bugs for a bump
> request are contra productive. We already have many important, but easy
> to fix open bugs.
> Automatic tickets for packages will flood bugzilla with tickets for
> unused packages and bind additional manpower.

Totally agree. I have already used euscan, and nowadays repology, and
they're very useful for keeping on top of the stuff I directly
maintain. I can also use them for the wider games team but there's a
mountain of work to do there and that's not even counting the constant
flood of largely automated bug reports we already get every day. I just
do what I can.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp4N4f_TOjII.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread James Le Cuirot
On Sat, 11 Apr 2020 18:38:27 +0300
Joonas Niilola  wrote:

> On 4/11/20 6:33 PM, Michał Górny wrote:
> > Hi,
> >
> > Now that we have proper components for keywording and stabilization,
> > the old keywords are redundant.  Nevertheless, some people still set
> > them.  I would like to propose two solutions going forward.  Either:
> >
> > 1. We kill both keywords, and just rely on components, or
> >
> > 2. I make NATTkA automatically add KEYWORDREQ or STABLEREQ where
> > appropriate.
> >
> > Which would you prefer?
> >  
> Less noise is better, so I vote for 1.
> 
> Wasn't aware KEYWORDREQ and STABLEREQ were useless, thats why I always
> set them. Will it break any commonly used search scripts / settings?

Me neither, must have missed that memo. Go for 1.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpw3dZfCiD2g.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 2/2] meson.eclass: add MYMESONARGS variable

2020-04-08 Thread James Le Cuirot
On Wed,  8 Apr 2020 16:34:52 -0400
Mike Gilbert  wrote:

> This was requested to allow users to pass aribtrary arguments to meson.
> 
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/meson.eclass | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 3e3a2e2f7a2e..0932a7ed427f 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -84,6 +84,11 @@ fi
>  # Optional meson test arguments as Bash array; this should be defined before
>  # calling meson_src_test.
>  
> +# @VARIABLE: MYMESONARGS
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# User-controlled environment variable containing arguments to be passed to
> +# meson in meson_src_configure.
>  
>  read -d '' __MESON_ARRAY_PARSER <<"EOF"
>  import shlex
> @@ -236,6 +241,9 @@ meson_src_configure() {
>  
>   BUILD_DIR="${BUILD_DIR:-${WORKDIR}/${P}-build}"
>  
> + # Handle quoted whitespace
> + eval "local -a MYMESONARGS=( ${MYMESONARGS} )"
> +
>   mesonargs+=(
>   # Arguments from ebuild
>   "${emesonargs[@]}"
> @@ -243,6 +251,9 @@ meson_src_configure() {
>   # Arguments passed to this function
>   "$@"
>  
> + # Arguments from user
> + "${MYMESONARGS[@]}"
> +
>   # Source directory
>           "${EMESON_SOURCE:-${S}}"
>  

I didn't mean for you to do this yourself so thank you very much
indeed! You've done a nice job, I've tested it, and it works perfectly.

Cheers,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpM1UUdR8UAC.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] ceph's static-libs

2020-04-05 Thread James Le Cuirot
On Sun, 5 Apr 2020 17:20:07 +
Peter Stuge  wrote:

> James Le Cuirot wrote:
> > Damn, I realised just as I hit send that there's a caveat here and
> > that's sub-dependencies. If you're building a partially static binary
> > then I think you're okay. A fully static binary obviously needs all its
> > dependencies to be static and that includes any sub-dependencies.  
> 
> Note that there isn't really a way to express "partially static" to the
> toolchain when building a binary.
> 
> If you link a binary -static then that is always "fully static". No .so
> will satisfy any -l options.
> 
> The only way a "partially static" binary gets created is when linking
> *without* -static but some -l libraries only exist as static libraries,
> or if a library/object archive is specified with full .a filename,
> without using -l.
> 
> And "partially static" also only means that some dependencies were
> included into the binary, but unlike "fully static" the binary is
> not runnable without ld.so and a fitting libc.

Yeah, I am aware and was glossing over the details slightly but thanks
for clarifying.

You can force static when linking specific libraries with -Wl,-static
and then undo this with -Wl,-dynamic. I don't know whether it's
feasible to do this with flags passed to Portage though, haven't tried.
Another approach might be to use INSTALL_MASK to filter out the share
libraries you don't want but that may have issues too.

> > That probably explains why the ceph dependencies are as they are  
> 
> I think USE=static-libs is nice to have, and ideally (IMHO) it would
> be a global USE flag, respected by every package that installs a
> library. The flag says nothing about consumers, it only promises
> availability of the .a files, which I think is nice.

Agreed, I think this is a reasonable position to take.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpvl5NR5ynXt.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] ceph's static-libs

2020-04-04 Thread James Le Cuirot
On Sat, 4 Apr 2020 10:43:26 +0100
James Le Cuirot  wrote:

> On Sat, 4 Apr 2020 08:12:09 +0200
> Alessandro Barbieri  wrote:
> 
> > I was trying to remove static-libs from hwloc and I noticed that the last
> > bump of ceph is requiring hwloc:=[static-libs?]
> > And I notices it needs also alot of other dependencies with [static-libs?]
> > Is there a *valid* reason for having ceph[static-libs] around in the first
> > place?
> > 
> > For more context on static-libs see:
> > https://projects.gentoo.org/qa/policy-guide/installed-files.html?highlight=static#pg0302
> > https://flameeyes.blog/2011/08/29/useless-flag-static-libs/
> > https://archives.gentoo.org/gentoo-dev/message/2dada80c2b9c85b0e83e6328428bf8ab
> >   
> 
> I do like to have the option for static-libs where it's not too much
> trouble. It's obviously not a mainline use case but I have needed it on
> occasions.
> 
> I think these dependencies are wrong though and I've seen the same
> thing in other packages. You don't need the dependent static libs
> when building other static libs. For example. I have webp[-static-libs]
> installed and I can build leptonica[static-libs,webp] just fine. They
> are only needed when linking executable binaries and for that, you'll
> typically have a static USE flag rather than static-libs. QEMU is a good
> example with its static and static-user USE flags. You could force a
> package to build static or partially static binaries through toolchain
> flags but then it's down to the user to ensure that all the dependent
> static libs are in place.
> 
> If the above paragraph is wrong, someone please correct me. :)

Damn, I realised just as I hit send that there's a caveat here and
that's sub-dependencies. If you're building a partially static binary
then I think you're okay. A fully static binary obviously needs all its
dependencies to be static and that includes any sub-dependencies. If
an executable statically links libwebp.a with JPEG support but you
don't have libjpeg.a then you'll end up with undefined references. That
probably explains why the ceph dependencies are as they are but the
resulting headache makes me think it's not worth the hassle. This is a
power user case and I'd leave the users to figure it out.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpSUYY7AIIC8.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] ceph's static-libs

2020-04-04 Thread James Le Cuirot
On Sat, 4 Apr 2020 08:12:09 +0200
Alessandro Barbieri  wrote:

> I was trying to remove static-libs from hwloc and I noticed that the last
> bump of ceph is requiring hwloc:=[static-libs?]
> And I notices it needs also alot of other dependencies with [static-libs?]
> Is there a *valid* reason for having ceph[static-libs] around in the first
> place?
> 
> For more context on static-libs see:
> https://projects.gentoo.org/qa/policy-guide/installed-files.html?highlight=static#pg0302
> https://flameeyes.blog/2011/08/29/useless-flag-static-libs/
> https://archives.gentoo.org/gentoo-dev/message/2dada80c2b9c85b0e83e6328428bf8ab

I do like to have the option for static-libs where it's not too much
trouble. It's obviously not a mainline use case but I have needed it on
occasions.

I think these dependencies are wrong though and I've seen the same
thing in other packages. You don't need the dependent static libs
when building other static libs. For example. I have webp[-static-libs]
installed and I can build leptonica[static-libs,webp] just fine. They
are only needed when linking executable binaries and for that, you'll
typically have a static USE flag rather than static-libs. QEMU is a good
example with its static and static-user USE flags. You could force a
package to build static or partially static binaries through toolchain
flags but then it's down to the user to ensure that all the dependent
static libs are in place.

If the above paragraph is wrong, someone please correct me. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpzFwxdMGt1r.pgp
Description: OpenPGP digital signature


[gentoo-dev] Re: [gentoo-dev-announce] Last rites: games-fps/ut2003

2020-03-31 Thread James Le Cuirot
On Tue, 31 Mar 2020 04:14:03 +0200
Jonas Stein  wrote:

> profiles: Mask games-fps/ut2003 for removal
> 
> SRC_URI is dead AND RESTRICT=mirror is required
> Bug: https://bugs.gentoo.org/715540

Fixed. Last-rites cancelled.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpcCW8mJfQLa.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New global USE flag 'gles2-only'

2020-03-31 Thread James Le Cuirot
On Tue, 31 Mar 2020 12:57:39 +0200
Andreas Sturmlechner  wrote:

> Hi,
> 
> this is currently used by 4 packages but there are many more to come, 
> especially in the dev-qt/* and kde-*/* categories where 'gles2' is being 
> renamed to 'gles2-only' where appropriate. Its purpose and description is 
> really the same everywhere.
> 
> Description: "Use GLES 2.0 or later instead of full OpenGL"
> 
> See also:
> - USE={egl,gles{,1,2,3}} flags are a total mess [1]
> - [gentoo-dev] Addressing split usage of USE=gles[123] [2]
> - PRs in prepration for gentoo.git [3], kde.git [4] and qt.git [5]
> 
> I plan to introduce this real soon, coinciding the necessary revbumps with 
> upcoming/in-preparation Qt 5.14.2 and KDE Plasma 5.18.4 version bumps.
> 
> Best regards,
> Andreas
> 
> 
> [1] https://bugs.gentoo.org/627758
> [2] https://archives.gentoo.org/gentoo-dev/message/
> ab302ac2ab641b1e82acad7d32308266
> [3] https://github.com/gentoo/gentoo/pull/13742
> [4] https://github.com/gentoo/kde/pull/888
> [5] https://github.com/gentoo/qt/pull/210

+1

Disclaimer: I maintain 2 of those 4 packages and used it because I knew
this change was coming.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpNKssYTm5bx.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] qt5-build.eclass: support sysroot builds

2020-03-27 Thread James Le Cuirot
On Fri, 27 Mar 2020 13:10:34 -0400
David Michael  wrote:

> I'd like to be able to install qt5 packages in a sysroot for staging,
> and this is an initial patch for it.  The pkg-config variables might not
> be required, but it seemed appropriate to pass the sysroot-configured
> versions through the build.  There are a few caveats:
> 
>   - The upstream configure scripts do some bad things like this:
> https://code.qt.io/cgit/qt/qtbase.git/tree/configure.pri#n363
> That makes the build fail for systems using lib64 (e.g. amd64).  I'm
> able to work around this by defining PKG_CONFIG_LIBDIR for dev-qt/*.

Indeed, that sucks. We should probably patch that out. I don't know
what it means where it says "or use -pkg-config to override this test",
do you? I suspect you could define PKG_CONFIG_LIBDIR=/ or anywhere that
simply exists and it will still work because our wrapper redefines that
variable anyway.

>   - This isn't for real cross-compiling.  There are places where it
> tries to execute cross-compiled programs that I haven't investigated
> yet, so this is only for building a sysroot for an architecture
> compatible with the build system for now.

Understood. I did try to do cross-compiling with Qt4 once upon a time
and I did make a little headway but it wasn't fun.

>   - The qt packages depend on each other being installed in / as well as
> the sysroot, so their ebuilds will need BDEPENDs added.

I imagine you'd at least need qtcore for qmake and moc. Probably not
the rest though?

>   - I've only gotten to testing a few packages that are dependencies of
> other applications (like VLC), so I may be missing breakages.
> 
> The patch basically just sets -sysroot when $SYSROOT is defined.  It
> also needs to set -extprefix to the normal prefix, since otherwise it
> would default to installing into /sysroot/prefix.  Is anyone involved in
> qt maintenance more experienced with this and able to comment?

I'm not the Qt guy but I am the cross guy. I'm not in a position to
test this right now but it looks good and I love the simplicity of it.
It's a hell of a lot simpler than Qt4 was. To be honest, we should be
setting QMAKE_PKG_CONFIG regardless.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppueAPzt7VC.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rites: media-video/gtk-recordmydesktop

2020-03-23 Thread James Le Cuirot
On Mon, 23 Mar 2020 00:13:46 +0100
Andreas Sturmlechner  wrote:

> # Andreas Sturmlechner  (2020-03-22)
> # Unmaintained revdep on dev-python/pygtk blocking its removal, py2-only
> # Bug #710172, masked for removal in 30 days.
> media-video/gtk-recordmydesktop

You may want to suggest media-video/simplescreenrecorder as a good
alternative.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpLIMw17qzq3.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-21 Thread James Le Cuirot
On Sat, 21 Mar 2020 22:03:41 +1300
Kent Fredric  wrote:

> On Sat, 21 Mar 2020 11:03:19 +0300
> Alexander Tsoy  wrote:
> 
> > Binary distros usually have separate repositories for each
> > architecture.  
> 
> One aspect: They don't have a package database that's a collection of
> bash scripts that have to be routinely executed.
> 
> And they also don't have USE flags to complicate dependency analysis.
> 
> So their user-side interface can handle this "Can't satisfy dependency"
> situation much more quickly. ( I have no recollection of apt taking
> more than a few seconds to work out what it needs to do, or throwing an
> error )

They also split out their packages a lot more than we do.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpp0vTUPxjE7.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: noarch keyword

2020-03-18 Thread James Le Cuirot
On Wed, 18 Mar 2020 12:47:53 -0500
William Hubbs  wrote:

> On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote:
> > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote:  
> > > this came up again on the recent thread about dropping non x86/amd64
> > > support for python packages, and I want to bring it up again on its own
> > > thread.
> > > 
> > > How often do architecture specific bugs really exist in languages like
> > > perl, python etc? From what I've seen they are pretty rare. Not to 
> > > mention,
> > > if we found one somewhere, we could adjust keywords as necessary.
> > > 
> > > Also, if someone did inadvertently keyword a package with noarch that 
> > > didn't
> > > work everywhere, it would be a matter of adjusting the keywords for that
> > > package.
> > > 
> > > So, my question is, why can't we add a noarch/~noarch keyword and see
> > > how things go? If it gets abused we can always nuke it later.
> > >   
> > 
> > 1. How is this going to work when noarch package depends on non-nonarch
> > package?  I mean, will all the package managers actually work?  Have you
> > did some minimal testing before bringing this up?  
>  
> Can you have multiple ACCEPT_KEYWORDS values in make.conf or
> make.defaults like this?
> 
>  ACCEPT_KEYWORDS="amd64 noarch"
> 
> If so, things should just work.

Not quite. Tools like repoman will need to be updated to understand
that an ebuild with KEYWORDS="amd64" can depend on another ebuild with
only KEYWORDS="noarch". I do think the idea has merit though.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpruHY6icF7Z.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-16 Thread James Le Cuirot
On Mon, 16 Mar 2020 22:15:32 +0100
"Andreas K. Huettel"  wrote:

> > > 
> > > https://github.com/zmedico/portage/compare/master...zmedico:drobbins-track
> > > -keywords?expand=1  
> > That's kind of what ALLARCHES is for although IIRC the rules state that
> > packages should still be initially keyworded in the usual way. Other
> > distros do "noarch" though so the idea isn't without precedent.  
> 
> It was a long discussion to get ALLARCHES finalized and accepted, and now 
> barely anyone is using it. (Most arch teams never bothered to adapt their 
> workflow.) Maybe we should do that for a start? 

We did use it for Java while I was around. I even wrote a policy page
about it. It would probably still be used if there was anything much
happening with Java at the moment.

https://wiki.gentoo.org/wiki/Project:Java/Stabilization_Policy

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp9wapE19Abm.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-14 Thread James Le Cuirot
On Sat, 14 Mar 2020 13:49:42 -0700
Zac Medico  wrote:

> On 3/14/20 1:15 PM, James Le Cuirot wrote:
> > On Sat, 14 Mar 2020 19:13:58 +0100
> > Michał Górny  wrote:
> > I've never joined an arch team as I'm not really interested in stable.
> > I understand what you're saying about keyword requests but I didn't
> > realise they were also a big issue.
> > 
> > I'm not even keeping up with the work I'm supposed to be doing already
> > so I don't exactly want to sign up for more. However, I do have a
> > couple of (unstable) arm systems that are important to me so I need to
> > keep them running and up to date. Perhaps we could write a tool that
> > looks up newer versions of installed ebuilds that have dropped keywords
> > for a given arch and report which dependencies also need keywording. I
> > guess we don't have something like that?  
> 
> Automation like that sounds good.
> 
> Also, I wonder if we should introduce an arch-independent keyword which
> would probably make sense for a lot of python packages.
> 
> Also, I've got this patch from drobbins that allows one architecture to
> sort of inherit keywords from another architecture:
> 
> https://github.com/zmedico/portage/compare/master...zmedico:drobbins-track-keywords?expand=1

That's kind of what ALLARCHES is for although IIRC the rules state that
packages should still be initially keyworded in the usual way. Other
distros do "noarch" though so the idea isn't without precedent.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpbAsFF3zc47.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Discontinuing (more-than-absolutely-minimal) Python support for non-x86 arches

2020-03-14 Thread James Le Cuirot
On Sat, 14 Mar 2020 19:13:58 +0100
Michał Górny  wrote:

> Dear developers,
> 
> TL;DR: Unless arch teams decide to help us, the Python team will stop
> supporting non-x86 arches and start dropping non-x86 keywords from
> reverse dependencies.
> 
> 
> Python team is struggling with a large number of keywordreqs
> and stablereqs.  It is common for new versions of Python packages to
> bring new dependencies, and it is uncommon for arch teams to handle our
> requests in time.
> 
> The situation is particularly bad on arm64 which seems to have initially
> stabilized a lot of packages but afterwards can't manage to stabilize
> new versions.  Even with the recent effort of NeddySeagoon, it is still
> common for me to open new stablereqs while the old ones are waiting for
> arm64.  Overall, arm64 ends up staying behind with dependencies as well
> which makes each new stablereq more and more effort.
> 
> However, all non-x86 arches are bad.  Making keywordreqs takes
> tremendous effort, and keeping them up-to-date with frequent package
> releases is simply impossible.  It is quite frustrating when a keyword
> request is open for a month, then some arch tester points out that
> the package list is outdated, you spend even more effort updating it,
> then you wait again and the same situation repeats.
> 
> In the end, we've reached the point where very high profile packages
> such as dev-python/virtualenv are missing almost all keywords.  To be
> honest, I don't want to spend another hour trying to update package
> list, so that *maybe* some arch team will finally consider helping us.
> 
> For this reason, I propose that the Python team officially stops
> supporting non-x86 arches.  For obvious reasons we will have to continue
> keeping Portage and the most basic packages work but we will not put any
> special effort to restore lost keywords, and we will drop keywords from
> low-profile packages as their dependencies are not keyworded.
> 
> I am thoroughly frustrated by this state of affairs, and I'm having
> a serious trouble motivating myself to do anything about it.  FWICS
> others have abandoned the ship earlier.  I will probably try to prepare
> some script to determine where we need to drop keywords, for a start.

I've never joined an arch team as I'm not really interested in stable.
I understand what you're saying about keyword requests but I didn't
realise they were also a big issue.

I'm not even keeping up with the work I'm supposed to be doing already
so I don't exactly want to sign up for more. However, I do have a
couple of (unstable) arm systems that are important to me so I need to
keep them running and up to date. Perhaps we could write a tool that
looks up newer versions of installed ebuilds that have dropped keywords
for a given arch and report which dependencies also need keywording. I
guess we don't have something like that?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpXeEcqGrGXe.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] autotools.eclass: reorder sysroot M4 include dir option

2020-03-13 Thread James Le Cuirot
On Fri, 13 Mar 2020 14:23:48 -0400
David Michael  wrote:

> The old autoconf-2.13 version requires options to be specified
> before the file name argument, so packages with WANT_AUTOCONF="2.1"
> would fail to build in a sysroot with the -l option at the end.
> 
> Closes: https://bugs.gentoo.org/710792
> Signed-off-by: David Michael 
> ---
>  eclass/autotools.eclass | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
> index 9df0e1b9366..625abd0e9d1 100644
> --- a/eclass/autotools.eclass
> +++ b/eclass/autotools.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2018 Gentoo Foundation
> +# Copyright 1999-2020 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: autotools.eclass
> @@ -512,7 +512,7 @@ autotools_run_tool() {
>   fi
>  
>   if ${m4flags} ; then
> - set -- "${1}" $(autotools_m4dir_include) "${@:2}" 
> $(autotools_m4sysdir_include)
> + set -- "${1}" $(autotools_m4dir_include) 
> $(autotools_m4sysdir_include) "${@:2}"
>   fi
>  
>   # If the caller wants to probe something, then let them do it directly.

NACK. Please see https://bugs.gentoo.org/710792#c4.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpTx6ZOTI21P.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/4] elt-patches: support wrapped Win32 MSVC toolchain

2020-03-12 Thread James Le Cuirot
On Thu, 12 Mar 2020 11:23:04 +0100
Alexis Ballier  wrote:

> On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org wrote:
> > As this native Win32 support is considered highly experimental still,
> > I
> > would like to apply the libtool patches for parity via elibtoolize
> > only,
> > without applying them in sys-devel/libtool itself yet.
> >   
> 
> IIRC you need to do it this way, experimental or not: elibtoolize is
> needed for packages whose autotools have been generated with an old
> libtool (ie all of them for now). eautoreconf should call elibtoolize,
> so, after having this in elt-patches, better focus on upstreaming this
> in libtool itself so that the need for elibtoolize fades away with
> time.
> 
> You will probably run into the same issues as in the old days with BSD:
> not all packages run elibtoolize and you do not have a sane way to
> force this besides editing ebuilds.

I've long wanted to automatically apply elibtoolize to fix other
cross-compile issues. I did come up with a rough prototype and it did
work though I imagine it might break some packages. Maybe it should be
opt-out rather than opt-in?

Without looking into the meat of the libtool patches themselves, the
changes seem good.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp7XRjCKFBMd.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 4/4] winnt: die if libtool version is not 2.4.6+

2020-03-12 Thread James Le Cuirot
On Thu, 12 Mar 2020 09:06:26 +0100
ha...@gentoo.org wrote:

> From: Michael Haubenwallner 
> 
> Signed-off-by: Michael Haubenwallner 
> ---
>  eltpatch.in | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/eltpatch.in b/eltpatch.in
> index 6b69216..e12f754 100644
> --- a/eltpatch.in
> +++ b/eltpatch.in
> @@ -179,7 +179,7 @@ elibtoolize() {
>   *-hpux*)elt_patches+=" hpux-conf deplibs hc-flag-ld 
> hardcode hardcode-relink relink-prog no-lc" ;;
>   *-irix*)elt_patches+=" irix-ltmain" ;;
>   *-mint*)elt_patches+=" mint-conf" ;;
> - *-winnt*)   elt_patches+=" winnt-conf winnt-ltmain" ;;
> + *-winnt*)   elt_patches+=" winnt-ltmain winnt-conf" ;;
>   esac
>  
>   if ${LD} --version 2>&1 | grep -qs 'GNU gold'; then

This change reorders something you added in the first patch.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUhSt6MDEk0.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] meson.eclass: Set needs_exe_wrapper in cross file

2020-03-04 Thread James Le Cuirot
On Wed,  4 Mar 2020 11:55:30 -0800
Matt Turner  wrote:

> needs_exe_wrapper tells meson whether the build machine is able to
> directly execute the binaries it produces or whether it needs an exe
> wrapper (like QEMU). For non-native ABI builds like building 32-bit
> libraries on an x86-64 system, we want this set to false to communicate
> to meson that the build machine can run the binaries directly.
> 
> This allows dev-libs/wayland to execute the wayland-scanner binary it
> builds rather than relying on the system's.
> 
> Signed-off-by: Matt Turner 
> ---
>  eclass/meson.eclass | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/eclass/meson.eclass b/eclass/meson.eclass
> index 0588590b31e..16e17dd4a38 100644
> --- a/eclass/meson.eclass
> +++ b/eclass/meson.eclass
> @@ -149,6 +149,9 @@ _meson_create_cross_file() {
>   # This may require adjustment based on CFLAGS
>   local cpu=${CHOST%%-*}
>  
> + local needs_exe_wrapper=false
> + tc-is-cross-compiler && needs_exe_wrapper=true
> +
>   cat > "${T}/meson.${CHOST}.${ABI}" <<-EOF
>   [binaries]
>   ar = $(_meson_env_array "$(tc-getAR)")
> @@ -173,6 +176,7 @@ _meson_create_cross_file() {
>   objc_link_args = $(_meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
>   objcpp_args = $(_meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
>   objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
> + needs_exe_wrapper = ${needs_exe_wrapper}
>  
>   [host_machine]
>   system = '${system}'

LGTM!

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpYnYr8e6Y6F.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2] ruby-ng.eclass: Include (-) in RUBY_TARGETS USE-dependencies

2020-01-03 Thread James Le Cuirot
On Fri, 3 Jan 2020 22:34:19 +
Michael 'veremitz' Everitt  wrote:

> On 03/01/20 10:36, David Seifert wrote:
> > On Thu, 2020-01-02 at 21:54 +, Michael 'veremitz' Everitt wrote:  
> >> On 02/01/20 21:08, Michał Górny wrote:  
> >>> On Thu, 2020-01-02 at 21:15 +0100, Ulrich Mueller wrote:  
> >>>>>>>>> On Thu, 02 Jan 2020, Michał Górny wrote:  
> >>>>> --- a/eclass/ruby-ng.eclass
> >>>>> +++ b/eclass/ruby-ng.eclass
> >>>>> @@ -137,7 +137,7 @@ ruby_samelib() {
> >>>>> local res=
> >>>>> for _ruby_implementation in $(_ruby_get_all_impls); do
> >>>>> has -${_ruby_implementation} $@ || \
> >>>>> -   res="${res}ruby_targets_${_ruby_impleme
> >>>>> ntation}?,"
> >>>>> +   res="${res}ruby_targets_${_ruby_impleme
> >>>>> ntation}(-)?,"
> >>>>> done
> >>>>>  
> >>>>> echo "[${res%,}]"  
> >>>> Hadn't we established that ruby_samelib() is dead code, no longer
> >>>> used
> >>>> since 2010?
> >>>>  
> >>> You did.  However, it isn't marked as private API and I'm not the
> >>> eclass
> >>> maintainer to take care of removing public API.  I have no clue if
> >>> Ruby
> >>> project doesn't have some secret overlays using it.
> >>>  
> >>  You can't use QA super-powerz ?! BDFL + sub-BDFL ?!
> >> *
> >>
> >> * Thought the tags probably worth making explicit
> >>  
> > Can you please stop polluting the -dev mailing list with this senseless
> > chatter?
> >
> >  
> Perhaps I should remind you that this is a public mailing list (or hasn't
> successfully been censored Yet) and not a private communication channel for
> developers (see -core for this). But I don't need to tell you this

This may be a public list and I don't always expect threads to stay
precisely on-topic but the posts should still have some value. This was
just frivolous. You won't know this but I have defended your presence
on this list multiple times in the past. Please respect that.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpxN8QOz1six.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Keywordreqs and slacking arch teams

2019-12-28 Thread James Le Cuirot
On Sun, 29 Dec 2019 00:27:36 +1300
Kent Fredric  wrote:

> On Sat, 28 Dec 2019 11:14:15 +
> Michael 'veremitz' Everitt  wrote:
> 
> > I know I'm gonna be shot down in flames, because $heresy, but here is where
> > a package 'database' would actually work quite well, because you can
> > trivially create a query that pulls this data out, and sorts it by package
> > category or maintainer or whatever you like ..
> > 
> > Ok, let the flamewars begin ...  
> 
> There's no real problem with a package database, however, the real
> limitation is in the ebuild source format, which ultimately means any
> such database needs a lot of bash-sourcing hell to simply stay
> up-to-date ( any time an eclass changes, the interpretation of every
> ebuild that uses it also changes, necessitating some pretty fun(1) code )
> 
> And that winds you up fighting with portage internals.
> 
> So simply, in order for somebody like me to actually implement such a
> thing, a precursory step is to rewrite enough portage to do just that.
> 
> But I haven't (yet) gotten around to that.
> 
> 
> 1: Not actually fun.

Doesn't https://packages.gentoo.org already have such a database?
Unfortunately a3li used Elasticsearch, which no one understands, but
it's a start.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpUl78_P3IXC.pgp
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] Clean up remnants of eapi5-hdepend, HDEPEND and targetroot

2019-12-26 Thread James Le Cuirot
I wanted to do this in the first place but someone, I forget who, said
it needs to stay. :/

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAftQqoeABx.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: games-util/xboxgw

2019-12-23 Thread James Le Cuirot
# James Le Cuirot  (2019-12-23)
# No license. HOMEPAGE and SRC_URI are dead.
# Removal in 30 days. See bug #703552.
games-util/xboxgw

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp9Q4b9JuPlX.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] dotnet.eclass: Add EAPI 7 support

2019-12-17 Thread James Le Cuirot
I could not see eutils.eclass being used anywhere but multilib.eclass
is needed for get_libdir. I will fix implicit use of eutils by
libgdiplus for prune_libtool_files.

Signed-off-by: James Le Cuirot 
---
 eclass/dotnet.eclass | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/eclass/dotnet.eclass b/eclass/dotnet.eclass
index 3e834835b971..55e10645deb7 100644
--- a/eclass/dotnet.eclass
+++ b/eclass/dotnet.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: dotnet.eclass
@@ -12,19 +12,21 @@
 # of dotnet packages.
 
 case ${EAPI:-0} in
-   0) die "this eclass doesn't support EAPI 0" ;;
-   1|2|3) ;;
-   *) ;; #if [[ ${USE_DOTNET} ]]; then REQUIRED_USE="|| (${USE_DOTNET})"; 
fi;;
+   0)
+   die "this eclass doesn't support EAPI 0" ;;
+   [1-6])
+   inherit eapi7-ver multilib
+   DEPEND="dev-lang/mono" ;;
+   *)
+   BDEPEND="dev-lang/mono" ;;
 esac
 
-inherit eutils versionator mono-env
+inherit mono-env
 
 # @ECLASS-VARIABLE: USE_DOTNET
 # @DESCRIPTION:
 # Use flags added to IUSE
 
-DEPEND+=" dev-lang/mono"
-
 # SET default use flags according on DOTNET_TARGETS
 for x in ${USE_DOTNET}; do
case ${x} in
@@ -51,7 +53,7 @@ dotnet_pkg_setup() {
FRAMEWORK="${F}";
fi
else
-   version_is_at_least "${F}" "${FRAMEWORK}" || 
FRAMEWORK="${F}"
+   ver_test "${F}" -le "${FRAMEWORK}" || FRAMEWORK="${F}"
fi
done
if [[ -z ${FRAMEWORK} ]]; then
-- 
2.24.1




Re: [gentoo-dev] Packages up for grabs due to creffett's inactivity

2019-11-30 Thread James Le Cuirot
On Fri, 29 Nov 2019 10:37:45 +0100
Michał Górny  wrote:

> games-roguelike/dwarf-fortress

Games team can absorb this one. It's simple enough.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAtNKR1rcRC.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs due to alonbl's inactivity

2019-11-30 Thread James Le Cuirot
On Fri, 29 Nov 2019 10:21:44 +0100
Michał Górny  wrote:

> [  ] net-firewall/firehol

I'll take this as I use it a lot.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpFkRMcYhN7W.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread James Le Cuirot
On 4 November 2019 07:57:58 GMT, Tomas Mozes  wrote:
>On Mon, Nov 4, 2019 at 4:50 AM Joonas Niilola 
>wrote:
>
>>
>> On 11/4/19 1:37 AM, William Breathitt Gray wrote:
>> > Hello,
>> >
>> > `games-action/minetest` creates a "minetest" user and group with
>random
>> > respective IDs, used for running the Minetest server daemon. The
>latest
>> > version bump PR (https://github.com/gentoo/gentoo/pull/13272)
>follows
>> > GLEP 81 by creating acct-{group,user}/minetest with 481 assigned as
>> > their respective IDs.
>> >
>> > Is this assignment all right?
>> >
>> > Thank you,
>> >
>> > William Breathitt Gray
>> >
>>
>> Hey,
>>
>>
>> 481 was already requested for mongodb.
>>
>>
>>
>https://archives.gentoo.org/gentoo-dev/message/b981a29d9ade23d10663f0c0ae850044
>>
>>
>> -- juippis
>>
>>
>Sorry, I haven't seen this UID/GID in the ML so I used it, haven't
>checked
>the PRs on github. Next time, please send a mail to the ML along with
>the
>PR creation.
>
>Thanks,
>Tomas

He did but he wasn't subscribed to the list at the time so the message was 
dropped. No harm done.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-dev] [RFC] News Item: Desktop profile switching USE default to elogind

2019-10-29 Thread James Le Cuirot
On Tue, 29 Oct 2019 11:23:20 -0700
Patrick McLean  wrote:

> On Tue, 29 Oct 2019 16:10:37 +0100
> Andreas Sturmlechner  wrote:
> 
> > 
> > Anyone else who thinks this should not be restricted to just desktop
> > profiles?  
> 
> I am not aware of any use cases for elogind/consolekit on servers, it's
> really for machines where you have to distinguish between someone
> connecting remotely and someone physically using a keyboard/mouse
> connected to the machine.

I switched from consolekit to elogind on my normally headless ARM box.
It runs XMMS2 and outputs through PulseAudio. Under consolekit, my
user's /var/run directory would disappear after a while, taking the
pulse socket with it. Under elogind, I was able to set my user to
"linger", which fixed the issue. It's not a typical use case but yeah,
they do have uses outside of desktop.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpJH8of6r7gP.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] separate /usr without initramfs

2019-10-27 Thread James Le Cuirot
On Sun, 27 Oct 2019 16:17:04 +
Michael Everitt  wrote:

> On 27/10/19 16:12, Matt Turner wrote:
> > On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot  wrote:  
> >> On Sun, 27 Oct 2019 05:38:48 -0400
> >> Joshua Kinard  wrote:
> >>  
> >>> Why do I not like an initramfs, though?  Well, for one, it complicates the
> >>> kernel compiles (and it makes them bigger, something which is an issue on
> >>> the old SGI systems at times).  Two, it's another layer that I have to
> >>> maintain.  Three, it violates, in my mind, the simplicity of keeping the
> >>> kernel and userland separated (e.g., kernel does kernel-y things, userland
> >>> does userland-y things).  
> >> You make it sound like the initramfs has to be built into the kernel
> >> image. It can be but it usually isn't. I suspect you know that though?
> >> Admittedly that does depend on support from your bootloader. While GRUB
> >> and U-Boot have supported this for years, I forget what oddball
> >> bootloaders your hardware may be using.  
> > Though he's likely not using it, GRUB2 supports all the platforms he
> > mentioned (x86, amd64, sparc64, [sgi] mips).
> >  
> FWIW, I do believe I saw LILO mentioned ..

https://wiki.gentoo.org/wiki/Early_Userspace_Mounting#Configuring_LILO

Phew. ;-)

Actually I was getting confused between initramfs support and device
tree support. I think every bootloader has supported initramfs since
forever.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpeQjlpCJruZ.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 2/3] virtual/cargo: drop virtual

2019-10-27 Thread James Le Cuirot
On Sun, 27 Oct 2019 01:42:48 +
Michael Everitt  wrote:

> > I agree that some rebuilds might be unnecessary, but if you don't like
> > compiling/building software Gentoo isn't for you.
> >
> > William
> >  
> There's a subtle difference between compiling for compiling's sake, and
> compiling with good reason .. especially for those who don't have copious
> quantities of free cpu resources at their disposal 24/7/365 ... just sayin' 
> ...
> 
> And not everyone is using rust, go, java and systemd as their prime movers,
> even if you are .. *shudders*

You do know that Rust code takes an age to compile, right? :P

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpCbzezD2Qtw.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] separate /usr without initramfs

2019-10-27 Thread James Le Cuirot
On Sun, 27 Oct 2019 05:38:48 -0400
Joshua Kinard  wrote:

> Why do I not like an initramfs, though?  Well, for one, it complicates the
> kernel compiles (and it makes them bigger, something which is an issue on
> the old SGI systems at times).  Two, it's another layer that I have to
> maintain.  Three, it violates, in my mind, the simplicity of keeping the
> kernel and userland separated (e.g., kernel does kernel-y things, userland
> does userland-y things).

You make it sound like the initramfs has to be built into the kernel
image. It can be but it usually isn't. I suspect you know that though?
Admittedly that does depend on support from your bootloader. While GRUB
and U-Boot have supported this for years, I forget what oddball
bootloaders your hardware may be using.

> Maybe I'm just a old codger who refuses to accept change.  I'm fine with
> that description.  I like things to remain somewhat simple, and my view of
> Linux, both kernel and userland, over the last few years is one of growing
> dismay due to the constant introduction of subsystem layer atop subsystem
> layer for very little gain.  How much longer until we need a kernel to boot
> the kernel to mount the userland that mounts the userland (yo dawg)?

Isn't that what the BIOS and bootloader do? On the plus side, you can
now boot straight from UEFI to kernel without a bootloader but on the
other hand, UEFI is horrifically over-complex.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpO0JiOpKI14.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] cdrom.eclass vs KEYWORDS

2019-09-25 Thread James Le Cuirot
On Wed, 25 Sep 2019 22:14:36 +0200
Michał Górny  wrote:

> Hi,
> 
> I'm wondering if we're doing the right things by adding KEYWORDS to
> packages using cdrom.eclass.  After all, it's somewhat similar to live
> ebuilds.  That is, data is fetched outside regular PM mechanisms (though
> not implicitly through Internet, arguably) and it is not covered by any
> checksums.
> 
> This creates a somewhat gaping security hole to anyone using those
> packages.  After all, the ebuilds are going to happily install any
> malware you might have on that CD without even thinking twice about it. 
> In fact, with construction of many ebuilds it is entirely plausible that
> additional unexpected files may end up being installed.

Let's be realistic. If the CDs being used are pirated copies of dubious
origin then you deserve what you get. We're otherwise talking a
read-only medium that's generally been pressed in a factory. In the
highly unlikely event that there is malware present, it would probably
be for ancient versions of Windows or even MS-DOS. We usually only copy
off the data files anyhow. I have never seen any ebuilds for games that
run under Wine. I have considered adding some for games that run under
DOSBox but that is effectively sandboxed.

> To be honest, I don't think this is a problem that could be fixed. 
> Technically, we could add some kind of, say, b2sum lists to ebuilds
> and verify installed files against them.  However, the way I understand
> we frequently aim to support different releases of the same product,
> that may have wildly differing checksums.

When CDs were popular, different variants sometimes resulted in strange
bugs where it was not initially obvious what the cause was. Knowing
exactly what CD we're dealing with would be useful but on the other
hand, you'd probably have to read the whole CD for it to be effective,
which would take ages and may cause issues due to scratches and such.

> So maybe the most obvious solution would be to remove KEYWORDS from
> ebuilds unconditionally using cdrom.eclass (and their reverse
> dependencies), and mask USE=cdinstall on the rest.

Certainly only the unconditional case because the conditional case
would be a pain. In addition to what I've said above, you have to weigh
this up against the miniscule number of people who actually use them
these days, though I guess that could be taken as for or against. I
still like to support them but even I have many of the same games on
GOG now. As you know, I'd like to have GOG better supported but that's
another story.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpAfu3582cPx.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: games-action/minetest_game

2019-09-19 Thread James Le Cuirot
# James Le Cuirot  (2019-09-19)
# Minetest Game is now installed and managed through the Minetest
# engine in games-action/minetest. Removal in 30 days.
games-action/minetest_game

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpiSseDS9CMI.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags

2019-09-11 Thread James Le Cuirot
On Tue, 10 Sep 2019 22:44:54 +0200
Michał Górny  wrote:

> Hi, everyone.
> 
> I've recently (finally!) started adding tests to cpuid2cpuflags.  Tests
> are based on mocked syscalls that return arch-specific data read from
> text files.  So far I've got x86 and ppc covered, and now I'd like to
> add tests for various arm hardware.  Since ARM covers a pretty broad
> range of hardware, I'd use as much data as possible, especially from
> different ARM generations.
> 
> If you have an ARM board and would like to help, please:

From my CompuLab Utilite Pro:

$ ./hwcap-dump
hwcap:0008b0d6
hwcap2:

$ ./cpuid2cpuflags 
CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfp-d32 v4 v5 v6 v7 thumb2

$ uname -a
Linux utilite 5.2.7-7-g4559111aee7b #100 SMP PREEMPT Wed Aug 7 23:24:36 BST 
2019 armv7l ARMv7 Processor rev 10 (v7l) Freescale i.MX6 Quad/DualLite (Device 
Tree) GNU/Linux

$ cat /proc/cpuinfo
...

processor   : 3
model name  : ARMv7 Processor rev 10 (v7l)
BogoMIPS: 6.00
Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part: 0xc09
CPU revision: 10

Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
Revision: 
Serial  : 0000

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpA6ft58l2jh.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

2019-09-05 Thread James Le Cuirot
On Fri, 6 Sep 2019 07:26:42 +1200
Kent Fredric  wrote:

> On Thu, 5 Sep 2019 09:04:23 -0500
> Gordon Pettey  wrote:
> 
> > You'll note the bit you quoted in defense of skipping review says
> > "changes", and the bit about new eclasses says "do not skip this step".  
> 
> Emphasis added:
> 
> -
> BEFORE committing a NEW eclass to the tree, it SHOULD be emailed to the
> gentoo-dev mailing list with a justification and a proposed
> implementation. DO NOT SKIP this step — sometimes a better
> implementation or an alternative which does not require a new eclass
> will be suggested. 
> -
> 
> 
> If its mandatory, it must say "MUST" not "SHOULD", SHOULD is a
> suggestion, following a suggestion with an imperative just adds
> predictable confusion.
> 
> Either fix the "should", or drop the "DO NOT SKIP".
> 
> Otherwise you're just giving mixed messages.

+1

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpJgXWi9pLeE.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread James Le Cuirot
On Sat, 31 Aug 2019 10:03:47 +0200
Michał Górny  wrote:

> dev-games/flinker

This builds and starts on amd64 but I'm dubious about whether it would
work correctly in practise. I don't imagine anyone will want to use it.
Best just let it die.

> dev-games/gtkradiant

This has been superseded a few times over and the current fork is
NetRadiant-custom. There is an open bug about the older NetRadiant but
I only dabbled in Quake mapping so never cared enough.

https://bugs.gentoo.org/352981

> dev-games/hlsdk

This is a remnant of the Half-Life server stuff that vapier removed in
2005 with the message "valve sucks at linux". I could say more about it
but nobody cares.

> games-action/battalion
> games-action/fakk2
> games-action/postalplus
> games-arcade/epiar
> games-arcade/gunocide2ex
> games-emulation/mekanix
> games-fps/aaut
> games-fps/industri
> games-fps/red-blue-quake2
> games-fps/tenebrae
> games-fps/tribes2
> games-fps/unreal-tournament-strikeforce
> games-fps/ut2003-bonuspack-cm
> games-fps/ut2003-bonuspack-de
> games-fps/ut2003-bonuspack-epic
> games-fps/wolfgl
> games-misc/c++robots
> games-roguelike/hengband
> games-server/bf1942-lnxded
> games-server/mtavc
> games-strategy/mindrover-demo
> games-strategy/netpanzer

I'll try to look through some of these. I still care about UT and even
worked on (but didn't finish) a new UT99 ebuild not so long ago.
Unfortunately it's never been a top priority.

> sys-fs/atari-fdisk

This is still usable on m68k, which is the Atari's own architecture.
The code assumes 32-bit longs so it won't work on 64-bit but it
probably wouldn't be that hard to fix if someone cared enough. I'm
interested in m68k but for the Amiga rather than the Atari. I'm not
sure how useful this is in practise. On the Amiga, I would still use
the AmigaOS partitioning tool over something like this. There is no
replacement for the Atari on Linux as far as I can see though so I
think it should stay.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp9QsRuUlfe4.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Packages up for grabs: app-misc/hello, sys-libs/libudev-compat

2019-08-18 Thread James Le Cuirot
On Sun, 18 Aug 2019 14:32:28 +0200
Michał Górny  wrote:

> Due to the retirement of their only maintainer, the following packages
> are now up for grabs:
> 
> app-misc/hello
> sys-libs/libudev-compat

I'll take sys-libs/libudev-compat.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpoZZeJDkY_V.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 2/2] perl-module.class: Enable EAPI=7 support

2019-08-14 Thread James Le Cuirot
On Wed, 14 Aug 2019 11:42:16 +1200
Kent Fredric  wrote:

> On Tue, 13 Aug 2019 20:39:01 +0100
> James Le Cuirot  wrote:
> 
> > Unfortunately there's currently no way to say that the versions of a
> > package across BDEPEND, DEPEND, and RDEPEND must be (roughly?) equal so
> > there's nothing to stop an ancient Perl in / building a module for a
> > newer Perl in ROOT but that's a problem that goes far beyond Perl.
> > Cross-compiling Perl modules is still a bit of a car crash anyway.  
> 
> I'd imagine that for CC, you'd need all perl modules installed to
> BDEPEND _and_ DEPEND _AND_ RDEPEND,
> 
> Because the configure stage runs Makefile.PL on the host perl, and it
> checks the existence of all "runtime" and "compile time" dependencies
> itself, and it does this by *loading* them into the host perl.
> 
> Failure to load them on the host perl produces lots of warnings in the
> best of cases, and errors in the worst of cases.

Yes, I thought that was probably the case. Python is more forgiving in
this regard.

When trying to solve this problem in cross-boss, I found that
Makefile-based modules would usually build if you ran Perl through QEMU
during src_configure and ran Make with some tweaked variables during
src_compile and src_install but this is extremely hacky.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppqvcDDOp1z.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 2/2] perl-module.class: Enable EAPI=7 support

2019-08-13 Thread James Le Cuirot
On Wed, 14 Aug 2019 03:43:12 +1200
ken...@gentoo.org wrote:

> From: Andreas K. Hüttel 
> 
> Signed-off-by: Andreas K. Hüttel 
> ---
>  eclass/perl-module.eclass | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/eclass/perl-module.eclass b/eclass/perl-module.eclass
> index 20b9947caca..81f79992d76 100644
> --- a/eclass/perl-module.eclass
> +++ b/eclass/perl-module.eclass
> @@ -44,61 +44,61 @@ esac
>  case ${EAPI:-0} in
>   5)
>   [[ ${CATEGORY} == perl-core ]] && \
>   PERL_EXPF+=" pkg_postinst pkg_postrm"
>  
>   case "${GENTOO_DEPEND_ON_PERL:-yes}" in
>   yes)
>   case "${GENTOO_DEPEND_ON_PERL_SUBSLOT:-yes}" in
>   yes)
>   DEPEND="dev-lang/perl:=[-build(-)]"
>   ;;
>   *)
>   DEPEND="dev-lang/perl[-build(-)]"
>   ;;
>   esac
>   RDEPEND="${DEPEND}"
>   ;;
>   esac
>  
>   case "${PERL_EXPORT_PHASE_FUNCTIONS:-yes}" in
>   yes)
>   EXPORT_FUNCTIONS ${PERL_EXPF}
>   ;;
>   no)
>   debug-print "PERL_EXPORT_PHASE_FUNCTIONS=no"
>   ;;
>   *)
>   die 
> "PERL_EXPORT_PHASE_FUNCTIONS=${PERL_EXPORT_PHASE_FUNCTIONS} is not supported 
> by perl-module.eclass"
>   ;;
>   esac
>   ;;
> - 6)
> + 6|7)
>   [[ ${CATEGORY} == perl-core ]] && \
>   PERL_EXPF+=" pkg_postinst pkg_postrm"
>  
>   case "${GENTOO_DEPEND_ON_PERL:-yes}" in
>   yes)
>   DEPEND="dev-lang/perl:="
>   RDEPEND="dev-lang/perl:="
>   ;;
>   noslotop)
>   DEPEND="dev-lang/perl"
>   RDEPEND="dev-lang/perl"
>   ;;
>   esac
>  
>   if [[ "${GENTOO_DEPEND_ON_PERL_SUBSLOT:-yes}" != "yes" ]]; then
> - eerror "GENTOO_DEPEND_ON_PERL_SUBSLOT=no is banned in 
> EAPI=6. If you don't want a slot operator"
> + eerror "GENTOO_DEPEND_ON_PERL_SUBSLOT=no is banned in 
> EAPI=6 and later. If you don't want a slot operator"
>   die"set GENTOO_DEPEND_ON_PERL=noslotop instead."
>   fi
>  
>   if [[ "${PERL_EXPORT_PHASE_FUNCTIONS}" ]]; then
> - eerror "PERL_EXPORT_PHASE_FUNCTIONS is banned in 
> EAPI=6. Use perl-module.eclass if you need"
> + eerror "PERL_EXPORT_PHASE_FUNCTIONS is banned in EAPI=6 
> and later. Use perl-module.eclass if you need"
>   die"phase functions, perl-functions.eclass if not."
>   fi
>  
>   EXPORT_FUNCTIONS ${PERL_EXPF}
>   ;;
>   *)
>   die "EAPI=${EAPI:-0} is not supported by perl-module.eclass"
>   ;;

First off, I don't think the SLOT operator in DEPEND actually does
anything? I believe it's only meaningful for RDEPEND?

Apart from that, I would say that dev-lang/perl should go in BDEPEND
too, again without the SLOT operator. You need to execute Perl to build
Perl modules, right? Whether it's also needed in DEPEND is a little
more nuanced. For modules including native code, yes definitely. For
others, maybe not but it's not worth complicating things here.

Unfortunately there's currently no way to say that the versions of a
package across BDEPEND, DEPEND, and RDEPEND must be (roughly?) equal so
there's nothing to stop an ancient Perl in / building a module for a
newer Perl in ROOT but that's a problem that goes far beyond Perl.
Cross-compiling Perl modules is still a bit of a car crash anyway.

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpKWUALqcWLE.pgp
Description: OpenPGP digital signature


[gentoo-portage-dev] [PATCH] Allow ESYSROOT and BROOT in the pkg_setup phase

2019-08-11 Thread James Le Cuirot
From: Michał Górny 

This follows a recent change to PMS.

Signed-off-by: James Le Cuirot 
---
 lib/portage/package/ebuild/config.py | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

Sending this on behalf of mgorny as requested.

diff --git a/lib/portage/package/ebuild/config.py 
b/lib/portage/package/ebuild/config.py
index 83a15b370..e0dda54d4 100644
--- a/lib/portage/package/ebuild/config.py
+++ b/lib/portage/package/ebuild/config.py
@@ -2820,12 +2820,13 @@ class config(object):
if not eapi_exports_merge_type(eapi):
mydict.pop("MERGE_TYPE", None)
 
-   src_phase = _phase_func_map.get(phase, '').startswith('src_')
+   src_like_phase = (phase == 'setup' or
+   _phase_func_map.get(phase, 
'').startswith('src_'))
 
-   if not (src_phase and eapi_attrs.sysroot):
+   if not (src_like_phase and eapi_attrs.sysroot):
mydict.pop("ESYSROOT", None)
 
-   if not (src_phase and eapi_attrs.broot):
+   if not (src_like_phase and eapi_attrs.broot):
mydict.pop("BROOT", None)
 
# Prefix variables are supported beginning with EAPI 3, or when
-- 
2.21.0




Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-08-02 Thread James Le Cuirot
PREFIX but
I can't think of any legitimate reason to do that.

I should add that your example is not a case we readily support.
Although we've broken down many of the barriers, native builds where
SYSROOT!=/ tend to blow up. If / is up to date and configured
similarly, you might get away with it. If glibc is older then binaries
that have just been built will fail to run at build time. If other
libraries have different sonames then binaries needing them will also
fail to run at build time. This isn't a problem when cross-compiling
because you can never run those binaries anyway! For native builds, it
is far simpler to just build in a chroot instead.

Any better?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpKOGM4rJ5x1.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread James Le Cuirot
On Tue, 30 Jul 2019 23:50:21 +0800
Benda Xu  wrote:

> > A check was added to Portage to ensure this held. Myself, the
> > ChromiumOS team, and others have since been caught out by this check
> > when trying to bootstrap brand new systems from scratch. You cannot
> > bootstrap with no headers at all! The check will therefore be adjusted
> > to merely ensure that SYSROOT is / when ROOT is /.  
> 
> It is very encouraging to see contributions from the ChromiumOS team to
> Gentoo!

Don't read too much into that. ;) I can't recall how I became aware of
it but I saw a patch that ChromiumOS had made against Portage to remove
the check I had added. No doubt it had caught them out in the same way.

> > What if we want to bootstrap a brand new prefixed system using the
> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The
> > problem is that there is no distinct variable for SYSROOT's prefix
> > and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
> > therefore cannot do it! If the crossdev prefix is blank then ROOT's
> > must be blank too.  
> 
> My question: is there a case when both SYSROOT and ESYSROOT are needed?
> As far as I can see, SYSROOT is strictly build-time. Therefore setting
> SYSROOT= would be enough for all.
> 
> Why did ESYSROOT exist in the first place?  Was it only for the sake of
> symmetry, or did I miss something?

Remember that we now install packages to SYSROOT too. Portage needs to
know the prefix so that it can set EPREFIX when building these
packages. You'll already know that you can't fake EPREFIX by setting
ROOT. We could potentially work out EPREFIX by comparing SYSROOT with
BROOT and EROOT (instead of / and ROOT) but that's not the whole story.

When using crossdev, pkg-config files are sourced from SYSROOT. These
may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then
pkg-config will need to translate this to -L/myroot/myprefix/usr/lib.
However, it's bad to explicitly add lib and include paths that the
toolchain would look at anyway as it can change the search order. Under
a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for
this to work in the above setup, we need to know that /myprefix is a
prefix. As stated, we don't have an explicit variable for SYSROOT's
prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is
what I have done in my pending cross-pkg-config fixes.

None of that magic happens when not using crossdev. I have debated
whether it should but native builds with SYSROOT!=/ tend to be a
disaster for various other reasons so perhaps it's not worth worrying
about.

There are probably more reasons when we need to know the prefix but I
can't remember what they are now. :)

> In conclusion, IMHO, if SYSROOT can be overridden without restriction
> ("distinct" in your email), we could cover all the use cases.

It's still a little bit restricted but less than it was and the only
cases we don't handle are obscure ones that we wouldn't want to support
anyway.

When dealing with this stuff, it's worth remembering that practically no
one has used crossdev with prefix until recently. I know this because
I had to fix the glibc ebuild, Portage, and crossdev itself to make it
work following a bug report this month. ;)

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpLWWBo9OyxR.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread James Le Cuirot
On Wed, 31 Jul 2019 21:40:19 +0100
James Le Cuirot  wrote:

> So why does ROOT affect it? Normally you install the packages for
> BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
> RDEPEND are installed to different locations (ROOT!=/) then DEPEND will
> almost always be installed to one of the other two. If either of those
> two locations is prefixed then we need the prefix for DEPEND's location
> to match, otherwise it wouldn't actually be the same location. Using
> ROOT allows us to figure this out automatically in a way that covers
> all sensible use cases and avoids accidentally falling into an
> unsupported case.

Just to clarify this in the binpkg case, here you would normally
install BDEPEND, DEPEND, and usually RDEPEND to / on your build
machine. On your other machines, you usually only care about RDEPEND.
If you care about BDEPEND and DEPEND too then you'll need to use the
same prefix everywhere but that's nothing new. You'd be pretty crazy to
use different prefixes in this kind of environment anyway.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpwVGu6zJELp.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread James Le Cuirot
On Wed, 31 Jul 2019 15:51:58 +0200
Alexis Ballier  wrote:

> On Tue, 30 Jul 2019 23:26:27 +0100
> James Le Cuirot  wrote:
> 
> > > Admittedly without a full understanding of the problem, but this
> > > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in
> > > build phases (src_*); (EPREFIX is a little special here but mostly
> > > for convenience). ROOT is only relevant in pkg_* phases. I don't
> > > see how this can work. Say I build a binpkg with ROOT=/ then use
> > > that binpkg with ROOT=/somewhere, you can't go back and change
> > > SYSROOT.  
> > 
> > ROOT is used to determine ESYSROOT, not the other way around. As you
> > say, (E)SYSROOT is only relevant in src phases so it doesn't matter if
> > ROOT has changed when installing a binpkg.  
> 
> I am missing something here: You are making ESYSROOT depend on the
> value of ROOT, so how can it not matter ?

What I am trying to say (somewhat unsuccessfully!) is that the value of
(E)SYSROOT only changes how the package is built, not what the
resulting package looks like. It's where all the headers and libraries
are sourced from at build time, which is irrelevant at runtime.

So why does ROOT affect it? Normally you install the packages for
BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
RDEPEND are installed to different locations (ROOT!=/) then DEPEND will
almost always be installed to one of the other two. If either of those
two locations is prefixed then we need the prefix for DEPEND's location
to match, otherwise it wouldn't actually be the same location. Using
ROOT allows us to figure this out automatically in a way that covers
all sensible use cases and avoids accidentally falling into an
unsupported case.

I hope that's clearer.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp7vt5Id1Dzh.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-30 Thread James Le Cuirot
On Mon, 29 Jul 2019 14:05:10 +0200
Alexis Ballier  wrote:

> There seems to be unneeded whitespace only changes here that make the
> diff less readable

Sorry about that. I've only changed one cell in that table.

> Admittedly without a full understanding of the problem, but this looks
> wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in build
> phases (src_*); (EPREFIX is a little special here but mostly for
> convenience). ROOT is only relevant in pkg_* phases. I don't see how
> this can work. Say I build a binpkg with ROOT=/ then use that binpkg
> with ROOT=/somewhere, you can't go back and change SYSROOT.

ROOT is used to determine ESYSROOT, not the other way around. As you
say, (E)SYSROOT is only relevant in src phases so it doesn't matter if
ROOT has changed when installing a binpkg.

I take your point that setting a src phase variable based on a pkg
phase variable seems odd but we're only using ROOT to determine the
applicable prefix. We're not taking the actual value of ROOT. When
Portage works all this out, it has access to all the necessary
variables. It only filters the variables based on the phase function
later on.

> Also, I think the wording could be more "programmatic" (if ... then
> ESYSROOT is ... else ... ) to avoid confusion.

Given that there are three clauses, I thought that using "respectively"
would be shorter and clearer but I'll try some other wording to see how
it looks.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpHV_CFv44RS.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-28 Thread James Le Cuirot
It was originally envisaged (but not stated in PMS) that SYSROOT would
only ever need to equal / or ROOT as a distinct SYSROOT would have no
benefit. A check was added to Portage to ensure this held. Myself, the
ChromiumOS team, and others have since been caught out by this check
when trying to bootstrap brand new systems from scratch. You cannot
bootstrap with no headers at all! The check will therefore be adjusted
to merely ensure that SYSROOT is / when ROOT is /.

There were differing assumptions about how prefixes applied to the
above. EPREFIX is traditionally something the user sets so some
thought that it would be applied to SYSROOT, regardless of the
latter's value. In order to honor the rule about there being no
distinct SYSROOT, this would mean that if SYSROOT is / then EPREFIX
would have to match BROOT. Despite that limitation, ESYSROOT was
written into PMS with a fixed value of ${SYSROOT}${EPREFIX}. Being
somewhat unfamiliar with prefix at the time, I didn't realise that
this view didn't align with what I'd had in mind and it was only when
I came to need a distinct SYSROOT that I realised there was a problem.

crossdev toolchains are installed to ${EPREFIX}/usr/${CHOST} but have
no further prefix appended and packages subsequently installed with
cross-emerge are placed in this location by setting ROOT. Bug #642604
recently revealed that the build system's prefix was being erroneously
duplicated on the end but I have now fixed this.

What if we want to bootstrap a brand new prefixed system using the
crossdev system as SYSROOT? This is the distinct SYSROOT case. The
problem is that there is no distinct variable for SYSROOT's prefix
and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
therefore cannot do it! If the crossdev prefix is blank then ROOT's
must be blank too.

I also never intended to have the aforementioned limitation where
EPREFIX must match BROOT when SYSROOT is /. These are both entirely
artificial restrictions.

So how should it work instead? We originally intended for SYSROOT to
equal either / or ROOT so I imagined the prefix would automatically be
adjusted to match the prefix applicable at the matching location,
namely BROOT or EPREFIX. This is obviously more flexible than forcing
it to match EPREFIX.

What about the distinct SYSROOT case? With no distinct variable, we
have no way to explicitly set a prefix but this is likely only needed
when bootstrapping against crossdev systems, which are unprefixed by
nature. We therefore simply assume that the prefix is blank in this
case.

What about the cross-prefix case? Here, SYSROOT matches both / and
ROOT so which prefix do we choose? The bootstrap-prefix.sh script sets
flags to build against the target prefix so EPREFIX is used in this
case. This happens to fit the current definition of ESYSROOT anyway.

Legitimate concerns have been raised about building for a system with
a different prefix to the one you're building against. The only
binaries that leak from SYSROOT to ROOT are static libraries. Headers
from SYSROOT will obviously also influence how ROOT's binaries are
built. It is entirely possible that SYSROOT's prefix may leak through
a header but grepping /usr/include on my own main system reveals only
a few paths from a small handful of packages. pkg-config files
invariably include paths but these are almost always used at build
time, not runtime. A differing prefix would likely only occur in cases
involving core packages like the libc and kernel headers anyway. Also
consider that we have never prevented this from happening in the
past. It has always been possible to do "EPREFIX=/foo emerge bar" from
some system with a different prefix or no prefix at all. All we're
doing here is including the prefix (if any) in the ESYSROOT variable.

Should this warrant a new EAPI? I don't think so. All existing usage
of ESYSROOT that I have seen still fits with this new definition and
most of that usage has come from me. We're not even changing what the
variable is used for, just loosening the constraints around what it
can be set to.

If you have doubts about whether this makes sense or actually works in
practise, I have experimented with a prefixed system using all the
different combinations I could think of, including cross-compiling,
and it all worked as expected. Keep in mind that ESYSROOT is not magic
and currently isn't used very much. As such, neither the toolchain nor
pkg-config will use this sysroot if you don't explicitly tell them
to. For the former, I find CC="${CHOST}-gcc --sysroot=${ESYSROOT}"
works well. For the latter, crossdev installs a cross-pkg-config
wrapper but it is completely lacking prefix support at the moment. I
have fixes waiting on this change.

Signed-off-by: James Le Cuirot 
---
 dependencies.tex| 24 ++--
 ebuild-env-vars.tex |  7 ---
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/dependencies.tex b/dependencies.tex
index 443

Re: [gentoo-dev] [PATCH] cdrom.eclass: Append to PROPERTIES variable.

2019-07-26 Thread James Le Cuirot
On Sat, 27 Jul 2019 00:25:21 +0200
Ulrich Müller  wrote:

> It is not accumulated across eclasses.
> 
> Signed-off-by: Ulrich Müller 
> ---
>  eclass/cdrom.eclass | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cdrom.eclass b/eclass/cdrom.eclass
> index 7b0eb9c6c3b5..77b9d6ceb209 100644
> --- a/eclass/cdrom.eclass
> +++ b/eclass/cdrom.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2017 Gentoo Foundation
> +# Copyright 1999-2019 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: cdrom.eclass
> @@ -28,9 +28,9 @@ inherit portability
>  # conditionally based on USE="cdinstall".
>  if [[ ${CDROM_OPTIONAL} == "yes" ]] ; then
>   IUSE="cdinstall"
> - PROPERTIES="cdinstall? ( interactive )"
> + PROPERTIES+=" cdinstall? ( interactive )"
>  else
> - PROPERTIES="interactive"
> + PROPERTIES+=" interactive"
>  fi
>  
>  # @FUNCTION: cdrom_get_cds

Ack, although shouldn't this variable be made to do that? Or perhaps
that's a PMS change?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpVWeHuCzFJw.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: games-kids/pytraffic and games-misc/yadex

2019-06-18 Thread James Le Cuirot
# James Le Cuirot  (18 Jun 2019)
# Web site and SRC_URI dead. Has required heavy patching. Superseded
# by games-util/deutex. Removal in 30 days.
games-misc/yadex

# James Le Cuirot  (18 Jun 2019)
# Web site and SRC_URI dead. Last release in 2007. Removal in 30
# days. See bug #688134.
games-kids/pytraffic

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpNjbEk0P1KF.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND

2019-06-13 Thread James Le Cuirot
On Thu, 13 Jun 2019 15:02:23 +0200
Michael Haubenwallner  wrote:

> On 6/13/19 2:45 PM, James Le Cuirot wrote:
> > On Thu, 13 Jun 2019 13:08:15 +0200
> > Michael Haubenwallner  wrote:
> > 
> >> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
> >> Also, unset variable 'arch' after use.
> >> ---
> >>  eclass/xorg-3.eclass | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
> >> index 6ac90a64d59..f135058fba6 100644
> >> --- a/eclass/xorg-3.eclass
> >> +++ b/eclass/xorg-3.eclass
> >> @@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
> >>  for arch in ${XORG_EAUTORECONF_ARCHES}; do
> >>EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
> >>  done
> >> -DEPEND+=" ${EAUTORECONF_DEPENDS}"
> >> +unset arch
> >> +BDEPEND+=" ${EAUTORECONF_DEPENDS}"
> >>  [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
> >>  unset EAUTORECONF_DEPENDS
> >>  unset EAUTORECONF_DEPEND
> > 
> > Apart from the unset, the comment doesn't seem to relate to the actual
> > change?
> 
> Agreed: The relation should become clear with 15 lines of context.
> Or do you mean something else?

Okay, I get it now. I was also slightly confused by the very similar
variable names.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpI9AKyjHgoG.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] xorg-3.eclass: EAUTORECONF_DEPENDS belong to BDEPEND

2019-06-13 Thread James Le Cuirot
On Thu, 13 Jun 2019 13:08:15 +0200
Michael Haubenwallner  wrote:

> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
> Also, unset variable 'arch' after use.
> ---
>  eclass/xorg-3.eclass | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
> index 6ac90a64d59..f135058fba6 100644
> --- a/eclass/xorg-3.eclass
> +++ b/eclass/xorg-3.eclass
> @@ -116,7 +116,8 @@ WANT_AUTOMAKE="latest"
>  for arch in ${XORG_EAUTORECONF_ARCHES}; do
>   EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
>  done
> -DEPEND+=" ${EAUTORECONF_DEPENDS}"
> +unset arch
> +BDEPEND+=" ${EAUTORECONF_DEPENDS}"
>  [[ ${XORG_EAUTORECONF} != no ]] && BDEPEND+=" ${EAUTORECONF_DEPEND}"
>  unset EAUTORECONF_DEPENDS
>  unset EAUTORECONF_DEPEND

Apart from the unset, the comment doesn't seem to relate to the actual
change?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpNdvQqpsruD.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-libs/liblazy

2019-06-09 Thread James Le Cuirot
# James Le Cuirot  (9 Jun 2019)
# Dead upstream, no release since 2008, not used by anything, possibly
# doesn't work any more. Removal in 30 days.
dev-libs/liblazy

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp8rBmWRVuyS.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/9] User/group package draft implementation

2019-05-30 Thread James Le Cuirot
On Thu, 30 May 2019 14:50:30 +0200
Michał Górny  wrote:

> Please review the following patches, implementing the user/group package
> concept.  The patches incorporate some of the feedback to the proposed
> GLEP, and I'd like to get them reviewed before I submit the next GLEP
> update.  They are based on earlier work by mjo.

I like the idea and the changes look good. I gather this doesn't
address the ROOT problem. That's fine, it wasn't one of the stated
goals, I just want to keep it in mind. I still stand by what I said in
https://bugs.gentoo.org/541406#c2.

  The various tools such as useradd do have a -R option to specify a
  root directory but this performs an actual chroot, making it useless
  for non-native environments. Even if this somehow worked or if it
  were run through QEMU, it would still not be sufficient because
  Portage needs to know about these users and groups from the
  perspective of the build system.

  I believe what is needed is some way to intelligently sync the
  accounts between / and ROOT. If a user or group already exists in /
  then use the same ID in ROOT. If it doesn't already exist then create
  it in / first, ensuring that the new ID doesn't clash with one
  already in ROOT. If there is an unresolvable ID clash then error out.

If we're looking to keep all UIDs/GIDs fixed going forwards then
clashes obviously become less of an issue. Since writing the above,
I've become aware that you can bind mount individual files such
as /etc/passwd and there are also new tricks like user namespacing. We
could probably come up with something workable but this hasn't reached
the top of my pile.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp7vErIW_k0d.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 0/4] llvm.eclass: EAPI 7 support

2019-05-24 Thread James Le Cuirot
On 24 May 2019 05:59:29 BST, "Michał Górny"  wrote:
>On Tue, 2019-04-30 at 07:38 +0200, Michał Górny wrote:
>> Hi,
>> 
>> Here's my proposed EAPI 7 support for llvm.eclass.  I think it should
>> conceptually work with cross but I haven't tested it.  The main
>problem
>> is that we have multiple distinct ways of building LLVM, and AFAIU
>> when using CMake modules, you should be able to get away without
>having
>> LLVM in CBUILD.  However, when using llvm-config you obviously need
>> it CBUILD-executable.
>> 
>> To support both scenarios, get_llvm_prefix is now provided with '-b'
>> and '-d' options (matching those to has_version).  Using them, you
>can
>> choose the behavior suitable for your package.
>> 
>> I've left the default at '-d'.  I don't really know which is better
>> for the generic cross case but either way should work for non-cross
>> setups.
>> 
>> --
>> Best regards,
>> Michał Górny
>> 
>> Michał Górny (4):
>>   llvm.eclass: Remove unnecessary '_rc' from < example
>>   llvm.eclass: Update examples for newer LLVM versions
>>   llvm.eclass: Add EAPI 7 API to get_llvm_prefix
>>   llvm.eclass: Enable EAPI 7
>> 
>>  eclass/llvm.eclass | 65
>+-
>>  1 file changed, 53 insertions(+), 12 deletions(-)
>> 
>
>Merged.

I know you made the necessary change in PMS for SYSROOT to work in pkg_setup 
but I don't think it's been fixed in Portage yet?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-dev] [PATCH] */*: Make 'colord' a global USE flag

2019-05-18 Thread James Le Cuirot
On 18 May 2019 08:00:00 BST, "Michał Górny"  wrote:
>USE=colord is used in 11 packages consistently.  Make it a global USE
>flag using the description from GNOME packages, and remove redundant
>local definitions.
>
>The local definition in x11-libs/gtk+ is left as it clarifies that
>the flag applies to printing.
>
>Signed-off-by: Michał Górny 
>---
> dev-libs/weston/metadata.xml  | 1 -
> dev-util/diffoscope/metadata.xml  | 1 -
> gnome-base/gnome-control-center/metadata.xml  | 1 -
> gnome-base/gnome-settings-daemon/metadata.xml | 1 -
> gnome-extra/cinnamon-control-center/metadata.xml  | 3 ---
> gnome-extra/cinnamon-settings-daemon/metadata.xml | 3 ---
> media-gfx/darktable/metadata.xml  | 1 -
> media-gfx/gthumb/metadata.xml | 1 -
> media-gfx/simple-scan/metadata.xml| 3 ---
> profiles/use.desc | 1 +
> xfce-base/xfce4-settings/metadata.xml | 1 -
> 11 files changed, 1 insertion(+), 16 deletions(-)
>
>diff --git a/dev-libs/weston/metadata.xml
>b/dev-libs/weston/metadata.xml
>index c98075bd2fed..8e5d258810a5 100644
>--- a/dev-libs/weston/metadata.xml
>+++ b/dev-libs/weston/metadata.xml
>@@ -6,7 +6,6 @@
>   James Le Cuirot
> 
> 
>-  Allow setting color managment
>   Enable the desktop shell
>   Enable drm compositor support
>   Install wayland-editor example application
>diff --git a/dev-util/diffoscope/metadata.xml
>b/dev-util/diffoscope/metadata.xml
>index c6b5b3df2213..3899d895c5bd 100644
>--- a/dev-util/diffoscope/metadata.xml
>+++ b/dev-util/diffoscope/metadata.xml
>@@ -13,7 +13,6 @@
> 
> 
>   Use sys-devel/binutils
>-  Use x11-misc/colord
>   Use app-arch/cpio
>   Use sys-apps/diffutils
>   Use app-text/docx2txt
>diff --git a/gnome-base/gnome-control-center/metadata.xml
>b/gnome-base/gnome-control-center/metadata.xml
>index f1ac0fd9a7be..05f1acb0836a 100644
>--- a/gnome-base/gnome-control-center/metadata.xml
>+++ b/gnome-base/gnome-control-center/metadata.xml
>@@ -6,7 +6,6 @@
>   Gentoo GNOME Desktop
>   
>   
>-  Support color management using
>x11-misc/colord
>   Add support for using photos from flickr as
>desktop background
>   Enable configuration panel 
> for
>net-libs/gnome-online-accounts accounts
>   Enable support for enhanced input methods 
> through
>app-i18n/ibus
>diff --git a/gnome-base/gnome-settings-daemon/metadata.xml
>b/gnome-base/gnome-settings-daemon/metadata.xml
>index 3b84b19df418..cddf35764192 100644
>--- a/gnome-base/gnome-settings-daemon/metadata.xml
>+++ b/gnome-base/gnome-settings-daemon/metadata.xml
>@@ -6,7 +6,6 @@
>   Gentoo GNOME Desktop
>   
>   
>-  Support color management using
>x11-misc/colord
>   Rely on sys-auth/elogind as 
> runtime
>logind provider
>   Rely on sys-apps/systemd as 
> runtime
>logind provider
>   Skip systemd dependency (#480336),
>diff --git a/gnome-extra/cinnamon-control-center/metadata.xml
>b/gnome-extra/cinnamon-control-center/metadata.xml
>index dbc06458f865..64ed8e976b58 100644
>--- a/gnome-extra/cinnamon-control-center/metadata.xml
>+++ b/gnome-extra/cinnamon-control-center/metadata.xml
>@@ -5,9 +5,6 @@
>   cinna...@gentoo.org
>   Cinnamon Project
>   
>-  
>-  Support color management using
>x11-misc/colord
>-  
>   
>   type="github">linuxmint/cinnamon-control-center
>   
>diff --git a/gnome-extra/cinnamon-settings-daemon/metadata.xml
>b/gnome-extra/cinnamon-settings-daemon/metadata.xml
>index aab7fdc66a7f..da9442eb0216 100644
>--- a/gnome-extra/cinnamon-settings-daemon/metadata.xml
>+++ b/gnome-extra/cinnamon-settings-daemon/metadata.xml
>@@ -5,9 +5,6 @@
>   cinna...@gentoo.org
>   Cinnamon Project
>   
>-  
>-  Support color management using
>x11-misc/colord
>-  
>   
>   type="github">linuxmint/cinnamon-settings-daemon
>   
>diff --git a/media-gfx/darktable/metadata.xml
>b/media-gfx/darktable/metadata.xml
>index 228506baefbe..57ab6042d4e3 100644
>--- a/media-gfx/darktable/metadata.xml
>+++ b/media-gfx/darktable/metadata.xml
>@@ -6,7 +6,6 @@
>   Gentoo Graphics Project
>   
>   
>-  Support color management using
>x11-misc/colord
>   Add support for uploading photos to 
> flickr
>   Enable geotagging support
>   Enable encrypte

Re: [gentoo-dev] net-misc/r8168 up for grabs

2019-05-14 Thread James Le Cuirot
On Tue, 14 May 2019 19:55:23 +0200 (CEST)
Conrad Kostecki  wrote:

> > James Le Cuirot  hat am 9. Mai 2019 um 21:47 geschrieben:
> > I sent out this request a couple of years ago but didn't get a reply.
> > Hoping I can find someone this time before I mark it maintainer-needed.  
> 
> if you still need help, I can help with maintaining.

That would be very much appreciated. Thanks for this and all the other
great work that you do!

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp_5JhFrBbfU.pgp
Description: OpenPGP digital signature


[gentoo-dev] net-misc/r8168 up for grabs

2019-05-09 Thread James Le Cuirot
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.

I sent out this request a couple of years ago but didn't get a reply.
Hoping I can find someone this time before I mark it maintainer-needed.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpWbYXfCinGS.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread James Le Cuirot
On Thu, 25 Apr 2019 12:57:54 +0100
Marek Szuba  wrote:

> On 2019-04-24 20:34, Rich Freeman wrote:
> 
> > The only reason to have a separate primary key is to have an offline
> >  copy,  
> 
> Not quite. First and foremost, you do not want to have an offline copy
> of the primary private key - you want to have the primary ENTIRELY
> offline.

This has confused me. Granted, GLEP 63 does not say anything about
where to store the primary key but I followed the Debian guide at
https://wiki.debian.org/Subkeys, believing it to be best practise and
if I understood it correctly, it only removes the primary private key
from the online copy and not the entire primary key. The --list-keys
option shows an [SC] primary with an [E] subkey and an [S] subkey and I
gathered from a conversation in #gentoo-dev that this is correct. Are
you suggesting the [SC] primary should not appear here at all?

> Secondly, the reason for that is not (just) to have a backup
> but that the primary private key gives you virtually unlimited control.

Are you contradicting yourself here? You explained why the private key
must be kept secure but you didn't say anything about the rest of the
primary key.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpVGro7fCSWU.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] tmpfiles.eclass: fix ROOT check for EAPI 7

2019-04-25 Thread James Le Cuirot
On Thu, 25 Apr 2019 17:46:50 -0400
Mike Gilbert  wrote:

> Signed-off-by: Mike Gilbert 
> ---
>  eclass/tmpfiles.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
> index a8bb9061ec8c..f23c7c77ab07 100644
> --- a/eclass/tmpfiles.eclass
> +++ b/eclass/tmpfiles.eclass
> @@ -113,7 +113,7 @@ tmpfiles_process() {
>   [[ ${#} -gt 0 ]] || die "${FUNCNAME}: Must specify at least one 
> filename"
>  
>   # Only process tmpfiles for the currently running system
> - if [[ ${ROOT} != / ]]; then
> + if [[ ${ROOT:-/} != / ]]; then
>   ewarn "Warning: tmpfiles.d not processed on ROOT != /. If you 
> do not use"
>   ewarn "a service manager supporting tmpfiles.d, you need to run"
>       ewarn "the following command after booting (or chroot-ing with 
> all"

Ack.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpSIOLgouwE3.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

2019-04-25 Thread James Le Cuirot
On Thu, 25 Apr 2019 11:30:27 -0400
Alec Warner  wrote:

> > Seeing as separating the primary and the signing key has been part of
> > OpenPGP best practices for a long, long time, I have got highly mixed
> > feelings about this statement. On the one hand, it is not reasonable to
> > expect someone with no or minimal prior knowledge of OpenPGP to master
> > it overnight. On the other, we are not just some random people from Teh
> > Intarwebz and we *have* been using OpenPGP signatures on commits for
> > quite a while now.
> >  
> 
> This is untrue though; we *are* random people from teh interwebs.
> 
> I store my primary key on my desktop.
> I don't have copies of my primary key.
> My primary key is protected by a passphrase.
> Most of the time its cached in gpg-agent, so the passphrase is easily
> stealable by local attackers.
> I've been a dev for like > 10 years.
> 
> I assume that every other dev does the same. Obviously some do not (and
> I've spoken to many who have better practices) but I assume
> people do the lazy / easy thing and I highly recommend this assumption. If
> you assume that people have your security practices, you should prepare to
> be disappointed.
> 
> Many devs have *no idea* how GPG works.
> GPG is quite possibly the worst program I've even been forced to use in
> terms of doing any operation, particularly around setup (hmm maybe Imation
> Ironkeys were worse?)
> Many devs are just following the wiki instructions and get what they get.

I can sort of echo this. I believe I'm close to the recommendations now
but it took me several evenings to actually wrap my head around all
this and even then, I still felt very nervous setting it up and I had
to rehearse it beforehand. As a professional software engineer for many
years, it really shouldn't be this hard. People talk about GPG best
practices but it was really difficult to find a reliable update-to-date
guide and it certainly doesn't feel like best practise when you have to
manually delete ~/.gnupg/private-keys-v1.d/KEYGRIP.key, where KEYGRIP
is returned by the obscure --with-keygrip option.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpsvBE3uLuyQ.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last-rites: app-emulation/uae and app-emulation/e-uae

2019-04-20 Thread James Le Cuirot
Ancient and long dead upstream. Use app-emulation/fs-uae instead.
Removal in 30 days.

Bug: https://bugs.gentoo.org/432092
Bug: https://bugs.gentoo.org/602966

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpSRjBv1Lngu.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: dev-java/oracle-{jre,jdk}-bin

2019-04-18 Thread James Le Cuirot
On 18 April 2019 16:56:16 BST, Mike Gilbert  wrote:
>On Wed, Apr 17, 2019 at 10:44 PM Georgy Yakovlev 
>wrote:
>>
>> On Wednesday, April 17, 2019 6:31:42 PM PDT Mike Gilbert wrote:
>> > On Wed, Apr 17, 2019 at 3:35 PM Georgy Yakovlev
>
>> wrote:
>> > > # Georgy Yakovlev  (17 Apr 2019)
>> > > # The Oracle JDK License has changed for releases starting April
>16, 2019
>> > > # While it may be fine to use for some usecases it's not
>comepletely clear
>> > > # what is considered "personal use" and if we can legally
>distribute it.
>> > > # License states:
>> > > # "You may not:
>> > > # make the Programs available in any manner to any third party"
>> >
>> > I don't agree with your rationale here.
>> >
>> > Gentoo does not distribute the JDK due to RESTRICT="fetch mirror"
>in
>> > the ebuild, so Oracle's license has no relevance.
>> >
>> > Oracle cannot prohibit us from distributing a shell script that
>moves
>> > some files around. That liability is on the user who runs it.
>> >
>> > We cannot force you to continue maintaining this package, but I
>think
>> > we should have a better reason for masking/removing it. If you
>cannot
>> > provide one, please just drop this to maintainer-needed.
>>
>> I've modified the mask for now, but I still believe we should drop
>it.
>> I do not maintain it at all, I only work on openjdk and a bit of
>icedtea.
>>
>> For a while[1] we've been modifying provided jar:
>>
>> zip -d jre/lib/rt.jar sun/misc/PostVMInitHook.class || die
>>
>> but license[2] states that
>>
>> "You may not:
>> ...
>> make the Programs available in any manner to any third party
>> ...
>> create, modify, or change the behavior of, classes, interfaces,
>or
>> subpackages that are in any way identified as "java", "javax", "sun",
>“oracle”
>> or similar convention as specified by Oracle in any naming convention
>> designation.
>>
>> "
>>
>> Is it even legal?
>
>That does seem like it might cause some legal problems for users.
>
>> Java usage tracker will fail due to sandbox during builds.
>>
>> while writing this email I found out it's probably possible to
>disable it with
>> com.oracle.usagetracker.track.last.usage=false
>> in
>>  /etc/oracle/java/usagetracker.properties
>>
>> need to test it
>
>If that does not work, a possible alternative would be to install a
>file in /etc/sandbox.d to add some path to SANDBOX_PREDICT.
>
>Anyway, this issue does seem like grounds for removal if it is not
>addressed by somebody.

IIRC, SANDBOX_PREDICT doesn't really help in this case because it triggers on 
any package using Java within the home directory of the build user and the HOME 
environment variable isn't respected.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



Re: [gentoo-dev] Last rites: dev-java/oracle-{jre,jdk}-bin

2019-04-18 Thread James Le Cuirot
On 18 April 2019 02:31:42 BST, Mike Gilbert  wrote:
>On Wed, Apr 17, 2019 at 3:35 PM Georgy Yakovlev 
>wrote:
>>
>> # Georgy Yakovlev  (17 Apr 2019)
>> # The Oracle JDK License has changed for releases starting April 16,
>2019
>> # While it may be fine to use for some usecases it's not comepletely
>clear
>> # what is considered "personal use" and if we can legally distribute
>it.
>> # License states:
>> # "You may not:
>> # make the Programs available in any manner to any third party"
>
>I don't agree with your rationale here.
>
>Gentoo does not distribute the JDK due to RESTRICT="fetch mirror" in
>the ebuild, so Oracle's license has no relevance.
>
>Oracle cannot prohibit us from distributing a shell script that moves
>some files around. That liability is on the user who runs it.
>
>We cannot force you to continue maintaining this package, but I think
>we should have a better reason for masking/removing it. If you cannot
>provide one, please just drop this to maintainer-needed.

While I was overjoyed to see this mask, this is a fair point. I had previously 
been under the impression that Oracle wasn't even going to provide their own 
builds anymore, giving way to OpenJDK, but I guess that's not the plan now, if 
it ever was. It doesn't seem like a very Oracle thing to do.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



[gentoo-dev] Re: [gentoo-dev-announce] Last rites: games-strategy/freecol

2019-04-13 Thread James Le Cuirot
On Sat, 13 Apr 2019 10:04:26 +0200
Michał Górny  wrote:

> # Michał Górny  (13 Apr 2019)
> # Fails to run.  The current release is from 2015, and upstream has not
> # made a release since.  Uses games.eclass.
> # Removal in 30 days.  Bug #654564.
> games-strategy/freecol

Reverted as I have fixed the bug and upstream is still active, despite
the lack of releases.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpxuk_Ii_WHO.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: dev-util/staruml-bin

2019-03-16 Thread James Le Cuirot
On Sat, 16 Mar 2019 10:35:18 +0100
Michał Górny  wrote:

> On Sat, 2019-03-16 at 09:31 +0000, James Le Cuirot wrote:
> > On Fri, 15 Mar 2019 10:23:00 +0100
> > Michał Górny  wrote:
> >   
> > > # Michał Górny  (15 Mar 2019)
> > > # Last reverse dependency of dev-libs/libgcrypt-1.5* (#656378).  Current
> > > # version is outdated, maintainer is MIA and the new versions are
> > > # in distro-unfriendly AppImage format (#661740).
> > > # Removal in 30 days.  Bug #677486.
> > > dev-util/staruml-bin
> > > =dev-libs/libgcrypt-1.5*  
> > 
> > I don't care about staruml-bin but libgcrypt is one of those legacy
> > libraries that would be helpful to keep around for older proprietary
> > software that is not in the tree. In particular, it is used by
> > Half-Life 2 and Portal, not exactly obscure games. It is included in
> > the Steam runtime but we highly recommend against using that because it
> > causes many issues.  
> 
> I don't understand why would you want to run some proprietary native
> executables requiring obsolete libraries on your system when HL2 works
> perfectly via wine, and gets a nice performance boost via Gallium Nine.

That is even more viable now that Steam can be forced to use Proton but
I still choose native, as I'm sure many would.

> > If you want me to maintain this version then I can do that. If it's
> > otherwise causing real issues by being in the tree then I could move it
> > to steam-overlay but I'd rather not. There may be non-Steam use cases.  
> 
> Yeah, moving to Steam overlay is what I'd suggest.  However, you want to
> talk to crypto@ people since they flagged it for removal.

Will do.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp_aH129L4Ek.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Last rites: dev-util/staruml-bin

2019-03-16 Thread James Le Cuirot
On Fri, 15 Mar 2019 10:23:00 +0100
Michał Górny  wrote:

> # Michał Górny  (15 Mar 2019)
> # Last reverse dependency of dev-libs/libgcrypt-1.5* (#656378).  Current
> # version is outdated, maintainer is MIA and the new versions are
> # in distro-unfriendly AppImage format (#661740).
> # Removal in 30 days.  Bug #677486.
> dev-util/staruml-bin
> =dev-libs/libgcrypt-1.5*

I don't care about staruml-bin but libgcrypt is one of those legacy
libraries that would be helpful to keep around for older proprietary
software that is not in the tree. In particular, it is used by
Half-Life 2 and Portal, not exactly obscure games. It is included in
the Steam runtime but we highly recommend against using that because it
causes many issues.

If you want me to maintain this version then I can do that. If it's
otherwise causing real issues by being in the tree then I could move it
to steam-overlay but I'd rather not. There may be non-Steam use cases.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpvwD8hUHHb4.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Replacing binary-only SLOTs with separate packages

2019-01-18 Thread James Le Cuirot
On Fri, 18 Jan 2019 23:31:39 +
"Robin H. Johnson"  wrote:

> > So apparently 14.2% of dependencies allow any slot of OpenSSL which is
> > most likely wrong, and 1.4% explicitly claim that's what the package
> > wants.  This could be valid only if e.g. the package supported multiple
> > ABIs of OpenSSL libraries and used dlopen() with a few possible SONAMEs
> > which I honestly doubt any of those packages is doing.  
>
> There's a valid case for accepting ANY openssl: tooling that explicitly
> calls the binary tools provided by OpenSSL, and does link or dlopen any
> of the openssl libraries.

The binary-only SLOTs don't include those tools because they would
conflict. Library-only is a more accurate term.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgppnuqvl8hro.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Replacing binary-only SLOTs with separate packages

2019-01-18 Thread James Le Cuirot
On Fri, 18 Jan 2019 21:13:34 +0100
Michał Górny  wrote:

> Hello,
> 
> Since I've been working on the early gx86-multilib, we've been using
> 'binary-only SLOTs' to support providing old versions of libraries for
> prebuilt software.  I think this was a bad idea, and I'd like to suggest
> replacing it with something cleaner, for the reasons outlined below.
> 
> 
> Current state
> =
> 
> Let's take dev-libs/openssl as an example.  This package has three SLOTs
> right now:
> 
>   0.9.8: 0.9.8z_p8-r1
>   1.0.0: 1.0.2q-r200
>   0: 1.0.2q 1.1.0j 1.1.1a 1.1.1a-r1
> 
> The real package is provided as slot :0, that includes all libraries,
> headers and executables.  Slots 0.9.8 and 1.0.0 only install .so.N*
> libraries that can be used to satisfy dependencies of prebuilt packages.
> 
> 
> Problems with the current state
> ===
> 
> Firstly, it is confusing to developers.  Let's analyze the dependencies
> on dev-libs/openssl.  A quick grep reveals seven patterns.  They are
> listed below, along with occurrence counts and percentages:
> 
>   dev-libs/openssl  2787.8%  }
>   dev-libs/openssl:* 491.4%  } 14.2%
>   dev-libs/openssl:=1785.0%  }
>   dev-libs/openssl:0660   18.6%
>   dev-libs/openssl:0=  2381   67.0%
>   dev-libs/openssl:0/040.1%
>   dev-libs/openssl:0/1.1  20.1%
> 
> (note that those are rough measures, not guaranteed to be precise)
> 
> So apparently 14.2% of dependencies allow any slot of OpenSSL which is
> most likely wrong, and 1.4% explicitly claim that's what the package
> wants.  This could be valid only if e.g. the package supported multiple
> ABIs of OpenSSL libraries and used dlopen() with a few possible SONAMEs
> which I honestly doubt any of those packages is doing.
> 
> In other words, 14.2% of dependencies on OpenSSL are plain wrong,
> and 6.4% are wrong in a way that isn't going to be reported by repoman. 
> 1.4% of cases are using ':*' which probably indicates the developer
> decided to silence repoman without understanding how slot operators work
> which is a horrible thing from QA perspective.
> 
> We also have a few cases that require specific OpenSSL subslot (e.g.
> forcing old version into :0 slot) but *none* actually using the binary
> compatibility slots.

I have noticed this and more generally that slot operators are poorly
understood, which is frustrating. I was initially inclined to say that
I think the model still fits and we should educate devs better but...

> Secondly, it is confusing to users.  If we remove old versions and only
> keep binary compatibility slots, users can be easily tricked into
> installing them and being surprised it's not a complete package.  If we
> keep old versions, we end up having different revisions of the same
> version in different slots which is also easily confused.

I can't say I've ever seen this happen but I don't speak to many users.
I'll buy it.

> Thirdly, it is cumbersome to introduce.  If we are to introduce a binary
> compatibility slot for a package that didn't have it, we need to update
> all reverse dependencies.  This usually means researching whether we
> should use ':0' or ':0=', and if we get this wrong, we just silence
> repoman warning about missing slot-op.

This I certainly agree with. It's so bad that it puts you off adding it
at all.

> All of this considered, I can't think of a single real benefit of using
> slots for this purpose.  They work but there's nothing really special
> about them.
> 
> 
> Suggested replacement
> =
> 
> My suggestion is to move binary compatibility slots into separate
> packages.  For example, dev-libs/openssl would be split into:
> 
>   dev-libs/openssl  -- containing the actual package
> 
>   dev-libs/openssl-bin-compat  -- containing binary compatibility slots
> 
> In this case, all dependencies on dev-libs/openssl would become correct
> (or semi-correct, wrt missing := dep) again.  Since packages are co-
> installable the same way slots are, there is no loss there.  Since
> nothing depends on binary compatibility slots, we do not even need to
> update anything (but if we had, the update cost would be minimal both to
> developers and to users).
> 
> 
> What do you think?

I'm on board as I have to deal with this a lot in games and I think
there were one or two more on my list to add.

The only downside is that packages requiring what is currently the
latest version would need to be updated later, though I guess you could
use || instead. Take libpng, for example:

|| ( =media-libs/libpng-1.6* media-libs/libpng-bin-compat:1.6 )

Or perhaps?

|| ( media-libs/libpng:0/16 media-libs/libpng-bin-compat:1.6 )

The security team may want to comment on how this will affect GLSAs,
especially as these old versions are frequently vulnerable.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpjPGqXJumhI.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] waf-utils.eclass: Simplify output of configure command and arguments

2019-01-10 Thread James Le Cuirot
On 10 January 2019 03:33:56 GMT, "Michał Górny"  wrote:
>On Wed, 2019-01-09 at 22:08 +0000, James Le Cuirot wrote:
>> We can just assign these to an array and echo before executing. Using
>> @Q makes Bash quote the output. This only works in Bash 4.4 and later
>> but on earlier versions, it simply doesn't quote.
>> 
>> Signed-off-by: James Le Cuirot 
>> ---
>>  eclass/waf-utils.eclass | 20 +---
>>  1 file changed, 13 insertions(+), 7 deletions(-)
>> 
>> diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
>> index 878068fc9f4f..8387829648a3 100644
>> --- a/eclass/waf-utils.eclass
>> +++ b/eclass/waf-utils.eclass
>> @@ -1,4 +1,4 @@
>> -# Copyright 1999-2015 Gentoo Foundation
>> +# Copyright 1999-2019 Gentoo Authors
>>  # Distributed under the terms of the GNU General Public License v2
>>  
>>  # @ECLASS: waf-utils.eclass
>> @@ -84,13 +84,19 @@ waf-utils_src_configure() {
>>  [[ -z ${NO_WAF_LIBDIR} ]] &&
>libdir=(--libdir="${EPREFIX}/usr/$(get_libdir)")
>>  
>>  tc-export AR CC CPP CXX RANLIB
>> -echo "CCFLAGS=\"${CFLAGS}\" LINKFLAGS=\"${CFLAGS} ${LDFLAGS}\"
>\"${WAF_BINARY}\" --prefix=${EPREFIX}/usr ${libdir[@]} $@ configure"
>>  
>> -CCFLAGS="${CFLAGS}" LINKFLAGS="${CFLAGS} ${LDFLAGS}"
>"${WAF_BINARY}" \
>> -"--prefix=${EPREFIX}/usr" \
>> -"${libdir[@]}" \
>> -"${@}" \
>> -configure || die "configure failed"
>> +local CMD=(
>> +CCFLAGS="${CFLAGS}"
>> +LINKFLAGS="${CFLAGS} ${LDFLAGS}"
>> +"${WAF_BINARY}"
>> +"--prefix=${EPREFIX}/usr"
>> +"${libdir[@]}"
>> +"${@}"
>> +configure
>> +)
>> +
>> +echo "${CMD[@]@Q}"
>
>>&2
>
>> +env "${CMD[@]}" || die "configure failed"
>>  }
>>  
>>  # @FUNCTION: waf-utils_src_compile

Obviously that wasn't there before but good call.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



[gentoo-dev] [PATCH 2/2] waf-utils.eclass: Respect PKG_CONFIG

2019-01-09 Thread James Le Cuirot
Waf has a helper that looks for PKGCONFIG. This fixes cross-compiling.

Signed-off-by: James Le Cuirot 
---
 eclass/waf-utils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
index 8387829648a3..6cdfe5f747e8 100644
--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -88,6 +88,7 @@ waf-utils_src_configure() {
local CMD=(
CCFLAGS="${CFLAGS}"
LINKFLAGS="${CFLAGS} ${LDFLAGS}"
+   PKGCONFIG="$(tc-getPKG_CONFIG)"
"${WAF_BINARY}"
"--prefix=${EPREFIX}/usr"
"${libdir[@]}"
-- 
2.19.2




  1   2   3   4   >