GSoC

GSoC

[Andreas Enge]

Hello,

I still think that an infrastructure based on gnunet for distributing
cryptographically signed packages would be interesting. In a nutshell,
I would like arbitrary independent instances to inject signed packages
into the network. A user could maintain a list of trusted keys and try
to download a package signed with one of the keys from the network.

Andreas

Re: GSoC

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> I still think that an infrastructure based on gnunet for distributing
> cryptographically signed packages would be interesting. In a nutshell,
> I would like arbitrary independent instances to inject signed packages
> into the network. A user could maintain a list of trusted keys and try
> to download a package signed with one of the keys from the network.

Agreed.  I’ll prepare a mail and copy/paste that one, the Emacs one, and
the Hurd one.

Thanks,
Ludo’.

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/