Hi all,
I am having some trouble updating my home environment on aarch64-linux
as shepherd fails to build. I tried rebuilding multiple times hoping it
would sort itself out like in #30299, but it might take a few more days
if my puny Librem 5 needs to rebuild it 19 times :3.
Log attached.
eikca
Hi all,
I know this isn't a properly submitted patch, but I think the change is
pretty simple. 2024 taxes are comming up in the US. Could someone bump
the version number for opentaxsolver? I tested the following changes
which passed moderate testing on my part.
diff --git a/gnu/packages/financ
Hi all,
I just tried the previous command on Device C, an x86_64-linux Guix System:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 --
build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run
/gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5
Hi Josselin,
Alas, the problem persists ~.~
Device A:
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 --
build qtwebengine --derivations --system=aarch64-linux --no-grafts --dry-run
/gnu/store/gnrk76mlrv3ipm2k3lpmy1533mn9dqc3-qtwebengine-6.5.2.drv
Device B:
~ $ guix time
Saku Laesvuori writes:
> Those hashes are not comparable: i9ir..nd (A) is the hash of the built
> store item and 6n9aq..qn (B) is the hash of the derivation that builds
> the store item.
Ah, rookie mistake :|
> But I do think it is weird if the derivation is not present on the
> machine that bu
Some more context might be useful:
Device A (which successfully built qutebrowser over a couple days)
~ $ guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 --
build qutebrowser --dry-run
/gnu/store/i9ir7a26gv1ii98b4bzgvxp1sx0akind-qutebrowser-2.5.4
Device B (trying to avoid bui
Hi all,
tl;dr I run the following command on two aarch64-linux machines and get
two different hashes for the 'qutebrowser' package:
guix time-machine --commit=deeb7d1f53d7ddfa977b3eadd760312bbd0a2509 -- build
qutebrowser --dry-run
Both machines use only the main guix repository, and guix descri
Hi Guix!
I noticed that the emacs package has the following value for
tramp-remote-path out of the box:
(tramp-default-remote-path "~/.guix-profile/bin" "~/.guix-profile/sbin"
"/run/current-system/profile/bin" "/run/current-system/profile/sbin"
"/bin" "/usr/bin" "/sbin" "/usr/sbin" "/usr/local/bi
And just like that, i find there is already a discussion of some of this
in 56050, though the fact that non-existant paths can be added by guix
home to those variables is seems to be missing from that discussion.
Could someone merge the threads? (I assume I can't do that.)
-Zacchae
Hi all!
$HOME/PROFILE/setup-environment contains the following lines:
case $XDG_CONFIG_DIRS in
*$HOME_ENVIRONMENT/profile/etc/xdg*) ;;
*) export XDG_CONFIG_DIRS=$HOME_ENVIRONMENT/profile/etc/xdg:$XDG_CONFIG_DIRS
;;
esac
There are two bugs in this code. Both bugs revolve around what happens
, 2023 6:40 AM
To: Zacchaeus Scheffer ;
60...@debbugs.gnu.org <60...@debbugs.gnu.org>
Subject: Re: bug#60545: Keras h5py Version Mismatch
CAUTION: Email originated externally, do not click links or open attachments
unless you recognize the sender and know the content is safe.
Hi,
On Wed,
Oh wow, should have read closer. That's a shepherd socket, not a syncthing
socket. (happened across this thread searching syncthing)
Please Disregard,
Zacchae
Hi all,
Not sure if it is relevant, but I have often had this problem, and it
has always been from an orphaned syncthing process. I.e, the user login
session which has my guix home services running in it ends, but the
syncthing process is not terminated. Then I start a new login, and it
tries
Hi Guix!
It would seem that the current keras version expects an earlier h5py version
for loading models. Specifically, running:
from tensorflow.keras.models import load_model
model = load_model("model.h5")
fails with:
File
"/gnu/store/idfn4l2kxil9id21v1yci4jcw6103fah-profile/lib/python3.
On Mon, Jul 4, 2022 at 1:50 AM Andrew Tropin wrote:
> On 2022-02-15 13:46, Zacchaeus Scheffer wrote:
> > There seems to be some problem installing password-store + pinentry
> > entirely via guix home. When I have both installed as such, I get the
> > following outputs:
>
enize;__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>
phase `check' failed after 8.3 seconds
command "python" "-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" failed with
status 1
builder for
`/gnu/store/n0s40wdrkc8sgdlkdv67d4y23yl7acir-synapse-1.61.1.drv' failed
with exit code 1
So it looks like the library I packaged (python-matrix-common) is not being
found. Anyone more experienced with packaging python have any ideas? The
matrix-common repository can be found at
https://github.com/matrix-org/matrix-python-common.
Thanks,
Zacchaeus
-1.2.0/bin/pinentry
lrwxrwxrwx 1 root root 71 Dec 31 1969
/home/zacchae/.guix-profile/bin/pinentry ->
/gnu/store/3hl7w63q0axngysrslkdw2a6jmgnm8kf-pinentry-1.2.0/bin/pinentry
So it's not as simple as a version mismatch.
-Zacchaeus
about two months behind, so sorry if this has already
been patched.
-Zacchaeus
better
solution, for now I am going to have guix home run "guix package -m" with
an empty manifest on reconfigure.
Thanks all for your help,
Zacchaeus
figure, after a normal guix pull, not make even a fresh login shell
able to launch minetest?...
One last test to show off the weirdness:
guix pull
guix show qutebrowser - > version 2.4
qutebrowser --version - > version 2.3
guix home reconfigure ... - > full
d).
My understanding is that "guix home reconfigure" SHOULD behave like "guix
package --manifest", and install all packages in the most recent guix pull.
Very minor and not impeding me, but thought y'all should know,
-Zacchaeus Scheffer
ome))
(if (not (file-exists? ".ssh"))
(mkdir ".ssh"))
(chmod ".ssh" #o700)
(chdir ".ssh")
(let ((port (open-output-file "authorized_keys")))
(display (ungexp authorized-keys) port)
(close-port port))
(chmod "authorized_keys" #o600)
(chdir ".."
where 'user-home and 'authorized-keys are appropriate strings defined
earlier in the file.
I believe that resolves the issue,
Zacchaeus Scheffer
f the day, there will be setup that should NOT happen
automatically (should require gpg passphrase input). Currently, I do this
for private keys by automatically pulling from my password store
(requiring password input) using fancy emacs org tangling. I'll look
into managing even this with guix home, but that is probably a discussion
for guix-devel.
Thanks all,
Zacchaeus Scheffer
It seems the permissions on the symlink don't matter. The problem is that
the file linked to in the store is readable by everyone (which I am ok with
because it's just public keys).
There is a solution with guix system by configuring openssh directly (see
openssh-configuration -> authorized-keys)
I finally migrated my home configuration to guix home. However, it seems
guix home creates all symlinks with 777 permissions. This causes problems
with openssh as it will not recognize my ~/.ssh/authorized_keys. It seems
the directories have reasonable permissions (maybe because they already
exi
me time...
It fails with:
command "make" "test" "CC=gcc"
"PREFIX=/gnu/store/jyjm47609k160r2rcfaiwz3ncs0qjwry-password-store-1.7.4"
"WITH_ALLCOMP=yes"
"BASHCOMPDIR=/gnu/store/jyjm47609k160r2rcfaiwz3ncs0qjwry-password-store-1
That certainly works as a hack. I ended up installing from source locally
because I needed it to work now. It is strange that my local build didn't
encounter this problem when all I did was grab the tarball, untar, cd in and
>./configure --prefix=~/.local && make && make install
which should be m
Hi Guix!
After installing octave, I tried to install the image package in octave in
two ways. One by running:
> pkg install image-.tar.gz
where image-.tar.gz is in my cwd. I also tried installing with:
> pkg install -forge image
In both cases, I had the same problem. The first error I was getti
Hi Guix!
I'm trying to install git-annex for aarch64, but it fails on the following
line:
\ 'configure-bin' phasebuilder for
`/gnu/store/b6j0zdnbpdhx81npbk25m4nls5y1h3f5-ghc-7.10.2.drv' failed with
exit code 1
I have attached the log for the failed ghc build. The first error there
seems to be:
Hi Brice,
Yes, setting "(needed-for-boot? #t)" did it for me. I agree that adding a
dependencies field for swap devices is the "correct" solution.
Thanks,
-Zacchae
On Sat, Sep 25, 2021 at 8:54 AM Brice Waegeneire wrote:
>
> Hello John and Zacchaeus,
>
> A m
I have the same problem. I can start the swapfile normally with herd start
swap-/swap/swapfile, but it fails to start at boot.
Here are the (possibly) relevant parts of my system configuration:
(mapped-devices
(list
(mapped-device
(source (uuid "59d615e4-8a35-469c-aa24-88f28f084847"))
with -o subvol=guix
/dev/mapper/jake /mnt/jake/swap # with -o subvol=swap
/dev/sdb2 /mnt/jake/boot/efi
I've been using the same system config without problem, and just changed
the bootloader config to the above
-zacchaeus
On Tue, Sep 14, 2021 at 6:34 PM GNU bug Tracking System <
help
Hi Guix!
I'm trying to install guix to a new drive using my main machine which boots
using grub-bootloader (legacy bios). I want to put grub-efi-bootloader
(EFI) on the new drive install (for use on another computer). However, the
install fails when running grub-install. The full output at the
d expect a list of boards before it
tries to make the image.
-Zacchaeus
njkp7140yzkik9c3r3imfj0jdj68k1-dhcp-4.4.2-P1.tar.xz.drv.bz2
Description: Binary data
;got: "echo
aaa\na"
I'm including the full log as well.
Thanks,
Zacchaeus Scheffer
v3qmpzjvjcjg0ksgp2j57m3di86lbw-zsh-autosuggestions-0.6.4.drv.bz2
Description: application/bzip
35 matches
Mail list logo
