[gentoo-portage-dev] sys-kernel/vanilla-sources not supported any more?

[Joakim Tjernlund]

I have noticed sys-kernel/vanilla-sources lagging behind for a while now and I 
wonder if this pkg is obsolete? 

 Jocke

Re: [gentoo-portage-dev] In what phase are file "merged"?

[Joakim Tjernlund]

On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote:
> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
> > > > > > > On Wed, 23 Jun 2021, Fabian Groffen wrote:
> > 
> > > On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
> > > > It's somewhat hidden, but it's there:
> > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprojects.gentoo.org%2Fpms%2F8%2Fpms.html%23x1-950009.1.10data=04%7C01%7CJoakim.Tjernlund%40infinera.com%7Cba02686be6d54ea9cc9108d9363acdd2%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C1%7C637600448462073359%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Jb60QbNzyIAUesXa9Z9YVlaGbbKBVVXK6qK%2BgiZ87%2BM%3Dreserved=0
> > > > 
> > > > 9.1.10 pkg_preinst
> > > > ... immediately before merging the package to the live
> > > > filesystem.
> > > > ...
> > > > 
> > > > 9.1.11 pkg_postinst
> > > > ... immediately after merging the package to the live filesystem.
> > > > ...
> > 
> > > Aha, so does this mean pkg_prerm and pkg_postrm are run with
> > > replacing
> > > package in place, e.g. if they refer to scripts installed by the
> > > replaced package they may no longer exist or be the same?
> > 
> > PMS has similar wording for pkg_prerm and pkg_postrm, so (at least
> > according to the spec) the old package will still be present in
> > pkg_prerm and will be gone in pkg_postrm.
> > 
> > I don't think that the ebuild can rely on any particular status of
> > the
> > new package in pkg_*rm (of the old package), or the status of the old
> > package in pkg_*inst (of the new package).
> 
> I would even say that it can't rely on the particular status of the old
> package in any case, if it's meant to be removed.  In particular, its
> dependencies can be unmerged before the package itself.

Stubled ove this mail again and noticed "its dependencies can be
unmerged before the package itself" stmt. That does not make sense to
me. Deps should be unmerged after any pkg that depends on them?

 Jocke

[gentoo-portage-dev] In what phase are file "merged"?

[Joakim Tjernlund]

In PMS 9.2 is says:
The call order for upgrading, downgrading or reinstalling a package is:

pkg_pretend (only for EAPIs listed in table 9.2), which is called outside 
of the normal call order process.
pkg_setup
src_unpack
src_prepare (only for EAPIs listed in table 9.3)
src_configure (only for EAPIs listed in table 9.4)
src_compile
src_test (except if RESTRICT=test)
src_install
pkg_preinst
pkg_prerm for the package being replaced
pkg_postrm for the package being replaced
pkg_postinst


It does not say where in this list new files merged and old files unmerged, can 
anyone enlighten me?

 Jocke

Re: [gentoo-portage-dev] Installed pkg list in dependency order ?

[Joakim Tjernlund]

On Mon, 2021-06-14 at 09:11 -0700, Zac Medico wrote:
> On 6/14/21 8:16 AM, Joakim Tjernlund wrote:
> > Hi 
> > 
> > I need to generate a pkg list from an uptodate gentoo system too feed this 
> > list into qmerge
> > so qmerge can install these pkgs in correct order.
> > 
> > Tried emerge -e but that list is not in dep order, seems to be just a list 
> > with pkgs to rebuild.
> > 
> >  Jocke 
> > 
> 
> The problem with emerge -e is that is pull in the whole kitchen sink, so
> all of the circular dependencies will be mixed into that order. What you
> want is a smaller calculation that only updates the intended packages.

Right, but I am fresh out of ides how to do that. Any pointers?

 Jocke

Re: [gentoo-portage-dev] KeyError: 'ED' ?

[Joakim Tjernlund]

On Wed, 2021-05-05 at 16:47 +, Joakim Tjernlund wrote:
> I am upgrading an old portage(2.3.76) to 3.0.18 using qmerge(binary pkg) and 
> I get this:
>  qmerge -OK sys-apps/portage
> [R] sys-apps/portage-3.0.18
>  * Checking for suitable kernel configuration options...
>  [ ok ]
>  * Using python3.8 in global scope
> FEATURES variable contains unknown value(s): disabled
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
> return _run_code(code, main_globals, None,
>   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
> exec(code, run_globals)
>   File 
> "/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py",
>  line 93, in 
> main()
>   File 
> "/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py",
>  line 63, in main
> config_path = os.path.join(os.environ['ED'], 
> GLOBAL_CONFIG_PATH.lstrip(os.sep), 'make.globals')
>   File "/usr/lib/python3.8/os.py", line 675, in __getitem__
> raise KeyError(key) from None
> KeyError: 'ED'
> 
> so portage fails to install properly, I am guessin this is becuse I have an 
> old portage to begin with?
> Can it be fixed?

The error goes away when I do: ED=/ qmerge -OK sys-apps/portage
Does that mean that it is qmerge(aka portage-utils) that needs to set ED during 
merge? which PHASES ?

 Jocke 

[gentoo-portage-dev] KeyError: 'ED' ?

[Joakim Tjernlund]

I am upgrading an old portage(2.3.76) to 3.0.18 using qmerge(binary pkg) and I 
get this:
 qmerge -OK sys-apps/portage
[R] sys-apps/portage-3.0.18
 * Checking for suitable kernel configuration options...
 [ ok ]
 * Using python3.8 in global scope
FEATURES variable contains unknown value(s): disabled
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
  File 
"/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py",
 line 93, in 
main()
  File 
"/var/tmp/qmerge/sys-apps/portage-3.0.18/image/usr/lib/python3.8/site-packages/portage/_compat_upgrade/default_locations.py",
 line 63, in main
config_path = os.path.join(os.environ['ED'], 
GLOBAL_CONFIG_PATH.lstrip(os.sep), 'make.globals')
  File "/usr/lib/python3.8/os.py", line 675, in __getitem__
raise KeyError(key) from None
KeyError: 'ED'

so portage fails to install properly, I am guessin this is becuse I have an old 
portage to begin with?
Can it be fixed?

Also, these "FEATURES variable contains unknown value(s): disabled" could tell 
me which value it does not like.

 Jocke

[gentoo-dev] python and frieds installs test code

[Joakim Tjernlund]

I have noted that python, portage and gentoolkit appers to install many MB of 
what appers
to be test code:
python: /usr/lib/python*/test, /usr/lib/python*/ctypes/test, 
/usr/lib/python*/lib2to3/tests,
/usr/lib/python*/unittest, /usr/lib/python*/distutils/tests ...

portage/gentoolkit:  /usr/lib/python*/site-packages/portage/tests 
/usr/lib/python*/site-packages/gentoolkit/test ..

Didn't look further, I guess there is more pkgs

The question then is, are these required in a running system? 

 Jocke

Re: [gentoo-portage-dev] profile-formats not respected ?

[Joakim Tjernlund]

On Mon, 2021-04-19 at 14:10 -0700, Zac Medico wrote:
> On 4/19/21 6:36 AM, Joakim Tjernlund wrote:
> > I got an embedded ppc32 system which I build in a QEMU user chroot and I 
> > cannot
> > make the profile-formats = portage-2 profile-bashrcs profile-set in my own 
> > profiles layout.conf
> > work for me.
> > Seems like portage just ignores this setting and I cannot understand why.
> > Any pointers?
> > 
> >  Jocke
> > 
> 
> Hopefully this command will provide a clue:
> 
> python -c 'import portage;
> print(portage.settings._locations_manager.profiles_complex)'

Got some progress. I got a profile.bashrc: 
.../my-overlay/profiles/cusfpv3/profile.bashrc
where I setup PKG_INSTALL_MASK/INSTALL_MASK and this does not work in
portage-3.0.18. I can echo the vars. and see them set but portage ignores these 
settings.
This system was previously using a very old portage, 2.3.76 and that was fine.


Another strange thing is my own set, i need to keep that at 
.../my-overlay/{sets, sets.conf}
In our amd64 DE profile I can have my sets at 
.../my-overlay/profiles/infinera/sets , why is that?

Anyhow, here is my profile printout:
./print-port.py 
(_profile_node(location='/usr/portage/profiles/base', 
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False,
show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/default/linux', 
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',),
eapi='5', allow_build_id=False, show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/arch/base', 
portage1_directories=True, user_config=False,
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/arch/powerpc',
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=False),
_profile_node(location='/usr/portage/profiles/default/linux/powerpc', 
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5',
allow_build_id=False, show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/arch/base', 
portage1_directories=True, user_config=False,
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/arch/powerpc',
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=False),
_profile_node(location='/usr/portage/profiles/arch/powerpc/ppc32', 
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5',
allow_build_id=False, show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/default/linux/powerpc/ppc32', 
portage1_directories=True, user_config=False,
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/releases',
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=False),
_profile_node(location='/usr/portage/profiles/releases/17.0', 
portage1_directories=True, user_config=False, 
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False,
show_deprecated_warning=False), 
_profile_node(location='/usr/portage/profiles/default/linux/powerpc/ppc32/17.0',
 portage1_directories=True, user_config=False,
profile_formats=('portage-1-compat',), eapi='5', allow_build_id=False, 
show_deprecated_warning=True), 
_profile_node(location='/usr/local/portage/tmv3-target-
overlay/profiles/cusfpv3', portage1_directories=True, user_config=False, 
profile_formats=('profile-bashrcs', 'portage-2', 'profile-set'), eapi='5', 
allow_build_id=False,
show_deprecated_warning=True), _profile_node(location='/etc/portage/profile', 
portage1_directories=True, user_config=True, 
profile_formats=('profile-bashrcs', 'profile-set'),
eapi=None, allow_build_id=True, show_deprecated_warning=False))

[gentoo-portage-dev] profile-formats not respected ?

[Joakim Tjernlund]

I got an embedded ppc32 system which I build in a QEMU user chroot and I cannot
make the profile-formats = portage-2 profile-bashrcs profile-set in my own 
profiles layout.conf
work for me.
Seems like portage just ignores this setting and I cannot understand why.
Any pointers?

 Jocke

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Thu, 2021-04-15 at 16:35 +, Joakim Tjernlund wrote:
> On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote:
> > Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a):
> > > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
> > > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> > > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> > > > > > in case the package does not work with java > 1.8 (still, i suggest 
> > > > > > we
> > > > > > first try to resolve the issue before we use this restriction as it
> > > > > > might cause some issues in the future)
> > > > > > virtual/jdk:1.8
> > > > > > virtual/jre:1.8
> > > > > This does not seem to be enforced by java eclasses. Example 
> > > > > dev-java/icedtea-web has
> > > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as 
> > > > > system default will
> > > > > try to build with java-11 and the build will fail.
> > > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND.
> > > > regular java apps use classes from jre (java runtime engine) and so they
> > > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this
> > > > icedtea-web issue, this should be filed as a bug. thank you for
> > > > mentioning this.
> > > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and 
> > > changed
> > > RDEPEND to virtual/jdk:1.8 it still fails.
> > yes, looking at that icedtea-web ebuild, it inherits none of java 
> > eclasses so it can't behave as a package that inherits a java eclass. 
> > gyakovlev would definitely know better. generally, this thread is meant 
> > for packages that inherit one of java eclasses, and even that is 
> > oversimplified.
> > > > 
> 
> Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or 
> JAVA_HOME in ebuilds?
> However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to 
> use BDEPEND here?
> 
> Also, RDEPEND does not seem to matter, only BDEPEND

Filed bug https://bugs.gentoo.org/783027 with a small patch, in case you want 
to comment.

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Thu, 2021-04-15 at 18:28 +0200, Miroslav Šulc wrote:
> Dne 15. 04. 21 v 17:56 Joakim Tjernlund napsal(a):
> > On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
> > > Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> > > > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> > > > > in case the package does not work with java > 1.8 (still, i suggest we
> > > > > first try to resolve the issue before we use this restriction as it
> > > > > might cause some issues in the future)
> > > > > virtual/jdk:1.8
> > > > > virtual/jre:1.8
> > > > This does not seem to be enforced by java eclasses. Example 
> > > > dev-java/icedtea-web has
> > > > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as 
> > > > system default will
> > > > try to build with java-11 and the build will fail.
> > > not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND.
> > > regular java apps use classes from jre (java runtime engine) and so they
> > > must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this
> > > icedtea-web issue, this should be filed as a bug. thank you for
> > > mentioning this.
> > Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and 
> > changed
> > RDEPEND to virtual/jdk:1.8 it still fails.
> yes, looking at that icedtea-web ebuild, it inherits none of java 
> eclasses so it can't behave as a package that inherits a java eclass. 
> gyakovlev would definitely know better. generally, this thread is meant 
> for packages that inherit one of java eclasses, and even that is 
> oversimplified.
> > > 

Yes, I found the error in dev-java/icedtea-web. Q: Should one use JDK_HOME or 
JAVA_HOME in ebuilds?
However, BDEPEND vs DEPEND is still outstanding. I don't think it is wrong to 
use BDEPEND here?

Also, RDEPEND does not seem to matter, only BDEPEND

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Thu, 2021-04-15 at 17:21 +0200, Miroslav Šulc wrote:
> Dne 15. 04. 21 v 16:34 Joakim Tjernlund napsal(a):
> > On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> > > in case the package does not work with java > 1.8 (still, i suggest we
> > > first try to resolve the issue before we use this restriction as it
> > > might cause some issues in the future)
> > > virtual/jdk:1.8
> > > virtual/jre:1.8
> > 
> > This does not seem to be enforced by java eclasses. Example 
> > dev-java/icedtea-web has
> > BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system 
> > default will
> > try to build with java-11 and the build will fail.
> not sure about BDEPEND but it should be enforced for DEPEND and RDEPEND. 
> regular java apps use classes from jre (java runtime engine) and so they 
> must have the dep both in DEPEND and RDEPEND, not BDEPEND. wrt this 
> icedtea-web issue, this should be filed as a bug. thank you for 
> mentioning this.

Don't think it is so simple, even if I add virtual/jdk:1.8 to DEPEND and changed
RDEPEND to virtual/jdk:1.8 it still fails.


> >   Jocke
> 
> fordfrog
> 
> 

Re: [gentoo-dev] unmasking java 11 on gentoo (for those that maintain packages where java is involved, either directly or conditionally)

[Joakim Tjernlund]

On Wed, 2021-04-14 at 09:45 +0200, Miroslav Šulc wrote:
> 
> in case the package does not work with java > 1.8 (still, i suggest we 
> first try to resolve the issue before we use this restriction as it 
> might cause some issues in the future)
> virtual/jdk:1.8
> virtual/jre:1.8


This does not seem to be enforced by java eclasses. Example 
dev-java/icedtea-web has
BDEPEND=virtual/jdk:1.8 but building icedtea-web with openjdk:11 as system 
default will
try to build with java-11 and the build will fail.

 Jocke

[gentoo-dev] anongit.gentoo.org/repo/sync/gentoo.git not syncing any more?

[Joakim Tjernlund]

Re: [gentoo-portage-dev] [PATCH v3] env-update: create systemd env configuration if required

[Joakim Tjernlund]

