GuixSD on arm

GuixSD on arm

[t3sserakt]

Hi *,

what is the status of GuixSD on arm? Is there any alpha status to test 
for somebody who can stand a lot of troubles? ;-)

Cheers

t3sserakt

Re: GuixSD on arm

[Ludovic Courtès]

Hi,

t3sserakt <t3ss@posteo.de> skribis:

> what is the status of GuixSD on arm? Is there any alpha status to test
> for somebody who can stand a lot of troubles? ;-)

There’s interest for doing that, but currently GuixSD doesn’t run at all
on ARM.  The major difficulty are (possibly) supporting U-Boot, and
providing a kernel that works well, along with other platform-specific
tweaks.

Help welcome!  :-)

Ludo’.

Re: GuixSD on arm

[t3sserakt]

Hi Ludo,

I would like to help, but I have no idea where to start.
I am "just" an application developer, and do not have
the right knowledge for doing this task alone.

Additionally to that I am busy with helping the
secushare (gnunet) project.

But if there is somebody who knows in more detail
what to do, I can help.

Cheers

t3sserakt

Am 04.07.16 um 17:33 schrieb Ludovic Courtès:
> Hi,
>
> t3sserakt <t3ss@posteo.de> skribis:
>
>> what is the status of GuixSD on arm? Is there any alpha status to test
>> for somebody who can stand a lot of troubles? ;-)
> There’s interest for doing that, but currently GuixSD doesn’t run at all
> on ARM.  The major difficulty are (possibly) supporting U-Boot, and
> providing a kernel that works well, along with other platform-specific
> tweaks.
>
> Help welcome!  :-)
>
> Ludo’.

Re: GuixSD on arm

[ng0]

t3sserakt writes:

> Hi Ludo,
>
> I would like to help, but I have no idea where to start.
> I am "just" an application developer, and do not have
> the right knowledge for doing this task alone.
>
> Additionally to that I am busy with helping the
> secushare (gnunet) project.
>
> But if there is somebody who knows in more detail
> what to do, I can help.

I think Jookia was working on this.. or still is.. I am unsure
about the state of Jookia's work.
I'll CC Jookia and we'll see if this thread gets an reply.

Additionally I CC'ed you t3ss because I don't know if you are
subscribed.

> Cheers
>
> t3sserakt
>
> Am 04.07.16 um 17:33 schrieb Ludovic Courtès:
>> Hi,
>>
>> t3sserakt skribis:
>>
>>> what is the status of GuixSD on arm? Is there any alpha status to test
>>> for somebody who can stand a lot of troubles? ;-)
>> There’s interest for doing that, but currently GuixSD doesn’t run at all
>> on ARM.  The major difficulty are (possibly) supporting U-Boot, and
>> providing a kernel that works well, along with other platform-specific
>> tweaks.
>>
>> Help welcome!  :-)
>>
>> Ludo’.
>
>
>

-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

Re: GuixSD on arm

[Jookia]

On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
> t3sserakt writes:
> 
> > Hi Ludo,
> >
> > I would like to help, but I have no idea where to start.
> > I am "just" an application developer, and do not have
> > the right knowledge for doing this task alone.
> >
> > Additionally to that I am busy with helping the
> > secushare (gnunet) project.
> >
> > But if there is somebody who knows in more detail
> > what to do, I can help.
> 
> I think Jookia was working on this.. or still is.. I am unsure
> about the state of Jookia's work.
> I'll CC Jookia and we'll see if this thread gets an reply.
> 
> Additionally I CC'ed you t3ss because I don't know if you are
> subscribed.

Hi there!

I started on an ARM port a few months ago with the intention of running the
system on my Novena, but eventually gave up given the hard development cycle.
I haven't talked about this before but I don't expect many people to read this
email, so here goes. The main pain points were these:

- Patches would get lost regularly.

This is probably the biggest issue, and from reading the mailing list it doesn't
seem to be solved. There was an attempt at adding a patch tracker but I guess
that was lost too. I suggested at some point to use a newer version of Mailman
which would help this, but the developers didn't think it useful. The suggested
way to fix this is to reply and get people's attention about your patches again.

I'm not cut out to what feels like nagging people when I don't know the reasons
why they haven't replied. Perhaps this is how things work in other systems, but
as someone that suffers from social anxiety and finds it hard enough to even
send patches I can't deal with this, and Guix seems to be doing fine without me.

