Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Raghav Gururajan]

Hello Mark!

That is so great to hear. I will try it and get back to you.

Regards,
RG.

April 17, 2019 8:11 PM, "Mark H Weaver"  wrote:

> Hello again,
> 
> "Raghav Gururajan"  writes:
> 
>> Ah I see. Thanks for raising the issue. Yes, we'll move on to "Stylus Input" 
>> :)
>> 
>> April 16, 2019 4:22 PM, "Mark H Weaver"  wrote:
>> 
>>> Hi Raghav,
>>> 
>>> "Raghav Gururajan"  writes:
>> 
>> I made the changes you told me. Now the error is "guix system: error:
>> /etc/rg-secondary.scm:49:24: no value specified for service of type
>> 'fprintd'"
>>> Sorry, this looks like a genuine bug in Guix's fingerprint service,
>>> which was added relatively recently, and apparently has not yet seen
>>> much use. I've just raised the issue with the author of that service,
>>> so hopefully it'll be fixed soon. In the meantime, I would suggest
>>> removing:
>>> 
>>> (service fprintd-service-type)
> 
> The author of 'fprintd-service-type' has pushed a fix. After a fresh
> "guix pull", you could try adding the line above to your OS config, and
> it might work now.
> 
> Regards,
> Mark

Rust development tools

[mikadoZero]

The rust book is a learning resource for the rust programming language.
https://doc.rust-lang.org/book/title-page.html

It includes content on these rust development tools:

* cargo
  + build system and package manager
  + provides dependency management
  + used through the entire rust book
  https://doc.rust-lang.org/book/ch01-03-hello-cargo.html

* rustup
  + adding the developer tool below
https://doc.rust-lang.org/book/appendix-04-useful-development-tools.html
  + using other versions of rust like nightly
- example of using nightly rust
  https://rocket.rs/v0.4/guide/getting-started/

* developer tools
  https://doc.rust-lang.org/book/appendix-04-useful-development-tools.html
  + rustfmt - code style reformatter
  + clippy - linting
  + rls - language server

I have rust installed on a Guix System.  It does not look like it
included any of these developer tools.  They also do not show up when
doing a package search for their names or for just rust.  I have also
searched for them with a `locate rust` and filtered its results with
sed.

What would be other ways to find these if they are already packaged for
Guix?

If cargo is not packaged are people who are using rust with Guix System
using rustc and manually managing their dependencies?

Are there any special considerations for Guix packages that provide
programs like cargo and rustup that are also package managers?

How does Guix deal with something like rust nightly releases if at all?

Re: guix pull package output truncated

[mikadoZero]

Thank you for pointing out `guix pull -l` for this.

Ludovic Courtès writes:

> Hello!
>
> mikadoZero  skribis:
>
>> Recently the output of guix pull has changed.  It no longer gives the
>> complete output for the "New in this revision" section.
>
> For the record, I did that after seeing that, when you don’t upgrade
> every two days or so, your screen could easily be filled by tens of
> lines of packages.
>
>> Is there a flag I can pass to guix pull to turn off this truncation.  I
>> found it informative to be able to see all the packages that were being
>> added and upgraded and would like to continue to be able to see all the
>> packages.
>
> There’s currently no flag to change this behavior.  Instead, you have to
> run ‘guix pull -l’ but it’s arguably not very convenient.
>
> Perhaps we could add an environment variable specifying whether/how to
> truncate?  I’d keep the default as it is now.
>
> Thoughts?
>
> Ludo’.

Re: guix-a dokumentaro en Esperanto

[Quiliro Ordonez]

El 2019-04-16 08:53, swedebugia escribió:
> On 2019-04-13 00:24, Luther Thompson wrote:
>> On Fri, 12 Apr 2019 12:43:12 -0700
>> Quiliro Ordonez  wrote:
>>
>>> Mi serĉas por Guix-a dokumentaro en Esperanto. Ĝi povas esti
>>> manlibroj, aŭdioj (rimarkoj) aŭ videoj (konferencoj, seminarioj).
>>> Kie mi povos trovi ilin?
>>>
>>> Dankon!
>>
>> Mi mem ne povas trovi ajn ion. Ne ke mi havas iom da tempon, sed eble
>> iu povus traduki la manlibro?
>>
>> I can't find anything, myself. Not that I have time or anything, but
>> maybe someone could translate the manual?
> 
> I just translated the complete manual with google translate to create a
> first draft. (it is ~200.000 words)
> https://gitlab.com/swedebugia/guix-manual-eo/blob/master/guix-manual-eo-1.0.0-pre1-guglo-tradukita.po
> (1,5 MB)
> 
> Unfortunately google removed their support for .po-files from the
> interface I used so now the original strings are translated which is a
> mess. (I'm guessing this happened because they extract fees from
> Transifex when people pay to enable google machine translation there.)
> 
> Does anyone know of a script to convert from this:
> 
> msgid "some text translated with a machine"
> msgstr ""
> 
> to this:
> 
> msgid ""
> msgstr "some text translated with a machine"
> 
> and then to populate the .po-file again with the original msgid?

