New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guix package #92

Closed
Ambrevar opened this Issue Apr 15, 2018 · 30 comments

Comments

6 participants
@Ambrevar
Contributor

Ambrevar commented Apr 15, 2018

I'm planning to package Next-browser for Guix.
Also see #89, #76 and #78.

@axd-v

This comment has been minimized.

axd-v commented May 8, 2018

Can't wait to try it on my guixsd install. GuixSD + Emacs + EXWM + Next browser.... the Lisp Machine is emerging in unexpected ways hehe

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented May 19, 2018

I've managed to run Next on GuixSD but packaging it properly will take some more time.

@spiderbit

This comment has been minimized.

spiderbit commented May 26, 2018

I would like to see that happen too, I am a Nixos user, I would love to give GuixSD a shot, but it still lacks lvm support. But I could at least use it in a vm to test nEXT-browser :D

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented May 27, 2018

@spiderbit Would you happen to know the state of Common Lisp-based packages on NixOS?

@spiderbit

This comment has been minimized.

spiderbit commented Jul 11, 2018

@Ambrevar sorry for not answering that so long, I was to lazy to answer and I think no answer was also a answer, because the answer is as you surely assumed no.

I have even problems installing or compiling that program manually so making a package on top of that with nixos which uses some weird special language for packaging doesn't help if you have 2 systems you don't really understand use both in one project is not what you wanna do, if you can help it.

I would be more happy to create a GuixSD Package sadly they still don't support lvm so I can't really use it. Well I could use it in a vm just to start the browser but also a far reaching endevour.

@spiderbit

This comment has been minimized.

spiderbit commented Jul 11, 2018

I start to wonder if it would not be best to create a docker or flatpack package as first stepstone.

It should not be that hard, basically start a basic I don't know debian docker image login compile it, and then look up how you start it from the outside in a X buffer.

I googled it in the past and at least the last part should not be that difficult. Before we create 20 distro-specific packages.

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Jul 12, 2018

I think I'm not too far from packaging Next for Guix.

For me the point of packaging for Guix is that you don't need docker, flatpack, etc. which in my opinion is not a good approach to the problem. They are many container formats and supporting each one of them is also a hassle.

See
https://www.gnu.org/software/guix/blog/2018/tarballs-the-ultimate-container-image-format/.
With guix pack, we end up with a truly universal tarball.

That and also the fact that Guix (or Nix) packages are reproducible and functional, they explicitly declare the transitive closure of each of their programs. With that knowledge, it's much easier to package for any other distro.

@spiderbit

This comment has been minimized.

spiderbit commented Jul 12, 2018

Of course if you get it done go for it :D
guix pack supports apperently even docker when I understand that right?

https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pack.html#index-Docker_002c-build-an-image-with-guix-pack

I didn't know about this pack feature, I knew that you can install guix into your distro, the problem with that aproach would be that I am not sure if nixos and guix would work together without problems, they both do heavy path manipulation operations and that might conflict.

A shebang to the host system with a lsb path from guix into the nixos system and it would not work :D

but this tarball and docker pack option seems to be the answer to all of that.

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Jul 12, 2018

No, it's much better than that! :p Guix does not even need docker, it solely relies on its functional properties to make "containers" fully stand-alone (shebangs are self-contained, so non-LSB issues should all be taken care of). Users don't even need a supporting application like docker.

Try it, it's amazing.

Also it should not conflict with Nix as Nix users /nix/store whereas Guix uses /gnu/store ;)

@spiderbit

This comment has been minimized.

spiderbit commented Jul 12, 2018

I just thought also it might be easier to create a docker because it's not functional you just have a virtual system you connect to it compile your stuff save it somehow start it with some parameter to the binary and you should be done. (quick / dirty)

But I am no expert, I would like to play around with guix itself bad sadly no lvm support which really sucks.

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Aug 24, 2018

I'm about half way into getting the Next package up and running for Guix.
I'm stuck at packaging mgl-pax at the moment. There is an issue with SWANK.

I've reported the issue there: slime/slime#457.

Would anyone have a clue about this? @jmercouris, @vindarel?

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 15, 2018

