Re: Building a library as both static and dynamic

[Efraim Flashner]

On Sun, Sep 27, 2020 at 07:57:19AM -0400, Greg Hogan wrote:
> Is there a best practice or example for building a library twice, both static 
> and dynamic? I submitted patch #43620, and in working on another library have 
> the same issue. These are cmake builds with a parameter declaration for 
> either a static or dynamic build, not both. I would like to create a single 
> package with both “out” and “static” outputs, which looks to be standard 
> across Guix.
> 
> One idea is to run the configure / make / make install phases twice. 
> modify-phases does not currently support copying phases (though add-after 
> could work with the right function reference from cmake-build) and 
> #:configure-flags would need to be set differently.
> 
> Another option would be to patch the source build files, but this problem 
> feels solvable in Guix without duplicating the code from cmake-build’s 
> configure.
> 
> Thanks,
> Greg

x265 is a package that uses cmake and is built multiple times with
different options and with a separate static output.

-- 
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: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Mark H Weaver]

zimoun  writes:

> However, I am still confused that the GNU Emacs package with default
> options (--with-modules, --with-cairo, --disable-build-details)
> depends on LLVM via GTK+ and Mesa; and not on only GNU tools.

LLVM is an optional input for Mesa which enables the Gallium 'llvmpipe'
driver, a fast software rasterizer that uses LLVM to do runtime code
generation.

  https://docs.mesa3d.org/gallium/drivers/llvmpipe.html

Among other things, this allows use of the GNOME Shell on systems
without hardware support for 3D graphics.

GTK depends on Mesa.

> Is it possible to build Emacs with Gtk compiled without LLVM?

When LLVM was first added to Mesa's inputs in Guix, I reverted that
commit on my private branch for a year or two, to avoid building LLVM.
This saved me disk space and compile time, since I don't use substitutes
and therefore build everything from source anyway.  For those who use
substitutes, this change would be more costly.  I eventually gave up on
this since I now need LLVM for IceCat anyway.

Alternatively, for those who do not wish to maintain their own private
branch, here's a hybrid approach that might be workable: add a local
variant of 'mesa' with 'llvm' removed from 'inputs' (and "-Dllvm=true"
removed from the configure flags), then add a local variant of 'gtk+'
that uses your local 'mesa', and finally add a local variant of 'emacs'
that uses your local 'gtk+'.  I guess those last two steps could be
replaced by deep package rewrites, although I've never used that
functionality since I prefer the more flexible "private git branch"
approach to customizing Guix to my preferences.

  Mark

Rewriting inputs and ’arguments’ after patch #43578

[zimoun]

Dear,

Let consider the package ’emacs-magit’.  It does not depend on
’emacs-minimal’ but instead the argument is replaced by ’emacs-no-x’,
see: 

