<leoprikler>It would be somewhat more consistent if you were saying something about the physical size or weight of 8GB of data, but putting binary files into /bin is just a convention made up by people.
<link2xt>nckx: k, I sent a patch but didn't see it in HTML archives, guess it is on moderation then
<raghav-gururajan>"Standardization can help maximize compatibility, interoperability, safety, repeatability, or quality."
<leoprikler>link2xt: you get a message once your post has been accepted
<nckx>raghav-gururajan: Your position is ‘standardisation == good’ and that's a very valid position to hold. However, posting Wikipedia links and using ‘standardisation == good’ as an *argument* for that position won't convince anyone. It's ‘x because x’.
<nckx>link2xt: The ‘problem’ is that we (Guix) don't moderate the (GNU) bug tracker. So neither of us can do more than wait.
<raghav-gururajan>nckx I am not sure how to explain in other words. A use of a standard is found within the deifintion of a standard.
<nckx>raghav-gururajan: ‘Standardization can help…’: It can also ruin just as many things. I honestly want to know: how will it help, and what exactly would that standard standardise and how?
<leoprikler>From what I can see, there are already just a few profits of using /gnu inside of guix, those being repeatability and quality (the latter only if you count substitutes).
<nckx>raghav-gururajan: I could say that the Guix standard is documented by the code (that's not a joke: LISP was created to document algorithms on paper, first, then made executable).
<nckx>Anything that wants to be Guix-compatible will have to follow the code, not some standard.md somewhere, anyway.
<raghav-gururajan>nckx Ah yes, I was outlining how standards can be useful and need not be static. For a specfic use cause, of course there needs to be details.
<nckx>You can have the malicious bytecode created with a compiler you love.
<raghav-gururajan>nckx So I upon reboot, sdcard's file-system was automatically mounted under /home/user/sdcard. The permissions of /home/user/sdcard were root as owner and group. I have changed to username as owner and users as group. Will this be conserved across reboot?
<cbaines>sneek: later tell civodul: I spotted those issues with the Guix Data Service, I think the problem is related to the handling of duplicate package definitions (same name and version). There's code in the Guix Data Service to deduplicate the definitions, but I think a lint warning for a duplicate is leading to the error shown.
<apteryx>excuse my ignorance, but how is the information stored in ~/.guix-profile/manifest useful? Shouldn't it keep a list of just package symbols, as well as their provenance (e.g., which Guix commit they originate from)?
<apteryx>OK, the output and version have a use, I can see that
<apteryx>as for the propagated inputs and search paths this seems redundant if we know the provenance
<nckx>apteryx: Both propagated inputs and search paths of all installed packages are needed to create subsequent versions of the profile, potentially for years to come if you never upgrade (a) certain package(s). There's no alternative than to save them along with the profile.
<apteryx>nckx: but all this information is available within and pegged to a Guix commit, no? I mean, it could be simply recomputed (with some processing cost, of course)
<apteryx>ah... mixed Guix version provenance (partial upgrades) could be costly (you'd need to run the search possibly multiple Guix inferiors)
<apteryx>but still feasible. I'm asking, because I'm toying with the idea of extending search paths so that you could run arbitrary, thunked Scheme to do things we can't imagine you'd need to do today (well, I can imagine a few scenarios already useful: special ordering of the paths, filtering, adding an extra separator which has some semantic for some program, etc.)
<apteryx>but having to serialize this (and keep track of its dependencies -- perhaps Gexps should be used?) in a format like what is currently used seems problematic
<nckx>‘Simply recomputed’ and ‘some processing’ are at best misleading, but you probably realised that by now 😉
<nckx>It's also beside the point, since it doesn't actually sound feasible. What would you do with this provenance data?
<nckx>You care about the code, not the deleted git repo it came from a year ago.
<nckx>Serialising locally sounds like the way to do this.
<nckx>Why's it problematic? Assuming extension is something we want (I remember reading about your idea but not all the details), perhaps we could find a solution.
<nckx>As much as I like first-class functions this would be a very powerful can of worms 🙂
<PotentialUser-52>can I user a radeon rx 580 with guix? I see "modprobe.blacklist=radeon" in the installer's grub entry, and booting without modifications gives the error "error in finalization thread: Bad file descriptor"
<nckx>PotentialUser-52: I don't know the answer to your main question (no AMD hardware here), but that blacklist argument is specifically to make the installer work and won't be needed on the final system, and the ‘Bad file descriptor’ is unrelated and harmless (happens to everyone).
<PotentialUser-52>question about the install: if I choose the graphical install... can I disable substitutes before I start the install?
<apteryx>nckx: well, the provenance data would be used to yes, aehem, refetch the repo if it's not locally cached already, rebuild it and use it to recompute the missing data.
<nckx>apteryx: But what if it's gone (not unlikely), moved (certainly not unlikely), or never had a provenance to begin with (~/apteryx/teststuff.tmp/guix)?
<apteryx>my current use of manifest is bound to package -m 'some-manifest.scm' to install the packages within. As far as I can tell, this also dependes on having Guix at the version noted in the provenance properties to rebuild the packages, no?
<PotentialUser-52>I'm at the end of the install... I'll try "exit" to see if it added /etc/config.scm
<PotentialUser-52>nah, can't get out of the installer. exit/abort just routes back to the start. C-c does nothing.
<PotentialUser-52>would be great to edit /etc/config.scm + get a shell before kicking it off :)
<PotentialUser-52>in lieu of that.. is there a way to rebuild after the fact with substitutes? or guix challenge everything (assuming that means what I think it means)?
<apteryx>nckx: I can manifests + guix archives would be the deal to ensure you can reproduce a profile somewhere else in the future
<nckx>apteryx: Yess… but that's user-generated, I don't think you can compare the two. You're telling Guix where to find something that it can't find without your help. OTOH stale ‘provenance’ info (I don't even like using the word here, can you tell :-) in the auto-generated manifest will break guix package -u/-i/… forever.
<nckx>I really don't think the two files are even related apart from the unfortunate choice of ‘manifest’ to label them both.
<apteryx>nckx: Doesn't 'system' manifest need to keep track of 'inputs' as well? Like... the profile wouldn't be complete without those shared libraries, no? It only seems to care about the propagated-inputs.
<apteryx>oh, I guess it already does. It's saving the whole 'bag' to the manifest, I guess.
<nckx>Guix keeps track of inputs as part of its regular operation. It doesn't need a manifest at all to compute the closure (all recursive dependencies) of each installed package.
<nckx>What Guix can't figure out as soon as the ‘package’ object vanishes (and remember, this could be as soon as ‘guix install’ exits it the unusual but legitimate case of ‘guix install -e’) is which inputs were propagated
<nckx>So that does need to be saved ‘out of band’ so to speak.
<apteryx>hmm. Now wondering what makes it interesting to 'know' which inputs were propagated rather than just knowing the union of all involved inputs for a manifest?
<nckx>PotentialUser-52: There have been some bugs reported in the last few days about Edit not working properly and the flow of the installer looping/otherwise not being great. That won't help you now, but it's something.
<nckx>apteryx: That's exactly one of the things I'm too tired to reason about at this hour 😉
<apteryx>hmm... maybe for tracking which dependencies could be removed if I were to remove x package? For the other , non propagated dependencies, perhaps it expects to find the references to other inputs in the binaries themselves (like what 'guix gc' does)?
<PotentialUser-52>nckx: no worries. Glad it's being tracked. is "guix challenge" the best way to verify things going forward? is there a way to just rebuild everything in the store?
<apteryx>nckx: hehe, thanks for entertaining the conversation so far :-)
<nckx>PotentialUser-52: I'm not sure what you mean by ‘rebuild after the fact with substitutes’. Even if you did use substitutes, I guess you could use a ‘guix build --check’ to see if your machine (re)builds the same thing as what you already have. If you're worried about the Thompson attack, well, you probably lost as soon as you downloaded a precompiled ISO 🤷
<nckx>That said, I did install without substitutes from the start for that extra fuzzy feeling of doing a lot more work for dubious benefit. I get it.
<nckx>PotentialUser-52: I don't know exactly how you'd invoke or script ‘guix build --check’ to rebuild (and compare and throw away) everything in the store but it's certainly possible.
<nckx>Your search-path procedure proposal did intrigue me, but also frightens me with its unboundedness.
<nckx>As right as first-class procedures sound at the Scheme level, something about not being purely declarative by the time you write files to disc feels wrong, unguixy, unsafe.
<apteryx>nckx: you mean, it'd open manifests as an attack vector?
<nckx>PotentialUser-52: I was unclear above: guix build --check build a package from scratch and compares it to the one you have in the store (complaining if they don't match), but it will throw away the newer copy, not move it to the store as my wording might have suggested.
<nckx>apteryx: Nothing as dramatic as that (although this has been discussed: we're already at the point where ‘doing the reproducible science‘ with Guix means handing people essentially a programme they must run, with an unauditable web of dependencies).
<nckx>Just that it makes it harder to reason about things once you allow that.
<bla>after exporting both http_proxy and https_proxy, the "guix download" command then success (following redirection and file successfully downloaded)
<efraim>I don't know if there's an easy way to have the daemon inside the VM use a proxy without already having access to the internet, can you proxy the whole VM?
<efraim>ah, looks like you got it with http_proxy and https_proxy
<bla>but the "guix pull" still doesn't work (same "Network is unreachable" error)
<bla>I have also tried to restart the guix-daemon after having exported the http_proxy vars, but the pull still fail
<bla>hey efraim, thanks for your answer, I'll have a look if I can setup something like that
<bla>other point: wouldn't it be possible for Guix project to provide an ISO that is installable offline ? the current ISO is named "install", but it might need to be called "network install", as network is mandatory, and maybe provide an "install" iso which allowss installation without internet access
<efraim>then we'd have to decide what goes on it. The installer is already on the larger side for text-only. We could keep the size down by adding just the sources needed to compile a selected system but even that could be large before deciding what needs to be included and what can be left out.
<bla>I have tried to setup the proxy on VMWare side, but still no success
<bla>anyway, I'm not sure it's applied to VM traffic, or only to traffic from the VMPlayer itself (looking for its updates)
<sneek>civodul, cbaines says: I spotted those issues with the Guix Data Service, I think the problem is related to the handling of duplicate package definitions (same name and version). There's code in the Guix Data Service to deduplicate the definitions, but I think a lint warning for a duplicate is leading to the error shown.
<sneek>civodul, efraim says: on my pine64 $(guix build guix) took 295 minutes, $(guix build guile3.0-guix) took 370 minutes
<potential-alex>Hello! I'm looking at how to get the imagick extension for PHP working in Guix. I can see two approaches:
<potential-alex>1) compile it statically into PHP, but that would require somehow also downloading the imagick source files at php build time. I know it's not possible to add this during the build system — but do we have a way to specify multiple sources? Or otherwise, I suppose, we could make an upstream that combines PHP and imagick? It all feels a bit… not rig
<potential-alex>2) add the extension using phpize & ./configure and friends. This seems doable, but requires that the extension is afterwards added to php.ini. Seems like that would be a service task? perhaps as a parameter to php-fpm service?
<potential-alex>Does anyone have experience with PHP or a hunch on what the best approach here might be?
<NieDzejkob>does guix generate php.ini by itself when you add the php-fpm service?
<NieDzejkob>I'd add an "extensions" field to php-fpm-configuration that would take a list of packages
<potential-alex>It does not — but it does generate a php-fpm configuration file, which afaik, can be used to add php.ini overrides. Should work there, I reckon.
<potential-alex>Yea, I think you might be right with the "extensions field" approach. That'll probably be where I go.
<potential-alex>jonsger: But yes, sounds like we need to think about PHP infrastructure! Gto hear there are a bunch of us thinking about PHP. Fairly sure Julien Lepiller would also have opinions on this…
<NieDzejkob>I'm trying to find all packages that use cmake-build-system and provide .la (libtool) files. I managed to cobble together a shell pipeline and a guile script (https://paste.debian.net/1127133/) to search my /gnu/store, but that only includes packages I have installed, which turns out to not be enough. I also managed to use fold-packages to find all packages that use cmake-build-system (there's 620 of them). How could I get the list of files in a package
<NieDzejkob>in Guile? I'll probably need to download the substitutes for the packages, but I'd rather avoid downloading the dependencies too...
<NieDzejkob>Oh, and I'm doing that because I want to figure out why googletest doesn't install its libgtest.la, even though the sources contain a template, and one of the scripts refers to the file
<bavier>NieDzejkob: I'm not sure, but I think the template la file may be old cruft
<NieDzejkob>(I'm trying to get the tests for MEGAcmd working, but if I fail, I can just do #:tests? #f, I guess)
<bricewge>civodul While you're into the installer I got two crashes but was too lazy to keep the coredumps. One happened when deleting a free space in the partitioner .The other was by unplugging the HDD which made opening the partitioner crashed.
<Parra>ArneBab_: it is difficult, I packaged some thought but they are self contained. In any case if you check node install, the global directory has npm installed with all dependencies recursively installed too, so there must be a way
<leoprikler>Parra: export environment variables in which way? If you need some variable to launch them correctly, wrap-program or wrap-script are probably what you want.
<leoprikler>If you want to access the environment variables inside a running process, then you'll have to use whichever facilities the program provides. If it has none, you'll have to break it first to get some ROP going or whatever.
<nckx>mbakke: I've already answered the remove-store-ref question upthread, it's needlessly ugly for a simple text file. Curious which advantages you think it would it have?
<nckx>Either you look for a /gnu/store/*-profile/etc/profile in the tarball as leoprikler suggests, or if you want something more robust you can probably use -S /etc=etc which will create a ./etc link to that file in the tarball.
<Parra>Include the “local state directory”, /var/guix, in the resulting pack, and notably the /var/guix/profiles/per-user/root/name profile—by default name is guix-profile, which corresponds to ~root/.guix-profile.
<nckx>mbakke: A somewhat circular answer but I don't doubt you. Does it create a prettier backtrace? Anyway, will do when/if I push it.
<NieDzejkob>pkill9: Why? What's the usecase? Are you really changing your global packages that often?
<mbakke>nckx: probably, although I only started religiously following this practice while hacking on guile-git and was uncomfortable calling out to a procedure in the context of a libgit2 C function :P
<pkill9>NieDzejkob: nah, it's just convenience, it wasnt a serious proposal
<janneke>96% -- my system init may just succeed after all...
<vagrantc>janneke: i've been thinking of making a linux-libre-arm64-generic like the linux-libre-arm-generic package ... which might require less fiddling every release to make sure it works on a wide variety of platforms
<vagrantc>there may be a number of kernel config changes needed to get pinebook pro working with mainline linux-libre
<janneke>vagrantc: that would be nice -- main reason for me to get this pinebook pro to get at least somewhat knowledgeable about arm and possibly help or at least complain :-/