- Feedback is little to none.

As patches were lost and most discussion was done on the mail list, there was
basically no discussion on patches or design problems. After getting Guix to
boot on my Libreboot machine I went to work on fixing issues with the boot
system, such as adding support for legacy Libreboot systems and encrypted
bootloaders. This was lost.

I also did some work to get LVM+LUKS working on Guix and tried to spark a
discussion in to fixing the design issues in system configuration. I think there
was about one reply, and it was lost.

Some of the work that I did do and in fact got in somewhat by proxy is GTK+
theming. There's a habit of maintainers fixing things themselves rather than
taking patches, which I feel is a further hindrance to actually working on Guix.

This gives me the impression that Guix doesn't have enough maintainers to
sustain people doing new development upstream, want to do things themselves, or
the project is just bad at communication.

- GNUness over pragmatism.

The main issue I had with doing an ARM port is the bootloader, and this is
because everyone I spoke to except Ludovic seemed to be hesitant towards using a
bootloader other than GRUB. Looking at the code base, I'd need to do make things
less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
end up with my work ignored or thrown away.

To be concrete, the conversation generally went like this: "To get the Novena
booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
is still early work compared to U-Boot (which GRUB uses) and it'd work for more
boards." then the conversation would drop off.

I have a distinct feeling this is due to a bias in building "the GNU system"
rather than building a fully free Guix-based system. I was originally going to
do a fork of Guix with my own changes that people could download, but in the end
I just went back to NixOS which runs happily on my Novena and my Libreboot
machine. The only reason I wanted to use Guix was so I could contribute patches
upstream and not maintain ones locally like I do with NixOS.

- Summary

This experience has put me off of Guix, GNU and free software development. I
don't blame any one, but more a system that doesn't incorporate people like me.
I'm not going to elaborate more on this, I just had to get it off my chest.

I'm willing to send you code and help you with what I've done: It's mostly
reworking the bootloader. There's no ARM support yet, but I did identify the
points that need changing.

Cheers,
Jookia.

Re: GuixSD on arm

[Alex Sassmannshausen]

Hey Jookia,

You might not be looking for this kind of email, but I wanted to send it
anyway, feel free to ignore…

I'm sorry to hear you feel the project is currently not set up to help
people like you contribute.  Obviously I cannot speak for the project,
as I'm rather involved on the sidelines (though I follow it with great
interest and am a keen user), but I'm sure people will be dis-heartened
to hear of your experience.  My own experience has been, and still is,
that contributing to Free Software in general has a steep learning
curve, and I really don't know if that's just me or whether this stuff
is just hard.  I don't know the solution for myself yet.

Anyway, you already say that you don't blame anyone — I just hope you
might still follow the project, and maybe, at some point in the future,
if it feels like the project might work better for you, you might give
it another go.

In the meantime, fwiw, I enjoyed your emails, even if they went totally
over my head :-)

Happy hacking,

Alex


Jookia writes:

> On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
>> t3sserakt writes:
>> 
>> > Hi Ludo,
>> >
>> > I would like to help, but I have no idea where to start.
>> > I am "just" an application developer, and do not have
>> > the right knowledge for doing this task alone.
>> >
>> > Additionally to that I am busy with helping the
>> > secushare (gnunet) project.
>> >
>> > But if there is somebody who knows in more detail
>> > what to do, I can help.
>> 
>> I think Jookia was working on this.. or still is.. I am unsure
>> about the state of Jookia's work.
>> I'll CC Jookia and we'll see if this thread gets an reply.
>> 
>> Additionally I CC'ed you t3ss because I don't know if you are
>> subscribed.
>
> Hi there!
>
> I started on an ARM port a few months ago with the intention of running the
> system on my Novena, but eventually gave up given the hard development cycle.
> I haven't talked about this before but I don't expect many people to read this
> email, so here goes. The main pain points were these:
>
> - Patches would get lost regularly.
>
> This is probably the biggest issue, and from reading the mailing list it doesn't
> seem to be solved. There was an attempt at adding a patch tracker but I guess
> that was lost too. I suggested at some point to use a newer version of Mailman
> which would help this, but the developers didn't think it useful. The suggested
> way to fix this is to reply and get people's attention about your patches again.
>
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
>
> - Feedback is little to none.
>
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
>
> Some of the work that I did do and in fact got in somewhat by proxy is GTK+
> theming. There's a habit of maintainers fixing things themselves rather than
> taking patches, which I feel is a further hindrance to actually working on Guix.
>
> This gives me the impression that Guix doesn't have enough maintainers to
> sustain people doing new development upstream, want to do things themselves, or
> the project is just bad at communication.
>
> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB. Looking at the code base, I'd need to do make things
> less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
> end up with my work ignored or thrown away.
>
> To be concrete, the conversation generally went like this: "To get the Novena
> booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
> GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
> tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
> is still early work compared to U-Boot (which GRUB uses) and it'd work for more
> boards." then the conversation would drop off.
>
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system. I was originally going to
> do a fork of Guix with my own changes that people could download, but in the end
> I just went back to NixOS which runs happily on my Novena and my Libreboot
> machine. The only reason I wanted to use Guix was so I could contribute patches
> upstream and not maintain ones locally like I do with NixOS.
>
> - Summary
>
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
> I'm not going to elaborate more on this, I just had to get it off my chest.
>
> I'm willing to send you code and help you with what I've done: It's mostly
> reworking the bootloader. There's no ARM support yet, but I did identify the
> points that need changing.
>
> Cheers,
> Jookia.

