Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-28 Thread Georgy Yakovlev
On 25.11.2020 13:57, Georgy Yakovlev wrote:
> Hi,
> 
> In case you don't know, opentmpfiles has an open CVE
> CVE-2017-18925: root privilege escalation by symlink attack
> https://github.com/OpenRC/opentmpfiles/issues/4
> It has been an issue for quite a while, reported 3 years ago,
> and not much changed since.
> Also it lacks any sort of testing, and master branch is in a non-working
> state at time of writing, latest version is masked.[0]
> 
> Due to nature of opentmpfiles (it's a POSIX sh script),
> it may be impossible to fix symlink handling and TOCTOU races.
> As a consequence I'll be switching default tmpfiles
> provider to sys-apps/systemd-tmpfiles by the end of the week by updating
> virtual/tmpfiles ebuild.
> 
> pros of systemd-tmpfiles:
> 0) Secure.
> 1) Reference implementation.
> 2) Supports all features, because ^.
> 3) Has working tests.
> 4) Has millions of users as part of systemd.
> 5) upstream supports standalone usecase/build our ebuild uses. [1][2]
> 6) drop-in replacement, just emerge and forget.
> 
> systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
> and is just a drop-in replacement, the only step needed is to emerge the
> package.
> it's a simple single binary + manpage, binary links to libacl and couple other
> system libs.
> 
> existing installations will not be affected, but openrc users are welcome to
> opt-in by running 'emerge --oneshot systemd-tmpfiles'
> 
> [0] https://bugs.gentoo.org/751739
> [1] https://github.com/systemd/systemd/pull/16061
> [2] 
> https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4

This is done in
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ab23417927d8454c8bb1c0ae52a5cac79d140b94


signature.asc
Description: PGP signature


[gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-25 Thread Georgy Yakovlev
Hi,

In case you don't know, opentmpfiles has an open CVE
CVE-2017-18925: root privilege escalation by symlink attack
https://github.com/OpenRC/opentmpfiles/issues/4
It has been an issue for quite a while, reported 3 years ago,
and not much changed since.
Also it lacks any sort of testing, and master branch is in a non-working
state at time of writing, latest version is masked.[0]

Due to nature of opentmpfiles (it's a POSIX sh script),
it may be impossible to fix symlink handling and TOCTOU races.
As a consequence I'll be switching default tmpfiles
provider to sys-apps/systemd-tmpfiles by the end of the week by updating
virtual/tmpfiles ebuild.

pros of systemd-tmpfiles:
0) Secure.
1) Reference implementation.
2) Supports all features, because ^.
3) Has working tests.
4) Has millions of users as part of systemd.
5) upstream supports standalone usecase/build our ebuild uses. [1][2]
6) drop-in replacement, just emerge and forget.

systemd-tmpfiles does not depend on any systemd-isms, does not need dbus,
and is just a drop-in replacement, the only step needed is to emerge the
package.
it's a simple single binary + manpage, binary links to libacl and couple other
system libs.

existing installations will not be affected, but openrc users are welcome to
opt-in by running 'emerge --oneshot systemd-tmpfiles'

[0] https://bugs.gentoo.org/751739
[1] https://github.com/systemd/systemd/pull/16061
[2] 
https://github.com/systemd/systemd/pull/16061/commits/db64ba81c62afa0e0d3e95c4a3e1ec3dd9a471a4


signature.asc
Description: PGP signature


Re: [gentoo-dev] Pushing to distfiles?

2020-11-11 Thread Georgy Yakovlev
On 11.11.2020 19:23, Joshua Kinard wrote:
> Forgive me for being a dunce, but what is the current procedure to push
> files to distfiles for distribution to the mirrors?  The devmanual is blank
> on this topic, and GLEP75 just talks about the motivations behind the change
> away from the flat directory format.  I am not easily finding anything that
> details how to get new distfiles onto the mirrors.
Hi,

Just put to devspace.
for example I keep distfiles in ~/public_html/distfiles

This is preferred of having file on mirrors only.
And it will be automatically mirrored from devspace, so no extra steps
required.
> 
> Thanks,
> 
> -- 
> Joshua Kinard
> Gentoo/MIPS
> ku...@gentoo.org
> rsa6144/5C63F4E3F5C6C943 2015-04-27
> 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
> 
> "The past tempts us, the present confuses us, the future frightens us.  And
> our lives slip away, moment by moment, lost in that vast, terrible 
> in-between."
> 
> --Emperor Turhan, Centauri Republic
> 


signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] eclass/cargo.eclass: add CARGO_OPTIONAL condition

2020-11-10 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index e6fec844d274..03dfbfebd1d7 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -15,20 +15,40 @@ _CARGO_ECLASS=1
 # we need this for 'cargo vendor' subcommand and net.offline config knob
 RUST_DEPEND=">=virtual/rust-1.37.0"
 
-case ${EAPI} in
-   7) BDEPEND="${RUST_DEPEND}";;
-   *) die "EAPI=${EAPI:-0} is not supported" ;;
+case "${EAPI:-0}" in
+   0|1|2|3|4|5|6)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   7)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
 esac
 
 inherit multiprocessing toolchain-funcs
 
-EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
+if [[ ! ${CARGO_OPTIONAL} ]]; then
+   BDEPEND="${RUST_DEPEND}"
+   EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install 
src_test
+fi
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
+# @ECLASS-VARIABLE: CARGO_OPTIONAL
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value, before inherit cargo part of the ebuild will
+# be considered optional. No dependencies will be added and no phase
+# functions will be exported.
+#
+# If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
+# for your package and call at least cargo_gen_config manually before using
+# other src_ functions of this eclass.
+
 # @VARIABLE: myfeatures
 # @DEFAULT_UNSET
 # @DESCRIPTION:
-- 
2.29.2




[gentoo-dev] RFC: introduce RUST_TARGETS use-expand (take2)

2020-10-10 Thread Georgy Yakovlev

Hi,

sending again, accidentally sent from personal email first time and it's 
stuck somewhere.


I would like to introduce new USE_EXPAND in profiles for rusts
3 consumers in the tree:
dev-lang/rust
dev-lang/rust-bin
sys-devel/rust-std
and maybe virtual, but not sure yet, may be required for firefox.

The idea:
Rust supports building as many targets as one wants, as long as C 
toolchan can do it and matching llvm target is enabled on rust or llvm.


There are some special rust targets that require same host toolchain but 
are treated like separate targets in rust.

For example x86_64-unknown-linux-gnu target is primary on amd64,
but on multilib profiles we can easily enable i686-unknown-linux-gnu 
target and it will just work (that's how multilib in rust works now)


Another example is arm:

armv7-unknown-linux-gnueabihf is primary toolchain.
but rust supports additional target thumbv7neon-unknown-linux-gnueabihf,
which requires exactly same host toolchain, but is capable of emitting 
thumb-neon binaries. This is required by firefox if --enable-neon is 
passed in firefox build.


Another example: ppc64

We can easily build both ppc64 and ppc64le targets in a single bootstrap 
with host toolchain, and rust will support emitting code for both endians.


Another example: musl

On musl we need 1 extra target with gentoo vendor field.
So installing both
  x86_64-unknown-linux-musl
  x86_64-gentoo-linux-musl
will be very easy, as both targets use same C toolchain, but slightly 
different settings.


And last, but not the least, it allows cross support if matching 
toolchain is installed (tested with crossdev)

A user can unmask the following targets on amd64
  rust_targets_thumbv7neon-unknown-linux-gnueabihf
  rust_targets_armv7-unknown-linux-gnueabihf

And as long as they have /usr/armv7a-unknown-linux-gnueabihf toolchain 
available at build time, and llvm_targets_ARM enabled, rust will 
bootstrap itself in a way that it will be able to emit code for any of 3 
targets enable. This is optional opt-in functionality.


And just to clarify, native host toolchain is not going to be a 
use-expand, at least that's how I imagine it now.
Native target matching CHOST is always build without any flags, and is 
the default target for rust.

But I may re-evaluate it and introduce requirements like

 abi_x86_64?? ( rust_targets_x86_64-unknown-linux-gnu )
 abi_x86_32? ( rust_targets_i686-unknown-linux-gnu )

for multilib profiles.

and something like this for non-multilib arches.

 ppc64? ( ||
rust_targets_powerpc64le-unknown-linux-gnu
rust_targets_powerpc64-unknown-linux-gnu
)

for example, similar to as llvm does with LLVM_TARGETS.
Of course default targets will be use-forced via profiles.
But if possible I'd avoid it.


Proof of concept exists (without using expand flags for now) in both 
rust and rust-bin ebuilds. Multilib is implemented that way and has been 
working great for more than a year, also experimental cross support in 
rust implemented that way, and users are already able to define as many 
targets as they want, but it feels hacky and I would like to move 
forward to targets approach and make it trackable via flags, and not 
magic variables nobody knows about.



Initial rollout will require a bit of arch profile masking (like llvm 
does it) and maybe new eclass to reduce boilerplate code in ebuilds, but 
nothing to complex.


WDYT?

tracking bug https://bugs.gentoo.org/747760

cross bugs:
https://bugs.gentoo.org/679878
https://bugs.gentoo.org/680652
https://bugs.gentoo.org/689336

Regards, Georgy.



[gentoo-dev] Re: RFC: introduce RUST_TARGETS use-expand

2020-10-10 Thread Georgy Yakovlev

On 10/10/20 7:17 PM, Georgy Yakovlev wrote:

Hi,
Sorry, thunderbird used personal mailfrom for some reason. Probably an 
issue after update.


OpenPGP_0xA5EDB076475B46A6.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 2/2] eclass/cargo.eclass: require cargo_gen_config in cargo_src* functions

2020-09-27 Thread Georgy Yakovlev
cargo_gen_config sets required config values and env vars, which
cargo_src_{compile,test,install} rely on.

it should be called as last step of src_unpack normally, so check it did.
Crate sources may have been vendored or cargo is wrapped by other build
system and pre-fetched, so cargo_*unpack may be not used.

In that case we can't guarantee our config will work, so src_ functions
should not be used.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dde601ec4e3c..3e0bb443 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -267,6 +267,7 @@ cargo_gen_config() {
_EOF_
 
export CARGO_HOME="${ECARGO_HOME}"
+   _CARGO_GEN_CONFIG_HAS_RUN=1
 }
 
 # @FUNCTION: cargo_src_configure
