Re: GSoC

Re: GSoC

[ng0]

On second thoughts I think it's okay to have all of this in
public, there are no stupid questions.

On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
> Heya,
>
> ng0@n0.is skribis:
>
>> Sorry for the offlist message, but I thought since you list
>> yourself as possible mentor for the item I'd ask.
>
> What?  I didn’t add myself there I think, we should find out where that
> comes from.  :-)

So.. who added Ludovic to the RISC-V item? And if not Ludovic,
who'd be a good mentor for this item (and has time to spend on
it)? Manolis has worked on porting to a different kernel, Efraim
has worked on porting to another architecture.

>> With regards to RISC-V porting: a question I don't dare asking in
>> public because it's answer could be too obvious: is the porting
>> possible without owning any real RISC-V hardware?
>
> I know very little about RISC-V, but I suppose QEMU could help (and most
> of the porting work is about getting cross-compilation right.)
>
>> I think at this point I know enough in Guix to port it to another
>> architecture and would apply for this when the GSoC student
>> applications are open, depending on your reply.
>
> Cool.  I think you’re welcome to discuss publicly the details and, as a
> last resort, privately with the person who submitted this idea (I don’t
> remember who that was, but we could ask on the list.)
>
> Cheers,
> Ludo’.
>

So, ahead of time, I'm interested in porting Guix to
RISC-V. Looking at the timeline on the Google GSoC website it
falls into my next semester where I can't tell you right how many
hours I have available.
Students applications period starts in March, so that gives me
enough time to look into how porting without owning the hardware
works, refreshing my memory on it (recently I've read about slow
but native compiling of ARM on qemu).
As Ludovic wrote, and by my understanding of porting, it will
mostly cover bootstrap + ideally having a compiled (better:
functional) Guix on RISC-V?
-- 
ng0 :: https://ea.n0.is
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/

Re: GSoC

[ng0]

On Tue, 06 Feb 2018, ng0@n0.is wrote:
> On second thoughts I think it's okay to have all of this in
> public, there are no stupid questions.
>
> On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
>> Heya,
>>
>> ng0@n0.is skribis:
>>
>>> Sorry for the offlist message, but I thought since you list
>>> yourself as possible mentor for the item I'd ask.
>>
>> What?  I didn’t add myself there I think, we should find out where that
>> comes from.  :-)
>
> So.. who added Ludovic to the RISC-V item? And if not Ludovic,
> who'd be a good mentor for this item (and has time to spend on
> it)? Manolis has worked on porting to a different kernel, Efraim
> has worked on porting to another architecture.
>
>>> With regards to RISC-V porting: a question I don't dare asking in
>>> public because it's answer could be too obvious: is the porting
>>> possible without owning any real RISC-V hardware?
>>
>> I know very little about RISC-V, but I suppose QEMU could help (and most
>> of the porting work is about getting cross-compilation right.)
>>
>>> I think at this point I know enough in Guix to port it to another
>>> architecture and would apply for this when the GSoC student
>>> applications are open, depending on your reply.
>>
>> Cool.  I think you’re welcome to discuss publicly the details and, as a
>> last resort, privately with the person who submitted this idea (I don’t
>> remember who that was, but we could ask on the list.)
>>
>> Cheers,
>> Ludo’.
>>
>
> So, ahead of time, I'm interested in porting Guix to
> RISC-V. Looking at the timeline on the Google GSoC website it
> falls into my next semester where I can't tell you right how many
> hours I have available.
> Students applications period starts in March, so that gives me
> enough time to look into how porting without owning the hardware
> works, refreshing my memory on it (recently I've read about slow
> but native compiling of ARM on qemu).
> As Ludovic wrote, and by my understanding of porting, it will
> mostly cover bootstrap + ideally having a compiled (better:
> functional) Guix on RISC-V?

I've started looking into the details of how Fedora and Debian
did it. Would be really good if we'd get glibc-2.27 in the next
couple of months because 2.27 added RISC-V support. That's not a
precondition for porting but it would help later on.
I guess we have 2.27 in core-updates?

I have a couple more exams and tests upcoming, but I'll start
writing the application soon. I have some vague ideas how this
could be done and need to read into Fedora's approach more to
write up something that fits for us.
I guess this is how it usually goes, write an application,
discuss the application and then decide wether this would work
out for the GSoC item and submit to Google.. According to what I
saw here in the past and read this year at the Google Summer of
Code website at Google.
-- 
ng0 :: https://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

Re: GSoC

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 4195 bytes --]

2018-02-08 12:25 GMT+01:00 <ng0@crash.cx>:

> On Tue, 06 Feb 2018, ng0@n0.is wrote:
> > On second thoughts I think it's okay to have all of this in
> > public, there are no stupid questions.
> >
> > On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
> >> Heya,
> >>
> >> ng0@n0.is skribis:
> >>
> >>> Sorry for the offlist message, but I thought since you list
> >>> yourself as possible mentor for the item I'd ask.
> >>
> >> What?  I didn’t add myself there I think, we should find out where that
> >> comes from.  :-)
> >
> > So.. who added Ludovic to the RISC-V item? And if not Ludovic,
> > who'd be a good mentor for this item (and has time to spend on
> > it)? Manolis has worked on porting to a different kernel, Efraim
> > has worked on porting to another architecture.
> >
> >>> With regards to RISC-V porting: a question I don't dare asking in
> >>> public because it's answer could be too obvious: is the porting
> >>> possible without owning any real RISC-V hardware?
> >>
> >> I know very little about RISC-V, but I suppose QEMU could help (and most
> >> of the porting work is about getting cross-compilation right.)
> >>
> >>> I think at this point I know enough in Guix to port it to another
> >>> architecture and would apply for this when the GSoC student
> >>> applications are open, depending on your reply.
> >>
> >> Cool.  I think you’re welcome to discuss publicly the details and, as a
> >> last resort, privately with the person who submitted this idea (I don’t
> >> remember who that was, but we could ask on the list.)
> >>
> >> Cheers,
> >> Ludo’.
> >>
> >
> > So, ahead of time, I'm interested in porting Guix to
> > RISC-V. Looking at the timeline on the Google GSoC website it
> > falls into my next semester where I can't tell you right how many
> > hours I have available.
> > Students applications period starts in March, so that gives me
> > enough time to look into how porting without owning the hardware
> > works, refreshing my memory on it (recently I've read about slow
> > but native compiling of ARM on qemu).
> > As Ludovic wrote, and by my understanding of porting, it will
> > mostly cover bootstrap + ideally having a compiled (better:
> > functional) Guix on RISC-V?
>
> I've started looking into the details of how Fedora and Debian
> did it. Would be really good if we'd get glibc-2.27 in the next
> couple of months because 2.27 added RISC-V support. That's not a
> precondition for porting but it would help later on.
> I guess we have 2.27 in core-updates?
>
>
Unfortunately, no. We actually have 2.26 currently.
As we are trying to get core-updates merged soon, I guess it will
only into the next core-updates cycle. However we do have everything else,
the binutils and gcc support is already on core-updates.

I guess that we could give it a try without actual hardware. We should not
support the architecture officially until we have build farm capacity.
I currently see porting to RISC-V a bootstrapping issue, it would be really
nice if we could relax assumptions about hardware.

I am really interested in this, and I proposed the idea, but:
1. the toolchain is not really reliable yet, according to conversations on
the
#bootstrappable channel.
2. Ricardo noted, that this kind of project can be quite discouraging for
new
contributors, as it requires lot of time to build.

If you are still willing to try this, in spite of the concerns raised
above, then I
guess we could arrange mentoring you.


> I have a couple more exams and tests upcoming, but I'll start
> writing the application soon. I have some vague ideas how this
> could be done and need to read into Fedora's approach more to
> write up something that fits for us.
> I guess this is how it usually goes, write an application,
> discuss the application and then decide wether this would work
> out for the GSoC item and submit to Google.. According to what I
> saw here in the past and read this year at the Google Summer of
> Code website at Google.
> --
> ng0 :: https://crash.cx
> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/
>
>