Re: GuixSD on arm

[Ludovic Courtès]

Howdy Jookia,

Jookia <166291@gmail.com> skribis:

> - Patches would get lost regularly.

Lack of responsiveness is terrible, but I think it’s easy to complain
about it until one gets involved in patch reviews.

Also, some reviews are more difficult than other: adding support for
another bootloader is not as simple as upgrading a package.

> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB.

I wrote repeatedly that using U-Boot is fine, especially if GRUB doesn’t
work on this platform.

> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system.

There is this bias, which makes a difference from most other distros.  I
don’t think I/we are blind though: when GNU lacks the right piece of
software, using another free software package is the right thing to do.

> This experience has put me off of Guix, GNU and free software development.

I think you’re throwing the baby with the bathwater.

Thanks for your feedback,
Ludo’.

Re: GuixSD on arm

[t3sserakt]

Am 05.07.16 um 00:18 schrieb Jookia:
> On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
>> t3sserakt writes:
>>
>>> Hi Ludo,
>>>
>>> I would like to help, but I have no idea where to start.
>>> I am "just" an application developer, and do not have
>>> the right knowledge for doing this task alone.
>>>
>>> Additionally to that I am busy with helping the
>>> secushare (gnunet) project.
>>>
>>> But if there is somebody who knows in more detail
>>> what to do, I can help.
>> I think Jookia was working on this.. or still is.. I am unsure
>> about the state of Jookia's work.
>> I'll CC Jookia and we'll see if this thread gets an reply.
>>
>> Additionally I CC'ed you t3ss because I don't know if you are
>> subscribed.

I am not. Thx!

> Hi there!
>
> I started on an ARM port a few months ago with the intention of running the
> system on my Novena, but eventually gave up given the hard development cycle.
> I haven't talked about this before but I don't expect many people to read this
> email, so here goes. The main pain points were these:
>
> - Patches would get lost regularly.
>
> This is probably the biggest issue, and from reading the mailing list it doesn't
> seem to be solved. There was an attempt at adding a patch tracker but I guess
> that was lost too. I suggested at some point to use a newer version of Mailman
> which would help this, but the developers didn't think it useful. The suggested
> way to fix this is to reply and get people's attention about your patches again.
>
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
>
> - Feedback is little to none.
>
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
>
> Some of the work that I did do and in fact got in somewhat by proxy is GTK+
> theming. There's a habit of maintainers fixing things themselves rather than
> taking patches, which I feel is a further hindrance to actually working on Guix.
>
> This gives me the impression that Guix doesn't have enough maintainers to
> sustain people doing new development upstream, want to do things themselves, or
> the project is just bad at communication.
>
> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB. Looking at the code base, I'd need to do make things
> less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
> end up with my work ignored or thrown away.
>
> To be concrete, the conversation generally went like this: "To get the Novena
> booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
> GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
> tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
> is still early work compared to U-Boot (which GRUB uses) and it'd work for more
> boards." then the conversation would drop off.
>
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system. 

I do not really want to start a debate on principles, but isn't the goal
of GNU
to have a fully free system?

