Re: Relicensing contributions

2016-10-31 Thread Samuel Thibault
Agustina Arzille, on Mon 31 Oct 2016 17:18:17 -0300, wrote: > As discussed on IRC, I'm going to relicense what I've contributed in order > to avoid any potential conflicts. Thanks! I have changed in gnumach and libpthread. > This implies: > > - My contributions to glibc are relicensed under GPLv

Re: Relicensing contributions

2016-10-31 Thread Agustina Arzille
On 2016-10-31 17:18, Agustina Arzille wrote: Hello, everyone. As discussed on IRC, I'm going to relicense what I've contributed in order to avoid any potential conflicts. This implies: - My contributions to gnumach are relicensed under GPLv2. - My contributions to glibc are relicensed under G

Relicensing contributions

2016-10-31 Thread Agustina Arzille
Hello, everyone. As discussed on IRC, I'm going to relicense what I've contributed in order to avoid any potential conflicts. This implies: - My contributions to gnumach are relicensed under GPLv2. - My contributions to glibc are relicensed under GPLv2. - My contributions to glibc add-ons (lib

[bug #49024] gnumach links with GPLv3+ material but omits GPLv3 text

2016-10-31 Thread Kalle Olavi Niemitalo
Follow-up Comment #2, bug #49024 (project hurd): I think the first step should be to import the GPLv3 license text to the source tree. Even if the GPLv3-or-later files were eventually deleted from the source tree, they would probably be left in the Git history. Having the GPLv3 license text like

Re: gnumach copyright assignment

2016-10-31 Thread Olaf Buddenhagen
Hi, On Thu, Oct 27, 2016 at 11:04:26PM +0300, Kalle Olavi Niemitalo wrote: > | 2. Developer will report occasionally, on its initiative and whenever > | requested by FSF, the changes and/or enhancements which are covered by > | this contract, and (to the extent known to Developer) any outstanding

Re: minor bug in glibc

2016-10-31 Thread Justus Winter
"Brent W. Baccala" writes: > task337(pid1240)->mach_port_deallocate (pn{ 0}) = 0xf ((os/kern) invalid > name) We talked about this briefly on the list, and I remember we agreed that this should be a nop. This needs to be documented and changed in GNU Mach, of course. Thoughts? Justus sign

Re: kernel panic in gsync_wait

2016-10-31 Thread Kalle Olavi Niemitalo
"Brent W. Baccala" writes: > My new and improved rpctrace is generating kernel panics when run on > ext2fs. This happens when rpctrace calls gsync_wait, with ext2fs as the > 'task' argument. Could gsync_wait be removed from gnumach.defs and replaced with only a trap that does not take a task_t