Re: [gentoo-portage-dev] portage user not listed in /etc/shadow ?

[M. J. Everitt]

On 16/01/19 12:59, Joakim Tjernlund wrote:
> On Wed, 2019-01-16 at 12:20 +0000, M. J. Everitt wrote:
>> On 16/01/19 11:58, Joakim Tjernlund wrote:
>>> How come portage isn't in shadow, only in passwd ?
>>> Seems wrong to me.
>>>
>>>  Jocke
>> Because the portage user never logs on .. hence has no password. That said,
> That goes for evry other system account too but these are in shadow.
>
>> it does seem an odd situation, since even users with no password do tend to
>> appear in /etc/shadow .. perhaps it was/is never "properly" added as a user
>> 
> I think/hope so. Now passwd looks like so:
> portage:x:250:250:portage:/var/tmp/portage:/bin/false
> This looks like a shadow account. Because of the missing entry passwd
> thinks this is a normal account:
> # > passwd -S portage 
> portage P
> as opposed to:
> # > passwd  -S daemon
> daemon L 10/28/1996 0 -1 -1 -1
>
>  Jocke
With the help of some devs, I have drilled this down to commit
https://gitweb.gentoo.org/proj/baselayout.git/commit/share.Linux/shadow?id=5ee3c95d2086e626247640ca35cf2da78c4c9846
in baselayout in 2016.

Some of my systems mysteriously (but predictably) are missing portage in
/etc/shadow as you describe, but these are prior to the baselayout change
above. Many have it as the commit suggests also. I suspect there may not
have been an upgrade path which added it between versions however, unless
it was pulled in via CONFIG_PROTECT somehow

Bug https://bugs.gentoo.org/show_bug.cgi?id=521970 is also referenced in
that commit.

Hope that answers your question (and my curiosity!).
Regards,

veremitz/Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] portage user not listed in /etc/shadow ?

[M. J. Everitt]

On 16/01/19 11:58, Joakim Tjernlund wrote:
> How come portage isn't in shadow, only in passwd ?
> Seems wrong to me.
>
>  Jocke
Because the portage user never logs on .. hence has no password. That said,
it does seem an odd situation, since even users with no password do tend to
appear in /etc/shadow .. perhaps it was/is never "properly" added as a user


MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v3] collision_protect: use dynamic report interval

[M. J. Everitt]

On 08/01/19 19:15, Zac Medico wrote:
> On 1/8/19 5:42 AM, Fabian Groffen wrote:
>> The reporting of files remaining can look somewhat odd since the report
>> interval is hardcoded to be per 1000 objects.  Adjust this interval to
>> be time based.  This means that modern (fast) machines likely will never
>> see the countdown messages at all.  On slow setups the message will be
>> informative that there is progress, albeit rather slowly.  While at it,
>> report percentage done.
>>
>> Output before this patch:
>>
>>  * checking 6158 files for package collisions
>> 5158 files remaining ...
>> 4158 files remaining ...
>> 3158 files remaining ...
>> 2158 files remaining ...
>> 1158 files remaining ...
>> 158 files remaining ...
>>
>> Possible output after this patch on a slower machine:
>>
>>  * checking 6158 files for package collisions
>>  48% done, 3145 files remaining ...
>>  96% done, 192 files remaining ...
>> 100% done
>>
>> Signed-off-by: Fabian Groffen 
>> ---
>>  lib/portage/dbapi/vartree.py | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/portage/dbapi/vartree.py b/lib/portage/dbapi/vartree.py
>> index 4b91caea8..244195fad 100644
>> --- a/lib/portage/dbapi/vartree.py
>> +++ b/lib/portage/dbapi/vartree.py
>> @@ -3475,13 +3475,18 @@ class dblink(object):
>>  symlink_collisions = []
>>  destroot = self.settings['ROOT']
>>  totfiles = len(file_list) + len(symlink_list)
>> +tnow = time.time()
>> +tinterv = 2  # seconds
>> +ninterv = tnow + tinterv
>>  showMessage(_(" %s checking %d files for package 
>> collisions\n") % \
>>  (colorize("GOOD", "*"), totfiles))
>>  for i, (f, f_type) in enumerate(chain(
>>  ((f, "reg") for f in file_list),
>>  ((f, "sym") for f in symlink_list))):
>> -if i % 1000 == 0 and i != 0:
>> -showMessage(_("%d files remaining 
>> ...\n") % (totfiles - i))
>> +if time.time() > ninterv:
>> +showMessage(_("%3d%% done, %d files 
>> remaining ...\n") %
>> +(i * 100 / totfiles, 
>> totfiles - i))
>> +ninterv = time.time() + tinterv
>>  
>>  dest_path = normalize_path(
>>  os.path.join(destroot, 
>> f.lstrip(os.path.sep)))
>> @@ -3570,6 +3575,8 @@ class dblink(object):
>>  break
>>  if stopmerge:
>>  collisions.append(f)
>> +if tnow + tinterv < ninterv:
>> +showMessage(_("100% done\n"))
>>  return collisions, dirs_ro, symlink_collisions, 
>> plib_collisions
>>  
>>  def _lstat_inode_map(self, path_iter):
>>
> Please replace time.time() with portage.util.monotonic.monotonic().
It's a bit of a nit-pick, granted, but can we ensure that the count-down's
remain padded/justified such that the numbers line up for easy at-a-glance
inspection ? The optimal standard looks somewhat like the pre-merge Sizes:

 * Final size of build directory: 2696 KiB (2.6 MiB)
 * Final size of installed tree:  5372 KiB (5.2 MiB)

Otherwise, I think this will be quite helpful. Thanks.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Error logs

[M. J. Everitt]

On 30/12/18 19:58, Pratyush Das wrote:
> Hi,
>
> In reference to this forum post
> - https://forums.gentoo.org/viewtopic-t-1091144-highlight-.html , I was
> told that several users found wrong information in the portage error logs
> pointing them to the wrong directory for distfiles to be downloaded and
> placed in for the emerge to work when the tree variable was displayed to
> the user, for the user to place the downloaded files in. 
> Instead of not using the tree variable to point to the distfiles location
> (and having a less descriptive error message), was using some other form
> of keeping a track of where the files are stored discussed? Or figuring
> out why the variable pointed to the wrong directory? 
>
> I could take a look at it if that is a feature you would be open to having. 
>
> Regards,
>
> -- 
> Pratyush Das(Reik)
Can you highlight some more examples (good & bad) as even the forum post
doesn't really go into much detail about what's present and missing? I can
see that dev-libs/cudnn is poor - usually LICENSE-restricted files give
some sensible directions, iirc. Not sure quite why this package is an
exception if it's problematic in being mirrored ...
Regards,

Michael/veremitz.


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538

[M. J. Everitt]

On 17/12/18 15:51, Michał Górny wrote:
> On Mon, 2018-12-17 at 15:44 +0000, M. J. Everitt wrote:
>> On 17/12/18 12:54, Michał Górny wrote:
>>>> Not only this, but as noted, unless you know the man pages for portage and
>>>> make.conf in order to recite them in your sleep, they are confusing for
>>>> users, as they do not necessarily follow an obvious pattern, and it wasn't
>>>> until I was attempting to debug something that I noticed that despite
>>>> believing I had the correct settings in my make.conf (set over a period of
>>>> YEARS) they were in fact completely useless, and it wasn't until I had to
>>>> spend time with somebody debugging WTF was happening, that this particular
>>>> issue even became apparent...
>>> I don't see how this is an argument for anything.  You have to read
>>> the manual in order to know that such variable exists and what it does. 
>>> Or, well, technically you don't since it's provided in make.conf.example
>>> already where you only need to uncomment it.
>>>
>>> Either way, the variable name is trivial.  Even if you don't follow
>>> the usual pattern of uncommenting it from make.conf.example or copying
>>> from the manual, remembering it for the time needed to retype shoudln't
>>> be a problem.
>>>
>>> So, is this a solution to a real problem?  Or is it merely a half-
>>> thought-out partial change that's going to require people to update
>>> their configuration for no long-term benefit?  And then they will have
>>> to update it again when someone decides to take another variable for
>>> a spin.
>>>
>> In the case you hadn't noticed, clearly you haven't .. the change is
>> backwards compatible.. that has already been thought out.
>>
>> But you haven't actually looked at the patch have you, Michal ?
>>
> I did look at it.  However, that doesn't change what I said.  Being
> 'backwards compatible' does not change the fact that the old variable
> becomes deprecated now.  Ergo, users are expected to eventually switch
> to the new one.
>
> Even if you don't care beyond changing this now and forgetting about it
> afterwards, someone eventually will have to clean up the old variable
> and actively force people to update.
>
Correct, but surely this doesn't apply in any other areas of Gentoo, eg.
perhaps Ebuilds? EAPIs? PMS? QA?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538

[M. J. Everitt]

On 17/12/18 15:44, M. J. Everitt wrote:
> On 17/12/18 12:54, Michał Górny wrote:
>>> Not only this, but as noted, unless you know the man pages for portage and
>>> make.conf in order to recite them in your sleep, they are confusing for
>>> users, as they do not necessarily follow an obvious pattern, and it wasn't
>>> until I was attempting to debug something that I noticed that despite
>>> believing I had the correct settings in my make.conf (set over a period of
>>> YEARS) they were in fact completely useless, and it wasn't until I had to
>>> spend time with somebody debugging WTF was happening, that this particular
>>> issue even became apparent...
>> I don't see how this is an argument for anything.  You have to read
>> the manual in order to know that such variable exists and what it does. 
>> Or, well, technically you don't since it's provided in make.conf.example
>> already where you only need to uncomment it.
>>
>> Either way, the variable name is trivial.  Even if you don't follow
>> the usual pattern of uncommenting it from make.conf.example or copying
>> from the manual, remembering it for the time needed to retype shoudln't
>> be a problem.
>>
>> So, is this a solution to a real problem?  Or is it merely a half-
>> thought-out partial change that's going to require people to update
>> their configuration for no long-term benefit?  And then they will have
>> to update it again when someone decides to take another variable for
>> a spin.
>>
> In the case you hadn't noticed, clearly you haven't .. the change is
> backwards compatible.. that has already been thought out.
>
> But you haven't actually looked at the patch have you, Michal ?
>
Whilst I'm here .. you won't also have noticed I've updated the
documentation too ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538

[M. J. Everitt]

On 17/12/18 12:54, Michał Górny wrote:
>> Not only this, but as noted, unless you know the man pages for portage and
>> make.conf in order to recite them in your sleep, they are confusing for
>> users, as they do not necessarily follow an obvious pattern, and it wasn't
>> until I was attempting to debug something that I noticed that despite
>> believing I had the correct settings in my make.conf (set over a period of
>> YEARS) they were in fact completely useless, and it wasn't until I had to
>> spend time with somebody debugging WTF was happening, that this particular
>> issue even became apparent...
> I don't see how this is an argument for anything.  You have to read
> the manual in order to know that such variable exists and what it does. 
> Or, well, technically you don't since it's provided in make.conf.example
> already where you only need to uncomment it.
>
> Either way, the variable name is trivial.  Even if you don't follow
> the usual pattern of uncommenting it from make.conf.example or copying
> from the manual, remembering it for the time needed to retype shoudln't
> be a problem.
>
> So, is this a solution to a real problem?  Or is it merely a half-
> thought-out partial change that's going to require people to update
> their configuration for no long-term benefit?  And then they will have
> to update it again when someone decides to take another variable for
> a spin.
>
In the case you hadn't noticed, clearly you haven't .. the change is
backwards compatible.. that has already been thought out.

But you haven't actually looked at the patch have you, Michal ?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538

[M. J. Everitt]

On 15/12/18 08:55, Michał Górny wrote:
> On Sat, 2018-12-15 at 02:25 +0000, M. J. Everitt wrote:
>> This patchset aims to fix potential ambiguity and confusion between older 
>> PORT_LOG* variables,
>> and more recent PORTAGE_* variables - often leading to mysteriously lacking 
>> logging due to
>> incorrect variable names. Documented in Bug 668538; with thanks to Zac for 
>> diagnosis, and
>> solution assistance!
>>
> Does 'often' actually affect more than one person?  Do you have any
> evidence to support this?
>
> Given that a lot of Portage variables don't have any prefix or sane
> names, I dare say this one doesn't especially stand out.
>
Just a thought, but how about you apply your skill and wisdom to reviewing
the patches, instead of wasting it on writing snide replies?
Quite radical I know, but whadda ya think?!

As it happens, I was going for consistency here, as that often reflects
code quality, and you being a keen QA member, I'da thought perhaps you
might have spotted this!

Not only this, but as noted, unless you know the man pages for portage and
make.conf in order to recite them in your sleep, they are confusing for
users, as they do not necessarily follow an obvious pattern, and it wasn't
until I was attempting to debug something that I noticed that despite
believing I had the correct settings in my make.conf (set over a period of
YEARS) they were in fact completely useless, and it wasn't until I had to
spend time with somebody debugging WTF was happening, that this particular
issue even became apparent...



signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH 4/4] Add note to NEWS/ChangeLog for PORT_LOGDIR* changes

[M. J. Everitt]

Suggested-by: Michael Everitt 
Bug: https://bugs.gentoo.org/668538
---
 NEWS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/NEWS b/NEWS
index b430f273f..e65205c42 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,11 @@
 News (mainly features/major bug fixes)
 
+portage-next
+--
+* Renamed PORT_LOGDIR and PORT_LOGDIR_CLEAN variables to
+  PORTAGE_LOGDIR and PORTAGE_LOGDIR_CLEAN to match other existing
+  similar variables
+
 portage-2.3.42
 
 * Sync with rsync quarantines data prior to verification, using the
-- 
2.13.6




signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH 1/4] Renamed PORT_LOGDIR[_CLEAN] to PORTAGE_LOGDIR[_CLEAN]

[M. J. Everitt]

To match similar existing PORTAGE_* variables

Suggested-by: Zac Medico 
Acked-by: Michael Everitt 
Bug: https://bugs.gentoo.org/668538
---
 NEWS   |  2 +-
 cnf/make.conf.example  | 12 +-
 cnf/make.globals   |  2 +-
 lib/_emerge/post_emerge.py |  2 +-
 lib/portage/dbapi/vartree.py   |  2 +-
 lib/portage/elog/mod_echo.py   |  2 +-
 lib/portage/elog/mod_save.py   |  4 ++--
 lib/portage/elog/mod_save_summary.py   |  4 ++--
 lib/portage/emaint/modules/logs/__init__.py|  2 +-
 lib/portage/emaint/modules/logs/logs.py| 22 +-
 .../package/ebuild/_config/special_env_vars.py |  2 +-
 lib/portage/package/ebuild/prepare_build_dirs.py   | 26 +++---
 lib/portage/tests/emerge/test_simple.py|  2 +-
 man/ebuild.5   |  2 +-
 man/emaint.1   |  6 ++---
 man/emerge.1   |  2 +-
 man/make.conf.5| 18 +++
 17 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/NEWS b/NEWS
index f77c310e3..b430f273f 100644
--- a/NEWS
+++ b/NEWS
@@ -389,7 +389,7 @@ portage-2.1 (ongoing via pre releases)
 * Make --emptytree only apply to ${ROOT} rather than always including /.
 * Allow packages to be upgraded that are only depended on via a
   "|| ( =cat/pkg-1* =cat/pkg-2* )" construct.
-* Ebuild output is no longer cut off early when using PORT_LOGDIR.
+* Ebuild output is no longer cut off early when using PORTAGE_LOGDIR.
 * Distfiles indirection- $DISTFILES access goes through a tmp dir to fail
   access to files not listed in SRC_URI.
 * Emerge now uses --resume to restart itself after portage upgrade.
diff --git a/cnf/make.conf.example b/cnf/make.conf.example
index 36fc9a8e4..ffebd24d4 100644
--- a/cnf/make.conf.example
+++ b/cnf/make.conf.example
@@ -130,13 +130,13 @@
 # storage. See the PORTDIR documentation for more information.
 #PKGDIR=/usr/portage/packages
 #
-# PORT_LOGDIR is the location where portage will store all the logs it
+# PORTAGE_LOGDIR is the location where portage will store all the logs it
 # creates from each individual merge. They are stored as
 # ${CATEGORY}:${PF}:MMDD-HHMMSS.log in the directory specified.
 # If the directory does not exist, it will be created automatically and
 # group permissions will be applied to it.  If the directory already
 # exists, portage will not modify its permissions.
-#PORT_LOGDIR=""
+#PORTAGE_LOGDIR=""
 #
 # PORTDIR_OVERLAY is a directory where local ebuilds may be stored without
 # concern that they will be deleted by rsync updates. Default is not
@@ -306,16 +306,16 @@
 # PORTAGE_ELOG_SYSTEM: selects the module(s) to process the log messages. 
Modules
 #  included in portage are (empty means logging is 
disabled):
 #  echo (display messages again when emerge exits)
-#  save (saves one log per package in 
$PORT_LOGDIR/elog,
-#/var/log/portage/elog if $PORT_LOGDIR is 
unset)
+#  save (saves one log per package in 
$PORTAGE_LOGDIR/elog,
+#/var/log/portage/elog if $PORTAGE_LOGDIR is 
unset)
 #  custom (passes all messages to 
$PORTAGE_ELOG_COMMAND)
 #  syslog (sends all messages to syslog)
 #  mail (send all messages to the mailserver defined
 #in $PORTAGE_ELOG_MAILURI)
 #  save_summary (like "save" but merges all messages
-#in $PORT_LOGDIR/elog/summary.log,
+#in $PORTAGE_LOGDIR/elog/summary.log,
 #/var/log/portage/elog/summary.log if
-#$PORT_LOGDIR is unset)
+#$PORTAGE_LOGDIR is unset)
 #  mail_summary (like "mail" but sends all messages in
 #a single mail when emerge exits)
 #  To use elog you should enable at least one module
diff --git a/cnf/make.globals b/cnf/make.globals
index 1bcc7ce64..5a3015ae2 100644
--- a/cnf/make.globals
+++ b/cnf/make.globals
@@ -101,7 +101,7 @@ PORTAGE_RSYNC_OPTS="--recursive --links --safe-links 
--perms --times --omit-dir-
 PORTAGE_SYNC_STALE="30"
 
 # Executed before emerge exit if FEATURES=clean-logs is enabled.