[-- Attachment #2: Type: text/html, Size: 5575 bytes --]

Re: GSoC

[ng0]

On Thu, 08 Feb 2018, Gábor Boskovits <boskovits@gmail.com> wrote:
> 2018-02-08 12:25 GMT+01:00 <ng0@crash.cx>:
>
>> On Tue, 06 Feb 2018, ng0@n0.is wrote:
>> > On second thoughts I think it's okay to have all of this in
>> > public, there are no stupid questions.
>> >
>> > On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
>> >> Heya,
>> >>
>> >> ng0@n0.is skribis:
>> >>
>> >>> Sorry for the offlist message, but I thought since you list
>> >>> yourself as possible mentor for the item I'd ask.
>> >>
>> >> What?  I didn’t add myself there I think, we should find out where that
>> >> comes from.  :-)
>> >
>> > So.. who added Ludovic to the RISC-V item? And if not Ludovic,
>> > who'd be a good mentor for this item (and has time to spend on
>> > it)? Manolis has worked on porting to a different kernel, Efraim
>> > has worked on porting to another architecture.
>> >
>> >>> With regards to RISC-V porting: a question I don't dare asking in
>> >>> public because it's answer could be too obvious: is the porting
>> >>> possible without owning any real RISC-V hardware?
>> >>
>> >> I know very little about RISC-V, but I suppose QEMU could help (and most
>> >> of the porting work is about getting cross-compilation right.)
>> >>
>> >>> I think at this point I know enough in Guix to port it to another
>> >>> architecture and would apply for this when the GSoC student
>> >>> applications are open, depending on your reply.
>> >>
>> >> Cool.  I think you’re welcome to discuss publicly the details and, as a
>> >> last resort, privately with the person who submitted this idea (I don’t
>> >> remember who that was, but we could ask on the list.)
>> >>
>> >> Cheers,
>> >> Ludo’.
>> >>
>> >
>> > So, ahead of time, I'm interested in porting Guix to
>> > RISC-V. Looking at the timeline on the Google GSoC website it
>> > falls into my next semester where I can't tell you right how many
>> > hours I have available.
>> > Students applications period starts in March, so that gives me
>> > enough time to look into how porting without owning the hardware
>> > works, refreshing my memory on it (recently I've read about slow
>> > but native compiling of ARM on qemu).
>> > As Ludovic wrote, and by my understanding of porting, it will
>> > mostly cover bootstrap + ideally having a compiled (better:
>> > functional) Guix on RISC-V?
>>
>> I've started looking into the details of how Fedora and Debian
>> did it. Would be really good if we'd get glibc-2.27 in the next
>> couple of months because 2.27 added RISC-V support. That's not a
>> precondition for porting but it would help later on.
>> I guess we have 2.27 in core-updates?
>>
>>
> Unfortunately, no. We actually have 2.26 currently.
> As we are trying to get core-updates merged soon, I guess it will
> only into the next core-updates cycle. However we do have everything else,
> the binutils and gcc support is already on core-updates.
>
> I guess that we could give it a try without actual hardware.

Yup, exactly what Fedora + Debian do (qemu etc).

> We should not
> support the architecture officially until we have build farm
> capacity.

Right, I agree.

> I currently see porting to RISC-V a bootstrapping issue, it would be really
> nice if we could relax assumptions about hardware.
>
> I am really interested in this, and I proposed the idea, but:
> 1. the toolchain is not really reliable yet, according to conversations on
> the
> #bootstrappable channel.

Yeah, I've noticed that too. On the other hand RISC-V
mailinglists speak of starting first application ports (Java for
example). I guess more reading, in about a week I have time to do
this, will give me a better view on the problems and situation of
RISC-V in the real world + our own toolchain.

> 2. Ricardo noted, that this kind of project can be quite discouraging for
> new
> contributors, as it requires lot of time to build.