On Thu, 2020-09-03 at 15:06 +0200, Florian Schmaus wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Portage's env-update currently transforms the environment information
> from /etc/env.d into /etc/profile.env, which is typically sourced by
> every user session, setting up its environment.
> 
> However, /etc/profile.env is not sourced by systemd user
> services. Instead, for the definition of a systemd user session
> environment, the 'environment.d' machinery exists. Unfortunately, up
> to now, env-update does not produce a profile.env equivalent for this
> machinery, causing issues for systemd user services. For example,
> an emacs daemon run a user systemd service does not have a complete
> PATH (bug #704412 [1]), because some PATH components are injected by
> packages via /etc/env.d. For example, an LLVM ebuild may set
> PATH="/usr/lib/llvm/9/bin".
> 
> This commit changes env-update so that, after profile.env has was
> generated, a systemd user session environment configuration file named
> 
> /etc/environment.d/gentoo-profile-env.conf

Are files /etc/environment.d/ ordered in anyway? If so it might be a good idea
to name the file 10-gentoo-profile-env.conf or similar.

 Jocke

Re: [gentoo-portage-dev] profile masking

[Joakim Tjernlund]

On Fri, 2020-08-14 at 23:12 +0200, Michał Górny wrote:
> On Fri, 2020-08-14 at 15:42 +0000, Joakim Tjernlund wrote:
> > On Fri, 2020-08-14 at 17:31 +0200, Ulrich Mueller wrote:
> > > > > > > > On Fri, 14 Aug 2020, Joakim Tjernlund wrote:
> > > > When pkgs are masked in the profile, it affects all variants of that
> > > > pkgs, even the ones that are in other overlays.
> > > > Example:
> > > > !!! The following installed packages are masked:
> > > > - sys-auth/sssd-::transmode (masked by: package.mask)
> > > > /usr/portage/profiles/package.mask:
> > > > # Matt Turner  (2020-08-13)
> > > > # Masked for testing
> > > > My sssd- is now masked.
> > > > Could the profile syntax be extended to include syntax allowed in
> > > > /etc/portage ? Then one could use the ::gentoo syntax (or so I hope)
> > > 
> > > The :: syntax is Portage specific and doesn't exist in EAPI 7.
> > > So there's no chance to get it into the profile dir anytime soon
> > > (because that would imply :: to be added to a future EAPI and the
> > > top-level profile dir to be bumped to that EAPI).
> > 
> > Is profile part of EAPI? masks are not defined/used in ebuilds directly.
> > 
> > > You could override the mask in your overlay's profile/package.mask
> > > instead, using an entry with the "-" operator.
> > 
> > Yes, I know I can add that in profile/package.mask but I am looking for the 
> > bigger
> > picture here. This has to stop somehow, there need to be something that 
> > limits
> > the mask scope to the repo/overlay it is defined.
> > 
> 
> Why is that?  I dare say the bigger picture needs to include different
> mask reasons.  Sure, 'masked for testing' may or may not make little
> sense for live ebuilds.  However, 'masked for security issues' may
> pretty apply to custom repo ebuilds as well.
> 

Possibly, but the way you mask Test/Security should then be referring to 
specific versions,
not all possible versions in the universe.

 Jocke 

Re: [gentoo-portage-dev] profile masking

[Joakim Tjernlund]

On Fri, 2020-08-14 at 17:31 +0200, Ulrich Mueller wrote:
> > > > > > On Fri, 14 Aug 2020, Joakim Tjernlund wrote:
> 
> > When pkgs are masked in the profile, it affects all variants of that
> > pkgs, even the ones that are in other overlays.
> > Example:
> > !!! The following installed packages are masked:
> > - sys-auth/sssd-::transmode (masked by: package.mask)
> > /usr/portage/profiles/package.mask:
> > # Matt Turner  (2020-08-13)
> > # Masked for testing
> 
> > My sssd- is now masked.
> 
> > Could the profile syntax be extended to include syntax allowed in
> > /etc/portage ? Then one could use the ::gentoo syntax (or so I hope)
> 
> The :: syntax is Portage specific and doesn't exist in EAPI 7.
> So there's no chance to get it into the profile dir anytime soon
> (because that would imply :: to be added to a future EAPI and the
> top-level profile dir to be bumped to that EAPI).

Is profile part of EAPI? masks are not defined/used in ebuilds directly.

> 
> You could override the mask in your overlay's profile/package.mask
> instead, using an entry with the "-" operator.

Yes, I know I can add that in profile/package.mask but I am looking for the 
bigger
picture here. This has to stop somehow, there need to be something that limits
the mask scope to the repo/overlay it is defined.

I think a good start would be to consider /etc/portage the top profile and other
subprofiles should be able to use the same features as /etc/portage.

Portage could start supporting that now, but there would be a while until
one can use them in Gentoo profile.

Meanwhile one should ban masks containing > and instead use exact revision of 
the package.

 Jocke

[gentoo-portage-dev] profile masking

[Joakim Tjernlund]

When pkgs are masked in the profile, it affects all variants of that pkgs, even 
the ones that are in other
overlays.
Example:
!!! The following installed packages are masked:
- sys-auth/sssd-::transmode (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Matt Turner  (2020-08-13)
# Masked for testing

My sssd- is now masked.

Could the profile syntax be extended to include syntax allowed in /etc/portage ?
Then one could use the ::gentoo syntax (or so I hope)

 Jocke

Re: [gentoo-portage-dev] Passing CFLAGS="-fdebug-prefix-map=..=$(readlink -f ..)"

[Joakim Tjernlund]

On Sat, 2020-06-27 at 14:00 +, Joakim Tjernlund wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> I am trying to add -fdebug-prefix-map to my CFLAGS but cannot get past 
> "$(readlink -f ..)"
> Portage will not expand $(anything)
> 
> Any way to make portage expand "$(readlink -f ..)" ?
> 
>  Jocke

Found it /etc/portage/bashrc add:

if [ $EBUILD_PHASE = configure ]; then
   echo "Adding -fdebug-prefix-map to CFLAGS/CXXFLAGS"
   CFLAGS="$CFLAGS -fdebug-prefix-map=..=$(readlink -f ..)"
   CXXFLAGS="$CXXFLAGS -fdebug-prefix-map=..=$(readlink -f ..)"
fi

[gentoo-portage-dev] Passing CFLAGS="-fdebug-prefix-map=..=$(readlink -f ..)"

[Joakim Tjernlund]

I am trying to add -fdebug-prefix-map to my CFLAGS but cannot get past 
"$(readlink -f ..)"
Portage will not expand $(anything)

Any way to make portage expand "$(readlink -f ..)" ?

 Jocke

Re: [gentoo-dev] [PATCH 3/4] dev-util/jenkins-bin: bump to v2.204.1

[Joakim Tjernlund]

On Wed, 2019-12-25 at 16:11 +0100, Thomas Deutschmann wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Package-Manager: Portage-2.3.82, Repoman-2.3.20
> Signed-off-by: Thomas Deutschmann 
> ---
>  dev-util/jenkins-bin/Manifest |  1 +
>  .../jenkins-bin/jenkins-bin-2.204.1.ebuild| 47 +++
>  2 files changed, 48 insertions(+)
>  create mode 100644 dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> 
> diff --git a/dev-util/jenkins-bin/Manifest b/dev-util/jenkins-bin/Manifest
> index 39d97b60d3e..854cbb4f581 100644
> --- a/dev-util/jenkins-bin/Manifest
> +++ b/dev-util/jenkins-bin/Manifest
> @@ -2,4 +2,5 @@ DIST jenkins-bin-2.190.1.war 78245883 BLAKE2B 
> 6c80eaebc6fe34e2c889c78a34dfc3e105
>  DIST jenkins-bin-2.190.2.war 78243424 BLAKE2B 
> 7a6bd4cf1c070ce3a09fb84b3dbe7e87f474f4254dd4b4fcffdd7dedf7d4c2ba91d8783e727321439bfeb02da721e4d539cba76312c21b523a9bf336a964
>  SHA512 
> b1f59ef10dfdfda06bedbf9a40a9e83e159b44b2b5574cba4d62547294386224f64d856490fd4477fb3300a4119d17fc284819719218dfcf32d3dc20ce468847
>  DIST jenkins-bin-2.190.3.war 78247363 BLAKE2B 
> 99d4c13236b4b4f7308c7993033d1e5f9dd2fd9926febf52ffdacea595fecaba0d0eb8962761d8a6f983eaf9738f8be1ba4df785bb2fe6b613ac8cadcc618e23
>  SHA512 
> 4ffa2ce3be4d55f0df8021026115d9ce8f1d0f4faa16eaf9f327ce17105f61731730c2a0124fb9af5d8c16c8fee9200f9b785b23856896e292a19f5404a9d2c2
>  DIST jenkins-bin-2.197.war 78309466 BLAKE2B 
> c3d34c6fc40a82148eafa978c8787375ece6522d0d936b42f0296ee13cd084669bfa31975c0ad27816bdd4c1266cb066c0909774199a1373661a7ec524c06e91
>  SHA512 
> 3b6a00dee5aeb8a94c8f75323c2469b54fe96d90bf8371898e41dc5bdecaa472f112bff1466481c66c9c7a07b22cbe799a08e45ac486d68fd5bdc7c20d43d722
> +DIST jenkins-bin-2.204.1.war 63433755 BLAKE2B 
> 53cb254ddf3b59e083b564adf8d5696c61012e6d0d26b622eac7023268d5ba3d43082d07cae5654e032169cd144a5338f2553d4ee39c851c4126fe0be5378f1e
>  SHA512 
> 2ebf1ff7792a2ba80d8cf6f8675864580533b62659346e9ef3334ff988899d735d5d72cb3a89308cd9287bcaa74c42306cbf80a716d03658ad748688f94f394b
>  DIST jenkins-bin-2.205.war 62738246 BLAKE2B 
> de350469e3a6e0d93f6d05c38f7669ce630f01a0284db83a0ba002e15ef712b4dddca6dcac804ab45c898f5c73cdac99bfe9b9bb99f6534c1446d8f4545660ec
>  SHA512 
> 1c0b12cdf7dadaba8d81ede769f76b059c7869732610353658cc928dd8c4943f8cf8beb15498a0dd4e064688cfdb7f88faaa9165c6da97c20d5e99080a12f413
> diff --git a/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild 
> b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> new file mode 100644
> index 000..f29b83b491f
> --- /dev/null
> +++ b/dev-util/jenkins-bin/jenkins-bin-2.204.1.ebuild
> @@ -0,0 +1,47 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit systemd
> +
> +DESCRIPTION="Extensible continuous integration server"
> +HOMEPAGE="https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjenkins.io%2Fdata=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cf63d3323a1844a3463cc08d7894d0284%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637128836158940038sdata=EZ5QAWXzcxCKufgyrnYoYyL4uPSmG5rENE4zQG747Gg%3Dreserved=0;
> +LICENSE="MIT"
> +SRC_URI="https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirrors.jenkins-ci.org%2Fwar-stable%2F%24data=02%7C01%7Cjoakim.tjernlund%40infinera.com%7Cf63d3323a1844a3463cc08d7894d0284%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C637128836158940038sdata=YZPJP7qtEM17poTYYuclipefI2YRyt1AF2PPaQjoL1I%3Dreserved=0{PV}/${PN/-bin/}.war
>  -> ${P}.war"
> +RESTRICT="mirror"
> +SLOT="lts"
> +KEYWORDS="~amd64 ~x86 ~amd64-linux"
> +IUSE=""
> +
> +COMMON_DEPS="acct-user/jenkins
> +   acct-group/jenkins"
> +
> +DEPEND="${COMMON_DEPS}"
> +
> +RDEPEND="${COMMON_DEPS}
> +   media-fonts/dejavu
> +   media-libs/freetype
> +   !dev-util/jenkins-bin:0
> +   >=virtual/jre-1.8.0"
> +
> +S=${WORKDIR}
> +
> +JENKINS_DIR=/var/lib/jenkins

Home dir is hardcoded, should just follow what acct-user/jenkins has defined.
Then one can finally choose some other dir for jenkins without duplicating the 
ebuild.

  Jocke

Re: [gentoo-portage-dev] Build path abi missing in qemu-user

[Joakim Tjernlund]

On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund
>  wrote:
> > When build in a qemu-user chroot I get odd build paths:
> >   /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc
> > 
> > This path is missing the abi_ppc_32 like so:
> >   
> > /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc
> > 
> > I struggle to find out why this happens, any ideas?
> 
> I would guess you are using a profile that doesn't define the ABI_PPC
> USE_EXPAND variable properly.
> 
# portageq envvar USE_EXPAND
ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS 
CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS 
CURL_SSL DRACUT_MODULES
DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES 
FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL LCD_DEVICES 
LIBREOFFICE_EXTENSIONS
LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP 
NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS 
OPENMPI_OFED_FEATURES OPENMPI_RM
PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS 
QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND 
UWSGI_PLUGINS VIDEO_CARDS
VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS
cu3-jocke fs # portageq envvar ABI_PPC
32
cu3-jocke fs # eselect profile list
Available profile symlink targets:
  [1]   default/linux/powerpc/ppc32/13.0
  [2]   default/linux/powerpc/ppc32/13.0/desktop
  [3]   default/linux/powerpc/ppc32/13.0/desktop/gnome
  [4]   default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd
  [5]   default/linux/powerpc/ppc32/13.0/desktop/kde
  [6]   default/linux/powerpc/ppc32/13.0/desktop/kde/systemd
  [7]   default/linux/powerpc/ppc32/13.0/developer
  [8]   default/linux/powerpc/ppc64/13.0/32bit-userland
  [9]   default/linux/powerpc/ppc64/13.0/32bit-userland/desktop
  [10]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome
  [11]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd
  [12]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde
  [13]  default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd
  [14]  default/linux/powerpc/ppc64/13.0/32bit-userland/developer
  [15]  hardened/linux/powerpc/ppc32
  [16]  hardened/linux/powerpc/ppc64/32bit-userland
  [17]  hardened/linux/musl/ppc
  [18]  default/linux/uclibc/ppc
  [19]  hardened/linux/uclibc/ppc
  [20]  tmv3-target-overlay:cusfpv3 *

cusfpv3 inherits default/linux/powerpc/ppc32/13.0

 Jocke

[gentoo-portage-dev] Build path abi missing in qemu-user

[Joakim Tjernlund]

When build in a qemu-user chroot I get odd build paths:
  /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc

This path is missing the abi_ppc_32 like so:
  /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc

I struggle to find out why this happens, any ideas?

 Jocke

Re: [gentoo-portage-dev] profile.bashrc variables

[Joakim Tjernlund]

On Tue, 2019-11-19 at 22:40 -0800, Zac Medico wrote:
> On 11/19/19 2:17 PM, Joakim Tjernlund wrote:
> > cat profile.bashrc 
> > if [ "${HOSTNAME}" == "gentoo64.infinera.com" ]; then
> ># This does not work, why?
> >[ -z "$_once" ] && EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} -k n" && 
> > _once=1
> >[ -z "$_fonce" ] && FEATURES="${FEATURES} buildpkg" && _fonce=1
> >export EMERGE_DEFAULT_OPTS
> >export FEATURES
> > fi
> > 
> > If I add logging inside I see that these are set but emerge
> > does not build binpkgs, what am I missing ?
> > 
> > sys-apps/portage-2.3.79
> > 
> > Jocke
> > 
> 
> You can use /etc/portage/package.env to modify FEATURES. The bashrc is
> evaluated only when executing ebuilds, so it's not appropriate for
> FEATURES modifications.

I did try adding --buildpkg to EMERGE_DEFAULT_OPTS too, same result
I do need to do this in the profile and last I tried package.env it didn't work
in profiles, has that changed?

In general I think /etc/portage is just another profile so things like
package.env should also work in a regular profile.
While at package.env, the other day I wanted do in package.env:
if not "cat/pkg" do my_extra.conf but I could not find
a NOT syntax for package.env, is there one?

 Jocke

[gentoo-portage-dev] profile.bashrc variables

[Joakim Tjernlund]

cat profile.bashrc 
if [ "${HOSTNAME}" == "gentoo64.infinera.com" ]; then
   # This does not work, why?
   [ -z "$_once" ] && EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} -k n" && 
_once=1
   [ -z "$_fonce" ] && FEATURES="${FEATURES} buildpkg" && _fonce=1
   export EMERGE_DEFAULT_OPTS
   export FEATURES
fi

If I add logging inside I see that these are set but emerge
does not build binpkgs, what am I missing ?

sys-apps/portage-2.3.79

Jocke

Re: [gentoo-portage-dev] SLOT move of sys-libs/ncurses-5.9-r5(0/5) to sys-libs/ncurses-compat-5.9-r5(5/5) ?

[Joakim Tjernlund]

On Thu, 2019-11-14 at 16:38 +0100, Ulrich Mueller wrote:
> >>>>> On Thu, 14 Nov 2019, Joakim Tjernlund wrote:
> 
> > And pkg move will move all pkgs within sys-libs/ncurses ?
> 
> Yes, "move" only accepts (qualified) package names without versions.
> 
> > Or could portage move only sys-libs/ncurses-5.9-r5 to
> > sys-libs/ncurses-compat-5.9-r5 ?
> 
> No.
> 
> Ulrich

Ok, but isn't there some time span on pkg/slot moves? 
 

Re: [gentoo-portage-dev] SLOT move of sys-libs/ncurses-5.9-r5(0/5) to sys-libs/ncurses-compat-5.9-r5(5/5) ?

[Joakim Tjernlund]

On Thu, 2019-11-14 at 14:06 +0100, Michał Górny wrote:
> On Thu, 2019-11-14 at 13:01 +0000, Joakim Tjernlund wrote:
> > Is there way to move the above with current portage ?
> > 
> 
> No.  Slot moves work only within a package.
> 

And pkg move will move all pkgs within sys-libs/ncurses ?
Or could portage move only sys-libs/ncurses-5.9-r5 to
sys-libs/ncurses-compat-5.9-r5 ?

 Jocke 

[gentoo-portage-dev] SLOT move of sys-libs/ncurses-5.9-r5(0/5) to sys-libs/ncurses-compat-5.9-r5(5/5) ?

[Joakim Tjernlund]

Is there way to move the above with current portage ?

 Jocke

Re: [gentoo-portage-dev] Re: seed emerge with old /var/db/pkg ?

[Joakim Tjernlund]

On Wed, 2019-11-13 at 11:07 -0800, Zac Medico wrote:
> On 11/8/19 9:09 AM, Joakim Tjernlund wrote:
> > On Fri, 2019-11-08 at 01:57 +0100, Joakim Tjernlund wrote:
> >> I am looking for a way to seed emerge with an older pkg db so emerge can 
> >> calculate
> >> which packages needs to be rebuild/upgraded in order to get to the same 
> >> state as the system pkg db,
> >> Is that possible?
> >>
> >> Also, is there some tool that allows med to copy just files needed for a 
> >> profile?
> >> Something like "cp" /etc/portage/make.profile /my/destination
> >>
> > 
> > portage-utils has variables Q_VDB and Q_EDB which allows qmerge to use 
> > different VDBs/EDBs
> > Does portage have something similar?
> 
> No, nothing like either of those things.
> 
> However, if you want to operate on an old system then the usual
> recommendation is to unpack a stage3 and bind mount the old system root
> into the stage3 so that you can chroot into the stage3 and run something
> like this:
> 
> emerge --root /mnt/old-system portage

Nice trick, but not quite what I want to do. 
Simply described I build binary pkgs which I tar together, transfer to an 
remote embedded system
and install these using qmerge(from portage-utils)

The problem is how make sure I got just the pkgs I need.

I build binary pkgs on the same HW using emerge and this is performed over time 
and
when release comes I package those bin pkgs and at that time I need some way to 
make sure
I got what the right pkgs. I figured I could use emerge to generate the 
difference
for me and the compare that list with the bin pkgs I have.

Maybe there is a simpler way to do this? I have the old VDB and the new VDB 
I need this list to be in dependency order too.

 Jocke  

[gentoo-portage-dev] Re: seed emerge with old /var/db/pkg ?

[Joakim Tjernlund]

On Fri, 2019-11-08 at 01:57 +0100, Joakim Tjernlund wrote:
> I am looking for a way to seed emerge with an older pkg db so emerge can 
> calculate
> which packages needs to be rebuild/upgraded in order to get to the same state 
> as the system pkg db,
> Is that possible?
> 
> Also, is there some tool that allows med to copy just files needed for a 
> profile?
> Something like "cp" /etc/portage/make.profile /my/destination
> 

portage-utils has variables Q_VDB and Q_EDB which allows qmerge to use 
different VDBs/EDBs
Does portage have something similar?

[gentoo-portage-dev] seed emerge with old /var/db/pkg ?

[Joakim Tjernlund]

I am looking for a way to seed emerge with an older pkg db so emerge can 
calculate
which packages needs to be rebuild/upgraded in order to get to the same state 
as the system pkg db,
Is that possible?

Also, is there some tool that allows med to copy just files needed for a 
profile?
Something like "cp" /etc/portage/make.profile /my/destination

Re: [gentoo-portage-dev] portageq not reading profile.bashrc

[Joakim Tjernlund]

On Mon, 2019-11-04 at 18:35 +, Joakim Tjernlund wrote:
> 
> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
> 
> cat profile.bashrc
> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
> export INSTALL_MASK
> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
> 
> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
> export PKG_INSTALL_MASK
> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
> 
> Using portageq envvar INSTALL_MASK I expect to see my settings but
> INSTALL_MASK is empty.
> 
> Am I missing something ?
> 
>Jocke

in profile make.defaults I have
  CONFIG_PROTECT=""
yet I see:
portageq envvar CONFIG_PROTECT
/etc

Is portageq envvar somewhat broken?

[gentoo-portage-dev] portageq not reading profile.bashrc

[Joakim Tjernlund]

I have a profile.bashrc in my profile where I try to set INSTALL_MASK:

cat profile.bashrc 
INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
export INSTALL_MASK
echo "profile INSTALL_MASK: ${INSTALL_MASK}"

PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
export PKG_INSTALL_MASK
echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"

Using portageq envvar INSTALL_MASK I expect to see my settings but
INSTALL_MASK is empty.

Am I missing something ?

   Jocke

[gentoo-portage-dev] FEATUES=noman nodoc noinfo and ebuild command

[Joakim Tjernlund]

Hi 