@@ -323,6 +324,9 @@ cargo_src_configure() {
 cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
+   [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+   die "FATAL: please call cargo_gen_config before using 
${FUNCNAME}"
+
tc-export AR CC CXX
 
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
@@ -340,6 +344,9 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
+   [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+   die "FATAL: please call cargo_gen_config before using 
${FUNCNAME}"
+
set -- cargo install $(has --path ${@} || echo --path ./) \
--root "${ED}/usr" \
$(usex debug --debug "") \
@@ -359,6 +366,9 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
+   [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+   die "FATAL: please call cargo_gen_config before using 
${FUNCNAME}"  
+
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo test failed"
-- 
2.28.0




[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: support cached downloads for live ebuilds

2020-09-27 Thread Georgy Yakovlev
Also honor ECARGO_OFFLINE/EVCS_OFFLINE
Good portion of the code/logic inspired by git-r3.eclass.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 115 +---
 1 file changed, 108 insertions(+), 7 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 6d341601a112..dde601ec4e3c 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -46,6 +46,35 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 # }
 # @CODE
 
+# @ECLASS-VARIABLE: ECARGO_REGISTRY_DIR
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Storage directory for cargo registry.
+# Used by cargo_live_src_unpack to cache downloads.
+# This is intended to be set by users.
+# Ebuilds must not set it.
+#
+# Defaults to '${DISTDIR}/ecargo-registry' it not set.
+
+# @ECLASS-VARIABLE: ECARGO_OFFLINE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If non-empty, this variable prevents online operations in
+# cargo_live_src_unpack.
+# Inherits value of EVCS_OFFLINE if not set explicitly.
+
+# @ECLASS-VARIABLE: EVCS_UMASK
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Set this variable to a custom umask. This is intended to be set by
+# users. By setting this to something like 002, it can make life easier
+# for people who use cargo in a home directory, but are in the portage
+# group, and then switch over to building with FEATURES=userpriv.
+# Or vice-versa.
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -122,13 +151,84 @@ cargo_live_src_unpack() {
[[ "${EBUILD_PHASE}" == unpack ]] || die "${FUNCNAME} only allowed in 
src_unpack"
 
mkdir -p "${S}" || die
+   mkdir -p "${ECARGO_VENDOR}" || die
+   mkdir -p "${ECARGO_HOME}" || die
+
+   local distdir=${PORTAGE_ACTUAL_DISTDIR:-${DISTDIR}}
+   : ${ECARGO_REGISTRY_DIR:=${distdir}/ecargo-registry}
+
+   local offline="${ECARGO_OFFLINE:-${EVCS_OFFLINE}}"
+
+   if [[ ! -d ${ECARGO_REGISTRY_DIR} && ! ${offline} ]]; then
+   (
+   addwrite "${ECARGO_REGISTRY_DIR}"
+   mkdir -p "${ECARGO_REGISTRY_DIR}"
+   ) || die "Unable to create ${ECARGO_REGISTRY_DIR}"
+   fi
+
+   if [[ ${offline} ]]; then
+   local subdir
+   for subdir in cache index src; do
+   if [[ ! -d ${ECARGO_REGISTRY_DIR}/registry/${subdir} 
]]; then
+   eerror "Networking activity has been disabled 
via ECARGO_OFFLINE or EVCS_OFFLINE"
+   eerror "However, no valid cargo registry 
available at ${ECARGO_REGISTRY_DIR}"
+   die "Unable to proceed with 
ECARGO_OFFLINE/EVCS_OFFLINE."
+   fi
+   done
+   fi
+
+   if [[ ${EVCS_UMASK} ]]; then
+   local saved_umask=$(umask)
+   umask "${EVCS_UMASK}" || die "Bad options to umask: 
${EVCS_UMASK}"
+   fi
 
pushd "${S}" > /dev/null || die
-   # need to specify CARGO_HOME before cargo_gen_config fired
-   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
-   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+
+   # Respect user settings befire cargo_gen_config is called.
+   if [[ ! ${CARGO_TERM_COLOR} ]]; then
+   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && export 
CARGO_TERM_COLOR=never
+   local unset_color=true
+   fi
+   if [[ ! ${CARGO_TERM_VERBOSE} ]]; then
+   export CARGO_TERM_VERBOSE=true
+   local unset_verbose=true
+   fi
+
+   # Let cargo fetch to system-wide location.
+   # It will keep directory organized by itself.
+   addwrite "${ECARGO_REGISTRY_DIR}"
+   export CARGO_HOME="${ECARGO_REGISTRY_DIR}"
+
+   # Absence of quotes around offline arg is intentional, as cargo bails 
out if it encounters ''
+   einfo "cargo fetch ${offline:+--offline}"
+   cargo fetch ${offline:+--offline} || die #nowarn
+
+   # Let cargo copy all required crates to "${WORKDIR}" for offline use in 
later phases.
+   einfo "cargo vendor ${offline:+--offline} ${ECARGO_VENDOR}"
+   cargo vendor ${offline:+--offline} "${ECARGO_VENDOR}" || die #nowarn
+
+   # Users may have git checkouts made by cargo.
+   # While cargo vendors the sources, it still needs git checkout to be 
present.
+   # Copying full dir is an overkill, so just symlink it.
+   if [[ -d ${ECARGO_REGISTRY_DIR}/git ]]; then
+   ln -sv "${ECARGO_REGISTRY_DIR}/git" "${ECARGO_HOME}/git" || die
+   fi
+
popd 

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

2020-09-19 Thread Georgy Yakovlev
took a while, removed.

I was able to save jabref-bin, works fine with openjdk:8
geogebra now availabie as geogebra-bin and works with openjdk8 and 11.
sleuthkit was spared.

rest is gone, but if someone wants to restore - patches welcome.


On 4/18/20 9:10 PM, Georgy Yakovlev wrote:
> # Georgy Yakovlev  (2020-04-18)
> # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
> # requires agreement to restrictive license
> # Revdeps that still depend on oracle variants require javafx
> # Please use icedtea or openjdk instead.
> # Removal in 30 days.
> # https://bugs.gentoo.org/681828
> dev-java/oracle-jdk-bin
> dev-java/oracle-jre-bin
> app-forensics/sleuthkit
> app-text/jabref-bin
> dev-java/netbeans-platform
> dev-java/netbeans-harness
> games-util/pogo-manager-bin
> net-p2p/bisq
> sci-mathematics/geogebra
> 
> 
> 
> Oracle java has been maintainer-needed since august 2019,
> no one stepped up.
> Removal in 30 days.
> 
> If someone wants to save the javafx revdeps, best way will be
> packaging zulufx community [1], I can provide some guidance
> on packaging it, should not be too hard.
> 




[gentoo-dev] Last rites: dev-python/ansimarkup

2020-09-02 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-09-02)


# Masked for removal. No revdeps.


dev-python/ansimarkup



[gentoo-dev] Re: [PATCH] profiles/base/make.defaults: ENV_UNSET CARGO_HOME

2020-08-30 Thread Georgy Yakovlev
On 8/28/20 2:09 PM, Georgy Yakovlev wrote:
> CARGO_HOME may leak into ebuild environment and lead to
> write attempts to directory specified.
> This is explicitly taken care of in cargo.eclass, but
> ebuilds that don't use the eclass can still be affected.
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  profiles/base/make.defaults | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
> index 1ac69f51ec9..9f570d905c8 100644
> --- a/profiles/base/make.defaults
> +++ b/profiles/base/make.defaults
> @@ -40,7 +40,7 @@ CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf"
>  # GOBIN needs to be cleaned as random values in GOBIN can affect the
>  # building of some packages:
>  # 
> https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0
> -ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
> XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
> PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH"
> +ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
> XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
> PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH CARGO_HOME"
>  
>  # Variables that are set exclusively by the profile
>  # and not by user configuration files.
> 

Pushed.



[gentoo-dev] [PATCH] profiles/base/make.defaults: ENV_UNSET CARGO_HOME

2020-08-28 Thread Georgy Yakovlev
CARGO_HOME may leak into ebuild environment and lead to
write attempts to directory specified.
This is explicitly taken care of in cargo.eclass, but
ebuilds that don't use the eclass can still be affected.

Signed-off-by: Georgy Yakovlev 
---
 profiles/base/make.defaults | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index 1ac69f51ec9..9f570d905c8 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -40,7 +40,7 @@ CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf"
 # GOBIN needs to be cleaned as random values in GOBIN can affect the
 # building of some packages:
 # 
https://archives.gentoo.org/gentoo-dev/message/163010f83ae7819d80c0cfdf797cbfe0
-ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH"
+ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY XDG_CACHE_HOME 
XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR PERL_MM_OPT PERL5LIB PERL5OPT 
PERL_MB_OPT PERL_CORE PERLPREFIX GOBIN GOPATH CARGO_HOME"
 
 # Variables that are set exclusively by the profile
 # and not by user configuration files.
-- 
2.28.0




Re: [gentoo-dev] News item: Multiple root kernel command-line arguments

2020-08-06 Thread Georgy Yakovlev
On 8/5/20 5:02 AM, Thomas Deutschmann wrote:
> Hi,
> 
> please review the news item below:
> 

Not all arches support --reuse-cmdline btw.
It may be only x86 which supports it.

This looks like a candidate wiki page or a word of warning in a
handbook, not a news item.



[gentoo-dev] Packages up for grabs (aerc, vagrant, rust utils and others)

2020-07-11 Thread Georgy Yakovlev
Hello People,

The following packages are up for grabs:

# untested with plundervolt mitigations, please test.
sys-power/intel-undervolt | need intel CPU machine to maintain

# rust stuff
app-misc/skim | needs bump, cleanup and new stable
app-shells/mcfly | needs minor bump
app-text/fblog | needs major bump
sys-apps/bat | great upstream, very friendly
sys-apps/exa | may be abandoned, check upstream


# vagrant bundle. take all 3 together.
app-emulation/vagrant | low prio bug [1]
dev-ruby/hashicorp-checkpoint | tests fail bug [2]
dev-ruby/vagrant_cloud

# random stuff
app-shells/loksh | release syned with openbsd releases
mail-client/aerc | go package, great upstream

-
Regards, Georgy.

[1] https://bugs.gentoo.org/589114
[2] https://bugs.gentoo.org/723820



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] eclass/cargo.eclass: add cargo_src_configure (revised)

2020-06-12 Thread Georgy Yakovlev
simple src_configure implementation inspired by cmake.eclass

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

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 77 -
 1 file changed, 70 insertions(+), 7 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ccbf87aa9a6..77c8e90755b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -22,7 +22,7 @@ esac
 
 inherit multiprocessing toolchain-funcs
 
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
 
 IUSE="${IUSE} debug"
 
@@ -34,6 +34,29 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 # Allows overriding the default cwd to run cargo install from
 : ${CARGO_INSTALL_PATH:=.}
 
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before 
calling
+# src_configure.
+# If this array is not empty, --no-default-features is passed to cargo.
+# To enable default crate features in that case you can add 'default' to the 
array.
+# Extra positional arguments supplied to this function
+# will be passed to cargo in all phases.
+# Make sure all cargo subcommands support flags passed here.
+#
+# Example for package that has x11 and wayland as features, and enables 
default set.
+# @CODE
+# src_configure() {
+#  local myfeatures=(
+#  default
+#  $(usex X x11 '')
+#  $(usev wayland)
+#  )
+#  cargo_src_configure
+# }
+# @CODE
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -112,6 +135,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
 
pushd "${S}" > /dev/null || die
+   # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -151,6 +175,47 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color = 
'never'" >> "${ECARGO_HOME}/config"
+
+   export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features and arguments.
+# Example for package that explicitly builds only 'foo' binary and
+# enables single feature 'barfeature', disabling default feature set.
+# will pass '--no-default-features --features barfeature --bin foo'
+# in src_{compile,test,install}
+# @CODE
+# src_configure() {
+#  local myfeatures=(
+#  barfeature
+#  )
+#  cargo_src_configure --bin foo
+# }
+# @CODE
+
+cargo_src_configure() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+   local myfeaturestype=$(declare -p myfeatures 2>&-)
+   if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+   die "myfeatures must be declared as array"
+   fi
+
+   # transform array from simple feature list
+   # to multiple cargo args:
+   # --features feature1 --features feature2 ...
+   # this format is chosen because 2 other methods of
+   # listing features (space OR comma separated) require
+   # more fiddling with strings we'd like to avoid here.
+   myfeatures=( ${myfeatures[@]/#/--features } )
+
+   # prepend --no-default features if myfeatures array is not empty, 
append extra args
+   readonly ECARGO_ARGS=( ${myfeatures:+--no-default-features 
${myfeatures[@]}} ${@} )
+
+   [[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
 }
 
 # @FUNCTION: cargo_src_compile
@@ -159,11 +224,9 @@ cargo_gen_config() {
 cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
 
-   cargo build $(usex debug "" --release) "$@" \
+   cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo build failed"
 }
 
@@ -173,8 +236,8 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install --path ${CARGO_INSTALL_PATH} \
-   --root="${ED}/usr" $(usex debug --debug "") "$@" \
+   cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+   $(usex debug --debug "") ${ECARGO_ARGS[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -188,7 +251,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test $(usex debug "" --release) "$@" \
+   cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@" \
|| die "cargo test failed"
 }
 
-- 
2.27.0




Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 11:59 AM, Luca Barbato wrote:
> On 12/06/2020 18:24, Georgy Yakovlev wrote:
>> On 6/12/20 4:16 AM, Luca Barbato wrote:
>>> On 12/06/2020 11:04, Georgy Yakovlev wrote:
>>>> +# cargo_src_configure --no-default-features
>>>
>>> Shall we default in not-defaulting so we can spare some boilerplate?
>> I don't think so. Let me explain.
>>
>> First of all, this will force to explicitly micro-manage all the
>> features for all the packages in the tree.
>>
> 
> The idea is:
> - if myfeatures is empty, do not pass --no-default-features.
> - if myfeatures has content, automatically pass --no-default-features.
> 
I realized that was the intention after sending the email.
That makes more sense, I'll scout toml files a bit and probably will
implement it.
I certainly remember scenarios where turning off default features is
highly undesirable, but toggling extras makes sense.
> --no-default-features --features default seems working as intended btw.
> 

in that case
local myfeatures=(
default
$(usex flagX featureX '')
)
-> --no-default-features --features default --features featureX

looks quite good actually. just need to make sure we pass
--no-default-features first in order in that scenario.
> lu




[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support

2020-06-12 Thread Georgy Yakovlev
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  eclass/cargo.eclass | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
>  RUST_DEPEND=">=virtual/rust-1.37.0"
>  
>  case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
>   7) BDEPEND="${RUST_DEPEND}";;
>   *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
> 
merged c30b9bed5d16025c59b878e9dff69b90af41bf4d



Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 6:03 AM, Kent Fredric wrote:

I've replied privately by mistake, replying to the list again.
> On Fri, 12 Jun 2020 02:04:51 -0700
> Georgy Yakovlev  wrote:
> 
>> +#   cargo_src_configure --no-default-features
> 
> Looking at the source, I don't see how this is passed from this command to 
> anything.
yeah I caught it later, will just pass it as

readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )

> 
>> +# transform array from simple feature list
>> +# to multiple cargo args:
>> +# --features feature1 --features feature2 ...
>> +readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
> 
> Is this really necessary?
> 
>> cargo --features "feature1 feature2"
> 
> is perfectly legal.
> 
cargo is very picky about how multiple features are quoted in your example.
like REALLY picky, and it breaks depending on how array is passed.
I had that initially but found that just not worth it because it may break.
multiple toggles is perfectly legal way to pass features as well and is
more robust in this situation IMO.





Re: [gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 4:16 AM, Luca Barbato wrote:
> On 12/06/2020 11:04, Georgy Yakovlev wrote:
>> +# cargo_src_configure --no-default-features
> 
> Shall we default in not-defaulting so we can spare some boilerplate?
I don't think so. Let me explain.

First of all, this will force to explicitly micro-manage all the
features for all the packages in the tree.

Like 90% of crates I've seen ship working choice and there's no benefit
of micro-management, and no benefit of enabling non-default features at
all. Not all features need to be exposed as use-flags, and this was
quite consistent situation so far.

I know it may sound a bit strange but automagic in this case works with
no downsides, unlike other languages/frameworks/build-systems.

Also it will break all the tree packages which do not manage features
directly if merged as is.

Not sure if --features=default  will activate default set and how it
will react to being passed along.

--no-default-features --features default
IDK, looks kinda unnatural.

I have a feeling that we'll get more boilerplate if we pass
--no-default-features than if we don't.

We can re-evaluate as time goes by, but for now I see no major benefit
and only downsides.
> 
> lu
> 




[gentoo-dev] Re: [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> simple src_configure implementation inspired by cmake.eclass
> 
> Closes: https://bugs.gentoo.org/721936
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  eclass/cargo.eclass | 51 ++---
>  1 file changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..b084e082730 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -23,7 +23,7 @@ esac
>  
>  inherit multiprocessing toolchain-funcs
>  
> -EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
> +EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
>  
>  IUSE="${IUSE} debug"
>  
> @@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
>  # Allows overriding the default cwd to run cargo install from
>  : ${CARGO_INSTALL_PATH:=.}
>  
> +# @VARIABLE: myfeatures
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# Optional cargo features defined as bash array. Should be defined before 
> calling
> +# src_configure.
> +# Example for package that has x11 and wayland as features.
> +# Also disables default features, as optional parameter is passed.
> +# @CODE
> +# src_configure() {
> +#local myfeatures=(
> +#$(usex X x11 '')
> +#$(usev wayland)
> +#)
> +#
> +#cargo_src_configure --no-default-features
> +# }
> +# @CODE
> +
>  # @FUNCTION: cargo_crate_uris
>  # @DESCRIPTION:
>  # Generates the URIs to put in SRC_URI to help fetch dependencies.
> @@ -113,6 +131,7 @@ cargo_live_src_unpack() {
>   mkdir -p "${S}" || die
>  
>   pushd "${S}" > /dev/null || die
> + # need to specify CARGO_HOME before cargo_gen_config fired
>   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
>   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
>   popd > /dev/null || die
> @@ -152,6 +171,26 @@ cargo_gen_config() {
>   EOF
>   # honor NOCOLOR setting
>   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color = 
> 'never'" >> "${ECARGO_HOME}/config"
> +
> + export CARGO_HOME="${ECARGO_HOME}"
> +}
> +
> +# @FUNCTION: cargo_src_configure
> +# @DESCRIPTION:
> +# Configure cargo package features
> +cargo_src_configure() {
> + debug-print-function ${FUNCNAME} "$@"
> +
> + [[ -z ${myfeatures} ]] && declare -a myfeatures=()
> + local myfeaturestype=$(declare -p myfeatures 2>&-)
> + if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
> + die "myfeatures must be declared as array"
> + fi
> +
> + # transform array from simple feature list
> + # to multiple cargo args:
> + # --features feature1 --features feature2 ...
> + readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
missed ${@}, fixed locally, this should be,
readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } ${@} )
>  }
>  
>  # @FUNCTION: cargo_src_compile
> @@ -160,11 +199,9 @@ cargo_gen_config() {
>  cargo_src_compile() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - export CARGO_HOME="${ECARGO_HOME}"
> -
>   tc-export AR CC
>  
> - cargo build $(usex debug "" --release) "$@" \
> + cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
>   || die "cargo build failed"
>  }
>  
> @@ -174,8 +211,8 @@ cargo_src_compile() {
>  cargo_src_install() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - cargo install --path ${CARGO_INSTALL_PATH} \
> - --root="${ED}/usr" $(usex debug --debug "") "$@" \
> + cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
> + $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
>   || die "cargo install failed"
>   rm -f "${ED}/usr/.crates.toml"
>   rm -f "${ED}/usr/.crates2.json"
> @@ -189,7 +226,7 @@ cargo_src_install() {
>  cargo_src_test() {
>   debug-print-function ${FUNCNAME} "$@"
>  
> - cargo test $(usex debug "" --release) "$@" \
> + cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
>   || die "cargo test failed"
>  }
>  
> 




[gentoo-dev] Re: [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
On 6/12/20 2:04 AM, Georgy Yakovlev wrote:
> Signed-off-by: Georgy Yakovlev 
> ---
>  x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild 
> b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> index ac4d768d09b..2efc1a6dd0a 100644
> --- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
> +++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
> @@ -328,19 +328,20 @@ src_unpack() {
>  }
>  
>  src_configure() {
> - myfeatures=(
> + local myfeatures=(
>   $(usex X x11 '')
>   $(usev wayland)
>   )
> + cargo_src_configure
>  }
>  
>  src_compile() {
>   cd alacritty || die
> - cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"} 
> --no-default-features
> + cargo_src_compile --no-default-features
>  }
^ --no-default-features should be passed to configure, missed it before
push, fixed locally.
>  
>  src_install() {
> - CARGO_INSTALL_PATH="alacritty" cargo_src_install 
> ${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
> + CARGO_INSTALL_PATH="alacritty" cargo_src_install
>  
>   newman extra/alacritty.man alacritty.1
>  
> @@ -368,5 +369,5 @@ src_install() {
>  
>  src_test() {
>   cd alacritty || die
> - cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"} 
> --no-default-features
> + cargo_src_test
>  }
> 




[gentoo-dev] PATCH: cargo.eclass src_configure function

2020-06-12 Thread Georgy Yakovlev


Add simple src_configure implementation, based on cmake.eclass. 
2nd patch is an example of migrated ebuild.




[gentoo-dev] [PATCH 1/2] eclass/cargo.eclass: add cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
simple src_configure implementation inspired by cmake.eclass

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

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 51 ++---
 1 file changed, 44 insertions(+), 7 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..b084e082730 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -23,7 +23,7 @@ esac
 
 inherit multiprocessing toolchain-funcs
 
-EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
+EXPORT_FUNCTIONS src_unpack src_configure src_compile src_install src_test
 
 IUSE="${IUSE} debug"
 
@@ -35,6 +35,24 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 # Allows overriding the default cwd to run cargo install from
 : ${CARGO_INSTALL_PATH:=.}
 
+# @VARIABLE: myfeatures
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Optional cargo features defined as bash array. Should be defined before 
calling
+# src_configure.
+# Example for package that has x11 and wayland as features.
+# Also disables default features, as optional parameter is passed.
+# @CODE
+# src_configure() {
+#  local myfeatures=(
+#  $(usex X x11 '')
+#  $(usev wayland)
+#  )
+#
+#  cargo_src_configure --no-default-features
+# }
+# @CODE
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
@@ -113,6 +131,7 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
 
pushd "${S}" > /dev/null || die
+   # need to specify CARGO_HOME before cargo_gen_config fired
CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
@@ -152,6 +171,26 @@ cargo_gen_config() {
EOF
# honor NOCOLOR setting
[[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo "color = 
'never'" >> "${ECARGO_HOME}/config"
+
+   export CARGO_HOME="${ECARGO_HOME}"
+}
+
+# @FUNCTION: cargo_src_configure
+# @DESCRIPTION:
+# Configure cargo package features
+cargo_src_configure() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   [[ -z ${myfeatures} ]] && declare -a myfeatures=()
+   local myfeaturestype=$(declare -p myfeatures 2>&-)
+   if [[ "${myfeaturestype}" != "declare -a myfeatures="* ]]; then
+   die "myfeatures must be declared as array"
+   fi
+
+   # transform array from simple feature list
+   # to multiple cargo args:
+   # --features feature1 --features feature2 ...
+   readonly ECARGO_FEATURES=( ${myfeatures[@]/#/--features } )
 }
 
 # @FUNCTION: cargo_src_compile
@@ -160,11 +199,9 @@ cargo_gen_config() {
 cargo_src_compile() {
debug-print-function ${FUNCNAME} "$@"
 
-   export CARGO_HOME="${ECARGO_HOME}"
-
tc-export AR CC
 
-   cargo build $(usex debug "" --release) "$@" \
+   cargo build $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo build failed"
 }
 
@@ -174,8 +211,8 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install --path ${CARGO_INSTALL_PATH} \
-   --root="${ED}/usr" $(usex debug --debug "") "$@" \
+   cargo install --path ${CARGO_INSTALL_PATH} --root="${ED}/usr" \
+   $(usex debug --debug "") ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
rm -f "${ED}/usr/.crates2.json"
@@ -189,7 +226,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test $(usex debug "" --release) "$@" \
+   cargo test $(usex debug "" --release) ${ECARGO_FEATURES[@]} "$@" \
|| die "cargo test failed"
 }
 
-- 
2.27.0




[gentoo-dev] [PATCH 2/2] x11-terms/alacritty: use new cargo_src_configure

2020-06-12 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 x11-terms/alacritty/alacritty-0.4.3.ebuild | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/x11-terms/alacritty/alacritty-0.4.3.ebuild 
b/x11-terms/alacritty/alacritty-0.4.3.ebuild
index ac4d768d09b..2efc1a6dd0a 100644
--- a/x11-terms/alacritty/alacritty-0.4.3.ebuild
+++ b/x11-terms/alacritty/alacritty-0.4.3.ebuild
@@ -328,19 +328,20 @@ src_unpack() {
 }
 
 src_configure() {
-   myfeatures=(
+   local myfeatures=(
$(usex X x11 '')
$(usev wayland)
)
+   cargo_src_configure
 }
 
 src_compile() {
cd alacritty || die
-   cargo_src_compile ${myfeatures:+--features "${myfeatures[*]}"} 
--no-default-features
+   cargo_src_compile --no-default-features
 }
 
 src_install() {
-   CARGO_INSTALL_PATH="alacritty" cargo_src_install 
${myfeatures:+--features "${myfeatures[*]}"} --no-default-features
+   CARGO_INSTALL_PATH="alacritty" cargo_src_install
 
newman extra/alacritty.man alacritty.1
 
@@ -368,5 +369,5 @@ src_install() {
 
 src_test() {
cd alacritty || die
-   cargo_src_test ${myfeatures:+--features "${myfeatures[*]}"} 
--no-default-features
+   cargo_src_test
 }
-- 
2.27.0




[gentoo-dev] Re: [PATCH] eclass/cargo.eclass: drop EAPI=6 support

2020-06-11 Thread Georgy Yakovlev
This will also allow me to start adding cross support to cargo.eclass
with new cross-friendly variables.


experimental cross support landed in rust-1.44.0 today [1]

[1] https://bugs.gentoo.org/679878
On 6/11/20 8:11 PM, Georgy Yakovlev wrote:
> no consumers left in the tree
> 
> Signed-off-by: Georgy Yakovlev 
> ---
>  eclass/cargo.eclass | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> index ad90a0c7dd8..ccbf87aa9a6 100644
> --- a/eclass/cargo.eclass
> +++ b/eclass/cargo.eclass
> @@ -16,7 +16,6 @@ _CARGO_ECLASS=1
>  RUST_DEPEND=">=virtual/rust-1.37.0"
>  
>  case ${EAPI} in
> - 6) DEPEND="${RUST_DEPEND}";;
>   7) BDEPEND="${RUST_DEPEND}";;
>   *) die "EAPI=${EAPI:-0} is not supported" ;;
>  esac
> 




[gentoo-dev] [PATCH] eclass/cargo.eclass: drop EAPI=6 support

2020-06-11 Thread Georgy Yakovlev
no consumers left in the tree

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ad90a0c7dd8..ccbf87aa9a6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -16,7 +16,6 @@ _CARGO_ECLASS=1
 RUST_DEPEND=">=virtual/rust-1.37.0"
 
 case ${EAPI} in
-   6) DEPEND="${RUST_DEPEND}";;
7) BDEPEND="${RUST_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
-- 
2.27.0




Re: [gentoo-dev] cmake-utils.eclass: DEPRECATED notice

2020-06-08 Thread Georgy Yakovlev
opened a PR to add it to repoman:

https://github.com/gentoo/portage/pull/554

On 6/8/20 2:09 AM, Sergei Trofimovich wrote:
> On Mon, 08 Jun 2020 10:13:24 +0200
> Andreas Sturmlechner  wrote:
> 
>> This eclass no longer receives any changes.
>> Everyone must port to cmake.eclass.
> 
> We have quite a few ebuilds that still use it:
> $ git grep -E 'inherit.*cmake-utils' | wc -l
> 1338
> 
> I don't see any warnings reported by repoman to suggest users
> to migrate away. Should we have one?
> 




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

2020-04-19 Thread Georgy Yakovlev
On Sun, 19 Apr 2020 11:30:25 +0200
"Haelwenn (lanodan) Monnier"  wrote:

> [2020-04-18 21:10:45-0700] Georgy Yakovlev:
> > # Georgy Yakovlev  (2020-04-18)
> > # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
> > # requires agreement to restrictive license
> > # Revdeps that still depend on oracle variants require javafx
> > # Please use icedtea or openjdk instead.
> > # Removal in 30 days.
> > # https://bugs.gentoo.org/681828
> > dev-java/oracle-jdk-bin
> > dev-java/oracle-jre-bin
> > app-forensics/sleuthkit
> > app-text/jabref-bin
> > dev-java/netbeans-platform
> > dev-java/netbeans-harness
> > games-util/pogo-manager-bin
> > net-p2p/bisq
> > sci-mathematics/geogebra
> 
> The mask on app-forensics/sleuthkit seems to be faulty/overkill: 
> optionally depends on java, only uses oracle-jdk on 4.7.0.
> 
Thanks! my grep misfired.
I removed it from package.mask, and masked java useflag for 4.7.0 instead.


-- 
Georgy Yakovlev 


pgpAH_4mWfNs3.pgp
Description: PGP signature


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

2020-04-18 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-04-18)
# Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
# requires agreement to restrictive license
# Revdeps that still depend on oracle variants require javafx
# Please use icedtea or openjdk instead.
# Removal in 30 days.
# https://bugs.gentoo.org/681828
dev-java/oracle-jdk-bin
dev-java/oracle-jre-bin
app-forensics/sleuthkit
app-text/jabref-bin
dev-java/netbeans-platform
dev-java/netbeans-harness
games-util/pogo-manager-bin
net-p2p/bisq
sci-mathematics/geogebra



Oracle java has been maintainer-needed since august 2019,
no one stepped up.
Removal in 30 days.

If someone wants to save the javafx revdeps, best way will be
packaging zulufx community [1], I can provide some guidance
on packaging it, should not be too hard.

-- 
Georgy Yakovlev 

[1] 
https://www.azul.com/downloads/zulu-community/?version=java-8-lts=linux=jdk-fx


pgpQeTto78oDk.pgp
Description: PGP signature


[gentoo-dev] package up for grabs: net-news/newsboat

2020-04-05 Thread Georgy Yakovlev
No longer use it.
Needs a minor bump, upstream changed doc dependency to asciidoctor.
Uses custom build system and rust,
may be tricky to maintain, but I can help.

Couple of open bugs: arm keywording and musl related build falure.

net-news/newsboat


-- 
Georgy Yakovlev 


pgpTpfceqLlmO.pgp
Description: PGP signature


[gentoo-dev] Re: [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item

2020-04-04 Thread Georgy Yakovlev
Clarification: this is just news item for review.

Profiles need to be marked stable, before posting news item,
but I see no reason not to.
Old profiles will be deprecated and removed on June 1st 2020.

Tracking bug: https://bugs.gentoo.org/715680

On Sat,  4 Apr 2020 19:37:32 -0700
Georgy Yakovlev  wrote:

> Signed-off-by: Georgy Yakovlev 
> ---
>  .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++
>  1 file changed, 25 insertions(+)
>  create mode 100644 
> 2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
> 
> diff --git 
> a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt 
> b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
> new file mode 100644
> index 000..c496154
> --- /dev/null
> +++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
> @@ -0,0 +1,25 @@
> +Title: new ppc64le (little-endian) profiles
> +Author: Georgy Yakovlev 
> +Posted: 2020-04-04
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Profile: 
> default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
> +Display-If-Profile: 
> default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
> +
> +A new set of 17.0 ppc64le profiles has been added to the Gentoo repository.
> +New profiles are compatible with existing ppc64 little-endian profiles,
> +and no additional action required after switching the profile.
> +
> +Please migrate away from the old profiles:
> +
> +* Old profiles:
> +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
> +default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
> +
> +* Replaced by:
> +default/linux/ppc64le/17.0 
> +default/linux/ppc64le/17.0/systemd
> +
> +Desktop profiles are now also available.
> +
> +Refer to `eselect profile list` output.
> -- 
> 2.26.0
> 


-- 
Georgy Yakovlev 


pgp4vCSLEyCeW.pgp
Description: PGP signature


[gentoo-dev] [PATCH] 2020-04-04-new-ppc64le-profiles: Add news item

2020-04-04 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 .../2020-04-04-new-ppc64le-profiles.en.txt| 25 +++
 1 file changed, 25 insertions(+)
 create mode 100644 
2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt

diff --git 
a/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt 
b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
new file mode 100644
index 000..c496154
--- /dev/null
+++ b/2020-04-04-new-ppc64le-profiles/2020-04-04-new-ppc64le-profiles.en.txt
@@ -0,0 +1,25 @@
+Title: new ppc64le (little-endian) profiles
+Author: Georgy Yakovlev 
+Posted: 2020-04-04
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Profile: 
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
+Display-If-Profile: 
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
+
+A new set of 17.0 ppc64le profiles has been added to the Gentoo repository.
+New profiles are compatible with existing ppc64 little-endian profiles,
+and no additional action required after switching the profile.
+
+Please migrate away from the old profiles:
+
+* Old profiles:
+default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian
+default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd
+
+* Replaced by:
+default/linux/ppc64le/17.0 
+default/linux/ppc64le/17.0/systemd
+
+Desktop profiles are now also available.
+
+Refer to `eselect profile list` output.
-- 
2.26.0




Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-23 Thread Georgy Yakovlev
On Mon, 23 Mar 2020 21:09:15 +0200
Jaco Kroon  wrote:

> Hi Michał,
> 
> On 2020/03/23 18:25, Michał Górny wrote:
> 
> > On Mon, 2020-03-23 at 10:21 +0200, Jaco Kroon wrote:
> >> Hi,
> >>
> >> https://bugs.gentoo.org/713668 relates.
> >>
> >>  * Searching for /usr/include/execinfo.h ...
> >> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
> >>
> >> As I see I can either add an explicit depend on glibc which I'd prefer
> >> not to.  Or someone from the musl team could possibly assist on how to
> >> get the backtrace() set of calls on musl please?
> >>
> > As someone not on musl team, I think libunwind provides
> > an implementation of backtrace().
> >
> Thanks.  That indeed looks interesting.
> 
> Let's say I do go that route rather than simply no-opping it, would I
> add a BDEPEND + RDEPEND of the form:
> 
> || ( sys-libs/glibc sys-libs/libunwind )
> 
> To the ebuild?
> 
> The code (./configure and actual "C" I'll manage).
> 
> Kind Regards,
> Jaco
> 
> 

if libunwind can be used, you should use this dep

elibc_musl? ( sys-libs/libunwind:= )

but idk if it's usable as is on musl.
best way to check is to get musl stage3 tarball and test it.
alpine does have a musl patch, but it seems they just patch it out completely.
https://git.alpinelinux.org/aports/tree/main/dahdi-tools/fix-musl.patch



-- 
Georgy Yakovlev 


pgpb0FaDXw7ig.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH] metadata/policy.conf: Introduce QA check configuration

2020-02-26 Thread Georgy Yakovlev
On Wed, 26 Feb 2020 11:23:49 +0100
Michał Górny  wrote:

> Introduce a new configuration file for assigning QA check significance
> levels to PG policies.  Long-term goal is that this will permit
> unified configuration of various QA tools, including pkgcheck, repoman
> and install-qa-check.d.
> 
> Signed-off-by: Michał Górny 
> ---
>  metadata/policy.conf | 61 
>  1 file changed, 61 insertions(+)
>  create mode 100644 metadata/policy.conf
> 
> diff --git a/metadata/policy.conf b/metadata/policy.conf
> new file mode 100644
> index ..824598063cc1
> --- /dev/null
> +++ b/metadata/policy.conf
> @@ -0,0 +1,61 @@
> +# Copyright 2020 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# The policy section assigns significance levels to various policies.
> +# Keys are identifiers from the Policy Guide, values are either
> +# 'notice', 'warninging' or 'error'.
extra ing here
> +#
> +# The rule of thumb is that 'error' indicates a serious problem that
> +# may cause serious problem to the end users and therefore should block
> +# committing / deployment.  'Warning' should be fixed by developer
capital W probably should be w
> +# but does not need to immediately prevent committing.
> +#
> +# https://projects.gentoo.org/qa/policy-guide/std-policy-index.html
> +

Looks really interesting.
Will overlays be able to define their own policy ?
Maybe rename file to metadata/qa-policy.conf ? just policy.conf is ambiguous.

-- 
Georgy Yakovlev 



Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check

2020-02-13 Thread Georgy Yakovlev
On Thu, 13 Feb 2020 08:11:09 -0800
Christopher Head  wrote:

> On Wed, 12 Feb 2020 23:39:11 -0800
> Georgy Yakovlev  wrote:
> 
> > +   eqawarn "For more details, please see the
> > freedesktop Upstrem Metadate guidelines"  
> 
> Couple of typos here: s/Upstrem/Upstream/, s/Metadate/Metadata/.

Thanks!
Fixed and pushed now.

Tracker bug is https://bugs.gentoo.org/709450


pgpaI8vnwCbLs.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check

2020-02-12 Thread Georgy Yakovlev
this will warn if package installs xml files to /usr/share/appdata
this location is deprecated, files should be installed to
/usr/share/metainfo

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html

Signed-off-by: Georgy Yakovlev 
---
 metadata/install-qa-check.d/60appdata-path | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 metadata/install-qa-check.d/60appdata-path

diff --git a/metadata/install-qa-check.d/60appdata-path 
b/metadata/install-qa-check.d/60appdata-path
new file mode 100644
index 000..c4878949b0e
--- /dev/null
+++ b/metadata/install-qa-check.d/60appdata-path
@@ -0,0 +1,33 @@
+# Copyright 2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that metadata files are installed in /usr/share/metainfo
+# Maintainer: Georgy Yakovlev 
+
+appdata_path_check() {
+   [[ -d ${ED%/}/usr/share/appdata ]] || return
+
+   local found=() f
+   while read -d '' -r f; do
+   found+=( "${f%/*}" )
+   done < <(find "${ED%/}/usr/share/appdata" -name '*.xml' -print0 || die)
+
+   if [[ ${found[@]} ]]; then
+   eqawarn
+   eqawarn "This package seems to install metainfo files into the 
following"
+   eqawarn "location(s):"
+   eqawarn
+   eqatag -v appdata.invalid-path "${found[@]#${D%/}}"
+   eqawarn
+   eqawarn "This location is deprecated, it should not be used 
anymore by new software"
+   eqawarn "Appdata/Metainfo files should be installed into 
/usr/share/metainfo directory"
+   eqawarn "For more details, please see the freedesktop Upstrem 
Metadate guidelines"
+   eqawarn 
"https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html;
+   eqawarn
+   fi
+}
+
+appdata_path_check
+: # guarantee successful exit
+
+# vim:ft=sh
-- 
2.25.0




Re: [gentoo-dev] Last rites: virtual/cargo

2020-01-27 Thread Georgy Yakovlev
On Mon, 27 Jan 2020 10:48:51 +0100
David Seifert  wrote:

> On Sun, 2020-01-26 at 21:53 -0500, Michael Orlitzky wrote:
> > On 1/26/20 9:46 PM, Georgy Yakovlev wrote:
> > > # update your rust packages running emerge with the
> > > # --changed-deps option if you have problems
> > 
> > If this advice helps, you have violated the PMS.
> > 
> 
> Agreed, if possible revbump any critical ebuilds, so we can avoid the
> virtual/pam disaster this time round.
> 
> 

All critical explicit consumers switched a while ago (mozilla & co).

Consumers via eclass switched about 1 month ago.

I considered revbumps, there were 44 ebuilds and 23 unique
packages,about half of that with stable keywords.
not that much, it's not pam after all. I did bump some meanwhile.
There will be no disaster.


pgpoJ8exDAmlk.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: virtual/cargo

2020-01-26 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-01-26)
# Not needed anymore, feel free to remove from your system
# emerge -C virtual/cargo
# update your rust packages running emerge with the
# --changed-deps option if you have problems
# https://bugs.gentoo.org/695698
virtual/cargo


pgpq8isLKhJsg.pgp
Description: OpenPGP digital signature


[gentoo-dev] Last rites: www-plugins/passff

2020-01-26 Thread Georgy Yakovlev
# Georgy Yakovlev  (2020-01-26)
# Starting with Firefox 74 Mozilla removes xpi sideloading support
# install from addons.mozilla.org
# passff-host remains in the tree
www-plugins/passff


pgpMRWkCmo2fK.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-06 Thread Georgy Yakovlev
On Friday, December 6, 2019 3:44:38 PM PST Sergei Trofimovich wrote:
> On Fri,  6 Dec 2019 12:09:31 -0800
> 
> Georgy Yakovlev  wrote:
> > Default output just prints crate name.
> > With -vv we can see all cargo options and rustc args.
> > 
> > Signed-off-by: Georgy Yakovlev 
> > ---
> 
> Looks good!
> 
> I had to do an equivalent locally at least a few times.
Pushed!
> 
> While at it I also suggest adding equivalent of
> econf's/emake's ${EXTRA_ECONF} and ${EXTRA_EMAKE}
> to allow users to inject arbitrary stuff. For example
> to sneak in '-Z' options globally.
> 
> Say, ${CARGO_BUILD_EXTRA},  ${CARGO_INSTALL_EXTRA},
> ${CARGO_TEST_EXTRA}.
> 

Yeah, it's on my to-do list for this eclass.
1 question tho, should it come after "$@" or before? Do you use it?
I know cargo can be picky about order and some ebuilds rely on passing params 
in phase funcs.




signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH] cargo.eclass: use verbose cargo invocations

2019-12-06 Thread Georgy Yakovlev
Default output just prints crate name.
With -vv we can see all cargo options and rustc args.

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 5b6d1f050f1..13dd5c355fb 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -146,7 +146,7 @@ cargo_src_compile() {
 
export CARGO_HOME="${ECARGO_HOME}"
 
-   cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo build -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo build failed"
 }
 
@@ -156,7 +156,7 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug 
--debug "") "$@" \
+   cargo install -vv -j $(makeopts_jobs) --root="${ED}/usr" $(usex debug 
--debug "") "$@" \
|| die "cargo install failed"
rm -f "${ED}/usr/.crates.toml"
 
@@ -169,7 +169,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo test -vv -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo test failed"
 }
 
-- 
2.23.0




Re: [gentoo-dev] Last rites: app-misc/rq, net-news/newsboat

2019-12-02 Thread Georgy Yakovlev
On Monday, December 2, 2019 11:53:58 AM PST Zoltan Puskas wrote:
> On Mon, Dec 02, 2019 at 11:10:52AM -0800, Georgy Yakovlev wrote:
... 
> 
> Let me know if you need some help maintaining newsboat, I'm willing to proxy
> maintain it, with you being the primary owner of the ebuild.
> 
Feel free to submit a PR on github next time there's a version bump, with a 
version bump and metadata.xml update, I appreciate the help.

> > also I use rq from time to time, I'll see if I can take it over and remove
> > mask if I decide to take it.
> 
> Zoltan








Re: [gentoo-dev] Last rites: app-misc/rq, net-news/newsboat

2019-12-02 Thread Georgy Yakovlev
On Sunday, December 1, 2019 1:27:34 PM PST Michał Górny wrote:
> # Michał Górny  (2019-12-01)
> # Unmaintained Rust packages with incorrect license information.
> # Removal in 30 days.  Bug #694414.
> app-misc/rq
> net-news/newsboat

I recently took over newsboat, just did not have enough time to push updated 
ebuild, will commit and unmask later today.

also I use rq from time to time, I'll see if I can take it over and remove 
mask if I decide to take it.

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] packages up for grabs

2019-11-18 Thread Georgy Yakovlev
On 11/18/19 4:47 PM, Tim Harder wrote:

Taken:
app-arch/pigz
net-news/newsboat
app-misc/binwalk
net-misc/proxychains
dev-vcs/tig (with chutzpah)

I already maintain this:
sys-apps/ripgrep
net-irc/weechat
app-misc/skim



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 3/3] cargo.eclass: use verbose cargo invocation

2019-10-25 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index dc031623067..940096ea230 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -115,8 +115,8 @@ cargo_live_src_unpack() {
mkdir -p "${S}" || die
 
pushd "${S}" > /dev/null || die
-   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
-   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+   CARGO_HOME="${ECARGO_HOME}" cargo -vv fetch || die
+   CARGO_HOME="${ECARGO_HOME}" cargo -vv vendor "${ECARGO_VENDOR}" || die
popd > /dev/null || die
 
cargo_gen_config
@@ -146,7 +146,7 @@ cargo_src_compile() {
 
export CARGO_HOME="${ECARGO_HOME}"
 
-   cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo -vv build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo build failed"
 }
 
@@ -156,7 +156,7 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug 
--debug "") "$@" \
+   cargo -vv install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug 
--debug "") "$@" \
|| die "cargo install failed"
rm -f "${D}/usr/.crates.toml"
 
@@ -169,7 +169,7 @@ cargo_src_install() {
 cargo_src_test() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   cargo -vv test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo test failed"
 }
 
-- 
2.23.0




[gentoo-dev] RFC: cargo.eclass changes and virtual/cargo retirement

2019-10-25 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/695698




[gentoo-dev] [PATCH 1/3] cargo.eclass: do not use virtual/cargo anymore

2019-10-25 Thread Georgy Yakovlev
Bug: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 44d11cdb838..dc031623067 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -14,14 +14,14 @@ _CARGO_ECLASS=1
 
 if [[ ${PV} == ** ]]; then
# we need at least this for cargo vendor subommand
-   CARGO_DEPEND=">=virtual/cargo-1.37.0"
+   RUST_DEPEND=">=virtual/rust-1.37.0"
 else
-   CARGO_DEPEND="virtual/cargo"
+   RUST_DEPEND="virtual/rust"
 fi
 
 case ${EAPI} in
-   6) DEPEND="${CARGO_DEPEND}";;
-   7) BDEPEND="${CARGO_DEPEND}";;
+   6) DEPEND="${RUST_DEPEND}";;
+   7) BDEPEND="${RUST_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-- 
2.23.0




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

2019-10-25 Thread Georgy Yakovlev
not used anymore

Closes: https://bugs.gentoo.org/695698
Signed-off-by: Georgy Yakovlev 
---
 virtual/cargo/cargo-1.34.2.ebuild | 17 -
 virtual/cargo/cargo-1.35.0.ebuild | 17 -
 virtual/cargo/cargo-1.36.0.ebuild | 17 -
 virtual/cargo/cargo-1.37.0.ebuild | 17 -
 virtual/cargo/cargo-1.38.0.ebuild | 17 -
 virtual/cargo/metadata.xml|  8 
 6 files changed, 93 deletions(-)
 delete mode 100644 virtual/cargo/cargo-1.34.2.ebuild
 delete mode 100644 virtual/cargo/cargo-1.35.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.36.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.37.0.ebuild
 delete mode 100644 virtual/cargo/cargo-1.38.0.ebuild
 delete mode 100644 virtual/cargo/metadata.xml

diff --git a/virtual/cargo/cargo-1.34.2.ebuild 
b/virtual/cargo/cargo-1.34.2.ebuild
deleted file mode 100644
index 032ae4f274f..000
--- a/virtual/cargo/cargo-1.34.2.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="amd64 ~arm64 ~ppc64 x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.35.0.ebuild 
b/virtual/cargo/cargo-1.35.0.ebuild
deleted file mode 100644
index 2c015c4a0d9..000
--- a/virtual/cargo/cargo-1.35.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.36.0.ebuild 
b/virtual/cargo/cargo-1.36.0.ebuild
deleted file mode 100644
index 5e737019292..000
--- a/virtual/cargo/cargo-1.36.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 ~arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.37.0.ebuild 
b/virtual/cargo/cargo-1.37.0.ebuild
deleted file mode 100644
index 631c2ccb793..000
--- a/virtual/cargo/cargo-1.37.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="amd64 arm64 ppc64 x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/cargo-1.38.0.ebuild 
b/virtual/cargo/cargo-1.38.0.ebuild
deleted file mode 100644
index 5e737019292..000
--- a/virtual/cargo/cargo-1.38.0.ebuild
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 1999-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-EAPI=7
-
-DESCRIPTION="Package manager for Rust"
-HOMEPAGE=""
-SRC_URI=""
-
-LICENSE=""
-SLOT="0"
-KEYWORDS="~amd64 ~arm64 ~ppc64 ~x86"
-
-RDEPEND="|| (
-   =dev-lang/rust-${PV}*
-   =dev-lang/rust-bin-${PV}*
-   )"
diff --git a/virtual/cargo/metadata.xml b/virtual/cargo/metadata.xml
deleted file mode 100644
index 85cf4eb9205..000
--- a/virtual/cargo/metadata.xml
+++ /dev/null
@@ -1,8 +0,0 @@
-
-http://www.gentoo.org/dtd/metadata.dtd;>
-
-  
-r...@gentoo.org
-Rust Project
-  
-
-- 
2.23.0




[gentoo-dev] [PATCH] 2019-09-11-cpu_flags_ppc-introduction: new item

2019-09-11 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 ...19-09-11-cpu_flags_ppc-introduction.en.txt | 38 +++
 1 file changed, 38 insertions(+)
 create mode 100644 
2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt

diff --git 
a/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt
 
b/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt
new file mode 100644
index 000..a4a4ee5
--- /dev/null
+++ 
b/2019-09-11-cpu_flags_ppc-introduction/2019-09-11-cpu_flags_ppc-introduction.en.txt
@@ -0,0 +1,38 @@
+Title: new CPU_FLAGS_PPC USE_EXPAND
+Author: Georgy Yakovlev 
+Posted: 2019-09-11
+Revision: 1
+News-Item-Format: 2.0
+Display-If-Keyword: ~ppc
+Display-If-Keyword: ~ppc64
+Display-If-Keyword: ppc
+Display-If-Keyword: ppc64
+
+
+A new set of CPU_FLAGS_PPC USE_EXPAND flags has been added.
+The flags are:
+
+  altivec - Use the AltiVec/VMX instruction set
+  vsx - Use the Vector Scalar Extension instruction set
+  vsx3 - Use the Vector Scalar Extension v.3 instruction set
+
+Note that CPU_FLAGS_PPC variable is used on ppc and ppc64 architectures.
+
+In order to transition to new set of flags, if the following flag was
+was present:
+ 
+  USE="altivec"
+
+This flag needs to be set as:
+
+  CPU_FLAGS_PPC="altivec"
+
+It's advised to keep 'altivec' USE flag enabled to ensure safe
+migration and compatibility with external repositories.
+'vsx' and 'vsx3' are new flags and no migration necessary.
+
+To help users enable the correct USE_EXPAND flags PPC support has been
+added to app-portage/cpuid2cpuflags package:
+
+  # emerge -1v >=app-portage/cpuid2cpuflags-7
+  $ cpuid2cpuflags
-- 
2.23.0




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

2019-09-11 Thread Georgy Yakovlev
On 9/10/19 12:44 PM, 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:
> 
> wget https://dev.gentoo.org/~mgorny/dist/cpuid2cpuflags-7-dev.tar.bz2
> tar -xf cpuid2cpuflags-7-dev.tar.bz2
> cd cpuid2cpuflags-7-dev
> ./configure
> make hwcap-dump
> ./hwcap-dump
> 
> and send me the output along with 'uname -m'.  TIA!
> 


couple of boards here


== rockpro64
Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53)

$ uname -m
aarch64

$ ./hwcap-dump
hwcap:08ff
hwcap2:

./cpuid2cpuflags
CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 aes sha1 sha2
crc32 v4 v5 v6 v7 v8 thumb2


cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4


diff -U0 <(./cpuid2cpuflags | tr ' ' '\n' | sed 1d |sort) <(grep -m1
Features /proc/cpuinfo | tr ' ' '\n' | sed 1d | grep '.' |sort)
--- /dev/fd/63  2019-09-11 09:57:36.360796732 -0700
+++ /dev/fd/62  2019-09-11 09:57:36.364130054 -0700
@@ -1,0 +2,2 @@
+asimd
+cpuid
@@ -3,2 +5,3 @@
-edsp
-neon
+evtstrm
+fp
+pmull
@@ -7,11 +9,0 @@
-thumb
-thumb2
-v4
-v5
-v6
-v7
-v8
-vfp
-vfp-d32
-vfpv3
-vfpv4





== Odroid N2
Amlogic S922X (4x Cortex-A73 @ 1.8GHz, 2x Cortex-A53 @ 1.9GHz)

$ uname -m
aarch64

$ ./hwcap-dump
hwcap:00ff
hwcap2:

CPU_FLAGS_ARM: edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 aes sha1 sha2
crc32 v4 v5 v6 v7 v8 thumb2

cpuinfo
processor   : 0
BogoMIPS: 48.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part: 0xd03
CPU revision: 4

CPU info: 290a41200e01313254524d50
Serial  : .
Hardware: Hardkernel ODROID-N2
Revision: 0400


diff -U0 <(./cpuid2cpuflags | tr ' ' '\n' | sed 1d |sort) <(grep -m1
Features /proc/cpuinfo | tr ' ' '\n' | sed 1d | grep '.' |sort)
--- /dev/fd/63  2019-09-11 09:59:59.616633443 -0700
+++ /dev/fd/62  2019-09-11 09:59:59.616633443 -0700
@@ -1,0 +2 @@
+asimd
@@ -3,2 +4,3 @@
-edsp
-neon
+evtstrm
+fp
+pmull
@@ -7,11 +8,0 @@
-thumb
-thumb2
-v4
-v5
-v6
-v7
-v8
-vfp
-vfp-d32
-vfpv3
-vfpv4




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: go 1.13 and go modules

2019-09-09 Thread Georgy Yakovlev
On Monday, September 9, 2019 2:46:16 PM PDT William Hubbs wrote:
> On Tue, Sep 10, 2019 at 08:35:17AM +1200, Kent Fredric wrote:
> > On Mon, 9 Sep 2019 12:34:18 -0500
> > 
> > William Hubbs  wrote:
> > > There is another option I want to try which is adding "go mod vendor" to
> > > src_unpack for go packages.
> > 
> > Is it infeasible to write a tool that you execute as a maintainer, that
> > simulates what "go mod vendor" would do, but instead emits a list of
> > entries for SRC_URI, and then have an eclass or something construct the
> > vendor dir from those?
> > 
> > That's what is available for rust stuff.
> 
> I'm not sure how feasible something like that is.
> 
> $ go list -m all
> 
> will list the dependencies of a module, but that doesn't look like it
> can be translated into src_uri format.
> 
> You would basically have to parse go.mod exactly the way upstream does
> it and come up with a way to download the correct versions of the
> source.
> 
> William

check mail-client/aerc ebuild.
I use "go list -m all" and manually format EGO_VENDOR string which will be 
translated into SRC_URI by eclass.
tool is certainly possible and should be quite easy to implement.
some manual editing will still be needed if dealing with forked packages/
repos, but looks pretty straightforward.
This is very similar approach to cargo ebuilds and it supports offline 
installs, PM checksumming and does not require packaging every single go 
dependency as a package.



signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH] tmpfiles.eclass: fix @USAGE to not include function name

2019-09-06 Thread Georgy Yakovlev
On Friday, September 6, 2019 11:52:53 AM PDT Michael Everitt wrote:
> On 06/09/19 18:27, Ben Kohler wrote:
> 
> This series seems super counter-intuitive to me .. surely all usage
> examples (in Linux/etc in general) utilise the command itself to provide
> context of how to invoke the function/etc ?? or am I [once again] mistaken?
> 
> Perhaps the series should be to *add* the function across the tree, rather
> than remove it?

Command itself is already added by magic awk, Ben just removing duplicates.

for example, desktop eclass man page right now

make_desktop_entry make_desktop_entry(, [name], [icon], [type]...

after the change

make_desktop_entry (, [name], [icon], [type], [fields])



check app-doc/eclass-manpages awk magic file how the pages are generated.

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
On 8/30/19 11:29 PM, Michał Górny wrote:
> On Sat, 2019-08-31 at 00:19 -0700, Georgy Yakovlev wrote:
>> On 8/30/19 11:11 PM, Michał Górny wrote:
>>> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:
>> 
>>>> +altivec - Use the AltiVec instruction set
>>>> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
>>>> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
>>>> later)
>>>
>>> Do all those flags have real use cases in ::gentoo?  I'd really prefer
>>> not having more 'unused flag' warnings ;-).
>>>
>>
>> yeah, I have mentioned possible users above and there are plenty I
>> haven't identified yet. patches to ebuilds will follow, I promise =)
>>
>> for example x264 if built with proper flags gives a noticeable boost,
>> (at least 2x at encoding), totally worth it.
>>
>> ppc will not have a lot of flags like on arm or x86, maybe a couple
>> more, but that's it for now.
>>
> 
> Just to be clear: we're not talking about -m compiler flags, are we? 
> 'cause those should be handled via CFLAGS.
> 

of course not just compiler flags, that's clear.

for example libpng has --enable-powerpc-vsx ./configure flag, and build
system will do it's black magic with intrinsics if it's passed.



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
On 8/30/19 11:11 PM, Michał Górny wrote:
> On Sat, 2019-08-31 at 00:03 -0700, Georgy Yakovlev wrote:

>> +altivec - Use the AltiVec instruction set
>> +vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
>> +vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and 
>> later)
> 
> Do all those flags have real use cases in ::gentoo?  I'd really prefer
> not having more 'unused flag' warnings ;-).
> 