-PORT_LOGDIR_CLEAN="find \"\${PORT_LOGDIR}\" -type f ! -name \"summary.log*\" 
-mtime +7 -delete"
+PORTAGE_LOGDIR_CLEAN="find \"\${PORTAGE_LOGDIR}\" -type f ! -name 
\"summary.log*\" -mtime +7 -delete"
 
 # Minimal 

[gentoo-portage-dev] [PATCH 2/4] Provide compatibility support for old PORT_LOGDIR* variable names

[M. J. Everitt]

Suggested-by: Zac Medico 
Acked-by: Michael Everitt 
Bug: https://bugs.gentoo.org/668538
---
 lib/portage/package/ebuild/config.py | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/lib/portage/package/ebuild/config.py 
b/lib/portage/package/ebuild/config.py
index a68df5807..5c1404389 100644
--- a/lib/portage/package/ebuild/config.py
+++ b/lib/portage/package/ebuild/config.py
@@ -155,6 +155,9 @@ class config(object):
_constant_keys = frozenset(['PORTAGE_BIN_PATH', 'PORTAGE_GID',
'PORTAGE_PYM_PATH', 'PORTAGE_PYTHONPATH'])
 
+   _deprecated_keys = {'PORTAGE_LOGDIR': 'PORT_LOGDIR',
+   'PORTAGE_LOGDIR_CLEAN': 'PORT_LOGDIR_CLEAN'}
+
_setcpv_aux_keys = ('BDEPEND', 'DEFINED_PHASES', 'DEPEND', 'EAPI', 
'HDEPEND',
'INHERITED', 'IUSE', 'REQUIRED_USE', 'KEYWORDS', 'LICENSE', 
'PDEPEND',
'PROPERTIES', 'RDEPEND', 'SLOT',
@@ -2653,6 +2656,14 @@ class config(object):
except KeyError:
pass
 
+   deprecated_key = self._deprecated_keys.get(mykey)
+   if deprecated_key is not None:
+   value = self._getitem(deprecated_key)
+   warnings.warn(_("Key %s has been renamed to %s. Please 
",
+   "update your configuration") % (deprecated_key, 
mykey),
+   UserWarning)
+   return value
+
raise KeyError(mykey)
 
def get(self, k, x=None):
-- 
2.13.6





signature.asc
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538

[M. J. Everitt]

This patchset aims to fix potential ambiguity and confusion between older 
PORT_LOG* variables,
and more recent PORTAGE_* variables - often leading to mysteriously lacking 
logging due to
incorrect variable names. Documented in Bug 668538; with thanks to Zac for 
diagnosis, and
solution assistance!

M. J. Everitt (4):
  Renamed PORT_LOGDIR[_CLEAN] to PORTAGE_LOGDIR[_CLEAN]
  Provide compatibility support for old PORT_LOGDIR* variable names
  Update documentation for PORT_LOGDIR* changes
  Add note to NEWS/ChangeLog for PORT_LOGDIR* changes

 NEWS   |  8 +++-
 cnf/make.conf.example  | 12 +++---
 cnf/make.globals   |  2 +-
 lib/_emerge/post_emerge.py |  2 +-
 lib/portage/dbapi/vartree.py   |  2 +-
 lib/portage/elog/mod_echo.py   |  2 +-
 lib/portage/elog/mod_save.py   |  4 +-
 lib/portage/elog/mod_save_summary.py   |  4 +-
 lib/portage/emaint/modules/logs/__init__.py|  2 +-
 lib/portage/emaint/modules/logs/logs.py| 22 +--
 .../package/ebuild/_config/special_env_vars.py |  2 +-
 lib/portage/package/ebuild/config.py   | 11 ++
 lib/portage/package/ebuild/prepare_build_dirs.py   | 26 ++--
 lib/portage/tests/emerge/test_simple.py|  2 +-
 man/ebuild.5   |  2 +-
 man/emaint.1   |  6 +--
 man/emerge.1   |  2 +-
 man/make.conf.5| 46 --
 18 files changed, 90 insertions(+), 67 deletions(-)

-- 
2.13.6




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [pre-GLEP] Gentoo binary package container format [gen...@jonesmz.com]

[M. J. Everitt]

On 18/11/18 22:40, Zac Medico wrote:
> On 11/18/18 1:55 PM, Rich Freeman wrote:
>> On Sun, Nov 18, 2018 at 4:10 PM Roy Bamford  wrote:
>>> Replying off list because I am not on the whitelist.
>> That seems odd.
>>
>>> 1) append a uuid to each filename. Generated when the bin package file is 
>>> generated.
>>> 2) encode the hostname of the machine that generated the file
>>> 3) encode the use flags in the filename.
>> So, I brought up this same issue in the earlier discussion and it was
>> considered out of scope, and I think this is fair.  The GLEP does not
>> specify filename, and IMO the standard for what goes INSIDE the file
>> will work just fine with any future enhancements that address exactly
>> this use case.
>>
>> Besides your case of building for a cluster, another use case is
>> having a central binary repo that portage could check and utilize when
>> a user's preferences happen to match what is pre-built.
>>
>> I suggest we start a different thread for any additional discussion of
>> this use case.  I was thinking and it probably wouldn't be super-hard
>> to actually start building something like this.  But, I don't want to
>> derail this GLEP as I don't see any reason designing something like
>> this needs to hold up the binary package format.  Both the existing
>> and proposed binary package formats will encode any metadata needed by
>> the package manager inside the file, and the only extension we need is
>> to encode identifying info in the filename.
>>
>> My idea is to basically have portage generate a tag with all the info
>> needed to identify the "right" package, take a hash of it, and then
>> stick that in the filename.  Then when portage is looking for a binary
>> package to use at install time it generates the same tag using the
>> same algorithm and looks for a matching hash.  If a hit is found then
>> it reads the complete metadata in the file and applies all the sanity
>> checks it already does.  Generating of binary packages with the hash
>> cold be made optional, and portage could also be configured to first
>> look for the matching hash, then fall back to the existing naming
>> convention, so that it would be compatible with existing generic
>> names.  So, users would get a choice as to whether they want to build
>> up a library of these packages, or just have each build overwrite the
>> last.
>>
>> Then the next step would be to allow these files to be fetched from a
>> binary repo optionally, and then finally we'd need tools to create the
>> repo.  But, this step isn't needed for your use case.  With the proper
>> optional switches you could utilize as much of this scheme as you
>> like.
>>
>> Also, you could optionally choose how much you want portage to encode
>> in the tag and look for.  Are you very fussy and only want a binary
>> package with matching CFLAGS/USE/whatever?  Or is just matching
>> USE/arch/etc enough?  Some of the existing portage options could
>> potentially be re-used here.
> We've already had this handled for a couple years now, via
> FEATURES=binpkg-multi-instance.
Working fine for me for catalyst ARM runs ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2 3/3] Introduce a tiny init replacement for inside pid namespace

[M. J. Everitt]

On 18/11/18 09:18, Michał Górny wrote:
> On Sun, 2018-11-18 at 09:04 +0000, M. J. Everitt wrote:
>> On 18/11/18 08:53, Michał Górny wrote:
>>> Signed-off-by: Michał Górny 
>>> ---
>>>  bin/pid-ns-init| 25 +
>>>  lib/portage/process.py | 11 ++-
>>>  2 files changed, 31 insertions(+), 5 deletions(-)
>>>  create mode 100644 bin/pid-ns-init
>>>
>>> diff --git a/bin/pid-ns-init b/bin/pid-ns-init
>>> new file mode 100644
>>> index 0..90660571a
>>> --- /dev/null
>>> +++ b/bin/pid-ns-init
>>> @@ -0,0 +1,25 @@
>>> +#!/usr/bin/env python
>>> +# Copyright 2018 Gentoo Authors
>>> +# Distributed under the terms of the GNU General Public License v2
>>> +
>>> +import os
>>> +import sys
>>> +
>>> +
>>> +def main(argv):
>>> +   if len(argv) < 2:
>>> +   return 'Usage: {} '.format(argv[0])
>>> +   main_child_pid = int(argv[1])
>>> +
>>> +   # wait for child processes
>>> +   while True:
>>> +   pid, status = os.wait()
>>> +   if pid == main_child_pid:
>>> +   return os.WEXITSTATUS(status)
>>> +
>>> +   # this should never be reached
>>> +   return 127
>>> +
>>> +
>>> +if __name__ == '__main__':
>>> +   sys.exit(main(sys.argv))
>>> diff --git a/lib/portage/process.py b/lib/portage/process.py
>>> index dee126c3c..75ec299f0 100644
>>> --- a/lib/portage/process.py
>>> +++ b/lib/portage/process.py
>>> @@ -544,13 +544,14 @@ def _exec(binary, mycommand, opt_name, fd_pipes, env, 
>>> gid, groups, uid, umask,
>>> else:
>>> if unshare_pid:
>>> # pid namespace 
>>> requires us to become init
>>> -   # TODO: do init-ty stuff
>>> -   # therefore, fork() ASAP
>>> fork_ret = os.fork()
>>> if fork_ret != 0:
>>> -   pid, status = 
>>> os.waitpid(fork_ret, 0)
>>> -   assert pid == 
>>> fork_ret
>>> -   os._exit(status)
>>> +   
>>> os.execv(portage._python_interpreter, [
>>> +   
>>> portage._python_interpreter,
>>> +   
>>> os.path.join(portage._bin_path,
>>> +   
>>> 'pid-ns-init'),
>>> +   '%s' % 
>>> fork_ret,
>>> +   ])
>>> if unshare_mount:
>>> # mark the whole 
>>> filesystem as slave to avoid
>>> # mounts escaping the 
>>> namespace
>> Why in python?! Surely a small C app would be significantly more efficient ..
>>
> Surely adding a new build system for C apps would be entirely justified
> by the necessity of premature optimization of program that spends ~100%
> of its time in wait().
>
Forgive my ignorance then .. what purpose does a process have which simply
wait()s ?! .. no, on second thoughts, don't answer that question, I'm
unlikely to like the answer anyway ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2 3/3] Introduce a tiny init replacement for inside pid namespace

[M. J. Everitt]

On 18/11/18 08:53, Michał Górny wrote:
> Signed-off-by: Michał Górny 
> ---
>  bin/pid-ns-init| 25 +
>  lib/portage/process.py | 11 ++-
>  2 files changed, 31 insertions(+), 5 deletions(-)
>  create mode 100644 bin/pid-ns-init
>
> diff --git a/bin/pid-ns-init b/bin/pid-ns-init
> new file mode 100644
> index 0..90660571a
> --- /dev/null
> +++ b/bin/pid-ns-init
> @@ -0,0 +1,25 @@
> +#!/usr/bin/env python
> +# Copyright 2018 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +import os
> +import sys
> +
> +
> +def main(argv):
> + if len(argv) < 2:
> + return 'Usage: {} '.format(argv[0])
> + main_child_pid = int(argv[1])
> +
> + # wait for child processes
> + while True:
> + pid, status = os.wait()
> + if pid == main_child_pid:
> + return os.WEXITSTATUS(status)
> +
> + # this should never be reached
> + return 127
> +
> +
> +if __name__ == '__main__':
> + sys.exit(main(sys.argv))
> diff --git a/lib/portage/process.py b/lib/portage/process.py
> index dee126c3c..75ec299f0 100644
> --- a/lib/portage/process.py
> +++ b/lib/portage/process.py
> @@ -544,13 +544,14 @@ def _exec(binary, mycommand, opt_name, fd_pipes, env, 
> gid, groups, uid, umask,
>   else:
>   if unshare_pid:
>   # pid namespace 
> requires us to become init
> - # TODO: do init-ty stuff
> - # therefore, fork() ASAP
>   fork_ret = os.fork()
>   if fork_ret != 0:
> - pid, status = 
> os.waitpid(fork_ret, 0)
> - assert pid == 
> fork_ret
> - os._exit(status)
> + 
> os.execv(portage._python_interpreter, [
> + 
> portage._python_interpreter,
> + 
> os.path.join(portage._bin_path,
> + 
> 'pid-ns-init'),
> + '%s' % 
> fork_ret,
> + ])
>   if unshare_mount:
>   # mark the whole 
> filesystem as slave to avoid
>   # mounts escaping the 
> namespace
Why in python?! Surely a small C app would be significantly more efficient ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Re: [RFC] Improving Gentoo package format

[M. J. Everitt]

On 11/11/18 19:20, Rich Freeman wrote:
> On Sun, Nov 11, 2018 at 1:02 PM M. J. Everitt  wrote:
>> If you can really present a decent argument for replicating the
>> functionality of other distros like Debian, Arch, Ubuntu etc then let's
>> here it. For now, the strength of Gentoo is being able to fully customise a
>> system to your own requirements, not being trapped by some distro
>> maintainer's arbitrary choices. Play to your USP's and strengths rather
>> than chasing rainbows ..
>>
> Why do we support binary packages at all?  Simple: compiling packages
> is expensive, and if you happen to already have them compiled, fully
> customized to your own requirements, then there is no point in
> recompiling them.  You're just spending a ton of resources to build
> the exact same files you already have.
>
> The only change I'm suggesting is that portage could take all the
> configuration you're already supplying, and then optionally go see if
> somebody you trust has already built the package that meets your
> requirements.  If so, then it would be downloaded and installed,
> otherwise it would just compile from source.
>
> You get the exact same files installed on your system either way.
>
Ok so I get the principle, but who's gonna provide the tools to make this
feasible, and perhaps more interestingly, who's going to curate, provide,
host and maintain the binpkg repos you propose? We barely have enough
developers to maintain a working source package repository, let alone
adding new distro "features" .. unless perhaps you have a few hours every
week to spare?

I see no sense in reinventing the wheel here, besides #thegentooway



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Re: [RFC] Improving Gentoo package format

[M. J. Everitt]

On 11/11/18 18:41, Rich Freeman wrote:
> On Sun, Nov 11, 2018 at 12:31 PM M. J. Everitt  wrote:
>> Binpkgs are also a popular component of a few downstream distro's based on
>> Gentoo (thinking pentoo right now as an easy example).
>>
>> So we don't want to break existing users of this format without considering
>> the ramifications for these scenarios, as you'll have some very grumpy 
>> devs...
>>
> I'd argue that they'd be more important for Gentoo if they were more
> useful.  IMO the main limitation with them is the inability to
> auto-download them from a repository, detecting the binpkg USE flags
> BEFORE downloading.  This is why I suggested hashing the USE flags or
> similar and sticking that in the filename.
>
> Obviously you can't host a repository with all the USE combinations.
> However, you could have a reference repo and the package manager could
> check it before doing a build.  If you get a hit then you can install
> the binpkg.  If you don't then you can do a source build.
>
> Portage already checks the USE flags inside the binpkg before merging
> it and by default doesn't use a non-matching binpkg.  The problem with
> the current approach is:
> 1.  You have to download the package to check this (could be a big file).
> 2.  You can't host multiple versions of a binpkg with different USE
> flags since the filenames collide.
>
> I suggested a content hash because you can use it for an arbitrary
> amount of metadata, vs having to cram arch/USE/multilib and I'm sure
> something I'm missing into a filename.  Make the hash as short as is
> economical - it isn't like we have THAT many permutations, the PM can
> still check the internal metadata, and this isn't a security feature.
>
If you can really present a decent argument for replicating the
functionality of other distros like Debian, Arch, Ubuntu etc then let's
here it. For now, the strength of Gentoo is being able to fully customise a
system to your own requirements, not being trapped by some distro
maintainer's arbitrary choices. Play to your USP's and strengths rather
than chasing rainbows ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] Re: [RFC] Improving Gentoo package format

[M. J. Everitt]

On 11/11/18 18:15, Duncan wrote [excerpted]:
> Is there any interest at all in binpkgs, perhaps when improved, from the 
> other PMs?  Or are they effectively dead now or not interested in binpkgs 
> even if the format were to be improved, or simply too hard to work with?  
> Because "it'd be nice" (aka MAY level) to have this formally standardized 
> to PMS... if there's any interest from the other PMs.
>
Binpkgs are an important part of catalyst/releng stage-building runs, as it
allows portage to 'cache' a lot of the packages needed/used.

Binpkgs are also a popular component of a few downstream distro's based on
Gentoo (thinking pentoo right now as an easy example).

So we don't want to break existing users of this format without considering
the ramifications for these scenarios, as you'll have some very grumpy devs...



signature.asc
Description: OpenPGP digital signature

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

[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?

[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] [PATCH] udev.eclass: support EAPI 7

[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

Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[M. J. Everitt]

On 26/08/18 19:14, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 26.08.2018 kell 19:14, kirjutas Michał Górny:
>> One thing where this would fail would be e.g.:
>>
>>   LICENSE="GPL-2+
>> bar? ( GPL-2 )
>> foo? ( GPL-3+ )" ^ you can't put a comment on the right line
> LICENSE="GPL-2+ "
> LICENSE+="bar? ( GPL-2 ) " # GPL-2 only
> LICENSE+="foo? ( GPL-3+ )"
.. and [then] enforce the ensuing format change via Repoman ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo i486 support

[M. J. Everitt]

On 22/08/18 20:20, Matt Turner wrote:
> On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler  wrote:
>> 2) Patch catalyst to start setting CXXFLAGS again.  Rather than roll
>> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
>> start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
>> CXXFLAGS=${COMMON_FLAGS}" etc.  I prepared such a patch a while back
>> [4], which seems to work but may need a bit of updating.
> [snip]
>> [2]
>> https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
> I don't think that was intentional, was it?
>
> That commit looks like it's supposed to just be a plain refactor (It's
> titled "stagebase.py: Refactor the *FLAGS handling code in
> chroot_setup()" after all) so it shouldn't have changed behavior. I'm
> guessing the commit is just broken. It doesn't even look like the
> commit message was finished when it was pushed.
>
> I think you should do whatever is required to fix catalyst brokenness.
>
Discussions on IRC in -releng demonstrate that this change resulted in
the CXXFLAGS variable *disappearing* from the stage3 make.conf. I
consider this a regressoin. I haven't personally looked as to how this
happened (although I'm familiar with the code from ARM profile changes),
but I think that also needs fixing. All my workstations descend from the
time when both CFLAGS *and* CXXFLAGS were set in make.conf and I hadn't
noticed this until today; however, this is a secondary issue to the one
that Ben has highlighted, which is a rather unhelpful fall-back
situation for x86 users ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [arm17] [PATCH 0/3] toolchain-funcs.eclass: tc-is-softfloat for ARM and associated functions

[M. J. Everitt]

On 21/08/18 21:38, James Le Cuirot wrote:
> On Tue, 14 Aug 2018 21:33:01 +0100
> James Le Cuirot  wrote:
>
>> I previously sent a single patch to this list entitled
>> "Update tc-is-softfloat for new ARM tuples" but I have now added two
>> further patches following the initial feedback.
>>
>> For the additional background behind these changes, please see:
>> https://archives.gentoo.org/gentoo-dev/message/b55b141e76ae1e08279d6f5b33be8151
>>
>> James Le Cuirot (3):
>>   toolchain-funcs.eclass: New tc-getTARGET_CPP function
>>   toolchain-funcs.eclass: tc-cpp-is-true function to simplify helpers
>>   toolchain-funcs.eclass: Update tc-is-softfloat for new ARM tuples
>>
>>  eclass/toolchain-funcs.eclass | 138 +++---
>>  1 file changed, 96 insertions(+), 42 deletions(-)
> There were no further comments so this has been pushed.
>


A commit id is often popular - not because we don't believe you pushed,
but for any potential future reference :).




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] waf-utils.eclass: WAF_VERBOSE always effectively on