The above issue is now solve. I've packaged all Next dependencies for Guix and Next itself is building, but sadly it does not work properly. It only show a grey window and crashes on the first key press:

$ next-browser -v
Arguments parsed: (VERBOSE T) and NIL
S-W-M
Unhandled SB-PCL::NO-APPLICABLE-METHOD-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
                                                          {10006B85B3}>:
  There is no applicable method for the generic function
    #<STANDARD-GENERIC-FUNCTION NEXT::MODE (1)>
  when called with arguments
    (NIL).
See also:
  The ANSI Standard, Section 7.6.6

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10006B85B3}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1004BEF363}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1004BEF363}>)
2: (INVOKE-DEBUGGER #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1004BEF363}>)
3: (UIOP/IMAGE:HANDLE-FATAL-CONDITION #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1004BEF363}>)
4: (SB-KERNEL::%SIGNAL #<SB-PCL::NO-APPLICABLE-METHOD-ERROR {1004BEF363}>)
5: (ERROR SB-PCL::NO-APPLICABLE-METHOD-ERROR :GENERIC-FUNCTION #<STANDARD-GENERIC-FUNCTION NEXT::MODE (1)> :ARGS (NIL))
6: ((:METHOD NO-APPLICABLE-METHOD (T)) #<STANDARD-GENERIC-FUNCTION NEXT::MODE (1)> NIL) [fast-method]
7: (SB-PCL::CALL-NO-APPLICABLE-METHOD #<STANDARD-GENERIC-FUNCTION NEXT::MODE (1)> (NIL))
8: (NEXT::CONSUME-KEY-SEQUENCE)
9: (GOBJECT::CALL-WITH-RESTARTS #<FUNCTION (LAMBDA (INTERFACE::WINDOW INTERFACE::EVENT) :IN INTERFACE:START) {222D176B}> (#<GTK:GTK-WINDOW {1004114DA3}> #S(GDK:GDK-EVENT-KEY :TYPE :KEY-PRESS :WINDOW #<GDK:GDK-WINDOW {1004BC82B3}> :SEND-EVENT NIL :TIME 76652648 :STATE (:MOD2-MASK) :KEYVAL 108 :LENGTH 1 :STRING "l" :HARDWARE-KEYCODE 46 :GROUP 0 :IS-MODIFIER 0)))
10: ((LAMBDA (GOBJECT::CLOSURE GOBJECT::RETURN-VALUE GOBJECT::COUNT-OF-ARGS GOBJECT::ARGS GOBJECT::INVOCATION-HINT GOBJECT::MARSHAL-DATA) :IN "/gnu/store/grddjf42238c3zha0jfz8kzg32ly6vk4-sbcl-cl-cffi-gtk-gobject-0.11.2-1.29443c5/share/common-lisp/sbcl-source/cl-cffi-gtk-gobject/gobject/gobject.signals.lisp") #.(SB-SYS:INT-SAP #X007D6300) #.(SB-SYS:INT-SAP #X7FFFF6E07550) 2 #.(SB-SYS:INT-SAP #X7FFFF6E07600) #<unused argument> #<unused argument>)
11: ((LAMBDA (SB-ALIEN::ARGS-POINTER SB-ALIEN::RESULT-POINTER FUNCTION) :IN "/gnu/store/grddjf42238c3zha0jfz8kzg32ly6vk4-sbcl-cl-cffi-gtk-gobject-0.11.2-1.29443c5/share/common-lisp/sbcl-source/cl-cffi-gtk-gobject/gobject/gobject.signals.lisp") #<unavailable argument> #<unavailable argument> #<unavailable argument>)
12: ("foreign function: funcall_alien_callback")
13: ("foreign function: callback_wrapper_trampoline")
14: ("foreign function: #x201004DB")
15: (GTK:GTK-MAIN)
16: (GTK:ENSURE-GTK-MAIN)
17: (INTERFACE:START)
18: (NEXT:START)
19: (NEXT-BROWSER-EXEC:MAIN)
20: ((LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE))
21: (UIOP/IMAGE:CALL-WITH-FATAL-CONDITION-HANDLER #<CLOSURE (LAMBDA NIL :IN UIOP/IMAGE:RESTORE-IMAGE) {1003F9A46B}>)
22: ((FLET SB-UNIX::BODY :IN SAVE-LISP-AND-DIE))
23: ((FLET "WITHOUT-INTERRUPTS-BODY-27" :IN SAVE-LISP-AND-DIE))
24: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))

unhandled condition in --disable-debugger mode, quitting

I remember seeing something similar when building Next manually with the wrong SBCL parameters. @jmercouris @vindarel ?

@jmercouris

This comment has been minimized.

Collaborator

jmercouris commented Oct 15, 2018

@Ambrevar

That is some interesting behavior. Apparently the active-buffer does not have a mode associated with it?

Maybe it is a timing thing, what happens if you start Next, and then wait some time before typing a keypress?

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 15, 2018

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 15, 2018

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 15, 2018

In particular cl-cffi-gtk: the version I've packaged for Guix is quite far from the one in Quicklisp. Gotta try that.

@jmercouris

This comment has been minimized.

Collaborator

jmercouris commented Oct 15, 2018

Maybe we need to start thinking about having our own Quicklisp dist?

@vindarel

This comment has been minimized.

Contributor

vindarel commented Oct 15, 2018

@jmercouris

This comment has been minimized.

Collaborator

jmercouris commented Oct 15, 2018

While Qlot is a good idea, I do not want to introduce any dependencies at this time, especially on requiring Roswell. I think our own quicklisp dist would make it easier for everyone, and would suffice for our needs

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 15, 2018

Custom Quicklisp could be a good idea. While it may seem a bit premature, this issue might push us to start thinking about package management right now.

So not only do we need a package manager to ship Next, but also for the upcoming Next extensions.
We could kill two birds with one stone.

Also note that Guix effectively supersedes Quicklisp: it provides all the Lisp systems as individual packages, for all supported Common Lisp distributions.
Right now Guix is not "transportable" (it requires root access to be installed), but work is in progress to have Guix run from an unprivileged user.

In my opinion, Guix is more powerful than Quicklisp, it might also be easier to use for non-Lispers; on the otherhand, Quicklisp is Common Lisp while Guix is Scheme, so Quicklisp might be more appropriate for Next.

Any other package manager you'd know of? What about GUIs?

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 15, 2018

I think we should move the package manager discussion to another issue.

@jmercouris

This comment has been minimized.

Collaborator

jmercouris commented Oct 15, 2018

@vindarel

This comment has been minimized.

Contributor

vindarel commented Oct 16, 2018

pointing also to the new Ultralisp: http://ultralisp.org/ Everybody can add packages and it follows a repository's master branch.

(and it's a Weblocks app)

@jmercouris

This comment has been minimized.

Collaborator

jmercouris commented Oct 16, 2018

Thanks @vindarel !

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 17, 2018

I've tried rebuilding on top of https://github.com/crategus/cl-cffi-gtk to no avail.
Note that the Quicklisp version is dated 20160208, which does not match the last commit date in the repo which is 20160118. I wonder how the dating is done on Quicklisp.

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 18, 2018

@Ferada: Would you have any idea about the issue mentioned in #92 (comment)? Any tip to narrow down the issue maybe?

@Ferada

This comment has been minimized.

Contributor

Ferada commented Oct 23, 2018

At a glance, no, I pulled master, then make and afterwards ./next-gtk works pretty well.

@Ferada

This comment has been minimized.

Contributor

Ferada commented Oct 23, 2018

Gray window would mean that gtk-widget-show-all or so hasn't been executed, right?

@Ambrevar unless you've done so I'd start printf debugging in start in gtk.lisp to see where it's stuck. You're running on a multithreaded SBCL yes? Just checking, I don't even know if the non-threaded variant's still a thing.

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Oct 24, 2018

@Ferada: It also works for me if I build with make (i.e. get all the deps from Quicklisp).
It only crashes when built against the deps packaged by Guix, which could be slightly different but I'm not sure exactly how.

@Ambrevar

This comment has been minimized.

Contributor

Ambrevar commented Dec 2, 2018

I've just pushed a brand new sbcl-next package!
It should be working rather well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment