Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Dmitry Yu Okunev]

Hello.

I'm not a gentoo-dev, so sorry if I shouldn't express my thoughts with
my lame English here. Please tell me if it's so.

On 08/11/2015 12:06 AM, Michał Górny wrote:
>> 3. Too many text, hard to read. Some bugs may refer to a dozen of
>> URLs.
>
> And how is a dozen numbers better?

 Less text, more readable.
>>>
>>> How is:
>>>
>>>   Bug: 123451, 453445, 344334, 343444
>>>
>>> more readable than:
>>>
>>>   Bug: https://bugs.gentoo.org/123451
>>>   Bug: https://bugs.gentoo.org/453445
>>>   Bug: https://bugs.gentoo.org/344334
>>>   Bug: https://bugs.gentoo.org/343444
>>>
>>> Readability is a matter of formatting, not contents.
>>
>> 1. One line and 35 chars are certainly more readable than four lines
>> and 140 chars.
> 
> Character counts are completely irrelevant to readability. Visual space
> is. And in this case, exhibit A (also known as wall of digits) is more
> likely to get people confused.

I think it's just individual preference. No sense to argue this. Just
everybody should consider that there exists another position on this
question.

However I want to add an other argument:

1a. It's easier to parse the "Bug:" header is there only bug IDs
(without URLs).

And is there any guarantee that URL format won't be changed in future
(that everybody won't be have to rewrite their parsers). I mean not
"near future", but "any long future".

>> 2. Strings are read from left to right (at least in English), thus
>> having most important information last on the line is not
>> convenient.
> 
> This is not literature. Keys usually precede values, and namespaces
> precede namespaced identifiers.

A commit-comment is not a source code. It's an ordinary text (like
"literature").

>> 3. A lot of duplicated and useless information consumes time and
>> space, irritating people.
> 
> Well, maybe I'm very special then because I can *instantly* notice that
> the four quoted lines are almost identical and differ only by bug
> numbers.

Yes. But as for me this duplicated text adds a lot of garbage to the
total text of a comment. It's harder to fast look over it. You were
right — "Visual space" does matter.

And Andrew said "useless information" — I agree.

>> 4. Think about people using special accessibility devices like
>> speech-to-text engine or Braille terminal. It will be pain for them
>> to read all this notorious URLs. And we have at least one developer
>> relying upon such devices.
> 
> And that's the first valid argument. Though I would doubt that
> accessibility software handles random numbers better than URLs. Unless
> you consider retyping one of the six numbers you just heard easier than
> triggering some kind of URL activation feature.

I remember that William Hubbs asked me to remove one very simple
ASCII-arted scheme (that explains how the code works) from a patch,
because it's very inconvenient to listen that stuff using speech-to-text
engines. May be somebody should just ask him for his opinion on this
question? I think it's more convenient to listen pure bug IDs rather
than a lot of full URLs.

 What is a corner case? Why not defining "clicking on the link in
 the git log" as a corner case?
>>>
>>> As far as I'm aware, URLs are supported much more widely than
>>> Gentoo-specific bug numbers. They are uniform and unique by definition.
>>> The tools using bug numbers can be easily expanded to extract them from
>>> URLs. I don't really see forking cgit to support Gentoo bug numbers, or
>>> asking github to provide special rules for our commits.
>>
>> We should not adjust our ecosystem for closed and proprietary
>> solutions like github.
> 
> URLs are not github invention. Localized bug numbers are local Gentoo
> non-sense. So should we adjust it to ignore the rest of the world and
> expect everyone to create custom hackery just to be able to see a bug
> report?

You can use header "Gentoo-Bug:" (instead of "Bug:") and explain in
documentation ways to parse that.

-- 
Best regards, Dmitry.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: rsync mirror security

[Matthias Maier]

On Mon, Aug 10, 2015, at 22:56 CDT, Kent Fredric  wrote:

> So how is GPG verifying "The whole repository" ?

You can verify the state of the repository via
  $ git fsck

after that you can verify that the current HEAD is tagged with a valid
and singed tag with something like

  $ git tag -v `git describe HEAD`

This verifies the integrity of the whole history up to HEAD - at least
if you consider sha1 to be cryptographically

Best,
Matthias


PS.: I think I was mistaken with respect to individually signed
commits - the verification seems to be stricter than I thought.

Re: [gentoo-dev] Re: rsync mirror security

[Mike Frysinger]

On 11 Aug 2015 15:23, Kent Fredric wrote:
> On 11 August 2015 at 15:06, Mike Frysinger wrote:
> > it would have to re-use the same tag name every time otherwise we end up 
> > with
> > 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea
> 
> I was very much under the impression git is not designed with repeated
> tag replication in consideration.

git has no problem fetching rewritten tags.  internally, it doesn't care
either -- a tag is merely a reference to an object.

> The git tag documentation very much implies that any tag having its
> reference changed will result in effort being required of everyone who
> wishes to consume that tag. ( It literally brands  the act of
> re-tagging things to be "insane" )
> 
> Tags are very much intended to be immutable references to commits.

the git docs take the stance that publishing any mutable names is wrong.
same goes for rebasing and publishing rewritten history.  that's simply
the recommended practice.  it doesn't mean that the world blows up when
you do rewrite things.

> If you need mutable references to commits, isn't that what branches are for?

no, that's not what they're for.  
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: rsync mirror security

[Kent Fredric]

On 11 August 2015 at 15:44, Matthias Maier  wrote:
>
> No, a signed tag verifies that the whole integrirty of the entire
> repository, whereas a signed commit only authenticates the differences
> introduced by a single commit.


git tag -s test

cat ./.git/refs/tags/test
456d216e3d1894d62429daf0ec482c3afb087dbe

git cat-file tag 456d216e3d1894d62429daf0ec482c3afb087dbe
object 9ca77ee7f72902e4e89456ff560a670465969603
type commit
tag test
tagger Kent Fredric  1439264837 +1200

A test tag
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAABCAAGBQJVyXBKAAoJEOhUMksTZqgg2/kP/iCXS12W57RB2wPQHgebgSpK
86zXXvXC5rqndTmGwOmYA9FcO/n2u+SMwk0ZGol9LWuvkKaW/6Wi/vzvG24lggWy
GxKRQTNHPXVHxwPQZOhj6fwS9EkC3rCSMWv82qLrbXvBqsH/dLXymq2nl+YDEGi1
lLkDWkX7EYWA6sgdnDhNzjPaHVC9P5qP1JDZOrKY0Qzm9JBDMl0xO9/faITrBMDi
BmVVHNELKQ9uN8BYxmQfHqUFKO2SWXFbqJftQ6LqpXmFHWDpasmY3gTMczPpQ47I
le+LPo0tT3Yk0fhBc8uk0/69kaHMa5hMmBPHuHh5ANWLPpxSyiDzCqqS9i8wPB+M
MONhAoVyLYaFUf62fBxa6kxKDdQuC5JRYjeiFs60k1uG/QI4OhjoIbbaaxJxQ0sy
45iZ3PBlVxbgxkpPRJtftr9PJBMDabekZbI5F6jX7S+x6G40O4ss1W1QnXsdFvqd
vJvVdIdnrGqu/6JXZpz2J65N3HfMqfj9PHNDJaxM6da6+z6HQ3JwvNSVum8dAaJn
jKoisQ7bEuXl2WOj5SCfAqjtOUp2pbYJCCb5QVHWuHCk53cvcY6FmGQPEzj42uVQ
bKSYGaJ3637t+NPysinifQv1HTfViP7lh/O3znsGj7qcm6DXGnHvkp84LFch6yiY
/oFbaDvWZ8zKyMSAJ9Ou
=Ieic
-END PGP SIGNATURE-



git cat-file tag 456d216e3d1894d62429daf0ec482c3afb087dbe > /tmp/sigfile
cp /tmp/sigfile /tmp/sigfile.asc

*edits both so sigfile has content, and asc file has signature*


gpg --verify /tmp/sigfile.asc
gpg: enabled debug flags: memstat
gpg: assuming signed data in '/tmp/sigfile'
gpg: Signature made Tue Aug 11 15:47:22 2015 NZST
gpg:using RSA key E854324B1366A820
gpg: Good signature from "Kent Fredric (GMail)
" [unknown]
gpg: aka "Kent Fredric (CPAN Author)
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3D96 B36C 8FEA AC54 F5A3  DAE7 E854 324B 1366 A820
gpg: keydb: kid_not_found_table: total: 1
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
  outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/65536 bytes in 0 blocks


^^ - so its clear the signature is only on the tag data itself.

And what does the tag refer to?