yeah, I have mentioned possible users above and there are plenty I
haven't identified yet. patches to ebuilds will follow, I promise =)

for example x264 if built with proper flags gives a noticeable boost,
(at least 2x at encoding), totally worth it.

ppc will not have a lot of flags like on arm or x86, maybe a couple
more, but that's it for now.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] PATCH: add CPU_FLAGS_PPC USE_EXPAND

2019-08-31 Thread Georgy Yakovlev
Possible users from the tree: 
  altivec useflag consumers (many)
  media libraries (x264, x265, libpng and others.)

also firefox-70[1] will have auto-detection of features but we may want to
prevent automagic optimizations.


cpuid2cpuflags support[2] is ready and and will be merged soon,
so users will have a gentoo-way of setting those flags.


And this patch in github PR[3] format for easy viewing

[1] https://hg.mozilla.org/mozilla-central/rev/252643ff91c5
[2] https://github.com/mgorny/cpuid2cpuflags/pull/13
[3] https://github.com/gentoo/gentoo/pull/12829





[gentoo-dev] [PATCH 1/2] profiles/desc: descriptions for CPU_FLAGS_PPC use_expand

2019-08-31 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 profiles/desc/cpu_flags_ppc.desc | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 profiles/desc/cpu_flags_ppc.desc