Mi ne plaĉas Google-on. Plie mi pensas ke ĝi igas kop'rajton malliberan.

Mi povas traduki parton manualan ĉiutage. Bonvolu diru min la maniero
kun Emacs kaj
https://translationproject.org/POT-files/guix-manual-1.0.0-pre1.pot .

Re: sha256 hash mismatch for mozjs-38.2.1.rc0

[Mark H Weaver]

Hi,

Platoxia  writes:

> After successfully doing "guix pull" as root, GuixSD fails to update from 
> /gnu/store/nbpba96q5vjhr64c91s788109mj7f3y6-system (kernel 4.20.1) 
> to current with "guix system reconfigure" due to an sha256 hash mismatch 
> after downloading mozjs-38.2.1.rc0.  
>
> I have attempted this system reconfiguration 3 times in as many weeks and 
> this failure always occurs for me. I am uncertain if this issue is unique 
> to me which is why I am posting here rather than making a bug report. It 
> could simply be a case of the mozjs-38 hash needing to be updated
> in gnuzilla.scm.
>
> From Guix System Reconfigure log:
>
> building 
> /gnu/store/x1k7m8k5n39ydbayh2mn57514sh77jyp-mozjs-38.2.1.rc0.tar.bz2.drv...
> downloading from 
> https://people.mozilla.org/~sstangl/mozjs-38.2.1.rc0.tar.bz2...

Indeed, the URL above is no longer valid.  It returns some kind of error
page.  In general, when this happens, you can work around the problem by
finding another copy of the same file somewhere else.  Often it is
sufficient to type the file name into a search engine.  I found this:

  http://anduin.linuxfromscratch.org/BLFS/mozjs/mozjs-38.2.1.rc0.tar.bz2

Now, if you type "guix download ", it will download the file and
add it to your store.  If it has the correct hash, it will be used
automatically when you repeat the "guix system reconfigure" command.

(If it has the wrong hash, it will be ignored and eventually removed the
next time you perform a garbage collection with "guix gc").

> The mozjs-38 definition as found in gnuzilla.scm:
> (define-public mozjs-38
>   (package
> (inherit mozjs)
> (name "mozjs")
> (version "38.2.1.rc0")
> (source (origin
>   (method url-fetch)
>   (uri (string-append
> "https://people.mozilla.org/~sstangl/";
> name "-" version ".tar.bz2"))

Indeed, in order to properly fix this problem, the code above needs to
be updated.

Clément: I see that you added our 'mozjs-38' package about a year ago.
Would you be willing to find a new source URL for it, and possibly to
update to a newer 38.x version?  It might be easier to find a stable URL
for a non-RC version, and it looks like several other distros now have
mozjs-38.8.0.

   Mark

Re: 1) Lid Buttons 2) Stylus Input 3) Fingerprint Scanner

[Mark H Weaver]

Hello again,

"Raghav Gururajan"  writes:

> Ah I see. Thanks for raising the issue. Yes, we'll move on to "Stylus Input" 
> :)
>
> April 16, 2019 4:22 PM, "Mark H Weaver"  wrote:
>
>> Hi Raghav,
>> 
>> "Raghav Gururajan"  writes:
>> 
>>> I made the changes you told me. Now the error is "guix system: error:
>>> /etc/rg-secondary.scm:49:24: no value specified for service of type
>>> 'fprintd'"
>> 
>> Sorry, this looks like a genuine bug in Guix's fingerprint service,
>> which was added relatively recently, and apparently has not yet seen
>> much use. I've just raised the issue with the author of that service,
>> so hopefully it'll be fixed soon. In the meantime, I would suggest
>> removing:
>> 
>> (service fprintd-service-type)

