-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Michał Górny:
> Dnia 2014-02-26, o godz. 23:53:22 hasufell
> 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
Dnia 2014-02-26, o godz. 23:53:22
hasufell 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, pleas
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 aga
-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 clon
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
Dnia 2014-02-26, o godz. 16:29:54
Ulrich Mueller 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"
> > +
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_CLON
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
> +
Dnia 2014-02-26, o godz. 16:22:25
Ulrich Mueller 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.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.
Ulrich
Dnia 2014-02-26, o godz. 12:55:20
Michał Górny 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
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
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 go
On Wed, Feb 26, 2014 at 5:49 AM, Thomas D. 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'
Dnia 2014-02-26, o godz. 07:39:51
Alex Xu 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 'gi
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
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 choos
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
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
++
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
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 has
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
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 remain
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 t
'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
---
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
> 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
> ???
Simil
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'.
Qui
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 thi
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 w
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?
>
> Ulri
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/ f
I'm confused, since when are news items signed?
-A
On Tue, Feb 25, 2014 at 6:05 AM, 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
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 :
> > 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
> >> feat
2014-02-26 12:52 GMT+04:00 Michał Górny :
> 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
2014-02-26 12:35 GMT+04:00 Dirkjan Ochtman :
> 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 alr
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].
> Th
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 wo
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 supp
39 matches
Mail list logo