diff --git a/profiles/desc/cpu_flags_ppc.desc b/profiles/desc/cpu_flags_ppc.desc
new file mode 100644
index 000..abd2434c4f5
--- /dev/null
+++ b/profiles/desc/cpu_flags_ppc.desc
@@ -0,0 +1,6 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+altivec - Use the AltiVec instruction set
+vsx - Use the Vector Scalar Extension instruction set (POWER7 and later)
+vsx3 - Use the Vector Scalar Extension v.3 instruction set (POWER9 and later)
-- 
2.23.0




[gentoo-dev] [PATCH 2/2] profiles: Add CPU_FLAGS_PPC to USE_EXPAND

2019-08-31 Thread Georgy Yakovlev
hide everywhere, and unhide in top level powerpc profile

Signed-off-by: Georgy Yakovlev 
---
 profiles/arch/powerpc/make.defaults | 9 +
 profiles/base/make.defaults | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 profiles/arch/powerpc/make.defaults

diff --git a/profiles/arch/powerpc/make.defaults 
b/profiles/arch/powerpc/make.defaults
new file mode 100644
index 000..8613dd7619e
--- /dev/null
+++ b/profiles/arch/powerpc/make.defaults
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# All extra USE/etc should be specified in sub-profiles.
+# DO NOT POLLUTE USE ON THIS PROFILE.
+
+# Georgy Yakovlev 

