Re: [GSOC 2020] Idea: Guile based build-tool

[Christopher Lemmer Webber]

There have been some conversations about using Guix's tooling as a build
tool in the past.

Personally, what I would prefer to see is a Guile-based build tool that
is standalone; an alternative for autotools basically.  That then could
be used *in combination with* Guix quite nicely... use the Guile-based
build tool for describing how to build your packages, use "guix
environment" to pull in all the dependencies and create the dev
environment, and of course this tool would then be used for package
definitions too.

However I think this is not a small task, and would take someone who is
willing to do a fair amount of research, or is already familiar with the
problem domain.  It may be hard to finish in a single summer.


Leandro Doctors writes:

> Hi, all,
>
> I am starting to do some research on this idea.
>
> Even though I haven't checked Guix's code yet (I plan to flickr it in
> the upcoming days), I am thinking on getting some inspiration from the
> architecture of similar Clojure-focused tools (which, as I stated
> earlier, is what I know).
>
> I know about three such tools: leiningen[1], boot[2], and clojure.deps[3].
>
> I plan to flickr over their code, and see what architectural decitions
> could be proposed.
> What do you think about this?
>
> Best,
> Leandro
>
> [1] leiningen: https://github.com/technomancy/leiningen
> [2] boot: https://github.com/boot-clj/boot
> [3] clojure.deps: https://github.com/clojure/tools.deps.alpha

[GSOC 2020] Guix Deploy, round 2!

[Christopher Lemmer Webber]

Hello,

I'd be interested in doing a round 2 of mentoring for Guix Deploy.
The previous student (Jakob L. Kreuze) will not be a GSoC student this
year but is willing to co-mentor.  (Maybe David Thompson is as well but
I won't speak for him since we haven't discussed it yet.)

I don't know what the situation with Outreachy slots are, but I'd also
be happy to mentor this for there as well, obviously.

I think there's probably more that can be done to improve environments.
This includes initial bootstrapping of environments, making more
environments available, etc.

Let me also put out a goal for the Guix community: I think we'll see
Guix Deploy as a success if a bunch of us can switch over to using it on
our own servers (that includes me).  To that end, I'd love to know, how
many people are doing so, or have attempted to do so?  What features
would you like/need?

 - Chris

Re: Hyperlinks!

[Christopher Lemmer Webber]

This is very nice.  The rainbow parenthesis matching is really excellent
too.

Guix has managed to make Texinfo html export look really nice!  I admit
I expressed skepticism in this endeavour a number of years back and am
happy to be incorrect.


Ludovic Courtès writes:

> Hello Guix!
>
> Scheme code snippets in the on-line manual now have hyperlinks for all
> the symbols documented in the manual:
>
>   
> https://guix.gnu.org/manual/devel/en/html_node/Using-the-Configuration-System.html
>   https://guix.gnu.org/manual/devel/en/html_node/Defining-Packages.html
>
> Hyperlinks are such an amazing invention!
>
> (If anyone knows how to get ‘a.syntax-symbol’ CSS different from just
> ‘a’, I’m all ears!)
>
> This is happening in ‘doc/build.scm’ as a post-processing step on the
> makeinfo-generated HTML (along with the syntax-highlighting
> post-processing step).  It works well but there can be false positives
> because it matches on identifiers, without taking scope etc. into
> account—e.g., anytime “service” appears, it’ll link to the ‘service’
> procedure.
>
> I’d like to extend it to include references to the Guile manual, so that
> one could click on, say, ‘append’, but there might be too many false
> positives at that point.  And then we would need DrRacket fanciness to
> be able to determine what an identifier really refers to…
>
> Feedback welcome!
>
> Ludo’.

Re: Medium-term road map

[Christopher Lemmer Webber]

Andy Wingo writes:

> On Sat 25 Apr 2020 15:37, Ludovic Courtès  writes:
>
>>   2. Performance.  There are many things we can improve there, first and
>>  foremost: the “Computing derivation” part of ‘guix pull’, Guile’s
>>  compiler terrible time and space requirements
>
> I think I have a solution here, as discussed on IRC.  Basic idea is to
> make a direct compiler from Tree-IL to bytecode, skipping the CPS step.
> The result won't be optimal in terms of generated code quality (I
> estimate on average 2x slowdown) but it will be very cheap to produce (I
> estimate 10x improvement in time, and going from O(n log n) space to
> O(n), with better constant factors.  We'd use this compiler for -O0 or
> maybe even -O1 code.
>
> Got to spend a few days working it up tho!
>
> Andy

That sound like a nice path to an improvement!

Re: GNU Guix maintainer collective update

[Christopher Lemmer Webber]

Jack Hill writes:

> On Mon, 4 May 2020, sirgazil wrote:
>
>>  On Mon, 04 May 2020 13:31:46 + Maxim Cournoyer 
>>  wrote 
>> > Let's take a moment to thank Ricardo for his time as a Guix
>> > co-maintainer.  He's been immensely useful to the project and I hope
>> > we'll continue to see him around.
>>
>>
>> Hey, Wurmus, thanks a million. I really appreciate your help and the work 
>> you have done.
>
> Indeed, thanks Ricardo. Guix is great technology, but what I
> particularly love about it is the great community of people thanks to
> your kind leadership. Hope to see you around and best wishes!

Absolutely sharing the same.  Guix has always been one of the warmest
and friendliest communities in my experience of FOSS, and Ricardo has
consistently been a stand-up role model in that regard.

>> > Let's also welcome Mathieu Othacehe in his new role!  Congratulations,
>> > Mathieu!  :-)
>>
>> Great! Welcome, Mathieu :)
>
> Huzzah! Welcome!

Yes!

Re: Towards a graphical installer?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Nice!
>
> I'm planning to work on a probably-GTK graphical installer as part of
> the NLNet grant I've received in the coming month.  Let's keep in touch!
>
> Let's get started with a simple question: guile-gi or g-golf?

This is awesome!

Re: Towards a graphical installer?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Errr... Sorry, I was distracted yesterday, the NLNet grant is actually
> for a graphical _package manager_, not an installer! :p
>
> That said, I'm interested in helping with it too! :)

Still awesome :)

I'm looking forward to seeing your work evolve! :)

 - Chris

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

[moving from help-guix to guix-devel]

On help-guix this exchange occured when discussing trying to install
Vanilla Firefox... two things struck me:

 - Firefox's source code is itself free, but it doesn't follow the FSDG
   (An assertion was made that Firefox was itself nonfree software,
   but this seems like an inaccurate characterization.  I agree it
   doesn't follow the FSDG, however.)
 - It is probably possible, with minimal changes, to resolve that.

So this page explains the problem:

  
https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines

"Problem: Recommends non-free addons and plugins; automatically downloads 
cisco's binary h.264 codecs"

I agree the latter is a problem.  The former is kind of maybe a problem,
but mostly because it isn't clear that it's happening to the user.

However, I wonder if, with a matter of just two patches, this could be
resolved:

 - Patch out the automatic download of Cisco's h.264 plugin.
 - Add a warning banner *above* the extensions page, or simply switch it
   to the same one that Icecat already uses.

Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
It strikes me that with those two changes, the criteria would be met.

(Yes, I know that IceCat also provides LibreJS and some other plugins,
and that's nice to have, but Guix already ships several other browsers
that do not have those plugins, so this does not seem to be a strict
impediment and I don't think it should be either.  We could change the
default Firefox homepage to point at one that recommends installing some
of these plugins, if that would be helpful.)

 - Chris


Christopher Lemmer Webber writes:

> I'm not sure it's really accurate to categorize asking for a vanilla
> copy of firefox, which might not comply with the FSDG, as nonfree
> software.  The primary issue with Firefox that makes it qualify as
> "nonfree" is that the add-ons tool brings you to something that might
> guide a user towards nonfree software right?  Thus I think this isn't
> exactly correct framing, since firefox itself isn't nonfree?  There is a
> difference if I, as a user, install Firefox as free software, and I am
> aware of the issue with the default extensions kit, and end up
> installing no nonfree software on my computer, right?
>
> Am I missing something?  What makes Firefox itself nonfree (which I
> think is not quite the same thing as not compliant with the FSDG)?
>
>
> Adonay Felipe Nogueira via writes:
>
>> I came late to this issue, but I think this should have been posted on
>> development mailing list. It's not good if we use the general help list
>> to foster non-free software like Firefox or those which are third-party
>> package managers with no default repository explicitly commited to
>> following the GNU FSDG.
>>
>> Furthermore, to ease the sides of both the thread starter and the
>> community, I'm taking a simplification in that I'm considering the use
>> of such non-free software for purpose of developing or improving a free
>> replacement. That means I'm not discussing the merit of whether the
>> question should or shouldn't have been answered the way it was.
>>
>> One must be remind though, that the GNU FSDG isn't only about the
>> packages distributed (software, documentation, text fonts, etc), but
>> also about the community, and this is one of the things that keep Debian
>> out of the list of free system distributions.
>>
>> Em 12/05/2020 16:23, Efraim Flashner escreveu:
>>> On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:
>>>>
>>>> Christopher Lemmer Webber  skribis:
>>>>
>>>>> Anyone have a package definition (or channel) for a recent vanilla
>>>>> firefox?
>>>>>
>>>>> I understand the decision to prefer distributing Icecat instead in Guix
>>>>> proper, but I need a more recent version of things... I suspect others
>>>>> sometimes do too.  I have a feeling at least someone in the community
>>>>> has written such a definition... would you mind sharing?
>>>>>
>>>>> Thanks!
>>>>>  - Chris
>>>>
>>>> Hi,
>>>>
>>>> There is a channel at
>>>> https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
>>>> definition for Firefox 74.0.1. I haven't tested it though.
>>>
>>> Other options include using the now official flatpak copy of firefox. If
>>> you do go that route make sure to use the '--user' flag for flatpak so
>>> it doesn't segfault while trying to write to /var/lib/flatpak.
>>>

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

(An obvious win from this also being that we will be able to have more
Guix users running, on average, a more up-to-date on security browser
more often.)

Christopher Lemmer Webber writes:

> [moving from help-guix to guix-devel]
>
> On help-guix this exchange occured when discussing trying to install
> Vanilla Firefox... two things struck me:
>
>  - Firefox's source code is itself free, but it doesn't follow the FSDG
>(An assertion was made that Firefox was itself nonfree software,
>but this seems like an inaccurate characterization.  I agree it
>doesn't follow the FSDG, however.)
>  - It is probably possible, with minimal changes, to resolve that.
>
> So this page explains the problem:
>
>   
> https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines
>
> "Problem: Recommends non-free addons and plugins; automatically downloads 
> cisco's binary h.264 codecs"
>
> I agree the latter is a problem.  The former is kind of maybe a problem,
> but mostly because it isn't clear that it's happening to the user.
>
> However, I wonder if, with a matter of just two patches, this could be
> resolved:
>
>  - Patch out the automatic download of Cisco's h.264 plugin.
>  - Add a warning banner *above* the extensions page, or simply switch it
>to the same one that Icecat already uses.
>
> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
> It strikes me that with those two changes, the criteria would be met.
>
> (Yes, I know that IceCat also provides LibreJS and some other plugins,
> and that's nice to have, but Guix already ships several other browsers
> that do not have those plugins, so this does not seem to be a strict
> impediment and I don't think it should be either.  We could change the
> default Firefox homepage to point at one that recommends installing some
> of these plugins, if that would be helpful.)
>
>  - Chris
>
>
> Christopher Lemmer Webber writes:
>
>> I'm not sure it's really accurate to categorize asking for a vanilla
>> copy of firefox, which might not comply with the FSDG, as nonfree
>> software.  The primary issue with Firefox that makes it qualify as
>> "nonfree" is that the add-ons tool brings you to something that might
>> guide a user towards nonfree software right?  Thus I think this isn't
>> exactly correct framing, since firefox itself isn't nonfree?  There is a
>> difference if I, as a user, install Firefox as free software, and I am
>> aware of the issue with the default extensions kit, and end up
>> installing no nonfree software on my computer, right?
>>
>> Am I missing something?  What makes Firefox itself nonfree (which I
>> think is not quite the same thing as not compliant with the FSDG)?
>>
>>
>> Adonay Felipe Nogueira via writes:
>>
>>> I came late to this issue, but I think this should have been posted on
>>> development mailing list. It's not good if we use the general help list
>>> to foster non-free software like Firefox or those which are third-party
>>> package managers with no default repository explicitly commited to
>>> following the GNU FSDG.
>>>
>>> Furthermore, to ease the sides of both the thread starter and the
>>> community, I'm taking a simplification in that I'm considering the use
>>> of such non-free software for purpose of developing or improving a free
>>> replacement. That means I'm not discussing the merit of whether the
>>> question should or shouldn't have been answered the way it was.
>>>
>>> One must be remind though, that the GNU FSDG isn't only about the
>>> packages distributed (software, documentation, text fonts, etc), but
>>> also about the community, and this is one of the things that keep Debian
>>> out of the list of free system distributions.
>>>
>>> Em 12/05/2020 16:23, Efraim Flashner escreveu:
>>>> On Mon, May 11, 2020 at 10:31:02PM +0200, Guillaume Le Vaillant wrote:
>>>>>
>>>>> Christopher Lemmer Webber  skribis:
>>>>>
>>>>>> Anyone have a package definition (or channel) for a recent vanilla
>>>>>> firefox?
>>>>>>
>>>>>> I understand the decision to prefer distributing Icecat instead in Guix
>>>>>> proper, but I need a more recent version of things... I suspect others
>>>>>> sometimes do too.  I have a feeling at least someone in the community
>>>>>> has written such a definition... would you mind sharing?
>>>>>>
>>>>>> Thanks!
>>>>>>  - Chris
>>>>>
>>>>> Hi,
>>>>>
>>>>> There is a channel at
>>>>> https://forge.monarch-pass.net/warrah/warrah-nonfsdg with a package
>>>>> definition for Firefox 74.0.1. I haven't tested it though.
>>>>
>>>> Other options include using the now official flatpak copy of firefox. If
>>>> you do go that route make sure to use the '--user' flag for flatpak so
>>>> it doesn't segfault while trying to write to /var/lib/flatpak.
>>>>

Re: Vanilla Firefox recipe?

[Christopher Lemmer Webber]

Carlo Zancanaro writes:

> Hey Chris,
>
> On Wed, May 27 2020, Christopher Lemmer Webber wrote:
>> However, I wonder if, with a matter of just two patches, this could be
>> resolved:
>>
>>  - Patch out the automatic download of Cisco's h.264 plugin.
>>  - Add a warning banner *above* the extensions page, or simply switch it
>>to the same one that Icecat already uses.
>>
>> Is that all that's necessary, then, to get "vanilla Firefox" in Guix?
>> It strikes me that with those two changes, the criteria would be met.
>
> We would need to watch out for Mozilla's requirements to use the
> "Firefox" trademark[1]. Of particular note is the section titled
> "Modified Versions Require Prior Written Permission":
>
>   The open source nature of Firefox and other Mozilla software allows
>   you to freely download and modify the source code. However, if you
>   make any changes to Firefox or other Mozilla software, you may not
>   redistribute that product using any Mozilla trademark without
>   Mozilla’s prior written consent and, typically, a distribution
>   agreement with Mozilla. For example, you may not distribute a
>   modified form of Firefox and continue to call it Firefox.
>
>   Changes requiring Mozilla’s prior written permission include (but are not 
> limited to):
>- Changing the default home page or adding bookmarks,
>- Adding, modifying, or deleting source files,
>- Adding, modifying, or deleting content from installer files,
>- File location changes,
>- Adding extensions, add-ons or plugins, or
>- Installing themes other than those available in the most recent
>  stable version of Firefox available at Mozilla.org.
>
>   If you wish to distribute a modified version of Firefox or other
>   Mozilla software with Mozilla trademarks please contact us with your
>   request at trademark-permissi...@mozilla.com.
>
> Carlo
>
> [1]: https://www.mozilla.org/en-US/foundation/trademarks/distribution-policy/

I agree this is a concern and is in the list of things to address.

I forget, but I remember reading somewhere that Firefox's codebase does
ship in such a way where rebranding it isn't as hard as it used to be,
or that the development version already did have some of this branding
stripped out.  

Am I misremembering?
 - Chris

Installing packages auto-container'ed

[Christopher Lemmer Webber]

Would it be possible to make launching applications in Guix with minimum
permissions even easier?  Here's just a sketch of an idea.

Borrowing from the new containerizing an application example in the
manual...

In my manifest.scm, what if instead of listing the browser package
eolie, I listed the following:

  (define containerized-eolie
(wrap-containerized eolie
#:network? #t
;; Not sure if this line would be needed.
#:other-packages (list coreutils nss-certs dbus)
#:expose '("/etc/machine-id")
#:share '(("/home/cwebber/tmp/shared-with-browser"
   . "/home/cwebber/shared"))
#:share-env '("DISPLAY")))

  ;; now here's my list of packages
  (list emacs
containerized-eolie
...)

The idea here is that containerized-eolie actually generates a new
package that "wraps" every binary that would be installed, as well as
all common launchers, to use a script that actually launches them in a
container with the above restrictions.
  
I'm not sure how feasible or easy this is, but it seems like a good
idea.

If the process of containerizing something tricky like icecat is fairly
common, we could abstract that into a procedure, like
(make-containerized-icecat ...) or something.

Thoughts?

 - Chris

Re: Racket packages: formerly Move DrRacket to a separate output?

[Christopher Lemmer Webber]

Dimakakos Dimos writes:

> Pierre Neidhardt writes:
>
>> I've (finally) pushed racket-minimal.
>> Hooray!
>>
>> Now to the Racket importer... Anyone?
>> Dimakakos? :)
>
> Nice! It will be very useful. I've put some research into a build system
> for racket, and sadly it isn't trivial to match the racket package
> system to guix.
>
> There is a lot of state handling in racket specific files, since every
> package is indexed by linking the specific folder of a package. Right
> now I'm creating these files ad-hoc but it doens't seem the best
> approach, since racket is really slow searching for the dependencies in
> many folders. At the same time, racket tries sometims to rebuild
> packages that are passed as inputs. There are also circular dependencies
> and other stuff that need to be ironed out.
>
> I'm also talking with the creator of racket2nix, a similar project for
> nix and he had the same problems, so we discussed about working for a
> solution for both package managers.
>
> So in conclusion, I don't have a specific roadmap, but I'm still working
> on it.

Would you mind sharing what you have so far?  Even just a complete
braindump of notes or WIP code could be helpful to move this along!

I've started reading some for the docs over at:

  https://docs.racket-lang.org/pkg/index.html

I'm getting an idea of some things but it would be useful to hear what
you and Claes have explored so far!

Pushed a fix (?) for ACL key location

[Christopher Lemmer Webber]

Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
of Guix, and it looks like it wasn't possible to build new systems from
that because the filename for the "Berlin ACL key" changed.  (Or at
least, I couldn't run "guix system vm".)

I pushed out a "fix" for this.  I hope it's ok.

I'm presuming this was expected to change given
ec4c404c0575b340a04b3922fb828ac5417832dd appearing to try to compensate
in the other direction *before* the new "guix" package version was
pushed.

If I made things worse, sorry in advance.  It fixes things here, but I
don't know the full context of what was going on.

 - Chris

Re: Setuid programs

[Christopher Lemmer Webber]

Maxim Cournoyer writes:

> Hello Gabor!
>
> Gábor Boskovits  writes:
>
>> Hello guix,
>>
>> I would like to propose an extension to how setuid programs are
>> currently handled. The last time I checked it could only do setuid and
>> setgid root. Some services, such as postfix need a more fine grained
>> setuid setup. I would propose a record type, such as:
>> (setuid
>> (program setuid-program)
>> (setuid setuid-setuid)
>> (setgid setuid-setgid)
>> (user setuid-user)
>> (group setuid-group))
>>
>> So that there is more fine grained control.
>>
>> I would also propose to move this to the services framework, so that
>> services could extend this field on demand.
>>
>> Wdyt?
>
> This sounds great!  I also encountered such limitation and tried to
> fixing it in https://issues.guix.info/41763, with some success (and an
> unresolved limitation pointed by Chriistopher) but I agree that using a
> record makes more sense and is more future proof.
>
> Maxim

I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
sense of the weird DSL that opensmtpd uses) so I guess if that's what's
necessary it already makes it a good idea.

