unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* Re: GuixSD on arm (ng0)
@ 2016-07-05 13:04 David Craven
  2016-07-05 17:02 ` Leo Famulari
  0 siblings, 1 reply; 6+ messages in thread
From: David Craven @ 2016-07-05 13:04 UTC (permalink / raw)
  To: help-guix

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
> ***************************************

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GuixSD on arm (ng0)
@ 2016-07-05 14:03 David Craven
  0 siblings, 0 replies; 6+ messages in thread
From: David Craven @ 2016-07-05 14:03 UTC (permalink / raw)
  To: help-guix

I don't see guixsd as a linux distro but more as a linux distro
building kit. Sure there are default options for new users, but the
idea behind guix was to be like emacs right? So freedom and
hackability are the most important core values here, including the
freedom of choice of bootloader.

Also on a related issue. At some point we may want something like the
AUR for packages that don't comply with the guix packaging guidelines
(for example linux-firmware). Or that have few users. So if I want to
write my own bootloader and convince my friends to use it - it should
not be in the guix tree, but it would be nice if there were a way to
publish my package. This is something I missed in nixos.

Cheers
David

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
> ***************************************

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GuixSD on arm (ng0)
  2016-07-05 13:04 GuixSD on arm (ng0) David Craven
@ 2016-07-05 17:02 ` Leo Famulari
  2016-07-05 19:45   ` Alex Sassmannshausen
  2016-07-05 20:54   ` ng0
  0 siblings, 2 replies; 6+ messages in thread
From: Leo Famulari @ 2016-07-05 17:02 UTC (permalink / raw)
  To: David Craven; +Cc: help-guix

On Tue, Jul 05, 2016 at 03:04:56PM +0200, David Craven wrote:
> 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...

I would really prefer to not have to use a web page for contributing to
Guix. I find the tools `git send-email` and `git am` to be very easy to
use and much faster than a web site.

The really nice thing about email is that one can do it with a *very*
wide variety of tools and interfaces. Web pages, on the other hand,
basically have a single interface, and you have to be a web developer to
change it for yourself.

But, some people don't prefer email. Considering that, my opinion is
that the ideal situation would be a hybrid mail / web interface, where
the two components could be used interchangeably. Work done on one
interface would automatically show up in the other interface. Does this
exist?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GuixSD on arm (ng0)
  2016-07-05 17:02 ` Leo Famulari
@ 2016-07-05 19:45   ` Alex Sassmannshausen
  2016-07-05 22:54     ` David Craven
  2016-07-05 20:54   ` ng0
  1 sibling, 1 reply; 6+ messages in thread
From: Alex Sassmannshausen @ 2016-07-05 19:45 UTC (permalink / raw)
  To: Leo Famulari; +Cc: David Craven, help-guix

Hello,

Leo Famulari writes:

> On Tue, Jul 05, 2016 at 03:04:56PM +0200, David Craven wrote:
>> 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...
>
> I would really prefer to not have to use a web page for contributing to
> Guix. I find the tools `git send-email` and `git am` to be very easy to
> use and much faster than a web site.

Just to throw this in the mix: I contribute to a project called Koha,
which uses Bugzilla as it's tracker.  I know previously this has come up
and I think there are a number of people who don't like it — the reason
I bring it up now, is because there is an extension for git called
git-bz, which basically provides commandline access to bugzilla — at
least for patch management (and I think commenting… though not 100%
sure).

You can apply patches, including entire series attached to specific bugs
to a codebase, upload new patches (including 'obsoleting' previous
versions).

Though I guess you'd still have to perform 'read' operations through the
browser.

I don't have a horse in this race, just throwing in 2¢… :-)

Happy hacking,

Alex

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GuixSD on arm (ng0)
  2016-07-05 17:02 ` Leo Famulari
  2016-07-05 19:45   ` Alex Sassmannshausen
@ 2016-07-05 20:54   ` ng0
  1 sibling, 0 replies; 6+ messages in thread
From: ng0 @ 2016-07-05 20:54 UTC (permalink / raw)
  To: help-guix

Leo Famulari writes:

> On Tue, Jul 05, 2016 at 03:04:56PM +0200, David Craven wrote:
>> 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...
>
> I would really prefer to not have to use a web page for contributing to
> Guix. I find the tools `git send-email` and `git am` to be very easy to
> use and much faster than a web site.
>
> The really nice thing about email is that one can do it with a *very*
> wide variety of tools and interfaces. Web pages, on the other hand,
> basically have a single interface, and you have to be a web developer to
> change it for yourself.
>
> But, some people don't prefer email. Considering that, my opinion is
> that the ideal situation would be a hybrid mail / web interface, where
> the two components could be used interchangeably. Work done on one
> interface would automatically show up in the other interface. Does this
> exist?
>

Sorry, I did not imply that people I talked to meant github or
other free/proprietary solutions similar to it.
So far I provide outside of freenode.net and outside of Email
federation help and support to a small number of people at
psyced.org (and also offer to proxy works via myself for people
who can not deal with the ways you can participate in Guix).

What I really mean will only be clear once I write a thought out
text about it. I currently can not focus on this and don't want
to participate in a half hearted discussion based on
assumptions/interpretations.
An Email vs Github discussion is not even close to what my
intentions are.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: GuixSD on arm (ng0)
  2016-07-05 19:45   ` Alex Sassmannshausen
@ 2016-07-05 22:54     ` David Craven
  0 siblings, 0 replies; 6+ messages in thread
From: David Craven @ 2016-07-05 22:54 UTC (permalink / raw)
  To: alex.sassmannshausen; +Cc: help-guix

Many projects use email for patch submission, so for me it's just
another useful skill to learn. I assumed that sending the patches via
email was the easy part. So whatever works best for you guys... ;-)

On Tue, Jul 5, 2016 at 9:45 PM, Alex Sassmannshausen
<alex.sassmannshausen@gmail.com> wrote:
> Hello,
>
> Leo Famulari writes:
>
>> On Tue, Jul 05, 2016 at 03:04:56PM +0200, David Craven wrote:
>>> 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...
>>
>> I would really prefer to not have to use a web page for contributing to
>> Guix. I find the tools `git send-email` and `git am` to be very easy to
>> use and much faster than a web site.
>
> Just to throw this in the mix: I contribute to a project called Koha,
> which uses Bugzilla as it's tracker.  I know previously this has come up
> and I think there are a number of people who don't like it — the reason
> I bring it up now, is because there is an extension for git called
> git-bz, which basically provides commandline access to bugzilla — at
> least for patch management (and I think commenting… though not 100%
> sure).
>
> You can apply patches, including entire series attached to specific bugs
> to a codebase, upload new patches (including 'obsoleting' previous
> versions).
>
> Though I guess you'd still have to perform 'read' operations through the
> browser.
>
> I don't have a horse in this race, just throwing in 2¢… :-)
>
> Happy hacking,
>
> Alex

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2016-07-05 22:54 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-07-05 13:04 GuixSD on arm (ng0) David Craven
2016-07-05 17:02 ` Leo Famulari
2016-07-05 19:45   ` Alex Sassmannshausen
2016-07-05 22:54     ` David Craven
2016-07-05 20:54   ` ng0
  -- strict thread matches above, loose matches on Subject: below --
2016-07-05 14:03 David Craven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).