emacs-lilypond-mode should we?

[jgart]

Hi,

Should we package this mode separately from lilypond as emacs-lilypond-mode?

https://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=tree;f=elisp;h=dc4d450a9f98433d04ac87057571ab58f98497c5;hb=HEAD

all best,

jgart

Re: Error when compiling file using Bigloo Scheme

[zimoun]

On Fri, 08 Jul 2022 at 18:53, Liliana Marie Prikler  
wrote:

> We don't typically propagate packages, especially not gcc-toolchain. 
> You should be able to swap that out for any other toolchain, e.g.
> another version of gcc-toolchain or perhaps even clang-toolchain.  I'm
> not sure about libunistring, libgc and pcre.  There is a somewhat
> similar bug in libgccjit not finding its own object files, which I find
> rather silly; search paths definitely need adjusting imho.


Well, indeed the convention is to not propagate some packages.  For
instance, it is similar with Haskell: the installation of GHC “guix
shell ghc” is not enough to have a working Haskell environment; it is
also required other packages as gcc-toolchain.

As I wrote elsewhere [1], I think Guix should provide ready-to-use
“compiler” toolsuite.  Other said, something like “bigloo-toolchain” or
“haskell-toolchain” or etc.

First, it eases the usuability; hiding plumbing details.  Second, it
eases the “swap out”; the application of a transformation appears to me
much easier because all is explicit instead of having beforehand
an implicit knowledge on the “compiler” itself.

Somehow, it was the rationale behind gcc-toolchain or gfortran-toolchain.


Cheers,
simon


1: 

Re: emacs-lilypond-mode should we?

[Efraim Flashner]

On Mon, Jul 11, 2022 at 02:10:36AM -0500, jgart wrote:
> Hi,
> 
> Should we package this mode separately from lilypond as emacs-lilypond-mode?
> 
> https://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=tree;f=elisp;h=dc4d450a9f98433d04ac87057571ab58f98497c5;hb=HEAD
> 
> all best,
> 
> jgart

I think it would be best to package it separately, and I'm pretty sure
that's already what is suggested. The two packages I have installed that
happen to have .el files installed also don't have them compiled to .elc
files. Best to keep it separate so it's done with all the automation of
the emacs-build-system.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[Joshua Branson]

Sorry for starting this centuries flame war, but I can't help but be
more and more impressed with OpenBSD.  It seems ideal for small scale
servers (aka NOT large databases).  It tries really hard to be secure by
default and has great documentation.  With OpenBSD it is easy to set up
a static website (httpd) and your own email server (openSMTPD, spamd,
and pf).

I would argue that the average user will find OpenBSD to be easier to
secure than the Linux kernel.  

The Hyperbola GNU/Linux team recently announced that they would ditch
Linux for OpenBSD. They are using the OpenBSD kernel and the OpenBSD
userland. And they are GPL-ing all of the code. It sounds like they will
have to replace 20% of said code.

https://www.hyperbola.info/

Though the website currently says "Donate to keep the project alive".
So that's not super reassuring...

Anyway, assuming that the HyperbolaBSD team accomplishes their goals,
would Guix System or Guix ever be able to run on HyperbolaBSD? I know
that Guix System ties itself to glibc. HyperbolaBSD does NOT use glibc
and probably never will. Would it be feasible/desireable for Guix & Guix
System to support a BSD kernel and alternative libc?  What about other
OSes?

Thanks,

Joshua

P.S.  I just recently came accross this guide for getting started with
OpenBSD on servers: http://si3t.ch/ah/en/toc/  I am really impressed
with how easy/awesome OpenBSD is.

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[indieterminacy]

On 12-07-2022 00:44, Joshua Branson wrote:

Sorry for starting this centuries flame war, but I can't help but be
more and more impressed with OpenBSD.  It seems ideal for small scale
servers (aka NOT large databases).  It tries really hard to be secure 
by

default and has great documentation.  With OpenBSD it is easy to set up
a static website (httpd) and your own email server (openSMTPD, spamd,
and pf).

I would argue that the average user will find OpenBSD to be easier to
secure than the Linux kernel.

The Hyperbola GNU/Linux team recently announced that they would ditch
Linux for OpenBSD. They are using the OpenBSD kernel and the OpenBSD
userland. And they are GPL-ing all of the code. It sounds like they 
will

have to replace 20% of said code.

