IRC channel logs


back to list of logs

<lechner>roptat: thanks!
<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
<fnstudio>it seems that cloud-init (or similar) is required... and i'm not sure how to have that included and configured as part of my image
<lechner>nckx: Hi, did we lose the 'knotc' executable with the update to knot 3.1.8 ?
<singpolyma>fnstudio: does it need to be DO specifically?
<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, 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
<fnstudio>i see some mention of cloud-init from last year but that doesn't seem to bring to any immediate solution
<fnstudio>ok, there seems to be something... here although it seems pretty complicated... definitely not a one-liner!
<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>Here is the error:
<lechner>and here is the package definition (the source distribution is still incomplete) http:/
<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 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
<sammm>thanks apteryx
<apteryx>you're welcome
<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>apteryx: thanks!
<lechner>What's missing now, please?
<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>lechner: <knotc> …no?
<roptat>pashencija[m], thanks for your help yesterday, I managed to boot on the system with linux-libre-arm64-generic :D
<jpoiret>char[m]: what file was that in?
<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>starting phase `generate-metadata'
<tribals>SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
<tribals>SLF4J: Defaulting to no-operation (NOP) logger implementation
<tribals>SLF4J: See for further details.
<tribals>[INFO] Discovered 58 component descriptors(s)
<tribals>Problem executing command line.
<tribals>Error stacktrace:
<tribals> Invalid input descriptor for merge: /tmp/plexus-metadata5180157864129530136xml --> feature not supported for SAX driver org.codehaus.plexus.metadata.merge.Driver
<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 Source)
<tribals> at 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 for long logs
<jpoiret>or any other paste site
<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?
<tribals>Here is it:
<lilyp>wtf how many maven-cores even are there?
<lilyp>any case, there seems to be a new CI failure as of May 27th
<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
<lilyp>hope that helps
<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>it probably failed silently
<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 [fixes CVE-2021-33813].
<roptat>yep, reverting the patch worked
<roptat>component-metadata gets an exception when it tries to use the new version of jdom, and it fails here:
<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
<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
<lilyp>it do be like that
<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 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> is more like a completely new version, the change to set it by default is from almost a year ago
<roptat>not sure why it's broken though
<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?
<ardon>s/guix remote/guix deploy/
<char[m]>jpoiret: haskell.scm
<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 for maven
<roptat>Haider, I don't think so
<Haider>That's fine, thanks!
<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
<jpoiret>hence the warning
<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>maybe make -B isn't the best idea
<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
<char[m]>What about make make-packages-go?
<roptat>tribals, found a fix!
<tribals>roptat: Wow! What's one?
<fnstudio>hey i've this guix that i've installed on a debian VPS via apt install guix; i've followed in order to solve the glibc-locales issue, i.e. the hint message that gets displayed after any guix command
<fnstudio>however i keep getting the notification
<fnstudio>my GUIX_LOCPATH is correctly configured
<fnstudio>i think i've installed every possible glibc-locales package
<fnstudio>i've re-started the guix daemon too
<fnstudio>any ideas on what i might be missing (or misreading from the above doc page)?
<fnstudio>ohhh got it
<fnstudio>the issue was at the host level, somewhat unrelated to guix
<fnstudio>there was no locale set in my (host) bash
<fnstudio>this did it: export LC_ALL=en_US.UTF-8
<char[m]>jpoiret: Using just make seems to have helped some. I can't quite tell because I have changed my code a bit since then. Here is my fork:
<char[m]>I'm now getting tcc is unbound even though I don't use tcc.
<jpoiret>in what file?
<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>if not, `make clean-go` and `make`
<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?
<jpoiret>wdym a warning with clean-go?
<jpoiret>about stale .go files?
<char[m]>"warning: stray .go files: ./gnu/build/vm.go..."
***Xenguy_ is now known as Xenguy
<tribals>roptat: Thanks!
<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]>(repl-version 0 1 1)
<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!!
<pashencija[m]>The channel is ``
<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?
<pashencija[m]>roptat: Of course I do. Always!
<roptat>pashencija[m], no, but they should not match on the architecture without at least a default case
<pashencija[m]>How to I debug what package it is?
<pashencija[m]>It has a lot of packages!
<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]>I can grep against x86_64
<pashencija[m]>Is there more civil way? Like make guix show the package that it cannot process?
<roptat>oh yes good idea
<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 :-)
<roptat>I'm too busy though :/
<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
<pashencija[m]>It looks like aarch64 is more important at the moment
<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`
<jpoiret>in messengers.scm
<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)
<roptat>civodul, of course not
<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>ok, that wasn't phrased very clearly...
<fnstudio>i've been using guix system image against a system configuration vaguely along the lines of this one:
<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>Ehlo Guix.
<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!
<pashencija[m]>Yes! fdisk and resize2fs should save you
<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
<pashencija[m]>That's exactly how I do it on raspberry
<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.
<pashencija[m]>It's possible on ext2/3/4
<nckx>Or the Guix installer if you're comfortable without GUIs.
<pashencija[m]>I mean online resize of /
<fnstudio>pashencija[m]: shouldn't i first unmount the partition?
<pashencija[m]>Live resize is possible
<fnstudio>oh ok, cool
<fnstudio>super, let me see
<nckx>pashencija[m]: Nice.
<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]>Raspbian, for example, does it automatically
<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.
<pashencija[m]>Thank you!
<pashencija[m]>What kind of arm boards are used for arm substitutes?
<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>thoughts on adding the system explorer in Guix proper?
<jpoiret>civodul: looks great!
<civodul>ok :-)
<civodul>i guess i could look into that then
<civodul>the UI could use some help but if it gets in people will have an incentive to make it better
<jpoiret> is worrying
<jpoiret>maybe the Submitting patches part could be made more concise/approachable
<civodul>oh, PAM configurable from Guile, sounds fun
<civodul>jpoiret: what do you find worrying?
<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>so we keep adding stuff
<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>to me, from Gnus, it's the same
<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?
<tribals>It's me again ^_^
<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 :)
<KarlJoad>Got it. TOFU it is.
<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`.
<tribals>I may be wrong, but ...
<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>Any idea what's wrong?
<tribals>Correction: I signed all commits with `--gpg-sign`, not `--signoff`
<nckx> jpoiret: It's a bit boilerplatey (see too) but I didn't see it as worrying. More as 'I don't want to speculate on what this could break'.
<jpoiret>hmmmm, right
<jpoiret>but that still means they didn't run guix refresh -l on it, no?
<jpoiret>your reply is much better than mine though :)
<nckx>Meh, just longer 🐱
<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 :)
<civodul>3 system test regressions on 'staging' compared to 'master':
<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>KarlJoad: check out
*civodul found out about syslogd sillyness:
<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>does guix use systemd?
<unmatched-paren>johnjaye: no
<johnjaye>oh. ok
<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
<unmatched-paren>shepherd, that is, not guix
<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 ‘’, runlevel, etc.
<unmatched-paren>johnjaye: you can just switch to another tty or something, no?
<nckx>Is my guess.
<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
<unmatched-paren>johnjaye: in that case, you'll want to disable gdm
<unmatched-paren>in your system config
<unmatched-paren>would setting the default tty to something that isn't 1 work?
<unmatched-paren>i think you can do that?
<unmatched-paren>johnjaye: do you have a nvidia card, by any chance?
<unmatched-paren>johnjaye: that's the problem, then.
<johnjaye>i think virtualbox should give it a generic card though?
<johnjaye>it's like VirtualVGA or something
<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>like, mount it as a fuse filesystem or something
<johnjaye>not sure. that's a good idea though
<johnjaye>ok now i got the gui
<unmatched-paren>if so, you should modify the /etc/config.scm to remove the gdm service
<unmatched-paren>oh, cool!
<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
<unmatched-paren>johnjaye: yeah
<unmatched-paren>you can easily remove it (and GNOME) though
<unmatched-paren>i've done so myself
<unmatched-paren> see (modify-services %desktop-services ...)
<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.
<unmatched-paren>yes. it's specifically based on gnu's scheme implementation
<unmatched-paren>[*] excluding the daemon
<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.
<unmatched-paren>actually, you can _technically_ use other languages
<johnjaye>well that's why i'm here. so that's good
<unmatched-paren>JS and Lua apparently work
<unmatched-paren>because Guile has frontends for them
<unmatched-paren>you can add other languages to it with... uh... scheme.
<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
<unmatched-paren>nckx: singpolyma i believe?
<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.
<unmatched-paren>most of the problems are not inherent
<unmatched-paren>such as the CI system failing
<nckx>unmatched-paren: The plan is to eventually remove all other front-ends.
<nckx>Just go all in for Brainfuck.
<unmatched-paren>because the team administrating it is pretty small
<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/ file too short
<wdkrnls>What should I do to fix this?
<nckx>wdkrnls: Oh dear, fs corruption.
<johnjaye>shepherd is the gnu answer to systemd?
<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>Well dang.
<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>I might be wrong, if is the oldest incarnation. systemd is older than I thought (2010).
<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>Those are for services.
<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.
<nckx>wdkrnls: Interesting.
<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.
<wdkrnls>sounds like a plan
<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 :)
<unmatched-paren>personally, i'm in the pessimistic camp
<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.
<nckx>For you protection.
<nckx>*r 😒
<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/ 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.
<unmatched-paren>nckx: new features in linux 5.18: stdout encryption
<unmatched-paren>TODO: add support for encrypted stdin
<wdkrnls>nckx: neat!
<nckx>unmatched-paren: It has 0 overhead, which I'm pretty sure is unique? …so there's that?
<unmatched-paren>nckx: yes, caesar cypher is hailed as remarkably efficient
<unmatched-paren>"even simpler than FNV!"
<nckx>O(ff by 1)
<unmatched-paren>No, silly parenthesis, it's `P)2*`. How could I forget.
<nckx>It was cp437.uni I'd screwed up, not the font.
<nckx>Because I know you all care.
<unmatched-paren>what are .uni files?
<jab>I had no idea guix had minetest packaged!
<unmatched-paren>jab: seems to even have a minetest-build-system
<unmatched-paren>for mods i guess
<nckx>unmatched-paren: Just a text file mapping Unicode glyphs to legacy CP437 (which is still used by console fonts baked into the kernel).
<nckx>jab: Explains your worrying productivity. No more!
<unmatched-paren>nckx: is CP437 some archaic text encoding then?
<nckx>We might even have a 2-person minetest team soon.
<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>oh, wait.
<unmatched-paren>no, cp/m wasn't an ibm thing
*unmatched-paren getting basic history mixed up, outrageous
<nckx>CP here = code page, no relation.
<unmatched-paren>i see.
<jab>nckx: I am super close to being done with the opensmtpd configuration...I promise.
<unmatched-paren>To be fair to myself, 1972 is a while before my time.
<nckx>…how old do you think I am?
<nckx>…don't answer.
<unmatched-paren>nckx: i did not anticipate that possible interpretation :P
*nckx was not involved in the design or implementation of the original IBM PC. I am innocent, I tell you.
<unmatched-paren>nckx exposed
<johnjaye>what is a minetest?
<unmatched-paren>you DOS sympathiser!
<unmatched-paren>johnjaye: a game
<roptat>just to be sure, since I'm moving servers, does look ok?
<nckx>johnjaye: An open-world sandbox game where you ‘mine’ blocks and build things. Sound familiar?
<roptat>(yes, asking for a DDOS)
<johnjaye>no i've never heard of anything like that ever in my life.
<nckx>roptat: Looks good from here.
<roptat>great, thanks
<unmatched-paren>roptat: looks fine to me at first glance.
<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?
<johnjaye>is emacs-guix the same as emacs?
<unmatched-paren>johnjaye: it's an emacs plugin
<unmatched-paren>that allows you to operate guix from emacs iirc
<unmatched-paren>included with the guix emacs package by default
<wdkrnls>okay, it finished.
<wdkrnls>Emacs still doesn't work. :(
<nckx>What finished? The gc? Is the file still empty?
*nckx AFK though.
<wdkrnls>Yes to bouth.
<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
<johnjaye>gcc-7.5? isnt' that a bit old?
<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.
<unmatched-paren>can you share the output from installing emacs-guix?
<johnjaye>idk i just installed opened a terminal window and typed 'guix install emacs-guix'
<johnjaye>trying to get emacs somehow
<unmatched-paren>johnjaye: just do `guix install emacs`
<unmatched-paren>or, for best results, use a home configuration from the start
<unmatched-paren>using `guix home import ~/.config/guix`
<unmatched-paren>i believe
<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`
<johnjaye>ah guix has no curl by default. sad
<unmatched-paren>johnjaye: have you run `guix pull` yet btw?
<unmatched-paren>you'll need to do that to get the latest guix version
<unmatched-paren>the manual recommends that you do it immediately
<unmatched-paren>might also be why you have gcc-7 being installed
<unmatched-paren>the current gcc we use is gcc-11
<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
<unmatched-paren>guix uses a lot of symlinks :P
<johnjaye>here is what i got
<johnjaye>thank the gods I was able to install curl at least without problems
<unmatched-paren>you will want to run the upgrade
<johnjaye>you really should have it by default
<unmatched-paren>because 1.3 is very old
<johnjaye>even windows does that now
<unmatched-paren>well, we have wget by default, so at least that curl use case is covered
<johnjaye>i used curl to make that paste for you
<johnjaye>pastebinit wasn't there either
<roptat>guix is pretty empty by default
<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?
<unmatched-paren>johnjaye: `guix describe`
<johnjaye>guix pull is taking a while
<unmatched-paren>the `stable` version?
<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.
<unmatched-paren>johnjaye: yes, you're supposed to use stable
<johnjaye>but you say stable doesn't really exist
<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
<unmatched-paren>johnjaye: yes, the latest `master` commit
<unmatched-paren>guix is bleeding-edge, but gives you plasters :)
<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
<unmatched-paren>hunger: (invoke "ls" "-lAh")
<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
<roptat>that's 1.3.0
<unmatched-paren>hunger: or, if the build fails: `guix build ... --keep-failed`, cd to the reported directory, and run that command
<unmatched-paren>1.3 is very old
<unmatched-paren>we're nearly at 1.4 though
<johnjaye>ok. it's not like i'm choosing to use it. it's what the site gave me.
<roptat>yeah, that's fine
<unmatched-paren>johnjaye: as i said, the site is correct in giving you 1.3 :)
<roptat>we haven't published anything newer yet
<unmatched-paren>the 1.3 installer is tested and working
<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
<unmatched-paren>johnjaye: `guix system reconfigure`?
<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 do it in a phase
<johnjaye>ah i see
<unmatched-paren>then switches your current system to the new system
<hunger>is install plan a phase?
<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
<unmatched-paren>and allow you to use guix without a backing distro
<unmatched-paren>you can use guix on any linux machine, but you lose guix system
<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>*guix the package manager
<unmatched-paren>hunger: can you please put the package and command used to build it on ``?
<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 <>, then run `./reconfigure && ./reconfigure system` in the conf directory
<unmatched-paren>obviously my code etc will need to be recovered from, but my setup will be there instantly
<unmatched-paren>it's an effective and space-efficient backup mechanism
<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>hunger: thanks
<unmatched-paren>johnjaye: which specific message are you replying to?
<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
<johnjaye>what you just said
<unmatched-paren>johnjaye: i'll be able to recover it?
<wdkrnls>guix gc --delete doesn't make any sense.
<unmatched-paren>from ~unmatched-paren/conf?
<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
<roptat>wdkrnls, why not?
<wdkrnls>Because it lies.
<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
<roptat>wdkrnls, how so?
<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>wdkrnls, I'd run an fsck first
<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
<unmatched-paren>on a foreign distro
<wdkrnls>nckx tried to help me repair the store, but we didn't try a fsck.
<unmatched-paren>this behaviour is occasionally useful
<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>you can just do (lambda _ ...)
<unmatched-paren>because you're not using inputs or outputs
<unmatched-paren>or any other key
<unmatched-paren>hunger: the reason it's failing is because you're returning a string
<unmatched-paren>not a package object
<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 (define-public NAME (package ...))
<unmatched-paren>you are defining a guile variable that contains a package object
<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`
<unmatched-paren>so you need to change `"libstc"` to `libstc` without quotes, hunger
<unmatched-paren>when you `guix build -f FILE` guix evaluates the file
<unmatched-paren>and directly builds the returned package object
<unmatched-paren>without doing specification lookup
<wdkrnls>fuser -v certainly shows a lot of stuff from my current session.
<roptat>wdkrnls, mh, then maybe you'll need a live system
<hunger>unmatched-paren, oh thanks
<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.
<unmatched-paren>hunger: the formatting in that file is a little non-standard, btw. here's a reformatted version:
<unmatched-paren>in scheme we generally don't put closing parens on a new line
<hunger>thanks a lot!
<hunger>ah i see, that was my bsd ass style taking over
<unmatched-paren>that way, the code _looks_ like it's defined by whitespace
<wdkrnls>... since I don't have any usb disks handy at the moment...
<unmatched-paren>but it doesn't have the disadvantages of pythonistic formatting
<roptat>wdkrnls, no
<unmatched-paren>although there IS a guile frontend that allows you to use python-like syntax for scheme
<unmatched-paren>hmm, what's that {n - 1} thing in the wisp example?
<unmatched-paren>does guile have prefix operator support then?
<unmatched-paren>not prefix /o\
<nckx>wdkrnls: Not at shutdown, but at boot:
<nckx>Hit ‘e’ at the GRUB menu to edit the command line.
<nckx>You want fsck.mode=force
<wdkrnls>nckx: that sounds promising... so I don't have to edit my config.scm, right? I can just edit GRUB?
<wdkrnls>well... nothing for it I guess.
<wdkrnls>I will give that a shot.
<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>ah i see
<unmatched-paren>it also has to authenticate them all
<johnjaye>well i'll hit the manual. i thought i could just sudo apt-get install emacs and start fiddling with things
<unmatched-paren>it ensures they're all signed with good GPG keys.
<unmatched-paren>well, once you've updated, you basically can!
<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>once you exit the subshell you won't be able to use 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
<unmatched-paren>don't install gcc directly, use gcc-toolchain
<johnjaye>unmatched-paren: yes i do but then i just install emacs and go to town
<unmatched-paren>yeah, that's basically what you're doing now
<johnjaye>well i didn't do what you said. sorry
<johnjaye>i just typed guix install emacs
<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>where is the system config.scm
<unmatched-paren>johnjaye: /etc/config.scm by default
<unmatched-paren>but you can move it anywhere
<unmatched-paren>i have mine at ~/conf/system.scm
<johnjaye>sorry to be so brash. but i hate not having emacs
<johnjaye>or curl. or htop. or tmux or...
<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.
<unmatched-paren>or while the substitutes download...
<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>johnjaye: both are harmless
<unmatched-paren>the latter will resolve itself the first time you reconfigure
<unmatched-paren>resolving the former requires a small change to your config, to remove the use of a deprecated API
<unmatched-paren>namely, the bootloader's (target) field
<unmatched-paren>(target "/path/to/bootloader")
<unmatched-paren>should be replaced with (targets (list "/path/to/bootloader"))
<unmatched-paren>i'm not sure that it takes a path, actually
<unmatched-paren>ah, yes, it takes a path
<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".
<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>if only
<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.
<nckx>…and good luck‌ :-/
<nckx>sneek: later tell wdkrnls: Guix doesn't use pretty alignment like this (there's only one space after ‘linux’), and the command line is much longer, and ignore the insane source, but the cursor here is in the right spot:
<nckx>sneek: botsnack
<wdkrnls>I got fsck to run, yay!
<sneek>wdkrnls, you have 1 message!
<sneek>wdkrnls, nckx says: Guix doesn't use pretty alignment like this (there's only one space after ‘linux’), and the command line is much longer, and ignore the insane source, but the cursor here is in the right spot:
<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>:( ... well I'm rerunning gc now.
<wdkrnls>specifically: sudo guix gc --verify=contents,repair
<wdkrnls>maybe the fifth time is the charm
<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?
<unmatched-paren>djeis: you mean the #:configure-flags argument?
<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.
<unmatched-paren>djeis: substitute-keyword-arguments
<djeis>Ah yes, much appreciated
<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>which is used as the new value
<unmatched-paren>(substitute-keyword-arguments (package-arguments OLD-PACKAGE) ((#:configure-flags old-flags) (cons* "--new-flag" "new-val" old-flags)))
<unmatched-paren>should do what you want
<unmatched-paren>if you don't want OLD-VAL you can just use _ as the binding
<djeis>I need to do some quotation trickery though, I think.
<unmatched-paren>oh, yeah
<djeis>Because #:configure-flags is actually an expression that evaluates to the list, not the list itself.
<unmatched-paren>sorry, NEW-VAL should be quoted
<unmatched-paren>or gexped
<unmatched-paren>based on whether OLD-VAL was gexped
<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...
<unmatched-paren>if the existing package doesn't, then don't use gexps
<wdkrnls>maybe I'm not running it right?
<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.
<unmatched-paren>djeis: it should. can i see the package?
<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.
<the_tubular>Coud somebody help me understand what this is ?
<djeis>Ah the ceph package has a dedicated lib output.
<djeis>That's probably it.
<unmatched-paren>djeis: ah, yes it is. 99% certain.
<djeis>Yea, got past the configure phase this time.
<djeis>Whelp, it built.
<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.