Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread Matthias Maier
On Sun, Sep 23, 2018, at 21:26 CDT, Kent Fredric  wrote:

> I personally try to use something of the form:
>
> "Bump version to 12.234.1567"
>
> Mostly, because it gives some vaguely useful context when reading a
> commit summary log, that doesn't necessitate you running "git log -p"
> or "git diff" to find out what actually changed.

++

> [...]
> All of this is "nice to have" stuff I'd try to gently nudge others into
> the direction of, in effort to provide useful information to not only
> our users, but to other developers, and our future selves looking back
> in the history trying to ascertain the importance of a given version.

++

> [...]
> But you can imagine how I get *just* a little bit frustrated when this
> is the sort of direction I'm trying to aspire towards, but what I'm
> seeing on the list is debates about "bup" vs "bump" :)

++

There is nothing more to add.

Best,
Matthias



Re: [gentoo-dev] [RFC] Removing support for mercurial repos in repositories.xml

2018-09-23 Thread Benda Xu
Michał Górny  writes:

> If you noticed that Gentoo repository mirrors did not update for 10
> hours a few days ago -- Mercurial was the reason.  It is very fragile,
> and if some server chokes during sync, it hangs the whole process until
> somebody (which means me) kills it.  And it's not the first time it
> killed the whole system.

While I agree with you that mercurial is less well-maintained than git,
this seems to me that the sync framework is more buggy than mercurial.

Benda


signature.asc
Description: PGP signature


[gentoo-portage-dev] [PATCH] portdbapi: add async_xmatch method (bug 666940)

2018-09-23 Thread Zac Medico
Add an async_xmatch method, and use it to implement the synchronous
xmatch method. Deprecate unused xmatch method parameters. Use the
compat_coroutine decorator for backward compatibility with python2.7
(via PEP 342 enhanced generators).

Bug: https://bugs.gentoo.org/666940
Suggested-by: Daniel Robbins 
Signed-off-by: Zac Medico 
---
 lib/portage/dbapi/porttree.py | 62 +++
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py
index 56955ec34..fc2980cdb 100644
--- a/lib/portage/dbapi/porttree.py
+++ b/lib/portage/dbapi/porttree.py
@@ -37,6 +37,7 @@ from portage import _unicode_encode
 from portage import OrderedDict
 from portage.util._eventloop.EventLoop import EventLoop
 from portage.util.futures import asyncio
+from portage.util.futures.compat_coroutine import coroutine, coroutine_return
 from portage.util.futures.iter_completed import iter_gather
 from _emerge.EbuildMetadataPhase import EbuildMetadataPhase
 
@@ -1055,8 +1056,41 @@ class portdbapi(dbapi):
self._better_cache = None
self.frozen = 0
 
-   def xmatch(self,level,origdep,mydep=None,mykey=None,mylist=None):
-   "caching match function; very trick stuff"
+   def xmatch(self, level, origdep, mydep=DeprecationWarning,
+   mykey=DeprecationWarning, mylist=DeprecationWarning):
+   """
+   Caching match function.
+
+   @param level: xmatch level (bestmatch-visible, 
match-all-cpv-only
+   match-allmatch-visible, minimum-all, 
minimum-all-ignore-profile,
+   or minimum-visible)
+   @type level: str
+   @param origdep: dependency to match (may omit category)
+   @type origdep: portage.dep.Atom or str
+   @return: match result(s)
+   @rtype: _pkg_str or list of _pkg_str (depends on level)
+   """
+   loop = self._event_loop
+   return loop.run_until_complete(
+   self.async_xmatch(level, origdep, mydep=mydep, 
loop=loop))
+
+   @coroutine
+   def async_xmatch(self, level, origdep, mydep=DeprecationWarning, 
loop=None):
+   """
+   Asynchronous form form of xmatch.
+
+   @param level: xmatch level (bestmatch-visible, 
match-all-cpv-only
+   match-allmatch-visible, minimum-all, 
minimum-all-ignore-profile,
+   or minimum-visible)
+   @type level: str
+   @param origdep: dependency to match (may omit category)
+   @type origdep: portage.dep.Atom or str
+   @param loop: event loop (defaults to global event loop)
+   @type loop: EventLoop
+   @return: match result(s)
+   @rtype: asyncio.Future (or compatible), which results in a 
_pkg_str
+   or list of _pkg_str (depends on level)
+   """
if level == "list-visible":
level = "match-visible"
warnings.warn("The 'list-visible' mode of "
@@ -1064,21 +1098,25 @@ class portdbapi(dbapi):
"has been renamed to match-visible",
DeprecationWarning, stacklevel=2)
 
