IRC channel logs


back to list of logs

<lfam>Any idea how to do `guix refresh -l` for something like meson, where the affected packages come through meson-build-system?
<apteryx><unnamed port>:102:33: error: package: unbound variable --> Could this be the telltale of a circular dependency?
<apteryx>ah, probably not, since it works in the shell using ./pre-inst-env ...
<apteryx>it's just emacs-guix who is throwing thi strange error. It sometimes also complain about an xclip unbound variable.
<apteryx>did the default substitute-urls change? I see only for the guix-daemon of a newly installed GuixSD machine.
<apteryx>I thought there should also be
<bavier`>apteryx: yes, it was updated
<bavier`> is a redirect to mirror.hydra, iirc
<apteryx>I thought ==
<apteryx>yep, I confirmed using the 'host' command
<apteryx>so, I want to add back since right now I feel like I'm using gentoo :-)
<bavier`>apteryx: I hear ya, same here lately
<apteryx>I think this should do it, as long as you manually authorize the keys:
<bavier`>apteryx: thanks :)
<bavier`>do we have a merge schedule for core-updates?
<apteryx>yay, hydra has a lot of substitutes
<janas>I have guixSD installed on a x200T and I'm running into an issue where the system freezes after waking up from suspend to RAM. The screen shows my desktop but no input devices work, and the SysReq key has no effect.
<janas>I'm not super knowledgable about this so any ideas would be appreciated. I'm using XFCE
<pkill9>janas: possibly a conflict between xfce trying to handle suspending and elogind handling suspending
<pkill9>you can disable xfce from handling suspending, can't remember how
<pkill9>ah, at the bottom of this page:
<pkill9>might not be the same issue though, the issue im thinking of is specifically handling suspendin via closing the lid
<janas>pkill9: Thanks for the tip, I'll look into it. I just realized that my installation was a few weeks out of date so I'm going to try updating it first
<reepca>anyone have any tips on why luatex would be silently exiting with status 127 in the build environment? tried looking it up and it seems to indicate that a command wasn't found or something, but you'd think it would print some sort of message at least, right?
<roptat>Hi guix!
<g_bor>hello guix!
<janneke>hi g_bor!
<jas4711>i'm using openntpd with the config example from the manual, but getting complaints about 'constraint: failed to load constraint ca'. i have the 'nss-certs' package installed. any ideas?
<g_bor>janneke: hi!
<efraim>jas4711: like in the manual? (constraint-from '(""))
<g_bor>hello guix!
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, apteryx says: with my patch, I can see that the dbus-configuration used by my system generation contains a system-local.conf file which has a new entry: <includedir>/gnu/store/gw3ckmw2pihc44d23lc8pipfw7wr16g7-network-manager-openvpn-1.8.0/etc/dbus-1/system.d</includedir>
<civodul>that looks good
<jas4711>efraim: yes, like on
***ng0_ is now known as ng0
<jas4711>efraim: i can't find any documentation on how openntpd finds its CA certs, which is proabably what's causing problems
<efraim>jas4711: I'm not sure what's up with it, it worked the last time I tested it with the constrants field
<g_bor>hello guix!
<g_bor>is there a way to get absoulte file name?
<g_bor>I have some problems with a procedure using with-directory-excursion internally, that breaks relative paths.
<civodul>hey jas4711!
<civodul>jas4711: it may be that openntpd looks for certs in /etc/ssl/certs
<civodul>in which case you may need to add 'nss-certs' to the 'packages' field of your OS
<civodul>we should document/fix it tho
<civodul>g_bor: you can use canonicalize-path
<g_bor>civodul: thanks!
<g_bor>civodul: I had a look at the suggestions regarding the utility functions.
<g_bor>I found that file-header-match is not exported.
<g_bor>I also believe that reset-gzip-timestamps is missing a make-file-writeable...
<jlicht>hey guix
<civodul>howdy jlicht!
<civodul>g_bor: apparently it works well without it :-)
<g_bor>civodul: it works, because most of the time the gzips are writeable in the tarballs, and in other cases a phase is added to make them so.
***rekado_ is now known as rekado
<g_bor>civodul: I was also thinking about writing the strip-zip-timestamps in guile, but it turns out that we still need to unpack,
<g_bor>as otherwise the reference scanner can't find store references in the generated jar files.
<civodul>oh right, but that's a different story
<g_bor>:) yes, but these are handled currently in one pass, packing without compression.
<g_bor>Do you think it would worth to separate these?
<g_bor>like: 'reset-zip-timestamps, then 'disable-jar-compression ?
<rekado> does have a substitute for /gnu/store/blmkj5wxnw19zqjc17jrfh8l2ap8xigq-python-minimal-3.7.0.drv | /gnu/store/qws8zsa0mm1d7jwlcrg4rr9rmhip30av-python-minimal-3.7.0, but chooses not to deliver it.
<rekado>what’s up with that?
<g_bor>rekado: I've seen someone else - maybe snape? - also complaining about that.
<g_bor>It is delivered from hydra, though...
<g_bor>you also answered to that thread on the ml 3 days ago...
<g_bor>I guess you could reproduce the problem mentioned there...
<rekado>ugh, I/we forgot to update the %texlive-tag and %texlive-revision variables when updating the big texlive package.
<rekado>I’ll do that now and update all tex packages.
<civodul>rekado: is 200 so you should definitely be able to get it
<civodul>what's the symptom exactly?
<civodul>could you "sudo grep -r qws8zsa0mm1d7jwlcrg4rr9rmhip30av /var/guix/substitute/cache"?
<rekado>I deleted /var/guix/substitute/cache already :)
<rekado>the symptom is that things like git-minimal or python-minimal are not fetched
<civodul>it could be that you had a cached 404 that did not expire
<rekado>but then it should be fine now
<civodul>and after deleting /var/guix/substitute/ everything is alright?
<civodul>ah good
<civodul>so what does grep say? :-)
<civodul>actually "cat /var/guix/substitute/cache/*/qws8zsa0mm1d7jwlcrg4rr9rmhip30av" might work better
<rekado>there’s a match
<civodul>and what's in there?
<rekado>(I looked for the git-minimal hash)
<rekado>fetching that URL from with wget also works fine.
<civodul>what does "guix build /gnu/store/6b84mh6l6gs520vd06rd8dsczz5qpxx3-git-minimal-2.20.1.drv --substitute-urls= -n" say?
<rekado>it says “The following derivation would be built: /gnu/store/6b84mh6l6gs520vd06rd8dsczz5qpxx3-git-minimal-2.20.1.drv”
<civodul>and you authorized the key, right?
<rekado>yes, of course.
<rekado>this is on my laptop where I’ve been using since the day I set it up.
<rekado>the result of substitutable-path-info is an empty list when is used.
<rekado>when is used it is a single-item list with a substitutable object for git-minimal.
<civodul>super weird
<civodul>could you strace the 'guix substitute' process to ensure it reads the file from /var/guix/substitute/cache?
<rekado>this is weird
<rekado>did the key for change?
<rekado>I authorized it *again* and now /etc/guix/acl contains three keys
<rekado>two different Ed25519 keys
<g_bor>rekado: Three different keys?
<civodul>can you find out which is which?
<rekado>I’ll try
<rekado>I’m sorry for wasting your time.
<rekado>I must have accidentally replaced /etc/guix/acl and thus lost the authorization of
<rekado>so nothing’s wrong after all.
<civodul>rekado: well, i prefer it this way :-)
<rekado>yeah, me too
<rekado>I guess whoever else complained about not providing enough substitutes should also double check their /etc/guix/acl :)
<civodul>heh :-)
*rekado updates all tex packages now
<g_bor>is it possible to query the names of the authorized substitute servers?
<g_bor>so that we can have a look at that, much like we can look at for example the guix version...
<g_bor>that would be useful for support. wdyt?
<civodul>g_bor: the "names" are the public keys, really
*rekado tries to reduce the coreutils module closure
<rekado>one big problem is the dependency on “audio”, which depends on “music”, which depends on all sorts of things.
<rekado>we have a similar problem with “python”, which depends on a lot of modules and is depended on by many packages
<g_bor>civodul: then this is really easy, some very simple magic on the /etc/guix/acl could extract that.
<civodul>rekado: yeah, it's hard to find where to start
<civodul>g_bor: "cat /etc/guix/acl" actually :-)
<civodul>that said, i agree it's not easy to deal with
<civodul>it'd be nice to have "pet names" to refer to keys
<civodul>so you don't have to compare hex strings with your eyes
<g_bor>:) yes.
<g_bor>and also this file has restricted permissions...
<rekado>this split between music and audio is challenging. I have no idea where things should go.
<rekado>“audio” depends on “music” because of “portmidi” only.
<rekado>that’s easy to cut, but does “portmidi” *really* belong to “audio”?
<rekado>it’s nothing at all to do with audio! That’s the whole point of MIDI…
<rekado>categories are bad.
<rekado>we could move libraries from audio.scm to audio-libraries.scm and only keep applications in audio.scm; same with “music.scm” and “music-libraries.scm”.
<jonsger>rekado: so portmidi is then a library or not?
<rekado>or: we create a new module “sound.scm”
<rekado>portmidi is a midi library, yes.
<rekado>sound-libraries.scm could provide portmidi and solve this totally made-up problem.
<g_bor>rekado: before I came around guix I was planning to create my own package manager. I came up with a structure where the packages had their individual modules. It meant more files, but having a mode simple module structure, as the module graph became a DAG, getting rid of the circular dependencies.
<g_bor>It also commes with it's own problems, but somehow the benefits were appealing...
<rekado>having one module per package is probably better in the long run, but what I don’t like about this is the boilerplate.
<rekado>it just seems like a lot more effort to write packages with a big module header and all the duplication of modules and package inputs.
<rekado>this could be avoided with a few extra features, so that these files would not be plain Guile modules
<g_bor>rekado: we could discuss this at the Guix days. Also it would be interesting to find out how to transition there without too much pain...
<civodul>too many files is not good for i/o, see Nixpkgs...
<rekado>with future Guile versions one could compile all these tiny modules into a bigger file.
<rekado>I’ll leave the audio question alone for now and work on something easier like removing game-development from the coreutils module closure.
<rekado>what do you think about separating emacs from emacs packages?
<rekado>same with python and python packages?
<jlicht>rekado: would you go with (gnu packages emacs <something>), or rather (gnu package emacs-packages), or even something else?
<rekado>I wanted to add (gnu package emacs-packages) first
<rekado>because the dependencies of emacs are probably fewer than those of all possible emacs packages that end up in the same module.
<jonsger>what is the exact purpose of separating those modules?
<rekado>reducing dependencies between modules, thereby reducing the number of modules that need to be compiled / interpreted for “guix pull”
<jas4711>civodul: yes, probably, but i have the nss-certs package installed so something else is missing. i'll try to strace it to see what's happening
<g_bor>rekado: I have seen three or more layers of packages, which usually goes like this, in a per language categorization context: bootstrap: a complier, a standard library, a build tool; development tools: most usually commonly used modules of the build tool, test frameworks, linters and the like; and finally the packages as the top layer.
<civodul>jas4711: it's installed globally? i.e., can you see it in /etc/ssl/certs?
<rekado>g_bor: yes. I’d like to separate these layers.
<rekado>g_bor: wanted to do this for java already.
<rekado>(but got stuck distracted with rewriting the bootstrap)
<jas4711>civodul: yes
*jas4711 waiting for strace to build
<civodul>weird you don't have substitutes for that
<jas4711>civodul: i find it builds a lot of things. maybe i should re-install based on 0.16... this is from a 0.15 installation
<civodul>or you should pull, in case the old binaries vanished
<civodul>that's on x86_64?
<civodul>also, make sure to enable (aka.
<jas4711>yes, x86_64. i haven't done anything since installation, but is mentioned when i do 'guix packge -i'
<g_bor>rekado: it is also unfortunate, that the theme based and the language based categorizations are in fact orthogonal.
<civodul>jas4711: and you did authorize the key, right?
<civodul>hello samplet!
<bavier`>efraim: did you say you fixed the python@2 build failure on core-updates?
<g_bor>I have to go now, bye!
<rekado>civodul: I want to also split guile.scm into guile-core and guile. Would you prefer other names?
<civodul>rekado: maybe guile.scm and guile-xyz.scm?
<civodul>i think there'd be less breakage if we keep guile in guile.scm
<rekado>yes, I think so too
<civodul>one way to test for unbound variables if you try that is "guix lint -c inputs-should-be-native"
<rekado>oh, I always just run “make”…
<civodul>but then you need "make clean-go" before make
<civodul>actually this could also break things in (gnu services) and co...
<roptat>rekado, you wanted me to write something about scala for How do I do that? (where's the repo, where do I submit my changes, ...)
<civodul>so utimensat & co. are timezone dependent
<civodul>go figure
<roptat>where do I send patches for the bootstrappable website?
<civodul>roptat: i'd email rekado@ and janneke@
<civodul>but you have write access to the repo :-)
<roptat>ah, that's because it's under the guix group?
<apteryx>civodul: I had also not much substitutes available from; had to re-add to my substitute-urls.
<apteryx>*didn't have much
<roptat>rekado, in maven and gradle don't have the same level. What's the correct level?
<rekado>apteryx: could you name an example of a package for which you didn’t get a substitute?
<roptat>title level*
<rekado>roptat: ## is correct
<rekado>the top level is #, which is used by the page title.
<roptat>so maven should be ## too, right?
<rekado>the same problem in; they all should be ##
<roptat>same with the other pages I guess
<rekado>we shouldn’t use the level for size adjustments. That’s what CSS is used for.
<apteryx>rekado: tar
<apteryx>git, gtk, there were many
<rekado>apteryx: could you take a look at /etc/guix/acl to make sure that the pubkey for is actually there?
<apteryx>this one right: EEA139318243D36EB4C728DB96856AB15C47AB64C765FA134CCFB12444B82A7C? yes
<apteryx>ah, not this one it seems
<rekado>should be this: 8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394
<rekado>(see etc/substitutes/ )
<apteryx>yeah I saw it's not the same under my etc/substitutes/ Strange.
<apteryx>I generated my own GuixSD installer image from a recent Guix, I'm not sure how that key crept in.
<apteryx>(it's a new install from that self generated GuixSD install image)
<apteryx>that should help :-) shouldn't there be outputs at the command line when I used a substitute-url but forgot to authorize its key?
<apteryx>as in: warning: Not using substitute URL because it is not authorized
<rekado>this sounds familiar. I’m sure this conclusion had been reached in the past … but then nothing happened :)
<apteryx>rekado: at least it's tracked as 30143
<apteryx>you opened the issue :-)
<rekado>do you want to be the one who ended up closing the issue…?
<apteryx>I have other issues I'm working on right now, but I'll keep a mental note :-)
<rekado>sure ;)
<apteryx>I have to reboot -- lost my elogind after playing with the dbus-daemon service.
*apteryx will be right back
<apteryx>ls -al
<apteryx>err ;-)
<rekado>hmm, splitting guile.scm and guile-xyz.scm isn’t as easy as I thought. I’m getting some weird errors now…
<rekado>curious. This happens when loading (guix scripts pack): no binding `zip' to hide in module (gnu packages compression)
<rekado>obviously, that’s not true
<rekado>but when I remove that “#:hide” thing, it complains about not finding gzip, so something is really wrong here.
<roptat>did you make clean-go first?
<civodul>rekado: this is scary
<civodul>there's an open bug about "gzip: unbound variable" in the same vein
<rekado>I wonder if this is due to some cyclic dependency maybe.
<civodul>you need to make sure your guile*.scm modules don't use each other at the top level
<rekado>guile-xyz.scm uses guile.scm, obviously
<civodul>for instance, calling package-with-guile2.0 at the top level has this effect
<rekado>but not the other way around.
<civodul>hmm if guile.scm doesn't use guile-xyz.scm at all, my hypothesis may be wrong
<Swedneck>hi, can someone confirm seeing this message?
<jlicht>Swedneck: hello, I can :-)
<Swedneck>great! i have some questions
<Swedneck>i'm on fedora 29 and i want to use guix to get some libraries for building
<Swedneck>i tried `guix environment --ad-hoc eigen sfml` but `cmake --build build` is unable to use the libraries, do i need to configure something for my system to see the guix-provided libraries?
<rekado>civodul: skipping guix/scripts/pack.scm doesn’t help. Next problem is with guix/scripts/pull.scm, which needs le-certs from certs.scm, which Guile claims cannot be found.
<roptat>Swedneck, I'm not too sure, but have you tried to set LIBRARY_PATH=$GUIX_ENVIRONMENT/lib?
<rekado>Swedneck: you may need to set LIBRARY_PATH to $GUIX_ENVIRONMENT/lib
<Swedneck>will that override fedora libraries?
<Swedneck>hmm, well setting that variable doesn't seem to help at all
<civodul>Swedneck: alternately you could try "guix environment --ad-hoc gcc-toolchain cmake eigen sfml"
<civodul>that'll have the env vars properly set
<Swedneck>i'll try that
<civodul>cool :-)
<pkill9>Swedneck: did you get marblemarcher compiled? I actually made a package definition for that last night to practise emacs
<Swedneck>it compiles but i can't run it
*Swedneck sent a long message: < >
<Swedneck>but i doubt that's a guix issue, rather it's probably an issue with the source code itself
<pkill9>ah yeah i got that error, see the bottom of
<Swedneck>how do i try your package?
<pkill9>"Make sure that the current working directory contains the assets folder"
<pkill9>but now i think about it, my package shouldn't work
<pkill9>maybe i was accidentally running it while in the build directory with the assets folder
<pkill9>Swedneck: just download tha tmodule file and run `guix build -f <module file>`
<pkill9>yeah my package fails with the same error, i was accidentlaly runnin git in the directory with the assets folder lol
<pkill9>running it*
<Swedneck>yeah now it works, nice
<Swedneck>what do you mean by tmodule file?
<Swedneck>you mean marblemarcher.scm, right?
<pkill9>yeah, i mean "that module"
<pkill9>made a typo lol
<Swedneck>hmm, how do i add it to my profile?
<Swedneck>rn it's just in the system profile, or whatever it's called. /gnu/store
<pkill9>i wouldn't add my package to your profile cos i have wrapped it such that it finds the assets folder, but if you wanted to install it then you would run `guix package -f <module file>` or add my repository as a channel and run `guix package -i marblemarcher`
<pkill9>cos i haven't*
<Swedneck>i'm still very new to how guix works :P
<Swedneck>and how do i uninstall it after i built it?
<pkill9>so basically, 'uninstallin' does mean removing the files from disk, it removes symlinks from the profile you install the package to
<Swedneck>oh right, i'd have to gc
<Swedneck>thank christ i've used ipfs so i have some slight reference for how gc works
<Swedneck>but if i just wanted to remove the symlinks, what command would i use?
<pkill9>if you want to uninstall a package from a profile, you run `guix package -r <package>`, or if you just installed it you can run `guix package --roll-back` to switch to the previous 'generation' of the profile
<Swedneck>but it's not in my profile
<pkill9>the default profile is the one in ~/.guix-profile, which is a symlink to /var/guix/profiles/per-user/<user>/guix-profile
<pkill9>oh ok
<pkill9>then there' sno symlinks to remove
<pkill9>if you want to remove it from disk, you could remove that particular path from the guix store (everything in /gnu/store) with `guix gc -d <path>`
<Swedneck>so then if i want to remove it from /gnu/store i'd gc?
<pkill9>running `guix gc` by default will delete everything that isn't being used i.e. everything that isn't symlinked
<pkill9>but `guix gc -d <path>` will delete only that path, if that path isn't being used (isn't symlinked)
<allana>Hi, I noticed that a couple of packages were added that interest me, "docker" and "docker-cli". Does anyone have information on how to configure the docker service for guixsd?
<Swedneck>any easy way to get paths?
<Swedneck>besides just going to /gnu/store and looking for paths with the package name in it
<pkill9>Swedneck: `guix build` will output the path
<apteryx>allana: the information would be in those patches -- there are patches that touch documenting the docker service (patches to the guix info manual)
<allana>apteryx: Thanks
<pkill9>but generally unless you need space you don't really need to find paths to remove from the guix store
<Swedneck>no way to just use package name instead of path?
<Swedneck>feels less than optimal to have to go digging for paths when you want to remove things
<apteryx>Swedneck: you usually don't. You let the stuff accumulated and after a while your run 'guix gc' to garbage collect the unused items.
<pkill9>using `guix gc -d $(guix build <package>)` you could do that
<davidl>I was able to download and run guile-bash successfully on my GuixSD install, but when run on PureOS with Guix installed only as a package manager it fails. When I make sure the GUILE_LOAD_PATH is correct, I get this error: bash: symbol lookup error: /gnu/store/pc00g13djrdi5gdp4nbcgmd6qbbn2k5j-guile-bash-0.1.6-0.1eabc56/lib/bash/ undefined symbol: sh_xfree
<davidl>I think it's related to linked libraries and perhaps the LD_LIBRARY_PATH, but don't know for sure or what to try do about it.
<g_bor>hello guix!
<rekado>davidl: are you using bash from Guix as well?
<davidl>rekado: yes I have bash 4.4 installed in /gnu/store
<rekado>but are you *using* it?
<davidl>ehm, I tried, by starting it the bash I found in the store, but it didn
<davidl>t make a difference.
<rekado>generally, you shouldn’t run stuff from /gnu/store. You’d run it from a profile.
<rekado>it could well be that you’re using a different variant of bash from the store other than the variant used with guile-bash.
<davidl>rekado: my bad sorry... I must have done something wrong last because now it worked after I started bash from /gnu/store and retried.
*lfam tries building the new svn
<bgardner>Hello guix, getting this on a fresh EFI install: /gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/sbin/grub-install: error: /gnu/store/6zkimxsfyn0gdc7p4ikxlrhilpnpblsi-grub-efi-2.02/lib/grub/i386-pc/ doesn't exist. Please specify --target or --directory.
<bgardner>guix system: error: failed to install bootloader /gnu/store/ggiq6y4wniqgpc8yn7s0c9hf94xm597v-bootloader-installer
<bgardner>This was right at the end of the copy to /mnt step
<bgardner>Ah, rats. /boot/efi isn't mounted. I bet that's why, my bad. Let me fix that and retry.
<THFKA4>make sure you're booted in EFI mode, my BIOS did not default to it for removable media
<THFKA4>check that sys firmware dir for efivars
<bgardner>THFKA4: Interesting notion. It's about the same spot, so if it dies again I'll check that next, thank you.
<bgardner>Soo, dumb question: During a standard EFI install, should I create /mnt/boot/efi for the empty mountpoint or will that be handled by the guix system init call?
<pkill9>you have to create the directory and mount it yourself yeah
<bgardner>I did at /boot/efi (since the config file refers to it by that name and not by device), my question is do I also need to create the empty folder under /mnt/boot/efi so on reboot it exists to be mounted? The instructions seem a bit unclear.
<pkill9>yeah, but it doesn't need to be mounted to boot
<pkill9>but you'd get an error if you tried to mount to nonexistent directoyr anyways
<bgardner>Understood, thank you
<civodul>apteryx: looks like you're making good progress on the openvpn front
<civodul>i don't have much insight to provide but your approach LGTM