[gentoo-dev] [PATCH] linux-info.eclass: enable EAPI 7
versionator is banned in EAPI 7, so switch to either native EAPI 7
version functions or inherit eapi7-ver on EAPI 0-6
---
eclass/linux-info.eclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 77df7a6ad60..96f94e4072a 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -106,7 +106,8 @@
# KBUILD_OUTPUT is used. This should be used for referencing .config.
# And to ensure all the weirdness with crosscompile
-inherit toolchain-funcs versionator
+inherit toolchain-funcs
+[[ ${EAPI:-0} == [0123456] ]] && inherit eapi7-ver
EXPORT_FUNCTIONS pkg_setup
@@ -634,9 +635,9 @@ get_running_version() {
# This handles a variety of weird kernel versions. Make sure
to update
# tests/linux-info_get_running_version.sh if you want to change
this.
local kv_full=${KV_FULL//[-+_]*}
- KV_MAJOR=$(get_version_component_range 1 ${kv_full})
- KV_MINOR=$(get_version_component_range 2 ${kv_full})
- KV_PATCH=$(get_version_component_range 3 ${kv_full})
+ KV_MAJOR=$(ver_cut 1 ${kv_full})
+ KV_MINOR=$(ver_cut 2 ${kv_full})
+ KV_PATCH=$(ver_cut 3 ${kv_full})
KV_EXTRA="${KV_FULL#${KV_MAJOR}.${KV_MINOR}${KV_PATCH:+.${KV_PATCH}}}"
: ${KV_PATCH:=0}
fi
--
2.18.0
[gentoo-dev] [PATCH] linux-info.eclass: enable EAPI 7
versionator is banned in EAPI 7, so switch to either native EAPI 7
version functions or inherit eapi7-ver on EAPI 0-6
---
eclass/linux-info.eclass | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 77df7a6ad60..96f94e4072a 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -106,7 +106,8 @@
# KBUILD_OUTPUT is used. This should be used for referencing .config.
# And to ensure all the weirdness with crosscompile
-inherit toolchain-funcs versionator
+inherit toolchain-funcs
+[[ ${EAPI:-0} == [0123456] ]] && inherit eapi7-ver
EXPORT_FUNCTIONS pkg_setup
@@ -634,9 +635,9 @@ get_running_version() {
# This handles a variety of weird kernel versions. Make sure
to update
# tests/linux-info_get_running_version.sh if you want to change
this.
local kv_full=${KV_FULL//[-+_]*}
- KV_MAJOR=$(get_version_component_range 1 ${kv_full})
- KV_MINOR=$(get_version_component_range 2 ${kv_full})
- KV_PATCH=$(get_version_component_range 3 ${kv_full})
+ KV_MAJOR=$(ver_cut 1 ${kv_full})
+ KV_MINOR=$(ver_cut 2 ${kv_full})
+ KV_PATCH=$(ver_cut 3 ${kv_full})
KV_EXTRA="${KV_FULL#${KV_MAJOR}.${KV_MINOR}${KV_PATCH:+.${KV_PATCH}}}"
: ${KV_PATCH:=0}
fi
--
2.18.0
[gentoo-dev] [PATCH] meson.eclass: add EAPI 7 support
---
It seems this is all that is needed, and all the eclasses inherited by
it are supported for EAPI 7. I could be missing something, so please do
comment if I have.
eclass/meson.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index f2202a04593..7c5b3da6ffa 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -34,7 +34,7 @@
# @CODE
case ${EAPI:-0} in
- 6) ;;
+ 6|7) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
@@ -69,7 +69,11 @@ MESON_DEPEND=">=dev-util/meson-0.40.0
# their own DEPEND string.
: ${MESON_AUTO_DEPEND:=yes}
if [[ ${MESON_AUTO_DEPEND} != "no" ]] ; then
- DEPEND=${MESON_DEPEND}
+ if [[ ${EAPI:-0} == [0123456] ]]; then
+ DEPEND=${MESON_DEPEND}
+ else
+ BDEPEND=${MESON_DEPEND}
+ fi
fi
__MESON_AUTO_DEPEND=${MESON_AUTO_DEPEND} # See top of eclass
--
2.18.0
Re: [gentoo-dev] rfc: moving default location of portage tree
On 10/07/18 21:09, William Hubbs wrote: > On Mon, Jul 09, 2018 at 03:54:35PM -0700, Zac Medico wrote: >> On 07/09/2018 03:27 PM, M. J. Everitt wrote: >>> On 09/07/18 23:12, Zac Medico wrote: On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote: > I'd mostly argue any such change should only affect new systems > Yes, changing defaults for existing systems would be annoying. My recommendation is to have catalyst set the new defaults in the stage tarballs. When sys-apps/portage changes its internal defaults, I'd like for the upgrade process to call a tool that generates configuration files when necessary to ensure that the existing paths remain constant. >>> I think it should be possible for RelEng to make a start on catalyst >>> updates - is there anything that would inhibit going ahead with this, >>> potentially? >> No, nothing. Whatever catalyst puts it the default config will become >> our new default. > I would still like to see notice about what the new defaults are and how > to migrate current systems to them. > > > Thanks, > > William > >> -- >> Thanks, >> Zac >> > > I'd like to propose that further to the discussion here on the -dev mailing list, the Council discuss and make a firm proposal on the new default paths, and then RelEng can make the appropriate updates to the catalyst builds. A news item can be compiled, with an appropriate wiki article perhaps on migration strategy (I may volunteer to format such a page with some appropriate guidance). Regards, Michael / veremitz. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
On Mon, Jul 09, 2018 at 03:54:35PM -0700, Zac Medico wrote: > On 07/09/2018 03:27 PM, M. J. Everitt wrote: > > On 09/07/18 23:12, Zac Medico wrote: > >> On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote: > >>> I'd mostly argue any such change should only affect new systems > >>> > >> Yes, changing defaults for existing systems would be annoying. > >> > >> My recommendation is to have catalyst set the new defaults in the stage > >> tarballs. > >> > >> When sys-apps/portage changes its internal defaults, I'd like for the > >> upgrade process to call a tool that generates configuration files when > >> necessary to ensure that the existing paths remain constant. > > I think it should be possible for RelEng to make a start on catalyst > > updates - is there anything that would inhibit going ahead with this, > > potentially? > > No, nothing. Whatever catalyst puts it the default config will become > our new default. I would still like to see notice about what the new defaults are and how to migrate current systems to them. Thanks, William > -- > Thanks, > Zac > signature.asc Description: Digital signature
[gentoo-dev] Last rites: media-sound/neroaac
profiles: Last rite media-sound/neroaac # Jonas Stein (10 Jul 2018) # Package is not maintained, has a broken SRC_URI and # we may not mirror the files. # Removal on (10 Aug 2018) Bug #660750 media-sound/neroaac https://bugs.gentoo.org/660750 -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
[gentoo-dev] Lastrites: guacamole-server and guacamole
# Andreas Schuerch (10 Jul 2018) # Packages have open bugs and mayor component is not working since years # Removal in 30 days. Bug 608540 net-misc/guacamole-server www-apps/guacamole
[gentoo-dev] [PATCH] glep-0001: Small update to reflect current practice.
Drop the requirement that GLEPs must be discussed in forums (in addition to mailing lists), since no GLEPs have been sent there since at least 2011. --- See also the discussion about the previous update of GLEP 1 in 2011: https://archives.gentoo.org/gentoo-dev/message/21796e64595d63f09d64ea1703aa4f2f The intention back then was "not let people pick only the forums". Subsequently, the clause "mailing list and/or forums" was changed to "mailing list and forums", which doesn't follow the intention, though. glep-0001.rst | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/glep-0001.rst b/glep-0001.rst index 310c538..f819a76 100644 --- a/glep-0001.rst +++ b/glep-0001.rst @@ -8,7 +8,7 @@ Type: Informational Status: Active Version: 3 Created: 2003-05-31 -Last-Modified: 2017-10-28 +Last-Modified: 2018-07-10 Post-History: 2003-06-01, 2003-07-02, 2008-01-19, 2008-06-05, 2011-03-09, 2013-12-14, 2017-09-17 Content-Type: text/x-rst @@ -109,12 +109,11 @@ the form of code, patch, or URL to same -- before it can be considered Final. GLEP authors are responsible for collecting community feedback on a GLEP before submitting it for review. A GLEP that has not been discussed on -the mailing lists and the Gentoo Linux forums [#FORUMS]_ will not be -accepted. However, wherever possible, long open-ended discussions on public -mailing lists should be avoided. Strategies to keep the discussions efficient -include setting up a specific forums thread for the topic, having the GLEP -author accept private comments in the early design phases, etc. GLEP authors -should use their discretion here. +the mailing lists will not be accepted. However, wherever possible, long +open-ended discussions on public mailing lists should be avoided. Strategies +to keep the discussions efficient include setting up a specific forums thread +for the topic, having the GLEP author accept private comments in the early +design phases, etc. GLEP authors should use their discretion here. Once the authors have completed a GLEP, they must inform the Gentoo Council [#COUNCIL]_ that it is ready for review by way of the appropriate mailing -- 2.18.0 pgpitF3RrVp6X.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On Tue, Jul 10, 2018 at 10:14 AM kuzetsa wrote: > > Authorship was brought up by: [ Mart Raudsepp ] > > It's germane, and wanting clarity doesn't hurt: Sure, and it was answered by mgorny 17 hours before your post, pointing to the original email which did in fact specifically reference the committer field. Improving the use of the author field in general is a great topic, just not the topic of this thread. -- Rich
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 07/10/2018 09:44 AM, Rich Freeman wrote:
> On Tue, Jul 10, 2018 at 9:38 AM kuzetsa wrote:
>>
>> I think authorship is a good point / distinction, Mart.
>>
>> Authorship was never shown in dev-timeline for addresses
>> which aren't @gentoo.org anyway. That's a separate issue,
>> so this policy change shouldn't affect proxy-maint?
>>
>
> Might I suggest bringing authorship issues into a separate thread? It
> really seems like a completely separate issue. IMO devs who are
> authors but not committers should probably also use their @g.o
> addresses, though it is a little less critical there. We're talking
> about the committer here, and the committer will always be a Gentoo
> dev for these repos, and I don't see any reason that we shouldn't have
> a matching email address between that and LDAP. The alternative would
> be to have some other key, and that just seems overly complex.
>
Authorship was brought up by: [ Mart Raudsepp ]
It's germane, and wanting clarity doesn't hurt:
... as quoted here:
On 07/09/2018 06:29 AM, Mart Raudsepp wrote:
> As long as that doesn't imply authorship, which seems to be as planned
> (for committer field only, as you said). Hopefully it's easy for people
> to set it up so that it uses gentoo address for committer and something
> else for author, albeit I don't see any config for it, but should be
> able to at least go via a script that uses the appropriate env vars.
~{prune}~
> Mart
>
^ As I think Mart may have been asking:
(or maybe just a related concern)
To avoid mistakes and confusion, it should be stated
unambiguously if //only// the commit field should be
modified (if not already a @gentoo.org address), and
the author field (in particular, commits authored by
persons not in LDAP / without @gentoo.org addresses)
ought to be left as-is, or if the intent is to imply
that both fields need to be @gentoo.org address.
Stating clearly that the author field should be left
as-is (if it's set to a n...@gentoo.org address) is
probably enough here.
I think the confusion may have partly been the
subject line for this thread, vaguely worded:
["... use their @gentoo.org address ..."],
which may accidentally imply that committers need to
apply @gentoo.org in all fields, not just committer.
the word "only" was in a few places, but if skimming
the thread it may not have been obvious. ::shrug::
Also, I agree:
dev-timeline tool not recognizing authorship ought to
be an issue for a separate thread, as this one seems
to be about the metadata in the commits themselves.
--kuza
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On Tue, Jul 10, 2018 at 9:38 AM kuzetsa wrote: > > I think authorship is a good point / distinction, Mart. > > Authorship was never shown in dev-timeline for addresses > which aren't @gentoo.org anyway. That's a separate issue, > so this policy change shouldn't affect proxy-maint? > Might I suggest bringing authorship issues into a separate thread? It really seems like a completely separate issue. IMO devs who are authors but not committers should probably also use their @g.o addresses, though it is a little less critical there. We're talking about the committer here, and the committer will always be a Gentoo dev for these repos, and I don't see any reason that we shouldn't have a matching email address between that and LDAP. The alternative would be to have some other key, and that just seems overly complex. -- Rich
Re: [gentoo-dev] [RFC] Requiring gentoo.git committers to use their @gentoo.org address
On 07/09/2018 06:29 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 09.07.2018 kell 10:40, kirjutas Michał Górny:
>> Hi,
>>
>> We currently don't enforce any particular standard for e-mail
>> addresses
>> for developers committing to gentoo.git. FWICS, the majority of
>> developers is using their @gentoo.org e-mail addresses. However, a
~{prune}~
>> Is anyone opposed to that? Does anyone know of a valid reason to use
>> n...@gentoo.org address when committing?
> As long as that doesn't imply authorship, which seems to be as planned
> (for committer field only, as you said). Hopefully it's easy for people
> to set it up so that it uses gentoo address for committer and something
> else for author, albeit I don't see any config for it, but should be
> able to at least go via a script that uses the appropriate env vars.
~{prune}~
> The only issue I see is that of slight complications on handling the
> different addresses for author and commit, that's all that comes to
> mind.
>
>
> Mart
>
I think authorship is a good point / distinction, Mart.
Authorship was never shown in dev-timeline for addresses
which aren't @gentoo.org anyway. That's a separate issue,
so this policy change shouldn't affect proxy-maint?
(There are a few authors who are proxy-maintaining)
--kuza
Re: [gentoo-dev] rfc: moving default location of portage tree
> On Tue, 10 Jul 2018, Ulrich Mueller wrote: > On Mon, 9 Jul 2018, William Hubbs wrote: >> Agreed, /var/db I guess is a Gentoo invention of some kind? > No, it exists in FreeBSD too. As was pointed out to me, it exists in all three BSD variants [1,2,3]. Its purpose there is for "miscellaneous automatically generated system-specific database files". Ulrich [1] https://www.freebsd.org/cgi/man.cgi?hier%287%29 [2] http://netbsd.gw.com/cgi-bin/man-cgi?hier+7+NetBSD-current [3] https://man.openbsd.org/hier pgpb0oOLPJ7DM.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] GitSync: support sync-depth (bug 552814)
Support sync-depth for shallow sync, using git reset --merge just
like in the earlier implementation that was reverted in commit
ab840ac982d3c8b676b89f6bedd14e85dd06870f. Also, use git gc --auto
in order to trigger periodic housekeeping and hopefully avoid
errors from automatic git gc calls as reported in bug 599008.
The default sync-depth is unlimited, which means that default
behavior remains unchanged (unlike the previous implementation that
was reverted).
Bug: https://bugs.gentoo.org/552814
Bug: https://bugs.gentoo.org/599008
---
man/portage.5 | 3 ++-
pym/portage/repository/config.py| 4
pym/portage/sync/modules/git/git.py | 26 +-
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/man/portage.5 b/man/portage.5
index acc80791be..a57531d444 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -985,7 +985,8 @@ overlay filesystems.
Specifies CVS repository.
.TP
.B sync\-depth
-This is a deprecated alias for the \fBclone\-depth\fR option.
+Specifies sync depth to use for DVCS repositories. If set to 0, the
+depth is unlimited. Defaults to 0.
.TP
.B sync\-git\-clone\-env
Set environment variables for git when cloning repository (git clone).
diff --git a/pym/portage/repository/config.py b/pym/portage/repository/config.py
index ad7ae9d180..bf2b6dd03c 100644
--- a/pym/portage/repository/config.py
+++ b/pym/portage/repository/config.py
@@ -179,10 +179,6 @@ class RepoConfig(object):
self.clone_depth = repo_opts.get('clone-depth')
self.sync_depth = repo_opts.get('sync-depth')
- if self.sync_depth is not None:
- warnings.warn(_("repos.conf: sync-depth is deprecated,"
- " use clone-depth instead"))
-
self.sync_hooks_only_on_change = repo_opts.get(
'sync-hooks-only-on-change', 'false').lower() == 'true'
diff --git a/pym/portage/sync/modules/git/git.py
b/pym/portage/sync/modules/git/git.py
index 68f8bd1fb9..f99867a34e 100644
--- a/pym/portage/sync/modules/git/git.py
+++ b/pym/portage/sync/modules/git/git.py
@@ -137,6 +137,24 @@ class GitSync(NewBase):
writemsg_level(msg + "\n", level=logging.ERROR,
noiselevel=-1)
return (e.returncode, False)
+ shallow = self.repo.sync_depth is not None and
self.repo.sync_depth != 0
+ if shallow:
+ git_cmd_opts += " --depth %d" % self.repo.sync_depth
+
+ # For shallow fetch, unreachable objects must be pruned
+ # manually, since otherwise automatic git gc calls will
+ # eventually warn about them (see bug 599008).
+ gc_cmd = ['git', 'gc', '--auto']
+ if quiet:
+ gc_cmd.append('--quiet')
+ exitcode = subprocess.call(gc_cmd,
+ cwd=portage._unicode_encode(self.repo.location))
+ if exitcode != os.EX_OK:
+ msg = "!!! git gc error in %s" %
self.repo.location
+ self.logger(self.xterm_titles, msg)
+ writemsg_level(msg + "\n", level=logging.ERROR,
noiselevel=-1)
+ return (exitcode, False)
+
git_cmd = "%s fetch %s%s" % (self.bin_command,
remote_branch.partition('/')[0], git_cmd_opts)
@@ -159,7 +177,13 @@ class GitSync(NewBase):
if not self.verify_head(revision='refs/remotes/%s' %
remote_branch):
return (1, False)
- merge_cmd = [self.bin_command, 'merge', 'refs/remotes/%s' %
remote_branch]
+ if shallow:
+ # Since the default merge strategy typically fails when
+ # the depth is not unlimited, `git reset --merge`.
+ merge_cmd = [self.bin_command, 'reset', '--merge']
+ else:
+ merge_cmd = [self.bin_command, 'merge']
+ merge_cmd.append('refs/remotes/%s' % remote_branch)
if quiet:
merge_cmd.append('--quiet')
exitcode = subprocess.call(merge_cmd,
--
2.13.6
