<jlicht>bah. I am already happy it's not just me :-) <mekeor>why is it that both the online and my local manual of guix document the scheme procedure network-manager-service while current guix doesn't include that procedure but instead offers network-manager-service-type? <sneek>Welcome back mekeor, you have 1 message. <sneek>mekeor, cbaines says: if you want to use the network-manager service, you write something like this (service network-manager-service-type (network-manager-configuration)) <mekeor>still, the docs are outdated, i think <mekeor>it would be nice if 'guix --version' showed the git commit hash. hmm. maybe i could actually implement that myself <lfam>mekeor: It's actually impossible for a copy of Guix to include the Git commit that it was created from. Try making a text file that contains its SHA1 hash :) <lfam>This is why the "guix-devel" package must refer to an earlier commit <lfam>Well, I suppose the built artifact could be made to include the hash. Perhaps there is room for improvement <mekeor>hm, at least, now i know, i can't implement it on my own <lfam>Currently, `guix pull` doesn't know the hash at all. It just pull the HEAD commit of the master branch. <lfam>I encourage you to play around if you are interested. I always remind myself that "motivation is not fungible" <mekeor>you're right. i will work more on guix after my exams ;) <lfam>We want to improve `guix pull` in a radical way, so the current mechanism should not constrain you. See the "Trustable guix pull" bug report for discussion <mekeor>(adding wpa-supplicant to the services field) <mekeor>i'm still wondering why the manual (online and local) are outdated. <lfam>The manual is in the file 'doc/guix.texi'. Improvements or bug reports welcome :) <davexunit>the online manual is always for the latest stable release <mekeor>still, davexunit, my local info-reader shows an outdated manual as well <davexunit>yeah I don't know enough about your setup to guess why that is happening, sorry. <mekeor>so it's not happening for all of us? alright <lfam>Did you check if the current version of guix.texi contains this error? <mekeor>yes, i checked. it doesn't contain that error. <Apteryx>mekeor: You'd have to add guix manual location to your INFO_PATH. <Apteryx>I have this: export INFOPATH="$HOME/.config/guix/latest/doc:$INFOPATH" in my ~/.bash_profile <mekeor>i'm using GuixSD, btw. i'm using emacs as info-reader. it's reading the info from /run/current-system/profile/share/info <Apteryx>I'm using GuixSD too. I think the default manual at that location must be that of the Guix package installed in the system profile. <Apteryx>If like me you are using guix directly from the git checkout, it is not installed, so it makes sense that its manual would not be visible unless you set INFOPATH to point to it. <mekeor>Apteryx: i don't have a directory $HOME/.config/guix/latest/doc <Apteryx>I'm not trying to fix a small but annoying problem: anytime I press the CapsLock key, my bluetooth keyboard stops responding. I have to disconnect & reconnect to rega <Apteryx>mekeor: OK, I guess you are not using a git checkout for Guix then? <mekeor>no, Apteryx, i just use `guix pull`... <mekeor>your capslock-issue sounds very annoying btw <Apteryx>OK. On my system, I have a symlink like this: latest -> /home/maxim/src/guix <Apteryx>(I'm using guix from the master branch, directly from a git checkout). <mekeor>for me it's a link to /gnu/store/dakig23iah6vd38g3jkfvv31m3ybcprq-guix-latest <Apteryx>I don't like "guix pull", it just seemed very innefficient compared to what git does, and it enables me to hack the thing better. <mekeor>oh, i see what's happening here now <mekeor>so, ~/.config/guix/latest is a link to /gnu/store/FOO-guix-latest. but `whereis guix` reports /gnu/store/BAR-profile/bin/guix. <mekeor>there is /gnu/store/BAR-profile/share/doc but there is no /gnu/store/FOO-guix-latest/share/doc <Apteryx>Wouldn't FOO-guix-latest be another symlink pointing to BAR-profile/bin/guix? <Apteryx>Quick and dirty solution to this annoying capslock problem on the Apple Wireless Keyboard: setxkbmap -option ctrl:nocaps <Apteryx>This makes it a CTRL key instead of a CAPSLOCK key. Problem solved! <Apteryx>Interesting thing though was that it was working great on Ubuntu. So they must have some patch/configuration to fix that behavior. <Apteryx>I have a strange problem. In my PATH, I append $HOME/.local/bin before $HOME/.guix-profile/bin. I have a GnuCash installed in my user profile. Now I create an executable bash script with the exact same name (gnucash) to wrap the original binary and use a different locale. <Apteryx>If I do `which gnucash`, it shows the wrapped version (script) in my .local/bin folder. <Apteryx>If I just type `gnucash` at the command line, it starts the original (unwrapped) binary. Why is that? <lfam>What does `command -v gnucash` say? <lfam>And where do you set path? In the login shell or the interactive shell initialization scripts? <Apteryx>lfam: I set the path in the login shell (I believe): ~/.bash_profile <Apteryx>lfam: command -v gnucash says: /home/maxim/.guix-profile/bin/gnucash <Apteryx>Why is the command output different that "which" ? <lfam>I'm not sure, to be honest, but I always trust `command`, since it's specified by POSIX <Apteryx>Anyone familiar with the guild command of guile? <Apteryx>I just checked, and yes, it's a Scheme script to launch the guile compiler. <Apteryx>Should our guile output contain a built version of this Scheme script already? <Apteryx>Hmm. guix lint is throwing a gnutls-error. This seems to have appeared after my reconfigure, and I'm sure it happened before. <lfam>Apteryx: Are SSL_CERT_DIR and SSL_CERT_FILE set as described in the manual section 7.2.9 X.509 Certificates? <Apteryx>I'm using GuixSD. Looking at the SSL_CERT* envars, they all point to /etc/ssl/certs/... <Apteryx>Which points to various locations in the store. I've checked for dangling symlinks, there are non. <Apteryx>(according to `find /etc/ssl/certs/ -xtype l`) <Apteryx>It's possible I've reconfigured and haven't rebooted yet. Could this cause this? <lfam>You might also try doing it within `guix environment guix` <Apteryx>Fails the same in a guix environment. <lfam>Precisely what command are you trying to run? <Apteryx>or "guix lint icecat" or "guix lint <any package>" <lfam>On a foreign distro, it fails for me when those variables point to '/etc/ssl/certs/...'. It works when they point go '~/.guix-profile/etc/ssl/certs/...' <Apteryx>OK. Fails with the same error as mine? <lfam>Now that I have the recent copies of the CVE database, Guix doesn't try any HTTPS connections for subsequent runs, so I can't check :/ <lfam>But, your backtrace looks familiar <lfam>I really don't know why one should work and not the other. <lfam>Seems like it should "just work" on GuixSD <lfam>It also works for me on GuixSD, updated within the last week <lfam>Hm. What's the value of `realpath /etc/ssl/certs/ca-certifificates.crt`? <lfam>Well, you'd better correct my typo <Apteryx>Which typo? It returned: /gnu/store/87z5imswjpjpl9kvbm18a4jcadm2127a-profile/etc/ssl/certs/ca-certifificates.crt <lfam>Ah, an interesting property of realpath <lfam>Well, it doesn't match mine, but that doesn't really narrow it down too much :/ <lfam>One would want to use --canonicalize-existing to be sure the full path exists <lfam>That machine has a 100 GB /gnu/store and is used for building. I don't run the gc often :) <lfam>I wish I had more questions to help figure out what the issue is, but I don't. <Apteryx>It's OK! Thanks for making me check those things. Maybe I'll open a bug if a new reconfigure + reboot doesn't cure it. <lfam>Yes, please open a bug in that case. Even otherwise... <efraim>I applied manolis's patch locally and rebuilt the aarch64 bootstrap binaries and uploaded them to flashner.co.il/guix/..., now its time to change up the patches and get it rebuilt on the arm board <efraim>civodul: is there a command I can run to try to cross build the cross-build packages? <civodul>to cross build the cross-build packages? <civodul>you want to run the cross-built packages? <civodul>you can use qemu for that, or real hardware <civodul>like "qemu-aarch64 /gnu/store/something-for-aarch64/bin/foo" <civodul>though it doesn't always work, as i mentioned on the list <efraim>no i mean like on core updates we build arm-linux-gnueabihf.coreutils-8.26.x86_64-linux <efraim>i transfered the new patches to my aarch64 board, building the git repo atm, then i'll build to hello again <civodul>efraim: ah yes, this is just the Hydra job name for "guix build --target=arm-linux-gnueabihf coreutils" on x86_64 <efraim>hmm, problems again with the fgrep test on %bootstrap-coreutils%co, lots of fun <efraim>that wasn't too bad actually, just moved my patch up 2 lines and it worked <efraim>no, i take it back, had to overwrite the `exec /gnu/store/eee..grep -F ...' entirely, but it should work for all bootstrap binaries <efraim>mmmm, nope, that failed hard on x86_64 <htgoebel>once again I get certificate errors (signer-not-found, invalid), when trying to "./pre-inst-env guix import …". <htgoebel>I used guix-0.12.0-4.d9da to set up the "guix environment" and just built guix from scratch (current master head db6afe387a). <htgoebel>Since I have such problems every few weeks, I'd like to solve eh root cause. <htgoebel>civodul: Shouldn't "guix environment guix --ad-hoc ..." do this? <htgoebel>civodul: Notable: I'm *not* using GuixSD, but using guix on top of y standard GNU/Linux distribution. <nckx>I'm updating a package with ‘#:tests? #f ;no tests’. That's true, but not disabling them results in 0 tests being run successfully in ~1s. So I'd prefer to remove this line to save future updaters the trouble of checking whether there are new tests. Is this acceptable? <nckx>(No new deps or anything. It's-a free!) <ng0>updating as in version update? <nckx>I'm going to do that and keep the comment. <civodul>htgoebel: you'd have to add nss-certs to your environments, and you'd have to make sure the relevant env. vars are set <civodul>well, unless the environment contains openssl, for instance ***ShalokShalom_ is now known as ShalokShalom
<civodul>jmd: yesterday you reported a problem with yelp while upgrading your profile <sneek>GNUnymous_IRC, you have 2 messages. <sneek>GNUnymous_IRC, phant0mas says: not yet, soon :-) <sneek>GNUnymous_IRC, phant0mas says: the longer answer is you can, you just need to place the tarballs in the correct directory while using core-updates branch <jmd>civodul: I will try again tonight and let you know. <GNUnymous_IRC>What is "%desktop-services in the services field of operating-system"? <adfeno>GNUnymous_IRC: %desktop-services is this: <GNUnymous_IRC>What is "%desktop-services in the services field of operating-system"? <ng0>GNUnymous_IRC: the documentation is actually helpfull. If it isn't, we are open to constructive critique <ng0>that or wathc one of the presentations about Guix concepts. with a systems which differs from the rest it helps to learn <jmi2k>Hello Guix! What happened with network-manager-service in the last weeks? guix system reconfigure doesn't find it :( <civodul>jmi2k: see commit b726096bc5fcef1b96554c679b81a34d49265f9c <civodul>you need to write: (service network-manager-service-type (network-manager-configuration)) <civodul>i'll do something about it at some point :-) <civodul>cbaines: BTW, does network-manager work for you? <jin>i use network-manager with some issues <jin>i need todo more tests to find why dhclient fail <civodul>jin: feel free to email the list to report your issues/findings <civodul>i think we need to figure out what remains to be done so it works out of the box <Apteryx>How can I add a dependency on dconf to a package? <Apteryx>GnuCash needs this to save its preferences. <Apteryx>jmi2k: Oh. I had missed that we had an actual dconf package. Well that should be easy :) Thanks! <erliphant>Where do the standard recipies get stored locally? Are they all in the guix database? <catonano>erliphant: the "standard" recipes are plain vanilla Scheme structures. They are defined in source files. You might want to take a look at the "gnu/package" folder inside the guix proect root <ng0>the download links are actually script-links <ng0>after failing to unpack the file many times I tried to read it and got the format :) <ng0>I noted this in the new patch <erliphant>thanks catonano - I stepped away. I understand that they are scheme - I've written some myself but I'm not sure where exactly the build daemon is reading them from. <catonano>erliphant: it's a whole issue, how to convey stuff to the daemon. There are some footages in which Ludo talks about that. Staging. Gexps and the such. I had troubles reading the code myself, some time ago <ng0>I review compton now for the last task of today :) <ng0>there's too much unreviewed and I'm not helping by only sending instead of reviewing more myself <ng0>oops, already pushed <ng0>okay.. then another one <ng0>I used to have this filtered inbox with +commited etc tags <adfeno>Is there such a concept as "GuixSD system version"? <nliadm>it would be nice if 'pull' could take a commit-ish <davexunit>nliadm: you can pull down any version of guix you want with 'guix pull' <davexunit>I believe someone added something to the manual recently giving examples <nliadm>oh really? have I just failed to read docs <davexunit>nliadm: I don't think the info was there when you read them <davexunit>it was a little known fact, if you look at what the manual has to say about 'guix pull' in master it should now have a couple of useful examples <davexunit>the cgit application on savannah.gnu.org allows you to generate tarballs of guix at arbitrary commits <davexunit>so you can use --url to download one of them <davexunit>'guix pull' defaults to doing that for the master branch <davexunit>you could also use it to download your own fork of guix or someone else's <ng0>eseentially you could even guix pull from an onion mirror this way <ng0>i found a perl package which is not deterministic, but afaik this is the problem with lots of perl.. just ignore it then? <ng0>this was from back in july, and i checked again <ng0>looking at the thread I wonder how spamassassin is doing. we have the dependencies now <bavier`>ng0: there was some nondeterminism caused by some of the documentation generators iirc <efraim>I think I'm going to try dealing with the egrep/fgrep bootstrap issues by rewriting them, right now it seems like the easiest option for dealing with pre2.25 and post 2.25 versions of grep <efraim>And it technically makes the bootstrap binaries smaller <efraim>i was going to bump guile-next, but it took me almost 4 hours to build <jmd>civodul: The answer would seem to be yes: That error doing guix package --upgrade is reproducible. <Exagone313>Hi, is it possible to use GuixSD on an existing distro without conflict (without a chroot)? Just for testing purpose. Not sure if it could omit system things like bootloader and kernel. <davexunit>Exagone313: you can use the guix package manager on its own, if that's what you mean. <davexunit>see the "binary installation" section of our manual <Exagone313>I was thinking Guix would mean the package manager without any repository that is distro related <Exagone313>like if you were creating a distro and use pacman/apt/similar, without using existing repos <davexunit>there's no "repository" like in mainstream binary distros <jmd>Exagone313: "Guix" is the name of the package manager. "GuixSD" is the name of the operating system. <davexunit>a bunch of those modules contain package objects that define the recipes for building all sorts of things <jmd>Exagone313: You would use your existing one. <davexunit>GuixSD uses GNU Shepherd for the init system <davexunit>but using Guix doesn't change anything like that <CompanionCube>ACTION wonders if GuixSD uses a custom initramfs or something like that <jmd>CompanionCube: Something like it. <davexunit>CompanionCube: our initrd is a guile program <lfam>I sent OpenSSL updates to guix-devel. I don't have time to test them properly. Please test and push on my behalf if they are correct. <lfam>Bah, I forgot to sign the email <lfam>ACTION wishes that `git send-email` could be signed <lfam>I'll send a signed followup <lfam>New linux-libre releases are ready <civodul>jmd: can you try to "reduce" it to a simple test case? like creating a different profile with the same package set, then a reduce package set, etc. <civodul>or trying to "guix build" whatever depends on yelp in your profile <civodul>jmd: at worst you can send me the output of "guix package -I" <civodul>assuming that's enough to reproduce the problem <jmd>According to "guix refresh -l yelp" there is only one package that depends on yelp. <jmd>and that is gnome-3.22.2 <jmd>... and that has no dependents. <efraim>sneek: later tell lfam I sign my emails with git-send-email, I'll take a look and see what the magic config is <nliadm>so this is more of a guile question, but can I programmatically create the first argument to define-public? I want to have a package built at a bunch of different versions, and it'd be nice to be able to just write a function that takes a package, a list of (version,hash), and a function to make an origin <bavier`>nliadm: that could be achieved with macros <nliadm>I had a feeling it could, but I can't figure out how to create the name to bind the package to. my attempt with gensym didn't work <civodul>nliadm: u-boot.scm is a good example (it doesn't use macros) <nliadm>although it's very possible I did it wrong <nliadm>that doesn't quite do what I want. the name of the package is still hardcoded, down at the bottom <nliadm>er, the symbol? the name the package is bound to is written in the source <taylan>nliadm: if you want to do what 'define-public' does at runtime, you'll have to use the reflective module API. (info "(guile) Module System Reflection") <jmd>civodul: I think the problem is, is that some time ago I locally modified yelp to have a debug output, and then installed that incarnation of yelp. But those modifications I have since discarded. <taylan>nliadm: oh, I only now realize this is a Guix packaging question :) <jmi2k>How is neovim package going? <taylan>yeah a macro may be the cleanest way if I understand your use-case correctly <nliadm>I want to write a thing that lets me do (make-pkgs inheret-from '(("version" "hash))) and then be able to have new versions just by adding version+hash entries. Does that make sense? <nliadm>forgot a " and rampant misspellings, but <taylan>nliadm: if they really don't require any changes to the body of the package definition, yeah. I think I'd do it with a macro like this: http://sprunge.us/UdBG <taylan>oh wow, I'll need to change my neat emacs function to use a different pastebin now :| <buenouanq>using dd ... bs=4M completely kills my machine <taylan>buenouanq: that's odd. is this a very peculiar machine? very old, or very strange hardware? <taylan>nliadm: BTW I guess it's best to call the macro define-foo rather than make-foo, to be conventional <nliadm>taylan: thanks! but would it be possible to construct <var-name>? <taylan>buenouanq: I got no clue then. I doubt it's related to guix. did you check in 'top' or so to make sure it's not another process causing it? <buenouanq>it only happens when I run dd with bs=4M (haven't tested other bs= values yes) - when I was successfully able to open top while it was running once, nothing looked weird or out of place <taylan>nliadm: with syntax-case rather than syntax-rules, yes. stylistically, I'd prefer the defined variable names to appear literally in the scheme file to be honest, but I'm not the style authority of guix so... example incoming <buenouanq>but I'd love if we could confirm if it's just me <jmi2k>buenouanq: dd if=/dev/zero of=/dev/null bs=4M could be an example? <nliadm>ultimately I want to be able to build a lot of revisions, then diff some tests. So having the list of versions be as simple as possible makes that much nicer, imo <taylan>nliadm: it's a little more challenging than I thought, so I'm using this as an exercise to improve my syntax-case magic :P <jmi2k>buenouanq: no sorry. What about reading from urandom? Or from an external hard disk to root? I can try it <nliadm>I tried and failed, and it felt like because I didn't know what questions to google <cbaines>civodul, in response to your earlier message about NetworkManager, yes, it does work for me <cbaines>I had some problems initially with it (I'm assuming) changing the hostname, and then applications failing to start as a result <jmi2k>buenouanq: and from zero to a file? <buenouanq>this wasn't a one time thing though, it's been happening all week <cbaines>I haven't read the scrollback, so I'm confused also <cbaines>the paste looks like some different syntax for defining packages? <nliadm>yeah, I was asking about a way to define packages in a marco, providing a base package and a list of version, hash pairs <nliadm>but generating the names to bind the new packages to escaped me and is apparently very tricky <cbaines>what are you planning to use this for? <nliadm>being able to specify lots of revisions of a package easily <nliadm>ultimately to spawn a lot of environments and diff output <nliadm>sort of like a guix'd up git bisect, I guess <nliadm>that looks very clever. I'll have to sit down an attempt to understand it >_> <taylan>eh, doesn't really work yet either. syntax-case is always a mind-screwer. <nliadm>I was surprised I couldn't just (gensym), because that seemed like what I wanted <taylan>nliadm: for what purpose exactly? <taylan>well they should be human-readable, no? or do you mean like (gensym "foobar")? <nliadm>does that matter? on the guix command line, you still specify names and versions using the "name" and "version" parts of the package, right? <taylan>hmm, yes. it might still be desired to have clean variable names. but if not, then generating the name becomes easier. gensym itself won't directly work, as scheme uses identifier objects rather than raw symbols to denote identifiers at compile time, but yeah... <taylan>it would be (datum->syntax stx (gensym)) I guess <taylan>(datum->syntax will turn a symbol into an identifier object) <taylan>(bound to a certain syntax context...) <taylan>the syntax-case system is kinda complicated but really mind-opening when one grasps it. <civodul>jmd: i was afraid of having caused a regression with my graft thing yesterday :-) <civodul>cbaines: good to know NM is working for you, it means the situation is better than i thought ;-) <cbaines>civodul, I was impressed how easy it was to get the dnsmasq configuration in and working <cbaines>its quite a neat way of managing dnsmasq, which I use just because it offers an easy way to do wildcard dns <cbaines>e.g. I have *.localhost pointing at 127.0.0.1, just by dropping a file in to /etc/NetworkManager/dnsmasq.d <jmd>civodul: But I still don't know how to solve the issue :( <civodul>cbaines: you should write somewhere about it :-) <civodul>jmd: i think you can do "guix package -r yelp:debug -u" <cbaines>Yeah... I'm hoping to be able to wrap the whole setup in to Guix eventually <civodul>hopefully you can tell us about all the Guix things you're doing at FOSDEM <jmd>civodul: That gives me the same error: "guix package: error: reference to invalid output 'debug' of derivation '/gnu/store/p3dngbj101p17mfc9qiyadsvcdk93kr9-yelp-3.22.0.drv'" <civodul>i mean, not in a formal talk, but we can chat <civodul>jmd: and "guix package -r yelp" alone? <cbaines>Haha, yeah, I'm really looking forward to it <cbaines>I'm planning on sending a email to the list this weekend <jmd>civodul: But guix package --upgrade still fails <civodul>cbaines: there seems to be lots of interesting stuff in there, and the idea that "govuk" uses Guix is fun! <cbaines>Well, its not quite that yet, I use Guix, and I also happen to work for the UK Government Digital Service, on GOV.UK <civodul>jmd: could it be that you have a package recipe with (inputs `(("yelp" ,yelp "debug"))) ? <jmd>civodul: There's certainly nothing like that in my current sources. <nliadm>oh hm, you have to repeat the entire origin even if you just want to change the sha <civodul>jmd: and in ~/.guix-profile/manifest ? <civodul>nliadm: not necessarily, you can use 'inherit' <civodul>usually you also want to change the URL tho <nliadm>every instance of inhereit I see in guix repeats the entire block, even if the url has the version factored out <efraim>You can inherit the package-source, for example if you need to add a patch <bavier`>nliadm: but the version is bound to the original package <jmd>civodul: There is a (yelp "3.20.1" "debug") there. <civodul>you can't edit this file, but you can find out where it comes from <civodul>and then run the corresponding "guix package -r" command <nliadm>efraim: do you know of a package that does what you're talking about? <efraim>Its useful for some of the security grafting, but not off the top of my head <jmd>civodul: And how do I find out where it comes from? <efraim>I'd git-grep for it though, I'm sure there's some there <civodul>jmd: check if it's within a 'propagated-inputs' list <jmd>Ahh simple "guix package -r yelp:debug" did the trick. <sankey>why would removing a package from a profile (guix package -r <package>) cause any derivations to get built? <sankey>shouldn't it just move around some symlinks and create a new profile? <jmd>sankey: A profile is a derivation, I think. <civodul>yeah, building a profile means generating an Info 'dir' file, a GTK+ icon cache, and so on <jmd>Anyway bed time. Thanks for your help. <nliadm>hm yeah, I think I have to make this macro take a function that returns an origin to make it generally useful <nliadm>I modified the explicit macro to take a function that returns an origin 