object 9ca77ee7f72902e4e89456ff560a670465969603

What is that?


git cat-file -t 9ca77ee7f72902e4e89456ff560a670465969603
commit


So how is GPG verifying "The whole repository" ?

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Re: rsync mirror security

[Matthias Maier]

> it would have to re-use the same tag name every time otherwise we end up with 
> 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea

Or we supply a signature of the sha1-sum of the tag in question by some
external procedure...

Best,
Matthias


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: rsync mirror security

[Matthias Maier]

> That is, I was under the impression signing a tag only signs the
> references themselves, and then relies on SHA1 referential integrity
> beyond that.

No, a signed tag verifies that the whole integrirty of the entire
repository, whereas a signed commit only authenticates the differences
introduced by a single commit.

As long as there are no conflicts, a signed commit can be rebased
freely (especially also on top of malicious commits...).

Best,
Matthias

Re: [gentoo-dev] Re: rsync mirror security

[Kent Fredric]

On 11 August 2015 at 15:06, Mike Frysinger  wrote:
> it would have to re-use the same tag name every time otherwise we end up with
> 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea


I was very much under the impression git is not designed with repeated
tag replication in consideration.

The git tag documentation very much implies that any tag having its
reference changed will result in effort being required of everyone who
wishes to consume that tag. ( It literally brands  the act of
re-tagging things to be "insane" )

Tags are very much intended to be immutable references to commits.

If you need mutable references to commits, isn't that what branches are for?



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Re: rsync mirror security

[Kent Fredric]

On 11 August 2015 at 09:05, Matthias Maier  wrote:
> We could also provide automatic signed tags every 30min/1h/2h/whatever
> (signed with a suitable infrastructure key). With that, the integrity of
> a tagged git checkout can be easily verified on client side.


I'm distinctly under the impression that a signed tag doesn't really
give you anything a signed commit wouldn't.

That is, I was under the impression signing a tag only signs the
references themselves, and then relies on SHA1 referential integrity
beyond that.


Hence, a signed tag basically is a statement proving X author
authorized Y-SHA1, and then it subsequently implies that X author
authorized whatever Y-SHA1 refers to.

So adding additional tags *just* for the purpose of having a periodic
signature would give no benefit over the "all tags are signed, all
commits are signed" mechanism for git users, and the signed tag could
_not_ be verified against an RSYNC clone.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Re: rsync mirror security

[Mike Frysinger]

On 10 Aug 2015 16:05, Matthias Maier wrote:
> > Users can fetch/pull from Github.
> 
> We could also provide automatic signed tags every 30min/1h/2h/whatever
> (signed with a suitable infrastructure key). With that, the integrity of
> a tagged git checkout can be easily verified on client side.

it would have to re-use the same tag name every time otherwise we end up with 
17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea

depending on how fast the process is, it could just be part of the receive hook
on the server that does the checking now.  that way the tag is always up to date
with every push a developer makes.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Duncan]

Ryan Hill posted on Mon, 10 Aug 2015 18:17:30 -0600 as excerpted:

> On Mon, 10 Aug 2015 12:25:58 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>> What about:
>> 
>> * bug number in summary strongly recommended
> 
> Making the bug number in the summary manditory or strongly encouraged
> leads to wonderful commit messages like:
> 
> ---
> cat-pkg: Fix bug #504321.

Ideally, it'd be something a bit more informative (here taking Gordon's 
points about the previously suggested B#):

cat-egory/semi-long-package-name: fix amd64-fbsd build error G-504321

> I would like to see this be more common:
> 
> ---
> cat-pkg: Make the thingy work again
> 
> Gentoo-Bug: https://bugs.gentoo.org/504321 *(or 504321 Idon'tcarewhich)
> 
> 
> If we're limiting the summary to 1 line, 70-75 chars, manditory
> cat/package and bug number there's not a lot of room to summarize in.

Note that a bug number would fit in your above summary very easily, 
omitting nothing, as it's only ~35/75 length.

Even with my somewhat longer cat/pkg example with the longest arch-
keyword I could quickly find, there's still room to indicate at minimum 
build vs runtime error, with the gentoo bug number reference for anyone 
who might find it interesting enough to look further than the one-line.  
People can then either select and klipper-popup (adding my usual trigger 
method to the others people have mentioned), or read the longer 
description for the full bug URL to click, if they prefer.

-- 
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-dev] Re: Referencing bug reports in git

[Duncan]

Gordon Pettey posted on Mon, 10 Aug 2015 17:57:56 -0500 as excerpted:

> On Mon, Aug 10, 2015 at 7:25 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> 
>> ** summary bug number standardized to GB#xx or #xx or similar,
>> short enough for summary, easily identified. GB# would be distinctly
>> gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for
>>
>>
> If you're going to prepend the project, just spell it out.

My thought is that this is the one-line summary, generally limited to 75 
chars, including category/package.  Spelling it out thus takes precious 
character-space that can better be used to describe the problem in words.

> Don't add a B suffix to everything. If it's the same everywhere, then
> it is meaningless, and just confuses things.

Very good point, particularly in light of the above -- that's another 
character-slot from 75 that can't be used for other things.

> Don't prefix bugs with #. 1. It doesn't apply to every system: Random
> Project using Jira is going to have bugs like RP-123. You'd have to
> insert it in the middle of the identifier like RP-#123. 2. It is a
> relatively useless prefix at best: In the bug tracker UI, you search for
> 123, not #123. At worst, it makes the identifier invalid (as in the Jira
> example).

Once again, very good point.  Thanks. =:^)

-- 
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-dev] Re: Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Ryan Hill]

On Mon, 10 Aug 2015 23:43:29 +0300
Andrew Savchenko  wrote:

> On Mon, 10 Aug 2015 15:11:02 +0200 Michał Górny wrote:
> > > > > 2. Bug number can be easily typed, URL has to be copied or
> > > > > generated by some tool.
> > > > 
> > > > So, please remind me, how many times the 'easy typing' got the bug
> > > > number wrong? This is not a real argument, just another of Gentoo's
> > > > 'I'm too lazy to do things right'.
> > > 
> > > URLs are longer, so probability of error during typing increases
> > > compared to raw numbers.
> > 
> > Not really. You are closer to the threshold when you are too lazy to
> > type it and you just copy-paste it.
> 
> Copy and pasting requires more time than typing 6 digits.
>  
> > > > > 3. Too many text, hard to read. Some bugs may refer to a dozen of
> > > > > URLs.
> > > > 
> > > > And how is a dozen numbers better?
> > > 
> > > Less text, more readable.
> > 
> > How is:
> > 
> >   Bug: 123451, 453445, 344334, 343444
> > 
> > more readable than:
> > 
> >   Bug: https://bugs.gentoo.org/123451
> >   Bug: https://bugs.gentoo.org/453445
> >   Bug: https://bugs.gentoo.org/344334
> >   Bug: https://bugs.gentoo.org/343444
> > 
> > Readability is a matter of formatting, not contents.
> 
> 1. One line and 35 chars are certainly more readable than four lines
> and 140 chars.

It isn't.  There's a reason why lists of things are generally written top to
bottom.  I found the second form to be much more readable.  In fact I was
generally against the URIs until I saw this.

> 2. Strings are read from left to right (at least in English), thus
> having most important information last on the line is not
> convenient.

Maybe if you were reading the whole line, but you're not.  You have built-in
pattern recognition.  Try it out.

> 3. A lot of duplicated and useless information consumes time and
> space, irritating people.

Arg, that is so irritating how I have easily-clickable machine-parsable links in
my git log. Look at all the space we could have saved!  How much time have I
wasted reading every character?!  Sorry kids, can't play, daddy's busy reading
commit logs.

No matter what we decide three months from now we won't remember arguing about
it.  So let's save some time an irritability now and pick something.



-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpjwTP4s_CiU.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Ryan Hill]

On Mon, 10 Aug 2015 12:25:58 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> What about:
> 
> * bug number in summary strongly recommended
> ** summary bug number standardized to GB#xx or #xx or similar, 
> short enough for summary, easily identified. GB# would be distinctly 
> gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for 
> projects where users likely to want to see the bug likely know what it is.
> ** summary lists gentoo bug if any, upstream only if no gentoo bug.
> 
> * bug URL in description required.
> ** standardized to Gentoo-Bug: ...
> ** gives people wanting something to click a way to do so
> ** U in URL is universal, unambiguously identifies reference for those 
> unfamiliar with summary shorthand.
> ** Multiple allowed, for multiple gentoo bugs or to identify upstream 
> bugs (using FDO-Bug: or similar) as well.
> 
> That seems a reasonable compromise, given people pulling both ways
> in-thread.

