Re: [gentoo-portage-dev] repos.conf location w.r.t PORTAGE_CONFIGROOT
On Thu, 2015-05-07 at 14:09 -0700, Zac Medico wrote:
On 05/07/2015 03:51 AM, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 22:45 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 15:16 -0700, Zac Medico wrote:
On 05/06/15 14:57, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 14:36 -0700, Zac Medico wrote:
On 05/06/15 14:30, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 13:30 -0700, Zac Medico wrote:
On 05/06/15 13:22, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 12:54 -0700, Zac Medico wrote:
On 05/06/15 12:41, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 19:13 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 11:37 -0700, Zac Medico wrote:
On 05/06/15 09:54, Joakim Tjernlund wrote:
I am trying to rebuild an old cross sysroot and I
got problems.
I cannot make emerge to select my old ebuilds in an
overlay over those
in /usr/portage.
What new is since last time I did this is
/etc/portage/repos.conf/
I suspect emerge always reads
/etc/portage/repos.conf/ no matter
what I set PORTAGE_CONFIGROOT / ROOT to ?
Jocke
It instantiates 2 config instances, one using
/etc/portage/repos.conf
(for build time DEPEND) and another one using
$PORTAGE_CONFIGROOT/etc/portage/repos.conf (for run
time {P,R}DEPEND).
You can see that it's joined with PORTAGE_CONFIGROOT
in the
load_repository_config function:
https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/repository/config.py?id=
0f19
11
13cc
cd04
9e11
fdbe
73
493eb1efbf4bf89e#n971
I see, doesn't this prevent exactly what I want to do?
I can't see why this should be needed, it only creates
a mess, another example:
I tried to specify exact version of my old binutils and
while that worked, portage
wanted
to pull in a newer binutils-config from the hosts
master gentoo repo and
thus the build failed.
If a someone really wants this behaviour, he can just
add the hosts master repo
in his PORTAGE_CONFIGROOT IMHO
Maybe emerge --root-deps=rdeps is what you are looking for.
This will
cause it to ignore DEPEND.
That is not the same is it? if I emerge ncurses it will
build ncurses but still
take the ebuild from the hosts master since it is newer
version.
I realize now that I can change what repos are searched by
using
PORTAGE_REPOSITORIES=/my/own/repos.conf/
but I still find the default behaviour very confusing and I
don't see that it is useful.
The idea is that you have separate repositories configured for
each
ROOT. If it's satisfying a build-time DEPEND that will be
installed into
ROOT=/, then it's supposed to use the repositories configured
for ROOT=/.
I see, but in my case I only install into my sysroot so I don't
want this behaviour.
So, why don't you use the --root-deps option?
Just did(and --root-deps=rdeps too) and it didn't work, still wants
to use
my newer hosts pkgs. :(
It shouldn't do that. It sounds like maybe the [gentoo] config
from/usr/share/portage/config/repos.conf is the source of your problems,
since you $PORTAGE_CONFIGROOT config will always inherit that. Would
that be consistent with your observations?
Moving that file out of the way changed things, now I got I profile error:
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'gentoo:default/linux/amd64/13.0' not found:
'/var/lib/layman/transmode/profiles/gentoo64-server/parent'
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
Which I think is a problem in my cross env.
No, this is not it. Portage just bails when reading the host profile which
it should not.
Note: defining
PORTAGE_REPOSITORIES=/my/own/repos.conf
gives the same error.
According to the error message, your transmode profile inherits a gentoo
profile, so you need the gentoo repository (at least the relevant profile).
I have a my own profile in
Re: [gentoo-portage-dev] repos.conf location w.r.t PORTAGE_CONFIGROOT
On 05/07/2015 11:43 PM, Joakim Tjernlund wrote:
On Thu, 2015-05-07 at 14:09 -0700, Zac Medico wrote:
On 05/07/2015 03:51 AM, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 22:45 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 15:16 -0700, Zac Medico wrote:
On 05/06/15 14:57, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 14:36 -0700, Zac Medico wrote:
On 05/06/15 14:30, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 13:30 -0700, Zac Medico wrote:
On 05/06/15 13:22, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 12:54 -0700, Zac Medico wrote:
On 05/06/15 12:41, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 19:13 +, Joakim Tjernlund wrote:
On Wed, 2015-05-06 at 11:37 -0700, Zac Medico wrote:
On 05/06/15 09:54, Joakim Tjernlund wrote:
I am trying to rebuild an old cross sysroot and I got problems.
I cannot make emerge to select my old ebuilds in an overlay
over those
in /usr/portage.
What new is since last time I did this is
/etc/portage/repos.conf/
I suspect emerge always reads /etc/portage/repos.conf/ no matter
what I set PORTAGE_CONFIGROOT / ROOT to ?
Jocke
It instantiates 2 config instances, one using
/etc/portage/repos.conf
(for build time DEPEND) and another one using
$PORTAGE_CONFIGROOT/etc/portage/repos.conf (for run time
{P,R}DEPEND).
You can see that it's joined with PORTAGE_CONFIGROOT in the
load_repository_config function:
https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/repository/config.py?id=
0f19
11
13cc
cd04
9e11
fdbe
73
493eb1efbf4bf89e#n971
I see, doesn't this prevent exactly what I want to do?
I can't see why this should be needed, it only creates a mess,
another example:
I tried to specify exact version of my old binutils and while
that worked, portage
wanted
to pull in a newer binutils-config from the hosts master gentoo
repo and
thus the build failed.
If a someone really wants this behaviour, he can just add the
hosts master repo
in his PORTAGE_CONFIGROOT IMHO
Maybe emerge --root-deps=rdeps is what you are looking for. This
will
cause it to ignore DEPEND.
That is not the same is it? if I emerge ncurses it will build
ncurses but still
take the ebuild from the hosts master since it is newer version.
I realize now that I can change what repos are searched by using
PORTAGE_REPOSITORIES=/my/own/repos.conf/
but I still find the default behaviour very confusing and I don't
see that it is useful.
The idea is that you have separate repositories configured for each
ROOT. If it's satisfying a build-time DEPEND that will be installed
into
ROOT=/, then it's supposed to use the repositories configured for
ROOT=/.
I see, but in my case I only install into my sysroot so I don't want
this behaviour.
So, why don't you use the --root-deps option?
Just did(and --root-deps=rdeps too) and it didn't work, still wants to
use
my newer hosts pkgs. :(
It shouldn't do that. It sounds like maybe the [gentoo] config
from/usr/share/portage/config/repos.conf is the source of your problems,
since you $PORTAGE_CONFIGROOT config will always inherit that. Would
that be consistent with your observations?
Moving that file out of the way changed things, now I got I profile error:
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'gentoo:default/linux/amd64/13.0' not found:
'/var/lib/layman/transmode/profiles/gentoo64-server/parent'
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
Which I think is a problem in my cross env.
No, this is not it. Portage just bails when reading the host profile which
it should not.
Note: defining
PORTAGE_REPOSITORIES=/my/own/repos.conf
gives the same error.
According to the error message, your transmode profile inherits a gentoo
profile, so you need the gentoo repository (at least the relevant profile).
I have a my own profile in PORTAGE_CONFIGROOT which does not
reference the host /etc/portage/make.profile at all so I think
portage is using the wrong profile.
When using ROOT=/foo, it always instantiates 2 profiles, and it uses one
profile for ROOT=/foo and the other profile for ROOT=/.
Futhermore, it does not understand the host profile, probably
because my own PORTAGE_CONFIGROOT don't have profile-formats = portage-2
You're saying this beciase of the above ParseError? I think maybe what
you want to do keep the default /usr/share/portage/config/repos.conf and
mask */*::gentoo in $PORTAGE_CONFIGROOT/etc/portage/package.mask.
--
Thanks,
Zac
[gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution
Hello. I'm not a Gentoo Developer and sorry if I shouldn't write such messages here. If it's really so then I'll consider this in the future and it will not happen again. The question is only for Russian Gentoo Developers subcommunity. I had been trying to push the idea of creating an united FOSS community to solve problems of the higher school of the Russian Federation. But such initiatives faded due to absence of support of top executives… And now (according to e.g. [1]) it won't be a problem, IMHO. And I'd prefer make a distribution for the higher shool based on Gentoo Linux. So here's the Question: Does anybody interested in creating a consortium to send an application to the Ministry of Communications? [1] http://www.opennet.ru/opennews/art.shtml?num=42189 Best regards, Dmirty. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution
I had been trying to push the idea of creating an united FOSS community to solve problems of the higher school of the Russian Federation. But such initiatives faded due to absence of support of top executives… And now (according to e.g. [1]) it won't be a problem, IMHO. It would. Just because of the fact, that top executives (in Education Dept, in regional ministerys and so on) is that kind of clerks, that WOULDN'T accept anything if it is impossible to get (read as steal) some money in personal. And I'd prefer make a distribution for the higher shool based on Gentoo Linux. I'd also prefer, but it is not that possible as you imagine. There is such thing as certification in Federal Security Service (FSB) and so on. And there is only two such distributions: Alt Linux and Rosa Linux (if not talking about GPL-violating MSVS and Elbrus OS with unknown status of GPL violation (since I'm not ready to pay $5k just to check if sources will be included there)). So here's the Question: Does anybody interested in creating a consortium to send an application to the Ministry of Communications? I'm partially interested to mentally maintain that, but I have to free time to activelly do anything in personal (but, probably, will be fine in a group). And, except of that, I even very interested in in-place integration, because: 1) I'm Gentoo-affiliated IT company CEO (and intereted in Gentoo popularity, and have legal possibility for in-place integration in the city I live now), 2) I'm a thrice father and dislike the idea my children will be forced to learn some M$-produced bloatware. That's why I very like the idea of FLOSS/Linuxes at all (and Gentoo in particular) in the schools. But, as I said, I doubt in success of that operation. But... Let the Force be with us... P.S. I'd not use politic-related phrases (like import software substitution) in international communities at all and here in particular. -- Best regards, mva signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] A question to Russian Gentoo Developers Community about import software substitution
On Sat, 09 May 2015 02:05:58 +0600 Vadim A. Misbakh-Soloviov m...@mva.name wrote: I'd also prefer, but it is not that possible as you imagine. There is such thing as certification in Federal Security Service (FSB) and so on. And there is only two such distributions: Alt Linux and Rosa Linux (if not talking about GPL-violating MSVS and Elbrus OS with unknown status of GPL violation (since I'm not ready to pay $5k just to check if sources will be included there)). For secure industrial OS there's one from Kaspersky wich isn't based on Linux kernel at all but was written by their own. And that's what FSB may check and certify if they want. But I don't think that you need to certify Linux Distribution for universities and colleges in FSB.
[gentoo-portage-dev] [PATCH] VdbMetadataDelta.applyDelta: handle remove events properly (bug 547532)
Since commit d800d224ab38c0f524d3fe858ebe201cbfa903c1, emerge --search
could report removed packages as installed, since applyDelta failed to
apply remove events unless the cpv exactly matched. Fix it to apply
the remove event to each affected package slot, using the same code
which is used to handle replaced packages for add events.
Fixes: d800d224ab38 (Log changes between vdb_metadata.pickle updates)
X-Gentoo-Bug: 547532
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=547532
---
pym/portage/dbapi/_VdbMetadataDelta.py | 39 ++
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/pym/portage/dbapi/_VdbMetadataDelta.py
b/pym/portage/dbapi/_VdbMetadataDelta.py
index 2dbb07a..7461f87 100644
--- a/pym/portage/dbapi/_VdbMetadataDelta.py
+++ b/pym/portage/dbapi/_VdbMetadataDelta.py
@@ -139,12 +139,12 @@ class VdbMetadataDelta(object):
def applyDelta(self, data):
packages = self._vardb._aux_cache[packages]
- added_slots = {}
+ deltas = {}
for delta in data[deltas]:
cpv = delta[package] + - + delta[version]
+ deltas[cpv] = delta
event = delta[event]
if event == add:
- added_slots[cpv] = delta
# Use aux_get to populate the cache
# for this cpv.
if cpv not in packages:
@@ -155,19 +155,22 @@ class VdbMetadataDelta(object):
elif event == remove:
packages.pop(cpv, None)
- # Remove replaced versions from updated slots
- for cached_cpv, (mtime, metadata) in list(packages.items()):
- if cached_cpv in added_slots:
- continue
- replaced = False
- for cpv, delta in added_slots.items():
- if (cached_cpv.startswith(delta[package]) and
- metadata.get(SLOT) == delta[slot]
and
- cpv_getkey(cached_cpv) ==
delta[package]):
- replaced = True
- break
- if replaced:
- del packages[cached_cpv]
- del added_slots[cpv]
- if not added_slots:
- break
+ if deltas:
+ # Delete removed or replaced versions from affected
slots
+ for cached_cpv, (mtime, metadata) in
list(packages.items()):
+ if cached_cpv in deltas:
+ continue
+
+ removed = False
+ for cpv, delta in deltas.items():
+ if
(cached_cpv.startswith(delta[package]) and
+ metadata.get(SLOT) ==
delta[slot] and
+ cpv_getkey(cached_cpv) ==
delta[package]):
+ removed = True
+ break
+
+ if removed:
+ del packages[cached_cpv]
+ del deltas[cpv]
+ if not deltas:
+ break
--
2.3.5