The author of 'fprintd-service-type' has pushed a fix.  After a fresh
"guix pull", you could try adding the line above to your OS config, and
it might work now.

  Regards,
Mark

Re: guix pull package output truncated

[Tobias Geerinckx-Rice]

Sleepy hullo,

Ludovic Courtès wrote:
There’s currently no flag to change this behavior.  Instead, you 
have to

run ‘guix pull -l’ but it’s arguably not very convenient.

Perhaps we could add an environment variable specifying 
whether/how to

truncate?  I’d keep the default as it is now.


AIUC, this list of changes is displayed once and then ‘lost’ (to 
the average user) when they clear their screen, right?


Or is there a command that returns this nice list of differences 
between two guix-profiles that we could suggest running when the 
default is truncated?  It could default to current and current-1, 
and would solve both (minor) irritations.


Am I making sense?

T G-R


signature.asc
Description: PGP signature

Re: Services and log management/monitoring

[Ludovic Courtès]

Hello!

The kind of “service” that Guix manages is those described here:

  https://www.gnu.org/software/guix/manual/en/html_node/Service-Composition.html

The first paragraph tries to explain it:

  Here we define a “service” as, broadly, something that extends the
  functionality of the operating system.  Often a service is a process—a
  “daemon”—started when the system boots: a secure shell server, a Web
  server, the Guix build daemon, etc.  Sometimes a service is a daemon
  whose execution can be triggered by another daemon—e.g., an FTP server
  started by ‘inetd’ or a D-Bus service activated by ‘dbus-daemon’.
  Occasionally, a service does not map to a daemon.  For instance, the
  “account” service collects user accounts and makes sure they exist when
  the system runs; the “udev” service collects device management rules and
  makes them available to the eudev daemon; the ‘/etc’ service populates
  the ‘/etc’ directory of the system.

For services that “map to a daemon”, you’d extend
‘shepherd-root-service-type’ by providing a Shepherd service.  A
Shepherd service is a service managed by PID 1.  You can list them on a
running system by running ‘herd status’ as root.

IOW, Shepherd services are a special case of service.  Just like D-Bus
services are another special case, etc.

About logging: Shepherd does very little in that area.  It limits itself
to providing a #:log-file parameter to capture the processes’s
stdout/stderr to a file.  Other than that we usually configure daemons
to write to syslog, which provides more flexibility regarding storage
and filtering of log entries.

A “non-Shepherd service” as you call them doesn’t necessarily map to a
process, so there’s potentially nothing to log in the first place.

Does that answer your questions?

Thanks,
Ludo’.

Re: guix pull package output truncated

[Ludovic Courtès]

Hello!

mikadoZero  skribis:

> Recently the output of guix pull has changed.  It no longer gives the
> complete output for the "New in this revision" section.

For the record, I did that after seeing that, when you don’t upgrade
every two days or so, your screen could easily be filled by tens of
lines of packages.

> Is there a flag I can pass to guix pull to turn off this truncation.  I
> found it informative to be able to see all the packages that were being
> added and upgraded and would like to continue to be able to see all the
> packages.

There’s currently no flag to change this behavior.  Instead, you have to
run ‘guix pull -l’ but it’s arguably not very convenient.

Perhaps we could add an environment variable specifying whether/how to
truncate?  I’d keep the default as it is now.

Thoughts?

Ludo’.

Re: National keyboard layout for Polish

[Ludovic Courtès]

Hello,

Adam Mazurkiewicz  skribis:

> How to set Polish keyboard layout to get Polish special letters?
> https://dailyweb.pl/wp-content/uploads/2016/11/zazolc.png
> They should be available in Gedit, Web browser address bar, etc. I
> have Xfce Desktop Environment.

With the new keyboard layout mechanism, I believe you could get it with:

  (keyboard-layout "pl")

Try running:

  info "(guix) Keyboard Layout"

to read on how to use it.

HTH!

Ludo’.

Re: guix-a dokumentaro en Esperanto

[Ludovic Courtès]

Konrad Hinsen  skribis:

> Laŭ mia scio nenia dokumentaro en Esperanto ekzistas. Sed ja troviĝas
> esperantistoj inter la Guix-istoj kaj Guix-umantoj. Eblas do esperi
> iaman pliboniĝon de la situacio.

Estas multaj Esperanto-parolantoj ĉi tie, iu devus traduki la manlibron!
:-)

  https://translationproject.org/domain/guix-manual.html

Ĝis,
Ludo'.

