Re: “guix --help” should point to https://guix.gnu.org/help/
Hey, zimoun writes: > Hi Ricardo, > > On Fri, 15 May 2020 at 12:20, Ricardo Wurmus wrote: > >> annoyed by the fact that people turn to Reddit for help with Guix — a >> venue only very few of us frequent — I wondered if our help channels are >> visible enough. > > Maybe it is "cultural" or/and "generational" thing and we cannot do > really better. Maybe some people prefer channels as Reddit because > they are a bit "afraid" by email and/or IRC, especially maybe on > official channels. Maybe because when someone has a problem, the > first thing they does is a query to popular search engines and then > browse some Reddit-kind of channels, so maybe they feels like it is a > good entry point. Maybe some people appreciate the voting system > (upvote, Discourse, etc.) to be "rewarded". Etc.. > > Well, I am not convinced it is an issue about visibility. :-( If the main issue is people turning to the subreddit for help, we could also kindly ask the moderators to advertise the official help channels in a sticky post. After all some people might turn to Reddit before even thinking of running `guix --help'. [...] Regards, Diego
Re: [bug#42738] [Work in progress] gnu: emacs: update to 27.1
Hey Guix, Jack Hill writes: [...] > On Tue, 18 Aug 2020, Michael Rohleder wrote: >>Jack Hill writes: [...] >>> Is the emacs-wide-int variant needed with the new multiprecision >>> functionality? >> >> I don't think so. > > Ok, I've deprecated that package. I added the emacs-wide-int variant because emacs-telega requires 62-bit [sic] integers (https://debbugs.gnu.org/39412). While Telega should work with regular (non-wide-int) Emacs 27.1 (thanks to the new multiprecision functionality), the test which checks if Emacs is suitable for running Telega will fail, because it does not know about "bignums" and looks at the value of most-positive-fixnum instead: --8<---cut here---start->8--- ;; 62bits for numbers is required ;; i.e. ./configure --with-wide-int (cl-assert (= most-positive-fixnum 2305843009213693951) nil "Emacs with wide ints (--with-wide-int) is required") --8<---cut here---end--->8--- I suggest we keep the emacs-wide-int variant until this issue has been resolved, so that the Emacs update does not break emacs-telega on 32-bit systems. [...] Greetings, Diego
Packaging Inferno
Hello Guix, I have written a package definition for Inferno and I would like to know if it would make sense to add it to Guix. I am asking because I am not sure if it is compatible with the FSDG (bundled fonts, trademarks, ...) and if it would be of any use to anyone. It builds reproducibly on my Laptop (x86_64-linux). I have not tried to build it on any of the other (supposedly) supported architectures. For now the recipe has to be passed to `guix build' or `guix package' using the `-f' option but I would be glad to add it to a module (e.g. (gnu packages virtualization), or a module of its own) and send a patch if it is decided that it belongs in Guix. Greetings, Diego inferno-trivial.scm Description: inferno-trivial.scm
Re: Packaging Inferno
Hello,
Thank you for your feedback.
Nils Gillmann writes:
> Ludovic Courtès transcribed 1.9K bytes:
>> Hello Diego,
>>
>> Diego Nicola Barbato skribis:
>>
>> > I have written a package definition for Inferno and I would like to know
>> > if it would make sense to add it to Guix. I am asking because I am not
>> > sure if it is compatible with the FSDG (bundled fonts, trademarks, ...)
>> > and if it would be of any use to anyone.
>>
>> Removing the proprietary(?) fonts like you did sounds like the right
@Ludo: The fonts I removed are copyright Bigelow & Holmes. They are
licensed in a way that forbids them from being modified and distributed
except as part of Inferno (or software derived from Inferno) [1].
>> thing to do. As for trademarks, please see
>> <https://www.gnu.org/distros/free-system-distribution-guidelines.html#trademarks>
>> to determine whether there’s a problem at all.
@Ludo: Judging from the link there seems to be no problem with the
trademarks after all. The bundled fonts (the ones I did not remove),
however, are provided in a format native to Inferno (and Plan 9) and can
not be rebuilt from source, which might be a problem according to this
[2] thread.
>> Could you also check whether all the code is GPLv2+ like the ‘license’
>> field suggests?
@Ludo: According to the NOTICE files scattered through the source tree
and the Inferno home page [3] different parts of Inferno are licensed
under GPLv2+, LGPLv2+, Expat (MIT-template), Lucent Public License 1.02
and Freetype.
Am I right to assume that I have to mention all of them in the ‘license’
field even though the NOTICE in the root of the source tree [4] says
that the "collection" is governed by the GPLv2+?
I could not find the Lucent Public License [5] in the (guix licenses)
module. Should I add it or should I use ‘non-copyleft’?
>> Do I get it right that the build result is a script that launches
>> Inferno as a GNU/Linux process? It seems like it could be useful.
@Ludo: That is right. I got the script from here [6]. It starts the
window manager and logs in as the current user; it is supposed to
provide a convenient entry point to start exploring the system.
Alongside this script in %out/bin/ there is also a symlink to the emu
binary which is installed by ‘mk install’ under
%out/usr/inferno/Linux/386/bin/ (Linux/arm/bin on arm machines). This
directory contains several other executables. I am considering making
some of them (like the Limbo compiler) available under %out/bin in the
same way as emu.
>> Some comments about the package definition:
>>
>> > (build-system trivial-build-system)
>> > (native-inputs `(("bash" ,bash)
>> > ("coreutils" ,coreutils)
>> > ("grep" ,grep)
>> > ("sed" ,sed)
>> > ("awk" ,gawk)
>> > ("xz" ,xz)
>> > ("tar" ,tar)
>> > ("gcc-toolchain" ,gcc-toolchain)
>> > ))
>> > (inputs `(("libx11" ,libx11)
>> > ("xorgproto" ,xorgproto)
>> > ("libxext" ,libxext)))
>>
>> Like Efraim wrote, I think using ‘gnu-build-system’ would allow you to
>> simplify the package definition.
@Ludo: My first attempt at writing the package definition used
‘gnu-build-system’. I switched to ‘trivial-build-system’ when I realised
that most phases in %standard-phases were ill suited for building
inferno. I will try to rewrite the definition using ‘gnu-build-system’.
>> > ;; build mk
>> > (invoke "./makemk.sh")
>>
>> It would be ideal if we had a separate package for ‘mk’ (I suppose it
>> can run on POSIX systems, right?).
@Ludo: This is Plan 9's mk (their version of make), which, I believe,
can run on POSIX systems. Though, if we were to add mk to Guix, i would
rather package the one provided by Plan 9 from Userspace [7] since that
project seems to be more active than Inferno.
> I can finish my mk package and send it in.
> My mk is the canonical set of mk files as used by bmake.
> Sources are from http://crufty.net/help/sjg/mk-files.htm
> and/or places linked from there.
>
> If this matches the mk mentioned here, I can create this patch.
@Nils: Your mk package seems to be unrelated to Plan 9's mk.
>> Once you’ve double-checked the licensing and trademark situation, I
>> think you can go ahead and submit it as a patch (or two patches, with
>> ‘mk’ separately).
>>
>> Thanks!
>>
>> Ludo’.
>>
Greetings,
Diego
[1]:
LICENCE
Description: Binary data
[2]: https://lists.gnu.org/archive/html/bug-guix/2018-10/msg00010.html
[3]: http://inferno-os.org/inferno/licence.html
[4]:
NOTICE
Description: Binary data
[5]: https://www.gnu.org/licenses/license-list.html#lucent102
[6]: https://www.ueber.net/who/mjl/inferno/getting-started.html
[7]: https://9fans.github.io/plan9port/
Re: Packaging Inferno
Hello Efraim, Efraim Flashner writes: > Not a big fan of using the trivial build system for something that ends > up with this many lines, but I built it on my aarch64 board and here's > the diff I came up with to make it work. Thanks for your feedback and especially for testing it on aarch64. I am currently rewriting the definition using the ‘gnu-build-system’. Since I am going to include your modifications, should I add a copyright line for you? (I am asking since I am relatively new to this and I am not sure how such things are handled correctly.) Greetings, Diego
Re: Packaging Inferno
Hello Nils, Nils Gillmann writes: > Diego Nicola Barbato transcribed 12K bytes: >> Hello, >> >> Thank you for your feedback. >> >> Nils Gillmann writes: >> >> > Ludovic Courtès transcribed 1.9K bytes: >> >> Hello Diego, >> >> >> >> Diego Nicola Barbato skribis: [...snip...] >> >> > ;; build mk >> >> > (invoke "./makemk.sh") >> >> >> >> It would be ideal if we had a separate package for ‘mk’ (I suppose it >> >> can run on POSIX systems, right?). >> >> @Ludo: This is Plan 9's mk (their version of make), which, I believe, >> can run on POSIX systems. Though, if we were to add mk to Guix, i would >> rather package the one provided by Plan 9 from Userspace [7] since that >> project seems to be more active than Inferno. >> >> > I can finish my mk package and send it in. >> > My mk is the canonical set of mk files as used by bmake. >> > Sources are from http://crufty.net/help/sjg/mk-files.htm >> > and/or places linked from there. >> > >> > If this matches the mk mentioned here, I can create this patch. >> >> @Nils: Your mk package seems to be unrelated to Plan 9's mk. > > Aha! I have it in 9base, which I have also packaged. At least according > to the README in the 9base/mk/ folder it should be compatible. > > Now I don't know if we want all of 9base... I would leave analyis of > that to you. If 9base on its own does not work, I can extract mk or > create a package which just builds mk and gets rid of the other files. > > https://git.suckless.org/9base > > I haven't checked but would assume that differences exist between > 9base (altough it states plan9 + inferno os) and inferno os mk. AFAICT it should be possible to build inferno using 9base's mk. In fact I think 9base is better suited for this purpose than Plan 9 from Userspace (plan9port), which was where I suggested we should get mk from, since it is much smaller. I can not tell from the source if it will be necessary to extract mk, so I will try to build inferno using 9base's mk as soon as you send in your patch and get back to you should I encounter any problems caused by one of the other commands provided by 9base. Thanks! Diego
Re: Packaging Inferno
Hello Ludo, I have sent a patch incorporating most of your feedback to guix-patc...@gnu.org (bug#33080). l...@gnu.org (Ludovic Courtès) writes: > Hi Diego, > > Sorry for the delay! No problem (my replies are not quite instantaneous either). > Diego Nicola Barbato skribis: > >> Nils Gillmann writes: >> >>> Ludovic Courtès transcribed 1.9K bytes: >>>> Hello Diego, >>>> >>>> Diego Nicola Barbato skribis: [...snip...] >>>> thing to do. As for trademarks, please see >>>> <https://www.gnu.org/distros/free-system-distribution-guidelines.html#trademarks> >>>> to determine whether there’s a problem at all. >> >> @Ludo: Judging from the link there seems to be no problem with the >> trademarks after all. The bundled fonts (the ones I did not remove), >> however, are provided in a format native to Inferno (and Plan 9) and can >> not be rebuilt from source, which might be a problem according to this >> [2] thread. > > Sometimes TTF files are considered source, so it really depends. Unless > there’s evidence that there exists another source for these fonts, I’d > say we can assume it’s fine, possibly with a comment. I have found no evidence that there exists another source. > Do you know whether other FSDG distros and Debian provide these fonts? They do not provide these exact fonts but those from which some of these are derived (misc and jis are "based" on X fonts, vera is probably based on Bitstream Vera). It is harder to find the origin of the other fonts as there is little information about them (big5 was "provided by students at the University of Hong Kong" according to its README; courier, gb, and minitel do not contain any information). The remaining fonts just reuse "subfonts" from the other directories. >>>> Could you also check whether all the code is GPLv2+ like the ‘license’ >>>> field suggests? >> >> @Ludo: According to the NOTICE files scattered through the source tree >> and the Inferno home page [3] different parts of Inferno are licensed >> under GPLv2+, LGPLv2+, Expat (MIT-template), Lucent Public License 1.02 >> and Freetype. >> Am I right to assume that I have to mention all of them in the ‘license’ >> field even though the NOTICE in the root of the source tree [4] says >> that the "collection" is governed by the GPLv2+? > > Yes, but you can leave a comment explaining that the combined work is > effectively GPLv2+. > >> I could not find the Lucent Public License [5] in the (guix licenses) >> module. Should I add it or should I use ‘non-copyleft’? > > You can use ‘non-copyleft’ in that case, with a reference to > <https://www.gnu.org/licenses/license-list.html#lucent102>. > > Note that the page above says that the Lucent PL is incompatible with > the GPL. Are we combining GPL code with Lucent code here? AFAICT LPL code (libmp libsec) is combined with GPL code when building emu. There is some more LPL code in the os directory, which is only needed for building native inferno, and in the appl and module directories, which contain Limbo code which is run on inferno but not used to build it. The NOTICE says that all licenses are compatible with the GPLv2 but that is apparently incorrect. As I am not very familiar with software licenses I do not know what to do about this. According to the GPL FAQ [*] it is possible to add an exception when using incompatible libraries, but I am hesitant to suggest this in a bug report to upstream because I do not know if that applies here. Is this a blocker? >>>> Do I get it right that the build result is a script that launches >>>> Inferno as a GNU/Linux process? It seems like it could be useful. >> >> @Ludo: That is right. I got the script from here [6]. It starts the >> window manager and logs in as the current user; it is supposed to >> provide a convenient entry point to start exploring the system. >> Alongside this script in %out/bin/ there is also a symlink to the emu >> binary which is installed by ‘mk install’ under >> %out/usr/inferno/Linux/386/bin/ (Linux/arm/bin on arm machines). This >> directory contains several other executables. I am considering making >> some of them (like the Limbo compiler) available under %out/bin in the >> same way as emu. > > Sounds good. Note that, if possible, we should stick to the usual file > system layout (that is OUT/share, OUT/lib, OUT/bin, etc. and not > OUT/usr.) Though if keeping the /usr/inferno layout style is really > important, we can make an exception. The layout style is not important; I only used OUT/usr/inferno because /usr/inferno is the default in mkconfig. I have changed this to OUT/share/inferno, which matches what the Nix package [†] does. [...snip...] > Thanks for your reply! > > Ludo’. Thanks for the feedback! Diego [*]: https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs [†]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/inferno/default.nix
ESC/P-R package
Hello,
I would like to create a package for the ESC/P-R printer driver. The
recipe works on my machine (GuixSD on x86_64). Yet I am not sure about
the source URL as it appears to break as soon as a new version is made
available because the old link is not preserved. Should we get the
source from
http://http.debian.net/debian/pool/main/e/epson-inkjet-printer-escpr/
instead, even though it is an older version?
Greetings
Diego
diff -u ~/Programs/Guix/cups.scm.old ~/Programs/Guix/cups.scm
--- ~/Programs/Guix/cups.scm.old2017-10-28 23:26:11.356064722 +0200
+++ ~/Programs/Guix/cups.scm2017-10-29 00:03:38.820338060 +0200
@@ -599,3 +599,30 @@
protocols, which cover printers made by Konica, HP (LaserJet), Oki, Samsung,
and more. See @file{README} for details.")
(license license:gpl2+)))
+
+(define-public escpr
+ (package
+ (name "escpr")
+ (version "1.6.17")
+ ;; This currently works. But it will break as soon as a newer
+ ;; version is available since the URLs for older versions are not
+ ;; preserved. An alternative would be to download the source (for
+ ;; an older version) from this Debian repository:
+ ;; http://http.debian.net/debian/pool/main/e/epson-inkjet-printer-escpr/
+ (source (origin
+ (method url-fetch)
+ (uri
"https://download3.ebz.epson.net/dsc/f/03/00/06/66/09/4ac2bf69bb1ddf4a9ad525596615cbb40fe4dad5/epson-inkjet-printer-escpr-1.6.17-1lsb3.2.tar.gz";)
+ (sha256
+(base32
+ "0m6v1wdavw4r25jfywqchsx0v9ss1l5fr8vq9d0d8cmjnz8mqblv"
+ (build-system gnu-build-system)
+ (arguments
+`(#:configure-flags
+ `(,(string-append "--prefix=" (assoc-ref %outputs "out"))
+,(string-append "--with-cupsfilterdir=" (assoc-ref %outputs "out")
"/lib/cups/filter")
+,(string-append "--with-cupsppddir=" (assoc-ref %outputs "out")
"/share/ppd"
+ (inputs `(("cups" ,cups-minimal)))
+ (synopsis "ESC/P-R printer driver")
+ (description "ESC/P-R driver supporting a multitude of Epson printers.")
+ (home-page "http://download.ebz.epson.net/dsc/search/01/search";)
+ (license license:gpl2+)))
Diff finished. Sun Oct 29 00:04:01 2017
Re: ESC/P-R package
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > Hello Diego, > > Diego Nicola Barbato skribis: > >> I would like to create a package for the ESC/P-R printer driver. The >> recipe works on my machine (GuixSD on x86_64). Yet I am not sure about >> the source URL as it appears to break as soon as a new version is made >> available because the old link is not preserved. Should we get the >> source from >> http://http.debian.net/debian/pool/main/e/epson-inkjet-printer-escpr/ >> instead, even though it is an older version? > > It would be ideal if you would find a mirror of the latest upstream > source at debian.org or anywhere else. Then you can change your recipe > to include several URLs: > > (origin > ;; … > (uri (list "…epson.net…" "…debian.org…"))) > > Does that make sense? I agree that this would be ideal. But as of now the latest version I have found on a mirror is 1.6.16 (on the aforementioned Debian repository) while the latest version is 1.6.17. I could use the epson.net source and add the one on debian.org as soon as it is updated to the latest version. > When you’re ready I encourage you to follow > <https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html> > and send us the ‘git format-patch’-produced patch so we can incorporate it. Thank you for your feedback. I apologise for not adhering to the guidelines; this is my first contribution to a free software project. If it is enough to add just the epson.net source for the time being I will submit my patch as soon as possible and according to the manual. Greetings Diego
Re: ESC/P-R package
Hello Guix,
I have sent the following patch to the guix-patches mailing list
(29...@debbugs.gnu.org):
>From 5d6449cc3cfc4154fff24abcdd54c05b44b9e471 Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato
Date: Wed, 1 Nov 2017 02:48:14 +0100
Subject: gnu: Add Epson escpr printer driver.
* gnu/packages/cups.scm (escpr): New variable.
---
gnu/packages/cups.scm | 32
1 file changed, 32 insertions(+)
diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm
index 491668e52..54a93fe49 100644
--- a/gnu/packages/cups.scm
+++ b/gnu/packages/cups.scm
@@ -599,3 +599,35 @@ printer/driver specific, but spooler-independent PPD file.")
protocols, which cover printers made by Konica, HP (LaserJet), Oki, Samsung,
and more. See @file{README} for details.")
(license license:gpl2+)))
+
+(define-public escpr
+ (package
+(name "escpr")
+(version "1.6.17")
+;; This currently works. But it will break as soon as a newer
+;; version is available since the URLs for older versions are not
+;; preserved. An alternative source will be added as soon as
+;; available.
+(source (origin
+ (method url-fetch)
+ ;; The uri has to be chopped up in order to satisfy guix lint.
+ (uri (string-append "https://download3.ebz.epson.net/dsc/f/03/00/06/66/09/";
+ "4ac2bf69bb1ddf4a9ad525596615cbb40fe4dad5/"
+ "epson-inkjet-printer-escpr-1.6.17-1lsb3.2.tar.gz"))
+ (sha256
+ (base32
+"0m6v1wdavw4r25jfywqchsx0v9ss1l5fr8vq9d0d8cmjnz8mqblv"
+(build-system gnu-build-system)
+(arguments
+ `(#:configure-flags
+ `(,(string-append "--prefix="
+ (assoc-ref %outputs "out"))
+ ,(string-append "--with-cupsfilterdir="
+ (assoc-ref %outputs "out") "/lib/cups/filter")
+ ,(string-append "--with-cupsppddir="
+ (assoc-ref %outputs "out") "/share/ppd"
+(inputs `(("cups" ,cups-minimal)))
+(synopsis "ESC/P-R printer driver")
+(description "ESC/P-R driver and PPDs supporting a multitude of Epson printers.")
+(home-page "http://download.ebz.epson.net/dsc/search/01/search";)
+(license license:gpl2+)))
--
2.14.3
It appears to build reproducibly (at least on my system). And I have
checked it with `guix lint'. It passes all tests except `guix lint -c
source' which does not report an error but strangely crashes with the
following output:
~$ guix lint -c source escpr
Backtrace:scpr@1.6.17 [source]...
13 (primitive-load "/gnu/store/19wpps1nmlg4j1530knl7kdhvgc…")
In guix/ui.scm:
1384:12 12 (run-guix-command _ . _)
In srfi/srfi-1.scm:
640:9 11 (for-each # …)
In guix/scripts/lint.scm:
1062:4 10 (run-checkers # …)
In srfi/srfi-1.scm:
640:9 9 (for-each # …)
In guix/scripts/lint.scm:
673:4 8 (check-source #)
In guix/monads.scm:
553:0 7 (_ _)
In guix/scripts/lint.scm:
109:38 6 (_ ())
543:7 5 (validate-uri _ # …)
96:17 4 (emit-warning # …)
In ice-9/boot-9.scm:
837:9 3 (catch system # …)
In guix/packages.scm:
355:11 2 (_)
In ice-9/ports.scm:
439:11 1 (call-with-input-file #f # …)
In unknown file:
0 (open-file #f "r" #:encoding #f #:guess-encoding #f)
ERROR: In procedure open-file:
ERROR: Wrong type (expecting string): #f
I have not yet found an alternative source. But the current one works
(except for the `guix lint' error). I will try to send a patch as soon
as the URI changes or the source is made available on this Debian
repository:
http://http.debian.net/debian/pool/main/e/epson-inkjet-printer-escpr/
Greetings
Diego
Re: [bug#29096] [PATCH] gnu: Add Epson escpr printer driver.
I sent a copy of this to guix-devel@gnu.org because the bug has already
been closed.
Danny Milosavljevic writes:
> On Wed, 01 Nov 2017 03:20:04 +0100
> Diego Nicola Barbato wrote:
>
>> This patch adds the Epson ESC/P-R printer driver.
>
> Nice! Could you also add the escpr to the documentation in doc/guix.texi
> (in a new patch) ?
>
> Maybe extend the documentation from
>
> --
> Suppose you want to enable the Web interface of CUPS and also add
> support for HP printers @i{via} the @code{hplip} package. You can do
> that directly, like this (you need to use the @code{(gnu packages cups)}
> module):
>
> @example
> (service cups-service-type
> (cups-configuration
>(web-interface? #t)
>(extensions
> (list cups-filters hplip
> @end example
> --
>
> to
>
> --
> Suppose you want to enable the Web interface of CUPS, add support for Epson
> printers $i{via}
> the @code{escpr} and also add support for HP printers @i{via} the
> @code{hplip} package. You can do
> that directly, like this (you need to use the @code{(gnu packages cups)}
> module):
>
> @example
> (service cups-service-type
> (cups-configuration
>(web-interface? #t)
>(extensions
> (list cups-filters escpr hplip
> @end example
> --
>
> (if that's how it's used).
Yes this is how it is used. I additionally installed it into my user
profile so as to have easier access to the ppd files.
> I think otherwise it's not really discoverable for the regular user how to
> use this (installing the package into the user profile would do nothing,
> right?).
I agree that it is hard to discover. Is it OK if I simply apply your
proposed extension to the documentation?
> I wonder whether we should extend the default cups-configuration
> to list both escpr and hplib. But that's for later...
Thanks.
Diego
pull: Update the %sbindir variable in (guix config) when building.
Hello Guix, The attached patch is supposed to fix <https://bugs.gnu.org/30370>. I am posting this here and not on guix-patches as I am not familiar with the internals of guix and do not know what the intended behaviour of this was. I have checked that it actually fixes the problem. However I do not know if it breaks anything. Greetings Diego >From 56d427eefe5c4667ed97b41f6411972b2c6ecc20 Mon Sep 17 00:00:00 2001 From: Diego Nicola Barbato Date: Tue, 13 Feb 2018 01:36:40 +0100 Subject: [PATCH] pull: Update the %sbindir variable in (guix config) when building. Fixes <https://bugs.gnu.org/30370>. * build-aux/build-self.scm (guix): New variable. (builder): Use it. --- build-aux/build-self.scm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/build-aux/build-self.scm b/build-aux/build-self.scm index 17d947bec..4c85c09df 100644 --- a/build-aux/build-self.scm +++ b/build-aux/build-self.scm @@ -44,6 +44,9 @@ ;; could be renamed or shuffled around in modules over time. Conversely, ;; 'find-best-packages-by-name' is expected to always have the same semantics. +(define guix + (first (find-best-packages-by-name "guix" #f))) + (define libgcrypt (first (find-best-packages-by-name "libgcrypt" #f))) @@ -165,8 +168,6 @@ files." (if (defined? '%localstatedir) %localstatedir (dirname %state-directory))) (define sysconfdir (if (defined? '%sysconfdir) %sysconfdir (dirname %config-directory))) - (define sbindir -(if (defined? '%sbindir) %sbindir (dirname %guix-register-program))) (define builder #~(begin @@ -222,7 +223,7 @@ files." #:storedir #$storedir #:localstatedir #$localstatedir #:sysconfdir #$sysconfdir -#:sbindir #$sbindir +#:sbindir (string-append #$guix "/sbin") #:package-name #$%guix-package-name #:package-version #$version -- 2.16.1
Starting SLiM on multiple ttys
Hello Guix, I would like to propose an enhancement to our SLiM service which would allow it to be started on multiple ttys (much like our mingetty service). I believe this would be useful for users who do not want to use GDM but still want to be able to run multiple graphical sessions at the same time. For this to work we would have to patch our SLiM package along the lines of this [0] since the Xorg display is currently hard coded (although we probably do not need the command line option). I have attached a crude proof of concept which can be tested by running something along the lines of: --8<---cut here---start->8--- qemu-system-x86_64 -snapshot -enable-kvm -m 4G $(guix system vm-image config.scm) --8<---cut here---end--->8--- Regards, Diego [0]: http://www.beroal.in.ua/prg/linux/slim-conf-arg.patch proof_of_concept.tar.gz Description: Binary data
Re: SLiM graphical login manager and keyboard layout
Hello Tanguy, Tanguy Le Carrour writes: [...] > I'm struggling to set the keyboard layout as, apparently, > slim-service-type is not supposed to be extended as gdm-service-type is. You can set the keyboard layout directly in the slim-configuration like this: --8<---cut here---start->8--- (service slim-service-type (slim-configuration (xorg-configuration (keyboard-layout keyboard-layout --8<---cut here---end--->8--- > I guess it's only a matter of copying (and adapting) the `(extend …)` and > `(compose …)` blocks from `gdm-service-type` to `slim-service-type`. But it's > just a guess. I've tried to define `my-slim-service-type` in my system config, > but failed! It's a good guess: I tried this a while back and it works, if there is only one instance of slim-service-type: >From be8f7e45384bb0676ea88f4cb488dd23114436f5 Mon Sep 17 00:00:00 2001 From: Diego Nicola Barbato Date: Fri, 27 Sep 2019 11:24:38 +0200 Subject: [PATCH] services: slim: Allow using 'set-xorg-configuration' with SLiM. Fixes <https://bugs.gnu.org/37422>. * gnu/services/xorg.scm (slim-service-type)[compose, extend]: New fields. --- gnu/services/xorg.scm | 15 +++ 1 file changed, 15 insertions(+) diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm index 1d55e388a1..1b78550825 100644 --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -589,6 +589,21 @@ reboot_cmd " shepherd "/sbin/reboot\n" ;; avoid bad surprises. (service-extension profile-service-type (const (list xterm) + +;; For convenience, this service can be extended with an +;; record. Take the first one that +;; comes. +(compose (lambda (extensions) + (match extensions + (() #f) + ((config . _) config +(extend (lambda (config xorg-configuration) + (if xorg-configuration + (slim-configuration + (inherit config) + (xorg-configuration xorg-configuration)) + config))) + (default-value (slim-configuration (define-deprecated (slim-service #:key (slim slim) -- 2.23.0 If there are multiple SLiM services, it doesn't work, because "[t]here can be only one instance of an extensible service type" (according to 'Service Types and Services' in the manual). Because of that I believe making slim-service-type extensible would be more confusing than useful, which is why I didn't pursue this further. Maybe it should be mentioned in the manual that 'set-xorg-configuration' doesn't work with SLiM? Regards, Diego
Re: SLiM graphical login manager and keyboard layout
Tanguy Le Carrour writes: > Hi Diego! > > > Le 10/18, Diego Nicola Barbato a écrit : >> You can set the keyboard layout directly in the slim-configuration like >> this: >> --8<---cut here---start->8--- >> (service slim-service-type >> (slim-configuration >> (xorg-configuration >>(keyboard-layout keyboard-layout >> --8<---cut here---end--->8--- > > I have a slightly different version that works! That's because mine doesn't make sense (sorry!). I've messed it up when adapting it from my own config.scm. >(service slim-service-type > (slim-configuration > (xorg-configuration >(xorg-configuration > (keyboard-layout keyboard-layout)) > > > I don't understand the "double" `xorg-configuration`, though! ^_^' The outer 'xorg-configuration' is a field of the 'slim-configuration' data type. The inner 'xorg-configuration' is itself a data type representing the Xorg configuration (with its 'keyboard-layout' field set to the value of 'keyboard-layout'). If you look at the section 'X Window' in the Guix manual, you'll see that the default value for the 'xorg-configuration' field (of the 'slim-configuration' data type) is '(xorg-configuration)', which is simply the 'xorg-configuration' data type with all its fields set to their respective default values. HTH, Diego
Recent $EMACSLOADPATH changes broke my setup: Bug or Feature?
Hey Guix, I've already asked about this on IRC, but since the people responsible for the changes didn't seem to be present I'll ask here too. I use EXWM so I've installed ‘emacs’ and ‘emacs-exwm’ in my system profile. Additionally I've installed Emacs packages (‘emacs-org’, ‘emacs-pdf-tools’, ‘emacs-emms’, etc.) in my user profile. Since the changes to the way Emacs packages are handled this no longer works, i.e. Emacs no longer knows about the packages installed in my user profile. I can work around it by installing ‘emacs’ to my user profile. But it doesn't make much sense to me that I have to install ‘emacs’ “twice” just so an environment variable is set. Is this an intended consequence of the recent changes or should this be considered a bug? Regards, Diego
System logs are world-readable
Hey Guix, In Guix System the system log files (/var/log/messages, /var/log/debug, etc.) are world readable by default. Since `dmesg' was restricted to privileged users a while ago [0] it seems reasonable to make these files readable by privileged users only as well. What do others think? Regards, Diego [0]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=24446ce299943efe3dfded6c9dd0cf9421d8da04
