<jackhill>civodul: thanks for reviewing/applying texlive-qrcode <fnstudio>hi, i'm trying to create a system image that i can then upload to digitalocean and use as a custom image to spin new machines <lechner>nckx: Hi, did we lose the 'knotc' executable with the update to knot 3.1.8 ? <fnstudio>singpolyma: well, i'm interested in understanding how the process work on the guix side more than in any specific vendor... so the answer is no, it doesn't... that said, DO would be a bit more convenient for me as i have an account there already <singpolyma>fnstudio: one option could be a provider that builds VMs from OCI ("docker images") such as fly.io, then use guix system docker stuff <fnstudio>singpolyma: interesting... thanks, definitely something i'll look into <fnstudio>it should be possible to create a qcow image and upload it to at least some hosting providers though, and i wouldn't mind to see how that works too <fnstudio>but not sure whether DO is particularly straightforward... this cloud-init thingy might get a bit in the way <singpolyma>Even my bare metal host sets up most boxes with cloud-init these days <fnstudio>i suppose it should be possible to create a "cloud-init ready" guix image... <fnstudio>by including the necessary client and adding the info in a file... but i'm mostly just thinking out loud here <patched[m]>Can I do a `git clone ...; stow ...` with guix home? <patched[m]>Or even better, clone if non-existent, pull otherwise <lechner>Hi, is libtool part of gnu-build-system, please? How can I find out why 'autoreconf -vfi' failed? Should I use guix environment, or perhaps a profile? Thanks! <lechner>and here is the package definition (the source distribution is still incomplete) http:/ix.io/3ZkA <daviid>lechner: nota guix user, but that is a bash command not founderror <lechner>daviid: thanks! (although i would be surprised if autoreconf was not part of gnu-build-system) <daviid>for some reason, the env that is trying to build your guile-pam instance can't find autoreconf, i think, not sure but ... worth investigate that symptom <sammm>hey - extreme guix newbie here, I wanted to use the service module that has been proposed here https://issues.guix.gnu.org/54561#29. I tried making my own channel and moving the patched modules to it but alas, getting guix pull errors. What's the easiest way to use these patches on my system? <apteryx>sammm: I'd apply the patch to a git checkout of guix, build that following instructions in the manual, then try './pre-inst-env guix system vm your-config.scm' or 'sudo -E guix system reconfigure your-config.scm' if you're brave <apteryx>lechner: autotools are not part of the gnu-build-system currently, because 'make dist' distributions produce a self-hosted configure script that doesn't require it <apteryx>so you only need to add autoconf, automake and whatever other things they use (libtool) when you patch the build system or build from git instead of a dist archive <apteryx>you can sometimes get away with patching the 'configure' file directly, if the change is trivial <lechner>failed to create path for auto-compiled file "/gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/bin/guild" <apteryx>hard to say, the backtrace is truncated <apteryx>perhaps you could try to build it on machine in a './pre-inst-env guix shell -D guile-pam' environment with export COLUMNS=400 <AwesomeAdam54321>It appears that my segfault problem the other day was caused by enabling the Captive Portal setting in IceCat <char[m]>Very interesting: If you remember I was having trouble with compiling guix. I was being told that glibc is unbound and that I should include module (gnu packages base) even though it was alreay included. I moved my code to a different file outside of guix source tree) and everything is working now. <nckx>/gnu/store/q1slac3k4sf6d036np7s191avia5mng8-knot-3.1.8/sbin/knotc <roptat>pashencija[m], thanks for your help yesterday, I managed to boot on the system with linux-libre-arm64-generic :D <fps>damn, having a toddler is detrimental to irc usage :) <tribals>Hi, folks! I'm still trying to solve my some-Clojure-and-Java-packages-are-not-building problem. Seems like here is the reason: <tribals>phase `build' succeeded after 4.1 seconds <tribals>SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". <tribals>SLF4J: Defaulting to no-operation (NOP) logger implementation <tribals>[INFO] Discovered 58 component descriptors(s) <tribals> at org.codehaus.plexus.metadata.merge.AbstractMerger.mergeDescriptors(Unknown Source) <tribals> at org.codehaus.plexus.metadata.DefaultMetadataGenerator.generateDescriptor(Unknown Source) <tribals> at org.codehaus.plexus.metadata.PlexusMetadataGeneratorCli.invokePlexusComponent(Unknown Source) <tribals> at org.codehaus.plexus.tools.cli.AbstractCli.execute(Unknown Source) <tribals> at org.codehaus.plexus.tools.cli.AbstractCli.execute(Unknown Source) <tribals> at org.codehaus.plexus.metadata.PlexusMetadataGeneratorCli.main(Unknown Source) <tribals>error: in phase 'generate-metadata': uncaught exception: <tribals>system-error "open-file" "~A: ~S" ("No such file or directory" "build/classes/META-INF/plexus/components.t.xml") (2) <tribals>Sorry for posting logs, it's very short, though <jpoiret>please use paste.debian.net for long logs <jpoiret>can't help you much with java build systems though, they're a nightmare <tribals>IIUC, most java packages will be built, no one interested in providing substitutes? <lilyp>wtf how many maven-cores even are there? <roptat>tribals, I'll try to look into it <roptat>I think 3, one for maven 3.0, a bootstrap one and the actual maven-core <lilyp>okay, so the bootstrap one builds fine but the actual one fails as far as I can parse CI <tribals>roptat: I'm trying to look at it, too. What do you think is the root cause? <roptat>not sure, maybe the file build/classes/META-INF/plexus/components.t.xml is no longer created after an update? <roptat>iirc it's copied from another location <roptat>ah no, it's generated by the generate-metadata phase <roptat>oh, no it's already failing in that phase, and it's not silent at all <roptat>I think you're right, that's what's failing <roptat>something must have changed and affected java-plexu-component-metadata-1.7 <roptat>oh the last change in java world is from May 22, if the first failure is May 23, that might be the cause <roptat>gnu: java-jdom: Update to 2.0.6.1 [fixes CVE-2021-33813]. <roptat>6068b83b82475566acd4162467bcf54270f338f9 <lilyp>another reminder that hardcoding dependencies is bad :) <lilyp>or wait, did they change their API in the bugfix? <roptat>the file that component-metadata generates worked with jdom 2.0.6, but no longer with jdom 2.0.6.1 <roptat>and component-metadata is deprecated since last month :/ <roptat>so no update to fix the issue from upstream <roptat>and the "drop-in" replacement is not so drop-in for us, iirc it doesn't have a CLI interface that we need at this point <unmatched-paren>move fast and break things, even if you're currently trying to fix things! :P <fnstudio>i've been reading a bit re cloud-init, following some initial attempts at building a guix image that could work with a particular hosting provider <fnstudio>i've gone through the stages: oh this sounds easy, there must be a package for this already; oh wait, no, it's more complicated that i thought; to finally realising that it's something we may not actually want... as also highlighted here https://logs.guix.gnu.org/guix/2016-11-30.log at some point in a convo re EC2 images <roptat>so, maybe it's because SAX_FEATURE_EXTERNAL_ENT is now set by default <roptat>2.0.6.1 is more like a completely new version, the change to set it by default is from almost a year ago <ardon>Hi Guix! I constantly get this error "Channel opening failure: channel 66 error (2) open failed" when invoking `guix remote', although at times re-running the command will make it work. I have a clean SSH config, is there an option that would alleviate this? <roptat>I tried adding builder.setExpandEntities(false) after creating the builder, but that doesn't fix the issue ***IForgiveSpecing is now known as Rampoina
<roptat>oh I think I see what's happening. When I do that it calls the driver with setFeature(..., false) <roptat>and the driver doesn't know the feature <roptat>now the driver should be easy to fix <Haider>Hello!, I got a very (nooby) question. I have mounted my seperate drive in Guix using the file-system field in my Guix operating-system decleration. My user account cannot create files in the mountpoint directory, I probably could use chmod but is there like some sort of property allowing you can do this in Guix system-configuration? <roptat>more unsupported features... I'm afraid there's nothing I can do <roptat>other than using jdom 2.0.6 instead of 2.0.6.1 for maven <jpoiret>char[m]: was it with your own modifications? <jpoiret>gnu/packages/haskell.scm compiles fine in my checkout <char[m]>jpoiret: yes. All I need to add to break it is (display glibc) then make <jpoiret>yes, but that's expected, glibc isn't imported afaik <char[m]>jpoiret: Isn't (gnu packages base) there? <jpoiret>(display glibc) works fine if i just add it at top-level <jpoiret>if you do ./pre-inst-env guix repl and then (@ (gnu packages base) glibc), does it work? <char[m]>jpoiret: That is what is extra strange, it would sometimes work for me too. Usually after some combination of `make` `make -B` `make clean` and maybe a `make make-packages-go`, it would become broken. <jpoiret>if something doesn't work because of ABI changes or whatnot, `make clean-go` -> `make` is the way to go <jpoiret>it's possible you ended up with bogus .go files <fnstudio>i think i've installed every possible glibc-locales package <fnstudio>any ideas on what i might be missing (or misreading from the above doc page)? <fnstudio>the issue was at the host level, somewhat unrelated to guix <fnstudio>there was no locale set in my (host) bash <char[m]>I'm now getting tcc is unbound even though I don't use tcc. <char[m]>It doesn't tell me where tcc is unbound, but the only changes I made where in haskell.scm, so it must be there somehow. <rekado_>this could be a misleading error message you get from cycles. <jpoiret>char[m]: does (@ (gnu packages c) tcc) work in a ./pre-inst-env guix repl? <jpoiret>hmmm, or cycles, i've never experienced those kinds of issues <char[m]>If an issue is possible, it is likey for me to experience it. Sometimes I even experience issues that should not be possible. <char[m]>jpoiret: (@...) did not work: tcc: unbound variable. Same thing with make clean-go make. <char[m]>Is it normal to get a warning with make clean-go? <char[m]>"warning: stray .go files: ./gnu/build/vm.go..." ***Xenguy_ is now known as Xenguy
<roptat>char[m], you can remove stray .go files, except guix/build/po.go (it will be rebuilt, but it's a dependency for translations which can take some time <pashencija[m]>There's a channel with 3rd party software that I want to add to my system <char[m]>roptat: Thanks, but it still doesn't fix the tcc business. <pashencija[m]>After I add it, it guix pull fails with the most clear and understandable error I expected to get <pashencija[m]>Generating package cache for '/gnu/store/1ap5yam5x5qirdpwbwg4gzwhcsr0f75y-profile'... <pashencija[m]>(exception match-error (value "match") (value "no matching pattern") (value "aarch64-linux")) <roptat>char[m], right, it's only a warning <pashencija[m]>So the question is: how to debug it? How to understand what exactly fails guix pull? <pashencija[m]>What happens to guix pull when I add a channel with packages that I have not installed yet? <fnstudio>i seem to have been able to create a guix image which i then uploaded to a hosting provider and used to spin a VPS... pretty amazed and very happy!! i can see many guix servers in my future ahah!! <roptat>pashencija[m], your channel defines something and somewhere it does a match on an architecture that doesn't have a case for aarch64-linux <roptat>I suppose you're running an aarch64 system <pashencija[m]>Do all packages in a channel have to support aarch64 for the channel to be addable? <roptat>pashencija[m], no, but they should not match on the architecture without at least a default case <roptat>you could clone the channel and grep for %current-system or similar variables <roptat>or maybe a match until you find something relevant <roptat>I mean, "grep -r match" and try to find something relevant <roptat>maybe "system" or "target" appear in one of these match <pashencija[m]>Is there more civil way? Like make guix show the package that it cannot process? <roptat>it can't process it, so it can't know about it <roptat>that's a guile issue, not a guix issue <roptat>ok, the translations have not been updating for a month because the server on which I was doing that died <roptat>it's fixed now, so weblate should get more strings soon <civodul>there's a whole bunch of new strings awaiting translation in guix-manual :-) <pashencija[m]><roptat> "it can't process it, so it can't..." <- It least it could have known file that it fails to process... <civodul>we need to spread the translation energy! <roptat>I do have the energy, but I need to translate ~1300 new strings in LFS first :p <pashencija[m]>I could translate to many languages, but unfortunately there's absolutely no time for that <roptat>it's best to translate to your native language only (but it's fine if you really have many native languages :)) <roptat>ah by regexp magic I lowered the burden to 720 strings ^^' <roptat>somehow po4a gave me xml tags to translate <jpoiret>pashencija[m]: could come from `make-signal-release-assets` <civodul>roptat: heh, make sure not to translate Texinfo markup either :-) <jpoiret>since that procedure only works for one system type, that should be reflected in the package's supported-systems field <jpoiret>(the procedure won't be evaluated since inputs are thunked) <civodul>rekado_: a big thanks for all the Python 2 work in Guix-Past <pashencija[m]><jpoiret> "pashencija: could come from `..." <- Thank you! Good catch <fnstudio>AFAIU, guix system image creates an image that is just about the minimum possible size <fnstudio>if i spin a VPS instance using that image and without separately configuring any extra storage device, the file system i end up getting is only around 1.5GB <fnstudio>despite the machine itself being associated to a much larger SSD <fnstudio>how do i create an image that will result in a machine with a larger root partition? is --image-size=20GB the way to go? <nckx>fnstudio: I've not used writable Guix 'images' but yes, that's what it does. <fnstudio>related to this (but probably less related to guix), out of curiosity, now that i've started this machine that has a micro 1.5GB root partition, is there a way to increase the partition size from within the machine? <fnstudio>nckx: amazing, thanks, i'm currently creating the new image, i'll try to upload it to my hosting provider in a min, thanks! <jpoiret>should emacs-next just point to the latest commit or is there a specific policy for its versions? <jpoiret>the current we have breaks emacsclient <fnstudio>pashencija[m]: ah amazing, great stuff, will try that in a sec <fnstudio>pashencija[m]: hm wait, on the live system? <nckx>Probably not. You could resize the partition, possibly reboot, and then resive the root fs, but the 'from within' isn't possible on most file systems. You'll need something like the Gparted live CD to do it off line. <nckx>Or the Guix installer if you're comfortable without GUIs. <fnstudio>pashencija[m]: shouldn't i first unmount the partition? <pashencija[m]>One can also do live resize with gparted. GUI is error-prone <nckx>Last ext* I tried to resize on-line was ext2, didn't work, but I'll trust you. <pashencija[m]>It is important to have backup as it may kill fs if something is done wrong <fnstudio>pashencija[m]: yeah, in my case it's more of a theoretical question, it's just an empty VPS that i just created and ended up having a minuscule root partition <fnstudio>but it's very good to know this can be done <pashencija[m]><jpoiret> "pashencija: could come from `..." <- So how do I entirely disable the package for architectures other than x86_64 without breaking guix pull? <jpoiret>you have to manually specify (supported-systems '("the-only-system-it-builds-on")) <nckx>What they said: supported-systems. <nckx>Overdrives 1000 and Honeycomb Somethings. <char[m]>What is even stranger is this: 1. branch to master, make, no problems. 2. branch to ghc-toolchain, make, no problems!? 3. ~/guix/pre-inst-env guix shell ghc toolchain: tcc unbound, and many other totally unrelated unbount variable errors like googletest and ffmpeg. <jpoiret>hmmmm, usually you want separate worktrees for branches that differ substantially <nckx>pashencija[m]: Quad Cortex A57, 16 Cortex A72, respectively. <jpoiret>otherwise you'll have stale .go files lying around since we don't have a great build script <pashencija[m]><nckx> "pashencija: Quad Cortex A57..." <- Cool! I suppose they even beat m1 macs <char[m]>jpoiret: I would say that they differ very minimally. <civodul>the UI could use some help but if it gets in people will have an incentive to make it better <jpoiret>maybe the Submitting patches part could be made more concise/approachable <civodul>oh, PAM configurable from Guile, sounds fun <civodul>re conciseness, yeah, there's a tension <jpoiret>the "I was unable to test the patch according to the requirements and recommendations listed for this submission." part <civodul>it's this big because every so often, someone would come and say: "looks, this is not stated in the guidelines, we should add it" <civodul>but then of course, at some point it becomes too long and changes are that things get lost <jpoiret>meaning they missed the Change Log part, as well as `guix refresh` <jpoiret>also, aren't MIME attachments more annoying to test than inline ones? <civodul>though inline patches are more likely to be mangled ("format: flowed" etc.) <jpoiret>i'm not sure b4 has mime support is the thing <jpoiret>bah, i can always import the thread and save the mime attachments manually, given that they're far and few in between <singpolyma>civodul: why would git-send-email have format:flowed set? Bad downstream filter? <KarlJoad>Does `guix download` not support git:// URIs? <KarlJoad>Mine does not seem to be liking git://URI for me, and I don't quite understand why. <civodul>singpolyma: "git send-email" is fine, but sometimes people will paste patches in their MUA and the MUA does weird things <civodul>KarlJoad: nope, currently it only supports downloading plain files <KarlJoad>So there is no way for me to update a hash from a git URI through the command line? <jpoiret>ah, it's the odd one that doesn't do `guix build` with the wrong hash to get the right one :) <tribals>I'm experimenting with my own channel. I created GPG key, updated `.guix-authorizations` with that key, then committed just changed `.guix-authorizations` into new "keyring" branch, signed off this commit with that key, ran `guix git authenticate` to verify that everything glued together, and then finally, updated channel's `(keyring-reference ...)` to point to just created "keyring" branch and committed `.guix-channel` (signing it with same key) to my <tribals>channel's main branch (581025b27e). All this worked as expected. Then, I added some new commits (all signed) in new branch, then merged (--no-ff) this branch into my channel's main (0e9b4bce09). Then, I tried to use just created channel in a manifest as an inferior channel, using proper channel introduction which authenticates commits starting from 0e9b4bce09. For some reason, that didn't work with error: commit not signed by an authorized key. Why? <KarlJoad>It's also weird, because I update the master branch of the repo, but not the hash of the build file, and I build the old version of master that the sha256 hash _does_ match. <roptat>tribals, when you merge a branch, you lose signature on commits <tribals>I tried to sign it off explicitly, using `git merge --no-ff --signoff` <tribals>Correction: I used channel with introduction starting from (581025b27e), not (0e9b4bce09) <tribals>*But*, `(channel .. (commit ...))` points to (0e9b4bce09). <jpoiret>KarlJoad: if you don't use file-name in origin that depends on the commit, guix won't try to download the file because it already has a file with that name + hash <jpoiret>you could just falsify the hash temporarily <tribals>I've seen some branches in main guix repo. How commit signing is preserved in, well, guix repo? (then) <jpoiret>about TOFU, you can just do `guix build -S the-package` to check out the downloaded source <roptat>not sure how it works in guix, it's probably resigned? <char[m]>upon a fresh git clone of my ghc-toolchain branch, I still get tcc unbound variable. <roptat>tribals, --signof doesn't sign with gpg, it's just adding "Signed-off-by ...", right? <jpoiret>char[m]: maybe there's a bug with that branch then <KarlJoad>jpoiret: Ahh. I just found an example of file-name. That would do it. Thanks. <tribals>roptat: I may be wrong, my merge-commit is signed, which is confirmed by `git show 0e9b4bce09 --show-signature`. <char[m]>jpoiret: I don't doubt, it but I doubt it has anything to do with tcc. Also the code additions work when in a guix.scm instead of in the source tree, so I'm not sure how to proceed. <roptat>tribals, how about all the intermediate commits? <jpoiret>i don't really understand how you'd make some changes in a guix.scm instead <tribals>roptat: They all signed, too (`--show-signature`) <roptat>ok, then I'm wrong, sorry for the confusion <tribals>Correction: I signed all commits with `--gpg-sign`, not `--signoff` <jpoiret>but that still means they didn't run guix refresh -l on it, no? <jpoiret>your reply is much better than mine though :) <char[m]>jpoiret: It is only additions. I define make-ghc-tooolchain in the guix.scm then the last line is (make-ghc-toolchain ghc) <nckx>True. They did run it in production though, and didn't notice a huge rebuild, so they were aware of the concept and perhaps thought guix rfresh was moot... <nckx>Oh, it's lechner, who's here :) <KarlJoad>How should I go about finding a latex package that I know exists (texlive has it), but I cannot find the package name in guix? the tlmgr info trick does not work because the package name is correct and not part of some larger package. <KarlJoad>One way I can think of is to use a full store path to get back a package name. <civodul>i wonder how other syslogd implementations and journald deal with syncing <KarlJoad>civodul: That is what I have been doing. chngcntr is present in the full texlive, but I cannot find a Guix package that provides it. Using tlmgr info chngcntr returns the package name chngcntr. <KarlJoad>There are other LaTeX packages that have similar issues, like nth. <johnjaye>i was trying to figure out that kernel param you pass in ubuntu for no graphic <unmatched-paren>it's the only distro that uses shepherd, actually. it was originally created for the Hurd <nckx>There is probably no such thing in Guix, johnjaye, unless you mean nomodeset (unlikely). <johnjaye>wait what. so if x or wayland hangs or crashes i'm out of luck? <unmatched-paren>not sure what kind of "no graphics" you mean; that could have multiple meanings <nckx>apteryx: Meeting this Tuesday, yes? <nckx>No ‘graphical.target’, runlevel, etc. <johnjaye>i can't. i've had problems in virtualbox recently with installing debian and it freezes at black screen right before graphical login comes up. <johnjaye>i saw the guix graphical login a minute ago. but now i can't get it back <johnjaye>i think virtualbox should give it a generic card though? <johnjaye>ok i double checked in another vm, it's definitely not letting me switch virtual consoles <unmatched-paren>johnjaye: is it possible to modify a virtualbox disk image outside of the vm? <unmatched-paren>if so, you should modify the /etc/config.scm to remove the gdm service <johnjaye>i see gdm-session-worker and gdm-x-session <unmatched-paren>also you'd need to chroot into the image and `source etc/profile` then run `guix system reconfigure etc/config.scm` to commit the changes <johnjaye>so i guess gdm is the default session manager <johnjaye>i see the rumors about guix being based on scheme were not joking. you have an srfi include in there <johnjaye>(gnu packages wm) (gnu services avahi) (gnu services desktop)... <nckx>Guix is written entirely[*] in Scheme. <nckx>[*]: A bit of C++ remains, because nobody wants to rewrite the daemon… <johnjaye>nckx: as in things i've just heard online. as in, things that are not reliable or inherently trustworthy <nckx>(And the daemon isn't ‘the meat’, it's really quite tiny in the — oh dear, I didn't go here on purpose, promise — grand scheme of Guix.) <johnjaye>i'm quite jaded and cynical as you might guess. today I realized the raspberry pi getting started has 0 information about configuring lxde. worse, the lxde doesn't even have a manual. more of a wiki <unmatched-paren>johnjaye: Guix is configured via scheme code too. All the package definitions are in scheme. The system config I linked to is in scheme. You can configure your dotfiles and user's packages with scheme if you want. <unmatched-paren>the command-line interface is scheme. you can write external scheme programs that call into guix's modules. <johnjaye>well that's why i'm here. so that's good <nckx>Some madperson wrote some package definitions in JS. <unmatched-paren>pretty cool, honestly. there's also an emacs lisp frontend and a third-party python one <nckx>Well I can't very well say ‘yes’ now that I used the m-word, can I? (Yes.) <unmatched-paren>Oh, yeah. Can't forget the brainfuck frontend. The best one, obviously. (it's basically just the example alternative frontend.) <nckx>Re: cynicism: there's plenty to complain about in Guix, so please try not to, we're mostly aware. It's a tiny team and a big undertaking. <nckx>unmatched-paren: The plan is to eventually remove all other front-ends. <nckx>Just go all in for Brainfuck. <unmatched-paren>nckx: absolutely agreed. maintaining the other ones is a waste of the Guile developers' time. <nckx>(Bugs [that] are not complaints are welcome.) <nckx>Brainfuck is NP-complete. <wdkrnls>Dear Guix, my Emacs no longer works because my guix installation has come down with an illness. <unmatched-paren>also apparently the brtfs and the bootloader on the ci server likes to fail <wdkrnls>/home/k/my/system/emacs/bin/emacs: error while loading shared libraries: /gnu/store/4ccp0z06gx7l69yfw5ha6v26ql6hqyh5-gtk+-3.24.30/lib/libgdk-3.so.0: file too short <nckx>wdkrnls: Oh dear, fs corruption. <nckx>wdkrnls: Start with $ sudo guix gc --verify=contents,repair <nckx>You have a 0-length file where a library should be. If there's a substitute still available, Guix will download it and ‘repair’ the missing code. <wdkrnls>nckx: I tried that twice. It didn't seem to do anything. <nckx>Define ‘do’. It should certainly try. <wdkrnls>I saw there was an open bug report about that saying that somehow hard linking was screwing things up. <nckx>johnjaye: I don't think so, isn't systemd younger? <nckx>Making systemd, obviousl, the Red Hat answer to the Shepherd. <nckx>(Didn't check, going to say it anyway.) <johnjaye>right. i meant it's like a rival if you will. <wdkrnls>nckx: I'm looking. I remember it was from late last year and Ludo tagged it as "Important". <nckx>(dmd = old Shepherd name.) <nckx>johnjaye: Just one of many inits. It doesn't aim to compete with systemd in… systemd-ness. It's much smaller in scope. <nckx>It *probably* won't grow a DNS cache, NTP client, … <nckx>wdkrnls: OK. I've always left hard linking on and have never had trouble across many different file systems. Hard links certainly aren't unreliable by definition or anything. <johnjaye>well that's part of the criticism of systemd as i understand <johnjaye>unless it's meant to be a guix only type of thing <roptat>and if that's what you're asking, it wasn't created an a response to systemd, I don't think <nckx>Guix in general isn't anti-systemd. <nckx>We don't have systemd, and this sometimes attracts types who assume we must hate it, but that's not true. <johnjaye>ok. i assume the scheme stuff is very unique though. <johnjaye>so it wouldn't necessarily be something you could transfer to say fedora or ubuntu whole cloth <wdkrnls>Thankfully my memory was enough to figure out the flags which made the search find what I remembered: "severity:important is:open repair" <nckx>Not easily, also because you'd have to backtrack all systemd extensions from the past 10 years. <davidl>johnjaye: in fact, if u look around carefully u will find a systemd guix package :) <wdkrnls>Not that I know this is really my problem. I just know I tried that `guix gc` command and a `guix build` command as well. <nckx><systemd package> It doesn't work, but it's there! <nckx>”I tried the daemon’s `--disable-deduplication` too with same results.” is weird? <nckx>wdkrnls: It wouldn't cause corruption, but it sounds likely that it's why you can't repair. <nckx>Leave some time for others to disagree, but I suggest you delete /gnu/store/.links and immediately try ‘guix gc --verify=contents,repair’ again. <nckx>There's nothing precious in that directory, just… links. <unmatched-paren>johnjaye: i think shepherd, even without guix, is configured using scheme, so it certainly wouldn't be easily translatable to other distros <unmatched-paren>(trivia: Guix System can actually run on the hurd, but it's not a particularly practical system -yet-) <unmatched-paren>whether that "yet" should be struckthrough or not depends on how optimistic you are about the hurd :) <nckx>Heh. Unfortunately, ‘runs on’ is transitive… <nckx>Maybe the Hurd can skip x86_64 and go straight for RISC-V. <tribals>What's confusing me is that `guix git authenticate` finishes without any errors. Authenticating at "manifest" build time doesn't work, though... <wdkrnls>nckx: rm complains about .links being part of a read-only file system. Should I be using some special guix deletion command? <nckx>Oh, no. Just sudo mount -o bind /gnu/store /mnt && sudo rm -rf /mnt/.links or something. <nckx>/gnu/store is bind-mounted read-only over itself. <wdkrnls>LOL, rm complained there were too many links *nckx reboots into Linux 5.18 from 5.13… o7 <wdkrnls>I guess that's what I just have done rm -rf like you said instead of rm .links/* <nckx>(Just mv it out of the way, I guess, wdkrnls. BRB.) <wdkrnls>Yeah, well... I guess I need to figure out how mount works too. It's still complaining that it's read only even with your mount command. <nckx>…well I seem to have introduced a wee off-by-one error in my kernel font but otherwise the upgrade went smoothly \o/ https://www.tobias.gr/htoprot1.png I'll just market it as a security feature. <nckx>wdkrnls: After a reboot, my /gnu/store agrees. I must have remounted it read-write earlier. You can do so with mount -o remount,rw /gnu/store. Which you must never do. Of course. So go ahead. <nckx>unmatched-paren: It has 0 overhead, which I'm pretty sure is unique? …so there's that? <nckx>It was cp437.uni I'd screwed up, not the font. <nckx>Because I know you all care. <jab>I had no idea guix had minetest packaged! <nckx>jab: Explains your worrying productivity. No more! <nckx>unmatched-paren: The original IBM PC one & only. *unmatched-paren notices too late the correlation between "CP437" and "CP/M" <jab>nckx: that's hilarious *unmatched-paren getting basic history mixed up, outrageous <nckx>CP here = code page, no relation. <jab>nckx: I am super close to being done with the opensmtpd configuration...I promise. <nckx>…how old do you think I am? *nckx was not involved in the design or implementation of the original IBM PC. I am innocent, I tell you. <nckx>johnjaye: An open-world sandbox game where you ‘mine’ blocks and build things. Sound familiar? <johnjaye>no i've never heard of anything like that ever in my life. <nckx>roptat: Looks good from here. <roptat>wasn't too sure whether CSS would be there <roptat>for some reason I connect to the old server from inside the network... <jab>roptat: is guix using your guile-netlink ? <jab>cool. That's pretty rad. I guess I am out of the loop <jab>where does guix use it? May I ask? <nckx>What finished? The gc? Is the file still empty? <johnjaye>i'm not sure what i did. but i typed guix install emacs-guix <johnjaye>now it's installing gcc, gnutls, and a lot of things <roptat>johnjaye, maybe you haven't enabled substitute servers? <wdkrnls>The gc command finished and when I try to start emacs it complains that the *gdk* library is too short. <johnjaye>is substitute a synonym for 'binary package'? <wdkrnls>err... libgdk-3 inside of gtk+-3.24.30/lib <civodul>KarlJoad: as the doc mentions, currently Guix only provides a subset of all the packages available in TeX Live <unmatched-paren>johnjaye: well, yes. it's called a substitute because it replaces the result of a local build <unmatched-paren>the output will not differ, unless the package has reproducibility issues <johnjaye>ah. i succesfully located the guix reference manual. that should be helpful <civodul>KarlJoad: i'd recommend trying "guix import texlive chngcntr" & similar to see how much effort it would be to bring those packages <wdkrnls>That is despite 7.8 Mb of data being downloaded to replace the 0 byte version... <unmatched-paren>johnjaye: i think substitutes should be enabled by default on guix system, though. <johnjaye>idk i just installed opened a terminal window and typed 'guix install emacs-guix' <unmatched-paren>and then add `(gnu packages emacs)` to the use-modules in ~/.config/guix/home-configuration.scm, add the `emacs` package to the `packages` list, and `guix home reconfigure ~/.config/guix/home-configuration.scm` <unmatched-paren>then run `sudo guix system reconfigure /etc/config.scm` to upgrade the system, and reboot <unmatched-paren>if something breaks you can roll back in grub, which is really nice to have <unmatched-paren>because of the way guix works, we can do that. traditional distros generally haphazardly replace libc, linux, etc with no way to revert it. in guix a new profile is created, then the current profile's symlink is atomically replaced with the updated profile <johnjaye>thank the gods I was able to install curl at least without problems <unmatched-paren>well, we have wget by default, so at least that curl use case is covered <johnjaye>well i can't really complain as packaging is one of the key points of guix. so i will go read about it. <roptat>if you're on a very old system (like even before 1.3), it's also possible we don't have substitutes anymore <unmatched-paren>the paste output looks normal to me, except for the old system version <johnjaye>is there an analogue of /etc/debian_version? <johnjaye>i thought i downloaded the latest version <unmatched-paren>you done `guix pull && sudo guix system reconfigure /etc/config.scm && guix upgrade` yet? <johnjaye>i just went here and clicked on the first thing i saw. which is what 90% of users are going to do by the way <unmatched-paren>because the disk images are badly named. guix is rolling-release, there isn't really a stable guix version. once you install it you should immediately pull. <johnjaye>by guix pulling i'm updating to the present right <unmatched-paren>because that one is guaranteed to work with installation. the unstable images are uploaded every so often and (iirc) untested <roptat>oh your paste shows you're using substitutes anyway, so forget about what I said <hunger>how can i run ls -lAh in the source directory of a package? <roptat>there's no stable guix distro, even releases are arbitrary commits at a point in time where things seem to be working fine <johnjaye>roptat: i don't know what i'm using. as i said i justed booted the image, opened terminal and typed guix install emacs-guix <unmatched-paren>hunger: or, if the build fails: `guix build ... --keep-failed`, cd to the reported directory, and run that command <johnjaye>ok. it's not like i'm choosing to use it. it's what the site gave me. <roptat>we haven't published anything newer yet <johnjaye>ok. it seems weird to remark that it's old if it's what i'm supposed to have. <roptat>so now you should just run that guix pull and update your system and packages once it's done <johnjaye>like i buy an iphone. then go to the help desk 10 minutes later for a question. and the guy says Wow you're iphone sure is old! <unmatched-paren>*stable* or *unstable* really refers to the stability of the *installation image* and not guix itself <johnjaye>unmatched-paren: does the middle command mean i should type in packages i want? or can i just run the upgrade command after <unmatched-paren>the manual recommends that you guix pull as soon as you boot into the installation <hunger>i was using hello as a base but now im getting that 'foo' unkown package unmatched-paren, and when i was doing that invoke command it gave me a huge error, but tbf i was doing it inside (arguments) <unmatched-paren>it basically evaluates the file you give it, then creates a new system following the operating-system declaration it evaluated to <unmatched-paren>hunger: you'll need to add `#:phases (modify-phases %standard-phases (add-after #| or before if you want |# 'install 'my-fancy-new-phase (lambda () #| code here |#))) inside argument <unmatched-paren>you can access various things like the package's outputs, inputs, etc by replacing the lambda with: <unmatched-paren>(lambda* (#:key inputs outputs #| we want to access package inputs and outputs in this build phase |# #:allow-other-keys) ...) <unmatched-paren>johnjaye: guix system reconfigure is the only way to modify the system-wide environment (e.g. update, add packages, add services...) <unmatched-paren>johnjaye: there's also `guix home`, which provides a user-specific analogue <unmatched-paren>so you can configure your home directory and user packages with scheme code, like you do with `guix system` <unmatched-paren>`guix system` is really just a collection of subcommands that initialize Guix Systems <hunger>ok that seems to have worked, but why do i keep getting the unkown package error? i added "foo" at the end because if i dont i get #unspecified# <unmatched-paren>hunger: can you please put the package and command used to build it on `paste.debian.net`? <unmatched-paren>johnjaye: the advantage of `guix home` is you can replicate your dotfiles and any packages you're using from a single file <unmatched-paren>(or directory, if you split the dotfiles into their own files and use `local-file` to load them like i do) <unmatched-paren>johnjaye: if my computer suddenly dies, all i need to do to replicate my system on the replacement machine is install guix system on it, install git and clone <https://git.sr.ht/~unmatched-paren/conf>, then run `./reconfigure && ./reconfigure system` in the conf directory <unmatched-paren>obviously my code etc will need to be recovered from git.sr.ht, but my setup will be there instantly <foobarxyz>Hi, how is a profile built out of installed packages? I couldn't locate something in the manual <unmatched-paren>which is one of the reasons I recommend using it instead of `guix install`, `guix upgrade`, etc <johnjaye>unmatched-paren: you mean guix specifically or any system where guix is the package manager like debian say? <foobarxyz>is it perhaps a union of all the files found in all installed packages? <unmatched-paren>using a declarative config also allows you to keep track of **exactly** what's on your machine <roptat>foobarxyz, it's a union of all the files from packages that were *explicitely* installed <wdkrnls>guix gc --delete doesn't make any sense. <johnjaye>it sounded to me like you were saying use a certain command if you want to be able to back up your guix config to another distro where guix is just the package manager. as opposed to guix being the OS <unmatched-paren>johnjaye: well, you can use `guix home` on any system, so you could use it to recover your user setup on a debian machine <unmatched-paren>but if you try to use `guix system` on a foreign distro you might get a nasty surprise. <wdkrnls> /gnu/store/z2qzp85a663xvwlmlqq8qkm26gkviws5-gtk+-3.24.30 has a broken libgdk-3 for me. <unmatched-paren>your OS will be effectively transformed into a guix system. if you're lucky :P <johnjaye>ok. i thought you meant guix system would only work on guix installed as an OS <wdkrnls>Which ensures that Emacs and a handful of other GTK programs don't work at all. <roptat>and then try to repair the store with gc <unmatched-paren>johnjaye: `guix system reconfigure` will just replace your bootloader, kernel, init system, etc with guix's ones <wdkrnls>nckx tried to help me repair the store, but we didn't try a fsck. <foobarxyz>roptat: thanks! Is there a guix convention what should go into a package's lib/ and share/ directories (which will end up in the profile as such), or is it up to the package to define how to structure its output files? <wdkrnls>Don't I have to boot from a live usb to do that? <roptat>foobarxyz, it's up to the package, all the files end up in the profile. But remember that only *explicitely* installed packages end up in the profile, not their dependencies <unmatched-paren>i think i've heard it being used to install to VPSes by installing a debian, installing guix on it, and running `guix reconfigure` to turn it into a guix system <unmatched-paren>a guix system is just an OS that is configured using the `guix system` command <roptat>wdkrnls, it might work if you remount your root fs ro <foobarxyz>roptat: I see thanks, this is an important point (wrt *explicitly* installed packages) <roptat>on most distros you would get access to dependencies, not on guix. You only get what you ask for <unmatched-paren>hunger: you don't actually need the (lambda* (#:key ...) ...) stuff. <unmatched-paren>hunger: the reason it's failing is because you're returning a string <wdkrnls>I kind of imagined that would be mount -o remount,ro / <unmatched-paren>you see, guix distinguishes between package objects (like `openjdk-17`) and package specifications (like "openjdk@17") <wdkrnls>unfortunately, it says that mount point is busy. <unmatched-paren>when you do e.g. `guix install openjdk@17", guix looks for a package with the `name` field `openjdk` and a major version of 17 <unmatched-paren>then gets its *package object*, which is assigned to the variable `openjdk-17` <wdkrnls>fuser -v certainly shows a lot of stuff from my current session. <roptat>wdkrnls, mh, then maybe you'll need a live system <wdkrnls>the ubuntu shutdown command has a way to force a fsck on next reboot, does guix have anything like that? I didn't see it in the options for shutdown, but I thought I would ask because maybe its somewhere else. <hunger>ah i see, that was my bsd ass style taking over <wdkrnls>... since I don't have any usb disks handy at the moment... <unmatched-paren>although there IS a guile frontend that allows you to use python-like syntax for scheme <nckx>Hit ‘e’ at the GRUB menu to edit the command line. <nckx>You want fsck.mode=force fsck.repair=yes <wdkrnls>nckx: that sounds promising... so I don't have to edit my config.scm, right? I can just edit GRUB? <unmatched-paren>johnjaye: the reason your guix pull is taking a while is probably that there's been a LOT of commits in guix since 1.3 <johnjaye>well i'll hit the manual. i thought i could just sudo apt-get install emacs and start fiddling with things <unmatched-paren>johnjaye: don't you usually do an apt update && apt upgrade first thing on a brand new debian/ubuntu system anyway? <unmatched-paren>johnjaye: one thing you should be aware of: if you want to try out a package, you can run `guix shell emacs` and that will open a bash where you can test out the packages <unmatched-paren>it's nice for testing things you're not sure about and also for e.g. gcc. you don't need gcc installed all the time, just use a shell to keep your environment clean <johnjaye>unmatched-paren: yes i do but then i just install emacs and go to town <unmatched-paren>the equivalent of `sudo apt update && sudo apt upgrade` is `guix pull && sudo guix system reconfigure /path/to/system/config.scm && guix upgrade` <unmatched-paren>the third command is necessary because guix allows installing packages per-user <johnjaye>sorry to be so brash. but i hate not having emacs <unmatched-paren>johnjaye: you can install those things without upgrading to the latest version, but they'll be a bit outdated :) <nckx>guix install curl or htop or tmux or … <nckx>Then just wait whilst GCC builds et voila. <johnjaye>i ran the command 'guix system reconfigure /etc/config.scm'. it's spitting out warnings about how targets is deprecated use targets instead. cannot determine provenance for the current system. <unmatched-paren>resolving the former requires a small change to your config, to remove the use of a deprecated API <unmatched-paren>so (target "/boot/efi") should be replaced with (targets (list "/boot/efi")) <wdkrnls>well... I couldn't actually figure out where to put "fsck.mode=force fsck.repair=yes". <wdkrnls>I say that there was a GRUB_CMDLINE_LINUX_DEFAULT variable mentioned in a tutorial, but Linux just seemed to ignore it. <nckx>You boot, then at the GRUB menu (where you choose which generation to boot), you press the E key, then add those arguments to the (very long!) command line that starts with ‘linux …’. <wdkrnls>hmm... I tried that first but it said that those arguments weren't recognized. <nckx>Then you added them in a different spot (I can't say more, sorry). They aren't validated. <nckx>You could add wdkrnls=awesome in the right spot & the system would boot fine. <wdkrnls>well, I will take a breath and try to find a spot to try again. <nckx>Ignore the ‘tutorial’, GRUB_CMDLINE_LINUX_DEFAULT is completely irrelevant here, it has to do with a baroque meta-shell-script that Guix doesn't use. <sneek>wdkrnls, you have 1 message! <nckx>Well feel free to ignore that, then :) <nckx>Now… I don't think fsck will actually help any, but who knows. <wdkrnls>I had placed fsck on the initrd line the first time. <wdkrnls>specifically: sudo guix gc --verify=contents,repair <wdkrnls>well... it didn't show any hash issues... unfortunately, emacs and other gtk still don't work. <wdkrnls>I guess I will do another guix pull and upgrade my profiles to see if that helps at all. <nckx>It might sidestep the issue if gtk changed. gtk+@3 being a core-updates package I doubt it, but who knows. <lilyp>did you hose your fs during package builds? <djeis>Is there a utility for making a derived package that extends the list of configure flags? <lilyp>my personal remedy for that is roll-back, deleting the newest generation, gc, then reapplying `guix package' <djeis>Yeah. I like the flags that are already present, I just need to add one along with an extra dep. <wdkrnls>lilyp: that seems to be the working hypothesis... fsck did report that it fixed some errors. <lilyp>alternatively, you can try finding all the store items with size 0 and guix build --repair those (though that's an underapproximation) <wdkrnls>well, I suppose it doesn't hurt try it for the one thing emacs depends on. <unmatched-paren>djeis: (substitute-keyword-arguments OLD-ARGUMENTS ((#:KEY OLD-VAL) NEW-VAL) ...) for each KEY/OLD-VAL/NEW-VAL finds the value of KEY in ARGUMENTS and binds it to OLD-VAL inside the NEW-VAL expression <unmatched-paren>(substitute-keyword-arguments (package-arguments OLD-PACKAGE) ((#:configure-flags old-flags) (cons* "--new-flag" "new-val" old-flags))) <djeis>I need to do some quotation trickery though, I think. <djeis>Because #:configure-flags is actually an expression that evaluates to the list, not the list itself. <djeis>`(cons ... ,flags) should do it. I'd use a gexp but the existing package doesn't and I'm not sure precisely how those'd interact. <wdkrnls>hmm... guix build --repair doesn't report any output... <djeis>I ran into the libvirt package not being built against ceph for rbd support, so I'm hoping it's as simple as adding the dep and configure flag. Here's hoping. <djeis>Sigh... it wasn't able to find librbd. <wdkrnls>I tried `sudo guix build --repair gtk+` and atleast it printed some store output, but it doesn't correspond to the stuff emacs is looking for. <wdkrnls>before that I tried passing it the who /gnu/store/...-gtk+-3.24.30 path, but that didn't report anything. <djeis>Ah the ceph package has a dedicated lib output. <djeis>Yea, got past the configure phase this time. <djeis>Now to try putting this on my server <wdkrnls>from what I read in the guix build info page, it seems like it cannot help me since it doesn't mess with the profile. <wdkrnls>And it's clear that my profile is busted. <nckx>I don't think that's clear. 
