Re: [gentoo-dev] [PATCH] kernel.eclass: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y

[Alice Ferrazzi]

>From f9b2693b32b7c7c7c561ae417cbd757624184327 Mon Sep 17 00:00:00 2001
From: Alice Ferrazzi 
Date: Thu, 18 Jan 2018 15:41:17 +
Subject: [PATCH] Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y

New 4.14 kernel is using CONFIG_UNWINDER_ORC=y by default
but having USE="minimal" is removing virtual/libelf,
this is breaking the Kernel compilation.
Closes: https://github.com/gentoo/gentoo/pull/6898

On Thu, Feb 1, 2018 at 4:09 AM, Robin H. Johnson  wrote:
> On Thu, Feb 01, 2018 at 12:09:10AM +0900, Alice Ferrazzi wrote:
>> New 4.14 kernel is using CONFIG_UNWINDER_ORC=y by default
>> but having USE="minimal" is removing virtual/libelf,
>> this is breaking the Kernel compilation.
> +1, this explains a breakage I saw for catalyst/genkernel.
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136



-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-portage-dev] Fix all misc. bash errors.

[Michał Górny]

W dniu pon, 05.02.2018 o godzinie 20∶33 -0600, użytkownik R0b0t1
napisał:
> On Sun, Feb 4, 2018 at 10:45 PM, Zac Medico  wrote:
> > On 02/04/2018 07:22 PM, R0b0t1 wrote:
> > > This is everything that shellcheck reported as an error. They are not
> > > as serious as the globbing issue, but it would be a good idea to
> > > change them. They are generally "type" issues (e.g. ">" instead of
> > > "-gt").
> > > 
> > > Some changes are shellcheck annotations. Very interesting was:
> > > 
> > > eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"
> > > 
> > > Which looks like a bad array expansion ("$x[@]").
> > 
> > I don't see a shellcheck error for that, using shellcheck-0.4.7. Maybe a
> > false positive with an older version?
> > 
> 
> 0.4.6, I will see if I can check.
> 
> > > diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
> > > index b28e44f18..377b32d90 100644
> > > --- a/bin/isolated-functions.sh
> > > +++ b/bin/isolated-functions.sh
> > > @@ -82,7 +82,7 @@ __dump_trace() {
> > >  lineno=${BASH_LINENO[${n} - 1]}
> > >  # Display function arguments
> > >  args=
> > > -if [[ -n "${BASH_ARGV[@]}" ]]; then
> > > +if [[ -n "${BASH_ARGV[*]}" ]]; then
> > 
> > I feel like the shellcheck authors might be willing to accept [[ -n
> > ${BASH_ARGV[@]} ]] or [[ ${BASH_ARGV[@]} ]] as correct, since the
> > "Problematic code" that they cite involves an incorrect comparison:
> > 
> > https://github.com/koalaman/shellcheck/wiki/SC2199#problematic-code
> > 
> 
> This example might be more illustrative:
> 
> argc () {
> echo $#
> }
> 
> argc "${BASH_ARGV[*]}"
> argc "${BASH_ARGV[@]}"
> 
> 
> Output (./test.sh a b):
> 
> 1
> 2
> 
> 
> Which changes the semantics of the tests in which it is present. It is
> hard to know what [[ is doing; if the same is attempted with [ it
> would be an error for the same reason that globbing produces errors.
> See:
> 
> [  "${BASH_ARGV[*]}"  ]
> [  "${BASH_ARGV[@]}"  ] # Fails; [: b: unary operator expected
> [[ "${BASH_ARGV[*]}" ]]
> [[ "${BASH_ARGV[@]}" ]]
> 
> 
> It is possible [[ ignores the extra elements. I can't think of a
> reason where this would make the results of the test different. At the
> same time, it might give people the wrong impression of the operation
> of [.
> 
> In the sense that [ and [[ represent test(1), anything but the "[*]"
> expansion is incorrect, as the error message indicates. That [[ treats
> its arguments specially because it is a feature of the syntax just
> makes the situation more confusing.
> 

They don't. '[' works as a external command whose arguments are subject
to word splitting. '[[' works as a builtin that does word splitting
before expanding variables.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] bzr.eclass: Drop bzr_bootstrap and bzr_src_prepare.

[Michał Górny]

W dniu śro, 07.02.2018 o godzinie 00∶24 +0100, użytkownik Ulrich Müller
napisał:
> No ebuild in the Gentoo repository uses the bzr_bootstrap
> functionality. Therefore drop the function along with bzr_src_prepare
> (which would not have worked in EAPI 6 anyway, due to missing call to
> eapply_user). After this change, inheriting eutils is not needed any
> more.
> 
> Drop support for EAPIs 0 and 1 for further simplification.
> ---
> 
> This is to be applied on top of the patch posted earlier today.
> 
> We could go for bzr-r1.eclass instead. However, the functionality
> associated with EBZR_PATCHES and EBZR_BOOTSTRAP is not used in the
> tree, and overall the eclass is little used. Therefore I think that
> applying these changes in-place is acceptable here.
> 
>  eclass/bzr.eclass | 99 
> ---
>  1 file changed, 13 insertions(+), 86 deletions(-)
> 
> diff --git a/eclass/bzr.eclass b/eclass/bzr.eclass
> index 9b3e0b6cf4dc..710b64db28c0 100644
> --- a/eclass/bzr.eclass
> +++ b/eclass/bzr.eclass
> @@ -18,21 +18,20 @@
>  # Note: Just set EBZR_REPO_URI to the URI of the branch and src_unpack()
>  # of this eclass will export the branch to ${WORKDIR}/${P}.
>  
> -inherit eutils
> -
>  EBZR="bzr.eclass"
>  
> -case "${EAPI:-0}" in
> - 0|1) EXPORT_FUNCTIONS src_unpack ;;
> - *)   EXPORT_FUNCTIONS src_unpack src_prepare ;;
> +case ${EAPI:-0} in
> + 2|3|4|5|6) ;;
> + *) die "${EBZR}: EAPI ${EAPI:-0} is not supported" ;;
>  esac
>  
> -DEPEND=">=dev-vcs/bzr-2.6.0"
> -case "${EAPI:-0}" in
> - 0|1) ;;
> - *) [[ ${EBZR_REPO_URI%%:*} = sftp ]] \
> - && DEPEND=">=dev-vcs/bzr-2.6.0[sftp]" ;;
> -esac
> +EXPORT_FUNCTIONS src_unpack
> +
> +if [[ ${EBZR_REPO_URI%%:*} = sftp ]]; then
> + DEPEND=">=dev-vcs/bzr-2.6.0[sftp]"
> +else
> + DEPEND=">=dev-vcs/bzr-2.6.0"
> +fi
>  
>  # @ECLASS-VARIABLE: EBZR_STORE_DIR
>  # @DESCRIPTION:
> @@ -85,9 +84,8 @@ esac
>  # @DESCRIPTION:
>  # The repository URI for the source package.
>  #
> -# Note: If the ebuild uses an sftp:// URI, then in EAPI 0 or 1 it must
> -# make sure that dev-vcs/bzr was built with USE="sftp".  In EAPI 2 or
> -# later, the eclass will depend on dev-vcs/bzr[sftp].
> +# Note: If the ebuild uses an sftp:// URI, then the eclass will depend
> +# on dev-vcs/bzr[sftp].
>  
>  # @ECLASS-VARIABLE: EBZR_INITIAL_URI
>  # @DEFAULT_UNSET
> @@ -100,21 +98,6 @@ esac
>  #
>  # Normally, this variable needs not be set.
>  
> -# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
> -# @DEFAULT_UNSET
> -# @DESCRIPTION:
> -# Bootstrap script or command like autogen.sh or etc.
> -
> -# @ECLASS-VARIABLE: EBZR_PATCHES
> -# @DEFAULT_UNSET
> -# @DESCRIPTION:
> -# bzr.eclass can apply patches in bzr_bootstrap().  You can use regular
> -# expressions in this variable like *.diff or *.patch and the like.
> -# Note: These patches will be applied before EBZR_BOOTSTRAP is processed.
> -#
> -# Patches are searched both in ${PWD} and ${FILESDIR}.  If not found in
> -# either location, the installation dies.
> -
>  # @ECLASS-VARIABLE: EBZR_PROJECT
>  # @DESCRIPTION:
>  # The project name of your ebuild.  Normally, the branch will be stored
> @@ -276,65 +259,9 @@ bzr_fetch() {
>   popd > /dev/null
>  }
>  
> -# @FUNCTION: bzr_bootstrap
> -# @DESCRIPTION:
> -# Apply patches in ${EBZR_PATCHES} and run ${EBZR_BOOTSTRAP} if specified.
> -bzr_bootstrap() {
> - local patch lpatch
> -
> - pushd "${S}" > /dev/null || die "${EBZR}: can't chdir to ${S}"
> -
> - if [[ -n ${EBZR_PATCHES} ]] ; then
> - einfo "apply patches -->"
> -
> - for patch in ${EBZR_PATCHES} ; do
> - if [[ -f ${patch} ]] ; then
> - epatch "${patch}"
> - else
> - # This loop takes care of wildcarded patches 
> given via
> - # EBZR_PATCHES in an ebuild
> - for lpatch in "${FILESDIR}"/${patch} ; do
> - if [[ -f ${lpatch} ]] ; then
> - epatch "${lpatch}"
> - else
> - die "${EBZR}: ${patch} is not 
> found"
> - fi
> - done
> - fi
> - done
> - fi
> -
> - if [[ -n ${EBZR_BOOTSTRAP} ]] ; then
> - einfo "begin bootstrap -->"
> -
> - if [[ -f ${EBZR_BOOTSTRAP} ]] && [[ -x ${EBZR_BOOTSTRAP} ]] ; 
> then
> - einfo "   bootstrap with a file: ${EBZR_BOOTSTRAP}"
> - "./${EBZR_BOOTSTRAP}" \
> - || die "${EBZR}: can't execute EBZR_BOOTSTRAP"
> - else
> - einfo "   bootstrap with commands: ${EBZR_BOOTSTRAP}"
> - "${EBZR_BOOTSTRAP}" \
> - || die "${EBZR}: can't eval 

Re: [gentoo-portage-dev] Fix all misc. bash errors.

[Zac Medico]

On 02/05/2018 06:55 PM, R0b0t1 wrote:
> On Mon, Feb 5, 2018 at 8:33 PM, R0b0t1  wrote:
>> On Sun, Feb 4, 2018 at 10:45 PM, Zac Medico  wrote:
>>> On 02/04/2018 07:22 PM, R0b0t1 wrote:
 This is everything that shellcheck reported as an error. They are not
 as serious as the globbing issue, but it would be a good idea to
 change them. They are generally "type" issues (e.g. ">" instead of
 "-gt").

 Some changes are shellcheck annotations. Very interesting was:

 eval "$x=(\"\${$x[@]}\" ${QA_PREBUILT//\*/.*})"

 Which looks like a bad array expansion ("$x[@]").
>>>
>>> I don't see a shellcheck error for that, using shellcheck-0.4.7. Maybe a
>>> false positive with an older version?
>>>
>>
>> 0.4.6, I will see if I can check.
> 
> Still in 0.4.7.

Yeah, I just tried again and I'm seeing it now. I've found that adding
braces to ${x} suppresses it:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=4a0a949d601969c672d9cf70ef8cf8682553f787

-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Fix all misc. bash errors.

[Zac Medico]

On 02/05/2018 06:33 PM, R0b0t1 wrote:
> On Sun, Feb 4, 2018 at 10:45 PM, Zac Medico  wrote:
>> On 02/04/2018 07:22 PM, R0b0t1 wrote:
>>> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
>>> index b28e44f18..377b32d90 100644
>>> --- a/bin/isolated-functions.sh
>>> +++ b/bin/isolated-functions.sh
>>> @@ -82,7 +82,7 @@ __dump_trace() {
>>>  lineno=${BASH_LINENO[${n} - 1]}
>>>  # Display function arguments
>>>  args=
>>> -if [[ -n "${BASH_ARGV[@]}" ]]; then
>>> +if [[ -n "${BASH_ARGV[*]}" ]]; then
>>
>> I feel like the shellcheck authors might be willing to accept [[ -n
>> ${BASH_ARGV[@]} ]] or [[ ${BASH_ARGV[@]} ]] as correct, since the
>> "Problematic code" that they cite involves an incorrect comparison:
>>
>> https://github.com/koalaman/shellcheck/wiki/SC2199#problematic-code
>>
> 
> This example might be more illustrative:
> 
> argc () {
> echo $#
> }
> 
> argc "${BASH_ARGV[*]}"
> argc "${BASH_ARGV[@]}"
> 
> 
> Output (./test.sh a b):
> 
> 1
> 2
> 
> 
> Which changes the semantics of the tests in which it is present. It is
> hard to know what [[ is doing; if the same is attempted with [ it
> would be an error for the same reason that globbing produces errors.
> See:
> 
> [  "${BASH_ARGV[*]}"  ]
> [  "${BASH_ARGV[@]}"  ] # Fails; [: b: unary operator expected
> [[ "${BASH_ARGV[*]}" ]]
> [[ "${BASH_ARGV[@]}" ]]
> 
> 
> It is possible [[ ignores the extra elements. I can't think of a
> reason where this would make the results of the test different. At the
> same time, it might give people the wrong impression of the operation
> of [.
> 
> In the sense that [ and [[ represent test(1), anything but the "[*]"
> expansion is incorrect, as the error message indicates. That [[ treats
> its arguments specially because it is a feature of the syntax just
> makes the situation more confusing.

I've turned this into an optimization by testing the array length
instead of expanding the elements:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=2306b8f4a2d781db87ee61707f6dea1c5f717936
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: SAT-based dependency solver: request for test cases

[Duncan]

Michael Lienhardt posted on Tue, 06 Feb 2018 23:53:05 +0100 as excerpted:

> Il 06/02/2018 15:00, Roy Bamford ha scritto:
>> Posting here to alert other potential helpers.
>> Your script uses
>> 
>> PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords"
>> 
>> but thats a recent name change.
>> 
>> PACKAGE_KEYWORDS="/etc/portage/package.keywords"
>> 
>> is the old name and my older systems still use that.
>> You probably need to harvest both and process both as portage does.
> 
> You are right, I was lazy (and hoped that everyone already made the
> switch because, as I understand it, package.keywords and
> package.accept_keywords do not have the same semantics).
> I added the package.keywords file/folder in the script.

AFAIK, (plain) etc-portage semantics are the same for both files -- that 
is, /etc/portage/package.keywords and the newer package.accept_keywords
are identical.

The reason for the new name and deprecation of the old one was that 
package.keywords also exists in the /profile/, where the semantics are 
different, which created confusion for devs and others attempting to edit 
the profile version as well as the more commonly user-edited (plain)
/etc/portage version.

(I add the parenthesized "(plain)" because there's also the deeper 
/etc/portage/profile path, which takes profile changes and therefore the 
profile format.  Actually, I suspect it was someone editing that using 
the wrong format and then filing a bug when things didn't work as 
expected that likely prompted the new name and deprecation of the old 
one.)


Meanwhile...

I've a rather unusual portage config here:

* /etc/portage/profile/packages contains a -* entry, negating the entire 
normal @system set.  Many normally @system packages I really need are 
dependencies of something or other I already have in @world anyway, and 
I've added @world entries where necessary to keep the few exceptions 
installed.

* My USE starts with a -* entry as well, negating profile and package USE 
defaults so I have direct control of all USE flag settings and don't have 
to worry about USE flag changes on profile updates or tracking down why a 
flag is changing when I didn't change anything, both previous problems I 
had to deal with until I set that initial -*, so the only flags set are 
the ones I deliberately chose, myself.

* My world file (/var/lib/portage/world) is empty.  I've categorized 
everything into individual sets found in /etc/portage/sets, with those in 
turn listed in the world_sets file (/var/lib/portage/world_sets).

* Overlays... (Less unusual, but still not mainline...) I run nearly all 
the kde I have installed (frameworks/plasma/apps), as well as a few other 
packages, from the live-git *- packages found in the gentoo/kde 
overlay (and others).  Package keywording/masking is adjusted 
accordingly.  (Everything else is mainline ~amd64.)

I expect  one or more of these you won't have anticipated so they'll 
present a challenge for your current script, but because it /is/ a rather 
unusual setup, I'm not sure it's worth your trouble to bother with.

OTOH, if you want unusual corner-cases to test...

So bother sending the results in (you're ready for it already), or you 
want them, but wait until you've adjusted the script to deal with it, or 
don't bother, you're not going to try supporting anything that unusual 
anyway?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] [PATCH] bzr.eclass: Drop bzr_bootstrap and bzr_src_prepare.

[Ulrich Müller]

No ebuild in the Gentoo repository uses the bzr_bootstrap
functionality. Therefore drop the function along with bzr_src_prepare
(which would not have worked in EAPI 6 anyway, due to missing call to
eapply_user). After this change, inheriting eutils is not needed any
more.

Drop support for EAPIs 0 and 1 for further simplification.
---

This is to be applied on top of the patch posted earlier today.

We could go for bzr-r1.eclass instead. However, the functionality
associated with EBZR_PATCHES and EBZR_BOOTSTRAP is not used in the
tree, and overall the eclass is little used. Therefore I think that
applying these changes in-place is acceptable here.

 eclass/bzr.eclass | 99 ---
 1 file changed, 13 insertions(+), 86 deletions(-)

diff --git a/eclass/bzr.eclass b/eclass/bzr.eclass
index 9b3e0b6cf4dc..710b64db28c0 100644
--- a/eclass/bzr.eclass
+++ b/eclass/bzr.eclass
@@ -18,21 +18,20 @@
 # Note: Just set EBZR_REPO_URI to the URI of the branch and src_unpack()
 # of this eclass will export the branch to ${WORKDIR}/${P}.
 
-inherit eutils
-
 EBZR="bzr.eclass"
 
-case "${EAPI:-0}" in
-   0|1) EXPORT_FUNCTIONS src_unpack ;;
-   *)   EXPORT_FUNCTIONS src_unpack src_prepare ;;
+case ${EAPI:-0} in
+   2|3|4|5|6) ;;
+   *) die "${EBZR}: EAPI ${EAPI:-0} is not supported" ;;
 esac
 
-DEPEND=">=dev-vcs/bzr-2.6.0"
-case "${EAPI:-0}" in
-   0|1) ;;
-   *) [[ ${EBZR_REPO_URI%%:*} = sftp ]] \
-   && DEPEND=">=dev-vcs/bzr-2.6.0[sftp]" ;;
-esac
+EXPORT_FUNCTIONS src_unpack
+
+if [[ ${EBZR_REPO_URI%%:*} = sftp ]]; then
+   DEPEND=">=dev-vcs/bzr-2.6.0[sftp]"
+else
+   DEPEND=">=dev-vcs/bzr-2.6.0"
+fi
 
 # @ECLASS-VARIABLE: EBZR_STORE_DIR
 # @DESCRIPTION:
@@ -85,9 +84,8 @@ esac
 # @DESCRIPTION:
 # The repository URI for the source package.
 #
-# Note: If the ebuild uses an sftp:// URI, then in EAPI 0 or 1 it must
-# make sure that dev-vcs/bzr was built with USE="sftp".  In EAPI 2 or
-# later, the eclass will depend on dev-vcs/bzr[sftp].
+# Note: If the ebuild uses an sftp:// URI, then the eclass will depend
+# on dev-vcs/bzr[sftp].
 
 # @ECLASS-VARIABLE: EBZR_INITIAL_URI
 # @DEFAULT_UNSET
@@ -100,21 +98,6 @@ esac
 #
 # Normally, this variable needs not be set.
 
-# @ECLASS-VARIABLE: EBZR_BOOTSTRAP
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# Bootstrap script or command like autogen.sh or etc.
-
-# @ECLASS-VARIABLE: EBZR_PATCHES
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# bzr.eclass can apply patches in bzr_bootstrap().  You can use regular
-# expressions in this variable like *.diff or *.patch and the like.
-# Note: These patches will be applied before EBZR_BOOTSTRAP is processed.
-#
-# Patches are searched both in ${PWD} and ${FILESDIR}.  If not found in
-# either location, the installation dies.
-
 # @ECLASS-VARIABLE: EBZR_PROJECT
 # @DESCRIPTION:
 # The project name of your ebuild.  Normally, the branch will be stored
@@ -276,65 +259,9 @@ bzr_fetch() {
popd > /dev/null
 }
 
-# @FUNCTION: bzr_bootstrap
-# @DESCRIPTION:
-# Apply patches in ${EBZR_PATCHES} and run ${EBZR_BOOTSTRAP} if specified.
-bzr_bootstrap() {
-   local patch lpatch
-
-   pushd "${S}" > /dev/null || die "${EBZR}: can't chdir to ${S}"
-
-   if [[ -n ${EBZR_PATCHES} ]] ; then
-   einfo "apply patches -->"
-
-   for patch in ${EBZR_PATCHES} ; do
-   if [[ -f ${patch} ]] ; then
-   epatch "${patch}"
-   else
-   # This loop takes care of wildcarded patches 
given via
-   # EBZR_PATCHES in an ebuild
-   for lpatch in "${FILESDIR}"/${patch} ; do
-   if [[ -f ${lpatch} ]] ; then
-   epatch "${lpatch}"
-   else
-   die "${EBZR}: ${patch} is not 
found"
-   fi
-   done
-   fi
-   done
-   fi
-
-   if [[ -n ${EBZR_BOOTSTRAP} ]] ; then
-   einfo "begin bootstrap -->"
-
-   if [[ -f ${EBZR_BOOTSTRAP} ]] && [[ -x ${EBZR_BOOTSTRAP} ]] ; 
then
-   einfo "   bootstrap with a file: ${EBZR_BOOTSTRAP}"
-   "./${EBZR_BOOTSTRAP}" \
-   || die "${EBZR}: can't execute EBZR_BOOTSTRAP"
-   else
-   einfo "   bootstrap with commands: ${EBZR_BOOTSTRAP}"
-   "${EBZR_BOOTSTRAP}" \
-   || die "${EBZR}: can't eval EBZR_BOOTSTRAP"
-   fi
-   fi
-
-   popd > /dev/null
-}
-
 # @FUNCTION: bzr_src_unpack
 # @DESCRIPTION:
-# Default src_unpack(), calls bzr_fetch.  For EAPIs 0 and 1, also calls
-# bzr_src_prepare.
+# Default src_unpack(), calls bzr_fetch.
 bzr_src_unpack() {

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

[Michael Lienhardt]

Il 06/02/2018 15:00, Roy Bamford ha scritto:

Posting here to alert other potential helpers.
Your script uses

PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords"

but thats a recent name change.

PACKAGE_KEYWORDS="/etc/portage/package.keywords"

is the old name and my older systems still use that.
You probably need to harvest both and process both as portage does.


You are right, I was lazy (and hoped that everyone already made the switch 
because, as I understand it, package.keywords and package.accept_keywords do 
not have the same semantics).
I added the package.keywords file/folder in the script.

Thank you,
Michael Lienhardt

[gentoo-dev] Why does baselayout not own directories it creates?

[William Hubbs]

All,

We keep hitting issues on various systems where portage is removing the
/var/run symlink once it deletes everything that uses this path.

The fix is going to be to make baselayout take ownership of this
symlink.

In looking at doing this, I realized that baselayout doesn't take
ownership of any directories it creates, for example, /bin, /usr/bin,
/var, /home, /root etc. Does anyone know why this is the case? If not, I
am going to start working on making baselayout take ownership of these.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.

[Michał Górny]

W dniu wto, 06.02.2018 o godzinie 09∶07 -0800, użytkownik Alec Warner
napisał:
> On Tue, Feb 6, 2018 at 6:12 AM, Kristian Fiskerstrand 
> wrote:
> 
> > On 02/06/2018 02:57 PM, Ulrich Müller wrote:
> > > Fixes: https://bugs.gentoo.org/446422
> > 
> > Bug or Closes, Fixes would be referencing a commit-id c.f GLEP 66.
> > 
> > More generally though, should we start requiring more verbose commit
> > messages for eclasses to make it easier to trace changes in our git repo
> > directly without reaching out to bugs? At least including summaries of
> > the respective bugs as a short description?
> > 
> 
> Nope, people can go read the bug.
> 

That's very nice of you. I do really enjoy when I have a log of like 30
different commits that might be relevant and whose descriptions boil
down to 'go see 30 bugs, and hope you won't have to read all comments'.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Testing Gentoo with openQA

[mudler]

On 04/02/2018 11:16, Francesco Riosa wrote:
> 2018-02-03 13:16 GMT+01:00 mudler :
>
>> Hi everyone,
>>
>>
>> This is an idea that has been floating around already, as some of you
>> already know, openQA [1] is a project that provides the ability to fully
>> test  O.S.
>>
> Being used to routinely build Gentoo profiles, this idea is one of the
> first to pop up, indeed.
>
>
>> I'd like to bring openQA to Gentoo, and start using it for both testing,
>> and maybe, if promising at it seems, using it to automatize even more
>> our testing workflow and help stabilization processes.
>>
> simply Great.

Glad to hear that!

>
>
>> I'm creating a new project for this, the aim is first to provide ebuilds
>> for openQA, and meanwhile writing test cases that can be used to test
>> Gentoo inside it. As i see it, it would be really helpful exp. regarding
>> testing DEs  and track back regressions as well [2], it offers also
>> integrations with bugzilla.
>>
> One of the first things noticed when trying to achieve full testing is that
> it's a gigantic work. Suse seem to have a really good framework that
> surely costed a lot to build.
> How much can be reused of that work?

I would say approx ~30% of test codebase could be reused, but this is
just my personal estimation.


> What are the differences, in features and building blocks expected for a
> gentoo implementation?

I don't see any big changes in the structure - rather of writing tests
that suits more on our needs.
But baby steps, i would be happy to see for now a test that from a
stage3 bootstraps a DE environment correctly.
What i see will be more complicated is trying to abstract tests that
expect different results from different useflags combinations.

>
>
>> Development plan and goals will be updated to the Project page soon [3]
>>
>>
>> What do you think?
>>
>>
> That's a difficult objective worth the effort to achieve it

I definitely agree

>
>
>> Best,
>>
>> Ettore
>>
>>
>> 1: http://open.qa/
>>
>> 2: https://openqa.opensuse.org/tests/600283
>>
>> 3: https://wiki.gentoo.org/wiki/Project:OpenQA
>>
>>
>>




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.

[Alec Warner]

On Tue, Feb 6, 2018 at 6:12 AM, Kristian Fiskerstrand 
wrote:

> On 02/06/2018 02:57 PM, Ulrich Müller wrote:
> > Fixes: https://bugs.gentoo.org/446422
>
> Bug or Closes, Fixes would be referencing a commit-id c.f GLEP 66.
>
> More generally though, should we start requiring more verbose commit
> messages for eclasses to make it easier to trace changes in our git repo
> directly without reaching out to bugs? At least including summaries of
> the respective bugs as a short description?
>

Nope, people can go read the bug.

-A


>
> --
> Kristian Fiskerstrand
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>
>

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

[Matthew Thode]

On 18-02-06 11:52:10, Michael Lienhardt wrote:
> Dear all,
> 
> With the help of some friends and colleagues, I am working on an SAT-based 
> dependency solver for portage.
> We need your help to test it and possibly improve in the long run the already 
> great portage toolset.
> 
> To help, you can send us the tar generated by this bash script: 
> https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh
> This bash script extracts your world file, the USE flags and keywords 
> configuration of your system and the list of installed packages you have (it 
> should not take more than few seconds).
> With this, we will see if our solver is able to recreate your system and how 
> much time it takes.
> 
> You can send everything to my professional email: mlien...@di.unito.it
> 
> 
> The goal of this alternative solver is to overcome some of the limitations of 
> emerge.
> Thanks to some users of the forum and the gentoo-user mailing list, I already 
> tested the solver on 8 systems, and the results for now are:
>  - emerge is not able to recreate any of these systems (i.e., 'cat 
> world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM does 
> not succeed, even with the right /etc/portage/package.* files)
>  - our solver takes 2 minutes in average (with little variation), and gives 
> either a yes answer (with what to install, which USE flags to set, which 
> packages to keyword) or a no answer (with the set of conflicting constraints) 
> for every systems
>  - we solved one bug in our solver (a behavior of emerge that seems 
> documented only in the PMS document, not in devmanual nor in the wiki, and 
> that is visible only in 15 packages), but at least one seems to still be 
> around.
> 
> I started discussing this on the gentoo-portage-dev and the gentoo-user 
> mailing lists (sorry for the duplicates), and on the forum with three posts:
>  - https://forums.gentoo.org/viewtopic-t-1074170.html about the documentation 
> I collected to implement the solver
>  - https://forums.gentoo.org/viewtopic-t-1074202.html about the solver and 
> its motivations
>  - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests I'm 
> doing
> 
> 
> About me:
> I'm a researcher in computer science, about formal methods, concurrency and 
> software engineering.
> Friday, I will present my first paper on portage, showing that its packages 
> and their dependencies constitute what is called a "Multi-Software Product 
> Line" in software engineering. If you skip the algebraic definition, it 
> should be readable ^^: http://www.di.unito.it/~mlienhar/vamos.pdf
> In 2013, I designed and contributed to the implementation of a dependency 
> solver for dynamic cloud architecture (currently maintained by Jacopo Mauro 
> https://bitbucket.org/jacopomauro/zephyrus2/src )
> I'm a gentoo user since 2007, and I'm very happy by this opportunity to 
> contribute back :).
> 
> 

This sounds intresting, I wonder how it'd handle things like
sys-cluster/openstack-meta which can sometimes require masking a package
(gentoo stablizes a package ahead of what openstack has tested support
for).

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

eclass committ message verbosity (Was: Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.)

[Kristian Fiskerstrand]

On 02/06/2018 03:36 PM, Ulrich Mueller wrote:
>> On Tue, 6 Feb 2018, Kristian Fiskerstrand wrote:


>> More generally though, should we start requiring more verbose commit
>> messages for eclasses to make it easier to trace changes in our git
>> repo directly without reaching out to bugs? At least including
>> summaries of the respective bugs as a short description?
> 
> In the concrete example, the bug's summary is "bzr.eclass might need
> to use bzr pull's --overwrite-tags flag" which is not much different
> from the git commit message.

Right, this specific commit likely has little more to gain given the
summary line. But could easily benefit from some text in body still :)

But I generally think we can benefit from some more verbosity in our
commit messages, in particular for eclasses.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: games-engines/love

[kuzetsa]

From freenode / #gentoo-proxy-maint

[09:13:53]  do I need to reply to the gentoo-dev ML to
  be able to proxy-maintain games-engines/love or can I just fire
  off the github PR with commits for EAPI 6, version bump, etc.
  (it's not up to date & being dropped by current maintainer)

Resolution: It was decided that a ML post would be proper / polite.

I'd like to take over this package, and will make some commits
in the next week or so (not sure how much will be involved to
do the required things mentioned above)

-- kuza

On 02/01/2018 05:36 AM, Chí-Thanh Christopher Nguyễn wrote:
> Hi all!
> 
> Due to lack of time, I have to drop maintainership of games-engines/love.
> There is some user interest in this package, and a version bump is
> needed (bug 640802).
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.

[Ulrich Mueller]

> On Tue, 6 Feb 2018, Kristian Fiskerstrand wrote:

>> Fixes: https://bugs.gentoo.org/446422

> Bug or Closes, Fixes would be referencing a commit-id c.f GLEP 66.

Updated, thanks for catching this.

> More generally though, should we start requiring more verbose commit
> messages for eclasses to make it easier to trace changes in our git
> repo directly without reaching out to bugs? At least including
> summaries of the respective bugs as a short description?

In the concrete example, the bug's summary is "bzr.eclass might need
to use bzr pull's --overwrite-tags flag" which is not much different
from the git commit message.

Ulrich


pgpnLlL3h5eAR.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.

[Kristian Fiskerstrand]

On 02/06/2018 02:57 PM, Ulrich Müller wrote:
> Fixes: https://bugs.gentoo.org/446422

Bug or Closes, Fixes would be referencing a commit-id c.f GLEP 66.

More generally though, should we start requiring more verbose commit
messages for eclasses to make it easier to trace changes in our git repo
directly without reaching out to bugs? At least including summaries of
the respective bugs as a short description?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

[Roy Bamford]

On 2018.02.06 10:52, Michael Lienhardt wrote:
> Dear all,
> 
> With the help of some friends and colleagues, I am working on an
> SAT-based dependency solver for portage.
> We need your help to test it and possibly improve in the long run the
> already great portage toolset.
> 
> To help, you can send us the tar generated by this bash script:
> https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh
> This bash script extracts your world file, the USE flags and keywords
> configuration of your system and the list of installed packages you
> have (it should not take more than few seconds).
> With this, we will see if our solver is able to recreate your system
> and how much time it takes.
> 
> You can send everything to my professional email: mlien...@di.unito.it
> 
> 
> The goal of this alternative solver is to overcome some of the
> limitations of emerge.
> Thanks to some users of the forum and the gentoo-user mailing list, I
> already tested the solver on 8 systems, and the results for now are:
>   - emerge is not able to recreate any of these systems (i.e., 'cat
> world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM
> does not succeed, even with the right /etc/portage/package.* files)
>   - our solver takes 2 minutes in average (with little variation), and
> gives either a yes answer (with what to install, which USE flags to
> set, which packages to keyword) or a no answer (with the set of
> conflicting constraints) for every systems
>   - we solved one bug in our solver (a behavior of emerge that seems
> documented only in the PMS document, not in devmanual nor in the wiki,
> and that is visible only in 15 packages), but at least one seems to
> still be around.
> 
> I started discussing this on the gentoo-portage-dev and the
> gentoo-user mailing lists (sorry for the duplicates), and on the forum
> with three posts:
>   - https://forums.gentoo.org/viewtopic-t-1074170.html about the
> documentation I collected to implement the solver
>   - https://forums.gentoo.org/viewtopic-t-1074202.html about the
> solver and its motivations
>   - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests
> I'm doing
> 
> 
> About me:
> I'm a researcher in computer science, about formal methods,
> concurrency and software engineering.
> Friday, I will present my first paper on portage, showing that its
> packages and their dependencies constitute what is called a
> "Multi-Software Product Line" in software engineering. If you skip the
> algebraic definition, it should be readable ^^:
> http://www.di.unito.it/~mlienhar/vamos.pdf
> In 2013, I designed and contributed to the implementation of a
> dependency solver for dynamic cloud architecture (currently maintained
> by Jacopo Mauro https://bitbucket.org/jacopomauro/zephyrus2/src )
> I'm a gentoo user since 2007, and I'm very happy by this opportunity
> to contribute back :).
> 
> 
> Thank you!
> Michael Lienhardt
> 
> 
> 

Michael,

Posting here to alert other potential helpers.
Your script uses

PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords" 

but thats a recent name change.

PACKAGE_KEYWORDS="/etc/portage/package.keywords"

is the old name and my older systems still use that.
You probably need to harvest both and process both as portage does.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpjZkguBNLdT.pgp
Description: PGP signature

[gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.

[Ulrich Müller]

Fixes: https://bugs.gentoo.org/446422
---
 eclass/bzr.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/bzr.eclass b/eclass/bzr.eclass
index ef1b47936867..792cc3bec36f 100644
--- a/eclass/bzr.eclass
+++ b/eclass/bzr.eclass
@@ -27,7 +27,7 @@ case "${EAPI:-0}" in
*)   EXPORT_FUNCTIONS src_unpack src_prepare ;;
 esac
 
-DEPEND=">=dev-vcs/bzr-2.0.1"
+DEPEND=">=dev-vcs/bzr-2.6.0"
 case "${EAPI:-0}" in
0|1) ;;
*) [[ ${EBZR_REPO_URI%%:*} = sftp ]] \
@@ -57,7 +57,7 @@ esac
 # @ECLASS-VARIABLE: EBZR_UPDATE_CMD
 # @DESCRIPTION:
 # The Bazaar command to update the sources.
-: ${EBZR_UPDATE_CMD:="bzr pull"}
+: ${EBZR_UPDATE_CMD:="bzr pull --overwrite-tags"}
 
 # @ECLASS-VARIABLE: EBZR_EXPORT_CMD
 # @DESCRIPTION:
-- 
2.16.1


pgpfAcAI_ChjH.pgp
Description: PGP signature

[gentoo-dev] SAT-based dependency solver: request for test cases

[Michael Lienhardt]

Dear all,

With the help of some friends and colleagues, I am working on an SAT-based 
dependency solver for portage.
We need your help to test it and possibly improve in the long run the already 
great portage toolset.

To help, you can send us the tar generated by this bash script: 
https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh
This bash script extracts your world file, the USE flags and keywords 
configuration of your system and the list of installed packages you have (it 
should not take more than few seconds).
With this, we will see if our solver is able to recreate your system and how 
much time it takes.

You can send everything to my professional email: mlien...@di.unito.it


The goal of this alternative solver is to overcome some of the limitations of 
emerge.
Thanks to some users of the forum and the gentoo-user mailing list, I already 
tested the solver on 8 systems, and the results for now are:
 - emerge is not able to recreate any of these systems (i.e., 'cat 
world_of_test_configuration | xargs emerge -vp' on a gentoo osboxes VM does not 
succeed, even with the right /etc/portage/package.* files)
 - our solver takes 2 minutes in average (with little variation), and gives 
either a yes answer (with what to install, which USE flags to set, which 
packages to keyword) or a no answer (with the set of conflicting constraints) 
for every systems
 - we solved one bug in our solver (a behavior of emerge that seems documented 
only in the PMS document, not in devmanual nor in the wiki, and that is visible 
only in 15 packages), but at least one seems to still be around.

I started discussing this on the gentoo-portage-dev and the gentoo-user mailing 
lists (sorry for the duplicates), and on the forum with three posts:
 - https://forums.gentoo.org/viewtopic-t-1074170.html about the documentation I 
collected to implement the solver
 - https://forums.gentoo.org/viewtopic-t-1074202.html about the solver and its 
motivations
 - https://forums.gentoo.org/viewtopic-t-1075286.html about the tests I'm doing


About me:
I'm a researcher in computer science, about formal methods, concurrency and 
software engineering.
Friday, I will present my first paper on portage, showing that its packages and their 
dependencies constitute what is called a "Multi-Software Product Line" in 
software engineering. If you skip the algebraic definition, it should be readable ^^: 
http://www.di.unito.it/~mlienhar/vamos.pdf
In 2013, I designed and contributed to the implementation of a dependency 
solver for dynamic cloud architecture (currently maintained by Jacopo Mauro 
https://bitbucket.org/jacopomauro/zephyrus2/src )
I'm a gentoo user since 2007, and I'm very happy by this opportunity to 
contribute back :).


Thank you!
Michael Lienhardt

Re: [gentoo-portage-dev] [PATCH 1/2] portage.package.ebuild.config: Rename iuse_implicit -> iuse_effective

[Michael Lienhardt]

Many thanks.

I should definitively read this document, that is far more precise that 
anything I have found on the wiki or on devmanual.

Il 06/02/2018 00:05, Zac Medico ha scritto:

On 02/05/2018 02:46 PM, Michael Lienhardt wrote:

Is the IUSE_IMPLICIT variable in the make.defaults also changed into
IUSE_EFFECTIVE?

I'm sorry if this question was already discussed/answered somewhere else.


The IUSE_EFFECTIVE variable is generated from IUSE_IMPLICIT and some
other variables. It's documented in the "USE and IUSE handling" section
here:

https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-11900011.1.1