IRC channel logs


back to list of logs

<Minall>Hello guix!
<Minall>nckx: o/
<Minall>Hello guix!
*nckx pokes guix with a stick.
<Minall>guix: *replies angrily in guile*
<nckx>Most of it truncated and replaced with ‘…’.
<quiliro>Saluton Guix!
<Minall>Hello guix!
<Minall>quiliro: Kiel vi fartas!
<quiliro>hello, i want to create a config.scm for systema reconfigure for a Guix System with git server, legder, ssh server and backup service
<quiliro>wthe user upleads ledger data files and connects to the ledger service to produce reports
<quiliro>the ledger data files are version controlled with git and secured to avoid data loss on an external device
<quiliro>maybe even mount an emacs server to conect to it via emacs clients and emacs-ledger-mode
<quiliro>with emacs-trap
<quiliro>(remote emacs clients)
<quiliro>can git be reached via onion addresses?
<tune>how can I adjust the temperature threshold for my cpu? I'm dropping frames trying to watch a movie, and I think it's due to thermal throttling
<tune>dmesg is full of messages about it
<nckx>tune: Which are? ‘Core|Package temperature above threshold, cpu clock throttled (total events = nnn)’?
<nckx>tune: We have a tlp service which I've never used, but which is generally thought to handle these sorts of things.
<tune>I'm no longer sure what to do. I installed lm-sensors and I can see that during the choppy playback it gets to like 96c
<nckx>tune: But first you need to actually look at your CPU frequency statistics to find out what's really happening, and sensors to see the temp. Maybe a bogus BIOS limit (processor.ignore_ppc=1 on the kernel command line could help). Maybe setting the governor to ‘performance’ at max frequency will make a difference. All that said, if your CPU is throttling, it's probably for a reason. It's too hot. End of ☹
<tune>probably can't afford to get much hotter than that. it cools down a lot after being paused for a bit. never had issues like this with movies before
<nckx>tune: My i7-3520M goes up to 100°C, although I throttle it at 75. IMO running at 96 for long periods of time is not going to make your CPU last very long.
<tune>sure, but I don't understand why it's struggling so much more than usual
<tune>kinda makes me wanna throw the computer away. I don't think I'm asking that much of it
<nckx>tune: Slim chance, but… if you happen to have an i915-compatible GPU, I recently added libva acceleration support.
<nckx>tune: What kind of CPU & video file are we talking?
<nckx>My 7-year-old laptop CPU handles 1080p x265/HEVC just fine. Did you accidentally all the 4K? 😛
<tune>i5-2520m in a thinkpad x220t
<tune>no it's 1080p
<tune>I have seen occasional thermal throttling in dmesg in the past, but it's never been noticeable like this, actually preventing me from doing something
<tune>maybe ambient room temperatures are worse than usual and it's enough to push it over the edge. I'm feeling pretty hot myself
<nckx>tune: True, it makes a surprising difference (especially this summer in Europe :-/ ).
<nckx>tune: Adding ‘intel-vaapi-driver’ to your profile (I add it to my system profile, not sure if it matters) ought to really make a noticable difference on anything x264 and ‘lower’.
<nckx>Assuming your x220 has a similar GPU to my x230.
<nckx>So many x2xx; confusing.
<tune>mine's one gen older (sandy bridge) and the tablet model but otherwise they should be fairly similar. the gpu would probably be different between generations though
<tune>so I should just install that package?
<tune>will I need to restart my session or reboot or anything?
<nckx>tune: Yes, mpv & vlc (and other libva users) should then pick it up. You should see console logs to this effect when opening the video afterwards.
<nckx>That I don't know.
<nckx>It does rely on a search path, so you'll need to refresh the environment that your media player sees. I'd just open a new terminal window, but depends on your 'flow.
<nckx>(Mine's also a tablet, by the way, it doesn't seem to any cool worse than my partner's same-gen T430.)
<civodul>Hello Guix!
<g_bor>Hello guix!
<civodul>berlin is back! thank you rekado!
<g_bor>nice :)
<nckx>Berlin was down? For how long?
<civodul>for an hour or so, thanks to rekado who couldn't sleep
<civodul>and then *didn't* sleep much i'm afraid!
<nckx>Ooh… +1 thanks for rekado!
<roptat>hi guix!
<roptat>bah, my client disconnected just as I was greeting you all
<civodul>hi roptat!
<civodul>rekado: i've pushed a couple more guile-json fixes for Cuirass
<civodul>how should we restart it?
<roptat>so did my changes break berlin, or was it unrelated?
<roptat>I love breaking things :D
<civodul>the crash was unrelated, but there were a couple of issues in those changes :-)
<civodul>BTW, i test these things with "guix system build berlin ... -n"
<civodul>and then building just the update-guix-manual-devel.drv, for instance
<civodul>you typically need to comment out all the Zabbix stuff in berlin.scm to do so
<roptat>yeah, I tried to do it once, but I didn't understand that zabbix stuff
<roptat>I think there was another issue after commenting it out, but I don't remember the details
<g_bor>hello guix!
<g_bor>Any idea why I am building guile-static-2.2.4?
<civodul>hi g_bor!
<civodul>no idea!
<civodul>depends on what you're doing i guess :-)
<g_bor>civodul: guix system reconfigure after guix pull :) almost bare-bones setup
<civodul>that must be for the initrd, but substitutes should be available
***ng0_ is now known as ng0
<civodul>"guix weather guile-static-stripped" says it's available
<g_bor>I have a lot of working substitues, though... I don't know...
<civodul>so i don't know
<rekado>Hi Guix!
***lio is now known as lenn
<g_bor>rekado: hello!
<rekado>civodul: good thing I couldn’t sleep. Perfect timing.
<g_bor>Nice work with Berlin!
<civodul>hey rekado!
<civodul>"good thing", dunno ;-)
<rekado>civodul: on berlin I’ve got a custom Cuirass package definition (to test minor things), so if you want to avoid having to update the ‘cuirass’ package all the time just adjust that custom package in berlin.scm
<rekado>one thing that’s not working yet is this:
<rekado>it seems to me that we need a built derivation.
<rekado>to get the log file
<rekado>that was broken since the move to derivation-build-plan
<rekado>I tried a silly substitution, but that was obviously wrong.
<rekado>that’s the variant of Cuirass that’s currently deployed, though
<rekado>it’s fine to reconfigure and then restart just ‘cuirass-web’
<civodul>derivation-log-file ends up being call with zero arguments, how's that possible?
<rekado>that’s my mistake
<rekado>I substituted (compose …) with ‘derivation-log-file’, but I didn’t escape the parens in the match expression.
<rekado>either way it’s wrong. There shouldn’t be any substitution anyway.
<rekado>but there’s still a problem in src/cuirass/templates.scm, ‘build-details’.
<rekado>we apply ‘derivation-input-path’ which leads to this error: In procedure derivation-input-derivation: Wrong type argument: #<derivation /gnu/store/9cagf3a66v132dbvgla725mfvmvnbhjn-linux-libre-5.2.7-guix.tar.xz.drv => /gnu/store/2bhq99srvy93jqn9iwswjddii194za1x-linux-libre-5.2.7-guix.tar.xz 17344b0>
<civodul>derivation-build-plan returns a list of <derivation-input> though
<civodul>or does it?
<civodul>actually no, it returns a list of <derivation>
<civodul>rekado: so just (filter derivation-log-file (with-store ...)) should do, no?
<civodul>it's tricky to test locally though
<rekado>yeah, might work
<rekado>I test this with a custom cuirass package on berlin ¯\_(ツ)_/¯
<rekado>doesn’t work because derivation-log-file operates on a string
*rekado looks up the derivation module
*rekado reconfigures
<civodul>ah yes, so (compose derivation-log-file derivation-file-name)
<civodul>trial and error
<rekado>I think it’s kinda clunky to have derivation-log-file work on a string
<civodul>fortunately no Haskeller/OCamler is reading this
<civodul>it is a bit clunky, but that's because (guix store) doesn't know about <derivation>
<civodul>we could fix that eventually
<rekado>I still see an error in the log that’s related to Guile JSON
<civodul>we need to move the <derivation> bit from (guix derivations) to (guix store derivations) first, as was discussed with reepca quite some time ago
<rekado>in build-eval-table we need a list, not a vector
<rekado>I’ll fix that
<civodul>didn't i fix that one?
<civodul>commit 3d494b89738d5bd65b7b6dbc3cfbb507a34372db
<rekado>oh, guess I should pull on berlin first
<civodul>"git commit --amend" appears to ignore --author now
<civodul>did something change?
<gnu_srs>Hello again. Another stupid question: guix package --list-installed only shows the by me explicitly installed packages. How to make a list of all packages installed and used?
<roptat>guix gc -R ~/.guix-profile should work
<roptat>(the -R is for --requisites)
<roptat>it shows you all recursive dependencies of your profile
<roptat>instead of ~/.guix-profile, you can use it on the store path of individual installed package if you prefer :)
<gnu_srs>thanks. And how to list scheme variables, like: Scheme Variable: %shepherd-root-service
<gnu_srs>gux gc -R gives me: guix gc: error: path `guix-profile-14-link' is not in the store
<roptat>try guix gc -R `readlink -f ~/.guix-profile`
<rekado>(hmm, no build slots on berlin, can’t reconfigure)
<civodul>rekado: even with --no-build-hook
<roptat>what do you want to do with %shepherd-root-service exactly?
*rekado afk
<roptat>you can use the guix repl (literraly, the guix repl command) to examine variables and experiment with them
<roptat>gnu_srs, you can also examine your system with "guix gc -R /var/guix/system"
<gnu_srs>roptat: Thanks, the readlink version works, but guix gc -R does not: guix gc: error: path `/var/guix/system' is not in the store
<roptat>bah, that's weird
<roptat>it works well on my systems
<nly>does anyone have a newer pkg for gnunet?
<sneek>Welcome back nly, you have 1 message.
<sneek>nly, str1ngs says: the new mru seems to fix the buffer kill race condition. but now sometimes buffer-enter-hook is not called, after killing a buffer and it switch's to another buffer.
<roptat>gnu_srs, again, try with readlink -f :)
<roptat>gnu_srs, maybe you're a bit behind current guix
<gnu_srs>I updated today. I have problems the difference with guix pull and guix package -u.
<roptat>guix pull updates your copy of guix
<roptat>guix package -u upgrades your package profile, according to the new packages in your new version of guix
<roptat>make sure ~/.config/guix/current/bin is firts in your $PATH, run hash guix and make sure you don't install guix in your package profile
<rekado>hmm, I’m also building guile-static now
<civodul>rekado: which one?
<gnu_srs>civodul: Hello, since you are here now: How do I get up-to-date with the current status of GNU/Hurd support in Guix?
<civodul>rekado: oh that's prolly because of 4f3811f6bbdfba817601eb3168f5b3e0d2f1c3f6, brought by the wip-binaries merge
<gnu_srs>1) Create a Debian qemu image. 2) Copy the cross-compiled gcc, glibc, binuutils,etc from where to that image. 3) ?
<civodul>gnu_srs: by asking :-) but i think the short answer is that it's in flux
<civodul>so right now what's supposed to work is cross-compiling to GNU/Hurd ("i586-pc-gnu")
<civodul>and hopefully running those binaries natively, and perhaps running guix-daemon and building things natively
<gnu_srs>Which packages should be cross-compiled: buniutls, gcc, glibc, mig, hurd, ?
<rekado>I build it as part of the reconfiguration
<rekado>it’s /gnu/store/m76732yw3k19ik8bzbxqsx1flzk5cli4-guile-static-2.2.4.drv
<rekado>gnu_srs: I tried to answer these questions yesterday already. Have you seen them?
<civodul>rekado: besides, cuirass.log shows match error for derivation-input-output-paths
<gnu_srs>rekado: I saw your replies here, thanks. How do I get to the state you described?
<jlicht>hey guix!
<rekado>gnu_srs: get a Debian GNU/Hurd, then build the Guix dependencies from source.
<rekado>once you’ve got everything for building Guix also fetch the bootstrap binaries:
<rekado>such as
<rekado>(you’ll find that some of the static binaries such as tar will segfault when given certain arguments)
<rekado>that’s where we’re at.
<rekado>these binaries were cross-built.
*rekado needs to leave
<raingloom>uhm. anyone else having trouble with ibus? i can't get it to save my input methods...
<civodul>rekado: looks like berlin is not configured from the latest guix-maintenace.git
<civodul>i'd like to "herd restart mcron"
<civodul>are you around? :-)
<civodul>on package maintenance in Nixpkgs:
<civodul>raingloom: there are occasional issues with GLib software refusing to save settings, because the GSettings "memory" backend is used for some reason
<civodul>i never quite remember what it takes to fix it
<civodul>hopefully someone here does
<raingloom>well, guess i'll see if an update fixes it..... -_-
<g_bor>it seems to me that guix is a bit verbose nowadays...
<g_bor>I got a huge bunch of @ build-log ... entries
<g_bor>is that intended?
<g_bor>it was building guix-daemon
<civodul>g_bor: that can happen with 'guix pull' under special circumstances
<civodul>there's a bug report
<gnu_srs>rekado: gnu_srs: get a Debian GNU/Hurd, then build the Guix dependencies from source: Seems like there are no guix packages in Debian??
<g_bor>civodul: yes, that's what happened here.
***flor_ is now known as flor
<civodul>gnu_srs: indeed, though someone is working on it
<g_bor>ok, I've found it:
<gnu_srs>civodul: How to find out which packages are needed for building Guix?
<civodul>see "Requirements" in the manual
<civodul>rekado: also, cuirass-web is running but cuirass is not
<apteryx>hello! could someone point me to where the magic happens when doing 'docker start guix-image-id'? What command does it run to initialize shepherd and the system?
<apteryx>(with a guix docker image created using 'guix system docker-image my-config.scm')
<civodul>apteryx: there's an "entry point" in the image, and that entry point is the shepherd
<civodul>so it basically runs the shepherd as in a normal system
<civodul>see 'system-docker-image' in (gnu system vm)
<apteryx>Thank you! I'll check that module. So the shepherd is run upon doing 'docker start $container_id'
<apteryx>in a real usage context, one would probably fire up the container, then run a command in it (in an automated manner). How do I know when shepherd has completed its initualization?
<apteryx>example: docker start $container_id && docker exec -ti $container_id /run/current-system/profile/bin/bash --login -c 'herd status' returns: error: connect: /var/run/shepherd/socket: No such file or directory when the system is not yet initialized (that's my brute force way of telling for now)
<civodul>apteryx: good question, you could run "herd status" until it succeeds
<civodul>or we could change the entry point such that it returns once shepherd is up and running
<civodul>it's tricky to do though because the process started by "docker run" is PID 1 inside the container
<civodul>so it has to be shepherd
<apteryx>hmm, why does shepherd need to be run as PID 1? I think I had it going with PID 2 with some home brewed script
<apteryx>I'll retest it just to verify
<civodul>hmm dunno, it might work with another PID but it likely breaks assumptions here and there
<civodul>rekado: i've now done "herd restart cuirass", but i suspect that's not the one you were running, is it?
<gnu_srs>02:24:08 PM) srs: civodul: How to find out which packages are needed for building Guix?: Does this give the build dependency list? guix package --show=guix
<gnu_srs>Or are these the runtime dependencies?
<roptat>gnu_srs, only runtime
<roptat>mh.. you can run "guix edit guix" to see what we use in guix itself
<gnu_srs>In debian it is easy: apt-get build-dep <package>
<roptat>actually, that's probably all of them, not only runtime
<roptat>because it's taken from the package definition
<roptat>gnu_srs, this page lists them all:
<gnu_srs>roptat: Thanks :) And where to find the guix tarball?
<roptat>select the last option (GNU Guix 1.0.1 Source)
<roptat>civodul, would it make sense to have our own set of bootstrap binaries for haiku? say I don't want to port glibc to i586-haiku :)
<civodul>roptat: i don't want to commit to maintaining the package set on top of an additional libc
<apteryx>civodul: shepherd seems happy as PID 6, but I don't know what i could try to stress it some more:
<civodul>6 is a good number
<civodul>i know that shepherd it self has a few (= 1 (getpid)) tests
<civodul>for example to determine what to do upon "reboot" (aka. "herd stop root")
<roptat>well, before I get there, I'll have to package guix dependencies for the haiku package manager
<nly>nly: does anyone have a newer pkg for gnunet?
<apteryx>civodul: looking at shepherd sources, there are only two "(= 1 (getpid)) tests, and they are for handling things differently (which tells me shepherd as pid != 1 is OK)
<jonsger>roptat: what makes Haiku so interesting to use Guix on?
<roptat>just want to play :)
<roptat>but I'm not even sure I can manage to get /gnu created
<apteryx>so, I think I could try to Guilify my bash entrypoint, and use it a the default entrypoint boot-program (in the built docker image metadata directly). That'd fix the 'docker run -ti --rm some-command' common use case.
<jonsger>roptat: I wish you luck and fun :)
<roptat>my reasonning is also that by doing it, I would discover assumptions guix does and help porting on other systems
<apteryx>and allow for checking if the shepherd has finished initializing (removing this burden from users)
<roptat>I could try and work on porting to windows too, but I don't have a windows and my parents won't let me get near their computer :p
<apteryx>err, 'docker run -ti $image_id some-command' use case
<civodul>apteryx: though it'd be interesting to make the default entry point more useful, if i may :-)
<civodul>i mean, if 'guix system docker-image' makes a broken entry point, we should fix it
<apteryx>civodul: yes, that's exactly what I meant; but communication is hard ;-)
<civodul>heh ok :-)
<apteryx>It's great that you added --entry-point, I think it used to not exist last time I was looking at this. It paves the way!
<jonsger>roptat: there are Windows VPS out there :P
<roptat>jonsger, only if *you* pay for the VPS :p
<jonsger>roptat: 3 Euro a month :P Not that I would pay a single cent for Windows...
<jlicht>a bit related, has anyone had a look at Nixery (
<jlicht>it provides a registry of on-demand docker container images using Nix
<civodul>jlicht: ah fun!
<civodul>we've been wanting to have "guix pack as a service", which is essentially that, IIUC
<civodul>oh it's from Google
<nly>looks nice
<jonsger>civodul: it's from a Google engineer, not Google itself
<jlicht>yeah, I had a quick look at the internals of their caching strategy, which actually seems like a really fun hacking project:
<civodul>yeah we've seen that before, very nice
<civodul>what i don't understand is whether it's really "on-demand"
<rekado>bleh, shipping of the new servers has been delayed.
<rekado>the first package is now expected to arrive on the 9th of September.
<rekado>civodul: I’m running Cuirass with ‘herd start cuirass’ only. Nothing special.
<rekado>civodul: yes, I stopped ‘cuirass’ in order to get build slots to reconfigure
<jlicht>they have a cache AFAICS
<civodul>jlicht: so it's even better than what i had in mind
<civodul>i mean, they implement the registry interface directly
*civodul wonders about DoS
<civodul>when you do "docker pull", i suppose it evaluates the top-level attributes x, y, and z
<civodul>so you could maybe do{ x = y; y = x; }.x
<civodul>things like that
<civodul>who knows
<jlicht>civodul: not sure, but they do have an extra level of caching now that prevents any request from spinning up a Nix call
<jlicht>so if you request the /x/y/z one for the first time, afterwards the response seems to be pre-baked and does not involve any actual calls to nix
<civodul>sure, i'm not concerned about performance
<civodul>my point is that the URL path is actually Nix code
<civodul>that just happens to look like "package names"
<civodul>i guess i'm just jealous, that's all
<jlicht>I hope merely envious though :-)
<rekado>civodul: I have just reconfigured berlin again after rebasing our copy of maintenance.git
<civodul>cool, thanks rekado
<civodul>i've restarted mcron
<rekado>it’s still up
<rekado>so… no problem?
<civodul>rekado: no problem!
<civodul>two weird things: it looks like "static-web-site" changed UIDs
<civodul>which could have happened if at some point we booted to generation that lacked that user
<civodul>2nd thing: we have duplicate entries in /etc/passwd, oops!
<civodul>that's easily fixed
<Minall>Hello guix!
<Minall>quiliro: Kiel vi Fartas!
<civodul>Minall: ĝi estas demando, do: "kiel vi fartas?" :-)
<rekado>civodul: I had to boot a much older generation — the last one for which the kernel and initrd were already on /store (local disk).
<rekado>this might explain the UID hiccup.
<Minall>civodul: ¡Kiel vi fartas is all I know!, and mi fartas bonne
<civodul>rekado: ok, makes sense
<civodul>not a problem, i was just wondering
<civodul>we'll have to address that SPoF issue at some point...
<civodul>for the web site, we discussed that Let's Encrypt certificate challenge thing at length, but i'm still not sure what the outcome was?
<Minall>Guix, trying to add my video driver with (set-xorg-configuration(xf86-video-openchrome)) crashes xorg serbver
<rekado>civodul: my colleague can take care of the server going forward
<rekado>I’ll send his contact info to guix-sysadmin again.
<civodul>rekado: the one in machines.rec, right?
<rekado>then it’s at least DPoF.
<civodul>oh i was thinking about the machine, not the person :-)
<rekado>oh, yes, already there.
<rekado>ah, true.
<civodul>of course it's good that there's human redundancy too, but i think we can do better technically
<rekado>so, for users in China I wanted to run an rsync daemon, so that they can mirror the nar cache.
<rekado>I guess the cache itself would be a useful thing to have elsewhere
<rekado>so that when the machine is down we can at least serve existing nars
<civodul>that's right, we could take advantage of that
<rekado>I’m still waiting for the network team to respond to another firewall change request… so I haven’t even asked them about the rsync daemon port.
<rekado>I get that they are busy, but response times are much too long for firewall changes.
<rekado>I can’t do much about that. Already pinged them.
*jonsger finally built gnome-contacts successful :)
<jonsger>rekado: how is the state of gnome 3.30 on core-updates?
<rekado>jonsger: I don’t know.
<rekado>Kei was last working on it.
<jonsger>oke, 3.34 will come out on 11th september
<rekado>I think Kei worked towards 3.32
<htgoebel>How can I use `sans-extension`, which is defined in guix/gnu-maintenance.scm, in another module?
<htgoebel>`sans-extension` is not exported in guix/gnu-maintenance.scm. Do I need to export it?
<htgoebel>Or is there some way for "qualified usage?
<Minall>quiliro:Kiel vi fartas!
<civodul>hi htgoebel
<civodul>htgoebel: file-sans-extension is defined in (guix utils)
<civodul>'basename' can also fill that role sometimes
<civodul>with its optional argument
<htgoebel>civodul: I'd also need tarball->version :-)
<civodul>htgoebel: maybe we can move these to (guix upstream) if they are sufficiently generic
<civodul>like if other updaters might need them as well
<htgoebel>- Moving sans-extension seems okay for me, while suggesting to rename into `tarbar-sans-extension`. WDYT?
<htgoebel>- Not sure whether this is generic tarball->version enough:
<htgoebel> tarball->version is based on gnu-package-name->name+version.
<htgoebel> But there is also package-name->name+version. I can't tell the difference.
<civodul>htgoebel: yes for tarball-sans-extension
<civodul>and yes, maybe you need your own variant of tarball->version
*civodul has to go
<nckx>Hullo, hc.
<lfam>Can I add max-jobs to the guix-configuration record type?
<str1ngs>lfam: I don't think so. I think it's best to set that with environment variables
<str1ngs>example export GUIX_BUILD_OPTIONS="--cores=$(nproc) --max-jobs=1"
<lfam>str1ngs: Where that be exported for Guix system?
<str1ngs>~/.bashrc it's more a per user setting then daemon setting IMHO
<lfam>It's an argument of guix-daemon
<lfam>I mean you can set it as a user to reduce the number, but I don't think you can increase it
<str1ngs>right but it's not something you would generally want to effect the whole daemon with. it's more a per build option
<lfam>If the default is 1, can a user increase it though?
*lfam tries
<str1ngs>I'm not sure what default max jobs is. maybe the number of build users?
<nckx>lfam: (extra-options (list "--max-jerbs=fu"))
<lfam>Unless things changed, the default is 1
<str1ngs>default max jobs 1 does not seem right to me... hmmm
<nckx>str1ngs: What does?
<lfam>I think it makes sense because running multiple jobs will easily overload your system unless it is super powerful
<lfam>If you have a spinning disk you are just totally done for the day
<str1ngs>IIRC guix daemon does not default to max one job.
<lfam>The docs say 1
<lfam>It's not the same as --cores
<lfam>The desktop and hobbyist user experience would be pretty bad if the default was greater than 1
<nckx>The problem is that the max-jobs/cores split makes it impossible to set anything close to an optimal value; you either risk heavily overloading many-core systems or have cores sitting idle.
<str1ngs>lfam right I guess I confused to two.
<lfam>Anyways thanks to nckx for highlighting the extra-options thing
<nckx>It would be nice to use 1 ‘pool’ of cores for both but that would need some redesigning of the things.
<str1ngs>lfam: I had forgot about extra-option myself I over looked that
<lfam>My big pet peeve here is that downloading substitutes and compiling are both treated as "builds" so you download tiny substitutes sequentially, which is super slow
<nckx>Oh, yeah, I forgot about that (I remember as soon as I try to install something 🙂).
<lfam>If I have to download a lot of small substitutes my throughput is like 50 KB/s even though I could do 100 Mbit/s
<nckx>That adds an extra layer of suck.
<lfam>So I like to keep max-jobs cranked up and turn it down when I know I will be compiling
<nckx>Read that & weep.
<lfam>It's pretty good now. I rarely need to compile many things unless I am developing
*nckx 's system load is currently 16.1, for these reasons.
*nckx has 2 cores with 2 threads :-/
<lfam>Whenever I develop Go packages it hits 40 and then I have to turn it down
<lfam>4 logical cores on 2 chips
<lfam>Thankfully the system is still responsive when this happens
<nckx>lfam: I actually crank up the number on spinning rusticles, so with some luck at least something can run while 31 other threads iowait.
<nckx>Bah. Computers.
<freeuser58>hello, I installed exfat-utils but when I executed mount, it says "unknown filesystem type 'exfat'."
<str1ngs>freeuser58: you may need to load the kernel module?
<str1ngs>just a guess here
<freeuser58>str1ngs: how I do so?
<str1ngs>or maybe you need exfat-fuse
<str1ngs>aka fuse-extfat
<str1ngs>err fuse-exfat
<freeuser58>I installed fuse-exfat right now and the same problem, maybe I needed a reboot
<nckx>Well, it is a Windows file system. /s
<freeuser58>nckx: Yes, but is used
<nckx>freeuser58: What about calling ‘mount.exfat’ directly?
<freeuser58>nckx: That works!! Thank you
<freeuser58>str1ngs: thank you too!
<nckx>Seems like we're missing some mount helper integration.
<nckx>Glad it works though 🙂
<Minall>Hello guix!
<Minall>quiliro: Kiel vi Fartas!
<tune>ugh ssl broken after a reboot again
<tune>"fixed" by doing 'swaymsg exit' and then logging back in. in other words, the auto login with sddm breaks ssl somehow
<quiliro>por ahora tu tarea es privativay con licencia a nombre de marloli
<quiliro>sorry...wrong chatroom
<quiliro>Minall: civodul diris vin ke kiel ne estas aserteco, ĝi estas demando!
<quiliro>Minall: vi skribu "Kiel vi fartas?", ne "Kiel vi fartas!".
<quiliro>is there a template file to build an email server with spam and virus control as well as all other necesary configurations for it to be accepted by other email servers such as gmail, hotmail, yahoo, etc
<civodul>quiliro: there's no such thing AFAIK, but i agree it'd be great to have!
<civodul>i think roptat has a working email setup, for example
<quiliro>cool!...did he share his config.scm
<quiliro>roptat: nice...thank you
<roptat>It doesn't have spam/virus control, but everytging else
<quiliro>"You need to sign in or sign up before continuing."
<quiliro>i corrected the url and it worked
<nckx>quiliro: Guix doesn't have any spam filters yet.
<nckx>(They're not really needed in my experience. I get ~1 portion of spam a day.)
<nckx>(Usually all 7 on 1 day of the week. Spammers are lazy people.)