[gentoo-dev] Tinderboxing efforts in Gentoo

[Michał Górny]

Hi, everyone.

I've heard multiple times about various tinderbox projects being
started by individuals in Gentoo. In fact, so many different projects
that I've forgotten who was working on most of them.

I know that Toralf is doing tinderboxing for most of the stuff.
What other projects do we have there? What is their status?

Is there anything we could try to integrate with pull requests to get
a better testing?

-- 
Best regards,
Michał Górny



pgpPRX9gJ3dnn.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Please retain authorship of contributed patches

[Michael Mol]

On Thursday, December 01, 2016 10:13:17 PM Andrey Utkin wrote:
> On Thu, Dec 01, 2016 at 12:50:42PM -0800, Daniel Campbell wrote:

[snip]

> > Thanks for bringing this to attention. It's somewhat related to another
> > discussion we've been having about copyright, and it may be worth
> > considering protocol for situations like the one you've outlined.
> 
> Could you  please give a link to archives of that discussion?

It looks like there's two of them. Daniel's probably thinking of this one:

https://archives.gentoo.org/gentoo-dev/message/d58dd815aa48df69afb9d096754c0d04


But this one is also relevant:

https://archives.gentoo.org/gentoo-dev/message/63dcd62b33080a2e29f1ec4f3b484b51

(Deep linking in the second thread, as that's when copyright was first brought 
up in it, dealing with DCOs.)

-- 
:wq

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Michael Mol]

On Friday, December 02, 2016 02:10:27 PM Michał Górny wrote:
> Hi, everyone.
> 
> I've heard multiple times about various tinderbox projects being
> started by individuals in Gentoo. In fact, so many different projects
> that I've forgotten who was working on most of them.
> 
> I know that Toralf is doing tinderboxing for most of the stuff.
> What other projects do we have there? What is their status?
> 
> Is there anything we could try to integrate with pull requests to get
> a better testing?

If there's a mostly-turnkey VM I can run to contribute to Tinderboxing, I have 
one or two systems I could benefit from some heat from over the winter. It's 
that or bring out the electric space heater. Was talking with my wife about 
mining Doge on one of them last night...

-- 
:wq

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Revision bumps vs git commits atomicity

[Andrew Savchenko]

Hi all!

Right now we have two somewhat conflicting policies (at least up to
my understanding of them):

1) git atomic commits [1]:
each logical change should be a separate commit.

2) revision bump policy [2]:
each change sufficiently affecting application run-time or
installed files should have a revision bump.

Let's consider the following quite common scenario: package foo-1.0
should be updated to foo-1.1, but aside from version bump there is
a set of accumulated issues which maintainer is willing to handle,
e.g.:
- bump to EAPI 6;
- fix several runtime bugs (still present in the new version);
- install missing documentation;
- add previously omitted USE flags for some tools of controllable
functionalities;
- etc...

If both policies are to be followed, users will see something like:
foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
a separate commit with a revision bump).

While such versioning change is technically correct, it is
confusing for our users and makes future maintainance harder,
because of multiple file renames (yeah, I know about git diff
--find-renames, but this kludge is not perfect).

What about the following forkflow:
- version bump first with minimal changes required, but without
pushing commit to the tree;
- make each logical change as a separate commit without revision
bumps and without pushing stuff to the tree (of course repoman
scan/full is required as usual for each commit);
- well test package after the last commit (that it builds with
various USE flag combinations, old and new functionality works fine
and so on);
- fix any problems found and only afterwards push changes to the
tree.

This way users will see only foo-1.0 -> foo-1.1 change in the tree,
while git will still retain each logical change as a separate
commit, which will make future maintenance and debugging much
easier.

Of course a separate git branch may be used as well, but using
branches for each half-a-dozen set of commits looks like an
overkill to me.

Thoughts, comments?

[1] https://devmanual.gentoo.org/ebuild-maintenance/index.html
[2] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

Best regards,
Andrew Savchenko


pgp0YeSDAqe67.pgp
Description: PGP signature

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Dirkjan Ochtman]

On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko  wrote:
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (of course repoman
> scan/full is required as usual for each commit);
> - well test package after the last commit (that it builds with
> various USE flag combinations, old and new functionality works fine
> and so on);
> - fix any problems found and only afterwards push changes to the
> tree.
>
> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> while git will still retain each logical change as a separate
> commit, which will make future maintenance and debugging much
> easier.
>
> Of course a separate git branch may be used as well, but using
> branches for each half-a-dozen set of commits looks like an
> overkill to me.
>
> Thoughts, comments?

Sounds sensible to me, possibly to the point of not having to spell it
out? (As in, I don't see the mentioned policies as necessarily
conflicting.)

Cheers,

Dirkjan

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Ian Stakenvicius]