[M. J. Everitt]

On 14/08/18 08:03, Joke Junkie wrote:
> Fix broken behavior not allowing to change the default verbosity.
> This should be of importance to everybody building on SMP systems, since
> giving the --verbose option to waf breaks a multi-job build (by making
> it one-job), at least for me. This is probably a waf issue, but the
> inability to change WAF_VERBOSE is clearly a bug in the eclass.
> The test affected by change is always true because WAF_VERBOSE is always
> set to "ON" or other non-null value. The change fixes that.
> ---
>  eclass/waf-utils.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/waf-utils.eclass b/eclass/waf-utils.eclass
> index 7acc97b10314..8b011c04b400 100644
> --- a/eclass/waf-utils.eclass
> +++ b/eclass/waf-utils.eclass
> @@ -98,7 +98,7 @@ waf-utils_src_configure() {
>  waf-utils_src_compile() {
>   debug-print-function ${FUNCNAME} "$@"
>   local _mywafconfig
> - [[ "${WAF_VERBOSE}" ]] && _mywafconfig="--verbose"
> + [[ "${WAF_VERBOSE}" = "ON" ]] && _mywafconfig="--verbose"
>
>   local jobs="--jobs=$(makeopts_jobs)"
>   echo "\"${WAF_BINARY}\" build ${_mywafconfig} ${jobs}"
>
There is always a trade-off here as to what a flag *means* .. does
simply specifying it mean that its 'set' or do you need one of the
following (set) to actually define it - [on,yes,y,ON,YES,Y,1].
Parsing such a set is slightly more tedious than simply accepting it's
existence, bearing in mind you need similar logic for the inverse
(OFF,off,NO,no,N,n,0].
I think the portage code-base is the one area I've seen this kinda of
option-handling (and overrides) done pretty well (potentially not
'perfect', i just said 'pretty well').





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] XARGS: use gxargs for USERLAND=BSD (bug 663256)

[M. J. Everitt]

On 10/08/18 00:17, M. J. Everitt wrote:
> On 10/08/18 00:04, Zac Medico wrote:
>> For USERLAND=BSD, set XARGS="gxargs -r" if gxargs is available,
>> so the code from bug 630292 works for USERLAND=BSD.
>>
>> Fixes: 50283f1abb77 (install-qa-check.d/60pngfix: parallel support (bug 
>> 630292))
>> Reported-by: Michał Górny 
>> Bug: https://bugs.gentoo.org/663256
>> ---
>>  bin/isolated-functions.sh | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
>> index 28ca94532..cac42a4c5 100644
>> --- a/bin/isolated-functions.sh
>> +++ b/bin/isolated-functions.sh
>> @@ -448,7 +448,11 @@ fi
>>  if [[ -z ${XARGS} ]] ; then
>>  case ${USERLAND} in
>>  BSD)
>> -export XARGS="xargs"
>> +if type -P gxargs > /dev/null; then
>> +export XARGS="gxargs -r"
>> +else
>> +export XARGS="xargs"
>> +fi
>>  ;;
>>  *)
>>  export XARGS="xargs -r"
> Isn't the else clause there redundant?
>
Oops, sorry missed the minus before the first export .. my bad .. 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] XARGS: use gxargs for USERLAND=BSD (bug 663256)

[M. J. Everitt]

On 10/08/18 00:04, Zac Medico wrote:
> For USERLAND=BSD, set XARGS="gxargs -r" if gxargs is available,
> so the code from bug 630292 works for USERLAND=BSD.
>
> Fixes: 50283f1abb77 (install-qa-check.d/60pngfix: parallel support (bug 
> 630292))
> Reported-by: Michał Górny 
> Bug: https://bugs.gentoo.org/663256
> ---
>  bin/isolated-functions.sh | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/bin/isolated-functions.sh b/bin/isolated-functions.sh
> index 28ca94532..cac42a4c5 100644
> --- a/bin/isolated-functions.sh
> +++ b/bin/isolated-functions.sh
> @@ -448,7 +448,11 @@ fi
>  if [[ -z ${XARGS} ]] ; then
>   case ${USERLAND} in
>   BSD)
> - export XARGS="xargs"
> + if type -P gxargs > /dev/null; then
> + export XARGS="gxargs -r"
> + else
> + export XARGS="xargs"
> + fi
>   ;;
>   *)
>   export XARGS="xargs -r"
Isn't the else clause there redundant?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 5/5] eutils.eclass: Restore the original path_exists function

[M. J. Everitt]

On 08/08/18 22:34, Michał Górny wrote [excerpted]:
> +# Example:
> +# @CODE
> +# if path_exists "${ROOT}"/etc/foo.d/*.conf; then
> +#   do_something
> +# fi
> +# @CODE
>  path_exists() {
> - local opt=$1
> - [[ ${opt} == -[ao] ]] && shift || opt="-a"
> -
> - # no paths -> return false
> - # same behavior as: [[ -e "" ]]
> - [[ $# -eq 0 ]] && return 1
> -
> - local p r=0
> - for p in "$@" ; do
> - [[ -e ${p} ]]
> - : $(( r += $? ))
> + local p
> + for p; do
> + [[ -e ${p} ]] && return 0
>   done
You seem to have lost the inclusion of the function parameters in the
execution code - was this intentional?!
Regards,
Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v3 0/2] Two insecure ownership and group-writability QA checks.​

[M. J. Everitt]

On 07/08/18 17:46, Michael Orlitzky wrote:
> Changes in v3:
>
>   * Undo the setguid exception from v2, and add a comment explaining why.
>   * Add line breaks for readability in two comments.
>   * Try to put back the leading "/" in the output list.
>   * Remove a superfluous comment mentioning the "prefix."
>
> Michael Orlitzky (2):
>   bin/install-qa-check.d: add new 90bad-bin-owner QA check.
>   bin/install-qa-check.d: add new 90bad-bin-group-write QA check.
>
>  bin/install-qa-check.d/90bad-bin-group-write | 55 
> 
>  bin/install-qa-check.d/90bad-bin-owner   | 48 
>  2 files changed, 103 insertions(+)
>  create mode 100644 bin/install-qa-check.d/90bad-bin-group-write
>  create mode 100644 bin/install-qa-check.d/90bad-bin-owner
>
May I just briefly complement you on your patch mail format ..

It's much easier to see, when you make updates to a patchset, that you
have added a summary in your 0/x mail for what changed from the previous
iteration.

I don't think git has an easy way to both describe the patch diffs from
the original *and* the changes from last iteration to current - that
really would be the cherry on the icing on the cake! (something perhaps
the avid perl users may be able to graft together!).

Keep up the good work :)
Best regards,

Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)

[M. J. Everitt]

On 06/08/18 19:35, Zac Medico wrote:
> On 08/06/2018 12:30 AM, Brian Dolbec wrote:
>> All these changes as well as the catlayst changes need to be
>> co-ordinated so that snapshots and portage and stages don't precede the
>> docs changes.
> I suppose all of the docs changes can be made in advance, with mention
> of both old a new locations. These commands can be used to check the
> local configuration:
>
> portageq get_repo_path / gentoo
> portageq distdir
> portageq pkgdir
Sounds like a plan .. do we need a tracker bug?! :P

Let's do this! :D

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

On 05/08/18 18:24, Rich Freeman wrote:
> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner  wrote:
>>
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>>
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.
>
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
>
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
>
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
>
"Cloud-based Gentoo" - yeah I see *absolutely no issues* with this ...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

On 05/08/18 18:01, Alec Warner wrote [excerpted]:
>
>
> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao  > wrote:
>
>
>
> On Jun 23, 2018, at 6:59 AM, Alec Warner  > wrote:
>
>>
>> I suspect this might be better done in the Linux foundation
>> itself as they have staffing for core components that everyone is
>> using.
> This would put decision making power into the hands of
> bureaucrats. I would rather it remain in a community of volunteers.
>
>
> Meh, it doesn't hurt to ask there about interest (they certainly fund
> development of other components.) Its not like they have to accept, or
> that declining somehow inhibits this development.
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>  
Maintaining a distro is increasingly becoming more a case of fixing
upstream's shortcomings, as they move towards completely-bundled
packages instead of thorough testing. Creating distribution packages,
especially in a source-based distro like Gentoo, requires quite a lot of
testing, and a lot of collating user feedback (in terms of bugs) to make
sure that the packages built do actually *work*.

So no, whilst it does seem on the surface to be a dilution of effort, if
it reduces the overall effort to generate robust packages, and
distributes it across multiple distros and developers, whilst
co-ordination and communication may prove a new challenge, I think this
is complementary to what everyone is trying to achieve.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)

[M. J. Everitt]

On 29/07/18 21:01, Rich Freeman wrote:
> 
>
> Why not stick the repos in /var/repos and not /var/db/repos?  If we're
> just making up paths, why not make up a shorter one?  I don't think
> any other linux distros use /var/db...
>
*BSD I believe ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [arm17] Background to ARM 17.0 profile migration

[M. J. Everitt]

On 25/07/18 00:07, James Le Cuirot wrote:

> My initial migration guide was rather scary as changing CHOST is never
> easy and I was concerned that such a guide was never going to be
> sufficiently palatable for a news item. I didn't expect to be able to
> script it up but I gave it a shot and I'm actually quite happy with
> the result. I've run it on the newest (but quite old) glibc stage3, the
> newest musl stage3, and the newest glibc hardened stage3. All went
> well. It aborts on failure but allows you to rerun it if necessary and
> it will skip the time-consuming builds that have already completed.
> Please give it a try if you can and leave some feedback.
Cool - well done, will give it a roll this end...

[1] was the bug where we were tackling migration attempts ..
> Obviously we will need new stage tarballs so that new systems can start
> with the new triplet. The official arm stage tarballs are ancient and I
> have already prepared new stages for armv7a/glibc and armv6j/musl.
> veremitz has been busy building others. The RelEng team has agreed to
> put these up once the profiles go live. Hopefully regular stage
> auto-builds will return in the near future.
>
> I will now follow up this mail with others tagged [arm17] containing:
>
> 1. The news item (including a link to the migration script)
> 2. A toolchain-funcs.eclass patch
> 3. A crossdev patch
>
> Catalyst will need updating too but I will leave it to the RelEng team
> to decide whether they want to update the existing specs or create new
> ones.
>
> Cheers,
The specs 'tree' is a bit of a mess already .. perhaps we can look at
giving it a heavy prune... ??

Updated arm17-stage3's should be building over the weekend all being
well, and no further hardware collapses back at base :/ tfw!

[1] - https://bugs.gentoo.org/602440



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding USE=udev to linux profiles

[M. J. Everitt]

On 20/07/18 13:39, n...@troglodyte.be wrote:
> Hi,
>
> July 20, 2018 2:26 PM, "Ben Kohler"  wrote:
>
>> On 07/19/18 23:04, Michael Orlitzky wrote:
>>
>>> 
>>>
>>> If you really want to enable it globally after being told that it's bad
>>> engineering and downright annoying, go do it in a profile that I can
>>> avoid and not "linux".
>> I believe you're arguing against profile global USE in general, can you
>> start a new thread for that if you believe it's worth discussing?
>>
>> We do have global USE in profiles now and I believe that the sane
>> default for linux profiles is to have udev support globally.
> Why not introducing a new level in the hierarchy ? Something like "common" 
> could be fit.
>
> default/linux/amd64/13.0
> default/linux/amd64/13.0/common
> default/linux/amd64/13.0/common/desktop
> default/linux/amd64/13.0/common/developer
> ...
>
> By doing so we could still have a bare profiles with minimal things set to 
> work, and have the
> common subset with sane defaults for most users.
>
> --
> Corentin “Nado” Pazdera
>
default/linux/amd64/17.0/minimal
default/linux/amd64/17.0/default
default/linux/amd64/17.0/default/desktop
default/linux/amd64/17.0/default/desktop/kde
default/linux/amd64/17.0/developer

The hierarchy method is indeed flawed, it would be better to have
something akin to USE flags for profiles (PROFLAGS?) .. so that you
could mingle different aspects without replicating sections of the
'tree' to get the common configurations covered ..

eg. LINUX + AMD64 + DEVELOPER + KDE
LINUX + ARM + DESKTOP
LINUX + X86 + CONTAINER
FREEBSD + DESKTOP

And then have some rules which say that .. eg. KDE inherits DESKTOP (if
required)

I know you're gonna bike-shed this to death, but its an idea ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding USE=udev to linux profiles

[M. J. Everitt]

On 20/07/18 13:20, Ben Kohler wrote:
> On 07/19/18 20:54, Mikle Kolyada wrote:
>
>> +1. widely used profiles should have as least flags enabled by default
>> as possible, I would not be happy with +udev on my servers.
>>
> I disagree with this premise.  The default and most widely used profiles
> should fit the most common use cases.
>
> I'd be curious as to what problems would be caused on your servers if
> this flag were turned on-- specifically what packages will get the flag
> turned on, where that bothers you?  On my servers, the impact is very
> minimal.
>
> I'm not totally sure that my proposal of USE=udev is correct/justified,
> but there are a few counter-arguments I've heard that I don't think hold
> water, I'd like to focus on the others.
>
> -Ben
Ben: Were you trying to sign your email .. a strange .asc attachment
came through this end?

Can we make a 'minimal'/container/etc _profile_ for such use-cases
perhaps? so that linux 'default' might have +udev but this minimal
doesn't .. or won't the overlapping of profiles allow this?



signature.asc
Description: OpenPGP digital signature

[RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

[M. J. Everitt]

On 18/07/18 13:20, Kristian Fiskerstrand wrote:
> On 07/18/2018 02:10 PM, Alexis Ballier wrote:
>> I often find myself in the
>> need to use/invent some abbreviation in order to fit the limit.
>> Considering this is an error, this sends the message that short is
>> preferred over clear.
> Or that the summary should be concise and a longer proper description
> can be written in the body of the commit message instead. Potentially
> mixed in with multiple commits for different logical changes etc etc.
>
Perhaps the time has come to re-assess the commit message "standard".
I'm thinking something along the lines of the following:
- Line one is limited to / and some Key Word that defines the
type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP,
EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the
issue of long package-names and/or overlays and other lengthy prefixes.
- Line two remains a blank line at present
- Line three+ actually describe what the change is, in plain English.
- Footer~3: Bug/Pull reference
- Footer~2: Signed/Authored/etc standard footer text(s)
- Footer: Package manager/repoman as appropriate
where: 3+ (line three onwards), ~n: approx. line prior to end (EOF-n)

This should satisfy line length limitations, whilst still preserving
some Basic information about commit type, which can then be sub-filtered
if necessary. I can't presently see anything that would preclude
tool-friendly parsing of such messages... or repoman applying
appropriate checks...

NB. I may have swapped F~3 and F~2 lines around .. order can be
preserved as present.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving default location of portage tree

[M. J. Everitt]

On 10/07/18 21:09, William Hubbs wrote:
> On Mon, Jul 09, 2018 at 03:54:35PM -0700, Zac Medico wrote:
>> On 07/09/2018 03:27 PM, M. J. Everitt wrote:
>>> On 09/07/18 23:12, Zac Medico wrote:
>>>> On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote:
>>>>> I'd mostly argue any such change should only affect new systems
>>>>>
>>>> Yes, changing defaults for existing systems would be annoying.
>>>>
>>>> My recommendation is to have catalyst set the new defaults in the stage
>>>> tarballs.
>>>>
>>>> When sys-apps/portage changes its internal defaults, I'd like for the
>>>> upgrade process to call a tool that generates configuration files when
>>>> necessary to ensure that the existing paths remain constant.
>>> I think it should be possible for RelEng to make a start on catalyst
>>> updates - is there anything that would inhibit going ahead with this,
>>> potentially?
>> No, nothing. Whatever catalyst puts it the default config will become
>> our new default.
> I would still like to see notice about what the new defaults are and how
> to migrate current systems to them.
>
>
> Thanks,
>
> William
>
>> -- 
>> Thanks,
>> Zac
>>
>
>
I'd like to propose that further to the discussion here on the -dev
mailing list, the Council discuss and make a firm proposal on the new
default paths, and then RelEng can make the appropriate updates to the
catalyst builds. A news item can be compiled, with an appropriate wiki
article perhaps on migration strategy (I may volunteer to format such a
page with some appropriate guidance).
Regards,
Michael / veremitz.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: moving default location of portage tree

[M. J. Everitt]

On 09/07/18 23:12, Zac Medico wrote:
> On 07/09/2018 02:34 PM, Kristian Fiskerstrand wrote:
>> I'd mostly argue any such change should only affect new systems
>>
> Yes, changing defaults for existing systems would be annoying.
>
> My recommendation is to have catalyst set the new defaults in the stage
> tarballs.
>
> When sys-apps/portage changes its internal defaults, I'd like for the
> upgrade process to call a tool that generates configuration files when
> necessary to ensure that the existing paths remain constant.
I think it should be possible for RelEng to make a start on catalyst
updates - is there anything that would inhibit going ahead with this,
potentially?

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Portage rsync hardlink support

[M. J. Everitt]

On 08/07/18 18:34, Rich Freeman wrote:
> On Sun, Jul 8, 2018 at 9:02 AM Kristian Fiskerstrand  wrote:
>> On 07/08/2018 08:53 AM, Michał Górny wrote:
>>> Is safe git syncing implemented already? If not, maybe finish it first and 
>>> cover both with a single news item. Git is going to be more efficient here, 
>>> so people may want to learn they have an alternative.
>> Why complicate things, and increase wait for something that benefits
>> most users, just to give alternatives to a few using non-default sync
>> mechanism. Securing git distribution is a whole different ballpark.
>>
> I'll agree that it is different, but we're talking about verification
> of the HEAD signature by infra, not verification of individual
> developer keys, which was the topic of the recent thread.
>
> Verification is already built-into portage for git syncing (but off by
> default).  The problem is that portage will still checkout the tree if
> it fails verification.  The patch is to do the verification before
> checking it out so that if it fails the tree is left in a
> last-known-good state (at least as seen by tools at the filesystem
> level - the fetched bad commits would still be visible to git).
>
Slightly radical thought here, but hear me out ..

Could we use this same functionality to be able to validate the tree
integrity with respect to CI testing? I mean, if the tree is 'broken'
could we have some kind of warning displayed perhaps? Something that
could be toggled (or default Off) would indeed be good, so that
users/devs can choose what level or 'standard' of tree state they're
prepared to accept.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Portage rsync hardlink support

[M. J. Everitt]

On 08/07/18 10:21, Zac Medico wrote:
> On 07/08/2018 02:15 AM, Michał Górny wrote:
>> 
>> Are you sure about that? That might have been the case so far but this 
>> hardlink tree may actually tip the balance.
> Even if it takes twice a long (which it doesn't), the difference is
> negligible for most people because they usually don't sync more than
> once per day.
It is recommended not to hammer the rsync mirrors with updates, and so
this argument holds true for "most users".



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: killing mediawiki

[M. J. Everitt]

On 03/07/18 21:01, William Hubbs wrote:
> On Tue, Jul 03, 2018 at 09:20:53PM +0200, Jonas Stein wrote:
>>> I don't care that we have a wiki, but can we please look into killing
>>> mediawiki and look at something with a git backend? 
>> I think the wiki is very useful and should remain.
> Like I said, there are wiki packages out there like gollum, ikiwiki, and
> probably others which would allow editing of content via text files and
> use vcs's for version control of the changes, so I'm not advocating for
> shutting down the wiki. I think we should have one that is more
> accessible to users who want to use different interfaces. We shouldn't
> be forcing users to use a full web browser just to contribute to the
> wiki.
>
>>> It would be very nice to be able to edit wiki pages in markdown or another 
>>> similar format
>>> and use git to control the changes instead of editing in a browser.
>> I think it is more efficient to convert your yearly contributions to the
>> wiki [1] manually from markdown to mediawiki, instead to convert the
>> existent wiki pages to anything plus setup a new engine and configure
>> user accounts.
> If that is converted from markdown, all you would have to do is use the
> markdown directly if the new wiki supports it.
>
>> Btw: Would a conversion to another wiki mean that we get another long
>> footer on every wikipage "This page was edited by... do not remove..."?
> I have no idea about that, but that alone shouldn't stop this from
> happening.
>
>> For the special case of the Gentoo Manual:
>> I think the Gentoo Manual is better maintained in a git repository,
>> because it was initially written like a book and sometimes it is better
>> to make PRs for the manual.
> I don't really see the manual as a special case. We should use the same
> interface for everything.
>
> William
1) I think this idea was floated before, and failed before ..
2) Existing wiki team are badly understaffed, how would this improve
things? How would new maintainers be registered and managed?
3) Are you volunteering to implement this change yourself (infra are
equally understaffed) and manage the change and transition, in addition
to your existing commitments?



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Hostile takeover of our github mirror. Don't use ebuild from there until new warning!