Re: Getting rid of "source file [...] newer than compiled" messages

[Ludovic Courtès]

Ricardo Wurmus  skribis:

>>   $ stat 
>> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go
>> File: 
>> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’
>> Size: 77485  Blocks: 152IO Block: 4096   regular file
>>   Device: fc02h/64514d   Inode: 137925  Links: 1
>>   Access: (0444/-r--r--r--)  Uid: (0/root)   Gid: (0/root)
>>   Access: 2019-04-06 16:56:32.259721626 -0500
>>   Modify: 2018-12-25 17:02:43.753150336 -0600
>>   Change: 2018-12-25 17:02:43.753150336 -0600
>>Birth: -
>> #+END_EXAMPLE
>>
>> It looks like the scheme file is fractions of a second newer than the
>> compiled file. So, pulling on this thread:
>
> These time stamps are wrong.  Everything in /gnu/store should have 0 for
> the mtime.

More precisely the mtime should be 1 (one second after the Epoch).

Also, when using the ‘stat’ command, it’s a good idea to set TZ=UTC to
avoid confusion when looking at the timestamps.

Thanks,
Ludo’.

Re: Bootstrappable bitcoin release builds with Guix

[Ludovic Courtès]

Hi Carl,

Carl Dong  skribis:

> I've been on a quest to use Guix for Bitcoin Core's reproducible builds as I
> believe that Guix's focus on bootstrappability, and Guile's simplicity and
> flexibility are very desirable qualities in building an auditable, secure, and
> reliable build process. My pull request (very short thanks to Guix's
> infrastructure) can be found here:
> https://github.com/bitcoin/bitcoin/pull/15277/files

I’m late to the party, but this is awesome!  The goals you’re pursuing
are in line with those we’re after in Guix, Reproducible Builds, and
Bootstrappable, so it’s great to see that Guix can help others here.

> I've submitted patches for the Guix bitcoin-core package to make it
> reproducible, which seems to work fine. However, for easier acceptance into 
> the
> bitcoin core process, I need to produce tarballs like the ones we have on our
> servers today: https://bitcoincore.org/bin/bitcoin-core-0.17.1/
>
> For some context, we have a "mini-guix" of sorts seen in our "depends tree"
> here: https://github.com/bitcoin/bitcoin/tree/master/depends. This builds all
> the dependencies for bitcoin just the way we want them, in preparation for
> getting linked into bitcoin itself.
>
> My current approach for the build process is to produce a Guix container in
> which I execute a build of our "depends tree" followed by a build of bitcoin
> itself. See the Guix manifest and scripts here:
> https://github.com/bitcoin/bitcoin/pull/15277/files

OK.  You could store the output of ‘guix describe -f channels’ in
addition to the manifest, and then do ‘guix pull -C’ of this file.  That
way, you’d be pinning a specific package set.

> However, there were three hiccups that I had to hack my way around:
>
> 1. libstdc++ would not link statically even with "-static-libstdc++". The hack
>was to remove the .la file under $LIBRARY_PATH.

Weird.  Could you send a small test case for this to bug-g...@gnu.org?

> 2. Upon inspection of the binaries produced at the end of this process, they 
> all
>had rpaths. The hack was to use patchelf --remove-rpath on them.

Yes, ‘ld-wrapper’ and our ‘gcc’ packages add those on purpose; they’re
required for dynamically-linked binaries.  But you’re producing
statically-linked executables in the end, right?