[gentoo-dev] [PATCH] cargo.eclass: add cargo_live_src_unpack()

2019-08-28 Thread Georgy Yakovlev
This function will allow using 'cargo fetch' during src_fetch
Since only new cargo supports that, all live packages will
have to depend on >=rust-1.37.0

This enables us to ship live rust packages,
cargo fetch will download all crates and vendor them for offline
phases.

here's an example of src_unpack()

src_unpack() {
if [[ "${PV}" == ** ]]; then
git-r3_src_unpack
cargo_live_src_unpack
else
cargo_src_unpack
fi
}

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index b16e0e9d633..44d11cdb838 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -12,7 +12,12 @@
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
-CARGO_DEPEND="virtual/cargo"
+if [[ ${PV} == ** ]]; then
+   # we need at least this for cargo vendor subommand
+   CARGO_DEPEND=">=virtual/cargo-1.37.0"
+else
+   CARGO_DEPEND="virtual/cargo"
+fi
 
 case ${EAPI} in
6) DEPEND="${CARGO_DEPEND}";;
@@ -97,6 +102,26 @@ cargo_src_unpack() {
cargo_gen_config
 }
 
+# @FUNCTION: cargo_live_src_unpack
+# @DESCRIPTION:
+# Runs 'cargo fetch' and vendors downloaded crates for offline use, used in 
live ebuilds
+
+cargo_live_src_unpack() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   [[ "${PV}" == ** ]] || die "${FUNCNAME} only allowed in live/ 
ebuilds"
+   [[ "${EBUILD_PHASE}" == unpack ]] || die "${FUNCNAME} only allowed in 
src_unpack"
+
+   mkdir -p "${S}" || die
+
+   pushd "${S}" > /dev/null || die
+   CARGO_HOME="${ECARGO_HOME}" cargo fetch || die
+   CARGO_HOME="${ECARGO_HOME}" cargo vendor "${ECARGO_VENDOR}" || die
+   popd > /dev/null || die
+
+   cargo_gen_config
+}
+
 # @FUNCTION: cargo_gen_config
 # @DESCRIPTION:
 # Generate the $CARGO_HOME/config necessary to use our local registry
-- 
2.23.0




[gentoo-dev] Packages up for grabs: dev-java/oracle-jdk-bin, dev-java/oracle-jre-bin

2019-08-18 Thread Georgy Yakovlev
All future versions masked, unmaintained, multiple security bugs, the
most important bug is a possible serious license violation[1] that puts
users into legal trouble.

nobody in java team maintains it, so if you want to keep it - please
take care of it.

Current tarballs no longer accessible, downloading new ones requires
oracle account and agreement to new license, which is in effect since
April 2019
New license seems to be ok for home or development use, but IANAL.



general discussion bug still open:
https://bugs.gentoo.org/681828


PS. Personally I'd drop it, but it was discussed before[2] and some
people expressed strong opinion of keeping it outside of java team.

[1]https://bugs.gentoo.org/692420
[2]https://archives.gentoo.org/gentoo-dev/message/ed6b0e3c3ac174aba972d2a436ab252f



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: sys-kernel/bliss-initramfs

2019-08-17 Thread Georgy Yakovlev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

# Georgy Yakovlev  (2019-08-17)
# Unmaintained both upstream and in gentoo, author retired
# Removal in 30 days
sys-kernel/bliss-initramfs


@fearedbliss retired a while ago.
upstream page[1] litreally says:
"This project is no longer in development. Please fork. Thank you."

[1] https://github.com/fearedbliss/bliss-initramfs
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3NQc5d2Nq7vhc9JNonLI8BUSnVIFAl1YqmMACgkQonLI8BUS
nVLA0RAAwYSUQAJ+H6ITlUSEJjatpjPfiAZg+zq1q9E24Lt4pwNGTGFlfzyYnUjg
oSkUxjXbi8jsrIvc0FDdQy+HcGP7HyVA24iSeQ5D3aJahpDNmrxGQI7098lLmhWv
xXGVyEbJWz2T00/l2pLZnJgpXKpxgtMUeKLxR+hSOc1Iq5O7W1o1KKM2LP9VeHdH
oSMyCt5BNOaz3eMwdEDdMMGTE6ucz5nrl5OUvI83fNpuVAokgLytX4wEGN/a4Fb6
gFjoafljFJPDt5+6HN0XcwcnEq8IBkAHupS/9cp/oan+2U77Vf346ysoqghYuMhr
3TSlVooktfmEMeq/462q4W0TI6lQFzTppqWQMFNPA190LmkbW/TJ5rG8PjO9uraY
lAkWyU201LqXO+jBe+eHPZ0iRr1Y9vRuQRLGQEmJleM2/OnO9zyB/7TaKXtxzhsc
acrn12kNMl/bz88WEaAei42Isie0ScWMNSpmgr+IrAhZU8urZXKwSPv+ov0wTBr7
i+bIVuRgEWYwdXYZQ7awBRhWfh+oel8/7o4/kmPFXkVlT2GtPOAq1KQHQzGKT/4e
2l6zbxmP79RsGNVqfaZr/EDqWR/2F+PqvpxRn1j91oS1X29aBM2swIM+WeULr/ZU
8DK1r+F59pE/JSJ8bDXQKHnkw/NYih7IaS7bBdxxOGiSqr7j2jw=
=gPMW
-END PGP SIGNATURE-



Re: [gentoo-dev] mark ppc64le profiles stable

2019-08-15 Thread Georgy Yakovlev
On Thursday, August 15, 2019 1:32:28 AM PDT Georgy Yakovlev wrote:
> Let's mark ppc64le profiles stable.
> It passes CI https://github.com/gentoo/gentoo/pull/12711
> 
> Regards, Georgy.

pushed.

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH 3/3] profiles/profiles.desc: mark ppc64le profiles stable

2019-08-15 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 profiles/profiles.desc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/profiles/profiles.desc b/profiles/profiles.desc
index afafbf39dea..d9384010e59 100644
--- a/profiles/profiles.desc
+++ b/profiles/profiles.desc
@@ -159,8 +159,8 @@ ppc64   
default/linux/powerpc/ppc64/17.0/64bit-userland/desktop
 ppc64   default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome  
 stable
 ppc64   
default/linux/powerpc/ppc64/17.0/64bit-userland/desktop/gnome/systemd   stable
 ppc64   default/linux/powerpc/ppc64/17.0/64bit-userland/developer  
 stable
-ppc64  default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian   
exp
-ppc64  
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd   exp
+ppc64  default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian   
stable
+ppc64  
default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd   stable
 
 # RISC-V Profiles
 # @MAINTAINER: ri...@gentoo.org
-- 
2.22.1




[gentoo-dev] [PATCH 2/3] profiles: add eapi=5 to ppc64/17.0/64bit-userland/little-endian/systemd

2019-08-15 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 .../powerpc/ppc64/17.0/64bit-userland/little-endian/systemd/eapi | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 
profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd/eapi

diff --git 
a/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd/eapi
 
b/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd/eapi
new file mode 100644
index 000..7ed6ff82de6
--- /dev/null
+++ 
b/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/systemd/eapi
@@ -0,0 +1 @@
+5
-- 
2.22.1




[gentoo-dev] mark ppc64le profiles stable

2019-08-15 Thread Georgy Yakovlev
Let's mark ppc64le profiles stable.
It passes CI https://github.com/gentoo/gentoo/pull/12711

Regards, Georgy.





[gentoo-dev] [PATCH 1/3] profiles: add eapi=5 to ppc64/17.0/64bit-userland/little-endian

2019-08-15 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 .../linux/powerpc/ppc64/17.0/64bit-userland/little-endian/eapi   | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 
profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/eapi

diff --git 
a/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/eapi 
b/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/eapi
new file mode 100644
index 000..7ed6ff82de6
--- /dev/null
+++ 
b/profiles/default/linux/powerpc/ppc64/17.0/64bit-userland/little-endian/eapi
@@ -0,0 +1 @@
+5
-- 
2.22.1




[gentoo-dev] [PATCH 2/3] acct-user/dnscrypt-proxy: new user (UID 353)

2019-07-27 Thread Georgy Yakovlev
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Georgy Yakovlev 
---
 acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild | 12 
 acct-user/dnscrypt-proxy/metadata.xml|  8 
 2 files changed, 20 insertions(+)
 create mode 100644 acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
 create mode 100644 acct-user/dnscrypt-proxy/metadata.xml

