IRC channel logs

2021-07-05.log

back to list of logs

<dstolfa>nckx: if you want i can do some work on that on the next free day i get
<dstolfa>maybe i'll be able to find the race condition by moving things around as well
<nckx>What race condition was that, dstolfa?
<dstolfa>nckx: when you run `make check -j2` or more, sometimes tcgetattr and tcsetattr tests get skipped in `tests/syscalls.scm`
<dstolfa>i don't know why yet
<dstolfa>the more jobs you add, the more likely it is to get skipped
<dstolfa>with `-j20` it's pretty much every time on a 20 core box
<nckx>Right, that one.
<nckx>Moving two functions is rather boring but I won't stop you if you beat me to it.
<dstolfa>nckx: unlikely, it's monday tomorrow. that means C for a while :<
<nckx>Same here, or I wouldn't have written ‘functions‘…
<nckx>I'm guessing you don't enjoy C.
<dstolfa>i enjoy some of the things i do with C, but no i'm really not a fan of C. i'd rather do these things with something else, but i haven't got much of a choice
<nckx>Fair.
*nckx → 😴💤
<nckx>Night all.
<dstolfa>nckx: gn!
<pkill9>dstolfa: i hear rust is all the rage these days
<dstolfa>pkill9: please don't bring up painful memories, packaging rust is behind me (for today, anyway)
<mason>dstolfa: You're going to let the memories rust now?
<dstolfa>they are busy oxidizing at the moment
<drakonis>mason: greetings friend
<mason>o/
<char>I tried to add network-manager-openvpn as a vpn-plugin for network-manager-configuration, but is still seems to not be working. Any ideas?
<apteryx_>try rebooting
***apteryx_ is now known as apteryx
<char>apteryx_: will try
<char>before I do, is networkManager the default network manager for guix system?
<dstolfa>yes
<dstolfa>well, that and your system configuration using iproute i guess
*dstolfa -> bed
<char>restart no work
<apteryx>char: what is not working? can you share you operating system configuration? personally I use nmcli or nm-connection-editor to manage my OpenVPN connection.
<jgart>What do people think of having a `guix cat` command?
<jgart>It would be similar to `guix edit` but outputs the package definition to standard output instead of opening it with $EDITOR
<jgart>😺️
<apteryx>Isn't 'guix edit' sufficient?
<apteryx>the line seems unclear of where to stop, once we have 'guix edit', 'guix cat', 'guix email' ;-)
<jgart>'guix fmt' :()
*apteryx mildly annoyed at GNOME-Boxes for randomly corrupting a VM image every now and then
<jgart>guix fmt instead of calling indent-code.el ;)
<apteryx>I'd prefer a guile-fmt tool that is shipped with guile, or guile-lib. Something general.
<apteryx>but I like the idea of having better formatting options
<apteryx>auto-formattting
<jgart>yup, that would be cool to have it in guile instead of elisp
<char>apteryx: I like to use gnome-settings. The usual interface is not there; it just asks for a file that never works. https://paste.debian.net/1203418/
<jgart> https://github.com/bqv/rc/blob/live/scripts/scmfmt
<jgart>found that the other day
<apteryx>char: does that work? I think network-manager-service-type should already be part of desktop-services; so you want to modify it instead of adding a new instance of it
<apteryx>char: in my main config, I use this: https://paste.debian.net/1203419/
<char>I'll try that. I shouldn't have to restart right, just sudo herd restart networking?
<char>and system reconfigure of course
<apteryx>for some reason I had to restart the last time I messed with network-manager plugins. It had something to do with the plugins being made available through some environment variable which would only be refreshed on a restart of shepherd, IIRC. Not great.
<char>So, anyone working on gnome 40?
<raghavgururajan>> char‎: So, anyone working on gnome 40?
<raghavgururajan>I am, but also looking for help. I have to update dependencies of gnome-desktop first. It would be great if you help with this (https://issues.guix.gnu.org/48554).
<raghavgururajan>*if you can
<raghavgururajan>Tests doesn't pass.
<char>I tried to help you before, but I'm a bit more familiar with guix now and no longer working out of a virutal machine, I'll see what I can do.
<char>raghavgururajan: What branch are you working off of?
<raghavgururajan>> char‎: I tried to help you before, but I'm a bit more familiar with guix now and no longer working out of a virutal machine, I'll see what I can do.
<raghavgururajan>Thanks! That means a lot.
<raghavgururajan>chat: wip-gnome branch.
<char>how come arch repositories are updated with gnome (and others) so quickly. Is it just pure person-power?
<drakonis> https://github.com/cookiengineer/audacity aight it is time to replace audacity with the telemetry free fork
<The_tubular>Is there a equivalent to gentoo patches for guix ?
<The_tubular>Also, I agree with drakonis but we should leave it as is for a few days see how the situation develops and see if that fork will actually be maintained
<drakonis>gentoo patches for guix?
<The_tubular>I don't really know how to explain it, my english is not that good, but here's an example : https://gitweb.gentoo.org/repo/gentoo.git/tree/app-shells/bash/files/bash-5.0_p11-disable_priv_mode.patch
<The_tubular>Basically you change upstream code before compiling it
<char>The_tubular: not sure if related https://guix.gnu.org/manual/en/guix.html#Package-Transformation-Options --with-patch option?
<The_tubular>I think this is it : --with-patch=package=file
<The_tubular>I'll have to test it out later for sure!
<The_tubular>Thanks
<The_tubular>lol, sorry char I just realized I stopped reading your message after the link lol
<char>apteryx: thanks, you network configuration seems to work for me!
***char_ is now known as char
***char_ is now known as char
***cadmium.libera.chat sets mode: +o ChanServ
<apteryx>glad you got it working!
***char_ is now known as char
<tissevert>hello guix : )
<jgart>hello!
<bricewge>Hello Guix!
<bricewge>Yesterday I tried to start Xorg without root (without login manager nor suid bit) but didn't succeed. Does someone know how to do that?
<bricewge>There are a few open issue on the bug tracker about that already
<civodul>Hello Guix!
<efraim>hello!
<drakonis>hello
<raghavgururajan>Hello Guix!
<raghavgururajan>How to allow network-access inside `guix environment --pure`?
<maximed>raghavgururajan: try "guix environment --help". IIRC, there is some option for that, but I don't recall its name
<maximed>--network
<zap>hello hello
<zap>does it restrict network access though? I thought its only the case with --container flag.
<zap>this works: guix environment --pure --ad-hoc curl nss-certs -- curl gnu.org
<raghavgururajan>maximed: I did try -n (--network). No luck.
<raghavgururajan>Also, it seems to be used along with -C, which ic for container.
<zap>raghavgururajan: hye I think it should work. --pure only fiddles with your environment it doesnt do anything with namespaces as far as i know.
<civodul>hey ho!
<raghavgururajan>zap: Most programs work, but except curl.
<civodul>evaluations on core-updates are breaking because of texlive-* failures :-/
<raghavgururajan>ERROR[#01]: Couldn't curl website. Please check your network and try again.
<raghavgururajan>> zap‎: this works: guix environment --pure --ad-hoc curl nss-certs -- curl gnu.org
<raghavgururajan>hmm.,
<zap>raghavgururajan: maybe something to do with certs? (im gusessing now) try adding nss-certs
<maximed>civodul: "guix build libdatrie" works for me (that's the cached failure)
<maximed>but the derivation is different.
<raghavgururajan>zap: `guix environment --pure --ad-hoc curl nss-certs -- curl gnu.org` works. But `guix environment --pure --ad-hoc ytfzf nss-certs -- ytfzf` doesn't (ERROR[#01]: Couldn't curl website. Please check your network and try again.).
<soheil> http://issues.guix.gnu.org/49164
<zap>raghavgururajan: ha. then I guess problem is on ytfzf side. dont know
<civodul>maximed: i cleared the cached failure and rebuilt libdatrie (yuk!), so that one is "fine"; now the problem is texlive-*: https://ci.guix.gnu.org/eval/57692/log/raw
<civodul>there's the beginning of a workaround at https://issues.guix.gnu.org/48064
<civodul>i hope we can get that workaround committed soon
<civodul>because i don't feel like merging patch series on core-updates if we can't get feedback from CI
<maximed>when building the "core-updates" evaluation, are packages from "core-updates" used as dependencies for that version of "guix"?
<maximed>otherwise, I don't see why there would be ‘evaluation failures’, and why committing a work-around to core-updates would help
<maximed>civodul: Would it help if I applied <https://issues.guix.gnu.org/48064#15> locally (on top of core-updaes) and run ../verify-texlive-packages.sh?
<maximed>(and verify it succeeds)
<rekado_>civodul: using pdftex is a reasonable workaround, but doesn’t this have implications for Unicode support? luatex supports Unicode out of the box, but I’m not sure about pdftex.
<rekado_>I hope this won’t cause the return of encoding/decoding problems
<civodul>maximed: yes, core-updates evaluations use packages from core-updates
<efraim>to build linux-libre-riscv64-generic am I supposed to pass --target=riscv64-linux-gnu?
<civodul>maximed: yes, hadn't noticed this patch, but that's the one!
<civodul>rekado_: i don't know
<efraim>I've been getting glib-networking test failure on core-updates
<civodul>rekado_: could we use pdftex selectively for just these packages?
<maximed>civodul: Did you mean: ‘use luatex just for those package that need it for its unicode support’?
<efraim>with --target=riscv64 I got an output that makes more sense. I wonder if that's something that needs to be fixed
<efraim>we do have a couple of kernels that are architecture specific, it doesn't make sense for the CI to build them for x86_64
<civodul>maximed: i'm not sure what i mean :-) here we use luatex just to build .sty from .dtx (IIUC)
<civodul>can this have a drawback on *users* of the packages, rekado_?
<civodul>efraim: yes, that seems weird
<maximed>texlive packages (someimes? usually?) have some (PDF, ps) documentation. If those use Unicode, there might be a problem
<civodul>right, but then it's "only" for documentation
<maximed>but malformed documentation isn't a huge problem I suppose (though still suboptimal)
<civodul>yeah
<maximed>I dunno if it has impact on user. I'm not familiar enough with how pdftex & luatex works
<maximed>*user -> the user
<apapsch>the (guix records) module is super useful imho, I find myself copying it to other repositories
<apapsch>if there's one thing that should be broken out of guix it's this
<maximed>apapsch: You could create a "guile-guixy-records" package
<civodul>maximed, rekado_: anyway, given the dire situation, i'm willing to apply https://issues.guix.gnu.org/48064#15 (switching to pdftex) until we have a luatex fix
<maximed>I'm inclined to agree, but maybe add a ‘TODO comment’ to "(guix build-system texlive)" that "luatex" is actually preferred? With a link to https://issues.guix.gnu.org/48064
<apapsch>maximed: Nice name, I will look into it :-)
<raghavgururajan>zap: It seems I also had to --ad-hoc curl. Looks like it has its own env-vars.
<civodul>maximed: yes, i agree about adding a comment
<raghavgururajan>efraim: glib-net tests fail?
<rekado_>civodul: no objections to switching to pdftex. There are cases where we don’t actually build the documentation from source, and others where we don’t distribute the built documentation, so the impact there would be small.
<efraim>yeah, glib-networking. It'll take me a while to build out to it though on core-updates. I'll let you know if it's still failing for me
<rekado_>the generated files *should* be identical, but there have been *some* instances in the past where encoding problems messed things up.
<rekado_>so I guess we should just keep an eye on things.
<civodul>rekado_: alright, we'll see how it goes
<raghavgururajan>efraim: I see. I recently made a commit for glib-net, but it shouldn't interfere with tests though. Okay, let me know.
<civodul>pushed!
<efraim>raghavgururajan: it was failing for me before your test too
<raghavgururajan>efraim: I see. If you rebuild, let me know the error message.
*maximed afk
<pineapples>o/
<pineapples>I'm attempting to use the `superseded' property in my package definition but the build results in an error saying that I've used an invalid field specifier. Any idea what I may be doing wrong?
<maximed>pineapples: where are you putting 'superseded'?
<maximed>It seems like that property must be put in the 'properties' field
<pineapples>maximed: At the end of the definition, in the `properties' field
<maximed>(package (name "bla-bla") ... (properties `((superseded ,next-version))))
<maximed>pineapples: that seems about right. Could you paste it? (paste.debian.net)
<maximed>(including the error message (and backtrace, if any))
<pineapples>Could it be possible that the `properties' field doesn't play nice with the fact the package definition inherits another package?
<pineapples>I'll see what I can do. Give me a while
<pineapples>maximed: Nevermind. Forgot to close the `arguments' field. :D TLDR: A single parenthesis was missing
<pineapples>Thank you for your willingness to help anyway :)
<brendyn>I discoverd that adding (snippet '(begin #t)) can break a package
<pineapples>By the way, where do I find all the available values that the `properties' field accepts?
<maximed>pineapples: there isn't such a list AFAIK
***iyzsong- is now known as iyzsong
*raghavgururajan wonders how to use patch-files inside phases
<maximed>if you want to start a list: ‘git grep -F 'package-properties' guix’
<pineapples>maximed: Thanks! I was going to scout Guix's code repository by hand, but this is infinitely better
<maximed>pineapples: maybe you can write a 'Package properties’ subsection of ‘8.2 Defining Packages’, documenting some package properties?
<maximed>(with cross-references ideally: 'upstream-name' would cave a cross-reference to ‘9.6 Invoking ‘guix refresh’)
<maximed>civodul: some build failures on core-updates are cross-compilation problems. E.g., https://ci.guix.gnu.org/build/653883/log/raw is a cross-build failure for readline. Problem is %build-inputs is unbound
<maximed>maybe a good idea to (a) re-introduce %build-inputs, or (b) apply relevant patches from the ‘wrap-program’ series?
<maximed>civodul: I'll try reintroducing %build-inputs
<munksgaard>Hi guix!
<maximed>Hi munksgaard
<munksgaard>What would it take to bump the default ghc to 8.8? I mean, in addition to changing https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/haskell.scm#n660
<munksgaard>Are there any packages that depend on using 8.6?
<munksgaard>I want to build a package (futhark) that depends on 8.8, but https://issues.guix.gnu.org/49326 is making life difficult for me. It would be easier (for me) to move the default to 8.8, which is two years old at this point.
<maximed>munksgaard: I wouldn't know. You can try moving GHC to 8.8, build random haskell packages and see what breaks.
<maximed>depending on the number of Haskell packages, this may be something for core-updates or staging
<munksgaard>maximed: There are quite a few haskell packages, I think :-/
<maximed>Maybe, after testing a few Haskell packages, ‘we’ could create a ‘ghc-update’ branch, and let 'ci.guix.gnu.org' build that branch?
<maximed>and when there are no haskell-related build failures there, and substitutes are available for everything, merge it?
<munksgaard>Sounds good to me. I'll try to get around to it later this evening.
<efraim>civodul: is posix_spawn buggy on all non-Intel systems or only on armhf and aarch64?
<pineapples>maximed: I am sorry for the late reply but I received an emergency call and had to leave my system for a while. Anyway, as I was going to say before I got interrupted, I will think about it but I can't promise anything; my writing style is—for the lack of better words—dull or/and "unimaginative", and the knowledge of Guix itself and its docs rather limited
<civodul>PurpleSym: hi! any hints on https://issues.guix.gnu.org/47018#5 ?
<civodul>howdy mothacehe! :-)
<maximed>civodul: ^^ (‘civodul: some build failures on core-updates are cross-compilation problems. E.g., https://ci.guix.gnu.org/build/653883/log/raw is a cross-build failure for readline. Problem is %build-inputs is unbound
<maximed>^ maybe a good idea to (a) re-introduce %build-inputs, or (b) apply relevant patches from the ‘wrap-program’ series?
<maximed>maybe a good idea to (a) re-introduce %build-inputs, or (b) apply relevant patches from the ‘wrap-program’ series?
<maximed>^ civodul: I'll try reintroducing %build-inputs
<maximed>currently building cross-gcc ...
<mothacehe>hey civodul!
<sneek>mothacehe, you have 1 message!
<sneek>mothacehe, nckx says: …it did however uncover some uncommitted test changes to choose-services which I will commit soon ☺ Sorry!
<bmk>Hello! Installed GuixSD like, two days ago, and I'm having a bit of an issue. How do I get cc as an alias for gcc? I tried by doing one in /usr/bin but that didn't seem to work
<bmk>libtool is complaining that it can't find cc
<maximed>bmk: Where does this error occur?
<bmk>I'm trying to compile the vterm module for emacs
<maximed>When building a package? (guix build bla-bla)
<bmk>Hang on, let me get a paste
<bmk>is there a service that this channel prefers?
<bmk>for pastes, I should say
<maximed>paste.debian.net
<bmk>I just remembered that I never installed a web browser, give me a second
<bmk>eww didn't seem to work
<maximed>There are some tools for sending pastas from a terminal, though I never use those
<bmk>apologies, I'll just dump three lines
<maximed>bmk: IceCat should work, though it is a bit large
<bmk>[ 33%] Performing build step for 'libvterm'
<bmk>CC src/encoding.c
<bmk>/home/barry/.guix-profile/bin/libtool: line 1766: cc: command not found
<maximed>bmk: I think I now what's going on ... let me verify
<maximed>Is this the source repo you're building from: <https://github.com/akermu/emacs-libvterm>?
<bmk>yeah, that's the one, the melpa package clones it I believe
<maximed>if it used was a makefile instead of cmake I would know what to do. But I don't know cmake well, so some generic advice:
<maximed>‘cc’ does not exist on Guix. Normally, the build scripts should autodetect whether "gcc" or "clang" or the like is available (or hardcode one or the other)
<bmk>Yes, that's what I thought too.
<maximed>can you tell "cmake" to use "gcc" (or "clang", if you prefer that)?
<maximed>I don't know cmake well enough ....
<bmk>I probably can, although I'm not sure how I'd go about it
<maximed> is downloaded from the Internet?
<PurpleSym>civodul: Hey :) I haven’t looked at it further, because I concluded it wasn’t caused by my patch directly. But I can take another look later this week.
<maximed>* wait, what, is downloaded from the Internet?
<bmk>The melpa package contains the elisp which has a function to compile the module
<maximed>Guix has a "libvterm" package". So maybe install "libvterm", so the build script won't try to download it?
<bmk>that'd probably do it
<bmk>That worked!
<bmk>Now to find the next problem! Have to try pdf-tools in emacs too
<bmk>guix search autoreconf
<bmk>that was not my vterm
<maximed>bmk: autoreconf is found in the "autoconf" package, I think
<maximed>not sure what you mean ith ‘that was not my vterm’
<bmk>I typed a command offhandly into ERC instead of my vterm
<PotentialUser-31>Hi i am having a problem with openvpn.
<PotentialUser-31>in the config file use-service-modules vpn dns network are present
<PotentialUser-31>but on startup I get the error:
<PotentialUser-31>sudo openvpn /etc/openvpn/riseup.ovpn
<PotentialUser-31>Options error: --up script fails with '/etc/openvpn/update-resolv.conf': Permission denied (errno = 13)
<PotentialUser-31>Options error: Please correct this error.
<PotentialUser-31>Use --help for more information.
<maximed>PotentialUser-31: what is the output of "ls -l /etc/openvpn/update-resolv.conf"
<maximed>if this is what I think it is, it will start with /gnu/store/...
<bmk>also, thankyou maximed
<maximed>sneek: later tell civodul: Reintroducing %build-inputs when cross-compiling allows "guix build grep --target=aarch64-linux-gnu" to succeed on core-updates. Running the binary under "qemu-aarch64" works. I'll send a patch to guix-patches@
<sneek>Got it.
<bmk>okay, at least I have a mostly-usable browser
<bmk>I typically use librewolf because I have to use drm content from time to time, but this will do until I can write a package for it
<munksgaard>What does #$output in the guile code mean?
<maximed>munksgaard: it is a G-exp thing
<munksgaard>maximed: Damn. I skipped that chapter...
<maximed>It is a G-exp denoting the store path where the package that is being build ends up
<maximed>#~, #$, #+, #$@ and #+@ are the other G-exp things
<maximed>sneek: later tell civodul: A patch %build-inputs re-introducing %build-inputs, fixing some failures on https://ci.guix.gnu.org/jobset/core-updates: <https://issues.guix.gnu.org/49416>
<sneek>Okay.
<maximed>sneek: later tell civodul: Other people can comment and/or apply too of course. Just sending you a sneek-mail because you have been fixing core-updates lately
<sneek>Got it.
<PotentialUser-31>maximed: Oh, I didn't think to write chmod + x, thanks) Only now I have another problem, vpn started but I get "2021-07-05 18:35:09 WARNING: Failed running command (--up / - down): could not execute external program
<PotentialUser-31>2021-07-05 18:35:09 Exiting due to fatal error "
<danrobi70>+
<danrobi70>my bad
<raghavgururajan>sneek, later ask nckx: Any luck with bitmask? :)
<sneek>Okay.
<maximed>PotentialUser-31: what was the output of "ls -l /etc/openvpn/update-resolv.conf"?
<maximed>If it was /gnu/store/..., you shouln't chmod it. In fact, if you're on Guix System, the store should be unwritable even to root (unless root is playing tricks), so chmod +x /etc/openvpn/update-resolv.conf should fail if it is a symlink to a file in the store
<maximed>(If it isn't a file in the store, then "sudo chmod +x ..." is probably fine, but I'm not familiar with the openvpn service of guix)
<civodul>making slow but steady progress: https://ci.guix.gnu.org/jobset/core-updates
<sneek>civodul, you have 3 messages!
<sneek>civodul, maximed says: Reintroducing %build-inputs when cross-compiling allows "guix build grep --target=aarch64-linux-gnu" to succeed on core-updates. Running the binary under "qemu-aarch64" works. I'll send a patch to guix-patches@
<sneek>civodul, maximed says: A patch %build-inputs re-introducing %build-inputs, fixing some failures on https://ci.guix.gnu.org/jobset/core-updates: <https://issues.guix.gnu.org/49416>
<sneek>civodul, maximed says: Other people can comment and/or apply too of course. Just sending you a sneek-mail because you have been fixing core-updates lately
<maximed>civodul: powerpc64le cross-compilation fails (‘bug#49417: glibc uses "objcopy", but seems to need "TARGET-objcopy" [core-updates]
<maximed>I'll investigate that
<apteryx>updating Guix from Feb 25 (a2ece4d): guix pull: error: Git error: failed to resolve path '/var/lib/jenkins/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq': No such file or directory
<apteryx>seems to proceed further on a 2nd run
<apteryx>yep, it worked. Perhaps the guile-git fixed as of late, or some rough migration step somewhere.
<civodul>maximed: i have a fix! :-)
*civodul is head-down on core-updates
<efraim>raghavgururajan: glib-networking test is still failing for me on core-updates, 5/6 connection-gnutls TIMEOUT 30.03s killed by signal 15 SIGTERM, looks like timeout after ok 15 /tls/gnutls/connection/client-auth-request-none
<efraim>raghavgururajan: I traced it as far as here last time: https://gitlab.gnome.org/GNOME/glib-networking/-/blob/2.68.1/tls/tests/connection.c#L2992
<maximed>civodul: great, now I don't have to wait minutes for "guix environment glibc --ad-hoc autoconf@2.69" to complete ... (I'm on a spinning disk and installing a package in a profile of 138 packages ...)
<civodul>apteryx: this issue was fixed by baf0a4288264098ede43e4f7cd099a29fcf35be4 (June)
<civodul>in the meantime, you can remove the cache
<maximed>(some optimisations would be nice)
<civodul>maximed: seconded! it would be great if several of us could look into specific performance issues
<civodul>for profile.drv, it may be tricky to do better, but we have to try
<civodul>you're "lucky" to be using a spinning disk, which makes you a good candidate to profile it :-)
<maximed>civodul: looking at "htop", I see (approximated, the percentages are not all the same) PSI Full I/O 70% 70% 70%
<maximed>(now it's 50% or so, & making grafts)
<maximed>maybe grafting and profile generation could be use multiple cores, processing separate files concurrently? That might help bringing the I/O to 100%
<maximed>I think I've a nice idea that should reduce grafting time a lot, at cost of package building taking longer
<maximed>Basically, don't scan for references & replace them. Instead, let each package output have a file, say, "reference-locations" containing a lists of file names and byte ranges where a store path can be found
<efraim>I've wondered about using bsdiff to create the replacement pckage when we have grafts
<maximed>so the grafting code could just copy everything that isn't a store path
<maximed>and maybe use fancy syscalls like "copy_file_range"
<maximed>and exploit copy-on-write?
<boeg>what do i need to be able to require a package in emacs installed with guix package manager? I have added the load-path as well as called guix-emacs-autoload-packages, but the package i have installed is not autoloaded and i cannot require it
<maximed>boeg: in case of magit: "guix package -i emacs emacs-magit" should do it
<maximed>maybe you need to log out and in again?
<maxwell_TGAP>Is it possible to use the sticky bit on guix, if your not supposed to mess with the file attributes of anything in the /gnu/store then would you simply have to copy it out into ~/bin or something?
<boeg>maximed: hmm, ill try to log out then
<maximed>boed: sometimes, for a package installation to take effect, that's required (such that all environment variables are set)
<boeg>right
<maximed>maxwell_TGAP: yes, just copy the relevant files out of the store, then you can fiddle with file attributes
<maximed>is this for "setuid / setgid" stuff?
<boeg>maximed: hmm, no luck
<boeg>maximed: do you have it set up, and do you have your dotifles online so i can take a look?
<maximed>civodul: I do not yet see the objcopy fix on savannah
<boeg>i must be doing something wrong
<maximed>boeg: I have emacs set up, and can use magit (you can try "magit-status" after installing magit, it should work)
<maximed>I'll paste my .emacs
<maximed>(It's fairly minimal)
<boeg>well, i have emacs set up, but have until now used emacs for instlaling packages, but want to try using guix and have installed emacs-vterm but it doesnt "register"
<maximed>boeg: <https://paste.debian.net/1203472>
<maximed>I never use elpa.
<boeg>maximed: is that your init.el?
<boeg>looks like something else
<maximed>boeg: it's .emacs
<apteryx>civodul: ah, thanks
<maximed>I don't think I have an init.el?
<apteryx>(also for diving into core-updates :-))
<boeg>maximed: oh, alright
<boeg>but is that your .emacs then?
<boeg>looks like something else
<boeg>but alright
<boeg>anyways, have to go, thank you for your help
<maximed>sneek: later tell civodul: I don't see the powerpc64le objcopy fix yet on savannah
<sneek>Okay.
<raghavgururajan>maximed: Maxime Devos?
<raghavgururajan>I was told the nick is mdevos. :)
<apteryx>perhaps a freenode -> libera.chat discrepancy ;-)
<raghavgururajan>Ah. ;)
<apteryx>mmh, I'm a bit puzzled by "guix time-machine: error: could not authenticate commit 7f580c27daa5076f1961acabe4e6b4c7b17763c3: key ACC2 3BA0 59F7 CCF4 08F0 43AD 442A 84B8 C70E 2F87 is missing" when attempting to use 'guix time-machine --url=https://gitlab.com/Apteryks/guix.git --branch=add-deb-pack-format [...]'
<apteryx>the guix running the time-machine command was freshly updated
<civodul>apteryx: most like that repo's 'keyring' branch is lagging behind
<sneek>civodul, you have 1 message!
<sneek>civodul, maximed says: I don't see the powerpc64le objcopy fix yet on savannah
<civodul>maximed: oh wait, i must be confused; what's the powerpc64le objcopy fix?
<civodul>doing better, but still a lot of cross-compilation failures: https://ci.guix.gnu.org/eval/57846/dashboard
<civodul>oh, powerpc & objcopy: https://ci.guix.gnu.org/build/654293/log/raw
<civodul>damnit, looks like we need the same fix as for objdump :-/
<Noisytoot>When I try to use gcc (after installing gcc-toolchain) to compile a hello world program, I get "ld: cannot find crt1.o: No such file or directory
<Noisytoot>ld: cannot find crti.o: No such file or directory
<Noisytoot>collect2: error: ld returned 1 exit status"
<Noisytoot>on Guix System
<Noisytoot>How can I fix it?
<apteryx>did you source your profile etc/profile file?
<maximed>civodul: I wrote a message ‘TARGET-objcopy blabla’, and you wrote a message ‘maximed: i have a fix!’, so I assumed you had a fix for the ‘TARGET-objcopy bla-bla’
<maximed>Now I'm wondering what the fix you were talking about actually was ...
<Noisytoot>no. I am using fish, which can't source the profile (which is designed for bash). when I source it in bash, it works
<maximed>Noisytoot: (a) log out and in again, or (b) start bash, source the profile, start fish inside bash?
<Noisytoot>bash -c 'source "$GUIX_PROFILE/etc/profile"; exec fish' works when I install fish into my profile
<podiki[m]>maximed and munksgaard: regarding a ghc branch, would it make sense to make it a more general haskell updates branch? munksgaard and I have hit some bugs (and have some patches) that would affect haskell-build-system. given the number of affected packages for this change, that might be helpful. I'd want to update a lot of haskell packages too, but maybe that should wait
<podiki[m]>(referring mostly to: https://issues.guix.gnu.org/49199 and https://issues.guix.gnu.org/49418)
<maximed>podiki: Makes sense to me
<Noisytoot>but I can't add that to ~/.config/fish/config.fish because it causes an infinite loop
<maximed>Noisytoot: it may be a good idea to teach guix to generate environment variables in a format appropriate for fish (/etc/fish-profile or something)
<podiki[m]>maximed: great, just let me know what you need or what I can do. Much as I like just compiling ghc over and over... :P
<maximed>podiki: I'm not hacking on ghc in guix
<maximed>Also, someone else would have to actually set up the branch, I'm no committer
<podiki[m]>I just mean when making changes and then needs build ghc, it takes a while
<podiki[m]>maximed: gotcha. I'll add a note on the patches/bugs that it would be best to set up a testing branch, and then I guess wait? (still very new here)
<maximed>podiki: In case I wasn't clear: one of the benefits of such a branch is that you can let ci.guix.gnu.org build things for you, and temporarily breaking things isn't a big problem (as long as things are fixed before it is merged in master, stating or core-updates)
<podiki[m]>maximed: yes, understood, that's why I was happy I won't have to rebuild everything. It is hot where I am, glad to save some cpu cycles and the free heat it provides
<maximed>So, if you modify ‘ghc-package-with-many-dependents’, you can just locally build that package and one or two dependents, and look at <https://ci.guix.gnu.org/jobset/core-updates> to see if you broke stuff (replace 'core-updates' with 'the-ghc-branch')
<maximed>Best is if it's right on the first try though (-:
<podiki[m]>gotcha
<podiki[m]>maximed: can you point me where I should ask about getting a branch made (and pushing to it)? email to the guix-devel list?
<maximed>podiki: I would mail to guix-devel
***smarton is now known as brown121407
<podiki[m]>will do, thanks
<Noisytoot>sneek: later tell maximed: Where's the code that generates ~/.guix-profile/etc/profile?
<sneek>Okay.
<Noisytoot>sneek: botsnack
<sneek>:)
<efraim>15 gnulib tests failed on core-updates on findutils-boot0 on riscv64-linux
<iskarian>civodul, regarding your patch removing input labels: was there already a discussion about handling ("a.patch" ,(search-patch "a.patch")) in inputs?
***iskarian is now known as Guest8584
***cadmium.libera.chat sets mode: +o ChanServ
***iskarian is now known as Guest2833
<excalamus>I'm setting up the Emacs daemon following a thread on the mailing list: https://lists.gnu.org/archive/html/help-guix/2019-11/msg00148.html I have services.scm and init.scm defined. I can call `shepherd -c ~/.config/shepherd/init.scm` and the service starts. I can kill the terminal and connect a client with `emacsclient -c`. Trouble is, I can't figure out how to start the service on boot.
<drakonis>excalamus: declare it as a service on your system config
<drakonis>at least until guix home arrives and you can do it in a per user basis
<drakonis> https://lists.gnu.org/archive/html/help-guix/2021-07/msg00007.html this sounds like unicode issues
<maximed>I sent a patch optimising profile generation somewhat. In case someone is interested: <https://issues.guix.gnu.org/49421>
<boeg>Anyone here installing emacs packages with guix package manager? I have added "(add-to-list 'load-path (expand-file-name "~/.guix-profile/share/emacs/site-lisp"))" to my init.el and call `guix-emacs-autoload-packages` but it doesnt work, i have to point directory to a package directory to make it work like this: "(add-to-list 'load-path (expand-file-name "~/.guix-profile/share/emacs/site-lisp/magit-xxxxxx"))" and hten it works, but it
<boeg>cannot be right that I have to do that for all packages? It looks to me as if `guix-emacs-autoload-packages` isn't doing its job to find all the packages in the directory. Maybe I am doing something wrong?
<maximed>boeg: What happens if you delete .emacs and ~/.config/emacs?
<maximed>(Make a back-up first)
<boeg>well then my emacs doesnt work :D
<maximed>I never modified these, but I can still use emacs just fine
<Noisytoot><Noisytoot> sneek: later tell maximed: Where's the code that generates ~/.guix-profile/etc/profile?
<boeg>well, emacs works, but not *my* emacs
<boeg>:P
<Noisytoot>according to https://logs.guix.gnu.org/guix/2021-07-05.log, sneek didn't deliver that message
<boeg>ill give it a try
<maximed>boeg: did you install emacs via guix, or from a foreign distro
<boeg>maximed: via guix
<maximed>Noisytoot: (guix profiles), and some other location I think
<boeg>i'm running guix the distro
<maximed>boeg: Something you could try (dunno if it will work): guix environment --pure --ad-hoc emacs emacs-magit -- emacs
<maximed>(that's without the .emacs and ~/.config/emacs)
<maximed>That will run it in a ‘pure environment’, where the list of environment variables should be minimal ...
<boeg>it should loads my init.el
<boeg>it still*
<maximed>(I have no idea what's going wrong, so I'm trying to minimise the variables here)
<boeg>yeah
<boeg>I have emptied my .emacs/init.el (and have no .config/emacs to only contain this:
<Noisytoot>ixmpp, How do you source ~/.guix-profile/etc/profile from fish (automatically)?
<boeg> https://paste.debian.net/1203501/
<maximed>also, keep in mind I don't really know what ‘autoloading’ in Emacs, instead I'm trying to make "magit-status" work
<boeg>maximed: ^
<boeg>yeah
<maximed>also, in my case, .emacs is an emacs-lisp file, and not a directory
<boeg>yeah
<boeg>so ... as I understand guix-emacs-autoload-packages, it should look at the load-path and find the path with the guix package manager packages and add each packages path to the load path so it can be loaded, right?
<maximed>boeg: I think so? But it should be run automatically, you shouldn't need to add it anywhere ...
<boeg>i shouldnt?
<boeg>I just found some tutorial only that said to do that
<boeg>maximed: how should it be run automatically?
<boeg>maximed: also, where is that function defined?
<boeg>like, where is it from?
<maximed>boeg: It should automatically be run automatically, I think? I don't think it is something you're supposed to run manually automatically
<boeg>hmm but where does it come from?
<boeg>has it been patched in or something in the guix distributed emacs?
<maximed>I'd need to look
<maximed>It is documented in the manual ... Additionally, autoload definitions are automatically evaluated at the
<maximed>initialization of Emacs, by the Guix-specific
<maximed>‘guix-emacs-autoload-packages’ procedure. If, for some reason, you want
<maximed>boeg: "guix edit emacs"
<maximed>you'll see "guix-emacs.el" there
<boeg>right, okay
<maximed>and the function call is patched in into "site-start.el"
<boeg>alright
<maximed>FWIW, what does "echo $EMACSLOADPATH" say?
<maximed>and "ls -l $EMACSLOADPATH"
<maximed>I mean "ls $EMACSLOADPATH"
<boeg>first says: /run/current-system/profile/share/emacs/site-lisp
<boeg>second: guix-emacs.el guix-emacs.elc site-start.el site-start.elc subdirs.el
<maximed>boeg: where did you install emacs? Added to the system profile (the packages field of 'operating-system'), or in your user profile (guix package -i emacs ...)
<maximed>It looks like the former is the case
<boeg>indeed
<boeg>is that the problem?
<boeg>or ... why is that a problem, actually :P
<maximed>boeg: it is or isn't, depending on what you're trying to do
<boeg>just .. use emacs
<boeg>but i see that subdirs.el is in both that and my .guix-profile/..../site-lisp but guix-emacs.el isn't
<boeg>as well as site-start.el
<maximed>two things that should 'just work': "guix package -i emacs emacs-magit", or add both 'emacs' and 'emacs-magit' to the 'packages' field of operating-system
<maximed>I'd recommend the former because it doesn't require sudo or the like
<maximed>mixing things from 'operating-system' and the user profile can easily become complicated
<boeg>right, i see
<maximed>so, maybe do "guix package -i emacs emacs-magit" and log out and in again?
<boeg>actually, ill reconfigure instead
<boeg>add the packages to my config
<boeg>i usually only use `guix install` for things until i am sure they are "staying", then i move them to my config.scm
<maximed>If you prefer declarative "config.scm"-like things above imperative "guix install"-like things, you might be interested in manifests and guix home-manager
<boeg>i do - can you give me a link to the former, i think ill be able to search out the latter
<maximed>manifests are like the 'packages' field of 'operating-system', but for user profiles
<excalamus>drakonis: I'm a bit confused about how I would add the service to my system config, or rather, how that would work. Would you suggest defining the service directly in the system config file? Or instead call (load "...") on the .config/shepherd/init.scm? I find both confusing because I expect Shepherd to automatically search some dirs. In fact, the third paragraph of (shepherd) Jump Start shows just that, /etc/shepherd.scm and
<excalamus>$HOME/.config/shepherd/init.scm should be searched on start. The latter is searched when Shepherd is started as a normal user, so I suppose that explains why my current setup doesn't work. I assume that Shepherd is started at boot by a superuser. Anyway, if I throw my user-made emacsd in (services (append (list ...))), how would the system know about it?
<maximed>boeg: see --export-manifest in the manual and --manifest
<boeg>maximed: it "just works" now
<boeg>maximed: thank you
<maximed>sneek: later tell Noisytoot: also see (guix build profiles)
<Noisytoot>sneek seems to be down
<ix> https://hacks.mozilla.org/2019/04/fluent-1-0-a-localization-system-for-natural-sounding-translations/
<maximed> /quit
***o is now known as niko
<munksgaard>podiki, maximed: Good idea with the separate branch. I'd like to help out, but I'm not on guix-devel. How do I reply to the mail you sent?
<podiki[m]>there's a reply button on the guix-devel archives: https://lists.gnu.org/archive/html/guix-devel/2021-07/msg00026.html
<podiki[m]>(I don't think I'm on the list, but I'm guessing I'll get replies sent to the thread, though that hasn't been true of bugs/patches)
<ixmpp>did someone ping me in here a while back?
<ixmpp>sorry i think i missed it
<Noisytoot><Noisytoot> ixmpp, How do you source ~/.guix-profile/etc/profile from fish (automatically)?
<ixmpp>Noisytoot; ah. https://dev.fron.io/rc/blob/master/rc/home/leaf.scm#L-210
<ixmpp>also, https://dev.fron.io/rc/blob/master/rc/home/leaf.scm#L-201
<ixmpp>i have since switched to zsh, but that's not because it's better or anything
<ixmpp>i just had a very specific issue that seems less prevalant with zsh
<The_tubular>Anyone tried to run guix on arm devices like a rasberrypi ?
<munksgaard>podiki: It looks like that will just reply to you directly. I'll figure it out.
<podiki[m]>munksgaard: I guess that and have a cc: guix-devel@gnu.org? also not sure, generally I just read the lists so it is new to me too
<bmk>Okay: I may have fecked somethin' up here: Am I able to have GRUB not be encrypted (so grub can run without needing to unlock the / and /home partitions), and if so what would that look like in my system declaration
<bmk>I just realized I have no swap partition either: I'm gonna need a reinstall anyways
<Noisytoot>bmk, you can use a swapfile
<bmk>I could indeed
<bmk>But for some reason I've never liked doing it
<dstolfa>is there a way to use `guix time-machine` for bisecting a regression?
<bmk>it's not even a "oh I tried it once and it didn't work well"
<bmk>it's "ehhhh, I don't like the cut of this files' jib"
<bmk>okay, my real question then: How do I set the proper keylayout BEFORE decrypting /, so I can actually typemy passwords correctly
<drakonis>hmm, isnt that something you have to set up on the initrd?
<bmk>Okay; I think I confused my self
<bmk>alright
<bmk>so the problem is the initrd, the kernel, all that is on /
<bmk>as WELL as the keymaps and such
<bmk>so to boot, I need to enter the 2 passwords for / and /home twice
<bmk>first in qwerty, second in dvorak
<bmk>So I was thinking: can I tell guix to put it's stuff on /boot
<bmk>and relevant grub config so that that doesn't happen
<bmk>There's not altogether much in the manual about bootloaders
<drakonis>i'm sure it already puts it on /boot
<bmk>I've just checked: All that's there is grub's efi file, a font, the config, and some modules
<bmk>Guix certainly is presenting some interesting issues
<bmk>great fun
<drakonis>do you use efi?
<bmk>yes
<bmk>I should have mentioned, sorry
<drakonis>the efi file should be at /boot/efi though
<bmk>it is, I was browsing around as I was writing that one
<bmk>my bad
<zacchae[m]>bmk: The bootloader configuration has a `keyboard-layout` feild
<bmk>It does, but Grub can only load it after I type the password for root
<bmk>and /home
<zacchae[m]>are you sure about that? I know it's possible to get your bootloader to use any keyboard layout pre-password. I assumed guix would have that implemented by now
<zacchae[m]>I mean, why else would the bootloader have a keyboard-layout field?
<bmk>I'm devilishly sure: I've had the misfortune of getting really confused when booting
<maximed>zacchae: I can confirm I need to type boot passwords in qwerty for GRUB
<bmk>i
<maximed>maybe the 'keyboard-layout' field only has effect for _non-encrypted_ boo
<bmk>If it's a bug or not implemented I can deal with it for now
<zacchae[m]>I see. Well, glad I didn't try to set up full disk encryption then
<zacchae[m]>bmk: yes, I think it is one of those
<bmk>Shame
<zacchae[m]>oh there is a trick I used on my last build, though it's a little slow
<bmk>Do tell?
<zacchae[m]>change your keyboard layout to qwerty, then add a second key typing your password as if it were dvorak
<bmk>That is interesting
<zacchae[m]>The downside is that your system will check one entry at a time, but depending on the system it might not be noticable
<zacchae[m]>but can confirm it works as desired
<bmk>Takes about 3 ish seconds
<bmk>not the fastest in the world to check a key but not awful
<bmk>Who needs boot times of less than a minute :P
<bmk>I'll submit a bug report in the morning
<apteryx>how can I manually undo the read only mount that the daemon does, as part of a manual uninstallation?
<apteryx>(for /gnu/store)
<maximed>on Guix System, there is something like "herd stop cow-store"
<dstolfa>apteryx: sudo systemctl stop guix-daemon.service && sudo systemctl stop gnu-store.mount
<dstolfa>and then you can do whatever
<maximed>maybe there is something similar for foreign distros
<dstolfa>(i assume this is a foreign distro with systemd)
<apteryx>it is
<bmk>Ideally I'd just be able to tell guix to put the kernel and initrd and keymaps on /boot, and only have to enter the passwords during startup of the kernel
<apteryx>dstolfa: thanks, it worked!
<bmk>I should also start learning gnu stow
<bmk>Anyway: To you all, thank you for your help
<bmk>And to you all, Oiche mhaith, agus codladh samh
<bmk>forgive my dropping of the fadas, I realize now that I didn't enable a compose key