On 02/12/16 10:32 AM, Dirkjan Ochtman wrote:
> On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko  wrote:
>> What about the following forkflow:
>> - version bump first with minimal changes required, but without
>> pushing commit to the tree;
>> - make each logical change as a separate commit without revision
>> bumps and without pushing stuff to the tree (of course repoman
>> scan/full is required as usual for each commit);
>> - well test package after the last commit (that it builds with
>> various USE flag combinations, old and new functionality works fine
>> and so on);
>> - fix any problems found and only afterwards push changes to the
>> tree.
>>
>> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
>> while git will still retain each logical change as a separate
>> commit, which will make future maintenance and debugging much
>> easier.
>>
>> Of course a separate git branch may be used as well, but using
>> branches for each half-a-dozen set of commits looks like an
>> overkill to me.
>>
>> Thoughts, comments?
> 
> Sounds sensible to me, possibly to the point of not having to spell it
> out? (As in, I don't see the mentioned policies as necessarily
> conflicting.)
> 
> Cheers,
> 
> Dirkjan
> 

If it matters, it may make sense to adhere to the order of operations
presented above more precisely.  For instance, I tend to do all of the
minor changes first and then revbump the ebuild (usually because I'm
adjusting these changes over a few days and then evaluate if it needs
a revbump once it's done).




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Michael Orlitzky]

On 12/02/2016 10:14 AM, Andrew Savchenko wrote:
> 
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
> 
> While such versioning change is technically correct, it is
> confusing for our users and makes future maintainance harder,
> because of multiple file renames (yeah, I know about git diff
> --find-renames, but this kludge is not perfect).

Do you have a situation in mind where going from -r0 to -r8 in one `git
push` is a problem? What maintenance becomes harder? I can see how it
could be confusing, but only in the sense that we've been doing it wrong
for so long that now it's surprising to see it done right. Now it makes
sense: the -r8 version contains 8 more fixes than -r0.

I should be able to `git checkout` any commit in the repo and have the
tree not be broken. Your proposal eliminates that guarantee, and the bar
for doing so should be high, I think.

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Michał Górny]

On Fri, 2 Dec 2016 18:14:05 +0300
Andrew Savchenko  wrote:

> Hi all!
> 
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
> 
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
> 
> 2) revision bump policy [2]:
> each change sufficiently affecting application run-time or
> installed files should have a revision bump.
> 
> Let's consider the following quite common scenario: package foo-1.0
> should be updated to foo-1.1, but aside from version bump there is
> a set of accumulated issues which maintainer is willing to handle,
> e.g.:
> - bump to EAPI 6;
> - fix several runtime bugs (still present in the new version);
> - install missing documentation;
> - add previously omitted USE flags for some tools of controllable
> functionalities;
> - etc...
> 
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
> 
> While such versioning change is technically correct, it is
> confusing for our users and makes future maintainance harder,
> because of multiple file renames (yeah, I know about git diff
> --find-renames, but this kludge is not perfect).

To be honest, I don't really see how multiple successive renames are
really any worse than a single rename in git. Not that I oppose your
idea, just nitpicking.

> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (of course repoman
> scan/full is required as usual for each commit);
> - well test package after the last commit (that it builds with
> various USE flag combinations, old and new functionality works fine
> and so on);
> - fix any problems found and only afterwards push changes to the
> tree.
> 
> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> while git will still retain each logical change as a separate
> commit, which will make future maintenance and debugging much
> easier.

Well, this is pretty much what we're doing and what fits common sense,
and I'm not sure if we really need to word this into a formal policy.

The definition of 'one logical change' is pretty inconclusive. One
could claim the whole bump to be one logical change, and I don't think
that we should really force people to split every change into a single
commit because it is too cumbersome.

What really makes sense is using the common sense to determine which
changes are best made together, and which really deserve a separate
commit. And of course, once a revbump or version bump is necessary, you
have to do it on the first commit involved (to avoid altering the old
file, in case you are keeping it) and you don't have to bump further
until the thing hits users.

What we need to keep in mind is the spirit of doing split commits --
it's meant to:

a) ease reviewing, through providing better context for each change,

b) ease reverting, especially in case one of the changes is more likely
to cause mayhem than others.

-- 
Best regards,
Michał Górny



pgpUt4Jm3Vurw.pgp
Description: OpenPGP digital signature

[gentoo-dev] Uppercase characters in package names

[Mike Gilbert]

The devmanual states:

The name section should contain only lowercase non-accented letters,
the digits 0-9, hyphens, underscores and plus characters. Uppercase
characters are strongly discouraged, but technically valid.

https://devmanual.gentoo.org/ebuild-writing/file-format/index.html


Why are uppercase characters strongly discouraged?

Wouldn't it make sense to follow upstream's naming convention?

Re: [gentoo-dev] Uppercase characters in package names

[Brian Dolbec]

On Fri, 2 Dec 2016 13:02:48 -0500
Mike Gilbert  wrote:

> The devmanual states:
> 
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
> Why are uppercase characters strongly discouraged?
> 
> Wouldn't it make sense to follow upstream's naming convention?
> 

I think so.

In at least one of the pkgs I created, I used mixed case to prevent
conflicts with other existing projects that google, pypi, etc.
searching returned results for.  But still have the name represent what
it did.

-- 
Brian Dolbec 

Re: [gentoo-dev] Uppercase characters in package names