Making the bug number in the summary manditory or strongly encouraged leads to
wonderful commit messages like:

---
cat-pkg: Fix bug #504321.

Gentoo-Bug: 504321
---

I would like to see this be more common:

---
cat-pkg: Make the thingy work again.

Gentoo-Bug: https://bugs.gentoo.org/504321 or 504321 Idon'tcarewhich


If we're limiting the summary to 1 line, 70-75 chars, manditory cat/package
and bug number there's not a lot of room to summarize in.


-- 
Ryan Hillpsn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463


pgpHa8xvvMufS.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Referencing bug reports in git

[Gordon Pettey]

On Mon, Aug 10, 2015 at 7:25 AM, Duncan <1i5t5.dun...@cox.net> wrote:

> ** summary bug number standardized to GB#xx or #xx or similar,
> short enough for summary, easily identified. GB# would be distinctly
> gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for
>

If you're going to prepend the project, just spell it out. Don't invent new
acronyms and abbreviations. Don't add a B suffix to everything. If it's the
same everywhere, then it is meaningless, and just confuses things. I know
what KDE is, but I'd have to go Google for what KDEB is (Is that KDE B? K
Debian?), and hope Google indexed the above email from gmane or something.

Don't prefix bugs with #. 1. It doesn't apply to every system: Random
Project using Jira is going to have bugs like RP-123. You'd have to insert
it in the middle of the identifier like RP-#123. 2. It is a relatively
useless prefix at best: In the bug tracker UI, you search for 123, not
#123. At worst, it makes the identifier invalid (as in the Jira example).

[gentoo-dev] golang-vcs.eclass: remove the EGO_SRC variable

[William Hubbs]

All,

this variable can be computed in the eclass using ${EGO_PN/%*}, so there
is no need to have a separate variable.

This patch removes it.

William

From ded07bc7b61183a737d2bf6a911f29639617b015 Mon Sep 17 00:00:00 2001
From: William Hubbs 
Date: Sun, 9 Aug 2015 12:04:36 -0500
Subject: [PATCH] golang-vcs.eclass: remove EGO_SRC variable