> 3. Upon inspection of the binaries produced at the end of this process, their
>interpreters all had a `/gnu/store/blahblah-glibc-2.28' prefix. The hack 
> was
>to use patchelf --set-interpreter on them.

To use /lib/ld-linux-x86-64.so.2 instead?

You can do that, but there’s a risk: this is assuming that the loader
and libc on the user’s machine are compatible with those you built
against.

> My questions are:
>
> 1. Is there a way to avoid the hacks that I listed above? I understand that it
>might mean writing custom gcc packages and I'm 100% okay with that.
>
> 2. Is there an easier way of achieving the same thing?

I think the difficulty here lies in producing non-self-contained binary
tarballs, paradoxically.  :-)

By that I mean that the tarball at

makes assumptions on the user’s machine:

--8<---cut here---start->8---
$ file /tmp/bitcoin-0.17.1/bin/bitcoin-cli 
/tmp/bitcoin-0.17.1/bin/bitcoin-cli: ELF 64-bit LSB pie executable x86-64, 
version 1 (GNU/Linux), dynamically linked, interpreter 
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
BuildID[sha1]=aced8cd0e28adb7a9e0c15f2e794aae7150d348e, stripped
$ objdump -x /tmp/bitcoin-0.17.1/bin/bitcoin-cli |grep NEED
  NEEDED   librt.so.1
  NEEDED   libm.so.6
  NEEDED   libgcc_s.so.1
  NEEDED   libpthread.so.0
  NEEDED   libc.so.6
  NEEDED   ld-linux-x86-64.so.2
  VERNEED  0x2850
  VERNEEDNUM   0x0006
--8<---cut here---end--->8---

The binary assumes that /lib64/ld-linux-x86-64.so.2 exists, that
libgcc_s.so & co. will be found in the “standard locations”, etc.  These
assumptions do not hold on a standalone Guix system or on NixOS or
Gobolinux.  They are probably reasonable for FHS distros, though.

Can you achieve this by simply taking the ouptut of “guix build
bitcoin-core-alt” (where ‘bitcoin-core-alt’ is a variant that statically
links against libstdc++ etc.), patching the ELF interpreter, and then
copying it in a tarball?

You’d also get cross-compilation by adding ‘--target’.

Thanks,
Ludo’.

Re: Remounting tmpfs

[rendaw]

On 4/18/19 5:31 AM, Ludovic Courtès wrote:
> Hi,
>
> 7e9wc56emja...@s.rendaw.me skribis:
>
>> On 4/9/19 11:58 PM, Ludovic Courtès wrote:
>>> Hello,
>>>
>>> 7e9wc56emja...@s.rendaw.me skribis:
>>>
 On a system I'm porting to guix I have 2GB tmpfs with subdirectories
 like /tmpfs/etc that I remount to /etc with an overlay filesystem.

 The current way I do this in systemd is making a service dependency
 between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
 /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
 filesystem dependencies.

 Are there any other ways I can do this without copying/pasting/modifying
 gobs of core guix code into my system definition?  Like somehow
 appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
 procedure or something.
>>> In Guix /etc is mostly populated by “activation programs”, which are
>>> generated from your config.  So I’m not sure what you describe would
>>> make much sense.
>> So if /etc can be read-only and boot I'm probably fine... my experience
>> with other distros was that some other processes needed to write to it. 
>> Ex: modifying resolv.conf.
> /etc is writable because of things like ‘resolv.conf’.
>
> /etc consists mostly of immutable files derived directly from your OS
> config (/etc/passwd, /etc/hosts, /etc/polkit-1, /etc/pam.d, etc.), along
> with files that contains bits of state (/etc/shadow, /etc/resolv.conf.)
>
> The former are directly managed by Guix, while the latter are either
> left as is or touched with care by Guix (/etc/shadow in particular.)
>
>>> Now, you could try to add a file system declaration that mounts /etc,
>>> with (needed-for-boot? #t).
>> My goal is to have a read-only / mount with the ability for programs to
>> make temporary modifications for operational purposes when necessary, in
>> limited scopes (like /etc).  Can you elaborate on what you're suggesting
>> here?  Mounting something other than the overlayfs on /etc would hide
>> the system config files.  I might be able to use another mount to create
>> a pseudo- /tmpfs/etc_work subdirectory but it sounds kind of wormy and
>> overlayfs requires the upper dir and workdir to be the same filesystem
>> which I think precludes doing any mounting for those subdirectories.
> The overlay makes a lot of sense.  This is what ‘guix system vm’ does:
> see the #:volatile-root? parameter of ‘raw-initrd’.
>
> Perhaps you could simply set #:volatile-root? #t in your initrd to
> obtain what you want?
>
> Thanks,
> Ludo’.

Thanks, yeah, that sounds exactly like what I want!  TBH I think
something's going on strange with my threads, perhaps because I messed
up the replies -- after much source reading I found volatile-root and
asked about it in my disk-image thread.  TBH I'm not clear how that
would be set in the config to use with disk-image to get a whole system.

Re: GUIX installation / uninstallation problem

[Zelphir Kaltstahl]

I already fixed it : )

I had to _restart_ the guix daemon. Note: It was already running
according to `systemctl status`. So this might be worth some
consideration for the future: If the daemon is running, but there is no
socket, tell the user something like: "You might need to restart your
guix daemon."

It would be great to have an official uninstallation / removal guide for
Guix, that does prevent all problems in future reinstalls of Guix.

Now I only need to fix the issue with the locales again. That is a topic
for another question under a different title though.

Hans

> Message: 2
> Date: Wed, 17 Apr 2019 13:48:35 +0200
> From: Hans-Werner Roitzsch 
> To: help-guix@gnu.org
> Subject: GUIX installation / uninstallation problem
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
> Hello Guix users!
>
> I sort of messed up my Guix setup as follows:
>
> I installed Guix using the binary installer script. The installer asked
> me, whether I wanted to allow prebuilt packages and I thought: "Nah, let
> it compile packages." Not considering how long that would take initially
> and/or with any updates for packages.
>
> Then I started installing the locales as suggested, when you do not have
> them yet, which I think is always the case on a fresh Guix installation.
> So I started installing those with the command provided by the Guix
> installer.
>
> I think it spent already 30min or so compiling stuff, when I canceled
> it. Then I started looking for a way to change the prebuilt thingy
> setting, as I realized what I had done. I found no way to change the
> setting and neither did any web search yield anything helpful. So I went
> ahead and thought "Isn't it like a thing contained in one directory? I
> should be able to simply delete Guix using `rm -rf` ?". I deleted `/gnu`
> and a few other locations.
>
> Then I tried to install Guix again, but it refused to "overwrite" an
> existing installation. So there must have been traces of the previous
> installation left somewhere. I searched more about uninstalling Guix and
> found very little. At some point I found the following Arch Linux wiki
> link:
>
> https://wiki.archlinux.org/index.php/Guix
>
> I removed all the guixbuilders and the group guixbuild. Then I removed
> the other paths mentioned in the wiki article.
>
> Finally Guix installer did not find any previous installation any longer
> and installed, seemingly without problems.
>
> But then I started to see the actual problem. When I tried installing
> the locales following the installation of Guix an error with the guix
> daemon socket came up:
>
> =
> guix package -i glibc-utf8-locales
> guile: warning: failed to install locale
> hint: Consider installing the `glibc-utf8-locales' or `glibc-locales'
> package and defining `GUIX_LOCPATH', along these lines:
>
> ??? guix package -i glibc-utf8-locales
> ??? export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>
> See the "Application Setup" section in the manual, for more info.
>
>
> guix package: error: failed to connect to
> `/var/guix/daemon-socket/socket': No such file or directory
> =
>
> So now my question is: How can I repair my Guix, its socket, or better
> yet: Completely remove and reinstall it?
>
> Thanks for any help!
>
> Hans

