Re: Run .deb or .rpm packages

[Vagrant Cascadian]

On 2021-12-12, Efraim Flashner wrote:
> On Fri, Dec 10, 2021 at 10:30:36AM +0100, Hartmut Goebel wrote:
>> Le 8 décembre 2021 14:46:24 GMT-05:00, "André A. 
>> Gomes"  a écrit :
>> 
>> > --8<---cut here---start->8---
>> > $ sudo dpkg -i foo-package.deb
>> > dpkg: error: unable to access the dpkg database directory 
>> > /gnu/store/902w5i1j38r33l6p871dyhng19zj1phk-dpkg-1.20.9/var/lib/dpkg: 
>> > Read-only file system
>> > --8<---cut here---end--->8---
>> > 
>> > Any ideas?  I don't know much about .deb or .rpm.
>> 
>> Beside Julien's objections: There might be legitimate use of installing .deb
>> or .rpm packages and they might even work. E.g. i one wants to install free
>> software provided as a .deb only and at the moment does not have the time to
>> create a package definition for it.
>> 
>> So, "dpkg" and "rpm" should at least work :-)
>> 
>> Regarding the error show above: One would need to add "--localstatedir=/var"
>> to the config flags (not sure whether this would build, then, since most
>> probably "make install" will try to create "/var/lib/dpkg" which will fail
>> in the build container.
>> 
>
> When I packaged dpkg I deliberately didn't "fix" the localstatedir or
> any other flags since Guix doesn't support installing packages from .deb
> archives. Similar to the rpm package it is primarily used for the other
> parts of the package.
>
> Vagrant has said in the past though that Guix's dpkg can be used to
> install packages on Debian based systems.

I don't think I would recommend trying that! It *might* technically work
with some changes to the guix dpkg package, it seems a bit risky; you'd
probably have a "native" dpkg available and I'm not sure I see the
benefit then.

I mostly found it useful to extract (dpkg-deb --extract PACKAGE.deb,
dpkg-deb --control PACKAGE.ded) and inspect .deb packages from Guix
System.

Whenever I need a Debian environment on Guix System I usually just use
debootstrap to create a chroot and work from there.


Thanks everyone for Debianing your Guixs and Guixing your Debians!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Loading Common Lisp Libraries with GNU/Guix in a REPL

[raingloom]

On Sun, 12 Dec 2021 11:01:34 -0600
Katherine Cox-Buday  wrote:

> Edouard Klein  writes:
> 
> I also don't know the canonical way, but I do it a different way. I'm
> wondering what the simpler way to do things is? I know nothing about
> rlwrap. But here's how I do things:
> 
> Depending on the project, I may have a =guix.scm= package defined for
> it or not. This only changes how I invoke =guix shell=, not the
> technique.
> 
> From emacs, I run slime: with =C-u M-x slime=. It prompts me for
> which lisp I want to run, and then I type =guix shell -D -- sbcl=.
> This seems pretty simple.
> 
> I think I did have to include this in my bash initialization though.
> I'm not sure if it will work without it, or if there's a more correct
> way to do what I'm doing:
> 
> #+begin-src bash
> if [ -n "${GUIX_ENVIRONMENT}" ]; then
> export
> XDG_CONFIG_DIRS="${GUIX_ENVIRONMENT}/etc:${XDG_CONFIG_DIRS}" export
> XDG_DATA_DIRS="${GUIX_ENVIRONMENT}/share:${XDG_DATA_DIRS}" export
> PATH="${GUIX_ENVIRONMENT}/bin:${PATH}" export
> PATH="${GUIX_ENVIRONMENT}/sbin:${PATH}" fi
> #+end_src
> 
> I hope this helps!
> 
> --
> Katherine
> 

I think Ambrevar's Lisp REPL page mentions something about sourcing
Bash scripts from Emacs? Maybe?
https://ambrevar.xyz/lisp-repl-shell/index.html

Re: Loading Common Lisp Libraries with GNU/Guix in a REPL

[Katherine Cox-Buday]

Edouard Klein  writes:

I also don't know the canonical way, but I do it a different way. I'm wondering 
what the simpler way to do things is? I know nothing about rlwrap. But here's 
how I do things:

Depending on the project, I may have a =guix.scm= package defined for it or 
not. This only changes how I invoke =guix shell=, not the technique.

>From emacs, I run slime: with =C-u M-x slime=. It prompts me for which lisp I 
>want to run, and then I type =guix shell -D -- sbcl=. This seems pretty simple.

I think I did have to include this in my bash initialization though. I'm not 
sure if it will work without it, or if there's a more correct way to do what 
I'm doing:

#+begin-src bash
if [ -n "${GUIX_ENVIRONMENT}" ]; then
export XDG_CONFIG_DIRS="${GUIX_ENVIRONMENT}/etc:${XDG_CONFIG_DIRS}"
export XDG_DATA_DIRS="${GUIX_ENVIRONMENT}/share:${XDG_DATA_DIRS}"
export PATH="${GUIX_ENVIRONMENT}/bin:${PATH}"
export PATH="${GUIX_ENVIRONMENT}/sbin:${PATH}"
fi
#+end_src

I hope this helps!

--
Katherine

Re: sbcl-ningle: permission denied

[Guillaume Le Vaillant]

The package for ningle has a custom phase changing the name of the
compiled files, this is why when you try to load it ASDF thinks that the
system has not been compiled yet, tries to compile it and fails because
it can't write the compiled files to the read-only "/gnu/store/...".

I don't know if this custom phase is necessary or if it's just
a leftover from the way asdf-build-system worked in the past...

Could you try the attached patch removing the custom phase and see if
everything works fine? If yes I'll push it to master.
From 78afaccecf95e4087564217c40f4d4eb4843357c Mon Sep 17 00:00:00 2001
From: Guillaume Le Vaillant 
Date: Sun, 12 Dec 2021 10:40:24 +0100
Subject: [PATCH] gnu: cl-ningle: Fix location of fasl files.

* gnu/packages/lisp-xyz.scm (sbcl-ningle)[arguments]: Remove custom phases.
---
 gnu/packages/lisp-xyz.scm | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/gnu/packages/lisp-xyz.scm b/gnu/packages/lisp-xyz.scm
index e25d0f5488..c292b91b89 100644
--- a/gnu/packages/lisp-xyz.scm
+++ b/gnu/packages/lisp-xyz.scm
@@ -4855,30 +4855,7 @@ (define-public sbcl-ningle
   (build-system asdf-build-system/sbcl)
   (arguments
;; TODO: pull in clack-test
-   '(#:tests? #f
- #:phases
- (modify-phases %standard-phases
-   (delete 'cleanup-files)
-   (delete 'cleanup)
-   (add-before 'cleanup 'combine-fasls
- (lambda* (#:key outputs #:allow-other-keys)
-   (let* ((out (assoc-ref outputs "out"))
-  (lib (string-append out "/lib/sbcl"))
-  (ningle-path (string-append lib "/ningle"))
-  (fasl-files (find-files out "\\.fasl$")))
- (mkdir-p ningle-path)
- (let ((fasl-path (lambda (name)
-(string-append ningle-path
-   "/"
-   (basename name)
-   "--system.fasl"
-   (for-each (lambda (file)
-   (rename-file file
-(fasl-path
- (basename file ".fasl"
- fasl-files))
- fasl-files)
-   #t)
+   '(#:tests? #f))
   (native-inputs
`(("sbcl-prove" ,sbcl-prove)))
   (inputs
-- 
2.34.0



signature.asc
Description: PGP signature

Re: Run .deb or .rpm packages

[Efraim Flashner]

On Fri, Dec 10, 2021 at 10:30:36AM +0100, Hartmut Goebel wrote:
> Hi,
> 
> Le 8 décembre 2021 14:46:24 GMT-05:00, "André A. 
> Gomes"  a écrit :
> 
> > --8<---cut here---start->8---
> > $ sudo dpkg -i foo-package.deb
> > dpkg: error: unable to access the dpkg database directory 
> > /gnu/store/902w5i1j38r33l6p871dyhng19zj1phk-dpkg-1.20.9/var/lib/dpkg: 
> > Read-only file system
> > --8<---cut here---end--->8---
> > 
> > Any ideas?  I don't know much about .deb or .rpm.
> 
> Beside Julien's objections: There might be legitimate use of installing .deb
> or .rpm packages and they might even work. E.g. i one wants to install free
> software provided as a .deb only and at the moment does not have the time to
> create a package definition for it.
> 
> So, "dpkg" and "rpm" should at least work :-)
> 
> Regarding the error show above: One would need to add "--localstatedir=/var"
> to the config flags (not sure whether this would build, then, since most
> probably "make install" will try to create "/var/lib/dpkg" which will fail
> in the build container.
> 

When I packaged dpkg I deliberately didn't "fix" the localstatedir or
any other flags since Guix doesn't support installing packages from .deb
archives. Similar to the rpm package it is primarily used for the other
parts of the package.

Vagrant has said in the past though that Guix's dpkg can be used to
install packages on Debian based systems.

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

Re: sbcl-ningle: permission denied

[edk]

Hi !

The store (everything under /gnu/store) is read-only. The only way to
edit it is when building a package.

If cl-ningle does not call asdf:make, then you'll need to edit the
package so that it does.

Maybe there's a way to tell asdf to put build products somewhere else
than near the source code, in which case you may point to somewhere
outside the store ?

Good luck,

Edouard.
jgart  writes:

> Hi Guixers,
>
> Just reporting this issue.
>
> I had sbcl and sbcl-ningle in my profile.
>
> When I try to build ningle I get the error below:
>
> ```
> λ rlwrap sbcl
> This is SBCL 2.1.9, an implementation of ANSI Common Lisp.
> More information about SBCL is available at .
>
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses.  See the CREDITS and COPYING files in the
> distribution for more information.
> CL-USER(1): (asdf:make :ningle)
> WARNING: System definition file 
> #P"/gnu/store/zwkhqlyijf8bwpm3a70f7ly978w2knqw-sbcl-flexi-streams-1.0.19/share/common-lisp/sbcl/flexi-streams/flexi-streams.asd"
>  contains definition for system "flexi-streams-test". Please only define 
> "flexi-streams" and secondary systems with a name starting with 
> "flexi-streams/" (e.g. "flexi-streams/test") in that file.
>
> debugger invoked on a SB-INT:SIMPLE-FILE-ERROR in thread
> #:
>   Error opening 
> #P"/gnu/store/8jn98z4pr2r9dglsw37a70y8nl6ksb9i-sbcl-ningle-0.3.0-1.50bd4f0/lib/common-lisp/sbcl/ningle/context-tmpGHU3ALSV.fasl":
>
> Permission denied
>
> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
>   0: [CONTINUE ] Retry opening.
>   1: [USE-VALUE] Try opening a different file.
>   2: [RETRY] Retry
>  compiling # "ningle/context" "file-type">.
>   3: [ACCEPT   ] Continue, treating
>  compiling # "ningle/context" "file-type">
>  as having been successful.
>   4: Retry ASDF operation.
>   5: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
>  configuration.
>   6: Retry ASDF operation.
>   7: Retry ASDF operation after resetting the
>  configuration.
>   8: [ABORT] Exit debugger, returning to top level.
>
> (SB-IMPL::FILE-PERROR 
> #P"/gnu/store/8jn98z4pr2r9dglsw37a70y8nl6ksb9i-sbcl-ningle-0.3.0-1.50bd4f0/lib/common-lisp/sbcl/ningle/context-tmpGHU3ALSV.fasl"
>  13 "Error opening ~S" 
> #P"/gnu/store/8jn98z4pr2r9dglsw37a70y8nl6ksb9i-sbcl-ningle-0.3.0-1.50bd4f0/lib/common-lisp/sbcl/ningle/context-tmpGHU3ALSV.fasl")
> ```
>
> WDYT?