<jgart>oh ok, I imagined it might not import the world yet
<Michal-Atlas>Hello, does anyone know if massive fonts displaying in all programs are a known issue? I was trying to find a solution, but then it popped up on another machine. Is this a thing? Or am I on my own. It's honestly the last hair holding me from shouting that guix is the most genius distro ever and solves all my troubles.
<nckx>So, speaking for myself: I think Guix should be opinionated about what a Guix channel is and how it's distributed (and most importantly: authenticated). Git could just be an implementation details channel authors & users need to accept. Supporting a totally new VCS just because people like it is, IMO, unreasonable.
<nckx>Patched kernel, and a few patches to Guix to barely support a silly parody of separate /boot, barely. Just good enough to boot. Since rebasing bcachefs onto linux-libre is… not something I'm interested in doing it's not going upstream any time soon.
<nckx>bcachefs is fun and promising but it still eats data. Others', never mine, so far, so bcachefs - btrfs 1 -0.
<guixy>guix deploy: error: creating directory `/gnu/store/.links': No such file or directory
<nckx>the_tubular: (1) GPL-2, because part of Linux (2) Nope, too ugly for now, and I don't want to support that crap (3) apart from my big ‘0’ I don't have numbers, I just lurk on #bcachefs, GitHub, and the (very low-traffic) list. Bugs happen. But not disconcertingly many, and most get fixed at an impressive pace for a mostly-1-man-show. That said, it's not that anymore, but it's still very much Kent-driven.
<nckx>And yes, I have full back-ups at all times, although I'd have them on any other file system too.
<KarlJoad>I set up a dummy "channel" in the Cuirass config for the system that is a channel corresponding to the GNU hello repo, building only the "hello" package. But I want to test if that will work.
<apteryx>lfam: OK, I think my local version-1.4.0 branch is shaping up nicely (Unpushed to origin/version-1.4.0 (58)), I'll try to push it tomorrow, and if it looks good with everyone and I haven't forgotten anything we can throw Cuirass at it.
<jackhill>speaking of X (well, not really), but I wonder if we can do a wlroots update without much breakage
<lfam>I don't know much about wayland stuff. What do you think jackhill?
<jackhill>lfam: I'm getting ready to look into it. I just realised wlroots had a release in early December
<apteryx>if you send the patch, why not; the version-1.4.0 is a basically a world rebuild anyway. I won't test it locally but cuirass can build it when we deem the branch ready
<jackhill>there's not that many dependent packages, but is seems like the sort of thing that needs an extra call for testing. Just becasue it works with my compositor, doesn't mean there won't be problems for someone else's
<lfam>It's definitely a case where some Wayland users can pitch in
<lfam>apteryx: I'm wondering about the release branching workflow. If I pushed these changes to master after you forked the version-1.4.0 branch, does that mean that they wouldn't be included in the 1.4.0 release? And users would have to get them later with `guix pull`
<lfam>apteryx: I'm still not sure how the workflow will be. Like, if these changes aren't on master tomorrow, would they still end up in 1.4.0?
<jackhill>oh, cool, I get to play with replacing assoc-ref with ungexp!
<apteryx>the way I see it, the purpose of the version-1.4.0 branch is twofold: having a more 'frozen' branch compared to master and having a branch other than master to fix nice to have but distrupting changes (such as that sitecustomize.py fix that rebuilds most of the world)
<apteryx>but at the current stage of things (limited testing and still has bugs we'd like to fix) it's far from frozen, we can cherry pick commits from master or even merge master into it later
<apteryx>after it's undergone more testing we'll have to be more careful
<lfam>In that case, what do you think about adding the Go patchset? I tested it on x86_64-linux and there are no new build failures. I would have liked to spend 2 or 3 more days begging people to test it with their favorite packages, but maybe that's okay? Overall I think it would be good to release 1.4.0 with a Go compiler that's still supported upstream
<lfam>And the full Xorg update sounds good. I can push the "small" version of it to master, and then the full update could come via version-1.4.0, or it could simply be delayed (it's typical for xorg-server-for-tests to be lagging behind)
<lfam>The Xorg update does fix some security issues, but what else is new. And of course we could say the same about updating the entire Go package graph
<apteryx>I have libx11 184.108.40.206, mesa 21.3.1 and xorg-server 21.1.2 on my local version-1.4.0 branch
<lfam>Xorg: "four vulnerabilities that could lead to privilege escalation when the xorg-server is running as a privileged process have been fixed"
<lfam>I just noticed another thing in the phoronix article I'm looking at
<lfam>"One notable regression fix is that reporting of physical display dimensions from the DRM connector is no longer being reported. That change to enable the physical dimension reporting of the output was deemed "too disruptive" and as a result the X.Org Server is back to just reporting 96 DPI."
<lfam>Aren't people reporting that text is large after the core-updates merge? Maybe this regression was introduced prior to 21.1.2. Or maybe it's unrelated
<apteryx>on xorg? dunno, didn't change here, although I do set my DPI manually
<jgart>Hi Guixers, I'm going to give a short demo over Big Blue Button on debugging a flask app with pudb Monday (today) at 1PM EST (approx +9 hours from now). I'll be using guix to set up a python development environment. Feel free to stop by: https://meet.nixnet.services/b/jga-vi3-nyz-wgx
<attila_lendvai>gnu/services/configuration.scm has a (eq? val 'disabled) which should most probably be 'undefined. anyone here who can quickly patch it? or will i need to go through the hurdles of sending a oneliner patch?
<yoctocell>attila_lendvai: I don't think that's a bug; 'disabled is used when a value isn't supposed to be serialized, which is the case when using a maybe-* type
<attila_lendvai>yoctocell, strange. i got there through chasing down a misbehavior... lemme look again
<yoctocell>attila_lendvai: e.g., see 'jami-account' in (gnu services telephony)
<attila_lendvai>yoctocell, it's in he definition of the maybe- stems. judging from the rest of the code, it looks to me that the value representing the unbound filed value is 'undefined. maybe it should check for both 'undefined and 'disabled then?
<attila_lendvai>and from another angle: 'undefined is a much better way to communicate that the field is not defined than 'disabled (e.g. is 'disabled a bool that is false?)
<yoctocell>attila_lendvai: I think the 'undefined (which is not user-facing, while 'disabled is) is for when a field must be set, while 'disabled is only used in a maybe-* type to specify that the value shouldn't be serialized
<attila_lendvai>yoctocell, *if* that is the case, then i have completely misunderstood the entire codebase. my understanding is that maybe-foo means that it's either a type of foo, or not specified (i.e. nothing about serialization).
<attila_lendvai>...other than that undefined values should skipped at serialization.
<yoctocell>attila_lendvai: maybe-foo means that it is either of type foo or 'disabled
<attila_lendvai>yoctocell, if that is the case, then i'm completely confused by the meaning or distinction between undefined and disabled
<attila_lendvai>yoctocell, i think i see the intention. but in that case i'd recommend using a cons cell identity in a global var (i.e. a truely private value) to represent what is currently represented by 'undefined, and use 'undefined instead of 'disabled. 'disabled' is very confusing for me in this context where there are boolean config fields all around...
<attila_lendvai>yoctocell, there's no error message. i was implementing my own service config using define-configuration based on examples and the codebase, and i was baffled why my maybe-foo field was erroring out when i didn't specify a default value for it.
<civodul>nckx: woow, this python-llvmlite change is terrrible!
<civodul>it's an ugly printer that we have in "guix style"
<attila_lendvai>yoctocell, another piece of info here is that my service's implementation needs to be smart regarding unspecified config values (e.g. some fields get their default values from other fields, excep when the user explicitly specifies them)
<zimoun>civodul, about “style”, I note that it is often “(list foo bar)” on one line instead of several as old style. To ease reading and maintenance, I suggest to document one input per line.
<yoctocell>attila_lendvai: ah, I see how disabled could be confused with booleans
<rekado>can’t get Guix System to install on this one build node.
<cbaines>civodul, thinking ahead to tomorrow, do you have any knowledge about the IPv6 configuration for bayfront? I'm guessing Aquilenet might provide some configuration details as part of the hosting
<aadcg>Error while loading ‘magit-libgit’: (module-open-failed "/gnu/store/5yhmmk1v4kb7q9b43jy80insqc253s6s-emacs-libgit-20200515-1.0ef8b13/share/emacs/site-lisp/libgit-20200515-1.0ef8b13/libegit2.so" "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/4xx9v8qvc3n9pqml3qp4ss2nan6f3b6f-libgit2-1.3.0/lib/libgit2.so.1.3)")
<taterbase>I updated and reconfigured guix and now it seems like xorg apps hare much lower density. Massive fonts on i3 and emacs. I haven't messed with configging density on guix, any links for tutes?
<phf`>Here is the doc: "When combined with --export, this instructs guix archive to include dependencies of the given items in the archive. Thus, the resulting archive is self-contained: it contains the closure of the exported store items."
<phf`>Here is the error: << guix install: erreur : some substitutes for the outputs of derivation `/gnu/store/i6d2vz93mfnfy2x7x2g98c55cv966k71-texinfo-6.7.drv' failed (usually happens due to networking issues); >>
<apteryx>hmm. I'm not sure... perhaps it wants to check for grafts? try passing --no-grafts
<lfam>attila_lendvai: It's typical in Go. They don't have a strong concept of "versioning", so every package depends on a random Git commit of its dependencies, essentially
<lfam>It's a problem for packaging because it's easy to package the "wrong thing"
<PurpleSym>Is there any known-good commit I can pull from a fresh debian installation? I remember there was someone else with the same issue previously, but I can’t find the logs.
<attila_lendvai>lfam, i know, but still... they don't care at all? and i'm packaging something that, when miscompiled, can lose a lot of money. i made binary packages of the official releases for this very reason.
<lfam>attila_lendvai: I initially misread your message. I thought you wrote "Why care at all?" Like, about packaging.
<awb99>but this is because of technical problems, which should be temporary, I guess the guix build farm is overloaded...
<podiki[m]>awb99: are you one that had slow profile building before (due we thought to icons etc.)?
<yewscion>Hey all, is there a way to reset a profile for a binary installation? I think I may have messed something up; multiple specific packages are failing to build, but only on my work laptop (My GuixSD installs are not experiencing this issue). I'd like to try to isolate the issue before reporting it as a bug.
<podiki[m]>the profile configuration is also faster for me (sometime during core-update-frozen time frame), now just a minute or so on my slowest profile
<yewscion>lfam: I suppose I could just make a new profile and try installing packages one by one, but I was hoping there was a way to simply remove and then reinstall everything, in order, in my current profile.
<lfam>yewscion: Also, when you say that builds are failing on one computer but not the other, how are you checking that they are the same? You should compare the full /gnu/store filenames of the things that fail to build on one computer with the filenames on the other computer. If they match, then they are the same build. If they don't match, then they are different
<yewscion>lfam: Do I just `ls` the directories in question? Or is there another idiomatic way?
<apteryx>awb99: at least for the tarball repacking it uses parallel compression; that may be one reason
<yewscion>And if they differ, is there a way to resolve that? I am not pinning any packages or commits at this point.
<civodul>we rarely get that kind of compliment :-)
<awb99>It is now similar to apt / yum / pacman in speed.
<awb99>THANKS TO ALL THE DEVELOPERS WHO MADE THAT HAPPEN!!!
<attila_lendvai>lfam, i agree with you, but my impression is that the guix maintainers think it differently. i had to argue multiple times that the chances of miscompilation is high, and the impact is large in my case, hence me packaging the binary releases.
<attila_lendvai>lfam, this beast has around 100 dependencies... and i need --pin-versions. so, i'm smartening up the go importer to be able to deal with all the complexity -- which is already done in golang's go binary, and i'm replicating it, in a potentially broken way (as i have fixed issues already that resulted in different versions being imported).
<nckx>(So ehm, whoever was working on rmtrashaaS, maybe investigate that avenue.)
<yewscion>Hey all, I am now sure the machines are running the exact same Guix (identical `guix describe`), and at least one of these packages is failing to build on both GuixSD and a binary install (it was not originally installed on the machine I checked). What is the process for submitting this as a bug, and for troubleshooting a non-building package?
<nckx>Noisytoot: Well, for me, it's ‘reconfigure headless box, go to bed, be unable to SSH into it in the morning, the end’. Rather hard to investigate further. But I suspect <https://issues.guix.gnu.org/52533> or thereabouts.
<nckx>Apart from that the machine is up & doing dandy.
<apteryx>we'll need better a betterdiagnostic when (guix gexp) is missing
<yewscion>lfam: I'm fairly comfortable, but I've never worked on a codebase as large or as widely used as Guix. I've cloned the source repo in the past, but I found it daunting to attempt to make changes due to my inexperience with the project. Has someone made a guide somewhere that goes a bit more in depth than the manual? An example of the workflow would
<tissevert>what are the pros and cons of using guix home to install user's packages vs. guix packages directly ?
***Xenguy_ is now known as Xenguy
<nckx>raghavgururajan: Did you check with (getenv "HOME") → (pk (getenv "HOME")) that HOME isn't set to /home/rg/guix-config/home by guix home? I don't know why it would do that, but it would be less spooky.
<nckx>That's about all I can suggest. The rest is guix home voodoo.
<unmatched-paren>sorry if this is a little off the channel's topic, but: to write things in niche languages such as guile scheme, you often seem to need to write c bindings, and for that, you need to know c. does anyone know any good resources for learning it? i find looking at the source code of c programs really disorienting, the language seems to have lots of syntatic noise, so that way of learning it is out of
<unmatched-paren>the picture. and if i learn c, i might also be able to also learn c++ and learn how guix-daemon and guile work...
<lfam>Hm, maybe it's dated advice, but for an intro to C, I found the K&R C book to be quite useful
<lfam>It won't teach you "modern C", but it will teach you how to read C code and have it make sense
<guixy>Guix on an old laptop with nvidia and intel integrated graphics tries to use nouveau and doesn't display anything. Is there a way to configure guix to force the desktop to use Intel drivers instead of nouveau?
<singpolyma>Hopefully we don't get too may new big projects in C anymore, but one can never predict
<unmatched-paren>another thing: why is the FILE type in uppercase? was it once a macro?
<lfam>Shall I pull K&R off the shelf and look it up? :)
<unmatched-paren>but the difference is that cargo is basically the only obvious choice; you could use a bunch of eldritch makefiles, but 99.99% of packages use cargo, which makes it way easier to decide
<lfam>Since Rust doesn't support all the architectures that Guix supports, we have a problem
<lfam>Additionally, Rust dependency graphs are cyclic, and so they can't be modeled in Guix
<nckx>unmatched-paren: Sorry, I shouldn't have commented on V. The vapourlang author & community are so vindictive that I'd rather not waste time on it. Life's to short to discuss genuinely unpleasant things (yes, despite grumbling about C/C++ — I not-so-secretly enjoy it! 😉).
<apteryx>reporting issues to mrustc author and reports about using the latest commit sure does help still
<nckx>apteryx: Could you share that broken file? I haven't tried gexping modify-inputs yet. Has anyone here?
<lfam>nckx: Check my "new style" commits from yesterday
<V>Most of the one-letter-nick people are staff, which makes them fairly easy to keep track of
<teddd>Just changed the hash. It now dowloads things the submodules :)
<nckx>teddd: Because these things are content-addressed (unless you change the file name blah blah), so if you ask Guix for a hash it already has, it will just keep giving you the same content. The git-fetch sexp does not ‘identify’ a checkout; the hash does.
<NicholasvonKlitz>I'm currently trying to update librsvg to 2.52.5 (including it's dependencies freetype, harfbuzz, pango, fontconfig, etc.). However, something is now causing rustc to rebuild (which leads to my computer running and crashing while trying to bootstrap it) and I don't know what. Is there anyway to find out what is causing rust to rebuild?
<apteryx>unless you touch librsvg-bootstrap it shouldn't
<bdju>is the guix issue webview not working? I've tried to pull up a few recent issues without success
<unmatched-paren>looks like a theoretical `guix git-download` would really just be a command wrapper around (git-fetch-ref) in guix/git-download.scm
<attila_lendvai>so, there are two namespaces: the scheme one, and the guix package repository. when i work on an importer (golang), it skips the packages that are already available, but then it has no clue under what variable name they are, and in which scheme module. should all dependencies emitted as (specification->package email@example.com") forms?
<apteryx>NicholasvonKlitz: yes, but (inherit librsvg)
<nckx>Yeah, I lurk in Freenode… it's bad. Thanks for letting us know.
<KarlJoad>I can't seem to even get the hello package to build from the default Guix channel using Cuirass... I used both the `specification` version from a configuration file and the web UI, but the both produce non-functional results.
<rekado>teddd: oh, like installing a build node in the data centre :)
<jonsger>booting a 10G linux image, just for updating
*jonsger wishes there were a freedom respecting server vendor with FOSS firmware + BIOS...
<teddd>not sure I understand, you need to get trough firmware updates to get to use the servers there ?
<rekado>this server is still stuck on “Loading BIOS drivers”; literally the first item on the list. So we can’t even get into the server setup, so we need to poke around with idrac or the management app…
<Gooberpatrol66>i added documentation to a guix checkout, ran make, started a vm with the checkout, ran info guix, and the changes didn't appear. what is the correct way to test changes to documentation?
<rekado>Gooberpatrol66: build the documentation and then open the file explictly with your info reader
<rekado>KarlJoad: I think this makes sense. On the other hand, it’s not really Cuirass that needs nss-certs (any more than, say, wget needs it).
<rekado>KarlJoad: maybe send an email to guix-devel to discuss this
<KarlJoad>rekado: Ok. If it is a runtime dependency for the `wget` run by Cuirass, I understand it not necessarily being part of the required Cuirass packages, but documentation about requiring it would make sense in that case. Otherwise, I personally think it should be part of the Cuirass-required runtime dependencies.
<rekado>Gooberpatrol66: I use Emacs: C-u C-h i the-file.info
<Gooberpatrol66>i run grep on that file and it contains a string, and i open it with info and it opens a file that does not contain that string
<mala>so I'm using guix offload fine on one of my guix systems, but it fails to successfully build anything coming from my guix-on-debian box. Is there a good way to get debug logs from a remote build?