> I was originally going to
> do a fork of Guix with my own changes that people could download, but in the end
> I just went back to NixOS which runs happily on my Novena and my Libreboot
> machine. The only reason I wanted to use Guix was so I could contribute patches
> upstream and not maintain ones locally like I do with NixOS.
>
> - Summary
>
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
> I'm not going to elaborate more on this, I just had to get it off my chest.
That reads very sad.
> I'm willing to send you code and help you with what I've done: It's mostly
> reworking the bootloader. There's no ARM support yet, but I did identify the
> points that need changing.

That would be very kind. I would endeavor that your work will not be for
nothing.
Like Alex I also had the experience, that you need a lot of patience
when participating
in free software development. There are a lot of volunteer with more or
less time
for working on a huge amount of tasks.

Maybe right now it is not the time for Guix on arm, but I hope you can
be encouraged
to give this community another chance in the future.

t3sserakt

Re: GuixSD on arm

[ng0]

Hi,

thanks for your reply Jookia.
This message makes it more clear to me why you quit/no longer
consider the other project a while (some months?) ago.

While I can not understand all of it, I have sympathy and can
understand the current decisions you made.

Further below a comment on some topics.

Jookia writes:

> On Mon, Jul 04, 2016 at 05:14:56PM +0000, ng0 wrote:
>> t3sserakt writes:
>> 
>> > Hi Ludo,
>> >
>> > I would like to help, but I have no idea where to start.
>> > I am "just" an application developer, and do not have
>> > the right knowledge for doing this task alone.
>> >
>> > Additionally to that I am busy with helping the
>> > secushare (gnunet) project.
>> >
>> > But if there is somebody who knows in more detail
>> > what to do, I can help.
>> 
>> I think Jookia was working on this.. or still is.. I am unsure
>> about the state of Jookia's work.
>> I'll CC Jookia and we'll see if this thread gets an reply.
>> 
>> Additionally I CC'ed you t3ss because I don't know if you are
>> subscribed.
>
> Hi there!
>
> I started on an ARM port a few months ago with the intention of running the
> system on my Novena, but eventually gave up given the hard development cycle.
> I haven't talked about this before but I don't expect many people to read this
> email, so here goes. The main pain points were these:
>
> - Patches would get lost regularly.
>
> This is probably the biggest issue, and from reading the mailing list it doesn't
> seem to be solved. There was an attempt at adding a patch tracker but I guess
> that was lost too. I suggested at some point to use a newer version of Mailman
> which would help this, but the developers didn't think it useful. The suggested
> way to fix this is to reply and get people's attention about your patches again.
>
> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.
>
> - Feedback is little to none.
>
> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.
>
> Some of the work that I did do and in fact got in somewhat by proxy is GTK+
> theming. There's a habit of maintainers fixing things themselves rather than
> taking patches, which I feel is a further hindrance to actually working on Guix.
>
> This gives me the impression that Guix doesn't have enough maintainers to
> sustain people doing new development upstream, want to do things themselves, or
> the project is just bad at communication.

At the moment Guix has about 35 regular contributors after 4
years. Gentoo has around 100 (or even more) after 16 or 17 years
or how long they exist now (even after many went on to other
distros).

We started using patchworks, it's okay for now, but I'm still not
completely happy. For me, It helps a bit in addition to marking
done patches as "expired" in my mail client.
Though it does not look like everyone is using patchworks, so
occasionally I go through it, marking resolved patches as what
they were resolved as. The only problem for me with it is a lack
of tls on the instance we use it on, and the register process
reads like you absolutely have to provide a first- and lastname
and it can't just be one word: in my case all patches send in by
'ng0' are now labeled as send by/author 'non such'.

I've got some further feedback regarding contribution and help
from people who don't use Email and who have a dislike for
freenode (contrary to what people claim there's is no freenode
hidden-service left). Feedback I'm taking into consideration for
a constructive proposal on changes, later when I have had enough
time to think and write about it.
It will include some longterm considerations, ideas and a
translations of an article (which is why it is taking some
time).

As a short immediate question: why did we choose freenode? why
not oftc, hackint, or a selfhosted psyced (irc,telnet,xmpp,psyc
access) instance? I know nothing is constant and frozen, and I
will give more input on the pro/cons etc in another thread,
another time.

