Re: [gentoo-portage-dev] gentoolkit.git repository reorganized
On 22 Oct 2015 00:45, Mike Frysinger wrote: > On 21 Oct 2015 16:35, Paul Varner wrote: > > On 10/20/2015 03:34 AM, Alexander Berntsen wrote: > > > On 15/10/15 19:42, Paul Varner wrote: > > > > Over the last couple of days, I have done the following: > > > > > > > 1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git > > > > repository > > > > 2. Moved the gentoolkit branch to master on the > > > > gentoolkit.git repository > > > Why did you not just make gentoolkit master, and leave gentoolkit-dev as > > > a branch? That's certainly the common way of using git. > > > > > > > Mainly, because at this point gentoolkit and gentoolkit-dev are now > > almost completely separate code bases as well as being separate packages. > > > > They share a common ancestry and that can be seen looking through the > > commit log, but starting with gentoolkit-0.2.5, gentoolkit started > > migrating to python as the only scripting language and utilizing the > > Portage API with setuptools as the build system. The two remaining bash > > scripts are being rewritten in python and when that is complete, they > > will be completely separate code bases. > > > > gentoolkit-dev has stayed as a collection of stand-alone scripts written > > in multiple languages intended mainly for Gentoo developers. > > > > Since they really do not share any code anymore, it did not make sense > > to me keeping gentoolkit-dev as a branch and it should be in its own > > repository. > > echangelog is the only non-shell/python script, and arguably not useful > anymore. repoman itself has a changelog option, and since the move to > git, we don't commit ChangeLog entries anymore. i would just punt it. > > there's also eviewcvs written in perl, but that's also dead now that > we use git, so it should be punted. > > that really only leaves three: > - ebump - bash > - ekeyword - python > - imlate - python > > why not merge them into a single repo ? you can have a dev/ subdir > for scripts that are more developer oriented and put them behind a > USE=dev flag. another reason i think there should be one: gentoolkit-dev rarely sees releases, nor is it clear who is supposed to be making them, nor does it seem like a good use of time to have independent builds/packages. since gentoolkit is getting rolled, updates could finally go out. case in point: ekeyword was rewritten almost 2 years ago and it still hasn't seen a release. -mike signature.asc Description: Digital signature
Re: [gentoo-portage-dev] gentoolkit.git repository reorganized
On 21 Oct 2015 16:35, Paul Varner wrote: > On 10/20/2015 03:34 AM, Alexander Berntsen wrote: > > On 15/10/15 19:42, Paul Varner wrote: > > > Over the last couple of days, I have done the following: > > > > > 1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git > > > repository > > > 2. Moved the gentoolkit branch to master on the > > > gentoolkit.git repository > > Why did you not just make gentoolkit master, and leave gentoolkit-dev as > > a branch? That's certainly the common way of using git. > > > > Mainly, because at this point gentoolkit and gentoolkit-dev are now > almost completely separate code bases as well as being separate packages. > > They share a common ancestry and that can be seen looking through the > commit log, but starting with gentoolkit-0.2.5, gentoolkit started > migrating to python as the only scripting language and utilizing the > Portage API with setuptools as the build system. The two remaining bash > scripts are being rewritten in python and when that is complete, they > will be completely separate code bases. > > gentoolkit-dev has stayed as a collection of stand-alone scripts written > in multiple languages intended mainly for Gentoo developers. > > Since they really do not share any code anymore, it did not make sense > to me keeping gentoolkit-dev as a branch and it should be in its own > repository. echangelog is the only non-shell/python script, and arguably not useful anymore. repoman itself has a changelog option, and since the move to git, we don't commit ChangeLog entries anymore. i would just punt it. there's also eviewcvs written in perl, but that's also dead now that we use git, so it should be punted. that really only leaves three: - ebump - bash - ekeyword - python - imlate - python why not merge them into a single repo ? you can have a dev/ subdir for scripts that are more developer oriented and put them behind a USE=dev flag. -mike signature.asc Description: Digital signature
Re: [gentoo-portage-dev] @sets and @profile does not work when ROOT=PORTAGE_CONFIGROOT=/my/new/root
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:
$ 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
--
Thanks,
Zac
Re: [gentoo-portage-dev] [PATCH] emerge(1): document --oneshot caveats (bug 563482)
On 2015-10-20 at 22:11:24 -0700, zmed...@gentoo.org wrote: > Any packages that are not reachable from @world are ripe for removal by > --depclean, so we allow their dependencies to break in order to satisfy > other dependencies (like in bug 563482). If you don't use --deep, then > emerge may try to build something that depends on one of these > unreachable packages with broken dependencies, such that whatever you > are trying to build has broken indirect dependencies (which is likely to > trigger a build failure like in bug 563482). I think I understand. So, one could get the hypothetical scenario: # emerge --oneshot A # which depends on B # emerge --update @world # shuffles stuff around breaking B # emerge C # which depends on A Package C's dependency is filled, so emerge goes ahead and builds C. Now, either C fails to build, or it is installed but fails at runtime, because it depends on a package which depends on a package which is broken. Sound about right? -- There are problems in today's world that cannot be solved by the level of thinking that created them. -- Albert Einstein
[gentoo-portage-dev] Re: How to have several gentoo repos on one machine?
Joakim Tjernlund posted on Wed, 21 Oct 2015 11:08:02 + as excerpted: > I need to more than one gentoo repo in my computer. > > So I add to repos.conf: > [tm-cusfpv3] > auto-sync = yes > sync-type = rsync > sync-uri = rsync://devsrv.transmode.se/tm-cusfpv3 > location = /usr/local/portage/tm-cusfpv3 > > this did not work as "portageq repositories_configuration /" complains: > !!! Section 'tm-cusfpv3' in repos.conf has name different from > repository name 'gentoo' set inside repository > > I figured the name in repos.conf would just override > /usr/local/portage/tm-cusfpv3/profiles/repo_name ? While it's not quite clear to me either why you'd need two identical gentoo repos (and if they're not identical, why is the non-gentoo- official mirror still using the gentoo name?) or exactly what this config- line does, the aliases= attribute, along with force=aliases, in repos.conf, may be what you're looking for. See the portage (5) manpage, repos.conf section, attributes supported in sections of repositories subsection, under aliases and force. Unfortunately, the description for aliases is anything but clear, tho the usage (including comment) further down in the example subsection does help some. If that doesn't help, then while the portage devs may have some other suggestions, the workaround that occurs to me is to use rsync's exclude/ filter options, so rsync ignores that file and doesn't sync it. I do[1] that with a few custom files/dirs that I don't want synced, and rsync ignores them just as I told it to. =:^) See the rsync (1) manpage, --exclude, --exclude-from, --include, -- include-from and --filter=RULE options, as well as the filter rules, include/exclude pattern rules, and anchoring include/exclude patterns sections. However, be prepared to spend a bit of time studying, as these options are very powerful/flexible/configurable and thus take some time to figure out. Once you have rsync ignoring the repo_name file, you can rename it as you like. However, do be aware that (as the repos.conf force option docs mention) messing with this is very likely to invalidate the pre-generated metadata cache, and if you don't regenerate it (egencache), portage will take a *VERY* long time figuring stuff out, *MUCH* longer than usual, as it won't have the benefit of the metadata cache for that repo. Which again has me asking why you need two separate gentoo repos. Either they're identical and the one should suffice, or the unofficial one should be named something other than gentoo. In fact, at least in theory, in addition to all the headaches not using a different name is forcing on users, that's potentially trademark violation if it's publicly available, different from the official gentoo mirror, and yet still calling itself gentoo. --- [1] rsync exclude options: I actually use gentoo's git-based usersync repo on github, now, and thus don't rsync any repos all any more, here, and git of course has its git-ignore feature/files, which I use now. But I used rsync's exclude as suggested above, for years. Worked fine. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-portage-dev] Re: [PATCH] emerge(1): document --oneshot caveats (bug 563482)
Zac Medico posted on Wed, 21 Oct 2015 12:26:11 -0700 as excerpted: > Yeah, and if you run emerge --depclean regularly, then it will prevent > problems like these. Thanks, Zac. I should be covered then, since I both consistently run --deep, and consistently --depclean after updates. =:^) (And now I understand the interaction between not running --deep, and --oneshot, as well. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-portage-dev] repos config using enviroment?
Now that PORTDIR is deprecated I wonder if there is any other way to add an local overlay to emerge without adding it to /etc/portage/repos.conf ? In crossdev you just specify the local file path to a repo/overlay where to find ebuilds, add cross symlinks etc. but this will not work if not the local repo is listed in repos.conf Jocke
[gentoo-portage-dev] How to have several gentoo repos on one machine?
I need to more than one gentoo repo in my computer. So I add to repos.conf: [tm-cusfpv3] auto-sync = yes sync-type = rsync sync-uri = rsync://devsrv.transmode.se/tm-cusfpv3 location = /usr/local/portage/tm-cusfpv3 this did not work as "portageq repositories_configuration /" complains: !!! Section 'tm-cusfpv3' in repos.conf has name different from repository name 'gentoo' set inside repository I figured the name in repos.conf would just override /usr/local/portage/tm-cusfpv3/profiles/repo_name ? Jocke
