[gentoo-dev] Depending on clang as a compiler
Hi! First of all, I'm not a Gentoo dev but a proud Gentoo user and also a developer of a piece of software that's present in portage tree under app-lc/ category, and Gentoo is kind of tier-1 distro for me. I'm currently considering using C++14 in my project, particularly features that aren't supported by gcc 4.8 and are barely supported by 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. Thus I wonder how bad is actually depending on recent clang in ebuilds? I ask because depending on the outcome of the discussion I'll either start playing around with C++14 in, say, only new modules that aren't present in the tree yet (most likely I guess) but are good candidates for inclusion, or postpone that until gcc like 4.10 is released (less likely but most safe I guess), or happily start using all new nifty C++14 features in the existing codebase as well (extremely unlikely :)). [1] http://gcc.gnu.org/projects/cxx1y.html [2] http://clang.llvm.org/cxx_status.html under C++1y section -- Georg Rudoy
Re: [gentoo-dev] Depending on clang as a compiler
On Wed, Feb 26, 2014 at 9:26 AM, Georg Rudoy 0xd34df...@gmail.com wrote: I'm currently considering using C++14 in my project, particularly features that aren't supported by gcc 4.8 and are barely supported by 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. Thus I wonder how bad is actually depending on recent clang in ebuilds? If you want to do that, it's not a problem with me. That said, I probably wouldn't install packages that wanted to pull in a whole different toolchain unless I wanted them really badly (but on machines where I already have clang installed, I might not even notice). I'd say there's value in staying close to where the community's at, if you actually want your software to be used. If you don't care that much about your software being used by other people, nobody can stop you. Cheers, Dirkjan
Re: [gentoo-dev] Depending on clang as a compiler
Dnia 2014-02-26, o godz. 12:26:06 Georg Rudoy 0xd34df...@gmail.com napisał(a): I'm currently considering using C++14 in my project, particularly features that aren't supported by gcc 4.8 and are barely supported by 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. Thus I wonder how bad is actually depending on recent clang in ebuilds? Well, you should note that DEPENDing on sys-devel/clang is currently implemented as USE=clang in sys-devel/llvm (please don't depend on that directly, we will split it back ASAP). So if someone doesn't have clang enabled, he'd hit portage telling him to enable the flag. Good news is that you won't take people by surprise, i.e. they will notice that you're forcing them to use clang. Bad news is that it won't be as transparent as you wished it was. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Depending on clang as a compiler
2014-02-26 12:35 GMT+04:00 Dirkjan Ochtman d...@gentoo.org: On Wed, Feb 26, 2014 at 9:26 AM, Georg Rudoy 0xd34df...@gmail.com wrote: I'm currently considering using C++14 in my project, particularly features that aren't supported by gcc 4.8 and are barely supported by 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. Thus I wonder how bad is actually depending on recent clang in ebuilds? If you want to do that, it's not a problem with me. That said, I probably wouldn't install packages that wanted to pull in a whole different toolchain unless I wanted them really badly (but on machines where I already have clang installed, I might not even notice). I'd say there's value in staying close to where the community's at, if you actually want your software to be used. If you don't care that much about your software being used by other people, nobody can stop you. I thought about some policy-related problems. Good if there aren't any. Thanks for the opinion. Depending strictly on clang is more like a temporary measure until gcc catches up, which I hope will happen fast enough. In this case I'll also probably stick with just introducing the dependency in newer, probably even unpackaged modules so everyone will be able to use what's already considered to be somewhat stable and solid part of the app with standard gcc. -- Georg Rudoy
Re: [gentoo-dev] Depending on clang as a compiler
2014-02-26 12:52 GMT+04:00 Michał Górny mgo...@gentoo.org: Dnia 2014-02-26, o godz. 12:26:06 Georg Rudoy 0xd34df...@gmail.com napisał(a): I'm currently considering using C++14 in my project, particularly features that aren't supported by gcc 4.8 and are barely supported by 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. Thus I wonder how bad is actually depending on recent clang in ebuilds? Well, you should note that DEPENDing on sys-devel/clang is currently implemented as USE=clang in sys-devel/llvm (please don't depend on that directly, we will split it back ASAP). So if someone doesn't have clang enabled, he'd hit portage telling him to enable the flag. And what about setting CMAKE_CXX_COMPILER in src_configure() (or where it should be overriden)? I don't think it's a good idea to forcefully set the compiler binary in CMakeLists.txt itself, is it better done in ebuild? -- Georg Rudoy
Re: [gentoo-dev] Depending on clang as a compiler
Dnia 2014-02-26, o godz. 12:56:30 Georg Rudoy 0xd34df...@gmail.com napisał(a): 2014-02-26 12:52 GMT+04:00 Michał Górny mgo...@gentoo.org: Dnia 2014-02-26, o godz. 12:26:06 Georg Rudoy 0xd34df...@gmail.com napisał(a): I'm currently considering using C++14 in my project, particularly features that aren't supported by gcc 4.8 and are barely supported by 4.9 [1], but the standard is already fully supported by clang 3.4 [2]. Thus I wonder how bad is actually depending on recent clang in ebuilds? Well, you should note that DEPENDing on sys-devel/clang is currently implemented as USE=clang in sys-devel/llvm (please don't depend on that directly, we will split it back ASAP). So if someone doesn't have clang enabled, he'd hit portage telling him to enable the flag. And what about setting CMAKE_CXX_COMPILER in src_configure() (or where it should be overriden)? I don't think it's a good idea to forcefully set the compiler binary in CMakeLists.txt itself, is it better done in ebuild? I don't know CMake well but I think it's enough to set CXX before calling cmake-utils_src_configure(). You gotta know the details better. And yes, it's better done in ebuild, it will also make it easier to support new enough gcc. You may add some checks for necessary features in CMake though, and fail explicitly when the compiler doesn't provide them. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-news: 2014: 2014-01-31-catalyst-head-changes.en.txt is missing it's gpg armour
I'm confused, since when are news items signed? -A On Tue, Feb 25, 2014 at 6:05 AM, Ulrich Mueller u...@gentoo.org wrote: On Tue, 25 Feb 2014, Samuli Suominen wrote: 2014/2014-01-31-catalyst-head-changes.en.txt is missing it's gpg armour: https://wiki.gentoo.org/wiki/GLEP:42#News_Item_Files Maybe the git update hook could check if the armour is present? Ulrich
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Hi, I like your (Alex) new proposal, but I have the following annotations: As of sys-fs/udev-210, the options CONFIG_FHANDLE and CONFIG_NET are now required in the kernel. A warning will be issued if they are missing when you upgrade. See the package's README in /usr/share/doc/udev-210/ for more optional kernel options. Isn't that a chicken/egg problem? I see the NEWS when I have sys-fs/udev-210 installed. The NEWS tells me to read the README in /usr/share/doc/udev-210/ for more options. But until I upgraded I cannot access the README.. So if these options are important, make them available in the Wiki or somewhere else and link to that resource. If these options are not important, remove the sentences because it doesn't add any usable information to that NEWS item. Overriding the 80-net-name-slot.rules in /etc/udev/rules.d/ no longer works since upstream renamed the file to /lib/udev/rules.d/80-net-setup-link.rules. All I have to do is changing the name from 80-net-name-slot.rules to 80-net-setup-link.rules, e.g. adjusting the name because upstream renamed... not? So a text like The most reliable way of disabling the new network interface scheme is still the kernel parameter net.ifnames=0. If you are using the net-name-slot.rules approach make sure you adapt the new naming before you restart because upstream renamed the 80-net-name-slot.rules to 80-net-setup-link.rules. sounds better for me instead of saying overriding no longer works and to clarify later that this is still possible ;) I don't see a need for mentioning that the actual configuration is located in /lib/systemd/network/... in the NEWS item. -Thomas
Re: [gentoo-dev] gentoo-news: 2014: 2014-01-31-catalyst-head-changes.en.txt is missing it's gpg armour
On 25/02/14 16:05, Ulrich Mueller wrote: On Tue, 25 Feb 2014, Samuli Suominen wrote: 2014/2014-01-31-catalyst-head-changes.en.txt is missing it's gpg armour: https://wiki.gentoo.org/wiki/GLEP:42#News_Item_Files Maybe the git update hook could check if the armour is present? Ulrich Perhaps, since despite the GLEP always requiring it, it's only randomly used: ssuominen@null ~/Documents/gentoo-news $ find ./ -name '*.txt'|wc -l 54 ssuominen@null ~/Documents/gentoo-news $ find ./ -name '*.asc'|wc -l 49 ??? - Samuli
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 02/25/2014 8:24 AM, Samuli Suominen wrote: If someone is willing to change his device manager because a file or directory name is 'systemd', then by all means, sounds very logical system maintaince, not. - Samuli There is actually a kind of psychological effect on doing it this way, one to which I have to give credit to upstream for employing (whether they intended to or not). By having udev put things into directories that would also be used by systemd, if it was installed, it reminds people of the inevitability that one day, systemd will be the only viable init choice to boot a Linux system and make the userland functional. This is why you're witnessing some people reacting by switching out their device manager over a silly directory name. That's the psychology working. Debian's recent vote on the default init system in jessie is just further affirmation that, sysvinit is deprecated (last release was almost 4 years ago, too). Most future Linux systems that are based off of mainstream distributions will *have* to use systemd+udev in order to achieve maximum functionality. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
Joshua Kinard wrote: Most future Linux systems that are based off of mainstream distributions will *have* to use systemd+udev in order to achieve maximum functionality. Certainly! And I think the reason systemd gains traction is that such maximum functionality can easily include various things which aren't available and more difficult with other choices. That doesn't mean that sysvinit doesn't do fine what it has always done. It just means that many have a changed mindset and want something else. //Peter
[gentoo-dev] [PATCHES git-r3] Clean up and different clone type support
Hello, all. I will submit a long serie of patches in reply to this mail. They add support for EGIT_CLONE_TYPE and also fix some bugs I've found during the testing. I've confirmed that the eclass works properly with git-1.8.3.2 (the current stable). This version is required for '--unshallow'. Quick summary: #1 just clarifies docs in order to get better consistency. #2 improves the checkout mode to be faster and avoids copying the whole repository to the checkout dir. It also makes the checkout future-proof for shallow clones. #3 fixes support for HEAD != master, that is repositories where the default branch is not master ;). #4 adds support for using local mirror for git repos. This could be used to reduce network use on local networks with many Gentoo machines using the same live ebuilds :). #5-#9 actually add all the EGIT_CLONE_TYPE magic. #10 fixes non-fast-forward updates :). Please review, and preferably reply to each of the patches separately. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] gentoo-news: 2014: 2014-01-31-catalyst-head-changes.en.txt is missing it's gpg armour
On Wed, 26 Feb 2014, Samuli Suominen wrote: Perhaps, since despite the GLEP always requiring it, it's only randomly used: ssuominen@null ~/Documents/gentoo-news $ find ./ -name '*.txt'|wc -l 54 ssuominen@null ~/Documents/gentoo-news $ find ./ -name '*.asc'|wc -l 49 ??? Similar to our signed Manifests, it's not verified at the moment. Also I wonder how this will fit into the tree-signing concept of GLEP 57 (and following). Ulrich pgp280JozCdK3.pgp Description: PGP signature
[gentoo-dev] [PATCH git-r3 01/10] Clarify that ebuilds are not supposed to set EGIT3_STORE_DIR.
---
eclass/git-r3.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index d726cee..c00b3a0 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -36,6 +36,9 @@ fi
# @DESCRIPTION:
# Storage directory for git sources.
#
+# This is intended to be set by user in make.conf. Ebuilds must not set
+# it.
+#
# EGIT3_STORE_DIR=${DISTDIR}/git3-src
# @ECLASS-VARIABLE: EGIT_REPO_URI
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 02/10] Replace 'git fetch' checkout with more efficient pseudo-shared fetch.
'git fetch' uses git transport to compress and transfer all the commits
even though they're on a local machine -- both very slow and space
consuming.
Setting 'alternates' before fetching solves the issue partially since
the commits no longer need to be transferred. The checkout is still slow
since git needs to recheck all of them.
Instead, just set 'alternates' and copy the refs manually. This is
pretty much what 'git clone --shared' does. And we can't use 'git clone'
because it refuses non-empty destinations.
This also makes it possible to use the same checkout method for shallow
clones with git-1.9 (git-1.9 finally allows clones and fetches using
shallow repos).
---
eclass/git-r3.eclass | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index c00b3a0..892ed07 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -458,13 +458,14 @@ git-r3_checkout() {
# non-empty directories.
git init --quiet || die
- set -- git fetch --update-head-ok ${orig_repo} \
- refs/heads/*:refs/heads/* \
- refs/tags/*:refs/tags/* \
- refs/notes/*:refs/notes/*
-
- echo ${@} 2
- ${@} || die git fetch into checkout dir failed
+ # setup 'alternates' to avoid copying objects
+ echo ${orig_repo}/objects
${GIT_DIR}/objects/info/alternates || die
+ # now copy the refs
+ # [htn]* safely catches heads, tags, notes without complaining
+ # on non-existing ones, and omits internal 'git-r3' ref
+ cp -R ${orig_repo}/refs/[htn]* ${GIT_DIR}/refs/ || die
+
+ # (no need to copy HEAD, we will set it via checkout)
set -- git checkout --quiet
if [[ ${remote_ref} ]]; then
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 03/10] Properly support non-master default branch.
Long story short, our HEAD was set by 'git init' and left at the default
'master'. So whenever we hit a repository that used a different default
branch, we either fetched the wrong branch or failed completely.
Using 'git clone' would fix the issue only temporarily since it does not
provide a way to follow changes of the 'HEAD' branch. git has some code
to obtain symbolic 'HEAD' using some of the transports but it seems not
to be part of the command-line API.
So instead, we do pretty much the same as 'git clone' does when it is
unable to get the symbolic HEAD from remote. We find the branch that is
on the same commit as HEAD, preferably 'master'.
As a note: we need to fetch into a custom ref since git does not allow
fetching to 'HEAD' directly. In fact, 'git fetch HEAD:HEAD' only creates
a branch named 'HEAD', and 'git fetch --prune HEAD:HEAD' creates and
removes it ;).
---
eclass/git-r3.eclass | 42 ++
1 file changed, 42 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 892ed07..7c78b66 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -270,6 +270,42 @@ _git-r3_is_local_repo() {
[[ ${uri} == file://* || ${uri} == /* ]]
}
+# @FUNCTION: _git-r3_update_head
+# @USAGE: remote-head-ref
+# @INTERNAL
+# @DESCRIPTION:
+# Given a ref to which remote HEAD was fetched, try to match
+# a local branch and update symbolic HEAD appropriately.
+_git-r3_update_head()
+{
+ debug-print-function ${FUNCNAME} $@
+
+ local head_ref=${1}
+ local head_hash=$(git rev-parse --verify ${1} || die)
+ local matching_ref
+
+ # TODO: some transports support peeking at symbolic remote refs
+ # find a way to use that rather than guessing
+
+ # (based on guess_remote_head() in git-1.9.0/remote.c)
+ local h ref
+ while read h ref; do
+ # look for matching head
+ if [[ ${h} == ${head_hash} ]]; then
+ # either take the first matching ref, or master if it
is there
+ if [[ ! ${matching_ref} || ${ref} == refs/heads/master
]]; then
+ matching_ref=${ref}
+ fi
+ fi
+ done (git show-ref --heads || die)
+
+ if [[ ! ${matching_ref} ]]; then
+ die Unable to find a matching branch for remote HEAD
(${head_hash})
+ fi
+
+ git symbolic-ref HEAD ${matching_ref} || die
+}
+
# @FUNCTION: git-r3_fetch
# @USAGE: [repo-uri [remote-ref [local-id]]]
# @DESCRIPTION:
@@ -335,11 +371,17 @@ git-r3_fetch() {
refs/tags/*:refs/tags/*
# notes in case something needs them
refs/notes/*:refs/notes/*
+ # and HEAD in case we need the default branch
+ # (we keep it in refs/git-r3 since otherwise --prune
interferes)
+ HEAD:refs/git-r3/HEAD
)
set -- ${fetch_command[@]}
echo ${@} 2
if ${@}; then
+ # find remote HEAD and update our HEAD properly
+ _git-r3_update_head refs/git-r3/HEAD
+
# now let's see what the user wants from us
local full_remote_ref=$(
git rev-parse --verify --symbolic-full-name
${remote_ref}
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 04/10] Support EGIT_MIRROR_URI to specify local git mirror.
When multiple Gentoo machines are used on the local network, and they
use the same git ebuilds it may be useful to set a local mirror :).
The idea is quite simple -- you set the host to EGIT_CLONE_TYPE=mirror,
and then share the EGIT3_STORE_DIR directory. Then you set
EGIT_MIRROR_URI on the remaining hosts and they try to fetch from your
local mirror first.
---
eclass/git-r3.eclass | 22 ++
1 file changed, 22 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 7c78b66..8462fba 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -41,6 +41,20 @@ fi
#
# EGIT3_STORE_DIR=${DISTDIR}/git3-src
+# @ECLASS-VARIABLE: EGIT_MIRROR_URI
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# 'Top' URI to a local git mirror. If specified, the eclass will try
+# to fetch from the local mirror instead of using the remote repository.
+#
+# The mirror needs to follow EGIT3_STORE_DIR structure. The directory
+# created by eclass can be used for that purpose.
+#
+# Example:
+# @CODE
+# EGIT_MIRROR_URI=git://mirror.lan/
+# @CODE
+
# @ECLASS-VARIABLE: EGIT_REPO_URI
# @REQUIRED
# @DESCRIPTION:
@@ -358,6 +372,14 @@ git-r3_fetch() {
local -x GIT_DIR
_git-r3_set_gitdir ${repos[0]}
+ # prepend the local mirror if applicable
+ if [[ ${EGIT_MIRROR_URI} ]]; then
+ repos=(
+ ${EGIT_MIRROR_URI%/}/${GIT_DIR##*/}
+ ${repos[@]}
+ )
+ fi
+
# try to fetch from the remote
local r success
for r in ${repos[@]}; do
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 05/10] Introduce EGIT_CLONE_TYPE for future use.
In this commit, it's just 'mirror' explained :).
---
eclass/git-r3.eclass | 21 +
1 file changed, 21 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 8462fba..9c8508a 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -32,6 +32,19 @@ if [[ ! ${_INHERITED_BY_GIT_2} ]]; then
DEPEND=dev-vcs/git
fi
+# @ECLASS-VARIABLE: EGIT_CLONE_TYPE
+# @DESCRIPTION:
+# Type of clone that should be used against the remote repository.
+# This can be either of: 'mirror'.
+#
+# The 'mirror' type clones all remote branches and tags with complete
+# history and all notes. EGIT_COMMIT can specify any commit hash.
+# Upstream-removed branches and tags are purged from the local clone
+# while fetching. This mode is suitable for cloning the local copy
+# for development or hosting a local git mirror. However, clones
+# of repositories with large diverged branches may quickly grow large.
+: ${EGIT_CLONE_TYPE:=mirror}
+
# @ECLASS-VARIABLE: EGIT3_STORE_DIR
# @DESCRIPTION:
# Storage directory for git sources.
@@ -107,6 +120,14 @@ fi
_git-r3_env_setup() {
debug-print-function ${FUNCNAME} $@
+ # check the clone type
+ case ${EGIT_CLONE_TYPE} in
+ mirror)
+ ;;
+ *)
+ die Invalid EGIT_CLONE_TYPE=${EGIT_CLONE_TYPE}
+ esac
+
local esc_pn livevar
esc_pn=${PN//[-+]/_}
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 06/10] Support single-branch mode.
This is pretty similar to what git-2.eclass did by default. Instead of
fetching all the branches, we only fetch what user told us to. Good news
is that it's sometimes a space-saver. Bad news is that it's harder to
deal with.
One of the problems is that EGIT_COMMIT can either specify a tag
or a hash (possibly an abbreviated one). And while we can fetch tags
(since they are refs), git can't fetch an arbitrary commit by hash. Plus
there's the special HEAD case to care about.
So first, we need to figure out what we're going to fetch actually. If
it's a commit hash, we need to fetch the (supposedly) requested branch
instead and hope the commit is in it. And if we're fetching HEAD, we
need to use the special ref as explained before.
Then, we need to update 'HEAD' properly. We could supposedly try to
figure out what HEAD is before fetching but since we support fetch
failures and repository fallback, it's easier to do so after checking
that the repo is up.
It's pretty much the opposite we do in 'mirror' mode. We fetch HEAD into
dedicated ref, then use 'git ls-remote' to figure out what branch we
actually fetched. Then we move the commits into proper branch and update
HEAD.
---
eclass/git-r3.eclass | 118 ---
1 file changed, 93 insertions(+), 25 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 9c8508a..8b7d75d 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -35,7 +35,7 @@ fi
# @ECLASS-VARIABLE: EGIT_CLONE_TYPE
# @DESCRIPTION:
# Type of clone that should be used against the remote repository.
-# This can be either of: 'mirror'.
+# This can be either of: 'mirror', 'single'.
#
# The 'mirror' type clones all remote branches and tags with complete
# history and all notes. EGIT_COMMIT can specify any commit hash.
@@ -43,7 +43,14 @@ fi
# while fetching. This mode is suitable for cloning the local copy
# for development or hosting a local git mirror. However, clones
# of repositories with large diverged branches may quickly grow large.
-: ${EGIT_CLONE_TYPE:=mirror}
+#
+# The 'single' type clones only the requested branch or tag. Tags
+# referencing commits throughout the branch history are fetched as well,
+# and all notes. EGIT_COMMIT can safely specify only hashes
+# in the current branch. No purging of old references is done (if you
+# often switch branches, you may need to remove stale branches
+# yourself). This mode is suitable for general use.
+: ${EGIT_CLONE_TYPE:=single}
# @ECLASS-VARIABLE: EGIT3_STORE_DIR
# @DESCRIPTION:
@@ -122,7 +129,7 @@ _git-r3_env_setup() {
# check the clone type
case ${EGIT_CLONE_TYPE} in
- mirror)
+ mirror|single)
;;
*)
die Invalid EGIT_CLONE_TYPE=${EGIT_CLONE_TYPE}
@@ -305,14 +312,14 @@ _git-r3_is_local_repo() {
[[ ${uri} == file://* || ${uri} == /* ]]
}
-# @FUNCTION: _git-r3_update_head
-# @USAGE: remote-head-ref
+# @FUNCTION: _git-r3_find_head
+# @USAGE: head-ref
# @INTERNAL
# @DESCRIPTION:
-# Given a ref to which remote HEAD was fetched, try to match
-# a local branch and update symbolic HEAD appropriately.
-_git-r3_update_head()
-{
+# Given a ref to which remote HEAD was fetched, try to find
+# a branch matching the commit. Expects 'git show-ref'
+# or 'git ls-remote' output on stdin.
+_git-r3_find_head() {
debug-print-function ${FUNCNAME} $@
local head_ref=${1}
@@ -332,13 +339,13 @@ _git-r3_update_head()
matching_ref=${ref}
fi
fi
- done (git show-ref --heads || die)
+ done
if [[ ! ${matching_ref} ]]; then
die Unable to find a matching branch for remote HEAD
(${head_hash})
fi
- git symbolic-ref HEAD ${matching_ref} || die
+ echo ${matching_ref}
}
# @FUNCTION: git-r3_fetch
@@ -406,24 +413,85 @@ git-r3_fetch() {
for r in ${repos[@]}; do
einfo Fetching ${r} ...
- local fetch_command=(
- git fetch --prune ${r}
- # mirror the remote branches as local branches
- refs/heads/*:refs/heads/*
- # pull tags explicitly in order to prune them properly
- refs/tags/*:refs/tags/*
- # notes in case something needs them
- refs/notes/*:refs/notes/*
- # and HEAD in case we need the default branch
- # (we keep it in refs/git-r3 since otherwise --prune
interferes)
- HEAD:refs/git-r3/HEAD
- )
+ local fetch_command=( git fetch ${r} )
+
+ if [[ ${EGIT_CLONE_TYPE} == mirror ]]; then
+ fetch_command+=(
+ --prune
+ # mirror the remote branches as local
[gentoo-dev] [PATCH git-r3 07/10] Support shallow clones.
This one's pretty similar to what we had before though a bit simpler.
For one, we don't have the 'smart fetching' anymore since it was complex
and unsafe.
Implementation-wise 'shallow' mode differs only when starting a new
branch. In that case, '--depth 1' is used to avoid fetching earlier
commits. Further updates are done through plain 'git fetch'.
So, if you enable shallow mode after cloning a repository in 'single'
mode, nothing will actually change :). However, if you switch branch
the repository will become partially 'shallow'.
This also comes with --unshallow support that requires =git-1.8.2.1.
When 'single' or 'mirror' mode is requested, and the repository is
shallow, it guarantees that at least the requested branch is
unshallowed and fully useful.
---
eclass/git-r3.eclass | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 8b7d75d..c9c2da5 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -29,13 +29,13 @@ EXPORT_FUNCTIONS src_unpack
if [[ ! ${_GIT_R3} ]]; then
if [[ ! ${_INHERITED_BY_GIT_2} ]]; then
- DEPEND=dev-vcs/git
+ DEPEND==dev-vcs/git-1.8.2.1
fi
# @ECLASS-VARIABLE: EGIT_CLONE_TYPE
# @DESCRIPTION:
# Type of clone that should be used against the remote repository.
-# This can be either of: 'mirror', 'single'.
+# This can be either of: 'mirror', 'single', 'shallow'.
#
# The 'mirror' type clones all remote branches and tags with complete
# history and all notes. EGIT_COMMIT can specify any commit hash.
@@ -50,6 +50,12 @@ fi
# in the current branch. No purging of old references is done (if you
# often switch branches, you may need to remove stale branches
# yourself). This mode is suitable for general use.
+#
+# The 'shallow' type clones only the newest commit on requested branch
+# or tag. EGIT_COMMIT can only specify tags, and since the history is
+# unavailable calls like 'git describe' will not reference prior tags.
+# No purging of old references is done. This mode is intended mostly for
+# embedded systems with limited disk space.
: ${EGIT_CLONE_TYPE:=single}
# @ECLASS-VARIABLE: EGIT3_STORE_DIR
@@ -129,7 +135,7 @@ _git-r3_env_setup() {
# check the clone type
case ${EGIT_CLONE_TYPE} in
- mirror|single)
+ mirror|single|shallow)
;;
*)
die Invalid EGIT_CLONE_TYPE=${EGIT_CLONE_TYPE}
@@ -249,10 +255,6 @@ _git-r3_set_gitdir() {
fi
addwrite ${EGIT3_STORE_DIR}
- if [[ -e ${GIT_DIR}/shallow ]]; then
- einfo ${GIT_DIR} was a shallow clone, recreating...
- rm -r ${GIT_DIR} || die
- fi
if [[ ! -d ${GIT_DIR} ]]; then
mkdir ${GIT_DIR} || die
git init --bare || die
@@ -428,7 +430,7 @@ git-r3_fetch() {
# (we keep it in refs/git-r3 since otherwise
--prune interferes)
HEAD:refs/git-r3/HEAD
)
- else # single
+ else # single or shallow
local fetch_l fetch_r
if [[ ${remote_ref} == HEAD ]]; then
@@ -468,6 +470,18 @@ git-r3_fetch() {
)
fi
+ if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then
+ # use '--depth 1' when fetching a new branch
+ if [[ ! $(git rev-parse --quiet --verify ${fetch_r})
]]
+ then
+ fetch_command+=( --depth 1 )
+ fi
+ else # non-shallow mode
+ if [[ -f ${GIT_DIR}/shallow ]]; then
+ fetch_command+=( --unshallow )
+ fi
+ fi
+
set -- ${fetch_command[@]}
echo ${@} 2
if ${@}; then
@@ -477,7 +491,7 @@ git-r3_fetch() {
$(_git-r3_find_head refs/git-r3/HEAD \
(git show-ref --heads ||
die)) \
|| die Unable to update HEAD
- else # single
+ else # single or shallow
if [[ ${fetch_l} == HEAD ]]; then
# find out what branch we fetched as
HEAD
local head_branch=$(_git-r3_find_head \
@@ -620,6 +634,10 @@ git-r3_checkout() {
# (no need to copy HEAD, we will set it via checkout)
+ if [[ -f ${orig_repo}/shallow ]]; then
+ cp ${orig_repo}/shallow ${GIT_DIR}/ || die
+ fi
+
set -- git checkout --quiet
if [[ ${remote_ref} ]]; then
set -- ${@} ${remote_ref#refs/heads/}
--
[gentoo-dev] [PATCH git-r3 08/10] Auto-unshallow when fetch-by-commit is requested.
This is required to support submodules transparently since they always
fetch by commit hash.
---
eclass/git-r3.eclass | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index c9c2da5..08b8ebb 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -449,13 +449,18 @@ git-r3_fetch() {
# tag
fetch_l=refs/tags/${remote_ref}
else
- # commit, so we need to fetch the branch
- # and guess where it takes us...
+ # commit
+ # so we need to fetch the branch
if [[ ${branch} ]]; then
fetch_l=${branch}
else
fetch_l=HEAD
fi
+
+ # fetching by commit in shallow mode?
can't do.
+ if [[ ${EGIT_CLONE_TYPE} == shallow ]];
then
+ local EGIT_CLONE_TYPE=single
+ fi
fi
fi
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 10/10] Use '+'-refs to force updates on fetch.
This is required to allow non-forward updates with upstreams that don't
like linear or predictable history.
---
eclass/git-r3.eclass | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 33e66a6..af84ca6 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -452,14 +452,14 @@ git-r3_fetch() {
fetch_command+=(
--prune
# mirror the remote branches as local branches
- refs/heads/*:refs/heads/*
+ +refs/heads/*:refs/heads/*
# pull tags explicitly in order to prune them
properly
- refs/tags/*:refs/tags/*
+ +refs/tags/*:refs/tags/*
# notes in case something needs them
- refs/notes/*:refs/notes/*
+ +refs/notes/*:refs/notes/*
# and HEAD in case we need the default branch
# (we keep it in refs/git-r3 since otherwise
--prune interferes)
- HEAD:refs/git-r3/HEAD
+ +HEAD:refs/git-r3/HEAD
)
else # single or shallow
local fetch_l fetch_r
@@ -502,7 +502,7 @@ git-r3_fetch() {
fi
fetch_command+=(
- ${fetch_l}:${fetch_r}
+ +${fetch_l}:${fetch_r}
)
fi
--
1.8.3.2
[gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
Use-cases include Google Code (that doesn't support shallow clones) and
random build systems that play with history and 'git describe'.
However, please use this sparingly. When the build can't go on without
non-shallow clone, sure. But if it only results in non-pretty versions,
I think users choosing EGIT_CLONE_TYPE=shallow explicitly are ready to
deal with the fallout.
---
eclass/git-r3.eclass | 31 +++
1 file changed, 31 insertions(+)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 08b8ebb..33e66a6 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -58,6 +58,19 @@ fi
# embedded systems with limited disk space.
: ${EGIT_CLONE_TYPE:=single}
+# @ECLASS-VARIABLE: EGIT_MIN_CLONE_TYPE
+# @DESCRIPTION:
+# 'Minimum' clone type supported by the ebuild. Takes same values
+# as EGIT_CLONE_TYPE. When user sets a type that's 'lower' (that is,
+# later on the list) than EGIT_MIN_CLONE_TYPE, the eclass uses
+# EGIT_MIN_CLONE_TYPE instead.
+#
+# A common case is to use 'single' whenever the build system requires
+# access to full branch history or the remote (Google Code) does not
+# support shallow clones. Please use sparingly, and to fix fatal errors
+# rather than 'non-pretty versions'.
+: ${EGIT_MIN_CLONE_TYPE:=shallow}
+
# @ECLASS-VARIABLE: EGIT3_STORE_DIR
# @DESCRIPTION:
# Storage directory for git sources.
@@ -140,6 +153,24 @@ _git-r3_env_setup() {
*)
die Invalid EGIT_CLONE_TYPE=${EGIT_CLONE_TYPE}
esac
+ case ${EGIT_MIN_CLONE_TYPE} in
+ shallow)
+ ;;
+ single)
+ if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then
+ ewarn git-r3: ebuild needs to be cloned in
'single' mode, adjusting
+ EGIT_CLONE_TYPE=single
+ fi
+ ;;
+ mirror)
+ if [[ ${EGIT_CLONE_TYPE} != mirror ]]; then
+ ewarn git-r3: ebuild needs to be cloned in
'mirror' mode, adjusting
+ EGIT_CLONE_TYPE=mirror
+ fi
+ ;;
+ *)
+ die Invalid EGIT_MIN_CLONE_TYPE=${EGIT_MIN_CLONE_TYPE}
+ esac
local esc_pn livevar
esc_pn=${PN//[-+]/_}
--
1.8.3.2
Re: [gentoo-dev] [PATCH git-r3 07/10] Support shallow clones.
On 26/02/14 06:59 AM, Michał Górny wrote: Implementation-wise 'shallow' mode differs only when starting a new branch. In that case, '--depth 1' is used to avoid fetching earlier commits. Further updates are done through plain 'git fetch'. So this fetches all a..b commits. If the package hasn't been updated in a while, wouldn't this be less efficient than a new clone? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH git-r3 07/10] Support shallow clones.
Dnia 2014-02-26, o godz. 07:39:51 Alex Xu alex_y...@yahoo.ca napisał(a): On 26/02/14 06:59 AM, Michał Górny wrote: Implementation-wise 'shallow' mode differs only when starting a new branch. In that case, '--depth 1' is used to avoid fetching earlier commits. Further updates are done through plain 'git fetch'. So this fetches all a..b commits. If the package hasn't been updated in a while, wouldn't this be less efficient than a new clone? In a few rare cases, yes, that could happen. Though we can't really estimate or guess that :). If user suspects that, he can always remove the local repository and let the eclass re-fetch it. I doubt we can do more than that. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On Wed, Feb 26, 2014 at 5:49 AM, Thomas D. whi...@whissi.de wrote: I don't see a need for mentioning that the actual configuration is located in /lib/systemd/network/... in the NEWS item. I think it makes sense to keep this in. If somebody doesn't like the default persistent naming conventions then they'll either want to disable it entirely or modify it. If they want to disable it, the best way to do it is from the kernel parameters. If they want to modify it, the best way is via the config files. Their location isn't at all intuitive to somebody for which this is NEWS, and assuming no work has been done to date it makes more sense to start there than to start hacking away at the rules. Granted, by now any such hacking is long done, but perhaps some who have disabled the rules entirely might now want to consider looking at the config file to see if they can be tamed. Rich
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 02/26/2014 6:44 AM, Peter Stuge wrote:
Joshua Kinard wrote:
Most future Linux systems that are based off of mainstream
distributions will *have* to use systemd+udev in order to
achieve maximum functionality.
Certainly!
Clarification: I wasn't implying that that was entirely a good thing,
however. But that's just my opinion.
And I think the reason systemd gains traction is that such maximum
functionality can easily include various things which aren't available
and more difficult with other choices.
I would argue that it gains traction more by providing APIs that only it can
implement. However efficient or sensible these APIs might be, when major,
upstream software projects use those APIs, you are then left with two
choices: switch to systemd+udev or lose the functionality offered by
${MAJOR_UPSTREAM_PROJECT}. udev was the first example of this, and more
will follow in time.
It just means that many have a changed mindset and want something else.
Many != Everyone, though. But, when you're in the minority, I guess that's
not really relevant. Majority takes all. C'est la vie.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
Re: [gentoo-dev] News draft #2 for the udev-210 upgrade (was: 209 upgrade)
On 25/02/14 15:26, Thomas D. wrote: No, not locations. My choice was not to use systemd. Now a package, sys-fs/udev, turns into systemd-udev... Also: If it wouldn't be possible to keep sys-fs/udev as it was I wouldn't bother that much. But as said, Lars (Polynomial-C) showed us that we don't need to turn sys-fs/udev into systemd-udev... So I am asking why we are doing that for people who don't use systemd? Nobody is doing anything except using upstream names for those files and directories as defined in the Makefile.am I can't speak for everybody, but in general, we are not in the business of randomly changing things when there is no technical reason for it I couldn't care less about the so called 'pro-systemd', or 'anti-systemd' propaganda that's out there. And nobody can influence me with that crap for udev's maintenance. I'm completely neutral to that spat, and even if I weren't, I wouldn't bring that crap over to udev's maintenance. What requires to be done will be done, to keep the functionality up-par with the sys-fs/udev-171 we had as longstanding version before. Only technical arguments have weight.
Re: [gentoo-dev] [PATCHES git-r3] Clean up and different clone type support
Dnia 2014-02-26, o godz. 12:55:20
Michał Górny mgo...@gentoo.org napisał(a):
I will submit a long serie of patches in reply to this mail. They add
support for EGIT_CLONE_TYPE and also fix some bugs I've found during
the testing.
oh, and the complete eclass for easier testing.
--
Best regards,
Michał Górny
# Copyright 1999-2014 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/git-r3.eclass,v 1.26 2014/02/25
13:01:49 mgorny Exp $
# @ECLASS: git-r3.eclass
# @MAINTAINER:
# MichaŠGórny mgo...@gentoo.org
# @BLURB: Eclass for fetching and unpacking git repositories.
# @DESCRIPTION:
# Third generation eclass for easing maitenance of live ebuilds using
# git as remote repository.
case ${EAPI:-0} in
0|1|2|3|4|5)
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
if [[ ! ${_GIT_R3} ]]; then
inherit eutils
fi
EXPORT_FUNCTIONS src_unpack
if [[ ! ${_GIT_R3} ]]; then
if [[ ! ${_INHERITED_BY_GIT_2} ]]; then
DEPEND==dev-vcs/git-1.8.2.1
fi
# @ECLASS-VARIABLE: EGIT_CLONE_TYPE
# @DESCRIPTION:
# Type of clone that should be used against the remote repository.
# This can be either of: 'mirror', 'single', 'shallow'.
#
# The 'mirror' type clones all remote branches and tags with complete
# history and all notes. EGIT_COMMIT can specify any commit hash.
# Upstream-removed branches and tags are purged from the local clone
# while fetching. This mode is suitable for cloning the local copy
# for development or hosting a local git mirror. However, clones
# of repositories with large diverged branches may quickly grow large.
#
# The 'single' type clones only the requested branch or tag. Tags
# referencing commits throughout the branch history are fetched as well,
# and all notes. EGIT_COMMIT can safely specify only hashes
# in the current branch. No purging of old references is done (if you
# often switch branches, you may need to remove stale branches
# yourself). This mode is suitable for general use.
#
# The 'shallow' type clones only the newest commit on requested branch
# or tag. EGIT_COMMIT can only specify tags, and since the history is
# unavailable calls like 'git describe' will not reference prior tags.
# No purging of old references is done. This mode is intended mostly for
# embedded systems with limited disk space.
: ${EGIT_CLONE_TYPE:=single}
# @ECLASS-VARIABLE: EGIT_MIN_CLONE_TYPE
# @DESCRIPTION:
# 'Minimum' clone type supported by the ebuild. Takes same values
# as EGIT_CLONE_TYPE. When user sets a type that's 'lower' (that is,
# later on the list) than EGIT_MIN_CLONE_TYPE, the eclass uses
# EGIT_MIN_CLONE_TYPE instead.
#
# A common case is to use 'single' whenever the build system requires
# access to full branch history or the remote (Google Code) does not
# support shallow clones. Please use sparingly, and to fix fatal errors
# rather than 'non-pretty versions'.
: ${EGIT_MIN_CLONE_TYPE:=shallow}
# @ECLASS-VARIABLE: EGIT3_STORE_DIR
# @DESCRIPTION:
# Storage directory for git sources.
#
# This is intended to be set by user in make.conf. Ebuilds must not set
# it.
#
# EGIT3_STORE_DIR=${DISTDIR}/git3-src
# @ECLASS-VARIABLE: EGIT_MIRROR_URI
# @DEFAULT_UNSET
# @DESCRIPTION:
# 'Top' URI to a local git mirror. If specified, the eclass will try
# to fetch from the local mirror instead of using the remote repository.
#
# The mirror needs to follow EGIT3_STORE_DIR structure. The directory
# created by eclass can be used for that purpose.
#
# Example:
# @CODE
# EGIT_MIRROR_URI=git://mirror.lan/
# @CODE
# @ECLASS-VARIABLE: EGIT_REPO_URI
# @REQUIRED
# @DESCRIPTION:
# URIs to the repository, e.g. git://foo, https://foo. If multiple URIs
# are provided, the eclass will consider them as fallback URIs to try
# if the first URI does not work.
#
# It can be overriden via env using ${PN}_LIVE_REPO variable.
#
# Can be a whitespace-separated list or an array.
#
# Example:
# @CODE
# EGIT_REPO_URI=git://a/b.git https://c/d.git;
# @CODE
# @ECLASS-VARIABLE: EVCS_OFFLINE
# @DEFAULT_UNSET
# @DESCRIPTION:
# If non-empty, this variable prevents any online operations.
# @ECLASS-VARIABLE: EGIT_BRANCH
# @DEFAULT_UNSET
# @DESCRIPTION:
# The branch name to check out. If unset, the upstream default (HEAD)
# will be used.
#
# It can be overriden via env using ${PN}_LIVE_BRANCH variable.
# @ECLASS-VARIABLE: EGIT_COMMIT
# @DEFAULT_UNSET
# @DESCRIPTION:
# The tag name or commit identifier to check out. If unset, newest
# commit from the branch will be used. If set, EGIT_BRANCH will
# be ignored.
#
# It can be overriden via env using ${PN}_LIVE_COMMIT variable.
# @ECLASS-VARIABLE: EGIT_CHECKOUT_DIR
# @DESCRIPTION:
# The directory to check the git sources out to.
#
# EGIT_CHECKOUT_DIR=${WORKDIR}/${P}
# @FUNCTION: _git-r3_env_setup
# @INTERNAL
# @DESCRIPTION:
# Set the eclass variables as necessary for operation. This can involve
# setting EGIT_* to defaults or
Re: [gentoo-dev] [PATCH git-r3 03/10] Properly support non-master default branch.
In _git-r3_update_head():
+ local head_hash=$(git rev-parse --verify ${1} || die)
Maybe it's overkill, but I'd put double quotes around the ${1} here.
Ulrich
Re: [gentoo-dev] [PATCH git-r3 03/10] Properly support non-master default branch.
Dnia 2014-02-26, o godz. 16:22:25
Ulrich Mueller u...@gentoo.org napisał(a):
In _git-r3_update_head():
+ local head_hash=$(git rev-parse --verify ${1} || die)
Maybe it's overkill, but I'd put double quotes around the ${1} here.
Good catch. Fixed now.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
In _git-r3_env_setup():
+ single)
+ if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then
+ ewarn git-r3: ebuild needs to be cloned in
'single' mode, adjusting
+ EGIT_CLONE_TYPE=single
+ fi
+ ;;
+ mirror)
+ if [[ ${EGIT_CLONE_TYPE} != mirror ]]; then
+ ewarn git-r3: ebuild needs to be cloned in
'mirror' mode, adjusting
This is part of normal operation, so maybe downgrade these ewarns to
elog? There's nothing the user can do to suppress these warnings,
apart from changing his global setting for the clone type, which we
won't want him to do.
Ulrich
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
On 26/02/14 10:29 AM, Ulrich Mueller wrote: This is part of normal operation, so maybe downgrade these ewarns to elog? There's nothing the user can do to suppress these warnings, apart from changing his global setting for the clone type, which we won't want him to do. You can put EGIT_CLONE_TYPE in package.env. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
Dnia 2014-02-26, o godz. 16:29:54
Ulrich Mueller u...@gentoo.org napisał(a):
In _git-r3_env_setup():
+ single)
+ if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then
+ ewarn git-r3: ebuild needs to be cloned in
'single' mode, adjusting
+ EGIT_CLONE_TYPE=single
+ fi
+ ;;
+ mirror)
+ if [[ ${EGIT_CLONE_TYPE} != mirror ]]; then
+ ewarn git-r3: ebuild needs to be cloned in
'mirror' mode, adjusting
This is part of normal operation, so maybe downgrade these ewarns to
elog? There's nothing the user can do to suppress these warnings,
apart from changing his global setting for the clone type, which we
won't want him to do.
Seems fine. Maybe even 'einfo'?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH git-r3 11/11] Disable shallow clones of local repositories.
It was already proven before that trying to fetch those with '--depth'
result in sandbox violations due to git writing temporary files
in the repository. Instead, fetch them as 'single'.
---
eclass/git-r3.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass
index 37138a9..7ab94d2 100644
--- a/eclass/git-r3.eclass
+++ b/eclass/git-r3.eclass
@@ -507,9 +507,13 @@ git-r3_fetch() {
fi
if [[ ${EGIT_CLONE_TYPE} == shallow ]]; then
- # use '--depth 1' when fetching a new branch
- if [[ ! $(git rev-parse --quiet --verify ${fetch_r})
]]
+ if _git-r3_is_local_repo; then
+ # '--depth 1' causes sandbox violations with
local repos
+ # bug #491260
+ local EGIT_CLONE_TYPE=single
+ elif [[ ! $(git rev-parse --quiet --verify
${fetch_r}) ]]
then
+ # use '--depth 1' when fetching a new branch
fetch_command+=( --depth 1 )
fi
else # non-shallow mode
--
1.9.0
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Micha? Górny: Use-cases include Google Code (that doesn't support shallow clones) and random build systems that play with history and 'git describe'. However, please use this sparingly. When the build can't go on without non-shallow clone, sure. But if it only results in non-pretty versions, I think users choosing EGIT_CLONE_TYPE=shallow explicitly are ready to deal with the fallout. Afaiu EGIT_MIN_CLONE_TYPE is not something the user should mess with. Can we make that more clear somehow? I already see related bug reports by people doing weird things in make.conf. Or even developers mixing these two up. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDn5yAAoJEFpvPKfnPDWzXSAH/jeogFcURQvW8/wOpd0Ejd5X vkX/g0nhwJj7+q4t9FHOtvhw95KvaMvqd7t5G11SRKu/RqgfvjN2RdnfPAAaYIuZ oQ04gopmHvuTxEF/FOrWv0aJ5oF9f2bpxesnsSgSRI4SVIeII9sjHyPowEOS+NH4 i1HPaMFG3OitI0yHBOFAqGhbPoNjNPrb2n3UVMUFnrM5bPZnj6MDUyFhc1p35fjt BVT7WWvDH6wKg0pYuHj6bPK6zyQAADYKF0VZOMfw+4UadWT7iGfjJE68JGW4Dm9s HUDqDg/Kda4Jexb/U2DoIpwXrKU79K7aUxSxUSTKV7UqSV+BmJpsGcVsddMJgu4= =NnXq -END PGP SIGNATURE-
[gentoo-dev] [PATCH git-r3 12/12] Clarify which EGIT_CLONE_TYPE variables are set by who.
As requested by hasufell. --- eclass/git-r3.eclass | 6 ++ 1 file changed, 6 insertions(+) diff --git a/eclass/git-r3.eclass b/eclass/git-r3.eclass index 7ab94d2..01a6461 100644 --- a/eclass/git-r3.eclass +++ b/eclass/git-r3.eclass @@ -37,6 +37,9 @@ fi # Type of clone that should be used against the remote repository. # This can be either of: 'mirror', 'single', 'shallow'. # +# This is intended to be set by user in make.conf. Ebuilds are supposed +# to set EGIT_MIN_CLONE_TYPE if necessary instead. +# # The 'mirror' type clones all remote branches and tags with complete # history and all notes. EGIT_COMMIT can specify any commit hash. # Upstream-removed branches and tags are purged from the local clone @@ -65,6 +68,9 @@ fi # later on the list) than EGIT_MIN_CLONE_TYPE, the eclass uses # EGIT_MIN_CLONE_TYPE instead. # +# This variable is intended to be used by ebuilds only. Users are +# supposed to set EGIT_CLONE_TYPE instead. +# # A common case is to use 'single' whenever the build system requires # access to full branch history or the remote (Google Code) does not # support shallow clones. Please use sparingly, and to fix fatal errors -- 1.9.0
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
Dnia 2014-02-26, o godz. 23:53:22 hasufell hasuf...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Micha? Górny: Use-cases include Google Code (that doesn't support shallow clones) and random build systems that play with history and 'git describe'. However, please use this sparingly. When the build can't go on without non-shallow clone, sure. But if it only results in non-pretty versions, I think users choosing EGIT_CLONE_TYPE=shallow explicitly are ready to deal with the fallout. Afaiu EGIT_MIN_CLONE_TYPE is not something the user should mess with. Can we make that more clear somehow? I already see related bug reports by people doing weird things in make.conf. Or even developers mixing these two up. I assumed 'supported by the ebuild' implies it's for ebuild to set. But I can make it explicit, sure. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH git-r3 09/10] Add EGIT_MIN_CLONE_TYPE to support ebuilds requiring greater clone type.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Michał Górny: Dnia 2014-02-26, o godz. 23:53:22 hasufell hasuf...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Micha? Górny: Use-cases include Google Code (that doesn't support shallow clones) and random build systems that play with history and 'git describe'. However, please use this sparingly. When the build can't go on without non-shallow clone, sure. But if it only results in non-pretty versions, I think users choosing EGIT_CLONE_TYPE=shallow explicitly are ready to deal with the fallout. Afaiu EGIT_MIN_CLONE_TYPE is not something the user should mess with. Can we make that more clear somehow? I already see related bug reports by people doing weird things in make.conf. Or even developers mixing these two up. I assumed 'supported by the ebuild' implies it's for ebuild to set. But I can make it explicit, sure. Thanks for your work. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTDoWPAAoJEFpvPKfnPDWzNz4H/Rjm3tImvgw9dVbdeBOFh4lQ l4lhHDtvM7vNJirChGogZIZUOm8hWSoGEZ2qfjZtFpm8Ywvbt1cbgKllOlUYMyOP ZPciTMmhfRiFAYkiVF1B2xcvKCeJufKiXPcm8iVUEQ3Q6sZ4doNSnXEW/un3MH4E h69H1FG21A+ZRcdc5jA0ETrT/bojODrqLuDwe6eMEuXVpAlpnQFA7KPZK3ZOq7dr d5gOtC6gPGr5HjWNp31w1QmzKrAqUGTdrmWW8vgvK4daufWjxKuj0+K4SEjfsNQk lB+AM+c7D58SvTy57Ey8GKv8QhVO6PSR1zty8bTzoCms6pvIf3DqNf6PJjOzd04= =oBmI -END PGP SIGNATURE-
