<GNUtoo>hi, I've released a tarball made with guix pack, and the other day someone told me how to get produce the full and corresponding source code when building a tarball in this way
<GNUtoo>(It can be done with guix build --source=transitive <the-package>)
<GNUtoo>But I've made the tarball months ago from guix master, hopefully I've (1) the command used to build it, (2) I've used --save-provenance in that command, so the tarball has a file named 'manifest'
<vivien>My hypothesis is that GUIX_PACKAGE_PATH modified the set of modules guix knows about, but when you ran the command for the first time it was not exactly the same content as of today, so the final hash varied. Can you try unsetting GUIX_PACKAGE_PATH and run the time-machine command again? It should give you a different file name.
<GNUtoo>The issue is that diffoscope refuses to work (diff too big) and that parabola's meld is broken and that Guix's meld works (in guix env --pure) but I've some issues with icons and probably display, because I probably miss some deps somehow
<vivien>So let’s do that for the most suspicious package of the pack then!
<cehteh>like for example in config.scm when i want to have a service running i need to mention it in 2-3 places in a very verbose way with some configuration syntax i have to look up (and for services that are not provided yet i would need to do some scheme coding i dont know yet)
<cehteh>i need to know if the service i want is in %base-service or %desktop-services, if i need to write it anew or modify it and so on
<cehteh>would be somewhat nicer if there would be a config.scm which 'merges' a services.scm which only lists services, *but* does the right thing as in creating a new list element or modifying the existing one for %*-services. also figuring out which use-* things are needed for that
<dstolfa>right, but those aren't arguments to have less documentation. you could still have full documentation for everything and have the system be more approachable out of the box. i agree that these would be good features (also... what services have the "feature" that they need to be mentioned in 2-3 places? most services are just (service foo-service-type (foo-configuration (...)))?)
<cehteh>and instead a (service foo-service-type (foo-configuration ...)) it could have an reference to an native external configfile or directory like (service opensshssh-service-type (openssh-config-file "~/my_sshd_config")) which of course gets included not referenced in the derivitation
<cehteh>the my_open_sshd_config is meant to be a native (ssh!) syntax configfile not scheme
<cehteh>is of course somehow its possible to do that eventually the scheme defined configs generated native configs for any service
<dstolfa>cehteh: that already exists, they're called "escape hatches" in guix, for openssh it's extra-content and it's just a string
<dstolfa>the problem with putting it in a file, rather than a string or scheme is that you need to transfer this out of bound
<dstolfa>guix doesn't know anything about external things. you can point it to external things and it can create derivations using them, but you will still need to transfer them out of bound, instead of transferring them as a part of your system configuration file
<cehteh>when you build a system this gets incluided into the system dev
<dstolfa>sure, and i've written such an escape hatch for strongswan. you still need to transfer the out of bound files
<cehteh>what do you mean with 'transfer the out of bound files'
<clemens3>well, a deaper understanding how things work under the hood, would be nice.. i haven't figured it out yet from the manual and cookbook.. i remember when i started with git, that was quite helpful to feel confident using it..
<clemens3>lotsa books about internal workings of git.. of course, always easy to say what one wants..
<cehteh>i mean yes when i reference a sshd_config it needs to be imported into the store
<clemens3>but guix betting on guile and wrapping guile around everything, which has it's advantages, but makes it of course extra hard for ppl who have to learn guile first..
<dstolfa>if you want to have a configuration such as (service foo-service-type (foo-configuration (file "/path/to/config"))), that "/path/to/config" needs to be put there manually somehow, either through your git repository and a script or by you doing a manual cp or something along those lines. guix simply doesn't know anything about that
<cehteh>not used in the place i reference, thats only the location i use for preparing it
<dstolfa>however, if this was a configuration using a guix EDSL, then you wouldn't need to do this
<clemens3>e.g. how do i bootstrap e.g. java myself, i found the gnu/packages/java.scm, but what to do with it.. i have no idea
<dstolfa>there are escape hatches for this, e.g. in openssh it's just extra-content
<cehteh>dstolfa: currently it generates for exammple /gnu/store/igcl2kd3w4xily0v3gjwj90v5id7waj9-sshd_config
<dstolfa>but in this case it's a string, not a file. you could just turn it into a file and import your module with a variable called "my-extra-openssh-content" or something
<cehteh>i would really like if the config isnt one big file to begin with, but a 'guix config export' or something may then create a tarball of all files that are referenced/included in the main config.scm
<dstolfa>it isn't one big file unless you make it one big file
<dstolfa>you could just as well write a guix system configuration library specific to your systems
<dstolfa>it's just guile, which means you can make modules
<cehteh>thats the 'could' which assumes every guix user must know scheme well and have a lot of time
<cehteh>nah .. i am talking about a layer between system and user
<dstolfa>that would need some work, but can be done. the key thing is to figure out how to make it transactional and prevent system configuration drift
<dstolfa>suppose you had `guix system package -i ...`, it would need to set up the package, but it would also need to modify the system configuration somehow
<dstolfa>ensuring that this doesn't get lost on the next reconfigure
<cehteh>imo it system should be split into differnt layers as well one kernel layer (only kernel and the services that pet the kernel and keep the hardware running) .. then a 'system' layer with rest of the services, and 'all_users' layer which is moveable between machines, and finally per user (while there are 'users' out there who do not want to care about installing software, they have an admin for that)
<dstolfa>the kernel thing you speak of is already the case
<cehteh>dstolfa: yes i am talking about whats lacking, somehow it may be even simple to add
<dstolfa>it's not "simple" if you want to do it right, because you'd need to deal with complex configuration that people have, importing modules from all over the place and having their system configuration file in different places. the latter can easily be solved by "remembering" where the configuration is. the former is non-trivial
<dstolfa>you could hack it up to work for simple cases, but it might break some reasonably complex cases
<dstolfa>if you want to work on it... i'm sure people would be more than happy to try it, review it and use it :)
<cehteh>problem is that i dont know scheme not do i have that much time, but it would be nice if such things would acknowledged as possible roadmap
<dstolfa>well, there are many nice things that could be added, the problem is that time is finite :(
<dstolfa>cehteh: ultimately, guix is a volunteer project, so people work on what they want to work on or need for their uses. while i agree that having something like `guix system package -i` would be nice, someone needs to put in the time and effort to implement it
<clemens3>i just did a guix challenge, as suggested, and the first time it was 100% inconclusive, then i did a guix pull && guix package -u, and then the challenge again, and now 8 differed, 457 packages indifferent, out of 1186. Is not normal business? I am a newbie
<bricewge>Would it make sense to have a 'inferior-package->package' procedure?
<bricewge>I can't manage to build any package with inputs containing 'inferior-package' and struggle to understand that part of the code base
<sneek>muradm, apteryx says: seems you can use (simple-service 'your-service-name session-environment-service-type env-var-alist)
<muradm>apteryx: thanks for the hint, yeah session-environment-service-type could be of help. for now i solved with wrapper script, which seems to be better solution. i am not very sure about writing session-environment-service-type '(("XDG_RUNTIME_DIR" . "/run/user/$(id -u $USER)")), feels like out of control
<muradm>but definetly i will use it in some other places )
<muradm>no match for fgrep -r "session-environment-service-type" docs/* tho .. :)
<rovanion>leoprikler: Search engines are getting worse. Found nothing when I searched for "zig guix", but I guess I should have searched directly in the mailing list. Looks like getting lld@12 built involves some policy/hard work, I'll try to get some prebuilt binaries of Zig meanwhile.
<iskarian>sneek: later tell civodul the ld-so-cache RFC looks very interesting! I'm curious to see actual data from HDD users on the magnitude of improvement from it, since that's a fair complexity cost
<efraim>looks like it, it's the connection-gnutls test
<iskarian>it looks like it's the client-auth-pkcs11 test failing
<thorwil>hi! trying to run ardour, i get "/gnu/store/yxivqfaqiaihycfpzrk5pil6p4x5s4j2-ardour-6.6/lib/ardour6/ardour-6.6.0: error while loading shared libraries: /gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10/lib/liblilv-0.so.0: file too short"
<thorwil>well, it’s size is zero. i tried `sudo guix build --repair lilv`, which got busy, bu i still get the same error.
<civodul>jorge[m]: bueno, este mensaje significa que no se puede conectar a ci.guix.gnu.org; entonces no hay substituvos
<jorge[m]><civodul> "jorge: bueno, este mensaje..." <- En mis prueba e instalado mi sistema Guix 4 veces sin problemas.
<cehteh>hum .. what do i use as x screenlocker? i tried i3lock, but that hangs, then as fallback xscrensaver which gives: warning: /etc/pam.d/xscreensaver does not exist.password authentication via PAM is unlikely to work ... that explains the fail
<cehteh>ok works somewhat, thanks ... next i didnt find: where are the special (acpi) keys handled suspend works but brightness control and screen lock does not, acpid is packaged but i dont see any 'service' for it documented
<cehteh>ah i get xevents, i cna confiure that in the wm
<atka>cehteh: I think you may need to add a udev rule
<cehteh>notice: i seen a lot (including gnome) implementations where the screenlock is started when you wake up from suspend because of some race conditions, which gives a glimps of the screen content to anyone opening the lid and waking up the system
<dstolfa>no, because of technical issues. there's nothing really stopping it other than people working on it and expertise
<dstolfa>you could try running it under linuxulator
<hendursaga>A real shame, I don't even think Nix has much FreeBSD support either
<dstolfa>portability is indeed a noble goal, but also a hard one for a small volunteer project :(
<bricewge>cehteh: Have a look in xsecurelock together with xss-lock