[Ciaran McCreesh]

On Fri, 2 Dec 2016 13:02:48 -0500
Mike Gilbert  wrote:
> The devmanual states:
> 
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
> Why are uppercase characters strongly discouraged?
> 
> Wouldn't it make sense to follow upstream's naming convention?

What's upstream's naming convention for Firefox?

-- 
Ciaran McCreesh

Re: [gentoo-dev] Uppercase characters in package names

[Mart Raudsepp]

Ühel kenal päeval, R, 02.12.2016 kell 13:02, kirjutas Mike Gilbert:
> The devmanual states:
> 
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
> Why are uppercase characters strongly discouraged?
> 
> Wouldn't it make sense to follow upstream's naming convention?

It's much easier to just write all in lowercase for emerge, because it
is case sensitive and won't directly work (only hopefully show how it's
capitalized in the suggestions it prints if no direct match is found).
So usually lowercase means there's no guessing which happens to be
upper case to feed to emerge.
Less important for stuff people usually don't install, but are usually
only pulled in as a dependency of something.

Re: [gentoo-dev] Uppercase characters in package names

[Mike Gilbert]

On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
 wrote:
> On Fri, 2 Dec 2016 13:02:48 -0500
> Mike Gilbert  wrote:
>> The devmanual states:
>>
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
>>
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>
>>
>> Why are uppercase characters strongly discouraged?
>>
>> Wouldn't it make sense to follow upstream's naming convention?
>
> What's upstream's naming convention for Firefox?
>

I have no idea. What's your point?

Re: [gentoo-dev] Uppercase characters in package names

[Ciaran McCreesh]

On Fri, 2 Dec 2016 13:24:29 -0500
Mike Gilbert  wrote:
> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>  wrote:
> > On Fri, 2 Dec 2016 13:02:48 -0500
> > Mike Gilbert  wrote:  
> >> The devmanual states:
> >>
> >> The name section should contain only lowercase non-accented
> >> letters, the digits 0-9, hyphens, underscores and plus characters.
> >> Uppercase characters are strongly discouraged, but technically
> >> valid.
> >>
> >> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> >>
> >>
> >> Why are uppercase characters strongly discouraged?
> >>
> >> Wouldn't it make sense to follow upstream's naming convention?  
> >
> > What's upstream's naming convention for Firefox?
> 
> I have no idea. What's your point?

That naming conventions are generally complicated and a mess, and that
no-one wants to have to remember whether it's firefox, Firefox, or
FireFox.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Uppercase characters in package names

[Ulrich Mueller]

> On Fri, 2 Dec 2016, Mike Gilbert wrote:

> The devmanual states:
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.

> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html


> Why are uppercase characters strongly discouraged?

> Wouldn't it make sense to follow upstream's naming convention?

No, because even for the most common packages it would be hard to
guess what the actual convention is. For example, is it GCC (used on
its web page and in documentation) or gcc (name of the command and
displayed by gcc --version)?

If we allow uppercase, then should we also allow two packages in the
tree whose names differ only in character case?

Ulrich


pgpb6LpA6sSWR.pgp
Description: PGP signature

Re: [gentoo-dev] Uppercase characters in package names

[Mike Gilbert]

On Fri, Dec 2, 2016 at 1:28 PM, Ulrich Mueller  wrote:
>> On Fri, 2 Dec 2016, Mike Gilbert wrote:
>
>> The devmanual states:
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
>
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>
>
>> Why are uppercase characters strongly discouraged?
>
>> Wouldn't it make sense to follow upstream's naming convention?
>
> No, because even for the most common packages it would be hard to
> guess what the actual convention is. For example, is it GCC (used on
> its web page and in documentation) or gcc (name of the command and
> displayed by gcc --version)?

As a developer I would tend to match the tarball naming to minimize
the amount of customization needed in SRC_URI and avoid having to
redefine S.

> If we allow uppercase, then should we also allow two packages in the
> tree whose names differ only in character case?

Do we prohibit this currently?

Anyway, this seems like a pretty unlikely thing to have happen.

Re: [gentoo-dev] Uppercase characters in package names

[Mike Gilbert]

On Fri, Dec 2, 2016 at 1:31 PM, Ciaran McCreesh
 wrote:
> On Fri, 2 Dec 2016 13:24:29 -0500
> Mike Gilbert  wrote:
>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>>  wrote:
>> > On Fri, 2 Dec 2016 13:02:48 -0500
>> > Mike Gilbert  wrote:
>> >> The devmanual states:
>> >>
>> >> The name section should contain only lowercase non-accented
>> >> letters, the digits 0-9, hyphens, underscores and plus characters.
>> >> Uppercase characters are strongly discouraged, but technically
>> >> valid.
>> >>
>> >> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>> >>
>> >>
>> >> Why are uppercase characters strongly discouraged?
>> >>
>> >> Wouldn't it make sense to follow upstream's naming convention?
>> >
>> > What's upstream's naming convention for Firefox?
>>
>> I have no idea. What's your point?
>
> That naming conventions are generally complicated and a mess, and that
> no-one wants to have to remember whether it's firefox, Firefox, or
> FireFox.

