<Aurora_v_kosmose>I think libpulseaudio does that autolaunching using dbus and pipewire-pulse taps into that, does it not? <Air4x>As far as I know pipewire uses dbus for doing it's thing <Air4x>I watched a video and the author said that to use pipewire you need to start dbus before <jpoiret>Aurora_v_kosmose: there's no dbus requirements for pulseaudio <jpoiret>the auto launching really is part of the lib afaik <jpoiret>it's not a dbus auto launching the service <vagrantc>huh. i guess i've been involved with guix about half as long as guix has been around (e.g. ~2017) ... and it started in 2012? ... i guess i'm not a newcomer anymore? :) <jpoiret>pipewire does use DBus, but pipewire-pulse only uses the pipewire side of dbus. there's no pulseaudio side <jpoiret>but the auto-launch is definitely not due to that <vagrantc>seeing yet another sound system makes me feel like a grumpy old person yelling ineffectively at kids to get off the lawn <Air4x>does the pulseaudio service provide some virtual service? <Aurora_v_kosmose>I'd have assumed that the lib just checked if it was registered, if the registered process was a live, if yes use that, else start a new one. <jpoiret>looks like communicating over dbus is a pulseaudio module, ie not needed for normal functionality <jpoiret>vagrantc: it's pretty good, you should try it :) <jpoiret>on wayland, it's mandatory since it's also used for A/V capture <jpoiret>including sharing your screen in a browser <vagrantc>jpoiret: by the time i get around to trying it, there will be another <vagrantc>i've used oss, alsa, esound, pulseaudio and i think i even tried pipewire ... it just seems to be abstractions on top of abstractions with a little abstraction on the side :) <lilyp>👆️ that's probably everyone's experience if they decide to mess around with any of the daemons <lilyp>don't forget jack if you need to be professional <Aurora_v_kosmose>Thankfully jack at least works as intended & properly with pulseaudio if you follow the Arch wiki guide. *vagrantc doesn't forget jack, but it seemed like the one you could get away with not using and still have sound <lilyp>I'm pretty sure pipewire is not a requirement *yet* *vagrantc waits patiently <lilyp>I mean not a requirement for audio. <lilyp>As far as I'm concerned, pulseaudio is currently "enough". <Air4x>Do you think that a pipewire service shoul require some sort of DBus service? (this is a question for everyone) <vagrantc>i like my radio. i press the power button, sound comes out. sometimes i have to twiddle a knob or two, but rarely. *vagrantc tries to get back on topic <Air4x>vagrantc: my father thinks the same <Aurora_v_kosmose>I vaguely recall mention of it being phased out here. I'm not sure if that was ever done though. *vagrantc will self-censur for a while at risk of going wildly off-topic :) <Aurora_v_kosmose>Anyway, I think that registering into the bus system can certainly be useful in avoiding unwieldy hacks... but dbus is not very portable afaik which isn't good. <lilyp>having a shepherd service would suffice for guix, no? <lilyp>a per-user shepherd service sure, but… this more or less re-raises the point that shepherd should be more like systemd and claim a role in initializing user sessions <Gooberpatrol66>I have included util-linux in propagated-inputs for a package, but the configure script can't find the util-linux headers. Do I need to add util-linux to search-paths or something? ***dgcampea-2 is now known as dgcampea
<NaturalNumber>i'm a little confused. "guix install exwm" creates a .desktop file in ~/.guix-profile/share/xsessions/. According to the manual (slim-service-type), shouldn't this show up on the login screen? <rekado_>dgcampea: I suggest using modify-inputs <Guest141>I'm trying to package a python library, but it crashes because the library has no setup.py. I looked at the docs for python-build-system, and it seems like the following should fix my problem: <Guest141>error: in phase 'build': uncaught exception: <rekado_>Guest141: take a look at python-isort in python-xyz.scm <NaturalNumber>"guix install xmonad" should show up in the login manager, right? <bjc>if you want it to show up in the greeter, you need to add it to your system configuration <baconicsynergy>I've noticed that the glibc-utf8-locales package no longer exists. Instead of downloading the beefy 1G worth of locale information from glibc-locales, is there a way for me to setup only en_US* locales for my guix installation? (foreign distro, Ubuntu) <Air4x>Hey magic people, when I launch shepherd it gives me this error: %exception(#<&missing-service-error name: pipewire>) <vagrantc>baconicsynergy: i think it still exists, it's just hidden ? <baconicsynergy>besides all of the locale information, guix is working on Ubuntu 22.04 perfectly :)))) <vagrantc>would it be crazy to make one output per locale? e.g. glibc-locales:en_US, glibc-locales:zh_CN, etc... <vagrantc>or ... glibc-locales:en glibc-locales:zh ... <vagrantc>then people could install just the locales they actually want... <baconicsynergy>yes, i agree that breaking up the locale information is a great idea! <vagrantc>not sure what the implications are for making such a locale split actually work well <Guest141>Thanks so much rekado_. I feel like I so much closer. <Air4x>Can't we use the same approach used for glibc-utf8-locales-2.29? <Guest141>Though, now it fails with "ValueError: ZIP does not support timestamps before 1980"... <rekado_>Guest141: (setenv "SOURCE_DATE_EPOCH" "315532800") before build <Air4x>they were able to make package of only utf8 locales, they could do a similar thing for breaking up the locale information <Air4x>rekado_: the people or the person who wrote the package <baconicsynergy>when i used arch linux about 5 years ago, I only installed the en_US.UTF locale <Air4x>english is not my first language <vagrantc>it looks like glibc-utf8-locales ... basically just copies out the locales from the glibc package <vagrantc>but it was poorly named ... it implied other utf8 locales, but really it was a very small set of utf-8 locales <Air4x>Changing topic, can someone explain me how #:requires works? <Air4x>it's giving me a lot of problem <Guest141>does that need to be done from a repl? If so, how do I call build from a repl? <jab>ve asked this before... <jab>Air4x: does guix have a client to watch said content? <jab>I didn't know it worked with a web broswer.... <Air4x>in the browser you can use odysee.com <baconicsynergy>I love it's portability, like pkgsrc. I can interface with most modern systems I'll encounter and have reproducible builds at my disposal, and if there isn't a derivation, I can just simply build the package. It's so beautiful <baconicsynergy>I'm gonna try to introduce Guix to my friend. Lately he's been VERY good at picking up the basics for compiling code and using git and make. I think Guix is perfect for him at his skill level now <xelxebar>Hrm. This is annoying. I think the strip phase of (guix build gnu-build-system) has a bug. <xelxebar>Debug outputs are not created when strip-binaries? is false. <xelxebar>The machinery to automatically create detached debug info files in a "debug" output is in (guix build gnu-build-system) inside the strip phase. <xelxebar>However, the strip phase is essentially no-oped when strip-binaries? is false. <xelxebar>I think the (when strip-binaries? ...) wrapper around the final (for-each strip-dir ...) invocation should simply be removed. <SeerLite[m]>Searched the logs and found some Guest11 getting the same error on June 8th <SeerLite[m]>Alright so some ctrl-f and reading further lead me to the solution: Removing ~/.cache/guix/checkouts <roptat>si des francophones passent par là , comment vous traduiriez « bill of materials » en français ? <rekado_>that’s why I gave you the (setenv …) form <efraim>I wonder if we can build glibc-locales using the default "libc" instead of adding glibc as a native-input <efraim>diffoscope says the only difference between glibc-locales and glibc-locales-2.32 is the version string in %output/lib/locale/$VERSION <rekado_>efraim: is the same true for much older locale data? <efraim>rekado_: checking that now. So far 2.31 is different, and 2.30 is different also <efraim>2.30 and 2.29 might be "the same" <efraim>no that one is different too, I messed up the hash the first time <efraim>heh, I think that's the only one I didn't check after the update <raghavgururajan>The derivation would be /gnu/store/6lq7dfdfzrlp24lmhj95fcnvkr2mrqfz-sbcl-2.2.6.drv @ cec5a52 <cbaines>raghavgururajan, have you got a link to a failing sbcl build on ci.guix.gnu.org? <efraim>I was able to build sbcl locally <efraim>I'm currently on commit c145e51844bf52eb77cdc969a0fe30a48755b29e. And that was for x86_64 <raghavgururajan>cbaines: Yep, that (#56353) seems to be the issue. Getting same error when I build locally. *raghavgururajan closed the CI tab, looking again <roptat>nckx, c'est ce que j'ai trouvé, mais je ne le connaissais pas dans ce sens <nckx>baconicsynergy: Why are you downloading 1GiB of locales? :-o <nckx>Are you deploying to a foreign distribution? <baconicsynergy>nckx: the glibc-locales package for guix comes in at a whopping 917 MiB :) <rekado_>odd that guix size and du -sh differ so wildly here <nckx>baconicsynergy: Hard links(?) aside, why are you using that package though? <baconicsynergy>I'm using Guix on a foreign distro and its what the manual says to install <rekado_>the manual says to install *one* of the locales packages <rekado_>it shows an example of installing the big package, but it also shows you how to install subsets <vivien>Do I have a way to know which file the nginx server uses as a configuration? <vivien>I’m having an issue with certbot not taking over port 80 <cbaines>I don't think certbot can take over port 80 from other processes though <vivien>The certbot service type injects itself in the nginx configuratio <baconicsynergy>rekado_: oh, i see now in the devel manual. but how would i perform this on a foreign distro? <rekado_>baconicsynergy: guix build -e '(begin (import (gnu packages base)) (make-glibc-utf8-locales glibc #:locales (list "de_DE") #:name "my-locales"))' <nckx>Aside, a patch to swap /manual and /manual/devel (and other adjustments like a CSS banner) will be one of the first things I send. <silicius[m]>If a program is meant (and structured) to be used from its own directory, can I put it to /opt or should I try patch it to somehow adhere to standard directiories? <rekado_>silicius[m]: it would be /gnu/store/…-name-version/opt, which isn’t very nice <rekado_>I’d try to make it work a little better with conventional directories, even if that means stuffing parts of it in /share or /libexec and adding a wrapper to /bin. <silicius[m]>hmm. The program concists of two python scripts loading the main module of the program, a binary it uses and some static files like images etc. <silicius[m]>I think the two scripts should go to /bin, the main module to /lib/python/<module> and static files to /var? <nckx>That, if doable, otherwise everything in lib with wrappers in bin. Var shouldn't be used (although it sometimes is), use share or lib. <nckx>There are no variable-size files in store land :) <rekado_>we mean /gnu/store/…-name-version/share <rekado_>the prefix is generated by Guix anyway; we don’t use /usr or / as a prefix. <silicius[m]>That's implicit. Sorry, I was always talking about anything under the "out" output of the package <rekado_>just “share” then. “/usr” is a prefix, and we don’t want to have an extra prefix under the prefix Guix generates. <silicius[m]>Is it mentioned somewhere in the manual? Maybe I missed that info <rekado_>it is not mentioned anywhere. The build system takes care of the prefix. <silicius[m]>Oh no. I'll have to package swftools too for that package <jpoiret>any reason git-checkout is extremely slow at updating cached checkouts? <ncbfg36>I'm installing guix on a system with coreboot. I've found this solution posted in a few places https://lists.gnu.org/archive/html/help-guix/2019-05/msg00275.html. Being unfamiliar with this system i'm struggling to understand exactly how this works. I have gathered that "(installer #~(const #t)" sets up some kind of condition that always returns True, so grub is never actually "installed". I don't <ncbfg36>understand why "(bootloader" is nested twice in a row. I also don't understand what "inherit grub-bootloader" does. Inherit from what? Maybe i'm overthinking it I just find myself needing to understand what i'm doing and why. Can anyone point me to some documentation that explains these things? <jpoiret>ncbfg36: the two nested (bootloader ...) are unfortunate, but that's because the first one is a field of the record (bootloader-configuration ...) to specify which bootloader you'd like to use, and the other bootloader is to define a bootloader record itself <rekado_>ncbfg36: the first (bootloader …) means the “bootloader” field of the bootloader-configuration value <rekado_>the second (bootloader …) is a constructor that returns a bootloader value. <jpoiret>basically, what this snippet says is: "let my bootloader configuration be one with, as a bootloader, the new bootloader that inherits all of grub-bootloader's fields, but with the install field reduced to #t" <jpoiret>defining install to be (const #t) just means that install should be a no-op, instead of running grub-install <ncbfg36>jpoiret: rekado_: wow thankyou! I appreciate the clear explanation. <jpoiret>ncbfg36: for the documentation part, unfortunately i don't think there's documentation on guix records, which are a high level API over SRFI-9 records <jpoiret>but for the specific fields of each record, you should look at gnu/bootloader.scm for the definition of the bootloader record, and gnu/system.scm for the operating-system record (danger, it's a big one!) <jpoiret>grub-bootloader is defined in gnu/bootloader/grub.scm most likely <jpoiret>guix records allow you to create records by naming their fields, rather than the SRFI-9 way which wants you to specify the fields in a specific order without names, which is less readable <jpoiret>also adds (inherit some-other-object), meaning that all fields that aren't specified should be looked up in some-other-object <jpoiret>(and also defaults, thunked and sanitized fields, but that's not important here) <jpoiret>all of that machinery is in guix/records.scm, but it's kind of heavy macro-foo so put on some goggles before opening the file <ncbfg36>Thanks. I'll get this installed and have a good explore. I'm quite new to programming but i'm planning to go through "Structure and Interpretation of Computer Programs" and "How to Design Programs" and getting myself familiar with using emacs as more than a text editor. I want to learn this whole ecosystem and have more control over my computing <jpoiret>if you're new to programming, good luck! Guix might not be the easiest OS to get into in this case, but it'll be a learning experience :) <rekado_>ncbfg36: I can also recommend the SICP *videos*; they are more accessible than the book. <ncbfg36>rekado_: are you talking about content from an MIT opencourseware course? <paulbutgold>Good afternoon everybody, what's the most idiomatic way to apply a single phase from python-build-system to a package built with meson-build-system? I'm trying to package lutris which is built with ninja and meson but has a python entypoint, which requires to be wrapped as python executables do in python-build-system <paulbutgold>I tried to replace the wrap phase of the package with (@@ (gnu build python-build-system) wrap) but it doesn't seem to be able to import it <fnstudio_>hm... i've guix installed emacs and emacs-s, then i started a new emacs session, but i don't seem to be able to find s.el functions such as s-format... <fnstudio_>oh maybe some issue with my init.el that gets in the way... <jpoiret>paulbutgold: you'd need to add the gnu build python-build-system to the imported modules of the gexp <fnstudio_>(oh ok sorted, i was looking at the wrong thing... 'M-x s-format' doesn't show s-format as that's not an interactive function) <paulbutgold>jpoiret: do you know any packages that already do this? So I can have a look at the code itself <jpoiret>a quick grep tells me hplip does something similar <jpoiret>btw it's guix build python-build-system, no gnu <jpoiret>system-config-printer in gnome.scm has something more along what you're looking for <jpoiret>there's a wrap phase that just reuses python's <paulbutgold>jpoiret: thank you vey much <3 i'll start from system-config-printer then <nckx>sneek: later tell paulbutgold: corefreq is another package that combines build systems (disclaimer: I wrote it). <lilyp>rekado_: Should we sort team members by last name? Right now that'd move you to the bottom :( <silicius[m]>How to run a program (from native-inputs) during one of the build phases? <lilyp>(invoke "program" "arg1" ...) <vagrantc>sneek: free range sustainably grown botsnack for you <dgcampea>how can I upgrade from guix stable to guix latest? <vagrantc>dgcampea: there isn't a guix "stable" ... guix merges updates on an ongoing basis, though ones that triggers lots of rebuilds are put off for staging and core-updates ... <dgcampea>by stable I mean the current 1.3.0 series <vagrantc>dgcampea: guix pull should pull from git and get the most current stuff ... you might have to log out and log back in again after running it for the changes to take effect <vagrantc>(or manually reset all the appropriate variables) <nckx>dgcampea: Put differently, there is *no* way to update, from 1.3 and not be on 'latest' without effort. <GNUtoo>hi, I've written some code that retrieve the various targets from an Android Makefile (Android.mk). That code generates a list, and I was wondering how to use that list in build and install functions of a package definition <GNUtoo>I've written something like make-<something>-package and passed the list to the package, but then it said it didn't find the variable <GNUtoo>"unbound-variable #f "Unbound variable: ~S" (local-modules-func) #f" <justkdng>you need to enclose your code with (let ...) I believe <rekado_>lilyp: if you think sorting is important then let’s do it. <dgcampea>nckx: so 'guix pull' on a 1.3 install automatically raises it to 'latest' ? <vagrantc>dgcampea: 'guix pull' builds guix from guix master <vagrantc>dgcampea: and all the relevent package definitions and whatnot <rekado_>GNUtoo: you do “(define-public (make-android-package local-modules-func) (package …))” <rekado_>that’s a procedure that takes an argument local-modules-func and then returns a package <rekado_>your problem is that the value of the package’s (arguments…) field is quoted <rekado_>you don’t have access to local-modules-func there <rekado_>local-modules-func apparently is not actually a procedure <rekado_>so you wouldn’t be able to call it anyway <dgcampea>what's the purpose of having 1.3 and 'latest' distributions then? For users to choose a fixed guix commit? <GNUtoo>ok, let's assume I make local-modules-func a procedure, I didn't understand the first point <rekado_>you give it a quoted list consisting of 'list and a bunch of strings <rekado_>because you can’t serialize a procedure and pass that to the build side <rekado_>if you just want to pass the list that’s fine <GNUtoo>Is there some documentation on that somewhere? <rekado_>the guile manual talks about quasiquoting <GNUtoo>And what I also don't understand is why the build functions can't accept functions <rekado_>but more importantly we’ve got two “layers” here <GNUtoo>I can deduce that from reading "6.16.1.1 Expression Syntax" ? <rekado_>we’ve got host-side code and build-side code <rekado_>all the stuff in (guix build …) is available on the build side <GNUtoo>Yes, I get that but I've no idea how these two layers work together <rekado_>so you can’t just sneak a procedure from the host side to the build side <GNUtoo>I meant how to interact together <rekado_>that whole arguments value is data, not code <GNUtoo>like is there some code that just does ungexp somewhere? <rekado_>at least from the perspective of the host side. <vagrantc>dgcampea: having a release gives you a starting point from a "known-good" state <rekado_>GNUtoo: let’s keep gexps out of this <rekado_>gexps are just sexps with more specialized knowledge of store locations <GNUtoo>Is there some code that does unquote somewhere? <GNUtoo>like how that build side code is executed? <rekado_>understanding that is not really necessary <rekado_>you only need to know that you cannot do anything from the host side to affect the build side unless you include modules on the build side <GNUtoo>ok, I was always a bit confused about things because I don't understand that part <rekado_>that’s why (arguments …) has #:modules so that you can add code in the execution context of the build side code <rekado_>all you can control when writing package definitions is the host-side stuff <rekado_>the package definition is evaluated on the host side <GNUtoo>So here I knew they were separate and so on but I didn't know exactly how, and I looked in manuals but didn't find enough infos that would make it clear for me, though I can read "6.16.1.1 Expression Syntax" and come back if I'm still confused <rekado_>what you can do when building up an (arguments …) value is pre-compute some values on the host side and then plug them into the quoted expression <rekado_>so the computation does not happen on the build side <GNUtoo>That would work fine for my use case <rekado_>let me try to explain how these things are connected <GNUtoo>The other way around (having the code that parses the Android.mk on the build side) would also work if that code isn't duplicated many times <rekado_>package definitions are nice and all, but they cannot directly be “executed” <rekado_>so what we need to do is “compile” them into derivations with builder scripts that the daemon can execute. <rekado_>you can see the builder script by doing “guix build -d hello” <rekado_>this returns the file name of a derivation <rekado_>and you’ll see /gnu/store/s5y2w04jiydki5wb0zb9189x88v5288s-hello-2.12.1-builder <rekado_>that’s the guile script that is run by a builder process invoked by the daemon <rekado_>this script has access to the modules that are listed there: /gnu/store/frk13f6mydbp3iph00b8q6gll4flwxck-module-import and /gnu/store/qvbs5ccswghddrqkvq9zr8dgvd0jh6zs-module-import-compiled <rekado_>other than that there’s no other code <rekado_>so if you were to include a reference to some host-side code it wouldn’t know how to access it <GNUtoo>ok, so there is something that takes that build function and produce a /gnu/store/s5y2w04jiydki5wb0zb9189x88v5288s-hello-2.12.1-builder <rekado_>there are two ways to get something from the host side to the build side: add the procedure to modules that are loaded on the build side (e.g. by modifying (guix build …) or by adding the module with #:modules) or include the *result* of a host-side computation by unquoting. <rekado_>in the case of make-android-package you can compute the strings on the host side and splice them in to the arguments value <GNUtoo>ok, I see. my mistake is that I thought I could somehow pass functions that would then be compiled inside the *-builder <rekado_>example: (make-it-so stuff `(#:phases (bla (list ,@stuff)))) <rekado_>(make-it-so '("foo" "bar" "baz")) => '(#:phases (bla (list "foo" "bar" "baz"))) <rekado_>(define (make-it-so stuff) `(#:phases (bla (list ,@stuff)))) <rekado_>so you’re really just computing that quoted data, fully formed <rekado_>there’s no computation on the build side; it just receives the finished data as code <GNUtoo>What was unclear was how it worked in practice, but for that I'll also read or re-read the documentation you pointed me too and do experiments to make it more clear in my head <GNUtoo>(I'm taking the occasion given by this issue to try to understand lisp and guix quote/unquote really well) <GNUtoo>(things weren't that clear in my head and that practical issue shows that in practice, so it's a good way to finally get to understand how things really work) <rekado_>the guile docs won’t be of much help <rekado_>they just show you how quasiquotation works <GNUtoo>more or less but it's always good to re-read things to make it more clear <GNUtoo>like I get the mechanism but I might have mistakes in my head with the exact syntax <GNUtoo>Anyway thanks a lot for the help and explanations!!! <rekado_>I often liken quasiquotation to a toggle switch that toggles between data and code <rekado_>` is the switch in data mode, whereas , is the switch in code mode. <rekado_>the result is still just data, but with the code stuff evaluated <rekado_>`(whatever you want ,(+ 1 3 4) and so on) <rekado_>that sum in the middle gets evaluated as code and you end up with a list of the symbols 'whatever, 'you, 'want, the number 8, and then the symbols 'and, 'so, and 'on. <rekado_>,@ is just like , except that it’s like penicillin *GNUtoo isn't very familiar with ,@ but I can read about it in the manual <rekado_>it bursts the cell wall of the list and pukes out the contents into the current context <rekado_>`(1 2 3 ,@(map 1+ '(1 2 3)) 5) ==> (1 2 3 2 3 4 5) <rekado_>compare with `(1 2 3 ,(map 1+ '(1 2 3)) 5) <Guest141>trying to package a python library, and I get "ValueError: ZIP does not support timestamps before 1980". I try specifying an epoch start date by running "SOURCE_DATE_EPOCH=315532800 ./pre-inst-env guix build synapse". Still broken <silicius[m]>What to do when there's a circular dependency between two packages? <silicius[m]>python-mkdocs-material needs python-mkdocs-material-extensions to function correctly, but the latter only needs the former for tests <silicius[m]>(I wrote the material-extensions package defintion, but mkdocs-material is already in guix) <efraim>Either a bootstrap package that does just enough, or more likely skip the tests with a note as to why <rekado_>that’s why I gave you the (setenv …) form <rekado_>(setenv "SOURCE_DATE_EPOCH" "315532800") before the build phase <rekado_>dgcampea: don’t use a label, just use the origin <rekado_>dgcampea: to access this origin without a label you’ll need to search the inputs <whereiseveryone_>does anyone happen to know where the sources are for that pdf reference card? <davidl>"hmm. The program concists of two python scripts loading the main module of the program, a binary it uses and some static files like images etc." - the binary that "it uses" should possibly be put in a libexec folder, but that's a detail which Im not sure anyone cares about or is very useful for guix packages. <tribals>I've a question about user passwords. According to docs, <tribals>> Passwords set with passwd are of course preserved across reboot and reconfiguration. <tribals>Another question is: if I set password during "operating system generation" time, be it image building, or reconfiguring, with Guile's `(getpass ...)`, will it preserved, as with `passwd` passwords? <civodul>a file to describe teams working in a specific area of the code <Guest141>the python library I packaged fails during "sanity-check": ERROR: matrix-common==1.2.1 DistributionNotFound(Requirement.parse('attrs'), {'matrix-common'}) <Guest141>I'm asuming that is a failure during the install phase? <dgcampea>unmatched-paren: is my 'firefox-policy' package definition correct? Right now icecat doesn't seem to pick it up although I'm not sure if its an icecat problem or if I got the paths wrong in the manifest <unmatched-paren>Guest141: I suppose you have python-matrix-common as a propagated input? <unmatched-paren>dgcampea: It won't be able to simply scan for it everywhere; you'd need to point firefox to the right directory :) <Guest141>It will be. This is the error I get when BUILDING python-matrix-common <unmatched-paren>dgcampea: If it has an environment variable, I suppose the icecat package would need to have a native-search-path for it. <dgcampea>unmatched-paren: firefox is supposed to read /lib/..... directly (I guess icecat should work the same but not sure) <dgcampea>testing this with guix environment, I don't see any /lib directory created <unmatched-paren>dgcampea: I see, it'd need to be patched to read an environment variable that points to multiple possible directories where /firefox/... might be found <Guest141>I think the problem is my install command. Currently, I invoke "pip --no-cache-dir --no-input install --no-deps --prefix $out $whl" <unmatched-paren>because if you're using the python-build-system install command it should work fine... <Guest141>no, in a custom defined 'install phase of the python-build-system. I need it to be custom defined because this library has no setup.py <nckx>dgcampea: 1.3 was simply a snapshot commit of master, over a year ago, when a relatively well-tested installer ISO was made. That is all. Nobody sane runs 'Guix 1.3' on their machine. <nckx>dgcampea: This is also not encouraged: all documentation suggests regular 'guix pull's, at which point you immediately abandon the 1.3 snapshot. <nckx>whereiseveryone_: I'd written this as draft mail, but it's probably more apt as IRC comment: your pitches often assume familiarity with Janet. Try selling to somebody wholly unfamiliar with it — like me! <dgcampea>unmatched-paren: which package requires patching? Does every program that expects third-party plugins/extra files require env var support? <nckx>tribals: Because none of the Guix system services touch /etc/passwd passwords, and /etc is not volatile in Guix. There isn't really a 'how' — passwords are preserved because at no point are they erased. <dgcampea>nckx: I see, thought it was a debian stable/sid situation <nckx>We don't have the person power to maintain a 'stable' backports branch. <nckx>TBQH, I don't recommend using the 1.3 ISO at this point. <nckx>silicius[m]: Make a hidden python-mkdocs-material-extensions/untested package that's used to build python-mkdocs-material which can then build the 'real' p-m-m-e. <tribals>Then, what is the root password? I can't find it in docs. <nckx>There isn't one by default. <nckx>Until you passwd (as) root. <nckx>So you can log in as root without password locally. <nckx>Or what unmatched-paren says. <trevdev>I have a custom module that is on my load path in my home environment that I am trying to import into a gexp (program-file), but for some reason it doesn't get included in the resulting derivation and I get errors about the module not having any code. Do I have to somehow build it into my home system ahead of time? <trevdev>I tried using (with-imported-modules (source-module-closure '((path to module))) #~(begin ...)) <trevdev> I can run my repl from my terminal and call up the module <civodul>trevdev: in the gexp, you're doing #~(begin (use-modules (path to module)) ...) ? <civodul>what if you replace (source-module-closure '((path to module))) with '((path to module)) ? <civodul>just in case source-module-closure returns the empty list or something <civodul>(it shouldn't happen, but who knows) <civodul>well you could also check the generated program <akonai>What's the quality bar for new system services in the main repo? <civodul>seriously though, i think it's okay to have a service that doesn't provide all the options but leaves room to do that later <civodul>IOW, i think it's okay to reduce scope, but not to reduce quality <civodul>(that's just my personal take though, not sure what others think) <tribals>nckx: That's exactly what I've thinking about. Why so? - Then password, even encrypted, will be persisted in /gnu/store. - Does it ever matter? When I will be log in first time, I immediately do `passwd`, then `sudo -i passwd`. So, I don't care. - Then, just pass *encrypted* password to `user-account (password ...) ...)`, as string. - Where to get one? `(crypt ...)`. - But it requires salt. For security reasons, it needs to be random. - How many salt? - <tribals>No more than sixteen characters, from alphabet: './0-9A-Za-z'. Also, it is not assumed, that encrypted password is ever exist in some file, eg. in my machine's `configuration.scm`, as it breaks any security. - So, I just want to directly type *my* password at machine's "build time" - when it's reconfigured, or image created. - There is `(getpass ...)` for this. So, my `(user-accounts (password ...))` becomes `(crypt (getpass "Password: " ((crypt (getpass <tribals>"Password: ") (sequence-of-randomly-chosen-characters-of-sixteen-length-from-alphabet-./0-9A-Za-z))))`. - The problem that there is no one. <tribals>This is because if password is ever stored, this should not even matter, or the whole cryptography will disappear, because it is encrypted. <tribals>In other words: if there is a way to restore random password (I've just typed it), then something is broken. <tribals>Display prompt to the standard error output and read a password from /dev/tty. If this file is not accessible, it reads from standard input. The password may be up to 127 characters in length. <civodul>tribals: the 'crypt' function is essentially a cryptographic hash, so it's one-way <tribals>`(getpass ...)` is limited to 127 character only, so at maximum, I get only `(string->bytevector (getpass "Password: ") "utf-8")`-byte entropy at maximum. <tribals>Not to say than salt is limited to just sixteen bytes. <tribals>I view this problem as a reason why it is not recommended to "The hash of this initial password will be available in a file in /gnu/store, readable by all the users, so this method must be used with care." <tribals>If it will be so simple `(user-account (password (crypt (getpass "Password: ") (salt))) ...)`, then I can do that even for root, in my `os/configuration.scm`, keep it in git repo, publish it and don't bother. <baconicsynergy>rekado_: thank you for the guix build command! I have something to study now :) I'm not a programmer but I think I can figure this out for other packages in the future <tribals>If anyone is ever interested about what I've just typed, then contact me: w732qq@gmail.com. Now I'm leaving, as it is too late ^_^ Good night!