I just did ebuild binutils-2.32-r1.ebuild install qmerge
on my target and noticed that I still got man pages etc:
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/ld.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/c++filt.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/windmc.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/windres.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/elfedit.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/strip.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/strings.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/size.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/readelf.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/ranlib.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/objdump.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/objcopy.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/nm.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/dlltool.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/ar.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/addr2line.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/gprof.1
/usr/share/binutils-data/powerpc-unknown-linux-gnu/2.32/man/man1/as.1


portageq envvar FEATURES has:
assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg 
config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync 
multilib-strict news nodoc noinfo noman parallel-fetch preserve-libs 
protect-owned sfperms strict unknown-features-warn unmerge-logs unmerge-orphans 
userfetch userpriv usersync xattr

I would expect noman etc would omit man pages, info etc here?

sys-apps/portage-2.3.76


 Jocke

[gentoo-portage-dev] Portage upgrade from 2.3.62 to 2.3.65 fails

[Joakim Tjernlund]

Trying to upgrade portage in an older embedded target I get:
When upgrading from old 2.3.62 
>>> Merging sys-apps/portage-2.3.65 to /
/usr/bin/python3.4: Error while finding spec for 
'portage._compat_upgrade.default_locations' (: No module 
named 'portage._compat_upgrade')
 * ERROR: sys-apps/portage-2.3.65::tmv3-target-overlay failed (preinst 
phase):
 *   (no error message)
 *
 * Call stack:
 * ebuild.sh, line 133:  Called pkg_preinst
 *   environment, line 3193:  Called die
 * The specific snippet of code:
 *   env -u DISTDIR -u PORTAGE_OVERRIDE_EPREFIX -u PORTAGE_REPOSITORIES 
-u PORTDIR -u PORTDIR_OVERLAY 
PYTHONPATH="${D%/}${PYTHON_SITEDIR}${PYTHONPATH:+:${PYTHONPATH}}" "${PYTHON}" 
-m portage._compat_upgrade.default_locations || die;
 *

Not a python expert but isn't portage trying to use a new function in 
portage(portage._compat_upgrade.default_locations) before
it is installed?

How should I resolve this?


 Jocke

Re: [gentoo-portage-dev] portage user not listed in /etc/shadow ?

[Joakim Tjernlund]

On Wed, 2019-01-16 at 12:20 +, M. J. Everitt wrote:
> On 16/01/19 11:58, Joakim Tjernlund wrote:
> > How come portage isn't in shadow, only in passwd ?
> > Seems wrong to me.
> >
> >  Jocke
> Because the portage user never logs on .. hence has no password. That said,

That goes for evry other system account too but these are in shadow.

> it does seem an odd situation, since even users with no password do tend to
> appear in /etc/shadow .. perhaps it was/is never "properly" added as a user
> 

I think/hope so. Now passwd looks like so:
portage:x:250:250:portage:/var/tmp/portage:/bin/false
This looks like a shadow account. Because of the missing entry passwd
thinks this is a normal account:
# > passwd -S portage 
portage P
as opposed to:
# > passwd  -S daemon
daemon L 10/28/1996 0 -1 -1 -1

 Jocke

[gentoo-portage-dev] portage user not listed in /etc/shadow ?

[Joakim Tjernlund]

How come portage isn't in shadow, only in passwd ?
Seems wrong to me.

 Jocke

[gentoo-portage-dev] x32 mode ?

[Joakim Tjernlund]

 ps uaww| grep emerg
root 22140 99.7  2.6 768204 655412 pts/34  R+   09:22   6:26 
/usr/bin/python3.4 -b /usr/lib/python-
exec/python3.4/emerge -aNDuv world
jocke25434  0.0  0.0  10860   916 pts/22   S+   09:29   0:00 grep 
--colour=auto emerg
jocke@gentoo-jocke ~ $ sudo strace -p 22140
strace: Process 22140 attached
strace: [ Process PID=22140 runs in x32 mode. ]
^Cstrace: Process 22140 detached
 uname -m
x86_64
How did x32 happen? Can I do something about it?

 Jocke

Re: [gentoo-portage-dev] Avoid stripping ld.so ?

[Joakim Tjernlund]

On Thu, 2018-08-30 at 20:12 +0100, Sergei Trofimovich wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Thu, 30 Aug 2018 07:37:16 +
> Joakim Tjernlund  wrote:
> 
> > > > Tweaking ebuild to expand STRIP_MASK for ld.so might help.
> > > 
> > > OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf 
> > > or
> > > in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"
> 
> I believe you can't. You would have to resort to /etc/portage/bashrc
> hacks to override ebuilds' value. Requesting new feature from dev-portage@
> sounds reasonable.
> 
> For example, add STRIP_MASK_USER to be controlled by user.
> 
> STRIP_MASK is normally used for cases when software breaks when
> stripped (examples: not-quite-ELF files, not-yet-linked .o files). Not
> something for convenience or niche purposes.
> 
> STRIP_MASK_USER might be a good way to fine-grain desired policy
> of stripping package on top of existing FEATURES=nostrip knob.

Yes, I like this idea with STRIP_MASK_USER

 Jocke

Re: [gentoo-portage-dev] Avoid stripping ld.so ?

[Joakim Tjernlund]

On Thu, 2018-08-30 at 09:15 +0200, Joakim Tjernlund wrote:
> On Wed, 2018-08-29 at 23:58 +0100, Sergei Trofimovich wrote:
> > CAUTION: This email originated from outside of the organization. Do not 
> > click links or open attachments unless you recognize the sender and know 
> > the content is safe.
> > 
> > 
> > On Wed, 29 Aug 2018 20:10:54 +
> > Joakim Tjernlund  wrote:
> > 
> > > Is there a way for portage to avoid strippning debug syms for ld.so ?
> > 
> > Tweaking ebuild to expand STRIP_MASK for ld.so might help.
> 
> OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf or
> in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"
> 
> > 
> > > I would like to avoid building all of glibc with debug syms.
> > 
> > s/building/installing, right?
> 
> Right :) I need to keep the stuff valgrind need. Don't recall if that
> just needs an unstripped ld.so or if ld.so needs debug syms as well.
> 
> > 
> > You will have to build all (or large part) of glibc with debug
> > symbols anyways as ld.so is linked of multiple source files.
> 
> Yes, I just need to build glibc with -g and avoid stripping ld.so
> 
> I think this should be default/USE flag for glibc, it would be a
> nice feature so one does not need to rebuild glibc(and extra space)
> run valgrind.

Arch seems to keep syms too:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/glibc#n178
# Do not strip these for gdb and valgrind functionality, but strip the rest
find "$pkgdir"/usr/lib \
  -not -name 'ld-*.so' \
  -not -name 'libc-*.so' \
  -not -name 'libpthread-*.so' \
  -not -name 'libthread_db-*.so' \
  -name '*-*.so' -type f -exec strip $STRIP_SHARED {} + 2> /dev/null || true

Re: [gentoo-portage-dev] Avoid stripping ld.so ?

[Joakim Tjernlund]

On Wed, 2018-08-29 at 23:58 +0100, Sergei Trofimovich wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> On Wed, 29 Aug 2018 20:10:54 +
> Joakim Tjernlund  wrote:
> 
> > Is there a way for portage to avoid strippning debug syms for ld.so ?
> 
> Tweaking ebuild to expand STRIP_MASK for ld.so might help.

OK, can I use STRIP_MASK outside ebuilds, like in /etc/portage/make.conf or
in my profile? Something like STRIP_MASK="/lib64/ld-* /lib/ld-*"

> 
> > I would like to avoid building all of glibc with debug syms.
> 
> s/building/installing, right?

Right :) I need to keep the stuff valgrind need. Don't recall if that
just needs an unstripped ld.so or if ld.so needs debug syms as well.

> 
> You will have to build all (or large part) of glibc with debug
> symbols anyways as ld.so is linked of multiple source files.

Yes, I just need to build glibc with -g and avoid stripping ld.so

I think this should be default/USE flag for glibc, it would be a
nice feature so one does not need to rebuild glibc(and extra space)
run valgrind.

> 
> --
> 
>   Sergei

[gentoo-portage-dev] Avoid stripping ld.so ?

[Joakim Tjernlund]

Is there a way for portage to avoid strippning debug syms for ld.so ?
I would like to avoid building all of glibc with debug syms.

 Jocke 

Re: [gentoo-dev] EAPI 7 can be used in the Gentoo repository

[Joakim Tjernlund]

Great news :)

W.r.t the new support for cross building, it would be grep if the eclass user 
could make use of
the new --prefix support in recent shadow utilities so users can be added to 
cross ROOT.

Jocke

On Sun, 2018-05-06 at 18:52 +0200, Ulrich Mueller wrote:
EAPI 7 has been approved by the Council one week ago [1]. The latest
Portage version in ~arch (2.3.36) supports it, and the Infra team has
upgraded the rsync master so that metadata cache generation will work
correctly.

Therefore, EAPI 7 ebuilds can be committed to the Gentoo repository
from now on. (Make sure that all inherited eclasses are supporting the
new EAPI, though.)

Some pointers to documentation:

- Package Manager Specification, in PDF and HTML format:
  https://projects.gentoo.org/pms/latest/
  or install ~app-doc/pms-7_p20180430

- List of changes in EAPI 7:
  https://projects.gentoo.org/pms/7/pms.html#x1-179000E

- EAPI Cheat Sheet (print out, and fold to a leaflet):
  https://projects.gentoo.org/pms/7/eapi-cheatsheet.pdf

- mgorny's (unofficial) guide:
  https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html

Ulrich

[1] https://bugs.gentoo.org/654262

[gentoo-portage-dev] EBUILD_PHASE for INSTALL_MASK ?

[Joakim Tjernlund]

I have a profile.bashrc which generates INSTALL_MASK dynamically and I want
to only run that during "merge"(when INSTALL_MASK is used by portage) but 
I cannot find a phase which matches.

Am I missing something ? Is there some other variable I can use instead?

 Jocke

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Fri, 2018-03-23 at 09:33 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> W dniu pią, 23.03.2018 o godzinie 00∶52 +, użytkownik Joakim
> Tjernlund napisał:
> > On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
> > > On 03/15/2018 12:22 PM, Michał Górny wrote:
> > > > Hi,
> > > > 
> > > > Here are three of four INSTALL_MASK updates I've sent long time ago
> > > > which were not really reviewed. The fourth patch added support
> > > > for repo-defined install-mask.conf and I'll do that separately.
> > > > 
> > > > Those patches focus on smaller changes. What they change, in order:
> > > > 
> > > > 1. Removes explicit file removal code for FEATURES=no*. Instead, those
> > > >values are converted into additional INSTALL_MASK entries
> > > >and handled directly via INSTALL_MASK processing.
> > > > 
> > > > 2. Rework INSTALL_MASK to filter files while installing instead of
> > > >pre-stripping them. In other words, before: INSTALL_MASK removes
> > > >files from ${D} before merge. After: ${D} contains all the files,
> > > >Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.
> > > > 
> > > > 3. Adds support for exclusions in INSTALL_MASK. In other words, you
> > > >can do stuff like:
> > > > 
> > > >  INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US"
> > > > 
> > > > I have been using this via user patches since the last submission.
> > > > Guessing by 'git log', this means almost 2 years now.
> > > > 
> > > > --
> > > > Best regards,
> > > > Michał Górny
> > > > 
> > > > Michał Górny (3):
> > > >   portage.package.ebuild.config: Move FEATURES=no* handling there
> > > >   portage.dbapi.vartree: Move INSTALL_MASK handling into merging
> > > >   portage.dbapi.vartree: Support exclusions in INSTALL_MASK
> > > > 
> > > >  bin/misc-functions.sh|  30 --
> > > >  pym/portage/dbapi/vartree.py | 104 
> > > > ++-
> > > >  pym/portage/package/ebuild/config.py |  11 
> > > >  3 files changed, 77 insertions(+), 68 deletions(-)
> > > > 
> > > 
> > > As mentioned in #gentoo-portage today, the rationale for including the
> > > INSTALL_MASKed files in CONTENTS is to that we can detect collisions
> > > that would have occurred had people not been using INSTALL_MASK.
> > > 
> > > Since people can use INSTALL_MASK to intentionally prevent collisions,
> > > in cases where COLLISION_IGNORE is not appropriate (this is common
> > > practice at my workplace), we'll need a new FEATURES setting to trigger
> > > the new behavior where INSTALL_MASKed files still trigger file collisions.
> > 
> > Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?
> 
> It's in sys-apps/portage-mgorny. Whatever's going to land in sys-
> apps/portage, it's probably going to be half-broken to satisfy
> somebody's colleague's corner case of misusing INSTALL_MASK.

I looked and saw the INSTALL_MASK part but no mention of PKG_INSTALL_MASK(which 
is what I need)

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Mon, 2018-03-19 at 15:59 -0700, Zac Medico wrote:
> On 03/15/2018 12:22 PM, Michał Górny wrote:
> > Hi,
> > 
> > Here are three of four INSTALL_MASK updates I've sent long time ago
> > which were not really reviewed. The fourth patch added support
> > for repo-defined install-mask.conf and I'll do that separately.
> > 
> > Those patches focus on smaller changes. What they change, in order:
> > 
> > 1. Removes explicit file removal code for FEATURES=no*. Instead, those
> >values are converted into additional INSTALL_MASK entries
> >and handled directly via INSTALL_MASK processing.
> > 
> > 2. Rework INSTALL_MASK to filter files while installing instead of
> >pre-stripping them. In other words, before: INSTALL_MASK removes
> >files from ${D} before merge. After: ${D} contains all the files,
> >Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.
> > 
> > 3. Adds support for exclusions in INSTALL_MASK. In other words, you
> >can do stuff like:
> > 
> >  INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US"
> > 
> > I have been using this via user patches since the last submission.
> > Guessing by 'git log', this means almost 2 years now.
> > 
> > --
> > Best regards,
> > Michał Górny
> > 
> > Michał Górny (3):
> >   portage.package.ebuild.config: Move FEATURES=no* handling there
> >   portage.dbapi.vartree: Move INSTALL_MASK handling into merging
> >   portage.dbapi.vartree: Support exclusions in INSTALL_MASK
> > 
> >  bin/misc-functions.sh|  30 --
> >  pym/portage/dbapi/vartree.py | 104 
> > ++-
> >  pym/portage/package/ebuild/config.py |  11 
> >  3 files changed, 77 insertions(+), 68 deletions(-)
> > 
> 
> As mentioned in #gentoo-portage today, the rationale for including the
> INSTALL_MASKed files in CONTENTS is to that we can detect collisions
> that would have occurred had people not been using INSTALL_MASK.
> 
> Since people can use INSTALL_MASK to intentionally prevent collisions,
> in cases where COLLISION_IGNORE is not appropriate (this is common
> practice at my workplace), we'll need a new FEATURES setting to trigger
> the new behavior where INSTALL_MASKed files still trigger file collisions.

Are we going to see this in Portage soon? And PKG_INSTALL_MASK too ?

Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

[Joakim Tjernlund]

On Tue, 2018-03-20 at 05:49 +0100, Manuel Rüger wrote:
> Hi Zac,
> 
> alternatively could --exclude be extended to support sets?
> So users could --exclude @world or @profile.

Yes please, I think I have a bug in that direction already(and --exclude during 
--depclean)


> 
> Cheers,
> Manuel
> 
> On 22.03.2018 00:03, Zac Medico wrote:
> > Ignore the @world package set and its dependencies. This may be useful
> > if there is a desire to perform an action even though it might break
> > the dependencies of some installed packages (it might also remove
> > installed packages in order to solve blockers). This also alters the
> > behavior of --complete-graph options so that only deep dependencies
> > of packages given as arguments are included in the dependency graph.
> > This option may be useful as an alternative to --nodeps in cases where
> > it is desirable to account for dependencies of packages given as
> > arguments.
> > 
> > Bug: https://bugs.gentoo.org/608564
> > ---
> >  man/emerge.1  | 17 +
> >  pym/_emerge/create_depgraph_params.py |  4 
> >  pym/_emerge/depgraph.py   |  8 ++--
> >  pym/_emerge/main.py   |  9 +
> >  pym/portage/tests/resolver/test_complete_graph.py | 18 ++
> >  5 files changed, 54 insertions(+), 2 deletions(-)
> > 
> > diff --git a/man/emerge.1 b/man/emerge.1
> > index a17b65ed2..01ce62e51 100644
> > --- a/man/emerge.1
> > +++ b/man/emerge.1
> > @@ -630,6 +630,23 @@ Therefore, \fB\-\-usepkgonly\fR (or 
> > \fB\-\-getbinpkgonly\fR) must be
> >  used in order to enable soname depedency resolution when installing
> >  packages.
> >  .TP
> > +.BR "\-\-ignore\-world [ y | n ]"
> > +Ignore the @world package set and its dependencies. This may be useful
> > +if there is a desire to perform an action even though it might break
> > +the dependencies of some installed packages (it might also remove
> > +installed packages in order to solve blockers). This also alters the
> > +behavior of \fB\-\-complete\-graph\fR options so that only deep
> > +dependencies of packages given as arguments are included in the
> > +dependency graph. This option may be useful as an alternative to
> > +\fB\-\-nodeps\fR in cases where it is desirable to account for
> > +dependencies of packages given as arguments.
> > +
> > +\fBWARNING:\fR
> > +This option is intended to be used only with great caution, since it is
> > +possible for it to make nonsensical changes which may lead to system
> > +breakage. Therefore, it is advisable to use \fB\-\-ask\fR together with
> > +this option.
> > +.TP
> >  .BR \-j\ [JOBS] ", "  \-\-jobs[=JOBS]
> >  Specifies the number of packages to build simultaneously. If this option is
> >  given without an argument, emerge will not limit the number of jobs that 
> > can
> > diff --git a/pym/_emerge/create_depgraph_params.py 
> > b/pym/_emerge/create_depgraph_params.py
> > index fc7fa60d7..0405011fd 100644
> > --- a/pym/_emerge/create_depgraph_params.py
> > +++ b/pym/_emerge/create_depgraph_params.py
> > @@ -26,6 +26,7 @@ def create_depgraph_params(myopts, myaction):
> >   # ignore_soname_deps: ignore the soname dependencies of built
> >   #   packages, so that they do not trigger dependency resolution
> >   #   failures, or cause packages to be rebuilt or replaced.
> > + # ignore_world: ignore the @world package set and its dependencies
> >   # with_test_deps: pull in test deps for packages matched by arguments
> >   # changed_deps: rebuild installed packages with outdated deps
> >   # changed_deps_report: report installed packages with outdated deps
> > @@ -56,6 +57,9 @@ def create_depgraph_params(myopts, myaction):
> >   myparams["selective"] = True
> >   return myparams
> >  
> > + if myopts.get('--ignore-world') is True:
> > + myparams['ignore_world'] = True
> > +
> >   rebuild_if_new_slot = myopts.get('--rebuild-if-new-slot')
> >   if rebuild_if_new_slot is not None:
> >   myparams['rebuild_if_new_slot'] = rebuild_if_new_slot
> > diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> > index 6c728684f..f7ea27c37 100644
> > --- a/pym/_emerge/depgraph.py
> > +++ b/pym/_emerge/depgraph.py
> > @@ -163,7 +163,10 @@ class _frozen_depgraph_config(object):
> >   self.trees[myroot]["bintree"] = DummyTree(
> >   
> > DbapiProvidesIndex(trees[myroot]["bintree"].dbapi))
> >  
> > - self._required_set_names = set(["world"])
> > + if params.get("ignore_world", False):
> > + self._required_set_names = set()
> > + else:
> > + self._required_set_names = set(["world"])
> >  
> >   atoms = ' '.join(myopts.get("--exclude", [])).split()
> >   self.excluded_pkgs = _wildcard_set(atoms)
> > @@ -7554,6 

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Sun, 2018-03-18 at 10:03 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> W dniu czw, 15.03.2018 o godzinie 22∶10 -0700, użytkownik Zac Medico
> napisał:
> >  A binary package should
> > use the value of INSTALL_MASK that existed at build time.
> > 
> 
> Wait a minute! This doesn't make any sense. The whole point of having
> separate PKG_INSTALL_MASK and INSTALL_MASK is to be able to strip stuff
> from more complete binary packages, not to force original restrictions
> forever.

