Re: Guix Home Issues: Redshift Service Won't Run (Problem with Wayland?)
On Tuesday (November 28, 2023) at 05:45:28 AM CST, Tomas Volf wrote: > > [1 ] > On 2023-11-28 03:02:58 -0600, Jaft wrote: > > I dunno if anyone would be able to help but I've had this issue where > > the Redshift home service just won't run. > > > > My config. is below but, as it's (relatively) long, I'll put it last. > > > > Looking at ~herd status redshift~, it says that it's stopped and > > disabled but, I also noticed, says it requires =x11-display=. I'm > > guessing this may be a reason the service keeps getting disabled and > > refuses to run? > > > > But Redshift works with Wayland (I'm using the =redshift-wayland= > > package); is there something I'm supposed to do to get the service to > > play nice with Wayland? I'm running XWayland. > > I do not use redshift nor wayland, so this is based just on a quick look at > the > service definition. If you check the gnu/home/services/desktop.scm file, > definition of redshift-shepherd-service, you will see that the dependency on > x11-display is non-conditional. > > As a test, you could just remove the requirement from the shepherd service and > see if that helps. If it does work, the dependency should probably be made > optional. I do not know if there is something like wayland-display service. So I tried removing ~(requirement '(x11-display))~ from =redshift-shepherd-service= but that resulted in an error from ~string-append~ (trying to append ~#f~). So I commented out the adjustment of the =DISPLAY= variable in ~#:environment-variables~ and that resulted in, finally, no errors but Redshift, nevertheless, failing. Since the environment variable was returning ~#f~, I hardcoded it to "0:0" and set =WAYLAND_DISPLAY= to "wayland-1"; and that did the trick! At least, it seems so; I see it running in =htop=, now; going to have to wait until later tonight to see if things get less blue.
Guix Home Issues: Redshift Service Won't Run (Problem with Wayland?)
I dunno if anyone would be able to help but I've had this issue where
the Redshift home service just won't run.
My config. is below but, as it's (relatively) long, I'll put it last.
Looking at ~herd status redshift~, it says that it's stopped and
disabled but, I also noticed, says it requires =x11-display=. I'm
guessing this may be a reason the service keeps getting disabled and
refuses to run?
But Redshift works with Wayland (I'm using the =redshift-wayland=
package); is there something I'm supposed to do to get the service to
play nice with Wayland? I'm running XWayland.
Not as pressing (or clear as to what might be wrong) but I've had
trouble getting the batsignal service to work right, as well. That one
does seem to run (I can see a running instance on my machine) but it
doesn't ever provide notifications. It worked the /first/ time I
ran/installed it and hasn't ever worked since – it never gives any
notifications for anything I set. I'm pretty certain it works if I run
=batsignal= manually, though (just not when ran via the service). Any
ideas?
> (use-modules (gnu home)
> (gnu home services)
> (gnu home services desktop) ; home-redshift-service-type
> (gnu home services mcron) ; home-mcron-service-type
> (gnu home services pm) ; home-batsignal-service-type
> (gnu home services shells) ; home-bash-service-type
> (gnu packages)
> (gnu packages pantheon) ; pantheon-wallpapers
> (gnu packages xdisorg) ; redshift-wayland
> (gnu services)
> (guix gexp)
> (guix packages) ; package-output
> (guix store) ; with-store
> (ice-9 ftw)) ; scandir
>
> (let* ([ homeDir (passwd:dir (getpwnam (getlogin)))]
>[configDir (string-append homeDir "/.config/guix")]
>[exclude-rel-paths (lambda (file)
> (not (or (string= "." file)
>(string= ".." file])
> (home-environment
> ;; Below is the list of packages that will show up in your
> ;; Home profile, under ~/.guix-home/profile.
> (packages (list pantheon-wallpapers))
>
> ;; Below is the list of Home services. To search for available
> ;; services, run 'guix home search KEYWORD' in a terminal.
> (services (list (simple-service 'some-useful-env-vars-service
> home-environment-variables-service-type
> `(("QT_QPA_PLATFORM" . "wayland;xcb")
> ("GDK_BACKEND" . "wayland,x11")
> ("PATH". ,(string-append
> "$PATH" ":$HOME/.local/bin"
>
> ":$HOME/.fly/bin"))
> ("GUIX_PROFILE".
> "$HOME/.guix-profile")
> ("EDITOR" . "emacs -nw")))
> (servicehome-bash-service-type
> (home-bash-configuration
> (environment-variables
> `(("QT_QPA_PLATFORM" . "wayland;xcb")
>("GDK_BACKEND"
> . "wayland,x11")))
> (aliases '(("la" . "ls
> -A")
>("ll" . "ls
> -l")
>("lsds" . "ls
> -p1 $* | grep /")
>("lsde" . "ls
> -Alh $* | grep ^d")
>("lsd" . "ls
> -Ap1 $* | grep /")))
> (bash-profile (list
> (local-file "./bash/initialize_wayfire.sh"
>
> "bash_profile")))
> (bashrc(list
> (local-file "./bash/rc.sh" "bashrc")
>
> (local-file "./bash/ps1.sh" "bashrc")
> (simple-service 'home-dir
> home-files-service-type
> (append `((".gtkrc-2.0" ,(local-file
> "./gtk/gtkrc-2.0")))
> (map (lambda (file)
>(list (string-append
> "Templates/" file)
> (local-file
> (string-append configDir
>
> "/Templates/"
>
Re: Every Reconfigure of Guix Home Results in "Connection Refused"
Hey, David. I'm not sure that your issue is the same of mine. Mine seemed to be a socket issue specifically related to Shepard (which, I suppose, makes sense as I was trying to start services). Mine went away when I restarted my computer; I could've sworn I did a guix pull before trying to reconfigure my Guix Home but maybe I hadn't and that was related; I'm not sure. Either way, it hasn't reoccurred since restarting (the services don't seem to get updated on any second reconfigure and require me to restart the computer to take effect but I think that's an unrelated situation to the one I originally reported and probably more of an inquery question for me to ask). Sorry I can't be more helpful; I hope you're able to resolve it! Granted, I am running GuixSD and not just Guix on a foreign distro (I'm not sure which of those you are doing) so what we require may be different, to solve the same issue. I can't say that I've ever had to start Shepard, myself, and that'd probably be the first place I'd look, in trying to pin down what's wrong. I'm pretty certain both your system config.scm and your Guix Home configuration should take care of connecting any services you define to Shepard when you reconfigure them without you having to manually run anything (beyond the reconfigure command); that's a huge part of the benefit of Guix – just being able to declaratively define the config. and everything else takes care of getting it to work, rather than imperatively running commands yourself and, possibly, running something in the wrong order (or whatever, etc.) which might introduce unexpected behavior.On Monday, May 29, 2023, 08:25:51 AM CDT, David Conner wrote: Sorry for the duplicate messages. I'm still getting Gnus configured and getting used to everything. I didn't realize there was a difference between a reply and a followup. Did you ever resolve this? I think I may be getting a similar error as you, but I'm not running Guix Home yet. https://lists.gnu.org/archive/html/help-guix/2023-05/msg00201.html I've attached strace logs in the issue I submitted. I'm not sure how you would get logging for Shepherd from within Guix Home. You could isolate things and test launching Shepherd by writing an =init.scm= and trying to start the services manually, but to do so, you'd have to create a Guix Profile with the binaries required for launching Shepehrd. I'm starting shepherd from inside .xsession and testing it with: =shepherd -s test.sock -c test.scm -l test.log --pid=test.pid= I can usually get the =mcron= service to start. Really, I think I can get a single service to start, but if I try to load anything more than that, I'm getting: #f "Attempt to suspend fiber within continuation barrier" () #f As part of moving towards Guix Home, I created a system definition for wayland/sway, but even there, I was getting the error. And now think about it, I'm running the =/run/current-ssytem/profile/bin/shepherd= binary, so maybe if I bundle this in with a user profile, it will work. -- David Conner
Including Cargo Input that's Pulled in By Git in .toml File
I packaged up a Crate that's being pulled in by another package with Git but =cargo-build-system= keeps trying to pull it from GitHub (which, naturally, it can't do). Is there something else I need to do beyond including it via the ~#:cargo-inputs~ =argument=? Alternatively, if there a way to get the =cargo-build-system= to not include it? It's marked as ~optional~ in the =Cargo.toml= file but =cargo-build-system= keeps trying to fetch it. Thanks!
Every Reconfigure of Guix Home Results in "Connection Refused"
Playing around with Guix Home and have, more or less:
> (use-modules (gnu home)
> (gnu home services)
> (gnu home services mcron)
> (gnu home services pm)
> (gnu home services shells)
> (gnu packages)
> (gnu packages gnome)
> (gnu packages monitoring)
> (gnu services)
> (guix gexp))
>
> (home-environment
> ;; Below is the list of packages that will show up in your
> ;; Home profile, under ~/.guix-home/profile.
> (packages (list batsignal))
>
> ;; Below is the list of Home services. To search for available
> ;; services, run 'guix home search KEYWORD' in a terminal.
> (services (list (simple-service 'some-useful-env-vars-service
> home-environment-variables-service-type
> '(("QT_QPA_PLATFORM" . "wayland;xcb")
> ("GDK_BACKEND" . "wayland,x11")))
> (service home-bash-service-type
> (home-bash-configuration
> …))
> (simple-service 'pull
> home-mcron-service-type
> ;; Every day at 2 P. M.
> (list #~(job '(next-hour '(14)) "guix
>pull"))
Without the =mcron= service, running ~guix home reconfigure~ works fine.
But the second I add the service, every reconfigure results in "error: connect:
/run/user/1000/shepherd/socket: Connection refused". I get a similar behavior
if I try to use =home-batsignal-service-type=.
Would anyone know the cause for this?
Additionally, =batsignal= doesn't seem to be ending up in my path; do I have to
add "~/.guix-home/profile/bin/" to my path manually? I would've expected Guix
Home to take care of that, for me, automatically.
Re: Help with DBus Tests Failing for Python Package
On Tuesday, December 27, 2022 at 11:49:31 AM CST, Maxim Cournoyer wrote: > I bet this is because of the expectation of python-dbus on the processes > being reaped by PID 1 instead of staying around as zombies, as currently > happens in the Guix build container (see: > https://issues.guix.gnu.org/30948). > > The current workaround currently used in Guix involves the use of tini > and of a forked process... it's not very pretty (see 'guix edit mutter' > for such an example). Thanks a ton for the pointer, Maxim. Unfortunately, I still seem to be getting the same result. At first, I tried a simple approach of ~(execlp "tini" "--" "python" "setup.py" "test")~; I think it wound up still requiring the =dbus= package, to run. That failing, I decided to try something closer to what =mutter= was doing with > (arguments (list #:imported-modules > `(,@%python-build-system-modules > (guix build syscalls)) > #:modules > '((guix build python-build-system) > (guix build syscalls) > (guix build utils) > (ice-9 match)) > #:phases > #~(modify-phases %standard-phases > (replace 'check > (lambda* (#:key tests? #:allow-other-keys) > (when tests? > ;; Setup (see the 'test-mutter' CI target at > ;; >https://gitlab.gnome.org/GNOME/mutter/-/raw/main/.gitlab-ci.yml). > (setenv "HOME" "/tmp") > (setenv "XDG_RUNTIME_DIR" (string-append (getcwd) > >"/runtime-dir")) > (mkdir (getenv "XDG_RUNTIME_DIR")) > (chmod (getenv "XDG_RUNTIME_DIR") #o700) > > (setenv "GSETTINGS_SCHEMA_DIR" "data") > (setenv "MUTTER_DEBUG_DUMMY_MODE_SPECS" >"800x600@10.0") > ;; (setenv "PIPEWIRE_DEBUG" "2") > ;; (setenv "PIPEWIRE_LOG" >"meson-logs/pipewire.log") > (setenv "XVFB_SERVER_ARGS" "+iglx -noreset") > (setenv "G_SLICE" "always-malloc") > (setenv "MALLOC_CHECK" "3") > (setenv "NO_AT_BRIDGE" "1") > ;; This is needed, otherwise the >"mutter:core+mutter/unit / > ;; anonymous-file" test would fail (see: > ;; >https://gitlab.gnome.org/GNOME/mutter/-/issues/2017). > (setenv "CI_JOB_ID" "1") > > ;; (invoke "glib-compile-schemas" (getenv >"GSETTINGS_SCHEMA_DIR")) > (mkdir-p (getenv "XDG_RUNTIME_DIR")) > (chmod (getenv "XDG_RUNTIME_DIR") #o755) > ;; (invoke "pipewire" "--version") ;check for >pipewire > ;; (system "pipewire &") ;always returns 0 due >to forking > > (match (primitive-fork) > (0 ;child process > (set-child-subreaper!) > ;; XXX: Tini provides proper PID1-like signal >handling that > ;; reaps zombie processes, necessary for the > ;; 'test_shutdown_subprocesses' test to pass. > > ;; TODO: Complete >https://issues.guix.gnu.org/30948. > ;; (execlp "tini" "--" "python" "setup.py" >"test") > (execlp "tini" "--" > "dbus-run-session" "--" > "xvfb-run" "-a" "-s" (getenv >"XVFB_SERVER_ARGS") > "python" "setup.py" "test")) > (pid > (match (waitpid pid) > ((_ . status) > (unless (zero? status) > (error "`pytest' exited with status" > status I know some bits there are definitely not relevant; I figured I could clean it up, after, if things worked but I'm still getting the exact same errors. Just to make sure /I'm/ not doing something incorrectly, is this within what you meant? Or did I do anything that's obviously not correct, in this setup?
Re: Help with DBus Tests Failing for Python Package
So I tried a different tactic and, noticing the error said the issue was
~dbus-session~ didn't exist, did this, instead:
> (arguments (list #:phases #~(modify-phases %standard-phases
> (add-before 'check 'start-xserver
> (lambda _
> ;; Tests require a running dbus-daemon.
> (system "dbus-daemon &")
> ;; For missing '/etc/machine-id'.
> (setenv "DBUS_FATAL_WARNINGS" "0"))
> (inputs (list python python-pygobject))
> (native-inputs (list xorg-server-for-tests))
This works much better and the 232 tests get run; most, even pass…except 4. The
output is thus:
> test_get_object_path (tests.test_proxy.DBusProxyTestCase)
> Test get_object_path. ... ok
>
> ==
> FAIL: test_async_calls (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus async calls with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>420, in test_async_calls
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _call_hello_async has finished with 1
>
> ==
> FAIL: test_properties (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus properties with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>457, in test_properties
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _set_pipes has finished with 1
>
> ==
> FAIL: test_signals (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus signals with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>481, in test_signals
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _trigger_signal has finished with 1
>
> ==
> FAIL: test_sync_calls (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus sync calls with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>398, in test_sync_calls
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _call_hello_sync has finished with 1
>
> --
> Ran 232 tests in 681.414s
>
> FAILED (failures=4)
> Test failed:
> error: Test failed: failures=4>
> error: in phase 'check': uncaught exception:
> %exception #< program: "python" arguments: ("-c" "import
> setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" "test") exit-status: 1
> term-signal: #f stop-signal: #f>
It doesn't look like enough to clearly tell /why/ things failed (and looking
through the source of the particular failing tests isn't much clearer, for me,
unfortunately) but maybe someone's run across a similar experience, before,
that might indicate something to try.
On Monday, December 26, 2022 at 10:18:55 PM CST, Jaft
wrote:
> I'm attempting to package the Python package DasBus
> (https://github.com/rhinstaller/dasbus/) and the tests, when it tries to test
> by making DBus calls, are failing.
>
> For specificity, the error output is:
>
> > test_additiona
Help with DBus Tests Failing for Python Package
I'm attempting to package the Python package DasBus
(https://github.com/rhinstaller/dasbus/) and the tests, when it tries to test
by making DBus calls, are failing.
For specificity, the error output is:
> test_additional_arguments (tests.test_dbus.DBusExampleTestCase)
> Call a DBus method. ... **
> GLib-GIO:ERROR:../glib-2.70.2/gio/gtestdbus.c:667:start_daemon: assertion
> failed (error == NULL): Failed to execute child process “dbus-daemon” (No
> such file or directory) (g-exec-error-quark, 8)
> Bail out! GLib-GIO:ERROR:../glib-2.70.2/gio/gtestdbus.c:667:start_daemon:
> assertion failed (error == NULL): Failed to execute child process
> “dbus-daemon” (No such file or directory) (g-exec-error-quark, 8)
> error: in phase 'check': uncaught exception:
> %exception #< program: "python" arguments: ("-c" "import
> setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" "test") exit-status:
> #f term-signal: 6 stop-signal: #f>
I tried using ~xorg-server-for-tests~ and initializing the server before the
=check= phase but I'm still running into the same error.
Would anyone know what might be a cause?
> (define-public python-dasbus
> (package
> (name "python-dasbus")
> (version "1.7")
> (source (origin
> (method url-fetch)
> (uri (pypi-uri "dasbus" version))
> (sha256 (base32
>
>"1xmn6q00v3kif5q8jcq6vi84k6xb97s2ry5rgdgyxs6z3a20v1d8"
> (build-system python-build-system)
> (arguments (list #:phases #~(modify-phases %standard-phases
> (add-before 'check 'start-xserver
> (lambda _
> (system "Xvfb :1 &")
> (setenv "DISPLAY" ":1"))
> (inputs (list python python-pygobject))
> (native-inputs (list xorg-server-for-tests))
> (home-page "https://github.com/rhinstaller/dasbus;)
> (synopsis "DBus library in Python 3")
> (description "DBus library in Python 3")
> (license #f)))
Re: Wayland Functionality for Jami
Bumping this, just in case. On Wednesday, October 5, 2022 at 03:52:49 PM CDT, Wamm K. D. wrote: The Jami available in the repo.s, currently, causes an error about the Wayland plugin for QT not being available. While some app.s don't require this to be bundled with the app. – apparently (I run into similar errors for Qutebrowser but installing QTWayland fixes the issue) –, Jami does. Building the package definition in the repo. exactly as is but with QTWayland added as an additional ~input~ causes Jami to be able to be used under Wayland perfectly. So my question is, what would be the best means of updating this package? Should QTWayland just get added to the ~inputs~, even for users who aren't running Wayland? Or would it make sense to just create a second Jami package definition (called =jami-wayland= or something) that ~inherit~s the original Jami package and just adds QTWayland to the ~inputs~? Or a third option?
Re: Trying to Build (Elixir) Mix Packages
Mmm; interesting. I'm going to have to keep that in mind. I managed to get things to work, finally with installing ~gcc-toolchain~, rather than just ~gcc~, and running it again in a new terminal than the one I installed the Guix packages in. Thanks a ton for the advice! On Friday, July 15, 2022, 01:58:53 AM CDT, pukkamustard wrote: I've had similar issues and was able to resolve them by setting the `CC` environment variable: CC=gcc mix build hth, pukkamustard Jaft writes: > I installed Elixir (from the Guix repo.s) and was trying to install > some dependencies. I don't know if anyone will know how to help but > I'm entirely out of my depth so I figured I'd at least ask around. > > Unfortunately, some of these dependencies have bits of C that ~mix~ > attempts to compile. Usually, these require the use of ~rebar3~ so I > installed that and pointed ~mix~ towards my Guix binary. That seems > fine. > > It then asks for ~make~ and ~gcc~; in an attempt to just see if it > would work, I tried just installing those (~gcc~ version 10, 11, and > 12 were tried). > > While it asks for ~gcc~, ~cc~ attempts to be used; so, again trying to > see if it would work, I make a soft link of ~cc~ to the installed > ~gcc~. > > This starts to compile but results in the error I'll post > below. …anyone have any ideas about how to solve/work-around this? > Very much thanks in advance. > > > > mkdir -p /home/jaft/MEGA/gits/Swanye/_build/dev/lib/argon2_elixir/priv > cc -g -O3 -pthread -Wall -Wno-format-truncation > -I"/gnu/store/7m5g7dc6qkgv1ri92al3ims6cmdscwn9-erlang-25.0.2/lib/erlang/erts-13.0.2/include" > -Iargon2/include -Iargon2/src -Ic_src -shared -fPIC > -fvisibility=hidden -Wl,-soname,libargon2.so.0 argon2/src/argon2.c > argon2/src/core.c argon2/src/blake2/blake2b.c argon2/src/thread.c > argon2/src/encoding.c argon2/src/ref.c c_src/argon2_nif.c -o > /home/jaft/MEGA/gits/Swanye/_build/dev/lib/argon2_elixir/priv/argon2_nif.so > In file included from > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/posix1_lim.h:161, > from > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/limits.h:195, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/limits.h:195, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/syslimits.h:7, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/limits.h:34, > from argon2/include/argon2.h:23, > from argon2/src/argon2.c:22: > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/local_lim.h:38:10: > fatal error: linux/limits.h: No such file or directory > 38 | #include > | ^~~~ > compilation terminated. > In file included from > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/posix1_lim.h:161, > from > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/limits.h:195, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/limits.h:195, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/syslimits.h:7, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/limits.h:34, > from argon2/include/argon2.h:23, > from argon2/src/core.h:21, > from argon2/src/core.c:35: > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/local_lim.h:38:10: > fatal error: linux/limits.h: No such file or directory > 38 | #include > | ^~~~ > compilation terminated. > In file included from > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/bits/posix1_lim.h:161, > from > /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/include/limits.h:195, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/limits.h:195, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/syslimits.h:7, > from > /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/10.3.0/include-fixed/limits.h:34, > from argon2/include/argon2.h:23, >
Re: Updating LXTerminal from v0.3.2 to v0.4.0
Wow; 'thought I'd sent this sometime last year. Your response, unfortunately, got put in the Spam folder and I just found it and thought it'd been months since you got back to me. Apparently, my last two months have been /rough/. zimoun writes: > Hi, > > On Mon, 07 Mar 2022 at 18:12, Jaft wrote: > >> Starting download of >> /gnu/store/89xj37ra014gxky8kmjrrbf3ndnia36l-lxterminal-0.4.0.tar.xz >> From >> http://downloads.sourceforge.net/project/lxde/LXTerminal%20%28terminal%20emulator%29/LXTerminal%200.4.0/lxterminal-0.4.0.tar.xz... >> download failed >> "http://downloads.sourceforge.net/project/lxde/LXTerminal%20%28terminal%20emulator%29/LXTerminal%200.4.0/lxterminal-0.4.0.tar.xz; >> 404 "Not Found" > > I think the error is because a wrong ’.0’ instead of ’.x’. > > This URL works for me: > > http://downloads.sourceforge.net/project/lxde/LXTerminal%20%28terminal%20emulator%29/LXTerminal%200.4.x/lxterminal-0.4.0.tar.xz Awesome; thanks a ton. 'Don't know why I hadn't just thought of it the first time but I went to http://downloads.sourceforge.net/project/lxde/LXTerminal%20%28terminal%20emulator%29/ and clicked on the link for LXTerminal and there was the folder, exactly as you pointed out (with ".x"). Oh, well; better late than never. > Hope that helps. By leaps and bounds. Just managed to build it; I switched to Wayland so no longer using LXTerminal but I'm sure others would like the newer version: 'gonna get this into a patch and send it in. Thanks (a ton), again!
Re: Android Device Mounting Detection with GVFS Help
> On Saturday, February 26, 2022, 04:27:23 PM CST, Tobias Geerinckx-Rice > wrote: > > > > > > Jaft, > > > Not quite equivalent to GVFS/udisks (for me that's a feature), but I'm > very happy with jmtpfs. Heh, – funnily enough – jmtpfs was recommended to me by someone in that Reddit thread I linked to. When my additional udev rules were causing the phone to be recognized (but still not mounting), I tried running jmtpfs to see if it spotted anything and it told me there weren't any MTP devices available.
Re: Android Device Mounting Detection with GVFS Help
Hmm; that's unfortunate. I can't say I've noticed any of the other behavior (thankfully?) but not recognizing my phone's definitely been an obvious one. Heh, I suppose it's all the more disappointing as I seem to've gotten close. Have you been using an alternative to GVFS (I know some people use udiskie, instead)? Or just tolerating the bugginess? On Monday, February 21, 2022, 07:08:57 PM CST, raingloom wrote: On Mon, 14 Feb 2022 11:19:29 + (UTC) Jaft via wrote: > I dunno if anyone might have any suggestions but I've been trying to > get my Android phone get detected. I'm using GVFS and Thunar; full > details of what I originally tried are at > https://www.reddit.com/r/GUIX/comments/s55e8m/smartphone_detection_with_gvfs/ > but the short of it is that I noticed that the 69-libmtp.rules file > that Guix installs differed from my Debian machine so I added a > udev-rules-service that added all the devices that were in the Debian > file and found the device was recognized, now, but trying to click on > it or mount it still resulted in the error "No mtp devices found." > > Someone on the IRC channel recommended trying android-udev-rules so I > did; this resulted in the phone not getting recognized, when plugged > in, by Thunar, again – but it was able to be recognized as a > connected device by adb. I've attached my system config. file, so > it's clear to see what the setup I've tried is; I have no idea what > else to try (if there's anything else even to try) but thanks for any > help! GVFS in general seems extremely buggy, but especially on Guix. If you manage to figure this out I'd be very interested. Other fun GVFS related issues include: - sometimes mounts just plain don't show up (no /run/user/$UID/gvfs entry) - removable drives only show up once you've run fstab --list on them. they can be mounted with udiskctl, but they aren't visible in Nautilus. - incorrect handling of symlinks can lead to data loss, bug has been known for years and no workaround or fix exists.
Only Using Openbox (vs GNOME/Openbox or KDE/Openbox); and xfce4-power-manager and polkit
So I got Guix working on a laptop and've been playing around with the system
config.
I've been trying to see how things work and figuring out what to use a service
for and what to install a package for. I have part of my config. as so,
currently:
(users (cons* (user-account (name "name")
(comment "Full N. Ame") (group "users")
(home-directory "/home/name") (supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts))(packages (append (list (specification->package
"openbox") (specification->package "nss-certs") bc dunst
compton inxi-minimal htop lxterminal lxappearance catfish thunar
thunar-volman xfce4-power-manager arandr tint2 rofi clipmenu
seahorse file-roller gnome-calculator gnome-font-viewer
gnome-screenshot gnome-themes-standard papirus-icon-theme
font-abattis-cantarell font-fira-code ncdu pulsemixer i3lock nitrogen
viewnior) %base-packages))(services (cons* (service
slim-service-type (slim-configuration
(display ":0") (vt "vt7")))
(modify-services %desktop-services (delete gdm-service-type
One of the things I'd like to change is SLiM shows three types of Openbox to
start; I'm assuming they all get setup as options with the Openbox package but
I'd like to just use Openbox and GNOME/Openbox keeps showing up as the first
option so I have to cycle twice to get the one I want every time I login.
Is there a means to remove the other two?
Secondly, trying to start xfce4-power-manager requires having to give a
password; given it's a daemon, it feels like it almost should have a
correlating service (outside of having to use an entire desktop environment
service) but I wasn't able to find one.
Is there a way to start xfce4-power-manager on startup (even if it's just via
Openbox's autostart) such that the user's password isn't involved? And, if so,
is there a best means to do so within the context of running Guix?
Thanks for any help!
Jonathan
Re: Running Out of Inodes
Oh, that's really cool. Good to know; I've never used anything outside of (ex)fat, ntfs, or ext4 and btrfs sounds interesting. I may have to play around with it more extensively, at some point. Jonathan On Sunday, November 14, 2021, 09:18:22 PM CST, Thiago Jung Bauermann wrote: Hello Jonathan, Em domingo, 14 de novembro de 2021, às 15:47:54 -03, Jaft via escreveu: > Out of curiosity, I read that Btrfs requires periodic > fragmentation; how often do you find yourself doing it and do you use > any particular program for it (if you don't mind sharing, of course; I > know it's not directly Guix related)? I use btrfs for several years now — not with Guix System, though I do have Guix installed on top of Ubuntu on btrfs so I do have /gnu/store on btrfs. My experience is that it is zero-maintenance, at least on a personal laptop workload. Btrfs has matured a lot over the years, so there’s a fair amount of outdated advice still floating around on the Internet. You’re probably thinking of the ‘btrfs balance’ command. In the past, it was useful to run it every once in a while to avoid spurious ENOSPC errors. This problem has since been fixed, and current advice is that regular use of “btrfs balance” is now considered detrimental rather than beneficial since it puts more load/stress on the disk without any practical benefit. -- Thanks, Thiago
Re: Running Out of Inodes
Mmm; that makes sense. 'Dunno why my brain interpreted it as "more inodes"; thanks for pointing it out. I just opted to make /gnu/store its own Btrfs partition; I don't trust myself to be able to properly estimate how many inodes I might need and it's been working really well, thus far. Thanks for the info. you provided, though; it was helpful in understanding what's going on. Jonathan On Sunday, November 14, 2021, 03:01:39 PM CST, Vincent Legoll wrote: Hello, On Sun, Nov 14, 2021 at 7:58 PM Jaft via wrote: > Heh, – well – I tried the large_dir suggestion in that thread and GRUB had > the same freak-out (in retrospect, not surprising as the E-mails are only from > 2020; dunno why I thought I'd seen 2017, on first read…). There's a "2017" mention in the thread referenced by Petr, maybe that's where you saw it. > using a root partition of about 46G > About 17 packages in, I started getting a "No space left on device" error; > looking closer at it, – while I still had ~20% of free disk space available – > I was fresh out of free inodes. If your problem is really being out of free inodes, I don't think the "large_dir" option is your solution, because it only increase the number of files per directory limit, it does not increase the available number of inodes. Maybe you should manually create the filesystem with mke2fs and specify a bigger number of inodes with its "-N" parameter. Tell us if you find a way around the problem. -- Vincent Legoll
Re: Running Out of Inodes
Heh, – well – I tried the large_dir suggestion in that thread and GRUB had the same freak-out (in retrospect, not surprising as the E-mails are only from 2020; dunno why I thought I'd seen 2017, on first read…). I remember, when first trying to look into this, seeing someone say, "This is why I always use Btrfs for my /gnu/store partition," so maybe that's my best bet. Out of curiosity, I read that Btrfs requires periodic fragmentation; how often do you find yourself doing it and do you use any particular program for it (if you don't mind sharing, of course; I know it's not directly Guix related)? JonathanOn Sunday, November 14, 2021, 07:47:23 AM CST, phodina wrote: Hi Jonathan, On Nov 14, 2021, 12:14 PM, Jaft via < help-guix@gnu.org> wrote: Hey, hey. It could very well be my own ignorance about things but I'm running into an issue that I wouldn't think I'd run into so naïvely; if there's any further light to be shed, I very much appreciate it. I wanted to try out Guix so I installed it to a laptop I have; the previous distro I had on there had been using a root partition of about 46G so I just decided to keep the same partition setup (though reformatting each one). About 17 packages in, I started getting a "No space left on device" error; looking closer at it, – while I still had ~20% of free disk space available – I was fresh out of free inodes. I remembered that someone I'd read, somewhere, had said you'd probably want, at least, 50G for Guix so I figured I probably shot myself in the foot with so small a root and just opted to reinstall. This time, I deleted the home partition and the root one to create one 156G partition for the entire install and figured that'd be sufficient (I've been using ext4 for these, in case that information is relevant, any). This time, though, I managed 21 packages before running into the same issue. There's still 70% of the disk space free but I'm entirely out of free inodes; leastwise, I was but I tried a guix gc, just to see what all got freed up, and, now, I have 5% of all inodes free. Is this relatively typical? I figured I hadn't done anything particularly out of ordinary usage (Guix's new to me so I literally just did an install and then started installing packages from the gnu channel). Let me know if there's any further or more particular info. to include, if that'd help; I just wouldn't know what to provide. Thanks! Jonathan You might check this thread [1] as it's similar question. Unfortunately I'm running on btrfs. Hope it helps! Kind regards Petr [1]: https://lists.gnu.org/archive/html/help-guix/2020-06/msg00015.html
Running Out of Inodes
Hey, hey. It could very well be my own ignorance about things but I'm running into an issue that I wouldn't think I'd run into so naïvely; if there's any further light to be shed, I very much appreciate it. I wanted to try out Guix so I installed it to a laptop I have; the previous distro I had on there had been using a root partition of about 46G so I just decided to keep the same partition setup (though reformatting each one). About 17 packages in, I started getting a "No space left on device" error; looking closer at it, – while I still had ~20% of free disk space available – I was fresh out of free inodes. I remembered that someone I'd read, somewhere, had said you'd probably want, at least, 50G for Guix so I figured I probably shot myself in the foot with so small a root and just opted to reinstall. This time, I deleted the home partition and the root one to create one 156G partition for the entire install and figured that'd be sufficient (I've been using ext4 for these, in case that information is relevant, any). This time, though, I managed 21 packages before running into the same issue. There's still 70% of the disk space free but I'm entirely out of free inodes; leastwise, I was but I tried a guix gc, just to see what all got freed up, and, now, I have 5% of all inodes free. Is this relatively typical? I figured I hadn't done anything particularly out of ordinary usage (Guix's new to me so I literally just did an install and then started installing packages from the gnu channel). Let me know if there's any further or more particular info. to include, if that'd help; I just wouldn't know what to provide. Thanks! Jonathan