https://www.hyperbola.info/

Though the website currently says "Donate to keep the project alive".
So that's not super reassuring...

Anyway, assuming that the HyperbolaBSD team accomplishes their goals,
would Guix System or Guix ever be able to run on HyperbolaBSD? I know
that Guix System ties itself to glibc. HyperbolaBSD does NOT use glibc
and probably never will. Would it be feasible/desireable for Guix & 
Guix

System to support a BSD kernel and alternative libc?  What about other
OSes?

Thanks,

Joshua

P.S.  I just recently came accross this guide for getting started with
OpenBSD on servers: http://si3t.ch/ah/en/toc/  I am really impressed
with how easy/awesome OpenBSD is.


I recall dicussing this topic area with you last year:
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00080.html
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00082.html
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00083.html
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00084.html
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00085.html
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00086.html

Im pleased that the Hyperbola community has been making strides.

Hopefully I can one day have an OpenBSD kernel overseeing Guix SD.


Kind regards,


Jonathan McHugh

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[Joshua Branson]

indieterminacy  writes:

>
> I recall dicussing this topic area with you last year:
> https://lists.gnu.org/archive/html/help-guix/2021-06/msg00080.html
> https://lists.gnu.org/archive/html/help-guix/2021-06/msg00082.html
> https://lists.gnu.org/archive/html/help-guix/2021-06/msg00083.html
> https://lists.gnu.org/archive/html/help-guix/2021-06/msg00084.html
> https://lists.gnu.org/archive/html/help-guix/2021-06/msg00085.html
> https://lists.gnu.org/archive/html/help-guix/2021-06/msg00086.html
>
> Im pleased that the Hyperbola community has been making strides.
>
> Hopefully I can one day have an OpenBSD kernel overseeing Guix SD.
>
>
> Kind regards,
>
>
> Jonathan McHugh

Looks like the most relevant bit to my question was here:
https://lists.gnu.org/archive/html/help-guix/2021-06/msg00078.html

The real problem will not be the languages (guile or C++), but the
system calls used by Guix.

Guix makes use of some recent (less than 2 decades) and somewhat
advanced features of the Linux kernel, such as namespaces.

To port Guix to another operating system such as BSD (including OSX),
one would have to translate these calls.

For example, Guix is the only software I've actually encountered that
can not run in SmartOS' emulation of Linux, because the system calls it
uses are not implemented there.

I would love for Guix to be a Multi Kernel package manager (I mean it
works on the Hurd also, but I have never encountered a Hurd user in real
life). My dream would be to port Guix to Plan 9 ;-)

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-06-28, Tobias Geerinckx-Rice wrote:
>>I am at a loss as to what to do then ... nothing and just have it be
>>unreproducible? embed a specific random number? come up with better
>>upstreamable patches?
>
> From upstream's response and my own biases and my reading of the room here, 
> I'd say #2.

Hrm.

I hear Efraim say better to have unique randomness and no substitutes,
and I hear Tobias say more or less it's ok as long as upstream is right
about it being ok to embed a specific prime as other random numbers get
mixed in at runtime...

I have a slight inclination towards making it non-substituteable, but I
may just be enamored of this as an interesting solution that most
distributions do not really have the option of taking. :)

Anyone else able to weigh in?

Or actually review the code?

If we can't find someone to review the code, seems like
non-substitutable is the safest approach ... at the guaranteed loss of
reproducibility. :/

Would love to resolve this issue one way or another.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: maradns reproducibility fixes and the merits of picking a random number

[Vagrant Cascadian]

On 2022-07-11, Vagrant Cascadian wrote:
> I hear Efraim say better to have unique randomness and no substitutes,
> and I hear Tobias say more or less it's ok as long as upstream is right
> about it being ok to embed a specific prime as other random numbers get
> mixed in at runtime...

Well, now that I hit send already, I guess another option is ... to have
both?

One package without patches that is not substitutable and not
reproducible, and one with patches that is verifyably reproducible and
substitutable?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

[Akib Azmain Turja]

Joshua Branson  writes:

> (I mean it
> works on the Hurd also, but I have never encountered a Hurd user in real
> life)

Really?  I found tons of bugs in the Hurd port, causing it to not even
boot properly.

-- 
Akib Azmain Turja

This message is signed by me with my GnuPG key.  It's fingerprint is:

7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5


signature.asc
Description: PGP signature