Well, I'm not a new contributor (I only had to change my email
address again, multiple reasons etc. I'll stick to this domain
now.).. Time spent building is no problem for me.
Plus I need only little help I'd guess, being 3+ years in this
project. It's nothing that will require lots of Guile expertise
(I wouldn't call myself an Guile expert, but by now I'm starting
to grok g-exps, which wasn't the case 2 years ago).

> If you are still willing to try this, in spite of the concerns raised
> above, then I
> guess we could arrange mentoring you.

Okay, great.
As I wrote above, I'll look into the Debian + Fedora material and
will take a good guess about weather we are too early for this on
Guix or not.

>> I have a couple more exams and tests upcoming, but I'll start
>> writing the application soon. I have some vague ideas how this
>> could be done and need to read into Fedora's approach more to
>> write up something that fits for us.
>> I guess this is how it usually goes, write an application,
>> discuss the application and then decide wether this would work
>> out for the GSoC item and submit to Google.. According to what I
>> saw here in the past and read this year at the Google Summer of
>> Code website at Google.
>> --
>> ng0 :: https://crash.cx
>> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/
>>
>>

-- 
ng0 :: https://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

Re: GSoC

[ng0]

On Thu, 08 Feb 2018, ng0@crash.cx wrote:
> On Thu, 08 Feb 2018, Gábor Boskovits <boskovits@gmail.com> wrote:
>> 2018-02-08 12:25 GMT+01:00 <ng0@crash.cx>:
>>
>>> On Tue, 06 Feb 2018, ng0@n0.is wrote:
>>> > On second thoughts I think it's okay to have all of this in
>>> > public, there are no stupid questions.
>>> >
>>> > On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
>>> >> Heya,
>>> >>
>>> >> ng0@n0.is skribis:
>>> >>
>>> >>> Sorry for the offlist message, but I thought since you list
>>> >>> yourself as possible mentor for the item I'd ask.
>>> >>
>>> >> What?  I didn’t add myself there I think, we should find out where that
>>> >> comes from.  :-)
>>> >
>>> > So.. who added Ludovic to the RISC-V item? And if not Ludovic,
>>> > who'd be a good mentor for this item (and has time to spend on
>>> > it)? Manolis has worked on porting to a different kernel, Efraim
>>> > has worked on porting to another architecture.
>>> >
>>> >>> With regards to RISC-V porting: a question I don't dare asking in
>>> >>> public because it's answer could be too obvious: is the porting
>>> >>> possible without owning any real RISC-V hardware?
>>> >>
>>> >> I know very little about RISC-V, but I suppose QEMU could help (and most
>>> >> of the porting work is about getting cross-compilation right.)
>>> >>
>>> >>> I think at this point I know enough in Guix to port it to another
>>> >>> architecture and would apply for this when the GSoC student
>>> >>> applications are open, depending on your reply.
>>> >>
>>> >> Cool.  I think you’re welcome to discuss publicly the details and, as a
>>> >> last resort, privately with the person who submitted this idea (I don’t
>>> >> remember who that was, but we could ask on the list.)
>>> >>
>>> >> Cheers,
>>> >> Ludo’.
>>> >>
>>> >
>>> > So, ahead of time, I'm interested in porting Guix to
>>> > RISC-V. Looking at the timeline on the Google GSoC website it
>>> > falls into my next semester where I can't tell you right how many
>>> > hours I have available.
>>> > Students applications period starts in March, so that gives me
>>> > enough time to look into how porting without owning the hardware
>>> > works, refreshing my memory on it (recently I've read about slow
>>> > but native compiling of ARM on qemu).
>>> > As Ludovic wrote, and by my understanding of porting, it will
>>> > mostly cover bootstrap + ideally having a compiled (better:
>>> > functional) Guix on RISC-V?
>>>
>>> I've started looking into the details of how Fedora and Debian
>>> did it. Would be really good if we'd get glibc-2.27 in the next
>>> couple of months because 2.27 added RISC-V support. That's not a
>>> precondition for porting but it would help later on.
>>> I guess we have 2.27 in core-updates?
>>>
>>>
>> Unfortunately, no. We actually have 2.26 currently.
>> As we are trying to get core-updates merged soon, I guess it will
>> only into the next core-updates cycle. However we do have everything else,
>> the binutils and gcc support is already on core-updates.
>>
>> I guess that we could give it a try without actual hardware.
>
> Yup, exactly what Fedora + Debian do (qemu etc).
>
>> We should not
>> support the architecture officially until we have build farm
>> capacity.
>
> Right, I agree.
>
>> I currently see porting to RISC-V a bootstrapping issue, it would be really
>> nice if we could relax assumptions about hardware.
>>
>> I am really interested in this, and I proposed the idea, but:
>> 1. the toolchain is not really reliable yet, according to conversations on
>> the
>> #bootstrappable channel.
>
> Yeah, I've noticed that too. On the other hand RISC-V
> mailinglists speak of starting first application ports (Java for
> example). I guess more reading, in about a week I have time to do
> this, will give me a better view on the problems and situation of
> RISC-V in the real world + our own toolchain.
>
>> 2. Ricardo noted, that this kind of project can be quite discouraging for
>> new
>> contributors, as it requires lot of time to build.
>
> Well, I'm not a new contributor (I only had to change my email
> address again, multiple reasons etc. I'll stick to this domain
> now.).. Time spent building is no problem for me.
> Plus I need only little help I'd guess, being 3+ years in this
> project. It's nothing that will require lots of Guile expertise
> (I wouldn't call myself an Guile expert, but by now I'm starting
> to grok g-exps, which wasn't the case 2 years ago).

Addition: I don't know what to expect, I know what mentoring is,
I just wanted to express that I feel like I understand a good
part of Guix, a bit about the way it bootstraps, and I'm patient
when it comes to doing lots of building for a long time. I just
felt I didn't express this in the quoted message. I will probably
still have questions should we find this item doable at this
stage of RISC-V toolchain support.

>> If you are still willing to try this, in spite of the concerns raised
>> above, then I
>> guess we could arrange mentoring you.
>
> Okay, great.
> As I wrote above, I'll look into the Debian + Fedora material and
> will take a good guess about weather we are too early for this on
> Guix or not.
>
>>> I have a couple more exams and tests upcoming, but I'll start
>>> writing the application soon. I have some vague ideas how this
>>> could be done and need to read into Fedora's approach more to
>>> write up something that fits for us.
>>> I guess this is how it usually goes, write an application,
>>> discuss the application and then decide wether this would work
>>> out for the GSoC item and submit to Google.. According to what I
>>> saw here in the past and read this year at the Google Summer of
>>> Code website at Google.
>>> --
>>> ng0 :: https://crash.cx
>>> A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/
>>>
>>>

-- 
ng0 :: https://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

RISC-V port for GSoC?

[Ludovic Courtès]

Hello ng0,

ng0@n0.is skribis:

> On second thoughts I think it's okay to have all of this in
> public, there are no stupid questions.

In general it’s not OK to quote private messages on a public list
without the author’s consent.

No big deal in this case, but please keep that in mind in the future.

> On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
>> Heya,
>>
>> ng0@n0.is skribis:
>>
>>> Sorry for the offlist message, but I thought since you list
>>> yourself as possible mentor for the item I'd ask.
>>
>> What?  I didn’t add myself there I think, we should find out where that
>> comes from.  :-)
>
> So.. who added Ludovic to the RISC-V item? And if not Ludovic,
> who'd be a good mentor for this item (and has time to spend on
> it)? Manolis has worked on porting to a different kernel, Efraim
> has worked on porting to another architecture.