A valid point, thank you for clarifying.

I will note that portage's spelling suggestion feature comes in handy here.

Re: [gentoo-dev] Uppercase characters in package names

[Ian Stakenvicius]

On 02/12/16 01:31 PM, Ciaran McCreesh wrote:
> On Fri, 2 Dec 2016 13:24:29 -0500
> Mike Gilbert  wrote:
>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>>  wrote:
>>> On Fri, 2 Dec 2016 13:02:48 -0500
>>> Mike Gilbert  wrote:  
 The devmanual states:

 The name section should contain only lowercase non-accented
 letters, the digits 0-9, hyphens, underscores and plus characters.
 Uppercase characters are strongly discouraged, but technically
 valid.

 https://devmanual.gentoo.org/ebuild-writing/file-format/index.html


 Why are uppercase characters strongly discouraged?

 Wouldn't it make sense to follow upstream's naming convention?  
>>>
>>> What's upstream's naming convention for Firefox?
>>
>> I have no idea. What's your point?
> 
> That naming conventions are generally complicated and a mess, and that
> no-one wants to have to remember whether it's firefox, Firefox, or
> FireFox.
> 

It's also more convenient at the consone to just type everything
lowercase.  I expect that's the primary reason it's discouraged.






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Michał Górny]

On Fri, 2 Dec 2016 13:02:48 -0500
Mike Gilbert  wrote:

> The devmanual states:
> 
> The name section should contain only lowercase non-accented letters,
> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> characters are strongly discouraged, but technically valid.
> 
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
> Why are uppercase characters strongly discouraged?
> 
> Wouldn't it make sense to follow upstream's naming convention?

I'd say keeping things lowercase makes sense for end user packages. For
pure dependencies with consistent conventions (e.g. perl), it makes
sense to keep upstream's naming.

-- 
Best regards,
Michał Górny



pgpsAvUuLjzg2.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Matt Turner]

On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko  wrote:
> Hi all!
>
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
>
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
>
> 2) revision bump policy [2]:
> each change sufficiently affecting application run-time or
> installed files should have a revision bump.
>
> Let's consider the following quite common scenario: package foo-1.0
> should be updated to foo-1.1, but aside from version bump there is
> a set of accumulated issues which maintainer is willing to handle,
> e.g.:
> - bump to EAPI 6;
> - fix several runtime bugs (still present in the new version);
> - install missing documentation;
> - add previously omitted USE flags for some tools of controllable
> functionalities;
> - etc...
>
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
>
> While such versioning change is technically correct, it is
> confusing for our users and makes future maintainance harder,
> because of multiple file renames (yeah, I know about git diff
> --find-renames, but this kludge is not perfect).
>
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (of course repoman
> scan/full is required as usual for each commit);
> - well test package after the last commit (that it builds with
> various USE flag combinations, old and new functionality works fine
> and so on);
> - fix any problems found and only afterwards push changes to the
> tree.
>
> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> while git will still retain each logical change as a separate
> commit, which will make future maintenance and debugging much
> easier.
>
> Of course a separate git branch may be used as well, but using
> branches for each half-a-dozen set of commits looks like an
> overkill to me.
>
> Thoughts, comments?

Thanks for starting the discussion. I completely agree.

Though my case might have been a bit more clear-cut since I was
working on an ebuild that initially didn't have any KEYWORDS, I think
what I did for freeradius is the best way of handling the situation
you describe.

See 97704b400b7^..e84dc52a816

An initial commit that copied the 3.0.12 ebuild to 3.0.12-r1 without
making any other changes, followed by three self-contained
fixes/commits, and finally a patch to add KEYWORDS to 3.0.12-r1.

Re: [gentoo-dev] Uppercase characters in package names

[William Hubbs]

On Fri, Dec 02, 2016 at 07:47:01PM +0100, Michał Górny wrote:
> On Fri, 2 Dec 2016 13:02:48 -0500
> Mike Gilbert  wrote:
> 
> > The devmanual states:
> > 
> > The name section should contain only lowercase non-accented letters,
> > the digits 0-9, hyphens, underscores and plus characters. Uppercase
> > characters are strongly discouraged, but technically valid.
> > 
> > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> > 
> > 
> > Why are uppercase characters strongly discouraged?
> > 
> > Wouldn't it make sense to follow upstream's naming convention?
> 
> I'd say keeping things lowercase makes sense for end user packages. For
> pure dependencies with consistent conventions (e.g. perl), it makes
> sense to keep upstream's naming.

I'm not advocating renaming this, but I found an example of this when
looking to package something:

dev-python/configargparse is called ConfigArgParse upstream.
If we had named it dev-python/ConfigArgParse, we wouldn't need to set
MY_PN, MY_P or S in our ebuild, and I wouldn't have had to check the
package to see if it was the same as the package I need to depend on.

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Brian Dolbec]

On Fri, 2 Dec 2016 13:38:19 -0600
William Hubbs  wrote:

