IRC channel logs

IRC channel logs
IRC channel logs
2025-02-06.log
back to list of logs

the patches were sent with git send-email, and some context was in an email sent to @debbugs.gnu.org, which i understand to be all that's required

just wanted to check that i didn't do something wrong, since it's been a couple of hours and they havent appeared on the webpage

the issues frontend hasn't updated in a while, it is not you

a while meaning several days

podiki: ah, thanks for letting me know!

no worries, i actually hadn't noticed until today either

i just assumed that i was losing my mind or missing some permissions or something

but that makes perfect sense. having one bug tracker for all of gnu seems a bit absurd to me though

i'm sure I'm not the first person to suggest that though

well issues is just a frontend guix runs

there is the actual debbugs site for everything

(just the frontend is behind as far as i know)

i need to config my gtk, how do i know what version all my applications use?

podiki: my emails also don't seem to have appeared on the debbugs backend. I guess either that's also behind or else I really did screw up

Howdy

Welcome back lfam, you have 1 message!

lfam, eikcaz says: No worry! Thanks for the offer to review #75959. Let me know if you have any other questions or concerns. Configuring Syncthing from Guix has been neat, so I hope to share that.

"[PATCH] (home-)syncthing-service: added support for config serialization"

mra: is the bug marked as closed? it may not accept new content until reopening it...

looks like it is not closed, nevermind

mra: IIRC if its your first time sending an email to a specific list it has to be approved manually the first time, next time (after the approval) it will be automatic

i am trying to sudo Xorg -configure

but it says Xorg: command not found

is this not the way to do it? is there a different package/command?

why is the guix manual seemingly wrong regarding guix system X window?


it says i should have gdm package but i don't?

I'm not sure but that's an old version of the manual

where can i get the newe version?

I think you need the xorg-server package for the Xorg command

what is it that you want to do though?

the up to date manual has 'devel' in the URL

i need to change the font (size especially) in all programs


on the Guix site in the top bar nav from Help go to Manual (latest) btw

ok ty

this might help you coyotes4ys

yes i've seen these different things

lxappearance, various gtk configs and the qt config

or gdm package in guix seems to be the way for guix geeks

is that a decent understanding of the situation?

if so i'll install gdm which for some reason is not installed

wakyct if you're available? ^

Hi eikcaz

I'm starting to write a configuration for a VM image to test your syncthing contributions

Oh wow, neat. I originally tested with guix home container

I did something like: guix shell -D guix -CPW -- ./pre-inst-env guix home container --share=/home/zacchae/tmp/guix empty-config.scm -- cp /home/zacchae/.config/syncthing/config.xml /home/zacchae/tmp/guix/empty-config.xml

also leaving the container running shows that syncthing does not clobber the config

anyone, how do you configure themes/fonts for X window?

At this point, I have deployed that service across my devices and it is working as expected.

eikcaz: That's a neat way to test it, but I don't use Guix home and learning it would only slow this process down :) And I have plenty of experience with Guix VMs. I'll try using your code to add a device to my Syncthing cluster and see how it goes

Neat!

I noticed your updated patch, clever

Thanks. Makes configuring even simpler

coyotes4ys: Regarding fonts, did you see that the Guix xorg-configuration has a fonts field?

the manual says to use gdm it appears. but no i don't have xorg installed

You are using wayland?

no openbox and no DE

sorry:

no i'm not, i'm using openbox and no DE

GDM can use Wayland or Xorg. So, you must have one of them if you are using GDM

i'm not. it's just what guix manual says to use

It looks like openbox uses Xorg

So, it's available on your system.

the package Xorg is not on my system it appears. can't tab to it, command not found

Does your Guix System configuration file say anything like "%desktop-services"?

i can't find in the manual how tto access my guix system configuration file

i know that is basic

You should be able to find it at '/run/current-system/configuration.scm'

anyway i just installed gdm but it install like 100 programs and/or libs

You don't need to install GDM like that

On Guix, you don't install system programs like GDM. Instead, you create services (like GDM) in your configuration file and reconfigure the system.

But, I don't think you need GDM at all

Does your Guix System configuration file say anything like "%desktop-services"?

ok i am removing gdm that i just installed then

hopefully it will remove all that stuff it installed with it

man that was super quick compared to all the time it took to install all that stuff. but i guess it justt changed sector headers and removes references to the packages/libs in other programs? shrug

anyway lfam the answer to your question is yes, i find this in my configuration.scm

;; This is the default list of services we

;; are appending to.

%desktop-services))