> - GNUness over pragmatism.
>
> The main issue I had with doing an ARM port is the bootloader, and this is
> because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> bootloader other than GRUB. Looking at the code base, I'd need to do make things
> less GRUB-specific which I was happy to do, but I didn't want to do it wrong or
> end up with my work ignored or thrown away.
>
> To be concrete, the conversation generally went like this: "To get the Novena
> booting Guix I'll need to add support for U-Boot as a bootloader." "I've heard
> GRUB works on ARM, have you tried that?" "Yes, it doesn't work from what I've
> tried." "Perhaps you've done it wrong." "I can't rule that out, but GRUB on ARM
> is still early work compared to U-Boot (which GRUB uses) and it'd work for more
> boards." then the conversation would drop off.
>
> I have a distinct feeling this is due to a bias in building "the GNU system"
> rather than building a fully free Guix-based system. I was originally going to
> do a fork of Guix with my own changes that people could download, but in the end
> I just went back to NixOS which runs happily on my Novena and my Libreboot
> machine. The only reason I wanted to use Guix was so I could contribute patches
> upstream and not maintain ones locally like I do with NixOS.
>
> - Summary
>
> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.
> I'm not going to elaborate more on this, I just had to get it off my chest.
>
> I'm willing to send you code and help you with what I've done: It's mostly
> reworking the bootloader. There's no ARM support yet, but I did identify the
> points that need changing.
>
> Cheers,
> Jookia.

-- 
♥Ⓐ  ng0
For non-prism friendly talk find me on http://www.psyced.org
SecuShare – http://secushare.org

Re: GuixSD on arm

[Jookia]

On Tue, Jul 05, 2016 at 10:23:07AM +0200, Ludovic Courtès wrote:
> Howdy Jookia,

Thanks for your reply! I just want to follow up to elaborate on a few things:

> Jookia <166291@gmail.com> skribis:
> 
> > - Patches would get lost regularly.
> 
> Lack of responsiveness is terrible, but I think it’s easy to complain
> about it until one gets involved in patch reviews.
> 
> Also, some reviews are more difficult than other: adding support for
> another bootloader is not as simple as upgrading a package.

I don't want to seem like I'm criticising you or the developers over this,
especially since I do understand why things are this way. But the experience
from things being this way is a pain point for me at least, and there doesn't
seem to be any clear solutions yet. It's a bit annoying for things to move
slowly, but it's demotivating for things to come to a stop.

> > - GNUness over pragmatism.
> >
> > The main issue I had with doing an ARM port is the bootloader, and this is
> > because everyone I spoke to except Ludovic seemed to be hesitant towards using a
> > bootloader other than GRUB.
> 
> I wrote repeatedly that using U-Boot is fine, especially if GRUB doesn’t
> work on this platform.

I know that's your stance on it, but there's multiple maintainers on Guix and
multiple people to talk about the issue, especially if I need help or review on
code. It's unsettling emotionally to see different people, especially authority
figures who work with the code and decide what's useful or not, giving mixed
answers as to what direction things should be taken. Implementing something that
only one developer approves of makes me question if it really is the right
approach or worth people's time.

> > I have a distinct feeling this is due to a bias in building "the GNU system"
> > rather than building a fully free Guix-based system.
> 
> There is this bias, which makes a difference from most other distros.  I
> don’t think I/we are blind though: when GNU lacks the right piece of
> software, using another free software package is the right thing to do.

I'm glad to hear that.

> 
> > This experience has put me off of Guix, GNU and free software development.
> 
> I think you’re throwing the baby with the bathwater.

Me too, but this isn't really as much as a conscious decision as an emotional
reaction to what I've felt and perceived. I'm sure eventually it'll get better.

> Thanks for your feedback,
> Ludo’.

I'm sorry for the negativity,
Jookia.

Re: GuixSD on arm

[Ricardo Wurmus]

Jookia <166291@gmail.com> writes:

> - Patches would get lost regularly.

Yeah, this is still a problem for me.  Many patches slip by because I
have no capacity to review them in time.  I have settled on reviewing
things that I feel I’m a little more qualified to review than others,
such as R packages, scientific software, audio software.  But it’s
really tough to review things *well* and in time.

In my opinion, patchwork hasn’t improved this, unfortunately, because
patch management requires too much effort (patches aren’t reliably
marked as merged, no email control, etc).

> I'm not cut out to what feels like nagging people when I don't know the reasons
> why they haven't replied. Perhaps this is how things work in other systems, but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without me.

