From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Craven Subject: Re: GuixSD on arm (ng0) Date: Tue, 5 Jul 2016 15:04:56 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKQ2F-0005n9-CD for help-guix@gnu.org; Tue, 05 Jul 2016 09:05:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bKQ27-0000A8-TC for help-guix@gnu.org; Tue, 05 Jul 2016 09:05:06 -0400 Received: from mail-yw0-x233.google.com ([2607:f8b0:4002:c05::233]:35615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bKQ26-00009N-Is for help-guix@gnu.org; Tue, 05 Jul 2016 09:04:59 -0400 Received: by mail-yw0-x233.google.com with SMTP id l125so60389519ywb.2 for ; Tue, 05 Jul 2016 06:04:57 -0700 (PDT) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix@gnu.org 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, 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 > Cc: t3sserakt , help-guix@gnu.org > Subject: Re: Reproducible bootstrapping > Message-ID: <878txg33of.fsf@gnu.org> > Content-Type: text/plain; charset=utf-8 > > t3sserakt 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 > . > > 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 , help-guix@gnu.org, t3sserakt > > 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 > Cc: Daniel Pimentel , 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 skribis: > >> Ludovic Court?s writes: >> >>> Ricardo Wurmus 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 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, translates to a graph. The whole > 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 > . 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 > To: ludo@gnu.org > Cc: help-guix@gnu.org > Subject: Re: Reproducible bootstrapping > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > Am 05.07.2016 10:11 schrieb ludo@gnu.org: >> t3sserakt 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 >> . >> >> 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 > To: Jookia <166291@gmail.com>, ng0 > Cc: help-guix@gnu.org > Subject: Re: GuixSD on arm > Message-ID: > 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 > To: help-guix@gnu.org > Cc: t3sserakt , 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 > ***************************************