> On Fri, Dec 02, 2016 at 07:47:01PM +0100, Michał Górny wrote:
> > On Fri, 2 Dec 2016 13:02:48 -0500
> > Mike Gilbert  wrote:
> >   
> > > The devmanual states:
> > > 
> > > The name section should contain only lowercase non-accented
> > > letters, the digits 0-9, hyphens, underscores and plus
> > > characters. Uppercase characters are strongly discouraged, but
> > > technically valid.
> > > 
> > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> > > 
> > > 
> > > Why are uppercase characters strongly discouraged?
> > > 
> > > Wouldn't it make sense to follow upstream's naming convention?  
> > 
> > I'd say keeping things lowercase makes sense for end user packages.
> > For pure dependencies with consistent conventions (e.g. perl), it
> > makes sense to keep upstream's naming.  
> 
> I'm not advocating renaming this, but I found an example of this when
> looking to package something:
> 
> dev-python/configargparse is called ConfigArgParse upstream.
> If we had named it dev-python/ConfigArgParse, we wouldn't need to set
> MY_PN, MY_P or S in our ebuild, and I wouldn't have had to check the
> package to see if it was the same as the package I need to depend on.
> 
> William
> 

It gets worse than that.  I recently added several pkg to the tree that
had slightly different names for the github repo than they publishedin pypi. 
I in turn ended up naming it slightly different to fit our
category/pkg system.  So, the end result is not one common name, but
three.  For some, I tried to stick with the github repo name, despite
getting the tarball from pypi due to the inconsistent github sha's.

-- 
Brian Dolbec 



pgpCuU6XZuV45.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Cleanup. Remove die from global, scope per EAPI 6 rules

[Mike Pagano]

On 12/01/2016 07:27 PM, Mike Pagano wrote:
> EAPI 6 prohibits dying in global scope.  Move that check to pkg_setup.
> 
> ---
>  eclass/kernel-2.eclass | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Committed

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Mart Raudsepp]

Ühel kenal päeval, R, 02.12.2016 kell 11:26, kirjutas Matt Turner:
> On Fri, Dec 2, 2016 at 7:14 AM, Andrew Savchenko 
> wrote:
> > 
> > Hi all!
> > 
> > Right now we have two somewhat conflicting policies (at least up to
> > my understanding of them):
> > 
> > 1) git atomic commits [1]:
> > each logical change should be a separate commit.
> > 
> > 2) revision bump policy [2]:
> > each change sufficiently affecting application run-time or
> > installed files should have a revision bump.
> > 
> > Let's consider the following quite common scenario: package foo-1.0
> > should be updated to foo-1.1, but aside from version bump there is
> > a set of accumulated issues which maintainer is willing to handle,
> > e.g.:
> > - bump to EAPI 6;
> > - fix several runtime bugs (still present in the new version);
> > - install missing documentation;
> > - add previously omitted USE flags for some tools of controllable
> > functionalities;
> > - etc...
> > 
> > If both policies are to be followed, users will see something like:
> > foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> > a separate commit with a revision bump).
> > 
> > While such versioning change is technically correct, it is
> > confusing for our users and makes future maintainance harder,
> > because of multiple file renames (yeah, I know about git diff
> > --find-renames, but this kludge is not perfect).
> > 
> > What about the following forkflow:
> > - version bump first with minimal changes required, but without
> > pushing commit to the tree;
> > - make each logical change as a separate commit without revision
> > bumps and without pushing stuff to the tree (of course repoman
> > scan/full is required as usual for each commit);
> > - well test package after the last commit (that it builds with
> > various USE flag combinations, old and new functionality works fine
> > and so on);
> > - fix any problems found and only afterwards push changes to the
> > tree.
> > 
> > This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> > while git will still retain each logical change as a separate
> > commit, which will make future maintenance and debugging much
> > easier.
> > 
> > Of course a separate git branch may be used as well, but using
> > branches for each half-a-dozen set of commits looks like an
> > overkill to me.
> > 
> > Thoughts, comments?
> 
> Thanks for starting the discussion. I completely agree.
> 
> Though my case might have been a bit more clear-cut since I was
> working on an ebuild that initially didn't have any KEYWORDS, I think
> what I did for freeradius is the best way of handling the situation
> you describe.
> 
> See 97704b400b7^..e84dc52a816
> 
> An initial commit that copied the 3.0.12 ebuild to 3.0.12-r1 without
> making any other changes, followed by three self-contained
> fixes/commits, and finally a patch to add KEYWORDS to 3.0.12-r1.
> 

That makes me think that it might be an idea to have no KEYWORDS on the
intermediate commits. So removing them at first for the -r1 copy in tis
example, even if -r0 had them, and then after all is done add back
~arch ones.
Just an idea, not even sure I think it's a good idea myself.

Re: [gentoo-dev] Uppercase characters in package names

[Michał Górny]

On Fri, 2 Dec 2016 13:38:19 -0600
William Hubbs  wrote:

> On Fri, Dec 02, 2016 at 07:47:01PM +0100, Michał Górny wrote:
> > On Fri, 2 Dec 2016 13:02:48 -0500
> > Mike Gilbert  wrote:
> >   
> > > The devmanual states:
> > > 
> > > The name section should contain only lowercase non-accented letters,
> > > the digits 0-9, hyphens, underscores and plus characters. Uppercase
> > > characters are strongly discouraged, but technically valid.
> > > 
> > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> > > 
> > > 
> > > Why are uppercase characters strongly discouraged?
> > > 
> > > Wouldn't it make sense to follow upstream's naming convention?  
> > 
> > I'd say keeping things lowercase makes sense for end user packages. For
> > pure dependencies with consistent conventions (e.g. perl), it makes
> > sense to keep upstream's naming.  
> 
> I'm not advocating renaming this, but I found an example of this when
> looking to package something:
> 
> dev-python/configargparse is called ConfigArgParse upstream.
> If we had named it dev-python/ConfigArgParse, we wouldn't need to set
> MY_PN, MY_P or S in our ebuild, and I wouldn't have had to check the
> package to see if it was the same as the package I need to depend on.

I should also add a statistical point that I've already seen 2 or 3
times Gentoo developers committing duplicate packages (i.e. missing
a package already there, under a different name/category).

-- 
Best regards,
Michał Górny



pgpMq1hIeDtnl.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Mike Gilbert]

On Fri, Dec 2, 2016 at 1:47 PM, Michał Górny  wrote:
> On Fri, 2 Dec 2016 13:02:48 -0500
> Mike Gilbert  wrote:
>
>> The devmanual states:
>>
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
>>
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>
>>
>> Why are uppercase characters strongly discouraged?
>>
>> Wouldn't it make sense to follow upstream's naming convention?
>
> I'd say keeping things lowercase makes sense for end user packages. For
> pure dependencies with consistent conventions (e.g. perl), it makes
> sense to keep upstream's naming.
>

This seems like a reasonable approach. Thanks.

Re: [gentoo-dev] Uppercase characters in package names

[William Hubbs]

On Fri, Dec 02, 2016 at 04:13:48PM -0500, Mike Gilbert wrote:
> On Fri, Dec 2, 2016 at 1:47 PM, Michał Górny  wrote:
> > On Fri, 2 Dec 2016 13:02:48 -0500
> > Mike Gilbert  wrote:
> >
> >> The devmanual states:
> >>
> >> The name section should contain only lowercase non-accented letters,
> >> the digits 0-9, hyphens, underscores and plus characters. Uppercase
> >> characters are strongly discouraged, but technically valid.
> >>
> >> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> >>
> >>
> >> Why are uppercase characters strongly discouraged?
> >>
> >> Wouldn't it make sense to follow upstream's naming convention?
> >
> > I'd say keeping things lowercase makes sense for end user packages. For
> > pure dependencies with consistent conventions (e.g. perl), it makes
> > sense to keep upstream's naming.
> >
> 
> This seems like a reasonable approach. Thanks.

So, should we clean up / rename packages that do not follow this as we
find them, like my ConfigArgParse example?

William


signature.asc
Description: Digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Nick Vinson]

On 12/02/2016 10:28 AM, Ulrich Mueller wrote:
>> On Fri, 2 Dec 2016, Mike Gilbert wrote:
> 
>> The devmanual states:
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
> 
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> 
> 
>> Why are uppercase characters strongly discouraged?
> 
>> Wouldn't it make sense to follow upstream's naming convention?
> 
> No, because even for the most common packages it would be hard to
> guess what the actual convention is. For example, is it GCC (used on
> its web page and in documentation) or gcc (name of the command and
> displayed by gcc --version)?
> 
> If we allow uppercase, then should we also allow two packages in the
> tree whose names differ only in character case?

If Gentoo chose to perfectly match GNU's naming with GCC, then the
ebuild should be GCC-.ebuild.

The reason is simple.  GNU says GCC refers to the GNU Compiler
Collection, and gcc refers to the GNU C compiler.

Personally, I've disliked that differentiation. Most people don't pay
close enough attention to such things.  For example, how many people
think iOS and IOS are the same thing?

-Nicholas Vinson

> 
> Ulrich
> 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Walter Dnes]

On Fri, Dec 02, 2016 at 09:49:59PM -0600, William Hubbs wrote
> 
> So, should we clean up / rename packages that do not follow this as we
> find them, like my ConfigArgParse example?

find /usr/portage -name *.ebuild | grep [A-Z] | sed "s/-[0-9].*//" | sort -u > 
upper.txt

...gives 1814 *UNIQUE* packages, usually vith multiple ebuild versions
for each package.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Robin H. Johnson]