diff --git a/acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild 
b/acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
new file mode 100644
index 000..fcce19b0688
--- /dev/null
+++ b/acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
@@ -0,0 +1,12 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="User for net-dns/dnscrypt-proxy"
+ACCT_USER_ID=353
+ACCT_USER_GROUPS=( dnscrypt-proxy )
+
+acct-user_add_deps
diff --git a/acct-user/dnscrypt-proxy/metadata.xml 
b/acct-user/dnscrypt-proxy/metadata.xml
new file mode 100644
index 000..efcd58fe0b9
--- /dev/null
+++ b/acct-user/dnscrypt-proxy/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   gyakov...@gentoo.org
+       Georgy Yakovlev
+   
+
-- 
2.22.0




[gentoo-dev] new UID/GID assignement for dnscrypt-proxy (353)

2019-07-27 Thread Georgy Yakovlev
Second attempt, now using UID/GID 353




[gentoo-dev] [PATCH 1/3] acct-group/dnscrypt-proxy: new group (GID 353)

2019-07-27 Thread Georgy Yakovlev
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Georgy Yakovlev 
---
 acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild | 9 +
 acct-group/dnscrypt-proxy/metadata.xml| 8 
 2 files changed, 17 insertions(+)
 create mode 100644 acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
 create mode 100644 acct-group/dnscrypt-proxy/metadata.xml

diff --git a/acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild 
b/acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
new file mode 100644
index 000..69c780fd796
--- /dev/null
+++ b/acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Group for net-dns/dnscrypt-proxy"
+ACCT_GROUP_ID=353
diff --git a/acct-group/dnscrypt-proxy/metadata.xml 
b/acct-group/dnscrypt-proxy/metadata.xml
new file mode 100644
index 000..efcd58fe0b9
--- /dev/null
+++ b/acct-group/dnscrypt-proxy/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   gyakov...@gentoo.org
+       Georgy Yakovlev
+   
+
-- 
2.22.0




[gentoo-dev] [PATCH 3/3] net-dns/dnscrypt-proxy: update live ebuild, use acct packages

2019-07-27 Thread Georgy Yakovlev
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Georgy Yakovlev 
---
 net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild 
b/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
index 721259c1364..44a5c203f65 100644
--- a/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
+++ b/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
@@ -5,7 +5,7 @@ EAPI=7
 
 EGO_PN="github.com/jedisct1/${PN}"
 
-inherit fcaps golang-build systemd user
+inherit fcaps golang-build systemd
 
 if [[ ${PV} ==  ]]; then
inherit git-r3
@@ -24,14 +24,14 @@ IUSE="pie"
 
 DEPEND=">=dev-lang/go-1.12"
 
+RDEPEND="
+   acct-group/dnscrypt-proxy
+   acct-user/dnscrypt-proxy
+"
+
 FILECAPS=( cap_net_bind_service+ep usr/bin/dnscrypt-proxy )
 PATCHES=( "${FILESDIR}"/config-full-paths-r10.patch )
 
-pkg_setup() {
-   enewgroup dnscrypt-proxy
-   enewuser dnscrypt-proxy -1 -1 /var/empty dnscrypt-proxy
-}
-
 src_prepare() {
default
# Create directory structure suitable for building
-- 
2.22.0




Re: [gentoo-dev] new UID/GID assignement for dnscrypt-proxy (553)

2019-07-27 Thread Georgy Yakovlev
On Saturday, July 27, 2019 12:41:21 AM PDT you wrote:
> Any specific reason for 553?
> 
> I had previously suggested that we stay below 500 as long as there is
> space. On the one hand it would match the LSB better, on the other hand
> we might at some point want to do dynamic allocation counting from 999
> downwards, and keeping the fixed IDs below 500 would reduce the chance
> of collisions.
> 
> Ulrich

Makes sense, I missed the part that range above 500 is reserved, thanks.
No reason except I wanted it to be ?53, because it listens to :53

I can assign to 353, it's unused.

-- 
Best regards,
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 00/12] Use acct-{group,user} for systemd accounts

2019-07-27 Thread Georgy Yakovlev
On Friday, July 26, 2019 10:33:09 PM PDT Michał Górny wrote:
> On Fri, 2019-07-26 at 22:07 -0400, Mike Gilbert wrote:
> > Reference:
> > Mike Gilbert (12):
> >   acct-group/systemd-journal: new group
> >   acct-group/systemd-journal-remote: new group
> >   acct-user/systemd-journal-remote: new user
> >   acct-group/systemd-network: new group
> >   acct-user/systemd-network: new user
> >   acct-group/systemd-resolve: new group
> >   acct-user/systemd-resolve: new user
> >   acct-group/systemd-coredump: new group
> >   acct-user/systemd-coredump: new user
> >   acct-group/systemd-timesync: new group
> >   acct-user/systemd-timesync: new user
> >   sys-apps/systemd: utilize new acct-{group,user} packages
> 
> LGTM.  I see you used some UID/GID values from Fedora which don't match
> the values used in Arch, and both of those sets are incomplete, so
> doesn't really matter.

LGTM as well, since fedora is as close as you can get to systemd upstream 
makes sense to match closely to their IDs which is the case.
-- 
Best regards,
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH 3/3] net-dns/dnscrypt-proxy: update live ebuild, use acct packages

2019-07-26 Thread Georgy Yakovlev
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Georgy Yakovlev 
---
 net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild 
b/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
index 721259c1364..44a5c203f65 100644
--- a/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
+++ b/net-dns/dnscrypt-proxy/dnscrypt-proxy-.ebuild
@@ -5,7 +5,7 @@ EAPI=7
 
 EGO_PN="github.com/jedisct1/${PN}"
 
-inherit fcaps golang-build systemd user
+inherit fcaps golang-build systemd
 
 if [[ ${PV} ==  ]]; then
inherit git-r3
@@ -24,14 +24,14 @@ IUSE="pie"
 
 DEPEND=">=dev-lang/go-1.12"
 
+RDEPEND="
+   acct-group/dnscrypt-proxy
+   acct-user/dnscrypt-proxy
+"
+
 FILECAPS=( cap_net_bind_service+ep usr/bin/dnscrypt-proxy )
 PATCHES=( "${FILESDIR}"/config-full-paths-r10.patch )
 
-pkg_setup() {
-   enewgroup dnscrypt-proxy
-   enewuser dnscrypt-proxy -1 -1 /var/empty dnscrypt-proxy
-}
-
 src_prepare() {
default
# Create directory structure suitable for building
-- 
2.22.0




[gentoo-dev] [PATCH 1/3] acct-group/dnscrypt-proxy: new group (GID 553)

2019-07-26 Thread Georgy Yakovlev
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Georgy Yakovlev 
---
 acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild | 9 +
 acct-group/dnscrypt-proxy/metadata.xml| 8 
 2 files changed, 17 insertions(+)
 create mode 100644 acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
 create mode 100644 acct-group/dnscrypt-proxy/metadata.xml

diff --git a/acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild 
b/acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
new file mode 100644
index 000..5aea3891e54
--- /dev/null
+++ b/acct-group/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
@@ -0,0 +1,9 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+DESCRIPTION="Group for net-dns/dnscrypt-proxy"
+ACCT_GROUP_ID=553
diff --git a/acct-group/dnscrypt-proxy/metadata.xml 
b/acct-group/dnscrypt-proxy/metadata.xml
new file mode 100644
index 000..efcd58fe0b9
--- /dev/null
+++ b/acct-group/dnscrypt-proxy/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   gyakov...@gentoo.org
+       Georgy Yakovlev
+   
+
-- 
2.22.0




[gentoo-dev] new UID/GID assignement for dnscrypt-proxy (553)

2019-07-26 Thread Georgy Yakovlev
Please review.
Will update wiki[1] page after approval.

[1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment

Best regards,
Georgy




[gentoo-dev] [PATCH 2/3] acct-user/dnscrypt-proxy: new user (UID 553)

2019-07-26 Thread Georgy Yakovlev
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Georgy Yakovlev 
---
 acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild | 12 
 acct-user/dnscrypt-proxy/metadata.xml|  8 
 2 files changed, 20 insertions(+)
 create mode 100644 acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
 create mode 100644 acct-user/dnscrypt-proxy/metadata.xml

diff --git a/acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild 
b/acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
new file mode 100644
index 000..d4bbb7e5439
--- /dev/null
+++ b/acct-user/dnscrypt-proxy/dnscrypt-proxy-0.ebuild
@@ -0,0 +1,12 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="User for net-dns/dnscrypt-proxy"
+ACCT_USER_ID=553
+ACCT_USER_GROUPS=( dnscrypt-proxy )
+
+acct-user_add_deps
diff --git a/acct-user/dnscrypt-proxy/metadata.xml 
b/acct-user/dnscrypt-proxy/metadata.xml
new file mode 100644
index 000..efcd58fe0b9
--- /dev/null
+++ b/acct-user/dnscrypt-proxy/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   gyakov...@gentoo.org
+       Georgy Yakovlev
+   
+
-- 
2.22.0




Re: [gentoo-dev] Gentoo-CI can now filter on maintainers (also verbose output)

2019-07-25 Thread Georgy Yakovlev
On Thursday, July 25, 2019 7:05:16 AM PDT Michał Górny wrote:
> Hi,
> 
> Just a quick bit of news on gentoo-ci.
> 
> Firstly, I've implemented support for quiet/verbose reports.  So now
> the default report seen at [1] is not that huge, and if somebody wants
> all the details at [2].
> 

This is great! Now I need to RSS-feed it somehow.

btw, there are some BadRestricts warnings for preserve-libs,
pkgcheck/pkgcore does not support it, but portage does.
Are you leaving this on intentionally?

trivial patch I did sometime ago
https://patch-diff.githubusercontent.com/raw/pkgcore/pkgcheck/pull/75.patch


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Amazon Corretto openjdk builds?

2019-06-26 Thread Georgy Yakovlev
On Wednesday, June 26, 2019 11:03:58 AM PDT Paul B. Henson wrote:
> Is anybody looking at Amazon's new openjdk distribution?
> 
>   https://aws.amazon.com/corretto/
> 
> Advertised as production ready with long term support, no-cost. I'm not
> sure how it compares to the current AdoptJDK builds, but seems like it
> might be another good option.

Hi,

As a maintainer of most jdks in gentoo I'm not looking at adding even more JDK 
versions this time as there is little to no reason of doing that.

adoptopenjdk is open, lts, managed by community and not corporate entity, 
gaining more attention lately. it supports arches amazon doesn't.

the only valuable feature of corretto I can think of is presence of javafx.*,  
but openjdk:8 and openjdk-bin:8 will soon have it as well and we already have  
it for openjdk:11

if there is significant performance or technical difference I could take a 
look at it, so let me know if I'm wrong in my assessment.

- Georgy

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH 0/7] User/group assignment: ftp, mail, postmaster

2019-06-20 Thread Georgy Yakovlev
On Thursday, June 20, 2019 3:11:07 AM PDT Michał Górny wrote:
> Hi,

> 
> Please review.
> 
> [1]
> https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment
> 

it's probably wort adding links to other distro standard UIDs as a reference.

  RHEL[1]
  Fedora[2]
  Arch[3]

[1] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-users-groups-standard-users
[2] https://pagure.io/setup/blob/master/f/uidgid
[3] https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last-rites: dev-util/rustfmt

2019-06-18 Thread Georgy Yakovlev
# Georgy Yakovlev  (17 Jun 2019) 
# this is now provided by dev-lang/rust{-bin}[rustfmt] 
# it's tightly integrated with rust toolchain, eselect-rust
# and it no longer makes sense ship this as standalone pkg
dev-util/rustfmt

-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: Rust flags

2019-05-14 Thread Georgy Yakovlev
On Tuesday, May 14, 2019 3:01:48 PM PDT Andrew Savchenko wrote:
> On Tue, 14 May 2019 11:47:04 -0700 Georgy Yakovlev wrote:
> > On Tuesday, May 14, 2019 9:15:52 AM PDT Andrew Savchenko wrote:
> > > Hi all!
> > > 
> > > Looks like rustc supports target CPU and optlevel options, e.g.
> > > 
> > >   rustc -C target-cpu=skylake -C opt-level=3
> > > 
> > > as well as more fine-grade optimizations.
> > > 
> > > But I see no way to specify them when building rust software.
> > > Am I missing something? Is there any reason for not providing
> > > something like RUSTFLAGS?
> > > 
> > > Best regards,
> > > Andrew Savchenko
> > 
> > Hi,
> > 
> > I have this in make.conf for quite some time.
> > 
> > RUSTFLAGS="-Ctarget-cpu=native -v"
> > 
> > it just works(tm) as you expect it to.
> 
> Well, it does not, at least for me. Right now I'm building
> torbrowser from mozilla overlay and content of RUSTFLAGS from
> make.conf doesn't show up in rustc arguments.
> 
That's something about mozbuild, not the variable itself.
check about:buildconfig page of torbrowser.

RUSTFLAGS show up for me on that page, not 100% sure if they actually get 
applied.

I have no idea how it calls rustc. if it's cargo then to see verbose 
invocations you need to find where the build system calls it and add "-vv"

btw, be careful with -C opt-level=3 for ff or derivatives, it was known to 
cause segfaults some time ago.

for regular packages this variable works fine.

> Moreover there is no mention of RUSTFLAGS in either man rustc or
> rust/cargo eclasses.

because it's a variable used by cargo to call rustc with given params, not by 
rustc itself.

This has nothing to do with eclass, it's cargo setting supposed to be set by 
user.

CARGO-RUSTC(1) page does mention it

more details here:
https://github.com/rust-lang/cargo/blob/master/src/doc/src/reference/
environment-variables.md


> 
> > I remember earlier rustc/cargo were failing if same options specified
> > twice, for example once in toml files and second time via RUSTFLAGS, but
> > I can't reproduce anymore.
> > Maybe it got smarter and RUSTFLAGS actually override whatever is set in
> > toml files.
> > 
> > 
> > -
> > Regards, Georgy
> 
> Best regards,
> Andrew Savchenko




signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: Rust flags

2019-05-14 Thread Georgy Yakovlev
On Tuesday, May 14, 2019 9:15:52 AM PDT Andrew Savchenko wrote:
> Hi all!
> 
> Looks like rustc supports target CPU and optlevel options, e.g.
>   rustc -C target-cpu=skylake -C opt-level=3
> as well as more fine-grade optimizations.
> 
> But I see no way to specify them when building rust software.
> Am I missing something? Is there any reason for not providing
> something like RUSTFLAGS?
> 
> Best regards,
> Andrew Savchenko
Hi,

I have this in make.conf for quite some time.

RUSTFLAGS="-Ctarget-cpu=native -v"

it just works(tm) as you expect it to.

I remember earlier rustc/cargo were failing if same options specified twice, 
for example once in toml files and second time via RUSTFLAGS, but I can't 
reproduce anymore.
Maybe it got smarter and RUSTFLAGS actually override whatever is set in toml 
files.


-
Regards, Georgy

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: abandoned Java libraries

2019-04-26 Thread Georgy Yakovlev
# Patrice Clement  (19 Apr 2019)
# Another round of abandoned Java libraries that must go.
# Removal in 30 days.
dev-java/lucene-analyzers
dev-java/sun-java3d-bin
dev-java/sun-dtdparser
dev-java/stax
app-misc/bfm

Closes: https://github.com/gentoo/gentoo/pull/11739

signature.asc
Description: This is a digitally signed message part.


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

2019-04-17 Thread Georgy Yakovlev
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?

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

[1]https://bugs.gentoo.org/559936
[2]https://www.oracle.com/technetwork/java/javase/terms/license/javase-license.html


-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


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

2019-04-17 Thread Georgy Yakovlev
# 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"
#
# Alternatives: icedtea, icedtea-bin, openjdk, openjdk-bin, openjdk-jre-bin
# removal in 30 days
dev-java/oracle-jdk-bin
dev-java/oracle-jre-bin



signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: app-shells/rust-zshcomp

2019-04-12 Thread Georgy Yakovlev
# Georgy Yakovlev  (11 Apr 2019)
# Rust provides zsh completion.
# This one is old, unmaintained obsolete version.
# Removal in 30 days.
app-shells/rust-zshcomp

-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] util-linux build time increase?