[M. J. Everitt]

On 28/06/18 22:54, Francisco Blas Izquierdo Riera (klondike) wrote:
> El 28/06/18 a las 23:15, Francisco Blas Izquierdo Riera (klondike) escribió:
>> Hi!
>>
>> I just want to notify that an attacker has taken control of the Gentoo
>> organization in Github and has among other things replaced the portage
>> and musl-dev trees with malicious versions of the ebuilds intended to
>> try removing all of your files.
>>
>> Whilst the malicious code shouldn't work as is and GitHub has now
>> removed the organization, please don't use any ebuild from the GitHub
>> mirror ontained before 28/06/2018, 18:00 GMT  until new warning.
>>
>> Sincerely,
>> Francisco Blas Izquierdo Riera (klondike)
>> Gentoo developer.
>>
>>
> Just to keep up with it. There is a more complete article published at
> https://www.gentoo.org/news/2018/06/28/Github-gentoo-org-hacked.html
>
>
>
Antarus has also posted on g-announce ML fyi ;)



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/4] xdg-utils.eclass: make EAPI 7 ready

[M. J. Everitt]

On 21/06/18 03:38, Jason Zaman wrote:
> On Wed, Jun 20, 2018 at 06:01:10PM -0500, Marty E. Plummer wrote:
>> On Wed, Jun 20, 2018 at 11:33:53PM +0100, James Le Cuirot wrote:
>>> On Wed, 20 Jun 2018 17:21:09 -0500
>>> "Marty E. Plummer"  wrote:
>>>
 On Wed, Jun 20, 2018 at 09:03:44PM +0800, Jason Zaman wrote:
> On Wed, Jun 20, 2018 at 02:10:50AM -0500, Marty E. Plummer wrote:  
>> Use ${EROOT%/} whereever possible, as the tools and directories which
>> are used with it are already prefixed with a /
>>
>> Package-Manager: Portage-2.3.40, Repoman-2.3.9
>> ---
>>  eclass/xdg-utils.eclass | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/eclass/xdg-utils.eclass b/eclass/xdg-utils.eclass
>> index ac075185d8e..8dba5ed6861 100644
>> --- a/eclass/xdg-utils.eclass
>> +++ b/eclass/xdg-utils.eclass
>> @@ -66,7 +66,7 @@ xdg_environment_reset() {
>>  # Updates the .desktop files database.
>>  # Generates a list of mimetypes linked to applications that can handle 
>> them
>>  xdg_desktop_database_update() {
>> -local updater="${EROOT}${DESKTOP_DATABASE_UPDATE_BIN}"
>> +local updater="${EROOT%/}${DESKTOP_DATABASE_UPDATE_BIN}"  
> Shouldn't things like this be $BROOT since they're being run? $EROOT
> might be a different architecture that may or may not run at all on the
> build machine.
>   
 Good point, but here's a question; if EROOT=${ROOT%/}${EPREFIX}, how do
 we use BROOT here? EBROOT? Or longhand ${BROOT%/}${EPREFIX} ? I think
 that may be a use case that got missed in the EAPI 7 discussions.
>>> BROOT is already prefixed as BROOT without a prefix would just be /.
>>>
>> I don't follow. Its my understanding that BROOT ~= ROOT for most
>> situations. But consider this setup:
>> Ubuntu amd64 with Gentoo Prefix, emerging a native arm @system to
>> /mnt/arm EPREFIX = /home/user/gentoo.
>>
>> In this situation, ROOT=/mnt/arm, EROOT=/mnt/arm, but what is BROOT? /,
>> or /home/usr/gentoo?
> https://dev.gentoo.org/~mgorny/articles/the-ultimate-guide-to-eapi-7.html#broot-variable-for-bdepend
>
> Basically BROOT already contains EPREFIX or BPREFIX or whatever it would
> be called. There is like no need for an un-prefixed BROOT so its just
> merged in. so you should just need "${BROOT}/usr/bin/update-mime-database"
>
> -- Jason
>
>>> -- 
>>> James Le Cuirot (chewi)
>>> Gentoo Linux Developer
>>
>>
Obligatory n00b question .. how does this work in EAPI <= 6 ?! :D



signature.asc
Description: OpenPGP digital signature

Re: Implicit use of versionator.eclass in ebuilds and eclasses (was: Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/)

[M. J. Everitt]

On 19/05/18 01:01, Andreas Sturmlechner wrote:
> On Freitag, 18. Mai 2018 23:53:06 CEST Michał Górny wrote:
>> One of the reasons we do mailing list reviews of widely used eclasses is
>> to let people tell you that you've left 'version_is_at_least' here.
> I see the error of my ways.
>
> Meanwhile, here's a list of packages implicitly using versionator.eclass 
> functions:
>
> eclasses:
>
> haskell-cabal.eclass
> mozextension.eclass
>
> ebuilds:
>
> app-admin/rsyslog/rsyslog-8.28.0-r1.ebuild
> app-admin/rsyslog/rsyslog-8.32.0-r4.ebuild
> app-admin/rsyslog/rsyslog-8.33.1-r1.ebuild
> app-admin/rsyslog/rsyslog-8.34.0.ebuild
> app-admin/rsyslog/rsyslog-8.35.0.ebuild
> app-emulation/qemu/qemu-2.11.1-r2.ebuild
> app-emulation/qemu/qemu-2.11.1-r53.ebuild
> app-emulation/qemu/qemu-2.12.0.ebuild
> app-emulation/qemu/qemu-.ebuild
> dev-java/htmlparser-org/htmlparser-org-1.6.ebuild
> dev-java/vecmath/vecmath-1.6.0_pre12.ebuild
> dev-ruby/rspec-core/rspec-core-3.5.4.ebuild
> dev-ruby/rspec-core/rspec-core-3.6.0.ebuild
> dev-ruby/rspec-core/rspec-core-3.7.0.ebuild
> dev-ruby/rspec-core/rspec-core-3.7.1.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.5.0.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.6.0.ebuild
> dev-ruby/rspec-expectations/rspec-expectations-3.7.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.5.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.6.0.ebuild
> dev-ruby/rspec-mocks/rspec-mocks-3.7.0.ebuild
> dev-vcs/bzr/bzr-2.7.1_pre.ebuild
> net-fs/samba/samba-4.2.14.ebuild
> net-fs/samba/samba-4.5.16.ebuild
> net-fs/samba/samba-4.6.15.ebuild
> net-fs/samba/samba-4.7.7.ebuild
> net-fs/samba/samba-4.8.1.ebuild
> net-fs/samba/samba-4.8.2.ebuild
> net-misc/openvswitch/openvswitch-2.7.2.ebuild
> net-misc/openvswitch/openvswitch-2.7.2-r1.ebuild
> net-misc/openvswitch/openvswitch-2.8.1.ebuild
> sys-apps/lm_sensors/lm_sensors-3.4.0_p20170901.ebuild
> sys-apps/lm_sensors/lm_sensors-3.4.0_p20180318.ebuild
> sys-kernel/mips-sources/mips-sources-4.13.16.ebuild
> sys-kernel/mips-sources/mips-sources-4.4.110.ebuild
> sys-kernel/mips-sources/mips-sources-4.9.75.ebuild
>
>
>
>
Can that be parsed into a list of (unique) maintainers to ping maybe?

Someone might have to pick up any maintainer-needed ones I s'pose.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[M. J. Everitt]

On 09/05/18 20:31, William Hubbs wrote:
> On Wed, May 09, 2018 at 07:54:16PM +0100, M. J. Everitt wrote:
>> ^ That is relatively common knowledge .. my question was more steered
>> towards whether Eudev is carrying this feature through as well (which
>> likely as they might ... ) I believe eudev was voted to become the
>> default implementation for Gentoo, to complement openRC as it was
>> becoming impossible to maintain udev-standalone separate from systemd.
> Well, it is not impossible to maintain udev standalone, we are still
> doing it just fine, so if that is the reason eudev was made the default,
> we need to revisit that. Not in this thread, however.
>
> William
Probably over-simplified there a little.

Still, I think we've run round one loop, and still not learnt much new...
*fakes surprise*



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[M. J. Everitt]

On 09/05/18 19:50, Kent Fredric wrote:
> On Wed, 9 May 2018 18:12:32 +0100
> "M. J. Everitt" <m.j.ever...@iee.org> wrote:
>
>>> On Wed, May 9, 2018 at 12:34 PM, Matt Turner <matts...@gentoo.org> wrote:  
>>> It's worth noting that the default rules shipped with udev assign mode
>>> 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox
>>> environment, any user may access these devices.
>>>
>>> This was merged as part of this PR: 
>>> https://github.com/systemd/systemd/pull/7112
>>>  
>> How does that pan out for other init systems?
> udev
>
> Which practically everyone uses regardless of init system. Even openrc users.
>
> Upstream, udev is part of systemd now.
^ That is relatively common knowledge .. my question was more steered
towards whether Eudev is carrying this feature through as well (which
likely as they might ... ) I believe eudev was voted to become the
default implementation for Gentoo, to complement openRC as it was
becoming impossible to maintain udev-standalone separate from systemd.

Do correct me if I'm mistaken ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?

[M. J. Everitt]

On 09/05/18 18:10, Mike Gilbert wrote:
> On Wed, May 9, 2018 at 12:34 PM, Matt Turner  wrote:
>> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde  wrote:
>>> Hello!
>>>
>>> I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/
>>> renderD128" pop up for more and more packages, probably since OpenCL becomes
>>> used more widely.  Hence I would like to ask: Could we in Gentoo treat GPUs
>>> just like CPUs and allow any process to access render nodes (i.e. the GPUs
>>> compute capabilities via the specific interface the Linux kernel's DRM 
>>> offers
>>> for that purpose) without sandbox restrictions?
>>>
>>> --Dennis
>>>
>>> See-Also: https://bugs.gentoo.org/654216
>> This seems like a bad idea. With CPUs we've had decades to work out
>> how to isolate processes and prevent them from taking down the system.
>>
>> GPUs are not there yet. It's simple to trigger an unrecoverable GPU
>> hang and not much harder to turn it into a full system lock up.
>>
>> This is not safe.
>>
> It's worth noting that the default rules shipped with udev assign mode
> 0666 to the /dev/dri/renderD* device nodes. So, outside of a sanbox
> environment, any user may access these devices.
>
> This was merged as part of this PR: 
> https://github.com/systemd/systemd/pull/7112
>
How does that pan out for other init systems?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] depgraph.autounmask_breakage_detected: ignore REQUIRED_USE violations (bug 654782)

[M. J. Everitt]

On 04/05/18 06:22, Zac Medico wrote:
> When autounmask USE changes violate REQUIRED_USE, rather than
> recalculate with autounmask disabled, display the autounmask USE
> changes along with the REQUIRED_USE violation. Adjust unit tests
> to allow for the autounmask USE changes that were previously
> discarded. For the case reported in bug 654782, the output will
> appear as follows:
>
> The following keyword changes are necessary to proceed:
>  (see "package.accept_keywords" in the portage(5) man page for more details)
> # required by =retext-7.0.1-r1 (argument)
> =app-editors/retext-7.0.1-r1 ~amd64
>
> The following USE changes are necessary to proceed:
>  (see "package.use" in the portage(5) man page for more details)
> # required by app-editors/retext-7.0.1-r1::gentoo
> # required by =retext-7.0.1-r1 (argument)
>> =dev-python/PyQt5-5.9.2 printsupport webengine network gui widgets
> !!! The ebuild selected to satisfy 
> "dev-python/PyQt5[gui,network,printsupport,webengine,widgets,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]"
>  has unmet requirements.
> - dev-python/PyQt5-5.9.2::gentoo USE="-bluetooth -dbus -debug -declarative 
> -designer -examples -gles2 -gui -help -location -multimedia -network -opengl 
> -positioning -printsupport -sensors -serialport -sql -svg -testlib 
> -webchannel -webengine -webkit -websockets -widgets -x11extras -xmlpatterns" 
> PYTHON_TARGETS="python2_7 python3_4 python3_6 -python3_5"
>
>   The following REQUIRED_USE flag constraints are unsatisfied:
> webengine? ( widgets? ( webchannel ) )
>
>   The above constraints are a subset of the following complete expression:
> any-of ( python_targets_python2_7 python_targets_python3_4 
> python_targets_python3_5 python_targets_python3_6 ) bluetooth? ( gui ) 
> declarative? ( gui network ) designer? ( widgets ) help? ( gui widgets ) 
> location? ( positioning ) multimedia? ( gui network ) opengl? ( gui widgets ) 
> positioning? ( gui ) printsupport? ( gui widgets ) sensors? ( gui ) 
> serialport? ( gui ) sql? ( widgets ) svg? ( gui widgets ) testlib? ( widgets 
> ) webchannel? ( network ) webengine? ( network widgets? ( printsupport 
> webchannel ) ) webkit? ( gui network printsupport widgets ) websockets? ( 
> network ) widgets? ( gui ) xmlpatterns? ( network )
>
> (dependency required by "app-editors/retext-7.0.1-r1::gentoo" [ebuild])
> (dependency required by "=retext-7.0.1-r1" [argument])
>
> Bug: https://bugs.gentoo.org/654782
> ---
>  pym/_emerge/depgraph.py|  8 ++--
>  pym/portage/tests/resolver/test_autounmask.py  | 48 
> --
>  pym/portage/tests/resolver/test_slot_collisions.py | 20 +
>  3 files changed, 61 insertions(+), 15 deletions(-)
>
> diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> index fbd16ad98..429d8871c 100644
> --- a/pym/_emerge/depgraph.py
> +++ b/pym/_emerge/depgraph.py
> @@ -3009,6 +3009,10 @@ class depgraph(object):
>   {"myparent" : dep.parent, 
> "show_req_use" : pkg}))
>   self._dynamic_config._required_use_unsatisfied 
> = True
>   self._dynamic_config._skip_restart = True
> + # Add pkg to digraph in order to enable 
> autounmask messages
> + # for this package, which is useful when 
> autounmask USE
> + # changes have violated REQUIRED_USE.
> + self._dynamic_config.digraph.add(pkg, 
> dep.parent, priority=priority)
>   return 0
>  
>   if not pkg.onlydeps:
> @@ -9428,10 +9432,6 @@ class depgraph(object):
>   return self._dynamic_config._need_config_reload
>  
>   def autounmask_breakage_detected(self):
> - # Check for REQUIRED_USE violations.
> - for changes in 
> self._dynamic_config._needed_use_config_changes.values():
> - if getattr(changes, 'required_use_satisfied', None) is 
> False:
> - return True
>   try:
>   for pargs, kwargs in 
> self._dynamic_config._unsatisfied_deps_for_display:
>   self._show_unsatisfied_dep(
> diff --git a/pym/portage/tests/resolver/test_autounmask.py 
> b/pym/portage/tests/resolver/test_autounmask.py
> index 9042349ea..809d42104 100644
> --- a/pym/portage/tests/resolver/test_autounmask.py
> +++ b/pym/portage/tests/resolver/test_autounmask.py
> @@ -251,15 +251,42 @@ class AutounmaskTestCase(TestCase):
>   use_changes={ "dev-util/R-1": { "bar": 
> True } }),
>  
>   #Test interaction with REQUIRED_USE.
> + # Some of these cases trigger USE change(s) 
> that violate
> +