To give some context, the issue is about the RISC-V port item at
<https://libreplanet.org/wiki/Group:Guix/GSoC-2018>.

I’m happy to help with Guix porting insight, but apart from that I’m not
the most qualified person and I’d rather have someone else mentor it, if
someone were to take this project.  Any takers?

Actually I’m unsure how good of a project it is for GSoC.  GSoC is about
development, but this one is not so much development, as Ricardo wrote
in the context of Outreachy.

What do people think?  Should we remove it from the list of GSoC ideas?

(RISC-V porting in itself does sound useful to me, just somewhat
unsuitable for GSoC.)

Ludo’.

Re: RISC-V port for GSoC?

[ng0]

On Thu, 08 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
> Hello ng0,
>
> ng0@n0.is skribis:
>
>> On second thoughts I think it's okay to have all of this in
>> public, there are no stupid questions.
>
> In general it’s not OK to quote private messages on a public list
> without the author’s consent.
>
> No big deal in this case, but please keep that in mind in the future.

Okay, I'm sorry. Next time I do what I also do in this case,
summarizing without mentioning authors, or asking first. My bad.

>> On Mon, 05 Feb 2018, ludo@gnu.org (Ludovic Courtès) wrote:
>>> Heya,
>>>
>>> ng0@n0.is skribis:
>>>
>>>> Sorry for the offlist message, but I thought since you list
>>>> yourself as possible mentor for the item I'd ask.
>>>
>>> What?  I didn’t add myself there I think, we should find out where that
>>> comes from.  :-)
>>
>> So.. who added Ludovic to the RISC-V item? And if not Ludovic,
>> who'd be a good mentor for this item (and has time to spend on
>> it)? Manolis has worked on porting to a different kernel, Efraim
>> has worked on porting to another architecture.
>
> To give some context, the issue is about the RISC-V port item at
> <https://libreplanet.org/wiki/Group:Guix/GSoC-2018>.
>
> I’m happy to help with Guix porting insight, but apart from that I’m not
> the most qualified person and I’d rather have someone else mentor it, if
> someone were to take this project.  Any takers?
>
> Actually I’m unsure how good of a project it is for GSoC.  GSoC is about
> development, but this one is not so much development, as Ricardo wrote
> in the context of Outreachy.

