IRC channel logs

2022-09-19.log

back to list of logs

<pkill9>error: in phase 'patch-autoloads': uncaught exception:
<pkill9>system-error "stat" "~A: ~S" ("No such file or directory" "/gnu/store/8jycasrgh7nx85qqbjwi2ysb8v07s3qg-emacs-geiser-guile-git.e540e14/share/emacs/site-lisp/geiser-guile-git.e540e14/geiser-guile-autoloads.el") (2)
<pkill9>phase `patch-autoloads' failed after 0.0 seconds
<pkill9>when i run ls /gnu/store/8jycasrgh7nx85qqbjwi2ysb8v07s3qg-emacs-geiser-guile-git.e540e14/share/emacs/site-lisp/geiser-guile-git.e540e14/ it shows the filename is geiser-guile-git.e540e14-autoloads.el
<Grimpper>that's weird
<Grimpper>is there a way to know what commit is being downloaded when doing: `guix build emacs-geiser-guile` ?
<Grimpper>The thing is that without the commit, the file that's patched don't have part of the commit hash appended in the name
<pkill9>Grimpper: looking at the package defintion, it uses the version as the commit
<pkill9>so it's the git tag release
<Grimpper>I'm also seeing that
<Grimpper>Do you have any idea on how that can help?
<pkill9>not sure
<Grimpper>like it seems that in the `emacs-geiser` package it does some renaming which is why this one has not hash atached to any patched file while in the `emacs-geiser-guile` seems to not do that renaming
<Grimpper>but I don't know enough lisp to understand it
<Grimpper>I will read more about it after work. Thanks for the help pkill9!
<pkill9>np
<fnstudio>hi :) i'm experimenting with guix home; i've run 'guix home import /tmp'
<fnstudio>now i'd like to create a container to test 'home-configuration.scm'
<fnstudio>i know i can use 'guix home container ...'
<fnstudio>out of curiosity, how do i tell guix to use the same version of the packages as per my current installation, without pulling/building anything new?
<fnstudio>is that the default?
<fnstudio>sorry, i'm simply trying running guix home container (i realise what i asked might not be very clear or make perfect sense)
<fnstudio>i'll see what happen and report :)
<lechner>Hi, how may I make the executable xmlstarlet from gnu/packages/xml.scm available on the build architecture for a phase, please?
<ulfvonbelow>lechner: I would assume you'd add the package to native-inputs, no?
<ulfvonbelow>the bin subdirectory should be automatically picked up by the 'set-paths' phase of the build system
<drakonis>hey folks, do we have any documentation on image generation that includes channels?
<fnstudio>hi, i get a "In procedure copy-file: Permission denied" when updating texlive-font-maps - anyone experiencing the same (or anything obvious that i might be mistaking?)
<abrenon>hi guix : )
<zimoun>hi!
<abrenon>how are you zimoun ? not too tired ?
<zimoun>abrenon: a bit, but the week is starting anyway. :-)
<abrenon>yeah I knooow ¤_¤
*tschilpt` sees a close relationship between setting guix inputs for python packages and heuristics in literature-sciences
<abrenon>: )
*tschilpt` seriously hopes to be old enough to have overcome https://www.youtube.com/watch?v=Abrn8aVQ76Q
<jpoiret>hello
<abrenon>hi jpoiret !
<tschilptschilp23>hi!
<tschilptschilp23>if i receive a 'target-riscv64?: unbound variable', which module would I add to my package definition?
<tschilptschilp23>I already rgrepped "~/.config/guix/current/share/guile/site/3.0/guix/" and "~/.config/guix/current/share/guile/site/3.0/gnu/" and do not have a clue where else I should search...
<rekado>(guix utils)
<tschilptschilp23>rekado: thanks!
<rekado>(I use ag, but on my local Guix repo checkout, not the symlink hell of a Guix profile)
<fnstudio>hi when updating my guix (on foreign distro) i get this error that says "cannot build derivation ...-profile.drv: 1 dependencies couldn't be built"
<fnstudio>there's build log at "...-texlive-font-maps.drv.gz"
<efraim>ocaml-4.07 (camlboot) and ocaml-4.09 don't natively have support for riscv64
<fnstudio>and if i look at that one, the error at the end says "In procedure copy-file: Permission denied"
<fnstudio>but from there on i'm a bit lost
<fnstudio>oh, ok, i was able to get rid of the error by temporarily eliminating some texlive dependencies
<fnstudio>which now allows me to go through the upgrade process with no errors
<fnstudio>i'll now see what happens if i install the texlive stuff back
<rekado>fnstudio: could you please submit a bug report with a reproducer? Feel free to Cc rekado@elephly.net.
<fnstudio>sure, thanks
<fnstudio>not sure what fixed it exactly, but removing texlive-base texlive-tiny texlive-tex-ini-files and then reinstalling texlive-base texlive-tex-ini-files made it work, no more errors now
<fnstudio>i think i don't need texlive-tiny if texlive-base is installed to be honest
<fnstudio>(and to be honest i'm not even sure whether i need texlive-tex-ini-files)
<rekado>yes, you shouldn’t use texlive-tiny
<fnstudio>thanks rekado
<ekaitz>hi guys! I'm finding some weird behavior with Mes, if I make a `guix build package-that-needs-mes` the `environment_variables` set the `MES_PREFIX` to /gnu/store/...-perl
<ekaitz>and it sould be -mes
<ekaitz>let me give more info
<ekaitz> https://paste.debian.net/1254338/
<ekaitz>so, if I change the order of the inputs of the package and put mes the first, it works
<ekaitz>looks like something is mixing LIBRARY_PATH with the MES_PREFIX
<ekaitz>looks like a bug... I'll send a report
<tschilptschilp23>Is there a way to tell a program an alias for a file during build? I try to build numpy with openblas-ilp64, but it does not seem to recognize it. I'm trying with this definition: http://paste.debian.net/1254341 but error out with that: http://paste.debian.net/1254340 . Most certainly the .so files are there: http://paste.debian.net/1254342 , is this a naming-problem at all?
<tschilptschilp23>(without the env variable NPY_USE_BLAS_ILP64 things build nicely)
<tschilptschilp23>For how I understand, it seems to look for the word 'openblas64', but there's only libopenblas[...] in the corresponding store-directories...
<rekado>tschilptschilp23: you’d have to tell numpy to look for something else. It’s not about the names that Guix uses but about the names numpy accepts
<tschilptschilp23>rekado: I got it! numpy seems to accept openblas_ilp64 for its site.cfg ;)
<ekaitz>i sent a bug report: https://lists.gnu.org/archive/html/bug-guix/2022-09/msg00215.html
<ekaitz>let me know if you need more info
***Maja_ is now known as Maja
*tschilptschilp23 off to the culprit, that brought me into this dark place
<pkill9>guix time-machine is snice because you can update your system with latest guix without installing new revision of guix
<pkill9>it's like a stateless apt-get update && apt-get upgrade or whatever
<rekado>ekaitz: the mes package has a search-path-specification for MES_PREFIX
<rekado>and it’s just set to the root of the profile into which mes is installed
***wielaard is now known as mjw
<ekaitz>rekado: but the root of the profile is the first element in the LIBRARY_PATH?
<lechner>Hi, is there a way to debug these stack errors for 'guix system reconfigure' after adding (set! xkeyboard-config my-xkeyboard-config) ? https://paste.debian.net/1254352/
<abrenon>not that I know of, but the line itself looks peculiar (I never had to use set! to replace a value in my config)
<abrenon>where did you add it ? what's the context ? do you mean that you have a full file for which system reconfigure works, but adding this single line somewhere breaks the reconfigure ?
<lechner>abrenon: in hope of using my own XKB keyboard layout i created a customized (although untested) xkeyboard-config and, yes, adding that line breaks the reconfigure
<PotentialUser-61>Hi! Why Visual Studio Code is not packaged in guix? Is that because everybody is happy with emacs? Or is there some license issue? Or does it phone home and is thus considered malware?
<pkill9>because nobody has worked on it, probably because it is electron
<ekaitz>PotentialUser-61: Visual Studio Code is free software? let's you install privative plugins?
<PotentialUser-61>They write something that the source code is free, but the provided binaries are not. I don't understand that, but guix wouldn't take the binaries anyway, so...?
<pkill9>vscodium has the nonfree stuff removed
<pkill9>but official guix repo only builds everything from source
<PotentialUser-61>Anyway, it seems quite popular, I hoped that someone here had thought about that conundrum already.
<PotentialUser-61>vscodium is not in guix either.  :-)
<unwox>electron apps are hellish to package, you'll need to create a package for every little dependency and dependency of dependency
<pkill9>someone has made an npm importer however, but guix won't accept npm packages
<pkill9>due to being tiny
<rekado>it’s not about them being tiny
<dthompson>here we go :)
<lechner>ulfvonbelow: hi, did you use something like (set! xkeyboard-config my-xkeyboard-config) successfully?
<Andronikos>I want to create a live CD with Guix. Therefore I like to be root password less. How do I configure that? Basically I just want to type in "su" and I should be root.
<lechner>Andronikos: sudo may be easier
<PotentialUser-61>Thank you, everybody, that's good to know!
<abrenon>Andronikos: I just recreated an ISO from a simple file and booted it with -cdrom in qemu just to check what I thought: there is no root password by default
<abrenon>I simply logged in as root from the tty and was in without having to enter a password
<abrenon>(on a side note, setting the user account a password seems not to have worked, but I was able to reset it with passwd from successful root login)
<civodul>zamfofex: yay, congrats on the i586-gnu substitute server!
<Andronikos>Thanks. I am also using Gnome. Setting it up to boot automatically as root is probably the best way? I used Fedora live CD in the past and it does boot as liveuser but you can switch to root without entering a password. Basically I wanted to copy that behavour since I was annoyed to install gparted all the time.
<tschilptschilp23>if it works, inheriting from a newer package version to an older one is pretty cool.
<tschilptschilp23>is the sanity-check phase actually a fall-back for the check-phase, in case one skips it? I just happen to see it, if I actively skip the check-phase in a package-definition.
<abrenon>Andronikos: well, I think the desktop session in the liveCD should be as liveuser, and they should su before running gparted or something else
<abrenon>I suppose GNOME must provide some tools to prompt for a sudo password for some executables like gparted (gksudo ? I think something by that name has existed at some point)
<abrenon>the (password …) field in (user-account …) in the scheme definition for your live CD should allow you to set the built-in password for the liveuser (even though my quick attempt would seem to show it doesn't work, but maybe I missed some obvious other reason why it didin't work since that's not what I was checking)
<Andronikos>Yes, it asks for prompt if you want to open gparted. But it is just one mouse click since no password. Would have been my next question. How do I get that prompt?
<Andronikos>Because I think I need to configure something. It does not do that prompt automatically. Only if I do gksudo manually in the terminal.
<abrenon>ahhh, then it means you want to override the Exec line in the .desktop file for gparted
<abrenon>so probably you have to customize gparted to get a different package behaving like this, and use this version of gparted within the liveCD
<abrenon>I don't know, I've never configured liveCDs that much but I see no reason why it wouldn't work
<Andronikos>Ah okay thanks. One last question. How does someone generate isos? I do "guix system image -t iso9660 guix-live.scm". This does take one hour to process. Is that normal? It is basically just GNOME and gparted.
<abrenon>well it's not the system-generating part that's eating up time, it's the compression of everything into an ISO
<abrenon>I've run the exact same command to get mine to test, and it indeed took quite some time
<abrenon>less than an hour, but it had much fewer packages, and depending on the speed of your proc, well it may take more or less time
<mothacehe> if the iso size doesn't matter much you can use -t uncompressed-iso9660
<mothacehe>it's way faster than -t iso9660
<abrenon>ohh nice I didn't know about that !
<abrenon>thank you !
<mothacehe>yw :)
<PurpleSym>tschilptschilp23:'sanity-check is a separate package for Python packages. It does not depend on 'check.
<Andronikos>Ah good to know. Helps with testing. The iso will be stored in the gnu store. Is it meant to point to that path in my VM or is there something I can do to select a path as well as set a name?
<ulfvonbelow>lechner: I didn't try it myself, no. That error message looks like there might be a circularity somewhere causing unbounded memory usage.
<andi->Is there a good integration of home-enviroment into a global system configuration? I'd like to manage both my home environment together with my system configuration so that I only have one file/command to run.
<ulfvonbelow>hmm, wait, are package input fields thunked?
<ulfvonbelow>oh no
<ulfvonbelow>they are thunked
<ulfvonbelow>and so is the arguments field
<ulfvonbelow>hm, that'd do it
<ulfvonbelow>alright lechner, what we have here is an example of how guix was not designed with mutation in mind
<ulfvonbelow>the thunking of those fields means that they are actually evaluated on demand
<ulfvonbelow>e.g. calling (package-arguments my-xkeyboard-config) will actually evaluate (substitute-keyword-arguments (package-arguments xkeyboard-config) ...)
<ulfvonbelow>and those will use the value of xkeyboard-config active *when package-arguments is invoked*, not when the package is defined
<ulfvonbelow>and at the time package-arguments is invoked, xkeyboard-config is bound to my-xkeyboard-config
<ulfvonbelow>so the first step to getting the package arguments of my-keyboard-config is to apply a substitution to the result of getting the package arguments of my-keyboard-config
<ulfvonbelow>this leads to endless recursion, until an out of memory condition is produced
<ulfvonbelow>anyway, it can be resolved by surrounding your package definition with (let ((xkeyboard-config xkeyboard-config)) ...)
<ulfvonbelow>(such that it surrounds the (package ...) form, but not the (define-public ...) form)
<rekado>zamfofex: a hurd substitute server! What changes are needed to deploy this to the nodes behind ci.guix.gnu.org?
<civodul>rekado: we used to have childhurds running on ci.guix, but they broke and we never got around to fixing it
<andi->Are there are some good public repos as example on how to structure my personal config repo? I struggle (as a guile beginner) to put my own package definitions into a different file.
<pkill9>somoene ordered a printed version of the Guix manual https://www.reddit.com/r/GUIX/comments/wgg0gd/i_thought_itd_be_cool_to_have_a_printed_copy_of/
<vivien>Apparently, the 2-year-old 1.3.0 unfortunately
<vivien>That’s another reason why we must have a new release.
<vivien>What is the state of the discussion of releases? Do we still plan to make date-numbered releases?
<fnstudio>hi, i'm looking into using guix home; what's the recommendation for, say, emacs.d/init.el (or init.org)? is there a home service for that already?
<fnstudio>'guix home search emacs' would seem to indicate there's no such service; shall i copy my emacs.d folder in my home-config folder and create a dummy service that simply copies the local emacs files over?
<unwox>there is home-files-service-type for copying dotfiles into places
<fnstudio>unwox: right, super, i'll go for that then, i was wondering if that was the recommended approach or if i was missing anything
<fnstudio>oh, also, i suppose i may want to list my emacs packages within this service as opposed to home-environment/services, if that's possible at all? so that things are better compartmentalised?
<nashdidan[m]><andi-> "Is there a good integration of..." <- As far as I understand that’s something you can do with the not yet official rde package (from the creator of home-environment).
<unwox>fnstudio: i do not use emacs but if i understand correctly it's better to install emacs packages by listing them in "packages" field in your home.scm
<fnstudio>unwox: oh i see, thanks
<unwox>np
<andi->nashdidan[m]: oh neat, do you have a link for further reading?
<drakonis>andi-: https://github.com/abcdw/rde/
<drakonis> https://trop.in/
<drakonis>abcdw's website links to his youtube videos on guix, notes and the repository
<Andronikos>Will it be possible to define Emacs with Scheme instead of Emacs Lisp in the future?
<rekado>civodul: yes, on two nodes we have the childhurd service enabled
<apteryx>Andronikos: there's emacs-guile, but it's not actively developped and has many problems (such as performance)
<rekado>I just wonder what changes were needed to make this work; I’d like to apply those changes to the childhurds behind ci.guix.gnu.org
<rekado>apteryx, Andronikos: guile-emacs
***Dynom_ is now known as Guest7441
<rekado>IIUC robin still has an active interest in Guile Emacs; perhaps we will see some updates to Guile Emacs in the near future.
<Andronikos>Would be awesome since one language to rule them all. I still don't understand the difference between Guile and Scheme. Can someone help me out?
<ulfvonbelow>guile is to scheme as GCC is to C
<antipode>Andronikos: They are incomparable -- Scheme is a language, Guile is an implementation (of that language, with various additions and perhaps some small deviations)
<antipode>(what ulfonbelow says, basically)
<zamfofex>rekado: In my case, I found it much easier to set up a ‘guix publish’ service on a persistent Hurd VM itself, rather than to use the childhurd service. That ends up meaning the VM has 128 GiB of disc space maximum (with IDE), which was fine for my case. Besides that, I found that some foundational packages (such as glibc) had test failures (or were causing test failures in other packages), so I had to disable the tests.
<zamfofex>rekado: Check the logs of the #hurd channel (from the twelfth up to the sixteenth of this month), and you’ll be able to see the adventures I underwent. 😅
<lechner>Hi, I just got try `--no-substitutes'. Is that really going to make things faster? https://paste.debian.net/1254389/
<zamfofex>lechner: Ideally not, but it might if the package you’re building is simple enough, and your connection with the substitute server is slow.
<lechner>zamfofex: thanks!
<vivien>antipode, what is an implementation of C, besides a compiler?
<zamfofex>I’m currently working on a C interpreter based on chibicc. 🙂
<antipode>vivien: A somewhat-standard C library
<vivien>I wish we could have guile interpret C
<vivien>(that is, compile C)
<ulfvonbelow>I approve of the idea of C interpreters. Make C development as iterative and painless as possible.
<lechner>hi, tagging along on pkill9's point, the 1.30 manual often ranks above the development version in online search results, but i am usually looking for the latter. would it make sense to perhaps offer some type of link to the development version on each page of the released manuals?
<antipode>ulfvonbelow: You can use 'tcc' as a C interpeter: https://bellard.org/tcc/
<antipode>It presumably compiles under the hood, but Guile does the same
<lechner>Hi, my ISP offers download speeds of up to 30 MB/sec but substitute servers often respond with 1 MB/sec or less. am i doing something wrong?
<antipode>Maybe you are running network I/O-intensive software like e.g. ipfs, on cellular?
<antipode>Stopping ipfs when I'm not actually using it made my network connection much more reliable.
***mark_ is now known as mjw
<antipode>Also, I don't know what network speed the substitute servers offer.
<lechner>antipode: i have never used ipfs. does guix use it for the substitutes?
<antipode>Currently, not.
<antipode>There is an outdated patch for that, though, and work is being done on improving things.
<lechner>i saw this https://github.com/fps/guix-ipfs-cache
<Andronikos>Thanks everyone.
<lechner>ulfvonbelow: thanks! it stopped the OOM issue but libxkbcommon is not building, presumably because of an empty reference here. how can that be? https://github.com/guix-mirror/guix/blob/master/gnu/packages/xdisorg.scm#L510 https://paste.debian.net/1254395/
<davidl>Is there any general way which you can run guix system init to a remote target? For example, can you run guix deploy instead of guix system init?
<lechner>ulfvonbelow: i cannot imagine that the path would not be found in my adapted version https://www.pastery.net/zpwwdm/
<davidl>can you do a guix pack of an operating-system instead of a package, then unpack it on a target filesystem?
<ulfvonbelow>lechner: libxkbcommon is in a limbo state in which it doesn't explicitly supply input labels for its inputs, but does rely on the sanitizing machinery to provide them implicitly. The consequence of this is that the input label it uses for xkeyboard-config actually depends on the name of the package, which in your case is actually "my-xkeyboard-config".
<ulfvonbelow>but in its build-side code it tries looking up an input under the original name "xkeyboard-config"
<ulfvonbelow>you could get around this by changing the package name of my-xkeyboard-config to just xkeyboard-config.
<ulfvonbelow>or rather, just inheriting it from the original xkeyboard-config
<pkill9>is it possible to load kodi plugins from guix packages?
<lechner>ulfvonbelow: thanks! i just commented out my own name declaration. maybe the name should not have been set in the first place. at the same time, all package declarations are global. why would anyone use the name to resolve them?
<lechner>p.s. but i do know that's the legacy way (or so they say)
<lilyp>yes, you ought to locate whatever you need using search-input-file
<ulfvonbelow>actually, not all package declarations are global. The way specification->package works is by iterating over all exported ("public") variables and looking for ones bound to a package with a certain name and version (and that don't have (hidden? . #t) in their properties list). Also, looking up an input label just looks up which input package was specified to have that label. The label doesn't have to be the package name, and in cases
<ulfvonbelow>where there was any ambiguity (e.g. differing versions, variants, different outputs of a package), the author would simply assign different labels, since they only need to be unique within the set of input labels for that package.
<lechner>ulfvonbelow: then why did libxkbcommon get it wrong on the build side?
<ulfvonbelow>the trouble here is because no input label was specified, and so it defaulted to the package name, AND the package definition assumed what the package name was
<lechner>ulfvonbelow: i see. it seems that the input label should be required when it is used for lookups
<ulfvonbelow>if a package used gexps, this wouldn't be an issue, and if they used input labels, this also wouldn't be an issue, but this particular package didn't specify input labels and relied on their value
<fnstudio>i'm hacking together a home-configuration.scm file and i must be doing something wrong with a local-file call; what's a good way of working with / debugging this? is there some geiser-thingy i should be using for hacking these guix-related files?
<lilyp>also note that if you're using the label, you should use (this-package-input )
<lechner>ulfvonbelow: would it be acceptable to file a patch to (re)introduce input labels to libxkbcommon?
<lechner>lilyp: as opposed to assoc-ref?
<ulfvonbelow>probably better to file a patch to completely switch it over to gexps, I'd think
<lilyp>fnstudio: I wouldn't trust local-file in the context of guix home, but since you *are* using it, do place them next to your home-config.scm and make sure you resolve names next to it
<lilyp>(that is using dirname etc.)
<lilyp>lechner: as opposed to assoc-ref.
<lechner>lilyp: thanks!
<lechner>lilyp: why is local-file problematic with guix home, please?
<fnstudio>lilyp: uh, very interesting
<fnstudio>yes, lechner stole my words
<fnstudio>:)
<lechner>sorry!
<lilyp>lechner: because the primary use of guix home is overwriting your local files
<fnstudio>ahah
<lechner>lilyp: thanks!
<fnstudio>lilyp: the way i was thinking of using it was to have the original dot-files in my home-config folder, as you say, next to home-configuration.scm - so i suppose, that's better?
<lilyp>In that case you're probably just missing the "resolve locally" part
<fnstudio>hm, it feels like i'm missing something yeah
<lilyp>All 69 news entries are valid, this time for real :)
<lechner>ulfvonbelow: instead of our complicated dance with set!, would it be preferable to somehow offer add-layout as part of the official xkeyboard-config? https://www.pastery.net/zpwwdm/#l-17
<fnstudio>oh... maybe i should be using plain-file instead then?
<fnstudio>the diff being the recursive search in subdirs if i got it correctly?
<fnstudio>oh no, scrap that
<fnstudio>this fails '(identity-file (local-file ".ssh/id_rsa"))', context: part of my home-openssh-configuration
<lilyp>lesson 2: don't use guix home for crypto
<fnstudio>lilyp: lol, yeah it didn't feel completely right to copy rsa keys over like that to be honest
<apteryx>neat, I was able to have GDM's XDMCP work, which will make my to-be-submitted xvnc-service-type much more useful to experiment with multiple type of remote graphical sessions
<fnstudio>(just testing with a test key, but still)
<ulfvonbelow>fnstudio: the 'identity-file' field of 'openssh-host' is of type maybe-string, according to section 13.3.5 of the manual
<fnstudio>ulfvonbelow: ah, thanks! yes, it works if i simply remove the local-file bit
<ulfvonbelow>the intended use is that it's used to tell ~/.ssh/config the filename to use for the identity, not to provide the identity itself
<lilyp>apteryx: does that mean we have a way of debugging gdm effectively now or is that something else?
<fnstudio>ulfvonbelow: oh, i see, so i understand i should be dealing with all sensitive files (including ssh keys) separately from guix home?
<fnstudio>in an ideal world all data should be in '.local/share' and all config in '.config' and it should be safe to track all .config stuff via guix-home?
<rekado>sneek: later tell antipode Download speed from within the MDC campus network is 190MB/s. Through my ISP (same city, same district) I get only about 2MB/s.
<sneek>Will do.
<ulfvonbelow>I would assume that 'guix home' stores most of the data derived from the configuration in the store, in which case it is world-readable. Whether that's acceptable may depend somewhat on the details of your situation (for example, I generally feel okay with putting my mumble server password in there, since anyone who I grant access to my computer will probably be someone I'm okay with joining anyway), but in the overwhelming majority of
<ulfvonbelow>cases it's a bad idea.
<fnstudio>ulfvonbelow: i see, thanks, very good to know
<pinoaffe>I'm packaging `emacs-pdfgrep` and trying to patch an elisp file so a path to a binary is hardcoded to the store. I've tried various variations of calls to `substitute*` and `emacs-substitute-sexps`, but so far none of my attempts have succeeded - does anyone have an idea what I might be doing wrong?
<pinoaffe>the package definition is at https://bpa.st/3GPQ
<rekado>I’ll try to figure out where all that bandwidth is lost. It’s not the server’s fault.
<pinoaffe>the package just builds, but the elisp file remains unchanged
<lilyp>pinoaffe: raise an error after the substitute*, thus you can inspect the source when building with -K
<lilyp>also no-brainer, but always patch after unpack
<rekado>from the proxy servers on the campus network it’s even better: 320+MB/s
<lilyp>(and not, e.g. before build)
<pkill9>anyone got pipewire video capture wroking with sway?
<pkill9>in obs*
<rekado>would love to see comparable numbers outside the campus network
<rekado>maybe it’s that darned firewall again
*rekado shakes fist
<civodul>pkill9: i heard someone mention this at the 10y event; i think daviwil had a pipewire shepherd service?
<ulfvonbelow>lechner: unfortunately the reason we have to use set! is because various places in guix are hard-coded to use the package bound to that particular variable. Even if you added utilities to make it easier to create derived packages with extra layouts, it doesn't change that the original package doesn't have it.
<pkill9>I'm running the pipewire service, I'm using for sound fine, this is for video capture
*rekado talks to the network people at MDC IT
<ulfvonbelow>ultimately I think the Proper Solution™ would be for the keyboard-layout record to allow the user to supply their own xkeyboard-config package, but that requires modifying guix itself
<pinoaffe>lilyp: thanks!
<pinoaffe>I somehow got it to work using emacs-substitute-variables, but I still don't quite know why this works and the other attempts didn't
<fnstudio>lilyp: re no crypto with guix-home, would you know what a good workflow for sensitive data (e.g. ssh keys) could be? should i simply handling things separately and leave .ssh/.gnupg/.pass/... out of guix-home?
<civodul>cbaines: just saw the #<eof> issue you mentioned :-)
<cbaines>civodul, cool :) I added some code to hopefully make things like that easier to debug in the future
<lilyp>fnstudio: it's an unsolved problem
<fnstudio>lilyp: ah, cool, good to know - at least i know it's not just me! thanks
<fnstudio>i'll be soon moving to a new machine and i wanted to make everything my env a tad more reproducible and easier to clone
<fnstudio>*to make my env
<fnstudio>but i suppose i'll handle .ssh and alike separately then
<ulfvonbelow>note that not all parts of ssh, gpg, etc configuration need to be secret. In fact, most of it aside from the actual key material itself is pretty harmless, e.g. specifying pinentry programs, known host fingerprints, identity filenames (not identity files themselves!), etc is usually pretty benign
***ft_ is now known as ft
<lechner>ulfvonbelow: thanks! it's still building locally btw
<lechner>ulfvonbelow: when i updated xkeyboard-config in guix recently, it went into core-updates because it affected ~3500 packages. should i look into a graft or so?
<fnstudio>ulfvonbelow: absolutely, thanks, good point
<ulfvonbelow>woah, 3500 packages? did not expect that
<ulfvonbelow>I guess maybe it's a dependency of xorg-server?
<pkill9>where is the path set for where to search for dbus services?
<ulfvonbelow>XDG_DATA_DIRS, I think
<pkill9>i'm not sure it is
<ulfvonbelow>looks in the dbus-1/services subdirectory IIRC
<apteryx>how do I specify minimum memory requirements for a system test marionette OS?
<apteryx>lilyp: turn debug? #t for gdm-configuration then run 'tail -c0 -f /var/log/gdm/greeter.log /var/lib/gdm/.local/share/xorg/Xorg.0.log /var/log/messages /var/log/debug /var/log/secure > gdm-debug.log' before logging in
<apteryx>it's about as fancy as our guile debugging with pk, but got the job done
<apteryx>and I compared the remote (failing) case with a successful local case
<fnstudio>any idea what could be wrong with this home service definition? https://bpa.st/AKPA still struggling with local-file
<fnstudio>it gives me a "Wrong type to apply" error
<jpoiret>fnstudio: the second argument of service-extension should be a procedure that takes a service value and returns the list of files to add
<lechner>Hi, do I have to do anything for Guix to query adjacent equipment for substitutes?
<jpoiret>i think you should be doing a list of pairs by the way, so ("file.el" . ,(whatever))
<fnstudio>jpoiret: ah! thanks, it'd have taken me ages to spot it
<jpoiret>lechner: yes, since you have to trust the substitute source
<jpoiret>i think `guix discover` should help you set that up using avahi
<jpoiret>but it doesn't seem to work on my laptop
<lechner>jpoiret: thanks!
<pkill9>live lfie on the edge and prepend `guix time-machine --` to all your guix commands
<pkill9>life*
<jpoiret>8)
<fnstudio>jpoiret: works like a charm now, ty!
<jpoiret>you can use time-machine to test patches now :) i realized that with cbaines s presentation, but since there's a git repo with a branch per issue with patchset, you can just do `guix time-machine --url=https://git.guix-patches.cbaines.net/git/guix-patches --branch=issue-57923` and test things out
<jpoiret>you should even get substitutes for the packages through bordeaux
<podiki[m]>very nice!
<jpoiret>(i'm actually testing this atm, but nothing should be preventing it, maybe a little --disable-authentication though)
<ulfvonbelow>I assume you'd need to either look over the patches yourself or trust the person submitting the patch + the patch-repo host?
<jpoiret>of course
<ulfvonbelow>personally I think I'd rather pull a local copy of the patch-branch, inspect it, then run guix time-machine from that
<jpoiret>the thing is, computing the derivation takes a long time compared to a make
<jpoiret>but it could be easier for end users that don't have a local checkout
<pkill9>I'm getting this error when running wireplumber as a user shepherd service and it fails to run: Error acquiring bus address: Cannot autolaunch D-Bus without X11 $DISPLAY
<pkill9>but I can run it outside shepherd fine
<pkill9>hmm I assume shepherd starts before dbus and therefore doesn't get a dbus socket in the environment, but, pipewire works in teh service so
<pkill9>yes, restarting shepherd itself worked
<pkill9>i added a dbus service to my guix home and it works now
<pkill9>hmmm, imagine desktop applications run as services in guix home
<pkill9>well not guix home
<pkill9>i meant a user shepherd service
<pkill9>nah it would be pointless
<pkill9>best done with a launcher
<fnstudio>any recommendations for a minimalist (x11?) clipboard app? i'd be interested in something that can work well with emacs