On Fri, Dec 02, 2016 at 02:10:27PM +0100, Michał Górny wrote:
> Hi, everyone.
> 
> I've heard multiple times about various tinderbox projects being
> started by individuals in Gentoo. In fact, so many different projects
> that I've forgotten who was working on most of them.
Flameeyes donated his tinderbox hardware, but it's still sitting at
antarus's desk in Mountain View, waiting for him to ship it to OSUOSL
(hopefully before it's even more obsolete).

It's not a matter of cost even, it's just waiting for him to physically
take the hardware to somewhere that ships it.


-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Re: [gentoo-dev] Uppercase characters in package names

[Robin H. Johnson]

On Sat, Dec 03, 2016 at 01:04:17AM -0500, Walter Dnes wrote:
> On Fri, Dec 02, 2016 at 09:49:59PM -0600, William Hubbs wrote
> > 
> > So, should we clean up / rename packages that do not follow this as we
> > find them, like my ConfigArgParse example?
> 
> find /usr/portage -name *.ebuild | grep [A-Z] | sed "s/-[0-9].*//" | sort -u 
> > upper.txt

There's a double-packaged case that stands out:
dev-python/shapely
sci-libs/Shapely
(Both use the same pypi source)

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Re: [gentoo-dev] Uppercase characters in package names

[Ulrich Mueller]

> On Fri, 2 Dec 2016, William Hubbs wrote:

> So, should we clean up / rename packages that do not follow this as
> we find them, like my ConfigArgParse example?

I still think that for any names exposed to users we should in general
stick to lowercase. Converting the name to uppercase for SRC_URI etc.
should be trivial, especially in EAPI 6 where bash's case conversion
operators are available.

The ebuild has to be written only once, while users will type the
package name many times.

Ulrich


pgpD98KZIfSVd.pgp
Description: PGP signature

Re: [gentoo-dev] Uppercase characters in package names

[Daniel Campbell]

On 12/02/2016 10:45 AM, Ian Stakenvicius wrote:
> On 02/12/16 01:31 PM, Ciaran McCreesh wrote:
>> On Fri, 2 Dec 2016 13:24:29 -0500
>> Mike Gilbert  wrote:
>>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>>>  wrote:
 On Fri, 2 Dec 2016 13:02:48 -0500
 Mike Gilbert  wrote:  
> The devmanual states:
>
> The name section should contain only lowercase non-accented
> letters, the digits 0-9, hyphens, underscores and plus characters.
> Uppercase characters are strongly discouraged, but technically
> valid.
>
> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>
>
> Why are uppercase characters strongly discouraged?
>
> Wouldn't it make sense to follow upstream's naming convention?  

 What's upstream's naming convention for Firefox?
>>>
>>> I have no idea. What's your point?
>>
>> That naming conventions are generally complicated and a mess, and that
>> no-one wants to have to remember whether it's firefox, Firefox, or
>> FireFox.
>>
> 
> It's also more convenient at the consone to just type everything
> lowercase.  I expect that's the primary reason it's discouraged.
> 
> 
> 
> 
That seems the most likely to me as well.

We could make a more "user friendly" feature by setting up bash
completion for package names, but that sounds a) daunting, b)
error-prone, and c) probably not worth the time spent writing the
script(s) necessary.

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Daniel Campbell]

On 12/02/2016 08:09 PM, Nick Vinson wrote:
> 
> [snip]
> Personally, I've disliked that differentiation. Most people don't pay
> close enough attention to such things.  For example, how many people
> think iOS and IOS are the same thing?
> 
> -Nicholas Vinson

Anyone familiar with Wii homebrew knows they're different, but I see
your point. :)
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Daniel Campbell]

On 12/02/2016 10:47 AM, Michał Górny wrote:
> On Fri, 2 Dec 2016 13:02:48 -0500
> Mike Gilbert  wrote:
> 
>> The devmanual states:
>>
>> The name section should contain only lowercase non-accented letters,
>> the digits 0-9, hyphens, underscores and plus characters. Uppercase
>> characters are strongly discouraged, but technically valid.
>>
>> https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
>>
>>
>> Why are uppercase characters strongly discouraged?
>>
>> Wouldn't it make sense to follow upstream's naming convention?
> 
> I'd say keeping things lowercase makes sense for end user packages. For
> pure dependencies with consistent conventions (e.g. perl), it makes
> sense to keep upstream's naming.
> 
What is a pure dependency? Do we handle those differently than the
garden-variety dependencies in other packages?

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Daniel Campbell]

On 12/02/2016 06:09 AM, Michael Mol wrote:
> On Friday, December 02, 2016 02:10:27 PM Michał Górny wrote:
>> Hi, everyone.
>>
>> I've heard multiple times about various tinderbox projects being
>> started by individuals in Gentoo. In fact, so many different projects
>> that I've forgotten who was working on most of them.
>>
>> I know that Toralf is doing tinderboxing for most of the stuff.
>> What other projects do we have there? What is their status?
>>
>> Is there anything we could try to integrate with pull requests to get
>> a better testing?
> 
> If there's a mostly-turnkey VM I can run to contribute to Tinderboxing, I 
> have 
> one or two systems I could benefit from some heat from over the winter. It's 
> that or bring out the electric space heater. Was talking with my wife about 
> mining Doge on one of them last night...
> 
I second that. I have a hexcore CPU and 16 GB of RAM, most of which I
don't use unless I'm compiling. If there's a guide that can get me up
and running with a VM within an hour or so, I'd be more than willing to
pitch in some cycles.