One could argue that this is development too, but little code
would be produced and it is more about getting code to run. In my
view it's development aswell, but I think we need something to
show Google in the end, and "Look 'ma, I made bootstrap
binaries!" is taking a very big u-turn around "writing original
code".
If we decided to cut the project from the list, I still have some
useful links and will open a bug ticket for it.

> What do people think?  Should we remove it from the list of GSoC ideas?
>
> (RISC-V porting in itself does sound useful to me, just somewhat
> unsuitable for GSoC.)
>
> Ludo’.
>
>

-- 
ng0 :: https://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

ARM compilation via qemu binfmt - Assertion failure

[Danny Milosavljevic]

Hi ng0,

On Tue, 06 Feb 2018 10:33:56 +0000
ng0@n0.is wrote:

> recently I've read about slow but native compiling of ARM on qemu.

Unfortunately, there's a (pretty reproducible) problem with it.

guix-master/guix $ ./pre-inst-env guix system disk-image --system=armhf-linux -e "(@ (gnu system install) installation-os)"
[... building grub-2.02 ...]
phase `configure' succeeded after 821.8 seconds
starting phase `patch-generated-file-shebangs'
patch-makefile-SHELL: ./po/Makefile: changing `SHELL' from `/bin/sh' to `/gnu/st[...]
phase `patch-generated-file-shebangs' succeeded after 14.6 seconds
starting phase `build'
bison -d -p grub_script_yy -b grub_script ./grub-core/script/parser.y
flex -o grub_script.yy.c --header-file=grub_script.yy.h ./grub-core/script/yylex[...]
bison: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed

This is only fixed in glibc 2.27 (not in core-updates).

The fix is:

https://sourceware.org/bugzilla/show_bug.cgi?id=22273
diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c
index dea1650..f02ac19 100644
--- a/sysdeps/unix/sysv/linux/spawni.c
+++ b/sysdeps/unix/sysv/linux/spawni.c
@@ -365,9 +365,15 @@ __spawnix (pid_t * pid, const char *file,
   if (new_pid > 0)
     {
       ec = args.err;
-      assert (ec >= 0);
       if (ec != 0)
-         __waitpid (new_pid, NULL, 0);
+       {
+         /* It handles the unlikely case where the auxiliary vfork process
+            is killed before calling _exit or execve.  */
+         int status;
+         __waitpid (new_pid, &status, 0);
+         if (WIFSIGNALED (status))
+           ec = 0;
+       }
     }
   else
     ec = -new_pid;

Re: RISC-V port for GSoC?

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> To give some context, the issue is about the RISC-V port item at
> <https://libreplanet.org/wiki/Group:Guix/GSoC-2018>.
>
> I’m happy to help with Guix porting insight, but apart from that I’m not
> the most qualified person and I’d rather have someone else mentor it, if
> someone were to take this project.  Any takers?
>
> Actually I’m unsure how good of a project it is for GSoC.  GSoC is about
> development, but this one is not so much development, as Ricardo wrote
> in the context of Outreachy.

It’s difficult to mentor a project like that; a consequence is that it
doesn’t really fit into the framework of GSoC, where mentors need to
have some way of deciding if the student is still on track (and fail the
student if necessary).

For a project that is “follow the instructions” in the best case and
“wait for upstream to fix it” in the worst case, I really don’t feel
comfortable having this as a GSoC project.  Problems encountered in the
porting effort are unforeseeable and could be outside the student’s
means to work around them — what do we do then?  Fail the student?  Pass
them by default?  It doesn’t really make sense to me to have a project
that has big unknowns as dependencies.

My opinion is to remove it from the list of GSoC ideas.

> (RISC-V porting in itself does sound useful to me, just somewhat
> unsuitable for GSoC.)

Same here.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: RISC-V port for GSoC?

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

2018-02-08 19:42 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Ludovic Courtès <ludo@gnu.org> writes:
>
> > To give some context, the issue is about the RISC-V port item at
> > <https://libreplanet.org/wiki/Group:Guix/GSoC-2018>.
> >
> > I’m happy to help with Guix porting insight, but apart from that I’m not
> > the most qualified person and I’d rather have someone else mentor it, if
> > someone were to take this project.  Any takers?
> >
> > Actually I’m unsure how good of a project it is for GSoC.  GSoC is about
> > development, but this one is not so much development, as Ricardo wrote
> > in the context of Outreachy.
>
> It’s difficult to mentor a project like that; a consequence is that it
> doesn’t really fit into the framework of GSoC, where mentors need to
> have some way of deciding if the student is still on track (and fail the
> student if necessary).
>
> For a project that is “follow the instructions” in the best case and
> “wait for upstream to fix it” in the worst case, I really don’t feel
> comfortable having this as a GSoC project.  Problems encountered in the
> porting effort are unforeseeable and could be outside the student’s
> means to work around them — what do we do then?  Fail the student?  Pass
> them by default?  It doesn’t really make sense to me to have a project
> that has big unknowns as dependencies.
>
> My opinion is to remove it from the list of GSoC ideas.
>
> > (RISC-V porting in itself does sound useful to me, just somewhat
> > unsuitable for GSoC.)
>
> Same here.
>
> Ok, remove it from the list then. It really seems, that this project does
not suit
GSoC. I am interested in getting this work, but GSoC does not seem to be the
place for this.

> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2718 bytes --]

Re: RISC-V port for GSoC?

[ng0]

On Thu, 08 Feb 2018, Ricardo Wurmus <rekado@elephly.net> wrote:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> To give some context, the issue is about the RISC-V port item at
>> <https://libreplanet.org/wiki/Group:Guix/GSoC-2018>.
>>
>> I’m happy to help with Guix porting insight, but apart from that I’m not
>> the most qualified person and I’d rather have someone else mentor it, if
>> someone were to take this project.  Any takers?
>>
>> Actually I’m unsure how good of a project it is for GSoC.  GSoC is about
>> development, but this one is not so much development, as Ricardo wrote
>> in the context of Outreachy.
>
> It’s difficult to mentor a project like that; a consequence is that it
> doesn’t really fit into the framework of GSoC, where mentors need to
> have some way of deciding if the student is still on track (and fail the
> student if necessary).
>
> For a project that is “follow the instructions” in the best case and
> “wait for upstream to fix it” in the worst case, I really don’t feel
> comfortable having this as a GSoC project.  Problems encountered in the
> porting effort are unforeseeable and could be outside the student’s
> means to work around them — what do we do then?  Fail the student?  Pass
> them by default?  It doesn’t really make sense to me to have a project
> that has big unknowns as dependencies.
>
> My opinion is to remove it from the list of GSoC ideas.

Okay, sounds more than reasonable. I also vote for removal.

So we have 4 people agreeing on removal.. let's take it down then.

>> (RISC-V porting in itself does sound useful to me, just somewhat
>> unsuitable for GSoC.)
>
> Same here.
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net

Thanks for all your replies, Ludovic, Ricardo and Gàbor.
-- 
ng0 :: https://crash.cx
A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://crash.cx/keys/

Re: RISC-V port for GSoC?

[Ludovic Courtès]

ng0 <ng0@crash.cx> skribis:

> On Thu, 08 Feb 2018, Ricardo Wurmus <rekado@elephly.net> wrote:

[...]

>> My opinion is to remove it from the list of GSoC ideas.
>
> Okay, sounds more than reasonable. I also vote for removal.
>
> So we have 4 people agreeing on removal.. let's take it down then.