-   if mydep is None:
-   #this stuff only runs on first call of xmatch()
-   #create mydep, mykey from origdep
-   mydep = dep_expand(origdep, mydb=self, 
settings=self.settings)
-   mykey = mydep.cp
+   if mydep is not DeprecationWarning:
+   warnings.warn("The 'mydep' parameter of "
+   "portage.dbapi.porttree.portdbapi.xmatch"
+   " is deprecated and ignored",
+   DeprecationWarning, stacklevel=2)
+
+   mydep = dep_expand(origdep, mydb=self, settings=self.settings)
+   mykey = mydep.cp
 
#if no updates are being made to the tree, we can consult our 
xcache...
cache_key = None
if self.frozen:
cache_key = (mydep, mydep.unevaluated_atom)
try:
-   return self.xcache[level][cache_key][:]
+   
coroutine_return(self.xcache[level][cache_key][:])
except KeyError:
pass
 
+   loop = asyncio._wrap_loop(loop)
myval = None
mytree = None
if mydep.repo is not None:
@@ -1131,12 +1169,14 @@ class portdbapi(dbapi):
 
for cpv in iterfunc(mylist):
try:
-   metadata = dict(zip(aux_keys,
-   

Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread M. J. Everitt
On 24/09/18 03:27, Matthew Thode wrote:
> On 18-09-23 21:39:01, Alec Warner wrote:
>> On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt  wrote:
>>
>>> On 23/09/18 22:27, Kent Fredric wrote:
 On Sat, 22 Sep 2018 15:36:23 -0500
 Matthew Thode  wrote:
> My hand slipped.  What ever happened to assuming the best :(  Are you
> going to ping the list every time my hand slips up and I mistype
> something?  Not sure you'll have time for it :P
 Personally, I would love it if more people tried harder to provide
 meaningful commit messages.

 "bup" vs "bump" isn't really achieving much, just one of the two are
 substantially more egregious.

 Perhaps, if the commit messages were crafted with clarity as their
 intent, the consequence of accidental typos would be much more
 inconsequential.

 ( I seriously think we could do with a *little* more chiding here than
 we generally see, but like, I'm typically just biting my tongue every
 time somebody doesn't invest any more effort than to write the word
 "bump" in their text editor when committing with repoman, cos I really
 don't want to be a dick about it. There's room for more than 4
 characters and a space in the subject, and infinitely more space in the
 body, why do we have to choose the least clear of all options? )

 Occasional accidents are still gonna happen, but it would be nice if we
 didn't define accidents and siblings of accidents as the status quo.

>>> I think Kent has pretty much the point here .. we try to stipulate that
>>> the commit message describes what the update is, and is clear for *all*
>>> users of the repository, and not just the relevant maintainer. There is
>>> also a cronic double-standard for existing or long-standing devs, and
>>> newer devs, recruits and proxy-maintainers (who get a double-scrutiny
>>> typically) - and I could easily see how this breeds resentment...
>>>
>>> Perhaps it would be simple enough to add a check to repoman for commit
>>> messages less than 10 characters, and with at least one *additional*
>>> space, mandating two words in the commit message. It seems draconian,
>>> but if developers continue to be lazy, what choice does one have?!
>>>
>>>
>> I don't see a problem with 'version bump' as a description. Sometimes you
>> bump an ebuild because upstream released a new version and you want to
>> track. I'm fairly against changes describing what was changed (typically
>> the reader can git show and observe the changes.) The useful information is
>> *why* the change was made. Sometimes its because "upstream released a new
>> version."
>>
>> Like Matt I'm curious what others expect to see in the description.
>>
> That's exactly why I release much of the stuff I do, I get a task in
> todoist via ifttt monitoring a github atom feed that a new release is
> out and I package it.
>
If you have automated tooling, surely it's not impossible to make that
tooling generate a semi-meaningful commit message on-the-fly too ...
just sayin' ...



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread Kent Fredric
On Sun, 23 Sep 2018 17:45:27 -0500
Matthew Thode  wrote:

> On 18-09-24 09:27:57, Kent Fredric wrote:
> > On Sat, 22 Sep 2018 15:36:23 -0500
> > Matthew Thode  wrote:  
> > > My hand slipped.  What ever happened to assuming the best :(  Are you
> > > going to ping the list every time my hand slips up and I mistype
> > > something?  Not sure you'll have time for it :P  
> > 
> > Personally, I would love it if more people tried harder to provide
> > meaningful commit messages.
> > 
> > "bup" vs "bump" isn't really achieving much, just one of the two are
> > substantially more egregious.
> > 
> > Perhaps, if the commit messages were crafted with clarity as their
> > intent, the consequence of accidental typos would be much more
> > inconsequential.
> > 
> > ( I seriously think we could do with a *little* more chiding here than
> > we generally see, but like, I'm typically just biting my tongue every
> > time somebody doesn't invest any more effort than to write the word
> > "bump" in their text editor when committing with repoman, cos I really
> > don't want to be a dick about it. There's room for more than 4
> > characters and a space in the subject, and infinitely more space in the
> > body, why do we have to choose the least clear of all options? )
> > 
> > Occasional accidents are still gonna happen, but it would be nice if we
> > didn't define accidents and siblings of accidents as the status quo.
> >   
> 
> What would you rather see for when a package is bumped (that is, simply
> copying the ebuild and editing the keywords)?
> 

I personally try to use something of the form:

"Bump version to 12.234.1567"

Mostly, because it gives some vaguely useful context when reading a
commit summary log, that doesn't necessitate you running "git log -p"
or "git diff" to find out what actually changed.

This lends itself to good user-feedback mechanisms when the log is
relayed via IRC on #gentoo-commits, and allows one to determine what's
going on at-a-glance via gitweb.

If the version bump is in response to a bug request, I'll try to
mention that in the subject too.

If I made changes in the ebuild in the bump itself, I'll attempt to
describe the nature of those changes (from the perspective of the
consumer)'

And where possible, I attempt to summarize the nature of the changes
between our largest in-tree version and the new version, as far as
upstream changes are concerned.

Eg: if version went from 1.0 to 1.3, but 1.1-1.2 existed,
I'll attempt a summary for the imagined user upgrading from 1.0 to 1.3.
If for instance something is added in 1.1 and then redacted in 1.2,
there's no need to mention that in 1.0 -> 1.3.

I Try to think of it as "a list of reasons why a user might want to
upgrade, or might want to avoid upgrading" from a context of "xxx
changed, if you were using this your code might break" or "xxx is new,
if you need this, you need to upgrade"

All of this is "nice to have" stuff I'd try to gently nudge others into
the direction of, in effort to provide useful information to not only
our users, but to other developers, and our future selves looking back
in the history trying to ascertain the importance of a given version.

Achieving all of the above is of course not always possible, sometimes
there are too many changes to summarize, or upstream is made of too
much insane for you to assess the differences, that's life.

But you can imagine how I get *just* a little bit frustrated when this
is the sort of direction I'm trying to aspire towards, but what I'm
seeing on the list is debates about "bup" vs "bump" :)



pgp3Tp9pj89v0.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread Matthew Thode
On 18-09-23 21:39:01, Alec Warner wrote:
> On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt  wrote:
> 
> > On 23/09/18 22:27, Kent Fredric wrote:
> > > On Sat, 22 Sep 2018 15:36:23 -0500
> > > Matthew Thode  wrote:
> > >> My hand slipped.  What ever happened to assuming the best :(  Are you
> > >> going to ping the list every time my hand slips up and I mistype
> > >> something?  Not sure you'll have time for it :P
> > > Personally, I would love it if more people tried harder to provide
> > > meaningful commit messages.
> > >
> > > "bup" vs "bump" isn't really achieving much, just one of the two are
> > > substantially more egregious.
> > >
> > > Perhaps, if the commit messages were crafted with clarity as their
> > > intent, the consequence of accidental typos would be much more
> > > inconsequential.
> > >
> > > ( I seriously think we could do with a *little* more chiding here than
> > > we generally see, but like, I'm typically just biting my tongue every
> > > time somebody doesn't invest any more effort than to write the word
> > > "bump" in their text editor when committing with repoman, cos I really
> > > don't want to be a dick about it. There's room for more than 4
> > > characters and a space in the subject, and infinitely more space in the
> > > body, why do we have to choose the least clear of all options? )
> > >
> > > Occasional accidents are still gonna happen, but it would be nice if we
> > > didn't define accidents and siblings of accidents as the status quo.
> > >
> > I think Kent has pretty much the point here .. we try to stipulate that
> > the commit message describes what the update is, and is clear for *all*
> > users of the repository, and not just the relevant maintainer. There is
> > also a cronic double-standard for existing or long-standing devs, and
> > newer devs, recruits and proxy-maintainers (who get a double-scrutiny
> > typically) - and I could easily see how this breeds resentment...
> >
> > Perhaps it would be simple enough to add a check to repoman for commit
> > messages less than 10 characters, and with at least one *additional*
> > space, mandating two words in the commit message. It seems draconian,
> > but if developers continue to be lazy, what choice does one have?!
> >
> >
> I don't see a problem with 'version bump' as a description. Sometimes you
> bump an ebuild because upstream released a new version and you want to
> track. I'm fairly against changes describing what was changed (typically
> the reader can git show and observe the changes.) The useful information is
> *why* the change was made. Sometimes its because "upstream released a new
> version."
> 
> Like Matt I'm curious what others expect to see in the description.
> 

That's exactly why I release much of the stuff I do, I get a task in
todoist via ifttt monitoring a github atom feed that a new release is
out and I package it.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread Alec Warner
On Sun, Sep 23, 2018 at 6:53 PM M. J. Everitt  wrote:

> On 23/09/18 22:27, Kent Fredric wrote:
> > On Sat, 22 Sep 2018 15:36:23 -0500
> > Matthew Thode  wrote:
> >> My hand slipped.  What ever happened to assuming the best :(  Are you
> >> going to ping the list every time my hand slips up and I mistype
> >> something?  Not sure you'll have time for it :P
> > Personally, I would love it if more people tried harder to provide
> > meaningful commit messages.
> >
> > "bup" vs "bump" isn't really achieving much, just one of the two are
> > substantially more egregious.
> >
> > Perhaps, if the commit messages were crafted with clarity as their
> > intent, the consequence of accidental typos would be much more
> > inconsequential.
> >
> > ( I seriously think we could do with a *little* more chiding here than
> > we generally see, but like, I'm typically just biting my tongue every
> > time somebody doesn't invest any more effort than to write the word
> > "bump" in their text editor when committing with repoman, cos I really
> > don't want to be a dick about it. There's room for more than 4
> > characters and a space in the subject, and infinitely more space in the
> > body, why do we have to choose the least clear of all options? )
> >
> > Occasional accidents are still gonna happen, but it would be nice if we
> > didn't define accidents and siblings of accidents as the status quo.
> >
> I think Kent has pretty much the point here .. we try to stipulate that
> the commit message describes what the update is, and is clear for *all*
> users of the repository, and not just the relevant maintainer. There is
> also a cronic double-standard for existing or long-standing devs, and
> newer devs, recruits and proxy-maintainers (who get a double-scrutiny
> typically) - and I could easily see how this breeds resentment...
>
> Perhaps it would be simple enough to add a check to repoman for commit
> messages less than 10 characters, and with at least one *additional*
> space, mandating two words in the commit message. It seems draconian,
> but if developers continue to be lazy, what choice does one have?!
>
>
I don't see a problem with 'version bump' as a description. Sometimes you
bump an ebuild because upstream released a new version and you want to
track. I'm fairly against changes describing what was changed (typically
the reader can git show and observe the changes.) The useful information is
*why* the change was made. Sometimes its because "upstream released a new
version."

Like Matt I'm curious what others expect to see in the description.

-A


Re: [gentoo-dev] [PATCH] udev.eclass: support EAPI 7

2018-09-23 Thread Mike Gilbert
On Sun, Sep 23, 2018 at 3:33 PM M. J. Everitt  wrote:
>
> On 23/09/18 16:20, Mike Gilbert wrote:
> > Signed-off-by: Mike Gilbert 
> > ---
> >  eclass/udev.eclass | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/eclass/udev.eclass b/eclass/udev.eclass
> > index 4f23c9ebbdf8..baf60584938f 100644
> > --- a/eclass/udev.eclass
> > +++ b/eclass/udev.eclass
> > @@ -1,10 +1,10 @@
> > -# Copyright 1999-2014 Gentoo Foundation
> > +# Copyright 1999-2018 Gentoo Authors
> >  # Distributed under the terms of the GNU General Public License v2
> >
> >  # @ECLASS: udev.eclass
> >  # @MAINTAINER:
> >  # udev-b...@gentoo.org
> > -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
> > +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
> >  # @BLURB: Default eclass for determining udev directories.
> >  # @DESCRIPTION:
> >  # Default eclass for determining udev directories.
> > @@ -34,12 +34,16 @@ _UDEV_ECLASS=1
> >  inherit toolchain-funcs
> >
> >  case ${EAPI:-0} in
> > - 0|1|2|3|4|5|6) ;;
> > + 0|1|2|3|4|5|6|7) ;;
> >   *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
> >  esac
> >
> > -RDEPEND=""
> > -DEPEND="virtual/pkgconfig"
> > +if [[ ${EAPI:-0} == [0123456] ]]; then
> > + RDEPEND=""
> > + DEPEND="virtual/pkgconfig"
> > +else
> > + BDEPEND="virtual/pkgconfig"
> > +fi
> >
> >  # @FUNCTION: _udev_get_udevdir
> >  # @INTERNAL
> Hate to nit-pick, but this *is* Gentoo .. the last IF, if EAPI <> 7 then
> BDEPEND could also be dragged in, probably better to explicitly mention '7'.

