IRC channel logs

2020-10-19.log

back to list of logs

<mbakke>vagrantc: I haven't been following too closely, but end-of-october was the initial target.
<vagrantc>mbakke: thanks for confirming
<civodul>yay vagrantc!
<civodul>fnstudio: yup, should be fun!
<vagrantc>1.2 will be the first version with authenticated guix pull, if i'm remembering correctly, which i was sort of waiting for (but not fully)
<civodul>correct
<civodul>mbakke: there's something fishy in berlin-nodes.scm (?) and "guix deploy berlin-nodes.scm" gets stuck at some point
*civodul -> zZz
<civodul>we'll see later!
<rekado>Zambonifofex: unfortunately, it fails to build. May need other packages to be upgraded as well.
*rekado –> zzZ
<Zambonifofex>rekado: I see. Well, if you’d prefer to not credit me at all, that’s fair enough, given that I don’t feel like I have put enough work to warrant it anyway.
<terpri_>fnstudio, what/when is the guix conference?
<nalaginrut>if I install guile with guix, the ffi can't load .so file from the original lib path, how can ffi load from guix?
<kozo[m]>terpri_ Guix will hold its first online conference November 22nd. Propose a talk before November 6th. Learn more!
<vagrantc>/20/15
<terpri_> http://guix.gnu.org/en/blog/2020/online-guix-day-announce-1/ cool
<ryanprior>I gotta figure out how to run guix in a resource-constrained cgroup or something
<ryanprior>I just had my system soft-locked for 20 minutes while Guix threw the whole kitchen sink into building clang
<ryanprior>Like dang leave some cpu and memory for the rest of us. I run guix and it starts oomkilling all my apps.
<pkill9>you can set the number of cores guix uses
<ryanprior>I guess I'm lucky that I haven't had this happen before that I can recall, but damn now I know I can't trust it. I'll either figure out a way to constrain its memory & cpu usage or I'll just run it in a VM and offload to the host system.
<ryanprior>Guix apparently interprets "use all the cores" as "you have permission to peg every core to 100% at highest priority, indefinitely" which has gotta change.
<bdju>yeah using the machine can become hard while updates are running
<ryanprior>It wouldn't accept hardly any keyboard input even
<bdju>oh wow
<ryanprior>It took 5 minutes just to get it to switch to a virtual tty
<pkill9>are you using earlyoom service ryanprior?
<pkill9>it's better than the default one
<pkill9>on my machine it killed the guix build before it froze up my machine
<ryanprior>I have a process called [oom_reaper]
<ryanprior>How do I tell which service I have?
<pkill9>you put it in the guix config
<ryanprior>Oh I'm not on Guix System
<link2xt>I recently discovered ancient technology (last updated in 2012) that fixes thrashing on Linux: https://doc.coker.com.au/projects/memlockd/
<pkill9>it's just a daemon
<pkill9>so you probably don't
<pkill9>just add the earlyoom service to your guix config and reconfigure if you want it
<link2xt>if it does not accept input, it means Xorg has been unloaded from memory
<pkill9>what's thrashing?
<link2xt>pkill9: https://en.wikipedia.org/wiki/Thrashing_(computer_science)
<ryanprior>link2xt that looks useful
<link2xt>it's when program is constantly paged out of the memory and reloaded
<link2xt>the problem is, when you are out of memory, linux unloads pages that can be reloaded, either from the disk or from swap
<link2xt>if you disable swap, it still unloads all your program and then reloads them when it tries to execute them
<link2xt>moving cursor etc. is a really cheap operation
<link2xt>so if your cursor is freezed, it means that Xorg, some video driver, input driver etc. was unloaded
<link2xt>and you are now waiting for cursor moving code to reload from HDD/SSD
<pkill9>oh interesting
<pkill9>that always bothered me
<link2xt>internet is full of advices to disable swap, disable overcommitment etc.
<link2xt>this does not work, because binaries are backed by the files on HDD and can still be paged out
<link2xt>memlockd simply does mlockall(MCL_CURRENT|MCL_FUTURE) and then mmaps every binary with its .so dependencies into its own memory
<link2xt>you can configure what to load there, but I simply added the whole /usr/bin/ with "+" prefix (which means load dependencies)
<link2xt>it uses 1G now, but it's all shared memory, so it's useful
<link2xt>when I compile something, compiler may be OOM-killed, but cursor never freezes
<link2xt>earlyoom/oomd are heuristics, while memlockd strictly prohibits paging out of executables
<link2xt>With memlockd you still need to provide it with paths to executables that you don't want to be unloaded in advance.
<link2xt>Probably a better way is to fix ld-linux loader to mlock binaries after loading, but I have not tried it.
<bdju>with `guix package --upgrade . --do-not-upgrade foo` what is the syntax like if I want to skip multiple things? I keep hitting build failures
<bdju>in addition to syncthing, bombadillo has failed to build for me
<bdju>I'm trying space-separated and I'll just see what happens in a few minutes
<kozo[m]>When I use substitute-urls I have to use ' ' to surround multiple entries
<kozo[m]>--do-not-upgrade 'syncthing bombadillo'
<bdju>well, without quotes it either worked or bombadillo didn't fail this time
<bdju>just ran upgrade without holding back anything but with --dry-run on the end and it says bombadillo and syncthing would upgrade, so I think it worked
<bdju>I will maybe use single quotes in the future just to be safe, though. glad to know that would work
***catonano_ is now known as catonano
<apteryx>ryanprior: you're basically complaining about how linux sucks at handling resource exhaustion (that's not really Guix specific). That's why boilted-on solutions such as earlyoom exist (hint: there's a service for it in Guix, and it'll save you more than once).
<ryanprior>I'm definitely looking into more of these things! But Guix is not entirely faultless. dpkg has never soft-locked my system in 12+ years of updates.
<raghavgururajan>🔥
<apteryx>dpkg doesn't build anything from source to install packages on your system :-)
<ryanprior>True but beside the point. Running a normal routine guix command can soft-lock your system, and that's an implication of Guix's design
<apteryx>I think the best way to handle this for users would be to allow a way to updates via substitutes only; some guix pull that'd use the knowledge from the Guix data service to pull the commit which has 100% substitutes coverage of you package collection, then the updates would be entirely binary.
<ryanprior>I think you're on the money there.
<apteryx>there's not much you can do when a package such as webkitgtk+ wants 12 GiB of RAM to build.
<ryanprior>To get even more sophisticated, we could gather information about typical build times of packages and upgrade without substitute for packages that only take a short time.
<kozo[m]>I ran into the same issue and as pkill9 said, I will add cores=total-1 to prevent that brutal softlock
<kozo[m]>also running a local publish server has helped a ton
<ryanprior>Whenever I upgrade I do a dry-run first, and then I add --do-not-upgrade flags for big packages if it wants to build them. That's not very user friendly, and it's a buzzkill to have to describe that process to people.
<ryanprior>And in this case today I neglected to do that (I actually did the dry-run but misread the output) and then couldn't even back out.
<ryanprior>Defaulting to cores-1, or to only upgrade from substitutes, sound like reasonable options to avoid that happening.
<apteryx>default to cores-1 would make builds slower for everyone, while not guaranteeing to prevent resource exhaustion, so I'd much prefer option #2. It seems the technicalities already allow for it, we just need someone motivated to implement it. You seem to be that person ;-)
<apteryx>I agree the user experience is not the best right now unless they have a good grasp of the build farms and other details (e.g., guix pull now and update in 12 hours will probably allow me to get better coverage)
<ryanprior>I would love to implement #2. My Guile knowledge is pretty low-tier, and my guix data service knowledge is pretty bottom basement (I know it's run by cbaines, written in Guile, and uses Postgres, that's about it)
<ryanprior>But I'd like to improve all those things.
<ryanprior>I'm also curious what performance characteristics it would have.
<ryanprior>Suppose that, to build a new profile from the latest available substitutes for the packages in the current generation of my profile, I'd be getting packages from 6 versions of Guix.
<ryanprior>Does that mean I pay 6*cost of a single guix pull?
<apteryx>I was thinking about something more dump and simpler to get started: selecting a single guix revision that has the required coverage, or fail.
<ryanprior>Yeah that would be a reasonable starting point.
<apteryx>parameters could include how old you're ready to allow the guix to be
<ryanprior>Right, you wouldn't want to back beyond where you're currently at.
<apteryx>guix pull --with-coverage=100% --max-age=2d
<apteryx>(hypothetical UI)
<vagrantc>doubt you ever see 100%
<apteryx>with --max-age it could
<vagrantc>you'd need to tell it what you want coverage of
<vagrantc>apteryx: it's not a simple matter of time ... there's pretty much always something that's broken, unfortunately
<apteryx>by default it could use your currently installed packages in your user profile, perhaps also those from your system profile
<apteryx>vagrantc: not true for my 182 something package collection
<vagrantc>apteryx: exactly, you have to tell it what you're asking coverage for
<apteryx>yes
<vagrantc>since "guix pull" is essentially a codified list of all available software in theory
<apteryx>as I wrote it could be smart and use your user and system profile when you don't hint at anything else
<apteryx>(and it could also allow you to pass extra profiles or manifests to get these included in the coverage)
<vagrantc>seems more like something that guix weather would do
<vagrantc>yeah, i'd think you'd want manifests or something, but implicit is not generally very guix ... being a functional package manager :)
<vagrantc>but you'd get interesting quirks, such as when packages disappear or are renamed (although there's some mechanism to check for renames)
<apteryx>vagrantc: I was thinking of implicit upon using 'guix pull --with-coverage', to make it as easy as possible for users. Not everyone manages their user profile with a manifest.
<vagrantc>yeah, i'm pretty ad-hoc about using manifests
<vagrantc>it doesn't seem appropriate for guix pull, though.
<apteryx>since you need guix at a specifically choosen revision to update with 100% substitutes coverage, it seems natural to provide a UI on 'guix pull' to do so, since git pull is about fetching a installing a Guix revision.
<vagrantc>apteryx: if you're itching to implement, probably worth discussing on the list ... possibly even a bug report already about that sort of thing
<apteryx>it's just brainstorming for now ;-)
<apteryx>the bug is #26608 (https://issues.guix.gnu.org/26608).
<vagrantc>it seems like "guix pull" should consume the result of some other command... similar to "guix time-machine"
<vagrantc>2
<vagrantc>bah.
<apteryx>sure, perhaps guix pull could rely on the internals of 'guix weather'. That's an implementation detail. I was thinking in terms of UI only.
<xelxebar>Oh nice. I've had guix cripple my (~8 yo) laptop several times---X stuff all gets paged out, etc. Finally decided to spin up a build offload vm just to keep from hitting the oom kiss of everlasting wait.
<apteryx>xelxebar: also consider using the earlyoom-service-type
<apteryx>it removes the everlasting wait from the equation ;-)
<apteryx>congrats for the successful offload setup! Did you hit some bumps configuring it?
<xelxebar>apteryx: Cheers. Just read the discussion above and saw mention of earlyoom and memlockd.
<xelxebar>apteryx: Thanks! Offload setup was pretty straightforward. It went almost without a hitch. For some reason guix offload test was failing to start guile at first.
<xelxebar>I fiddled with the config a bit, but after returning the settings to what I had originally, it just started working for some reason :/
<wleslie>does anyone know how to generate a Makefile.in within newlib? automake says "error: support for Cygnus-style trees has been removed"
<wleslie>cygnus being the group that wrote newlib before being acquired by hedrat
<apteryx>xelxebar: did it fixed itself without intervention (the guile not starting issue)?
<apteryx>ah, just read your last message, seems it fixed itself automagically, eh
<apteryx>there's a transient issue where sometimes offload complains about guile not found, perhaps that's what you had
<xelxebar>apteryx: Yeah, civodul suggested the issue might have been https://issues.guix.gnu.org/43763
<apteryx>indeed!
<wleslie>or maybe... can guix give me an older version of automake? the package list doesn't say anything about different versions, and only includes 1.16.2
<xelxebar>Anyone here a neovim user? How are you providing the python(2) "neovim" module(s)?
<apteryx>wleslie: if guix show automake doesn't list many versions, you'd have to git log --grep='gnu: automake', pick the guix revision with the version you like, then 'guix time-machine COMMIT -- guix environment --ad-hoc automake'
<wleslie>wow, that's a cool feature
<wleslie>guix: guix: command not found
<wleslie>;____;
<Zambonifofex>Pfft. Guix seems to be doubting its own existence! 😅 Kinda philosophical of it, to be honest. 🧐
<janneke>eh, that would be: guix time-machine --commit=<commit> -- environment --ad-hoc automake
<wleslie>thanks heaps janneke, I was just poking around with various --help
<wleslie>guix --help time machine -> guix: unrecognized option '--help' ; Try `guix --help' for more information.
<wleslie>hmm, this commit is too old. I'll put together an expression.
<janneke>wleslie: guix time-machine --help
***amfl_ is now known as amfl
***apteryx is now known as Guest12922
***apteryx_ is now known as apteryx
<jlicht>hey guix!
<wleslie>hi jlicht!
<g_bor[m]>sneek: seen zimoun
<sneek>I think I remember zimoun in #guix 16 hours ago, saying: roptat: awesome! Thanks.
<jlicht>
<jlicht>o/
<jlicht>g_bor[m]: how is this round of outreachy going? From what I've been getting on the ML, there are a lot of applicants this year right :D?
***ping is now known as niko
<civodul>Hello Guix!
<user_oreloznog>Hello civodul!
<user_oreloznog>Trying to contribute to the translation of guix-manual-1.2.0-pre1.fr.po, I hope that by the end of the month I will have been able to pass my first test with success :-)
<user_oreloznog>It's very rewarding to translate...
<maav>hi, everybody
<maav>user_oreloznog: it's great to have more translators :)
<civodul>hey maav!
<user_oreloznog>hi maav! Yes, I hope to be useful!
<civodul>user_oreloznog: note that we're aiming for a release end of Oct/beginning of Nov, so now is the right time to get started :-)
<user_oreloznog>civodul: yes, locally, 85% is traducted...
<user_oreloznog>translated
<user_oreloznog>I can actually fix about 150 messages by day...
<sss2>hi all, does guix system support separate partition for /boot ?
<civodul>user_oreloznog: woow, nice!
<efraim>yes, it just needs to be defined in the OS config and mounted at install time
<sneek>efraim, you have 1 message!
<sneek>efraim, divoplade says: There's also a chdir problem with containerd
<efraim>indeed, but it was fixed
<efraim>sneek: botsnack
<sneek>:)
<sss2>efraim, startnge, looks like does not worked for me (
<sss2>grub does installed into separate /boot
<sss2>and booting succesfuly, but it looking for bzimage in /gnu/store/... whic his on another partition
<efraim>ah, yes, that part isn't yet supported. sorry, I forgot about that use case
<sss2>efraim, ok, what about encrypted root ?
<sss2>efraim, on non-efi system
<efraim>I don't use it, but I hear that if /boot is a separate partition it should work to encrypt the other partitions.
<sss2>yes, but with boot on separate partition i have error about unavailable bzimage
<maav>sss2: do you mean /boot without crypto and /gnu/store in an encrypted partition?
<maav>efraim: i might have some code for that in the fridge... ;)
<sss2> https://paste.debian.net/1167798/
<sss2>i am dropped desktop from config as it takes 6 hours
<maav>sss2: i see, grub-i386 + plain /boot + crypto /
<sss2>yes
<maav>is there any bug report open about that? I could send there a WIP patch ;)
<maav>let me check
<maav>wow, #25305, it's old
<sss2>looks like it's different problem
<maav>it seems that i solve everything with boot-parameters... but the thing is that the info is needed somehow :-(
<sss2>solved ?
<sss2>can you provide some info ?
<maav>not solved really, the thing is that grub-install checks the encryption for /boot partition, but not for the files we provide for booting in /gnu/store, IIRC
<sss2>so what options i have ?
<maav>my patch unlocked all the partitions, but that wasn't optimal neither
<maav>i guess the only supported configuration for that is that /gnu/store and /boot are in the same encrypted partition (i have that everywhere)
<sss2>so decryption will be done by grub ?
<sss2>does it support luks2 with argon2 ?
<maav>nope, you have to provide it twice (yet(?))
<maav>i mean, i'm not 100% sure what algorithms are currently supported by our grub version, but that way it puts into the image the correct uuid to decrypt
<maav>the real solution would need to traverse the device path up to our store and add them to the image
<maav>grub depends on the hardware, but guix must only depend on the operating system definition, so mapped-devices and file-systems is enough knowledge to do that
<sss2>i am even more confused now
<maav>sss2: tl;dr is what efraim said, it isn't supported yet unless to split boot into a separate partition when /gnu/store is encrypted :(
<maav>s/yet unless to/yet to/
<sss2>m..., so i should try sing encrypted partition ?
<sss2>*single
<mothacehe>hey guix!
<maav>sss2: yep, that works
<OriansJ>sss2: the steps for manually setting up a fully encrypted drive: https://paste.debian.net/1167807/
<OriansJ>the only thing you need to ensure is that cryptsetup is in your package list
<OriansJ>and here is an example configure for encrypted root you might find useful: https://paste.debian.net/1167808/
<civodul>hey mothacehe!
<Zambonifofex>OriansJ: Note that sss2 seems to have left due to a timeout.
<maav>i've just seen d66a4eac44, neat :)
<civodul>maav: yes, i'm growing tired of the clunky HTML!
<civodul>especially when i look for instance at https://docs.racket-lang.org/
<maav>hmmm: 'This page is intended to redirect to the result of a search request. Since you’re reading this, it seems that the redirection did not work.'
<maav>i guess what you mean, but a robot don't ;)
<maav>(that's from racket, btw)
<maav>people use too much js...
<civodul>bah
<maav>who cares about energy ;-P
<civodul>it's also on CloudFare
<civodul>but wait, i just noticed that RacketCon used Zoom, it seems
<maav>never meet your idols
<maav>;)
<maav>one question, should I push the patch and close #44027?
<maav>it's confirmed that the esp was there before
<civodul>maav: i think you should double-check with mothacehe, i wasn't clear from their comment whether it was OK or not
<civodul>can you just email them for confirmation?
<civodul>hey zimoun!
<refcfar>Hi, I'm exploring Guix (as a current Nix user) and am not terribly well-versed in the arts of Guile/Scheme. How do I write a by-label getter function for a list of records in Guile? Use case is to list all `%desktop-services` by name (or something).
<civodul>refcfar: hi! it may be that "guix system extension-graph /your/config.scm | xdot -" will give you the info you're looking for
<civodul>otherwise, if you use Emacs and Emacs-Guix, there's M-x guix-default-services
<civodul>last, you can run "guix repl" and do (map (compose service-type-name service-kind) %desktop-services)
<refcfar><civodul "last, you can run "guix repl" an"> This I think is what I was looking for. I wasn't aware of `guix repl` (I just ran `guile` and then a bunch of `(use-...)` like it's done in the config.scm file), thanks.
<zimoun>civodul: hey!
<zimoun>nice logo for Guix Day ;-)
<zimoun>is roptat around?
<refcfar>Is there a generic way to print/get the type of a given data structure)
<civodul>refcfar: "guix repl" is the same as "guile", only it has the right module search path set by default
<civodul>zimoun: if roptat & you agree, we can add it to the post
<roptat>hi guix!
<roptat>zimoun, I agree :)
<zimoun>civodul: I totally agree. As you want, I can update the post today (later or maybe this (my) evening) and go ahead
<zimoun>roptat: I am giving a look at OCaml update. Cool!
<roptat>zimoun, and it fixes our reproducibility issues, which is really nice :)
<civodul>roptat: do you want to announce the Guix Day(s) on the fediverse?
<civodul>you can stick that picture in the message :-)
<maav>civodul: just answered at the thread, i checked here because i wanted to confirm with you all, of course :)
<civodul>heh, thanks!
<luhux>How to execute a command when the user logs in (SSH, Telnet, or tty)?
<luhux>I want to execute a command to send an email to notify me when my server is logged in.
<luhux>I found the pam_exec method on the Internet, but I don’t know how to set it on Guix System
<maav>luhux: https://guix.gnu.org/manual/en/guix.html#index-pluggable-authentication-modules
<apteryx>civodul: note, Emacs-Guix is currently broken
<maav>luhux: there is a record that you can append to that list called pam-service, it should have everything you need
<maav>pam-entry*, sorry
<luhux>maav: I read this document before, but it did not solve my problem
<maav>hmmm, yes, i'm reading the code, it's harder than i thought from the manual, oops
<maav>but not impossible: you have to append a pam-service with a pam-entry on the session group
<civodul>apteryx: oh still?
<civodul>can't we maintain a branch in the meantime?
<apteryx>apparently it has to do with the update from Geiser 0.11 to 0.12
<apteryx>if we find the problem, we could patch it in Guix awaiting the fix to trickle down upstream
<luhux>maav: Is there any sample code?
<maav>not in the manual (yet)
<roptat>civodul, done
<civodul>roptat: neat, thanks :-)
<maav>luhux: something along these lines: https://paste.debian.net/1167839/
<maav>luhux: or modify the lists inside the services inside the current base-pam-services, whatever fits better your needs... i've never done it 0:)
<luhux>maav: Thank you very much. I will try.
***slyfox_ is now known as slyfox
<civodul>new CSS for procedure definitions & co: https://guix.gnu.org/manual/devel/en/html_node/Build-Utilities.html
<civodul>(maybe you need to reload to bypass the browser's cache)
<civodul>tweaking from someone more knowledgeable and/or with better tastes is welcome :-)
<bavier[m]1>hello Guix!
<roptat>civodul, maybe try this: dl { border-top: 3px solid #d4cbb6; } dt {background: #eee;} dd {background:#fafafa;}, and replace margins by paddings in dt and dd
<roptat>also, remove the border on the left
<roptat>civodul, here's what I propose: https://lepiller.eu/files/manual.png
<roptat>for dd, use #eeeeee55 instead (transparent, so data type definitions get a slightly different color too), with a padding of .5 in every direction for dt: https://lepiller.eu/files/manual2.png
<civodul>roptat: i like it!
<civodul>it's maybe a little too "heavy" for fields as in the mcron-configuration case
<civodul>(i'd just do nothing special here)
<civodul>you can distinguish them by class (dt.symbol-definition vs. dt)
<civodul>roptat: but anyway, i'm all for something like that, so i say go for it!
<roptat>is that in the artworks, or the guix repo?
<civodul>artwork
<civodul>in code.css
<mfg>Hey!
<mfg>so i now found out why gdb doesn't load debugging symbols even though it's configured to look into the correct path... It seems the .gnu_debuglink that gets embedded into the object files point to inaccessible locations...
<mfg>yesterday i looked into how the .debug file genreations works in guix and where it is placed but i couldn't find out how it works...
<roptat>civodul, pushed
<civodul>thanks, roptat!
<mothacehe>is Miguel around here?
<emys>Can I somehow get rid of the "hint: Consider setting the necessary environment variables by running: GUIX_PROFILE="/home/holger/.config/guix/current ...." warning?
<emys>GUIX_PROFILE is set and I have GUIX_PROFILE/etc/profile sourced
<civodul>mothacehe: yup, talk to maav :-)
<mothacehe> nice, thanks civodul :)
<civodul>maav: this is mothacehe
<civodul>emys: hi! the warning gets displayed only when your environment is missing one or more environment variable settings
<maav>hey, mothacehe :)
<mothacehe>maav: hey maav! Thanks for the recent installer patches, much appreciated!
<mothacehe>if the system tests are ok, the ESP patch looks good to me
<mothacehe>i'm currently testing the locale patch
<maav>mothacehe: i did a quick test and no esp appeared :)
<maav>and thanks to you, my patch only moves a line from here to there :)
<emys>civodul, strange, because I have it in my zshrc config, env var setting and sourcing
<civodul>emys: good, but maybe you just installed something that wants more env vars
<mothacehe>maav: good! regarding locales it seems that our font can't handle some symbols that result in ▯ symbols
<maav>mothacehe: which symbols? I haven't found any, but I remember that I changed at some point the quotations in the grub translation... maybe to avoid that 0:)
<maav>mothacehe: let me check...
<maav>mothacehe: well, at least «, » work and unicode arrows work on my system, could you check which symbols are missing?
<mothacehe>maav: just sent you a screen capture by email!
<maav>mothacehe: ooops, i didn't saw these, and I thought i browsed all the pages... :(
<apteryx>mbakke: it's OK to merge staging into core-updates at any time, right?
<maav>mothacehe: wait a sec, I can see them in my image... I'm going to generate a new one, but I have to check what happens
<mothacehe>I generated this image on master, commit 324057e8d6
<g_bor[m]>sneek: seen zimoun ?
<sneek>zimoun was last seen in #guix 4 hours and 20 minutes ago, saying: roptat: I am giving a look at OCaml update. Cool!.
<refcfar>Is there no plasma-desktop service in the guix repo?
<MSavoritias[m]2>plasma is not yet added to guix
<apteryx>mbakke: looking at past commits, it looks like it is! I just did. Commit 5e2140511c syncs core-updates with both master & staging.
<refcfar><MSavoritias[m]2 "plasma is not yet added to guix"> I see. Thanks
<maav>mothacehe: i'm generating a new version (on top of fc316a585e, it shouldn't matter) to check, i'll tell what i've found
<MSavoritias[m]2>np
<mothacehe>maav: ok thanks. Saw your screenshot, very strange!
<mbakke>apteryx: nice! :-)
<mbakke>although I expected an octopus merge.. :P
<apteryx>ah, I haven't yet reached your level ;-)
<apteryx>I peggy-backed on the fact that you had merged master in staging 18 hours ago ;-)
<mbakke>haha :) I haven't done any octopus merges either as it's usually better to merge one into the other first :-)
<brown121407>I like the style changes you guys added to the devel manual, they make stuff easier to read
<brown121407>and now there are links in the code blocks?! that's amazing
<maav>mothacehe: i cannot reproduce it, i've sent you the screenshot by mail
<roptat>brown121407, glad it helps :)
<mfg>so i thought the cmake build system supports debug outputs, it creates a separate debug output yes and it conatins all .debug files, but those are either created after the debugging symbols have been stripped from the object files or the debug files themselves are also stripped. The resulting .debug files don't conatin a .debug_info section.
<raghavgururajan>Hello Guix!
<mfg>Does anyone know a little program that uses cmake which i can use to test some things? i don't want to have to rebuild too much...
<mfg>nvm found one: flashrom
<civodul>roptat: your CSS changes are live and it's pretty, thanks!
<roptat>yw
<roptat>now I want the same for my own manuals (guile-netlink, ...)
<civodul>heh :-)
<civodul>we should hack the stexi module so we can all have that by default
<civodul>without resorting to the ugly post-processing tricks
<roptat>is that part of guile?
<roptat>did you mean (texinfo) and friends?
<zimoun`>rekado_: Hi! I was giving a look at the texlive package, trying to understand why the PDF table of contents is wrong for French and German, at least. And the big texlive does not have source. Where does it come from so?
<Zambonifofex>Hello, Guix! I’m currently getting an error trying to use a Git repository I set up from `channels.scm`. The error I get is `invalid content-type: 'application/octet-stream'`
<Zambonifofex>Note that the only file Guix seems to be trying to fetch is `info/refs`, and although it *is* sent as `application/octet-stream`, it contains the expected contents. It works with `git` itself, even!
<Zambonifofex>It would be (really) inconvenient for me to change the content type, so I was wondering if there is any way to get it to work as is.
<zimoun`>sneek: seen g_bor[m] ?
<sneek>g_bor[m] was in #guix 2 hours and 26 minutes ago, saying: sneek: seen zimoun ?.
<roptat>oh I'm a bit disappointed sneek didn't pick up that one, it would have been a nice loop :)
<roptat>sneek, botnack
<roptat>sneek, botsnack
<sneek>:)
<leoprikler>Regarding the new CSS, is it intended, that those blocks don't match up with the example blocks?
<leoprikler>Feels a bit weird to me.
<divoplade>Zambonifofex, guix uses libgit, not git. There are a few things that git supports and that libgit does not. For instance, you cannot have your git repo as a static "simple" repo and have guix pull it, you need the more complex setup with CGI and stuff
<divoplade>Or git daemon
<roptat>leoprikler, not really, if you have suggestions, it'd be nice
<divoplade>I don't know exactly, I use cgit
<leoprikler>I feel like the examples should use some grey, that is between the colour of the header line and the body.
<leoprikler>So that both @example and @deffn @example make sense when put against @deffn
<roptat>do you have an example?
<leoprikler>Perhaps we could also round the @deffn corners a bit
<leoprikler>hmm let's see
<leoprikler>we have the range from #eeeeee to #fafafa if I'm not mistaken
<leoprikler>how about #f6f6f6?
<roptat>yes
<roptat>you can use the inspector in icecat or any browser you use to change the CSS live and tests things
<roptat>I'm not sure what you want to do, so either explain better, or send a patch :)
<leoprikler>I think setting div.lisp and some other background colors from #f2efe4 (which is definitely not a "grey" tone) to #f6f6f6 (or maybe something a bit less light like #f2f2f2)
<zimoun`>rekado_: I withdraw my question :-)
<leoprikler>anyway, me → afk, maybe I'll formalize it tomorrow
<raghavgururajan>nckx: You on binge updating?
<vagrantc>hrm. for some reason u-boot isn't getting updated on a pinebook-pro or pinebook
<vagrantc>as in, in builds, says it's installing it ... but it doesn't actually install anything
<vagrantc>or at least, nothing ends up on the target media...
<civodul>uh
*civodul is in a documentation mood
<civodul>just wrote a "Build Phases" section
<civodul>translators will hate me but hey, that'll pay off!
<roptat>civodul, I don't hate you
<roptat>that's great!
<roptat>also, I don't get to translate it, as someone else stepped in to do it :)
<civodul>roptat: ooh, good news!
<maav>civodul, surely I don't hate you neither :)
<civodul>pheww
<civodul>:-)
<user_oreloznog_>civodul: idem for me :-)
<zimoun`>Chinesse speaker here? What is the texlive and co to get the correct fonts?
<roptat>civodul, I tried using texi->stexi on my manual, but first it fails with (#f "Unknown command" detailmenu), and after removing that, with Wrong type argument in position 2 (expecting character): #<eof>
<civodul>roptat: yeah the parser is not capable of handling whole documents, but not far from it i think
<civodul>so i think it would make sense to invest time in reaching parity with the "official" parser
<roptat>I'll look into it
<civodul>that's be nice
<civodul>plus, it's definitely easier to parse than Scala :-)
<maav>well, i'm gonna be mostly offline these three days, but i'll check daily at least the mail, next weekend will continue full-time :-)
<maav>have a nice week, guixers!
<vagrantc>anyone looked into packaging wolfssl ? seems to have a largely working compatibility layer with openssl, and solves the OpenSSL/GPL disconnect issue, as wolfssl is GPL
<raghavgururajan>Thanks! you to maav o/
<civodul>vagrantc: not that i know of, but it sounds interesting
<civodul>we have no shortage of TLS implementations these days
<vagrantc>true enough ...
<vagrantc>it seems to build successfully with most u-boot stuff, though still having issues with at least one thing
<apteryx>vagrantc: I'm curious; gnutls doesn't offer provide compatibility with openssl, correct?
<civodul>it used to, but that bitrotted and was eventually removed
<apteryx>ah!
<civodul>worse: https://gitlab.com/gnutls/gnutls/-/tree/master/devel
<apteryx>are you referring to the openssl submodule?
<apteryx>I guess/hope it is used for comparison / benchmarking purposes, being under the devel directory
<civodul>yes, the submodule
<civodul>i don't know what it's used for, but it strikes me as odd :-)
<mbakke>so cuirass lists several k's of builds as cancelled: https://ci.guix.gnu.org/jobset/staging-staging
<mbakke>I wonder if 'update builds set status=-2 where status=4 and evaluation=17638' will make them restart at the next evaluation?
<cbaines>mbakke, I think grey is "pending" in that view
<cbaines>although I'm not sure if that includes canceled or not
<mbakke>civodul: it's the red ones I'm worried about :)
<cbaines>anyway, I believe canceled means that when Cuirass came round to try and build the derivation, it had disappeared from the store
<mbakke>hmm
<cbaines>changing their status may help, but only if the derivation has somehow reappeared
<cbaines>and yeah, I didn't realise the red failed group included canceled, I guess that makes some sense...
<mbakke>cbaines: indeed, poking at some of the cancelled builds, their derivations are indeed missing on berlin
<mbakke>I guess they got wiped during the nightly GC?
<cbaines>that would be my guess
***amiloradovsky1 is now known as amiloradovsky
<mbakke>adding GC roots for .drvs is fine, right?
*mbakke is guix noob
<cbaines>in princible, although that might lead to having a rather large number of GC roots
<civodul>mbakke: yup it's fine
<civodul>you can add GC roots to any store item
<civodul>mbakke: https://ci.guix.gnu.org/jobset/staging-staging looks like a battlefield indeed
<mbakke>let's see if Cuirass restarts those builds with the ongoing evaluation... otherwise I have some hacking to do :P
<civodul>some are bogus: https://ci.guix.gnu.org/log/pb0qx8v77nm5jlfhmlcynachhhig7k7w-flashrom-1.2
<civodul>heh :-)
<civodul>the yellow crosses are pretty
<civodul>not sure what that means though
<cbaines>"Aborted" is what it says on the page for the yellow crosses
<civodul>ok :-)
<cbaines>I'm not sure what that means though...
<civodul>mbakke: BTW i restarted guix-daemon on a couple of machines but it still has --cores=4
<civodul>i think that's because the upgrade-shepherd-services phase of "guix deploy" failed
<mbakke>oh
<jackhill>wondering about https://issues.guix.gnu.org/43795#2 (stockfish). Do we have a policy on pre-trained neural networks? It does't look like source to me, but I also don't know of another way. This machine learning stuff puts free software in an unfortunate place.
<hadi>Hi guys. I'm a trisquel user. I heard about GNU/Guix. I researched it on the internet but did not find out exactly what it is. Is it a GNU distro or a package manager!? will you please tell me. Is it worth installing? what it is exactly? thanks...
<vagrantc>hadi: it's a package manager, and also a distro
<vagrantc>hadi: the package manager can co-exist with other package manages on other distros ... or you can install a fully guix system that only uses guix packages
<hadi>vagrantc thanks for reply. Is it easy to install? Is the environment graphical?
<rekado_>zimoun``: re fonts: that depends on the variant of TeX you use.
<zimoun``>jackhill: it is still an open question… well AFAIK, no policy on pre-trained neural networks.
<vagrantc>i'm mostly familiar with the guix commandline ... i think there's a emacs interface for it...
<rekado_>lualatex has a font loader that allows you to use your existing OTF fonts
<rekado_>xelatex has something similar, but weirder
<vagrantc>hadi: there's a script you can download that will install it ... haven't used it much myself
<rekado_>pdflatex doesn’t, so you need special font metrics and all that stuff
<rekado_>I can’t say I know this stuff well at all, but I know that fonts and LaTeX are frustrating.
<rekado_>it’s especially bad in the modular TeX Live because I’m sure we’re missing something somewhere.
<rekado_>I’m still trying to fix an important lualatex package so that we can actually recommend using it.
<zimoun``>rekado_: thank you for explaining. For the PDF manual, by default it currently uses pdftex, right? LuaTeX would be nice to have.
<jackhill>zimoun``: yes, and I see why there isn't one. It's not clear to me what the right policy should be.
<zimoun``>and yes we are missing something somewhere…
<rekado_>yes, it’s pdftex
<rekado_>you can overwrite this by setting one (or all?) of the PDFTEX, LATEX, and/or PDFLATEX variables.
<rekado_>I think we’re really close to a well-working modular TeX Live
<rekado_>there are some known issues that are just boring to fix, but not impossible
<rekado_>but the configuration is really … quirky and hard to set up correctly
<zimoun``>I agree and the manual (with translations) is a good use-case. :-0
<zimoun``>s/0/) :-)
<rekado_>so while I can’t see anything obvious that we’re doing wrong I’m sure it would be good to go through the profile hook and texlive-union expression by expression.
<rekado_>it still irks me that the profile hook doesn’t use texlive-union directly
<rekado_>it probably should
<rekado_>I already have a few more replacement packages (e.g. texlive-context instead of the arbitrary subset texlive-context-base), but that sadly didn’t fix anything.
*rekado_ pushes the R upgrade
<rekado_>sneek: later tell civodul The new manual hyperlinks are superb!
<sneek>Got it.
*zimoun`` is \o/ for R upgrade