Re: [gentoo-dev] Re: Mailing list moderation and community openness

[M. J. Everitt]

On 27/03/18 17:39, Rich Freeman wrote:
> On Tue, Mar 27, 2018 at 12:12 PM, Martin Vaeth  wrote:
>> Rich Freeman  wrote:
>>> On Tue, Mar 27, 2018 at 3:34 AM, Martin Vaeth  wrote:
 It is about openness vs. isolation.
>>> I'm pretty sure most developers, myself included, want to welcome
>>> contributions.
>> Closing of the mailing list does not sound like that.
>>
> Sure, but it is actually part of the motivation.
>
> Consider this scenario.
>
> Fred is a community member.  Fred consistently harasses and trolls new
> contributors in private.  New contributors end up leaving because of
> Fred.
>
> Fred gets booted out as a result.  No mention is made of why Fred as
> booted out, because everything happened in private.
>
> Now a bunch of community members get upset about Fred being booted out
> without reason.  Fred claims it is because he disagrees with the
> leadership on something.  People start arguing endlessly about
> openness.
>
> Ultimately the leaders just want Fred gone so that new contributors
> aren't getting driven away.  They can't explain that because then they
> create potential civil liability for the project.  The problem is that
> the debate goes on for over a year despite intervening elections and
> now this becomes the issue that is driving new contributors away.
>
> What solution would you propose for this problem?  It isn't
> hypothetical at all - I can think of one case in Gentoo's past where
> this happened that I'm aware of, and I'd be shocked if it were the
> only one.
>
>> And anyway, you can be sure that the problem will appear again,
>> no matter how closed the list will be.
> Sure, but we can at least force the negative advertising of Gentoo to
> go elsewhere, rather than basically paying to run a negative PR
> campaign against ourselves.
>
>>> A lot of this comes down to considering that most people in these
>>> debates probably are well-intended.
>> Taking away freedom is never justified by good intention.
> You might want to choose a BSD-based distro then.  :)
>
> And what about the freedom to endlessly troll and harass you and
> others?  Is this truly a freedom we want to stand for?  How about the
> freedom to harass members of legally-protected classes (something that
> also has happened historically in the community)?
>
> Surely Gentoo's mission isn't to run completely unrestricated forums
> for discussion of anything and everything.  Our main purpose here is
> to maintain a Linux distro, not provide a platform for anybody who has
> an opinion on anything.  Free expression has to be balanced against
> the interests of people who want to actually contribute to the distro
> without being endlessly trolled and harassed.
>
It sounds a lot to me like you're replacing one set of problems with
another .. solving not a lot. Whether you take action on "Fred" or not,
you're going to lose out, so what do you do... Where is the greater
damage, with one/two people, 10/20 people or 100/200 people .. its a
huge value judgement - certainly not one I'd like to make!

You may or may not have heard the expression "throwing out the baby with
the bathwater" .. alas I feel this measure is a good example of this. To
try to rid the mailing list of one or two bad apples, you've cut the
whole tree down so it can't bear fruit. I think this is a foolish step,
but only time will tell that for sure ... The next "logical" step would
simply be to delete the whole mailing list - I suppose that's the next
"measure" when the trolling from white-listed members resurfaces And
don't go telling me it doesn't exist .. set a bad example, others will
surely follow ...

Ooops, another $2 spent on a lost cause .. >,<



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Mailing list moderation and community openness

[M. J. Everitt]

On 22/03/18 00:33, Kristian Fiskerstrand wrote:
> 
> Most contributions should happen via patches on b.g.o
>
Who was lamenting about the every-increasing bug queue on this Very list
recently?

And what about those 5+ year old bugs that are rotting for packages long
last-rited from the tree ?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

[M. J. Everitt]

On 21/03/18 23:26, M. J. Everitt wrote:
> n 20/03/18 04:49, Manuel Rüger wrote:
>> Hi Zac,
>>
>> alternatively could --exclude be extended to support sets?
>> So users could --exclude @world or @profile.
>>
>> Cheers,
>> Manuel
>>
> The idea is sound enough, but I fear the syntax would be too confusing.
>
> Reading a potential command-line as "emerge   world-file unless --no-replace specified>  puts my head into
> a spin! I can see it might be clearer for an unmerge perhaps ..
>
> Unless I'm missing something fundamental ...
>
On a related note, it would be quite handy to enumerate an
"exclude-from" option like rsync/tar(?) to specify a file with the
--exclude options in. There could be some way to append @world to this
option, perhaps?

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --ignore-world [ y | n ] option (bug 608564)

[M. J. Everitt]

n 20/03/18 04:49, Manuel Rüger wrote:
> Hi Zac,
>
> alternatively could --exclude be extended to support sets?
> So users could --exclude @world or @profile.
>
> Cheers,
> Manuel
>
The idea is sound enough, but I fear the syntax would be too confusing.

Reading a potential command-line as "emergeputs my head into
a spin! I can see it might be clearer for an unmerge perhaps ..

Unless I'm missing something fundamental ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

[M. J. Everitt]

On 21/03/18 01:27, Kent Fredric wrote:
> On Tue, 20 Mar 2018 14:48:29 -0400
> Michael Orlitzky  wrote:
>
>> There's a real technical problem hidden in there. Since npm
>> (recursively!) bundles every dependency, nobody worries about
>> compatibility in their JS packages. You'll quickly find yourself stuck.
> Honestly, I expected at some point we'd reach for slotting and normalization,
> and recursive trees of symlinks
>
> eg: 
>   /usr/lib/nodejs///lib/  -> 
> /usr/lib/nodejs//
>
> Or something like that.
>
> So you'd wind up with
>
>   /usr/lib/nodejs/foo/1.0/lib/bar  -> /usr/lib/nodejs/bar/1.0
>   /usr/lib/nodejs/foo/1.0/lib/baz  -> /usr/lib/nodejs/baz/2.0
> /usr/lib/nodejs/bar/1.0/lib/baz  -> /usr/lib/nodejs/baz/1.0
> /usr/lib/nodejs/baz/1.0/...
> /usr/lib/nodejs/baz/2.0/...
>
> Or something like that. But I imagine constructing such a thing a
> rather painful exercise.
>
 Said the voice of bitter experience ... *eg* :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] things becoming better and better

[M. J. Everitt]

On 19/03/18 18:48, Toralf Förster wrote:
> honestly.
>
>
> When I started with my tinderbox 2 or 3 years ago I had often a fair
> amount of manual work to made to get an image up and running - moslty
> tweaking USE flags to get blockers being solved. This yielded into a
> growing list of fixed USE flags settings for certain packages.
>
> But over the time this list became small and smaller and eventually this
> month I kicked off the last few lines (famous last words?).
>
> Said that Gentoo has IMO a lot of success stories to tell too (beside
> the usual grumblings and annoyances) - and the quality of the Gentoo
> tree is IMO an example of that.
>
>
> /me was just in the mood for a statement like this
>
I think I speak for many readers of this list, in echo'ing a big
thank-you for your efforts on the Tinderbox project. Gentoo has been
slow to move to more automated testing methods, and this is a huge leap
forward in this regard. Hopefully, moving forward there will be less
human effort required to extend and maintain the tree of packages on
which we depend, and together with QA, huge strides forward are being
made to achieve this end.

It is quite useful to have a consistent means to test packages, and to
this end, hopefully we can eliminate some of the randomness that having
a very flexible build system creates!

Onwards and upwards ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

[M. J. Everitt]

On 12/03/18 04:53, Duncan wrote:
> Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted:
>
>> I really don't want to spend a lot of time making revisions, and I think
>> "unstable" communicates well enough in this case.
> Very well then.  With robbat2's already accepted first paragraph changes 
> it's acceptable as-is.
>
> Thanks.  You put an awful lot of work into portage, and I'm sure I'm not 
> the only one who's thankful there's a steady hand at the portage wheel, 
> even if it doesn't always come thru.  Your efforts certainly make the 
> gentoo experience a better one! =:^)
>
+1 to that .. particularly through choppy waters lately .. keep up the
good work!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

[M. J. Everitt]

On 10/03/18 21:22, Zac Medico wrote:
> Please review. This is needed in order to resolve
> https://bugs.gentoo.org/650072.

> 2) Once the 'rsync-verify' USE flag has been unmasked as described
> in step 1, it can be enabled with a line like the folling in
> /etc/portage/package.use:
s/folling/following/

:)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge --search: use slash to auto-detect category (bug 647940)

[M. J. Everitt]

On 18/02/18 21:27, Zac Medico wrote:
> Since search strings containing a slash do no work unless category
> match mode is enabled, use slash to auto-detect category match mode,
> so that users do not have to prefix the search string with the special
> @ symbol.
>
> Bug: https://bugs.gentoo.org/647940
> ---
>  pym/_emerge/search.py | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/pym/_emerge/search.py b/pym/_emerge/search.py
> index 36897fb15..eb52b2ca3 100644
> --- a/pym/_emerge/search.py
> +++ b/pym/_emerge/search.py
> @@ -256,6 +256,10 @@ class search(object):
>   if self.searchkey.startswith('@'):
>   match_category = 1
>   self.searchkey = self.searchkey[1:]
> + # Auto-detect category match mode (@ symbol can be deprecated
> + # after this is available in a stable version of portage).
> + if '/' in self.searchkey:
> + match_category = 1
>   fuzzy = False
>   if regexsearch:
>   self.searchre=re.compile(self.searchkey,re.I)
+1 long overdue! :D



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2 1/3] repoman: Add commit message verification

[M. J. Everitt]

On 18/02/18 16:28, Brian Dolbec wrote:
> On Sat, 17 Feb 2018 13:18:03 +
> "M. J. Everitt" <m.j.ever...@iee.org> wrote:
>
>> Might I suggest breaking out checks into a separate module? I think
>> that hard-coding it all is likely to become a pain as time goes on,
>> more checks get added, etc  ...
>>
> So, you would like the commit message checks to be  a plug-in system
> like the ebuild checks are now.
>
> Yes that is possible,  that would also allow overlays and sub-distros
> to customize it to their liking.  But you do realize it would be a
> module system with only the one plug-in.  It would add a slight amount
> of overhead and subsequently a tiny bit more time.  Although it is not
> much as I remember when I first developed the plug-in system for emaint.
>
> I will consider that for the stage3 work in progress, but for the
> master branch of repoman, the hard-coded version above would be fine.
>
That's probably a better implementation, but for the time being I was
thinking more of an 'actions_commit' module to break out the extra code
from the generic 'actions' module.
Regards,
Michael/veremitz.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2 1/3] repoman: Add commit message verification

[M. J. Everitt]