That's by design: future EAPIs will probably have BDEPEND, and I don't
want to have to update this if statement for every new EAPI.



[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-09-23 23:59 UTC

2018-09-23 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2018-09-23 23:59 UTC.

Removals:
sys-apps/paludis20180919-11:27 zlogene   5d144f9e4df

Additions:
app-crypt/hashcat-utils 20180918-20:26 zerochaos f6225f11a1a
app-misc/tmux2html  20180917-15:58 monsieurp b3221ab2ce4
dev-php/xdebug-handler  20180907-11:22 whissi8c21e81f017
dev-python/asciimatics  20180919-21:05 monsieurp 6ed588329e7
dev-python/gast 20180921-16:46 perfinion 65e215bd498
dev-python/pyfiglet 20180919-20:01 monsieurp f16ab4e29d3

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
sys-apps/paludis,removed,zlogene,20180919-11:27,5d144f9e4df
Added Packages:
dev-python/gast,added,perfinion,20180921-16:46,65e215bd498
dev-php/xdebug-handler,added,whissi,20180907-11:22,8c21e81f017
dev-python/asciimatics,added,monsieurp,20180919-21:05,6ed588329e7
dev-python/pyfiglet,added,monsieurp,20180919-20:01,f16ab4e29d3
app-crypt/hashcat-utils,added,zerochaos,20180918-20:26,f6225f11a1a
app-misc/tmux2html,added,monsieurp,20180917-15:58,b3221ab2ce4

Done.

Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread M. J. Everitt
On 23/09/18 22:27, Kent Fredric wrote:
> On Sat, 22 Sep 2018 15:36:23 -0500
> Matthew Thode  wrote:
>> My hand slipped.  What ever happened to assuming the best :(  Are you
>> going to ping the list every time my hand slips up and I mistype
>> something?  Not sure you'll have time for it :P
> Personally, I would love it if more people tried harder to provide
> meaningful commit messages.
>
> "bup" vs "bump" isn't really achieving much, just one of the two are
> substantially more egregious.
>
> Perhaps, if the commit messages were crafted with clarity as their
> intent, the consequence of accidental typos would be much more
> inconsequential.
>
> ( I seriously think we could do with a *little* more chiding here than
> we generally see, but like, I'm typically just biting my tongue every
> time somebody doesn't invest any more effort than to write the word
> "bump" in their text editor when committing with repoman, cos I really
> don't want to be a dick about it. There's room for more than 4
> characters and a space in the subject, and infinitely more space in the
> body, why do we have to choose the least clear of all options? )
>
> Occasional accidents are still gonna happen, but it would be nice if we
> didn't define accidents and siblings of accidents as the status quo.
>
I think Kent has pretty much the point here .. we try to stipulate that
the commit message describes what the update is, and is clear for *all*
users of the repository, and not just the relevant maintainer. There is
also a cronic double-standard for existing or long-standing devs, and
newer devs, recruits and proxy-maintainers (who get a double-scrutiny
typically) - and I could easily see how this breeds resentment...

Perhaps it would be simple enough to add a check to repoman for commit
messages less than 10 characters, and with at least one *additional*
space, mandating two words in the commit message. It seems draconian,
but if developers continue to be lazy, what choice does one have?!



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Removing support for mercurial repos in repositories.xml

2018-09-23 Thread Alec Warner
On Sun, Sep 23, 2018 at 4:42 PM Michał Górny  wrote:

> Hi, everyone.
>
> I'd like to ask Gentoo repository owners to switch off Mercurial
> and remove all Mercurial repositories from repositories.xml.  There are
> two reasons for that:
>
> 1. Portage does not support syncing from Mercurial repos, and needs to
> use external tools (e.g. layman) for that.
>
> 2. Mercurial is buggy and maintaining support for those repos is PITA.
>
> If you noticed that Gentoo repository mirrors did not update for 10
> hours a few days ago -- Mercurial was the reason.  It is very fragile,
> and if some server chokes during sync, it hangs the whole process until
> somebody (which means me) kills it.  And it's not the first time it
> killed the whole system.
>
> Yes, I could add process timeouts.  But small timeouts are going to
> break the occasional necessity of cloning big repos, and big timeouts
> are going to make little difference when Mercurial starts hanging again.
>

So you are against timeouts altogether, or you just don't want to implement
them?


>
> If someone really cares about this horrible piece of software, I'd
> appreciate patches (preferably going upstream) to make it timeout sanely
> when something hangs.  Otherwise, I'd like to announce discontinuation
> of Mercurial support soon.
>

> --
> Best regards,
> Michał Górny
>


Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread Matthew Thode
On 18-09-24 09:27:57, Kent Fredric wrote:
> On Sat, 22 Sep 2018 15:36:23 -0500
> Matthew Thode  wrote:
> > My hand slipped.  What ever happened to assuming the best :(  Are you
> > going to ping the list every time my hand slips up and I mistype
> > something?  Not sure you'll have time for it :P
> 
> Personally, I would love it if more people tried harder to provide
> meaningful commit messages.
> 
> "bup" vs "bump" isn't really achieving much, just one of the two are
> substantially more egregious.
> 
> Perhaps, if the commit messages were crafted with clarity as their
> intent, the consequence of accidental typos would be much more
> inconsequential.
> 
> ( I seriously think we could do with a *little* more chiding here than
> we generally see, but like, I'm typically just biting my tongue every
> time somebody doesn't invest any more effort than to write the word
> "bump" in their text editor when committing with repoman, cos I really
> don't want to be a dick about it. There's room for more than 4
> characters and a space in the subject, and infinitely more space in the
> body, why do we have to choose the least clear of all options? )
> 
> Occasional accidents are still gonna happen, but it would be nice if we
> didn't define accidents and siblings of accidents as the status quo.
> 

What would you rather see for when a package is bumped (that is, simply
copying the ebuild and editing the keywords)?

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Re: What means bup?

2018-09-23 Thread Kent Fredric
On Sat, 22 Sep 2018 15:36:23 -0500
Matthew Thode  wrote:
> My hand slipped.  What ever happened to assuming the best :(  Are you
> going to ping the list every time my hand slips up and I mistype
> something?  Not sure you'll have time for it :P

Personally, I would love it if more people tried harder to provide
meaningful commit messages.

"bup" vs "bump" isn't really achieving much, just one of the two are
substantially more egregious.

Perhaps, if the commit messages were crafted with clarity as their
intent, the consequence of accidental typos would be much more
inconsequential.

( I seriously think we could do with a *little* more chiding here than
we generally see, but like, I'm typically just biting my tongue every
time somebody doesn't invest any more effort than to write the word
"bump" in their text editor when committing with repoman, cos I really
don't want to be a dick about it. There's room for more than 4
characters and a space in the subject, and infinitely more space in the
body, why do we have to choose the least clear of all options? )

Occasional accidents are still gonna happen, but it would be nice if we
didn't define accidents and siblings of accidents as the status quo.

 








pgpg0CvstIsLc.pgp
Description: OpenPGP digital signature


[gentoo-dev] [RFC] Removing support for mercurial repos in repositories.xml

2018-09-23 Thread Michał Górny
Hi, everyone.

I'd like to ask Gentoo repository owners to switch off Mercurial
and remove all Mercurial repositories from repositories.xml.  There are
two reasons for that:

1. Portage does not support syncing from Mercurial repos, and needs to
use external tools (e.g. layman) for that.

2. Mercurial is buggy and maintaining support for those repos is PITA.

If you noticed that Gentoo repository mirrors did not update for 10
hours a few days ago -- Mercurial was the reason.  It is very fragile,
and if some server chokes during sync, it hangs the whole process until
somebody (which means me) kills it.  And it's not the first time it
killed the whole system.

Yes, I could add process timeouts.  But small timeouts are going to
break the occasional necessity of cloning big repos, and big timeouts
are going to make little difference when Mercurial starts hanging again.

If someone really cares about this horrible piece of software, I'd
appreciate patches (preferably going upstream) to make it timeout sanely
when something hangs.  Otherwise, I'd like to announce discontinuation
of Mercurial support soon.

-- 
Best regards,
Michał Górny


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


Re: [gentoo-dev] [PATCH] udev.eclass: support EAPI 7

2018-09-23 Thread M. J. Everitt
On 23/09/18 16:20, Mike Gilbert wrote:
> Signed-off-by: Mike Gilbert 
> ---
>  eclass/udev.eclass | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/eclass/udev.eclass b/eclass/udev.eclass
> index 4f23c9ebbdf8..baf60584938f 100644
> --- a/eclass/udev.eclass
> +++ b/eclass/udev.eclass
> @@ -1,10 +1,10 @@
> -# Copyright 1999-2014 Gentoo Foundation
> +# Copyright 1999-2018 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: udev.eclass
>  # @MAINTAINER:
>  # udev-b...@gentoo.org
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
>  # @BLURB: Default eclass for determining udev directories.
>  # @DESCRIPTION:
>  # Default eclass for determining udev directories.
> @@ -34,12 +34,16 @@ _UDEV_ECLASS=1
>  inherit toolchain-funcs
>  
>  case ${EAPI:-0} in
> - 0|1|2|3|4|5|6) ;;
> + 0|1|2|3|4|5|6|7) ;;
>   *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
>  esac
>  
> -RDEPEND=""
> -DEPEND="virtual/pkgconfig"
> +if [[ ${EAPI:-0} == [0123456] ]]; then
> + RDEPEND=""
> + DEPEND="virtual/pkgconfig"
> +else
> + BDEPEND="virtual/pkgconfig"
> +fi
>  
>  # @FUNCTION: _udev_get_udevdir
>  # @INTERNAL
Hate to nit-pick, but this *is* Gentoo .. the last IF, if EAPI <> 7 then
BDEPEND could also be dragged in, probably better to explicitly mention '7'.
Cheers,
Michael.
Replying off-list due to black-listing.



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] udev.eclass: support EAPI 7

2018-09-23 Thread Mike Gilbert
Signed-off-by: Mike Gilbert 
---
 eclass/udev.eclass | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 4f23c9ebbdf8..baf60584938f 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: udev.eclass
 # @MAINTAINER:
 # udev-b...@gentoo.org
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6
+# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
 # @BLURB: Default eclass for determining udev directories.
 # @DESCRIPTION:
 # Default eclass for determining udev directories.
@@ -34,12 +34,16 @@ _UDEV_ECLASS=1
 inherit toolchain-funcs
 
 case ${EAPI:-0} in
-   0|1|2|3|4|5|6) ;;
+   0|1|2|3|4|5|6|7) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
 esac
 
-RDEPEND=""
-DEPEND="virtual/pkgconfig"
+if [[ ${EAPI:-0} == [0123456] ]]; then
+   RDEPEND=""
+   DEPEND="virtual/pkgconfig"
+else
+   BDEPEND="virtual/pkgconfig"
+fi
 
 # @FUNCTION: _udev_get_udevdir
 # @INTERNAL
-- 
2.19.0




Re: [gentoo-dev] [PATCH] meson.eclass: add EAPI 7 support

2018-09-23 Thread Mike Gilbert
On Tue, Jul 10, 2018 at 8:40 PM Marty E. Plummer  wrote:
> It seems this is all that is needed, and all the eclasses inherited by
> it are supported for EAPI 7. I could be missing something, so please do
> comment if I have.

I pushed this, thanks!