mgorny mentioned PRs, however... are such efforts moot if I don't have a
GitHub account?

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Daniel Campbell]

On 12/02/2016 07:14 AM, Andrew Savchenko wrote:
> Hi all!
> 
> Right now we have two somewhat conflicting policies (at least up to
> my understanding of them):
> 
> 1) git atomic commits [1]:
> each logical change should be a separate commit.
> 
> 2) revision bump policy [2]:
> each change sufficiently affecting application run-time or
> installed files should have a revision bump.
> 
> Let's consider the following quite common scenario: package foo-1.0
> should be updated to foo-1.1, but aside from version bump there is
> a set of accumulated issues which maintainer is willing to handle,
> e.g.:
> - bump to EAPI 6;
> - fix several runtime bugs (still present in the new version);
> - install missing documentation;
> - add previously omitted USE flags for some tools of controllable
> functionalities;
> - etc...
> 
> If both policies are to be followed, users will see something like:
> foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as
> a separate commit with a revision bump).
> 
> While such versioning change is technically correct, it is
> confusing for our users and makes future maintainance harder,
> because of multiple file renames (yeah, I know about git diff
> --find-renames, but this kludge is not perfect).
> 
> What about the following forkflow:
> - version bump first with minimal changes required, but without
> pushing commit to the tree;
> - make each logical change as a separate commit without revision
> bumps and without pushing stuff to the tree (of course repoman
> scan/full is required as usual for each commit);
> - well test package after the last commit (that it builds with
> various USE flag combinations, old and new functionality works fine
> and so on);
> - fix any problems found and only afterwards push changes to the
> tree.
> 
> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
> while git will still retain each logical change as a separate
> commit, which will make future maintenance and debugging much
> easier.
> 
> Of course a separate git branch may be used as well, but using
> branches for each half-a-dozen set of commits looks like an
> overkill to me.
> 
> Thoughts, comments?
> 
> [1] https://devmanual.gentoo.org/ebuild-maintenance/index.html
> [2] https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> 
> Best regards,
> Andrew Savchenko
> 
I've always worked as if each commit needed to be working for Gentoo
users. So if I need to version bump, that's a separate commit. However,
let's say I found a bug in the ebuild itself for foo-1.0. The way I see
it is I should bump to foo-1.0-r1 to fix the bug in that ebuild, _then_
version bump so that foo-1.1 already has the fixes that foo-1.0-r1 has.
If I version bump first, then I have to revbump both and that just
increases my odds of forgetting to put the fixes into all the correct
ebuilds.

It results in the appropriate fixes in the older package, and the new
version comes with the old one's fixes (plus any changes the new ebuild
might need due to upstream changes).

Does that make any sense?

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Uppercase characters in package names

[Vadim A. Misbakh-Soloviov]

> We could make a more "user friendly" feature by setting up bash
> completion for package names, but that sounds a) daunting, b)
> error-prone, and c) probably not worth the time spent writing the
> script(s) necessary.

By the way, the ones for zsh is already done and working (even for sets).

Although, talking about main topic of the thread, I think that emerge lacks 
"autocontinue" support in cases, where there is only single variant of 
misspelled suggestion more, that requirement to name all packages lowercase :)

Re: [gentoo-dev] Uppercase characters in package names

[Michał Górny]

On Fri, 2 Dec 2016 23:21:34 -0800
Daniel Campbell  wrote:

> On 12/02/2016 10:45 AM, Ian Stakenvicius wrote:
> > On 02/12/16 01:31 PM, Ciaran McCreesh wrote:  
> >> On Fri, 2 Dec 2016 13:24:29 -0500
> >> Mike Gilbert  wrote:  
> >>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
> >>>  wrote:  
>  On Fri, 2 Dec 2016 13:02:48 -0500
>  Mike Gilbert  wrote:
> > The devmanual states:
> >
> > The name section should contain only lowercase non-accented
> > letters, the digits 0-9, hyphens, underscores and plus characters.
> > Uppercase characters are strongly discouraged, but technically
> > valid.
> >
> > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
> >
> >
> > Why are uppercase characters strongly discouraged?
> >
> > Wouldn't it make sense to follow upstream's naming convention?
> 
>  What's upstream's naming convention for Firefox?  
> >>>
> >>> I have no idea. What's your point?  
> >>
> >> That naming conventions are generally complicated and a mess, and that
> >> no-one wants to have to remember whether it's firefox, Firefox, or
> >> FireFox.
> >>  
> > 
> > It's also more convenient at the consone to just type everything
> > lowercase.  I expect that's the primary reason it's discouraged.
> > 
> > 
> > 
> >   
> That seems the most likely to me as well.
> 
> We could make a more "user friendly" feature by setting up bash
> completion for package names, but that sounds a) daunting, b)
> error-prone, and c) probably not worth the time spent writing the
> script(s) necessary.

There is a bash completion script for that for a long time now.
However, it no longer works correctly with new bash-completion versions
and it seems that nobody cares enough to fix it.

-- 
Best regards,
Michał Górny



pgpEo7I9v_HJM.pgp
Description: OpenPGP digital signature