2019-02-21 Thread Georgy Yakovlev
On Thursday, February 21, 2019 1:36:24 AM PST Joshua Kinard wrote:
> Does anyone have an idea why util-linux's build time would go up
> significantly from 2.32.x to 2.33.x?  It may be a MIPS thing, as my x86_64
> box shows no discernible change in build times between the same versions.
> Can any other archs check w/ genlop to see if they see a large jump in build
> time?
> 

This may be related to this bug:
https://bugs.gentoo.org/447970

I have packages ( cpio and tar for example) that take hours to emerge on arm 
boards with FEATURES=sandbox, and couple of minutes without.
./configure getcwd test takes unreasonably long time under sandbox.

don't have util-linux statistics to show.

-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH] opam.eclass: unbreak on EAPI=7

2019-02-04 Thread Georgy Yakovlev
On Monday, February 4, 2019 2:52:37 AM PST Alexis Ballier wrote:
> On Sat,  2 Feb 2019 21:27:29 -0800
> 
> Georgy Yakovlev  wrote:
> > Since D, ED, ROOT, EROOT no longer have a trailing slash in EAPI=7
> > This eclass is terribly broken, installing things into
> > imageusr/...
> 
> You might want to check https://github.com/aballier/ml-overlay
Hi!

I don't really use this eclass in any way.
A user reported breakage, I wrote a patch and submitted here for review.

there is a commit in overlay that adds slashes, but paths will end up having 

// two slashes on EAPI6 and single on EAPI7 

https://github.com/aballier/ml-overlay/commit/
98c0f16bc490349f17afdd7a7675b9b5264d267e

also probably the docdir subdir part of opam_src_install() will  also fail, as 
there are no slashes.


::gentoo version needs some kind of fix as any EAPI7 ebuild that uses 
opam.eclass is broken.

If you are ok with my patches I can commit, just let me know.




signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH] opam.eclass: unbreak on EAPI=7

2019-02-03 Thread Georgy Yakovlev
On Sunday, February 3, 2019 1:01:17 AM PST Sergei Trofimovich wrote:
> On Sat,  2 Feb 2019 21:27:29 -0800
> 
> Georgy Yakovlev  wrote:
> > Since D, ED, ROOT, EROOT no longer have a trailing slash in EAPI=7
> > This eclass is terribly broken, installing things into
> > imageusr/...
> 
> ...
> 
> > opam-installer -i \
> > 
> > -   --prefix="${ED}usr" \
> > +   --prefix="${ED%/}usr" \
> 
> Now this change strips '/' on older EAPIs as well. I guess you meant:
> --prefix="${ED%/}/usr" \
yeah, I missed that in the first version of the patch. second one is ok, 
probably should have posted separately as a non-reply.

-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH] opam.eclass: check only for known EAPI, die otherwise

2019-02-02 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 eclass/opam.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/opam.eclass b/eclass/opam.eclass
index ba4f515f0ec..0342d46553d 100644
--- a/eclass/opam.eclass
+++ b/eclass/opam.eclass
@@ -13,8 +13,8 @@
 # src_install for opam-based packages.
 
 case ${EAPI:-0} in
-0|1|2|3|4) die "You need at least EAPI-5 to use opam.eclass";;
-*) ;;
+   5|6|7) ;;
+*) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
 esac
 
 RDEPEND=">=dev-lang/ocaml-4:="
-- 
2.20.1




[gentoo-dev] [PATCH 2/2] opam.eclass: check only for known EAPI, die otherwise

2019-02-02 Thread Georgy Yakovlev
Signed-off-by: Georgy Yakovlev 
---
 eclass/opam.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/opam.eclass b/eclass/opam.eclass
index 03ffc027641..c742ff7e936 100644
--- a/eclass/opam.eclass
+++ b/eclass/opam.eclass
@@ -1,51 +1,51 @@
 # Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: opam.eclass
 # @MAINTAINER:
 # Gentoo ML Project 
 # @AUTHOR:
 # Alexis Ballier 
 # @SUPPORTED_EAPIS: 5 6 7
 # @BLURB: Provides functions for installing opam packages.
 # @DESCRIPTION:
 # Provides dependencies on opam and ocaml, opam-install and a default
 # src_install for opam-based packages.
 
 case ${EAPI:-0} in
-0|1|2|3|4) die "You need at least EAPI-5 to use opam.eclass";;
-*) ;;
+   5|6|7) ;;
+*) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
 esac
 
 RDEPEND=">=dev-lang/ocaml-4:="
 DEPEND="${RDEPEND}
dev-ml/opam"
 
 # @FUNCTION: opam-install
 # @USAGE: 
 # @DESCRIPTION:
 # Installs the opam packages given as arguments. For each "${pkg}" element in
 # that list, "${pkg}.install" must be readable from current working directory.
 opam-install() {
local pkg
for pkg ; do
opam-installer -i \
--prefix="${ED%/}/usr" \
--libdir="${D%/}/$(ocamlc -where)" \
--docdir="${ED%/}/usr/share/doc/${PF}" \
--mandir="${ED%/}/usr/share/man" \
"${pkg}.install" || die
done
 }
 
 opam_src_install() {
local pkg="${1:-${PN}}"
opam-install "${pkg}"
# Handle opam putting doc in a subdir
if [ -d "${ED%/}/usr/share/doc/${PF}/${pkg}" ] ; then
mv "${ED%/}/usr/share/doc/${PF}/${pkg}/"* 
"${ED%/}/usr/share/doc/${PF}/" || die
rmdir "${ED%/}/usr/share/doc/${PF}/${pkg}" || die
fi
 }
 
 EXPORT_FUNCTIONS src_install
-- 
2.20.1




[gentoo-dev] [PATCH 1/2] opam.eclass: unbreak on EAPI=7

2019-02-02 Thread Georgy Yakovlev
Since D, ED, ROOT, EROOT no longer have a trailing slash in EAPI=7
This eclass is terribly broken, installing things into
imageusr/...

Reported by AnAverageHuman on #gentoo-dev-help

Signed-off-by: Georgy Yakovlev 
---
 eclass/opam.eclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

Sorry, forgot slashes in first version

diff --git a/eclass/opam.eclass b/eclass/opam.eclass
index 5c9c4950dd2..03ffc027641 100644
--- a/eclass/opam.eclass
+++ b/eclass/opam.eclass
@@ -1,51 +1,51 @@
 # Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: opam.eclass
 # @MAINTAINER:
 # Gentoo ML Project 
 # @AUTHOR:
 # Alexis Ballier 
 # @SUPPORTED_EAPIS: 5 6 7
 # @BLURB: Provides functions for installing opam packages.
 # @DESCRIPTION:
 # Provides dependencies on opam and ocaml, opam-install and a default
 # src_install for opam-based packages.
 
 case ${EAPI:-0} in
 0|1|2|3|4) die "You need at least EAPI-5 to use opam.eclass";;
 *) ;;
 esac
 
 RDEPEND=">=dev-lang/ocaml-4:="
 DEPEND="${RDEPEND}
dev-ml/opam"
 
 # @FUNCTION: opam-install
 # @USAGE: 
 # @DESCRIPTION:
 # Installs the opam packages given as arguments. For each "${pkg}" element in
 # that list, "${pkg}.install" must be readable from current working directory.
 opam-install() {
local pkg
for pkg ; do
opam-installer -i \
-   --prefix="${ED}usr" \
-   --libdir="${D}$(ocamlc -where)" \
-   --docdir="${ED}usr/share/doc/${PF}" \
-   --mandir="${ED}usr/share/man" \
+   --prefix="${ED%/}/usr" \
+   --libdir="${D%/}/$(ocamlc -where)" \
+   --docdir="${ED%/}/usr/share/doc/${PF}" \
+   --mandir="${ED%/}/usr/share/man" \
"${pkg}.install" || die
done
 }
 
 opam_src_install() {
local pkg="${1:-${PN}}"
opam-install "${pkg}"
# Handle opam putting doc in a subdir
-   if [ -d "${ED}usr/share/doc/${PF}/${pkg}" ] ; then
-   mv "${ED}usr/share/doc/${PF}/${pkg}/"* 
"${ED}usr/share/doc/${PF}/" || die
-   rmdir "${ED}usr/share/doc/${PF}/${pkg}" || die
+   if [ -d "${ED%/}/usr/share/doc/${PF}/${pkg}" ] ; then
+   mv "${ED%/}/usr/share/doc/${PF}/${pkg}/"* 
"${ED%/}/usr/share/doc/${PF}/" || die
+   rmdir "${ED%/}/usr/share/doc/${PF}/${pkg}" || die
fi
 }
 
 EXPORT_FUNCTIONS src_install
-- 
2.20.1




[gentoo-dev] [PATCH] opam.eclass: unbreak on EAPI=7

2019-02-02 Thread Georgy Yakovlev
Since D, ED, ROOT, EROOT no longer have a trailing slash in EAPI=7
This eclass is terribly broken, installing things into
imageusr/...

Reported by AnAverageHuman on #gentoo-dev-help

Signed-off-by: Georgy Yakovlev 
---
 eclass/opam.eclass | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/eclass/opam.eclass b/eclass/opam.eclass
index 5c9c4950dd2..ba4f515f0ec 100644
--- a/eclass/opam.eclass
+++ b/eclass/opam.eclass
@@ -1,51 +1,51 @@
 # Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: opam.eclass
 # @MAINTAINER:
 # Gentoo ML Project 
 # @AUTHOR:
 # Alexis Ballier 
 # @SUPPORTED_EAPIS: 5 6 7
 # @BLURB: Provides functions for installing opam packages.
 # @DESCRIPTION:
 # Provides dependencies on opam and ocaml, opam-install and a default
 # src_install for opam-based packages.
 
 case ${EAPI:-0} in
 0|1|2|3|4) die "You need at least EAPI-5 to use opam.eclass";;
 *) ;;
 esac
 
 RDEPEND=">=dev-lang/ocaml-4:="
 DEPEND="${RDEPEND}
dev-ml/opam"
 
 # @FUNCTION: opam-install
 # @USAGE: 
 # @DESCRIPTION:
 # Installs the opam packages given as arguments. For each "${pkg}" element in
 # that list, "${pkg}.install" must be readable from current working directory.
 opam-install() {
local pkg
for pkg ; do
opam-installer -i \
-   --prefix="${ED}usr" \
-   --libdir="${D}$(ocamlc -where)" \
-   --docdir="${ED}usr/share/doc/${PF}" \
-   --mandir="${ED}usr/share/man" \
+   --prefix="${ED%/}usr" \
+   --libdir="${D%/}$(ocamlc -where)" \
+   --docdir="${ED%/}usr/share/doc/${PF}" \
+   --mandir="${ED%/}usr/share/man" \
"${pkg}.install" || die
done
 }
 
 opam_src_install() {
local pkg="${1:-${PN}}"
opam-install "${pkg}"
# Handle opam putting doc in a subdir
-   if [ -d "${ED}usr/share/doc/${PF}/${pkg}" ] ; then
-   mv "${ED}usr/share/doc/${PF}/${pkg}/"* 
"${ED}usr/share/doc/${PF}/" || die
-   rmdir "${ED}usr/share/doc/${PF}/${pkg}" || die
+   if [ -d "${ED%/}usr/share/doc/${PF}/${pkg}" ] ; then
+   mv "${ED%/}usr/share/doc/${PF}/${pkg}/"* 
"${ED%/}usr/share/doc/${PF}/" || die
+   rmdir "${ED%/}usr/share/doc/${PF}/${pkg}" || die
fi
 }
 
 EXPORT_FUNCTIONS src_install
-- 
2.20.1




[gentoo-dev] [PATCH 2/2] cargo.eclass: add standard src_test

2019-01-07 Thread Georgy Yakovlev
But not set IUSE=test by default

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 06c85ce9de8..051d5c499a6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -23,7 +23,7 @@ esac
 
 inherit multiprocessing
 
-EXPORT_FUNCTIONS src_unpack src_compile src_install
+EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
 
 IUSE="${IUSE} debug"
 
@@ -139,4 +139,14 @@ cargo_src_install() {
[ -d "${S}/man" ] && doman "${S}/man" || return 0
 }
 
+# @FUNCTION: cargo_src_test
+# @DESCRIPTION:
+# Test the package using cargo test
+cargo_src_test() {
+   debug-print-function ${FUNCNAME} "$@"
+
+   cargo test -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
+   || die "cargo test failed"
+}
+
 fi
-- 
2.20.1




[gentoo-dev] [PATCH 1/2] cargo.eclass: allow passing additional arguments to cargo

2019-01-07 Thread Georgy Yakovlev
for example:

src_compile() {
cargo_src_compile $(usex pcre "--features pcre2" "")"
}

Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 50f7830c51b..06c85ce9de8 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Authors
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: cargo.eclass
@@ -122,7 +122,7 @@ cargo_src_compile() {
 
export CARGO_HOME="${ECARGO_HOME}"
 
-   cargo build -j $(makeopts_jobs) $(usex debug "" --release) \
+   cargo build -j $(makeopts_jobs) $(usex debug "" --release) "$@" \
|| die "cargo build failed"
 }
 
@@ -132,7 +132,7 @@ cargo_src_compile() {
 cargo_src_install() {
debug-print-function ${FUNCNAME} "$@"
 
-   cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug 
--debug "") \
+   cargo install -j $(makeopts_jobs) --root="${D}/usr" $(usex debug 
--debug "") "$@" \
|| die "cargo install failed"
rm -f "${D}/usr/.crates.toml"
 
-- 
2.20.1




Re: [gentoo-dev] [PATCH] cargo.eclass: allow passing additional arguments to cargo

2019-01-06 Thread Georgy Yakovlev
On Thursday, January 3, 2019 1:37:20 AM PST Sergei Trofimovich wrote:
> On Wed,  2 Jan 2019 13:58:26 -0800
> 
> Georgy Yakovlev  wrote:
> > +# @CODE
> > +# ECARGO_BUILD_FLAGS="$(usex pcre "--features pcre2" "")"
> > +# @CODE
> 
> You may also want to provide user's hooks as well.
> 

I have something else brewing for cargo, next time I'll include something like 
this.
 it's nice to have, sure. Thanks for suggestion.

> Similar to EXTRA_ECONF and EXTRA_EMAKE those might be
> ECARGO_EXTRA_BUILD_FLAGS
> ECARGO_EXTRA_INSTALL_FLAGS
> 
> That way user would be able to tweak cargo behaviour without
> breaking ebuild behaviour too much via make.conf/package.env, like
> ECARGO_EXTRA_BUILD_FLAGS=--color=never


-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH 2/2] cargo.eclass: add standard src_test

2019-01-06 Thread Georgy Yakovlev
But not set IUSE=test by default

Signed-off-by: Georgy Yakovlev 
This is pretty straightforward change, just adds standard src_test for
cargo

---
 eclass/cargo.eclass | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ee17f2af9d9..c576c8e8066 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,142 +1,152 @@
 # Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: cargo.eclass
 # @MAINTAINER:
 # r...@gentoo.org
 # @AUTHOR:
 # Doug Goldstein 
 # @SUPPORTED_EAPIS: 6 7
 # @BLURB: common functions and variables for cargo builds
 
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
 CARGO_DEPEND=""
 [[ ${CATEGORY}/${PN} != dev-util/cargo ]] && CARGO_DEPEND="virtual/cargo"
 
 case ${EAPI} in
6) DEPEND="${CARGO_DEPEND}";;
7) BDEPEND="${CARGO_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
 inherit multiprocessing
 
-EXPORT_FUNCTIONS src_unpack src_compile src_install
+EXPORT_FUNCTIONS src_unpack src_compile src_install src_test
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
 cargo_crate_uris() {
local crate
for crate in "$@"; do
local name version url pretag
name="${crate%-*}"
version="${crate##*-}"
pretag="^[a-zA-Z]+"
if [[ $version =~ $pretag ]]; then
version="${name##*-}-${version}"
name="${name%-*}"
fi

url="https://crates.io/api/v1/crates/${name}/${version}/download -> 
${crate}.crate"
echo "${url}"
done
 }
 
 # @FUNCTION: cargo_src_unpack
 # @DESCRIPTION:
 # Unpacks the package and the cargo registry
 cargo_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
 
