IRC channel logs


back to list of logs

<the_grognardling>Is it normal for GRUB to take several minutes to decrypt the HDD after I enter my passphrase?
<juliana[m]>probably! there's no hardware support for AES encryption in GRUB
<juliana[m]>er, there's no support in Grub for hardware decryption of AES*
<the_grognardling>It wasn't taking this long before
<andresmoreno-mat>It takes about 1 min for me
<whosit1>Never seen it take minutes with sane settings on a 2tb hdd (--key-size 512 --iter-time 500). Might check your syslog / smartctl for disk errors. Sounds like it might be failing. ~10 seconds for me usually, every once in awhile it takes 20 seconds. Never a minute.
<the_grognardling>Ah nvm keyboard wasn't plugged-in lol
<andresmoreno-mat>whosit1: I timed it--15 seconds for a slow drive
<oriansj>the_grognardling: depends on the number of rounds used; it can easily take up to 30 minutes
<whosit1>Doesn't matter how many times you type in your password if your keyboard isn't plugged in.
<andresmoreno-mat><whosit1> "Doesn't matter how many times..." <- I have been laughing about this on and off for the past few minutes...
<rebiw>I'm trying to use the gtk3 library and guix shell. But the gtk3 include file  tries to find gdk in <gdk/gdk.h>
<rebiw>And it is installed in the following path: gtk-3.0/gdk/gdk.h
<rebiw>Is this a problem with the library itself or I need to do something extra in the Makefile??  Anyone else using gtk3?
<lilyp>use pkg-config :)
<rebiw>using guix environment it works. Thanks I will look it up, It's probably a simple change in the makefile.
<ChocolettePalett>GPG-riddle:... (full message at <>)
<ChocolettePalett>Nvm, I figured out what ``(file-append)`` will do.
<ChocolettePalett>The main question is what to do about ``pinentry-emacs``. I suppose I should add it to the list of home environment packages? Omg okay, I figured it out completely
<ChocolettePalett>Thanks yall (:
<ngz>Hello Guix!
<sammm>hello, is there a reason elogind uses cgroupv1 instead of cgroupv2?
<sammm>i have a god awful configuration which swaps out elogind with a variant that uses cgroupsv2 (, just wondering if I should submit a patch
<sozuba>Is it possible to generate config of the current guix install? if so, what's the command? Is there a guix equivalent of nixos-generate-config? I have never used nix, I've been with arch, gentoo and void. I am moving to guix.
<sammm>sozuba: I just use `guix system describe`, and cat out the configuration file
<sammm>probably is a better way tho
<sozuba>sammm: guess that's what i was looking for,but now i am curious as to what other better ways exist. :) Thank you. Even the command si n guix looks so thoughtful
<sozuba>guis system describe-- cool
<sammm>sozuba: you could make an alias for `guix-generate-config='guix system describe | awk -F':' '/configuration file/ {print $2}' | xargs'` :-)
<sammm>as i said tho, that's my hacky, only _just_ using guix myself method
<sozuba>Seems nice, i will copy this and try it when i am done with it to play around. I most probably will just hve to see what guix system describe do. :)
<ChocolettePalett>Don't forget about exporting channels!
<jpoiret>sammm: elogind used to not support cgroupv2, so it's probably an historical artefact in guix
<jpoiret>have you ran into any issues/gotchas?
<sozuba>ChocolettePalett: i haven;t even gone to the part of channles yet, i just came across that keyword from an article or config.scm, will have to read more, I am just strating
<jpoiret>run *
<jpoiret>sozuba: you can use /run/current-system/configuration.scm
<jpoiret>and channels.scm in the same directory
<sammm>jpoiret: I was running my variant briefly and it _seemed_ okay, but i'd need to run it for longer + look out for any issues
<gabber`>may i drag somebody's attention towards my patch here: ? i guess this should be mostly fine but i'd love feedback (or a merge) :)
<sozuba>jpoiret: awesome. Thanks :)
<jpoiret>we could totally switch to it if everything works out okay (there are no lost features, right?)
<sammm>i'll submit a patch in the near future and can discuss there
<sammm>afaik, no loss of features, but will take a closer look
<jpoiret>remember to cc the relevant teams so that they see the patches
<jpoiret>(i wouldn't see your patch otherwise)
<sammm>can do
<abrenon>hey guix
<gabber`>also similar issue #61956 was merged but not closed
<abrenon>how would I go about resizing the tmpfs for / in a live CD ?
<abrenon>as of now I simply use (file-systems %base-file-systems) and I get my RAM split in halves, 50% for / and 50% for /dev/shm
<abrenon>what would be the quickest way to make that 75%/25% ?
<gabber`>it's in (gnu system file-systems) under %shared-memory-file-system (which is used by %base-file-system)
<gabber`>easiest way (i guess) is to craft your own argument for (file-systems ..) with your own shm-fs option
<abrenon>ok, so that would resize /dev/shm, but can I assume that / would be automatically expanded to fill the rest ?
<abrenon>l.433 … ;TODO: make size configurable
<ChocolettePalett>woah, shm uses 50% of RAM for real
<abrenon>I think it's more complicated than that and I'm not sure I understand everything
<abrenon>but when you list the free space with df, it reports half of the whole for each
<gabber`>abrenon: i'd read the sources (or the docs) instead of assuming ;)
<abrenon>gabber`: which is what I'm trying to do
<abrenon>but I'm completely new to the live system generation parts in guix
<abrenon>which is why I was fishing for some direct hint in case anyone here knew their way around
<abrenon>ChocolettePalett: and of course, part of the RAM is also just used by processes and not mounted so…
<abrenon>I think it's rather an upper limit of the amount one can claim on each mountpoint
<gabber`>the docs say tempfs lives in *virtual* memory. and `df` checks file system space.. what are you actually trying to do? does your root partition run out of space? or are you running out of RAM?
<abrenon>no, of space of course
<abrenon>there's a snippet in gnu/system/images.scm transforming an operating-system definition into the corresponding one for an image system
<gabber`>you're trying to create a bootable, 700MiB CD?
<abrenon>I have created a bootable USB, yes
<abrenon>I first went for embedding all the tools I need but for some reason I seem to get some binary incompatibilities
<abrenon>which is why I resorted to having te minimum in my image, booting that, and then deploying everything I need from there
<abrenon>works fine when there's enough RAM
<abrenon>but on 8G -> 4G available for /gnu/store, it's a little short
<gabber`>doesn't the kernel mount shm according to the machine you're on? like "oh, i have 16G of RAM, let's do a 8G shm"?
<abrenon>apparently, there is indeed a setting saying "take 50% of everything" for /dev/shm in the file you mentioned
<abrenon>I'm surprised not to find some equivalent in gnu/system/image.scm
<abrenon>describing a similar strategy for /
<gabber`>it's the default for tempfs sizes
<abrenon>50% ?
<gabber`>/ is not a tempfs, it's a real disk with a real size (in blocks)
<gabber`>cf (search for the string "half")
<abrenon>well the config says it's the iso9660 disk
<abrenon>but in practice it *is* writeable at run-time
<abrenon>and empirically, I saw df report it 3.9G on my 8G system
<abrenon>and mount saying it was tmpfs there
<HiltonChain[m]>its contents are kept in RAM
<abrenon>so anyway I made an attempt with setting /dev/shm to 25% in case that was enough while browsing the doc and reading your resources
<abrenon>so we'll know in a couple secs if that's enough
<abrenon>damn, / is still half
<abrenon>hmm actually I was wrong, df doesn't report it as tmpfs but as none
<abrenon>ok it's an overlayfs
<abrenon>I wonder why nothing of that shows up in gnu/system/image.scm
<abrenon>I wish the init scripts were easier to find and tweak
<ChocolettePalett>Are you using LiveCD? Like, installing GNU/Guix?
<abrenon>(yeah, I tried to remount to change the size, that works for /dev/shm but not /…)
<abrenon>ChocolettePalett: I've generated a live USB to run guix on a machine I have physically access to but on which I'm not allowed to install anything
<ChocolettePalett>I am not sure, but !... (full message at <>)
<abrenon>I just need some CPU time and I'm trying to spawn nodes to handle a part of the computation
<abrenon>I can't write to any local disk
<abrenon>got it ! it's in gnu/build/linux-boot
<abrenon>how I will override that just for one system, however, is another story : (
<abrenon>nice lack of parameters on line 419
<abrenon>taking half by default like you said
<abrenon>thanks a lot for the help gabber` !
<gabber`>abrenon: YW, HTH :)
<cdo256>Is it unexpected that the docker binary isn't in the 'docker' package derivation?
<cdo256>Should it be picked up from a different git url?
<gabber`>WDYM "in" the package derivation? it should be in $(guix build docker)
<cdo256>as in ls $(guix build docker)/bin just has dockerd in it.
<gabber`>i guess (for i ain't no docker user) you want the package `docker-cli'
<cdo256> Oh I'm being silly, it's in docker-cli
<davidl>hi, Im trying to build a specific output of a package but can't figure out how to do it with guix build command. I tried using the expression syntax but Im probably doing it wrong. Can someone provide a simple example?
<HiltonChain[m]>you can't build a specific output
<gabber`>i'm not sure this actually works with `guix build foo:out` -- it does with `guix install foo:out`
<HiltonChain[m]>they are defined in one build process, just installed to different places
<davidl>HiltonChain[m]: according to the docs, the option argument of --expression, can be a zero argument monadic procedure that returns a derivation as a monadic value (which is then passed to run-with-store), or it can be a g-expression (then passed to gexp->derivation). Are you sure it's not possible at all?
<davidl>(it can also be just a package like "(@ (gnu packages guile) guile-1.8)" )
<davidl>I thought I could do something like -e='((@ (gnu packages base) coreutils) "out")' but it doesnt work
<HiltonChain[m]>all outputs are included in one derivation
<davidl>HiltonChain[m]: Thanks for your help. I found a partial solution that works only in most cases, as long as there isn't a reference to #$outputs:<some-other-output> in the package definition. This will return the out output only: guix build --expression='(begin (use-modules (guix packages)(gnu packages base)) (define-public coreutils-out (package (inherit coreutils)(outputs (list "out")))) coreutils-out)'
<degauss>Hi! Does anybody know how to make, etc. available in an FHS-compatible container? I tried (as suggested by the Guix blog post) with `guix shell -CF gcc:lib`, but it says that package `gcc-toolchain@11.3.0` lacks output `lib`. Using Guix 44bbfc24. Thanks a lot!
<gabber`>the output is called "static", so it's more like gcc-toolchain:static
<HiltonChain[m]>degauss: How about this?
<HiltonChain[m]>guix shell -CF -e '(list (@@ (gnu packages commencement) gcc) "lib")'
<degauss>gabber`, the `cc-toolchain:static doesn't seem to work (e.g. no in $GUIX_ENVIRONMENT/lib).
<degauss>HiltonChain[m], your solution *does* work! :) Reads a little like black magic to me. :P
<degauss>Thanks to both!
<sughosha>Hi all! I am having some problems with mounting filesystems from system configuration. I have NTFS partitions but they mount read-only. Another problem is that on boot the filesystems get mounted but if I try remounting then the UUID in the fstab has one zero escaped. Here is how I configured:
<nckx>sughosha: No idea, really, but anything looking relevant in dmesg?
<ChocolettePalett>sughosha: I have once heard that there were two implementations of ntfs driver, the in-kernel one could only read data, and there was a buggy one which could read and write stuff
<sughosha>ChocolettePalett: If I unmount and mount manually, like "mount /dev/sda5 /media/shared", then it will be read and write. Only when it mounts on boot, then read-onl.
<ChocolettePalett>Oh that's indeed weird
<sughosha>nckx: dmesg says "File system check on /dev/sda5 failed". But it is mounted at last. I don't understand.
<sughosha>I also configured initrd-modules with 'ntfs3'.
<degauss>sughosha, I had some issues with NTFS (I got the "Unrecognized mount option windows_names") which I avoided by using the `ntfs-3g` package in operating-system/packages. See also <>.
<nckx>ChocolettePalett: <I have once heard> True, but now outdated. There are two in-kernel and the one being used here (ntfs3) is probably better than the out-of-kernel (FUSE) one at this point.
<nckx>…except for that windows_names thing.
<nckx>sughosha: Nothing from the ntfs3 driver itself? Can you manually mount (full umount+mount, not remount) the drive rw with -t ntfs3?
<sughosha>degauss: I already have "ntfs-3g" package in my system configuration file.
<sughosha>ncks: with -t ntfs3, it is mounting, with "rw" permission. It seems that because I mounted with "sudo" I (user) don't have read and write permission.
<sughosha>This is the permission for a normal file: .rwxr-xr-x.
<nckx>You can probably work around that with your preferred combination of -o uid=, gid=, and/or mode= .
<nckx>But OK, seems like the bug is in Guix not mounting it rw when the kernel driver can handle it.
<nckx>If nobody here can help, could you file a bug? Just describe the problem in a mail to bug-guix at gnu dot org.
<sughosha>The main problem in my case is that the UUID I want to mount is "5234ED0D34ECF53F" but it in /etc/fstab the UUID is "5234EDD34ECF53F" (without zero). Even though the partition is mounted at boot, if I unmount and remount with "mount /media/shared", it says "can't find UUID=5234EDD34ECF53F." (zero is missing).
<nckx>Oh wow.
<nckx>That's uhm.
<sughosha>nckx: I wait for sometime here, and then if noone can help, I will go for reporting bug.
<nckx>Definitely a bug in Guix, assuming that's a valid NTFS UUID.
<nckx>((@@ (gnu system uuid) ntfs-uuid->string) (string->ntfs-uuid "5234ED0D34ECF53F")) → "5234EDD34ECF53F"
<nckx>I don't see how this would explain the ro/rw problem, but it sure implies that our NTFS mounting code is not… exceedingly tested. ( ͡° ͜ʖ ͡°)
<bjc>oh my god
<bjc>it's not 0 padding in the format string
<nckx>ACTION slogging through the format docs, because that's always fun.
<bjc>i was just doing the same thing
<nckx>~2,'0x I guess.
<nckx>Or ~2'0x?
<flaminwalrus[m]><sughosha> "ChocolettePalette: If I unmount..." <- There is a kernel command line parameter `rw`
<flaminwalrus[m]>I didn't pay too close attention to the details, but if it's happening on boot that might be something.
<bjc>"~{~:@(~2'0,x~)~}" is the format string i have working
<nckx>Oh good, a third variant.
<bjc>that's the entire string for the call to ‘format’ in ‘ntfs-uuid->string’
<bjc>just so you don't have to figure out where to interpolate it =)
<sughosha>flaminwalrus[m]: On boot, the partition is mounted with ".rwxr-xr-x". If I unmount and remount with "mount /dev/sda5 /media/shared" (without any -o ... options), it mounts with ".rwxrwxrwx" 🤔️
<sughosha>I want ".rwxrwxrwx" btw.
<nckx>But does ‘mount | grep /dev/sda5’ show ro or rw in the options list?
<nckx>bjc: Ah. I went a slightly different route, ‘2,’ because that's what the other procedures use.
<nckx>Are you a wizard? If so, can you explain the differences?
<bjc>i am not. i can barely parse the info page for it
<mirai>what's the inspiration behind the formatting scheme used by format
<bjc>the 70s were a wild time
<mirai>it's quite different compared to say, printf (not that I think it's a good formatting scheme either)
<ieure>Lisp System Design
<nckx>I *just* realised DSL is LSD backwards.
<sughosha>nckx: Now rw is shown. The difference is that manual mount has "nosuid", "nodev" and "allow_other".
<sughosha>Maybe "allow_other" is what I need to have user read/write permission?
<nckx>Sounds plausible. (I haven't mounted an NTFS this decade or probably the last.)
<bjc>nckx: with ‘~2,0x’ i get ‘\x0D’ instead of ‘0D’. i don't know why. the docs say that position is PADCHAR, which implies a character in that position, not an integer, but it's seemingly interpreting it as an integer
<nckx>mirai: I'd guess (but haven't checked whether) someone wrote a sexp equivalent to the stringy version, but I guess it came too late.
<bjc>‘~2,'0x’ works, though, and is probably the best option
<podiki[m]>nckx: hi! welcome back :)
<bjc>seems like i already wrote that. anyway, the explanation for it is that ‘''’ effectively quotes the next argument, so it's the literal character 0
<podiki[m]>also, hi guix! anyone know of any patches related to things like mesa for a feature branch?
<mirai>there's SRFI-166 which I think is another take at formatting
<sughosha>nckx: So quick! Thank you!
<nckx>That's just the fstab bug, but you're welcome.
<bjc>heh. ‘format’ has a ‘~p’ parameter for plurals. it works exactly as well as you might expect
<nckx>Lisp is the original AI language.
<podiki[m]>anyone know why our freetype is built without brotli support? (as simple as adding an input)
<podiki[m]>increases closure from 79.9 MiB to 82.3 MiB, seems common to have it enabled; needed for godot 4 update
<mirai>lilyp: I think I've figured out the reason why gdk-pixbuf fails to build
<nckx>podiki[m]: That's for WOFF fonts, right? SGTM.
<mirai>it turns out that during shared-mime-info's transition from autotools to meson, the build options were converted from: --disable-update-mimedb (default=no) to option('update-mimedb', type: 'boolean', value: false, …)
<mirai>which of course means completely opposite things
<ekaitz>hi all lechner added some packages based on the zig-build-system I proposed in the past #64208 (my build system is #60889 ) can anyone take a look into this and maybe merge upstream?
<nckx>Good riddance to the double negative though.
<mirai>the current (outdated) shared-mime-info does an update-mime-database and the package contains things like /gnu/…/share/mime/audio/mp4.xml when it shouldn't (since this should be done by (guix profiles) and according to the comment “Call update-mime-database after install. It should not be enabled if DESTDIR is used.”
<podiki[m]>nckx: correcto. would it make sense to have that patch on the same branch as mesa (and maybe harfbuzz) updates? i'm guessing there is good overlap in dependents
<mirai>the quick fix is to do an update-mime-database like it did before though this is incorrect to begin with
<nckx>podiki[m]: I haven't been following branch shenanigans the past months, but your guess sounds plausible to me.
<nckx>If so, yes.
<podiki[m]>nckx: the shenanigans are new and not really been deployed yet, I thought mesa updates would make a nice usage, though the scope grows by the day :)
<nckx>Good ol' scope doing its scopey thing.
<podiki[m]>does someone have a good one-liner for finding intersection of guix refresh -l outputs?
<nckx>ACTION has so much reading to do… :-/
<podiki[m]>nckx: you can be like me and I wait so long for the big threads it ends up being implemented or dropped....sometimes procrastination leads to less work :)
<podiki[m]>ah, maybe in some handy stuff there
<nckx>podiki[m]: Unoptimised bash guess: comm -12 <(guix refresh -l A | cut -d: -f2- | tr ' ' '\n' | sort) <(guix refresh -l B | cut -d: -f2- | tr ' ' '\n' | sort)
<nckx>Also, not really tested, for extra fun™.
<nckx>But the output looked plausible! (®)
<podiki[m]>neat! will play around, would be nice to have something to see what changes to batch for better use of resources
<podiki[m]>ACTION off for a walk first though
<nckx>Noob question: are Go packages (still?) supposed to install a top-level /src directory?
<nckx>Seems so.
<Guest28>I have problems with shepherd.  It just hangs.  Therefore running herd status does nothing and I can't ssh in to the machine after a minute has passed.  How can I debug this?
<lilyp>mirai: having this update baked in does seem reasonable for shared-mime-info tho, can we do without the gratuitous phase
<mirai>lilyp: I don't know if we should prebake a mime database, iiuc how this works then there's room for very subtle kinds of breakage
<mirai>suppose you have a dependency that ships its own mime type (share/mime/packages/foo.xml)
<lilyp>that'd be a dependency of shared-mime-info then, would it not?
<mirai>and package X wants both this dependency and shared-mime-info
<mirai>and it will somehow require the knowledge of the peculiar mime-type at test-phase or build phase
<lilyp>you can try baking the shared mime database as a gdk-pixbuf build phase, but I'm not sure whether that'd be the superior option
<lilyp>if package X doesn't consider the case that it's not installed when testing, it is seriously broken
<mirai>it sounds suboptimal since it potentially means that any package wanting shared-mime-info might want a baked version
<mirai>would be a trial and error effort
<lilyp>yeah, but that'd be the standard baked version like literally every time
<mirai>I don't know if I understood it right, but maybe something like texlive-updmap.cfg could be of use?
<mirai>not texlive but the approach
<lilyp>if it worked thus far and not baking the base is the reason why it broke, it does strongly suggest that the regularly baked thing works fine™
<mirai>a procedure that returns a package that bakes mime database given a list of packages for input
<lilyp>sure, that would do the trick in cases where we need special inputs, but I assure you it's most likely overengineering
<mirai>lilyp: it should work in most cases, though should we take this shorter road since it might leave us with mysterious build breakages?
<lilyp>I don't think there'd be that many mysterious breakages and if it were, it'd break a whole lot of packages at once
<mirai>I dont feel particularly strong against prebaking, just noting that there's room for pathological cases
<lilyp>coding up such pathological cases would sound weird in 2023
<mirai>I don't think so? Say there's package X that implements some custom/experimental FOOXL image format and it just does the same kind of thing that gdk-pixbuf did (and failed)
<mirai>sorry, that wasn't a proper example. package X implements FOOXL image format and some other package Y, perhaps an image viewer, depends on X and has a stage similar to gdk-pixbuf
<mirai>according to the spec, it's not unusual for packages to add their own mime types under share/mime/packages/….xml
<mirai>though in honesty, I don't know of any particular package whose build is broken due to this
<mirai>so I have no meaningful way to try the new-way-of-things, should it be done
<mirai>just wanted to let you know before committing to any choice in particular, I take it its acceptable to prebake the mimetypes then?
<podiki[m]>nckx: thanks for that bash-ism, playing around seems there's pretty good overlap between the ones I was looking at freetype, harfbuzz, mesa; of course freetype touches so much that alone probably subsumes the rest
<lilyp>that's something you'd have to account for in the gdk-pixbuf-loader that you'd have to write anyway
<lilyp>I do think you're trying to optimize the wrong thing here
<ArneBab>When I try to use modify-service for openssh on %base-services or %desktop-services, I get `modify-services: service 'openssh' not found in service list` — this is my config: (openssh-configuration (x11-forwarding? #t) (port-number 24))) ;; what do I miss?
<ArneBab>(I managed to make the system build by taking out the config, but I want to get the ssh port back to 24
<bjc>i'd need to see more of the config. at least the ‘modify-services’ section
<bjc>is ssh actually running (though on port 22) with the section removed?
<ArneBab>I did not restart yet …
<gabber>i think you'll just need to (cons* ) it to the other services, not modify it
<bjc>if you're starting from ‘%base-services’, then it doesn't include openssh
<gabber>(modify is only for services that are already in there)
<gabber>same with %desktop-services :)
<bjc>right. neither includes openssh-service-type
<bjc>so gabber's advice is correct: you need to cons* it in with (service openssh-service-type (openssh-configuration …))
<ArneBab>sorry, accidentally deleted it … here it is again:
<gabber>ArneBab: (cons* ) is a shortcut for (append (list ) another-list)
<bjc>add: (service openssh-service-type (openssh-configuration …)) to the end of the (append) in your service list
<ArneBab>when I add it as service, I get the error: service 'ssh-daemon' provided more than once
<ArneBab>(that was my first try)
<ArneBab>(service openssh-service-type (openssh-configuration (x11-forwarding? #t) (port-number 24)))
<ArneBab>is that because I also have dropbear-service (but on a different port)?
<bjc>that indicates the shepherd is seeing it more than once. maybe something is invoking lsh?
<bjc>yes. it's dropbear
<bjc>that also tries to provide ssh via shepherd
<ArneBab>(what is the difference between lsh and openssh?)
<bjc>i think lsh is pure guile? i'm not really sure. i only use openssh
<rekado>lsh is part of the GNU project
<bjc>it doesn't matter though, since the conflict is coming from trying to have both dropbear and openssh running, and the shepherd can't handle that
<rekado>its ssh server used to be the default in Guix
<ArneBab>without dropbear-ssh it worked — thank you!
<ArneBab>Is there an article describing the reasons for choosing the one or the other?
<bjc>i wonder how hard it would be to get the “provided more than once” error to spit out some kind of identifiers for the conflicting services
<rekado>ArneBab: lsh is very old, much less active as a project, and *much* less popular than openssh.
<bjc>even tatu's original ssh is much less popular than openssh
<ArneBab>thank you
<distopico>Hi, QQ, there is something like "systemd suspend" or "loginctl lock" in guix with herd?