Changing user-account's shell

[Tanguy Le Carrour]

Hi Guix!

I'm trying to set my user's shell through the Guix configuration system,
but without success.

The syntax I use is:

(use-package-modules ... shells)

(operating-system
  ;; ...
  (users (cons (user-account
;; ...
(shell (file-append fish "/bin/fish")))
   %base-user-accounts))

It's from `gnu/system/shadow.scm:112`.

I also found a slightly different syntax in thomassgn's config [1]:

(shell #~(string-append #$bash "/bin/bash"))

… but it does not work either!

[1]: https://notabug.org/thomassgn/guixsd-configuration/src/master/config.scm


Am I doing something wrong?! Any help would be welcome!


-- 
Tanguy

Re: Remounting tmpfs

[Ludovic Courtès]

Hi,

7e9wc56emja...@s.rendaw.me skribis:

> On 4/9/19 11:58 PM, Ludovic Courtès wrote:
>> Hello,
>>
>> 7e9wc56emja...@s.rendaw.me skribis:
>>
>>> On a system I'm porting to guix I have 2GB tmpfs with subdirectories
>>> like /tmpfs/etc that I remount to /etc with an overlay filesystem.
>>>
>>> The current way I do this in systemd is making a service dependency
>>> between the /tmpfs and /etc mounts that mkdirs /tmpfs/etc and
>>> /tmpfs/etc_work, but AFAICT filesystem definitions in guix can only have
>>> filesystem dependencies.
>>>
>>> Are there any other ways I can do this without copying/pasting/modifying
>>> gobs of core guix code into my system definition?  Like somehow
>>> appending (mkdir /tmpfs/etc) onto the tmpfs filesystem service start
>>> procedure or something.
>> In Guix /etc is mostly populated by “activation programs”, which are
>> generated from your config.  So I’m not sure what you describe would
>> make much sense.
>
> So if /etc can be read-only and boot I'm probably fine... my experience
> with other distros was that some other processes needed to write to it. 
> Ex: modifying resolv.conf.

/etc is writable because of things like ‘resolv.conf’.

/etc consists mostly of immutable files derived directly from your OS
config (/etc/passwd, /etc/hosts, /etc/polkit-1, /etc/pam.d, etc.), along
with files that contains bits of state (/etc/shadow, /etc/resolv.conf.)

The former are directly managed by Guix, while the latter are either
left as is or touched with care by Guix (/etc/shadow in particular.)

>> Now, you could try to add a file system declaration that mounts /etc,
>> with (needed-for-boot? #t).
>
> My goal is to have a read-only / mount with the ability for programs to
> make temporary modifications for operational purposes when necessary, in
> limited scopes (like /etc).  Can you elaborate on what you're suggesting
> here?  Mounting something other than the overlayfs on /etc would hide
> the system config files.  I might be able to use another mount to create
> a pseudo- /tmpfs/etc_work subdirectory but it sounds kind of wormy and
> overlayfs requires the upper dir and workdir to be the same filesystem
> which I think precludes doing any mounting for those subdirectories.

The overlay makes a lot of sense.  This is what ‘guix system vm’ does:
see the #:volatile-root? parameter of ‘raw-initrd’.

Perhaps you could simply set #:volatile-root? #t in your initrd to
obtain what you want?

Thanks,
Ludo’.

Re: trackpad and icecat trouble

[Joshua Branson]

So, an update on this issue.  I recently black listed usbkbd and usbmouse, I 
switched to the sway wm, and I disabled gdm.  So now I log into a virtual 
console, and i have a bash script that auto starts sway.  My mouse works 
perfectly, and sway is rock stable!  I'm really impressed with it.   You might 
give that a try.

Here is my kernel-arguments line.

  (kernel-arguments 
'("modprobe.blacklist=usbkbd,usbmouse,dm_crypt,pata_acpi,joydev"))

Here is my autostart sway command:  ~/.bash_profile

# Honor per-interactive-shell startup file
if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

#auto start sway on login
if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then
exec sway
fi

You can set the environmental variable XKB_DEFAULT_LAYOUT="dvorak", and sway 
will honor that.  Or you can just a sway config file to ~/.config/sway/config.

I'll attach my config.  Maybe it'll help you out Efraim.


Thanks,

Joshua



config
Description: Binary data

Re: Way to synchronize files like Dropbox

[Christopher Lemmer Webber]

Adam Mazurkiewicz writes:

> What is the way to synchronize files with a remote storage like
> Dropbox? I work in several places and I need to get the same document
> files in these places. On Debian I was using just Dropbox. I need a
> free solution from Guixsd.

I recommend git-annex with git-annex assistant.  However, I don't
remember if all the git-annex tools have been made available in GuixSD;
I seem to remember some of the dependencies weren't made available yet.

GUIX installation / uninstallation problem

[Hans-Werner Roitzsch]

Hello Guix users!

I sort of messed up my Guix setup as follows:

I installed Guix using the binary installer script. The installer asked
me, whether I wanted to allow prebuilt packages and I thought: "Nah, let
it compile packages." Not considering how long that would take initially
and/or with any updates for packages.

Then I started installing the locales as suggested, when you do not have
them yet, which I think is always the case on a fresh Guix installation.
So I started installing those with the command provided by the Guix
installer.

I think it spent already 30min or so compiling stuff, when I canceled
it. Then I started looking for a way to change the prebuilt thingy
setting, as I realized what I had done. I found no way to change the
setting and neither did any web search yield anything helpful. So I went
ahead and thought "Isn't it like a thing contained in one directory? I
should be able to simply delete Guix using `rm -rf` …". I deleted `/gnu`
and a few other locations.

Then I tried to install Guix again, but it refused to "overwrite" an
existing installation. So there must have been traces of the previous
installation left somewhere. I searched more about uninstalling Guix and
found very little. At some point I found the following Arch Linux wiki
link:

https://wiki.archlinux.org/index.php/Guix

I removed all the guixbuilders and the group guixbuild. Then I removed
the other paths mentioned in the wiki article.

Finally Guix installer did not find any previous installation any longer
and installed, seemingly without problems.

But then I started to see the actual problem. When I tried installing
the locales following the installation of Guix an error with the guix
daemon socket came up:

=
guix package -i glibc-utf8-locales
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales'
package and defining `GUIX_LOCPATH', along these lines:

    guix package -i glibc-utf8-locales
    export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.


guix package: error: failed to connect to
`/var/guix/daemon-socket/socket': No such file or directory
=

So now my question is: How can I repair my Guix, its socket, or better
yet: Completely remove and reinstall it?

Thanks for any help!

Hans

Re: dhcpcd logs

[znavko]

Ok. I use dhcp-client instead, cause I need only to get Ip address but not to 
have dncp server.
Some of threads in help-guix has solved my troubles with wifi. and I published 
config to my site live-znavko.pantheonsite.io

April 17, 2019 6:06 AM, "Chris Marusich"  wrote:

>  writes:
> 
>> Where are dhcpcd logs?
> 
> We start dhcpd as described in gnu/services/networking.scm:
> 
> (define dhcpd-shepherd-service
> (match-lambda
> (($  package config-file version run-directory
> lease-file pid-file interfaces)
> (unless config-file
> (error "Must supply a config-file"))
> (list (shepherd-service
> ;; Allow users to easily run multiple versions simultaneously.
> (provision (list (string->symbol
> (string-append "dhcpv" version "-daemon"
> (documentation (string-append "Run the DHCPv" version " daemon"))
> (requirement '(networking))
> (start #~(make-forkexec-constructor
> '(#$(file-append package "/sbin/dhcpd")
> #$(string-append "-" version)
> "-lf" #$lease-file
> "-pf" #$pid-file
> "-cf" #$config-file
> #$@interfaces)
> #:pid-file #$pid-file))
> (stop #~(make-kill-destructor)))
> 
> I checked the manual page for dhcpd ("man dhcpd"). None of those
> options (-4, -lf, -pf, -cf) seem to tell dhcpd to change the way it
> emits logs. However, -cf tells it to look at a config file, which might
> change the way it behaves. What dhcpd config are you using?
> 
> By default, according to the manual, dhcpd emits logs to syslog:
> 
> "Normally, dhcpd will log all output using the syslog(3) function with
> the log facility set to LOG_DAEMON."
> 
> Have you customized the syslog config at all? By default, it is the
> following (defined in gnu/services/base.scm):
> 
> ;; Snippet adapted from the GNU inetutils manual.
> (define %default-syslog.conf
> (plain-file "syslog.conf" "
> # Log all error messages, authentication messages of
> # level notice or higher and anything of level err or
> # higher to the console.
> # Don't log private authentication messages!
> *.alert;auth.notice;authpriv.none /dev/console
> 
> # Log anything (except mail) of level info or higher.
> # Don't log private authentication messages!
> *.info;mail.none;authpriv.none /var/log/messages
> 
> # Like /var/log/messages, but also including \"debug\"-level logs.
> *.debug;mail.none;authpriv.none /var/log/debug
> 
> # Same, in a different place.
> *.info;mail.none;authpriv.none /dev/tty12
> 
> # The authpriv file has restricted access.
> authpriv.* /var/log/secure
> 
> # Log all the mail messages in one place.
> mail.* /var/log/maillog
> "))
> 
> It might be good to check all of the places mentioned above, to see if
> you can find the logs. It looks like the "daemon" log facility might
> get sent to different locations depending on the severity.
> 
> I hope that helps!
> 
> --
> Chris

Re: Way to synchronize files like Dropbox

[Adonay Felipe Nogueira]

Syncthing is good too. I also use rsync, SFTP, or torrents with no 
trackers/publishers. The last one needs an unchanged copy of the files being 
synchronized. SFTP will work friendlier if the file broeser/explorer integrates 
with a copy of GVFS which has SSH SFTP enabled.

Em 16 de abril de 2019 22:29:21 BRT, Benjamin Slade  escreveu:
>I would also recommend syncthing. I use it to synchronize files between
>several computers (including a GuixSD one) as well as mobile. 

-- 
- Página com formas de contato:
  https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do software livre (não confundir com o gratuito). Avaliador
  da liberdade de software e de sites.
- Página com lista de contribuições:
  https://libreplanet.org/wiki/User:Adfeno#Contribs
- Para uso em escritórios e trabalhos, favor enviar arquivos do padrão
  internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e
  correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de
  escritório recomendada para editar tais arquivos.
- Para outros formatos de arquivos, veja:
  https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
  https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
  permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
  (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook
  #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
  #Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
  https://www.defectivebydesign.org/