(bootloader (bootloader-configuration

(bootloader grub-efi-bootloader)

(targets (list "/boot/efi"))

Ahem

Use <
> for that, coyotes47s

oh ok

i usually do that......


there ^ lfam

Okay, if you are using Openbox with that configuration, then you are using Xorg

what is Xorg?

It's a program that lets you have multiple windows

Basically

Openbox uses it

so openbox doesn't do that. incredible.

They work together

i know

i have startx'd now and again

but anyway

i do not have a command Xorg

Anyways, if you want to change your fonts in the Xorg user interface, you could modify the xorg-configuration to change the available fonts. That's described here: <

It will probably take some effort to set up

That's okay, you don't need to use the Xorg command for this

ah

thank you for taking me throuogh all this, lfam and wakyct too

I recommend you send an email explaining what you want to do, along with your configuration file, to

and everyone

It will be easier to get help with this via email

i hear you. i am doing it

what if i just guix install lxappearance? or is that also something that i shouldn't need and i should make a service

Hm, not sure about that. I would install it and see what happens

so i did $ export QT_SCALE_FACTOR=1.5

earlier

and that did it for vlc which apparently uses qt

perhaps there is a similar thing i can do for gtk?

this is not particular to guix, maybe see
and similar references about setting sizes, themes etc

you can of course use guix home to set env things, but there is no guix-system for any of these in particular that i know of

i have done that podiki

it looks like lxappearance may work

i just mean nothing is particular to guix at this point

thank you that middle comment was illuminating podiki!

Hey Guix! I’m trying to install Guix System with the Hurd on a Vultr VPS (using the installer), and it seems to be failing to build the ‘hurd’ package. I looked into the build logs, and it seems to be missing ‘-lpciaccess’ when linking something during the build. I wonder if anyone might have any hints about what might be wrong.

Here are some screenshots of the failed build: <
> and <

My impression is it's possible but there are a lot of rough edges. If you don't get an answer here, please report it to

this was a recent issue, are you on a current commit?

i think commit beb9ad2cf7e83b747781b47cdde2f75a19cd3a1b

"guix.git - GNU Guix and GNU Guix System"

and possibly some commits just after that

Hmm. I’m using the installer very recently downloaded from:
It says “7w8666y9g15r48cxn3ib542mzcmb88zm-image.iso”. ‘guix describe’ tells me I’m on d48da2d21610f9cf5f76cd846703b12beedb1fd5, which seems indeed older.

"guix.git - GNU Guix and GNU Guix System"

not sure, there is something about the guix package/in installer compared to guix pull bu t i don't remember

podiki: Yeah, looking more closely into ‘guix describe’ output, it has as its repository as directory name in the store, which seems unusual!

I wonder if I might be able to “cheese it” by runnning ‘guix pull’ (perhaps with some flag to specify the repository) before commencing the installation properly.

it has something to do with how guix provides itself...? it comes up but not sure what key words to give you to find out

i think if you do a guix pull and then maybe "hash guix" and run commands with that guix...?

That would be the move to get up to date

sadly not familiar with the details of how the installer and guix package work

The problem is, if you build the installer from commit 123456, it can't contain a copy of Guix that corresponds to commit 123456, but only an older one

It's a limitation of the functional model

right

Somewhat fun

maybe the installer images are a bit old since cuirass was stuck recently...might just be unlucky timing

Hmm.

I’m looking into this page:
It almost seems like the ‘guix’ package in Guix hasn’t been updated since last year, but the one on the installer seems newer.

Yeah, solving this puzzle is the purpose of the 'guix' package

We basically only update it in response to bug reports like this one ;)

But it seems Guix on the installer is newer than the ‘guix’ package itself, so it seem to come from elsewhere.

Hm

I must remember the details incorrectly

What commit is it? (`guix describe`

I'm trying to get docker running with a user namespace. That requires, amongst many things, for it to have access to the `getent` command. So far, what I did is this:
. Yet, /var/log/docker.log still reports me not being able to find getent. From what I could gather, I'd need to add an entry for getent here:

. Is there any smart way to go about it which does not involve copying the entire package definition?

lfam: On the installer, ‘guix describe’ tells d48da2d21610f9cf5f76cd846703b12beedb1fd5

"guix.git - GNU Guix and GNU Guix System"

vhns: It's possible to only change patch-paths phase of the Docker package definition, but it's going to be much faster to just copy it

And, maybe it's worth a patch to

Interesting zamfofex

Shows what I know!

Somehow it's able to do (guix (current-guix)) in the guix-service-type

Hmm, I saw! I guess that’s probably why it has a repository pointing to the store.

So, I guess ultimately, the “proper” way to solve my issue is to either wait for a new installer image to build, or to install it in some other way.

I'm not sure how the latest installer gets built

But, it's defined in gnu/system/install.scm

I mean, I can give you an example of how to build it yourself. But I don't know what part of our infrastructure is supposed to be building it

There's no 'installer' job on Cuirass:

sneek: later tell lfam: I imagine the installer might be built by the “images” job.

Okay.

sneek: later tell lfam: Thanks for the help, anyway!

Will do.

lechner, lilyp: I've rebased and submitted a modified fix to #63508

"[PATCH] gnu: eudev: Look for rules in /etc/udev/rules.d"


There was this blog post 16 months ago promising regular updates on how things go with the guix daemon in Guile. Has there been any development?

The blog post says that they have money to work on it for a year, so by now they should have run out of money.

There is recent commits on the guix daemon IIRC


Welcome back lfam, you have 2 messages!

lfam, zamfofex says: I imagine the installer might be built by the “images” job.

lfam, zamfofex says: Thanks for the help, anyway!


lfam: Aha. Interesting coincidence that you revealed those messages just now, I was actually about to share some updates on that.

Some further thoughts about my Hurd endeavors: I noticed there was a more recent build of the installer image just a few hours before the last conversation ended. I eventually got it to complete the installation! But with a DOS partition table, which Vultr doesn’t seem to support at all. I tried to install it with a GPT partitition table, but then the installation failed when installing GRUB.

This is the error I got:

Hm...

If it's GRUB that fails, it can't be too hard to figure out how to tell GRUB what to do

I think I figured out the issue. It seems Vultr requires UEFI, but the system configuration was using ‘grub-minimal-bootloader’ rather than ‘grub-efi-bootloader’. It seems the ‘-efi-’ variant doesn’t actually build properly, because of peer dependency ‘efivar’, which seems to be specific to Linux.

s/peer dependency/indirect dependency/ (I think I’m too sleepy now.)

(I’m not even sure it’s indirect now that I think about it.)

A final piece of thought for today: I don’t think Vultr actually requires UEFI, but it does require a GPT partition table. but I can’t get the installer to generate anything that GRUB recognises as a boot partition. I could probably do manual partitioning from the command line, I suppose, but I’m not very familiar with it. In any case, sleepy tiem for me for today!

question about the patches workflow: i'm trying to resolve a stagnant issue, so i sent some stuff to the relevant issue on debbugs. would it be appropriate to send an email to the guix-patches mailing list to let people know about it, or should i just wait?

i'm somewhat new to the whole email-based workflow

mra: no, because sending email to guix patches is going to open new issue

Ref my problems building webkitgtk yesterday, trying with -c1 (overnight) worked. Otherwise it was non-deterministic and failed at different points.

Hello Guix!

o/

Hi guix o/

mirror at
is fully operational (finally!)

I made some minimal adjustments to get go cross-compiling of binaries to work but the inputs I'm substituting are from the host, not the target

Rutherther: ah, thanks. good to know.

I've been wondering about this several times now: how do I ensure that SOME programs prefer OS-provided stuff over Guix stuff?

I am trying to re-setup the gnome nextcloud integration and it always loads the GIO modules from Guix, even when GIO_EXTRA_MODULES is set to the module folder provided by the OS (in .zshenv)

civodul: great news, thanks ! Is there any other guix repo expected to be mirrored at codeberg too ? I understand that pulling happens automatically, right ?

hi, does anyone know why the guix-locate test is failing for me: sqlite-exec 8 "attempt to write a readonly database" . It is working correctly when i run it in a guix shell container

i tried anything from removing the guix and guile cache and even recloning the repository

Follow-up: I set the environment variable in the desktop file of the gnome integrations service

Now it works

While issues.guix.gnu.org is not updated I noticed that llvm is broken with a lot of consequences due to dependencies. Is someone working on that?

how is llvm broken? I recently fixed it (i think) so that we can cross-build mesa again

csantosb: there’s a job running on Guix infra that periodically updates the repo (every other hour)

and no, i don’t think there are plans to mirror others

this one is the most critical, since Savannah has been broken every other day lately

yelninei: could you figure out which file it’s attempting to write to?

should be ~/.cache/guix/locate/db.sqlite by default

i'm having difficulty with a package. It's failing to find any of it's 'inputs' when doing the RUNPATH check at the end

civodul: it fails at the last line in the test 'guix locate --clear'. Stracing that reveals that it is trying to write to /var/cache/guix/locate/db.sqlite (and ofc failing)

(i have the package-database-service-type in my system config which is where i guess this comes from)

“last line in the test”?

ok, I think I'm going to split the release manifest into 2 manifests: one for the installer and one for "these packages really all need to build"

running make check TESTS=tests/guix-locate.sh from a checkout and failing at
(appearently because a global cache exists)

maybe more manifests, I don't really need to have it all in one I guess

(oh guix locate --clear fails even normally because it is trying to clear the root owned db)

maybe you ran sudo guix locate at some point and now root owns the database?


ACTION only read the last message, feel free to ignore if it doesn't make any sense


efraim: i think this expected from the package-database-service-type which updates the global database as a (root) cron job. But guix locate --clear is trying to use that and ofc failing

yelninei: oh i see; could you report a bug for this?

moving the /var/cache/guix/locate/db.sqlite out of the way fixes the test/issue

civodul: have now registered a free mail and will send once the account is approved (might take 1-2 days)

thanks

yelninei: out of curiosity, would you be more likely to create an account on Codeberg than to fiddle with email?

efraim: I tried llvm 2 days ago but did not pull since then. When did you fix it?

ennoausberlin: I made sure that it could be cross compiled about 2 weeks ago. how is it broken?

civodul: I dont have a problem with email per se other than the problem of exposing my personal mail in public lists

efraim: I am not infront of the computer right now. It is an aarch64 machine. And now substitutes available. How can I check on the CI if there are successful builds available?

now -> no

`guix weather llvm` will check if there are substitutes available for llvm

(i already have an account at codeberg because gitlab asked for a credit card or phonenumber to filter out spam registrations)

does not look so good

efraim: guix weather almost always fails for aarch64 packages.

substitute availability has been low recently on aarch64

yelninei: right, ok; i’m asking because we often hear about reluctance to create an account, shown as an advantage of email (i’m in that category)

efraim: We should prioritize the large packages known to fail more often on the CI and ignore others that can be build locally. Having some watchdog on these packages would be nice. Is this technically possible? Building rust, go, llvm webkit etc on a local machine is quite annoying and burns CPU cycles worldwide for nothing.

ennoausberlin: as part of the Upcoming Release™ I'm updating the manifests of packages we Need™ to be available

efraim: Sounds interesting. Can you elaborate a little on that?

right now we have a release manifest which lists all the packages that should have substitutes available at release time. I'm splitting it up into packages we need for the installer and packages which are needed for cross-building an OS config and ones which are needed in general

we don't have an installer for aarch64 but I'll probably add it to the installer manifest to make sure it works, since there's a sizable group that use Guix System on aarch64 and the same packages should build as in the installer

how can i get the store path of a package from within a (home) service?

efraim: Nice. Are the manifests available in one of the repos?

the current release manifest is in the guix repo at etc/manifests/release.scm, the others aren't public yet

nvm, figured it out (:

efraim: Thank you

civodul: I would tend to agree as one already needs to have an email to register the account at the various forges. The main difference is that with a mailing list i need to disclose my mail with the whole world as apposed to the forge admins only

yelninei: right, that makes sense to me

it also seems to be more common these days to contribute anonymously to free software

that wasn’t the case a decade ago (or more)

do we have a grub that will run on BIOS or EFI?

well, from anecdotal evidence anyway

efraim: grub-hybrid?

i'll try it. I'd like to replace grub-bootloader in install.scm

I think the issue is that guix locate does not ask for a writable db when trying to clear it (only when updating it) here

after a month long packaging stint, guix gc deleted 217 GiB xD

heh :-)

I was wondering whether there is a way to trace back contributions ? For example, commit a53bd6f27b originates in #76056. Is that possible ?

"[PATCH] gnu: emacs-yaml: Update to 1.1.0."

Other than the title, I mean.

csantosb: in theory, ‘Change-Id’ was added for that purpose

in practice, none of the tools uses it currently

Hi, my "sudo herd status" hangs with 0% cpu

I booted my computer with date set to 2020 (probably due to cmos battery missing). That led to 100% CPU and i was unable to reboot. I switched off the computer, set the date in my BIOS/UEFI and booted into GNU Guix. Now, I can't use "sudo herd status". It simply does not return

what could be broken, (how do I debug) and what can I do to fix it?

related: halt / reboot also don't work / return.

Hi folks, I'm having trouble with disk encryption (LUKS). The encryption is for the root filesystem, so the disk needs to be decrypted at boot.

I'm trying to decrypt the disk with a key file located on a USB drive.

I followed:

For `luks-device-mapping-with-options [#:key-file]` the manual page

For `initrd`

Right now, when the system boots, it only asks for a password once before the GRUB menu appears.

janneke or anyone else, is isc-dhcp supported on the hurd?

phew, greetd improvements merged

efraim: it is installed on debian/hurd so in princible yes

thanks. it currently fails to cross-compile to i586-gnu and I wanted to make sure it's supposed to build

apt search isc-dhcp

isc-dhcp-client/now 4.4.3-P1-1.1+hurd.1 hurd-amd64 [installed,local]

DHCP client for automatically obtaining an IP address

possibly there are patches --

I'll try to check it out later, right now I'm messing with some manifests

(y)


ACTION has no idea what might be needed for integration


Can I force connman to favor my dns servers over the dns servers it gets with DHCP?

hi, what status about core-packages-team branch?

Z572: it needs love! specifically: fixing
and upgrading glibc (again)

i haven’t been able to look into it since FOSDEM

If core-packages-team isn't ready yet, maybe next queue first?

oh crap, i hadn’t realized it was next in queue

maybe give us a chance before

there's currently 6 branches waiting to be merged

or maybe yes, let’s gnome-team go first

s/let’s/let/

I also want to merge some base package upgrades to core-packages-team, like #76085 #75797 #75028

"[PATCH core-packages] gnu: which: Update to 2.22."

"[PATCH core-packages-team] gnu: libseccomp: Update to 2.6.0."

"[PATCH core-packages-team] gnu: libatomic-ops: Update to 7.8.2."

right

Z572: please feel free to merge them if you consider them ready

i’ll take a look at the Gash bug

if people are merging things, may i recommend #55231 👀

"[PATCH v1] initrd: Allow extra search paths with ?initrd-extra-module-paths?"

civodul, can you remind me how to manually load/eval shepherd stuff on bayfront?

I think the paste you previously sent has disapeared now

cbaines: i sent the trick on guix-sysadmin, this time for berlin :-)

herd eval root '(register-services (list (primitive-load …)))'

haha, I had that email open, I just hadn't read it yet :)

replace the ellipses with the /gnu/store/*-sphepherd*.scm thing

:-)

cbaines: BTW, should “we” propose subscription of a Hetzner server for web services, as discussed in Brussels?

civodul, I'd still like to stop personally renting the machine for data.guix.gnu.org, so maybe that's a good candidate for something to move across

cbaines: oh, what was the blocker here?

maybe it's possible to pay Hetzner through the SumUp thing, although I don't know how long that would last for given there's problems topping up the funds from the FSF

it should definitely be moved

let’s let Foundation folks figure out how to get things paid

Uh, that's not normal: /gnu/store/49ygdzi7w51dimqdhlbzq3lw7na0c2wr-module-import-compiled.drv is an empty file.

civodul, I can try and send an email about it, I think the next steps are for someone to create a Hetzner account for the foundation and try and setup the billing/invoice side of things

As is /gnu/store/gcplqqyiqvpszgq0f46x6s1ys7wh3fm7-kexec-load-system.scm.drv, the sole referrer of the above.

Hrm...

Causing my guix system reconfigure to fail right at the end.

cbaines: right, if you can provide detailed instructions for that, that may help; probably email both guix-sysadmin and guix-europe (public)

wanted to test the greetd changes and i am getting an error during the activation script: guix system: error: mkdir: File exists "/run/user" when i reconfigure

should this be mkdir-p instead?


ACTION emailed lilyp in
to proposed letting gnome-team be merged first


dariqq: sounds like it

dariqq: I am getting the same trying to reconfigure

Hello, Guix! Some updates on my Hurd endeavors from last night: I got GRUB to detect a boot partition properly (by just making it sufficiently small, it seems), but it seems to fail installing some locale files to it (because it is too small!) It seems if I make it too large, GRUB doesn’t recognise it, and if I make it too small, it can’t install the locale files to it.

Not sure what’s the expected way to go about resolving this, hrmph.

Here is the error I’m getting:

look: could you test

dariqq: I applied something around those lines to my local guix, guix pulling right now, will let you know if it works

wait this does not work, mkdir-p has no second argument

this worked for me

worked here as well

look: Should I send my patch or do you want to send yours?

dariqq: you can do it, no problem

look: it is at #76102

Hi, i3status is not applying my configuration on Guix. The config is in ~/.config/i3status/i3status.conf and I'm pretty sure everything is correct. In my ~/config/i3/config I have `bar { status_command i3status }`. If I set in the `general` module of the i3status.conf the `colors` directive to false and then reload the config, colors are still displayed. Can anyone confirm this behavior or provide a working config as an example? I manage my dotfiles with

stow.

olndrxyz: the correct path is $XDG_CONFIG_HOME/i3status/config, you have the name wrong. It's in the man page of i3status

if I use that path I get an error that I don't remember now and the bar is not loaded at all.

if you get error with that path, my guess would be the config has been loaded, but it's wrong. So I am not sure what you're trying to say...

I have realised that the “BIOS boot partition” and the “/boot partition” are not the same thing at all. I have also learned that Vultr does require UEFI boot as of somewhat recently after all. I have read that you can request for disabling UEFI boot to their support team, and that they respond reasonably quickly, so I might try that.

So wait, you were marking your smol /boot partition as also of type ‘BIOS Boot’ and GRUB was… clobbering itself? That sounds like a gem of a UX bug.

I couldn’t find a way to mark a partition as “BIOS boot” from the installer image at all. So I was just assuming that creating a partition for ‘/boot’ would have been enough.

Might have to do that kind of stuff "by hand" in the console

Does the installer image not use cfdisk or whatever?


ACTION doesn't know which installer image is even being discussed, tho.


It's trivial in most partition editors.

The one that can be downloaded from here:

i can't find /etc/xdg folder to get the openbox menu file

it's in /gnu/store/something or?

everything's in /gnu/store/something

zamfofex: I always use (c)fdisk when installing Guix but I don't know if the 'guided installer' does.

Well, in any case, I managed to get Vultr support to disable UEFI, and it seems to boot to GRUB now. I noticed (backed up by info the blog post) that it hard codes the boot device, though, which doesn’t work. Currently I’m trying to figure out what /dev/vda on Linux would be on the Hurd.

ok thx hanker. how do i find it

nckx, The installer correctly sets up the boot partition.

you can do `guix shell openbox` and all the openbox files will be in `$GUIX_ENVIRONMENT`

zamfofex: I hope vda doesn't imply virtio (unlike an emulated SCSI drive sda) or that the Hurd speaks virtio.

zamfofex, The installer does this stuff for you automatically, not sure what all you'd have to do to change from UEFI to legacy boot, though.

ieure: Set up how? I think it only creates a BBP when booted in BIOS/CSB mode.

So what you said in the meantime with very different words.

hanker i accidentally did that as root first, then exited, then did it as user. did i do a bad?

s/CSB/CSM/

nckx: Hmm, are you saying you suspect the Hurd might simply not support it at all?

nckx, Yeah, if you're changing from UEFI to legacy or vice-versa, likely going to invalidate your setup. But I think that's the same on any Linux distro.

ieure: I couldn’t manage to get an UEFI install working at all, so I installed a normal DOS MBR setup, and asked Vultr support to disable UEFI.

zamfofex, Odd. I've never had an issue with installing in UEFI mode.

> hanker i accidentally did that as root first, then exited, then did it as user. did i do a bad?

not really

ieure: Hurd?

zamfofex, But, yeah, the BIOS doesn't/cannot know how partitions correspond to FS mountpoints. For UEFI systems, the partition type determines whether that's the boot partition. Legacy mbr partitions have a per-pertition bootable flag. Not sure how things work with a legacy boot on GPT partition table.

nckx, Oh hurd, no.

No idea about hurd, never tried it.

ok thx hanker

Was looking at different messages, I think.

guix shell just makes a bunch of symlinks in `/gnu/store` and sets a bunch of environment variables so you can get access to a program "without" installing it

but after i did guix shell openbox it's showing coyotes4ys@localhost ~ [env]$ but if i ls it just shows the normal folders, same for cp showing the normal folders for that

when you exit `guix shell` the environment variables don't hangaround

nice

zamfofex: I do suspect it but based only on experience with Linux, so it may not hold! …I hope.

I fear, though.

i am a curious combination on n00b and experienced, sorry

sneek: later tell eikcaz: I applied your recent patch on master, with the clever "take devices from folders" logic. I copied the syncthing-service-type example from the manual, imported (gnu services syncthing), used full device IDs, and tried to build an image based on this. But it fails with "error: folders: unbound variable". Ditto for devices, when I try making a simpler syncthing-config-file that only registers some devices

Don't let me discourage you but keep it in mind if the Hurd refuses to see your drive at all.

Got it.

> i am a curious combination on n00b and experienced, sorry

dw everyone's a noob before being experienced

you will see what i mean if we talk enough LOLOL

but what of my comment about ls showing normal folders, how do i access the openbox files after guix shell openbox

sneek: later tell eikcaz: Also, let me know if you'd rather move to email for this stage of the review

Got it.

> but what of my comment about ls showing normal folders, how do i access the openbox files after guix shell openbox

ls $GUIX_ENVIRONMENT/

coyotes4ys, Openbox (or whatever) binaries will be in your $PATH within the `guix shell', so, you can just enter commands.

caps necessary?

yes

ok

coyotes4ys, Ditto man pages etc. If you need to see other stuff, `guix build openbox' will print the paths to it in the store, and you can poke around in there.

oh that's useful ieure thank y

ok then how do i cd

hanker i mean

cd $GUIX_ENVIRONMENT/

nckx: Hmm, I see. I’m currently trying to decipher how I can get to know what it even sees at all.

oh ok

thank u i see lots of goodies! !

if i copy the whole /xdg/ folder to my own /etc/ will that do any bad?

coyotes4ys, I wouldn't recommend that. What are you trying to do?

oh why not

i want the openbox config files. i guess i could just copy them to my .config

coyotes4ys, Most stuff in /etc should be placed by a declarative system service.

ok

coyotes4ys, What are you trying to do?

if i copy autostart to my .config/openbox is that useful?

ieure i am trying to configure openbox

Openbox config should all happen inside your home dir.

I do not know if copying autostart (what autostart?) to ~/.config/openbox is useful, it depends on what you want to do.

i know. it said to pull it from etc/ so i thought of copying it there in case i read another tutorial and forget how to guix shell openbox etc

to answer my question yes autostart is useful, it is the config file for autostart not some other rando thing

i wasn't sure if it was that initially

nckx: Seems like it indeed doesn’t support virtio:

Rats :(

Worse, I can't find anything on-line implying that virtio is optional on Vultr (or how it could be switched to emulated SCSI/SATA).

ratpoison? yes i shall try that soon i installed it also

wahey, i got the zfs kernel module on my initramfs!

However don't use Vultr myself.

nckx: It’s not impossible things would work more transparently if I used a “dedicated CPU” instance, but those are a fair bit more exepensive. Honestly, I just wanted to use QEMU locally, but I’m currently using NetBSD, and it seems QEMU has failed to build on the latest MNX update, because pkgin doesn’t pick it up. (This is the only reason I’m trying to use Vultr rather than just using QEMU.)

Achso. Well, thank you for your service, at least… o7

Well, I said I’d try to help submitting patches to packages once networking was fixed, and it seems to be, so I (perhaps ambitiously) wanted to see if I could get e.g. velox working (swc/Wayland compositor). But it seems I couldn’t even get it to boot at all.


ACTION notices that ‘guix system reconfigure’ is rebuilding doom for the initrd; suck that, ZFS.


zamfofex: What's swc in this context?

curious, why do ppl call it, "the Hurd" not just Hurd?

nckx: It is a Wayland compositor library. It was made mostly for the purposes of velox:

I’ve read NetBSD had “sufficient success” with it: <
> (under some definition of “sufficient”) unlike for other compositors, which seemed more Linux‐specific.

coyotes4ys: I’m not sure there is a reason beyond “that’s what it’s called” (i.e. it was decided to call it that). See:

oh cool

thx zamfofex

Thanks.

the GCD process is ratified, my friends

that’s quite something

lfam: I see, looks like it's a bug in the documentation. Replace (syncthing-config-file (folders ...)) with (syncthing-config-file (syncthing-config-file (folders ... ))) and make sure you add any missing closing parens at the end

eikcaz, you have 2 messages!

eikcaz, lfam says: I applied your recent patch on master, with the clever "take devices from folders" logic. I copied the syncthing-service-type example from the manual, imported (gnu services syncthing), used full device IDs, and tried to build an image based on this. But it fails with "error: folders: unbound variable". Ditto for devices, when I try making a simpler syncthing-config-file that only registers some devices

eikcaz, lfam says: Also, let me know if you'd rather move to email for this stage of the review

> the GCD process is ratified, my friends

to migrate to forgejo?

No, just to have a decision making process

Just the GCD process itself.

eikcaz: Okay, I'll do that. It seems rather redundant, no?

lfam: that is how it is normally done. the syncthing-config-file field of syncthing-configuration should be a syncthing-config-file object (or a file-like object, or #f)

I see, maybe we can adjust the naming to make it a little more clear

civodul: oops. meant to reply to that with a generally favorable response :)

what is gcd?

guix consensus document


ACTION proposes a GCD to change GCD to Guix Consensus Decision


ah

i web searched but several different places on guix.gnu.org came up, can someone link me

coyotes4ys, Look in the guix-devel ML archives.

recent discussions on guix-devel

For jan/feb

Huh, looks like my email in support was never delivered!

So weird

curious what the numbers panned out to be... it seemed like a fairly small number of people actually replied

I guess because I replied all, it got bounced by info-guix

Oh well

lfam: maybe the rename the syncthing-configuration syncthing-config-file field should be changed to config-file?

"config-file"? not "config-file?"

I see that pattern in other guix services

e.g. (connman-configuration (general-configuration (connman-general-configuration ...)))

It's ironic that I sent mail to support the GCD process, it got bounced, and I didn't know, and the first GCD under discussion is about leaving behind the email workflow.

lfam: I didn't approve any of the many replies CC'ing info-guix@. I don't believe that's how it's supposed to be used. Your mail should have been broadcast through some other address, though. The others were.

Well, it was one of many addresses in CC, I just did 'reply-all'

Right.

It wasn't clear to me that it wouldn't be delivered to the bug ticket either

You just mentioned info-guix@ so I wanted to make that clear.

(Weird.)

Yeah, I don't expect to be able to send mail to info-guix. But for some reason, it also didn't get delivered to debbugs

It doesn't matter, I'm just being salty

(That's weird.)

eikcaz: Now, the example fails with "In procedure string-join: Wrong type argument in position 1: "/home/leo"

(I adjusted the name to be my own

Is "~/home" expected to work?

what's the lightest-weight terminal and is terminator anywhere close?

eikcaz: Here's the backtrace: >

coyotes4ys: Try xterm

Terminator is not light weight

lfam, yes I just found that bug. It's specific to guix system over guix home, so I missed it. Should be string-append not string-join. Lemme quickly resubmit the patch with that fixed and documentation fixed

ok lfam

i loved terminator but want to go lightweight

Okay thanks!

lfam: I submitted the updated patch. The annotation at the beginning says it all

Thanks!

lfam, i can't get terminator to show any cpu usage in htop, so i guess i

am keeping it

Sounds good!

pentium silver n6000 4 core 4 thread

it is a great processor but i thought at least terminator would show a little. not even a 0.1%

I don't think that the choice of terminal will have a big impact on your resource consumption

neither did i but i wanted to be pretty extreme since i want to run a daw on this

could anyone help me with some RUNPATH issues I am experiencing while trying to package a large cmake project?

Deltafire: feel free to ask away. Expertise is mixed here, so hopefully someone will have some insight on your issue. If not, you can always email your question to help-guix@gnu.org

okay.. i've managed to get the project to successfully compile and link an executable, but then the runpath checker is failing. The dependencies listed in the 'inputs' section are not being found

I'm not sure at what stage the various store directories are supposed to be added to the runpath

vagrantc: i counted 22 replies from team members, which is half of them

Deltafire: I'm not really familiar, but if you can't find something at runtime, maybe you should include it in "propagated-inputs" instead of "inputs"?

hmm.. i think that would work, but i was unsure whether this is the correct way of doing it

eikcaz, The runpath checker runs as a build phase, so I don't think this is a runtime issue.

Ah

Deltafire, My guess is that you have stuff in native-inputs that belongs in inputs.

native-inputs is just cmake and pkg-config

Deltafire, How long does it take to build? Asking to gauge my level of regret at trying to reproduce.

about 50 minutes on this rather old i5-4590 @ 3.3GHz

civodul: thanks! read in the post since :)

Deltafire, Hmm, not sure I have the time for it today, but probably a good idea to share the package definition and paste the build output.

Deltafire, et al: Just because something is a Guix package input, it will not necessarily be added to the binary RUNPATH. The package's own build tooling must add things to RUNPATH, and if it doesn't then we have to help the build tools do so. But it's not automatic

So, the details depend on what build tools the program uses, and how it uses them

I'm guessing it's a CMake system

that's correct

Right, so either the CMake scripts made by the developers of the thing you are packaging don't aim to include these inputs, or they are kinda half-baked and we have to persuade them

The ideal CMake usage will properly find and create these RUNPATH references to all the necessary dependencies but, in my experience, there's a big range of quality

should i add them to CMAKE_INSTALL_RPATH myself?

(or BUILD_RPATH)

I'm not a CMake expert. I'd start by... hoping an expert chimes in now :) And also by grepping in our packages to see what other people have done

Like, grep for CMAKE_INSTALL_RPATH

Also, I'd look at the upstream CMakeLists.txt to see if it mentions these dependencies or not

Also I'd check upstream bug reports, and how other distros package this, if they do. Arch and Nix are what I usually look at for comparison, sometimes Gentoo

the nix one doesn't seem to do anything special.. grepping gnu/packages turns up this potentially useful setting: set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

i'll give that ago

Yeah, could be! After years of packaging things, CMake still never clicked for me. It's always a slog when it doesn't work the first time

a guile-based build tool would be cool, perhaps replacing autotools :)

Autotools is usually super easy to package! Go figure

I think it would be hard to replace at this point. Might as well make a new kernel ;)

How do you actually set a user password in config.scm? I can't figure it out

lfam, I'm also interested in this. I kinda-sorta know how, but not really.

Like, I tried adapting the example in the manual but it did not work

I'm not sure it's advisable.

I do it. Not sure I recommend it

It's for testing

It's for testing your patch, in fact :)

It's like, the first field is the plain-text password, and then a salt, right?

I thought you could only stick a hashed password in there.

open up /etc/passwd and copy the column $6$... up to (not including) the colon

Is there a way to run an `oci-container` with a git repository/a local directory with a Dockerfile?


I'm looking at that ^

And then:

"Encrypt key, with the addition of salt (both strings), using the crypt C library call. "

There's no hash to be entered

eikcaz: Hm, I'm trying to generate a new system here

Mine looks like (user-account ... (password "$6$bzL...k1"))

Huh

No call to crypt?

No because I didn't want a file living in my file system with my password as plain-text

Right

Like, is the documentation incorrect? I feel like I'm losing my mind here

I always tested things in VMs with root, but I wanted to use a regular user for this

the example has you put your actual password and (crypt ...) turns it into the hash. I skipped that step and just provided the hashed password, which I obtained from /etc/shadow

why do you need to set a user password? Just start it as root, then su to the user. root can su to user without a password

Right, that's my understanding. But it didn't work

Yeah, I could do that. Just seems like a PITA when I could just log in as a user

And it's hard to ignore these kinds of UX bugs, you know

And like, if root has no password to log in... how can I do that for the regular user?

oh, if it doesn't work, maybe the user name is part of the salt?

so if you are extracting from /etc/shadow, maybe make sure the user in your new system has the same username?