I’m sad to hear that this makes it hard for you to continue to
contribute to Guix.

In my case a lack of a response is usually just a result of having too
many other things to work on.  Sometimes it’s because I really don’t
feel qualified to answer (as in the case of LUKS+Libreboot because at
that time I didn’t have any experience with Libreboot).

> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think there
> was about one reply, and it was lost.

Now that my laptop is running Libreboot I’m actually looking at the
discussions you started to see how we can move forward there.  Thank you
for your experimentation and documenting your work on the mailing list!
I can assure you that it’s not lost (just not used in the moment).

> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like me.

That’s sad and I hope you will be able to reconsider some time in the
future as the project matures.

~~ Ricardo

Re: GuixSD on arm

[Jookia]

On Tue, Jul 05, 2016 at 10:53:14AM +0200, t3sserakt wrote:
> That would be very kind. I would endeavor that your work will not be for
> nothing.
> Like Alex I also had the experience, that you need a lot of patience
> when participating
> in free software development. There are a lot of volunteer with more or
> less time
> for working on a huge amount of tasks.
> 
> Maybe right now it is not the time for Guix on arm, but I hope you can
> be encouraged
> to give this community another chance in the future.
> 
> t3sserakt

Hi again, I've found my old Guix repo: https://notabug.org/Jookia/guix
It's about a month old, and I think works. There's these branches:

- SET_jookia

This is just compilation of all the branches to make a usable system.

- WIP_av

This branch adds JACK support to OpenAL, ffmpeg and ALSA. The ALSA patches can
be used to add PulseAudio configuration.
It also adds the OpenShot video editor, and bumps libsndfile down to allow
Blender to work with FLAC files properly.

Not pushed upstream because of the effort it'd take.

- WIP_freedoom

Adds Odaemx, chocolate-doom, crispy-doom for playing Doom WADs. Includes
Freedoom WAD and these are patched to do autodetection: You can just run 'guix
environment --ad-hoc odamex freedoom' and Odamex will find your WADs!
It also includes the Eureka level editor and Rocket Launcher 2.0 launcher.

Not pushed upstream because of the effort it'd take. Require WIP_sdl-union.

- WIP_gdk-pixbuf

Disables gdk-pixbuf test that freezes my 2G RAM system when building Guix. I
submitted this to Guix, but I think the response was along the lines of 'see why
the test breaks' and I didn't have the resources to debug something that would
completely lock up my system so I gave up.

- WIP_grub-platform

Majority of work to improve/decouple GRUB work here, it's what you'll be
interested in. All patches are thoroughly documented, and tested. In summary it
does some refactoring and adds the ability for GRUB 'platforms' to specified in
the system configuration. This is what you'd find on the mailing list.

My plan of attack for modularing the bootloader system was to reduce the
references to GRUB functions and assumptions as much as possible outside of
gnu/system/grub.scm then create an interface based on that for bootloaders.

- WIP_localstatedir

Not intended to be pushed upstream, it just makes source builds compatible with
binary Guix packages by default by setting the state directory to /var rather
than /usr/local/var. Suggested upstream, but it breaks some conventions.

A fix was implemented where if you already have Guix installed, but why would
you if you're boostrapping from source like I was?

- WIP_luks-keyfiles

Add LUKS device that supports being unlocked by a keyfile. Puts your key in a
globally readable initramfs in /gnu/store. Not secure if for some reason someone
has access to your /gnu/store but wants to unlock your machine when powered off.

Submitted upstream in big LUKS+LVM discussion, didn't really go anywhere.

- WIP_lvm

Adds LVM device mapping. Untested after the rebase, and probably the very wrong
way to do it since the device mapping system needs to be overhauled IMHO to
support concepts of mapping input multiple devices to multiple outputs, like
/dev/sda + /dev/sdf to LVM /dev/matrix/root and /dev/matrix/swap on a RAID
system. Currently it only goes /dev/xxx -> /dev/mapper/xxx. The same flaw
prevents chaining mapped devices like LUKS to LVM as they won't resolve
dependencies.

Submitted upstream in big LUKS+LVM discussion, didn't really go anywhere.

- WIP_mapped-devices

Disables dependency management so devices and device mappings load serially, so
device mappings can depend on each other.

Submitted upstream in big LUKS+LVM discussion, didn't really go anywhere.

