Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Michał Górny
On Sat, 2020-08-08 at 21:17 +0100, Roy Bamford wrote:
> With the declared aim from upstream of making udev inseparable from 
> systemd, its not something to be done lightly.
> That's the entire reason that eudev was necessary.

Really?  And I've thought that the primary reason was that udev upstream
has removed the 'repeatedly bash the rules until they succeed' feature
that required people to actually fix things.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-portage-dev] RFC: conf-update.d hook dir for dispatch-conf

2020-08-08 Thread Zac Medico
On 8/3/20 1:13 AM, Florian Schmaus wrote:
> Portage's dispatch-conf does historically only support RCS for
> configuration file archival. There are currently two unresolved
> feature requests to extend dispatch-conf support for further
> configuration file management tools:
> 
> - bug #260623 git support for dispatch-conf [1]
> - bug #698316 etckeeper support for dispatch-conf [2]
> 
> Extending dispatch-conf by a hook directory, which can be used by
> configuration file management tools to receive notifications about
> dispatch-conf updating a configuration file, appears to be flexible
> approach to satisfy those feature requests (or at least lay the
> groundwork for them).
> 
> Attached is a patch with a prototypical implementation for
> conf-update.d hooks. I am curious whether or not you deem this useful
> enough to get into dispatch-conf.

Yes, and hooks are a great way to allow for customization.

> If my suggested approach is considered sensible, then I am happy to
continue the work on it.

Yes, it looks good. I wonder if we should support hooks that are only
called once per dispatch-conf session, rather than once per file. I see
that your etckeeper hook does not utilize the file argument, so maybe it
would make more sense to call it at the end of the dispatch-conf session?

If it makes sense to have session hooks, then I suppose we can add a
separate directory for them (kind of like how we have separate
repo.postsync.d and postsync.d hooks).

> For example, I want to write a unit test for this. But I am not sure if
> portage's test framework already provides the necessary functionality
> to create test scenarios for the conf-update.d hooks. Any pointers and
> further feedback would be much appreciated.

In lib/portage/tests/emerge/test_simple.py, we execute emerge,
dispatch-conf, and etc-update inside a mock gentoo prefix environment.
Maybe you can copy that file and modify it to do what you want.

> 
> - Florian
> 
> 1: https://bugs.gentoo.org/260623
> 2: https://bugs.gentoo.org/698316
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
Hi Rich,

On Sat, Aug 08, 2020 at 06:22:17PM -0400, Rich Freeman wrote:
> On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford  wrote:
> >
> > With the declared aim from upstream of making udev inseparable from
> > systemd, its not something to be done lightly.
> > That's the entire reason that eudev was necessary.
> >
> > I would want some convincing that it was not another step on the road
> > to Gentoo being assimilated by systemd.
> 
> So, I really could care less what the default is since it won't impact
> any of my Gentoo hosts either way, but this seems like a silly reason
> to base the decision on.  IMO it was paranoid years ago when people
> first brought it up.  Now it is even moreso considering that years
> have elapsed without any grand systemd conspiracy being revealed.  If
> their goal was to make it impossible to use udev on its own just to
> mess with the 0.01% of Linux users who don't use systemd but do use
> (e)udev, I'd think they'd have gotten around to it by now, or at least
> they would still be talking about it.
 
 I couldn't agree with you more on this point. I think if they were
 going to make udev impossible to use without systemd they would have
 gotten around to that by now. And, yes, the fear of this was the
 primary reason for the switch when the council voted to change it.

> William - can you actually elaborate on WHY you want to change things?
>  Is there some problem with eudev?  Is it actively maintained and
> generally tracking upstream udev commits (minus whatever they
> intentionally don't want to accept)?
 
 It is maintained primarily by one person the last time I checked, and I
 don't really know what he has included or not included from udev. What
 I can say is that the last release of eudev hit the tree a year ago,
 and I'm not sure about feature parity with udev.

> I'd be curious as to a list of the practical differences between the
> two at this point.  For the longest time the only ones I was aware of
> were the de-bundled build system, and the change in the default
> persistent ethernet device name rule which was made in udev but not
> made (by default) in eudev.  Perhaps at this point there are other
> differences.

The only other one I know of is if you aren't using glibc udev will not
compile, but I'm not even sure that is an issue still.

The way I see it, we switched away from udev because of a fear that
never materialized, and I'm not convinced that we have enough time to
keep it in feature parity with udev which it needs to be to be the
default provider.

I am going to echo again. I am not talking about removing eudev from the
tree, so you would be able to use it if you want. I'm just suggesting
that we should start new systems out with udev.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Rich Freeman
On Sat, Aug 8, 2020 at 6:48 PM Roy Bamford  wrote:
>
> On 2020.08.08 23:22, Rich Freeman wrote:
> > On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford 
> > wrote:
> > >
> > > With the declared aim from upstream of making udev inseparable from
> > > systemd, its not something to be done lightly.
> > > That's the entire reason that eudev was necessary.
> > >
> > > I would want some convincing that it was not another step on the
> > road
> > > to Gentoo being assimilated by systemd.
> >
> > So, I really could care less what the default is since it won't impact
> > any of my Gentoo hosts either way, ..
>
> I don't have a dog in this fight. Being old and cynical, I have static /dev,
> so I use neither.
>
> I'm interested in what's changed since the Council decision [1] to make
> eudev the default.
>

And you'll note that this is the one line in your post I didn't quote,
because it was about the only thing that you said which made sense.  I
wasn't in any way criticizing that point, and basically asked the same
question myself.

-- 
Rich



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Roy Bamford
On 2020.08.08 23:22, Rich Freeman wrote:
> On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford 
> wrote:
> >
> > With the declared aim from upstream of making udev inseparable from
> > systemd, its not something to be done lightly.
> > That's the entire reason that eudev was necessary.
> >
> > I would want some convincing that it was not another step on the
> road
> > to Gentoo being assimilated by systemd.
> 
> So, I really could care less what the default is since it won't impact
> any of my Gentoo hosts either way, ..
[snip]
> 
> -- 
> Rich
> 

Rich,

I don't have a dog in this fight. Being old and cynical, I have static /dev,
so I use neither.

I'm interested in what's changed since the Council decision [1] to make 
eudev the default.

[1] https://bugs.gentoo.org/573922#c28

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgp8OZnGNadvH.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Jaco Kroon


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It actually works is enough reason for me.  Was forced to migrate a
> bunch of systems not six months back from systemd-udev to eudev because
> systemd-udev is absolutely terrible w.r.t. race conditions resulting in
> lockups that kept forcing us into manual intervention situations.
> Mostly on systems with LVM.
>
> > I don't exactly know what your situation is, but as I said, this
> > proposal wouldn't affect your systems. I'm not talking about lastrites
> > for eudev, just making it the default for new installs.

It would affect new installations.  But yes, we can switch it back to
eudev post install.

>
> I'm completely against the proposal.
>
>  I would want some convincing that it was not another step on the road
>  to Gentoo being assimilated by systemd.
> 
>  We had this discussion several years ago when the default became
>  eudev. What's changed?
> >>>
> >>> If systemd folks do make udev inseparable from systemd, then we would
> >>> need eudev to be the default, but as I see it right now, there is not
> >>> a case for it being the default.
>
> Other than that it works and the systemd version does not.  Might be
> configuration dependent, but I don't expect a default udev
> configuration/system side to not cause LVM breakages when running
> commands as simple as "lvs".  eudev in coparison just works.
>
> >  I don't know what is going on with your systems, but I suspect possible
> >  configuration dependence.

Ok, simplest mechanism we've found:

Install a system with at least one LV partition and leave some space
available in the VG, then do:

term 1:  watch lvs

term 2:  while true; do lvcreate -L1G -s -ntemp_snap /dev/${vg}/${lv} &&
lvremove /dev/${vg}/temp_snap; done

Give it anywhere from two two five minutes.  Can be hours sometimes. 
But eventually it does die.  Can't say the same for eudev.

>
> > When are the breakages happening-- just at random or during bootup?

In some cases rebooting is the only way to recover.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8vJyEACgkQCC3Esa/3
7p4eewf/bOXgnx4n30HUZnTmvhyjC4F2MTc8bOwYj45t+UMeGoIN8C+GMHxWMGvG
NQpoK2hkY8egykCbuO4rSBwV9YS/naAiAZEcEXCPdcAUgV2FxJSGWKCLDLfTiflg
vXCLpd8ybxVbVhEO5XU8K4jTc9fc4peY/4ZVK0Lhl80rzWLf/yrc9+IurBZE+0g0
GXpHxNa6e2AZWPFyNXMu83fatlyOZpy/WXE7owb+yLPwTJPs30W9OLFQ6lWXSLdx
FGyLBh8vFn9BExF3IS1ZgKYIBRrH45AazMNV3+fvO+aZX/6UfXDID/JDjXHdq3bl
awMSVX40kYbgskCkOwf5DreCrs7nBw==
=ROIf
-END PGP SIGNATURE-




Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Rich Freeman
On Sat, Aug 8, 2020 at 4:17 PM Roy Bamford  wrote:
>
> With the declared aim from upstream of making udev inseparable from
> systemd, its not something to be done lightly.
> That's the entire reason that eudev was necessary.
>
> I would want some convincing that it was not another step on the road
> to Gentoo being assimilated by systemd.

So, I really could care less what the default is since it won't impact
any of my Gentoo hosts either way, but this seems like a silly reason
to base the decision on.  IMO it was paranoid years ago when people
first brought it up.  Now it is even moreso considering that years
have elapsed without any grand systemd conspiracy being revealed.  If
their goal was to make it impossible to use udev on its own just to
mess with the 0.01% of Linux users who don't use systemd but do use
(e)udev, I'd think they'd have gotten around to it by now, or at least
they would still be talking about it.

William - can you actually elaborate on WHY you want to change things?
 Is there some problem with eudev?  Is it actively maintained and
generally tracking upstream udev commits (minus whatever they
intentionally don't want to accept)?

I'd be curious as to a list of the practical differences between the
two at this point.  For the longest time the only ones I was aware of
were the de-bundled build system, and the change in the default
persistent ethernet device name rule which was made in udev but not
made (by default) in eudev.  Perhaps at this point there are other
differences.

-- 
Rich



Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
On Sat, Aug 08, 2020 at 11:38:36PM +0200, Jaco Kroon wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> On 2020/08/08 22:57, William Hubbs wrote:
> > On Sat, Aug 08, 2020 at 09:17:20PM +0100, Roy Bamford wrote:
> >> On 2020.08.08 19:51, William Hubbs wrote:
> >>> All,
> >>>
> >>> I would like to propose that we switch the default udev provider on
> >>> new
> >>> systems from eudev to udev.
> >>>
> >>> This is not a lastrites, and it will not affect current systems since
> >>> they have to migrate manually. Also, this change can be overridden at
> >>> the profile level if some profile needs eudev (the last time I
> >>> checked,
> >>> this applies to non-glibc configurations).
> >>>
> >>> What do people think?
> >>>
> >>> Thanks,
> >>>
> >>> William
> >>>
> >>>
> >>
> >> William,
> >>
> >> With the declared aim from upstream of making udev inseparable from
> >> systemd, its not something to be done lightly.
> >> That's the entire reason that eudev was necessary.
> >  
> > Eudev never became necessary unless you are using a non-glibc system,
> > and as I said, this can be handled in the profiles.
> > Udev  runs completely fine without systemd, so I fail to see how eudev
> > is necessary for most of Gentoo.
> 
> It actually works is enough reason for me.  Was forced to migrate a
> bunch of systems not six months back from systemd-udev to eudev because
> systemd-udev is absolutely terrible w.r.t. race conditions resulting in
> lockups that kept forcing us into manual intervention situations. 
> Mostly on systems with LVM.
 
I don't exactly know what your situation is, but as I said, this
proposal wouldn't affect your systems. I'm not talking about lastrites
for eudev, just making it the default for new installs.

> I'm completely against the proposal.
> 
> >> I would want some convincing that it was not another step on the road
> >> to Gentoo being assimilated by systemd.
> >>
> >> We had this discussion several years ago when the default became
> >> eudev. What's changed?
> >
> > If systemd folks do make udev inseparable from systemd, then we would
> > need eudev to be the default, but as I see it right now, there is not
> > a case for it being the default.
> 
> Other than that it works and the systemd version does not.  Might be
> configuration dependent, but I don't expect a default udev
> configuration/system side to not cause LVM breakages when running
> commands as simple as "lvs".  eudev in coparison just works.
 
 I don't know what is going on with your systems, but I suspect possible
 configuration dependence.

When are the breakages happening-- just at random or during bootup?

William

> >
> > Another thing to consider is bus factor (eudev is maintained by one
> > person primarily, so I have doubts about its viability as the default.
> 
> Yes, this is a problem.
> 
> Kind Regards,
> Jaco
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8vG1AACgkQCC3Esa/3
> 7p7Yvgf6Apoi1oCUKSyLEvH8fAEgbMIODULJAZx5+/C1dbROdjkWEzTTp3pNjWiQ
> u8S2qz3xmh9QmKBwTAxB38U/gqXVRpF+xYfSF7K/CDUVcfAg5ViTL3W7YeJMPFNa
> Jk8BgrarAc1Ln8OXCJ37Gf0eeuyBTsQQQ5qqubzNjdLBhrZegWY57gElrItE0Ywb
> IjVBUO4QX3PSoOpZ5UlIo8Ioh+8ANXc/ADg7wASVQkd3dciyewZasZho/q6cNn6W
> c44aMNFRTeiUfcK4+bpGMslq70y7D7JITkjkP+9e68e8wkh93L8fVs4BszBYEtUY
> G6IXc4QtJ5Jf3bQRbyCnGcFYXrSLgg==
> =rF5/
> -END PGP SIGNATURE-
> 
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Jaco Kroon


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 2020/08/08 22:57, William Hubbs wrote:
> On Sat, Aug 08, 2020 at 09:17:20PM +0100, Roy Bamford wrote:
>> On 2020.08.08 19:51, William Hubbs wrote:
>>> All,
>>>
>>> I would like to propose that we switch the default udev provider on
>>> new
>>> systems from eudev to udev.
>>>
>>> This is not a lastrites, and it will not affect current systems since
>>> they have to migrate manually. Also, this change can be overridden at
>>> the profile level if some profile needs eudev (the last time I
>>> checked,
>>> this applies to non-glibc configurations).
>>>
>>> What do people think?
>>>
>>> Thanks,
>>>
>>> William
>>>
>>>
>>
>> William,
>>
>> With the declared aim from upstream of making udev inseparable from
>> systemd, its not something to be done lightly.
>> That's the entire reason that eudev was necessary.
>  
> Eudev never became necessary unless you are using a non-glibc system,
> and as I said, this can be handled in the profiles.
> Udev  runs completely fine without systemd, so I fail to see how eudev
> is necessary for most of Gentoo.

It actually works is enough reason for me.  Was forced to migrate a
bunch of systems not six months back from systemd-udev to eudev because
systemd-udev is absolutely terrible w.r.t. race conditions resulting in
lockups that kept forcing us into manual intervention situations. 
Mostly on systems with LVM.

I'm completely against the proposal.

>> I would want some convincing that it was not another step on the road
>> to Gentoo being assimilated by systemd.
>>
>> We had this discussion several years ago when the default became
>> eudev. What's changed?
>
> If systemd folks do make udev inseparable from systemd, then we would
> need eudev to be the default, but as I see it right now, there is not
> a case for it being the default.

Other than that it works and the systemd version does not.  Might be
configuration dependent, but I don't expect a default udev
configuration/system side to not cause LVM breakages when running
commands as simple as "lvs".  eudev in coparison just works.

>
> Another thing to consider is bus factor (eudev is maintained by one
> person primarily, so I have doubts about its viability as the default.

Yes, this is a problem.

Kind Regards,
Jaco

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEyyCUcKjG7P5BDam8CC3Esa/37p4FAl8vG1AACgkQCC3Esa/3
7p7Yvgf6Apoi1oCUKSyLEvH8fAEgbMIODULJAZx5+/C1dbROdjkWEzTTp3pNjWiQ
u8S2qz3xmh9QmKBwTAxB38U/gqXVRpF+xYfSF7K/CDUVcfAg5ViTL3W7YeJMPFNa
Jk8BgrarAc1Ln8OXCJ37Gf0eeuyBTsQQQ5qqubzNjdLBhrZegWY57gElrItE0Ywb
IjVBUO4QX3PSoOpZ5UlIo8Ioh+8ANXc/ADg7wASVQkd3dciyewZasZho/q6cNn6W
c44aMNFRTeiUfcK4+bpGMslq70y7D7JITkjkP+9e68e8wkh93L8fVs4BszBYEtUY
G6IXc4QtJ5Jf3bQRbyCnGcFYXrSLgg==
=rF5/
-END PGP SIGNATURE-




Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
On Sat, Aug 08, 2020 at 09:17:20PM +0100, Roy Bamford wrote:
> On 2020.08.08 19:51, William Hubbs wrote:
> > All,
> > 
> > I would like to propose that we switch the default udev provider on
> > new
> > systems from eudev to udev.
> > 
> > This is not a lastrites, and it will not affect current systems since
> > they have to migrate manually. Also, this change can be overridden at
> > the profile level if some profile needs eudev (the last time I
> > checked,
> > this applies to non-glibc configurations).
> > 
> > What do people think?
> > 
> > Thanks,
> > 
> > William
> > 
> > 
> 
> William,
> 
> With the declared aim from upstream of making udev inseparable from 
> systemd, its not something to be done lightly.
> That's the entire reason that eudev was necessary.
 
Eudev never became necessary unless you are using a non-glibc system,
and as I said, this can be handled in the profiles.
Udev  runs completely fine without systemd, so I fail to see how eudev
is necessary for most of Gentoo.

> I would want some convincing that it was not another step on the road
> to Gentoo being assimilated by systemd.
> 
> We had this discussion several years ago when the default became 
> eudev. What's changed?

If systemd folks do make udev inseparable from systemd, then we would
need eudev to be the default, but as I see it right now, there is not
a case for it being the default.

Another thing to consider is bus factor (eudev is maintained by one
person primarily, so I have doubts about its viability as the default.

William



signature.asc
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Roy Bamford
On 2020.08.08 19:51, William Hubbs wrote:
> All,
> 
> I would like to propose that we switch the default udev provider on
> new
> systems from eudev to udev.
> 
> This is not a lastrites, and it will not affect current systems since
> they have to migrate manually. Also, this change can be overridden at
> the profile level if some profile needs eudev (the last time I
> checked,
> this applies to non-glibc configurations).
> 
> What do people think?
> 
> Thanks,
> 
> William
> 
> 

William,

With the declared aim from upstream of making udev inseparable from 
systemd, its not something to be done lightly.
That's the entire reason that eudev was necessary.

I would want some convincing that it was not another step on the road
to Gentoo being assimilated by systemd.

We had this discussion several years ago when the default became 
eudev. What's changed?

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpb6AvBiQ28_.pgp
Description: PGP signature


Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread Andreas K. Huettel
> I would like to propose that we switch the default udev provider on new
> systems from eudev to udev.

Well... maybe you could somewhat expand on the why?

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)


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


[gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-08 Thread William Hubbs
All,

I would like to propose that we switch the default udev provider on new
systems from eudev to udev.

This is not a lastrites, and it will not affect current systems since
they have to migrate manually. Also, this change can be overridden at
the profile level if some profile needs eudev (the last time I checked,
this applies to non-glibc configurations).

What do people think?

Thanks,

William



signature.asc
Description: PGP signature


[gentoo-dev] last rite: media-sound/tapiir

2020-08-08 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-08)
# HOMEPAGE dead.
# Removal in 30 days. bug #736326
media-sound/tapiir




[gentoo-dev] last rite: media-sound/specimen

2020-08-08 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-08)
# Last release in 2007, HOMEPAGE dead.
# Removal in 30 days. bug #736322
media-sound/specimen




[gentoo-dev] last rite: media-sound/jackbeat

2020-08-08 Thread Miroslav Šulc

# Miroslav Šulc  (2020-08-08)
# Last release in 2010.
# Removal in 30 days. bug #736300
media-sound/jackbeat




[gentoo-portage-dev] [PATCH 1/3 v2] Add cached portage.getpid() function

2020-08-08 Thread Zac Medico
Since getpid is a syscall, cache results, and update them
via an after fork hook.

Signed-off-by: Zac Medico 
---
 lib/portage/__init__.py   | 16 +
 .../tests/process/test_AsyncFunction.py   | 24 +++
 2 files changed, 40 insertions(+)

diff --git a/lib/portage/__init__.py b/lib/portage/__init__.py
index 916c93510..4d4b590a8 100644
--- a/lib/portage/__init__.py
+++ b/lib/portage/__init__.py
@@ -14,6 +14,7 @@ try:
if not hasattr(errno, 'ESTALE'):
# ESTALE may not be defined on some systems, such as interix.
errno.ESTALE = -1
+   import multiprocessing.util
import re
import types
import platform
@@ -368,6 +369,21 @@ _internal_caller = False
 
 _sync_mode = False
 
+class _ForkWatcher:
+   @staticmethod
+   def hook(_ForkWatcher):
+   _ForkWatcher.current_pid = _os.getpid()
+
+_ForkWatcher.hook(_ForkWatcher)
+
+multiprocessing.util.register_after_fork(_ForkWatcher, _ForkWatcher.hook)
+
+def getpid():
+   """
+   Cached version of os.getpid(). ForkProcess updates the cache.
+   """
+   return _ForkWatcher.current_pid
+
 def _get_stdin():
"""
Buggy code in python's multiprocessing/process.py closes sys.stdin
diff --git a/lib/portage/tests/process/test_AsyncFunction.py 
b/lib/portage/tests/process/test_AsyncFunction.py
index 55857026d..3b360e02f 100644
--- a/lib/portage/tests/process/test_AsyncFunction.py
+++ b/lib/portage/tests/process/test_AsyncFunction.py
@@ -3,6 +3,7 @@
 
 import sys
 
+import portage
 from portage import os
 from portage.tests import TestCase
 from portage.util._async.AsyncFunction import AsyncFunction
@@ -36,3 +37,26 @@ class AsyncFunctionTestCase(TestCase):
def testAsyncFunctionStdin(self):
loop = asyncio._wrap_loop()
loop.run_until_complete(self._testAsyncFunctionStdin(loop))
+
+   def _test_getpid_fork(self):
+   """
+   Verify that portage.getpid() cache is updated in a forked child 
process.
+   """
+   loop = asyncio._wrap_loop()
+   proc = AsyncFunction(scheduler=loop, target=portage.getpid)
+   proc.start()
+   proc.wait()
+   self.assertEqual(proc.pid, proc.result)
+
+   def test_getpid_fork(self):
+   self._test_getpid_fork()
+
+   def test_getpid_double_fork(self):
+   """
+   Verify that portage.getpid() cache is updated correctly after
+   two forks.
+   """
+   loop = asyncio._wrap_loop()
+   proc = AsyncFunction(scheduler=loop, 
target=self._test_getpid_fork)
+   proc.start()
+   self.assertEqual(proc.wait(), 0)
-- 
2.25.3