Agreed, thanks.

Ludo’.

Re: ARM compilation via qemu binfmt - Assertion failure

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

Danny Milosavljevic <dannym@scratchpost.org> writes:

> This is only fixed in glibc 2.27 (not in core-updates).

Should we upgrade glibc in core-updates, then?  Or is it better to do it
in the next core-updates cycle, to avoid still more unexpected breakage?

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

It's too late in this cycle. Upgrading glibc would require a full
rebuild and would introduce new failures.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

It's too late in this cycle. Upgrading glibc would require a full
rebuild and would introduce new failures.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: ARM compilation via qemu binfmt - Assertion failure

[Pjotr Prins]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic <dannym@scratchpost.org> writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

I think we should not update packages deep in the tree unless there is
a security patch. What we have now is well tested.

Pj.


-- 

bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Ludovic Courtès]

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Unfortunately, there's a (pretty reproducible) problem with it.
>
> guix-master/guix $ ./pre-inst-env guix system disk-image --system=armhf-linux -e "(@ (gnu system install) installation-os)"
> [... building grub-2.02 ...]
> phase `configure' succeeded after 821.8 seconds
> starting phase `patch-generated-file-shebangs'
> patch-makefile-SHELL: ./po/Makefile: changing `SHELL' from `/bin/sh' to `/gnu/st[...]
> phase `patch-generated-file-shebangs' succeeded after 14.6 seconds
> starting phase `build'
> bison -d -p grub_script_yy -b grub_script ./grub-core/script/parser.y
> flex -o grub_script.yy.c --header-file=grub_script.yy.h ./grub-core/script/yylex[...]
> bison: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed

[...]

> https://sourceware.org/bugzilla/show_bug.cgi?id=22273
> diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c
> index dea1650..f02ac19 100644
> --- a/sysdeps/unix/sysv/linux/spawni.c
> +++ b/sysdeps/unix/sysv/linux/spawni.c
> @@ -365,9 +365,15 @@ __spawnix (pid_t * pid, const char *file,
>    if (new_pid > 0)
>      {
>        ec = args.err;
> -      assert (ec >= 0);
>        if (ec != 0)

Note that this is only a problem for code that uses the ‘posix_spawn’
interface, such as Bison in the example above.

In practice that interface is rarely used, which is probably why I never
hit that assertion before.

Ludo’.

Re: bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Ludovic Courtès]

Hello,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Unfortunately, there's a (pretty reproducible) problem with it.
>
> guix-master/guix $ ./pre-inst-env guix system disk-image --system=armhf-linux -e "(@ (gnu system install) installation-os)"
> [... building grub-2.02 ...]
> phase `configure' succeeded after 821.8 seconds
> starting phase `patch-generated-file-shebangs'
> patch-makefile-SHELL: ./po/Makefile: changing `SHELL' from `/bin/sh' to `/gnu/st[...]
> phase `patch-generated-file-shebangs' succeeded after 14.6 seconds
> starting phase `build'
> bison -d -p grub_script_yy -b grub_script ./grub-core/script/parser.y
> flex -o grub_script.yy.c --header-file=grub_script.yy.h ./grub-core/script/yylex[...]
> bison: ../sysdeps/unix/sysv/linux/spawni.c:360: __spawnix: Assertion `ec >= 0' failed

[...]

> https://sourceware.org/bugzilla/show_bug.cgi?id=22273
> diff --git a/sysdeps/unix/sysv/linux/spawni.c b/sysdeps/unix/sysv/linux/spawni.c
> index dea1650..f02ac19 100644
> --- a/sysdeps/unix/sysv/linux/spawni.c
> +++ b/sysdeps/unix/sysv/linux/spawni.c
> @@ -365,9 +365,15 @@ __spawnix (pid_t * pid, const char *file,
>    if (new_pid > 0)
>      {
>        ec = args.err;
> -      assert (ec >= 0);
>        if (ec != 0)

Note that this is only a problem for code that uses the ‘posix_spawn’
interface, such as Bison in the example above.

In practice that interface is rarely used, which is probably why I never
hit that assertion before.

Ludo’.