--8<---cut here---start->8---
  (build-system emacs-build-system)
  (arguments
   `(#:emacs ,emacs-no-x;module support is required
 #:tests? #t
--8<---cut here---end--->8---

which is for example confirmed by “guix graph –path”:

--8<---cut here---start->8---
$ guix graph --path emacs-magit emacs-minimal
guix graph: error: no path from 'emacs-magit@2.90.1-6.7f486d4' to 
'emacs-minimal@27.1'

$ guix graph --path emacs-magit emacs-no-x
emacs-magit@2.90.1-6.7f486d4
emacs-libgit@20200515-1.0ef8b13
emacs-no-x@27.1
--8<---cut here---end--->8---


Therefore, it is not possible to rewrite this “inputs“ (using the patch
[1]), as the dry-run shows:

--8<---cut here---start->8---
$ guix build emacs-magit --with-input=emacs-no-x=emacs-next -n
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations would be built:
   /gnu/store/c7g5f6xgljj63n69dilvxmkgsdarflj2-emacs-magit-2.90.1-6.7f486d4.drv
   
/gnu/store/aanmy6ma51yc3ivfmzp8iakirmg2hclb-emacs-libgit-20200515-1.0ef8b13.drv
43.2 MB would be downloaded:
   /gnu/store/bvhvqv99ylyam8gv77ipa9qrgr6659ly-emacs-no-x-27.1
   
/gnu/store/j5vhj85bn6adkmlnfc6w7rikss6753d3-emacs-libgit-20200515-1.0ef8b13.tar.xz
   /gnu/store/0w02d2pxhjwfa6674fwq5asv6w7xdkrp-jsoncpp-1.9.2
   /gnu/store/nlia3wcilwsdj8q883bgjmzirs6yl8z7-rhash-1.3.9
   /gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5
   /gnu/store/mhlxiw0fgv5mbqsml433f34349xdlmn3-module-import-compiled
   
/gnu/store/gk7gh5ik9f4ng35k22pz49r75vkhcbk8-emacs-magit-2.90.1-6.7f486d4-checkout
--8<---cut here---end--->8---


And it is expected because ’package-mapping’ only “rewrites” the
’inputs:

--8<---cut here---start->8---
  (inputs (map rewrite (package-inputs p)))
  (native-inputs (map rewrite (package-native-inputs p)))
  (propagated-inputs (map rewrite (package-propagated-inputs p)))
  (replacement (and=> (package-replacement p) replace))
--8<---cut here---end--->8---


Do I miss something?


All the best,
simon

[1] 

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi Bengt,

On Mon, 28 Sep 2020 at 21:16, Bengt Richter  wrote:

> I am wondering if there is a pure-wayland-client version of emacs, as 
> discussed here[1]

About Wayland, I do not know.

> A debian emacs-nox appears to exist [2]

Do you mean the Guix package 'emacs-no-x'?


> Perhaps such an emacs package could have a smaller closure,
> by depending as simply as possible on wayland (sans Xwayland)?

Thank you for the idea.  I do not know much about Wayland.  I will give a look.

Cheers,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Bengt Richter]

Hi Simon,

On +2020-09-28 10:56:55 +0200, zimoun wrote:
> Hi Pierre,
> 
> On Sun, 27 Sep 2020 at 12:54, Pierre Neidhardt  wrote:
> 
> > Just tested, EXWM works with emacs-no-x-toolkit!
> 
> Cool!
> 
> 
> > So I suggest we add the following packages:
> >
> > --8<---cut here---start->8---
> > (define-public emacs-no-x-toolkit-xelb
> >(package
> >  (inherit emacs-xelb)
> >  (name "emacs-no-x-toolkit-xelb")
> 
> [...]
> 
> > (define-public emacs-no-x-toolkit-exwm
> >(package
> >  (inherit emacs-exwm)
> >  (name "emacs-no-x-toolkit-exwm")
> 
> It appears to me more logical to name it: emacs-xelb-no-x-toolkit;
> appending the variation last.
> 
> 
> All the best,
> simon
>

I am wondering if there is a pure-wayland-client version of emacs, as discussed 
here[1]
A debian emacs-nox appears to exist [2]

On my system, apt show emacs-nox tells me
--8<---cut here---start->8---
Description: GNU Emacs editor (without GUI support)
 GNU Emacs is the extensible self-documenting text editor.  This
 package contains a version of Emacs compiled without support for X,
 and provides only a text terminal interface.
--8<---cut here---end--->8---

IIUC, wayland gets input events like keystrokes from the kernel and sends them 
by
registered call-backs to the programs that thus registered interest.

But I wonder how this connects with emacs and its use of pts/ptmx, readline, 
etc ...
Is there a legacy layer of vt encoding/decoding that could be eliminated by a 
more
direct use of wayland protocol?

Perhaps such an emacs package could have a smaller closure,
by depending as simply as possible on wayland (sans Xwayland)?

If the low level stuff were wrapped nicely in some guile extension modules,
I suspect other uses than emacs would be found.

[1] 
https://emacs.stackexchange.com/questions/48561/is-there-an-x11-free-build-of-emacs-that-can-run-on-wayland-not-going-through-x
[2] https://packages.debian.org/sid/emacs-nox
-- 
Regards,
Bengt Richter

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

On Mon, 28 Sep 2020 at 11:25, Pierre Neidhardt  wrote:
>
> zimoun  writes:
>
> > It appears to me more logical to name it: emacs-xelb-no-x-toolkit;
> > appending the variation last.
>
> Depends how you look at it ;)  But I don't have a strong opinion.

Me neither.  Just it seems more consistent:
 1. with how "guix search" works (see 'relevance')
and 2. with the description which says "`emacs-xelb' is a pure Emacs
Lisp [...]".

Cheers,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Bonface M. K.]

