The licence change is fine with me.
On 22 May 2013 23:25, "Pádraig Brady" wrote:
> On 05/22/2013 06:49 PM, Eric Blake wrote:
> > I am trying to fix a bug in libvirt where a child process deadlocked
> > because it called initgroups() in between fork and exec when the parent
> > was multithreaded;
On 05/22/2013 11:49 AM, Eric Blake wrote:
> I am trying to fix a bug in libvirt where a child process deadlocked
> because it called initgroups() in between fork and exec when the parent
> was multithreaded; it turns out that looking up group membership
> information requires a mutex, but if some o
On 2013-05-22 Eric Blake wrote:
> Since getgrouplist is implemented in glibc as LGPLv2+, is there any
> objection to relicensing the following modules as LGPLv2+?
[...]
> getgroups [LGPLv3+] => *Jim, *Eric, Bruno, Paul
> getugroups [GPLv3+] => *Jim, Eric, Paul, Bruno, Lasse
> mgetgroups [GPLv3+] =>
Eric Blake wrote:
> I am trying to fix a bug in libvirt where a child process deadlocked
> because it called initgroups() in between fork and exec when the parent
> was multithreaded; it turns out that looking up group membership
> information requires a mutex, but if some other thread in the paren
On 05/22/2013 06:49 PM, Eric Blake wrote:
> I am trying to fix a bug in libvirt where a child process deadlocked
> because it called initgroups() in between fork and exec when the parent
> was multithreaded; it turns out that looking up group membership
> information requires a mutex, but if some o
It's fine with me to relicense that as LGPLv2+.
I am trying to fix a bug in libvirt where a child process deadlocked
because it called initgroups() in between fork and exec when the parent
was multithreaded; it turns out that looking up group membership
information requires a mutex, but if some other thread in the parent
owns that mutex at the t
