Re: GuixSD on arm (ng0)

[David Craven <david@craven.ch>]

Just chiming in here...

I know that github being propietary software probably won't be
considered, but it is unarguably an awesome piece of software,
possibly the best propietary software since google search :-) I think
that using github would improve the efficiency of submitting/reviewing
patches. But I'm still new to the sending patches via email thing - so
I might get used to it...

On Tue, Jul 5, 2016 at 2:35 PM,  <help-guix-request@gnu.org> wrote:
> Send Help-Guix mailing list submissions to
>         help-guix@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/help-guix
> or, via email, send a message with subject or body 'help' to
>         help-guix-request@gnu.org
>
> You can reach the person managing the list at
>         help-guix-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Help-Guix digest..."
>
>
> Today's Topics:
>
>    1. Re: Reproducible bootstrapping (Ludovic =?utf-8?Q?Court=C3=A8s?=)
>    2. Re: GuixSD on arm (Ludovic =?utf-8?Q?Court=C3=A8s?=)
>    3. Re: udev rules and system configuration
>       (Ludovic =?utf-8?Q?Court=C3=A8s?=)
>    4. Re: Reproducible bootstrapping (t3sserakt)
>    5. Re: GuixSD on arm (t3sserakt)
>    6. Re: GuixSD on arm (ng0)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 05 Jul 2016 10:11:12 +0200
> From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
> To: t3sserakt <t3sserakt@posteo.de>
> Cc: t3sserakt <t3ss@posteo.de>,  help-guix@gnu.org
> Subject: Re: Reproducible bootstrapping
> Message-ID: <878txg33of.fsf@gnu.org>
> Content-Type: text/plain; charset=utf-8
>
> t3sserakt <t3sserakt@posteo.de> skribis:
>
>> I was talking about reproducible builds like it is mentioned here:
>>
>> https://lwn.net/Articles/663954/
>
> Currently a large fraction (no exact figure yet) of the packages are
> bit-reproducible, but it?s not 100%.  For example, the .go files
> produced by Guile are not bit-reproducible yet, due to
> <http://bugs.gnu.org/20272>.
>
> I haven?t checked recently whether the packages involved in
> ?bootstrap-tarballs? are bit-reproducible.  It would be useful.
>
> However, note that the bootstrap binaries we currently use? were built
> in 2013 for the most part.  To rebuild them, you would need to do that
> from a Guix checkout of that time.
>
> I hope this answers your question.
>
> Ludo?.
>
> ? ftp://alpha.gnu.org:/gnu/guix/bootstrap
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 05 Jul 2016 10:23:07 +0200
> From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
> To: Jookia <166291@gmail.com>
> Cc: ng0 <ng0@we.make.ritual.n0.is>, help-guix@gnu.org,  t3sserakt
>         <t3sserakt@posteo.de>
> Subject: Re: GuixSD on arm
> Message-ID: <87furo1ok4.fsf@gnu.org>
> Content-Type: text/plain; charset=utf-8
>
> 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?.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 05 Jul 2016 10:34:37 +0200
> From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
> To: Ricardo Wurmus <rekado@elephly.net>
> Cc: Daniel Pimentel <d4n1@d4n1.org>,  help-guix@gnu.org
> Subject: Re: udev rules and system configuration
> Message-ID: <8737no1o0y.fsf@gnu.org>
> Content-Type: text/plain; charset=utf-8
>
> Hello!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Court?s <ludo@gnu.org> writes:
>>
>>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>
>>>> Here?s an idea, which might be bad: how about adding a feature to load
>>>> and merge a directory tree of configuration files as they are?  For
>>>> example, if I had a directory ?/etc/guix/system/udev/rules.d? then all
>>>> files therein would automatically be considered part of the system
>>>> configuration, maybe after adding ?/etc/guix/system? as a prefix path to
>>>> some new field in the ?operating-system? declaration.
>>>>
>>>> I have a feeling that this will be considered a bad idea, but it also
>>>> seems to me that it would make the configuration of some parts of the
>>>> system easier than embedding file contents as strings in variables in
>>>> ?/etc/config.scm? and modifying services manually.
>
> [...]
>
>> These files are not loaded at system runtime but upon running ?guix
>> system reconfigure?.  Their contents *at that time* would be embedded in
>> the configuration.  Their state *at runtime* would not matter (just like
>> the contents of ?config.scm? don?t matter at runtime).
>>
>> The files would become part of the configuration in the store.  Changing
>> them would always require the additional step of reconfiguring the
>> system.
>
> OK, I had misunderstood your suggestion.  It doesn?t have the drawbacks
> I mentioned.
>
> However, I don?t like the idea of having special directories that are
> automatically scanned.  In my mind, it?s a problem similar to ?macro
> hygiene?: we should not scan files whose name does not appear in
> config.scm.
>
>>> However, what we can do is improve the interface.  Things that come to
>>> mind:
>>>
>>>   1. Change or remove the ?udev-rule? procedure; we should be using
>>>      file-like objects instead, so one could store them alongside
>>>      config.scm and write:
>>>
>>>        (local-file "./my-udev-rule")
>>
>> Is this really so different from the bad idea I proposed?  As soon as we
>> load files outside of ?config.scm? users would need to copy more than
>> just the GuixSD config file to duplicate the system state on another
>> machine.  In this example we would need both ?config.scm? and
>> ?my-udev-rule? in the same directory.
>
> It?s similar to your idea, except that the file is explicitly named in
> the <operating-system> object.
>
> If that helps, we could also allow users to specify a directory
> containing several rules, instead of just a single rule:
>
>   (local-file "./my-udev-rule-directory")
>
>>>   2. Add a ?extra-udev-rule? procedure that you could use like this:
>>>
>>>        (operating-system
>>>          ;; ?
>>>          (services (extra-udev-rule (local-file "./my-udev-rule"))
>>>                    ?))
>>>
>>>      thus avoiding the verbose ?modify-services? stanza.
>>>
>>>   3. (Instead of #2) Introduce a ?udev-rules? field in
>>>      ?operating-system?, just like we do for firmware.
>>>
>>> WDYT?
>>
>> I don?t know.  Although this would simplify configuration I don?t really
>> like either of them for somewhat conflicting reasons.  #3 gives special
>> treatment to udev rules (?What about Xorg config snippets??), and with
>> #2 it seems like an unnecessary implementation detail that this
>> ?extra-udev-rule? procedure is inside of the ?services? field (?How come
>> this is a service??).
>>
>> I also feel that we should avoid adding ?special? syntax.  Actually, I
>> really like how generic this whole ?modify-services? business is.  It?s
>> just a little too verbose to be user-friendly, in my opinion.
>
> I sympathize with that.
>
> In fact, <operating-system> translates to a <service> graph.  The whole
> <operating-system> thing is just ?syntax.?
>
> I would like to have a more formal way to describe this translation.  I
> think this would allow us to fearlessly add or remove fields to
> <operating-system>.  But I don?t know how to achieve it.
>
> In the meantime, we should still address the usability issue that you
> raised, which is why I made these suggestions.
>
> Thoughts?
>
> Thank you,
> Ludo?.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 05 Jul 2016 10:35:51 +0200
> From: t3sserakt <t3ss@posteo.de>
> To: ludo@gnu.org
> Cc: help-guix@gnu.org
> Subject: Re: Reproducible bootstrapping
> Message-ID: <c1c3c5a8366af913a6ffa2fb83002956@posteo.de>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Am 05.07.2016 10:11 schrieb ludo@gnu.org:
>> t3sserakt <t3sserakt@posteo.de> skribis:
>>
>>> I was talking about reproducible builds like it is mentioned here:
>>>
>>> https://lwn.net/Articles/663954/
>>
>> Currently a large fraction (no exact figure yet) of the packages are
>> bit-reproducible, but it?s not 100%.  For example, the .go files
>> produced by Guile are not bit-reproducible yet, due to
>> <http://bugs.gnu.org/20272>.
>>
>> I haven?t checked recently whether the packages involved in
>> ?bootstrap-tarballs? are bit-reproducible.  It would be useful.
>>
>> However, note that the bootstrap binaries we currently use? were built
>> in 2013 for the most part.  To rebuild them, you would need to do that
>> from a Guix checkout of that time.
>>
>> I hope this answers your question.
>
> Yes. Thank you very much!
>
> t3sserakt
>
>>
>> Ludo?.
>>
>> ? ftp://alpha.gnu.org:/gnu/guix/bootstrap
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 5 Jul 2016 10:53:14 +0200
> From: t3sserakt <t3sserakt@posteo.de>
> To: Jookia <166291@gmail.com>, ng0 <ng0@we.make.ritual.n0.is>
> Cc: help-guix@gnu.org
> Subject: Re: GuixSD on arm
> Message-ID: <ec633903-7d16-05db-a3c3-08e764d95206@posteo.de>
> Content-Type: text/plain; charset=windows-1252
>
> 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
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 05 Jul 2016 12:08:32 +0000
> From: ng0 <ng0@we.make.ritual.n0.is>
> To: help-guix@gnu.org
> Cc: t3sserakt <t3sserakt@posteo.de>, Jookia <166291@gmail.com>
> Subject: Re: GuixSD on arm
> Message-ID: <8737noxp6n.fsf@we.make.ritual.n0.is>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Help-Guix mailing list
> Help-Guix@gnu.org
> https://lists.gnu.org/mailman/listinfo/help-guix
>
>
> ------------------------------
>
> End of Help-Guix Digest, Vol 8, Issue 8
> ***************************************