mkdir -p "${ECARGO_VENDOR}" || die
mkdir -p "${S}" || die
 
local archive shasum pkg
for archive in ${A}; do
case "${archive}" in
*.crate)
ebegin "Loading ${archive} into Cargo registry"
tar -xf "${DISTDIR}"/${archive} -C 
"${ECARGO_VENDOR}/" || die
# generate sha256sum of the crate itself as 
cargo needs this
shasum=$(sha256sum "${DISTDIR}"/${archive} | 
cut -d ' ' -f 1)
pkg=$(basename ${archive} .crate)
cat <<- EOF > 
${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json
{
"package": "${shasum}",
"files": {}
}
EOF
# if this is our target package we need it in 
${WORKDIR} too
# to make ${S} (and handle any revisions too)
if [[ ${P} == ${pkg}* ]]; then
tar -xf "${DISTDIR}"/${archive} -C 
"${WORKDIR}" || die
fi
eend $?
;;
cargo-snapshot*)
ebegin "Unpacking ${archive}"
mkdir -p "${S}"/target/snapshot
tar -xzf "${DISTDIR}"/${archive} -C 
"${S}"/target/snapshot --strip-components 2 || die
# cargo's makefile needs this otherwise it will 
try to
# download it
touch "${S}"/target/snapshot/bin/cargo || die
eend $?
;;
*)
unpack ${archive}
;;
esac
done
 
cargo_gen_config
 }
 
 # @FUNCTION: cargo_gen_config
 # @DESCRIPTION:
 # Generate the $CARGO_HOME/config necessary to use our local registry
 cargo_gen_config() {
debug-print-function ${FUNCNAME} "$@"
 
cat <<- EOF > "${ECARGO_HOME}/config"
[source.gentoo]
directory = "${ECARGO_VENDOR}"
 
[source.crates-io]
replace-with = "gentoo"

[gentoo-dev] [PATCH 1/2] cargo.eclass: allow passing additional arguments to cargo

2019-01-06 Thread Georgy Yakovlev
for example:

src_compile() {
cargo_src_compile $(usex pcre "--features pcre2" "")"
}

Signed-off-by: Georgy Yakovlev 
---
Some packages just copy cargo_src_install and add custom arguments.
This change will allow just passing arguments to cargo_src_* instead.

 eclass/cargo.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 50f7830c51b..ee17f2af9d9 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,142 +1,142 @@
-# Copyright 1999-2018 Gentoo Authors
+# Copyright 1999-2019 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: cargo.eclass
 # @MAINTAINER:
 # r...@gentoo.org
 # @AUTHOR:
 # Doug Goldstein 
 # @SUPPORTED_EAPIS: 6 7
 # @BLURB: common functions and variables for cargo builds
 
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
 CARGO_DEPEND=""
 [[ ${CATEGORY}/${PN} != dev-util/cargo ]] && CARGO_DEPEND="virtual/cargo"
 
 case ${EAPI} in
6) DEPEND="${CARGO_DEPEND}";;
7) BDEPEND="${CARGO_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
 inherit multiprocessing
 
 EXPORT_FUNCTIONS src_unpack src_compile src_install
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
 cargo_crate_uris() {
local crate
for crate in "$@"; do
local name version url pretag
name="${crate%-*}"
version="${crate##*-}"
pretag="^[a-zA-Z]+"
if [[ $version =~ $pretag ]]; then
version="${name##*-}-${version}"
name="${name%-*}"
fi

url="https://crates.io/api/v1/crates/${name}/${version}/download -> 
${crate}.crate"
echo "${url}"
done
 }
 
 # @FUNCTION: cargo_src_unpack
 # @DESCRIPTION:
 # Unpacks the package and the cargo registry
 cargo_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
 
mkdir -p "${ECARGO_VENDOR}" || die
mkdir -p "${S}" || die
 
local archive shasum pkg
for archive in ${A}; do
case "${archive}" in
*.crate)
ebegin "Loading ${archive} into Cargo registry"
tar -xf "${DISTDIR}"/${archive} -C 
"${ECARGO_VENDOR}/" || die
# generate sha256sum of the crate itself as 
cargo needs this
shasum=$(sha256sum "${DISTDIR}"/${archive} | 
cut -d ' ' -f 1)
pkg=$(basename ${archive} .crate)
cat <<- EOF > 
${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json
{
"package": "${shasum}",
"files": {}
}
EOF
# if this is our target package we need it in 
${WORKDIR} too
# to make ${S} (and handle any revisions too)
if [[ ${P} == ${pkg}* ]]; then
tar -xf "${DISTDIR}"/${archive} -C 
"${WORKDIR}" || die
fi
eend $?
;;
cargo-snapshot*)
ebegin "Unpacking ${archive}"
mkdir -p "${S}"/target/snapshot
tar -xzf "${DISTDIR}"/${archive} -C 
"${S}"/target/snapshot --strip-components 2 || die
# cargo's makefile needs this otherwise it will 
try to
# download it
touch "${S}"/target/snapshot/bin/cargo || die
eend $?
;;
*)
unpack ${archive}
;;
esac
done
 
cargo_gen_config
 }
 
 # @FUNCTION: cargo_gen_config
 # @DESCRIPTION:
 # Generate the $CARGO_HOME/config necessary to use our local registry
 cargo_gen_config() {
debug-print-function ${FUNCNAME} "$@"
 
cat <<- EOF > "${ECARGO_HOME}/config"
[source.gentoo]
dire

Re: [gentoo-dev] [PATCH] cargo.eclass: allow passing additional arguments to cargo

2019-01-02 Thread Georgy Yakovlev
On Wednesday, January 2, 2019 8:52:45 PM PST Michał Górny wrote:
> On Wed, 2019-01-02 at 13:58 -0800, Georgy Yakovlev wrote:
> > This adds 2 eclass variables
> > 
> > ECARGO_BUILD_FLAGS
> > ECARGO_INSTALL_FLAGS
> > 
> > contents will be passed to "cargo build" and "cargo install" calls in
> > cargo_src_compile() and cargo_src_install() respectively.
> > 
> > Closes: https://github.com/gentoo/gentoo/pull/10725
> > Signed-off-by: Georgy Yakovlev 
> > ---
> >  eclass/cargo.eclass | 25 +++--
> >  1 file changed, 23 insertions(+), 2 deletions(-)
> > 
> > diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> > index 50f7830c51b..ea58c63b456 100644
> > --- a/eclass/cargo.eclass
> > +++ b/eclass/cargo.eclass
> > @@ -1,142 +1,163 @@
> >  # Copyright 1999-2018 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >  
> >  # @ECLASS: cargo.eclass
> >  # @MAINTAINER:
> >  # r...@gentoo.org
> >  # @AUTHOR:
> >  # Doug Goldstein 
> >  # @SUPPORTED_EAPIS: 6 7
> >  # @BLURB: common functions and variables for cargo builds
> >  
> >  if [[ -z ${_CARGO_ECLASS} ]]; then
> >  _CARGO_ECLASS=1
> >  
> >  CARGO_DEPEND=""
> >  [[ ${CATEGORY}/${PN} != dev-util/cargo ]] && CARGO_DEPEND="virtual/cargo"
> >  
> >  case ${EAPI} in
> > 6) DEPEND="${CARGO_DEPEND}";;
> > 7) BDEPEND="${CARGO_DEPEND}";;
> > *) die "EAPI=${EAPI:-0} is not supported" ;;
> >  esac
> >  
> >  inherit multiprocessing
> >  
> >  EXPORT_FUNCTIONS src_unpack src_compile src_install
> >  
> >  IUSE="${IUSE} debug"
> >  
> >  ECARGO_HOME="${WORKDIR}/cargo_home"
> >  ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
> >  
> > +# @ECLASS-VARIABLE: ECARGO_BUILD_FLAGS
> > +# @DEFAULT_UNSET
> > +# @DESCRIPTION:
> > +# This allows to pass additional build flags to cargo in 
> > cargo_src_compile()
> > +#
> > +# Example:
> > +# @CODE
> > +# ECARGO_BUILD_FLAGS="$(usex pcre "--features pcre2" "")"
> > +# @CODE
> > +
> > +# @ECLASS-VARIABLE: ECARGO_INSTALL_FLAGS
> > +# @DEFAULT_UNSET
> > +# @DESCRIPTION:
> > +# This allows to pass additional install flags to cargo in 
> > cargo_src_install()
> > +#
> > +# Example:
> > +# @CODE
> > +# ECARGO_INSTALL_FLAGS="--path=."
> > +# @CODE
> > +
> > +
> >  # @FUNCTION: cargo_crate_uris
> >  # @DESCRIPTION:
> >  # Generates the URIs to put in SRC_URI to help fetch dependencies.
> >  cargo_crate_uris() {
> > local crate
> > for crate in "$@"; do
> > local name version url pretag
> > name="${crate%-*}"
> > version="${crate##*-}"
> > pretag="^[a-zA-Z]+"
> > if [[ $version =~ $pretag ]]; then
> > version="${name##*-}-${version}"
> > name="${name%-*}"
> > fi
> > 
> > url="https://crates.io/api/v1/crates/${name}/${version}/download -> 
> > ${crate}.crate"
> > echo "${url}"
> > done
> >  }
> >  
> >  # @FUNCTION: cargo_src_unpack
> >  # @DESCRIPTION:
> >  # Unpacks the package and the cargo registry
> >  cargo_src_unpack() {
> > debug-print-function ${FUNCNAME} "$@"
> >  
> > mkdir -p "${ECARGO_VENDOR}" || die
> > mkdir -p "${S}" || die
> >  
> > local archive shasum pkg
> > for archive in ${A}; do
> > case "${archive}" in
> > *.crate)
> > ebegin "Loading ${archive} into Cargo registry"
> > tar -xf "${DISTDIR}"/${archive} -C 
> > "${ECARGO_VENDOR}/" || die
> > # generate sha256sum of the crate itself as 
> > cargo needs this
> > shasum=$(sha256sum "${DISTDIR}"/${archive} | 
> > cut -d ' ' -f 1)
> > pkg=$(basename ${archive} .crate)
> > cat <<- EOF > 
> > ${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json
> > {
> > "package": "${sha

[gentoo-dev] [PATCH] cargo.eclass: allow passing additional arguments to cargo

2019-01-02 Thread Georgy Yakovlev
This adds 2 eclass variables

ECARGO_BUILD_FLAGS
ECARGO_INSTALL_FLAGS

contents will be passed to "cargo build" and "cargo install" calls in
cargo_src_compile() and cargo_src_install() respectively.

Closes: https://github.com/gentoo/gentoo/pull/10725
Signed-off-by: Georgy Yakovlev 
---
 eclass/cargo.eclass | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 50f7830c51b..ea58c63b456 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -1,142 +1,163 @@
 # Copyright 1999-2018 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: cargo.eclass
 # @MAINTAINER:
 # r...@gentoo.org
 # @AUTHOR:
 # Doug Goldstein 
 # @SUPPORTED_EAPIS: 6 7
 # @BLURB: common functions and variables for cargo builds
 
 if [[ -z ${_CARGO_ECLASS} ]]; then
 _CARGO_ECLASS=1
 
 CARGO_DEPEND=""
 [[ ${CATEGORY}/${PN} != dev-util/cargo ]] && CARGO_DEPEND="virtual/cargo"
 
 case ${EAPI} in
6) DEPEND="${CARGO_DEPEND}";;
7) BDEPEND="${CARGO_DEPEND}";;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
 inherit multiprocessing
 
 EXPORT_FUNCTIONS src_unpack src_compile src_install
 
 IUSE="${IUSE} debug"
 
 ECARGO_HOME="${WORKDIR}/cargo_home"
 ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
 
+# @ECLASS-VARIABLE: ECARGO_BUILD_FLAGS
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# This allows to pass additional build flags to cargo in cargo_src_compile()
+#
+# Example:
+# @CODE
+# ECARGO_BUILD_FLAGS="$(usex pcre "--features pcre2" "")"
+# @CODE
+
+# @ECLASS-VARIABLE: ECARGO_INSTALL_FLAGS
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# This allows to pass additional install flags to cargo in cargo_src_install()
+#
+# Example:
+# @CODE
+# ECARGO_INSTALL_FLAGS="--path=."
+# @CODE
+
+
 # @FUNCTION: cargo_crate_uris
 # @DESCRIPTION:
 # Generates the URIs to put in SRC_URI to help fetch dependencies.
 cargo_crate_uris() {
local crate
for crate in "$@"; do
local name version url pretag
name="${crate%-*}"
version="${crate##*-}"
pretag="^[a-zA-Z]+"
if [[ $version =~ $pretag ]]; then
version="${name##*-}-${version}"
name="${name%-*}"
fi

url="https://crates.io/api/v1/crates/${name}/${version}/download -> 
${crate}.crate"
echo "${url}"
done
 }
 
 # @FUNCTION: cargo_src_unpack
 # @DESCRIPTION:
 # Unpacks the package and the cargo registry
 cargo_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
 
mkdir -p "${ECARGO_VENDOR}" || die
mkdir -p "${S}" || die
 
local archive shasum pkg
for archive in ${A}; do
case "${archive}" in
*.crate)
ebegin "Loading ${archive} into Cargo registry"
tar -xf "${DISTDIR}"/${archive} -C 
"${ECARGO_VENDOR}/" || die
# generate sha256sum of the crate itself as 
cargo needs this
shasum=$(sha256sum "${DISTDIR}"/${archive} | 
cut -d ' ' -f 1)
pkg=$(basename ${archive} .crate)
cat <<- EOF > 
${ECARGO_VENDOR}/${pkg}/.cargo-checksum.json
{
"package": "${shasum}",
"files": {}
}
EOF
# if this is our target package we need it in 
${WORKDIR} too
# to make ${S} (and handle any revisions too)
if [[ ${P} == ${pkg}* ]]; then
tar -xf "${DISTDIR}"/${archive} -C 
"${WORKDIR}" || die
fi
eend $?
;;
cargo-snapshot*)
ebegin "Unpacking ${archive}"
mkdir -p "${S}"/target/snapshot
tar -xzf "${DISTDIR}"/${archive} -C 
"${S}"/target/snapshot --strip-components 2 || die
# cargo's makefile needs this otherwise it will 
try to
# download it
touch "${S}"/target/snapshot/bin/cargo || die
eend $?
 

Re: [gentoo-dev] [RFC] adding more entries to profiles/info_pkgs

2018-12-16 Thread Georgy Yakovlev
On Sunday, December 16, 2018 2:18:33 PM PST Toralf Förster wrote:
> On 12/15/18 3:00 AM, Georgy Yakovlev wrote:
> > that should be enough to provide a bit more to initial information without
> > going crazy and clobbering output too much.
> > 
> > Thoughts?
> 
> At least for the tinderbox image issues I was asked by devs in the past to
> include bits for the following software in #comment0:
> 
>   cat << EOF >> $issuedir/issue
> gcc-config -l:
> $(gcc-config -l   )
> $( [[ -x /usr/bin/llvm-config ]] && echo llvm-config: && llvm-config
> --version ) $(eselect python  list 2>/dev/null)
> $(eselect rubylist 2>/dev/null)
> $(eselect rustlist 2>/dev/null)
> $( [[ -x /usr/bin/java-config ]] && echo java-config: && java-config
> --list-available-vms --nocolor ) $(eselect java-vm list 2>/dev/null)
> 
> ...
Actually after conversation with you on some rust related bug It occurred to 
me that there should be a more central location for similar info, so every 
reported bug that has --info output can show it right away, not only tinderbox 
bugs.
-- 
Georgy Yakovlev
Gentoo Linux Developer

signature.asc
Description: This is a digitally signed message part.


  1   2   >