On 17/02/18 12:56, Michał Górny wrote:
> Add a check for common mistakes in commit messages. For now, it is
> pretty rough and works only for -m/-F. It will be extended to work
> in the interactive mode in the future.
> ---
>  repoman/pym/repoman/actions.py  | 74 
> -
>  repoman/pym/repoman/tests/commit/__init__.py|  2 +
>  repoman/pym/repoman/tests/commit/__test__.py|  1 +
>  repoman/pym/repoman/tests/simple/test_simple.py |  8 +--
>  4 files changed, 80 insertions(+), 5 deletions(-)
>  create mode 100644 repoman/pym/repoman/tests/commit/__init__.py
>  create mode 100644 repoman/pym/repoman/tests/commit/__test__.py
>
> diff --git a/repoman/pym/repoman/actions.py b/repoman/pym/repoman/actions.py
> index b76a6e466..91603865c 100644
> --- a/repoman/pym/repoman/actions.py
> +++ b/repoman/pym/repoman/actions.py
> @@ -119,7 +119,16 @@ class Actions(object):
>   if commitmessage[:9].lower() in ("cat/pkg: ",):
>   commitmessage = self.msg_prefix() + 
> commitmessage[9:]
>  
> - if not commitmessage or not commitmessage.strip():
> + if commitmessage is not None and commitmessage.strip():
> + res, expl = self.verify_commit_message(commitmessage)
> + if not res:
> + print(bad("RepoMan does not like your commit 
> message:"))
> + print(expl)
> + if self.options.force:
> + print('(but proceeding due to --force)')
> + else:
> + sys.exit(1)
> + else:
>   commitmessage = self.get_new_commit_message(qa_output)
>  
>   commitmessage = commitmessage.rstrip()
> @@ -585,3 +594,66 @@ class Actions(object):
>   print("* no commit message?  aborting commit.")
>   sys.exit(1)
>   return commitmessage
> +
> + footer_re = re.compile(r'^[\w-]+:')
> +
> + @classmethod
> + def verify_commit_message(cls, msg):
> + """
> + Check whether the message roughly complies with GLEP66. Returns
> + (True, None) if it does, (False, ) if it does not.
> + """
> +
> + problems = []
> + paras = msg.strip().split('\n\n')
> + summary = paras.pop(0)
> +
> + if ':' not in summary:
> + problems.append('summary line must start with a logical 
> unit name, e.g. "cat/pkg:"')
> + if '\n' in summary.strip():
> + problems.append('commit message must start with a 
> *single* line of summary, followed by empty line')
> + # accept 69 overall or unit+50, in case of very long package 
> names
> + elif len(summary.strip()) > 69 and len(summary.split(':', 
> 1)[-1]) > 50:
> + problems.append('summary line is too long (max 69 
> characters)')
> +
> + multiple_footers = False
> + gentoo_bug_used = False
> + bug_closes_without_url = False
> + body_too_long = False
> +
> + found_footer = False
> + for p in paras:
> + lines = p.splitlines()
> + # if all lines look like footer material, we assume 
> it's footer
> + # else, we assume it's body text
> + if all(cls.footer_re.match(l) for l in lines if 
> l.strip()):
> + # multiple footer-like blocks?
> + if found_footer:
> + multiple_footers = True
> + found_footer = True
> + for l in lines:
> + if l.startswith('Gentoo-Bug'):
> + gentoo_bug_used = True
> + elif l.startswith('Bug:') or 
> l.startswith('Closes:'):
> + if 'http://' not in l and 
> 'https://' not in l:
> + bug_closes_without_url 
> = True
> + else:
> + for l in lines:
> + # we recommend wrapping at 72 but 
> accept up to 80;
> + # do not complain if we have single 
> word (usually
> + # it means very long URL)
> + if len(l.strip()) > 80 and 
> len(l.split()) > 1:
> + body_too_long = True
> +
> + if multiple_footers:
> + problems.append('multiple footer-style blocks found, 
> please combine them into one')
> + if gentoo_bug_used:
> + 

Re: [gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[M. J. Everitt]

On 13/02/18 20:57, Rich Freeman wrote:
> On Tue, Feb 13, 2018 at 3:53 PM, Chí-Thanh Christopher Nguyễn
>  wrote:
>> Dean Stephens schrieb:
>>
 Suppose that the council decides to accept an appeal from comrel. Is it
 a conflict of interest for a member of the council who is also a member
 of comrel to vote in the appeal? If it isn't, it is at least a pretty
 strong perception that it is.

>>> Why? How? Exactly what sort of conflicting interest is supposed to be
>>> present?
>> I think in Comrel vs. Council is not a conflict of interest, but rather
>> throwing the appeals process off balance. Can you expect someone to neutrally
>> review material and actions (question the authenticity of evidence, identify
>> potential misconduct, etc.) that they themselves used to build the case
>> against the reprimanded?
>>
> I hope that Comrel does not consider it their main duty to build cases
> against community members.  They're supposed to investigate, mediate,
> and take action if necessary.  They aren't prosecutors.
>
Do you have evidence either to support or contradict your case? TIA...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Lastrite: app-crypt/monkeysign

[M. J. Everitt]

On 13/02/18 10:47, Michael Palimaka wrote:
> On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote:
>> # Kristian Fiskerstrand  (11 Feb 2018)
>> # Lastrite: app-crypt/monkeysign . Please use caff from
>> # app-crypt/signing-party instead. Removal in 30 days.
>> # Bug: #647352
>> app-crypt/monkeysign
>>
> What's the reason for the removal?
>
Wait, there have to be reasons for removal now?! 

The only good last-rites messages I've ever seen from from jstein where
there is indeed a good traceable path as to why the dev feels that the
package is "beyond repair". Otherwise it does seem like a lot of cases
of "can't be bothered with this any more, lets kill it off". Correct me
if I'm wrong, by all means ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[M. J. Everitt]

On 08/02/18 22:33, William Hubbs wrote:
> All,
>
> here is a link to an old, but brief discussion about this.
>
> https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c
>
> I think we have talked about this several other times, but not done
> anything about it.
>
> On Thu, Feb 08, 2018 at 10:17:59PM +, M. J. Everitt wrote:
>>
>> On 08/02/18 22:13, William Hubbs wrote:
>>> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>>>> However, there are plenty of examples of commands that normal users
>>>> may run from sbin. Moving these commands often causes problems for
>>>> packages that either hard code absolute paths, or detect paths at
>>>> build time. I think it would be less disruptive to add sbin to PATH
>>>> than it would be to try and "fix" all the packages that install
>>>> commands in the wrong place.
>>> There are no reasons to remove the *sbin directories from PATH; I know
>>> of no other distros that do this.
>>>
>>> William
>>>
>> Pardon my ignorance, but does that mean you are essentially relying on
>> file system features/permissions and security settings to enforce
>> correct use of system tools?! Or is this just to make sudo/etc commands
>> 'more convenient' ?!
> The basic problem is that what goes in *bin vs *sbin is quite arbitrary
> and the best way to fix it is to make all of the *bin and *sbin
> directories accessible to all users.
>
> You can't rely on a path to separate system-only programs from
> programs that users might want to run, and some programs can be run by
> users to look around but not change things.
>
> Here is one non-gentoo source discussing this.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Even if we don't adopt the usr merge in Gentoo Linux as default, removing 
> *sbin
> from the path doesn't make sense.
>
> William
>
Thank you William, and also rich for your explanations! I do see where
you're coming from now.

Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

[M. J. Everitt]

On 08/02/18 22:13, William Hubbs wrote:
> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote:
>> However, there are plenty of examples of commands that normal users
>> may run from sbin. Moving these commands often causes problems for
>> packages that either hard code absolute paths, or detect paths at
>> build time. I think it would be less disruptive to add sbin to PATH
>> than it would be to try and "fix" all the packages that install
>> commands in the wrong place.
> There are no reasons to remove the *sbin directories from PATH; I know
> of no other distros that do this.
>
> William
>
Pardon my ignorance, but does that mean you are essentially relying on
file system features/permissions and security settings to enforce
correct use of system tools?! Or is this just to make sudo/etc commands
'more convenient' ?!

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] glep-0074: Remove single filesystem limitation

[M. J. Everitt]

On 08/02/18 17:09, Michał Górny wrote:
> Remove the limitation that all files covered by the Manifest must reside
> on a single filesystem. This breaks valid uses of overlayfs without
> providing any real advantage.
>
> The removal is justified further in the updated rationale section.
> ---
>  glep-0074.rst | 66 
> +++
>  1 file changed, 39 insertions(+), 27 deletions(-)
>
> RST:  https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst
> HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html
>
> diff --git a/glep-0074.rst b/glep-0074.rst
> index 3835247..2f8deb2 100644
> --- a/glep-0074.rst
> +++ b/glep-0074.rst
> @@ -6,10 +6,10 @@ Author: Michał Górny ,
>  Ulrich Müller 
>  Type: Standards Track
>  Status: Final
> -Version: 1
> +Version: 1.1
>  Created: 2017-10-21
> -Last-Modified: 2017-12-16
> -Post-History: 2017-10-26, 2017-11-16
> +Last-Modified: 2018-02-08
> +Post-History: 2017-10-26, 2017-11-16, 2018-02-08
>  Content-Type: text/x-rst
>  Requires: 59, 61
>  Replaces: 44, 58, 60
> @@ -126,13 +126,6 @@ a different file type. If the tree contain files of 
> other types
>  that are not otherwise ignored, they need to be covered by an explicit
>  ``IGNORE``.
>  
> -All the local (non-``DIST``) files covered by a Manifest tree must
> -reside on the same filesystem. It is an error to specify entries
> -applying to files on another filesystem. If files or directories that
> -are not otherwise ignored reside on a different filesystem, or symbolic
> -links point to targets on a different filesystem, they must
> -be explicitly excluded via ``IGNORE``.
> -
>  
>  Path and filename encoding
>  --
> @@ -325,22 +318,18 @@ Algorithm for finding parent Manifests
>  In order to find the top-level Manifest from the current directory
>  the following algorithm can be used:
>  
> -1. Store the current directory as *original* and the device ID
> -   of the containing filesystem (``st_dev``) as *startdev*,
> -
> -2. If the device ID of the containing filesystem (``st_dev``)
> -   of the current directory is different than *startdev*, stop.
> +1. Store the current directory as *original*,
>  
> -3. If the current directory contains a ``Manifest`` file:
> +2. If the current directory contains a ``Manifest`` file:
>  
> a. If an ``IGNORE`` entry in the ``Manifest`` file covers
>the *original* directory (or one of the parent directories), stop.
>  
> b. Otherwise, store the current directory as *last_found*.
>  
> -4. If the current directory is the root system directory (``/``), stop.
> +3. If the current directory is the root system directory (``/``), stop.
>  
> -5. Otherwise, enter the parent directory and jump to step 2.
> +4. Otherwise, enter the parent directory and jump to step 2.
>  
>  Once the algorithm stops, *last_found* will contain the relevant
>  top-level Manifest. If *last_found* is null, then the directory tree
>


Observation: does RST not support auto-numbering like other formats? It
would make renumbering lists like this much easier (and from programming
experience, less error-prone). If not, #FEATUREREQ ... :]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH v2 6/9] rsync: Issue an explicit warning if Manifest timestamp is >24hr old

[M. J. Everitt]

On 02/02/18 20:42, Michał Górny wrote[excerpted]:
> index 27a2548c0..cb80f6d66 100644
> --- a/pym/portage/sync/modules/rsync/__init__.py
> +++ b/pym/portage/sync/modules/rsync/__init__.py
> @@ -109,6 +110,20 @@ class RsyncSync(NewBase):
>   writemsg_level("!!! sync-rsync-verify-jobs not 
> a positive integer: %s\n" % (self.verify_jobs,),
>   level=logging.WARNING, noiselevel=-1)
>   self.verify_jobs = None
> + # Support overriding max age.
> + self.max_age = self.repo.module_specific_options.get(
> + 'sync-rsync-verify-max-age', '')
> + if self.max_age:
> + try:
> + self.max_age = int(self.max_age)
> + if self.max_age < 0:
> + raise ValueError(self.max_age)
> + except ValueError:
> + writemsg_level("!!! sync-rsync-max-age not a 
> non-negative integer: %s\n" % (self.max_age,),
A beautiful double-negative .. but would read better as "not a positive
integer" or "is a negative integer" ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v3)

[M. J. Everitt]

On 27/01/18 14:26, Michał Górny wrote [excerpted]:
> The verification is implemented via using app-portage/gemato. Currently,
> the whole repository is verified after syncing.
>
I would drop either 'via' or 'using' - they both are the same
verb/meaning and one is hence redundant.
Just my 2c as a native English speaker :)

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [News item review] Portage rsync tree verification

[M. J. Everitt]

On 25/01/18 11:01, Kristian Fiskerstrand wrote:
> On 01/25/2018 11:04 AM, Michał Górny wrote:
>
>> The verification is implemented using app-portage/gemato. Currently, 
> ... "implemented in", as opposed to "using"? its implemented using
> various cryptographic primitives, but gemato is the implementation
> itself of sorts.
>
>

"implemented with gemato" ?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change

[M. J. Everitt]

On 16/01/18 21:56, Róbert Čerňanský wrote:
> On Tue, 16 Jan 2018 15:58:11 +0100
> Kristian Fiskerstrand  wrote:
>
>> On 01/16/2018 03:45 PM, Aaron W. Swenson wrote:
>>> Given the situation, we have a choice: Remove GnuCash altogether, or
>>> press ahead with recommending a version upstream considers
>>> unstable.  
>> Or 3, discuss with upstream to see if they can release an updated
>> version as stable branch.
> 4. Mask the vulnerable webkit-gtk.  This way: A. User is informed.
> B. Manual action is required to continue using such package.
>
> I see this as the most obvious choice considering that I am still
> unable to find any possible attack vector against GnuCash.  If it is me
> and only me who enters data.  Webkit reports are generated from those
> data.  How can anyone hack me through GnuCash?
>
> In general, many times users use applications in a way that
> vulnerabilities does not apply to their use cases.  I would prefer to
> be informed and allowed to continue using such application as a part of
> the distro.
>
> Robert
>
>
Forgive my potential misunderstanding here .. but who's actively
preventing you from using GnuCash 2.6? You can take a copy locally to
/usr/local/portage so that When/If finally it gets removed from the
central package 'tree' it will run for you provided its requirements are
still met on your system ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[M. J. Everitt]

On 11/01/18 03:18, Benda Xu wrote:
> Hi MJ,
>
> "M. J. Everitt" <m.j.ever...@iee.org> writes:
>
>> Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
>> different between 2.6.16+ and 2.6.32+ .. should this potentially be
>> 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
>> and more confusing to others
> 2.6.16+ means that it can be used in any cases when the kernel is newer
> than 2.6.16.  For example, you can use it on linux-4.14, just with
> unnecessary backward compatibility code.
>
> Besides, with the newest profile, kernel-3.2+, the ending kernel version
> is not known.  We will have to rename it when glibc jumps if the profile
> is named with a version range.
>
>
> Hope this addresses your concern.
>
> Cheers,
> Benda
Thanks, that does make sense!

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 23:35, Rich Freeman wrote:
> On Wed, Jan 10, 2018 at 6:27 PM, M. J. Everitt <m.j.ever...@iee.org> wrote:
>
>> I think Roy's point is quite valid .. if you want to cut out users from
>> contribution why are you even posting on -dev ML in the first place?
> Probably because we don't want to cut out users from contribution.
>
I think the proverb "don't throw the baby out with the bathwater"
probably applies here ...

[With apologies for all the proverbs and metaphors lately!]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 23:20, Rich Freeman wrote:
> On Wed, Jan 10, 2018 at 5:28 PM, Roy Bamford  wrote:
>> Being somwhat old and cynical, I'm seeing signs of history
>> repeating itself.
>>
>> Does being 'struck off' the list in this way apply to devs, including
>> Council and comrel members?
>>
> It would seem that this question is already answered:
> https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct#Consequences
>
> Being banned from lists or removal of dev status (which would also
> remove posting privs unless whitelisted) are already listed as
> potential consequences for refusal to comply with the CoC.
>
I have to ask a stupid question here .. how do devs apply to return to
the list? Via other devs, council, Comrel, the Foundation, Infra, or
what? (the "select few"/clique/club/etc?)

I think Roy's point is quite valid .. if you want to cut out users from
contribution why are you even posting on -dev ML in the first place? Use
-core and/or #-dev IRC .. or is this simply an attempt to replicate
#-dev IRC as a ML .. and you simply move the "problem" elsewhere .. and
then apply sanctions to that system also .. you create a rod for your
own back ...

I'm tending towards the idea that this is a technical "solution" to a
non-technical problem, and as such, nobody is capable of "fixing" that ..



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 19:31, Alec Warner wrote:
> On Wed, Jan 10, 2018 at 2:06 PM, Michał Górny  > wrote:
>
> W dniu śro, 10.01.2018 o godzinie 09∶11 -0800, użytkownik Matt Turner
> napisał:
> > On Wed, Jan 10, 2018 at 1:55 AM, Michał Górny  > wrote:
> > > W dniu wto, 09.01.2018 o godzinie 17∶08 -0800, użytkownik Matt
> Turner
> > > napisał:
> > > > On Tue, Jan 9, 2018 at 1:20 PM, Andreas K. Huettel
> > wrote:
> > > > > During the last Gentoo council meeting, the decision was
> made to implement
> > > > > changes to the gentoo-dev mailing list [1].
> > > > >
> > > > > These changes affect only the gentoo-dev mailing list, and
> will come into
> > > > > effect on 23 January 2018.
> > > > >
> > > > > * Subscribing to the list and receiving list mail remains
> as it is now.
> > > > > * Posting to the list will only be possible to Gentoo
> developers and
> > > > >   whitelisted additional participants.
> > > > > * Whitelisting requires that one developer vouches for
> you. We intend this
> > > > >   to be as unbureaucratic as possible.
> > > > > * Obviously, repeated off-topic posting as well as
> behaviour against the
> > > > >   Code of Conduct [2] will lead to revocation of the
> posting permission.
> > > > >
> > > > > If, as a non-developer, you want to participate in a
> discussion on
> > > > > gentoo-dev,
> > > > > - either reply directly to the author of a list mail and
> ask him/her to
> > > > > forward your message,
> > > > > - or ask any Gentoo developer of your choice to get you
> whitelisted.
> > > > >
> > > > > If, as a developer, you want to have someone whitelisted,
> please comment on
> > > > > bug 644070 [3]. Similar to Bugzilla editbugs permission,
> if you are vouching
> > > > > for a contributor you are expected to keep an eye on their
> activity.
> > > >
> > > > It seems like the obvious way this fails is some Gentoo
> developer acks
> > > > one of the problem people. I don't think that's particularly
> unlikely.
> > > > Then what do we do?
> > > >
> > >
> > > Then it becomes comrel business.
> >
> > If that was an effective solution, wouldn't the problem already
> be solved?
>
> One of the problems mentioned before was that a person could easily
> evade the ban via subscribing from another e-mail address. In this
> case
> it's no longer possible, as he would need to obtain the vouching
> for his
> new e-mail address, and for that he would first have to have something
> positive to post.
>
> Of course this relies on developers not vouching for new people out of
> the blue but expecting them to have something to contribute first.
>
>
> This sounds like an amazing fundraising opportunity.
>
> https://www.gentoo.org/donate/
>
> Get membership posting privs.
>
> -A
>  
>
>
> --
> Best regards,
> Michał Górny
>
>
>
Do I read a hint of sarcasm there too Alec?! :]


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 14:55, Alexander Berntsen wrote:
> On 10/01/18 08:55, Lars Wendler wrote:
>> Seems we're turning into an elitist club or something... 
> Gentoo has already had the reputation of being an elitist club for
> years. As such I'd like to see steps to remedy this status, rather than
> taking steps like this, which just exacerbates the unfortunate status.
At the risk of earning myself an outright ban may I propose the following:

Perhaps some of the devs still reading this thread, may wish to table a
discussion at the forthcoming Gentoo council meeting, that this subject
is given some discussion by those [supposedly] steering the
distribution. Perhaps some of those elected representatives(!) who could
potentially be considered perpetrators of this problem would then be
tasked with addressing the issue properly, both in their own courts, and
more widely ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[M. J. Everitt]

On 10/01/18 13:49, kuzetsa wrote:
> On 01/10/2018 05:57 AM, David Seifert wrote:
>> On Wed, 2018-01-10 at 08:55 +0100, Lars Wendler wrote:
>>> On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote:
>>>
 On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
> * Posting to the list will only be possible to Gentoo developers
> and
>   whitelisted additional participants.  
 This is so contrary to what I and I thought Gentoo stands for:
 openness, transparency, inclusiveness even when these require a
 rather
 thick skin and result in high noise.  It's a price worth paying.

 I guess I should a) pay more attention to council elections b)
 consider
 the idea that the whole council thing as it stands now is just not
 working.

>>> Wow. I couldn't have said it better. 
>>> Seems we're turning into an elitist club or something... 
>>> I wonder how many users we're going to loose on this one. Well done
>>> council :-(
>>>
>> If your only reason to use Gentoo is because you can post to the main
>> developer ML, and not because we try to provide a great distribution
>> with lots of choice, a current toolchain and lots of customization,
>> then you're likely using the wrong distribution.
>>
> If development of a quality distribution which meets
> these goals requires thick skin, something is broken:
>
> I've never seen anything from the gentoo foundation
> which suggests that the gentoo developer mail list
> should be considered a safe space for disparaging
> remarks. Think of the messaging on this - for every
> 1 or 2 people who are willing to come forward to
> address these concerns, there are likely "not zero"
> who didn't want to deal with confrontation and the
> risk that rudeness and hostile behavior would be
> defended.
>
Your argument seems partially contradictory here, and I think the
interpretation may be muddled with language barriers for those
developers/users with English as a foreign language ...

Are you reinforcing the point [widely accepted by many whose heads
aren't in the proverbial sand[0]] that Gentoo is [or is becoming] an
elitist club, or condoning "bad behaviour" by both devs and non-devs on
the mailing lists

Your final point, however, makes a lot of sense .. [1]


[0] - https://www.merriam-webster.com/dictionary/head-in-the-sand
[1] - https://idioms.thefreedictionary.com/keep+head+down



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

[M. J. Everitt]

On 10/01/18 14:00, kuzetsa wrote:
> On 01/09/2018 08:21 AM, Aaron Bauman wrote:
>> On January 8, 2018 9:39:47 PM EST, Benda Xu  wrote:
>>> Hi kuzetsa,
>>>
>>> kuzetsa  writes:
>>>
 The term "beyond" feels wrong & confusing.
 (Not sure what to replace it with though)
>>> How about this?
>>>
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+
>>>  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
>>>
>>> Yours,
>>> Benda
>> I like this as it is shorter and makes the version ranges more clear.  Lgtm.
>>
>> -Aaron
> Yes. Using a plus looks nicer / cleaner to me too.
>
Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the
different between 2.6.16+ and 2.6.32+ .. should this potentially be
2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me,
and more confusing to others

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[M. J. Everitt]

On 04/01/18 11:36, M. J. Everitt wrote:
> On 04/01/18 11:21, David Seifert wrote:
>> On Thu, 2018-01-04 at 10:43 +0000, M. J. Everitt wrote:
>>> On 04/01/18 10:23, Pacho Ramos wrote:
>>>> El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
>>>>> Split off functions preserve_old_lib and preserve_old_lib_notify
>>>>> from
>>>>> eutils.eclass into a dedicated preserve-libs.eclass. These
>>>>> functions
>>>>> are rarely used and are independent of the rest of eutils,
>>>>> therefore
>>>>> moving them into their own eclass will help clarifying eclass
>>>>> inheritance in ebuilds.
>>>>>
>>>>> For backwards compatibility, eutils inherits the new eclass in
>>>>> existing EAPIs.
>>>>> ---
>>>>>  eclass/eutils.eclass| 65 ++-
>>>>> 
>>>>>  eclass/preserve-libs.eclass | 74
>>>>> +
>>>>>  2 files changed, 76 insertions(+), 63 deletions(-)
>>>>>  create mode 100644 eclass/preserve-libs.eclass
>>>>>
>>>>> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
>>>>> index 7d4193e76b51..91d329e99c9e 100644
>>>>> --- a/eclass/eutils.eclass
>>>>> +++ b/eclass/eutils.eclass
>>>>> @@ -1,4 +1,4 @@
>>>>> -# Copyright 1999-2017 Gentoo Foundation
>>>>> +# Copyright 1999-2018 Gentoo Foundation
>>>>>  # Distributed under the terms of the GNU General Public License
>>>>> v2
>>>>>  
>>>>>  # @ECLASS: eutils.eclass
>>>>> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>>>>>  # implicitly inherited (now split) eclasses
>>>>>  case ${EAPI:-0} in
>>>>>  0|1|2|3|4|5|6)
>>>>> - inherit desktop epatch estack ltprune multilib
>>>>> toolchain-funcs
>>>>> + inherit desktop epatch estack ltprune multilib preserve-
>>>>> libs
>>>>> toolchain-funcs
>>>>>   ;;
>>>>>  esac
>>>>>  
>>>>> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>>>>>   has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
>>>>> ${EROOT:=${ROOT}}
>>>>>  }
>>>>>  
>>>>> -# @FUNCTION: preserve_old_lib
>>>>> -# @USAGE:  [more libs]
>>>>> -# @DESCRIPTION:
>>>>> -# These functions are useful when a lib in your package changes
>>>>> ABI SONAME.
>>>>> -# An example might be from libogg.so.0 to libogg.so.1.  Removing
>>>>> libogg.so.0
>>>>> -# would break packages that link against it.  Most people get
>>>>> around this
>>>>> -# by using the portage SLOT mechanism, but that is not always a
>>>>> relevant
>>>>> -# solution, so instead you can call this from pkg_preinst.  See
>>>>> also the
>>>>> -# preserve_old_lib_notify function.
>>>>> -preserve_old_lib() {
>>>>> - _eutils_eprefix_init
>>>>> - if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
>>>>> - eerror "preserve_old_lib() must be called from
>>>>> pkg_preinst()
>>>>> only"
>>>>> - die "Invalid preserve_old_lib() usage"
>>>>> - fi
>>>>> - [[ -z $1 ]] && die "Usage: preserve_old_lib >>>> preserve>
>>>>> [more libraries to preserve]"
>>>>> -
>>>>> - # let portage worry about it
>>>>> - has preserve-libs ${FEATURES} && return 0
>>>>> -
>>>>> - local lib dir
>>>>> - for lib in "$@" ; do
>>>>> - [[ -e ${EROOT}/${lib} ]] || continue
>>>>> - dir=${lib%/*}
>>>>> - dodir ${dir} || die "dodir ${dir} failed"
>>>>> - cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp
>>>>> ${lib} failed"
>>>>> - touch "${ED}"/${lib}
>>>>> - done
>>>>> -}
>>>>> -
>>>>> -# @FUNCTION: preserve_old_lib_notify
>>>>> -# @USAGE:  [more libs]
>>>>> -# @DESCRIPTION:
>>>>> -# Spit helpful messages about the libraries preserved by
>>

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[M. J. Everitt]

On 04/01/18 11:21, David Seifert wrote:
> On Thu, 2018-01-04 at 10:43 +0000, M. J. Everitt wrote:
>> On 04/01/18 10:23, Pacho Ramos wrote:
>>> El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
>>>> Split off functions preserve_old_lib and preserve_old_lib_notify
>>>> from
>>>> eutils.eclass into a dedicated preserve-libs.eclass. These
>>>> functions
>>>> are rarely used and are independent of the rest of eutils,
>>>> therefore
>>>> moving them into their own eclass will help clarifying eclass
>>>> inheritance in ebuilds.
>>>>
>>>> For backwards compatibility, eutils inherits the new eclass in
>>>> existing EAPIs.
>>>> ---
>>>>  eclass/eutils.eclass| 65 ++-
>>>> 
>>>>  eclass/preserve-libs.eclass | 74
>>>> +
>>>>  2 files changed, 76 insertions(+), 63 deletions(-)
>>>>  create mode 100644 eclass/preserve-libs.eclass
>>>>
>>>> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
>>>> index 7d4193e76b51..91d329e99c9e 100644
>>>> --- a/eclass/eutils.eclass
>>>> +++ b/eclass/eutils.eclass
>>>> @@ -1,4 +1,4 @@
>>>> -# Copyright 1999-2017 Gentoo Foundation
>>>> +# Copyright 1999-2018 Gentoo Foundation
>>>>  # Distributed under the terms of the GNU General Public License
>>>> v2
>>>>  
>>>>  # @ECLASS: eutils.eclass
>>>> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>>>>  # implicitly inherited (now split) eclasses
>>>>  case ${EAPI:-0} in
>>>>  0|1|2|3|4|5|6)
>>>> -  inherit desktop epatch estack ltprune multilib
>>>> toolchain-funcs
>>>> +  inherit desktop epatch estack ltprune multilib preserve-
>>>> libs
>>>> toolchain-funcs
>>>>;;
>>>>  esac
>>>>  
>>>> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>>>>has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
>>>> ${EROOT:=${ROOT}}
>>>>  }
>>>>  
>>>> -# @FUNCTION: preserve_old_lib
>>>> -# @USAGE:  [more libs]
>>>> -# @DESCRIPTION:
>>>> -# These functions are useful when a lib in your package changes
>>>> ABI SONAME.
>>>> -# An example might be from libogg.so.0 to libogg.so.1.  Removing
>>>> libogg.so.0
>>>> -# would break packages that link against it.  Most people get
>>>> around this
>>>> -# by using the portage SLOT mechanism, but that is not always a
>>>> relevant
>>>> -# solution, so instead you can call this from pkg_preinst.  See
>>>> also the
>>>> -# preserve_old_lib_notify function.
>>>> -preserve_old_lib() {
>>>> -  _eutils_eprefix_init
>>>> -  if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
>>>> -  eerror "preserve_old_lib() must be called from
>>>> pkg_preinst()
>>>> only"
>>>> -  die "Invalid preserve_old_lib() usage"
>>>> -  fi
>>>> -  [[ -z $1 ]] && die "Usage: preserve_old_lib >>> preserve>
>>>> [more libraries to preserve]"
>>>> -
>>>> -  # let portage worry about it
>>>> -  has preserve-libs ${FEATURES} && return 0
>>>> -
>>>> -  local lib dir
>>>> -  for lib in "$@" ; do
>>>> -  [[ -e ${EROOT}/${lib} ]] || continue
>>>> -  dir=${lib%/*}
>>>> -  dodir ${dir} || die "dodir ${dir} failed"
>>>> -  cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp
>>>> ${lib} failed"
>>>> -  touch "${ED}"/${lib}
>>>> -  done
>>>> -}
>>>> -
>>>> -# @FUNCTION: preserve_old_lib_notify
>>>> -# @USAGE:  [more libs]
>>>> -# @DESCRIPTION:
>>>> -# Spit helpful messages about the libraries preserved by
>>>> preserve_old_lib.
>>>> -preserve_old_lib_notify() {
>>>> -  if [[ ${EBUILD_PHASE} != "postinst" ]] ; then
>>>> -  eerror "preserve_old_lib_notify() must be called
>>>> from
>>>> pkg_postinst() only"
>>>> -  die "Invalid preserve_old_lib_notify() usage"
>>>> -

Re: [gentoo-dev] [PATCH 1/2] preserve-libs.eclass: Split off preserve_old_lib from eutils.

[M. J. Everitt]

On 04/01/18 10:23, Pacho Ramos wrote:
> El mié, 03-01-2018 a las 17:13 +0100, Ulrich Müller escribió:
>> Split off functions preserve_old_lib and preserve_old_lib_notify from
>> eutils.eclass into a dedicated preserve-libs.eclass. These functions
>> are rarely used and are independent of the rest of eutils, therefore
>> moving them into their own eclass will help clarifying eclass
>> inheritance in ebuilds.
>>
>> For backwards compatibility, eutils inherits the new eclass in
>> existing EAPIs.
>> ---
>>  eclass/eutils.eclass| 65 ++-
>>  eclass/preserve-libs.eclass | 74
>> +
>>  2 files changed, 76 insertions(+), 63 deletions(-)
>>  create mode 100644 eclass/preserve-libs.eclass
>>
>> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
>> index 7d4193e76b51..91d329e99c9e 100644
>> --- a/eclass/eutils.eclass
>> +++ b/eclass/eutils.eclass
>> @@ -1,4 +1,4 @@
>> -# Copyright 1999-2017 Gentoo Foundation
>> +# Copyright 1999-2018 Gentoo Foundation
>>  # Distributed under the terms of the GNU General Public License v2
>>  
>>  # @ECLASS: eutils.eclass
>> @@ -20,7 +20,7 @@ _EUTILS_ECLASS=1
>>  # implicitly inherited (now split) eclasses
>>  case ${EAPI:-0} in
>>  0|1|2|3|4|5|6)
>> -inherit desktop epatch estack ltprune multilib toolchain-funcs
>> +inherit desktop epatch estack ltprune multilib preserve-libs
>> toolchain-funcs
>>  ;;
>>  esac
>>  
>> @@ -172,67 +172,6 @@ _eutils_eprefix_init() {
>>  has "${EAPI:-0}" 0 1 2 && : ${ED:=${D}} ${EPREFIX:=}
>> ${EROOT:=${ROOT}}
>>  }
>>  
>> -# @FUNCTION: preserve_old_lib
>> -# @USAGE:  [more libs]
>> -# @DESCRIPTION:
>> -# These functions are useful when a lib in your package changes ABI SONAME.
>> -# An example might be from libogg.so.0 to libogg.so.1.  Removing libogg.so.0
>> -# would break packages that link against it.  Most people get around this
>> -# by using the portage SLOT mechanism, but that is not always a relevant
>> -# solution, so instead you can call this from pkg_preinst.  See also the
>> -# preserve_old_lib_notify function.
>> -preserve_old_lib() {
>> -_eutils_eprefix_init
>> -if [[ ${EBUILD_PHASE} != "preinst" ]] ; then
>> -eerror "preserve_old_lib() must be called from pkg_preinst()
>> only"
>> -die "Invalid preserve_old_lib() usage"
>> -fi
>> -[[ -z $1 ]] && die "Usage: preserve_old_lib 
>> [more libraries to preserve]"
>> -
>> -# let portage worry about it
>> -has preserve-libs ${FEATURES} && return 0
>> -
>> -local lib dir
>> -for lib in "$@" ; do
>> -[[ -e ${EROOT}/${lib} ]] || continue
>> -dir=${lib%/*}
>> -dodir ${dir} || die "dodir ${dir} failed"
>> -cp "${EROOT}"/${lib} "${ED}"/${lib} || die "cp ${lib} failed"
>> -touch "${ED}"/${lib}
>> -done
>> -}
>> -
>> -# @FUNCTION: preserve_old_lib_notify
>> -# @USAGE:  [more libs]
>> -# @DESCRIPTION:
>> -# Spit helpful messages about the libraries preserved by preserve_old_lib.
>> -preserve_old_lib_notify() {
>> -if [[ ${EBUILD_PHASE} != "postinst" ]] ; then
>> -eerror "preserve_old_lib_notify() must be called from
>> pkg_postinst() only"
>> -die "Invalid preserve_old_lib_notify() usage"
>> -fi
>> -
>> -# let portage worry about it
>> -has preserve-libs ${FEATURES} && return 0
>> -
>> -_eutils_eprefix_init
>> -
>> -local lib notice=0
>> -for lib in "$@" ; do
>> -[[ -e ${EROOT}/${lib} ]] || continue
>> -if [[ ${notice} -eq 0 ]] ; then
>> -notice=1
>> -ewarn "Old versions of installed libraries were
>> detected on your system."
>> -ewarn "In order to avoid breaking packages that
>> depend on these old libs,"
>> -ewarn "the libraries are not being removed.  You need
>> to run revdep-rebuild"
>> -ewarn "in order to remove these old dependencies.  If
>> you do not have this"
>> -ewarn "helper program, simply emerge the 'gentoolkit'
>> package."
>> -ewarn
>> -fi
>> -ewarn "  # revdep-rebuild --library '${lib}' && rm '${lib}'"
>> -done
>> -}
>> -
>>  # @FUNCTION: built_with_use
>>  # @USAGE: [--hidden] [--missing ] [-a|-o]  > flags>
>>  # @DESCRIPTION:
>> diff --git a/eclass/preserve-libs.eclass b/eclass/preserve-libs.eclass
>> new file mode 100644
>> index ..548c6411fcf0
>> --- /dev/null
>> +++ b/eclass/preserve-libs.eclass
>> @@ -0,0 +1,74 @@
>> +# Copyright 1999-2018 Gentoo Foundation
>> +# Distributed under the terms of the GNU General Public License v2
>> +
>> +# @ECLASS: preserve-libs.eclass
>> +# @MAINTAINER:
>> +# base-sys...@gentoo.org
>> +# @BLURB: preserve libraries after SONAME changes
>> +
>> +if [[ -z ${_PRESERVE_LIBS_ECLASS} ]]; then
>> +_PRESERVE_LIBS_ECLASS=1
>> +
>> +# @FUNCTION: preserve_old_lib
>> +# @USAGE:  

Re: [gentoo-dev] [PATCH] skel.ebuild: Update comments for inherit, SLOT, KEYWORDS.

[M. J. Everitt]

On 31/12/17 19:59, Ulrich Mueller wrote:
>
>> +1, but I'm not going to suggest what to replace it with.
> How about one of these examples:
> "eautoreconf function from autotools.eclass"
> "tc-getCC function from toolchain-funcs.eclass"
>
> Ulrich
I second eautoreconf (with mention of eapply_user and/or default) as I
recently mistakenly put it in the wrong phase function  [d'oh, the
n00bness!]

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: repo/gentoo:master commit in: dev-libs/libunibreak/

[M. J. Everitt]

On 16/12/17 17:45, Andreas K. Huettel wrote:
> Am Donnerstag, 14. Dezember 2017, 13:21:47 CET schrieb Fabian Groffen:
>> Can we make it a policy to list /what/ QA issues are the justification
>> for commits like these?  A description in the commit message would be
>> preferred, but a pointer to a location where said issues can be found
>> would do too.
>>
>> Thanks,
>> Fabian
>>
>> On 14-12-2017 12:10:59 +, Andreas Hüttel wrote:
>>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34e2c43f
> That would have been a good thing to do, yes. 
>
> Unfortunately I was between two meetings, just saw the message on #gentoo-qa 
> that someone had committed straight to m-n, and if it could be reverted by 
> someone with tree access, and decided to quickly help out.
>
> (And adding a new package straight to m-n is in my opinion enough reason for 
> an immediate revert.)
>
> That said I think we have sorted out things in the meantime.
>
Andreas,

Thanks for the explanation out in the clear!

Might I politely, with all due respect, suggest that drive-by tree
commits are avoided, without adequate prior investigation. Whilst I
think your intentions were indeed noble and justified, the resolution
was not ideal .. (not that perfection is ever achievable) .. but perhaps
alerting another member of QA to do said investigation may have been a
slightly better method! :]

Best regards,
Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[M. J. Everitt]

On 15/12/17 01:17, R0b0t1 wrote (excerpted):
> I'm not trying to be confrontational, but asserting an opinion is
> correct without explaining why that it is so isn't really conducive to
> arriving at the truth. I understand not wanting to answer if I am
> completely clueless, and would like to apologize in advance for
> bothering the developers.
>
> I am not very smart, sir.
>
> Cheers,
>  R0b0t1
>
With all due respect, Gentoo is not renowned for spoon-feeding ...

Returning to the topic in hand, two key points strike out at me:-

1) Gentoo isn't really interested in having a 'stable' tree or it would
already be happening. As such, why not cut the Gordian knot, declare
that this is not something that will happen [soon] and let users make
their own choices. The [majority of] developers already seem to have ...

2) Whilst there has yet another fine bike-shed emerged on the subject, I
have only seen one volunteer willing or capable to actually take on
implementation of anything that has been discussed on this thread. As
such, you can talk all you like .. nothing will happen until somebody
actually *does* something .. For all the hating, I will duly credit
mgorny for producing a consistent quantity of commits across the board
in Gentoo, and whilst you may not agree with all his bitching (for want
of a better term) at least he can stand and say "well at least I did
*something* about it, whether You like it or not ...".

Damnit, there's another $2 from me .. my apologies.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists

[M. J. Everitt]

On 04/12/17 00:37, Matt Turner wrote:
> A user requested I forward this information to the mailing list:
>
> There's been research, on this, and the study by harvard business
> school was summarized and discussed by NPR in 2015:
>
> [ Turns out toxic coworkers are more
> than just an annoyance. A new study
> out of the Harvard Business School
> warns that bullying workers are more costly,
> even if they are more productive. ] -- NPR description
>
> https://www.npr.org/2015/12/16/460024322/harvard-business-school-study-highlights-costs-of-toxic-workers
> https://goo.gl/g8Ujuk (short URL of the same)
>
> With gentoo being a non-profit organization, an alternative way to
> view it could be the trade-off of seeing developers / maintainers /
> staff leave, and any "lost profits" are in the form of community
> relations, image, and willingness for ongoing productive work by those
> who remain with the gentoo organization.
>
> Research paper itself (which includes supporting 57 citations)
>
> http://www.hbs.edu/faculty/Publication%20Files/16-057_d45c0b4f-fa19-49de-8f1b-4b12fe054fea.pdf
> https://goo.gl/42A8v7 (short URL of the same)
>
> ... and was itself cited a dozen or times:
>
> https://scholar.google.com/scholar?cites=5443947091657980238
> https://goo.gl/obvdzh (short URL of the same)
>
I refer you also to a former Gentoo developer's talk on "A$$holes on
your project" ... [1]

[1] - https://www.youtube.com/watch?v=-ZSli7QW4rg



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 20:44, Michael Orlitzky wrote:
> On 11/27/2017 03:37 PM, Arve Barsnes wrote:
>> Sounds kind of weird? If he has keyworded the game package, shouldn't it
>> just never install that version if it depends on an unstable package?
> That's right, but if there are two available ~arch versions, one of
> which has all stable dependencies and (the newer) one of which has all
> ~arch dependencies, then portage will try to install the newer one and
> tell you to keyword a million things -- even though it could install the
> first one with less hassle.
>
> For example, if you're on a system with no ruby packages, then it's the
> difference between having to keyword 10 packages for rails-x.y.z versus
> 200 packages for rails-x.y.(z+1). I'd rather have the slightly older
> version that requires less configuration.
>
>
You might achieve something with one of the new
"autounmask-keep-keywords" -type parameters to portage .. although YMMV,
etc ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 20:34, Rich Freeman wrote:
> On Mon, Nov 27, 2017 at 3:15 PM, M. J. Everitt <m.j.ever...@iee.org> wrote:
>> On 27/11/17 18:44, Christopher Head wrote:
>>> For those of us who run mostly stable systems, there is one question I 
>>> don’t know a good answer to.
>>>
>>> If I add a specific version of a game to package.accept_keywords, I will 
>>> get that version forever. That’s not really what I want: I prefer to stay 
>>> up to date as new versions are packaged.
>>>
>>> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
>>> latest version. If that version has some unstable dependencies which I 
>>> haven’t also accepted, Portage will yell at me. An example of this is 
>>> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter 
>>> of which is unstable.
>>>
>>> What I really want to install is, “the latest version of the package that 
>>> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
>>> don’t know any way to tell Portage that. Am I missing something, or is that 
>>> indeed impossible?
>> Sounds to me a failure in adhering to the stabilisation criterion that
>> state that all deps must be stabilised FIRST .. as the bugzilla
>> stable-bot will now automagically check ...
>>
> Nobody is stabilizing anything.  That is the whole reason he raised
> that concern.  He wants to use ~arch versions of games, with stable
> dependencies.
>
> To answer his question, there is not any way out-of-the-box to tell
> portage to install the latest ~arch version of a package that has only
> stable or already-accepted dependencies.  Certainly it should be
> possible to build such a feature, but it doesn't exist today.
>
Ah my apologies .. that's definitely what most would consider a bit of
an 'edge case' then ..

Thanks for the clarification, Rich.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] NEWS item for games destabling

[M. J. Everitt]

On 27/11/17 18:44, Christopher Head wrote:
> For those of us who run mostly stable systems, there is one question I don’t 
> know a good answer to.
>
> If I add a specific version of a game to package.accept_keywords, I will get 
> that version forever. That’s not really what I want: I prefer to stay up to 
> date as new versions are packaged.
>
> If I add just a cat/pkg to p.a_k, Portage will always try to pull in the 
> latest version. If that version has some unstable dependencies which I 
> haven’t also accepted, Portage will yell at me. An example of this is 
> games-emulation/mednafen-0.9.46 depending on dev-libs/lzo-2.10, the latter of 
> which is unstable.
>
> What I really want to install is, “the latest version of the package that 
> doesn’t pull in any deps that aren’t available (stable or accepted),” but I 
> don’t know any way to tell Portage that. Am I missing something, or is that 
> indeed impossible?
Sounds to me a failure in adhering to the stabilisation criterion that
state that all deps must be stabilised FIRST .. as the bugzilla
stable-bot will now automagically check ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[M. J. Everitt]

On 21/11/17 21:01, Manuel Rüger wrote:
> Packages up for grabs:
>
> * app-crypt/yubikey-manager-qt
> * sys-apps/etckeeper
> * sys-auth/yubico-piv-tool
> * dev-libs/libsodium
> * app-editors/retext
> * sys-apps/rkflashtool
> * dev-embedded/esptool
> * app-shells/thefuck
> * app-crypt/paperkey
> * dev-util/bumpversion
> * dev-python/python-afl
> * dev-python/pyotherside
> * dev-util/docker-distribution-pruner
>
I can proxy etckeeper and esptool as I use both those ... will check for
bugs ..

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged

[M. J. Everitt]

On 20/11/17 03:38, hero...@gentoo.org wrote:
> From: Benda Xu 
>
> Thanks MJ, how about "Unprivileged to execute"? Less bytes.
>
>   enewgroup and enewuser does not apply when executed as a normal
>   user, e.g. under Gentoo Prefix.
> ---
>  eclass/user.eclass | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..8ff06935277 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
>  # Default uid is (pass -1 for this) next available, default shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Unprivileged to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the username
> @@ -262,6 +266,10 @@ enewuser() {
>  # do the rest.  You may specify the gid for the group or allow the group to
>  # allocate the next available one.
>  enewgroup() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Unprivileged to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the group
That's rather strange English .. perhaps "Unprivileged: cannot execute..."

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged.

[M. J. Everitt]

On 20/11/17 03:25, hero...@gentoo.org wrote:
> From: Benda Xu 
>
>   enewgroup and enewuser does not apply when executed as a normal
>   user, e.g. under Gentoo Prefix.
> ---
>  eclass/user.eclass | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/eclass/user.eclass b/eclass/user.eclass
> index 86bcd282479..82ccc1100ac 100644
> --- a/eclass/user.eclass
> +++ b/eclass/user.eclass
> @@ -103,6 +103,10 @@ egetent() {
>  # Default uid is (pass -1 for this) next available, default shell is
>  # /bin/false, default homedir is /dev/null, and there are no default groups.
>  enewuser() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the username
> @@ -262,6 +266,10 @@ enewuser() {
>  # do the rest.  You may specify the gid for the group or allow the group to
>  # allocate the next available one.
>  enewgroup() {
> + if [[ ${EUID} != 0 ]] ; then
> + einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
> + return 0
> + fi
>   _assert_pkg_ebuild_phase ${FUNCNAME}
>  
>   # get the group
s/Donot have enough privilege/Insufficient privileges/ or "Needs root"

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs: sys-process/parallel

[M. J. Everitt]

On 28/10/17 22:02, Jonas Stein wrote:
> Dear all,
>
> The following packages are up for grabs:
>
> sys-process/parallel
>
> after retirement of the proxied maintainer.
> (https://bugs.gentoo.org/633090)
>
> https://packages.gentoo.org/packages/sys-process/parallel
>
> The ebuild was defacto maintained by several gentoo developers who kept
> the package up to date.
>
> The tool is very powerful and it would be great to have one or more
> interested developers who want to maintain it.
>
Possibly worth CC'ing to the proxy-maint ML too? fwiw...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[M. J. Everitt]

On 28/10/17 03:41, Dean Stephens wrote:
> On 10/27/17 17:48, Hanno Böck wrote:
>> Should a package manager reject a sync if it is too old? or not install
>> packages if a sync hasn't happened for some time? What is considered
>> "outdated"? I think that should be clarified how exactly it's supposed
>> to work.
>>
> If such a rejection is to be the default, an override option should be
> required as part of the spec. There are use cases where using an "old"
> repository would be necessary, even if only temporarily.
>
I_KNOW_WHAT_I_AM_DOING=1

:]




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] FEATURES=splitdebug and debugedit

[M. J. Everitt]

On 12/10/17 22:24, Francesco Riosa wrote:
> hi,
>
> FEATURES=splitdebug at the moment require package dev-util/debugedit
> which is a lagging behind upstream.
> However package app-arch/rpm (from which debugedit is forked) always
> install the same binary in ${ROOT}/usr/libexec/rpm/debugedit.
>
> In 2017 I don't see much value in maintaining a fork from a package
> (rpm) that weight less than 3MB when the functionality we need is
> already all upstreamed. But if there is someone willing to keep it up to
> date, that's totally fine.
>
> Provided we^W you keep dev-util/debugedit indefinitely  it's possible to
> provide more useful choices to the users with at least two courses of
> action:
>
> 1) instruct ${package_manager} to search for `debugedit` first in
> ${PATH} _and_ then in /usr/libexec/rpm/debugedit.
> This way dev-util/debugedit take precedence, if it's not installed and
> app-arch/rpm is, then the latter will be used.
>
> 2) optionally (via useflag) create a symlink in /usr/bin to the libexec
> debugedit when installing rpm. Obviously the two package must block each
> other.
> the rpm package implementing this solution (revbumped to latest) is
> available here:
> https://github.com/vivo75/vivovl/blob/master/app-arch/rpm/rpm-4.14.0.ebuild
>
> thanks for reading and please share your thoughts
>
> -- Francesco (vivo) Riosa
>
Sounds to me like a potential case of a 'virtual/debugedit' package,
depending on one of rpm or debugedit to be installed, perhaps?

MJE




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...

[M. J. Everitt]

On 18/09/17 16:36, Andreas K. Huettel wrote:
> Am Montag, 18. September 2017, 14:28:37 CEST schrieb M. J. Everitt:
>> 
>>
>> Would a virtual help any? Probably overlooking a good number of factors,
>> but wasn't mentioned yet ...
>>
> So far I don't see how...  Virtual would mean that the same functionality is 
> provided by different packages, and that they can be exchanged at runtime. 
> However, for rpc there are different library *names* (sonames) to be linked, 
> and for nls the soversion is different... Even if the headers were identical, 
> that wouldnt work :/
>
Gotcha, thanks for the explanation. So you'd even need a common API
(header, etc) to be able to do some fudgery linking the lib names even.

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ...

[M. J. Everitt]

On 18/09/17 10:56, Andreas K. Huettel wrote:
> So glibc-2.26 is already out for some time, but we still haven't keyworded it 
> yet. Why?
>
> * I want to use the opportunity to make the long-delayed switchover from 
> glibc-internal SunRPC (long deprecated and outdated) to external 
> implementations (libtirpc, and possibly ntirpc).
>
> * The (outdated and deprecated) NIS(YP) and NIS+ support (libnsl) has been 
> removed from glibc (except for a compatibility library that doesnt install 
> headers), and is now provided by net-libs/libnsl (increased soversion).
>
> This mail is mainly about how to best structure the transition.
> Comments, suggestions, corrections, feedback welcome.
>
> 1) About RPC. 
>
> AFACIS there are three implementations:
> a) SunRPC, headers in /usr/include, code provided by glibc
> b) net-libs/libtirpc, headers in /usr/include/libtirpc, library -l tirpc
> c) (?) net-libs/ntirpc, headers in /usr/include/ntirpc, library -l ntirpc
>
> Option a) is going away with sys-libs/glibc-2.26-r1. 
> Options b) and c) may in addition need headers from net-libs/rpcsvc-proto
> I haven't done any testing with c) yet, will do so.
> a), b), and c) are co-installable.
>
> My suggestion for an ideal implementation would be that any package that uses 
> RPC defines useflags:
> sunrpc - build against glibc
> libtirpc - build against net-libs/libtirpc
> ntirpc - build against net-libs/ntirpc
> with 
> REQUIRED_USE="^^ ( sunrpc libtirpc ntirpc )"
> If rpc support is optional with useflag rpc, then this becomes
> REQUIRED_USE="rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )"
>
> Since the three options are coinstallable I see no problems with a package 
> only supporting a subset, but I have no clue how this interacts at runtime.
>
> Of course this "ideal option" is also the most work-intensive.


Would a virtual help any? Probably overlooking a good number of factors,
but wasn't mentioned yet ...

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [FRC] News item: Changing USE flags for >=app-backup/bacula

[M. J. Everitt]

On 15/08/17 18:49, tom...@gentoo.org wrote:
> I think we can find a proper formulation for the use flag description in
> metadata.xml, e.g.:
>
> director - Installs the backup director additional to the default file daemon.
> storage-daemon - Installs the storage daemon additional to the default file
> daemon.
>
> Thomas
>
>
s/additional to the default file daemon.//

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] Rewrite doins in python (bug 624526)

[M. J. Everitt]

On 14/08/17 08:39, Zac Medico wrote:
> From: Hidehiko Abe 
>
> doins is written in bash. However, specifically in case that
> too many files are installed, it is very slow.
> This CL rewrites the script in python for performance.
>
> BUG=chromium:712659
> TEST=time (./setup_board --forace && \
>  ./build_package --withdev && \
>  ./build_image --noenable_rootfs_verification test)
> ===Before===
> real21m35.445s
> user93m40.588s
> sys 21m31.224s
>
> ===After===
> real17m30.106s
> user94m1.812s
> sys 20m13.468s
>
I know I'm gonna get chewed out on this one, but here goes anyway ...

Surely for a package like chromium, who's build time is already in the
'hours' range anyway, surely a couple of minutes gain for the install
phase is neither here nor there?! If there were some genuine filesystem
iop gains/etc for this change, I think I'd likely support it further ..

On this basis, what do the performance differences look like on an
'average' package .. and are there any regressions in this regard?!

I take issue with the copyright assignment, as I believe the legal ..
err .. IANAL devs are campaigning for full rights to be owned and
enforced by Gentoo Inc LLC in the US .. even if they have no idea what
that means or does .. :]

MJE



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --autounmask-keep-keywords option (bug 622480)

[M. J. Everitt]

On 14/08/17 01:19, Zac Medico wrote [excerpted]:
> You'll get the same result as --autounmask-use-only if you use
> --autounmask-keep-keywords together with --autounmask-keep-masks.
>
> This way, we can also add --autounmask-keep-license and
> --autounmask-keep-use options if we want, and the meaning is very easy
> to explain. The meaning of --autounmask-use-only would have required
> more explanation, since it allowed license changes in addition to USE
> changes.
I guess that's the more flexible option, and logical to all users of all
locales ;)

Does portage ignore missing command-line options, if I set them in my
make.conf in anticipation!?!?!

Thanks for the clear explanation, extra coding, and look forward to the
push to 'live' :)

Michael.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] emerge: add --autounmask-keep-keywords option (bug 622480)

[M. J. Everitt]

On 12/08/17 19:08, Zac Medico wrote:
> The option prevents --autounmask from making changes to
> package.accept_keywords. This option does not imply
> --autounmask-keep-masks, so --autounmask is still allowed
> to create package.unmask changes unless the
> --autounmask-keep-masks is also specified.
>
> X-Gentoo-bug: 622480
> X-Gentoo-bug-url: https://bugs.gentoo.org/622480
> ---
>  man/emerge.1   |  7 +++
>  pym/_emerge/depgraph.py| 12 ++--
>  pym/_emerge/main.py|  9 +++
>  .../resolver/test_autounmask_keep_keywords.py  | 68 
> ++
>  4 files changed, 92 insertions(+), 4 deletions(-)
>  create mode 100644 
> pym/portage/tests/resolver/test_autounmask_keep_keywords.py
>
> diff --git a/man/emerge.1 b/man/emerge.1
> index ffb453efb..12a0db166 100644
> --- a/man/emerge.1
> +++ b/man/emerge.1
> @@ -395,6 +395,13 @@ using the \'=\' operator will be written. With this
>  option, \'>=\' operators will be used whenever possible.
>  USE and license changes always use the latter behavior.
>  .TP
> +.BR "\-\-autounmask\-keep\-keywords [ y | n ]"
> +If \-\-autounmask is enabled, no package.accept_keywords changes will
> +be created. This leads to unsatisfied dependencies if any keyword
> +changes are required. This option does not imply \-\-autounmask\-keep\-masks,
> +so \-\-autounmask is still allowed to create package.unmask changes unless
> +the \-\-autounmask\-keep\-masks is also specified.
> +.TP
>  .BR "\-\-autounmask\-keep\-masks [ y | n ]"
>  If \-\-autounmask is enabled, no package.unmask or ** keyword changes
>  will be created. This leads to unsatisfied dependencies if
> diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
> index abe2cb1bd..b4fc5f297 100644
> --- a/pym/_emerge/depgraph.py
> +++ b/pym/_emerge/depgraph.py
> @@ -5707,6 +5707,7 @@ class depgraph(object):
>   if self._dynamic_config._autounmask is not True:
>   return
>  
> + autounmask_keep_keywords = 
> self._frozen_config.myopts.get("--autounmask-keep-keywords", "n") != "n"
>   autounmask_keep_masks = 
> self._frozen_config.myopts.get("--autounmask-keep-masks", "n") != "n"
>   autounmask_level = self._AutounmaskLevel()
>  
> @@ -5716,14 +5717,16 @@ class depgraph(object):
>   autounmask_level.allow_license_changes = True
>   yield autounmask_level
>  
> - autounmask_level.allow_unstable_keywords = True
> - yield autounmask_level
> -
> - if not autounmask_keep_masks:
> + if not autounmask_keep_keywords:
> + autounmask_level.allow_unstable_keywords = True
> + yield autounmask_level
>  
> + if not (autounmask_keep_keywords or autounmask_keep_masks):
> + autounmask_level.allow_unstable_keywords = True
>   autounmask_level.allow_missing_keywords = True
>   yield autounmask_level
>  
> + if not autounmask_keep_masks:
>   # 4. USE + license + masks
>   # Try to respect keywords while discarding
>   # package.mask (see bug #463394).
> @@ -5732,6 +5735,7 @@ class depgraph(object):
>   autounmask_level.allow_unmasks = True
>   yield autounmask_level
>  
> + if not (autounmask_keep_keywords or autounmask_keep_masks):
>   autounmask_level.allow_unstable_keywords = True
>  
>   for missing_keyword, unmask in ((False, True), (True, 
> True)):
> diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
> index 2132aa63c..d3a415b91 100644
> --- a/pym/_emerge/main.py
> +++ b/pym/_emerge/main.py
> @@ -129,6 +129,7 @@ def insert_optional_args(args):
>   '--autounmask'   : y_or_n,
>   '--autounmask-continue'  : y_or_n,
>   '--autounmask-only'  : y_or_n,
> + '--autounmask-keep-keywords' : y_or_n,
>   '--autounmask-keep-masks': y_or_n,
>   '--autounmask-unrestricted-atoms' : y_or_n,
>   '--autounmask-write' : y_or_n,
> @@ -348,6 +349,11 @@ def parse_opts(tmpcmdline, silent=False):
>   "choices" : true_y_or_n
>   },
>  
> + "--autounmask-keep-keywords": {
> + "help": "don't add package.accept_keywords entries",
> + "choices" : true_y_or_n
> + },
> +
>   "--autounmask-keep-masks": {
>   "help": "don't add package.unmask entries",
>   "choices" : true_y_or_n
> @@ -797,6 +803,9 @@ def parse_opts(tmpcmdline, silent=False):
>   if myoptions.autounmask_unrestricted_atoms in true_y:
>   myoptions.autounmask_unrestricted_atoms = True
>  
> + if 

Re: [gentoo-dev] Re: Revisions for USE flag changes

[M. J. Everitt]

On 13/08/17 11:11, Michael Orlitzky wrote:
> On 08/12/2017 10:52 PM, Duncan wrote:
>> How so?  Are you arguing that deciding to system-wide switch to/from 
>> pulseaudio, systemd, or gstreamer is nonsense?
>>
> The meaning of any one USE flag varies widely across packages. I could
> never say "I want to enable USE=gstreamer" for every package in the
> tree, because I have no idea what it does for most of them. Setting
> USE=whatever globally essentially means "make random changes to my
> system" -- hence my wording.
>
> The meaning of a USE flag is per-package, so per-package is the only
> meaningful way to set them.
>
Which is why we have GLOBAL use flags and LOCAL use flags, right?!

I'm not sure I'm actually reading this discussion right now?! and I'm
*not* a dev ...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: sys-boot/plymouth needs major fixes/maintainer

[M. J. Everitt]

On 05/08/17 03:16, Michael Palimaka wrote:
> On 08/05/2017 12:37 AM, Mart Raudsepp wrote:
>> On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>>> I am looking into this for openrc. I copied it over to my personal
>>> overlay.
>> Ok, how about I mark myself as maintainer then and add you as co
>> -maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
>> or otherwise?
>> sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
>> still, right?
>>
>> I'm not sure about
>> kde-plasma/breeze-plymouth
>> kde-plasma/plymouth-kcm
>> do you use KDE/Plasma to care for those too?
> These two are still maintained by KDE team, they just got masked
> (without asking by the way...) because they depend on plymouth.
>
You mean to say treecleaners and QA should actually contact maintainers
before wielding their chainsaws ??  Musta missed that policy doc ...



signature.asc
Description: OpenPGP digital signature