- WIP_pioneer

Adds the Pioneer space simulator game.

Not pushed upstream because I didn't want to participate. May require
WIP_sdl-union.

- WIP_proxies

Adds HTTP proxy support for SVN and Git checkouts, so you can build over Tor.
Regular files don't work with HTTPS proxies since Guile doesn't support that.

Submitted upstream, used a wrong SRFI, I forgot about the patch and eventually
didn't want to participate.

- WIP_rsnapshot

Adds rsnapshot.

Not pushed upstream because I didn't want to participate.

- WIP_sdl-union

When bulding either Pioneer or Odamex, I found sdl-config reported the wrong
include directory. This fixes it by having sdl-config report the union's include
directory rather than just SDL's

I was going to submit this upstream, but when I brought up the bug with the
maintainer I got a blunt response implying the bug didn't exist. I gave up
communication altogether with developers altogether after this.

When rebasing I found that a bunch of packages already worked around this bug
which is why it wasn't an issue, so I removed the workarounds in the branch.

- WIP_themes

Adds Numix and Numix icon theme, including circles. Looks great.

Not pushed upstream because I didn't want to participate.

- Summary

I hope you (or the Guix community) get something out of this before it bitrots.

Jookia.

Re: GuixSD on arm

[Ludovic Courtès]

Hi!

Jookia <166291@gmail.com> skribis:

> On Tue, Jul 05, 2016 at 10:23:07AM +0200, Ludovic Courtès wrote:

[...]

>> > - GNUness over pragmatism.
>> >
>> > The main issue I had with doing an ARM port is the bootloader, and this is
>> > because everyone I spoke to except Ludovic seemed to be hesitant towards using a
>> > bootloader other than GRUB.
>> 
>> I wrote repeatedly that using U-Boot is fine, especially if GRUB doesn’t
>> work on this platform.
>
> I know that's your stance on it, but there's multiple maintainers on Guix and
> multiple people to talk about the issue, especially if I need help or review on
> code. It's unsettling emotionally to see different people, especially authority
> figures who work with the code and decide what's useful or not, giving mixed
> answers as to what direction things should be taken. Implementing something that
> only one developer approves of makes me question if it really is the right
> approach or worth people's time.

I don’t remember anyone rejecting the idea of using U-Boot per se.

BTW, formally I’m currently the only maintainer.  However, I think most
decisions should be (and indeed are) based on consensus among active
contributors (developers and people who participate in discussions.)
That can introduce delays in the short term, but I think it makes the
whole project stronger in the long run.

Cheers,
Ludo’.

Re: GuixSD on arm

[Ludovic Courtès]

Jookia <166291@gmail.com> skribis:

> Hi again, I've found my old Guix repo: https://notabug.org/Jookia/guix
> It's about a month old, and I think works. There's these branches:

Woow, thanks for sharing!  I hope we’ll manage to integrate this work or
get inspiration from it.

Ludo’.

GuixSD on ARM

[Daniel Pimentel]

Hi Guixs,

Guix run in ARM, but GuixSD not.

I'd like GuixSD on ARM plataform, for instance Libre Tea Computer Card 
or other ARM libre plataform.

I buy a Libre Tea Computer Card:
- https://www.crowdsupply.com/eoma68/micro-desktop
- http://retro-freedom.nz/blog/2016/06/30/eoma68-my-dream-machine/

Features Libre Tea Computer Card
- Compliant with the EOMA68 Specification
- A20 Dual-Core ARM Cortex A7, 1.2 GHz
- 2 GB RAM
- 8 GB NAND
- Micro-HDMI Interface (for 2nd monitor)
- Micro-USB-OTG (bi-directional power)
- Micro-SD Card Slot
- Pre-installed with Parabola GNU/Linux-libre Operating System (I'd like 
install GuixSD in soon)
- Respects Your Freedom (RYF) Certification from the Free Software 
Foundation (currently in progress with no known blockers)

Note: Help this project, it's cool and libre :)

-- 
Daniel Pimentel (aka d4n1)

Re: GuixSD on ARM

[Ricardo Wurmus]

Hi Daniel,

> I'd like GuixSD on ARM plataform, for instance Libre Tea Computer Card 
> or other ARM libre plataform.
>
> I buy a Libre Tea Computer Card:
> - https://www.crowdsupply.com/eoma68/micro-desktop
> - http://retro-freedom.nz/blog/2016/06/30/eoma68-my-dream-machine/

