<raghavgururajan>My apologies. I usually do separate git worktrees to avoid pushing unintended commits. This time was I a bit lazy and it bit me back. <projectmoon>so i've got `(use-modules (gnu) (gnu packages linux))` up top, and then `(kernel-loadable-modules (list librem-ec-acpi-linux-module))`. it says unbound variable, and asks me if i'm missing a use-modules <projectmoon>i based my kernel-loadable-modules off the example in the documentation <nckx>That sounds like your Guix is still out of date. Does the command above now print the right guix? If it does, what does ‘guix show librem-ec-acpi-linux-module’ print? <projectmoon>`command -v guix` points to /run/current-system/profile/bin/guix <nckx>Did you run ‘guix pull’? <nckx>Guix isn't designed to run that way and it can cause root-owned files in your ~ leading to seemingly strange permission errors. How often doesn't matter. <nckx>🦇 sudo guix pull: not even once 💀 <sbp>couldn't guix pull detect that and warn, or even abort? <nckx>sbp: It should, shouldn't it. <sbp>I had a converse problem today when I accidentally did a guix system reconfigure today as user, which meant it built many derivations but then failed to write the new state to the root owned directory right at the end <sbp>I wondered why it didn't warn that I wasn't running privileged <nckx>How do you reliably detect that? I think everyone's too scared to breaks somebody's legitimate workflow, or else I don't know why everyone's so shy to fix it (including me). <nckx>The discussion always peters out. <sbp>I suppose in the case of sudo guix pull it should be a warning <sbp>in the case of guix system reconfigure as user, I think that should abort early <sbp>and require an extra flag if the user really does want to do it without privileges <nckx>But guix system reconfigure as user is harmless and easily (and quickly, because 0 rebuilds) rectified if you meant to sudo it. <nckx>Yes, I've done that deliberately before, although admittedly I could have done so by passing a --no-really flag too. <sbp>oh, I wonder what happened to me then - I didn't have zero rebuilds <sbp>it took ages to rebuild when I did it again with sudo <projectmoon>next semi-petty question... gnome tap to click on trackpad: does guix have it? don't see in the mouse options <nckx>If you didn't pull in the meantime or edit your configuration that is unexpected. <sbp>trying to recall... I didn't think I did, but that would make more sense wouldn't it <nckx>projectmoon: Which mouse options? <nckx>Tap to click works fine here in sway (with ‘tap enabled’, indeed). <Guest80>Hi guys! Did anyone try to install guixSD on raspberry pi 4? <nckx>projectmoon: GNOME doesn't support tapping on X11…? <projectmoon>pretty sure that's not going to work. raspberry pis use a ton of random proprietary components for maximum cheapness <projectmoon>nckx: it does, or did. but the interaction with synaptics, libinput, x11, wayland, all very confusing <projectmoon>i guess if you plugged enough usb dongles into a raspberry pi it might run <sbp>Guest80: there's a patch set somewhere, sec <Guest80>Every time it fails to build guix or the libre kernel. I am doing it in raspbian to prepare the image for the full install <Guest80>How do you think, would a non-guix work? <pkill9>anyone got pipewire working? can't play anything through it, things just stay unplayed <pkill9>hmm might need to update installed vesion <projectmoon>well that didn't last long. librem 14 shit itself and won't turn on <projectmoon>A+ experience with this computer, especially the part where i waited 10 months to get it <nckx>There was someone at FOSDEM with a (probably older) Librem that wouldn't turn on. I think it was rekado…? <projectmoon>it refused to fully boot. not sure wtf it was doing. logo didn't even show up ***iskarian is now known as Guest427
<nckx>Anger disperses ESD. Known fact. <Guest80>How do you think guix on mnt reform would work? <sbp>Guest80: I asked the two people I know to be working on it the same question recently. one had not received their Reform yet, and the other had only just received it a few days ago and hadn't got round to working on it yet! <projectmoon>how can i append to the service list and then also remove a service at the same time? <projectmoon>and i have the basic service thingy with append on it <projectmoon>yeah i looked at that, but it's not the exact same setup i have. i have (services (append (list ...) %desktop-services))) <projectmoon>so i'm trying to understand where, or if, modify-services fits in there <projectmoon>because mostly i just get massive amounts of syntax errors <nckx>You'd substitute ‘%desktop-services’ with all of ‘(modify-services %desktop-services…)’. <nckx>Your snippet above has one ) more than ( but that was probably just in pasting. <projectmoon>it would be easier to paste what i have from the actual computer, but my network is also simultaneously having some massive routing fart, and i can't connect to the irc server without vpning to the US <projectmoon>so modify-services takes the %collection-of-services and returns the modified %collection-of-services i guess? <nckx>It's really just (x + (s - y)). <projectmoon>by adding sddm-service-type and removing gdm-service-type, it's telling me xorg-server is provided more than once o_O <projectmoon>hmm must have been something with set-xorg-configuration <nckx>Greetings, mysterious stranger. <tekakutli>can you define services if you are using guix on a foreign distro? <Aurora_v_kosmose>Unless you're running sheperd on that distro, I suspect that won't work. <Aurora_v_kosmose>I don't know if sheperd (sp?) can be run as a simple service manager atop another pid0 program. <tekakutli>hmm thanks yea that was what I expected but I had to ask maybe someone surprised me <newjuice[m]>What type of sandboxing does guixsd have or can have? <apteryx>it's also able to produce VM images you can run easily with QEMU (guix system vm) <PotentialUser-40>Any idea why Mesa is at v20 and not yet v21 (and current version is 6 months old)? Didn't see any open issues, activity on help list, commits in core-updates.... <PotentialUser-40>I know it is a bit of a beast in its package def, but needed for newer AMD hardware <PotentialUser-40>irfus you had some messages before about mesa 21, did a patch get sent? (didn't see it) <newjuice[m]><tekakutli "namespaces"> Name space? Where could I read on that? <newjuice[m]><apteryx "it's also able to produce VM ima"> Interesting ***jfred_ is now known as jfred
<efraim>nckx: apparently you're having a bad day, gnuradio from sources patch had some extra bits sneak in from shells.scm <irfus>PotentialUser-40: no patch yet, I didn't find the time to test the build completely in core-updates yet <irfus>but I am using it on my own system <apteryx>arg. I keep getting guix build: error: corrupt input while restoring archive from #<closed: file 7f436e162380> <irfus>there was a patch already for an updated mesa (not the latest though) so I kind of slacked off on it <apteryx>or guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet. <PotentialUser-40>irfus: if it builds and some dependent packages build, I think that should be good to at least have the patch on the patch mailing list, then others can try (I would test building, for instance) <PotentialUser-40>esp since core-updates will take a while, gives time to test and keep bumping version as needed until a merge maybe? <irfus>building from local guix checkout, I ran into the 'possibly undefined macro" error that is mentioned in the manual. I tried modifying $ACLOCAL_PATH as suggested, but that didn't help. <irfus>ah nvm, I'm an idiot for not simply using `guix environment guix` -_- <wirez>can whatever main browser guix runs be declaratively configured too? like which search engine it has, color theme, cookie rules etc <irfus>wirez: wouldn't that vary from browser to browser? idk any way to set a declarative configuration for, say, chromium on any platform <irfus>something like qutebrowser or nyxt, I suppose it should be possible <wirez>with nixos home manager you can use a .nix file to configure your ~ programs and most of their settings <wirez>then that generates the appropriate config for each program <irfus>something similar has indeed been upstreamed recently (guix home) <wirez>so i can use that to configure browser? <irfus>but, I'm curious: how does nix home let you declare a configuration for icecat/firefox <wirez>irfus: i don't think it does. seems like every(?) browser is user hostile and keeps their settings in a black box <irfus>not every browser, checkout nyxt for example <newjuice[m]>Qutebrowser and Nyxt are quite interesting projects. <jak_wolf>I also found Nomad, which uses Guile for configs, it does look very immature compared to Nyxt though <jak_wolf>I think in fact Nyxt just implemented a Guix interface <jak_wolf>for managing packages, not it's own configuruation <MysteriousSilver>Hello! Any idea how to make (geiser-edit-symbol-at-point) work in emacs while writing packages? <wirez>cool idea jak_wolf, for a browser to extend the same guix/guile system of declarative config to the user that can list extensions and anything else <wirez>then guix home will make sure browser is set up like that <wirez>i wonder how guix handles modular configs. like take this for example, lutris game launcher config lists a game to install, and its config. well that game config should be usable on its own if the game is installed directly to the system, like if a linux version is released <jak_wolf> wirez I thought it was too when I found out about Nomad, I'm just starting to learn guile though, so I'll have to work up to trying to make Nomad usable for me <jak_wolf>Hmm.. I think it literally handles it as modules, so in your example, there would be individual modules for individual games, then the lutris module would simply import those modules, or they could be included in a manifest or config file directly. I'm still learning so it's just me spitballing. I want to and get into tropin's rde project, since I thought that shows the most promise for those sorts of things <rekado_>projectmoon: my Librem 13v2 came with a broken RAM module. We arranged to swap it at FOSDEM. But even after that was fixed I had tons of problems with the laptop. <rekado_>it’s not currently in use, because the display won’t work while booting. <projectmoon>also, my problems last night with the laptop not turning on seem to be more related to guix than the hardware itself. <projectmoon>or more accurately, something lower level that is installed (or not installed) by guix <projectmoon>or maybe because i didn't have a swap partition? i don't really know <projectmoon>can't tell without figuring out what was actually happening to the laptop <rekado_>I never had problems getting into GRUB. <rekado_>it would seemingly freeze once Linux took over, but it later turned out that the graphics just wouldn’t update at all until I had fully booted. <rekado_>(I had a disk password for which no prompt was displayed, so I didn’t realize it.) <projectmoon>yeah, it wasn't getting to grub. at least not visually <projectmoon>it would happen after suspending the laptop. then even hard reset by holding power button wouldn't do it <projectmoon>would take multiple tries until it finally turned on properly. <projectmoon>since putting pureOS back on it, no issues. but i've only tested it a limited amount of times. <projectmoon>since i don't really want to use debian, next stop on the distro train is gentoo <projectmoon>another thing i didn't think of trying was a different kernel in guix <irfus>I've run into another issue while trying to build an updated mesa with a local checkout of core-updates <irfus>mesa requires updating libdrm, which I did and it builds successfully. However the mesa build itself fails at the configure stage <projectmoon>the graphical partitioner doesn't create swap by default, right? <irfus>relevant portion of the log ^ <irfus>since libdrm builds successfully, I'm not sure why this is happening or how to fix it. Can anybody take a look and tell me how to proceed? <civodul>we're still bitten by random texlive-* package build failures on core-updates :-/ <irfus>I'm trying to build in an environment started with `guix environment guix mesa libdrm --pure --ad-hoc help2man git` <civodul>irfus: hi! note that this command gives you the development environment *of* guix, mesa, and libdrm (the union of all three) <irfus>so, when inside the above environment, when I run: `./pre-inst-env guix build mesa`, how can I ensure that it finds the correct version of libdrm that is needed? <irfus>I also ran: `./pre-inst-env guix build libdrm` which successfully builds that <civodul>irfus: to get a development environment for Guix itself, all you need is "guix environment guix --pure --ad-hoc help2man git" <civodul>then, "./pre-inst-env guix build mesa" will build mesa as specified in the package definitions <civodul>you can check its dependency graph, the libdrm version used, etc., for instance with "./pre-inst-env guix graph mesa | xdot -" <irfus>civodul: that correctly shows libdrm@2.4.106 as the needed dependency. I updated the libdrm package definition to that version and committed that <irfus>but the build configure fails <civodul>ah well, perhaps mesa needs to be updated as well? <irfus>I did, that's what I'm testing the build of <irfus>all of this builds fine on my actual system (where the package definitions are in a local channel) <civodul>ok, so you must be testing something different somehow <efraim>irfus: Does libdrm_intel.pc on core-updates have in Libs -lpciaccess? <efraim>cat $(./pre-inst-env guix build libdrm)/lib/pkgconfig/libdrm_intel.pc <efraim>if it's not there then you might need to move libpciaccess to propagated-inputs in libdrm <efraim>ah, it's there in requires.private <efraim>move it to propagated-inputs and add a comment above it that it's in Requires.private <irfus>okay, will do. What does that mean, though? <efraim>I think in Debian terms it means it needs the -dev dependency for building, but it doesn't actually link to it. In our case it means it needs to be propagated since programs which link against libdrm also need libpciaccess's headers <irfus>efraim: so that worked, onto the next (hopefully not) error! :) <maximed>"guix --help" is properly translated, but "./pre-inst-env guix --help" isn't. Any ideas? <civodul>maximed: hi! yes, that's because the bindtextdomain call refers to the installed .mo directory <irfus>I think I found a bug in the existing mesa definition in core-updates, but I'm not confident enough that my understanding is correct. Can somebody confirm? <irfus>^ in lines 6 and 7, I believe the first "bin" ought to be "out" <irfus>as it stands, that phase fails because the mesa out dir has no subdirectory 'bin'. Changing both those instances to "out" fixes this. <irfus>the comment also seems to confirm that interpretation. ***wielaard is now known as mjw
<irfus>apart from this, I got mesa, mesa-utils, and mesa-opencl all to build correctly. Is that enough to send in a patch for this? <irfus>or should I build some more dependent packages to make sure it's all good? <rekado_>civodul: could you show me an example of a randomly failing build? <maximed>civodul: makes sense. Is there a way to test the translations, before installation? <maximed>I suppose I could do something like "./configure --localstatedir=/var --prefix=$PWD/installation" though && make install" though ... <maximed>irfus: please verify the binaries went into the "bin" directory of the "bin" output <maximed>How odd that no binaries were installed in the directory "bin" of the "out" output before split-output though ... <maximed>Maybe 'split-outputs' has become superfluous, and can be removed? I dunno <civodul>(you can run "guix build /gnu/store/p5qr1pm20cjf529mayllqd049prv67rj-texlive-latex-amsmath-54632.drv") <civodul>it downloads the .drv, checks what it depends on, downloads its dependencies, and so on <irfus>maximed: there were no binaries (only the .empty file that was created in that snippet). I believe older revisions of this package did not have the split-outputs phase <rekado_>amsmath builds on my laptop. So my uneducated guess is that this too might be related to file order. <rekado_>hmm, I have — again — a problem with consistency on my cluster installation <rekado_>guix build --no-grafts --check /gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv returns the three outputs of gnutls, but only one of them actually exists in /gnu <rekado_>when I build it I see this: grafting '/gnu/store/199npi1hcv7zn0r19vl29np6ccshii4p-gnutls-3.6.16-debug' -> '/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug'... <rekado_>guix gc --verify=contents tells me that it disappeared <rekado_>path `/gnu/store/2vjql2vd6srqxhr0r9xnhclqgc5kxlh1-gnutls-3.6.16-debug' disappeared, removing from database... <rekado_>path `/gnu/store/ads39f4czri8s1k43qd0qpxi6dr3w0zn-gnutls-3.6.16-doc' disappeared, removing from database... <rekado_>and after that “guix build” creates the missing locations <rekado_>back to latex: the derivation fails on our cluster installation <rekado_>now we just need to figure out what differs between my laptop and this VM <rekado_>it fails randomly at different points in the build <rekado_>we have a couple of invocations of luatex, and sometimes it fails on amsbsy.ins, some other times on amsopn.ins <rekado_>there’s always some mention of “size” being wrong <rekado_>so to me this looks like something deeper in texlive-bin <civodul>rekado_: to me that looks like double-free or similar <civodul>clearly TeX should be rewritten in Rust <dstolfa>i appreciate the work that you're putting in with texlive, given that i can't finish my dissertation without it <civodul>ouch, that's a huge responsibility on our shoulders :-) <dstolfa>heh, i can always just boot debian if things go REALLY south <leoprikler>why does your thesis depend on Texlive 2021 tho? <dstolfa>leoprikler: it doesn't, but if things break it won't compile :D <ngz>dstolfa: try tectonic, that's in guix ;) <civodul>rekado_: i tried "valgrind luatex ..." on master, where the problem also exists, but unfortunately that doesn't give any useful hint <dstolfa>ngz: hrm, it struggles with xits-regular font. sad :( <sbp>at first I figured I could use (recursive? #t) in git-reference, but that doesn't get the submodules <civodul>sbp: hi! (recursive? #t) should definitely get submodule <sbp>the makefile in ly copies a .github file to .gitmodules and then invokes some git commands manually. first I tried using (invoke "make" "github") to get it to do that <dstolfa>ngz: i'll definitely use it for anything it can build though, seems much nicer <sbp>civodul: I think it's doing more than just submodule resolution sadly <sbp>I mean I think the package is doing more, during the make github phase <civodul>sbp: ah, so you'll have to arrange to do that beforehand <civodul>since the build environment doesn't have network access <sbp>I didn't realise this, thanks! <rekado_>oh, I didn’t know we have the same problem on the master branch <civodul>seems to be less acute though (fails less often) <dstolfa>texlive seems like a nightmare to update and maintain <sbp>I looked into using (snippet ...) to prepare the ly package, but all of the examples of snippet that I found on the web were just very simple file deletions or moving things about etc., not doing submodule resolution or anything using invoke <sbp>so then I thought maybe it would be better to package all of the submodules as separate guix packages, because they are separate packages intended for separate distribution really. it's just that the author is using submodules for dependency resolution; we wouldn't do that in guix, we'd use native guix methods <sbp>however, the submodule resolution is embedded deep even in the dependencies. for example, in the argoat dependency there's a call during the regular "make" invocation to @git submodule update --init --recursive <sbp>therefore it doesn't seem to be possible to package, at least with my current (very shallow) level of knowledge. I'd have to rewrite the makefiles <sbp>also, I was wondering about not having network access during the build phase. if the justification is "well it wouldn't be pure functional if we could have io side effects like networking", why does it matter as long as the hash of the output is as expected? <sbp>in other words, currently you have to give the hash of the input. but if you just did the whole build process and then took the hash of the output and compared that to what's recorded in the package definition, it'd be safe <sbp>so I don't really understand why the sandboxing is necessary. maybe it is optional and building can be done imperatively and I just haven't found any examples or read it in any documentation so far <sbp>(well, it's always imperative. I mean with side effects like networking) <roptat>sbp, when we give the hash of the output in advance, it's called a fixed-output derivation <rekado_>civodul: looks good! I mean bad. That’s good! <roptat>a fixed-output derivation has network access, because it doesn't matter how it's built, as long as the result is exactly as expected <roptat>that's used with sources for instance: it doesn't matter that the source comes from a given URL, the ci build farm, a mirror, or whatever <civodul>rekado_: what's the canonical upstream repo for this code? we should check whether a fix has landed in the meantime <roptat>the issue is that packages are not fixed-output derivation: you don't know in advance what you're gonna get when you build the package <roptat>when you get the source, you can set recursive? #t in the git-reference, that might help <roptat>well, as long as all the submodules are pinned to a given revision, otherwise it's not deterministic <roptat>you can also use an origin object as an input <sbp>roptat: thanks very much, I'll look into fixed-output derivations now that I know the terminology. I did try recursive? #t first of all, but it didn't work. I think the problem is that the upstream author calls the .gitmodules file .github originally and renames it to .gitmodules during the make process <sbp>which could only happen after git-fetching, whereas recursive? is a parameter to the fetch <rekado_>but since 2020.0 there have been three more releases. <sbp>yeah, it's a very non-standard package <roptat>you probably want to fix the Makefile though <roptat>either with a patch, or in a phase with substitute* <rekado_>civodul: perhaps we should switch to 2021.3 on core-updates <sbp>I would do, but the author has structured their code so that it's distributed across several of their own submodules, each of which uses the same .github renaming mechanism, and then may call other such dependencies <dstolfa>when is the next merge to master for all of this stuff? <sbp>so it's a massive tree of this sort of thing, which means I'd need to patch every single one <roptat>you could have a macro/function to do that for you <sbp>beyond my present abilities. this is my first guix package <sbp>I'll probably try smaller things first <roptat>looks like you didn't choose the easiest package ^^' <sbp>"it's a simple TUI display manager! how hard could it be!" <roptat>I don't think there's an easy way to make a fixed-output package anyway <civodul>rekado_: hmm what's the svn command to fetch that? :-) <civodul>ah found it: svn checkout svn://tug.org/texlive/tags/texlive-2020.0/Master/source <civodul>an svn repo that contains tarballs, hmm <rekado_>ad the tarball it contains is … older? than the one we’re using. <civodul>the lualang.c file in there is different, but the diff doesn't reveal an obvious double-free kind of fix <civodul>so, is there someone we can talk to in luatex land? <mfg>what license shall i pick for the license field if the project contains many components with different licenses? do i have to just specify all of them? <dstolfa>mfg: usually you just specify the license of the project itself, and you disable the incompatible licenses at compile time (e.g. 4-clause bsd) *dstolfa notices a possible typo <sbp>it's a bit simpler, written in go. I realised I had to use the go-build-system <sbp>which I managed to package as go-github-com-msteinert-pam.scm and it builds successfully <sbp>now the problem that I'm having is that I want to use it in native-inputs in emptty.scm <sbp>as ("go-github-com-msteinert-pam" ,go-github-com-msteinert-pam) <sbp>but I wouldn't be able to do that until go-github-com-msteinert-pam is upstream <sbp>oh yeah, probably input since it's used at runtime? <sbp>fixed that. same sort of problem though: I'm not sure how to refer to go-github-com-msteinert-pam for testing purposes. in files using go-build-system that I've seen online they actually define large modules where all the dependencies are side-by-side <sbp>I wouldn't be able to test with guix build -f SCM then though <roptat>the scm file can return more than one object <roptat>you can use define to define the package, and at the end of the file, you can add something like (list go-github-com-msteinert-pam ...) <roptat>and in the dependent, you can use the variable you defined <sbp>I just catted the files together and put (define go-github-com-msteinert-pam ...) around the go-github-com-msteinert-pam package definition for now. gave me a brand new error to work on <sbp>ah yes, thanks. that's exactly how I've done it <sbp>victory over entropy <sbp>thinking about it, I should probably contribute it to gnu/packages/display-managers.scm anyway <mfg>does the license field distinguish between gpl2 and gpl2+? <nckx>mfg: ‘grep define guix/licences.scm’ for a rough list. <nckx>Doesn't give you the variable names you crave, though. <nckx>(Also took ~7s to start here, is that normal?) <nckx>I feel like I'd use more native tooling over my rag-tag collection of faster bash scripts if I didn't have to ask that a lot. *nckx considers a ‘morning’ nap — TTYL. <mjw>civodul, that is on ppc64le only? <mjw>civodul, which gcc has that lua library been build with? <mjw>asking because there were some string optimizations on powerpc that confused valgrind memcheck a lot. So much that the gcc hackers decided to optimize those string functions differently so that valgrind memcheck could proof them correct. <civodul>and Valgrind is doing great, as always :-) <civodul>nckx: there's an initial cost (a few seconds) for all things M-x guix, but then it's quick <civodul>the first time it starts the REPL and collects the list of packages or something <mjw>civodul, OK, on x86_64 valgrind often is fairly accurate. If it complains about something there is a good chance it is right. <boeg>Does network manager in guix (network-manager-service-type?) have support for dispatcher scripts? <boeg>civodul: dunno, i tried looking in the manual, which is not always very revealing so afterwards i asked here <boeg>network manager normally does <boeg>but since its guix, i cannot just do it the normal way, i believe <civodul>well if it's not mentioned there, the probably network-manager-service-type doesn't support it out of the box <civodul>but i've never used that feature, so i can't really help <civodul>it may be that it'd be quite easy to add to network-manager-service-type <boeg>the network manager dispatcher functionality entails placing a file at a specific location and then file will then be executed by network manager when it determines its time. <boeg>so i need to place a file in a location that on "normal" systems is /etc/Networkmanager/dispatcher.d - however one cannot do that in guix just normally, right? <maximed>depends on where NetworkManager is configured to look I guess <boeg>could be it is configured to look in a "static" location i gues <boeg>ill see if i can find the source code and check <maximed>FWIW, /etc/NetworkManager does not refer to /gnu/store on my system <maximed>It only has configurations of network connections <maximed>(made outside guix service mechanism) <civodul>and it's configured with "--sysconfdir=/etc" <civodul>so chances are that it's like a normal system <boeg>yeah, ill give it a try then <civodul>but we should work to make it abnormal, so you can declare those scripts in the OS config <PotentialUser-40>irfus: happy to test your mesa update patches (before you submit them if you like, or else point me to the patch # when you do). Looking to move to guixsd and a more recent mesa will be needed for me I think <maximed>Add a, say, 'dispatchers' field to network-manager-configuration or something <boeg>civodul: indeed - right now ill place the contents there from the OS config <PotentialUser-40>I have a guix environment on my current system, was already submitting some patches and trying to add packages, so should be easy for me to test yours <maximed>which would be a list of file-like objects? <boeg>maximed: indeed - see here <maximed>which Guix would assemble into a directory (in the store) with 'directory-union'? <maximed>and at activation (or service start?), create a symlink from /etc/NetworkManager/dispatcher.d to that directory <boeg>maximed: also seems like there is a network-dispatcher service normally that needs to be running for this to be work <boeg>at least, that is what i get from googling, and is possibly why this is not working for me <ixmpp>How do i get debug symbols[] <ixmpp>Derivation has no debug output <ixmpp>Ah cool, --with-debug-info. The one time im happy to accept a command line based answer :p <ixmpp>This is much smarter than the nix way ngl <mekeor>is it possible to run "guix pull --use-latest-with-binary-substitutes" or something like that? i.e. is it possible to tell guix-pull it should pull those package channels and package definitions which have a binary substitute? or something similar which drastically reduces the compilation required, especially for slow, small hardware? <mekeor>that would be really useful. because IIRC, i had problems with my little (proprietary) single-board computer, running "guix pull", because of it's small memory :( <nckx>You could try to hack something together, either with bash spaghetti & guix-weather, or even directly in your channels file. It's just a script after all. <nckx>It will speed up only ‘guix pull’ but that's (partially) what you want. <nckx>All actual packages are still best-effort, although you should be finding more substitutes for packages merely by pulling a slightly older Guix. <nckx>(It's not new, I just thought it did more at first.) <mekeor>nckx: that sounds awesome. so the compilation of package definitions is one part. the other part is the actual compilation of packages. and for that second part, `guix weather PACKAGE` is my friend. that's super awesome :) <mekeor>and for the first part, channel-with-substitutes-available is my friend :) <nckx>Yep. It's still all very manual (some day…) but it's a toolkit you can use today. <HiddenKarma>Hello, when making a Guix package that uses gnu-build-system, is it normal to use the autotools package and import autoconf/automake in the SCM file? I thought it was already included with the gnu-build-system <roptat>the gnu-build-system was designed to work with tarballs that already have a configure script. you'd need the autotools only to generate the configure script, which happens when you clone a repository instead of unpacking a tarball <roptat>so yeah, it's normal, although using a pre-generated configure script is a bit weird when one of the goals is bootstrapping <mekeor>HiddenKarma: e.g. some software released on github, only requires you to run autoconf, when you git-clone the repository. when you use the release-tarball, it in my experience already includes the generated configure-script. <HiddenKarma>The configure script needs 3 auxiliary files: missing, install-sh, compile. So I thought using a bootstrap would trim down what needs to be downloaded <HiddenKarma>by removing configure script and just having bootstrap script and configure.ac <nckx>Bootstraps normally do the opposite. You build more stuff, so you need more stuff. <mekeor>HiddenKarma: isn't the meaning of "bootstrap" "generate a configure-script so that i only need to run ./configure && make && make install"? <nckx>We seem to be gravitating towards from-git bootstrappability over using the upstream-blessed tarball (it used to be the other way round). I think when a significant number of packages do so auto{conf,make} might become implicit. Maybe libtool. Maybe pkg-config? Where do you stop. <mekeor>so build-systems come with default inputs, right? <mekeor>why not just define an bootstrapped-gnu-build-system? :D <nckx>I'd rather bootstrapping become the default. <nckx>Oh, that's what you mean. <nckx>gnu- with autoconf; bootstrapped- without? <HiddenKarma>nckx: Right so there's a difference between building from tarball (generated by make dist -> ./configure) and from git repo (./bootstrap -> ./configure) <mekeor>idk, idc, but i guess it's better for packages to have exactly fitting inputs, instead of having redundant inputs <nckx>Or is ‘bootstrapped-’ the one that bootstraps? 😛 This is ambiguous. <nckx>mekeor: It's a tradeoff. I don't think one is ‘better’. <maximed>I'd do "gnu-build-system: with autotools as implicit inputs, and does autoreconf", and add a #:autotools? #t/#f and #:implicit-autotools-inputs? #t/#f <maximed>#:implicit-autotools-inputs?: should autoconf, automake, ... be added as (native-)inputs? <maximed>#:autotools?: should I run "autoreconf", even if "./configure" already exists? <maximed>it avoids the ‘bootstrapping’ ambiguity at least <nckx>should autoconf, automake, ... be added as (native-)inputs? → There's a field for that ☺ <maximed>What about: let gnu-build-system detect if ./configure is generated by autoconf. If it is, run ./bootstrap, "autoreconf", etc as appropriate, to regenerate "./configure". <maximed>Also allow disabling this behaviour on a per-package basis when this would cause cycles <maximed>(e.g. in (gnu packages commencement) maybe?)) <mekeor>i think it's important to keep the inputs minimal and the logic simple. thus, i think gnu-build-system is fine as is. :D <mekeor>it's not that exhausting to add autoconf, automake and libtool manually <apteryx>maximed: re the 'guix pack -f deb' patches, is i586 a real arch or just something used in the context of the Hurd? <apteryx>seems like a real architecture; from the Internet: "i586 is the same as a pentium and amd k1" <nckx>My first machine was a 5(x)86, of course it's a real architecture 😛 <maximed>apteryx: i386, i486, i586 and i686 are a family of (mostly?) backwards-compatible architectures <nckx>To be clear: I meant to suggest adding auto{conf,make} in some future *because all our packages bootstrap properly*, not just because it's mildly convenient. I think the real issue is that gnu-build-system is two things: the GNU (autoconf) build system and a good template for anything that roughly follows the sane [configxx &&] make && make install steps. Adding autotools to all of those would indeed be overkill. <maximed>nckx: what about an ‘autotools-build-system’? <nckx>Something like that yeah. Remove the dual use. <maximed>autotools-build-system = gnu-build-system + implicit autotools inputs + run ./bootstrap or "autoreconf" <nckx>I'm pretty sure there's stuff using the gnu-build-system that doesn't use the C compiler so don't let's bum all this too hard. <maximed>Would gnu-build-system still have to do ./bootstrap when ./configure doesn't exist? I.e. (?), is there any project using a "./bootstrap" script without the autotools? <maximed>keeping the old behaviour of gnu-build-system seems harmless though, and less likely to accidentally create roblems <nckx>What do you mean by ./bootstrap? IME it's not very common. ./autogen.sh is much more common, and we often don't run those because they're ofter hand-written, unconditionally run ./configure, and just wrap ‘autoreconf -vfi’ anyway. <maximed>though maybe print a warning if the configure script seems to be generated by "autoconf", advising people to add "autoconf" & friends <nckx>I'm jaded about build-time warnings. <maximed>nckx: ./bootstrap, ./autogen.sh, ./autogen, whatever. They are all alternative spellings to me <nckx>Just wanted to make sure we were on the same page. <nckx>For all I knew there's some different boostrap-vs-autogen.sh convention out there. <maximed>What about a tip, instead of a warning: ‘tip: for maximal ‘build-from-source’ points [TODO proper wording], add "autoconf" & friends to native-inputs"? <nckx>Hehe, yeah, maybe. For now I'll put my effort into actually modify more packages to ‘bootstrap’ from Git. <raghavgururajan>leoprikler: I used your @pattern@ suggestion in v2 of #49238. Looks good? <leoprikler>I think there are some cases in which you repeat yourself <leoprikler>how is "video_player_format=${YTFZF_PLAYER_FORMAT-${video_player_format-@mpv@ --ytdl-format=}}" parsed for instance? <leoprikler>similarly what does dep_ck do, do we even need it? <boeg>what are the terms i need to use to search for icon themes to install so that applications that uses system icons has some icons to use? <boeg>why are duckduckgo so bad at searching for guix packages <apteryx>boeg: I reckon you don't have Guix installed yet? <boeg>i do but i was in my browser when i needed it, so i just used duckduckgo to search for the guix packages <boeg>apteryx: guix search immidiately gave me what i was looking for though <apteryx>OK. You'll probably have more luck with 'guix search' <roptat>I suppose guix is not that famous yet :) <boeg>is there some website some where that has a great frontend for the guix packages? <boeg>i just remember i ran across a thirdparty one at one time <apteryx>it should be doable to add a search, but nobody has bothered yet <apteryx>it'd be a great feature to attract potential users, IMO. <sbp>being able to search packages that contain filenames would be rather useful too <sbp>currently trying to track down a bug(?) where guix weather says that a substitute is available for a package, but when I guix package -i it, it goes to build it instead <sbp>guix-install in scripts/install.scm just seems to call (guix-package* opts) ultimately, but it's not clear how it sets the "-i" there. the code for guix-package* in scripts/package.scm is then extremely opaque to me however <boeg>Hmm, anybody know what i need to do other than install an icon theme and then and app that uses it to have icons appear? There are no icons in transmission and thunar <sbp>I suppose the action, -i etc., must be set in opts, and then there's both (set-build-options-from-command-line (%store) opts) and (process-actions (%store) opts). let's have a look at both of those... <tricon>b boeg: I wonder what happens when you install an icon theme: guix package -i tango-icon-theme <sbp>the former just calls store-lift (it's in scripts/build.scm), and the latter is defined in scripts/package.scm still and looks like where things happen <boeg>tricon: well I just installed papirus-icon-theme and even rebooted, no luck <sbp>guess that manifest-transaction-install in the let* is the salient one there <sbp>seems like it builds up a <manifest-transaction> record, defined in profiles.scm, and then processes the whole transaction <sbp>which makes manifest-perform-transaction the leading candidate to inspect next <sbp>defined in profiles.scm, and for install it calls manifest-transaction-install <raghavgururajan>leoprikler: IIUC, foo_bar=${YTFZF_foo_bar-${foo_bar-@xyz@ --ytdl-format=}} is used when the app doesn't find conf file in ~/.config/ytfzf/conf.sh set by user. But if there is a config file and there is the line foo_bar=xyz, then the app uses dep_ck to get the location of xyz program. <sbp>I can't actually see where that's defined, so I'm guessing it's some magic Schemeism relating to records somehow. unless I missed something obvious... double checking <sbp>well, profiles.scm says it exports it so it must be defined therein <sbp>ah yeah, define-record-type* surely creates the function when making the record <raghavgururajan>boeg: IIRC, you need hicolor-icon-theme and dconf, along with foo-icon-theme (your choice of icon theme). <sbp>but that means it's probably just a record field getter, and not something that actually does the action. got to backtrack <sbp>oh, I see, it's a metagetter. you call it on the transaction and then that *returns* a getter <sbp>or... no maybe just a getter. not sure <sbp>next best candidate is build-and-use-profile, which is called at the bottom of process-actions in scripts/package.scm <sbp>still defined in package.scm. this creates a prof-drv using profile-derivation, and then runs build-derivations on it; seems like we're on the right track <sbp>build-derivations is defined in derivations.scm: "Build DERIVATIONS, a list of <derivation> or <derivation-input> objects, .drv file names, or derivation/output pairs, using the specified MODE." <sbp>not 100% sure what's going on in there, but the main purpose of the function seems to be to depolymorphise itself by getting a filename from each of the different types of items that it takes, and then passing it along to the presumably monomorphic build-things function <boeg>raghavgururajan: alright, thanks <sbp>build-things is defined in store.scm. really getting somewhere now: "an element of THING can be a derivation/output name pair, in which case the daemon will attempt to substitute just the requested output of the derivation" <sbp>quite puzzling how this works, but it seems that (build store things mode) is most likely the important part, where build was earlier defined in let as (operation (build-things (string-list things) (integer mode)). it's strange that build-things is calling itself recursively here; I don't understand it <sbp>operation is a define-syntax macro in store.scm. it's doing some RPC to the store, which means this is not going to be easy to follow <sbp>okay, well, we can at least look at the operation types. (write-int (operation-id name) buffered) is what's being sent to the store server through RPC to identify the kind of operation <sbp>this is a bit confusing though, because the operation kinds are very low level and granular. for example, has-substitutes? is operation-id 3. (for some reason there is no operation-id 2, and several others are missing like 17. presumably they were once allocated, then deprecated and subsequently removed?) <sbp>whereas you'd expect this to be much higher level, like "build this derivation" <sbp>oh, there's a (build-things 9) <sbp>there must be a handler for this in the server then. next step is to locate it! <nckx><several others are missing like> This is old old Nix stuff. <nckx>guix.gnu.org is a static site. *civodul enjoyed reading sbp's investigation log :-) <nckx>boeg: Er, wtf, wrong link. <nckx>That was the dynamic searchy one IIRC. <sbp>civodul: ah, thank you so much! I was looking through all the Scheme files for it, I didn't even think to check in nix-daemon because I figured it was some nix compatibility code or something. ha <nckx>No, it's still very much the actual daemon. <nckx>The daemon is C++ and whoever ports it to Scheme gets a free beer equivalent. <sbp>thanks for the note about the missing codes too, nckx. that should have tipped me off. there's even a guix-daemon.cc file, I don't know how I missed that <sbp>currently at LocalStore::buildPaths in nix/libstore/build.cc, but I'll have to save a bookmark there because it's getting late in my tz and my brain has already had a lot of guix thrown into it today <civodul>nckx: ah, it was stuck; "sudo herd start hpcguix-web" on bayfront and it's back now :-)