These discussions also mentions PKG_INSTALL_MASK while the actual patches
only mention INSTALL_MASK. I am getting somewhat confused, does
the patches support PKG_INSTALL_MASK too or do you only intend to support
this new exclusion syntax in INSTALL_MASK?

Jocke

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Fri, 2018-03-16 at 09:13 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> W dniu pią, 16.03.2018 o godzinie 08∶11 +, użytkownik Joakim
> Tjernlund napisał:
> > On Thu, 2018-03-15 at 20:22 +0100, Michał Górny wrote:
> > > CAUTION: This email originated from outside of the organization. Do not 
> > > click links or open attachments unless you recognize the sender and know 
> > > the content is safe.
> > > 
> > > 
> > > Hi,
> > > 
> > > Here are three of four INSTALL_MASK updates I've sent long time ago
> > > which were not really reviewed. The fourth patch added support
> > > for repo-defined install-mask.conf and I'll do that separately.
> > > 
> > > Those patches focus on smaller changes. What they change, in order:
> > > 
> > > 1. Removes explicit file removal code for FEATURES=no*. Instead, those
> > >values are converted into additional INSTALL_MASK entries
> > >and handled directly via INSTALL_MASK processing.
> > > 
> > > 2. Rework INSTALL_MASK to filter files while installing instead of
> > >pre-stripping them. In other words, before: INSTALL_MASK removes
> > >files from ${D} before merge. After: ${D} contains all the files,
> > >Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.
> > 
> > Will this also remove corresponding split debug files?
> > There would be little/no point in keeping debug syms if the binary has been
> > MASKed
> > 
> 
> Nope. Add both paths to INSTALL_MASK. Expecting it to do implicit magic
> is a very bad idea.

Maybe but it also makes senses to get rid of them. To me it is only a matter
of applying PKG_INSTALL_MASK before applying strip debug, does that make sense ?

 Jocke

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Thu, 2018-03-15 at 22:10 -0700, Zac Medico wrote:
> On 03/15/2018 12:22 PM, Michał Górny wrote:
> > Hi,
> > 
> > Here are three of four INSTALL_MASK updates I've sent long time ago
> > which were not really reviewed. The fourth patch added support
> > for repo-defined install-mask.conf and I'll do that separately.
> > 
> > Those patches focus on smaller changes. What they change, in order:
> > 
> > 1. Removes explicit file removal code for FEATURES=no*. Instead, those
> >values are converted into additional INSTALL_MASK entries
> >and handled directly via INSTALL_MASK processing.
> > 
> > 2. Rework INSTALL_MASK to filter files while installing instead of
> >pre-stripping them. In other words, before: INSTALL_MASK removes
> >files from ${D} before merge. After: ${D} contains all the files,
> >Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.
> > 
> > 3. Adds support for exclusions in INSTALL_MASK. In other words, you
> >can do stuff like:
> > 
> >  INSTALL_MASK="/usr/share/locale -/usr/share/locale/en_US"
> > 
> > I have been using this via user patches since the last submission.
> > Guessing by 'git log', this means almost 2 years now.
> > 
> > --
> > Best regards,
> > Michał Górny
> > 
> > Michał Górny (3):
> >   portage.package.ebuild.config: Move FEATURES=no* handling there
> >   portage.dbapi.vartree: Move INSTALL_MASK handling into merging
> >   portage.dbapi.vartree: Support exclusions in INSTALL_MASK
> > 
> >  bin/misc-functions.sh|  30 --
> >  pym/portage/dbapi/vartree.py | 104 
> > ++-
> >  pym/portage/package/ebuild/config.py |  11 
> >  3 files changed, 77 insertions(+), 68 deletions(-)
> 
> I like this patch set but here are some important things that I want it
> to do differently:
> 
> 1) For the unmerge code, it needs to read the appropriate
> /var/db/pkg/*/*/{PKG,}INSTALL_MASK file in order to account for the
> {PKG,}INSTALL_MASK settings that existed when the package was built
> (PKG_INSTALL_MASK) and merged (INSTALL_MASK). A binary package should
> use the value of INSTALL_MASK that existed at build time.

Why does unmerge code need to know PKG_INSTALL_MASK? The files are not
installed so nothing to filter ?
similarly for merge of binary pkgs I guess, PKG_INSTALL_MASKed files are not
in the binary packed so no need to something special in this case ?

> 
> 2) In order to support bashrc {PKG,}INSTALL_MASK settings, we need to
> write the values from the environment to
> ${PORTAGE_BUILDDIR}/build-info/{PKG,}INSTALL_MASK and read them from
> there (we do this for many other variables including QA_PREBUILT).

Re: [gentoo-portage-dev] [PATCH 0/3] INSTALL_MASK refurbishing resubmit

[Joakim Tjernlund]

On Thu, 2018-03-15 at 20:22 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Hi,
> 
> Here are three of four INSTALL_MASK updates I've sent long time ago
> which were not really reviewed. The fourth patch added support
> for repo-defined install-mask.conf and I'll do that separately.
> 
> Those patches focus on smaller changes. What they change, in order:
> 
> 1. Removes explicit file removal code for FEATURES=no*. Instead, those
>values are converted into additional INSTALL_MASK entries
>and handled directly via INSTALL_MASK processing.
> 
> 2. Rework INSTALL_MASK to filter files while installing instead of
>pre-stripping them. In other words, before: INSTALL_MASK removes
>files from ${D} before merge. After: ${D} contains all the files,
>Portage just skip INSTALL_MASK-ed stuff, verbosely indicating that.

Will this also remove corresponding split debug files?
There would be little/no point in keeping debug syms if the binary has been
MASKed 

 Jocke

Re: [gentoo-portage-dev] [PATCH 3/3] portage.dbapi.vartree: Support exclusions in INSTALL_MASK

[Joakim Tjernlund]