I’m also very excited about this project and wish it to succeed, because
it is appalling and discouraging to see how little environmental
concerns are usually considered in tech.

It would be very nice to be able to use GuixSD on the EOMA68.  Alas, I
don’t have an overview on what work needs to be done to get there.

~~ Ricardo

Re: GuixSD on ARM

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

>> I'd like GuixSD on ARM plataform, for instance Libre Tea Computer Card 
>> or other ARM libre plataform.
>>
>> I buy a Libre Tea Computer Card:
>> - https://www.crowdsupply.com/eoma68/micro-desktop
>> - http://retro-freedom.nz/blog/2016/06/30/eoma68-my-dream-machine/
>
> I’m also very excited about this project and wish it to succeed, because
> it is appalling and discouraging to see how little environmental
> concerns are usually considered in tech.
>
> It would be very nice to be able to use GuixSD on the EOMA68.  Alas, I
> don’t have an overview on what work needs to be done to get there.

Essentially, we need to use a supported bootloader (U-Boot or GRUB)
and provide a kernel that works well.

Ludo’.

Re: GuixSD on ARM

[Eric Bavier]

On Wed, 13 Jul 2016 08:55:23 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:

> Hi Daniel,
> 
> > I'd like GuixSD on ARM plataform, for instance Libre Tea Computer Card 
> > or other ARM libre plataform.
> >
> > I buy a Libre Tea Computer Card:
> > - https://www.crowdsupply.com/eoma68/micro-desktop
> > - http://retro-freedom.nz/blog/2016/06/30/eoma68-my-dream-machine/  
> 
> I’m also very excited about this project and wish it to succeed, because
> it is appalling and discouraging to see how little environmental
> concerns are usually considered in tech.
> 
> It would be very nice to be able to use GuixSD on the EOMA68.  Alas, I
> don’t have an overview on what work needs to be done to get there.

I've signed up for the Libre Tea and the desktop enclosure, so I'll be
playing with the GuixSD support in the coming days/weeks/months.  I'm
looking forward to working with other backers here.

It Would Be Nice™ if we could get something up and running before
shipment so we could propose a pre-imaged GuixSD version of the card.  :-)

`~Eric

Re: GuixSD on ARM

[Christopher Allan Webber]

Eric Bavier writes:

> On Wed, 13 Jul 2016 08:55:23 +0200
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> Hi Daniel,
>> 
>> > I'd like GuixSD on ARM plataform, for instance Libre Tea Computer Card 
>> > or other ARM libre plataform.
>> >
>> > I buy a Libre Tea Computer Card:
>> > - https://www.crowdsupply.com/eoma68/micro-desktop
>> > - http://retro-freedom.nz/blog/2016/06/30/eoma68-my-dream-machine/  
>> 
>> I’m also very excited about this project and wish it to succeed, because
>> it is appalling and discouraging to see how little environmental
>> concerns are usually considered in tech.
>> 
>> It would be very nice to be able to use GuixSD on the EOMA68.  Alas, I
>> don’t have an overview on what work needs to be done to get there.
>
> I've signed up for the Libre Tea and the desktop enclosure, so I'll be
> playing with the GuixSD support in the coming days/weeks/months.  I'm
> looking forward to working with other backers here.
>
> It Would Be Nice™ if we could get something up and running before
> shipment so we could propose a pre-imaged GuixSD version of the card.  :-)
>
> `~Eric

I've also signed up for a Libre Tea card.  I hope it works out, and also
hope we can get Guix support in.  That would rock!

Re: GuixSD on ARM

[Andreas Enge]

On Mon, Aug 15, 2016 at 03:14:14PM -0500, Christopher Allan Webber wrote:
> Eric Bavier writes:
> > I've signed up for the Libre Tea and the desktop enclosure, so I'll be
> > playing with the GuixSD support in the coming days/weeks/months.  I'm
> > looking forward to working with other backers here.
> I've also signed up for a Libre Tea card.  I hope it works out, and also
> hope we can get Guix support in.  That would rock!

So did I, and it did work out!

Do you think it would make sense if the Guix project asked for a prototype?
I suppose this is what other distributions have done that are confirmed
to run on the card? Once Danny's work has advanced and GuixSD works on
some other ARM board, it would be a good moment to ask.

Andreas