This is not needed, because it can be referred to as ${EGO_PN%/*}.
---
 eclass/golang-vcs.eclass | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/eclass/golang-vcs.eclass b/eclass/golang-vcs.eclass
index 2fe3a84..2caaac4 100644
--- a/eclass/golang-vcs.eclass
+++ b/eclass/golang-vcs.eclass
@@ -38,20 +38,6 @@ _GOLANG_VCS=1
 # EGO_PN="github.com/user1/package1 github.com/user2/package2"
 # @CODE
 
-# @ECLASS-VARIABLE: EGO_SRC
-# @DESCRIPTION:
-# This is the Go upstream repository which will be copied to
-# ${WORKDIR}/${P}.
-# If it isn't set, it defaults to the first word of ${EGO_PN}.
-# This should be set if you are retrieving a repository that includes
-# multiple packages, e.g. golang.org/x/tools.
-#
-# Example:
-# @CODE
-# EGO_PN="github.com/user/repository/..."
-# EGO_SRC="github.com/user/repository"
-# @CODE
-
 # @ECLASS-VARIABLE: EGO_STORE_DIR
 # @DESCRIPTION:
 # Storage directory for Go sources.
@@ -98,10 +84,6 @@ _golang-vcs_env_setup() {
 	[[ -n ${EVCS_UMASK} ]] && eumask_pop
 	mkdir -p "${WORKDIR}/${P}/src" ||
 		die "${ECLASS}: unable to create ${WORKDIR}/${P}"
-	if [ -z "${EGO_SRC}" ]; then
-		set -- ${EGO_PN}
-		EGO_SRC="$1"
-	fi
 	return 0
 }
 
@@ -127,11 +109,11 @@ _golang-vcs_fetch() {
 
 		[[ -n ${EVCS_UMASK} ]] && eumask_pop
 	fi
-	set -- mkdir -p "${WORKDIR}/${P}/src/${EGO_SRC%/*}"
+	set -- mkdir -p "${WORKDIR}/${P}/src/${EGO_PN%/*}"
 	echo "$@"
 	"$@" || die "Unable to create ${WORKDIR}/${P}/src"
-	set -- cp -r	"${EGO_STORE_DIR}/src/${EGO_SRC}" \
-		"${WORKDIR}/${P}/src/${EGO_SRC%/*}"
+	set -- cp -r	"${EGO_STORE_DIR}/src/${EGO_PN%/*}" \
+		"${WORKDIR}/${P}/src/${EGO_PN%/*}"
 	echo "$@"
 	"$@" || die "Unable to copy sources to ${WORKDIR}/${P}"
 	return 0
-- 
2.4.6



signature.asc
Description: Digital signature

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Michał Górny]

Dnia 2015-08-10, o godz. 23:43:29
Andrew Savchenko  napisał(a):

> On Mon, 10 Aug 2015 15:11:02 +0200 Michał Górny wrote:
> > > > > 2. Bug number can be easily typed, URL has to be copied or
> > > > > generated by some tool.
> > > > 
> > > > So, please remind me, how many times the 'easy typing' got the bug
> > > > number wrong? This is not a real argument, just another of Gentoo's
> > > > 'I'm too lazy to do things right'.
> > > 
> > > URLs are longer, so probability of error during typing increases
> > > compared to raw numbers.
> > 
> > Not really. You are closer to the threshold when you are too lazy to
> > type it and you just copy-paste it.
> 
> Copy and pasting requires more time than typing 6 digits.

Excuse me but could you stop shifting from one argument to another?
Because this is not going anywhere if we're going to switch from X to
Y, and back, depending on which goal fits you at the moment.

> > > > > 3. Too many text, hard to read. Some bugs may refer to a dozen of
> > > > > URLs.
> > > > 
> > > > And how is a dozen numbers better?
> > > 
> > > Less text, more readable.
> > 
> > How is:
> > 
> >   Bug: 123451, 453445, 344334, 343444
> > 
> > more readable than:
> > 
> >   Bug: https://bugs.gentoo.org/123451
> >   Bug: https://bugs.gentoo.org/453445
> >   Bug: https://bugs.gentoo.org/344334
> >   Bug: https://bugs.gentoo.org/343444
> > 
> > Readability is a matter of formatting, not contents.
> 
> 1. One line and 35 chars are certainly more readable than four lines
> and 140 chars.

Character counts are completely irrelevant to readability. Visual space
is. And in this case, exhibit A (also known as wall of digits) is more
likely to get people confused.

> 2. Strings are read from left to right (at least in English), thus
> having most important information last on the line is not
> convenient.

This is not literature. Keys usually precede values, and namespaces
precede namespaced identifiers.

> 3. A lot of duplicated and useless information consumes time and
> space, irritating people.

Well, maybe I'm very special then because I can *instantly* notice that
the four quoted lines are almost identical and differ only by bug
numbers.

> 4. Think about people using special accessibility devices like
> speech-to-text engine or Braille terminal. It will be pain for them
> to read all this notorious URLs. And we have at least one developer
> relying upon such devices.

And that's the first valid argument. Though I would doubt that
accessibility software handles random numbers better than URLs. Unless
you consider retyping one of the six numbers you just heard easier than
triggering some kind of URL activation feature.

> > > What is a corner case? Why not defining "clicking on the link in
> > > the git log" as a corner case?
> > 
> > As far as I'm aware, URLs are supported much more widely than
> > Gentoo-specific bug numbers. They are uniform and unique by definition.
> > The tools using bug numbers can be easily expanded to extract them from
> > URLs. I don't really see forking cgit to support Gentoo bug numbers, or
> > asking github to provide special rules for our commits.
> 
> We should not adjust our ecosystem for closed and proprietary
> solutions like github.

URLs are not github invention. Localized bug numbers are local Gentoo
non-sense. So should we adjust it to ignore the rest of the world and
expect everyone to create custom hackery just to be able to see a bug
report?

-- 
Best regards,
Michał Górny



pgpyWtfdFCsAr.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: rsync mirror security

[Matthias Maier]

> Users can fetch/pull from Github.

We could also provide automatic signed tags every 30min/1h/2h/whatever
(signed with a suitable infrastructure key). With that, the integrity of
a tagged git checkout can be easily verified on client side.

Best,
Matthias



signature.asc
Description: PGP signature

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[Michał Górny]

Dnia 2015-08-10, o godz. 23:49:55
Andrew Savchenko  napisał(a):

> On Mon, 10 Aug 2015 23:47:21 +0300 Andrew Savchenko wrote:
> > On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> > > On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > > > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  
> > > > wrote:
> > > >>
> > > >> Expanding on this: the rsync master creates the following
> > > >> files/directories under metatdata. On my own system, I like to symlink
> > > >> them to locations outside my repo so that related portage features
> > > >> continue to work.
> > > >>
> > > >> I would like to have these added in .gitignore.
> > > >>
> > > >> metadata/dtd/ # used by something?
> > > >> metadata/glsa/ # used by the GLSA utilities?
> > > >> matadata/herds.xml # used by equery from gentoolkit
> > > >> metadata/news/ # used by eselect news
> > > >>
> > > > 
> > > > As a side note, it probably wouldn't hurt to set up a guide for
> > > > running git on /usr/portage, including setting up these symlinks,
> > > > running egencache after emerge --sync, etc.  I imagine that this is a
> > > > configuration that many developers will tend to use, and with the
> > > > advent of git we may see more users who tend to contribute doing the
> > > > same.
> > > > 
> > > 
> > > In fact, this should be the recommended way of running gentoo for
> > > everyone. Our rsync methods are still inherently insecure (unless I
> > > missed something), because:
> > > 1. machine key
> > > 2. profiles, eclasses and so on are not covered with a
> > > signature/Manifest anyway
> >  
> > Not unless metadata cache will be synced too from a trusted source.
> > It takes too much time to generate, especially on non-brand-new
> > hardware.
> 
> Another issue: we will have to setup git mirrors as well (probably
> reusing hosts providing rsync mirrors). I really doubt current
> infrastructure will survive if all users will sync from its git.

Do you mean git mirrors of the original repo, or md5-cache propagated
copy for users syncing? The latter is available for a few months now
[1,2].

[1]:https://github.com/gentoo-mirror/
[2]:https://wiki.gentoo.org/wiki/Project:Repository_mirror_and_CI

-- 
Best regards,
Michał Górny



pgplxXKEHh0ji.pgp
Description: OpenPGP digital signature

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[Michał Górny]

Dnia 2015-08-10, o godz. 23:47:21
Andrew Savchenko  napisał(a):

> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> > On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:
> > >>
> > >> Expanding on this: the rsync master creates the following
> > >> files/directories under metatdata. On my own system, I like to symlink
> > >> them to locations outside my repo so that related portage features
> > >> continue to work.
> > >>
> > >> I would like to have these added in .gitignore.
> > >>
> > >> metadata/dtd/ # used by something?
> > >> metadata/glsa/ # used by the GLSA utilities?
> > >> matadata/herds.xml # used by equery from gentoolkit
> > >> metadata/news/ # used by eselect news
> > >>
> > > 
> > > As a side note, it probably wouldn't hurt to set up a guide for
> > > running git on /usr/portage, including setting up these symlinks,
> > > running egencache after emerge --sync, etc.  I imagine that this is a
> > > configuration that many developers will tend to use, and with the
> > > advent of git we may see more users who tend to contribute doing the
> > > same.
> > > 
> > 
> > In fact, this should be the recommended way of running gentoo for
> > everyone. Our rsync methods are still inherently insecure (unless I
> > missed something), because:
> > 1. machine key
> > 2. profiles, eclasses and so on are not covered with a
> > signature/Manifest anyway
>  
> Not unless metadata cache will be synced too from a trusted source.
> It takes too much time to generate, especially on non-brand-new
> hardware.

Err, it takes around 2 minutes to generate full cache with pkgcore on
some old Xeon. Updates are much faster.

-- 
Best regards,
Michał Górny



pgps3l6OZ6CPq.pgp
Description: OpenPGP digital signature

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[Aaron W. Swenson]

On 2015-08-10 23:49, Andrew Savchenko wrote:
> Another issue: we will have to setup git mirrors as well (probably
> reusing hosts providing rsync mirrors). I really doubt current
> infrastructure will survive if all users will sync from its git.

Users can fetch/pull from Github.

https://github.com/gentoo/gentoo


signature.asc
Description: Digital signature

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[hasufell]

On 08/10/2015 10:47 PM, Andrew Savchenko wrote:
> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
>> On 08/10/2015 05:09 PM, Rich Freeman wrote:
>>> On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:

 Expanding on this: the rsync master creates the following
 files/directories under metatdata. On my own system, I like to symlink
 them to locations outside my repo so that related portage features
 continue to work.

 I would like to have these added in .gitignore.

 metadata/dtd/ # used by something?
 metadata/glsa/ # used by the GLSA utilities?
 matadata/herds.xml # used by equery from gentoolkit
 metadata/news/ # used by eselect news

>>>
>>> As a side note, it probably wouldn't hurt to set up a guide for
>>> running git on /usr/portage, including setting up these symlinks,
>>> running egencache after emerge --sync, etc.  I imagine that this is a
>>> configuration that many developers will tend to use, and with the
>>> advent of git we may see more users who tend to contribute doing the
>>> same.
>>>
>>
>> In fact, this should be the recommended way of running gentoo for
>> everyone. Our rsync methods are still inherently insecure (unless I
>> missed something), because:
>> 1. machine key
>> 2. profiles, eclasses and so on are not covered with a
>> signature/Manifest anyway
>  
> Not unless metadata cache will be synced too from a trusted source.
> It takes too much time to generate, especially on non-brand-new
> hardware.
> 

I was wondering if that could be automated in a separate branch (only
needs to update in 24h intervals).

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[Andrew Savchenko]

On Mon, 10 Aug 2015 23:47:21 +0300 Andrew Savchenko wrote:
> On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> > On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:
> > >>
> > >> Expanding on this: the rsync master creates the following
> > >> files/directories under metatdata. On my own system, I like to symlink
> > >> them to locations outside my repo so that related portage features
> > >> continue to work.
> > >>
> > >> I would like to have these added in .gitignore.
> > >>
> > >> metadata/dtd/ # used by something?
> > >> metadata/glsa/ # used by the GLSA utilities?
> > >> matadata/herds.xml # used by equery from gentoolkit
> > >> metadata/news/ # used by eselect news
> > >>
> > > 
> > > As a side note, it probably wouldn't hurt to set up a guide for
> > > running git on /usr/portage, including setting up these symlinks,
> > > running egencache after emerge --sync, etc.  I imagine that this is a
> > > configuration that many developers will tend to use, and with the
> > > advent of git we may see more users who tend to contribute doing the
> > > same.
> > > 
> > 
> > In fact, this should be the recommended way of running gentoo for
> > everyone. Our rsync methods are still inherently insecure (unless I
> > missed something), because:
> > 1. machine key
> > 2. profiles, eclasses and so on are not covered with a
> > signature/Manifest anyway
>  
> Not unless metadata cache will be synced too from a trusted source.
> It takes too much time to generate, especially on non-brand-new
> hardware.

Another issue: we will have to setup git mirrors as well (probably
reusing hosts providing rsync mirrors). I really doubt current
infrastructure will survive if all users will sync from its git.

Best regards,
Andrew Savchenko


pgpgTnzWmzUEz.pgp
Description: PGP signature

Re: rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[Andrew Savchenko]

On Mon, 10 Aug 2015 22:13:23 +0200 hasufell wrote:
> On 08/10/2015 05:09 PM, Rich Freeman wrote:
> > On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:
> >>
> >> Expanding on this: the rsync master creates the following
> >> files/directories under metatdata. On my own system, I like to symlink
> >> them to locations outside my repo so that related portage features
> >> continue to work.
> >>
> >> I would like to have these added in .gitignore.
> >>
> >> metadata/dtd/ # used by something?
> >> metadata/glsa/ # used by the GLSA utilities?
> >> matadata/herds.xml # used by equery from gentoolkit
> >> metadata/news/ # used by eselect news
> >>
> > 
> > As a side note, it probably wouldn't hurt to set up a guide for
> > running git on /usr/portage, including setting up these symlinks,
> > running egencache after emerge --sync, etc.  I imagine that this is a
> > configuration that many developers will tend to use, and with the
> > advent of git we may see more users who tend to contribute doing the
> > same.
> > 
> 
> In fact, this should be the recommended way of running gentoo for
> everyone. Our rsync methods are still inherently insecure (unless I
> missed something), because:
> 1. machine key
> 2. profiles, eclasses and so on are not covered with a
> signature/Manifest anyway
 
Not unless metadata cache will be synced too from a trusted source.
It takes too much time to generate, especially on non-brand-new
hardware.

Best regards,
Andrew Savchenko


pgp1HcAyNrAU_.pgp
Description: PGP signature

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Andrew Savchenko]

On Mon, 10 Aug 2015 15:11:02 +0200 Michał Górny wrote:
> > > > 2. Bug number can be easily typed, URL has to be copied or
> > > > generated by some tool.
> > > 
> > > So, please remind me, how many times the 'easy typing' got the bug
> > > number wrong? This is not a real argument, just another of Gentoo's
> > > 'I'm too lazy to do things right'.
> > 
> > URLs are longer, so probability of error during typing increases
> > compared to raw numbers.
> 
> Not really. You are closer to the threshold when you are too lazy to
> type it and you just copy-paste it.

Copy and pasting requires more time than typing 6 digits.
 
> > > > 3. Too many text, hard to read. Some bugs may refer to a dozen of
> > > > URLs.
> > > 
> > > And how is a dozen numbers better?
> > 
> > Less text, more readable.
> 
> How is:
> 
>   Bug: 123451, 453445, 344334, 343444
> 
> more readable than:
> 
>   Bug: https://bugs.gentoo.org/123451
>   Bug: https://bugs.gentoo.org/453445
>   Bug: https://bugs.gentoo.org/344334
>   Bug: https://bugs.gentoo.org/343444
> 
> Readability is a matter of formatting, not contents.

1. One line and 35 chars are certainly more readable than four lines
and 140 chars.

2. Strings are read from left to right (at least in English), thus
having most important information last on the line is not
convenient.

3. A lot of duplicated and useless information consumes time and
space, irritating people.

4. Think about people using special accessibility devices like
speech-to-text engine or Braille terminal. It will be pain for them
to read all this notorious URLs. And we have at least one developer
relying upon such devices.

> > What is a corner case? Why not defining "clicking on the link in
> > the git log" as a corner case?
> 
> As far as I'm aware, URLs are supported much more widely than
> Gentoo-specific bug numbers. They are uniform and unique by definition.
> The tools using bug numbers can be easily expanded to extract them from
> URLs. I don't really see forking cgit to support Gentoo bug numbers, or
> asking github to provide special rules for our commits.

We should not adjust our ecosystem for closed and proprietary
solutions like github.
 
> > > > 5. Clicking is less convenient than typing "bugs search $number" —
> > > > user have to move hands from a keyboard to a mouse — a terrible
> > > > waste of time, at least in my case with my typing speed.
> > > 
> > > You can type the number you see at the end of the URL. If you really
> > > want to go l33t, that shouldn't a problem for you.
> >  
> > This is not a matter of going l33t, this is a matter of getting rid
> > of redundant and pretty much useless data all the same through
> > almost all commit messages.
> 
> Which reminds me of the metadata.xml discussion. These days we have
> transparent compression which handles redundant data much better than
> explicit obfuscation, and with much less harm.
 
I'm not talking about bits on disk (though they matter too), but
more about human being reading them.

Best regards,
Andrew Savchenko


pgp16i0YCp7ll.pgp
Description: PGP signature

rsync mirror security (WAS: Re: [gentoo-dev] .gitignore)

[hasufell]

On 08/10/2015 05:09 PM, Rich Freeman wrote:
> On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:
>>
>> Expanding on this: the rsync master creates the following
>> files/directories under metatdata. On my own system, I like to symlink
>> them to locations outside my repo so that related portage features
>> continue to work.
>>
>> I would like to have these added in .gitignore.
>>
>> metadata/dtd/ # used by something?
>> metadata/glsa/ # used by the GLSA utilities?
>> matadata/herds.xml # used by equery from gentoolkit
>> metadata/news/ # used by eselect news
>>
> 
> As a side note, it probably wouldn't hurt to set up a guide for
> running git on /usr/portage, including setting up these symlinks,
> running egencache after emerge --sync, etc.  I imagine that this is a
> configuration that many developers will tend to use, and with the
> advent of git we may see more users who tend to contribute doing the
> same.
> 

In fact, this should be the recommended way of running gentoo for
everyone. Our rsync methods are still inherently insecure (unless I
missed something), because:
1. machine key
2. profiles, eclasses and so on are not covered with a
signature/Manifest anyway

Re: [gentoo-dev] git commit / push signing error

[Patrice Clement]

Monday 10 Aug 2015 12:02:25, Daniel Campbell (zlg) wrote :
> On 08/10/2015 06:15 AM, Doug Goldstein wrote:
> > On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn 
> >  wrote:
> >> Doug Goldstein schrieb:
> >>> gpg: cancelled by user gpg: skipped "0xA2BC03DC87ED1BD4":
> >>> Operation cancelled gpg: signing failed: Operation cancelled 
> >>> error: gpg failed to sign the data
> >> 
> >> There was an IRC discussion yesterday about this. Probably your
> >> pinentry tries to talk to a GUI and fails. Try:
> >> 
> >> unset DISPLAY export GPG_TTY=$(tty)
> >> 
> >> to make it fall back to curses, or use "eselect pinentry" to
> >> select curses as default.
> >> 
> >> Interestingly, git requires GPG_TTY if eselect-pinentry is set to
> >> gtk-2 or qt4, but repoman doesn't.
> >> 
> >> 
> >> Best regards, Chí-Thanh Christopher Nguyễn
> >> 
> >> 
> > 
> > $ eselect pinentry show Current pinentry binary implementation: 
> > pinentry-curses
> > 
> > $ eselect pinentry list Available pinentry binary implementations: 
> > [1]   pinentry-curses *
> > 
> > Its the only version I've got on this machine. The box is headless
> > and I ssh into and I use keychain to manage my SSH and GPG agent.
> > 
> What's your keychain line look like in your .bashrc/.bash_profile?
> Here's the relevant portion of mine. I was also having problems with
> it until I changed the order of the arguments:
> 
> [snip]
> /usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY}
> source ~/.keychain/sporkbox-sh > /dev/null
> source ~/.keychain/sporkbox-sh-gpg > /dev/null
> [snip]
> 
> For some reason, it's important that ssh comes before gpg. I got this
> advice straight from drobbins, so unless it's changed, that's the way
> to get it working.
> -- 
> Daniel Campbell - Gentoo Developer
> OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
> fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6

Would someone mind documenting this issue in the wiki?

https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Issues

So that we all have a point of reference to go to.

Thanks!


pgp5LAuSmShMi.pgp
Description: PGP signature

Re: [gentoo-dev] .gitignore

[Mike Gilbert]

On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:
> On Mon, Aug 10, 2015 at 2:42 AM, Mike Frysinger  wrote:
>> On 10 Aug 2015 08:28, Justin (jlec) wrote:
>>> how do we maintain this file?
>>
>> like any other file.  git add && git commit.
>>
>>> I like to propose to add the md5-cache into it. Which other files are of 
>>> interest?
>>
>> /distfiles/
>> /local/
>> /packages/
>>
>> /metadata/md5-cache/
>> -mike
>
> Expanding on this: the rsync master creates the following
> files/directories under metatdata. On my own system, I like to symlink
> them to locations outside my repo so that related portage features
> continue to work.
>
> I would like to have these added in .gitignore.
>
> metadata/dtd/ # used by something?
> metadata/glsa/ # used by the GLSA utilities?
> matadata/herds.xml # used by equery from gentoolkit
> metadata/news/ # used by eselect news

Heh, Robin has already taken care of these. I did not notice the
.gitignore file in the metadata subdirectory.

Re: [gentoo-dev] git commit / push signing error

[Daniel Campbell (zlg)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/10/2015 06:15 AM, Doug Goldstein wrote:
> On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn 
>  wrote:
>> Doug Goldstein schrieb:
>>> gpg: cancelled by user gpg: skipped "0xA2BC03DC87ED1BD4":
>>> Operation cancelled gpg: signing failed: Operation cancelled 
>>> error: gpg failed to sign the data
>> 
>> There was an IRC discussion yesterday about this. Probably your
>> pinentry tries to talk to a GUI and fails. Try:
>> 
>> unset DISPLAY export GPG_TTY=$(tty)
>> 
>> to make it fall back to curses, or use "eselect pinentry" to
>> select curses as default.
>> 
>> Interestingly, git requires GPG_TTY if eselect-pinentry is set to
>> gtk-2 or qt4, but repoman doesn't.
>> 
>> 
>> Best regards, Chí-Thanh Christopher Nguyễn
>> 
>> 
> 
> $ eselect pinentry show Current pinentry binary implementation: 
> pinentry-curses
> 
> $ eselect pinentry list Available pinentry binary implementations: 
> [1]   pinentry-curses *
> 
> Its the only version I've got on this machine. The box is headless
> and I ssh into and I use keychain to manage my SSH and GPG agent.
> 
What's your keychain line look like in your .bashrc/.bash_profile?
Here's the relevant portion of mine. I was also having problems with
it until I changed the order of the arguments:

[snip]
/usr/bin/keychain --agents ssh,gpg ~/.ssh/id_rsa ${GPGKEY}
source ~/.keychain/sporkbox-sh > /dev/null
source ~/.keychain/sporkbox-sh-gpg > /dev/null
[snip]

For some reason, it's important that ssh comes before gpg. I got this
advice straight from drobbins, so unless it's changed, that's the way
to get it working.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVyPVAAAoJEAEkDpRQOeFwOb4P/1o4qUuUTstuz5A57V9bGX97
D6sWioMhjjRX//951064Q7sHmQbb3CbDpUanPg0Np0devXai4OipuQCKf773OkVI
iFCHH1vm9U5qi70O7ylBKpjzfI5SLS/evlFOmP9e/wmrp482FsuODM+VqSx6i1Yb
P1wIbnttNJI/qFu23Y6XkE3cIwrzXWUrjm1ROFWir1x/xy9SwoWe3hcdy/HNVokS
jlM+RJL9bByEioWQXnxR0p2VLHr45bGXtBj+8m4rciAFFiqbNLaoGWt6+fpCR36g
YYLYPiZ4XTWUamTBtsIVBwx+t0E2oj9AReejKjIxbysUFyd0KyrVqg4Ri+YMdr0x
4j1uR9MZ39ItKjlGIncizPNjc7IAUDubxt8tuY4ndayr5lgtML4vGSbb2XDd2H3A
tlAS5QbV0k+eQQak8Mff0UmRfQE/IsWaPKe21ymBXI7wQPhrXCAZ+LwqdvTtiYJT
bFzezJ9HKTscHrRywDNPmzIDER6y6tkOdCkhjFpOGt+9zvadTN3Mt0ZJSiknZasT
35irU1s+ulFFgczW8FBm0kliFRJIf7n8BbyJpsMcIE4qekTiwRLi2x4VbrFVDn1v
/0R8sGAWNJRcSv0e9OI7oLfbT76seP+Bh5nK6Vt4szDzm+XCiPeQEZc8jCqwc9M0
PigIGXV12N6k/4usjY8e
=OUvd
-END PGP SIGNATURE-

Re: [gentoo-dev] Referencing bug reports in git

[Chí-Thanh Christopher Nguyễn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michał Górny schrieb:
>> I prefer the
>> 
>> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531
>> 
>> format even though not all bug trackers are running Bugzilla. "Bug: "
>> works fine with me too, and we could make 
>> "https://bugs.gentoo.org/show_bug.cgi?id="; optional for Gentoo bugs,
>> to accommodate for those who insist on not typing so much.
> 
> Thanks, this is exactly what I wanted.
> 
> "Fixes", "References", "Bug" are all good. "Bugzilla" goes against your 
> proposal diverging keyword depending on bug tracker software.
> 

I'd use "Bugzilla" somewhat inaccurately even for non-Bugzilla bugtrackers.
But of course that is just a minor detail, "Bug" is fine too. "Fixes" is
maybe misleading in certain cases (e.g. a partial fix or revert).


Best regards,
Chí-Thanh Christopher Nguyễn


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlXI8QsACgkQ+gvH2voEPRCtoACfeEsi/dn7bpCvaaqzYEMozCX0
4tsAn2BIsNAK1R9ZBrQfLvEPqi9161QS
=09+F
-END PGP SIGNATURE-

Re: [gentoo-dev] .gitignore

[Daniel Campbell (zlg)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/10/2015 08:09 AM, Rich Freeman wrote:
> On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert 
> wrote:
>> 
>> Expanding on this: the rsync master creates the following 
>> files/directories under metatdata. On my own system, I like to
>> symlink them to locations outside my repo so that related portage
>> features continue to work.
>> 
>> I would like to have these added in .gitignore.
>> 
>> metadata/dtd/ # used by something? metadata/glsa/ # used by the
>> GLSA utilities? matadata/herds.xml # used by equery from
>> gentoolkit metadata/news/ # used by eselect news
>> 
> 
> As a side note, it probably wouldn't hurt to set up a guide for 
> running git on /usr/portage, including setting up these symlinks, 
> running egencache after emerge --sync, etc.  I imagine that this is
> a configuration that many developers will tend to use, and with
> the advent of git we may see more users who tend to contribute
> doing the same.
> 
++

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJVyO2pAAoJEAEkDpRQOeFwmMwQAMBNw6VA3UEINvi6RgyW6NJJ
a+6QYB2RigTxOJP3nlnTXywahme1Mxtdp8X/rcebHZ0LUi5XSup+n6mGljcUHsx+
Gl09zShXoHxRdDX2JFsptt6YSVr7gXMgT83iFUDGRAKVPFIvJ4Q0jFzWjj0MD0KW
4363Oz2+5/Wdt85vKcLuT8QLG+9niEaxHab2VgauHieFYPALdTdhaEX0DTxTf/6s
M7oz8IN8p+iKbXbks0q0ZhsbJSIcOKLxE6IQ1alftFFeMkbP5wyxH5QLOFKlk6eG
oojNVXlxwvcz+nVnnYVPLhGDpPjdOndjkJ0P+uqsuLA/QIK7rwKy7VGDaFNX9zUD
2fxUNqKXstQXUBkvrzXDNDBpqWuh9v27bbS9Dx+5iJMVIUNm1YegM+JyIor9bBVT
UKeixNwYanYtWNJDGmFluc3vnIwuDqgMXC9dYrDdk3a1wPXj2l/kUmljl1wr5Ora
9BCaVSLAENg+VaNhQ8IkY5LcUnyLw/O3T4SLydqAJwc0u9+uwrcmSndwPAmRnp7U
eg/AccY1/PXARTK+u56yVzmApP6GHUz+tFIQ3frobYO3YOhT0xZojP8ecuMAkeiw
C4KRtVDRgNXmu/5FPvIMzhNNJPB0U1WFS7ZphOtGG2adRkXl4kGzmVi9QEFGGL3+
sDIclOHeOXp1LGP17Ek4
=jJqm
-END PGP SIGNATURE-

Re: [gentoo-dev] .gitignore

[Rich Freeman]

On Mon, Aug 10, 2015 at 11:04 AM, Mike Gilbert  wrote:
>
> Expanding on this: the rsync master creates the following
> files/directories under metatdata. On my own system, I like to symlink
> them to locations outside my repo so that related portage features
> continue to work.
>
> I would like to have these added in .gitignore.
>
> metadata/dtd/ # used by something?
> metadata/glsa/ # used by the GLSA utilities?
> matadata/herds.xml # used by equery from gentoolkit
> metadata/news/ # used by eselect news
>

As a side note, it probably wouldn't hurt to set up a guide for
running git on /usr/portage, including setting up these symlinks,
running egencache after emerge --sync, etc.  I imagine that this is a
configuration that many developers will tend to use, and with the
advent of git we may see more users who tend to contribute doing the
same.

-- 
Rich

Re: [gentoo-dev] .gitignore

[Mike Gilbert]

On Mon, Aug 10, 2015 at 2:42 AM, Mike Frysinger  wrote:
> On 10 Aug 2015 08:28, Justin (jlec) wrote:
>> how do we maintain this file?
>
> like any other file.  git add && git commit.
>
>> I like to propose to add the md5-cache into it. Which other files are of 
>> interest?
>
> /distfiles/
> /local/
> /packages/
>
> /metadata/md5-cache/
> -mike

Expanding on this: the rsync master creates the following
files/directories under metatdata. On my own system, I like to symlink
them to locations outside my repo so that related portage features
continue to work.

I would like to have these added in .gitignore.

metadata/dtd/ # used by something?
metadata/glsa/ # used by the GLSA utilities?
matadata/herds.xml # used by equery from gentoolkit
metadata/news/ # used by eselect news

Re: [gentoo-dev] Referencing bug reports in git

[hasufell]

On 08/10/2015 03:19 PM, Michał Górny wrote:
> 
> Thanks, this is exactly what I wanted.
> 
> "Fixes", "References", "Bug" are all good. "Bugzilla" goes against your
> proposal diverging keyword depending on bug tracker software.
> 

Afaik "Fixes: " is for referencing commits, not bug reports.

And now I am completely lost, because there are too many different
opinions on this trivial matter. I guess that means people will just use
whatever they currently like.

Re: [gentoo-dev] golang-build.eclass: add EGO_BUILD_FLAGS variable

[William Hubbs]

This is now committed.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] .gitignore

[Anthony G. Basile]

On 8/10/15 3:35 AM, Justin (jlec) wrote:

On 10/08/15 08:42, Mike Frysinger wrote:

On 10 Aug 2015 08:28, Justin (jlec) wrote:

how do we maintain this file?

like any other file.  git add && git commit.


I rather meant, if this file should only be modified after a discussion in a bug
or on a ml. Or if only QA is modifying this file. Or if anybody can play around
as she/he likes.

Justin


That's how I interpreted your original question.  I think we should 
discuss modifying .gitignore on this list, along with any other far 
reaching changes which individual committers can make to git. (Can't 
think of another example right now, but there probably is.)


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Referencing bug reports in git

[Michał Górny]

Dnia 2015-08-10, o godz. 11:45:33
Chí-Thanh Christopher Nguyễn  napisał(a):

> Ulrich Mueller schrieb:
> >> This is not a matter of going l33t, this is a matter of getting rid of
> >> redundant and pretty much useless data all the same through almost all
> >> commit messages.
> > 
> > +1
> > 
> > "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely 
> > identify a bug. Also it is easier to read (and to type) than its URL 
> > equivalent.
> 
> I'd like to make the case for a URL in commit messages, like for example
> freedesktop.org does, and also the kernel for external reports.
> 
> This allows us to treat Gentoo Bugzilla and upstream/external bug trackers
> the same.
> Besides, extracting the bug number from the URL is typically trivial. Going
> from bug number to URL is sometimes not.
> 
> Regarding the argument that bug URLs change more often than bug numbers, I
> think the number of instances when URL changed but the bug numbering didn't
> is very low. OpenOffice did this I think, but I can't think of any other
> project right now.
> 
> Here are examples from freedesktop and kernel:
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=db5337afb248edf81087cf8d74006fc496d70589
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac88cd738425e04dbed3706621cf613a00708834
> 
> I prefer the
> 
> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531
> 
> format even though not all bug trackers are running Bugzilla. "Bug: " works
> fine with me too, and we could make
> "https://bugs.gentoo.org/show_bug.cgi?id="; optional for Gentoo bugs, to
> accommodate for those who insist on not typing so much.

Thanks, this is exactly what I wanted.

"Fixes", "References", "Bug" are all good. "Bugzilla" goes against your
proposal diverging keyword depending on bug tracker software.

-- 
Best regards,
Michał Górny



pgpFZAfpl80ty.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] git commit / push signing error

[Doug Goldstein]

On Mon, Aug 10, 2015 at 3:36 AM, Chí-Thanh Christopher Nguyễn
 wrote:
> Doug Goldstein schrieb:
>> gpg: cancelled by user
>> gpg: skipped "0xA2BC03DC87ED1BD4": Operation cancelled
>> gpg: signing failed: Operation cancelled
>> error: gpg failed to sign the data
>
> There was an IRC discussion yesterday about this. Probably your pinentry
> tries to talk to a GUI and fails. Try:
>
> unset DISPLAY
> export GPG_TTY=$(tty)
>
> to make it fall back to curses, or use "eselect pinentry" to select curses as
> default.
>
> Interestingly, git requires GPG_TTY if eselect-pinentry is set to gtk-2 or
> qt4, but repoman doesn't.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

$ eselect pinentry show
Current pinentry binary implementation:
  pinentry-curses

$ eselect pinentry list
Available pinentry binary implementations:
  [1]   pinentry-curses *

Its the only version I've got on this machine. The box is headless and
I ssh into and I use keychain to manage my SSH and GPG agent.

-- 
Doug Goldstein

Re: [gentoo-dev] git commit / push signing error

[Doug Goldstein]

On Sun, Aug 9, 2015 at 9:00 PM, Kent Fredric  wrote:
> On 10 August 2015 at 13:40, Doug Goldstein  wrote:
>> $ git push --signed origin master
>>
>> You need a passphrase to unlock the secret key for
>> user: "Doug Goldstein "
>> 4096-bit RSA key, ID 0xA2BC03DC87ED1BD4, created 2015-04-24
>>  (subkey on main key ID 0x6C4E620431C9980D)
>>
>> gpg: cancelled by user
>> gpg: skipped "0xA2BC03DC87ED1BD4": Operation cancelled
>> gpg: signing failed: Operation cancelled
>> error: gpg failed to sign the data
>> fatal: failed to sign the push certificate
>> fatal: The remote end hung up unexpectedly
>
>
> Your GPG is not working correctly.
>
> eg:  echo hello | gpg -a --sign # also fails
>
> export GPG_TTY=$(tty)
>
> try again. ( The GPG-Agent associates with the tty it was spawned in
> by default, and that tty might have evaporated )
>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>

This was it. Thanks. I use keychain and ssh into the box so I would
expect keychain would handle things for me correctly.

-- 
Doug Goldstein

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Michał Górny]

Dnia 2015-08-10, o godz. 02:16:01
Andrew Savchenko  napisał(a):

> On Mon, 10 Aug 2015 00:40:44 +0200 Michał Górny wrote:
> > > > Which is terribly redundant. Just put the whole bug URL. Advantages:
> > > > 
> > > > - keeps the bug namespaced to bugs.gentoo.org,
> > > > - has the bug no inside,
> > > > - is convenient -- you can click it instead of copy-pasting the no.
> > > 
> > > 1. URL may change in future, bug number — unlikely.
> > 
> > If the URL changes, we need to provide backwards compatibility. Too
> > many resources already depend on that.
> > 
> > > 2. Bug number can be easily typed, URL has to be copied or
> > > generated by some tool.
> > 
> > So, please remind me, how many times the 'easy typing' got the bug
> > number wrong? This is not a real argument, just another of Gentoo's
> > 'I'm too lazy to do things right'.
> 
> URLs are longer, so probability of error during typing increases
> compared to raw numbers.

Not really. You are closer to the threshold when you are too lazy to
type it and you just copy-paste it.

> > > 3. Too many text, hard to read. Some bugs may refer to a dozen of
> > > URLs.
> > 
> > And how is a dozen numbers better?
> 
> Less text, more readable.

How is:

  Bug: 123451, 453445, 344334, 343444

more readable than:

  Bug: https://bugs.gentoo.org/123451
  Bug: https://bugs.gentoo.org/453445
  Bug: https://bugs.gentoo.org/344334
  Bug: https://bugs.gentoo.org/343444

Readability is a matter of formatting, not contents.

> > > 4. It is easier to copy a number, than selecting and copying whole
> > > string. Not all terminals support running browser on URL click.
> > 
> > So we should optimize for a corner case?
> 
> What is a corner case? Why not defining "clicking on the link in
> the git log" as a corner case?

As far as I'm aware, URLs are supported much more widely than
Gentoo-specific bug numbers. They are uniform and unique by definition.
The tools using bug numbers can be easily expanded to extract them from
URLs. I don't really see forking cgit to support Gentoo bug numbers, or
asking github to provide special rules for our commits.

> > > 5. Clicking is less convenient than typing "bugs search $number" —
> > > user have to move hands from a keyboard to a mouse — a terrible
> > > waste of time, at least in my case with my typing speed.
> > 
> > You can type the number you see at the end of the URL. If you really
> > want to go l33t, that shouldn't a problem for you.
>  
> This is not a matter of going l33t, this is a matter of getting rid
> of redundant and pretty much useless data all the same through
> almost all commit messages.

Which reminds me of the metadata.xml discussion. These days we have
transparent compression which handles redundant data much better than
explicit obfuscation, and with much less harm.

-- 
Best regards,
Michał Górny



pgp4YORhnUYTk.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: Referencing bug reports in git

[Duncan]

hasufell posted on Mon, 10 Aug 2015 03:02:43 +0200 as excerpted:

> On 08/10/2015 02:51 AM, Ulrich Mueller wrote:
>>> On Mon, 10 Aug 2015, Andrew Savchenko wrote:
>> 
>>> This is not a matter of going l33t, this is a matter of getting rid of
>>> redundant and pretty much useless data all the same through almost all
>>> commit messages.
>> 
>> +1
>> 
>> "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely
>> identify a bug. Also it is easier to read (and to type) than its URL
>> equivalent.
>> 
>> 
> So, would this replace the bug number reference in the summary? Should
> we tell people to reference the bug only in the commit message
> description?
> 
> Or do we say:
> * bug number in summary optional
> * bug number in description mandatory via "Gentoo-Bug: 1234"

What about:

* bug number in summary strongly recommended
** summary bug number standardized to GB#xx or #xx or similar, 
short enough for summary, easily identified. GB# would be distinctly 
gentoo and could be expanded to KDEB#, GNB# (gnome), FDOB#, etc, for 
projects where users likely to want to see the bug likely know what it is.
** summary lists gentoo bug if any, upstream only if no gentoo bug.

* bug URL in description required.
** standardized to Gentoo-Bug: ...
** gives people wanting something to click a way to do so
** U in URL is universal, unambiguously identifies reference for those 
unfamiliar with summary shorthand.
** Multiple allowed, for multiple gentoo bugs or to identify upstream 
bugs (using FDO-Bug: or similar) as well.

That seems a reasonable compromise, given people pulling both ways
in-thread.

-- 
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-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-process/anacron/

[hasufell]

On 08/10/2015 10:00 AM, Mike Frysinger wrote:
> commit: 2f168392284fec294f9bfbb06d1c0a8a46f5a7d5
> Author: Mike Frysinger  gentoo  org>
> AuthorDate: Mon Aug 10 07:39:36 2015 +
> Commit: Mike Frysinger  gentoo  org>
> CommitDate: Mon Aug 10 07:59:50 2015 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2f168392
> 
> anacron: improve CFLAGS/CC handling
> 
> Rather than expand CFLAGS in the sed statement, pass it via the env later
> on when running make.
> 
> Make sure we set up CC to a sane default.
> 

Your commit messages still don't follow "CATEGORY/PN".

Re: [gentoo-dev] Referencing bug reports in git

[Ulrich Mueller]

> On Mon, 10 Aug 2015, Chí-Thanh Christopher Nguyễn wrote:

> I prefer the

> Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531

> format even though not all bug trackers are running Bugzilla.
> "Bug: " works fine with me too,

There are bug trackers other than bugzilla, for example
debbugs.gnu.org. So I think using "Bugzilla:" wouldn't be such a good
idea.

> and we could make "https://bugs.gentoo.org/show_bug.cgi?id=";
> optional for Gentoo bugs, to accommodate for those who insist on not
> typing so much.

Ulrich


pgpoJhawBxg7E.pgp
Description: PGP signature

Re: [gentoo-dev] Referencing bug reports in git

[Chí-Thanh Christopher Nguyễn]

Ulrich Mueller schrieb:
>> This is not a matter of going l33t, this is a matter of getting rid of
>> redundant and pretty much useless data all the same through almost all
>> commit messages.
> 
> +1
> 
> "Gentoo-Bug: 123456" or even "Bug: 123456" is enough to uniquely 
> identify a bug. Also it is easier to read (and to type) than its URL 
> equivalent.

I'd like to make the case for a URL in commit messages, like for example
freedesktop.org does, and also the kernel for external reports.

This allows us to treat Gentoo Bugzilla and upstream/external bug trackers
the same.
Besides, extracting the bug number from the URL is typically trivial. Going
from bug number to URL is sometimes not.

Regarding the argument that bug URLs change more often than bug numbers, I
think the number of instances when URL changed but the bug numbering didn't
is very low. OpenOffice did this I think, but I can't think of any other
project right now.

Here are examples from freedesktop and kernel:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=db5337afb248edf81087cf8d74006fc496d70589
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac88cd738425e04dbed3706621cf613a00708834

I prefer the

Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=333531

format even though not all bug trackers are running Bugzilla. "Bug: " works
fine with me too, and we could make
"https://bugs.gentoo.org/show_bug.cgi?id="; optional for Gentoo bugs, to
accommodate for those who insist on not typing so much.


Best regards,
Chí-Thanh Christopher Nguyễn




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] git commit / push signing error

[Chí-Thanh Christopher Nguyễn]

Doug Goldstein schrieb:
> gpg: cancelled by user
> gpg: skipped "0xA2BC03DC87ED1BD4": Operation cancelled
> gpg: signing failed: Operation cancelled
> error: gpg failed to sign the data

There was an IRC discussion yesterday about this. Probably your pinentry
tries to talk to a GUI and fails. Try:

unset DISPLAY
export GPG_TTY=$(tty)

to make it fall back to curses, or use "eselect pinentry" to select curses as
default.

Interestingly, git requires GPG_TTY if eselect-pinentry is set to gtk-2 or
qt4, but repoman doesn't.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] .gitignore

[Justin (jlec)]

On 10/08/15 08:42, Mike Frysinger wrote:
> On 10 Aug 2015 08:28, Justin (jlec) wrote:
>> how do we maintain this file?
> 
> like any other file.  git add && git commit.
> 

I rather meant, if this file should only be modified after a discussion in a bug
or on a ml. Or if only QA is modifying this file. Or if anybody can play around
as she/he likes.

Justin




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)

[Andrew Savchenko]

On Sun, 9 Aug 2015 17:02:27 -0700 Daniel Campbell (zlg) wrote:
> I don't know about you guys, but I have a "smart bookmark" in Firefox
> where I type "bgo xx" and it'll take me to the relevant bug. It'd
> be trivial to set that up as a bash alias, too. There are tons of ways
> to get to a bug; the important part is the bug number. I think putting
> the URL in there adds extra work for us later down the road should we
> migrate away from Bugzilla.

Same here, but "gentoo $number" in the URL field.

Best regards,
Andrew Savchenko


pgpR_HPHe1iEN.pgp
Description: PGP signature

Re: [gentoo-dev] .gitignore

[Mike Frysinger]

On 10 Aug 2015 09:17, Michał Górny wrote:
> Dnia 2015-08-10, o godz. 02:42:21 Mike Frysinger napisał(a):
> > On 10 Aug 2015 08:28, Justin (jlec) wrote:
> > > I like to propose to add the md5-cache into it. Which other files are of 
> > > interest?
> > 
> > /distfiles/
> > /local/
> > /packages/
> 
> Those directories should not be ignored. Those should not exist for
> a long time.

there's no reason people can't use these on their own system.  there's no
reason they should be added to the git repo which means, if a user opted
to utilize them, they should be ignored.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: useflag policies

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/08/15 21:38, Sergey Popov wrote:
> 
> 
> In short - apropriate REQUIRED_USE with setting recommended 
> USE-flag(e.g. USE="+qt4 qt5" or USE="qt4 +qt5")
> 
> 
Strong -1.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVyFJ0AAoJENQqWdRUGk8BdYkP/3ZNmUAawdlBnX7Bjlc8io0c
AGVTFCFX8tjbu4nnx1jZe9ZXB3SEBfHs8rb8/I/9h6BmDUi9jU2ca7E9Iw27/IDg
qxd7xy+iGY00IjLgtWooI06ELJRv7KHxAAOb9UOpJuRZvxW4a1MaUgE2lddy+c9r
7wNJaHjgdkm9qJOejaf/kWiYpwOM6HYWZlV9Mq7EV3Jzn1K9u8gRJDB9Rf0uIwoe
Tt/bD1wbQvMKzgDXdxh8zlNaI6F2v+xUFF8UJqjtEptjVHN/BFGTL8Rxbdm39eIk
PqiyfMQsjGSk6OLJe60dD5nnRHxwVz+r97O9Kwag7bGdaTeRB9/8zITHHe5GgvbW
v3ibxSfS1/2rOmynMJmj1/tFeFyulDcAhajUdB6dpX/Pv2wyUN8SluezrT0VIb1G
IGMkzRAzqwYAbdhe/y6YcO6lFtKDcET4NpuLo6cHhDzYmkcHWjcROHOOghtpLL9w
TvYwyQmCA4BN9y/NBw6Sw80TeumRKGr0Uh1SyvNwb/JaMRWEvR0NdfljOtPk4cjS
mf55dWs85wrZTSvqpNS1riAI+UIXeB5A/Rwb4F/mvvV4B0tabnoPMxyNGqk7ZP+n
AC4pCMoI29saUedBjl+Em8iG1dYL2KCAUE4ItONl74AchzQBToN1zcpHegEBGKjt
cCJj84GIjFWf3BVm63xa
=MKyo
-END PGP SIGNATURE-

Re: [gentoo-dev] .gitignore

[Michał Górny]

Dnia 2015-08-10, o godz. 02:42:21
Mike Frysinger  napisał(a):

> On 10 Aug 2015 08:28, Justin (jlec) wrote:
> > how do we maintain this file?
> 
> like any other file.  git add && git commit.
> 
> > I like to propose to add the md5-cache into it. Which other files are of 
> > interest?
> 
> /distfiles/
> /local/
> /packages/

Those directories should not be ignored. Those should not exist for
a long time.

-- 
Best regards,
Michał Górny



pgpVSkSQ_UyrJ.pgp
Description: OpenPGP digital signature