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
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
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
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
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
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
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"
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
, 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
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:
>
Hi Guix!
I'm trying to update synapse because it seems an update somewhere has
broken synapse (I'm thinking python -> 3.9.*?). Specifically, I get the
following traceback:
$ synctl start .config/synapse/homeserver.yaml --no-daemonize
Starting ...
Traceback (most recent call last):
File
I thought it might be important to confirm package versions. Here is some
sample commands and their output:
before guix package -i pinentry (pass not giving pinentry prompt)
$ ls -l $(which -a pinentry)
lrwxrwxrwx 1 root root 71 Dec 31 1969
/home/zacchae/.guix-home/profile/bin/pinentry ->
Hi Guix,
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:
$ pinentry
OK Pleased to meet you
$ gpg --import ...
[prompts normally with pinentry, allows me to import]
$ pass
[my password
>
> I believe that's the main misunderstanding here, `guix home` acts like
> `guix system`: it creates home generations, inside which there is a
> profile. That profile is _not_ ~/.guix-profile, but rather
> ~/.guix-home/profile. They are disjoint and not operated on by the same
> commands, guix
hell-profile... done
done
Finished updating symlinks.
Loading /gnu/store/2z8k6n538446fm0r5byk81kcv3khgkkn-shepherd.conf.
Starting services...
Comparing
/gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home/profile/share/fonts and
/gnu/store/02q0hr0k29wr866b1mrh88qnaixnk3v7-home/profile/share/fonts
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
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
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 ->
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
Hi Guix!
I've been having trouble updating for a couple of days because
password-store won't build. I haven't seen others complain, and I think
this package is widely used, so I'm a bit worried the problem is related to
the fact that I haven't updated guix for some time...
It fails with:
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
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
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 month ago I open a thread in
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"))
I should probably give some more details. Here is the bootloader config
I'm using
(bootloader
(bootloader-configuration
(bootloader grub-efi-bootloader)
(targets (list "/boot/efi"))
(keyboard-layout keyboard-layout)))
My mounts look like:
/dev/mapper/jake /mnt/jake # with -o
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
Hi bug-guix,
I tried running:
guix system image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@
(gnu system install) installation-os) "aoeuthant")'
And got two unexpected behaviors.
First of all, I get the error:
|builder for
;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
34 matches
Mail list logo