On Fri, 2018-03-16 at 08:50 +0100, Michał Górny wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> W dniu czw, 15.03.2018 o godzinie 21∶44 +, użytkownik Joakim
> Tjernlund napisał:
> > On Thu, 2018-03-15 at 17:02 -0400, Alec Warner wrote:
> > > 
> > > 
> > > On Thu, Mar 15, 2018 at 3:22 PM, Michał Górny <mgo...@gentoo.org> wrote:
> > > > Allow INSTALL_MASK patterns to start with '-' to indicate that
> > > > a specific match is to be excluded from being masked. In this case,
> > > > the last matching pattern determines whether the file is actually
> > > > filtered out or kept.
> > > > ---
> > 
> > Yes, please ! I just needed this feature 2 hours ago.
> > I need the same for PKG_INSTALL_MASK
> > 
> > I hope this allows me to do:
> > INSTALL_MASK="/usr/share/i18n/locales/* -/usr/share/i18n/locales/en_GB 
> > -/usr/share/i18n/locales/sv_SE"
> > to all in /usr/share/i18n/locales/* but /usr/share/i18n/locales/en_GB and 
> > /usr/share/i18n/locales/sv_SE
> > removed in usr/share/i18n/locales/ ?
> > 
> 
> Yes, that is the intended use case.

Thanks, while on the subject I had a similar idea for stripping:

Today one have to build all files in glibc with debug syms just to get debug 
syms for
perf/valgrind in ld.so so it would be great if one could specify that just some 
files
should have debug syms.

 Jocke

Re: [gentoo-portage-dev] [PATCH 3/3] portage.dbapi.vartree: Support exclusions in INSTALL_MASK

[Joakim Tjernlund]

On Thu, 2018-03-15 at 17:02 -0400, Alec Warner wrote:
> 
> 
> On Thu, Mar 15, 2018 at 3:22 PM, Michał Górny  wrote:
> > Allow INSTALL_MASK patterns to start with '-' to indicate that
> > a specific match is to be excluded from being masked. In this case,
> > the last matching pattern determines whether the file is actually
> > filtered out or kept.
> > ---

Yes, please ! I just needed this feature 2 hours ago.
I need the same for PKG_INSTALL_MASK 

I hope this allows me to do:
INSTALL_MASK="/usr/share/i18n/locales/* -/usr/share/i18n/locales/en_GB 
-/usr/share/i18n/locales/sv_SE"
to all in /usr/share/i18n/locales/* but /usr/share/i18n/locales/en_GB and 
/usr/share/i18n/locales/sv_SE
removed in usr/share/i18n/locales/ ?

 Jocke

[gentoo-portage-dev] keepdir function missing when using qmerge to install binary packages

[Joakim Tjernlund]

I got an error msg similar to
  keepdir: function missing
using qmerge to install.

So this function seem missing and I wonder if that one
should be defined/impl. inside the binary packet or if qmerge
should provide it?

Where can I find a list(and definitions) of functions etc. that the
package manager should provide?

 Jocke

[gentoo-portage-dev] portage perfoemance again ...

[Joakim Tjernlund]

.. using portage 2.3.24 on our embedded target(ppc329 It takes forever, > 10 
mins) to just do the
dependencies for emerge -aNDuv world
Here is what strace says, one can see portage is rereading the profile over and 
over again.
At this point I am prepared to try anything to eliminate the rereading of the 
profile, any pointers?
 
23:04:25.472818 _llseek(5, 0, [0], SEEK_CUR) = 0
23:04:25.472978 read(5, "# Copyright 1999-2015 Gentoo Fou"..., 32768) = 677
23:04:25.473099 read(5, "", 28672)  = 0
23:04:25.473228 read(5, "", 32768)  = 0
23:04:25.473366 close(5)= 0
23:04:25.482102 stat64("/usr/portage/profiles/base/profile.bashrc", 
{st_mode=S_IFREG|0644, st_size=183, ...}) = 0
23:04:25.482509 stat64("/usr/portage/profiles/default/linux/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.482887 stat64("/usr/portage/profiles/arch/base/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.483240 stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.483594 
stat64("/usr/portage/profiles/default/linux/powerpc/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.483924 stat64("/usr/portage/profiles/arch/base/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.484269 stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.484604 
stat64("/usr/portage/profiles/arch/powerpc/ppc32/profile.bashrc", 0xbfe61330) = 
-1 ENOENT (No such file or directory)
23:04:25.484930 
stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.485272 stat64("/usr/portage/profiles/releases/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.485615 stat64("/usr/portage/profiles/releases/13.0/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.485944 
stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/13.0/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.486329 
stat64("/usr/local/portage/tmv3-target-overlay/profiles/cusfpv3/profile.bashrc",
 {st_mode=S_IFREG|0644, st_size=133, ...}) = 0
23:04:25.486764 stat64("/etc/portage/profile/profile.bashrc", 0xbfe61330) = -1 
ENOENT (No such file or directory)
23:04:25.499748 
access("/usr/portage/virtual/perl-Text-ParseWords/perl-Text-ParseWords-3.290.0-r1.ebuild",
 R_OK) = 0
23:04:25.500088 
stat64("/usr/portage/virtual/perl-Text-ParseWords/perl-Text-ParseWords-3.290.0-r1.ebuild",
 {st_mode=S_IFREG|0644, st_size=664, ...}) = 0
23:04:25.500417 
open("/usr/portage/metadata/md5-cache/virtual/perl-Text-ParseWords-3.290.0-r1", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
23:04:25.500545 fstat64(5, {st_mode=S_IFREG|0644, st_size=593, ...}) = 0
23:04:25.500664 ioctl(5, TCGETS, 0xbfe61f98) = -1 ENOTTY (Inappropriate ioctl 
for device)
23:04:25.500761 fstat64(5, {st_mode=S_IFREG|0644, st_size=593, ...}) = 0
23:04:25.500897 _llseek(5, 0, [0], SEEK_CUR) = 0
23:04:25.501101 _llseek(5, 0, [0], SEEK_CUR) = 0
23:04:25.501238 _llseek(5, 0, [0], SEEK_CUR) = 0
23:04:25.501343 fstat64(5, {st_mode=S_IFREG|0644, st_size=593, ...}) = 0
23:04:25.501446 read(5, "DEFINED_PHASES=-\nDESCRIPTION=Vir"..., 594) = 593
23:04:25.501552 read(5, "", 1)  = 0
23:04:25.501831 fstat64(5, {st_mode=S_IFREG|0644, st_size=593, ...}) = 0
23:04:25.502013 close(5)= 0
23:04:25.502474 
open("/usr/portage/virtual/perl-Text-ParseWords/perl-Text-ParseWords-3.290.0-r1.ebuild",
 O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
23:04:25.502607 fstat64(5, {st_mode=S_IFREG|0644, st_size=664, ...}) = 0
23:04:25.502739 ioctl(5, TCGETS, 0xbfe61b88) = -1 ENOTTY (Inappropriate ioctl 
for device)
23:04:25.502838 fstat64(5, {st_mode=S_IFREG|0644, st_size=664, ...}) = 0
23:04:25.502961 _llseek(5, 0, [0], SEEK_CUR) = 0
23:04:25.503114 read(5, "# Copyright 1999-2015 Gentoo Fou"..., 32768) = 664
23:04:25.503244 read(5, "", 28672)  = 0
23:04:25.503374 read(5, "", 32768)  = 0
23:04:25.503519 close(5)= 0
23:04:25.512617 stat64("/usr/portage/profiles/base/profile.bashrc", 
{st_mode=S_IFREG|0644, st_size=183, ...}) = 0
23:04:25.513003 stat64("/usr/portage/profiles/default/linux/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.513379 stat64("/usr/portage/profiles/arch/base/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.513736 stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.514142 
stat64("/usr/portage/profiles/default/linux/powerpc/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.514494 stat64("/usr/portage/profiles/arch/base/profile.bashrc", 
0xbfe61330) = -1 ENOENT (No such file or directory)
23:04:25.514831 

Re: [gentoo-portage-dev] emerging binary pkgs very slow on ppc32

[Joakim Tjernlund]

On Wed, 2018-02-14 at 11:53 -0800, Zac Medico wrote:
On 02/14/2018 07:49 AM, Joakim Tjernlund wrote:
> We got an embedded target which we upded with binary pks(157 in this case) 
> using:
>  PKGDIR=/opt/fs/osappl04a-r30b-1/usr/portage/packages emerge 
> --rebuilt-binaries --verbose --usepkgonly -NDu @world @cusfpv3
> and this takes forever, about 1 hour
>
> not sure where to start looking for a cause, is this known for ppc32 ?

No, I haven't seen any reports like this.

Tested on my x86_64 DE and I find binary pkg install slow there too. The load 
stays between 1-2 there as well.
There is something odd going on I think.


> I got btrfs root FS on 4 core, 1.3 GHz CPU on eMMC media. The rw performance 
> is decent I think.
> load avg. about 1.1 so no CPU is not limiting.
> sys-apps/portage:
>  Installed versions:  2.3.19-r1(17:41:24 24/01/18)(ipc native-extensions 
> xattr -build -doc -epydoc -selinux LINGUAS="-ru" PYTHON_TARGETS="python2_7 
> python3_4 -pypy -python3_5 -python3_6")
>
> Is there some I can speed up binary pkg emerge?
> when stracing I see way too many system calls
> but this one stands out, 1 byte reads:
>
> 17750 16:39:40 brk(0x100d7000)  = 0x100d7000
> 17750 16:39:40 brk(0x100d6000)  = 0x100d6000
> 17750 16:39:40 read(0, "d", 1)  = 1
> 17750 16:39:40 read(0, "e", 1)  = 1
> 17750 16:39:40 read(0, "c", 1)  = 1
> 17750 16:39:40 read(0, "l", 1)  = 1
> 17750 16:39:40 read(0, "a", 1)  = 1
> 17750 16:39:40 read(0, "r", 1)  = 1
> 17750 16:39:40 read(0, "e", 1)  = 1
> 17750 16:39:40 read(0, " ", 1)  = 1
> 17750 16:39:40 read(0, "-", 1)  = 1
> 17750 16:39:40 read(0, "x", 1)  = 1
> 17750 16:39:40 read(0, " ", 1)  = 1
> 17750 16:39:40 read(0, "A", 1)  = 1
> 17750 16:39:40 read(0, "=", 1)  = 1
> 17750 16:39:40 read(0, "\"", 1) = 1
> 
> 17750 16:39:43 read(0, "t", 1)  = 1
> 17750 16:39:43 read(0, "\n", 1) = 1
> 17750 16:39:43 read(0, "}", 1)  = 1
> 17750 16:39:43 read(0, "\n", 1) = 1
> 17750 16:39:43 read(0, "", 1)   = 0
> 17750 16:39:43 write(1, "function _eapply_patch () \n "..., 4345) = 4345


I see what's causing those 1 byte reads, I've filed this bug:

https://bugs.gentoo.org/647654


Nice, one down!

[gentoo-portage-dev] emerging binary pkgs very slow on ppc32

[Joakim Tjernlund]

We got an embedded target which we upded with binary pks(157 in this case) 
using:
 PKGDIR=/opt/fs/osappl04a-r30b-1/usr/portage/packages emerge --rebuilt-binaries 
--verbose --usepkgonly -NDu @world @cusfpv3
and this takes forever, about 1 hour

not sure where to start looking for a cause, is this known for ppc32 ?

I got btrfs root FS on 4 core, 1.3 GHz CPU on eMMC media. The rw performance is 
decent I think.
load avg. about 1.1 so no CPU is not limiting.
sys-apps/portage:
 Installed versions:  2.3.19-r1(17:41:24 24/01/18)(ipc native-extensions 
xattr -build -doc -epydoc -selinux LINGUAS="-ru" PYTHON_TARGETS="python2_7 
python3_4 -pypy -python3_5 -python3_6")

Is there some I can speed up binary pkg emerge?
when stracing I see way too many system calls 
but this one stands out, 1 byte reads:

17750 16:39:40 brk(0x100d7000)  = 0x100d7000
17750 16:39:40 brk(0x100d6000)  = 0x100d6000
17750 16:39:40 read(0, "d", 1)  = 1
17750 16:39:40 read(0, "e", 1)  = 1
17750 16:39:40 read(0, "c", 1)  = 1
17750 16:39:40 read(0, "l", 1)  = 1
17750 16:39:40 read(0, "a", 1)  = 1
17750 16:39:40 read(0, "r", 1)  = 1
17750 16:39:40 read(0, "e", 1)  = 1
17750 16:39:40 read(0, " ", 1)  = 1
17750 16:39:40 read(0, "-", 1)  = 1
17750 16:39:40 read(0, "x", 1)  = 1
17750 16:39:40 read(0, " ", 1)  = 1
17750 16:39:40 read(0, "A", 1)  = 1
17750 16:39:40 read(0, "=", 1)  = 1
17750 16:39:40 read(0, "\"", 1) = 1

17750 16:39:43 read(0, "t", 1)  = 1
17750 16:39:43 read(0, "\n", 1) = 1
17750 16:39:43 read(0, "}", 1)  = 1
17750 16:39:43 read(0, "\n", 1) = 1
17750 16:39:43 read(0, "", 1)   = 0
17750 16:39:43 write(1, "function _eapply_patch () \n "..., 4345) = 4345

 Jocke 

[gentoo-portage-dev] repos.conf: suppport for syncing from branch/tag

[Joakim Tjernlund]

Hi Portage guys

Looking at repos.conf I do not see a way to pull from a particular 
branch (or tag). Maybe I am missing something or it could be added?

 Jocke

Re: [gentoo-portage-dev] [PATCH] grabfile_package: support -* in profile "packages" files (bug 610670)

[Joakim Tjernlund]

On Thu, 2017-02-23 at 07:52 -0800, Brian Dolbec wrote:
> On Thu, 23 Feb 2017 11:53:15 +
> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> 
> > On Thu, 2017-02-23 at 02:52 -0800, Zac Medico wrote:
> > > Support -* in order to make it easier to create profiles for
> > > minimal systems (especially those built entirely from binary
> > > packages).  
> > 
> > Would be nice, but I don't get what the "packages" file is?
> 
> 
> That would be the 'packages' file (list of required packages)that are
> required for that specific profile.   This patch would allow to
> override that packages file  to build an image that only contained the
> minimum runtime pkgs required to perform the tasks it is suppose to.
> The idea being you would not need gcc, automake, ... or even portage or
> possibly python.  The built image could of course be considered more
> secure not having a compiler, etc... not to mention smaller.

Many of the packages files in /usr/portage/profiles already contain -* so
I guess this must be another packages file?
in /etc/portage or possibly /usr/portage/packges/ ?

  Jocke

Re: [gentoo-portage-dev] [PATCH] grabfile_package: support -* in profile "packages" files (bug 610670)

[Joakim Tjernlund]

On Thu, 2017-02-23 at 02:52 -0800, Zac Medico wrote:
> Support -* in order to make it easier to create profiles for
> minimal systems (especially those built entirely from binary
> packages).

Would be nice, but I don't get what the "packages" file is?

> 
> X-Gentoo-Bug: 610670
> X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=610670
> ---
>  pym/portage/util/__init__.py | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/pym/portage/util/__init__.py b/pym/portage/util/__init__.py
> index c2c871f..45710ba 100644
> --- a/pym/portage/util/__init__.py
> +++ b/pym/portage/util/__init__.py
> @@ -478,13 +478,20 @@ def grabfile_package(myfilename, compatlevel=0, 
> recursive=0,
>   eapi = read_corresponding_eapi_file(
>   myfilename, default=eapi_default)
>   mybasename = os.path.basename(myfilename)
> + is_packages_file = mybasename == 'packages'
>   atoms = []
>   for pkg, source_file in pkgs:
>   pkg_orig = pkg
>   # for packages and package.mask files
>   if pkg[:1] == "-":
> + if is_packages_file and pkg == '-*':
> + if remember_source_file:
> + atoms.append((pkg, source_file))
> + else:
> + atoms.append(pkg)
> + continue
>   pkg = pkg[1:]
> - if pkg[:1] == '*' and mybasename == 'packages':
> + if pkg[:1] == '*' and is_packages_file:
>   pkg = pkg[1:]
>   try:
>   pkg = Atom(pkg, allow_wildcard=allow_wildcard,

Re: [gentoo-dev] [PATCH] toolchain.eclass: set CHOST for gcc-config calls

[Joakim Tjernlund]

On Tue, 2016-12-27 at 00:22 -0800, Daniel Campbell wrote:
> On 12/26/2016 12:22 PM, Mike Gilbert wrote:
> > Bug: https://bugs.gentoo.org/603776
> > ---
> >  eclass/toolchain.eclass | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> > index 55249b00249b..97511ee12440 100644
> > --- a/eclass/toolchain.eclass
> > +++ b/eclass/toolchain.eclass
> > @@ -2119,13 +2119,13 @@
> >  
> >  do_gcc_config() {
> >     if ! should_we_gcc_config ; then
> > -   env -i ROOT="${ROOT}" gcc-config --use-old --force
> > +   env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config --use-old 
> > --force
> >     return 0
> >     fi
> >  
> >     local current_gcc_config target
> >  
> > -   current_gcc_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 
> > 2>/dev/null)
> > +   current_gcc_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config 
> > -c ${CTARGET} 2>/dev/null)
> >     if [[ -n ${current_gcc_config} ]] ; then
> >     local current_specs use_specs
> >     # figure out which specs-specific config is active
> > @@ -2159,12 +2159,12 @@ should_we_gcc_config() {
> >     # if the current config is invalid, we definitely want a new one
> >     # Note: due to bash quirkiness, the following must not be 1 line
> >     local curr_config
> > -   curr_config=$(env -i ROOT="${ROOT}" gcc-config -c ${CTARGET} 2>&1) || 
> > return 0
> > +   curr_config=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" gcc-config -c 
> > ${CTARGET} 2>&1) || return 0
> >  
> >     # if the previously selected config has the same major.minor (branch) as
> >     # the version we are installing, then it will probably be uninstalled
> >     # for being in the same SLOT, make sure we run gcc-config.
> > -   local curr_config_ver=$(env -i ROOT="${ROOT}" gcc-config -S 
> > ${curr_config} | awk '{print $2}')
> > +   local curr_config_ver=$(env -i CHOST="${CHOST}" ROOT="${ROOT}" 
> > gcc-config -S ${curr_config} | awk
> > '{print $2}')
> >  
> >     local curr_branch_ver=$(get_version_component_range 1-2 
> > ${curr_config_ver})
> >  
> > 
> 
> Seems like an obvious bug and fix; is there any reason passing CHOST
> around might be a bad idea? It seems to me that it enforces the behavior
> it's meant to have to begin with and makes it more obvious that CHOST is
> used.

Will that work for cross toolchains well?

   Jocke

Re: [gentoo-dev] grub-2 configuration

[Joakim Tjernlund]

On Thu, 2016-10-20 at 11:03 -0400, Tom H wrote:
> On Wed, Oct 19, 2016 at 4:43 PM, Joakim Tjernlund
> <joakim.tjernl...@infinera.com> wrote:
> > 
> > On Wed, 2016-10-19 at 15:21 -0400, Tom H wrote:
> > > 
> > > 
> > > but it looks like, unlike for grub-legacy, you need a grub config file
> > > ("/boot/grub{,2}/grub.cfg") to exist.
> > 
> > That is reasonable, to create a new entry one needs to copy the previous 
> > and replace the
> > kernel.
> > 
> > Would be nice if someone could confirm this though.
> 
> if [[ -z "${GRUB_CONF}" ]]; then
> print_error 1 "Error! Grub2 configuration file does not exist, please
> ensure grub2 is correctly setup first."
> return 0
> fi


Tried to make grub2 and EFI work on a HP Skylake laptop but failed. This laptop 
PXE boots linux
during install in BIOS mode so no EFI vars etc. available when installing grub2.
Is this an impossible combo? Do I need to EFI boot in order to install grub2 
efi?

 Jocke

Re: [gentoo-dev] LLVM News item

[Joakim Tjernlund]

On Tue, 2016-10-25 at 16:07 -0400, Ian Stakenvicius wrote:
> On 25/10/16 04:02 PM, Joakim Tjernlund wrote:
> > 
> > On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
> > > 
> > > On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
> > > > 
> > > > 
> > > > On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
> > > > > > 
> > > > > > 
> > > > > > On Tue, 25 Oct 2016 17:32:22 +
> > > > > > Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item 
> > > > > > > and read:
> > > > > > > ..
> > > > > > > In order to enable all targets, add the following to your
> > > > > > > /etc/portage/package.use or equivalent file:
> > > > > > > 
> > > > > > >   sys-devel/llvm LLVM_TARGETS: *
> > > > > > >   sys-devel/clang LLVM_TARGETS: *
> > > > > > > ...
> > > > > > > 
> > > > > > > I would like to control such variables(LLVM_TARGETS) through the 
> > > > > > > profile as
> > > > > > > well but it seems not supported?
> > > > > > 
> > > > > > Why not? We're already setting the defaults in profiles, and you 
> > > > > > can do
> > > > > > whatever you want in your own profile. The news item is focused on
> > > > > > regular users, so it covers the usual configuration files rather 
> > > > > > than
> > > > > > creating custom profiles.
> > > > > > 
> > > > > 
> > > > > How? in my profile(which inherits 
> > > > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add:
> > > > > # > svn diff
> > > > > Index: package.use
> > > > > ===
> > > > > --- package.use   (revision 1087)
> > > > > +++ package.use   (working copy)
> > > > > @@ -1,3 +1,6 @@
> > > > > +sys-devel/llvm LLVM_TARGETS: *
> > > > > +sys-devel/clang LLVM_TARGETS: *
> > > > > 
> > > > > Then I get:
> > > > > # > emerge -aNDuv world
> > > > > --- Invalid USE flag for 'sys-devel/llvm' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > 'LLVM_TARGETS:'
> > > > > --- Invalid USE flag for 'sys-devel/llvm' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > '*'
> > > > > --- Invalid USE flag for 'sys-devel/clang' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > 'LLVM_TARGETS:'
> > > > > --- Invalid USE flag for 'sys-devel/clang' in
> > > > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > > > '*'
> > > > > 
> > > > 
> > > > Syntax error:
> > > > 
> > > > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> > > > sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
> > 
> > This is standard USE flags, not the VAR: x y z syntax
> > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > You can't specify wildcards to enable groups of use flags.
> > > > 
> > > > 
> > > 
> > > Correction, the earlier syntax *is* supposed to work (and tested that
> > > it works here, with VIDEO_CARDS)..  If I had to guess this probably
> > > relates to an issue with the transmode overlay.
> > > 
> > 
> > Hmm, are you saying that you can write:
> >   x11-base/xorg-drivers VIDEO_CARDS: intel radeon
> > in your profile?
> > 
> > Any idea what my issue might be?
> > 
> >  Jocke
> > 
> 
> In my profile as in /etc/portage/package.use/  , yes. Specifically I
> tested VIDEO_CARDS: *

I thought it was obvious that I was referring to a custom profile
as in eselect profile ..

> 
> I *didn't* try to mess with my in-repo profile though.  Given that
> repositories may well need to follow PMS, and the USE_EXPAND: * syntax
> is a portage'ism, this is why they are being rejected in the
> transmode-overlay case.  I certainly can't find an example of this
> syntax in the gentoo repo.

Portage supports lots more than PMS as is, should we remove that?
Just because something is supported in portage, you don't have to use it
in official repos. Our overlay is used to maintain all the linux computers
we have here and /etc/portage is the individual using a particular computer.

It would be nice if portage, in general, supported the same features/syntax as
/etc/portage does.

  Jocke

Re: [gentoo-dev] LLVM News item

[Joakim Tjernlund]

On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
> On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
> > 
> > On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
> > > 
> > > On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
> > > > 
> > > > On Tue, 25 Oct 2016 17:32:22 +
> > > > Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and 
> > > > > read:
> > > > > ..
> > > > > In order to enable all targets, add the following to your
> > > > > /etc/portage/package.use or equivalent file:
> > > > > 
> > > > >   sys-devel/llvm LLVM_TARGETS: *
> > > > >   sys-devel/clang LLVM_TARGETS: *
> > > > > ...
> > > > > 
> > > > > I would like to control such variables(LLVM_TARGETS) through the 
> > > > > profile as
> > > > > well but it seems not supported?
> > > > 
> > > > Why not? We're already setting the defaults in profiles, and you can do
> > > > whatever you want in your own profile. The news item is focused on
> > > > regular users, so it covers the usual configuration files rather than
> > > > creating custom profiles.
> > > > 
> > > 
> > > How? in my profile(which inherits 
> > > gentoo:default/linux/amd64/13.0/desktop) I just tested to add:
> > > # > svn diff
> > > Index: package.use
> > > ===
> > > --- package.use   (revision 1087)
> > > +++ package.use   (working copy)
> > > @@ -1,3 +1,6 @@
> > > +sys-devel/llvm LLVM_TARGETS: *
> > > +sys-devel/clang LLVM_TARGETS: *
> > > 
> > > Then I get:
> > > # > emerge -aNDuv world
> > > --- Invalid USE flag for 'sys-devel/llvm' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > 'LLVM_TARGETS:'
> > > --- Invalid USE flag for 'sys-devel/llvm' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > '*'
> > > --- Invalid USE flag for 'sys-devel/clang' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > 'LLVM_TARGETS:'
> > > --- Invalid USE flag for 'sys-devel/clang' in 
> > > '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> > > '*'
> > > 
> > 
> > Syntax error:
> > 
> > sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> > sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..

This is standard USE flags, not the VAR: x y z syntax

> > 
> > 
> > You can't specify wildcards to enable groups of use flags.
> > 
> > 
> 
> Correction, the earlier syntax *is* supposed to work (and tested that
> it works here, with VIDEO_CARDS)..  If I had to guess this probably
> relates to an issue with the transmode overlay.
> 

Hmm, are you saying that you can write:
  x11-base/xorg-drivers VIDEO_CARDS: intel radeon
in your profile?

Any idea what my issue might be?

 Jocke

Re: [gentoo-dev] LLVM News item

[Joakim Tjernlund]

On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
> On Tue, 25 Oct 2016 17:32:22 +
> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> 
> > 
> > Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
> > ..
> > In order to enable all targets, add the following to your
> > /etc/portage/package.use or equivalent file:
> > 
> >   sys-devel/llvm LLVM_TARGETS: *
> >   sys-devel/clang LLVM_TARGETS: *
> > ...
> > 
> > I would like to control such variables(LLVM_TARGETS) through the profile as
> > well but it seems not supported?
> 
> Why not? We're already setting the defaults in profiles, and you can do
> whatever you want in your own profile. The news item is focused on
> regular users, so it covers the usual configuration files rather than
> creating custom profiles.
> 

How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I 
just tested to add:
# > svn diff
Index: package.use
===
--- package.use (revision 1087)
+++ package.use (working copy)
@@ -1,3 +1,6 @@
+sys-devel/llvm LLVM_TARGETS: *
+sys-devel/clang LLVM_TARGETS: *

Then I get:
# > emerge -aNDuv world
--- Invalid USE flag for 'sys-devel/llvm' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use':
'LLVM_TARGETS:'
--- Invalid USE flag for 'sys-devel/llvm' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
--- Invalid USE flag for 'sys-devel/clang' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use':
'LLVM_TARGETS:'
--- Invalid USE flag for 'sys-devel/clang' in 
'/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'

[gentoo-dev] LLVM News item

[Joakim Tjernlund]

Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
..
In order to enable all targets, add the following to your
/etc/portage/package.use or equivalent file:

  sys-devel/llvm LLVM_TARGETS: *
  sys-devel/clang LLVM_TARGETS: *
...

I would like to control such variables(LLVM_TARGETS) through the profile as
well but it seems not supported?

 Jocke

Re: [gentoo-dev] grub-2 configuration

[Joakim Tjernlund]

On Wed, 2016-10-19 at 15:21 -0400, Tom H wrote:
> On Tue, Oct 18, 2016 at 1:20 PM, Joakim Tjernlund
> <joakim.tjernl...@infinera.com> wrote:
> > 
> > On Tue, 2016-10-18 at 12:45 -0400, Tom H wrote:
> > > 
> > > On Tue, Oct 11, 2016 at 10:54 AM, M. J. Everitt <m.j.ever...@iee.org> 
> > > wrote:
> > > > 
> > > > On 11/10/16 15:42, Tom H wrote:
> > > > > 
> > > > > 
> > > > > You can use exactly the same text in 40_grub that you'd use in
> > > > > grub.cfg and have the latter generated.
> > > > 
> > > > That's a useful tit-bit .. thanks!
> > > 
> > > You're welcome.
> > > 
> > > I doubt that the grub developers intended 40_custom to be the only
> > > "/etc/grub.d/" file to be executed but it's practical for generating a
> > > simple grub.cfg. This is what I use in a Debian VM:
> > 
> > We still use grub-1 and I really like the automatic generation of new
> > grub menu entries using genkernel --bootloader=grub, does this work
> > with grub2 as well?
> 
> It looks ike you can pass "--bootloader=grub2" but it's not documented
> in the man page because gen_bootloader.sh has:

OK, good.

> 
> set_bootloader() {
> case "${BOOTLOADER}" in
> grub)
> set_bootloader_grub
> ;;
> grub2)
> set_bootloader_grub2
> ;;
> *)
> print_warning "Bootloader ${BOOTLOADER} is not currently supported"
> ;;
> esac
> }
> 
> but it looks like, unlike for grub-legacy, you need a grub config file
> ("/boot/grub{,2}/grub.cfg") to exist.

That is reasonable, to create a new entry one needs to copy the previous and 
replace the
kernel.

Would be nice if someone could confirm this though.

    Jocke

Re: [gentoo-dev] grub-2 configuration

[Joakim Tjernlund]

On Tue, 2016-10-18 at 12:45 -0400, Tom H wrote:
> On Tue, Oct 11, 2016 at 10:54 AM, M. J. Everitt  wrote:
> > 
> > On 11/10/16 15:42, Tom H wrote:
> > > 
> > > 
> > > You can use exactly the same text in 40_grub that you'd use in
> > > grub.cfg and have the latter generated.
> > 
> > That's a useful tit-bit .. thanks!
> 
> You're welcome.
> 
> I doubt that the grub developers intended 40_custom to be the only
> "/etc/grub.d/" file to be executed but it's practical for generating a
> simple grub.cfg. This is what I use in a Debian VM:
> 

We still use grub-1 and I really like the automatic generation of new grub
menu entries using genkernel --bootloader=grub, does this work with grub2 as 
well?

 Jocke

Re: [gentoo-dev] Mirrors corrupts?

[Joakim Tjernlund]

On Sat, 2016-10-08 at 18:07 +0200, Jeroen Roovers wrote:
> On Sat, 8 Oct 2016 14:52:13 +
> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> 
> > 
> > Tried several mirrors and I still get:
> 
> 
> https://bugs.gentoo.org/show_bug.cgi?id=596462

Thanks, I added myself to CC list

[gentoo-dev] Mirrors corrupts?

[Joakim Tjernlund]

Tried several mirrors and I still get:

gentoo-jocke gentoo64 # emerge -avNDuv world
[ebuild U ] x11-libs/libX11-1.6.4 [1.6.3] USE="ipv6 -doc -static-libs 
{-test}" ABI_X86="32 (64) (-x32)" 
[ebuild U ] x11-libs/libXfixes-5.0.3 [5.0.2] USE="-static-libs" 
ABI_X86="(64) -32 (-x32)" 
[ebuild U ] x11-libs/libXrender-0.9.10 [0.9.9] USE="-static-libs" 
ABI_X86="32 (64) (-x32)" 
[ebuild U ] x11-libs/libXi-1.7.7 [1.7.6] USE="-doc -static-libs" 
ABI_X86="(64) -32 (-x32)" 
[ebuild U ] x11-libs/libXrandr-1.5.1 [1.5.0] USE="-static-libs" 
ABI_X86="(64) -32 (-x32)" 
[ebuild U ] x11-libs/libXv-1.0.11 [1.0.10] USE="-static-libs" ABI_X86="(64) 
-32 (-x32)" 
[ebuild U ] x11-libs/libXtst-1.2.3 [1.2.2] USE="-doc -static-libs" 
ABI_X86="(64) -32 (-x32)" 
[ebuild U ] sys-apps/man-pages-4.07 [4.06] USE="nls" L10N="-da -de -fr -it 
-ja -nl -pl -ro -ru -zh-CN" 
[ebuild U ] net-wireless/wpa_supplicant-2.6 [2.5-r2] USE="dbus gnutls hs2-0 
qt4 readline ssl -ap -eap-sim
-fasteap (-libressl) -p2p (-ps3) -qt5 (-selinux) -smartcard -tdls 
-uncommon-eap-types (-wimax) -wps" 

Would you like to merge these packages? [Yes/No] 
>>> Verifying ebuild manifests

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libX11/libX11-1.6.4.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 1619
!!! Expected: 1620

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXfixes/libXfixes-5.0.3.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 709
!!! Expected: 710

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXrender/libXrender-0.9.10.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 649
!!! Expected: 650

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXi/libXi-1.7.7.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 973
!!! Expected: 974

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXrandr/libXrandr-1.5.1.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 798
!!! Expected: 799

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXv/libXv-1.0.11.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 669
!!! Expected: 670

!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXtst/libXtst-1.2.3.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 831
!!! Expected: 832

!!! Digest verification failed:
!!! /usr/portage/net-wireless/wpa_supplicant/wpa_supplicant-2.6.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 10295
!!! Expected: 10296
>>> Emerging (1 of 9) x11-libs/libX11-1.6.4::gentoo
>>> Jobs: 0 of 9 complete, 1 runningLoad avg: 0.77, 0.36, 0.22
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libX11/libX11-1.6.4.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 1619
!!! Expected: 1620
>>> Failed to emerge x11-libs/libX11-1.6.4
>>> Jobs: 0 of 9 complete, 1 failed Load avg: 0.77, 0.36, 0.22
*** Resuming merge...
>>> Emerging (1 of 8) x11-libs/libXfixes-5.0.3::gentoo
>>> Jobs: 0 of 8 complete, 1 runningLoad avg: 0.73, 0.37, 0.22
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXfixes/libXfixes-5.0.3.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 709
!!! Expected: 710
>>> Failed to emerge x11-libs/libXfixes-5.0.3
>>> Jobs: 0 of 8 complete, 1 failed Load avg: 0.73, 0.37, 0.22
*** Resuming merge...
>>> Emerging (1 of 7) x11-libs/libXrender-0.9.10::gentoo
>>> Jobs: 0 of 7 complete, 1 runningLoad avg: 0.78, 0.39, 0.23
!!! Digest verification failed:
!!! /usr/portage/x11-libs/libXrender/libXrender-0.9.10.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 649
!!! Expected: 650
>>> Failed to emerge x11-libs/libXrender-0.9.10

Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

[Joakim Tjernlund]

On Thu, 2016-10-06 at 00:18 +0800, konsolebox wrote:
> On Wed, Oct 5, 2016 at 10:58 PM, Joakim Tjernlund
> <joakim.tjernl...@infinera.com> wrote:
> > 
> > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
> > "(null)". This
> > creates a /(null) dir. with various stuff in it.
> > 
> > I am trying to find out what sets XDG_RUNTIME_DIR?
> 
> It's pam_ck_connector.so.  Also see
> https://bugs.gentoo.org/show_bug.cgi?id=588840 for details.
> 

 Got it and consolekit-1.1.0-r1 works around the issue.

 Thanks

Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

[Joakim Tjernlund]

On Thu, 2016-10-06 at 00:04 +0800, Jason Zaman wrote:
> On Wed, Oct 05, 2016 at 03:58:44PM +0000, Joakim Tjernlund wrote:
> > 
> > On Wed, 2016-10-05 at 23:10 +0800, Jason Zaman wrote:
> > > 
> > > On Wed, Oct 05, 2016 at 02:58:20PM +, Joakim Tjernlund wrote:
> > > > 
> > > > 
> > > > I know this might be a bit off topic but I just want some clues
> > > > 
> > > > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
> > > > "(null)". This
> > > > creates a /(null) dir. with various stuff in it.
> > > > 
> > > > I am trying to find out what sets XDG_RUNTIME_DIR?
> > > its https://bugs.gentoo.org/585688
> > > fixed in sys-auth/consolekit-1.1.0-r1
> > > 
> > > I'd forgotten to update the stablereq to that, will do it now.
> > 
> > Ah, I see that now.
> > Thou after installing sys-auth/consolekit-1.1.0-r1 I get XDG_RUNTIME_DIR
> > but no the directory is not created for root, seems to be fixed by:
> > https://github.com/ConsoleKit2/ConsoleKit2/commit/664d2fdbd966764836b1f4da2dbc5750c7f01f0f
> 
> Yep, that patch is what the -r1 bump was for. Did you remember to
> restart consolekit after updating?
> 
ehh, no. It worked after a restart(but I had to manually kill the daemon first)

Re: [gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

[Joakim Tjernlund]

On Wed, 2016-10-05 at 23:10 +0800, Jason Zaman wrote:
> On Wed, Oct 05, 2016 at 02:58:20PM +0000, Joakim Tjernlund wrote:
> > 
> > I know this might be a bit off topic but I just want some clues
> > 
> > Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
> > "(null)". This
> > creates a /(null) dir. with various stuff in it.
> > 
> > I am trying to find out what sets XDG_RUNTIME_DIR?
> its https://bugs.gentoo.org/585688
> fixed in sys-auth/consolekit-1.1.0-r1
> 
> I'd forgotten to update the stablereq to that, will do it now.

Ah, I see that now.
Thou after installing sys-auth/consolekit-1.1.0-r1 I get XDG_RUNTIME_DIR
but no the directory is not created for root, seems to be fixed by:
https://github.com/ConsoleKit2/ConsoleKit2/commit/664d2fdbd966764836b1f4da2dbc5750c7f01f0f

[gentoo-dev] XDG_RUNTIME_DIR=(null) when root logs in

[Joakim Tjernlund]

I know this might be a bit off topic but I just want some clues

Whenever root logs in(ssh or on text console) XDG_RUNTIME_DIR is set to 
"(null)". This
creates a /(null) dir. with various stuff in it.

I am trying to find out what sets XDG_RUNTIME_DIR?

We auth. against Windows AD using sssd, but root is a local UNIX user only(not 
in AD)

Any clues?

  Jocke 

[gentoo-dev] Bug 548208 - net-fs/nfs-utils: enable gssproxy support (to replace rpc-svcgssd) seems forgotten?

[Joakim Tjernlund]

Could someone from core systems look at 
 https://bugs.gentoo.org/show_bug.cgi?id=548208
and "unbreak" unstable nfs-utils for openrc, please?

Jocke

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Joakim Tjernlund]

On Fri, 2016-05-27 at 18:21 -0400, NP-Hardass wrote:
> On 05/27/2016 06:05 PM, Daniel Campbell wrote:
> > On 05/27/2016 02:45 PM, NP-Hardass wrote:
> > > Not on hand, but as the MATE maintainer, I can tell you that starting
> > > with MATE-1.14, two packages are gtk3 only, and starting with 1.16, four
> > > more are.
> > > 
> 
> > 
> > Aha, thanks for offering that info. Which ones if you don't mind?
> > 
> in 1.14 x11-misc/mozo and mate-extra/mate-system-monitor.  Don't have
> the 1.16 ones handy as I haven't been able to work on it the last week
> (more hw issues)
> 

NP, there are 2 patches floating on the MATE ml that move the dependency on 
sys-power/upower-pm-utils
consolekit(suspend/resume is handled by consolekit instead). Wold you be 
interested to
add those to gentoo MATE?

  Jocke

Re: [gentoo-portage-dev] USE_EXPAND in profiles?

[Joakim Tjernlund]

On Thu, 2016-03-31 at 02:26 +1300, Kent Fredric wrote:
> On 31 March 2016 at 01:49, Joakim Tjernlund
> <joakim.tjernl...@infinera.com> wrote:
> > 
> > 
> > I am missing something?
> > Generally I think that everything possible to do under /etc/portage should 
> > be
> > doable under a profile as well.
> 
> So after you ignore my other stuff:  Profiles are part of the PMS
> specification, so any changes that go in there have to be EAPI
> scheduled and cried over for a bit, and probably GLEPs and stuff also.
> 
> I guess portage could informally support it prior to any such
> specification materialising, but it would have to be forbidden in the
> main tree until such a specification was defined, or the portage tree
> would become PMS in-compatible.

Yes, exactly! There is no need to use non PMS compatible features in
the gentoo tree.

 Jocke

[gentoo-portage-dev] USE_EXPAND in profiles?

[Joakim Tjernlund]

Under /etc/portage/package.use one can add:
  sys-libs/ntdb PYTHON_TARGETS: python2_7
  net-fs/samba  PYTHON_TARGETS: python2_7

But when I try to transfer this to our custom profile I get
--- Invalid USE flag for 'sys-libs/ntdb' in 
'/var/lib/layman/transmode/profiles/gentoo64-common/package.use': 
'PYTHON_TARGETS:'
--- Invalid USE flag for 'net-fs/samba' in 
'/var/lib/layman/transmode/profiles/gentoo64-common/package.use': 
'PYTHON_TARGETS:'

I am missing something? 
Generally I think that everything possible to do under /etc/portage should be
doable under a profile as well.

Jocke

[gentoo-portage-dev] trying to speed up emerge

[Joakim Tjernlund]

emerge -NDuv world takes a log time until it begins to build pks, has been
like this for a long time.

straced emerge and I see the pattern below repeat over and over again.
I figured there is some cache problem but I cannot find out how to fix it.
Been running emerge --regen/--metadata and egencache --update --repo xxx for 
all repos/overlays
Where to look next?

 Jocke

stat("/usr/portage/profiles/base/profile.bashrc", {st_mode=S_IFREG|0644, 
st_size=183, ...}) = 0
stat("/usr/portage/profiles/default/linux/profile.bashrc", 0x7ffd69c0d1d0) = -1 
ENOENT (No such file or directory)
stat("/usr/portage/profiles/arch/base/profile.bashrc", 0x7ffd69c0d1d0) = -1 
ENOENT (No such file or directory)
stat("/usr/portage/profiles/features/multilib/profile.bashrc", 0x7ffd69c0d1d0) 
= -1 ENOENT (No such file or directory)
stat("/usr/portage/profiles/features/multilib/lib32/profile.bashrc", 
0x7ffd69c0d1d0) = -1 ENOENT (No such file or directory)
stat("/usr/portage/profiles/arch/amd64/profile.bashrc", 0x7ffd69c0d1d0) = -1 
ENOENT (No such file or directory)
stat("/usr/portage/profiles/default/linux/amd64/profile.bashrc", 
0x7ffd69c0d1d0) = -1 ENOENT (No such file or directory)
stat("/usr/portage/profiles/releases/profile.bashrc", 0x7ffd69c0d1d0) = -1 
ENOENT (No such file or directory)
stat("/usr/portage/profiles/releases/13.0/profile.bashrc", 0x7ffd69c0d1d0) = -1 
ENOENT (No such file or directory)
stat("/usr/portage/profiles/default/linux/amd64/13.0/profile.bashrc", 
0x7ffd69c0d1d0) = -1 ENOENT (No such file or directory)
stat("/usr/portage/profiles/targets/desktop/profile.bashrc", 0x7ffd69c0d1d0) = 
-1 ENOENT (No such file or directory)
stat("/usr/portage/profiles/default/linux/amd64/13.0/desktop/profile.bashrc", 
0x7ffd69c0d1d0) = -1 ENOENT (No such file or directory)
stat("/var/lib/layman/transmode/profiles/gentoo64-common/profile.bashrc", 
0x7ffd69c0d1d0) = -1 ENOENT (No such file or directory)
stat("/var/lib/layman/transmode/profiles/gentoo64/profile.bashrc", 
0x7ffd69c0d1d0) = -1 ENOENT (No such file or directory)
stat("/etc/portage/profile/profile.bashrc", 0x7ffd69c0d1d0) = -1 ENOENT (No 
such file or directory)
access("/var/lib/layman/transmode/media-libs/gegl/gegl-.ebuild", R_OK) = -1 
ENOENT (No such file or directory)
access("/var/lib/layman/tmv3-cross-overlay/media-libs/gegl/gegl-.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/telred/media-libs/gegl/gegl-.ebuild", R_OK) = -1 
ENOENT (No such file or directory)
access("/usr/local/portage/gentoo-mate/media-libs/gegl/gegl-.ebuild", R_OK) 
= -1 ENOENT (No such file or directory)
access("/var/lib/layman/transmode/media-libs/gegl/gegl-0.3.4.ebuild", R_OK) = 
-1 ENOENT (No such file or directory)
access("/var/lib/layman/tmv3-cross-overlay/media-libs/gegl/gegl-0.3.4.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/telred/media-libs/gegl/gegl-0.3.4.ebuild", R_OK) = -1 
ENOENT (No such file or directory)
access("/usr/local/portage/gentoo-mate/media-libs/gegl/gegl-0.3.4.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/transmode/media-libs/gegl/gegl-0.3.2.ebuild", R_OK) = 
-1 ENOENT (No such file or directory)
access("/var/lib/layman/tmv3-cross-overlay/media-libs/gegl/gegl-0.3.2.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/telred/media-libs/gegl/gegl-0.3.2.ebuild", R_OK) = -1 
ENOENT (No such file or directory)
access("/usr/local/portage/gentoo-mate/media-libs/gegl/gegl-0.3.2.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/transmode/media-libs/gegl/gegl-0.3.0.ebuild", R_OK) = 
-1 ENOENT (No such file or directory)
access("/var/lib/layman/tmv3-cross-overlay/media-libs/gegl/gegl-0.3.0.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/telred/media-libs/gegl/gegl-0.3.0.ebuild", R_OK) = -1 
ENOENT (No such file or directory)
access("/usr/local/portage/gentoo-mate/media-libs/gegl/gegl-0.3.0.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/transmode/media-libs/gegl/gegl-0.2.0-r2.ebuild", R_OK) 
= -1 ENOENT (No such file or directory)
access("/var/lib/layman/tmv3-cross-overlay/media-libs/gegl/gegl-0.2.0-r2.ebuild",
 R_OK) = -1 ENOENT (No such file or directory)
access("/var/lib/layman/telred/media-libs/gegl/gegl-0.2.0-r2.ebuild", R_OK) = 
-1 ENOENT (No such file or directory)
access("/usr/local/portage/gentoo-mate/media-libs/gegl/gegl-0.2.0-r2.ebuild", 
R_OK) = -1 ENOENT (No such file or directory)

Re: [gentoo-portage-dev] emerge getting slower

[Joakim Tjernlund]

On Mon, 2015-12-21 at 12:36 -0800, Zac Medico wrote:
> On 12/21/2015 12:24 PM, Joakim Tjernlund wrote:
> > Lately it feels like emerge has been getting unusual slow to calculate 
> > dependencies.
> > I did a strace while emerge was running and noticed a lot of:
> > 
> > stat64("/usr/portage/profiles/base/profile.bashrc", {st_mode=S_IFREG|0644, 
> > st_size=183, ...}) = 0
> > stat64("/usr/portage/profiles/default/linux/profile.bashrc", 0xbfbb02d0) = 
> > -1 ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
> > ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = 
> > -1 ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/default/linux/powerpc/profile.bashrc", 
> > 0xbfbb02d0) = -1 ENOENT (No such file
> > or directory)
> > stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
> > ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = 
> > -1 ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/arch/powerpc/ppc32/profile.bashrc", 
> > 0xbfbb02d0) = -1 ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/profile.bashrc", 
> > 0xbfbb02d0) = -1 ENOENT (No
> > such file or directory)
> > stat64("/usr/portage/profiles/releases/profile.bashrc", 0xbfbb02d0) = -1 
> > ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/releases/13.0/profile.bashrc", 0xbfbb02d0) = 
> > -1 ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/13.0/profile.bashrc",
> >  0xbfbb02d0) = -1 ENOENT
> > (No such file or directory)
> > stat64("/usr/local/portage/tmv3-target-overlay/profiles/cusfpv3/profile.bashrc",
> >  {st_mode=S_IFREG|0644,
> > st_size=133, ...}) = 0
> > stat64("/etc/portage/profile/profile.bashrc", 0xbfbb02d0) = -1 ENOENT (No 
> > such file or directory)
> > access("/usr/local/portage/tmv3-target-overlay/dev-libs/apr/apr-1.5.1-r1.ebuild",
> >  R_OK) = -1 ENOENT (No
> > such file or directory)
> > access("/usr/portage/dev-libs/apr/apr-1.5.1-r1.ebuild", R_OK) = 0
> > stat64("/usr/portage/dev-libs/apr/apr-1.5.1-r1.ebuild", 
> > {st_mode=S_IFREG|0644, st_size=4215, ...}) = 0
> > open("/usr/portage/metadata/md5-cache/dev-libs/apr-1.5.1-r1", 
> > O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
> > fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
> > ioctl(5, TCGETS, 0xbfbb0d88)= -1 ENOTTY (Inappropriate ioctl 
> > for device)
> > fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
> > _llseek(5, 0, [0], SEEK_CUR)= 0
> > _llseek(5, 0, [0], SEEK_CUR)= 0
> > _llseek(5, 0, [0], SEEK_CUR)= 0
> > fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
> > read(5, "DEFINED_PHASES=compile configure"..., 1351) = 1350
> > read(5, "", 1)  = 0
> > fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
> > close(5)= 0
> > open("/usr/portage/dev-libs/apr/apr-1.5.1-r1.ebuild", 
> > O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
> > fstat64(5, {st_mode=S_IFREG|0644, st_size=4215, ...}) = 0
> > ioctl(5, TCGETS, 0xbfbb0898)= -1 ENOTTY (Inappropriate ioctl 
> > for device)
> > fstat64(5, {st_mode=S_IFREG|0644, st_size=4215, ...}) = 0
> > _llseek(5, 0, [0], SEEK_CUR)= 0
> > read(5, "# Copyright 1999-2015 Gentoo Fou"..., 32768) = 4215
> > read(5, "", 24576)  = 0
> > read(5, "", 32768)  = 0
> > close(5)= 0
> > stat64("/usr/portage/profiles/base/profile.bashrc", {st_mode=S_IFREG|0644, 
> > st_size=183, ...}) = 0
> > stat64("/usr/portage/profiles/default/linux/profile.bashrc", 0xbfbb02d0) = 
> > -1 ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
> > ENOENT (No such file or
> > directory)
> > stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = 
> > -1 ENOENT (No such file or
> > directory)
> > stat64(&quo

[gentoo-portage-dev] emerge getting slower

[Joakim Tjernlund]

Lately it feels like emerge has been getting unusual slow to calculate 
dependencies.
I did a strace while emerge was running and noticed a lot of:

stat64("/usr/portage/profiles/base/profile.bashrc", {st_mode=S_IFREG|0644, 
st_size=183, ...}) = 0
stat64("/usr/portage/profiles/default/linux/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/default/linux/powerpc/profile.bashrc", 
0xbfbb02d0) = -1 ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/powerpc/ppc32/profile.bashrc", 0xbfbb02d0) = 
-1 ENOENT (No such file or directory)
stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/profile.bashrc", 
0xbfbb02d0) = -1 ENOENT (No such file or directory)
stat64("/usr/portage/profiles/releases/profile.bashrc", 0xbfbb02d0) = -1 ENOENT 
(No such file or directory)
stat64("/usr/portage/profiles/releases/13.0/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/13.0/profile.bashrc", 
0xbfbb02d0) = -1 ENOENT (No such file or directory)
stat64("/usr/local/portage/tmv3-target-overlay/profiles/cusfpv3/profile.bashrc",
 {st_mode=S_IFREG|0644, st_size=133, ...}) = 0
stat64("/etc/portage/profile/profile.bashrc", 0xbfbb02d0) = -1 ENOENT (No such 
file or directory)
access("/usr/local/portage/tmv3-target-overlay/dev-libs/apr/apr-1.5.1-r1.ebuild",
 R_OK) = -1 ENOENT (No such file or directory)
access("/usr/portage/dev-libs/apr/apr-1.5.1-r1.ebuild", R_OK) = 0
stat64("/usr/portage/dev-libs/apr/apr-1.5.1-r1.ebuild", {st_mode=S_IFREG|0644, 
st_size=4215, ...}) = 0
open("/usr/portage/metadata/md5-cache/dev-libs/apr-1.5.1-r1", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
ioctl(5, TCGETS, 0xbfbb0d88)= -1 ENOTTY (Inappropriate ioctl for 
device)
fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
_llseek(5, 0, [0], SEEK_CUR)= 0
_llseek(5, 0, [0], SEEK_CUR)= 0
_llseek(5, 0, [0], SEEK_CUR)= 0
fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
read(5, "DEFINED_PHASES=compile configure"..., 1351) = 1350
read(5, "", 1)  = 0
fstat64(5, {st_mode=S_IFREG|0644, st_size=1350, ...}) = 0
close(5)= 0
open("/usr/portage/dev-libs/apr/apr-1.5.1-r1.ebuild", 
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=4215, ...}) = 0
ioctl(5, TCGETS, 0xbfbb0898)= -1 ENOTTY (Inappropriate ioctl for 
device)
fstat64(5, {st_mode=S_IFREG|0644, st_size=4215, ...}) = 0
_llseek(5, 0, [0], SEEK_CUR)= 0
read(5, "# Copyright 1999-2015 Gentoo Fou"..., 32768) = 4215
read(5, "", 24576)  = 0
read(5, "", 32768)  = 0
close(5)= 0
stat64("/usr/portage/profiles/base/profile.bashrc", {st_mode=S_IFREG|0644, 
st_size=183, ...}) = 0
stat64("/usr/portage/profiles/default/linux/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/default/linux/powerpc/profile.bashrc", 
0xbfbb02d0) = -1 ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/base/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/powerpc/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/arch/powerpc/ppc32/profile.bashrc", 0xbfbb02d0) = 
-1 ENOENT (No such file or directory)
stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/profile.bashrc", 
0xbfbb02d0) = -1 ENOENT (No such file or directory)
stat64("/usr/portage/profiles/releases/profile.bashrc", 0xbfbb02d0) = -1 ENOENT 
(No such file or directory)
stat64("/usr/portage/profiles/releases/13.0/profile.bashrc", 0xbfbb02d0) = -1 
ENOENT (No such file or directory)
stat64("/usr/portage/profiles/default/linux/powerpc/ppc32/13.0/profile.bashrc", 
0xbfbb02d0) = -1 ENOENT (No such file or directory)
stat64("/usr/local/portage/tmv3-target-overlay/profiles/cusfpv3/profile.bashrc",
 {st_mode=S_IFREG|0644, st_size=133, ...}) = 0
stat64("/etc/portage/profile/profile.bashrc", 0xbfbb02d0) = -1 ENOENT (No such 
file or directory)
access("/usr/local/portage/tmv3-target-overlay/dev-libs/apr/apr-1.5.0-r2.ebuild",
 R_OK) = -1 ENOENT 

Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[Joakim Tjernlund]

On Thu, 2015-12-03 at 09:28 +0100, Alexis Ballier wrote:
> On Wed, 2 Dec 2015 23:20:05 +
> James Le Cuirot  wrote:
> 
> > On Wed, 2 Dec 2015 12:40:08 +0100
> > Alexis Ballier  wrote:
> > 
> > > On Tue, 1 Dec 2015 22:58:55 +
> > > James Le Cuirot  wrote:
> > > [...]  
> > > > 
> > > > I raised one further point with mgorny that he feels could
> > > > potentially go into EAPI 7 but I think could remain an
> > > > implementation detail. In cases #3 and #4 (basically when
> > > > ROOT != / and PORTAGE_CONFIGROOT != /), the toolchain needs to
> > > > know how to source headers and libraries from ROOT instead of /.  
> > > 
> > > Use SYSROOT. ROOT has nothing to do with building. This should be
> > > defined in PMS though.  
> > 
> > In case #2, ROOT != / but SYSROOT = / so I take your point that
> > SYSROOT would negate the need to check which use case we're dealing
> > with.
> > 
> > I looked into SYSROOT while I was writing cross-boss. It's used in
> > some crossdev scripts, most notably cross-pkg-config, but not by
> > pkg-config itself. It's also used in a small handful of eclasses and
> > other *-config scripts but that's all. Conversely, the aforementioned
> > libtool patch uses ROOT and I suspect many other things do too. In
> > practise, you need to set both.
> 
> The libtool patch has probably not been updated after SYSROOT
> introduction. Feel free to file a bug about it.
> 
> > On reflection, I'm now thinking that we should call it something less
> > generic. I also found that the Qt build uses SYSROOT for its own
> > purposes so you cannot rely on it in toolchain wrappers. ROOT is
> > probably just as unreliable. For that reason, I ended up using
> > CB_SYSROOT in cross-boss.
> > 
> > I forgot to mention earlier that if ROOT were used, PMS actually
> > forbids it from being referenced in the src_* phases so this
> > restriction would need to be lifted. Relying on the toolchain's
> > internal sysroot is not sufficient.
> 
> And PMS is absolutely right.
> 
> Put simple:
> SYSROOT is where "sources" are installed (headers, .so, etc); think
> debian's -dev packages.
> ROOT is where packages are merged.
> 
> Meaning:
> 
> RDEPEND are installed to ROOT
> DEPEND are installed to SYSROOT

hmm, this implies that a pkg in both DEPEND and RDEPEND should be installed in 
both
SYSROOT and ROOT? Does portage do this ATM?


> (BDEPEND are installed to /)

Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[Joakim Tjernlund]

On Thu, 2015-12-03 at 23:32 +, James Le Cuirot wrote:
> On Thu, 3 Dec 2015 08:22:01 +
> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> 
> > > There's also a further complication here that I forgot to mention to
> > > mgorny. While calling configure with --with-sysroot certainly helps,
> > > it still stumbles on a significant number of packages that do
> > > relinking at the end of the build if elibtoolize hasn't been called.
> > > elibtoolize has long patched ltmain.sh with
> > > ELT-patches/cross/link-ROOT  
> > 
> > I looked at ELT-patches/cross/link-ROOT and it has
> > --- libltdl/config/ltmain.sh2008-09-07 19:56:33.0
> > +0200 +++ libltdl/config/ltmain.sh.new  2009-02-15
> > 20:37:47.0 +0100 @@ -5768,7 +5768,7 @@
> >        test "$hardcode_direct_absolute" = no; then
> >       add="$libdir/$linklib"
> >     elif test "$hardcode_minus_L" = yes; then
> > -     add_dir="-L$libdir"
> > +     add_dir="-L$ROOT/$libdir"
> >       add="-l$name"
> >     elif test "$hardcode_shlibpath_var" = yes; then
> >       case :$finalize_shlibpath: in
> > @@ -5785,7 +5785,7 @@
> >       fi
> >     else
> >       # We cannot seem to hardcode it, guess we'll fake it.
> > -     add_dir="-L$libdir"
> > +     add_dir="-L$ROOT/$libdir"
> > 
> > I think this should be "add_dir=-L$lt_sysroot$libdir" rather than
> > ROOT. See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184
> > and since I think this is also a libool bug there is a post upstream
> >  http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html
> > This has not gotten any attention from upstream libtool folks. Would
> > be great if someone more could push for such a change.
> 
> Agreed. I already wondered if there was an autotools variable that
> would be more appreciate. Since aballier also said that this should be
> corrected, I'll see about doing that in conjunction with these changes.
> 
> I wouldn't hold your breath for upstream. I've heard of them ignoring
> other issues like the "as-needed" one for years.

Upstream seems a bit unfocused and probably needs some prodding to get
going. The suggested change is simple and won't affect normal libtool use
so it should not be to hard to get it committed.

 Jocke, off for the weekend as of now.

Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[Joakim Tjernlund]

On Tue, 2015-12-01 at 22:58 +, James Le Cuirot wrote:
> 

[SNIP really good writeup, thanks :)]

> There's also a further complication here that I forgot to mention to
> mgorny. While calling configure with --with-sysroot certainly helps,
> it still stumbles on a significant number of packages that do
> relinking at the end of the build if elibtoolize hasn't been called.
> elibtoolize has long patched ltmain.sh with ELT-patches/cross/link-ROOT

I looked at ELT-patches/cross/link-ROOT and it has
--- libltdl/config/ltmain.sh2008-09-07 19:56:33.0 +0200
+++ libltdl/config/ltmain.sh.new2009-02-15 20:37:47.0 +0100
@@ -5768,7 +5768,7 @@
       test "$hardcode_direct_absolute" = no; then
      add="$libdir/$linklib"
    elif test "$hardcode_minus_L" = yes; then
-     add_dir="-L$libdir"
+     add_dir="-L$ROOT/$libdir"
      add="-l$name"
    elif test "$hardcode_shlibpath_var" = yes; then
      case :$finalize_shlibpath: in
@@ -5785,7 +5785,7 @@
      fi
    else
      # We cannot seem to hardcode it, guess we'll fake it.
-     add_dir="-L$libdir"
+     add_dir="-L$ROOT/$libdir"

I think this should be "add_dir=-L$lt_sysroot$libdir" rather than ROOT.
See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184
and since I think this is also a libool bug there is a post upstream
 http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html
This has not gotten any attention from upstream libtool folks. Would
be great if someone more could push for such a change.

 Jocke

> when cross-compiling and this still applies to the very latest libtool.
> I filed several bugs about this before realising that fixing this
> globally would be better. elibtoolize doesn't require anything to be
> installed and the description does say "this function should always be
> safe to run" but I suppose calling it unconditionally might screw up
> patching in some isolated cases. What do you think?
> 
> Phew, I'm done. Please be gentle! :)
> 

Re: [gentoo-portage-dev] cat/pkg::x-portage ?

[Joakim Tjernlund]

On Tue, 2015-12-01 at 10:44 -0500, Mike Frysinger wrote:
> On 24 Nov 2015 15:41, Joakim Tjernlund wrote:
> > Emerging on my embedded gentoo ppc target I see this:
> >   
> >   dev-lang/python-exec-2.0.1-r1::x-portage
> >   sys-apps/install-xattr-0.5::x-portage
> >   sys-libs/timezone-data-2015f::x-portage
> > 
> > Where does the name x-portage come from? I do not have a repo
> > named x-portage, it is still named gentoo.
> 
> it has no name so one is auto-created using the path.

Ahh, this must be the repos.conf/repo_name conflict/mess.
I have a name in repos.conf but I have deleted the profiles/repo_name file in
the repo.

This inconsistency could use some portage (and related tools) love. There is 
also a bug
https://bugs.gentoo.org/show_bug.cgi?id=563874

> pym/portage/repository/config.py:
> @staticmethod
> def _read_valid_repo_name(repo_path):
> name, missing = RepoConfig._read_repo_name(repo_path)
> # We must ensure that the name conforms to PMS 3.1.5
> # in order to avoid InvalidAtom exceptions when we
> # use it to generate atoms. 
> name = _gen_valid_repo(name)
> if not name:
> # name only contains invalid characters
> name = "x-" + os.path.basename(repo_path) 
> name = _gen_valid_repo(name)
> # If basename only contains whitespace then the
> # end result is name = 'x-'.
> return name, missing
> 
> @staticmethod
> def _read_repo_name(repo_path):
> """
> Read repo_name from repo_path.
> Returns repo_name, missing.
> """
> repo_name_path = os.path.join(repo_path, REPO_NAME_LOC)
> f = None
> try:
> f = io.open(
> _unicode_encode(repo_name_path,
> encoding=_encodings['fs'], errors='strict'),
> mode='r', encoding=_encodings['repo.content'],
> errors='replace')
> return f.readline().strip(), False
> except EnvironmentError:
> return "x-" + os.path.basename(repo_path), True
> finally:
> if f is not None:
> f.close()
> -mike

Re: [gentoo-portage-dev] Adding sets to @world in custom profile?

[Joakim Tjernlund]

On Fri, 2015-11-27 at 00:41 -0800, Zac Medico wrote:
> On 11/27/2015 12:24 AM, Joakim Tjernlund wrote:
> > On a related note, could not profile-formats = portage-2 profile-set
> > become default ?
> 
> For purposes of interoperability, we use PMS to document the standard
> profile format. So, in order to change the default profile format as you
> suggest, we would have to change PMS retroactively. Generally,
> retroactive changes to PMS need to be very well justified in order to be
> accepted.

hmm, how about in gentoo layout.conf?
There seems to be additions there so perhaps one can add
profile-formats = portage-2 profile-set ?

It is a pity these new features rarely sees the light of day as
few knowns about them.

 Jocke

Re: [gentoo-portage-dev] Adding sets to @world in custom profile?

[Joakim Tjernlund]

On Fri, 2015-11-27 at 13:46 +0100, Michał Górny wrote:
> On Fri, 27 Nov 2015 11:45:48 +
> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> 
> > On Fri, 2015-11-27 at 00:41 -0800, Zac Medico wrote:
> > > On 11/27/2015 12:24 AM, Joakim Tjernlund wrote:  
> > > > On a related note, could not profile-formats = portage-2 profile-set
> > > > become default ?  
> > > 
> > > For purposes of interoperability, we use PMS to document the standard
> > > profile format. So, in order to change the default profile format as you
> > > suggest, we would have to change PMS retroactively. Generally,
> > > retroactive changes to PMS need to be very well justified in order to be
> > > accepted.  
> > 
> > hmm, how about in gentoo layout.conf?
> > There seems to be additions there so perhaps one can add
> > profile-formats = portage-2 profile-set ?
> 
> This will break the two alternative package managers as profile-set is
> only implemented in Portage.

What about:
# Use thin Manifests for Git
thin-manifests = false

# Sign Git commits, and NOT Manifests
sign-commits = false
sign-manifests = false

Are these not fairly new too? How could these enter the gentoo repo?

What about adding portage-2 now and announce profile-set to be added soon?

 Jocke

Re: [gentoo-portage-dev] Adding sets to @world in custom profile?

[Joakim Tjernlund]

On Fri, 2015-11-27 at 14:46 +0100, Michał Górny wrote:
> On Fri, 27 Nov 2015 13:35:39 +
> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> 
> > On Fri, 2015-11-27 at 13:46 +0100, Michał Górny wrote:
> > > On Fri, 27 Nov 2015 11:45:48 +
> > > Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
> > >   
> > > > On Fri, 2015-11-27 at 00:41 -0800, Zac Medico wrote:  
> > > > > On 11/27/2015 12:24 AM, Joakim Tjernlund wrote:
> > > > > > On a related note, could not profile-formats = portage-2 profile-set
> > > > > > become default ?
> > > > > 
> > > > > For purposes of interoperability, we use PMS to document the standard
> > > > > profile format. So, in order to change the default profile format as 
> > > > > you
> > > > > suggest, we would have to change PMS retroactively. Generally,
> > > > > retroactive changes to PMS need to be very well justified in order to 
> > > > > be
> > > > > accepted.
> > > > 
> > > > hmm, how about in gentoo layout.conf?
> > > > There seems to be additions there so perhaps one can add
> > > > profile-formats = portage-2 profile-set ?  
> > > 
> > > This will break the two alternative package managers as profile-set is
> > > only implemented in Portage.  
> > 
> > What about:
> > # Use thin Manifests for Git
> > thin-manifests = false
> > 
> > # Sign Git commits, and NOT Manifests
> > sign-commits = false
> > sign-manifests = false
> > 
> > Are these not fairly new too? How could these enter the gentoo repo?
> 
> Hardly. They were both supported for a few years now (and used in many
> repositories), and considered useful.
> 
> > What about adding portage-2 now and announce profile-set to be added soon?
> 
> Why? Most of us don't even have a clue what is it and how it works.
> In fact, the name 'portage-*' implies it's non-standard extension that
> can't be used where portability matters.
> 

portage-2 allows stacking of (custom) profiles, very useful I think.
profile-set I think is needed for the @profile set, impl. in 
https://bugs.gentoo.org/show_bug.cgi?id=532224

 Jocke

Re: [gentoo-portage-dev] Adding sets to @world in custom profile?

[Joakim Tjernlund]

On Thu, 2015-11-26 at 10:47 -0800, Zac Medico wrote:
> On 11/24/2015 09:24 AM, Joakim Tjernlund wrote:
> > I have created my own set, @cusfpv3, and now I want to
> > include this set in @world using my custom profile.
> > How can I do that?
> > 
> > I can add it in overlay/sets.conf:
> > [CUSFPv3 sets]
> > class = portage.sets.files.StaticFileSet
> > multiset = true
> > directory = %(PORTAGE_CONFIGROOT)s${repository:tmv3-target-overlay}/sets/
> > 
> > [world]
> > class = portage.sets.base.DummyPackageSet
> > packages =  @cusfpv3 @profile @selected @system
> > 
> > But then this set becomes active as soon as one add the overlay to
> > a machine and I do not want that.
> > 
> >   Jocke
> > 
> 
> We could extend the @profile set to support nested sets. Would you like
> to file a feature request bug? For example, I requested support for the
> @profile set in this bug:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=532224

Feature req. in bug https://bugs.gentoo.org/show_bug.cgi?id=566960

 Thanks
         Jocke

Re: [gentoo-portage-dev] Adding sets to @world in custom profile?

[Joakim Tjernlund]

On Fri, 2015-11-27 at 09:12 +0100, an unknown sender wrote:
> On Thu, 2015-11-26 at 10:47 -0800, Zac Medico wrote:
> > On 11/24/2015 09:24 AM, Joakim Tjernlund wrote:
> > > I have created my own set, @cusfpv3, and now I want to
> > > include this set in @world using my custom profile.
> > > How can I do that?
> > > 
> > > I can add it in overlay/sets.conf:
> > > [CUSFPv3 sets]
> > > class = portage.sets.files.StaticFileSet
> > > multiset = true
> > > directory = %(PORTAGE_CONFIGROOT)s${repository:tmv3-target-overlay}/sets/
> > > 
> > > [world]
> > > class = portage.sets.base.DummyPackageSet
> > > packages =  @cusfpv3 @profile @selected @system
> > > 
> > > But then this set becomes active as soon as one add the overlay to
> > > a machine and I do not want that.
> > > 
> > >   Jocke
> > > 
> > 
> > We could extend the @profile set to support nested sets. Would you like
> > to file a feature request bug? For example, I requested support for the
> > @profile set in this bug:
> > 
> > https://bugs.gentoo.org/show_bug.cgi?id=532224
> 
> Feature req. in bug https://bugs.gentoo.org/show_bug.cgi?id=566960
> 
>  Thanks
>          Jocke

On a related note, could not profile-formats = portage-2 profile-set
become default ?

 Jocke

[gentoo-portage-dev] Adding sets to @world in custom profile?

[Joakim Tjernlund]

I have created my own set, @cusfpv3, and now I want to
include this set in @world using my custom profile.
How can I do that?

I can add it in overlay/sets.conf:
[CUSFPv3 sets]
class = portage.sets.files.StaticFileSet
multiset = true
directory = %(PORTAGE_CONFIGROOT)s${repository:tmv3-target-overlay}/sets/

[world]
class = portage.sets.base.DummyPackageSet
packages =  @cusfpv3 @profile @selected @system

But then this set becomes active as soon as one add the overlay to
a machine and I do not want that.

  Jocke

[gentoo-portage-dev] cat/pkg::x-portage ?

[Joakim Tjernlund]

Emerging on my embedded gentoo ppc target I see this:
  
  dev-lang/python-exec-2.0.1-r1::x-portage
  sys-apps/install-xattr-0.5::x-portage
  sys-libs/timezone-data-2015f::x-portage

Where does the name x-portage come from? I do not have a repo
named x-portage, it is still named gentoo.

 Jocke

[gentoo-portage-dev] distfiles in overlays?

[Joakim Tjernlund]

Sometimes I have to move files from my layman overlays distfiles to 
/usr/portage/distfiles
in orders to rebuild older stuff not in gentoo anymore.

Should not emerge search in distfiles where the ebuild resides?

What about eclass? What is the search order here?
If I got a customized user.eclass in my overlay, can I have this eclass take
precedence over the one in /usr/portage/eclass ?

 Jocke

Re: [gentoo-portage-dev] distfiles in overlays?

[Joakim Tjernlund]

On Tue, 2015-11-03 at 13:38 +0100, Michał Górny wrote:
> On Tue, 3 Nov 2015 12:29:01 +
> Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote:
> 
> > Sometimes I have to move files from my layman overlays distfiles to 
> > /usr/portage/distfiles
> > in orders to rebuild older stuff not in gentoo anymore.
> > 
> > Should not emerge search in distfiles where the ebuild resides?
> 
> distfiles are not part of repository. The /usr/portage/distfiles path
> is just wrong and you shouldn't be using it.

I am not "using" it, emerge does so by default. It would be nice if portage 
tried
distfiles in the overlay it found the ebuild in or if one could configure which 
distfiles
to use in repos.conf. Makes it much easier to keep track of different source 
files
and then storing then in a git repo so one can find them after they are gone 
from gentoo.

> 
> > What about eclass? What is the search order here?
> 
> It follows masters. First the repository with ebuild. If it's not
> there, it looks through all masters, then their masters etc.
> 
> > If I got a customized user.eclass in my overlay, can I have this eclass take
> > precedence over the one in /usr/portage/eclass ?
> 
> Yes. 'man 5 portage', look for eclass-overrides. Note that this will
> effectively discard metadata cache and therefore make stuff slow after
> syncing   .

OK, thanks.

 Jocke

Re: [gentoo-portage-dev] @sets and @profile does not work when ROOT=PORTAGE_CONFIGROOT=/my/new/root

[Joakim Tjernlund]

On Thu, 2015-10-22 at 11:54 -0700, Zac Medico wrote:
> On 10/22/2015 11:29 AM, Joakim Tjernlund wrote:
> > On Thu, 2015-10-22 at 08:54 -0700, Zac Medico wrote:
> > > On 10/22/2015 12:05 AM, Joakim Tjernlund wrote:
> > > > I don't use world_sets, I have in my 
> > > > profile(/my/new/root/usr/local/portage/tmv3-target-overlay):
> > > > # > cat sets.conf 
> > > > [CUSFPv3 sets]
> > > > class = portage.sets.files.StaticFileSet
> > > > multiset = true
> > > > directory = ${repository:tmv3-target-overlay}/sets/
> > > > 
> > > > [world]
> > > > class = portage.sets.base.DummyPackageSet
> > > > packages =  @cusfpv3 @profile @selected @system
> > > > 
> > > > and in sets/:
> > > > # > cat sets/cusfpv3
> > > > net-ftp/ftp
> > > > net-ftp/tftp-hpa
> > > > net-ftp/vsftpd
> > > > 
> > > > 
> > > > and now it hits me, this line:
> > > >  directory = ${repository:tmv3-target-overlay}/sets/
> > > > does it always refer too ROOT=/ ?
> > > 
> > > You need to use %(ROOT)s${repository:tmv3-target-overlay}/sets to
> > > substitute $ROOT into the set configuration. For example, the default
> > > set configuration located at /usr/share/portage/config/sets/portage.conf
> > > does something similar with %(PORTAGE_CONFIGROOT)s.
> > 
> > Nice! I am a bit puzzled over the trailing s in ..)s, is that a typo? if not
> > what does it mean?
> 
> The trailing s is required. It's python configparser interpolation syntax:
> 
> https://docs.python.org/3/library/configparser.html#interpolation-of-values

Looking at that URL I wonder why not use ExtendedInterpolation ?
This would look like any other variable used in portage.

  Jocke

Re: [gentoo-portage-dev] cross emerge pulls in my hosts gentoo repo

[Joakim Tjernlund]

On Thu, 2015-10-22 at 18:58 -0700, Zac Medico wrote:
> On 10/22/2015 12:24 AM, Joakim Tjernlund wrote:
> > In my cross sysroot I have:
> > [DEFAULT]
> > main-repo = tm-cusfpv3
> > 
> > [tm-cusfpv3]
> > location = /usr/local/portage/tm-cusfpv3/
> > masters =
> > priority = 500
> > auto-sync = no
> > 
> > Still  "sudo powerpc-g2.20-linux-gnu-emerge -d -ep  sys-libs/pam" pulls in
> > my hosts gentoo repo:
> 
> Note that emerge -e has known issues with ROOT:
> 
> https://bugs.gentoo.org/show_bug.cgi?id=239114
> 
> > 
> > (sys-libs/ncurses-5.9-r5:0/5::tm-cusfpv3, installed in 
> > '/usr/powerpc-g2.20-linux-gnu/') (no children)
> > (sys-libs/pam-1.2.1:0/0::tm-cusfpv3, ebuild scheduled for merge to 
> > '/usr/powerpc-g2.20-linux-gnu/')
> > depends on
> >   (sys-auth/pambase-20150213:0/0::tm-cusfpv3, ebuild scheduled for merge to 
> > '/usr/powerpc-g2.20-linux
> > -gnu/')
> > (runtime_post)
> >   (virtual/libintl-0-r2:0/0::gentoo, ebuild scheduled for merge to 
> > '/usr/powerpc-g2.20-linux-gnu/')
> > (runtime)
> > ...
> > 
> > feels much like there is a hardcoded search for gentoo 
> 
> No, there's nothing hardcoded about the gentoo repo.
> 
> > and it will even fallback
> > to my hosts /etc/portage/repos.conf
> 
> Yes, but only for DEPEND (also HDEPEND if you use EAPI 5-hdepend) which

I am not using EAPI 5-hdepend

> is installed to ROOT=/ by default (unless you use the --root-deps option).

I am, crossdev's emerge wrapper uses emerge --root-deps=rdeps

> 
> > Both ROOT and PORTAGE_CONFIGROOT are set to point at my cross sysroot
> 
> Since ROOT=/ is used to satisfy DEPEND, the configuration for
> PORTAGE_CONFIGROOT=/ is still loaded even when you have set ROOT and
> PORTAGE_CONFIGROOT to some other location.

hmm, this is very confusing. As is powerpc-g2.20-linux-gnu-emerge will pull
the virtual/libintl-0-r2 into my sysroot because it is newer than what I have in
my local gentoo repo config. This should not happen I think when using 
--root-deps=rdeps
or --root-deps only, it will break the sysroot sooner or later.

 Jocke

[gentoo-portage-dev] repos.conf, location, is it an absolute path ?

[Joakim Tjernlund]

in any repos.conf there is a
  location=/path/to/repo
is this path absolute or does it follow ROOT or PORTAGE_CONFIG ?

I tried to add location=${ROOT}/path/to/repo but emerge
would only accept this for the master gentoo repo:
[gentoo]
location = ${ROOT}/usr/portage
..
[tmv3-target-overlay]
location = ${ROOT}/usr/local/portage/tmv3-target-overlay

and emerge gives me:
emerge -aNDuv world
!!! Section 'tmv3-target-overlay' in repos.conf has location attribute set to 
nonexistent directory:
'${ROOT}/usr/local/portage/tmv3-target-overlay'

 Jocke

Re: [gentoo-portage-dev] @sets and @profile does not work when ROOT=PORTAGE_CONFIGROOT=/my/new/root

[Joakim Tjernlund]

On Wed, 2015-10-21 at 21:35 -0700, Zac Medico wrote:
> On 10/21/2015 09:47 AM, Joakim Tjernlund wrote:
> > I have enabled @sets and @profile in my own profile and if I add
> > some pkg to either my new set or @profile in ROOT=PORTAGE_CONFIGROOT=/
> > then emerge -aNDuv world notices this and pulls in the new pkg.
> > 
> > Then I clone / to  /my/new/root and add a pkg @profile or my set 
> > ROOT=/my/new/root PORTAGE_CONFIGROOT=/my/new/root emerge -aNDuv world 
> > nothing happens.
> > 
> > This feels like @profile and @sets looks in ROOT=PORTAGE_CONFIGROOT=/
> > instead of ROOT=PORTAGE_CONFIGROOT=/my/new/root
> > 
> > if I in my new ROOT(/my/new/root) add pkg to the @system set it works.
> > 
> > Does this make sense to you?
> > 
> >   Jocke
> > 
> 
> Are there any special details about your set configuration that we might
> need to consider? The following strace command seems to show that
> load_emerge_config uses the correct world file when the ROOT variable is
> set:

I don't use world_sets, I have in my 
profile(/my/new/root/usr/local/portage/tmv3-target-overlay):
# > cat sets.conf 
[CUSFPv3 sets]
class = portage.sets.files.StaticFileSet
multiset = true
directory = ${repository:tmv3-target-overlay}/sets/

[world]
class = portage.sets.base.DummyPackageSet
packages =  @cusfpv3 @profile @selected @system

and in sets/:
# > cat sets/cusfpv3
net-ftp/ftp
net-ftp/tftp-hpa
net-ftp/vsftpd


and now it hits me, this line:
 directory = ${repository:tmv3-target-overlay}/sets/
does it always refer too ROOT=/ ?

> 
> $ ROOT=/mnt/gentoo strace python -c 'from _emerge.actions import
> load_emerge_config;
> load_emerge_config().target_config.setconfig.getSetAtoms("world")' 2>&1
> > grep world
> stat("/usr/lib64/python3.4/site-packages/_emerge/create_world_atom.py",
> {st_mode=S_IFREG|0644, st_size=4414, ...}) = 0
> stat("/usr/lib64/python3.4/site-packages/_emerge/create_world_atom.py",
> {st_mode=S_IFREG|0644, st_size=4414, ...}) = 0
> open("/usr/lib64/python3.4/site-packages/_emerge/__pycache__/create_world_atom.cpython-34.pyc",
> O_RDONLY|O_CLOEXEC) = 4
> read(4, "# required by @world (argument)\n"..., 8192) = 8192
> read(4, "# required by @world (argument)\n"..., 8192) = 8192
> stat("/mnt/gentoo/var/lib/portage/world", {st_mode=S_IFREG|0644,
> st_size=14364, ...}) = 0
> stat("/mnt/gentoo/var/lib/portage/world", {st_mode=S_IFREG|0644,
> st_size=14364, ...}) = 0
> open("/mnt/gentoo/var/lib/portage/world", O_RDONLY|O_CLOEXEC) = 4
> stat("/mnt/gentoo/var/lib/portage/world_sets", {st_mode=S_IFREG|0644,
> st_size=0, ...}) = 0
> stat("/mnt/gentoo/var/lib/portage/world_sets", {st_mode=S_IFREG|0644,
> st_size=0, ...}) = 0
> open("/mnt/gentoo/var/lib/portage/world_sets", O_RDONLY|O_CLOEXEC) = 4
> stat("/mnt/gentoo/var/lib/portage/world", {st_mode=S_IFREG|0644,
> st_size=14364, ...}) = 0
> stat("/mnt/gentoo/var/lib/portage/world", {st_mode=S_IFREG|0644,
> st_size=14364, ...}) = 0
> open("/mnt/gentoo/var/lib/portage/world", O_RDONLY|O_CLOEXEC) = 4
> stat("/mnt/gentoo/var/lib/portage/world_sets", {st_mode=S_IFREG|0644,
> st_size=0, ...}) = 0
> stat("/mnt/gentoo/var/lib/portage/world_sets", {st_mode=S_IFREG|0644,
> st_size=0, ...}) = 0
> open("/mnt/gentoo/var/lib/portage/world_sets", O_RDONLY|O_CLOEXEC) = 4

[gentoo-portage-dev] cross emerge pulls in my hosts gentoo repo

[Joakim Tjernlund]

In my cross sysroot I have:
[DEFAULT]
main-repo = tm-cusfpv3

[tm-cusfpv3]
location = /usr/local/portage/tm-cusfpv3/
masters =
priority = 500
auto-sync = no

Still  "sudo powerpc-g2.20-linux-gnu-emerge -d -ep  sys-libs/pam" pulls in
my hosts gentoo repo:

(sys-libs/ncurses-5.9-r5:0/5::tm-cusfpv3, installed in 
'/usr/powerpc-g2.20-linux-gnu/') (no children)
(sys-libs/pam-1.2.1:0/0::tm-cusfpv3, ebuild scheduled for merge to 
'/usr/powerpc-g2.20-linux-gnu/') depends on
  (sys-auth/pambase-20150213:0/0::tm-cusfpv3, ebuild scheduled for merge to 
'/usr/powerpc-g2.20-linux-gnu/')
(runtime_post)
  (virtual/libintl-0-r2:0/0::gentoo, ebuild scheduled for merge to 
'/usr/powerpc-g2.20-linux-gnu/') (runtime)
...

feels much like there is a hardcoded search for gentoo and it will even fallback
to my hosts /etc/portage/repos.conf

Both ROOT and PORTAGE_CONFIGROOT are set to point at my cross sysroot

 Jocke

Re: [gentoo-portage-dev] @sets and @profile does not work when ROOT=PORTAGE_CONFIGROOT=/my/new/root

[Joakim Tjernlund]

On Thu, 2015-10-22 at 08:54 -0700, Zac Medico wrote:
> On 10/22/2015 12:05 AM, Joakim Tjernlund wrote:
> > I don't use world_sets, I have in my 
> > profile(/my/new/root/usr/local/portage/tmv3-target-overlay):
> > # > cat sets.conf 
> > [CUSFPv3 sets]
> > class = portage.sets.files.StaticFileSet
> > multiset = true
> > directory = ${repository:tmv3-target-overlay}/sets/
> > 
> > [world]
> > class = portage.sets.base.DummyPackageSet
> > packages =  @cusfpv3 @profile @selected @system
> > 
> > and in sets/:
> > # > cat sets/cusfpv3
> > net-ftp/ftp
> > net-ftp/tftp-hpa
> > net-ftp/vsftpd
> > 
> > 
> > and now it hits me, this line:
> >  directory = ${repository:tmv3-target-overlay}/sets/
> > does it always refer too ROOT=/ ?
> 
> You need to use %(ROOT)s${repository:tmv3-target-overlay}/sets to
> substitute $ROOT into the set configuration. For example, the default
> set configuration located at /usr/share/portage/config/sets/portage.conf
> does something similar with %(PORTAGE_CONFIGROOT)s.

Nice! I am a bit puzzled over the trailing s in ..)s, is that a typo? if not
what does it mean?

Can I use %(PORTAGE_CONFIGROOT) in repos.conf too? or is it not needed?