***rekado_ is now known as rekado
<EMax`0Mancer[m]>weird error trying to run a package installed from Nix on a Guix system: `/nix/store/.....-glibc-2.34-115/lib/libpthread.so.0: version `GLIBC_PRIVATE' not found (required by /gnu/store/....-glibc-2.33/lib/librt.so.1)` ***Xenguy__ is now known as Xenguy
***user3456_ is now known as user3456
<vagrantc>littlebobeep: most likely because nobody worked to implement it ***Xenguy_ is now known as Xenguy
<piethesailor>yeah I am still having issues with boxes.. Is there a set up process required before using? <vagrantc>seems like it ought to have a reference baked in for qemu if there's really no other way to use it <piethesailor>Virtualization extensions are unavailable.. check BIOS settings to enable? <vagrantc>might need to add your user to a group to access that file <piethesailor>hmmm.. I think your right. any good resource for doing that? <xelxebar>Cool. Then check out the supplementary-groups spec of your user definition. <piethesailor>I found this is system.scm, is that where I should be looking? <xelxebar>piethesailor: If system.scm is where your operating-system definition is, then yeah. <piethesailor>Ah, yes. Is it as simple as adding "kvm" to that quoted list? <xelxebar>Yeah, the kvm group should already be specified by default, so just adding its name there should work. Does on my system, at least :) <luishgh>hi guix, can you define dynamic package inputs with the new-style notation or do you need to keep using the old-style in this cases? <luishgh>for example: (inputs (list foo (if (bla?) bar))) <luishgh>i'm trying to convert neovim's inputs to the new style, but the code that chooses between luajit and lua5.1 depending on luajit supporting the target-architecture seems to have stopped working <luishgh>currently it is done this way: ("lua" ,(if (member (if (%current-target-system) (gnu-triplet->nix-system (%current-target-system)) (%current-system)) (package-supported-systems luajit)) luajit lua-5.1)) <luishgh>i assumed i just needed to put the part after the comma inside the list arguments and it would work, but now it tries to compile neovim with luajit on unsupported platforms <piethesailor>I have made changes to my user configuration but I'm not seeing any changes with rebbot <atka>piethesailor: did you run guix system reconfigure after you edited your config? <piethesailor>Is that command guix system reconfigure -k /path/to/system.scm? <atka>sudo guix system reconfigure /path/to/config.scm <atka>well depending what you have done since your last reconfigure it can <luishgh>oh, just managed to get it to work, never mind haha <lilyp>with rust, rust is more a downside than up ***daviid` is now known as daviid
<ZhuAisi[m]>How can I get rid of warning "pulled channel 'xxxxx' from a mirror of xxxxxx" <ZhuAisi[m]>And I edit the /etc/guix/channels.scm, now Guix warns that I'm using a mirror <FlaminWalrus>`guix pull` is giving me a non-forward update warning on the official channel...I'm moving to ffb616b69dced25b840f2e5178062072d89623eb from 42679e3f81a0fa61e225b1f6aa0e80e39625372f, and the URL is the usual GNU Savannah guix.git file. I don't think I've done anything wacky in the week since my last pull. Should I lose the tinfoil hat and force it? Did someone manage to get an unsigned commit through? <the_tubular>There was a thread about this on the mailing list FlaminWalrus <FlaminWalrus>the_tubular: and the thread references some IRC buzz. Now that they mention it, I do recall people speaking of guix pull woes about a week ago...I went ahead and did --allow-downgrades because the target commit matches master@savannah, and so can hardly be a downgrade attack. <the_tubular>Sorry, I remember seeing the thread a few days ago, people weren't talking about IRC IIRC <NinjaTrappeur>Hey! I'm trying to wrap my head around a confusing guix behaviour. I just built a new guix system (1h ago). I modified my system config to add a new package. After running guix system reconfigure, I'm up to download ~50MB of unrelated data to the package I just added. I'm also up to build guix-1.3.0rc2. Is there a way for me to understand what triggered that? A channel bump? How could I figure <NinjaTrappeur>Also, is there a way to explicitely pin my local system to a specific channel revision to prevent this kind of channel upgrade? <NinjaTrappeur>Answering my own first question: the part I was missing in my mental model were grafts. I was operating on a outdated guix channel, hence locally grafting a bit too much stuff :) <abrenon>I have certificate errors downloading HTTPS stuff from python within a container <abrenon>anything special package to include there ? (I tried nss-certs to no avail) <arjan>abrenon: I remember for a similar case also having to set some environment variable to point to the certs <NinjaTrappeur>abrenon: if your python software is based on requests, SSL_CERT_FILE is the one you're looking for. <NinjaTrappeur>Requests sadly does not use your system /etc/ssl/certs certstore by default :( <abrenon>NinjaTrappeur: thank you !! I'll try that <abrenon>doesn't seem to work, I've tried SSL_CERT_DIR too but : S <NinjaTrappeur>abrenon: :( Can you curl the same URL you're trying to download from your python software from within the container? <abrenon>hmmm I don't really know what URL it's trying to pull <abrenon>it's just NLTK downloading its stopwords <abrenon>I tried pre-downloading it and exporting NLTK_DATA but that didn't work either <abrenon>NinjaTrappeur: glad you answered your first question ! <abrenon>for the second one, I think the answer might be "inferiors" <abrenon>now I don't know if you can use inferiors for the rest of the system, but it may be a lead <abrenon>ahhh, interesting, if it is indeed the URL I pasted above, I can't download it with curl either <abrenon>ok, apparently I needed to both preserve the variable(s ?) from the environment and add nss-certs to the packages <abrenon>not sure why adding it in the first place wasn't enough but heh *abrenon has generated a docker with the appropriate python packages to send to a colleague because their python environment is utterly messy and nothing works as expected any longer <abrenon>but it would work only on one of the targeted architecture, right ? <abrenon>I'm stupid, so would the docker, no ? <abrenon>why did I ever think I could do this <allana>On a related note, I have been using guix pack -f docker for a bit now. Still unsure how to activate the profile but I do use the "--symlink" feature to make things from the profile findable. Is this the way? <qzdlns[m]>do we fire boot messages to a log? I saw a flash of a fsck sector warning and would like to check the message before jumping into a live CD -- I've ripgrepped /var/log and searched dmesg so far to no avail <NinjaTrappeur>Is there a way to save the channel revision I used (provenance in guix terms if I'm not mistaken?) to build a guix machine closure without having to rebuild guix locally (kind of expensive CPU-wise)? ***Guest28 is now known as davidl
<ZhuAisi[m]>Did ci.guix.gnu.org garbage collect its store? Is all history build result is still available? <jpoiret>NinjaTrappeur: you could transfer the guix pull profile along with its closure <jpoiret>a guix pull profile is a profile like any other, you can manipulate it with the same tools <zacts>hi has KDE been ported to guix? <zacts>have any components towards this goal been accomplished? ***bandali_ is now known as bandali
<davidl>mbakke: hi! just fyi: I sent you a pull request on github for the ganeti-instance-guix package. <ZhuAisi[m]>zacts: No body is interested in that. And packaging KDE is hard mode <jpoiret>in fact, DEs don't cooperate well with guix/nix <zacts>I wonder if you could mix guix with apt or something. like apt within guix. <zacts>like contain apt packages into guix somehow <jpoiret>they have to be patched a lot, patches which thus often break <mbakke>davidl: wow, impressive work! it looks like the PR got closed though, perhaps by accident? <jpoiret>zacts you wouldn't really be able to use those packages as is <mbakke>davidl: I probably won't have time to look at it until next week <zacts>could you use NixOS KDE packages tho? <jpoiret>well, if it's packaged by Nix, it's definitely packageable for guix <zacts>yeah, KDE is packaged by Nix <jpoiret>nix packages are often a good source of inspiration <davidl>mbakke: actually it's a late bug fix. I opened a new a few mins ago. Thanks! <zacts>can you directly use Nix packages with Guix? <jpoiret>you can use nix on guix, but they won't mix at all <jpoiret>just like you can use Guix/Nix on Debian/others <zacts>I just want a running KDE environment, but guix for everything else <zacts>like, couldn't I install Nix on-top of guixOS? <zacts>perhaps that could help with gradually porting KDE to guix too <jpoiret>you could definitely, but it'll be hard to have a boot-directly-to-KDE experience i think <abrenon>jpoiret: I thought the nix package had been removed at some point last year ? <zacts>also, how might guix work with something like kubernetes? <zacts>has i3wm/sway been ported to guix? <ZhuAisi[m]>with `guix deploy` you can deploy Guix system to many machines <ZhuAisi[m]>so I can run KDE on Guix and keep my hands clean 😂 <apteryx>abrenon: it was just the importer yes <zacts>can you manage and cluster running guix packages across nodes <zacts>like what would the equivalent to a docker container be for guix? <zacts>and can you manage running guix containers like that across nodes? <ZhuAisi[m]>For something like `bubblewrap` use `guix shell -C` <zacts>or does guix just deal with installing and managing packages (not running containers, but just packages) <zacts>is guix just a better apt, or is it more than that? <ZhuAisi[m]>To run a Guix system inside container, try `guix system vm` <ZhuAisi[m]>To package a OCI compatiable container image, use `guix pack` <jpoiret>k8s is go, so is a nightmare to package <zacts>yeah, but can guix provide similar functionality to what k8s does? <jpoiret>you can think of guix like a `package/system library`, which also happens to have a CLI interface <ZhuAisi[m]>Is k8s executable statically linked? If so, you can run it without any ELF hacks <jpoiret>we have our own container implementation in Guix <jpoiret>k8s and orchestrators in general are complicated software <zacts>how might guix containers differ from FreeBSD jails for example <allana>I have an ambition to package kubernetes, but I have not started and I am not sure if it's even possible (by me) <ZhuAisi[m]>So the difference is the difference between Linux namespace & FreeBSD jail? <jpoiret>guix containers use roughly the same techniques as docker (ie. linux namespaces) <jpoiret>i don't think guix runs on BSDs but i could be wrong <allana>I would actually love to see a "guix deploy" option for declaring kubernetes clusters. Maybe I will find out how far I can get in the coming months <zacts>perhaps with a Linux emulation layer it might be possible <ZhuAisi[m]>The main pain of Guix containers is missing something like network bridging and port forwarding <jpoiret>namespaces are very linux-centric and a very deeply integrated feature <jpoiret>i'm not sure you could simulate that <jpoiret>ZhuAisi[m]: isn't that just a matter of making a proper iptables interface? <jpoiret>we have the static network interfaces that were recently reworked <zacts>what are the main development goals for guix at the moment (for the next major releases)? <zacts>what is most of the development effort focused on at the moment? <jpoiret>the thing is, guix is very much rolling-release, even for its features <jpoiret>point releases are very much just snapshots, but new features are introduced at basically any time <jpoiret>there isn't really a roadmap i'd say, even though there kind of is a wishlist <jpoiret>there aren't that many contributors working on Guix internals, so adding new big features is pretty complicated <attila_lendvai>in the new input format, is there a way to have named inputs? or is that deprecated and will be removed completely? <mbakke>attila_lendvai: it will be removed completely, you should use search-input-file & co instead <civodul>so, comrades, we have a review problem! <civodul>i'm starting work on a "guix review" tool in the hope it'll help reviewers <civodul>hibiki: an ever-increasing backlog of contributions <civodul>contributors turned away by the lack of responsiveness and all that <civodul>well, review activity has also dropped lately <jgibbons[m]>Calls to guix home reconfigure don't exit. I'm seeing right now if the problem is my home configuration or the guix home reconfigure script. <jgibbons[m]>'(E . Max `(0 ,Mancer)): Probably the latter then. i'm making sure the complexity of my configuration isn't the issue. <EMax`0Mancer[m]>but it seems to have just started, as yesterday it was fine. (Unless the last changes I did also increased the complexity of my configuration to a similar point.) <char[m]>Good morning guix! Is it possible to use vixie crontab files with guix mcron service? <char[m]>I read how to do it with mcron, but I couldn't see how to get it to work with mcron-service-type <jgibbons[m]>char: I'm not sure then. The mcron-service-type might be too lispy. <jgibbons[m]>The documentation says mcron-service-type expects g-exps corresponding to an mcron job specification. <char[m]>Mcron says if run without arguments it will look for and run the crontab files, but running mcron-service-type without any jobs doesn't work. <jgibbons[m]>Maybe if the gexp referenced a file. Like (local-file "/path/to/cron/file") or something like that it might work. <char[m]>I'll try that, I still don't understand g expressions or how a file-like-object is a g expression <jgibbons[m]>I know that gexp is supposed to be a monad, and nobody understands monads. So I would be surprised if anyone understood gexps. <bjc>if i have a file-like-object (say, <computed-file>) how can i coerce the store from the repl to put that on disk so i can look at its contents? <jgibbons[m]>Somehow gexps usually turn into strings referencing a location in a file system, so I think a file-like object can stand in for a gexp. <bjc>i don't need it outside of /gnu/store, but i don't even know how to get that far <bjc>been banging my head on this for a couple days and i just can't find my way around to it <bjc>yeah, i've read that a bunch of times and i still have no idea <bjc>fwiw, 'gexp?' on a <computed-file> => #f <jgibbons[m]>"The local-file, plain-file, computed-file, program-file, and scheme-file procedures below return file-like objects. That is, when unquoted in a G-expression, these objects lead to a file in the store. Consider this G-expression:" <bjc>so i can just unquote it? i think i was thrown off by the 'system*' call in the beginning of the expression <jgibbons[m]>You could try something like #~(begin #$(local-file "/path/to/file")) <bjc>i'm going to try and simplify my working case to express my issues better <bjc>i still think i'm missing a step <jgibbons[m]>#~(local-file "/path/to/file") returns a gexp. (gexp->derivation "stuff" #~(local-file /path/to/file")) returns a derivation. <civodul>jgibbons[m]: i'm seeing the same problem with "guix home reconfigure"; i think it has to do with the shepherd ugprade <civodul>it hangs while running "herd load root ..." <civodul>you can run "herd stop root" before "guix home reconfigure" <civodul>but then shepherd isn't running anymore <civodul>and reconfigure won't restart it, it seems <bjc>was just looking for that ;) *jgibbons[m] reboots and logs in to start home shepherd <civodul>jgibbons[m]: i posted a patch there; would be great if you could test and report back <bjc>ok, so if i create the following derivation: <bjc>(define test-drv (gexp->derivation "foo" <bjc> #~(begin #$(plain-file "foo.txt" "the contents of foo") <bjc>when i call (let ((store (open-connection))) (build-derivations store (list (run-with-store store test-drv)))) => #t <bjc>that's not useful for me. i assume i'm missing a step <bjc>what i'd like is to run the derivation and get the "foo.txt" output location in the store so i can manually inspect it <bjc>kind of like what this does at the repl: ,enter-store-monad RET (text-file "foo.txt" "contents") <bjc>or am i way off base here and need to approach this from a different angle? <jgibbons[m]>bjc: Try it with gexp #~(display #$(plain-file "foo.txt" "the contents of foo")) <bjc>there's no output at all from display, presumably because that runs in the guix daemon, not in my repl <bjc>i only added it there as a hail mary <bjc>should i take this to the mailing list? i'm so lost <jpoiret>bjc: personally i'd say you would have to use the monadic procedure (lower-object ...) from (guix gexp) tice <jpoiret>it will work, but there might be something better <jpoiret>maybe lower+expand-object instead, have not used it <bjc>jpoiret: i'm not entirely sure what lower-object does, but i'd guessed it was too low level for what, i'm presuming, is a common thing to do <jpoiret>oh, right, you're building a derivation, one lower-object will be enough <bjc>where does it go? i've tried wrapping 'test-drv' -- (run-with-store (open-connection) (lower-object test-drv)) -- and it throws an error <bjc>likewise, wrapping (run-with-store) in it also throws an error <bjc>there's no 'lower-object' call in there <bjc>(run-with-store (open-connection) (lower-object test-drv)) => In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure 7f81189803c0 at guix/gexp.scm:1180:2 (state)> <netamuffin[m]>Hello! Are there packages or other ways to use rust nightly on guix? <jpoiret>netamuffin[m]: unfortunately not afaik <bjc>you can't use rustup? <netamuffin[m]>bjc: rustup doesn't have any binaries that were patched to work on guix, right? <jpoiret>guix functions differently enough that bare rustup wouldn't work *jgibbons[m] looks for rust nightly on dockerhub <jgibbons[m]>If you need rust nigthly, you can make it with docker from rustlang/rust:nightly <jgibbons[m]>How to build rust nightly? Special branch on a git repo? <jpoiret>you need `(run-with-store (open-connection) (with-monad %store-monad (>>= test-drv lower-object)))` <jpoiret>but there's definitely better i think <bjc>i'll try that though <bjc>i will also scratch that ;) <jpoiret>it'll just give you the derivation, because silly me forgot that lower-object doesn't build anything (: <bjc>right. i'm pretty sure i've *got* the derivation, but i don't know how to run it, and 'run-with-store' isn't doing what i expected <jpoiret>yeah, run-with-store will just execute an mval with a store connection <bjc>and the derivation isn't a monadic value? <jpoiret>the mval you're executing is given by (gexp->derivation ...) so basically you'll just get the derivation path <bjc>right, that's what i'm getting <jpoiret>no! you're executing a monadic derivation, ie something that needs the store to give you the derivation path <jpoiret>a derivation itself isn't monadic at all <bjc>that makes sense, since i never gave it the store monad <bjc>so i have to turn it into an mval, then, to execute it? <jpoiret>no, you should use build/build-things/mapm/accumulate-builds or similar <jpoiret>basically yeah, it turns a derivation into monadic value (but that value isn't the output path iiuc, which is annoying) <bjc>unfortunately (build-derivations store (run-with-store store test-drv)) doesn't give me anything i can inspect <jpoiret>well, yeah, as jgibbons was saying, you should use derivation-output-path to get that <civodul>bjc: these are rather low-level APIs; it's okay to use them, but be sure you really need it <civodul>in most cases, you can use 'computed-file' & co., and pass that to "guix build" or similar <jpoiret>yeah, because the derivation doesn't build anything iiuc <jpoiret>you're not trying to use #$output inside the gexp, so it doesn't have an output i think <bjc>civodul: i don't know the appropriate level to be working at. i *do* have a computed-file that i'm trying to use, but i also need to be doing this in scheme <jpoiret>what are you trying to achieve at the higher-level? <bjc>i intend to create a package that can write out the file, but, while i'm working on it, i want to verify its contents <jpoiret>so you're writing a phase gexp, and you want to inspect a file? can't you do that directly inside the gexp? <bjc>i don't want to have to call 'guix build' all the time. i'd rather be doing as much as i can from geiser and its repl <bjc>i want to verify the actual file contents <bjc>i'm pulling the computed file from the grub bootloader, and its not the kind of thing i'd want to install if it has an error in it, for instance <jpoiret>looking at the `guix build` source, it really does (build derivations ...) followed by (for-each show-derivation-outputs drv) <bjc>plus, this seems like fairly basic functionality to me? maybe i'm odd, but going from file-like-object to actual file in scheme seems like the kind of thing you'd get in a beginner hacker tutorial <jpoiret>often, you just `guix build -f` file-likes <bjc>can i do that from the repl? <jpoiret>from the repl you really have to `build-derivations` followed by `derivation-output-path` <bjc>build-derivations just returns #t, though. what do i call derivation-output-path on? <jpoiret>let me check though if there isn't something easier <jpoiret>bjc: you call it on the original derivation <jpoiret>derivations always already know their output path, so as long as they build you know where the output is <jpoiret>if you just print out the derivation in the shell, it will display it nicely along with its outputs <ZhuAisi[m]>it will be handy if we can build something in REPL directly <ZhuAisi[m]>Maybe add some repl command like ,build GEXP-LIKE-OBJECT <bjc>jpoiret: so, i'd call 'derivation-output-path' on: (gexp->derivation "foo" #~(begin #$(plain-file "foo.txt" "foo contents"))) <jpoiret>no, you'd have to run it first to get the actual derivation <jpoiret>but you could also write most of it using monadic style <bjc>you mean i need to run build-derivations, *then* run derivation-output-path on something? <jpoiret>something like (mlet* %store-monad ((drv (gexp->derivation gexp)) (output (derivation-output-path drv))) (begin (build-derivations (list drv)) (format #t "~a~%" output))) <jgibbons[m]>gexp->derivation seems like a misnomer. It returns a procedure, not a derivation object. <jpoiret>it returns a monadic value to be exact <jpoiret>the fact that the internals of monadic values are procedures shouldn't matter <jpoiret>ah, and it should likely be (output <- (derivation-output-path drv)) instead <bjc>Wrong number of arguments to #<procedure gexp->derivation <jpoiret>let me fire up something to actually test out what i'm saying, cause it's all vague <bjc>ok, so that returns a procedure, which i guess i have to (return) to get its value? <PotentialUser-97>Hi can anyone advise how to set dconf settings fro Gnome via guix or guix home? <bjc>actually, that procedure should probably go through run-with-store, right? <bjc>but trying that and i get: Wrong type argument: #<derivation /gnu/store/dr813a1m81rzmprnig1kpqah3f3gd1hd-foo.drv => 7f8114d70dc0> <netamuffin[m]><netamuffin[m]> "Bootstrapping rust seems..." <- Also bootstrapping rust failed, because of an unknown issue i cant resolve. <netamuffin[m]>> Thiago Jung Bauermann - I learned about Guix when I was looking for alternative, safe ways of installing an up-to-date Rust toolchain on my machine... <netamuffin[m]>> Thiago Jung Bauermann - I learned about Guix when I was looking for alternative, safe ways of installing an up-to-date Rust toolchain on my machine... <bjc>it's not wrong, depending on what's meant by "safe" <bjc>rustup, while it works, is a mess <drakonis>i'm getting the itch to get guix back on my box again <netamuffin[m]>civodul: the python script fails executing the prebuilt binaries for bootstrapping <civodul>netamuffin[m]: i'm missing context; which python script? <civodul>"guix weather rust" suggests binaries are available <netamuffin[m]>The docs for building rust say that building is done with a provided python script `x.py` instead of cargo. <jpoiret>you can build the newer rustcs using the stable ones <civodul>ah well, that's not the right channel for complaints then :-) <bjc>you may be best off just running rust in a container <civodul>there's no guarantee of course, because you'd be building an arbitrary tarball from upstream <netamuffin[m]>jpoiret: Thats would be cool, but the build script is untransparent for me and uses downloaded binaries that dont work on guix <netamuffin[m]>civodul: Nice. Didn't know that existed, because i am new to guix. I will try it <jpoiret>your best bet is writing a package for the version you want, with inspiration from the stable ones :) <bjc>how would that work for a nightly package that updates every day? <netamuffin[m]>I dont need them every day. I just need a relatively new version, which would be nightly in my case. <jpoiret>why am i getting unbound symbol: 'ungexp' :( <jgibbons[m]>(define test-drv (gexp->derivation "foo" #~(copy-file #$(plain-file "foo.txt" "the contents of foo") #$output))) (let* ((store (open-connection)) (drv (run-with-store store test-drv))) (build-derivations store (list drv)) (format #t "~a~%" (derivation-outputs drv))) <civodul>bjc: --with-source accepts a URL, so it'd download that first <char[m]>jgibbons: using local-file or just the file name as a string didn't work <netamuffin[m]><netamuffin[m]> "Nice. Didn't know that existed..." <- Sadly didn't work. Would have been too nice <bjc>jgibbons[m]: you are a hero. thank you <jgibbons[m]>char: I've been working on correcting that. Try a gexp like #~(copy-file #$(local-file "/path/to/file") #$output) <bjc>copy-file makes sense, and was the step i was missing <jgibbons[m]>i don't know if there's a simpler way to get the gexp #~(copy-file #$file-like-object #$output) <bjc>if i didn't want it to go to the output, maybe it'd be a problem, but i can't see a reason to want that right now <jgibbons[m]>Also, if you are using local-file, unless you do something to make it unique based on the file's hash, you will need to garbage collect every time the local file changes. <jpoiret>i tried using monadic notation to make it cleaner :p <jpoiret>also, don't use gexp as your gexp variable name, you'll run into nasty issues :( <bjc>jpoiret: thanks, that was my next step <char[m]>jgibbons: what is output supposed to be? <jgibbons[m]>output refers to the out output of the gexp and a location in the store. <jgibbons[m]>So the gexp #~(copy-file #$file-like-object #$output) copies the file-like-object to its output and can be used to reference a location in the store like with a package. <jgibbons[m]>I'm not familiar enough with mcron-service-type to know what it does with the gexp you give it in its configuration object though. <littlebobeep>So there are 6 revisions of the ARMv8 ISA and now one ARMv9 version.... what versions of all of these aarch64 levels does Guix target? <efraim>littlebobeep: v8a, but we do also have the --tune flag, which should help with later revisions <char[m]>Arguments to mcron can be crontab files. Instead of putting the file name though, mcron-service-type keeps putting a file who's contents is a path to the crontab. <littlebobeep>efraim: Okay would I have to edit the scheme package definitions to optimize for the correct ISA? <efraim>littlebobeep: I'm not sure how to do it as part of a manifest, but it should be possible to just do `guix install foo --tune` <efraim>oh, autotuning isn't setup yet for aarch64, I should've checked (guix cpu) first <efraim>well they are listed as armv8-a through armv8.6-a, so it should be `guix install foo --tune=armv8.2-a` or the like <efraim>littlebobeep: what machine do you have? I didn't have any that weren't armv8-a so I couldn't do anything with the autodetection yet ***chexum_ is now known as chexum
<char[m]>I found a read-vixie-file function in mcron source. It returns a list of jobs, but those aren't gexps, so I doubt it will ever work. I'm not sure sure how to load mcron source into my /etc/config.scm in the first place. <leinad>char[m]: IIUC the mcron service only allows job descriptions in Scheme format. Reading the source, specifically the definition of the procedure job-files in gnu/services/mcron.scm:59:9, it appears to me that the gexps from the jobs field of the mcron-service-configuration is simply ungexp'ed and then quoted again and written to a Scheme file and passed to mcron. <char[m]>Thanks leinad , I guess I will just conform then. <leinad>Hopefully, you're going to like the Scheme forms eventually <bost>Hi. Does anybody know how to get the 'gsettings' installed? <atka>civodul: zram-device-configuration has the priority field which can/should be defined when creating zram and/or multiple swaps, I think zram defualting to -1 or -2 is the default when starting zram with zramctl on other distros. Fedora uses zram instead of swap by default and defaults to 100. <jonsger[m]>bost: guix shell/install glib:bin will do the trick :) <bost>jonsger[m]: Thanks. Can tell me please how can I find out such things by myself? <civodul>atka: ok, thanks for explaining; actually my question to jpoiret was more like: could you gimme a patch to apply? :-) <civodul>bost: hi! it's usually installed with GNOME/GTK things <atka>civodul: just tested on a fedora distro, creating zram, running mkswap, and running swapon with no priority argument defaults to -2, not a guix issue imo <civodul>bost: you're getting warnings from a GTK app? <jonsger[m]>find /gnu/store/ -name gsettings | grep "bin/gsettings" :P <bost>jonsger[m]: will that find command work if I haven't installed 'glib' yet? <bost>jonsger[m] civodul I mean I'd like to know how to find out from the guix source code that gsettings comes from glib:bin? <jonsger[m]>no, it wont. There is no such a command in guix yet... <bost>jonsger[m]: so in general I need to install as many packages as possible and then just run 'find ... | grep ...' and hope for the best? Hmm. <roptat> ls /gnu/store/*/bin/gsettings is faster than find ;) <bjc>does guix even know what files are installed in a given package until it's built? <bjc>feels like this is a job for the data service <civodul>jpoiret: could you reply to the bug tracker? <civodul>actually i was just scanning it for open bugs :-) <jpoiret>i'll have to read up a bit on zram first, but for sure :)