Pierre Neidhardt  writes:

> "Bonface M. K."  writes:
>
>> Wouldn't that be redundant? If you wanted to use
>> EXWM, we already have EXWM provided on MELPA, so
>> you could just set that up. That's IMHO though.
>
> Maybe there is a misunderstanding.  We provide EXWM as a Guix package
> for those who don't want to use Emacs' own package manager.  Without an
> emacs-no-x-toolkit-exwm package, Guix+EXWM users would be forced to drag
> GTK->Mesa->LLVM just to start Emacs.
>

Ooof! I never thought about it /that/ way. Thanks
for clarifying.

> Besides, MELPA can't be used to build Guix systems, images and the like.

Yeah sure. In that case, it makes alot of sense to
have emacs-no-x-toolkit-exwm packaged.

-- 
Bonface M. K. (https://www.bonfacemunyoki.com)
Chief Emacs Mchochezi / Twitter: @BonfaceKilz
GPG key = D4F09EB110177E03C28E2FE1F5BBAE1E0392253F


signature.asc
Description: PGP signature

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi Pierre,

On Sun, 27 Sep 2020 at 12:54, Pierre Neidhardt  wrote:

> Just tested, EXWM works with emacs-no-x-toolkit!

Cool!


> So I suggest we add the following packages:
>
> --8<---cut here---start->8---
> (define-public emacs-no-x-toolkit-xelb
>(package
>  (inherit emacs-xelb)
>  (name "emacs-no-x-toolkit-xelb")

[...]

> (define-public emacs-no-x-toolkit-exwm
>(package
>  (inherit emacs-exwm)
>  (name "emacs-no-x-toolkit-exwm")

It appears to me more logical to name it: emacs-xelb-no-x-toolkit;
appending the variation last.


All the best,
simon

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[zimoun]

Hi Mark,

On Sat, 26 Sep 2020 at 18:34, Mark H Weaver  wrote:

> FYI, our 'emacs-no-x-toolkit' package has a closure size of 390.9 MiB
> and does _not_ have the Gtk bug described above.  That's why I use it.

Thank you for the information.  It is worth knowing.  I am currently
giving it a try.

However, I am still confused that the GNU Emacs package with default
options (--with-modules, --with-cairo, --disable-build-details)
depends on LLVM via GTK+ and Mesa; and not on only GNU tools.  Is it
possible to build Emacs with Gtk compiled without LLVM?

All the best,
simon

Re: Contribute to the translation of the user manual

[Hubert Lombard]

Le Sun, 27 Sep 2020 16:13:57 -0400,
Julien Lepiller  a écrit :

Hi Julien :-)

Thank you for your answer! Of course, I accept the mentionned change. I just 
need to learn how to use the robot by studing basics:

https://www.translationproject.org/html/translators.html

Once this point has been clarified, I will move on to the next step. 

I will also be on the channel #guix again, this could be useful :-)

Hubert

> Le 27 septembre 2020 16:03:28 GMT-04:00, Hubert Lombard
>  a écrit :
> >
> >Hi Guix !  
> 
> Hi Hubert!
> 
> >
> >As a very basic end user of the Free Software, for more than 2
> >years, I have been using Guix System with pleasure. Also, it really
> >helps me.
> >
> >I would like to help with the translation.
> >
> >The manual is translated my native language (french), however I
> >noticed that some passages are left in English.  
> 
> I'm the main translator for the French language, and I'm glad you're
> willing to help!
> 
> >
> >eg:
> >https://guix.gnu.org/manual/fr/html_node/Installer-Guix-dans-une-VM.html
> >(isolated phrases in parts 3 and 4).
> >
> >I also found other concerned sentences in a few pages.
> >
> >Could I try to help with this? 
> >
> >Having never participated in the life of a free software, it would
> >be a great pleasure for me to be able to contribute to Guix as a
> >translator of the manual... and maybe later for other things...
> >Complete noob in the matter, I have never used .po files, but I
> >guess it's not difficult :-)
> >
> >The FSF has confirmed receipt of the document, all I'll have to do is
> >send an email to the coordinator to indicate which documents I would
> >like to translate. (From https://traduc.org/Projet_de_traduction/)  
> 
> There's no need to give your copyright to the FSF to contribute to
> the translation of Guix. Individual contributors keep their copyright.
> 
> There is an issue with the current po files though, as they don't
> list the correct license. They are currently under "the same license
> as the guix package" (gpl3+), but it should be "the same license as
> the guix manual" (gfdl). As long as you agree to this change, I can
> let you contribute :)
> 
> I see that I'm not specifically assigned to the cranslation of the
> manual, so as long as you accept the above-mentionned change you can
> simply use the robot at the TP.
> 
> Note that we are planning to move to a weblate instance soonish, but
> we're still using the TP for now.
> 
> >
> >The last/current step about the mailing list: "Confirmed requests for
> >Traduc and Traduc-po subscriptions."
> >
> >Thanks in advance for your answer
> >
> >Good continuation, this project is becoming a practical reality and
> >the childhurds seem great.
> >
> >Kind regards
> >
> >Hubert  



-- 

Re: emacs-lucid (was Re: Emacs closure at ~900MB?)

[Pierre Neidhardt]

"Bonface M. K."  writes:

> Wouldn't that be redundant? If you wanted to use
> EXWM, we already have EXWM provided on MELPA, so
> you could just set that up. That's IMHO though.

Maybe there is a misunderstanding.  We provide EXWM as a Guix package
for those who don't want to use Emacs' own package manager.  Without an
emacs-no-x-toolkit-exwm package, Guix+EXWM users would be forced to drag
GTK->Mesa->LLVM just to start Emacs.

Besides, MELPA can't be used to build Guix systems, images and the like.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: Service implementation for LXQt desktop

[Reza Alizadeh Majd]

On Thu, 3 Sep 2020 11:11:42 +0430
Reza Alizadeh Majd  wrote:

> Hi Guix, 
> 
> working on a service definition for LXQt desktop, I need to perform a
> series of default configurations. for example to set the window
> manager, prepare default panel, set the default theme, etc.
> 
> these configurations should be located $XDG_CONFIG_DIRS so the default
> paths are:
> 
> /run/current-system/profile/etc/xdg
> /home/$USER/.guix-profile/etc/xdg
> /home/$USER/.config/
> 
> I wanted to use `activation-service-type` to prepare default
> configurations in users home directory, but don't know how to access
> each user's home directory. 
> 
> the other option is to provide default configurations in store and
> symlink them in system profile. could anyone help me to do this using
> activation snippet? 
> 
> this is the service implementation that I'm working on:
> 
> --8<---cut here---start->8---
> (define-record-type* 
>   lxqt-desktop-configuration make-lxqt-desktop-configuration
>   lxqt-desktop-configuration?
>   (package lxqt-package (default lxqt-modified-dev)))
> 
> 
> (define %lxqt-activation
>   #~(begin
>   (let* ((conf-dir "DON'T KNOW HOW TO SET PATH FOR PROFILE")
>  (session-conf (string-append conf-dir "/session.conf")))
> (use-modules (guix build utils))
> (mkdir-p conf-dir)
> (unless (file-exists? session-conf)
>   (call-with-output-file session-conf
> (lambda (port)
>   (format port "# Auto Generated by Lxqt Service
> [General]
> window_manager=openbox")))
> 
> 
> (define lxqt-desktop-service-type
>   (service-type
>(name 'lxqt-desktop)
>(extensions
> (list (service-extension profile-service-type
>  (compose list lxqt
>   (service-extension activation-service-type
>  (const %lxqt-activation))
>(default-value (lxqt-desktop-configuration))
>(description "Run the LXQt desktop environment.")))
> 
> --8<---cut here---end--->8---
> 
> Kind regards,
> Reza
> 

does anyone have any suggestion about this initial configurations for a
new desktop service (LXQt)? 

check the other desktop services, I didn't find any reference about
this type of initial configurations in service definitions, is this
type of modifications need to be applied on package definition instead?

Regards,
Reza

-- 
Reza Alizadeh Majd
PantherX Team
https://www.pantherx.org/