<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' <GNUtoo>I did 'guix time-machine --commit=f9bd4621dd92a9415276706b476b9bd2973411fa -- pack [the same guix pack arguments than before]' <GNUtoo>Is there something that I did wrong or is that somehow a behavior to expect? <vivien>GNUtoo, you need extra steps to make sure timestamps aren’t included in tarballs, otherwise they mess things up <GNUtoo>I don't know, would it be a good idea to look with diffoscope? <GNUtoo>The issue I see at first sight is that it's supposed to produce a file name sz1lkq3ryr5iv6amy6f3d2pziks27g28-tarball-pack.tar.xz <vivien>I don’t know diffoscope, but if the extracted files compare equal recursively, then it’s a problem with the tar format itself <GNUtoo>I didn't use channels yet but I've a local repo with GUIX_PACKAGE_PATH <GNUtoo>Would that affect the output if none of the packages in GUIX_PACKAGE_PATH are used in the final tarball or in its dependencies? <vivien>I don’t know. I’m trying to run your command... <GNUtoo>Here if I set / unset it I've the same tarball being generated <GNUtoo>/gnu/store/bfxvk59q0m034iyq5zkk841zkisayyjl-tarball-pack.tar.xz <clemens3>leoprikler: oki.. looking tomorrow into it, thnx <vivien>There is a catch if you modify ~/.bashrc <GNUtoo>The host is Parabola x86_64 and some things probably changed between then and now <GNUtoo>Though if guix time-machine is typically reliable I could proably not care about this issue for now and just publish the source with guix time-machine [...] -- build [...] <vivien>Maybe it’s the previous or next commit <vivien>I’m building the historic pack, I will tell you my filename and hash *GNUtoo doens't know guix well so if I do shots in the dark, it could be really long for me to find why <GNUtoo>for diffoscope it's something meant to compare 2 files <GNUtoo>but it compares them recursively <GNUtoo>For instance if you have two tarballs, it can compare the content, and the content of the .so (as it has sections), and if something is compressed inside it'd compare its uncompressed version <GNUtoo>AFAIK It works with many file formats like squashfs, disk images and so on <GNUtoo>So it's probably a good occasion for me to try it <vivien>Right, but if the filename aren’t even equal, it’s not an accidental unreproducibility, it should be a problem with the environment <GNUtoo>ok, so the commands I did were supposed to work? <GNUtoo>In that case I could still fix my environment for the next releases and maybe ditch the old release <GNUtoo>but I'd need to know what to fix <GNUtoo>So I could try to isolate better the build <vivien>I’m not sure whether guix time-machine is sensible to other channel specifications <leoprikler>you can produce channel files, that way you can be sure there's nothing fishy in there <GNUtoo>ahh I can do that with guix time-machine probably <vivien>OK guix time-machine will look for your personal channels even if you don’t pass -C <vivien>So that’s a thing to worry about <vivien>Can you build a package with time-machine that you have defined in your GUIX_PACKAGE_PATH? <GNUtoo>I've something that looks quite similar <GNUtoo>guix time-machine --commit=f9bd4621dd92a9415276706b476b9bd2973411fa -- describe --format=channels <GNUtoo>I've /gnu/store things in the provenance file <GNUtoo>I'll try to see if they are there <vivien>I have no GUIX_PACKAGE_PATH set, I retried the command with your channels file <vivien>I need to download a few more git objects but I’ll tell you what filename I end up with <GNUtoo>In the rebuild tarball I've some of the same /gnu/store/ <GNUtoo>the provenance file has /gnu/store/hmp6ab9kw1z3hjns9h1fm3afsq4g6j7x-python-certifi-2020.11.8R <GNUtoo>tar tf bfxvk59q0m034iyq5zkk841zkisayyjl-tarball-pack.tar.xz | grep /gnu/store/hmp6ab9kw1z3hjns9h1fm3afsq4g6j7x-python-certifi-2020.11.8R finds that directory <GNUtoo>And here bfxvk59q0m034iyq5zkk841zkisayyjl-tarball-pack.tar.xz is the newly generated tarball <GNUtoo>same with the rest of the packages (git, nss-certs, le-certs, git-repo) *GNUtoo tries diffoscope now <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>But I've tried with today's GUIX_PACKAGE_PATH and without today's GUIX_PACKAGE_PATH <GNUtoo>The dir it points to might have been modified between when I released that tarball and now) <GNUtoo>So it might still be correct somehow <vivien>To see if it changes today’s hash <GNUtoo>I can try to go back in time with my GUIX_PACKAGE_PATH dir <GNUtoo>ah it points to an inexisting directory <vivien>I’m 32% of the way to download the correct guix commit <GNUtoo>(I use GUIX_PACKAGE_PATH on my laptop, and it propagated to my other computers due to configuration management, but I didn't built that package on my laptop, hence the confusion) <vivien>I’m curious, did you set it in .bashrc or .profile or .bash_profile ? <GNUtoo>yes, and that might have changed too <GNUtoo>for script in $(find "${HOME}/.bashrc.d" -maxdepth 1 -type f -name "*.rc") ; do ; if [ -x "${script}" ] ; then ; source "${script}" ; fi ; done <GNUtoo>And so It sources things like .bashrc.d/guix.rc <vivien>(bashrc is a problem for guix environment --container, because it loads .bashrc and the environment set there might make it instantly escape the container) <vivien>I don’t know how it works for time-machine though <GNUtoo>And on that build machine I have: 'ls: cannot access '/home/gnutoo/.config/guix/local': No such file or directory' *GNUtoo will try to use diffoscope <vivien>I built /gnu/store/bfxvk59q0m034iyq5zkk841zkisayyjl-tarball-pack.tar.xz too <vivien>So my hypothesis now is that when you built the pack for the first time, as you didn’t do it with time-machine, GUIX_PACKAGE_PATH actually mattered then, so it changed the output file name. <vivien>So if you want to reproduce it, remember to set the correct channels file (-C) and use time-machine. <vivien>When I guix hash it, I get 1q2xbfhg4m1cgma8dx0kn12li26w02x104cl0bclzb60xihm9b89 <vivien>sha256sum: 09ad5461ecc0ac4fd902941110ba00dc884845b013f486547d2c54f2a05b5de0 /gnu/store/bfxvk59q0m034iyq5zkk841zkisayyjl-tarball-pack.tar.xz <GNUtoo>/gnu/store/bfxvk59q0m034iyq5zkk841zkisayyjl-tarball-pack.tar.xz <GNUtoo>f3009be080fae86484bcddcd36409cddbaef17b927fd0d1c673743cc433c7e0c *GNUtoo will do some more checks <vivien>If I extract it and run guix hash -r gnu/ I get 1g287dyc98fz037r2ixbhxi5vlnhwb7gi7nhwp52h10hcrx670zb <GNUtoo>0040vnyvq73318d1dvi7sw7m82c33mrq7ndrrfglkay75p8nv52i here <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! <vivien>To have less binary files to diff <GNUtoo>it seems that the profile is somehow different <vivien>Are you comparing the original pack and the time-machine pack? <vivien>Since the file names are different, then it’s entirely possible that some symlinks point to different outcomes <vivien>I’m comparing 2 rounds of time-machine packs, separated by a gc <vivien>I forgot to save the previous one though, so I’ll do 3 rounds <vivien>Yes but I want to try diffing too <vivien>Because it’s not normal that two subsequent guix time-machine pack give two different hashes <GNUtoo>oh ok, so you managed to find issues there too <GNUtoo>Note that repo is strange by itself <vivien>Well, I suspect there is an issue since we don’t have the same hash for the time-machine pack <GNUtoo>when used normally it somehow tries to update itself <GNUtoo>Though it can't touch the /usr/bin/ or the store, so it runs itself in the repository you are checking out <GNUtoo>like when you download replicant source code it'll store a newer version of itself in Replicant source code <GNUtoo>That's why we use guix for that in the first place, because we ended up not being able to run the newer versions anymore *GNUtoo will diff with md5deep <GNUtoo>it seems that the main diff is the profile <GNUtoo>+ some of the files referencing the profile in /usr/local/ <GNUtoo>I see no other diffs with the other files <GNUtoo>(I grepped -v for -profile/" in the huge diff that I produced) <vivien>Is it because some symlinks don’t point to the same location, or is it actual file content differences? <GNUtoo>The names of the dirs are different for a start <GNUtoo>There is only 1 file that differs <GNUtoo>All the rest is a consequence of that change it seems <GNUtoo>so maybe I need more than just --commit= <GNUtoo>If I don't specify everything then the manifest file changes and everything else changes <GNUtoo>Even if it's the exact same commit <vivien>Be careful, --branch will use the latest commit from the branch you pass <GNUtoo>Should I bugreport about this strange behavior? <GNUtoo>+ (name guix) is also part of the diff <GNUtoo>so for that I'm not sure how to modify that <vivien>Maybe I’m confused about --branch because the guix build option --with-branch=package=branch reads in the manual: Build package from the latest commit of branch. <GNUtoo>Adding --branch=master doesn't rebuild the tarball... <vivien>Anyway, those #f are indeed suspicious *GNUtoo doesn't know how I could force it to rebuild the tarball *GNUtoo tries with guix build instead as pack --rounds=2 doesn't change anything *GNUtoo will try to bugreport tomorrow about all that <GNUtoo>For now I'll try to miniimze the diff with branch master <GNUtoo>So --branch=master didn't change anything <GNUtoo>vivien: thanks a lot for the help!!! <vivien>I learnt a lot about time-machine myself. I hope it will be a small step to help Replicant. <GNUtoo>Now that I'm pretty sure that the binaries matches I will generate the source code and publish it "in the same place" than the released repo tool, so it does help. <GNUtoo>We have (too?) many things to do with Replicant and ones of the areas of work is to make sure we publish the source code in the right way <vivien>(it would be terrible if Replicant had Reproducibility issues, given its name) <GNUtoo>vivien: it does but that's another story <GNUtoo>We need to investigate how to fix that at some point, though right now the top priority is porting Replicant on Android >=9 <GNUtoo>And I've issues with the modem driver of the Galaxy SIII (GT-I9100): I can't make it work on top of a mainline kernel <GNUtoo>Like we didn't even looked into it yet <GNUtoo>One thing that would be neat would be to be able to build it with Guix somehow, like from within a guix container <GNUtoo>The name Replicant (if I recall correctly) comes not only from Blade Runner but also from the fact that we're replicating Android <GNUtoo>Unlike the GNU project which reimplemented unix, we already had the source code to beginning with <vivien>There are some things for basic Java in Guix, there’s even an android-ndk-build-system <GNUtoo>but it was incomplete, so we spent time completing it <vivien>I suspect android-ndk-build-system was meant for Replicant <GNUtoo>not really, I'm not sure exactly what it builds <GNUtoo>Some utilities needs the android build system, like adb for instance <GNUtoo>It would be really interesting to be able to build Android applications with Guix though <GNUtoo>it's probably quite some work though <vivien>We have a maven-build-system, but you need to figure out the source <vivien>because maven central won’t tell you <GNUtoo>Many Android applications depend on that, and as-is it's almost unusable as it often contains binries with no corresponding source code <GNUtoo>So I guess that the way to go is to package each dependency in guix <GNUtoo>and somehow teach guix to build android applications for instance with --target= <GNUtoo>and package them with guix-pack somehow, though I'm unsure if /gnu would work there <GNUtoo>What is neat is that guix pack already has the deb format <GNUtoo>Gentoo also has some bionic port, so that work could be reused <GNUtoo>If we manage to build f-droid that way it could be really interesting <vivien>Guix packs are usually quite big <GNUtoo>Once all that is fixed we had a plan to make an FSDG version of f-droid that would be somehow maintained upstream <GNUtoo>Though given the huge mess out there, I don't see other viable solutions than Guix for that <GNUtoo>It's FSDG compliant, and it has the right abstractions for package management <GNUtoo>So maybe something based on guix could be worked out <GNUtoo>Where guix would take care somehow of the maven central issue <vivien>Like, a guix importer for maven? <GNUtoo>I was more thinking of something manual, the source code of important projects have to be somewhere, like in git for instance <GNUtoo>so if it's in git it can probably packaged like regular software <GNUtoo>The issue is if the whole thing depends on itself <GNUtoo>And I heard that some people worked on maven at least <GNUtoo>It was probably in the guix days presentations <vivien>I was trying to remember the name ^^ <GNUtoo>So it's probably a lot of packaging work, though it might still be possible to do some importers <GNUtoo>I don't know anything about go, but for instance the importer is quite generic <GNUtoo>the name of the package is related to its URL, so you can probaby import a repo from any URL <GNUtoo>Since maven probably doesn't depend on maven central we might be able to package more and more deps <GNUtoo>guix seems to have a maven build-system now <GNUtoo>It's probably necessary to build maven anyway ***califax- is now known as califax
<vivien>Scala looks really scary, the oldest commit (named "added CVS") already has scala code in it. <roptat>GNUtoo, even one package that uses the maven-build-system :) <roptat>it's really nice to be able to finally use it :) <roptat>I'm still missing the maven-plugin-plugin, that would allow us to build other maven plugins more easily <roptat>but that thing has hundreds of recursive dependencies that are not yet in guix... <roptat>and I'd need to build gradle too, which depends on scala and kotlin, which are not bootstrappable yet <roptat>btw, the scala files in the first commit of the repo can be built with the compiler that you can built from a subset of the "java" files <roptat>the real issue is that those java files are not java files, they are written in a superset of java5, that can be compiled with pico, but its source code is not available <roptat>I tried sending that email to get the source code, but never got a response <Guest53>I'm using x200 thinkpad with libreboot and can't boot into usb installer <Guest53>Still everything is fine for parabola installer <muradm>roptat: i submitted it as the patch as well <muradm>any way to add extra environment variable to /etc/environment? <muradm>couldn't find anything in docs on how to customize pam-environment <muradm>to be exact what would be the best way to set XDG_RUNTIME_DIR=/run/user/$(id -u $USER) <apteryx>sneek: later tell muradm seems you can use (simple-service 'your-service-name session-environment-service-type env-var-alist) <amirouche>the goal is to make it possible for people to test their scheme code on several scheme implementations <amirouche>last time I checked, cuirass will compile, install and test packages that are part of guix tree (possibly also from channels) <amirouche>For my use-case, I need to pick the package definition, or at least, the build and runtime dependencies from another repository. <amirouche>Also, regarding sandboxing / security model, what guix provides builtin in this regard? <amirouche>e.g. is it possible to request a build job inside qemu ? <vivien>roptat, so we just need a pico preprocessor? <bricewge>However I can as root, but if use the guix binary from root as a normal user it also fail <bricewge>Does someone know which user specific state could make this fail? <vivien>roptat, do you have the Extensible Algebraic Datatypes with Defaults paper? <leoprikler>On the Scala bootstrapping thing, even if you manage to build early Scala, you won't be able to use that to build later Scala versions <leoprikler>a post in the ML says it's being rebootstrapped several times per cycle <rubujeto>How can I install « nscd » ? Is it with «guix » or with « apt » ? <clemens3>hi, i got a mismatch in hash, and when i want to challenge the package, actually it is a patch file, it says package not found <clemens3>i5a5jv...-texlive-bin-pdftex-poppler0.76.patch ***rt is now known as robin
<PotentialUser-45>I have a problem, I want to forward the pci ethernet and pci usb controller to separate virtual machines, but I get in response "host doesn't support passthrough of host PCI devices" <PotentialUser-45>I did this before, on other distributions, Guix does not support pci forwarding? <bricewge>I never tried that on Guix, but it should. <bricewge>Having a reproducible method to show the issue would help in fixing this <bricewge>I can reproduce it, with vfio but no IOMMU groups <bricewge>PotentialUser-45: Did you configured IOMMU groups correctly? <PotentialUser-45>bricewge: Oh, thanks a lot. I added this "intel_iommu = on" to /boot/grub/grub.cfg, but I don't know how to update grub in Guix, I used to do it with grub-mkconfigc <bricewge>We don't have documentation for what you want to achieve :/ <PotentialUser-45>Do I need to run the "guix system reconfigure" command to update the bootloader?Do I need to run the "guix system reconfigure" command to update the bootloader? <bricewge>You can't just copy what is stated in the Arch wiki, you need to adjust it to Guix <PotentialUser-45>As I understood in the Guix Libre kernel, the Iommu parameter, as an option, you can include either the parameter in grub.cfg, or rebuild the kernel <PotentialUser-45>I know, I went through the documentation about this and had to include a little fancy <cehteh>hehe .. that are my starting woes as well <cehteh>every little thing is done differently and needs to be looked up in the docs <bricewge>Yup, the doc are good in Guix but practical examples are light. The cookbook ought to be larger <dstolfa>bricewge: documentation can always be improved, and i'd like to poke at that, but there are many things around guix i'd like to poke at, i just don't have time :( <cehteh>i think the system should be improved to need less docs :D <dstolfa>cehteh: self-documenting systems and code never work, no matter how descriptive and "simple" it is <cehteh>doesnt need to be self documenting <cehteh>and i intentionally leave out 'simple' .. just say ergonomic <dstolfa>i find it hard to buy any argument for less documentation. there's nothing but benefits in having things explained <dstolfa>you could make the system as approachable as possible, it would still benefit a lot from documentation <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 <dstolfa>it's not quite that syntax, but you can just (define my-openssh-config (openssh-configuration ...)) and use my-openssh-config <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.. <cehteh>copy it into the system closure? <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>but when i say use ~/my_sshd_config (or /etc/ssh/sshd_config) it could just hash that and import it into the store, whats different? <dstolfa>cehteh: the difference is that you need to transfer ~/my_sshd_config outside of your guix system configuration file <cehteh>yes my configuration wont be a single file then <dstolfa>guix isn't only meant for deploying local systems, see `guix deploy` <dstolfa>that means for each system you want to deploy, you would have to first copy over your sshd configuration file manually <cehteh>but some tooling could package the configuration <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 <dstolfa>which is true for any system configuration ever. <dstolfa>you can't just sit down and write composable systemd unit files or debootstrap scripts <cehteh>well when guix could provide the tooling to make this things easier then it would be nicer <cehteh>yes sure, but isnt guix eventually meant to be easier/better .. imo computers are there to do the work, someone just needs to come up once with the code that does it and then everyone benefits <dstolfa>guix is infinitely easier than the alternatives IMO, and i say this as someone who has tens of thousands of yaml for ansible and has managed RHEL, debian, ubuntu and various *BSD systems <dstolfa>things can always be improved, but there's a point where it becomes very hard <cehteh>in some ways it is yes, but it could be even much better <dstolfa>ultimately, if you want to customize guix system configuration in a way a developer hasn't thought of, you're going to have to write some guile <cehteh>also since years i waitong that guix introduces some 'users' layer, aka package installation for all users on a system <dstolfa>i think we can all agree that making computers easier = better, the question is how to get there in a sensible way (and it also doesn't exclude having documentation about everything) <cehteh>because as admin i dont want to log into all users accounts and install some software, nor do i tihnk its a good idea to install them under system <dstolfa>(packages (cons screen %base-packages)) <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 :( <cehteh>i tihnk i talked about 5 years ago or so <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 <MysteriousSilver>Hello! Would it be possible to use a private git repository as a guix channel? <dstolfa>in your channel configuration, you can point it to any git repository, including those on the file system *dstolfa looks for one of his many guix VMs that has this in there... <dstolfa>in (url "...") just, do (url "file:///path/to/git/repo") <dstolfa>i'm not sure, i haven't tried that. maybe there's some documentation on it somewhere <dstolfa>i assume you'd need to put your ssh private key somewhere so that you can access the repository <dstolfa>MysteriousSilver: hmm, if you just add the private channel and have the ssh private key in your home directory in the usual place, does it work? <dstolfa>i'm thinking it might just pick up the key <sneek>irfus, podiki[m] says: Mesa has been updated to 21.1.6 in core-updates-frozen! and now I see mesa-opencl failing, will need to take a look <MysteriousSilver>but since i now know it is possible to specify local file as an URL, i probably wont <podiki[m]>howdy irfus! and I think I fixed the opencl packages too *MysteriousSilver feels ashamed on his lazyness <irfus>podiki[m]: thanks for keeping that going :) <podiki[m]>I annoyed whoever I could find until it was done :) <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>Welcome back muradm, you have 1 message! <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 .. :) <civodul>bricewge: an inferior package cannot be "converted" to a package <civodul>however, it should be possible to have inferior packages as inputs of a package <civodul>(anything "file-like" is accepted as input) <civodul>so... it could be that you found a bug? <bricewge>civodul: I think those bug are known #40272 and #48082 <bricewge>I would like to fix them but I don't know If I could do it <bricewge>Do you have any guidance about how to fix this? From the copyrights it seems you are the only one who have dealt with inferior's code <civodul>lemme know if you need further guidance <civodul>otherwise i'll happily review patches you come up with :-) <bricewge>In which way using goops could help fix this? <pkill9>is there a bad reason to change the current grafts to update the packages and just wait for the world to rebuild then commit to master? <civodul>(i'm not seriously suggesting to use GOOPS, not yet at least :-)) *bricewge was reading the GOOPS tutorial <civodul>with GOOPS we could have method, so <inferior-package> and <package> could have the same superclass, things like that <civodul>but so far we've lived without it, so we'll see <cbaines>pkill9, why are you looking for a bad reason? <pkill9>well, it would be desireable to have as few grafts as possible <pkill9>then it wouldn't list downloadsmultiple times <pkill9>so i wondered if there's a reason not to do this in particular <cbaines>there are processes (like ungrafting packages on staging/core-updates), but they're quite slow at the moment <cbaines>that's not slow in terms of computer time, but just that there's a while between staging or core-updates merges <bricewge>civodul: That change seems massive if it's needed <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 <clemens3>civodul: OK, so seems not so bad.. ok - thanks.. i will look on the site further.. <efraim>can't get glib-networking to pass its tests on core-updates-frozen <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. <efraim>well that certainly sounds a lot like it <iskarian>thorwil, can you verify that all the lilv .so files are empty? (and is this a substitute, and if so, which platform? I was able to pull a working lilv-0.24.10 substitute for x86_64.) <thorwil>iskarian: i have 3 empty *lilv*so* and 6 with 4k in /gnu/store <thorwil>the empty ones have "0.24.10", the others are ... symlinks <thorwil>`sudo guix build --repair lilv` tells me that lilv is corrupt or missing, then "substituting /gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10..." <iskarian>...something is definitely afoot. It's a long shot, but you didn't run out of disk space, did you? <thorwil>it also notes corrupted serd, sord and sratom and fetches substitues for those <thorwil>Generation 4 Aug 01 2021 20:43:59 (current) (...) guix fcba63f (...) commit: fcba63f8b7806493fc5060b267af93cdb7d21aa6 <thorwil>the substitutes came down with 73KiB, 55 KiB ... so definitively not empty. but why do they not take the place of the empty store items? <Rooks>is there a way to change configs quickly? like on boots <iskarian>You might try `guix gc -D /gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10` just to make sure there's not something "sticky" about that directory <thorwil>guix gc: error: cannot delete path `/gnu/store/5q75cw8lnw4kfg9nss5vwkx8pxakk96l-lilv-0.24.10' since it is still alive <iskarian>ah, right, since you have ardour installed <thorwil>i had filesytem corruption woes before, but the symptoms had been different <thorwil> /gnu/store: find -empty | wc -l -> 7956 (ouch) <maximed>"guix gc --check" will check the store for errors <thorwil>guess i have to find out how to boot into initramfs on purpose, then <maximed>"guix gc --help" has a full list of options <thorwil>`guix gc --verify` says: reading the store... checking path existence... <iskarian>(just as confirmation, a `guix time-machine --commit=fcba63 -- build lilv` works correctly for me, after removing lilv from the store) <maximed>There's also "guix gc --verify=repair", maybe it can fix the lilv issue <thorwil>requires root ... and then does nothing <Noisytoot>(although it's called "btrfs check" or "btrfsck") <Noisytoot>on btrfs, you should use btrfs scrub for a lot of uses of fsck on other filesystems <civodul>iskarian: thanks for your feedback on the ld.so cache! <sneek>civodul, you have 1 message! <sneek>civodul, iskarian says: 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 <civodul>i think the added complexity is reasonable (the ld.so cache already existed in glibc, in gremlins.scm was already there on our side) <iskarian>I was thinking more about the extra build phase--are we sure that it will substitute correctly? <civodul>but yeah, how this affects startup times really depends on the hardware <civodul>iskarian: ah sure, it's deterministic <civodul>well, we can double-check :-), but i'd be surprised if it's not <iskarian>What's the complexity of maintaining the patch on glibc look like? It looks fairly self-contained, so it shouldn't be too bad if that file doesn't change often. <civodul>"./pre-inst-env guix build sed --check" says it's ok <civodul>yeah, the patch is self-contained, and the loader doesn't change a lot anyway <civodul>ideally, this could start a discussion to integrate the patch upstream <vagrantc>sunny weather, maybe time to upgrade guix on my pinebook pro with all the spare electrons... *vagrantc hasn't been guixing so much lately <iskarian>I hope so! There's definitely more software that could benefit from it <vagrantc>been meaning to take a stab at the issue with linux-libre sources getting built independently for each of the linux-libre* variants on the substitute servers ... <thorwil>ad i still have 7957 empty objects in /gnu/store <thorwil>well, 7694 after `guix package --delete-generations; guix gc --collect-garbage` <civodul>(i wouldn't normally link to vmware.com but this post looks interesting *and* it mentions Guix ;-)) <jorge[m]>I have 2 errors that do not allow me to use my Guix system, the 2 errors can be seen in an image but it is not received by paste-debian <civodul>vagrantc: i'm skeptical about the idea of "converting" the linux-libre origin to a package just to placate Cuirass <civodul>jorge[m]: me parece que había un problema con la red ("Nombre o servicio desconocido") <muradm>is there "which" call in standard guile? <vagrantc>civodul: it seems like the simplest solution to "each and every linux-libre variant rebuilds the source tarball" problem ... <vagrantc>civodul: which hurts more on aarch64/armhf and other potentially slow platforms <civodul>vagrantc: d'oh, we have that problem? <vagrantc>civodul: if you follow the thread up, i describe it a bit more <civodul>that's because there are no substitutes for intermediate build results like this one, right? *vagrantc tries to redescribe it <vagrantc>if you try to build all the linux-libre variants before the intermediate build derivation is built, they will all simultaneously try to rebuild the source tarball <vagrantc>but since usually they all trigger a build at the same time, ci.guix.gnu.org ends up rebuilding the linux-libre source tarball for each and every linux-libre variant <muradm>civodul: yeah thanks, i though there could be similar in std guile for some script, but yeah (guix build utils) is not of harm as well <civodul>vagrantc: i see, so we (potentially) waste resources on the build farm <vagrantc>so theoretically, they will re-use the intermediate substitute if available, but effectively that doesn't happen <civodul>muradm: in standard Guile you could use 'search-path', which is the more general primitive <vagrantc>i thought there was a bug about this, but i think it only got as far as that thread <muradm>civodul: oh that is too general ))) <vagrantc>oh, but bordeaux.guix.gnu.org has a substitute for linux-libre on aarch64 :) <vagrantc>so maybe having two different substitute server systems is working nicely :) <muradm>i have a question also on shepherd, there is make-forkexec-contructor, which drills to exec-command, and exec-command does setsid <muradm>what is the reason for unconditionally setting setsid <muradm>that makes impossible to run programs from shepherd that require tty <jorge[m]><civodul> "jorge: me parece que había un..." <- Siempre da el mismo mensaje, igual para obtener cualquier paquete y no tengo navegador en Guix por lo que tengo que regresar al os privativo. <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 <jorge[m]><jorge[m]> "En mis prueba e instalado mi sis" <- Puede tener relación con el reloj de hardware y la hora actual del sistema ? <muradm>cehteh (gnu packages wm) i3lock, if you add to your profile or operating system packages it will do the pam thing and work <cehteh>moment i installed i3lock that doesnt unlock <cehteh>but i can try to ass that to the xorg-configuration <vagrantc>most screen lockers need special configuration to make them setuid <vagrantc> (screen-locker-service swaylock "swaylock") <cehteh>guix install i3lock ... i have my own keybind from the i3 config to start it up, that works on other machines <cehteh>i now added (screen-locker-service i3lock "i3lock") .. but that gives (screen-locker-service i3lock "i3lock"): invalid field specifier <muradm>cehteh, put it in your configuration.scm or a like depends how you manage it <muradm>(operating-system ... (packages '(.... i3lock) ...) ... ) <muradm>and (services (append (list (screen-locker-service i3lock "i3lock")) %desktop-services)) <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>huh? those keys dont send udev events <cehteh>i used to handled that with the acpid on debian, but now i see they are translated to x keypresses as well, which makes it possible to handle them in i3 <muradm>cehteh: ps -ef | elogin, most likely you run that, those buttons are handled by elogind-service-type, your may need to (modify-services ....) to customize it <jackhill>civodul: cool, I guess we've made it with the vmware post :) Then the mention bazel, is bazel bootstrappable? <muradm>cehteh: if you disabled elogind explicitly then manual dancing will be required <muradm>by default elogind-service-type is part of %desktop-services <civodul>jackhill: no it's not! :-) but it supports reproducible and "hermetic" (as they call it) builds <cehteh>but i need some config it doesnt do what i want, also no brightness key .. i installed brightnessctl as user, but actually i need to install that suid root <cehteh>muradm: closing the lid on battery goes into suspend, but it does not lock the screen, which is a bit ugly <cehteh>and looking at elogind docs there isnt any screenlock relatated stuff, guess i handle that in the wm as well <muradm>cehteh: yeah somethings need customizations, if you don't want to bother gnome option could be most complete in this sence, things like i3 or sway will require some more effort <cehteh>i dont want to have too mcuh gnome <muradm>cehteh: then more discipline and/or digging is required ) i don't have that feature as well )) <cehteh>well usually i found out that gnome does a lot but often the wrong thing and then finding and configuring that wasnt easy as well or even hardcoded <cehteh>just need to relearn a lot stuff in guix <muradm>if you done, then you are at good point, just port things in guix way <cehteh>and yeah the lid doesnt generate a key event, so how do i get the screen locked when the lid is closed? <atka>write a script or lock it manually is what I do, I don't bother with setting up any of that when using a tiler, brightness suspend etc I just tee to /sys/* <cehteh>well thats not the solution i want, i always had it "lid closed, screen locked" <muradm>cehteh: how didi you it in your debian <cehteh>and screen lock when going insto suspend as well <cehteh>and some bash scripting, figuring out if X is running and starting i3lock there and then when it started going into suspend <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 <cehteh>bricewge: not yet, thanks for the hint <bricewge>This screen locker doesn't have the issue you are talking about <cehteh>usually its not the screenlocker itself but the infrastructure around <cehteh>years ago i uses some vt based locker with some more scripting around, switching to a dedicated vt, disable vt-switching, locking that. that worked pretty well even when X was not started <bricewge>Yes, and xsecurelock take extra steps to avoid such issues <bricewge>xss-lock is to respond to event to X signals and elogind events <cehteh>i try to start with xss-lock starting i3lock <muradm>why (docker-shepherd-service ...) requires elogind? <muradm>gnu/services/docker.scm has no hint on why it is listed in requirements <muradm>cehteh: great, which way did you implement? <cehteh>xss-lock started from i3 config and bind all key events as well there ***Kimapr3 is now known as Kimapr
<the_tubular>hendursaga I wonder if I'm missing something by not trying BSDs 