However I don't fully understand the syntax of what you proposed.  Let's
see if I can guess with a fake entry

#~(setuid
   ;; The program to run, from the shady package
   (program (string-append #$shady "/bin/scaryfoo")
   ;; Would this be a boolean?  If so should it be `setuid?`
   (setuid setuid-setuid)
   ;; Likewise?
   (setgid setuid-setgid)
   ;; Presumably the use we want to set this to
   (user setuid-user)
   ;; Presumably the group we want to se this to
   (group setuid-group))

... right?

I guess this could be done in a backwards compatible way;
%setuid-programs could either evaluate to strings or records, so the
"simpler" version can remain an option?

 - Chris

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Christopher Lemmer Webber  ezt írta (időpont:
> 2020. szept. 9., Sze, 21:00):
>>
>> Maxim Cournoyer writes:
>>
>> > Hello Gabor!
>> >
>> > Gábor Boskovits  writes:
>> >
>> >> Hello guix,
>> >>
>> >> I would like to propose an extension to how setuid programs are
>> >> currently handled. The last time I checked it could only do setuid and
>> >> setgid root. Some services, such as postfix need a more fine grained
>> >> setuid setup. I would propose a record type, such as:
>> >> (setuid
>> >> (program setuid-program)
>> >> (setuid setuid-setuid)
>> >> (setgid setuid-setgid)
>> >> (user setuid-user)
>> >> (group setuid-group))
>> >>
>> >> So that there is more fine grained control.
>> >>
>> >> I would also propose to move this to the services framework, so that
>> >> services could extend this field on demand.
>> >>
>> >> Wdyt?
>> >
>> > This sounds great!  I also encountered such limitation and tried to
>> > fixing it in https://issues.guix.info/41763, with some success (and an
>> > unresolved limitation pointed by Chriistopher) but I agree that using a
>> > record makes more sense and is more future proof.
>> >
>> > Maxim
>>
>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
>> necessary it already makes it a good idea.
>>
>> However I don't fully understand the syntax of what you proposed.  Let's
>> see if I can guess with a fake entry
>>
>> #~(setuid
>>;; The program to run, from the shady package
>>(program (string-append #$shady "/bin/scaryfoo")
>>;; Would this be a boolean?  If so should it be `setuid?`
> yes, this should be a bool, studi? looks good to me.
>>(setuid setuid-setuid)
>>;; Likewise?
>>(setgid setuid-setgid)
> yes, the same thing applies here.
>>;; Presumably the use we want to set this to
>>(user setuid-user)
> yes, this should just be the uid of the owner
>>;; Presumably the group we want to se this to
> this should be the gid.
>>(group setuid-group))
>>
>> ... right?
>>
>> I guess this could be done in a backwards compatible way;
>> %setuid-programs could either evaluate to strings or records, so the
>> "simpler" version can remain an option?
> Yes, it can be done this way. Actually I had a bit more general
> solution in mind,
> I feel there should be service to install a file from a store to a
> given place, and with all the access control available,
> like acl-s, if supported. And then provide the whole setuid thing as a
> backwards compatibility layer, somehow like you described.
> For now I guess creating this record type and implementing the
> extended setuid functionality would be a good first step.

A service seems like a really good idea to me in that it feels the most
composable with how Guix currently approaches things.

Re: Setuid programs

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Gábor Boskovits writes:
>
>> Hello,
>>
>> Christopher Lemmer Webber  ezt írta (időpont:
>> 2020. szept. 9., Sze, 21:00):
>>>
>>> Maxim Cournoyer writes:
>>>
>>> > Hello Gabor!
>>> >
>>> > Gábor Boskovits  writes:
>>> >
>>> >> Hello guix,
>>> >>
>>> >> I would like to propose an extension to how setuid programs are
>>> >> currently handled. The last time I checked it could only do setuid and
>>> >> setgid root. Some services, such as postfix need a more fine grained
>>> >> setuid setup. I would propose a record type, such as:
>>> >> (setuid
>>> >> (program setuid-program)
>>> >> (setuid setuid-setuid)
>>> >> (setgid setuid-setgid)
>>> >> (user setuid-user)
>>> >> (group setuid-group))
>>> >>
>>> >> So that there is more fine grained control.
>>> >>
>>> >> I would also propose to move this to the services framework, so that
>>> >> services could extend this field on demand.
>>> >>
>>> >> Wdyt?
>>> >
>>> > This sounds great!  I also encountered such limitation and tried to
>>> > fixing it in https://issues.guix.info/41763, with some success (and an
>>> > unresolved limitation pointed by Chriistopher) but I agree that using a
>>> > record makes more sense and is more future proof.
>>> >
>>> > Maxim
>>>
>>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
>>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
>>> necessary it already makes it a good idea.
>>>
>>> However I don't fully understand the syntax of what you proposed.  Let's
>>> see if I can guess with a fake entry
>>>
>>> #~(setuid
>>>;; The program to run, from the shady package
>>>(program (string-append #$shady "/bin/scaryfoo")
>>>;; Would this be a boolean?  If so should it be `setuid?`
>> yes, this should be a bool, studi? looks good to me.
>>>(setuid setuid-setuid)
>>>;; Likewise?
>>>(setgid setuid-setgid)
>> yes, the same thing applies here.
>>>;; Presumably the use we want to set this to
>>>(user setuid-user)
>> yes, this should just be the uid of the owner
>>>;; Presumably the group we want to se this to
>> this should be the gid.
>>>(group setuid-group))
>>>
>>> ... right?
>>>
>>> I guess this could be done in a backwards compatible way;
>>> %setuid-programs could either evaluate to strings or records, so the
>>> "simpler" version can remain an option?
>> Yes, it can be done this way. Actually I had a bit more general
>> solution in mind,
>> I feel there should be service to install a file from a store to a
>> given place, and with all the access control available,
>> like acl-s, if supported. And then provide the whole setuid thing as a
>> backwards compatibility layer, somehow like you described.
>> For now I guess creating this record type and implementing the
>> extended setuid functionality would be a good first step.
>
> A service seems like a really good idea to me in that it feels the most
> composable with how Guix currently approaches things.

I feel like this one needs more "Guix maintainer" overview.  The current
setuid-programs could be kept as legacy behavior that installs an
additional service.  Thoughts?

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Christopher Lemmer Webber  ezt írta (időpont:
> 2020. szept. 10., Cs, 0:52):
>>
>> Christopher Lemmer Webber writes:
>>
>> > Gábor Boskovits writes:
>> >
>> >> Hello,
>> >>
>> >> Christopher Lemmer Webber  ezt írta (időpont:
>> >> 2020. szept. 9., Sze, 21:00):
>> >>>
>> >>> Maxim Cournoyer writes:
>> >>>
>> >>> > Hello Gabor!
>> >>> >
>> >>> > Gábor Boskovits  writes:
>> >>> >
>> >>> >> Hello guix,
>> >>> >>
>> >>> >> I would like to propose an extension to how setuid programs are
>> >>> >> currently handled. The last time I checked it could only do setuid and
>> >>> >> setgid root. Some services, such as postfix need a more fine grained
>> >>> >> setuid setup. I would propose a record type, such as:
>> >>> >> (setuid
>> >>> >> (program setuid-program)
>> >>> >> (setuid setuid-setuid)
>> >>> >> (setgid setuid-setgid)
>> >>> >> (user setuid-user)
>> >>> >> (group setuid-group))
>> >>> >>
>> >>> >> So that there is more fine grained control.
>> >>> >>
>> >>> >> I would also propose to move this to the services framework, so that
>> >>> >> services could extend this field on demand.
>> >>> >>
>> >>> >> Wdyt?
>> >>> >
>> >>> > This sounds great!  I also encountered such limitation and tried to
>> >>> > fixing it in https://issues.guix.info/41763, with some success (and an
>> >>> > unresolved limitation pointed by Chriistopher) but I agree that using a
>> >>> > record makes more sense and is more future proof.
>> >>> >
>> >>> > Maxim
>> >>>
>> >>> I'm eager to use Postfix on Guix (maybe it's me, but I just can't make
>> >>> sense of the weird DSL that opensmtpd uses) so I guess if that's what's
>> >>> necessary it already makes it a good idea.
>> >>>
>> >>> However I don't fully understand the syntax of what you proposed.  Let's
>> >>> see if I can guess with a fake entry
>> >>>
>> >>> #~(setuid
>> >>>;; The program to run, from the shady package
>> >>>(program (string-append #$shady "/bin/scaryfoo")
>> >>>;; Would this be a boolean?  If so should it be `setuid?`
>> >> yes, this should be a bool, studi? looks good to me.
>> >>>(setuid setuid-setuid)
>> >>>;; Likewise?
>> >>>(setgid setuid-setgid)
>> >> yes, the same thing applies here.
>> >>>;; Presumably the use we want to set this to
>> >>>(user setuid-user)
>> >> yes, this should just be the uid of the owner
>> >>>;; Presumably the group we want to se this to
>> >> this should be the gid.
>> >>>(group setuid-group))
>> >>>
>> >>> ... right?
>> >>>
>> >>> I guess this could be done in a backwards compatible way;
>> >>> %setuid-programs could either evaluate to strings or records, so the
>> >>> "simpler" version can remain an option?
>> >> Yes, it can be done this way. Actually I had a bit more general
>> >> solution in mind,
>> >> I feel there should be service to install a file from a store to a
>> >> given place, and with all the access control available,
>> >> like acl-s, if supported. And then provide the whole setuid thing as a
>> >> backwards compatibility layer, somehow like you described.
>> >> For now I guess creating this record type and implementing the
>> >> extended setuid functionality would be a good first step.
>> >
>> > A service seems like a really good idea to me in that it feels the most
>> > composable with how Guix currently approaches things.
>>
>> I feel like this one needs more "Guix maintainer" overview.
> I agree, this would be nice.
>
>   The current
>> setuid-programs could be kept as legacy behavior that installs an
>> additional service.  Thoughts?
>
> I believe it should be kept and install an additional service.
>
> I have two reasons for that: backwards compatibility is really
> important, so we should not break it, and I believe this would not be
> hard to do.
> On the other hand it would be nice to have a more integrated backend,
> and move as many things into the services infrastructure as practical,
> and I think this is a good candidate for that. Wdyt?
>
> Best regards,
> g_bor

That's fine by me.  I don't feel like I'm the right one to make the call though!

Racket will move on top of Chez soon

[Christopher Lemmer Webber]

Just a heads up that right now you *can* run Racket-on-Chez, but soon
Racket-on-Chez will be the "default"... maybe it's a good idea to see
how hard it will be to make a racket-on-chez package variant.

I'm interested in looking at that but it'll probably have to be a while
before I can do so... if someone does so before me, I'll be interested
in beta testing at least.

But also leaving this here as a self-reminder so we aren't surprised
when it becomes a more important thing to deal with :)

Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber  writes:
>
>> Just a heads up that right now you *can* run Racket-on-Chez, but soon
>> Racket-on-Chez will be the "default"... maybe it's a good idea to see
>> how hard it will be to make a racket-on-chez package variant.
>>
>> I'm interested in looking at that but it'll probably have to be a while
>> before I can do so... if someone does so before me, I'll be interested
>> in beta testing at least.
>>
>> But also leaving this here as a self-reminder so we aren't surprised
>> when it becomes a more important thing to deal with :)
>>
>>
>
> Also, since we are talking about Racket, what
> happened to having a racket build system?

There's interest in it, and Dimos made interesting progress towards
figuring out some of the key problems... there's been interest beyond
that but sadly it seems like organizing the energy to work on it hasn't
happened for whatever reason yet.

I've offered to throw money at the problem if someone's willing to take
it on btw... not much, but some money.  I've talked to a couple of
people about that but it stalled in each iteration I don't think
it's impossible but I guess it's one of those tasks that for whatever
reason seems difficult to get going on because there are some
complexities around the way Racket builds "collections" that eg don't
seem to show up in Python.  Anyway that's not a judgement because
despite wanting it fairly badly clearly I haven't made progress on it.

I have the notes that Dimos wrote up not long ago in case anyone is
interested.  Dimos, do you mind if I post them to the list?

 - Chris

Re: Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber 
> writes:
>
>> Bonface M. K. writes:
>>
>>> Christopher Lemmer Webber  writes:
>>>
>>>> Just a heads up that right now you *can* run Racket-on-Chez, but soon
>>>> Racket-on-Chez will be the "default"... maybe it's a good idea to see
>>>> how hard it will be to make a racket-on-chez package variant.
>>>>
>>>> I'm interested in looking at that but it'll probably have to be a while
>>>> before I can do so... if someone does so before me, I'll be interested
>>>> in beta testing at least.
>>>>
>>>> But also leaving this here as a self-reminder so we aren't surprised
>>>> when it becomes a more important thing to deal with :)
>>>>
>>>>
>>>
>>> Also, since we are talking about Racket, what
>>> happened to having a racket build system?
>>
>> There's interest in it, and Dimos made interesting progress towards
>> figuring out some of the key problems... there's been interest beyond
>> that but sadly it seems like organizing the energy to work on it hasn't
>> happened for whatever reason yet.
>>
>
> Can I volunteer on this task? There's some work in
> my team done in Racket; and it would be of great
> interest to us to have a working Racket build
> system. I can set apart some time to work on
> this. I'd ask for alot of guidance/ review on this
> though :)

YES!  Please do.  Let's talk.  You can ping me on IRC also, dustyweb on
freenode.

>> I've offered to throw money at the problem if someone's willing to take
>> it on btw... not much, but some money.  I've talked to a couple of
>> people about that but it stalled in each iteration I don't think
>> it's impossible but I guess it's one of those tasks that for whatever
>> reason seems difficult to get going on because there are some
>> complexities around the way Racket builds "collections" that eg don't
>> seem to show up in Python.  Anyway that's not a judgement because
>> despite wanting it fairly badly clearly I haven't made progress on it.
>>
>> I have the notes that Dimos wrote up not long ago in case anyone is
>> interested.  Dimos, do you mind if I post them to the list?
>>
> Please do share the notes! I can try to hack
> something up \m/\m/.

I looked at the email that Dimos sent to me (also the email I had was
apparently not the most recent email that they are using, corrected in
the addressing this time), and they had asked me if they should post it
to the mailing list, so I think that's consent to post it since they
expressed consideration in doing so in our exchange... so I'm attaching
it.

* Basics of Racket packaging system

Racket provides three abstractions of how to reuse and move around modules of 
code. These are:
** Libraries

A library in Racket is a single file module that can be used in other files. 
Libraries that are
serving some higher purpose are organised together in Collections.

