bug#63717: [Shepherd] Replaced services remain active in the shadows
Ludovic Courtès skribis: > Ludovic Courtès skribis: > >> What seems to happen is that, in both cases, the registry points to the >> new service; ‘herd status’ & co. look up the service by name in the >> registry, find the new service, and rightfully show that it’s stopped. >> But the old service still exists: it’s no longer in the registry, but it >> handles SIGCHLD, incoming connections on port 22, etc. > > Fixed in Shepherd commit 63af9d7c4460b55953bfa199ea44ac0114289b64. > > We’ll have to make a new release soon. Released 0.10.1, and updated the package in commit b8f89ab2c9d0c459ce158ee16a4f4a6542b88ce0. Ludo’.
bug#63634: bug#63646: [PATCH] substitute: If a server's nar URL is 404, try the next one(s).
Hi, Ludovic Courtès skribis: > Ludovic Courtès skribis: > >> + (define (try-fetch choices) >> +(match choices >> + (((uri compression file-size) rest ...) >> + (guard (c ((and (pair? rest) (network-error? c)) >> + (warning (G_ "download from '~a' failed, trying next >> URL~%") >> + (uri->string uri)) > > I realized we can change ‘network-error?’ to ‘http-get-error?’ above. > Otherwise, we could find ourselves trying several nar URLs on the same > server when the error is ETIMEDOUT or ECONNREFUSED, which would be a > waste of time. Pushed as 8af9a2aa5fa2fa5b00234c1cbe12e9aff60888a0. Ludo’.
bug#63728: GHC cannot find lrt
2023-05-26 15:44 ant...@mailbox.org: The gcc-toolchain:static workaround fixes the rt problem, but now the binaries aren't linked to libgmp and libffi, even though gmp and libffi packages are installed in the profile: Maybe there should be a ghc-toolchain package that has libgmp and libffi as inputs, and makes sure GHC links them correctly? Hm. Alternatively, we could just fix gcc-toolchain (so that it includes rt). But maintainers (understandably) hesitate because this will trigger a world rebuild.
bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading
On 2023-05-24 12:27, Christopher Baines wrote: Hey! On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't reboot or halt. root@hamal ~# halt Service root is not running. 1: /gnu/store/y6w0xix15cq08qasmq75f04yzgbl98jx-shepherd-0.9.3 FWIW, this has happened to me a bunch of times, I just never reported it. Sometimes I was able to just login as root and run herd start root to fix it. I have an impression, from the "bunch of times" I've experienced, that service root doesn't fail to work because of the system reconfigure, but for some other reason. Best regards, David
bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading
Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and >> (defined? (quote transient?)) (map (# ?) ?)). >> May 24 11:17:02 localhost shepherd[1]: Evaluating user expression >> (register-services (primitive-load "/gnu/st?") ?). >> May 24 11:17:03 localhost shepherd[1]: Service host-name has been started. >> May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started. >> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1 >> May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1 >> May 24 11:18:41 localhost shepherd[1]: Exiting shepherd... >> May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; >> sending -337 SIGKILL. >> May 24 11:23:55 localhost shepherd[1]: Service root is not running. > > The grace period expiration thing is probably due to the fact that > shepherd is no longer processing signals, as I described here: > > https://issues.guix.gnu.org/63736 > > Could you share all of /var/log/messages (possibly privately, and > limiting to “shepherd” lines) starting from when the machine booted? > I’d like to see if there are hints of something that went wrong. The machine is hamal (one of the HoneyComb's) and I've added a user for you now and added the SSH key from maintenance.git. So you should be able to: ssh l...@hamal.cbaines.net Your users password is also in your home directory. signature.asc Description: PGP signature
bug#63787: udev-rules-service inoperable for some rules
Hi Felix,
Am Montag, dem 29.05.2023 um 08:25 -0700 schrieb Felix Lechner:
> Hi,
>
> A brief thread from guix-devel about trying to use MAC-based names
> for network interfaces [1] shall be incorporated herein by reference.
>
> [1]
> https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00192.html
>
> On Wed, May 17, 2023 at 6:14 PM Felix Lechner
> wrote:
> >
> > In a concession to Liliana's opposition, I retitled the bug to
> > sidestep the question of the MAC-based names as a default setting.
>
> It was not enough of a concession.
Heads up, that was not a nice way of phrasing things – at least as I, a
non-native English speaker take it. To me, "concession" implies some
backdrop of a fight between opposing forces, whereas I do see the
problem you're facing but want to find a better solution. In other
words, we share a goal.
> In Guix, many custom rules like the following—namely those that use
> values determined by udevadm—are inoperable.
>
> > (udev-rules-service 'net-name-mac
> > (udev-rule
> > "79-net-name-mac.rules"
> > "
> > SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> > ")))
>
> The issue is that udevadm looks in the installation folder for udev
> rules. In standard distros, that works fine because the installation
> folder and the runtime folder are the same. Unfortunately, that is
> not so for Guix. The installation folder is in the store.
For the record, I'm not sure whether udevadm is the sole component at
play here. Sure, it's a tool you may invoke at the command line, but
the big daemon thingy, that's udevd.
> The way I understand our strategy in Guix, we construct another,
> aggregate folder with links to rules in /etc/udev/rules.d. (That
> location also happens to be the installation directory for many
> traditional distros.) I proposed a local patch that causes udevadm to
> look in that folder instead. [2] It replaces one line in the source
> code.
>
> [2] https://issues.guix.gnu.org/63508#12
>
> Liliana, who kindly reviewed my patch, disagreed with that solution.
> For reasons I do not fully understand, she prefers a more generalized
> solution via an environmental variable called EUDEV_RULES_DIRECTORY.
> [3] As far as I can tell, that variable is not provided by upstream.
> It was invented by a custom patch to Guix [4] and currently does not
> seem to work all the way.
>
> [3] https://issues.guix.gnu.org/63508#6
> [4]
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/eudev-rules-directory.patch
Note: EUDEV_RULES_DIRECTORY was implemented by Ludo in 2014 [6, 7]. In
one year and a little bit it will celebrate ten years of being with us.
I think it is allowed to grow up.
> Liliana insists on improving the environment variable
> EUDEV_RULES_DIRECTORY, while I have several issues with that.
Just as I take issue with not using an environment variable for the
purpose it serves :)
> For starters, my substitution is simpler.
Simpler is not always better. One might say that overwriting files as
you install packages is simpler than worrying about setting the right
symlinks, but Guix, being a functional distribution, does the latter.
> It is also a common packaging strategy in Guix. (I furthermore cannot
> envision setting the variable to any value other than
> /etc/udev/rules.d, although maybe the flexibility comes in handy one
> day.)
Supplying an environment where there previously was none is also a
common packaging strategy for Guix. The fact that said environment
variable was already introduced prior to my patch should tell you as
much.
> Mainly, however, I believe that her patch goes beyond the typical
> packaging activity.
Note how said environment variable already exists prior to this patch.
It is well within typical packaging activity.
> By implementing a new feature, the patch for EUDEV_RULES_DIRECTORY
> should really be sent upstream. I do not know whether that's already
> happened, but I am not convinced upstream would accept it.
I doubt that I'd need upstream permission to modify local patches that
haven't been accepted upstream yet. Granted, our patch could be sent
upstream, but at this point I feel like we've already diverged a little
bit from the usual scenario.
> In the latest 3.2.12 release, which does not work without further
> modifications in Guix, the upstream developers added a command-line
> option called '--root' to udevadm [5] that offers another solution to
> setting the runtime path. Unfortunately, that option does not change
> the default, which is the issue in this bug.
>
> [5]
> https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1c241f057f8c0a79/man/udevadm.8#L378C2-L380
You're again assuming that udevadm is the only component at play here.
I have yet to hear your reason for believing so.
> Finally, programming styles also differ. I have philosophical
>
bug#63789: Native compilation broken on the Hurd (with patch)
Hi! The commit 56759d30d9a817a9c9221c9468a4c4a59c9a4713 gnu: Switch to GCC 11. introduced a gratuitous dependency on coreutils-boot0 to gcc-boot0 by adding this atypical snippet --8<---cut here---start->8--- (snippet #~(begin ;; XXX: The GCC test suite contains files with non-ASCII file ;; names, which cannot be repacked by BOOTSTRAP-ORIGIN. Nor ;; can it be deleted from Guile, so resort to this evil hack. #$(origin-snippet (package-source gcc)) (system* #$(file-append coreutils-boot0 "/bin/rm") "-rf" "gcc/testsuite/go.test/test/fixedbugs/issue27836.dir")) --8<---cut here---end--->8--- This is problematic, because coreutils-boot0 doesn't build for the Hurd: coreutils needs hurd headers, and our hurd-headers-boot0 depends on...coreutils-boot0. Why was coreutils-boot0 used instead of the canonical delete-file-recursively? Anyway, as a first attempt, I tried adding --8<---cut here---start->8--- (define gcc-boot0/hurd ;; gcc-boot0 adds a dependency on coreutils-boot0, which does not build on ;; the Hurd. Move this origin definition to gcc-boot0 and remove ;; gcc-boot0/hurd in the next rebuild cycle. (package (inherit gcc-boot0) (source (bootstrap-origin (origin (inherit (package-source gcc)) (snippet #~(begin ;; XXX: The GCC test suite contains files with non-ASCII file ;; names, which cannot be repacked by BOOTSTRAP-ORIGIN. Nor ;; can it be deleted from Guile, so resort to this evil hack. #$(origin-snippet (package-source gcc)) (delete-file-recursively "gcc/testsuite/go.test/test/fixedbugs/issue27836.dir" --8<---cut here---end--->8--- and use that in %boot1-inputs...but as gcc-boot0 is used in more places that doesn't really work. So, until we can correct the gcc-boot0 snippet problem in the next rebuild cycle (how does that work now that we don't have core-updates anymore?, I made coreutils-boot0 build on the Hurd. See the patch below. Using this patch, I've just succeeded to build gcc-boot0: --8<---cut here---start->8--- root@guixydevel ~/src/guix/wip-hurd# ./pre-inst-env guix build -e '(@@ (gnu packages commencement) gcc-boot0)' --verbosity=1 The following derivation will be built: /gnu/store/669gwbfc96k5r8rv06d4cd10q7kpnkqn-gcc-cross-boot0-11.3.0.drv building /gnu/store/669gwbfc96k5r8rv06d4cd10q7kpnkqn-gcc-cross-boot0-11.3.0.drv... /gnu/store/3hl61ndnzqjrr07rywh2mfw58k81jchy-gcc-cross-boot0-11.3.0-lib /gnu/store/wbdza27aq1mab8blvswvd0g28n5pk982-gcc-cross-boot0-11.3.0 --8<---cut here---end--->8--- but now `guix build hello' seems to hang, so it a circular dependency might have been introduced somewhere. What a mess... WDYT? Greetings, Janneke >From 37f38eb35fff505da9bfad8cb1f5f250378f7648 Mon Sep 17 00:00:00 2001 Message-Id: <37f38eb35fff505da9bfad8cb1f5f250378f7648.1685370023.git.jann...@gnu.org> From: Janneke Nieuwenhuizen Date: Mon, 29 May 2023 10:34:42 +0200 Subject: [PATCH] gnu: commencement: coreutils-boot0: Fix native build for the Hurd. * gnu/packages/patches/coreutils-boot0-hurd_types.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/commencement.scm (coreutils-boot0)[arguments]: When building for the hurd, add new phase 'add-hurd_types.h' and use it. Add "ac_cv_member_struct_stat_st_author=no" and -Wl,-rpath for %bootstrap-libc to configure flags when building for the Hurd. Add make-flags with "IGNORE_UNUSED_LIBRARIES_CFLAGS=" to avoid -Wl,--as-needed, which undoes previous rpath option. --- gnu/local.mk | 1 + gnu/packages/commencement.scm | 56 + .../patches/coreutils-boot0-hurd_types.patch | 82 +++ 3 files changed, 122 insertions(+), 17 deletions(-) create mode 100644 gnu/packages/patches/coreutils-boot0-hurd_types.patch diff --git a/gnu/local.mk b/gnu/local.mk index 44aa0ba69b..d86a6763b2 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -1018,6 +1018,7 @@ dist_patch_DATA = \ %D%/packages/patches/converseen-hide-updates-checks.patch \ %D%/packages/patches/converseen-hide-non-free-pointers.patch \ %D%/packages/patches/cool-retro-term-wctype.patch \ + %D%/packages/patches/coreutils-boot0-hurd_types.patch \ %D%/packages/patches/coreutils-gnulib-tests.patch \ %D%/packages/patches/coq-fix-envvars.patch \ %D%/packages/patches/cppcheck-disable-char-signedness-test.patch \ diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm index a24c60ebf8..eb1377c01c 100644 --- a/gnu/packages/commencement.scm +++ b/gnu/packages/commencement.scm @@ -1997,24 +1997,46
bug#63787: udev-rules-service inoperable for some rules
Hi,
A brief thread from guix-devel about trying to use MAC-based names for
network interfaces [1] shall be incorporated herein by reference.
[1] https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00192.html
On Wed, May 17, 2023 at 6:14 PM Felix Lechner
wrote:
>
> In a concession to Liliana's opposition, I retitled the bug to
> sidestep the question of the MAC-based names as a default setting.
It was not enough of a concession.
In Guix, many custom rules like the following—namely those that use
values determined by udevadm—are inoperable.
> (udev-rules-service 'net-name-mac
> (udev-rule
> "79-net-name-mac.rules"
> "
> SUBSYSTEM==\"net\", ACTION==\"add\", NAME=\"$env{ID_NET_NAME_MAC}\"
> ")))
The issue is that udevadm looks in the installation folder for udev
rules. In standard distros, that works fine because the installation
folder and the runtime folder are the same. Unfortunately, that is not
so for Guix. The installation folder is in the store.
The way I understand our strategy in Guix, we construct another,
aggregate folder with links to rules in /etc/udev/rules.d. (That
location also happens to be the installation directory for many
traditional distros.) I proposed a local patch that causes udevadm to
look in that folder instead. [2] It replaces one line in the source
code.
[2] https://issues.guix.gnu.org/63508#12
Liliana, who kindly reviewed my patch, disagreed with that solution.
For reasons I do not fully understand, she prefers a more generalized
solution via an environmental variable called EUDEV_RULES_DIRECTORY.
[3] As far as I can tell, that variable is not provided by upstream.
It was invented by a custom patch to Guix [4] and currently does not
seem to work all the way.
[3] https://issues.guix.gnu.org/63508#6
[4]
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/eudev-rules-directory.patch
Liliana insists on improving the environment variable
EUDEV_RULES_DIRECTORY, while I have several issues with that. For
starters, my substitution is simpler. It is also a common packaging
strategy in Guix. (I furthermore cannot envision setting the variable
to any value other than /etc/udev/rules.d, although maybe the
flexibility comes in handy one day.) Mainly, however, I believe that
her patch goes beyond the typical packaging activity.
By implementing a new feature, the patch for EUDEV_RULES_DIRECTORY
should really be sent upstream. I do not know whether that's already
happened, but I am not convinced upstream would accept it.
In the latest 3.2.12 release, which does not work without further
modifications in Guix, the upstream developers added a command-line
option called '--root' to udevadm [5] that offers another solution to
setting the runtime path. Unfortunately, that option does not change
the default, which is the issue in this bug.
[5]
https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1c241f057f8c0a79/man/udevadm.8#L378C2-L380
Finally, programming styles also differ. I have philosophical
objections to the use of pointer arithmetic, although the upstream
code may have some of that, too.
With the discussion at an impasse, I am not sure how to proceed.
Eudev, which is an essential part of any modern Linux operating
system, is not working properly in Guix.
Liliana challenged me to "file a formal complaint." [6] I do not know
what that means and now filed this bug in hope of finding an
acceptable way forward. Maybe it is easier to discuss the reasoning
for one fix or another when the arguments for and against are not
separated by multiple versions of competing inline patches.
[6] https://issues.guix.gnu.org/63508#22
For the success of any group, it is essential that problems are being
solved. Perhaps someone with an independent perspective would be so
kind to comment and help bring this bug one step closer to being
closed. Thanks!
Kind regards,
Felix
cc: Liliana
bug#63440: Some python-pyelftools test failed
I am also running into the same issue. I am trying to package python-platformio, but python-pyelftools fails its check phase so it cannot be used as a dependency.
bug#62517: installer-dump-ed8ac2cb
On Sat, 20 May 2023 at 16:05, Graham Addis wrote: > > I never did get KVM enabled on my windows 10 box. > > I ended up doing a bare metal guix install on an old laptop I had, > which works fine, if a little slow. > > I'll close this. Thanks Simon > > On Tue, 16 May 2023 at 16:06, Simon Tournier wrote: > > > > Hi, > > > > Sorry for the late reply. > > > > On Wed, 29 Mar 2023 at 11:31, Graham Addis > > wrote: > > > > > qemu didn't like the -enable-kvm switch, so I left that out. > > > > I guess you need to enable KVM on your host distribution. On default > > Debian, I am running something like: > > > > 1. Check if =/dev/kvm= is there: =ls -l /dev/kvm= > > 2. Add the user to the KVM group > >#+begin_src shell > > sudo usermod -a -G kvm > > newgrp kvm > >#+end_src > > 3. If it does not work, then try: > >#+begin_src shell > > sudo chmod 777 /dev/kvm > >#+end_src > > > > Once KVM is enable, do you have still the same issue? > > > > Cheers, > > simon
bug#63394: guix pack and proot
Hi Guix,
I acknowledge the answers provided, but I'd like to emphasize that guix
pack won't run if proot is broken. This is a critical issue and a
temporary solution is simple enough: disable the tests for the current
proot version packaged.
Please check the patch attached.
--
André A. Gomes
Atlas Engineer - https://atlas.engineer/
>From 1c9ece50575f568c824be2274b7b4d874827f0bb Mon Sep 17 00:00:00 2001
From: "Andre A. Gomes"
Date: Mon, 29 May 2023 16:02:45 +0300
Subject: [PATCH] Fix proot.
---
gnu/packages/linux.scm | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 1be505d949..01f809d980 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -8212,12 +8212,9 @@ (define-public proot
(supported-systems '("x86_64-linux" "i686-linux"
"armhf-linux" "aarch64-linux" "i586-gnu"))
(arguments
- ;; Disable the test suite on armhf-linux, as there are too many
- ;; failures to keep track of (see for example:
- ;; https://github.com/proot-me/proot/issues/286).
- `(#:tests? ,(not (or (%current-target-system)
- (string-prefix? "armhf"
- (or (%current-system)
+ ;; Temporarily disable the tests until https://issues.guix.gnu.org/63284
+ ;; is solved.
+ `(#:tests? #f
#:make-flags '("-C" "src")
#:phases (modify-phases %standard-phases
(add-after 'unpack 'patch-sources
--
2.39.2
bug#63451: Guix pull not successful
hm. i will chalk it up to hardware/filesystem then! thank you for the time. On Tue, May 23, 2023 at 8:04 AM Simon Tournier wrote: > Hi, > > On Mon, 22 May 2023 at 23:31, a wrote: > > This: > > > ~ guix pull -l > > > > Generation 1 Feb 05 2023 20:46:03 > > guix 4b9e1e8 > > Generation 2 Feb 06 2023 10:23:38 > > guix a582d86 > > Generation 3 May 08 2023 07:32:24 > > guix e118b92 > > Generation 4 May 11 2023 13:02:21 > > guix d6f6b57 > > Generation 5 May 14 2023 21:53:47 (current) > > guix c5fa9dd > > is inconsistent with the initial report: > > > λ ~ guix pull > > [1259] > > Updating channel 'guix' from Git repository at ' > > https://git.savannah.gnu.org/git/guix.git'... > > Authenticating channel 'guix', commits 9edb3f6 to d6f6b57 (667 new > commits)... > > [...] > > > guix pull: error: You found a bug: the program > > '/gnu/store/s2rl9h1zmxx84iyk25ndmn7rmy9508dj-compute-guix-derivation' > > failed to compute the derivation for Guix (version: > > "d6f6b57766e95d2fa8af63d4460a2b303ca4d867"; system: "x86_64-linux"; > > host version: "1.4.0"; pull-version: 1). > > And as pointed previously, this last message is also inconsistent by > itself. > > > >> Well, can you share the output of “guix pull -l”? It would not explain > >> why the Guile ’module-gensym’ failed though. > > Well, since the error seems from: > > --8<---cut here---start->8--- > \Backtrace: > In ice-9/boot-9.scm: >222:29 19 (map1 (# (#) #) > # ?)) >222:29 18 (map1 (# (#) #) > (# ()))> # ?)) >222:17 17 (map1 (# sanitize-location> (# ?)) > In ice-9/psyntax.scm: > Exception thrown while printing backtrace: > Wrong type to apply: 129 > > > ice-9/boot-9.scm:3165:6: In procedure module-gensym: > Invalid read access of chars of wide string: "m-1bcbf699e1749862-28a08" > --8<---cut here---end--->8--- > > Well, I do not know if it’s possible to investigate more. Especially, > when you re-run “guix pull” and it passes. > > As Csepp is saying, maybe it comes from your hardware or your > filesystem. > > > Cheers, > simon >
bug#53580: shepherd's architecture
Hi Brian, On Mon, May 29, 2023 at 8:02 AM Brian Cully via Development of GNU Guix and the GNU System distribution. wrote: > > Erlang has had hot code reloading for decades Thank you for that pointer! I also had Erlang on my mind while reading Attila's message. > Lisp Flavoured Erlang exists if you want that syntax. There > would definitely be advantages to writing an init (and, indeed, > any service that needs 100% uptime) on top of the Erlang virtual > machine. “Twenty years from now you will be more disappointed by the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. Explore. Dream. Discover.” --- H. Jackson Brown Jr in "P.S. I Love You" Kind regards Felix
bug#63270: d-feet: Fails to build (Function does not take positional arguments)
I fix this in https://issues.guix.gnu.org/63270 and it's pending to be merged. You can also try d-spy which IMO it's very good alternate. -- Retrieve my PGP public key: gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC Zihao signature.asc Description: PGP signature
bug#53580: shepherd's architecture
Attila Lendvai writes: it doesn't seem to be an insurmontable task to make sure that guile can safely unlink a module from its heap, check if there are any references into the module to be dropped, and then reload this module from disk. the already runing fibers would keep the required code in the heap until after they are stopped/restarted. then the module would get GC'd eventually. this would help solve the problem that a reconfigured service may have a completely different start/stop code. and by taking some careful shortcuts we may be able to make reloading work without having to stop the service process in question. Erlang has had hot code reloading for decades, built around the needs of 100% uptime systems. The problem is more complex than it often appears to people who are used to how lisps traditionally do it. I strongly recommend reading up on Erlang's migration system. Briefly: you can't just swap out function definitions, because they rely on non-function state which needs to be migrated along with the function itself, and you can't do it whenever you want, because external actors may be relying on a view of the internal state. To accomplish this, Erlang has a lot of machinery, and it fits in to the core design of the language and runtime which would be extremely difficult to port over to non-Erlang languages. Doing it in Scheme is probably possible in an academic sense, but not in a practical one. OTOH, Lisp Flavoured Erlang exists if you want that syntax. There would definitely be advantages to writing an init (and, indeed, any service that needs 100% uptime) on top of the Erlang virtual machine. But going the other way, by porting Erlang's functionality into Scheme, is going to be a wash. in this setup most of the complexity and the evolution of the shepherd codebase would happen in the runner, and the other two parts could be kept minimal and would rarely need to change (and thus require a reboot). Accepting that dramatic enough changes to PID 1 are going to require a reboot seems reasonable to me. They should be even more rare than kernel updates, and we accept rebooting there already. -bjc
bug#63783: r-dismo bundles pre-built jars
The files dismo.jar and maxent.jar in the r-dismo package don’t have any associated source code and are not built from source. -- Ricardo
