<jlicht>upgrading the apt-installed version of the guix-daemon seems to be entirely undocumented right now; If I'm not mistaken, it involves running guix pull as root, and manually patching the apt-installed guix-daemon systemd service definition
<vagrantc>hrm. still seem to have issues with parallel build of make dist
<nckx>vagrantc: I've got too much work lined up but if you're interested, gnu/ci.scm declares all CI jobs. It's not geared at quickly adding "make dist" anywhere, though, it's squarely Scheme-API stuff.
<vagrantc>nckx: i'll glanceat it, thanks for the pointer :)
<vagrantc>seems most similar to the binary-tarball jobs
<nckx>nergal: ‘Is Tor already running?’ Try ‘sudo pkill tor’ or even ‘sudo pkill -9 tor’, then ‘sudo herd enable tor’ and ‘sudo herd restart tor’. There's something off about how Shepherd keeps track of processes, and sometimes… it doesn't?
<nergal>i am maintaining a few 4 year old hp laserjet that behave like that
<nckx>Here the machine/firmware freezes if you print a duplex job with a blank page in it, but that's a CUPS/hplip/cups-filter regression because it used to work. And this baby doesn't download exciting new firmware from trusted HP® servers.
<nergal>it was well accepted that the quality of hardware distributed to developing nations far understamp those of developed nations
<nckx>It still has a centronix port, maybe you need to connect that to you router…
<nergal>keep telling them to "beware the cloud" here. cf, university of kyoto 77TB data loss.
<asdf-uiop>There isn't a way to search for binary names generated by a package at the moment, right? I searched for 'xdg-open' and found only 'snap' and 'go-github-com-skratchdot-open-golang'. Since 'snap' requires 'xdg-tools', it was pretty easy to figure out where to find 'xdg-open', but it proably isn't always that easy to guess. Couldn't 'build' collect the outputs of a derivation as metadata for 'search'?
<jpoiret>ennoausberlin: there is no `guix pull` option to do that (yet). I've been meaning to add it but haven't had the time to
<jpoiret>but yes, you'll need a local checkout as bricewge said
<jpoiret>it'd be great to have a guix pull option for that, as people would test new patchsets more easily I reckon
<jpoiret>or even a `guix pull --with-patchset=NNNNvX` which would fetch the mbox from mimu
<jpoiret>i think Xinglu's `guix review` script does something similar
<bricewge>ennoausberlin: Basiclaly `git clone`, `./bootstrap`, `./configure`, `make` and then you can use the built binary with`./pre-inst-env guix`. But you'll need to adjust these commands with options explained in the manual
<ennoausberlin>bricewge So I checkout the git then apply the patch then compile it. The last step would be to run guix system reconfigure with the freshly build guix binary. Is this correct?
<tex_milan>Hello Guix! I am trying to package ocamlfuse. It needs camlidl, it gets it in its inputs, but compilation fails as it can't find camlidl headers. The headers are in output of camlidl package. Any idea what to try?
<abrenon>tex_milan: hmmm not really, I've had similar issues in the past and never really understood why
<abrenon>I don't see why it should be in the propagated-inputs if it's a regular compilation, but have you tried that ? (I don't expect it to work, but in case it does, that would be some additional information)
<jpoiret>jacereda: tbh I think software devs are the most qualified people to actually package their own code, but welp
<jacereda>jpoiret: I think they should package at least for one distribution, others will follow and can get hints from the original package. And in the case of emacs packages, I think publishing on *elpa is a must
<jpoiret>yes, that's also what I think! Given that the dev is a Guix user, I think packaging it for Guix would be the best "official" packaging method, but I may be biased
<sash-kan>p.s. it is very difficult to search for files without something like apt-file.
<mfg>Why isn't autoconf in the environemnt created with `guix shell --pure -D guile'? guile is using the gnu-build-system, so i would expect autotools to be present, right?
<bricewge>sash-kan: Yes, it is known; I just had the same conversation with asdf-uiop 2 hours ago here
<bricewge>mfg: Because the package is using a tarball which contains additional artifact than the git repository
<mfg>ah i see, i'll have to add the missing bits manually then :) thx
<bricewge>It's the case with many packages, it's kind of annoying. And it's frown upon to update packages to use a git repository if it already use a tarball (there are some discussion in the ML about that).
<asdf-uiop>Have there been any thoughts about 'guix pull' options to only update a certain channel? I have tried to create a file with only my local channel, but it requires the 'guix' channel. My next try at a workaround will be copying the current commit from 'guix describe' and pinning it to that. An option to do this natively with 'guix pull' would really ease the process of creating and linting packages for newbies like me who hav
<florhizome[m]>How can I run a build from a locally defined package that already has a substitute in my store again?
<asdf-uiop>I finished packaging Screamer (https://nikodemus.github.io/screamer). (require 'screamer) works fine when I run it inside a shell generated by 'guix shell rlwrap sbcl sbcl-screamer', but I have no idea how to access it in my regular system.
<viivien>It’s not about creating the lock file, the question is wether we can lock it if it exists
<viivien>gnoo, then you can inherit the package and rewrite its inputs
<gnoo>but that will only work for a few packages, right? i want to ignore a popular package and rewriting inputs of alot of packages seems hard work :')
<bricewge>I still don't fully understand thunked records. `operating-service-user-services` is a thunked field, can I use `(operating-system-kernel this-operating-system)` in a service record for example?
<singpolyma>gnoo: if you remove an input, presumably the packages will mostly fail to build.
<gnoo>i'm not building anything, i want the equivalent of 'apt remove -f foo' 'pacman -dd -R foo' but for the whole system
<singpolyma>Packages may reference other packages, but there is not "runtime dependency" metadata
<gnoo>singpolyma: thanks, i read native-inputs and inputs in guix manual and it's a little more clear. i guess there is no way to say 'this package needs foo for running but not for compiling'. and to blacklist a package, i will probably need to make a new package and graft it?
<gnoo>(sadly i don't know how to do those, yet, i'll try again next time after learning scheme)
<sash-kan>and which package contains `asn1_compile` program? `git grep asn1_compile` didn't help: there is one mention of heimdall, but this package, as far as i can see, does not contain `asn1_compile`.
<mfg>well, accoridng to ubuntus packages it is part of heimdall, but heimdall kerberos5 not heimdall the flashing tool
<mfg>in guix heimdall is the name of the flashing tool
<florhizome[m]><singpolyma> "Packages may reference other..." <- well you have propagated inputs which will put the bin directory into path and activate the needed search–paths for the respective package, right?
<jpoiret>gnoo, AwesomeAdam54321: ~/.cache/guix/checkouts/ is only used as a cache directory for git checkouts, nothing more.
<jpoiret>package definitions are part of the guix source code, which on `guix pull` is first downloaded to that cache directory, and then built in the store and added to a new guix profile, then symlinked to ~/.config/guix/current/
<jpoiret>basically, when you `guix pull`, you build the latest available guix source code, and make it your default `guix` profile
<jpoiret>if you want to consult a package definition, you can simply use `guix edit PACKAGE-NAME` which will fire up your $EDITOR with the relevant source file
<jpoiret>(and you'll notice that the source file is in the store, hence read-only)
<gnoo>jpoiret: thanks, i wrongly assumed ~/.cache stores the current definition which will be evaluated everytime it is needed
<unmatched-paren>hello guix, i'm having problems with linking libwayland-client; my code compiles, but when i run it the dynamic linker claims that libwayland-client.so.0 does not exist. i presume this is something to do with guix because i can't find anything on the internet about this
<unmatched-paren>i'm not using meson or cmake, just a custom ./build script (but it does the same thing when i manually run gcc)
<unmatched-paren>hm, when i do the same thing with meson it works... i guess i'll use meson then
<aru>Hi, is guix able to deal with it if I configured my / to be tmpfs?
<rekado_>Kolev: the server board? I think we’ve done just that.
<grokkingStuff>Hi there! Is there a place where I could request for a package to be added to guix? I tried to install calculix but i couldn't and I'm not sure how to install such a complicated package properly.
<grokkingStuff>I could help provide necessary information about the installation, if it would help!
<lfam>I've noticed a lot of confusion on this subject here and on the mailing lists
<lfam>It's somewhat suprising, because it always seemed quite clear to me since I got interested in Guix. But I think that part of the problem is that my introduction to Guix was watching an "intro to Guix" video by civodul from that era, maybe 2015 through 2017. Those videos provide the high-level overview of how Guix works that is harder to find in the manual, unless you are going to read the manual straight through
<lfam>I think it's really important to find one of these old intro videos and present it more prominently
<lfam>I think these videos gave a lot of us old-timers an easy and clear introduction to Guix that is lacking for newcomers
<lfam>I'm also searching the FOSDEM archives but it would be great to find that 2015 video
<aru>does anyone have an example of what to put into config.scm if I have lvm on luks? Just to be double sure things will get opened in the right order
<lfam>We should get a nice example and put it in the Cookbook
<lfam>I watched the 2015 FOSDEM talk "The Emacs of Distros" and I don't think it's the right video for this. It's not enough of a "how Guix works" overview. It's also suprising how much has changed since that time... who else remembers `deco`? :)
<lfam>I wonder if anyone else agrees with my assessment of the problem. That is, there are a lot of new Guix users who don't understand the basics of Guix / functional package management
<drakonis>i think working on the cookbook would help
<drakonis>the biggest difficulty is with how they envision using it
<drakonis>guix's overarching goals are incredibly laudable
<bricewge>For sure working an the cookbook will help, but it doesn't attract a lot of people. Just look at the copyright header
<lfam>The recent discussion describes that people don't want to contribute to the cookbook or participate in the development process. Which is fine; we need a way to keep those users and eventually some of them will start contributing
<Ribby>I heard repositories are just for compressed package updates/upgrades. It wouldn't be compiling. I really like the cmake/make compiling program. I can't say about the other compressed package file formats. I can do .zip via GUI. Not sure about the terminal/TUI yet. Not sure about .tar. I think a tar in a tar might be problematic.
<Ribby>I believe that at least communication and feedback would be necessary. A focus study with a sample set of users, is a smart way to go about before marketing.
<lfam>The confusion about profiles is really interesting to me bricewge. I guess it's hard for me to relate to because profiles are *why* I was attracted to Guix. It's not clear why you would choose Guix otherwise :)
<ngz>I agree, but that's not emphasized in the documentation.
<lfam>Well, it is in the packagement management chapter. We could add the word "default" in the right place
<lfam>There's another important point of confusion that I'm noticing often. People don't necessarily understand that Guix captures the entire dependency graph of a package. I see a lot of people trying to fix problems by garbage collecting and rebuilding
<nckx>lfam: I'd rather not, if we're discussing this.
<mala>a not entirely unrelated question: I've turned off substitution and am offloading my builds to my remote server. But my remote server is erroring out because it's going to find substitutions to build its packages! Is this a bug, or an option I'm not setting?