Documentation can be found 
[[https://docs.racket-lang.org/reference/collects.html][here]].

** Collections

Collections are a number of libraries bundled together. They can be added to 
the system through
packages. Racket gets informed for presence of collections through collection 
link files.

In the filesystem collections are directories that include library files. The 
default path they are
stored is #. The corresponding link file is 
located at
# and includes a list as illustrated below:

#+begin_src racket
((root "pkgs/racket-lib")
 (root "pkgs/main-distribution")
 (root "pkgs/2d"))
#+end_src

More specifics about link files and their structure can be found 
[[https://docs.racket-lang.org/reference/collects.html#%28tech._collection._links._file%29][here]].
 More links can be added to
arbitary directories through 'raco link'. This file informs racket where a 
collection resides in the
# directory.

** Packages

Packages in Racket are the abstractions used to share and move around modules 
of code. The include a
number of libraries in a collection, or more collections. They are the means 
through which
dependencies are defined. The main entry for managing them is 'raco pkg'.

The tool for installing packages is 'raco pkg install' that takes as an 
argument a package source
(name of package in a catalog, directory, tar or zip file etc). How it will act 
is defined by the
"info.rkt" file included in the package source. 

Documentation for 
[[https://docs.racket-lang.org/pkg/cmdline.html#%28part._raco-pkg-install%29]['raco
 pkg install']] and 
[[https://docs.r

Re: Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber 
> writes:
>
> [...]
>
>>> Can I volunteer on this task? There's some work in
>>> my team done in Racket; and it would be of great
>>> interest to us to have a working Racket build
>>> system. I can set apart some time to work on
>>> this. I'd ask for alot of guidance/ review on this
>>> though :)
>>
>> YES!  Please do.  Let's talk.  You can ping me on IRC also, dustyweb on
>> freenode.
>>
>
> Thanks! I'm called bonz060 on FreeNode; though nowadays I've
> grown to be an e-mail person.
>
> [...]
>
>>> Please do share the notes! I can try to hack
>>> something up \m/\m/.
>>
>> I looked at the email that Dimos sent to me (also the email I had was
>> apparently not the most recent email that they are using, corrected in
>> the addressing this time), and they had asked me if they should post it
>> to the mailing list, so I think that's consent to post it since they
>> expressed consideration in doing so in our exchange... so I'm attaching
>> it.
>>
>
> [...]
>
> Thanks for the notes. I've skimmed through them
> and they seem sensible. I'll look at how other
> build systems are written as a first step, then
> get my hands wet.
>
> Do I open an issue for this---I can't see anything
> that tracks this even in archived issues--- then
> send patches there? Or do I send patches off the
> list and then submit the final drafts(if we get
> there) on the list later?

That sounds like a great plan!

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Maxim Cournoyer writes:

> Hello Guix!
>
> I've been experimenting with the following modification to the
> .dir-locals file shipped with Guix, that allows setting per-buffer
> variables within Emacs when visiting a file in the same directory (or in
> one of its sub-directories).
>
> This makes life a bit easier, by ensuring that a Geiser REPL started
> with C-c C-a in a file of either the main 'guix' checkout, a
> 'guix-core-updates' worktree or a 'guix-staging' worktree will set up
> the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH correctly (via the
> `geiser-guile-load-path' Elisp variable).
>
> The only requirement for it to work reliably is that any Guix checkout
> or worktree name should start with "guix".
>
> It doesn't require Geiser to be installed (it will just set the above
> variable uselessly if it isn't used -- not a big deal).
>
> What do you think?  Is it useful?  Should we include this as part of the
> default .dir-locals of Guix?
>
> Patch to follow!
>
> Thanks,
>
> Maxim

I'm a bit unsure what the implications fully are with this change, but
here was my user experience:

 - Did a pull using magit to guix
 - Suddenly every file I open in Guix is prompting me if I want to
   enable these dir-locals, I notice some have "eval" and I don't know
   what it's doing so I say no
 - But it's asking me every file
 - And oh no, it's asking me about ten times for every magit operation!
   (Presumably due to the reload operation.)  Fine okay fine, YES, okay
   cool it's quiet now... I hope that was safe.

Later...

 - I'm hacking on another file in another repo
 - C-x v = (check to see a diff of the work-in-progress changes of the
   file I'm working on)
 - Error in the minibuffer!  "Wrong type argument: stringp, nil"
 - wtf, okay M-x toggle-debug-on-error

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  (let* ((root-dir (expand-file-name (locate-dominating-file default-directory 
".dir-locals.el"))) (root-dir* (directory-file-name root-dir))) (unless (boundp 
'geiser-guile-load-path) (defvar geiser-guile-load-path 'nil)) 
(make-local-variable 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew 
root-dir* geiser-guile-load-path :test #'string-equal))
  eval((let* ((root-dir (expand-file-name (locate-dominating-file 
default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
(require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
#'string-equal)))
  hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
(locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
(directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
(defvar geiser-guile-load-path 'nil)) (make-local-variable 
'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
geiser-guile-load-path :test #'string-equal)))
  hack-local-variables-apply()
  hack-dir-local-variables-non-file-buffer()
  diff-mode()
  vc-diff-internal(t (Git 
("/home/cwebber/devel/scribble/scribble-lib/scribble...")) nil nil t)
  vc-diff(nil t)
  funcall-interactively(vc-diff nil t)
  call-interactively(vc-diff nil nil)
  command-execute(vc-diff)
 
 - Oh... it's whatever thing I enabled earlier in the guix repo.  Well
   now my vc-diff is broken outside of there... :\

I'm presuming that if I understood whatever this is doing, it's probably
something that gives me a better user experience if I accept it while
working on Guix.  But a) for whatever reason Emacs' dir-locals stuff is
written in such a way that it antagonizes me for not accepting it and I
didn't know what it eval was (maybe this is a lack of understanding in
how to "say no and get it to listen to me"... I didn't resist for too
long) and b) it seems like this change isn't scoped to Guix's checkout
itself somehow...

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Also, I hope this email isn't interpreted as being dismissive or negative
about what looks like it's probably a real usability improvement for
hacking on Guix!  I just thought my experience indicated maybe there are
additional considerations to address.

Christopher Lemmer Webber writes:

> Maxim Cournoyer writes:
>
>> Hello Guix!
>>
>> I've been experimenting with the following modification to the
>> .dir-locals file shipped with Guix, that allows setting per-buffer
>> variables within Emacs when visiting a file in the same directory (or in
>> one of its sub-directories).
>>
>> This makes life a bit easier, by ensuring that a Geiser REPL started
>> with C-c C-a in a file of either the main 'guix' checkout, a
>> 'guix-core-updates' worktree or a 'guix-staging' worktree will set up
>> the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH correctly (via the
>> `geiser-guile-load-path' Elisp variable).
>>
>> The only requirement for it to work reliably is that any Guix checkout
>> or worktree name should start with "guix".
>>
>> It doesn't require Geiser to be installed (it will just set the above
>> variable uselessly if it isn't used -- not a big deal).
>>
>> What do you think?  Is it useful?  Should we include this as part of the
>> default .dir-locals of Guix?
>>
>> Patch to follow!
>>
>> Thanks,
>>
>> Maxim
>
> I'm a bit unsure what the implications fully are with this change, but
> here was my user experience:
>
>  - Did a pull using magit to guix
>  - Suddenly every file I open in Guix is prompting me if I want to
>enable these dir-locals, I notice some have "eval" and I don't know
>what it's doing so I say no
>  - But it's asking me every file
>  - And oh no, it's asking me about ten times for every magit operation!
>(Presumably due to the reload operation.)  Fine okay fine, YES, okay
>cool it's quiet now... I hope that was safe.
>
> Later...
>
>  - I'm hacking on another file in another repo
>  - C-x v = (check to see a diff of the work-in-progress changes of the
>file I'm working on)
>  - Error in the minibuffer!  "Wrong type argument: stringp, nil"
>  - wtf, okay M-x toggle-debug-on-error
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>   expand-file-name(nil)
>   (let* ((root-dir (expand-file-name (locate-dominating-file 
> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
> #'string-equal))
>   eval((let* ((root-dir (expand-file-name (locate-dominating-file 
> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
> #'string-equal)))
>   hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
> (locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
> (directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
> (defvar geiser-guile-load-path 'nil)) (make-local-variable 
> 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
> geiser-guile-load-path :test #'string-equal)))
>   hack-local-variables-apply()
>   hack-dir-local-variables-non-file-buffer()
>   diff-mode()
>   vc-diff-internal(t (Git 
> ("/home/cwebber/devel/scribble/scribble-lib/scribble...")) nil nil t)
>   vc-diff(nil t)
>   funcall-interactively(vc-diff nil t)
>   call-interactively(vc-diff nil nil)
>   command-execute(vc-diff)
>  
>  - Oh... it's whatever thing I enabled earlier in the guix repo.  Well
>now my vc-diff is broken outside of there... :\
>
> I'm presuming that if I understood whatever this is doing, it's probably
> something that gives me a better user experience if I accept it while
> working on Guix.  But a) for whatever reason Emacs' dir-locals stuff is
> written in such a way that it antagonizes me for not accepting it and I
> didn't know what it eval was (maybe this is a lack of understanding in
> how to "say no and get it to listen to me"... I didn't resist for too
> long) and b) it seems like this change isn't scoped to Guix's checkout
> itself somehow...

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi Christopher,
>
> First of all I want to say sorry: I've tested this and reviewed the
> patch, and this is the second issue that already has caused, so yes, my
> tests weren't enough at all.
>
> Christopher Lemmer Webber  writes:
>
>> Also, I hope this email isn't interpreted as being dismissive or negative
>> about what looks like it's probably a real usability improvement for
>> hacking on Guix!  I just thought my experience indicated maybe there are
>> additional considerations to address.
>
> At least from my side I see your report as something positive, I cannot
> see how could it be negative at all, and I'd like to thank you for it.

Thanks.  I don't have time to fully respond inline to your comments
right now, but I appreciate the emails and work of both you and Maxim.
Thank you both, and glad we haven't had a miscommunication where we
mistakenly thought we were at odds. :)

Re: Setuid programs

[Christopher Lemmer Webber]

Gábor Boskovits writes:

> Hello,
>
> Ludovic Courtès  ezt írta (időpont: 2020. szept. 16., Sze, 
> 15:25):
>>
>> Hi,
>>
>> Gábor Boskovits  skribis:
>>
>> > I have two reasons for that: backwards compatibility is really
>> > important, so we should not break it, and I believe this would not be
>> > hard to do.
>> > On the other hand it would be nice to have a more integrated backend,
>> > and move as many things into the services infrastructure as practical,
>> > and I think this is a good candidate for that. Wdyt?
>>
>> There’s already ‘setuid-program-service-type’.  I think the way forward
>> would be to:
>>
>>   1. Define the  record type you propose.
>>
>>   2. Have ‘setuid-program-service-type’ accept that through its
>>  extensions.  When it receives something else, it should
>>  transparently turn it into a  record, for backward
>>  compatibility, and emit a deprecation warning.
>>
>>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>>  records.
>>
>> How does that sound?
>
> Sounds good to me. I will have a look.
>
>>
>> Thanks,
>> Ludo’.
>
> Best regards,
> g_bor

Hi!  It's been a bit since progress has been made on this, and I wonder
if I can help?

Getting Postfix included in Guix is my last step before moving my main
servers from Debian -> Guix so I'm feeling motivated. ;)

Re: Racket packages / build system

[Christopher Lemmer Webber]

Dimos Dimakakos writes:

> Bonface M. K. writes:
>
>> To simply put it, AFAIU updating a package would
>> require racket to update it's references(either
>> links, and other references that I won't go into),
>> hence creating some form of "global state";
>> thereby if you use raco, every package updated
>> would lead to some update with racket's search
>> paths or dirs somewhere. Any ideas to overcome
>> this wall? (or anything I've got wrong somewhere?)
>
> This was one of the main problems that I also encountered when working
> on this. racket2nix solves this by generating a temporary environment
> (by coping most of the racket folders and the deps needed as writable
> folders) where it installs with raco and then tries to update the global
> state of racket.
>
> To be honest this solution is kinda hacky and also slow, but I couldn't
> think of another one at the time I tried to work on the issue. It's a
> reality that the racket install system is quite stateful and also many
> operations seem to try to touch files. Installing with raco for example
> will try to recompile the dependencies of the new package and other such
> examples.
>
> Anyway, I hope you can find a way to move this forward!

I wonder if it would be a good idea to copy many of the points from this
email and the parent to racket-users or racket-dev and see if someone
more familiar with the structure of the system can provide guidance from
there?

If we have to go the racket2nix route, it would be better than nothing I
guess.

Another possible route: don't use the Racket installer tooling.
Instead, read the info.rkt file of the package to understand what raco
*probably would* do, and then do it in a more Guix way instead.

What do you think of that route?

Re: Racket packages / build system

[Christopher Lemmer Webber]

Bonface M. K. writes:

> Christopher Lemmer Webber 
> writes:
>
>> Dimos Dimakakos writes:
>>
>>> Bonface M. K. writes:
>>>
>>>> To simply put it, AFAIU updating a package would
>>>> require racket to update it's references(either
>>>> links, and other references that I won't go into),
>>>> hence creating some form of "global state";
>>>> thereby if you use raco, every package updated
>>>> would lead to some update with racket's search
>>>> paths or dirs somewhere. Any ideas to overcome
>>>> this wall? (or anything I've got wrong somewhere?)
>>>
>>> This was one of the main problems that I also encountered when working
>>> on this. racket2nix solves this by generating a temporary environment
>>> (by coping most of the racket folders and the deps needed as writable
>>> folders) where it installs with raco and then tries to update the global
>>> state of racket.
>>>
>>> To be honest this solution is kinda hacky and also slow, but I couldn't
>>> think of another one at the time I tried to work on the issue. It's a
>>> reality that the racket install system is quite stateful and also many
>>> operations seem to try to touch files. Installing with raco for example
>>> will try to recompile the dependencies of the new package and other such
>>> examples.
>>>
>>> Anyway, I hope you can find a way to move this forward!
>>
>> I wonder if it would be a good idea to copy many of the points from this
>> email and the parent to racket-users or racket-dev and see if someone
>> more familiar with the structure of the system can provide guidance from
>> there?
>>
>
> This is a good idea IMHO. I'll go ahead and do
> this. Perhaps there's something more important
> we've missed or aren't seeing.
>
>> If we have to go the racket2nix route, it would be better than nothing I
>> guess.
>>
>
> Yeah. I'm considering going though this route as a
> last resort. I don't understand the nix DSL
> syntax(though it reads alot like Haskell!).
>
>> Another possible route: don't use the Racket installer tooling.
>> Instead, read the info.rkt file of the package to understand what raco
>> *probably would* do, and then do it in a more Guix way instead.
>>
>> What do you think of that route?
>
> I've considered doing this... studying raco's source and seeing how it
> actually does and sets up things. I'd rather do this than the above,
> but it would take more time and would lead to alot more boiler plate I
> think... I'm not entirely sure about how to work around the global
> state though...

Regarding the boilerplate, not sure it needs to from a
package-definitions perspective... if the info.rkt can be read in the
general case, this could be the racket-build-system that does most of
the work (probably even by reading the very same info.rkt) rather than
it being output'ed from an importer definition.

> First, let's consult with the racket-devel and racket-user ML and see
> what those communities have to suggest...

Yes, good idea.

Re: Guix now in Debian experimental!

[Christopher Lemmer Webber]

This!  Is!  Awesome!

I think Guix in Debian could be huge and help both massively.  Well,
I've said so more than once in the past.  I believe it!  What's easy to
package in one tends to be easy to package in the other.  Just imagine
if we encouraged more developers using Debian as their host OS to use
"guix environment" (or eventually "guix shell") for their development
environments instead of one million incompatible language package
managers!

Vagrant Cascadian writes:

> It's been a long haul getting all the build dependencies of guix into
> Debian, but it has finally paid off:
>
>https://tracker.debian.org/pkg/guix
>
> So now you can install guix from Debian's experimental distribution!
>
> It is not well tested, in fact, I had to disable many tests, because in
> Debian it is a policy violation to download from the network during a
> build, but unlike guix, the policy is not necessarily enforced in any
> technical way!
>
> Many of the tests call out to the network in one way or another... So,
> this lead to:
>
>   Support GUIX_DISABLE_NETWORK_TESTS environment variable
>   https://issues.guix.gnu.org/44491
>
> Though I since learned about RES_OPTIONS=attempts:0 to disable name
> resolution in glibc instead, still working on refactoring tests/*.sh to
> make use of some common functions.
>
>
> There are many tests that make use of bootstrap binaries which attempt
> to download them during running the tests, despite networking not being
> available. I have patched these tests to also not run when the network
> is unreachable:
>
>   https://salsa.debian.org/debian/guix/-/tree/debian/devel/debian/patches
>
> My guess is these bootstrap binaries are available as inputs during the
> guix package builds of guix?
>
>
> I've also patched out a few tests that seemed non-deterministic, and a
> few that were simply inscrutible as to why they failed. Probably need to
> file bugs about those at some point... :)
>
>
> I also switched the packages to only run the tests in series, just in
> case parallelism was triggering issues with the tests:
>
>   https://issues.guix.gnu.org/21097
>
>
> In all, this ends up disabling about 200 out of 1100 tests in the Debian
> packages. I will explore another option to run those tests outside of
> the build, where network can be used, against the installed package
> using:
>
>   https://ci.debian.net
>
>
> It actually builds on both amd64 and i386 with some of the above
> mentioned tests disabled:
>
>   https://buildd.debian.org/status/package.php?p=guix&suite=experimental
>
> On armhf (ARMv7), it successfully built, but failed some test suites
> that passed on amd64/i386.
>
> On armel (ARMv4t?), where it probably shouldn't even attempt to build,
> it failed in the same way it failed on armhf...
>
> On arm64, guile-gnutls isn't available for guile-3.0, so it cannot
> build:
>
>   https://bugs.debian.org/966714
>
> An alternative would be to build guix against guile-2.2, which has
> guile-gnutls, although I did manage to find... more test suite failures
> on guile-2.2 (tests/lint.scm), including one which seemed to run
> indefinitely(tests/swh.scm), an infinitely thorough test!
>
> If the guile-gnutls issues do not get sorted out soon, building against
> guile-2.2 is a plausible backup plan for getting guix 1.2 into the next
> Debian release (speculated to be released mid 2021)...
>
>
> For other architectures, it would require considerably more courage,
> though there has been work on a few of those architectures in guix
> recently (e.g. hurd-i386, mips64el, powerpc, ppc64, ppc64el, and even
> talk of riscv64).  Would it be interesting to run guix on one of the
> more exotic architectures, Debian GNU/kFreeBSD? :)
>
>
> Well, thanks for reading the status update from your entirely unofficial
> Debian-Guix or Guix-Debian ambassador.
>
>
> live well,
>   vagrant

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi Christopher,
>
> First of all I want to say sorry: I've tested this and reviewed the
> patch, and this is the second issue that already has caused, so yes, my
> tests weren't enough at all.
>
> Christopher Lemmer Webber  writes:
>
>> Also, I hope this email isn't interpreted as being dismissive or negative
>> about what looks like it's probably a real usability improvement for
>> hacking on Guix!  I just thought my experience indicated maybe there are
>> additional considerations to address.
>
> At least from my side I see your report as something positive, I cannot
> see how could it be negative at all, and I'd like to thank you for it.
>
>> Christopher Lemmer Webber writes:
>>> I'm a bit unsure what the implications fully are with this change, but
>>> here was my user experience:
>>>
>>>  - Did a pull using magit to guix
>
> I use magit too, so I guess this isn't the source of the error.
>
>>>  - Suddenly every file I open in Guix is prompting me if I want to
>>>enable these dir-locals, I notice some have "eval" and I don't know
>>>what it's doing so I say no
>
> Saying no here shouldn't be a problem, as the variables should always be
> optional.
>
>>>  - But it's asking me every file
>
> If every file means "every file on guix project" that should be the
> normal behavior of Emacs for .dir-locals.el since this file was
> introduced long before the patch: you can mark the 'eval' lines to be
> accepted, or to be rejected always, but they're loaded with each file.
> A problem could be that the UI shows the ones you have already accepted
> too, and simply marks with * the new ones.
>
> If it means "every other file too", I'm unable to reproduce that with a
> fresh Emacs session.
>
>>>  - And oh no, it's asking me about ten times for every magit operation!
>>>(Presumably due to the reload operation.)  Fine okay fine, YES, okay
>>>cool it's quiet now... I hope that was safe.
>
> The only effects of the new code should be:
>
>   * First eval: Set guix-directory for emacs-guix to the folder where
> .dir-locals.el is located.  This affects the whole emacs-guix, but
> AFAIU this isn't your issue.
>
>   * Second eval:
> - Make geiser-guile-load-path buffer-local, and optionally define it
>   as empty if it was void.
> - Add the directory where .dir-locals.el is located to
>   geiser-guile-load-path.
>
>>> Later...
>>>
>>>  - I'm hacking on another file in another repo
>>>  - C-x v = (check to see a diff of the work-in-progress changes of the
>>>file I'm working on)
>
> Thanks, with that I reproduce the problem, but I cannot debug it right
> now.  I'll be available in some hours, as soon as I have anything I'll
> update about this.
>
>>>  - Error in the minibuffer!  "Wrong type argument: stringp, nil"
>>>  - wtf, okay M-x toggle-debug-on-error
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>>   expand-file-name(nil)
>>>   (let* ((root-dir (expand-file-name (locate-dominating-file 
>>> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
>>> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
>>> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
>>> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
>>> #'string-equal))
>>>   eval((let* ((root-dir (expand-file-name (locate-dominating-file 
>>> default-directory ".dir-locals.el"))) (root-dir* (directory-file-name 
>>> root-dir))) (unless (boundp 'geiser-guile-load-path) (defvar 
>>> geiser-guile-load-path 'nil)) (make-local-variable 'geiser-guile-load-path) 
>>> (require 'cl-lib) (cl-pushnew root-dir* geiser-guile-load-path :test 
>>> #'string-equal)))
>>>   hack-one-local-variable(eval (let* ((root-dir (expand-file-name 
>>> (locate-dominating-file default-directory ".dir-locals.el"))) (root-dir* 
>>> (directory-file-name root-dir))) (unless (boundp 'geiser-guile-load-path) 
>>> (defvar geiser-guile-load-path 'nil)) (make-local-variable 
>>> 'geiser-guile-load-path) (require 'cl-lib) (cl-pushnew root-dir* 
>>> geiser-guile-load-path :test #'string-equal)))
>>>   hack-local-variables-apply()
>>>   hack-

Re: Setuid programs

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hi,
>
> Gábor Boskovits  skribis:
>
>> I have two reasons for that: backwards compatibility is really
>> important, so we should not break it, and I believe this would not be
>> hard to do.
>> On the other hand it would be nice to have a more integrated backend,
>> and move as many things into the services infrastructure as practical,
>> and I think this is a good candidate for that. Wdyt?
>
> There’s already ‘setuid-program-service-type’.  I think the way forward
> would be to:
>
>   1. Define the  record type you propose.
>
>   2. Have ‘setuid-program-service-type’ accept that through its
>  extensions.  When it receives something else, it should
>  transparently turn it into a  record, for backward
>  compatibility, and emit a deprecation warning.
>
>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>  records.
>
> How does that sound?
>
> Thanks,
> Ludo’.

This sounds like a good plan.  I'm taking a stab at it, but there's a
good chance I'll get it wrong, so review will be seriously needed.
Let's find out how I do!

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi Maxim and Christopher,
>
> Maxim Cournoyer  writes:
>>[...]
>> Christopher Lemmer Webber  writes:
>> [...]
>>> I figured out what was happening!  The bug is *technically* in vc-mode.
>>> However, nontheless it manifested here...
>>>
>>> Here's what happened.  vc-mode has some various hacks, as you can see
>>> above with "hack-local-variables-apply"... which traverses the dirlocals
>>> stuff.  (Not sure what the purpose is, didn't look too long.)
>
> The file where these functions are located is lisp/files.el, right on
> the Emacs core.  Some modes add hooks there, like flyspell or cc, but
> not vc, so I don't really think the problem is exclusive from that mode
> after some debugging.
>
> This code ends up in file-local-variables-alist, even though
> dir-local-variables-alist contains the correct values for some reason I
> still don't really understand.
>
>>> However for whatever reason, vc-mode also seems to be reusing buffers
>>> such as `*vc-diff*'... and somehow still is left in the directory
>>> context it *first* was used in.
>
> This may be the culprit but I think it isn't the issue, as
> file-local-variables-alist accumulates every eval marked as nil, not
> only the first/last one... when it fails, as we've seen.
>
>>> Thus if I C-x v = in a guix-oriented buffer first, and then switch to
>>> another completely different project and do the same, it's loading the
>>> dirlocals from Guix(...)
>>>
>>> This is clearly a bug in vc-mode, I'll try to report it as such.
>
>> Thank you for the investigation.  I'd be really happy if you could
>> report the problem upstream (M-x report-emacs-bug) aznd link to it here!
>
> I haven't reported it yet, but as you can see I have a reproducer script
> attached.  I haven't seen anything in vc-code that points in that
> direction, surely though Emacs people will have a better understanding.
>
> Christopher, would you mind to CC me if you open the bug?  I can do it
> too if you tell me to, but I don't want to create a duplicate entry if
> we do it roughly at the same time.

It sounds like you're already putting together the work to do it.  If
you don't mind doing it that would save me a lot of time right
now... I'm quite swamped!  I'd be very grateful!

>> [..] Miguel had written in IRC at the time of the initial report, but
>> to no avail.
>
> Maxim, could you test the script to check if we can narrow the cases?
> It shows the README in the emacs it opens, so it should be
> straight-forward.
>
>>> In the meanwhile, I used this hacky "fix".  Maybe worth applying for the
>>> moment... what do you think of it?
>>
>> I'd like to have the upstream bug linked in that fix rather than the
>> Guix one; that way it'll be possible to track upstream resolution and
>> know when the workaround can be removed.
>
> Apart from the tracking reference, I agree that it's worth applying it.
> And also, thank you both for making easier to work on guix. :-)

Okay cool; since you two have already basically reviewed this code I'll
just make the suggested change and push it to the master branch.  Thank
you!

Re: Setuid programs

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Ludovic Courtès writes:
>
>> Hi,
>>
>> Gábor Boskovits  skribis:
>>
>>> I have two reasons for that: backwards compatibility is really
>>> important, so we should not break it, and I believe this would not be
>>> hard to do.
>>> On the other hand it would be nice to have a more integrated backend,
>>> and move as many things into the services infrastructure as practical,
>>> and I think this is a good candidate for that. Wdyt?
>>
>> There’s already ‘setuid-program-service-type’.  I think the way forward
>> would be to:
>>
>>   1. Define the  record type you propose.
>>
>>   2. Have ‘setuid-program-service-type’ accept that through its
>>  extensions.  When it receives something else, it should
>>  transparently turn it into a  record, for backward
>>  compatibility, and emit a deprecation warning.
>>
>>   3. Document the OS ‘setuid-programs’ field as taking a list of such
>>  records.
>>
>> How does that sound?
>>
>> Thanks,
>> Ludo’.
>
> This sounds like a good plan.  I'm taking a stab at it, but there's a
> good chance I'll get it wrong, so review will be seriously needed.
> Let's find out how I do!

I've attached a patch that includes my plan for the setuid stuff.  I
could submit this to guix-patches I suppose if that would be better.
But I wonder if I should actually just rebase the wip-postfix on top of
master, apply this, and then start working on setting up postfix to make
use of it.

What do you think of this approach?

>From cab9f7c017fb2ea0c8dc80084c3c269fa8e85378 Mon Sep 17 00:00:00 2001
From: Christopher Lemmer Webber 
Date: Sun, 15 Nov 2020 16:58:52 -0500
Subject: [PATCH] services: setuid: More specific setuid support.

New record  with fields for setting the specific user and
group, as well as specifically selecting the setuid and setgid bits, for a
program within the setuid-program-service.

* gnu/services.scm (): New record type.
  (setuid-program, make-setuid-program, setuid-program?)
  (setuid-program-program, stuid-program-setuid?, setuid-program-setgid?)
  (setuid-program-user, setuid-program-group): New variables, export them.
  (setuid-program-entry): New variable, a procedure used for the
  service-extension of activation-service-type as set up by
  setuid-program-service-type.  Unpacks the  record,
  handing off within the gexp to activate-setuid-programs.
  (setuid-program-service-type): Make use of setuid-program-entry.
* gnu/build/activation.scm (activate-setuid-programs): Update to expect a
  ftagged list for each program entry, pre-unpacked from the 
  record before being handed to this procedure.
---
 gnu/build/activation.scm | 40 
 gnu/services.scm | 49 +---
 2 files changed, 67 insertions(+), 22 deletions(-)

diff --git a/gnu/build/activation.scm b/gnu/build/activation.scm
index 4b67926e88..a2bdfd5aa5 100644
--- a/gnu/build/activation.scm
+++ b/gnu/build/activation.scm
@@ -229,13 +229,6 @@ they already exist."
 (define (activate-setuid-programs programs)
   "Turn PROGRAMS, a list of file names, into setuid programs stored under
 %SETUID-DIRECTORY."
-  (define (make-setuid-program prog)
-(let ((target (string-append %setuid-directory
- "/" (basename prog
-  (copy-file prog target)
-  (chown target 0 0)
-  (chmod target #o6555)))
-
   (format #t "setting up setuid programs in '~a'...~%"
   %setuid-directory)
   (if (file-exists? %setuid-directory)
@@ -247,18 +240,27 @@ they already exist."
  stringhttps://bugs.gnu.org/38800>.
-  (format (current-error-port)
-  "warning: failed to make '~a' setuid-root: ~a~%"
-  program (strerror (system-error-errno args))
+  (for-each (match-lambda
+  [('setuid-program src-path setuid? setgid? uid gid)
+   (catch 'system-error
+ (lambda ()
+   (let ((target (string-append %setuid-directory
+"/" (basename src-path)))
+ (mode (+ #o0555   ; base permissions
+  (if setuid? #o4000 0); setuid bit
+  (if setgid? #o2000 0 ; setgid bit
+ (copy-file src-path target)
+ (chown target uid gid)
+ (chmod target mode)))
+ (lambda args
+   ;; If we fail to create a setuid program, better keep going
+   ;; so that we don't leave %SETUID-DI

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> Miguel Ángel Arruga Vivas writes:
>
>> I haven't reported it yet, but as you can see I have a reproducer script
>> attached.  I haven't seen anything in vc-code that points in that
>> direction, surely though Emacs people will have a better understanding.
>>
>> Christopher, would you mind to CC me if you open the bug?  I can do it
>> too if you tell me to, but I don't want to create a duplicate entry if
>> we do it roughly at the same time.
>
> It sounds like you're already putting together the work to do it.  If
> you don't mind doing it that would save me a lot of time right
> now... I'm quite swamped!  I'd be very grateful!
>
>> Apart from the tracking reference, I agree that it's worth applying it.
>> And also, thank you both for making easier to work on guix. :-)
>
> Okay cool; since you two have already basically reviewed this code I'll
> just make the suggested change and push it to the master branch.  Thank
> you!

I've pushed the fix to master.  I also did the setq-local thing as
another commit.

However, since Miguel is the one submitting the upstream report, I left
a TODO item to link to that once done.  Miguel, do you mind committing
that once done?

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Christopher Lemmer Webber]

Miguel Ángel Arruga Vivas writes:

> Hi!
>
> Christopher Lemmer Webber  writes:
> [...]
>> It sounds like you're already putting together the work to do it.  If
>> you don't mind doing it that would save me a lot of time right
>> now... I'm quite swamped!  I'd be very grateful!
>
> No problem, I just didn't want to end up with two reports for the same
> issue.  It's already open as <https://bugs.gnu.org/44698>.
>
>>>[...]
>> I've pushed the fix to master.  I also did the setq-local thing as
>> another commit.
>
> Thanks.
>
>> However, since Miguel is the one submitting the upstream report, I left
>> a TODO item to link to that once done.  Miguel, do you mind committing
>> that once done?
>
> Pushed the update for the TODO line to master as
> 3428c66c5a4d5f1a5fd2f1ad4cd3105993ae8e6d.

Great, thank you! :)

Re: Setuid programs

[Christopher Lemmer Webber]

Christopher Lemmer Webber writes:

> I've attached a patch that includes my plan for the setuid stuff.  I
> could submit this to guix-patches I suppose if that would be better.
> But I wonder if I should actually just rebase the wip-postfix on top of
> master, apply this, and then start working on setting up postfix to make
> use of it.

I changed my mind since the setuid stuff is more general, is not blocked
by the postfix work.  Thus bug #44700 is tracking this.

Re: Guix in Debian!

[Christopher Lemmer Webber]

This.  Is.  Huge.

THANK YOU for all your hard work here!

I wrote out why I think this is big news:

  https://octodon.social/@cwebber/105612900114421037

Vagrant Cascadian writes:

> So, a while back I mentioned that Guix was present in Debian
> "experimental":
>
>   https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00254.html
>
> And it was useable for a brief window of time, but was broken due to
> some issues with guile-gnutls and guile-3.0:
>
>   https://bugs.debian.org/964284
>
> Somewhat deterred, I back-burnered it for a while while I focused on
> other things...
>
>
> Just a few days ago, I decided to attempt to get Guix into Debian's next
> release, and went with the fallback plan of building it against
> guile-2.2, and a few disabled tests later...
>
>   https://tracker.debian.org/guix
>
>
> If all goes well, it should migrate to "bullseye" in a few
> days. Hopefully in a few months "bullseye" will become Debian's stable
> release shipping with guix! Presumeably Guix will also eventually find
> itself in Ubuntu and other Debian derivatives...
>
>
> Now on Debian you should be able to:
>
>   apt install guix
>   guix install dpkg
>   guix environment --ad-hoc dpkg -- dpkg -i ./guix_1.2.0-3_amd64.deb
>
> It is almost like symmetry!
>
>
> Thanks for all the help and encouragement along the way, everyone!
>
>
> live well,
>   vagrant

Re: Potential security weakness in Guix services

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> I think it’s a good endeavor, but it’s a longer-term one since it’ll
> take some time before this new version is in use by all the Guix code.
>
> The difficulty in designing such an interface is that the Scheme API is
> more about ports than it’s about file names and file descriptors.
>
> Thanks!
>
> Ludo’.

In the long run, that might end up being safer.
In the meanwhile, we suffer the world of ACLs. ;)

(From my read, this is practically exactly the scenario from Norm
Hardy's original Confused Deputy paper...)

Re: Changes to the branching workflow

[Christopher Lemmer Webber]

Hello,

As someone who jumps in and out of Guix development occasionally but who
does have commit access (probably for grantparented-in reasons, heh),
sometimes I don't know where I should commit code or what the current
branching policy is, and I might miss emails like this.

I wonder if we should formalize it.  What about adding a section to the 
"Contributing" section of the manual explaining what the different
branches are, and when you have a patch that's been approved, when to
push it to which branch?

I think that would help me, and maybe it would help others.  Thoughts?

 - Chris

Leo Famulari writes:

> Based on experiences with the last "staging" cycle and discussions at
> the most recent Guix Day meeting [0], we've changed the branching
> workflow.
>
> The default branch names remain "core-updates" and "staging".
>
> When we begin actively building and testing the branches, they will be
> renamed to "core-updates-frozen" and "staging-frozen", respectively.
>
> This will indicate that they are closed to any changes except for bug
> fixes and merges of the master branch.
>
> During those periods, new patches can be pushed to "core-updates-next"
> and "staging-next".
>
> Hopefully these changes will clarify the status of the branches and
> reduce confusion.
>
> [0] https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00163.html

Re: Changes to the branching workflow

[Christopher Lemmer Webber]

zimoun writes:

> Hi, Chris,
>
> On Thu, 04 Mar 2021 at 16:05, Christopher Lemmer Webber 
>  wrote:
>
>> I wonder if we should formalize it.  What about adding a section to the 
>> "Contributing" section of the manual explaining what the different
>> branches are, and when you have a patch that's been approved, when to
>> push it to which branch?
>
> Do you mean something like #8 in [1] and then [2]?
>
> 1: <https://guix.gnu.org/manual/en/guix.html#Submitting-Patches>
> 2: <https://guix.gnu.org/manual/en/guix.html#Commit-Access>
>
> In [2], it reads:
>
> For patches that just add a new package, and a simple one, it’s
> OK to commit, if you’re confident (which means you successfully
> built it in a chroot setup, and have done a reasonable copyright
> and license auditing). Likewise for package upgrades, except
> upgrades that trigger a lot of rebuilds (for example, upgrading
> GnuTLS or GLib).
>
> which I understand as: the ’staging’ or ’core-update’ patches should go
> to guix-patches and not be pushed directly.  Especially when one has
> commit access and does not follow closely enough to know the status of
> the very branch.

I don't think the quoted part fully answered it, but the following part
does answer it:

 Depending on the number of dependent packages and thus the amount
 of rebuilding induced, commits go to different branches, along
 these lines:

 300 dependent packages or less
  ‘master’ branch (non-disruptive changes).

 between 300 and 1,800 dependent packages
  ‘staging’ branch (non-disruptive changes).  This branch is
  intended to be merged in ‘master’ every 6 weeks or so.
  Topical changes (e.g., an update of the GNOME stack) can
  instead go to a specific branch (say, ‘gnome-updates’).

 more than 1,800 dependent packages
  ‘core-updates’ branch (may include major and potentially
  disruptive changes).  This branch is intended to be merged in
  ‘master’ every 6 months or so.

I guess I hadn't read that part of the manual.  Oops!  So it does seem
well answered.  Good!

 - Chris

Golly... what's up with Golly?

[Christopher Lemmer Webber]

I think Sourceforge may have gone through a recent upgrade that broke
some things:

Starting download of 
/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz
>From 
>http://tenet.dl.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz...
following redirection to 
`http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=tenet.dl.sourceforge.net'...
ERROR: download failed 
"http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=tenet.dl.sourceforge.net";
 404 "Not Found"

Starting download of 
/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz
>From 
>http://vorboss.dl.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz...
following redirection to 
`http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=vorboss.dl.sourceforge.net'...
ERROR: download failed 
"http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=vorboss.dl.sourceforge.net";
 404 "Not Found"

Starting download of 
/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz
>From 
>http://netassist.dl.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz...
following redirection to 
`http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=netassist.dl.sourceforge.net'...
ERROR: download failed 
"http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=netassist.dl.sourceforge.net";
 404 "Not Found"

Starting download of 
/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz
>From 
>http://mirror.hydra.gnu.org/file/golly-3.1-src.tar.gz/sha256/0dn74k3rylhx023n047lz4z6qrqijfcxi0b6jryqklhmm2n532f7...
ERROR: download failed 
"http://mirror.hydra.gnu.org/file/golly-3.1-src.tar.gz/sha256/0dn74k3rylhx023n047lz4z6qrqijfcxi0b6jryqklhmm2n532f7";
 404 "Not Found"

Starting download of 
/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz
>From 
>http://tarballs.nixos.org/sha256/0dn74k3rylhx023n047lz4z6qrqijfcxi0b6jryqklhmm2n532f7...
ERROR: download failed 
"http://tarballs.nixos.org/sha256/0dn74k3rylhx023n047lz4z6qrqijfcxi0b6jryqklhmm2n532f7";
 404 "Not Found"
failed to download 
"/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz" from 
"mirror://sourceforge/golly/golly-3.1/golly-3.1-src.tar.gz"
builder for 
`/gnu/store/jqwc4vvkywr27ldcpqc5fqdq47nny3li-golly-3.1-src.tar.gz.drv' failed 
to produce output path 
`/gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz'
cannot build derivation 
`/gnu/store/bbx1h1n52wfvbj7lz26x40kjaqbk9zf8-golly-3.1.drv': 1 dependencies 
couldn't be built
guix environment: error: build failed: build of 
`/gnu/store/bbx1h1n52wfvbj7lz26x40kjaqbk9zf8-golly-3.1.drv' failed

The file still seems to exist in the web interface.  Those links don't
look particularly wrong but they no longer resolve.  I'm confused.

Also observed on IRC:

 I can't seem to build Golly... all the sourceforge links aren't 
working here
 dustyweb: weird, "git clone https://git.code.sf.net/p/golly/code"; hangs
 and eventually, "fatal: The remote end hung up unexpectedly"

I wonder what happened?

Re: Golly... what's up with Golly?

[Christopher Lemmer Webber]

Mark H Weaver writes:

> Christopher Lemmer Webber  writes:
>
>> I think Sourceforge may have gone through a recent upgrade that broke
>> some things:
>>
>> Starting download of 
>> /gnu/store/k857xn4vnppdp5z853c92lfa7h5fhdii-golly-3.1-src.tar.gz
>> From 
>> http://tenet.dl.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz...
>> following redirection to 
>> `http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=tenet.dl.sourceforge.net'...
>> ERROR: download failed
>> "http://downloads.sourceforge.net/project/golly/golly-3.1/golly-3.1-src.tar.gz?download&failedmirror=tenet.dl.sourceforge.net";
>> 404 "Not Found"
>
> I suspect that the URL in the package recipe is wrong, and has always
> been wrong.  I noticed this same error on Hydra's first attempt to build
> golly, but never got around to reporting it.
>
>   Mark

It looks like you're right... the error was on our end, not
SourceForge's.  I've pushed a commit correcting the URL.

Re: ScummVM

[Christopher Lemmer Webber]

ng0 writes:

> ng0 transcribed 3.2K bytes:
>> Hi,
>> 
>> I haven't checked the source code repo yet for licenses included except the 
>> obvious stated ones.
>> Last week I wrote on IRC that it contains proprietary engines (or something 
>> along this lines).
>> Memory served me wrong, there's only stable and unstable engines. This is 
>> from my current build log.
>> Now, last time I started scummvm was maybe over 10 years ago so I don't know 
>> if anything of this
>> requires the original disks etc and if that is okay by GFSDGL. I have some 
>> backups of my original
>> floppies, so I'll test ScummVM later today and see what works and how it 
>> works (I didn't read their
>> Manual or website so far). Or if it works at all. At least it build without 
>> issues now.
>
> Update: I tried "Day of the Tentacle" and "Mystery House", both worked.
> I'll give one of my Indiana Jonesand Monkey Island games a try tonight.

Beneath a Steel Sky is a cyberpunk ScummVM game:

  https://en.wikipedia.org/wiki/Beneath_a_steel_sky

And it's distributed in Debian... I think it's even in Debian main?

  
http://metadata.ftp-master.debian.org/changelogs/main/b/beneath-a-steel-sky/beneath-a-steel-sky_0.0372-6_copyright

Re: torbrowser

[Christopher Lemmer Webber]

ng0 writes:

> The maintainer of the ebuild for Gentoo in the torbrowser-overlay
> just gave me the last missing pieces of information for building torbrowser.
> Recent commit message subjects in the upstream torbrowser repository
> make me assume there will be no issues for integration into Guix master.
> As long as the final build ressembles what I have talked about with them
> we can even name it torbrowser and have the official design.
>
> I hope to be done with this by summer, but you never know with browser.
> But it's just a Firefox ESR deriv., so (ideally) it should just be a matter
> of 1 or 2 weekends.

This is great, ng0!  Thank you! :)

Re: Guix-based build tool

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello!
>
> Pjotr Prins  skribis:
>
>> Indeed, I love working with Guix and developing with Guix. Guix takes
>> care of my deployment and configuration requirements.
>>
>> I have written some time in the past that with Guix you don't need
>> autotools. The main thing autotools solve is configuring the build for
>> an environment. At the same time, with Guix you get a predictable
>> environment, so a make file (or similar) suffices. It is what I do in
>> all my development projects - I don't use autotools to develop and
>> deploy them. It greatly simplifies my existence :). Indeed, I have
>> never liked autotools (essentially a nasty hack) and only used them
>> before Nix/Guix. So, my approach is the same as yours :) 
>
> +1!
>
> If we could provide tooling with an abstraction level close to that of a
> makefile, that’d help a lot.
>
> Actually, just like we have ‘emacs-build-system’, we could very much add
> ‘guile-build-system’ for simple Guile packages that don’t need/use
> Autoconf & co.
>
> ‘guile-build-system’ would automatically run ‘guild compile’,
> ‘makeinfo’, etc. pretty much like we do here:
>
>   https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n870
>
> Once we have that, developers of Guile packages can simply drop a
> ‘.guix’ file in their project and use it with ‘guix environment’, ‘guix
> build’, and ‘guix package’.
>
> That’s coarser-grain than a makefile, of course, but would be a good
> first step to providing tooling for people working on Guile code.
>
> Any takers for ‘guile-build-system’?
>
>
> A next step could be to add a tool that understands a syntax like that
> of the guildhall, which gets us closer to the makefile/Makefile.am level
> of abstraction:
>
>   https://github.com/ijp/guildhall/blob/master/docs/packaging.texi#L121
>
> Ludo’.

While this is a fun idea, I'd still much rather have a guile-based
DSL replacement for autotools type things that's standalone (but maybe
also which can export to shell if need be).

David Thompson has made many comments before on the mistake of mixing
build systems and package managers... I'm a bit worried that we might be
encouraging going down that same path?

Re: Introducing myself as an Outreachy Intern

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> Welcome Sahithi!
>
>> I Sahithi Yarlagadda, a Free Software enthusiast. I am from India,
>> pursuing my under graduation final semester in Computer Science. I will
>> be working as an Outreachy Intern for May-August 2018. I am glad to be
>> part of Guix Community. I have been working with Ricardo Wurmus during
>> the application process. He helped me in understanding and working with
>> Guix. Community has given a great support, expecting the same till the end.

Hello Sahithi!  I'm very excited to have you joining our community!

> In my experience, this community is very supportive, patient, and
> friendly.  I’m sure you will find the same.  I’m looking forward to
> working with you and hope you’ll enjoy the experience.  Feel free to ask
> questions by sending email to guix-devel@gnu.org — chances are that
> someone else has the same question but didn’t dare to ask.

This has been my experience also.  I think "not being afraid to ask" is
one of the biggest challenges, in my experience, for students coming in
from Google Summer of Code or Outreachy.

Luckily you have a realy great mentor, and people here are generally
very happy to answer questions!

> To the rest of the Guix community: please welcome Sahithi and support
> this project by answering questions on IRC or here on the list.

Horray!  Welcome!  (Wait, I already said that, but welcome again!)

> I should add that Sahithi will be working on the project “Improve the
> user experience for the "guix package" command line tool”, which will
> address some of the major and minor problems that the command line
> interface currently has.  I’m the primary mentor for this project, and
> Gábor has volunteered to be co-mentor.  Thank you, Gábor!

Oh!  This is very exciting!

Re: Packaging a free Firefox

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Pjotr Prins  writes:
>
>>> Not packaging FF or crippling FF is a no-go! Doing so will discourage
>>> users from using GuixSD and Free Software.
>
> As an anecdote with a data-point of one, I uninstalled GuixSD because I
> suddenly needed the machine I was running it on to be my daily driver. I
> had been attempting to package Firefox whenever I had a spare moment,
> but I ran out of time and needed it to work as I didn't have time to
> migrate all the machines I use to a libre-friendly browser (nor am I
> sure I want to).

I'm sorry to hear we lost you as a user, and hope eventually you can
come back.  I suspect that you aren't the only person whom we've lost
due to this.

I think that means that at least one of these three is a priority, IMO:
 - Getting Chromium in
 - Getting Firefox in (even if we remove the direct link to Mozilla's
   extensions page and have to rebrand to Aurora)
 - Getting a channels mechanism

These days Guix has nearly everything I need, but this is a clear gap
for many.  Icecat helps a tremendous amount (and thank you thank you to
Mark for all your work keeping things patched) but I do think we need to
provide some other browser options.

 - Chris

Re: Packaging a free Firefox

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Ludovic Courtès transcribed 1.1K bytes:
>> Hello Katherine,
>> 
>> Katherine Cox-Buday  skribis:
>> 
>> > E.g. I've seen several people in this thread mention they had already,
>> > or were trying to, package Firefox (myself included). Had there been an
>> > official non-libre channel, this work might not have been duplicated.
>> 
>> There will never be an “official” non-libre channel in that Guix as a
>> project will not provide such a channel.
>> 
>> Now, Firefox *is* free software, so there’s could be an official
>> “firefox” package, but in essence, it would have to incorporate pretty
>> much the same changes that IceCat provides.
>> 
>> I wonder why IceCat is based on an ESR, and what it would take to have
>> it follow Firefox releases more closely.
>
> I am not involved or speaking for Icecat, but ESR is moving slower than
> Firefox "master" channel. This alone is good enough to base on it for
> long-term support when you are a downstream vendor such as Torbrowser,
> Icecat, or a simple company running a site-specific Firefox.

It would be really nice to be able to have tor browser bundle in GuixSD.

Re: Packaging a free Firefox

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Christopher Lemmer Webber transcribed 1.2K bytes:
>> Nils Gillmann writes:
>> 
>> > Ludovic Courtès transcribed 1.1K bytes:
>> >> Hello Katherine,
>> >> 
>> >> Katherine Cox-Buday  skribis:
>> >> 
>> >> > E.g. I've seen several people in this thread mention they had already,
>> >> > or were trying to, package Firefox (myself included). Had there been an
>> >> > official non-libre channel, this work might not have been duplicated.
>> >> 
>> >> There will never be an “official” non-libre channel in that Guix as a
>> >> project will not provide such a channel.
>> >> 
>> >> Now, Firefox *is* free software, so there’s could be an official
>> >> “firefox” package, but in essence, it would have to incorporate pretty
>> >> much the same changes that IceCat provides.
>> >> 
>> >> I wonder why IceCat is based on an ESR, and what it would take to have
>> >> it follow Firefox releases more closely.
>> >
>> > I am not involved or speaking for Icecat, but ESR is moving slower than
>> > Firefox "master" channel. This alone is good enough to base on it for
>> > long-term support when you are a downstream vendor such as Torbrowser,
>> > Icecat, or a simple company running a site-specific Firefox.
>> 
>> It would be really nice to be able to have tor browser bundle in GuixSD.
>
> TL;DR is we can have it and I will pick up work on it again pretty soon.
> (We had the idea for a custom browser based on Torbrowser, so I have a
> requirement beyond simply using it.)
>
> Under the conditions (for packaging torbrowser) I talked about with 
> Torbrowser-project
> it is okay to ship it fully branded. I will have to get back to them as soon
> as I am past the current bug and got it building.

Hey, that's great news!  Thank you :)

Re: Mes 0.14 released

[Christopher Lemmer Webber]

Jan Nieuwenhuizen writes:

> I am pleased to announce the release of Mes 0.14, representing 98
> commits over 4 weeks.  Mes+MesCC now compiles a self-hosting TinyCC
> that has only been slightly patched.
>
> This means that we can now build a tcc that depends only on a 1MB
> ASCII M1 seed.  GuixSD currently uses a ~250MB binary seed to build
> gcc.
>
> Next targets are: build gcc using this almost full-source bootstrapped
> tcc, and reduce the 1MB ASCII M1 seed to ~100KB of M2 source, which is
> a restricted subset of C.

Awesome!  Thank you for all your work, Jan!

Re: my latest blog post

[Christopher Lemmer Webber]

I think Catonano and Mark discussed things nicely earlier in the thread,
so I'm not going to weigh in on that (though I do agree that we would
can and should do better, but that also it's important to realize that
community members only have so many personal resources to be able to
respond sometimes).

Guile still matters a lot to me.  I think Guile has a long way to go,
but I look at it more that there is an opportunity for us to do better
than that we have failed currently.  What can we do to move in the right
direction?

Joshua Branson writes:

> I personally dislike that saying "guys" on IRC is frowned upon.  In my
> personal life I use "guys" when I'm talking to a group of people, even
> if some are women.  Are there women in the guix community that are
> offended by the use of "guys"?

There may be, and even if there weren't, I certainly know many women (or
generally non-male, and heck, even many male) developers who are
bothered by that language.  The question isn't just whether or not we're
upsetting someone currently (though that's important), it's also whether
we're losing the opportunity to grow our community to include such
people going forward.

Re: my latest blog post

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> Catonano  writes:
>
> I wrote this:
>
>But please do not demand of others to explain everything in detail.
>(I’m directing this at everyone who heeds my advice to go to
>guile-devel, not at any one person in particular.)
>
> Rephrasing: I’d like to point this out to people who take this
> opportunity to bemoan the lack of other features or who disagree with
> what they think are different priorities.  You do not feel addressed if
> you know you’ve made efforts in this area.
>
>> And saying I should come on guile-dev and actually provide what I thin is
>> useful, nowing that I can't (not immediately is not a fair answer either
>>
>> Because it's equivalent to a "fuck you"

I think at a moment like this it's important to step back a
moment... Wikipedia has a good philosophy here called "Assume Good
Faith":

  https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

Making Guile into a friendlier environment for newcomers is important.
But if we are to have a friendly environment, the only way that can
happen is if we believe that in general we have a culture of
collaboration.  That doesn't mean we don't hold people accountable if
they are clearly demonstrating disrespectful or hostile behavior.  But
there's no way to have a collaborative environment if we don't try to
give people the benefit of the doubt that they wish to work together to
improve things.

Re: my latest blog post

[Christopher Lemmer Webber]

Catonano writes:

> Instead of calling me an hopeless moron unwilling to learn, he went and
> updated Skribilo, without saying a single word
>
> I noticed
>
> And I appreciated it
>
> So, yes, it was aggressie indeed
>
> Again. I'll try to be more complete later

I think it's great that Ludovic responded so nicely with Skribilo.
Though I read what Ricardo wrote... I think he never called you anything
of the sort, and if I had read only your email I would have gotten the
impression that he had (I am not sure if this is what you intended here,
maybe you were referring to something else, but I think it applies to at
least the comment where you interpreted what Ricardo said as "f--- you").
If I were in Ricardo's situation I think I would feel very hurt.

I think part of the conflict here is you're saying you're seeing some
things that you think are clearly missing from the project, and here are
some things that you'd like to see changed, and here are some things you
are offering to change.  And that I think is very good.  But you are
also identifying some things you'd like to see changed that you don't
yet know how to change.  Ricardo is suggesting that you learn more about
them and jump in to help change them.

Is this a hostile thing to do?  Well, if it were used as a way to
dismiss the request entirely, probably.  But what I think Ricardo is
trying to say is that the Guile community is resource-strapped (which it
is, being run by volunteers).  We cannot demand that anyone who is
volunteering work on a specific thing, but we can ask and make
suggestions.  And one excellent way to make changes happen is to learn
and step into the role of making them happen.

Not everyone can, and this is true and I fully agree.  To that end, I
think that's where bug reports come in, and making an appeal to the
community to work on a specific thing is useful.  But I also think that
it is true that everyone can help in some ways, and that we also
remember that everyone is volunteering.  We cannot expect that
everything that we would like done will be done because all volunteers
only have so much energy.  To that end, a call to "please help" is not
necessarily dismissive... it may be a call to ask you to be empowered,
and a call to say that your contributions would be welcome and
appreciated.

Most importantly, I think we should not put negative words in another
person's mouth that they did not say or intend.  I linked "Assume Good
Faith" earlier because I think we cannot build a strong community
together without doing so.  To put more negative words in place of what
someone said puts them on the defensive and makes it hard to come
towards further progress.  This is a collaborative game... let's
recognize that, and all work together to make it a better place.

Re: my latest blog post [everyone, please take a cooldown break]

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Hi,
>
> I think it would be best if everyone involved would cool down for a couple of
> days, restructure their thoughts and reflect on this thread. Look at what
> they are doing, and at how they are reacting to other peoples reaction.
> This topic is getting quiet heated, and other than the maintainers we
> do not have established some kind of mderation. It can be hard to discuss
> some topics online.
> Text can sometimes fail to transport what we attampt to express, and
> I have seen people step away from projects because of this.

+1000

Re: Update on GuixSD containers

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Definitely.  Another application I’ve always wanted is a least-authority
> shell, like Plash [0].
>
> (Speaking of which, I just found Shill [1], which seems similar to Plash
> and even has a to-do item regarding package management [2] and is
> written in Racket; unfortunately it runs on FreeBSD, for Capsicum.)

As a side note, yesterday I learned about Capsicum for Linux:

  https://github.com/google/capsicum-linux

Unfortunately it has not seen commits this last year.  A shame; it would
really be nice to get such ocap support in GNU/Linux.

Re: Graft hooks

[Christopher Lemmer Webber]

Timothy Sample writes:

> Hi Guix,
>
> I just submitted a patch for , but now I’m
> wondering if there isn’t a more general way to solve the problem.
>
> The bug has to do with grafting and checksums.  I know three bugs that
> follow this theme: the one above (Racket), 
> (GDB), and  (Go).  The basic problem is that
> these packages store checksums of files during build time.  If they get
> updated due to grafting, the files change, but the checksums do not.
> The checksums become invalid, which causes other problems like trying to
> update files in the store or asserting that debugging information is
> invalid.
>
> The patch I submitted makes Racket assume that files in the store are
> good.  It patches Racket to skip checksum validation if it is checking a
> file in the store.  A similar approach could be taken for GDB and Go.
>
> It occurs to me that if we had some way to run package-specific code
> during grafting we could solve problems like this easily and without
> patching software that is not broken.
>
> The basic idea would be to add a field (or use a property) to the
> package record.  Let’s call it “graft-hook”.  It would be Scheme code
> that gets run after grafting takes place, giving us a chance to patch
> special things like checksums.  The hook would be passed the list of
> files that were been modified during grafting.  Then, in the Racket
> package for example, I could write a graft-hook that updates the SHA-1
> hash of each of the modified source files.

This seems like a really good approach to me and seems also much nicer /
safer in the long run than the solution in #30680 since it wouldn't just
patch out the package in question's checks, it would correct them.  That
seems very good indeed to me.

> Since grafting is done at the derivation level, the hook code would have
> to be propagated down from the package level.  I haven’t looked at all
> the details yet, because maybe this is a bad idea and I shouldn’t waste
> my time!  :)  My first impression is that it is not too tricky.
>
> Are these problems too specialized to deserve a general mechanism like
> this?  Let me know what you think!
>
>
> -- Tim

As said, it seems good to me.  But I would be interested in what Mark
would think, since he is mostly responsible for the grafts design.

Re: Graft hooks

[Christopher Lemmer Webber]

Ludovic Courtès writes:

>
>> Here’s a draft patch (it’s mercifully small).  I have a few questions
>> about it, but if it looks like the right approach, I will clean it up
>> and submit it.
>>
>> Basically, it checks if we are grafting Racket, and then adds some code
>> to the build expression to run the hook.
>
> OK.  In theory, should it be just for Racket, or should it also be for
> Racket libraries (we don’t have any currently AFAIK)?

That's something I'd like to change soon :)

Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

Hello... reading over a few articles this morning:

 - Researchers Blame ‘Monolithic’ Linux Code Base for Critical
   Vulnerabilities
   
https://threatpost.com/researchers-blame-monolithic-linux-code-base-for-critical-vulnerabilities/136785/
 - Its associated paper:
   "The Jury Is In: Monolithic OS Design Is Flawed"
   http://ts.data61.csiro.au/publications/csiro_full_text/Biggs_LH_18.pdf
 - Brains behind seL4 secure microkernel begin RISC-V chip port
   https://www.theregister.co.uk/2018/04/23/risc_v_sel4_port/

I'm bringing this up because I want to plant the seed for some thinking
and conversation:

 - It's getting hard to trust our computers as in terms of our physical
   hardware.  Companies like Purism are helping to build blobless
   systems, but even then the hardware is built on un-auditable and
   with growing apparent insecurity (Spectre, Meltdown) with little
   chance of fixing things.  RISC-V has a libre instruction set, and in
   the long term I think we want to support that.

 - In terms of software, currently we run on ACL-heavy systems, which
   are well known to be insecure designs:
 http://waterken.sourceforge.net/aclsdont/current.pdf
   If a computer program behaves badly, it shouldn't be able to do any
   more damage than the smallest amount of authority it should need to
   run.  Currently programs run with the full authority of the user.
   This means that a tiny code flaw in even the most trivial package
   can lead to complete user compromise.

   In the long run, we'll want to support object capability based OS
   designs which follow the principle of least authority, so a program's
   vulnerabilities will be limited in scope.

 - What paths do we have forward on that last one?

   - Well, GNU Hurd is a microkernel + ocap system (while also trying
 to be POSIX compatible).  Manolis has done much good work in
 helping to make that a more feasible option for Guix users.

   - There's also seL4 which has a verified security kernel, possibly
 even seL4 with Genode.  I'm not sure how hard it will be to run
 POSIX type things on Genode.

   - There's also Google's recent work with Magenta/Fuschia.  From what
 I've read, architecturally this looks right.  I think the reason
 for worry here is the same difficulty the community has had to
 build actual community and libre distributions on top of the
 Android ecosystem could apply here.

 - It's also worth noting that the most common class of serious
   application / library vulnerabilities that we have to deal with is C
   / C++ memory management issues.  I'm not saying we should embrace
   everything getting ported to Rust, but I do think it's important to
   note that we're finally seeing paths out of that nightmare.

As a side note, if we don't have both together (libre hardware + ocap)
and we just have microkernel + ocap systems on top of proprietary
hardware, especially heavily "vendor controlled" systems, we could end
up much more screwed than we are even in our current systems, which is
why I think it's critical that we engage these things.  In the book
Rainbow's End (minor spoilers here) it's hinted that all the users are
running computers which have object capaiblity security and are thus
much more resilient to attacks, except that the bottom most layer of the
system is intentionally government compromised so that all systems are
effectively backdoored.  So, your sustem is secure... except for the
backdoor.

Anyway... the goal of this email was mostly just to try to get people
thinking about the direction we want to go long term.  Hope that's
useful/interesting even if it isn't an actual contribution of code
towards it ;)

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

First off, I should mention that rain1 reminded me about OpenBSD's
Capsicum and the Capsicum for Linux project, which I had mostly
forgotten about:
  http://www.capsicum-linux.org/

Capsicum brings file descriptor based capabilities, and this is a
reasonable intermediate approach.

Shill is an ocap (object capability) supporting shell using Capsicum:
  http://shill.seas.harvard.edu/

Ricardo Wurmus writes:

> Hey,
>
>>  - In terms of software, currently we run on ACL-heavy systems, which
>>are well known to be insecure designs:
>>  http://waterken.sourceforge.net/aclsdont/current.pdf
>>If a computer program behaves badly, it shouldn't be able to do any
>>more damage than the smallest amount of authority it should need to
>>run.  Currently programs run with the full authority of the user.
>>This means that a tiny code flaw in even the most trivial package
>>can lead to complete user compromise.
>>
>>In the long run, we'll want to support object capability based OS
>>designs which follow the principle of least authority, so a program's
>>vulnerabilities will be limited in scope.
>
> I agree, which is why I think that in the short term we should look into
> doing more work on SELinux policies (hear me out, please).  SELinux
> already exists and it provides an implementation of mandatory access
> control.  The big picture idea is: processes and files are assigned to
> certain domains where only certain access types are permitted and the
> kernel enforces these declarations.  Processes can transition from one
> domain to another only according to policies.
>
> SELinux certainly isn’t pretty, but it isn’t quite as complicated as the
> bad documentation out there makes it seem.
>
> I was thinking that we could have an internship (GSoC or Outreachy)
> project to implement support for SELinux in Guix, including the design
> of an extensible policy scheme.  I think Guix is uniquely suited as the
> foundation of an understandable SELinux system.  (Think of how the
> existing system service framework could be extended to provide
> context-specific SELinux policies.)

I'm not a big fan of SELinux because it's using an RBAC style system,
which is like a more fine grained ACL.  It's still a centralized
authority model, non-composable, and isn't as secure as a capability
security type approach.

I said this on IRC but:

 E in a Walnut has something to say about that
 > With tools like access control lists and firewalls, we engage in
   "perimeter defense", which is more correctly described as "eggshell
   defense". It is like an eggshell for the following reason: while an
   eggshell may seem pretty tough when you tap on it, if you can get a
   single pinhole anywhere in the surface, you can suck out the entire
   yoke.

Source: http://www.skyhunter.com/marcs/ewalnut.html

My personal view is that ACL'ish / RBAC'ish systems are the wrong
approach.  I suppose if someone wants to put effort into this direction
I don't object, unless it starts to complicate our tooling.  But for
focusing our efforts what I think we should do is work towards a better
long-term security approach of supporting object capability operating
system ideas.

>>- Well, GNU Hurd is a microkernel + ocap system (while also trying
>>  to be POSIX compatible).  Manolis has done much good work in
>>  helping to make that a more feasible option for Guix users.
>
> I’d love to get us closer to being able to run the GNU system with the
> Hurd and Guix underpinnings.  Unfortunately, Hurd is not considered a
> priority by GNU, which shows in the lack of support for modern hardware.

Yes, this is unfortunate.

>> As a side note, if we don't have both together (libre hardware + ocap)
>> and we just have microkernel + ocap systems on top of proprietary
>> hardware, especially heavily "vendor controlled" systems, we could end
>> up much more screwed than we are even in our current systems, which is
>> why I think it's critical that we engage these things.
>
> I don’t understand this.  Why would the situation with microkernel +
> ocap on top of proprietary hardware be *worse* than the current
> situation of a monolithic ACL-based system on top of equally proprietary
> hardware?

The problem is that a much better implemented system will be harder to
break out of.  Right now many people "jailbreak" systems so they can
install free software on them.  We want to build watertight security
systems so that when users *control their hardware*, the programs on
their machines cannot do damage that they shouldn't be able to do.

But if the same watertight security system was applied but the lowest
capability layers were out of the user control, it might not be possible
to break free.

We can already see some of this today.  My understanding of why Intel
won't release a chip without ME, for instance, is that it's key to the
DRM systems that enforce playback of blue-ray players.  The enfor

Re: FOSDEM 2019

[Christopher Lemmer Webber]

Manolis Ragkousis writes:

> Hello everyone,
>
> It's that time of the year again we need to start organizing about
> FOSDEM. We have a deadline for the 20th of September[1] to apply for a
> devroom. We also need to start looking for a place for this year's
> fringe event!
>
> I created a libreplanet page[2] to start writing possible talk ideas in
> case we get a devroom.

Thanks for everyone is doing organizing, especially Manolis for kicking
this off!

I added a talk topic: "A Guiler's Year of Racket".  I think there's a
lot we could learn from our fellow friends in Racket-land, and I'd like
to share some of that!

Should *.fr.texi be committed in git?

[Christopher Lemmer Webber]

I frequently find that my git repo says:

Unstaged changes (2)
modified   doc/contributing.fr.texi
modified   doc/guix.fr.texi

And then I need to revert them before doing a pull.

These files are autogenerated from translations, right?  Shouldn't they
be gitignore'd and not committed to git at all?

Re: A major milestone in bootstrapping

[Christopher Lemmer Webber]

jerem...@pdp10.guru writes:

> Today I am proud to announce a combo of releases with major milestones.
>
> First stage0, reached Release version 0.2.0; which includes the following:
> A 250byte hex0 bootstrap binary that is self-hosting and builds hex1,
> which builds hex2, which bootstraps M0 macro assembly which has been
> used to make:
>
> The world's FIRST C compiler written in M0 macro assembly, supporting:
> structs
> unions
> inline assembly
> function pointers
>
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s
>
> which is capable of compiling reproducibly:
>
> The newly released M2-Planet V1.0
> https://github.com/oriansj/M2-Planet
>
> Which is a self-hosting C compiler which is 100% deterministic by design
> with support for all the features needed to build the pieces of:
>
> mescc-tools
> https://savannah.nongnu.org/projects/mescc-tools
>
> which is capable of building M2-Planet from it's M1 macro seed.
>
> Soon we hope to finish the MesCC bootstrap from M2-Planet and then we
> will have a complete bootstrap path from 250byte hex0 all the way up to
> gcc ^_^
>
> -Jeremiah Orians

Interesting... I'm looking at

  https://github.com/oriansj/M2-Planet/blob/master/seed.M1

How was it written?  It seems like a monumental task to write all that
and keep enough context in one's head!  Then again, I have never written
assembly before...

Re: Firefox 52's end of life, packaging Chromium

[Christopher Lemmer Webber]

Clément Lassieur writes:

> Hi,
>
> Firefox 52 isn't supported anymore upstream[1] and we don't have a
> package for Firefox 60.  Currently the only alternative is Epiphany but
> it's close to unusable (it crashes every 5 minutes, and sometimes
> freezes my computer).
>
> So the question is: can we push the Chromium package?  I've read it's
> almost ready[2].  It's probably far better than everything we have,
> despite not being totally 'finished'.  Maybe we can add what's left to
> do as a TODO and fix the package later?

+1 on this.  Considering how well attacked browsers are, not providing a
generally usable recent browser is putting our users at risk.

Re: [rb-general] A major milestone in bootstrapping

[Christopher Lemmer Webber]

Orians, Jeremiah (DTMB) writes:

>> Interesting... I'm looking at
>> https://github.com/oriansj/M2-Planet/blob/master/seed.M1
>> How was it written?  It seems like a monumental task to write all
>> that and keep enough context in one's head!  > Then again, I have
>> never written assembly before...
>
> If you'll notice https://github.com/oriansj/M2-Planet/blob/master/seed.M1#L2
>
> It explicitly says it was generated from stage0 
> https://savannah.nongnu.org/projects/stage0/
> Specifically cc_x86 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/cc_x86.s
> Which was built by M0: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/M0-macro.hex2
> Which was built by hex2: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-2.hex1
> Which was built by hex1: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-1.hex0
> Which was built by hex0: 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage1/stage1_assembler-0.hex0
> Which was the 250byte seed used
>
> Well the work started back in 2016 with 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.s
> and 
> http://git.savannah.nongnu.org/cgit/stage0.git/tree/Linux%20Bootstrap/hex0.hex
>
> It was written one function at a time, with the arguments passed in registers 
> and careful preservation of everything passed.
>
> - Jeremiah Orians

Ah very interesting!  Thanks for the history :)

Re: Heads-up: New dependency on Guile-Gcrypt

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello Guix!
>
> Coming soon: Guix will no longer provide its own crypto modules and will
> instead depend on Guile-Gcrypt:
>
>   https://issues.guix.info/issue/32606
>
> ‘guix pull’ will happily perform the transition.
>
> If you’re used to working on a Git checkout with “guix environment
> guix”, you’ll have to add ‘guile-gcrypt’ to the environment.  If your
> “guix” is too old and lacks the ‘guile-gcrypt’ package, you have a
> chicken-and-egg problem that you can solve either by running ‘guix pull’
> or by running this from your checkout:
>
>   $(make as-derivation)/bin/guix environment guix
>
> or:
>
>   $(make as-derivation)/bin/guix package -i guile-gcrypt
>
> Besides, our friends at openSuSE have already created a ‘guile-gcrypt’
> package.  :-)
>
> Ludo’.

Woohoo!  Really nice to see that package put to good use!

Re: bootstrap: i686-linux now builds without binutils, gcc, and glibc seeds

[Christopher Lemmer Webber]

Jan Nieuwenhuizen writes:

> Jan Nieuwenhuizen writes:
> Feeling slightly discouraged, but I will hammer on.  We're getting
> closer and closer...
>
> janneke

You really are!  Go team bootstrap!

Re: Firefox 52's end of life, packaging Chromium

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> Benjamin Slade  skribis:
>
>> Speaking from a user-perspective, I would be very much in favour of
>> having modern Firefox and Chromium (appropriately de-Googled as much as
>> possible, of course) as actual Guix offerings.
>>
>> And while there are lots of objectionable things about the www in 2018,
>> I don't think being a GNU follower is likely to strongly correlate with
>> being anti-web (I suspect the opposite, if anything).
>
> I agree with both statements.  I do see things in today’s www that I’m
> unhappy with, but I think it’s important to provide our users with a
> recent browser.
>
> I have to say that Andreas, Mark, Marius, and others who worked on
> IceCat and Chromium packaging are heroes: it’s a huge effort and we can
> be grateful for that!
>
> Ludo’.

Hear hear!  (Or is it "Here here?")

Re: Changes in the spending committee for the FSF Fund

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Thanks Mark for your time on the spending committee, and welcome Tobias!

Yes, thank you both!

Re: Racket: Move DrRacket to a separate output?

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello Pierre,
>
> Pierre Neidhardt  skribis:
>
>> Wouldn't it make sense to move DrRacket to a separate output?  I take
>> that most advanced users use something else (who said Emacs?) and
>> DrRacket might eat up a decent amount of disk space + extra dependencies
>> by itself.
>
> I don’t think it’s a matter of being an “advanced” user or not (DrRacket
> is really impressive, with a macro stepper and all sorts of bells and
> whistles), but I agree with the rationale.  :-)
>
>> Arch Linux provides racket and racket-minimal: the latter is stripped
>> from DrRacket:
>>
>>  https://www.archlinux.org/packages/?q=racket
>
> Such a split sounds good to me.  What do Chris and other Racketeers
> think?
>
> Cheers,
> Ludo’.

I'm ok with splitting out racket-minimal and racket, which is a common
convention these days... even Racket's download page provides "Racket"
and "Minimal Racket":

https://download.racket-lang.org/

I'd take the least effort route to doing that though... we aren't ready
to break each of the Racket "core" packages into their own packages and
I don't think that would need to hold this back.

 - Chris

Re: SeaGL 2018 Accepts Guix-Themed Talk: "Everyday Use of GNU Guix"

[Christopher Lemmer Webber]

Chris Marusich writes:

> Hi Guix!
>
> I recently submitted a Guix-themed talk proposal for SeaGL 2018 [1], a
> local GNU/Linux conference that takes place in November here in Seattle,
> and I'm happy to report that it was accepted!  Here's the link:
>
> "Everyday Use of GNU Guix"
> https://osem.seagl.org/conferences/seagl2018/program/proposals/526
>
> I'm very excited about it!  I've been to SeaGL before as an attendee,
> but this is the first time I'll try my hand as a presenter.  It's a
> great opportunity to promote and share Guix within my local community.
>
> I'll do my best to introduce Guix to the attendees!  If even one person
> from Seattle decides to give Guix or GuixSD a try, I'll consider that a
> success!  I need more Guix here on my home turf.  :-)
>
> Footnotes: 
> [1]  http://seagl.org/

Hey this is great news!  I've been to SeaGL before and it was great.

Enjoy your talk!  I'm sure it'll go great.

openssh vulnerability

[Christopher Lemmer Webber]

https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/

seems serious?

Re: openssh vulnerability

[Christopher Lemmer Webber]

Leo Famulari writes:

> On Wed, Oct 17, 2018 at 12:47:26AM -0400, Mike Gerwitz wrote:
>> On Tue, Oct 16, 2018 at 21:20:30 -0400, Christopher Lemmer Webber wrote:
>> > https://www.libssh.org/2018/10/16/libssh-0-8-4-and-0-7-6-security-and-bugfix-release/
>> >
>> > seems serious?
>> 
>> Very... Fortunately that's libssh and not OpenSSH[0], but with that said,
>> it does appear to be packaged in Guix and there are a couple packages
>> that use it.

Ha, sorry for the scare.

> Patch at <https://bugs.gnu.org/33067>

Yay, thanks Leo!

Re: Promoting the GNU Kind Communication Guidelines?

[Christopher Lemmer Webber]

Thorsten Wilms writes:

> On 29/10/2018 09.59, Björn Höfling wrote:
>> In law, there is the term of "conduct implying an intent". So even not
>> signing anything you could argue that by sending a bug or a patch you
>> silently agree with the community guidelines, CoC, etc. You enter the
>> community be interacting the first time. And will be judged by their
>> guidelines.
>
> It used to be that you could pick a Free Software project and send a patch.
>
> Now sending a patch is supposed to imply agreeing to the equivalent of
> an EULA? Everyone is expected to welcome that as progress?

Submitting code to a project under a copyleft license is also agreeing
to policy.

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Christopher Lemmer Webber]

Mark H Weaver writes:

> Christopher Lemmer Webber  writes:
>
>> Thorsten Wilms writes:
>>
>>> On 29/10/2018 09.59, Björn Höfling wrote:
>>>> In law, there is the term of "conduct implying an intent". So even not
>>>> signing anything you could argue that by sending a bug or a patch you
>>>> silently agree with the community guidelines, CoC, etc. You enter the
>>>> community be interacting the first time. And will be judged by their
>>>> guidelines.
>>>
>>> It used to be that you could pick a Free Software project and send a patch.
>>>
>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>> an EULA? Everyone is expected to welcome that as progress?
>>
>> Submitting code to a project under a copyleft license is also agreeing
>> to policy.
>
> What is the basis for this claim?
>
> While I'm generally in favor of the CoC, I strongly oppose the idea that
> submitting a patch or communicating with us implies automatic agreement
> to our policies.
>
> We should not claim that someone has "agreed" to anything without their
> conscious knowledge and consent.  Even if the law would allow us to make
> such a claim, we should not do it because it would be unjust.
>
> Please, it is enough to make our policies clear and highly visible, to
> encourage people to read them, and to give the lead project maintainers
> the authority to issue warnings, and if deemed necessary, to ban people
> from our communication channels who repeatedly or severely violate our
> CoC.  I support that practice, as long as it's used judiciously, and I
> have every confidence in Ludovic and Ricardo to do so.
>
> We do _not_ need to extract promises from contributors ahead of time
> that they will follow our policies, and I think it's a bad idea to ask
> them to.  It's a worse idea to claim that they've done so implicitly
> without their knowledge or consent.
>
>   Mark

I suspect we do not disagree Mark, but the way in which you replied to
me makes it sound like we do, so let me clarify. :)  My short reply was
because I was trying to demonstrate, in few words, that the message I
was replying to was introducing an inaccuracy.  I did not clarify what
that was, but I will below.

We accept many patches from users where the user does not sign an actual
document, but their patch and their name applied on the top is
considered sufficient evidence that they have declared their code to be
licensed under the GPL.

But I should clarify the claim I was making, since I was not trying to
say that the legal or mechanistic aspects of this were equivalent.  Let
me quote what was I was replying to:

>>> It used to be that you could pick a Free Software project and send a patch.
>>>
>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>> an EULA? Everyone is expected to welcome that as progress?

The statement above makes it sound like the Code of Conduct is
dramatically new.  My claim here was that in both cases, there is a
policy the community has adopted.  One is legal and copyleft, the other
is behavioral and a code of conduct.  In both cases, your participation
in this community is dependent on your willingness to agree to respect
the policies and norms that the group upholds.

What's interesting to me is that this isn't new at all, it's just
codified for some specific things.  The Code of Conduct is not a legal
document, it is a set of policies about community norms.  Many of these
norms already existed, and the same process (speak to the person, ask
them to change their behavior, if we can't fix it, yes they may be
banned) has existed for a long time in free software circles.  What is
new from the code of conduct perspective is making explicit what some of
those norms are, and what participants can expect if they are not
upheld.

I have seen some accusations that this is censorship or an overreach or
equivalent to an EULA to have these norms enforced.  And yet the free
software community, and especially GNU projects, have long been
enforcing of policies.  Copyleft is a mechanism for enforcement of
policies by law, but even beyond that, I think most of the members of
this group would find it perfectly acceptable to ban someone who began
to post patches to the list under a license that was incompatible with
the GPL and which "poisoned" our ability to use them upon seeing them.
The former is a legal agreement, the latter is a norms agreement, but
they are both policy, and by participating in our group in general you
have an understanding that these policies exist.  The code of conduct
does not provide a legal enforcement mechanism, so the EULA comment in
that sense does n

Re: Guix receives donation from the Hanshake project!

[Christopher Lemmer Webber]

Leo Famulari writes:

> On Mon, Dec 03, 2018 at 10:34:23PM +0100, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> We have some good news: the Hanshake project donated to GNU and the FSF,
>> and part of that goes to us!
>> 
>>   
>> https://gnu.org/s/guix/blog/2018/gnu-guix-receives-donation-from-the-handshake-project/
>> 
>> Concretely that’ll be 90KUSD for Guix (the FSF keeps 10% of the 100K we
>> got).  As we wrote in the blog post above, that opens the door to quite
>> a few things and I’m sure we’ll put the money to good use.  Now we need
>> your help to carry out projects such as an expansion of the build farm!
>
> Wow, that's awesome!
>
>> A big thanks to Handshake for this awesome gift and to the FSF for
>> handling it!
>
> Yes, thanks very much to all involved!

That's incredible!

Re-approaching package tagging

[Christopher Lemmer Webber]

Hello,

In the past when we've discussed package tagging, I think Ludo' has been
against it, primarily because it's a giant source of bikeshedding.  I
agree that it's a huge space for bikeshedding... no space provides more
bikeshedding than naming things, and tagging things is a many to many
naming system.

However, I will say that finding packages based on topical interest is
pretty hard right now.  If I want to find all the available roguelikes:

cwebber@jasmine:~$ guix package -A rogue
hyperrogue  10.5out gnu/packages/games.scm:3652:2
roguebox-adventures 2.2.1   out gnu/packages/games.scm:1047:2

Hm, that's strange, there's definitely more roguelikes that should show
up than that!  A more specific search is even worse:

cwebber@jasmine:~$ guix package -A roguelike
cwebber@jasmine:~$

What I should have gotten back:
 - angband
 - cataclysm-dda
 - crawl
 - crawl-tiles
 - hyperrogue
 - nethack
 - roguebox-adventures
 - tome4

So I only got 1/4 of the entries I was interested in in my first query.
Too bad!

I get that we're opening up space for bikeshedding and *that's true*.
But it seems like not doing so makes things hard on users.

What do you think?  Is there a way to open the (pandora's?) box of tags
safely?

 - Chris

What's up with the .texi files always "changing"?

[Christopher Lemmer Webber]

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   doc/contributing.de.texi
modified:   doc/contributing.fr.texi
modified:   doc/guix.de.texi
modified:   doc/guix.fr.texi

Why does this keep happening?  If these are autogenerated, why are they
committed into git?  If they aren't autogenerated, why are they changing?

Re: Re-approaching package tagging

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> I’m surprised you don’t mention --search, which is more appropriate than
> -A (‘-A’ is here only to search among package names):
>
> --8<---cut here---start->8---
> $ guix package -s roguelike | recsel -p name,relevance
> name: roguebox-adventures
> relevance: 7
>
> name: tome4
> relevance: 5
>
> name: crawl
> relevance: 5
>
> name: crawl-tiles
> relevance: 5
>
> name: cataclysm-dda
> relevance: 5
>
> name: angband
> relevance: 5
> --8<---cut here---end--->8---
>
> I’m very much in favor of improving ‘--search’ until we’re happy with
> the results it gives.
>
> WDYT?
>
> Ludo’.

I'm embarassed to say I didn't know about --search :)

Re: Re-approaching package tagging

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hello,
>
> zimoun  skribis:
>
>>> And how the regexp works ?
>>> I am not able to find some doc... I am diving in the code but it is
>>> not easy to find. :-)
>>
>> If I understand well, basically the code is here, right?
>> http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/package.scm#n754
>>
>> And the regexp engine comes from the module (ice-9 regex), right?
>> Documented there:
>> https://www.gnu.org/software/guile/manual/html_node/Regular-Expressions.html#Regular-Expressions
>
> Yes, just plain POSIX regexps.
>
>>> For example, how to search package with the name emacs and not the name 
>>> emacs-
>>> or how to search package with the name emacs and with the decription GNU?
>>> The '-s foo -s bar' is OR. What about the AND?
>>> etc.
>>
>> This needs more than the actual implementation, right?
>
> Having multiple -s flags makes it an “or” but it influences the
> relevance score:
>
>   
> https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-package.html#index-searching-for-packages
>
> So if you take the results with the highest score, that’ll probably be
> those that match all the regexps.
>
> HTH!
>
> Ludo’.

I wonder for keywords that would be awkward to "force" into the
description if we could have an "extra keywords" section?  Then we can
skip tagging, but in case a package's description didn't comfortably fit
that word, you can still find it by it.  Then it's not separate tagging,
just extra words to find a package by that the description didn't say.

WDYT?

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

[Christopher Lemmer Webber]

Adonay Felipe Nogueira writes:

> Em 24/09/2018 11:14, Ludovic Courtès escreveu:
>> Christopher Lemmer Webber  skribis:
>>>- There's also Google's recent work with Magenta/Fuschia.  From what
>>>  I've read, architecturally this looks right.  I think the reason
>>>  for worry here is the same difficulty the community has had to
>>>  build actual community and libre distributions on top of the
>>>  Android ecosystem could apply here.
>> 
>> Indeed.
>> 
>> We could also mention MINIX, which many of us are already using daily.
>> :-)
>> 
>> Putting aside Fuschia, I think the Hurd and MINIX are by far the
>> solutions that require the less work to be in a state where people with
>> “regular needs” like the rest of us to switch (MINIX is probably in that
>> state already.)
>> 
>> The Hurd already has a very advanced POSIX C library, which is not
>> negligible, especially compared to the other OSes.  Much progress has
>> been made in recent years wrt. drivers (using the Rump kernel in
>> particular.)  There are of course serious shortcomings, in particular
>> lack of 64-bit and SMP support.  But fixing these is relatively “little
>> work” in the grand scheme of things.
>> 
>> To put this in perspective, consider Linux namespaces: they have already
>> seen years of evolution, and the story of user namespaces shows that
>> it’s far from complete.
>
> I don't know if what I'll say will be off-topic here given that this
> list is about Guix development, not on general free/libre software
> activism, but please forgive me anyways.
>
> So, my worry is that if we somehow were to support Fuchsia and if it
> were to be not strong auto-upgradable copyleft with community-oriented
> enforcement, then we could actually loose the freedoms of the software
> for the end user. This thought was initially presented by Eben Moglen
> during one of his talks[1], but I just tried to bring the issue to Guix.
>
> [1]
> https://media.libreplanet.org/u/libreplanet/m/the-free-software-movement-in-the-age-of-trump/

It's a valid concern, and one that applies to seL4 which I have
advocated on this thread as well.  However, I think we've seen a big
difference in "community-run" free software projects under a lax license
(which tend to stay free and good for the users) and "corporate-run"
throw-the-code-over-the-wall projects (which tend to be less so, and
Android is a great example).

However in a sense this is why we need to push, as a community, to get
our feet into the door of a secure, ocap-powered system for users.
Because users *need* and will want that security; systems are just so
dangerously insecure.  If we don't get the community in there, we'll
leave it up to and Android-like sorry state where you've just got some
large powers and users and communities desparately trying to figure out
how to stay free underneath them, and most users not even trying or know
how they could.

Re: FOSDEM 2019: Thank you!

[Christopher Lemmer Webber]

I'm sorry I missed the Guix days, it seems like it was quite an event!
But all the Guile stuff in the minimalist languages room was great.
Clearly 2018 was a great year for Guile and Guix... I'll place a bet
that 2019 will be just as great or better :)

Pjotr Prins writes:

> Thank you everyone for this great FOSDEM with the GNU Guix days: it
> was just great to see everyone and all the interactions! I feel much
> inspired to try GNU Hurd, new Guix features, the new Guile build
> system and even Racket (oops).
>
> A special thank you to the speakers and everyone who helped out!
>
> People came from really far, e.g., Argentina, USA (4x!), Canada,
> Israel.  Wonderful to have you with us! Thanks you so much for making
> the effort!
>
> Especially I wish to thank Manolis Ragkousis for doing so many of the
> preparations and dealing with the ungrateful job of organizing the
> programme and chasing speakers.
>
> I wish to thanks Andreas Enge, Efraim Flashner and Chris Marusich:
> thank you so much for helping out with the minimalistic languages
> devroom! We have run one of the most intense devrooms with so many
> back-to-back talks and no pauses.
>
> And finally I wish to thank all the people working on GNU Guix and GNU
> Mes. You make it all so interesting :). I feel 2019 is going to be an
> exceptional year.
>
> The videos should be coming online in the coming days (see the
> schedule
>
> https://fosdem.org/2019/schedule/track/minimalistic_languages/
>
> If you were a speaker, please click the link that was sent to you to
> release the video. Slides can still be uploaded through pentabarf.
>
> For those still heading back: safe travels! And hope to see everyone
> next year in health and great spirits!
>
> Pj.

Re: [PATCH] gnu: Add ungoogled-chromium.

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hi bill-auger,
>
> bill-auger  skribis:
>
>> re: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg9.html
>>
>> i would like to remind readers of the guix-devel list that it was
>> discussed some months ago, why no FSDG distros currently distribute
>> chromium[1] - it appeared at that time, that most people in that
>> discussion were in agreement that chromium should not be included in
>> guix; and marius was instead hosting it in a private repo, as not to
>> taint the main guix repos with dubious software - has there been a
>> notable break-through since then?
>
> It’s not entirely clear to me what the problems are, to be honest.
> Marius listed specific issues that were addressed by the patches; others
> then pointed out at additional issues that ungoogled-chromium fixes,
> which Marius took into account; what’s left now?
>
> I understand you’re skeptical about Chromium, but we cannot base
> decisions based on vague skepticism.  If you know of issues that are
> still unaddressed, please do list them.
>
> I’d also like to stress that, if Chromium is eventually included in
> Guix, we are committed to fixing it or removing it should someone later
> discover that it does not comply with the FSDG (that’s the “Commitment
> to Correct Mistakes” section of FSDG.)

+1 ... If concrete problems are found, by all means those should be
raised and addressed.  Otherwise I really think we ought to merge this
work.

It's time to build "guix deploy"

[Christopher Lemmer Webber]

Hi,

This has come up several times.  A lot of us want "guix deploy".
Personally, I'm running a variety of Debian servers and one Guix server
and I am terrible at maintaining all of them.

It's time for Guix Deploy... or it's time for me to give up and use
something like Ansible + Debian.  (Egads!  I don't want to do that.)

David's thoughts on this are below, and here's the original thread:

Original thread can be found at the links below:
  https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html
  https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
  https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html

There is a heavily, heavily bitrotted branch named "wip-deploy" where
David originally started exploring these ideas.  Conveniently, it's all
in one commit:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy&id=fcd6fc84e493d05be1f7590ee77509c81ac315c2

That seems like a good starting point.  But I know David feels that with
real-world experience in devops type work that actually things would be
a bit different than what's described in his original email.  I'm not
sure myself what would be different.  It would be helpful to hear Dave
weigh in on that point.

Maybe Dave and I can meet up IRL now that we're close enough to each
other to chat about it.  But I know it's less fun than it used to be for
Dave to consider this because now that's Dave's actual job... but all
the more reason we need Dave's wisdom! :)


David Thompson writes:

> Hey folks,
>
> I'm writing this in an attempt to "think out loud" about a deployment
> automation tool for GuixSD.
>
> Guix needs a NixOps[0] equivalent.  NixOps is the Nix project's
> deployment automation tool.  I read the source code[1] a bit, and here's
> what I've learned about it:
>
> * The central data type is a "deployment", which is a Nix expression
>   consisting of one or more named OS configs
>
> * The OS configs contain extra data that specifies the target platform:
>   VirtualBox, EC2, NixOS container, etc.  Each platform implements the
>   generic MachineDefinition and MachineState interfaces.
>
> * The 'nixops' command is stateful.  It stores necessary state about
>   deployed systems in a special directory ($HOME/.nixops by default),
>   such as the IP addresses of the deployed systems.  Because of this,
>   each deployment needs a unique identifier.
>
> * Deployments may be parameterized by values known only at deploy time.
>   This covers cases such as a web application server needing to know the
>   IP address of the database server.
>
> * There are useful subcommands to check the status of each system or ssh
>   into one of them.
>
> Here's a rough outline of how I'm thinking of implementing similar
> features in Guix:
>
> * Introduce new data types:
>
>   * : The generic interface type for implementing deployment
> targets.  Its fields hold procedures for various actions like
> 'provision', 'destroy', 'boot', or 'reboot'.  I haven't determined
> the precise list of actions needed, but it will become apparent as
> platforms are added.
>
>   * : Describes a single system in the deployment.  Contains a
> name string, an , and a .
>
>   * : Contains a name string and a list of  and
> procedures.  Procedures in the list should accept an argument
> containing the deployment results of the non-parameterized machines
> and return a .
>
> * Use a simple s-exp deployment state format.  Store the state in
>   $HOME/.config/guix by default.
>
> * Implement a 'guix ops' subcommand roughly the same actions as NixOps:
>   create, deploy, start, stop, destroy, list, info, check, ssh, etc.
>
> * The bulk of the work will be creating  objects that actually
>   provision various types of resources.  For prototyping, a
>   'local-vm-platform' would be enough to test that the whole system
>   works.
>
> Anyone want to join in on this brainstorming party?  Your thoughts are
> appreciated!
>
> [0] http://nixos.org/nixops/
> [1] https://github.com/NixOS/nixops

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Pjotr Prins writes:

> I am also interested in 'guix deploy', especially if it can run on top
> of Debian and handle HOME directories. Currently using a mixture of
> sysadmin heroics and my own cfengine style Ruby deploy tool ;). Happy
> to switch, test and hack. But not enough time to run with it.
>
> Pj.

I am trying to think, "what can I do to help advance things further",
and maybe my best next step is to write minimalist user stories with
mockups of configurations and deployments based off of davexunit's old
branch?  That way I can think through what's there and what I need yet.

 - Chris

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Pjotr Prins writes:

> I am also interested in 'guix deploy', especially if it can run on top
> of Debian and handle HOME directories.

I should also say: I'm not considering how "guix deploy" could or would
handle running on top of Debian *or* handle HOME directories.  Both of
those feel out of scope to me, but for different reasons:

 - "guix deploy" would deploy by, well, building guix system profiles
   and then pushing them out.  So I'm not sure how Debian would fit in
   there...
 - Mutable state of the system is hard to tackle.  We might need to
   tackle some degree of it, but I think that would be in
   post-install-hooks type things which might sometimes do that
   on server?

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Thompson, David writes:

> Hi Chris,
>
> Here we go again, eh? :)
>
>>   https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
>>   https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html
>>
>> There is a heavily, heavily bitrotted branch named "wip-deploy" where
>> David originally started exploring these ideas.  Conveniently, it's all
>> in one commit:
>>
>>   
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy&id=fcd6fc84e493d05be1f7590ee77509c81ac315c2
>
> Useful for context, but the code can probably be tossed at this point.

OK!

>> That seems like a good starting point.  But I know David feels that with
>> real-world experience in devops type work that actually things would be
>> a bit different than what's described in his original email.  I'm not
>> sure myself what would be different.  It would be helpful to hear Dave
>> weigh in on that point.
>
> Sure, since 2015 I've become the lead devops person at my company, so
> I like to think I'm a bit wiser now.

:)

>> Maybe Dave and I can meet up IRL now that we're close enough to each
>> other to chat about it.  But I know it's less fun than it used to be for
>> Dave to consider this because now that's Dave's actual job... but all
>> the more reason we need Dave's wisdom! :)
>
> We could meet up IRL about this and I can try to make an earnest
> effort to deal with this. I think what has stopped me in the past is
> the sheer size of this project, and maybe dramatically scaling down
> the scope will allow us to get *something* out the door.

Yes I think we shouldn't allow ourselves to get too overwhelmed!  We
should give the warnings that this is an alpha system in alpha (soon
beta?) software and we don't guarantee that the api will be stable :)

Furthermore, I think if we put an emphasis on composable layers, and
start with the simplest lower layers, and then add some other layers
above it (and actually the different use cases you lay out may actually
swap out which layers are above this), then I think we could be good?

> Here are some general use-cases I know about for deployments, roughly
> ordered from small scale to large scale, and least complex to most
> complex:
>
> * Managing a physical machine or two that have been given memorable
> names that you update in-place (home scale)
> * Managing a virtual machine or two that have been given memorable
> names that you update in-place (blog scale)

In the past we have discussed storing "deployment state", and where and
how we would store it.  I will make the argument that for these two
cases, we actually don't need state!  We can just do the simplest thing
possible: build the system derivation for each of these machines, log in
and see if the system already has that derivation running, and if not
copy over the closure and install it as the system state.  This could
be entirely declarative.

I think initially we can ignore entirely the issue of provisioning an
initial guix image.  We can also ignore things like getting the right
public keys and configuring the initial authority of how you can be
authorized to copy over that data.

> * Managing a large number of virtual machines whose names don't matter
> that you update in-place (proto-cloud scale)
> * Managing a large number of virtual machines whose names don't matter
> that are replaced when there is an update (cloud scale)
> * Managing 1 or more clusters of physical machines (datacenter scale)
> * Managing 1 or more clusters of physical machines and virtual
> machines ("corporation with a datacenter that is moving some stuff to
> the cloud" scale)

For all these, I think there can be one or more abstraction layers that
build on top of the same declarative primitives described above.  And
this may be where state comes in; since you don't really know what the
identifiers are ahead of time, but you do need to keep track of them,
yes we do want to serialize the state somewhere.

> There are, of course, more scenarios to consider (haven't even touched
> upon things like a Kubernetes cluster), but this is enough to
> illustrate the point that is a great diversity in setups.  How many
> machines are there? Are the bare metal, virtual machines, or a mix of
> both? In the case of virtual machines, are updates applied in an
> immutable fashion or not?  If immutable, which technique (blue-green,
> rolling release, etc.)?  It makes my head spin to think about all the
> use-cases.

... I don't know anything about the things you said above so I guess
that would be nice to go over in person :)

I think maybe my ignorance is helpful for optimism in this case!

> So... let's start small. Can we write a tool that handles in-place
> updates to machines (physical or virtual) whose name and IP address we
> know well (our special pet servers) without precluding the possibility
> of scaling up to more sophisticated architectures?  This would address
> the "home" and "blog" scale items above, which is probably what most
> of the 

Re: [GNU-linux-libre] [PATCH] gnu: Add ungoogled-chromium.

[Christopher Lemmer Webber]

Julie Marchant writes:

> I don't understand what's so complicated about this issue. In justice
> systems, we adopt an "innocent until proven guilty" system because you
> can't really prove innocence, only guilt.

I agree with Julie's point here.  The fear that "there might be
something nonfree in there"... well, that's true for our entire system.
We also have a similar issue with security vulnerabilities... there are
almost certainly security vulnerabilities in the sum total of our
packages.  Which packages though?  And what are they?  We don't know the
answer to either of those.  Our response is to take action if and when
problems are found.  That's the same approach we should take here.

 - Chris

Re: Meltdown / Spectre

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Tobias Geerinckx-Rice  writes:
>
>
>> I think the real and thornier question for GuixSD
>> is: if the recent CPU vulnerabilities require a
>> microcode update to fully mitigate, then how do we
>> square not recommending proprietary globs like
>> this in official channels with giving users all
>> knowledge required to decide for themselves?
>
> Yes, this exactly.
>
> It's a unique (hm, is it?) situation pitting the ideals of copyleft
> against the welfare of users. If an opaque microcode is required to
> successfully mitigate these bugs, what is the moral stance to take?
>
> I don't have an answer and that's why I'm asking here :)

It seems to me that this is one of those "you need to upgrade some
lowest level firmware which you already didn't have access to in order
to keep your system secure"... I dunno if GuixSD should ship something,
but I wouldn't blame anyone updating their microcode for something this
critical.

That said, if the microcode were free in the first place, this would
probably be a lot easier to deal with?

Re: Improving Shepherd

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hopefully it’s nothing serious: Fibers doesn’t rely on anything
> architecture-specific.

I think it relies on epoll currently?  But I think there should be no
reason other architectures couldn't also be supported.

Re: What’s next?

[Christopher Lemmer Webber]

Pierre Neidhardt writes:

> Hi,
>
> Off the top of my head:
>
> - Optimize the man page database update during profile builds.
>
> - File search.
>
>   (I did work on it a year ago, it's stuck, would need help from people
>   familiar with Cuirass.)

That sounds interesting.  What does it mean?  Would it help me figure
out which commands come from which package?

A feature I remember being cool they had enabled by default on Ubuntu
back in the day was:

  $ crawl-tiles
  Not found.  Maybe "sudo apt-get install crawl-tiles"?

So for us:

  $ crawl-tiles
  Not found.  Maybe "guix package -i crawl-tiles"?

The curious thing about this though... it seems to require knowledge of
the *outputs*.

To invoke this manually, a user could type:

  # Queries curiass or some sort of build system, similar to guix weather
  $ guix search --binary crawl-tiles
  Found in:
   - crawl-tiles

> - A GUI.
>
>   https://gitlab.com/daym/guix-gui.git seems to be a good starting point.

Oh wow!  I'm going to give this a try.

> Maxim Cournoyer  writes:
>
>> * Add .deb and .rpm formats for 'guix pack'.
> [...]
>> * guix environment --fhs (file hierachy standard)
>
> Oh my, awesome ideas!!!  (These 2 in particular.)
>
> Cheers!

I'll add one that I *should* finish: I should get the setuid stuff
done.  IIRC it's like, two minor tweaks away from being done and
bitrotting... I've been busy...

Maybe I could do it towards the end of the following week?  Would be
good to get the damned thing done... and then finally get postfix in,
too.

Re: RISCV porting effort

[Christopher Lemmer Webber]

Exciting... thanks for this update!  Even if not "usable" quite yet,
it's thrilling to see progress on this. :)


Efraim Flashner writes:

> Last week my HiFive Umatched¹ board came and was quite the object of
> interest at the local computer store as I picked up a case, PSU and
> graphics card.
>
> Couple of observations about the board first:
> It boots very slowly. I think it takes about 5 minutes from power-on to
> being able to sign in at TTY1.
> It has an NVMe slot which I haven't populated yet.
> Ubuntu has an image for the board² which booted up just fine and I'm
> using, since I didn't want to spend too long getting Debian to run on
> the board.
> Upstream u-boot support was merged days ago³ so we should be able to add
> support to our u-boot package soon-ish™.
>
> Porting Guix comes with two parts: building the bootstrap-tarballs and
> adding support for the new architecture in (gnu packages bootstrap).
> Support for riscv was added to GCC with 7.1.0 so I had to bump the
> bootstrap GCC to 7 (and adjust some inputs), and guile-2.0.14 didn't
> known the endianness of riscv64 so instead of patching it I bumped the
> bootstrap guile to 3.0. I uploaded my bootstrap-tarballs to my regular
> spot after signing them and switched over to the riscv machine.
>
> Building Guix from sources is much easier thanks to the work of Vagrant,
> I was able to apt install most of the dependencies on riscv. The
> packaged version of guile-zlib was too old in 21.04 so I built that from
> source (0.1.0 is available in Debian experimental), and I also had to
> build gnutls from source for the guile-3.0 bindings. I added the riscv
> binaries to (gnu packages bootstrap) and temporarily switched the
> raw-build function to look for 3.0 guile libraries instead of 2.0.
>
> Where I'm at right now:
> Downloading using the daemon (builtin:download) fails currently, it says
> it doesn't have permissions to open-file to write downloaded files to
> the store.
> I haven't built anything using the bootstrap binaries to see if they
> actually work yet.
>
>
> (ins)efraim@unmatched:~$ neofetch --off
> efraim@unmatched
> 
> OS: Ubuntu 21.04 riscv64
> Host: SiFive HiFive Unmatched A00
> Kernel: 5.11.0-1007-generic
> Uptime: 3 days, 15 hours, 57 mins
> Packages: 782 (dpkg)
> Shell: bash 5.1.4
> Terminal: /dev/pts/0
> CPU: (4)
> GPU: NVIDIA GeForce GT 730
> Memory: 350MiB / 15995MiB
>
> (ins)efraim@unmatched:~$ lscpu
> Architecture:riscv64
> Byte Order:  Little Endian
> CPU(s):  4
> On-line CPU(s) list: 0-3
> Thread(s) per core:  4
> Core(s) per socket:  1
> Socket(s):   1
> L1d cache:   32 KiB
> L1i cache:   32 KiB
> L2 cache:2 MiB
>
>
> ¹https://www.sifive.com/boards/hifive-unmatched
> ²http://cdimage.ubuntu.com/releases/21.04/release/
> ³https://source.denx.de/u-boot/u-boot/-/commit/d8729a114e1e98806cffb87d2dca895f99a0170a

Re: Raco importer

[Christopher Lemmer Webber]

Brett Gilio writes:

> Pierre Neidhardt writes:
>
>> That'd be awesome!
>
>
> Maybe i'm jumping the gun here. But once I get a working raco importer,
> would there be any objection to moving racket from scheme.scm to
> racket.scm, and subsequently placing raco derived imports in
> racket-xyz.scm?
>
> Brett Gilio

This would be extremely awesome, and is actually something I really need
myself.  I'd be willing to test and assist with implementation where I
can if you can take the lead!

 - Chris

Re: building "guix deploy"

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> Hi there!

Hi Ludo!  Thanks for your reply.

> "Thompson, David"  skribis:
>
>> Chris Webber and I spent the morning chatting about how we want to
>> approach making "guix deploy" a reality and then started hacking on it
>> in the afternoon.  Although we weren't able to complete a working
>> prototype by the end of the day, we were able to get pretty close.  We
>> created a 'guix deploy' CLI to build derivations for any number of
>> remote systems on a local workstation and initiate the transfer to the
>> remote systems, but we encountered a difficult to debug SSH error that
>> blocked our progress:
>>
>> sending 85 store items (0 MiB) to 'test.activitypub.rocks'...
>> exporting path 
>> `/gnu/store/ylcdmrj3vf00ixdcjvkl3mbs8f5i9w8l-git-minimal-2.20.1.drv'
>> ;;; [2019/03/09 17:32:48.792589, 0] write_to_channel_port: [GSSH
>> ERROR] Remote channel is closed: #> 541a220>
>> Backtrace:
>>   10 (apply-smob/1 #)
>> In ice-9/boot-9.scm:
>> 705:2  9 (call-with-prompt _ _ #)
>> In ice-9/eval.scm:
>> 619:8  8 (_ #(#(#)))
>> In guix/ui.scm:
>>   1654:12  7 (run-guix-command _ . _)
>> In guix/scripts/deploy.scm:
>>  72:8  6 (guix-deploy . _)
>> In srfi/srfi-1.scm:
>> 640:9  5 (for-each # …)
>> In guix/scripts/deploy.scm:
>> 74:20  4 (_ _)
>> In gnu/machine.scm:
>> 58:22  3 (_ _ _ _)
>> In guix/ssh.scm:
>> 313:4  2 (send-files # _ _ # _ # …)
>> In guix/store.scm:
>>1504:7  1 (export-paths # _ # …)
>> In unknown file:
>>0 (put-bytevector # …)
>>
>> ERROR: In procedure put-bytevector:
>> Throw to key `guile-ssh-error' with args `("write_to_channel_port"
>> "Remote channel is closed" #
>> #f)'.
>>
>> If anyone knows what might be going on here and how we could resolve
>> it, your input would be much appreciated!  We verified via the sshd
>> logs that we were indeed successfully establishing a connection.
>
> Error reporting in (guix ssh) is, ahem, not as good as it could be.
>
> Apparently the SSH channel was closed prematurely, which could be due to
> a number of things:
>
>   1. Are ‘guix’ and ‘guile’ in $PATH on the remote machine, for
>  non-interactive shells?
>
>   2. Is ‘guix repl’ available in the remote machine?
>
> You can test this with:
>
>   ssh HOST guile --version
>   ssh HOST guix repl --version

Yep, both respond with
  guile (GNU Guile) 2.2.4
and
  guix (GNU Guix) 0.16.0-10.2637cfd
respectively.

> Also, does ‘guix copy’ fail similarly when sending files to that host?

It seems it does:

cwebber@jasmine:~/devel/librelounge-audio$ guix copy 
--to=test.activitypub.rocks pidgin
guile: warning: failed to install locale
sending 37 store items (336 MiB) to 'test.activitypub.rocks'...
;;; [2019/03/11 10:39:25.573104, 0] write_to_channel_port: [GSSH ERROR] Remote 
channel is closed: #
Backtrace:
  11 (primitive-load "/home/cwebber/.config/guix/current/bin…")
In guix/ui.scm:
  1654:12 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
829:9  9 (catch _ _ # …)
829:9  8 (catch _ _ # …)
In guix/status.scm:
810:4  7 (call-with-status-report _ _)
In guix/scripts/copy.scm:
81:27  6 (send-to-remote-host _ _)
In guix/ssh.scm:
313:4  5 (send-files # _ _ # _ # …)
In guix/store.scm:
  1505:12  4 (export-paths # _ # …)
  1485:22  3 (export-path # _ # …)
   683:13  2 (process-stderr _ _)
   646:10  1 (dump-port # # …)
In unknown file:
   0 (put-bytevector # …)

ERROR: In procedure put-bytevector:
Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote 
channel is closed" # #f)'.

I wonder what got screwed up!

>> Once we're past this blocking issue and are able to transfer OS
>> closures to remote systems, we plan to write a modified version of
>> switch-to-system that uses guile-ssh to switch remote symlinks for the
>> active system and run the activation script.  We'll save
>> upgrade-shepherd-services for later, as it is quite a bit more
>> complex.
>
> My plan is to have ‘guix system reconfigure --host=host.example.org’.
> To do that, I thought about the following plan:
>
>   1. Isolate the effectful part of reconfigure (basically
>  ‘switch-to-system’).
>
>   2. Implement ‘remote-eval’, which takes a gexp and an SSH session and
>  evaluates the expression remotely, copying the gexp inputs as
>  needed.
>
>   3. Have ‘reconfigure’ use either ‘eval’ or ‘remote-eval’ to evaluate
>  the effectful bits of reconfigure.

This sounds like the right approach to me.

> #1 is a bit annoying because we need to untangle code so that we can
> easily put it all “on the build side.”  In particular, I think we’ll
> have to change (guix graph), used by ‘upgrade-shepherd-services’, so
> that it no longer depends on ‘%store-monad’.
>
> That said, it’s probably a good idea to take a shorter path in the
> meantime to unlock progress on ‘guix deploy’!
>
>> There's not a lot of code yet, but you can check it out in the
>> wip-deploy2 branch.  Currently, the only supported use-case is running
>>

Re: What is the philosophy behind shepherd?

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> I must preface this email with the assurance that there is no agenda
> behind my questions; only ignorance and curiosity. Please read it with
> that in mind!
>
> A couple weeks ago, I was watching a video called "The Tragedy of
> Systemd"[1]. In it, Benno Rice discusses the need for a so-called
> "system layer" which is responding to the many complicated signals
> coming into a system from thing happening (e.g. networks becoming
> available/unavailable, VPNs mucking with DNS and routing tables, etc.).
> He characterizes systemd and things like it as something that lives
> between kernel-space and user-space.
>
> It really opened my eyes to why something like systemd exists rather
> than sticking with the old-style init systems.
>
> Does Shepherd take the stance that it is, or is to become a "system
> layer"?
>
> If so, one of the criticisms he has for systemd is that instead of
> pulling in protocols for things (e.g. DNS), and allowing best-of-breed
> software to handle the implementation, it has pulled in the
> responsibility for implementation as well. Any thoughts on that?
>
> [1] - https://www.youtube.com/watch?v=o_AIw9bGogo

I think one interesting thing, to me, is that I agree that this is
desirable, but I think a microkernel + services approach would be much
better architecture.  In such a world then shepherd's role would be to
bootstrap the key services needed to talk to each other.

In other words, I think systemd exists in many ways to make up for the
limitations of a monolithic kernel approach.  In that way, it makes
sense, but I think we could do better with a different fundamental
infrastructure.

But maybe I am wrong!

 - Chris

Should we upgrade openssl?

[Christopher Lemmer Webber]

>From the openssl website:

> Note: The latest stable version is the 1.1.1 series. This is also our
> Long Term Support (LTS) version, supported until 11th September
> 2023. Our previous LTS version (1.0.2 series) will continue to be
> supported until 31st December 2019 (security fixes only during the
> last year of support). The 1.1.0 series is currently only receiving
> security fixes and will go out of support on 11th September 2019. All
> users of 1.0.2 and 1.1.0 are encouraged to upgrade to 1.1.1 as soon as
> possible. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support
> and should not be used.

I know, everyone's going to groan hearing this, but maybe given the
above it would make sense to upgrade to the openssl 1.1.0 series before
Guix 1.0 gets out the door?

I guess that would probably require a massive rebuild of core packages
though.

 - cwebb

Re: Guix on Purism's Librems?

[Christopher Lemmer Webber]

Katherine Cox-Buday writes:

> Hey all,

Hi Katherine!

> I brought this up in IRC tonight, and I thought I'd cast a net on the
> mailing list to collect experiences. I am considering purchasing a
> Librem laptop, and I was curious how Guix runs on it. Would anyone who
> has these laptops (especially if you have a version with the TPM and
> head) care to write up an experience-report?

I have a LibreM laptop.  I'm not using it at the moment because I need
to send it in for repairs (and keep procrastinating on that) but I'll
say that GuixSD worked just fine out of the box.

> Also, would it make sense for us to have a package specifically for
> hardware like this to make it easier to build install images for the
> machines? Even if the packages don't do much, there is still value in
> declaring that the specific configuration of hardware has been
> investigated, and is supported.

I'm happy to publish my guix configuration if it helps, though I think
it isn't anything particularly special for the laptop to work.

That said I think I'd love more reports about what laptops/machines
people have gotten to work with GuixSD and what challenges they've run
into in general.  It would be nice to collect that.

 - Chris

Re: GNU Guix 1.0.0 released

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> We are thrilled to announce the release of GNU Guix 1.0.0!

Massive congrats to the whole Guix community!  Woohoo :)

Re: Introducing myself

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> Hello, guix-devel!
>
> My name is Jakob L. Kreuze, and I was accepted into Google's Summer of
> Code program this year to work on "guix deploy," the deployment
> automation tool for GuixSD that's been discussed in [1] and [2]. I just
> wanted to briefly introduce myself to the list, as you'll likely be
> seeing postings from me about "guix deploy" on a regular basis.
>
> Officially, my work doesn't start until the 27th of this month; the next
> few days will be spent ensuring that I have a working development
> environment and familiarizing myself with both the code and the
> development practices of Guix.
>
> I look forward to working with all of you.
>
> Jakob
>
> [1]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00145.html
> [2]: https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00114.html

Hi Jakob!  Fancy seeing you here ;)

As said in person today, the vision of "guix deploy" is what originally
got me interested in Guix.  I'm so thrilled you're going to be working
this summer on making that a reality.

Welcome aboard!
 - cwebb

Re: Progress on 'guix deploy'

[Christopher Lemmer Webber]

Jakob L. Kreuze writes:

> Hello, Guix!
>
> Apart from a few patches and my introductory email about a month ago,
> I've been pretty silent. I feel it's time to finally break that silence,
> let people know where progress has been made, and request some feedback
> on the code I've written so far.

Hi Jakob!  Thanks for sending this to the list. :)

> As a quick refresher, my GSoC project this summer is 'guix deploy', a
> deployment automation tool for GuixSD that's been discussed more
> thoroughly in [1] and [2]. Development has taken place on my personal
> branch of Guix, specifically the 'wip-deploy' branch [3], and is
> represented by three new Scheme source files:
>
> - 'gnu/machine.scm', which provides an abstraction for /something/ that
>   can be deployed to in a heterogeneous deployment. Currently, the only
>   concrete implementation of this is the simple case of in-place updates
>   to machines running SSH whose names and IP addresses we know.
> - 'gnu/tests/machine.scm', which implements some tests for
>   'gnu/machine.scm'. This is where I'm most interested in receiving
>   feedback. More on that later.
> - 'guix/scripts/deploy.scm', which implements the rudimentary
>   command-line interface for 'guix deploy'.
>
> The command-line interface hasn't really been fleshed out yet, but if
> you'd like to play around with it, it takes a "deployment" file as a
> parameter, which is a Scheme file looking something like the following:
>
> #+BEGIN_SRC scheme
> (use-modules ...)
>
> (define %system
>   (operating-system
>(host-name "gnu-deployed")
>(timezone "Etc/UTC")
>(bootloader (bootloader-configuration
> (bootloader grub-bootloader)
> (target "/dev/sda")
> (terminal-outputs '(console
>(file-systems (cons (file-system
> (mount-point "/")
> (device "/dev/vda1")
> (type "ext4"))
>%base-file-systems))
>(services
> (append (list (service dhcp-client-service-type)
>   (service openssh-service-type
>(openssh-configuration
> (permit-root-login #t)
> (allow-empty-passwords? #t
> %base-services
>
> (list (make 
> #:host-name "localhost"
> #:ssh-port 5556
> #:system %system))
> #+END_SRC
>
> Basically, you attach an 'operating-system' declaration to a 'machine'.
> In this case, 'sshable-machine' is the specific type of 'machine' that
> we're deploying to (one that's running an SSH daemon and has a known IP
> + port + hostname).
>
> I've found that the GuixSD QEMU images work well for playing around with
> this, provided that you add the SSH service to the system configuration
> and start it. In the case of this deployment file, I had a GuixSD guest
> with port 22 forwarded to my host's port 5556. You'll also need to set
> up some sort of public key auth in your SSH config. The current code
> isn't capable of handling other forms of SSH authentication.
>
> In terms of implementation, GOOPS feels like a bit of an unusual choice
> when juxtaposed with the rest of the Guix codebase, but I've come to
> really enjoy it. I'll roll with it for now, since I think it will make
> it easier to flesh out the vocabulary for specifying deployments.

I also want to clarify: I know that GOOPS code isn't quite contemporary
style for Guix, but David Thompson and I encouraged Jakob to spend the
minimal amount of time necessary focusing on doing polymorphism in a
clever way, as this is what Dave and I found was slowing us down in our
initial prototype code.

It's possible we could/should move to something else, but that's the
motivation there.

> The implementation of '' is doing what
> 'switch-to-system' and 'install-bootloader' in 'guix/scripts/system.scm'
> do, but in terms of data that can be sent with 'remote-eval'. I imagine
> the code will make more sense if you read both simultaneously.
>
> Okay, on to the test suite.
>
> My understanding of the system test suite (tests run with 'check-system'
> as opposed to those run with 'check') is that the meat of the test code
> exists in a G-Expression and should _not_ be interacting with the store
> of the machine running the test suite (i.e. that's the reason we're
> using marionettes in the first place). 'gnu/tests/install.scm' seems to
> be somewhat of an exception, and because the code in '(gnu machine)'
> depends heavily on having access to a store, I've tried to extend what's
> done in 'gnu/tests/install.scm' so that my tests have access to store
> while instrumenting the marionettes.
>
> To be specific, the chicken and egg scenario I'm working around is that
> the SSH daemon on the marionette needs to be running in order for
> 'deploy-os' to work, but I can't call 'deploy-os' from the test
> G-Expression because the store wouldn't be accessible then.
>
> My gut is t

New episode of Libre Lounge out interviewing Ludovic about Guix!

[Christopher Lemmer Webber]

Hey all!  I'm really excited to say that there's a new episode of Libre
Lounge out (a podcast I co-host) and we interview Ludovic Courtès about
Guix!  There's a lot of cool stuff in here, including some discussion
about reproducibily, Mes, etc.

  
https://librelounge.org/episodes/episode-23-guix-with-ludovic-court%C3%A8s.html

Have a listen!  Tell your friends!
 - Chris

Re: Suggest another way of importing GNU Guix GPG key

[Christopher Lemmer Webber]

That's probably the right way to do it for now.

Alex Vong writes:

> Hello,
>
> One solution would be to download the keyring from
>  and verify the signature in
> the following way:
>
>   $ gpg --keyring ./gnu-keyring.gpg --verify guix-1.0.1.tar.gz.sig 
> guix-1.0.1.tar.gz
>
> Cheers,
> Alex
>
> dftxb...@free.fr writes:
>
>> Hello,
>>
>> SKS keyservers are currently under attack
>> (https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f) - 
>> the attack can cause a GPG client to freeze completely and mess the
>> GPG installation completely.
>>
>> I suggest GNU Guix proposes another way of importing the GPG keys so
>> that users will not suffer from this problem.
>>
>> There's another, newer, keyserver, proposed in this gist, that is run
>> by new software that doesnt suffer from this attack. See:
>> https://keys.openpgp.org/about/news#2019-06-12-launch
>>
>> However, that keyserver is not replicated. You could either use that
>> one or simply offer a download of the key over TLS with verification
>> against installed CAs, as secure as this can get.
>>
>> Regards