IRC channel logs


back to list of logs

<Christoph[m]>AdaCore sponsors the Software Heritage Project:
<Christoph[m]>Maybe they can help with bootstrapping gnat?
<nckx>civodul: Is the ability to successfully use #$output:blah without declaring (outputs (list "out" "blah")) API?
<nckx>Because it's nifty as heck.
<raghavgururajan>jgart opalvaults[m] podiki[m] : You might want to check-out efraim 's guix-config also.
<KE0VVT>Oh, THAT'S why my jet engine is taking off! I left an upgrade in a tmux pane somewhere.
<podiki[m]>raghavgururajan: thanks
<KE0VVT>Telegram Desktop gives me so many issues.
<raghavgururajan>jgart: Chezmoi looks amazing. I think it's key-concepts could be incorporated into home-files-service-type, by extending it. :D
<vldn[m]>never get used to dotfile managementsoftware, just use my symlinks in my bashrc init :D
<KE0VVT>raghavgururajan: No need for Chez Moi. We have Guix Home.
<jgart>I've checked out efraim's configs before. He has great stuff
<jgart>kitnil still uses chezmoi
<KE0VVT>raghavgururajan: Or, do you mean Chez Moi supports storing "~/.ssh/" and "~/.gnupg/" in Git?
<jgart>I wonder if kitnil is slowly migrating to Guix Home or using both in tandem
<KE0VVT>I want my dotfiles in Guix Home.
<jgart>both := guix home and chezmoi
<KE0VVT>Can someone migrate my files to Guix Home for me?
<jgart>doesn't guix home have an importer? I haven't tried it and I might not understand the scope yet of the `guix home` importer
<KE0VVT>jgart: All it does is import “.bashrc”.
<KE0VVT>…and your installed apps.
<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.
<vagrantc>hope you can find more hairs :)
<jgart>bashrc is a good enough for me though. That's maybe all I need at the moment.
<jgart>KE0VVT, > guix home: error: open-file: Not a directory: ".bashrc/home-configuration.scm"
<chipb>KE0VVT: what an unfortunate user name for a bash user...I was expecting a .cshrc in that repo. ;-P
<jgart>KE0VVT, > jgart@guixmobile ~ λ guix home import .bashrc
<jgart>I get the error from the above command
<KE0VVT>jgart: Hm.
<jgart>Am I using it wrong?
<KE0VVT>jgart: Yeah, I just used the thing that grabs all the files it can and generates a config dir.
<jgart>Usage: guix home [OPTION ...] ACTION [ARG ...] [FILE]
<jgart>KE0VVT, do you happen to remember the command you used?
<KE0VVT>jgart: I don't, sorry.
<jgart>ok, no worries
<KE0VVT>jgart: I'm scared of using Guix Home right now. Migrating is just so complicated.
<jgart>I'll have to find the time to watch some more Andrew Tropin videos
<jgart>on guix home
<jgart>or RTFM
<KE0VVT>jgart: A lot of time, he just says to read the code. >_>
<jgart>or read the source
<KE0VVT>I tried using RDE, but it failed on me.
<jgart>I should schedule that
<KE0VVT>I thought RDE would make it easier to migrate to Guix Home.
<jgart>KE0VVT, maybe open an issue to include install instructions for RDE?
<jgart>that would be useful
<KE0VVT>He said he'll do it once the code is more stable.
<jgart>Ok, I guess we'll just have to wait or put in the time
<KE0VVT>jgart: I can't code. :-(
<KE0VVT>I've tried to learn. I'm just bad at it.
<the_tubular>Anyone tested : ?
<KE0VVT>jgart: I did write this: <>.
<jgart>KE0VVT, Do simple things with code
<the_tubular>Looks very interesting, finally I can get rid of docker
<jgart>What are you trying to code?
<KE0VVT>jgart: Explanation here: <>.
<jgart>KE0VVT, cool, that's not bad
<jgart>maybe, don't measure yourself by how well you can build a self-hosting compiler in 10 days
<jgart>I sure can't do that well or at all if you give me 10 days starting from today
<jgart>Or maybe I can. Not sure, haven't tried ;()
<KE0VVT>jgart: I tried writing it in the literate style. It's hard.
<jgart>I haven't used noweb
<jgart>How should I start checking it out?
<jgart>I started using org babel recently. It's the only thing I use org for now. I journal with jrnl currently
<jgart>guix install jrnl if you want an ancient version
<KE0VVT>jgart: I started by writing something small, with only one <<thing>>, then tangled it to see if it would run.
<jgart>unfortunately pep517 blocks jrnl in guix atleast on master
<KE0VVT>jgart: I don't like how Org handles code chunks. All of <<These things>> are expanded in the printed document. It makes the code illegible.
<jgart>KE0VVT, this is another cool literate system I discovered some months ago:
<jgart>It uses markdown for tangling and untangling instead
<jgart>it's written in dlang
<KE0VVT>I would prefer Texiweb and Texiweb Jr. so programs can be read in GNU Info, the web, or in books.
<raghavgururajan>KE0VVT: It also handles file permissions. We can modify home-files-service-type to include fields for permissions.
<jgart>and the implementation is less that half the size of org-mode
<KE0VVT>I like Texiweb but I am sticking with Noweb because it is more established and has actually been used for projects like Axiom.
<jgart>raghavgururajan, KE0VVT
<jgart>that's the output of `guix home import bashrc`
<raghavgururajan>jgart: Guix home has importer, but currently only imports shell files and packages list.
<jgart>the error on my part was that I had used a dot
<KE0VVT>jgart: Oh, you did it!
<jgart>the first one will make `guix home` trip out
<KE0VVT>I wish Texiweb Jr. produced decent printed manuals.
<jgart>I was thinking you could import individual files
<KE0VVT>Texiweb is like CWEB and Texiweb Jr is like Noweb.
<jgart>guix home [OPTION ...] ACTION [ARG ...] [FILE]
<jgart>it says that it takes file as arg
<raghavgururajan>jgart: `guix home import ~/guix-config`
<jgart>but maybe it should be DIRECTORY?
<raghavgururajan>The argument is where you want to put the output of import.
<jgart>Yup, that's a directory after the ACTION
<jgart>ACTION is import
<jgart>FILE is ~/guix-config
<jgart>in your example
<jgart>but it's actually a directory
<jgart>unless we want to think of files as directories and directories as files?
<KE0VVT>So, “guix home import dotfiles”.
<jgart>that will create a directory with the name dotfiles
<jgart>`guix home build bashrc/home-configuration.scm`
<jgart>ice-9/boot-9.scm:222:17: In procedure map1:
<jgart>Throw to key `quit' with args `(1)'.
<jgart>guix home: error: git:send-email: unknown package
<jgart>guix home: error: failed to load 'bashrc/home-configuration.scm':
<jgart>guix home failed to load the config it just generated from `guix home import`
<KE0VVT>Maybe I should try RDE again.
<the_tubular>guix home import is a thing ?
<KE0VVT>Installing Sway.
<jgart>the_tubular, looks like it
<nckx>sneek: later tell civodul This is cybercrime:
<sneek>Will do.
<nckx>sneek: botsnack :)
<nckx>‘guix style’ does not handle in-line patches well.
<jgart>nckx, can you show an example of an in-line patch?
<nckx>jgart: I meant in-line origins (here) used for patches. I don't think anyone's been so mad as to include an actual in-line patch!
<jgart>oh nm, you meant patches in an s-expression?
<nckx>I'm morbid but not that morbid.
<the_tubular>nckx did you call the cyberpolice ?
<nckx>They no longer pick up when I call.
<jgart>What's the quickest way to get the bleeding edge of elisp packages? `guix home` or a guix channel?
<jgart>I'd like to track exact commits instead of version releases
<jgart>I'd like it to be convenient
<jgart>I thought I had seen some guix home config for elisp packages in the wild some weeks ago
<jgart>can't find it now
<nckx>The *quickest* way is probably guix install --with-commit. The vast majority of emacs- packages already use git-fetch.
<jgart>oh cool, I should have thought of that
<jgart>but didn't ;()
<singpolyma>When I'm packaging something with an importer, should I prefer to switch it to git-fetch where the git is known?
*jgart guix install emacs-evil-collection --with-commit=emacs-evil-collection=f31162b2536d14bf97fe96d6e54be0d091ba9493
*jgart yay!
*jgart ⏳️😅️
<raghavgururajan>jgart: Are you on zopiclone? :D
<jgart>haha no
<jgart>but I think guix is
<jgart>with the above command
<jgart> emacs-minimal-27.2 35.2 MiB 29KiB/s 10:56 [######### ] 52.9%
<nckx>‘It does that.’
<jgart>nckx, how can I tell?
<jgart>substitute: updating substitutes from ''... 100.0%
<jgart>substitute: updating substitutes from ''... 100.0%
<nckx>If it didn't print ci.guix or bordeaux.guix, you can't (easily).
<nckx>Unfortunately not for a while now. User friendliness won.
<jgart>is ci.guix the one in Berlin?
<nckx>singpolyma: That might depend on the conventions for that language, but in general I prefer git nowadays, if the git repository is complete (tests, etc.) and generally sane.
<nckx>jgart: Yes.
<jgart>ah ok
<jgart>nckx, wdyt of guix supporting fossil repos?
<nckx>The machine is named ‘berlin’, which is more the reason I say it than the location (which is also, that notwithstanding, Berlin).
<nckx>I've never used fossil.
<jgart>I'd like to run a Guix Channel from a fossil repo some day
<nckx>Oh, like that.
<jgart>VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC
<jgart>ohh my
<jgart>then, no need for sourcehut
<jgart>laminar for CI
<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.
<jgart>maybe we can allow the user to choose the authentification method for a channel?
<nckx>It's not going to happen unless the majority of maintainers/contributors fall in love with fossil and want to move main Guix development to it. Personally, I don't see that happening.
<singpolyma>It needs to be a VCS because of integration with "guix pull"?
<nckx>Choose your own crypto?
<nckx>If there were choices authors would choose, not users.
<jgart>I wouldn't implement a crypto for authenticating the channel
<jgart>if I do, run away haha
<jgart>guix depends on guile-git
<jgart>do channels use those bindings?
*jgart reads
*nckx AFK a while.
<jgart>maybe we need guile fossil bindings or just simple cli wrappers
<jgart>for fossil
<lfam>It might be nice if you could do something like `guix build --cache-failures` on shared servers
<lfam>I'm not sure how it would work. Maybe each user would have a failed build cache
<lfam>Maybe it's worth the effort, idk
<jgart>I think I know the answer to this already but can I offer users a custom home-service in a guix channel?
<guixy>jgart: Sure, why not?
<guixy>But I think it would be better to have it in upstream guix.
<jgart>Yup, that's what I though since a guix channel can contain any guile code/modules?
<jgart>sure, I would too
<jgart>but sometimes it's nice to have it available conveniently as a pre-release while we wait for review
<guixy>I agree
<guixy>Is it possible to install guix by running `guix deploy` to a system running the install image?
<guixy>Or does it break because it needs cow-store?
<jgart>by "install image" do you mean any machine running Guix System that is the target of `guix deploy`?
<guixy>By `install image` I mean the installer
<guixy>On removable media
<jgart>oh ok, so like, running guix deploy on a target system running the live iso?
<guixy>I'm trying to do exactly that. Got it on the network and set up ssh server
<jgart>that would be cool
<mroh>lfam: I think, the hard thing (as usual for caches) will be: when to invalidate entries...
<jgart>I haven't tried that
<jgart>s/cool/cool and convenient
<guixy>I already deploy to 2 laptops, both already running guix
<guixy>I have laptop #3 running the install image.
<guixy>SSH authentication failed for '': Access denied for 'publickey'. Authentication that can continue: publickey,password
<guixy>publickey denied, needs `publickey
<guixy>Which public key do they want?
<nckx>root by default, but guix deploy can sudo if you don't like that.
<guixy>My root?
<nckx>Which else?
<nckx>jgart: You'd need (well, want) Guile bindings yes.
<nckx>You could write ‘bindings’ that just invoke command line tools, but I'm not sure that will be fun at all.
<nckx>I'm almost certain it won't.
<mroh>be careful to `guix deploy` to a machine where the only access is ssh:
<nckx>mroh: --cache-failures currently handles cache invalidation by not handling it at all, i.e., deferring to the user 😉 So nothing would need to change there.
<KE0VVT>Are we doing Markdown on IRC now?
<guixy>My root doesn't have a public key, but I'm deploying to my 2 laptops just fine.
<nckx>Well, as noted, it's just the default.
<guixy>It looks like I relied too much on a generic configuration. I'm deploying with an "admin" user that doesn't yet exist on the target machine.
<guixy>I have physical access to laptop #3 luckily enough. I just need to get out of this comfortable armchair and walk into the next room to access it.
<the_tubular>nckx, do you use bcachefs as the root files system ?
<the_tubular>Also mroh, I haven't read the full thread but I'm pretty sure it's not related to guix deploy
<the_tubular>Same thing happened to my machine and I never used guix deploy
<nckx>I do the_tubular.
<the_tubular>Just curious, I bought a new SSD to test guix and might want to give this a try
<nckx>the_tubular: No, but the implication with guix deploy often (not always) is ‘headless machine, not easy to log into withou SSH’.
<the_tubular>Yes, I get that. The way I understand it was that it was caused by guix deploy
<nckx>the_tubular: It's not usable with vanilla Guix.
<the_tubular>How do you use it ?
<mroh>the_tubular: I know, you said that the very first day of your problems... the warning was more for guixy, who deployed to some machines.
<the_tubular>AIght :)
<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.
<the_tubular>That's a lot of info
<nckx>I'm sorry.
<the_tubular>1st. I though the goal of bcachefs was to fix ZFS liscense problem
<the_tubular>What is it licensed under ?
<nckx>Kent wrote bcachefs, kept writing it, thought ‘hm I'm basically writing a file system here’, forked it as bcachefs.
<the_tubular>Also 2. did You publish those patches, I'd be curious to take a look
<vagrantc>oh wait, bcachefs is it's own filesystem, not some add-on for btrfs?
<the_tubular>And also 3. Any numbers on the data eaten ?
<nckx>vagrantc: It has nothing to do with btrfs.
<the_tubular>Totally unrelated to btrfs, vagrantc. More related to bcache
<nckx>I mean, not even historically or familially.
<vagrantc>nckx: they both begin with "b", obviously.
<nckx>Hm. I have no counterargument. You win.
*vagrantc dances
<the_tubular>I wonder if I should try bachefs on backed up data
<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.
<nckx>Sleeping is fun.
<nckx>And with that honestly unplanned segue, it's off to bed for me.
<nckx>o/ Good night #guix
<vagrantc>nckx: last time you said that a while later a bunch of patches landed in guix git
<lfam>I tested an update of the go-build-system along with an upgrade to Go 1.17. Everything builds! So, please apply these patches and test your favorite Go programs: <>
<lfam>mroh: Re cache invalidation, yeah I agree
<podiki[m]>oh nice
<lfam>When working on my own, I sometimes enable cache-failures in the daemon while working on a big project, and then turn it off at the end, and clear the failures then
<lfam>The nice thing is that this cache doesn't take disk space. It just makes the daemon remember that a derivation failed to build, and so it won't build it again
<lfam>So, it's not a total disaster if the cache isn't cleared regularly
<mroh>nice, indeed!
<the_tubular>nckx Sorry, just read your message. What is the license issue exactly ?
<the_tubular>Also, yeah I follow bcachefs, and for a one man team, It's pretty impressive
<the_tubular>Writing a file system is way out of my league
<ns12>Are new style inputs (list package-a package-b) preferred over old style inputs `(("package-a" ,package-a) ("package-b" ,package-b))?
<ns12>Is it documented?
<ns12>Will the old style be deprecated?
<jackhill>Any tips on trackign down Xwayland failing to start up automatically with sway? It wokred for me at some point in the past, but now it doesn't
<jackhill>I seem to have starting having the problem sometime between d627fbad8f4e157103251b07d7543dd2f5647cea and 11334d15d590073c631c574436d2110aa1ea2142
<podiki[m]>ns12: should be in the current manual, and see
<podiki[m]>(you can use the old style for a while still)
<KarlJoad>Can I find the source code used to define the Guix infrastructure somewhere? Namely the config used for
<mroh>KarlJoad: Not sure if ci configs are included, but you can try `git clone`
<lfam>The configuration for is indeed in the maintenance.git repo
<KarlJoad>Ok. Then I will have to go searching for what I want in there. I just want to be able to connect to a Cuirass instance using a web browser, from another system.
<jackhill>bug submitted for my Xwayland problem:
<lfam>KarlJoad: Check the file 'hydra/berlin.scm'
<lfam>That's the entry point
<KarlJoad>lfam: Figured it out. Just set the thing IP address it would listen for to
<lfam>Hydra is the name of the CI software that we used to use. We still use the word to describe the overall build farm infrastructure. And berlin is the name of the head node of the build farm
<lfam>There ya go
<KarlJoad>Does Cuirass (the package) support a request to build a specification? (Not the CI system, but a personal instance of cuirass.)
<lfam>Hopefully somebody else can answer
<nckx>vagrantc: I push all my patches whilst asleep.
<nckx>the_tubular: I'm not aware of any licence issue, I thought you brought that up?
<vagrantc>nckx: i have much to learn.
*nckx mumbles something; rolls over.
<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.
<lfam>Sounds good apteryx
<lfam>I'm planning to push an xorg-server update to master, pending further feedback / testing
<lfam>And also an update of Go along with improvements to the go-build-system
<lfam>The latter I think is fairly self-contained within the distro. Like, nothing that's not part of Go depends on it
<lfam>The X update should definitely get some more people testing it
<apteryx>oh, why to master? we can batch it with version-1.4.0 (already in those 58 commits)
<lfam>I figured why not? It doesn't have many dependent packages
<apteryx>are you sure?
<lfam>I think so...
<lfam>Am I missing something?
<apteryx>through these xorg-server-for-tests or something
<lfam>That's why I adjusted the xorg-server-for-tests package :)
<lfam>So that we can keep that derivation unchanged and avoid a mass rebuild, while still deploying the updated X for actual users
<lfam>And the Go patches: <<>
<apteryx>OK, sounds good; the patch I had locally was kaelyn's
<apteryx>(just version bump to 21.1.2 with hash)
<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`
<apteryx>version-1.4.0 is still pretty much empty so far
<apteryx>I'll rebase my local branch on master and recreate it tomorrow, if my night of building stuff looks good
<lfam>It would be great to have these patchsets I'm reviewing available in 1.4.0 for new users and Guix System installation
<apteryx>so master changes will be in
<jackhill>ugh, the release notes here are hard to read :/
<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 fix that rebuilds most of the world)
<lfam>I see
<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
<apteryx>I'm good with it!
<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, 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
<lfam>I booted Xfce with 21.1.2 last night, seemed okay
<apteryx>I noticed fonts looked a bit crisper or something; I attributed by fontconfig upgrades, although that's just purely a guess.
<lfam>Well that's nice
<apteryx>anyhow, that's a pleasing change to my eyes
<apteryx>I upgraded gtk to 4.4.1 also
<jackhill>lfam: answer about wlroots, is we need to do it on core-updates I think. wlroots would only cause 5 rebuilds, but it needs a newer wayland which would case 3660 (according to guix refesh -l)
<lfam>So will there be 3 GTK+ packages then, apteryx?
<lfam>I see jackhill
<apteryx>there already is, lfam
<lfam>Oh, shows what I know
<apteryx>gtk+-2, gtk+, and gtk (which is 4)
<apteryx>currently it was at 4.2.1
<lfam>They got rid of the +!
<lfam>Well jackhill, hopefully we can get through the next core-updates cycle more quickly than the last one
<apteryx>yes! they must have gotten tired to type it or something
*apteryx -> zzz
<lfam>C ya
<apteryx>see you :-)
<jackhill>haha, I hope so :)
<podiki[m]>sneek: later tell apteryx oh nice about even newer Mesa for 1.4.0, but of course they are now on 21.3.2 (they are keeping a quick pace)
<sneek>Got it.
<lfam>What is up with the big jump in version numbers?
<podiki[m]>sneek: later tell apteryx and that would save an extra staging branch (or something) to have the mesa update, so I think that would be great (assuming no breakage)
<sneek>Will do.
<podiki[m]>lfam: on mesa?
<lfam>And X too
<podiki[m]>mesa just seems to have a quick cycle (since I started paying attention recently), seems every ~5 months goes up from 21.x to 21.x+1
<podiki[m]>but first release is always development, then the later releases are meant to be stable (so 21.3.0 was devel out november, few weeks later 21.3.1 stable)
<lfam>I misunderstood your message about 1.4.0 -> 21.3.2. The former is the Guix version
<podiki[m]>that would be something!
<lfam>I thought their versioning jumped. But, X's did
<podiki[m]>go the way of firefox or chrome :)
<lfam>X went from 1.20.11 to 21.1.1 on core-updates
<apteryx>podiki[m]: fixed, thanks!
<podiki[m]>X I don't know
<sneek>Welcome back apteryx, you have 2 messages!
<sneek>apteryx, podiki[m] says: oh nice about even newer Mesa for 1.4.0, but of course they are now on 21.3.2 (they are keeping a quick pace)
<sneek>apteryx, podiki[m] says: and that would save an extra staging branch (or something) to have the mesa update, so I think that would be great (assuming no breakage)
<podiki[m]>oh, new scheme?
<podiki[m]>apteryx: thanks!
<lfam>podiki[m]: Seems that way
<apteryx>they split xorg-server-wayland into a separate repo
<podiki[m]>X is just in bug fixes mode now? or is it doing new stuff still?
<podiki[m]>oh right,that too
<apteryx>alright, really of for some zzz now, eh
<apteryx>night, gentlefolks
<podiki[m]>good night!
<PurpleSym>Savannah is down?
<efraim>looks like it, I can't pull
<rekado>even seems to be down.
<rekado>hosting a Guix forge: when?
<efraim>our use-case minimum seems to be git-daemon and cgit? or would we want all of gitea or something?
<rekado>it would be useful to have server-side per-branch rules and checks
<rekado>permission management too.
<PurpleSym>+1 for gitea (or similar).
<rekado>doesn’t mean we have to enable a pull request workflow
<efraim>I can try poking the instance of gitea I manage and see what it has in terms of per-branch rules
<rekado>but something we can more easily manage on our own would be neat
<PurpleSym>Some server-side checks before pushing/merging to master could prevent most of the trivial breakage.
<vivien>I agree with that
<vivien>Even running guix style
<jgart>A location record returns information like this for the location of a package:
<jgart>#<<location> file: "gnu/packages/suckless.scm" line: 217 column: 2>
<jgart>I'd like to delimit the range of a package
<jgart>Any ideas?
<jgart>The above location object is for dwm from the suckless module
<jgart>I called it like this in a guix repl: `(specification->location "dwm")`
<efraim>I assume you're looking for the end of the package also?
<jgart>If only I could encode whatever % does in vi for parens bouncing haha
<jgart>efraim, yup
<efraim>something something awk, looking for the closing parenthesis?
<jgart>So I can know what to pass to a script that calls `bat gnu/packages/suckless.scm -r x:y`
<jgart>or using cat instead
<jgart>or tac
<jgart>path arg to bat would be a variable
<jgart>depending on the module/package
<vivien>Why not an emacs script?
<jgart>efraim, awk can parse s-expressions?
<jgart>Or maybe I am thinking too hard...
<jgart>vivien, what were you thinking from elisp that would be useful?
***DannyOB[m] is now known as malamatrix
<vivien>There’s a function in guix to run a emacs batch script to substitute lisp code
<rekado>you can just read the expression with Guile, no?
<rekado>advance the port and then look at the seek into the port
<rekado>etc/committer.scm has to do something similar
<vivien>It’s awkward to advance in the port until a specific line / column has been reached, because the column number can decrease
***malamatrix is now known as malaclyps
<vivien>But in a normal situation, that’s a valid way to go :)
<jgart>rekado, I'll check out committer, thnx
***malaclyps is now known as mala[m]
<jgart>(define (surrounding-sexp port line-no)
<jgart>"Return the top-level S-expression surrounding the change at line number LINE-NO in PORT."
<jgart>that looks promising
<efraim>rekado: gitea has the ability to only allow pushes when commits are signed, and to restrict branches to certain contributors
<efraim>*signed including signed by the gpg key registered to that user in the gitea instance
<jgart>I'd just like to have a package as arg instead of a port
<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:
<jgart>I had recently packaged pudb for guix:
<jgart>From #kiss on libera: Featyre‎: Lmao is down I cannot download binutils
<rekado>(doesn’t understand the joke)
<tissevert>hello guix
<jgart>rekado, just reporting that someone else found to be down. Not sure why they are all lmao about it either
<rekado>oh, ok
<rekado>in Chinese we say “xiao4 dian3 hen3 di1”
<rekado>(literally: laughing threshold very low)
<tex_milan>Hello Guix. How to install nerdfonts? Anyone have a package for it?
<rekado>weird that there’s no status update on
<cehteh>everyone sleeping?
<efraim>They are centered out of the Boston area
<attila_lendvai>how do people configure their gnome extensions? `flatpak run org.gnome.Extensions` errors out on me.
<rekado>I’m not using flatpak with my Guix System.
<rekado>is this mandatory to use gnome extensions?
<rekado>*when using
<jpoiret>attila_lendvai: what kind of error?
<attila_lendvai>rekado, IIUC, this is the currently suggested way by upstream
<attila_lendvai>but i'm open for any alternative way to configure the extensions
<attila_lendvai>gnome-extensions-app also errors out on me:
<jpoiret>attila_lendvai: can you do `gjs $(guix build gnome-shell)/share/gnome-shell/org.gnome.Shell.Extensions`?
<abcdw>Can't pull guix.git from savannah. Is something happend to it or it's my local setup problem?
<abcdw>fatal: unable to access '': gnutls_handshake() failed: Error in the pull function.
<jpoiret>abcdw: savannah and are down
<abcdw>jpoiret: ok, thank you. Do you have any additional info on what is hapenning or a place, where we can follow the status?
<jpoiret>no. apparently, the tech team behind both are around the boston area, so it might take some time until they're up
<jpoiret>okay, I think I know what might cause the problem
<attila_lendvai>jpoiret, excellent! let me know if i should test something!
<rekado>abcdw: there’s but nothing has been posted there
<jpoiret>attila_lendvai: do you get the same error when running `$(guix build gnome-shell)/bin/gnome-extensions-app`?
<abcdw>rekado: Thank you! BTW, maybe there is a guix mirror somewhere? I need a few recent commits related to wireplumber, pipewire and xdg-portals.
<jpoiret>abcdw: there's
<abcdw>jpoiret: Thank you very much!)
<jpoiret>you can possibly also just download patchsets from
<abcdw>jpoiret: I already did and tested them, now I want to get the code, which was actually committed, also I hope the substitutes for chromium-wayland is available too.
<jgart>Guixers, what does G_ usually stand for in the arg to syntax-rules?
<jgart>I'm looking at `(define-syntax define-command-categories ...`
<jgart>... `(syntax-rules (G_)`
<jgart>I mean, what is the convention for using `G_`?
<cbaines>jgart, I think it's a gettext related thing
<cbaines>so it's something to do with a string being translatable
<jgart>Looks like it's an expression: `(cut gettext <> %gettext-domain)`
<jgart>function: (define G_ (cut gettext <> %gettext-domain))
<jgart>because `cut` creates a lambda with one arg <> iirc?
<jgart>darn, the one time I actually try to read guile docs is down... ha ;)
<cbaines>I think you're roughly right
<cbaines>so, G_ ends up being a specialised version of gettext, where the second argument is %gettext-domain
<rekado>jgart: you’ve got guile docs in your info reader
<vivien>Gettext strings sometimes are in the form "context|Text", where we are expected to drop anything until the first | in case the string has not been translated.
<vivien>I think the G_ macro does not do it
<vivien>So I redefined it to call gettext, and remove anything up until the first |
<vivien>That’s useful for GUI elements for instance
<jgart>I don't have my info reader installed
<jgart>or the guile docs as info pages
<jgart>should've done that before the lights went out
<jgart>A convoluted way to say `((cut display <>) "hello guixers!\n")`
<jgart>maybe didactic, maybe not
<jgart>scheme@(guix-user)> ,exp ((cut display <>) "hello guixers\n")
<jlicht>hey guix!
<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 looks
<attila_lendvai>yoctocell, could it be the case that jami-account disagrees with the codebase in configuration.scm? if you look there for 'undefined, there are several matches in relevant contexts.
<attila_lendvai>and there's only one mention of 'diabled
<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
<yoctocell>something like this: <>
<yoctocell>attila_lendvai: 'disabled is a user-facing thing, while 'undefined is just an implementation detail
<the_tubular>Anyone has a nice emacs conf made with guix home ?
<the_tubular>I'm looking for ideas
<jgart>probably abcdw
<jgart>or yoctocell
<jgart>maybe kitnil
<yoctocell>attila_lendvai: maybe sharing your error message would help?
<yoctocell>the the_tubular: I don't think Guix Home has an Emacs service yet?
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, nckx says: This is cybercrime:
<the_tubular>Ohh really ?
<yoctocell>the_tubular: I think it's only part of rde
<the_tubular>I'm not familiar with rde
<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...
<the_tubular>Wait, isn't it the original guix home repo ?
<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
<yoctocell>attila_lendvai: I have a patch that will document (gnu services configuration); maybe you want to have a read and give some feedback? <>
<yoctocell>attila_lendvai: i gotta go now, sorry
<attila_lendvai>yoctocell, that, and also my expectation that maybe-foo should tolerate unspecified values
<jlicht>zimoun: afaik, the recently-'established' convention is to put it on one line, if there are N or fewer inputs, for a specific small N
<attila_lendvai>yoctocell, me, too, afk for a while. i'll read it and we'll get back to this later.
<zimoun>jlicht, yes and this new convention is only because “guix style” and I think it is harder to read.
<mbakke>ooh, removing a native-inputs identical to propagated-inputs, causes no rebuilds on the same architecture
<mbakke>were inputs always deduplicated like that?
<mbakke>not sure if bug or feature, but I'll take it
<jlicht>zimoun: Having a `guix style` command that conflicts documented advice seems like suboptimal. Are you (implicitly) proposing to adjust guix style output as well?
<zimoun>jlicht: yes. I suggest to have always one input per line, as previously. Instead of something depending on “obscure” rule. :-)
<civodul>zimoun, jlicht: there's a #:long-list parameter set to 5, meaning that "guix style" tries to fit lists of 5 or fewer inputs on a single line:
<civodul>mbakke: yes, it's been this way for some time i think
<zimoun>civodul, yes. And I think it should be one input per line.
<civodul>ok; i like it this way :-)
<civodul>we can see what others think and adjust accordingly
<civodul>it would have been best to adjust before the big commit, but better late than never
<jlicht>... and let's paint it yellow! ;-). FWIW, based on nothing but subjective experience, I much prefer the current output of e.g. recursive pypi import commands
<civodul>to me, the #:long-list heuristics was a middleground to keep things concise in simple cases while keeping readable diffs in cases of long lists
<jlicht>civodul: did you get a chance to consider the git-blame-ignore-rev approach for ignoring stylistic changes? Or is this no longer applicable?
<zimoun>Savannah is down, right?
<the_tubular>I'm about to try importing a python project, any tips ?
<rekado>civodul: I attached the SAN on and ran the performance test again
<rekado>the SSDs in there seem to help
<vldn[m]>i found via google this today:
<the_tubular> seems down
<rekado>READ: bw=1547MiB/s, WRITE: bw=528MiB/s (with bs 512k)
<vldn[m]>if i understand correctly the person used it to just upgrade packages when there are substitutes avaiable
<vldn[m]>not just on pulling like with substitutes-avaible..
<vldn[m]>you even can select packages in channels.packages.scm
<vldn[m]>somebody using something similiar or can verify that it's working? :D
<rekado>the attached storage where /gnu sits: READ: bw=215MiB/s, WRITE: bw=73.1MiB/s
*rekado sits in the data centre
<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
<raghavgururajan>Hello Guix!
<rekado>an unusually large amount of data is transferred from
<civodul>cbaines: yes, the IPv6 config is in a comment in bayfront.scm
<civodul>so we should be able to turn it on
<raghavgururajan>rekado: Do you have to address? Like IP?
<civodul>cbaines: now, going to the data center is tricky (need to schedule in advance), so it'd be best to not make mistakes :-)
<civodul>i was thinking about going there to switch disks but haven't yet studied all this
<civodul>rekado: nice! so you put new SSDs in there, right?
<civodul>jlicht: re git-blame-ignore-rev, i think it's a good idea and i suggested submitting patch, didn't i? :-)
<aadcg>has anyone seen this:
<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/" "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ version `GLIBC_2.33' not found (required by /gnu/store/4xx9v8qvc3n9pqml3qp4ss2nan6f3b6f-libgit2-1.3.0/lib/")
<cbaines>civodul, I did see that, and I tried running the commands, but I don't think v6 connectivity is working yet
<cbaines>if that's the right configuration though, that's fine, I probably did something wrong
<cbaines>and hopefully this is something that doesn't require going to the data center for
<aadcg>and when I run `guix pull`: guix pull: error: Git error: SSL error: syscall failure: Connection reset by peer
<rekado>civodul: no, I haven’t added SSDs. The SAN uses tiered storage, so there’s a top layer of SSDs. When the SAN has been extended we might move /gnu/store over there.
<civodul>aadcg: hi! is LD_LIBRARY_PATH set? looks like there's a mixture of pre-merge and post-merge (glibc 2.31 vs. 2.33) binaries being used
<civodul>rekado: ah so it's a new SAN, not the thing currently behind /gnu/store? (i'm confused)
<aadcg>civodul: oh, I see. thank you!
<civodul>cbaines: ah, then we can check with the folks on #aquilenet whether something else needs to be done
<civodul>looks like {savannah,fencepost,lists} are down
<rekado>civodul: correct. Separate storage.
<rekado>we use that SAN for other servers
<civodul>ah ok
<rekado>there’s maybe 20T free, so not quite enough for our store as is
<rekado>but we will get an extension next year
<rekado>in the meantime I’d like to run some performance tests
<civodul>that's great
<civodul>i had kinda forgotten about our gc issues on berlin, but it looks like it's still an issue
***goodspeed is now known as Nios34
<civodul>gc lock held, even :-/
<Nios34>Hello, everyone!
<Nios34>Is anyone using icewm? How to make it work on guixSD?
<apteryx>civodul: 996 GiB cleared in 20 minutes on an NVMe drive; perhaps we should take the splurge for solid state storage on berlin? that'd be a good use of our funds in my opinion
<apteryx>IO seems crucial on it
<apteryx>what's even more interesting, is that these 996 GiB were cleared from a 466 GiB size partition ^^
<civodul>heh :-)
<apteryx>(this is due to using Btrfs zstd compression)
<civodul>rekado: re debbugs, their X.509 certificate changed, too; perhaps that explains the big transfers?
<rekado>apteryx: we’re considering local NVMe for new storage for berlin. But we don’t know yet if we’ve got the funds.
<apteryx>rekado: ok, neat. What kind of drive size?
<apteryx>you can consider that with btrfs zstd, you should be able to get about twice as much real storage (as shown by the numbers reported by my last 'guix gc' above)
<rekado>depends on how much money we get
<apteryx>don't we have enough already, held at the FSF?
<rekado>we were aiming for 40 to 50TB
<rekado>money = MDC money
<apteryx>ah... to not intermingle Guix/MDC infrastructure at that fine grain level... I understand
<apteryx>so if you were considering 50 TB on ext4, you may now consider a 30 TB on btrfs + zstd or so
<apteryx>if cost is a concern
<rekado>what do I need to do to install btrfs?
<rekado>I’d like to test it with the SAN
<rekado>with compression we might be able to use the 20T that we already have
<rekado>part of the 37T we use right now is for /var/cache.
<rekado>getting the store itself off of the storage array and onto faster storage on the SAN seems like a feasible next step
<apteryx>rekado: wouldn't solid state storage gains be mostly offset by SAN? I was thinking local drives connected directly to the Berlin motherboard
*rekado runs guix install btrfs-progs
<rekado>apteryx: have you seen the fio bandwidth output above?
*apteryx has no experience with storage area network... are these like appliances you buy, running their own firmware?
<rekado>we have one controller Dell SCv3020, and four disk enclosures Dell EMC SCv320.
<zimoun>Is Savannah down?
<rekado>zimoun: still
<zimoun>ah, it was?
<jlicht>see for updates; still down afaik
<apteryx>rekado: re fio bandwidth, no haven't seen? what's the link again (can't find it)
<rekado><rekado> the attached storage where /gnu sits: READ: bw=215MiB/s, WRITE: bw=73.1MiB/s
<rekado>the SAN: <rekado> READ: bw=1547MiB/s, WRITE: bw=528MiB/s (with bs 512k)
<apteryx>OK; that's for serial (opposed to random) read/writes, correct
<zimoun>jlicht, thanks. I thought FSF was not GNU ;-)
<rekado>apteryx: random rw
<apteryx>that's pretty good
<rekado>and that’s without multipath
<rekado>i.e. we’re only using one of the connections to the SAN
<zimoun>jlicht, about painting the shed of ’inputs’. Well, I think one item per line is generally less error prone. Even for my grocery list. ;-)
<apteryx>rekado: don't know about Btrfs on these things, but I bet it's not really (meant to be) hackable.
<efraim>IIRC the only flag I use with mkfs.btrfs is '--metadata=dup', and that gets ignored on SSDs
<efraim>then I'll mount it with 'compression=zstd' for zstd compression at whatever base level
<efraim>Fedora uses zstd:1 for basically a free 20% bonus space
<attila_lendvai>yoctocell, FYI, i have answered on that configuration doc issue
<yewscion>Good Morning, Guix!
<rekado>apteryx: we export just a block device
<rekado>raw storage
<rekado>in Linux it appears as a block device that we can format any way we want.
<rekado>so I just need to know how to format btrfs with zstd and all that jazz
<rekado>can’t install btrfs-progs because of the GC lock :(
<rekado>anyway, enough data centre air for this week.
*rekado coughs
<apteryx>basically mkfs.btrfs; the rest are mount time options (e.g., compression)
<apteryx>I recommend using as options "compress-force=zstd,space_cache=v2"
<awb99>I am getting errors when doing guix pull. It strted after core-update merge. Does anyone have a similar problem?
<awb99>uix pull: error: Git error: SSL error: syscall failure: Connection reset by peer
<awb99>sometimes I also get this error: guix pull: error: Git error: failed to resolve address for Temporary failure in name resolution
<kwjc>awb99: if it makes you feel better, I get the same error.
<gnoo>awb99: kwjc some gnu servers are down
<awb99>I am sorry to her that twjc
<awb99>I guess the uild farm is very busy after the emerge of core update frozen
<civodul>cbaines: bayfront is now reachable at 2a0c:e300::58 \o/
<civodul>i'll push the update to bayfront.scm when Savannah is back
<cbaines>civodul, awesome, thanks for sorting that out!
<civodul>we're entering the 21st century
<civodul>cbaines: related to that, looking at hydra/K*.pdf, bayfront has a SAS controller
<civodul>the Aquilenet folks told me they have spare SAS disks they could give us
<civodul>so, IIUC, it may be that we could hot-add them (we're doing software RAID10 right now)
<civodul>problem of RAID10 is that it's a bit silly, and it seems that going from 2 to 4 disks may increase redundancy, but not storage
<cbaines>that sounds interesting
<cbaines>note that the storage situation on bayfront is much better now, it's 45% full, down from 88% last week
<civodul>oh, what happened?
<cbaines>in other news, fsf hosted things seem to be coming back
<cbaines>civodul, there's more information in but in summary, the nar-herder was used to move most of the nars to another machine
<civodul>ah good
<cbaines>this means that the fastest growing thing on bayfront is now /var/cache/nginx/bordeaux/ which Nginx will keep below a configured size
<cbaines>(it's ~730 GB so far and growing)
<civodul>neat; i'll catch up on email
<attila_lendvai>it's a pity this is still not merged: (Make gzip files writable before resetting timestamps)
<robin>oooh, i see a bash-mesboot0 in the 'guix upgrade' log
<apteryx>attila_lendvai: I'll add it to the version-1.4.0 branch (a world rebuild anyway), thanks for the ping
<attila_lendvai>apteryx, thanks for taking care of this! (an issue tracker with tags/milestones would help a lot with these issues)
<raghavgururajan>Regarding scheme-procedure `local-file`, is it possible to mention file paths with variables like $HOME?
<civodul>raghavgururajan: no
<civodul>you'd have to write (string-append (getenv "HOME") ...)
<apteryx>attila_lendvai: we typically use patch prefix, e.g. [PATCH core-updates], we could also use tags
<apteryx>attila_lendvai: if you want to help you could review the backlog of patches and tag them with '1.4.0'
<apteryx>see info '(guix) Debbugs Usertags'
<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`>Hello, is there a way to install a `.nar' archive without network access? I tought it should be the case but here is where i'm stuck :
<phf`>Essentially : guix archive --export -r /gnu/store/fvdl...-example-1.0 > example-1.0.nar
<phf`>but guix archive --import < ./example-1.0.nar seems to require network access.
<raghavgururajan>civodul: Ahh thanks.
<phf`>oups nope
<raghavgururajan>civodul: Same for `plain-file` as well?
<phf`>it was: `guix install /gnu/store/fvd...-example-1.0' that required network access
<phf`>after `guix archive --import < ./example-1.0.nar'
<phf`>so, is it possible to avoid the network access and have a self-contained `.nar' archive as in the documentation ? I'm missing something apparently.
<raghavgururajan>If `(plain-file "filename" "contents")` is done, where will that file will be created/saved?
<lfam>taterbase: I'm wondering if the issue you describe is related to the 4th paragraph here: <>
<taterbase>lfam: that looks about right, thank you for sharing that
<taterbase>How did you come across that? I must have missed that news
<lfam>I noticed it while reviewing the patch to update to 21.1.2: <>
<lfam>We are still looking for someone to test the patch outside of a VM
<taterbase>Any way I can help? I'm running on a laptop
<apteryx>taterbase: to set DPI you can use something like: 'xrandr --dpi 96' in your xsession or equivalent
<taterbase>apteryx: thank you I'll give that a shot!
<taterbase>I also saw you can dictate scale with xrandr.
<apteryx>raghavgururajan: in /gnu/store; e.g., don't put anything sensitive in there
<taterbase>I'll try both of those
<apteryx>s/e.g./i.e./ :-)
<taterbase>Oh also, I can't tell you how thrilled I was to see how easy it is to revert to an old guix installation in grub
<apteryx>scale will give you a bit fuzzy results; I seldom use it
<apteryx>(harder to read text)
<taterbase>ah ok
<phf`>Please, can someone give me hand ?
<taterbase>I don't know anything about nar's I'm sorry phf`
<apteryx>phf`: I'd have expected it to work without networking too; what does it error with?
<phf`>Thank you for your answers. here is what I did:
<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
<phf`>I will try this.
<phf`>Same error
<phf`>guix package --delete-generations; guix gc; guix archive --import < ./example-1.0.nar;
<phf`>guix install --no-grafts /gnu/store/fvd...-example-1.0
<apteryx>hmmph. Perhaps try adding '--no-substitutes', but that seems bad behavior to me
<phf`>gives: `guix install: erreur : ... failed (usually happens due to networking issues)'
<phf`>Here is the log file with `--no-subsitutes'
<phf`>And here is the log file for `/gnu/store/rwdagc0kip190y8kxj0z2bwhr4h1ipln-Python-3.5.9.tar.xz.drv'
<phf`>Which a is network access issue again.
<awb99>Guix system builds seem to be WAY FASTER after the core-update-frozen merge.
<awb99>Am I fantasising?
<awb99>Or is it really faster?
<attila_lendvai>ehh, golang: the transitive closure of dependencies for the go-ethereum client has 8 different versions of (working on the importer)
<phf```>So, no luck ?
<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.
<lfam>That's my take on the situation
<lfam>At least, it's best to not unbundle the dependencies
<lfam>Like, if the software is very important, why try to rebuild it? Why take that risk?
<lfam>That all assumes that you trust them to get it right
<lfam>Like, their releases
<florhizome[m]><awb99> "Guix system builds seem to be..." <- For me guix pull takes much longer. .
<florhizome[m]>Other then that, i think yes.
<awb99>yes guix pull is VERY slow,
<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.
<awb99>The profile building was always slow.
<phf-1>Where may I get help on this deployment issue? Should I try the guix mailing list? Or maybe someone is known to know about these `guix archive --export/--import' magics?
<awb99>I have filed an issue where profile cofniguration (the last step) takes 10 minutes.
<awb99>But I am now talking of the profile building phase,
<lfam>yewscion: What do you mean by "reset a profile"?
<awb99>which feels like 10x faster now.
<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.
<yewscion>But I will if I need to.
<apteryx>(for xz tarballs)
<lfam>yewscion: Guix will print that information when you are trying to install things
<apteryx>also, GCC 10, although I doubt it compiles faster than GCC 7.5
<apteryx>(it may make faster binaries though, hopefully)
<lfam>yewscion: And also when builds fails
<lfam>yewscion: Actually, there's an easier way. Compare the results of `guix describe` on both computers
<yewscion>lfam: Copy that. Sorry, haven't run into this issue before. Still learning the SOPs for stuff like this.
<apteryx>awb99: oh, you mean profile generation? civodul has made the mandb sluggish profile hook only occur when you explicitly add 'mandb' to your profile; that may be it
<lfam>Sure, no worries yewscion
<nckx>Morning, Guix.
<nckx>‘The [Nix 2.5.0] garbage collector no longer blocks new builds, so the message “waiting for the big garbage collector lock...” is a thing of the past.’
<lfam>That would be nice
<nckx>I thought of you and your berlin woes.
<tissevert>'morning nckx
<civodul>nckx: oh! we should look at their code
<civodul>last i looked it hadn't changed
<nckx>I don't C++ very good but I was going to, just in case it's trivial.
*nckx unquotes tissevert's 'morning, ssh, play along.
<tissevert>I promise I wasn't trying to inject anything : )
<awb99>thanks apteryx
<apteryx>phf-1: if you can make a neat minimal reproducer, I'd post this to; it ought to work
<apteryx>nckx: that sounds delightful
<phf-1>apteryx: ok !
<raghavgururajan>apteryx: I see. Thanks!
<nckx><can’t install btrfs-progs because of the GC lock :(> Timely, too.
<awb99>There has been a change how guix creates docker images. It seems now the images are made with "guix pack" and they only have a manifest. Prior I could define user ids, and this is gone.
<raghavgururajan>Hmm. Substitute for linux-libre-5.10.87 hasn't been available for couple of days now.
<awb99>Is this really gone, or has it been moved to another menu entry that I ddint find?
<awb99>I am wondering how I would define user ids now in docker images.
<raghavgururajan>lfam: Any ideas? ^
<nckx>raghavgururajan: ?
<phf-1>apteryx: assume I have an archive with everything needed to reproduce the bug, how do I send it to you?
<nckx>raghavgururajan: I also successfully built it locally yesterday to work on . Are you on x86_64?
<nckx>(By the way, ‘work on’ — I don't see a good solution :-/ )
<rekado>awb99: it should be faster to run programs, because we build a library cache now and so we don’t need to search all the RUNPATH directories for libraries.
<civodul>awb99: re Docker images, right now "guix pack" doesn't let you define user IDs or do other such things one can do in Dockerfile, but that'd be a welcome addition
<phf-1>apteryx: can it be in French ?
<awb99>thanks civodul!
<civodul>phf-1: yes, feel free, plusieurs personnes ici parlent français :-)
<awb99>Its amazing how fast guix profile build is!
<awb99>This really is day and night difference!
<civodul>we rarely get that kind of compliment :-)
<awb99>It is now similar to apt / yum / pacman in speed.
<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>...which will not be accepted in guix proper.
<lfam>Yeah, I've been thinking about solutions for this for a long time
<rekado>awb99: oh, another reason why profile actions are faster: no more mandb when you don’t have it installed.
<lfam>I still think we need to either 1) Use bundled source code dependencies or 2) Make a simple parameterized package syntax
<drakonis>nckx: hmmmm no garbage collector locks?
<nckx>‘nix commit 8eac7d Remove trash directory’
<nckx>IS NOTHING HOLY to you people???
<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.)
<phf-1>apteryx: here is the archive:
<phf-1>civodul: thanks ! here is the archive
<lfam>attila_lendvai: Idea for parameterized Go packages:
<drakonis> wooow
<lfam>attila_lendvai: At this point, I think we'd only need the version and hash, no the import-paths
<lfam>There would be a template package that included that info
<sneek>Yey! unmatched-paren is back
<raghavgururajan>nckx: Yes, x86_64
<raghavgururajan>nckx: /gnu/store/dxpk2l1kl4f5a0nnxw50f79p7i6c0xkz-linux-libre-5.10.87.drv
<phf-1>apteryx: civodul: Dear lord, does not appear to allow to share tar.gz and text.
<attila_lendvai>lfam, i don't understand how that would be implemented, but it sounds better than the current situation.
<phf-1>apteryx: here is the text version
<phf-1>civodul: here is the text version
<raghavgururajan>nckx: I tried clearing /var/guix/substitutes/cache/* too
<nckx>raghavgururajan: No, it's just not available on berlin, sorry. Berlin is also frozen because of the big GC lock.
<nckx>Aaand I can't share mine because I'm locked out of because of the SSH issue…
<raghavgururajan>Ah I see.
<nckx>Arbitrary binary shared in PM 👍
<nckx>Plus ça change.
<tissevert>quoi ?
<Noisytoot>What's the SSH issue?
<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 <> or thereabouts.
<nckx>Apart from that the machine is up & doing dandy.
<apteryx>we'll need better a betterdiagnostic when (guix gexp) is missing
<apteryx>the errors are rather confusing
<Noisytoot>I haven't updated my Guix server yet because lots of packages are broken
<nckx>I've always got a helpful ‘did you forget (guix gexp), you dolt?’ hint?
<lfam>attila_lendvai: I think it would basically be another layer of syntactic sugar over package inheritance
<nckx>Noisytoot: I'd… wait. Just to let things settle.
<lfam>yewscion: Bug reports are mailed to <>
<lfam>For troubleshooting a failed build, it depends on how comfortable you are troubleshooting compilation / build issues in general
<unmatched-paren>"just to let things settle" <- did i miss something?
<lfam>But, what will happen is that somebody will use a development environment to reproduce the problem and then try to fix it
<lfam>The development environment is documented here: <>
<lfam>Building From Git and Running Guix Before It Is Installed
<apteryx>civodul: having glib use gexps, I was able to cross-compile it for aarch64-linux-gnu; it'll be on version-1.4.0 when I push
<unmatched-paren>just that part of your statement is worrying me a little :P
<nckx>I mean nothing more than the general increase of bugs after a big change. This c-u more had more big changes than most.
<Noisytoot>Also, since I updated, Evolution doesn't work. It starts and tries to connect to IMAP servers but never succeeds.
<raghavgururajan>Any guix-homies online?
<unmatched-paren>nckx: got it, i was worried that something bad had happened while i was away :)
<unmatched-paren>luckily, my c-u-f experience was completely smooth
<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
<yewscion>help me a lot.
<lfam>Did you read those two sections of Contributing that I mentioned?
<lfam>The workflow is describe there
<lfam>Basically, clone Guix from git.
<yewscion>Also, is there a template I should use when submitting bugs to
<lfam>Then, `guix environment guix`, followed by `./bootstrap && ./configure --localstatedir=/var && make`
<lfam>Finally, you can then use Guix from the Git checkout like `./pre-inst-env guix build foo`
<unmatched-paren>or `guix shell -D guix` if you want to be trendy :)
<lfam>Oh right
<lfam>Anyways, let's stay on traack
<lfam>Those instructions are smallest possible summary
<lfam>You can build packages with --keep-failed, and you'll be able to enter the failed build directory and poke around
<yewscion>Oh dang, sorry, my eyes skipped over those messages for some reason! Thanks for the quick rundown, I'll go read them now.
<lfam>No template is required for bug reports. Just do your best to help others understand and reproduce the bug
<nckx>unmatched-paren: and are particularly not great, but before I reconfigured this server I had not even the tiniest hitch on my laptop which has been running c-u-f for weeks now. Experiences are very mixed.
<raghavgururajan>When home-configuration.scm has `(local-file (string-append (getenv "HOME") "/path/to/file"))`, it uses "$HOME/$CWD/path/to/file" instead of "$HOME/patch/to/file".
<lfam>yewscion: You might also search the existing bug reports, to check if they are already reported: <>
<nckx>"$HOME/$CWD/path/to/file" — how does that even
<yewscion>lfam: Awesome, thanks for all the help!
<lfam>Happy to help!
<lfam>And you'll help too, by filing or contributing to those bug reports :
<raghavgururajan>nckx: Let me paste an example.
<nckx>OK, but note that I don't use guix home myself. I'm just impressed.
<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.
<raghavgururajan>tissevert: Installing with guix-home is more declarative way.
<tissevert>compared to maintaining a manifest and "guix package -m"ing that ?
<tissevert>also, I'm a bit confused by the original import creating a (bash-profile …) entry pointing to… the path of my bash profile, but not its content
<tissevert>when does that become portable so that I can replicate it on a different host ?
<raghavgururajan>nckx: I had another one:
*raghavgururajan tries pk
<nckx>Whoah. (getenv "HOME")"dotfiles/bash/bash_profile") → "/home/rgdotfiles/bash/bash_profile"
<nckx>So it is being ‘clever’/running a string substitution/something else.
<nckx>If it were mucking with HOME you'd get "/home/rg/guix-config/homedotfiles/git/config"
<nckx>So I don't expect the pk to show anything different.
<tissevert>I wonder why you have to pass two strings to (local-file …) when the simple configuration imported from guix home passes only one
<nckx>You'll have to ask Andrew whether it's unintentional, but to me it's a strange way of doing things.
<roptat>raghavgururajan, I'm pretty sure the error about "home/rg/guix-config/home/dotfiles/git/config" has nothing to do with your bash_profile
<raghavgururajan>roptat: O h yeah, damn I have been reading errors as same
<raghavgururajan>didn;t notice file name
<nckx>C++ is no fun.
<nckx>raghavgururajan: roptat: Oh, same.
<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
<lfam>And, it's a gentle learning curve
<unmatched-paren>thanks! i did read that it was really outdated, yeah
<singpolyma>Luckily C hasn't really changed since 1990 :)
<lfam>I don't think is so out of date as to be useless. Like C before that book is basically a different language. But the C in that book is still used and useful
<lfam>It's the foundation of modern C
<lfam>And I do think it's an easy way to start
<lfam>Writing modern and safe-enough C will take a while to learn no matter how you start
<unmatched-paren>the language itself feels very messy; the lack of well-defined naming and formatting conventions bothers me a lot
<lfam>Well, it's from 1970
<singpolyma>To do bindings from guile I'm not sure you have to actually write any C though. Just need to be able to understand the relevant headers you are wrapping
<lfam>I'd also argue that there are well-defined conventions
<lfam>But maybe you have to stick to Linux kernel C for that
<lfam>Like, each industry has conventions for C
<lfam>Embedded, kernel, etc
<singpolyma>Yeah, projects definitely use formatting conventions same as any other language
<lfam>The real problems are undefined behaviour, the infinity of subtle mistakes that can be made, etc
<lfam>But, for learning to read C and make simple patches, I'd go with K&R. Once you learn that, you can easily take one step at a time
<singpolyma>You a really need more of them for C, things like always write * next to var name and not type name, etc
<unmatched-paren>peeking at c code, i can see some using camelCase for functions, some snake_case; some people use PascalCase for types, others snake...
<lfam>Well, that's not a convention, but an indication of a data type. It's not just a naming thing singpolyma
<unmatched-paren>"* next to var name..." <- yes, this bothers me too
<lfam>The asterisk is how pointers are described
<lfam>It is not just a character, but has meaning within the language
<lfam>I'd say read K&R :)
<singpolyma>unmatched-paren: different naming styles in different projects happens in any language, not just C, it's personal style of the project maintainers
<singpolyma>lfam: * next to var is formatting thing, that's what I meant
<lfam>If you are at the stage where you think that the asterisk is just about naming, then you are ready to start learning at the beginning
<unmatched-paren>int* foo, bar looks like two ints ptrs, foo and bar, but it's actually one foo int ptr and one bar int (not ptr)
<unmatched-paren>lfam: no, no, that wasn't what i thought
<lfam>Oh, sorry!
<singpolyma>unmatched-paren: yes, never write that for sure
<lfam>Something to remember is that C was designed *before computer monitors*
<lfam>Every character that you read had to be printed out, one at a time
<singpolyma>int* is always bad style but new C programmers do it sometimes because of course the parser can't tell
<lfam>So, C is more terse than languages designed after computer monitors were available, in order to save time
<lfam>Similar with UNIX
<lfam>Imagine working with a command line terminal that printed a few characters per second
<lfam>Imagine writing code in that
<unmatched-paren>but then int *foo, *bar doesn't really make it clear that it's part of the type
<unmatched-paren>it looks like some kind of fancy naming convention
<unmatched-paren>to the newcomer
<singpolyma>unmatched-paren: it does if you know C :) heh
<lfam>This is why significant C projects like Linux are so strict about style
<lfam>Because it really matters for understanding
<unmatched-paren>i guess i'll just avoid defining multiple variables on the same line?
<lfam>Anyways, yeah, most people hate C! But if you want to live in UNIX, it's still very useful
<lfam>Nearly everything is based on it
<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? :)
<singpolyma>unmatched-paren: I think it's a macro, yeah
<nckx>Sorry for the YT link, but I have to abuse this excuse to post:
<nckx>You will wonder many times in your life ‘Unix… why…’. This is usually why.
<lfam>Thanks for the example nckx :)
<lfam>Hence things like `ls` and `cd`
<unmatched-paren>nckx: i have icecat configured to redirect youtube to invidious anyway :)
<nckx>I want to experience that in real life some day.
<nckx>Must be visceral.
<lfam>Viscerally annoying
<nckx>Well, yeah, I'd head home back to laptops and wifi.
<nckx>But still.
<lfam>Thank god for abstractions
<unmatched-paren>yeah, ls and cp et al. don't bother me, it's just c does; some of its style choices don't make sense even in the pre-monitor age
<lfam>Well, it was written by one person in about 1 year :)
<unmatched-paren>i get why you'd use abbreviations back then
<lfam>And we've had 50 years to learn some lessons
<unmatched-paren>lfam: wasn't there a b language that preceeded it, though?
<nckx>unmatched-paren: They probably got inherited from B.
<lfam>If you don't like post-89 C... don't read C from like 1980 :)
<lfam>Yeah, there was a B
<nckx>And ‘everyone knew B’. s/B/JS/ — we are not so different from our ancestors.
<unmatched-paren>pretty sure i read on wikipedia that c was basically just an improvement of b... like, b wasn't typed
<unmatched-paren>obviously, it grew to more, but back then...
<lfam>Yeah, it was an evolution of sorts, is my understanding
<lfam>Anyways... to go back to your original question. It might be easier to implement things in Guile than in C
<unmatched-paren>lfam: yep, that's what i'm planning to do
<unmatched-paren>or when speed matters, either rust or zig
<lfam>But if you want to, I'd say it's well worth it to learn basic C
<lfam>Because Guile, Linux, and pretty much every language is actually written in C
<lfam>So, it's the proper layer to go to to "read the source"
<lfam>And also, the deployment story for C is way more mature than things like Rust
<singpolyma>How so? They seem about the same?
<unmatched-paren>can guile be completely compiled to asm, or does it just get compiled to .go files and fed through the JIT? is there any way to turn it into an executable binary
<lfam>And that lesson was learned by Go (old school C people wrote Go), hence the simplest deployment of all languages
<lfam>singpolyma: Hardly! Consider the poor state of Rust support compared to C
<singpolyma>I'm not sure what that even means
<lfam>I guess I could say the same about your statement :)
<lfam>With C, there is already decades of lessons learned about how to build and deploy software. With Rust, everyone is still figuring it out
<singpolyma>I compile a binary, copy it to whatever computer I'm gonna use it on, and run it. So long as any dynamically linked bitt are present, it works. Seems the same as when I build C
<guixy>Has anyone been able to get nouveau drivers to work? If not, is there a way to disable them in favor of Intel?
<lfam>So, in Guix for example, Rust software is missing almost all the advantages of Guix, because there is no example to take from
<lfam>We have to figure it all out for the first time
<nckx>guixy: You can add modprobe.blacklist=nouveau to your kernel-arguments list.
<lfam>It's not a problem for Rust. But decades of experience is worth a lot
<guixy>nckx: Thanks
<lfam>Or I mean, it's not a problem with Rust. Everything is immature at the beginning
<unmatched-paren>Rust can also take lessons learned by C, it's not exactly a clean slate
<nckx>Thanks for keeping it positive this holiday season.
<lfam>Yeah, and eventually it will
<lfam>Or rather, the entire world of distros will
<lfam>Like, Rust has obviously figured out how to make a working language that people want to use. But there is so much more work to be done before it can be relied on easily
<singpolyma>Do you have a concrete example?
<lfam>It's a huge problem for Guix
<nckx>If you count autotools/cmake/meson as part of the ‘deployment story’ of C (and why wouldn't you?) that story is still very much being written today.
<unmatched-paren>I like how rust only has one build system, but the centralized package manager is vulnerable to npm-style dependency overuse
<nckx>It's just not written by ‘the C project’.
<unmatched-paren>nckx: yep, i'm still not sure which to use
<singpolyma>unmatched-paren: you can use lots of build systems for rust. But there is a very popular one of course
<lfam>Once Linux adopts Rust, I think things will improve rapidly
<unmatched-paren>if you use autotools, users don't have to install anything unusual, it's really a shell script and makefile generator
<unmatched-paren>singpolyma: are you talking about the rust meson support?
<unmatched-paren>other than that i am not aware of any other build system
<nckx>guixy: I don't Nvidia so don't ask me what happens next.
<singpolyma>unmatched-paren: not specifically. Just, like, any build tool can invoke rustc. I've used make before
<singpolyma>lfam: so, you were saying something about librsvg?
<lfam>Do you know its status in Guix?
<lfam>Librsvg switched from C to Rust
<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
<singpolyma>lfam: oh, you're talking about backend support
<lfam>So, we have a case where we have to split the distro's dependency graph at a low level, and we lose all the Guix tooling about the graph in order to use librsvg at all
<unmatched-paren>Guix's Rust doesn't build on any arch except x64, iirc
<singpolyma>I hear about that being an issue with rust sometimes. I'll admit that I only have x64 and arm stuff myself. And wasm of course
<lfam>I'm not saying "Rust is bad" or anything like that. But it's immature in comparison
<unmatched-paren>the actual rust compiler works on lots of targets, because of llvm
<lfam>And you see the downside of granular dependency specification in the context of a cyclic dependency model
<nckx>Works, but doesn't bootstrap.
<unmatched-paren>i don't know the specifics, but the actual compiler won't build in guix on any other archs
<lfam>Like, the Rust developers are developers. It's a different task from integrating components into a usable operating system
<lfam>So, cyclic and granular dependencies are not a problem for them
<nckx>IIRC someone (lfam?) even suggested ‘injecting’ cross-built Rust into the bootstrap graph for that reason. Crazy!
<lfam>By the time Rust is as old as C, this will all be solved
<nckx>Not the suggestion, the fact.
<singpolyma>Cyclic can be a problem but I guess they've solved it somehow. Haskell is still trying to work that out to make it work well
<lfam>Have they solved it? Or is it just not a problem in the context of development?
<unmatched-paren>yeah, i don't think dependency additions should be just one command or new line in a cargo.toml away, guix has taught me that much :)
<lfam>Also, C has cyclic dependencies too
<lfam>But C doesn't have extremely specific dependency requirements, so it's easier to find a solution
<unmatched-paren>s/cargo.toml away/cargo.toml away _anymore_/
<singpolyma>lfam: .. if the system doesn't run forever or crash when building and someone is using cycles then it must be solved?
<lfam>No, we just "turned off Guix" for Rust
<jlicht>at least it's not javascript/node ;)!
<lfam>We handle Rust in a totally different and non-Guixy way
<unmatched-paren>lfam: i think some of that got fixed, didn't it?
<lfam>Maybe, I don't know. It's at least being worked on
<unmatched-paren>(inputs) and #:cargo-inputs got merged
<lfam>I'm not saying that Rust is bad. But rather that 50 years of refinement is worth more than we can imagine
<unmatched-paren>same story with (inputs) and #:cargo-development-inputs; and also (native-inputs) and #:cargo-native-inputs
<singpolyma>The real mess in guix is Go. Oof. It works, but so sad. But have to start somewhere I understand
<lfam>At least Go works within the Guix model
<singpolyma>lfam: uh, does it? I don't think so
<lfam>How's that?
<singpolyma>Go libraries have to propagate their source code to work at all
<unmatched-paren>part of the reason i find zig interesting is no package manager \o/
<unmatched-paren>and the library ecosystem is decentralized
<singpolyma>And then the final package just builds everything together as though there were no packages
<lfam>Oh yeah. That's largely because I landed the go-build-system, but I don't actually write Go. I did the only thing that I could figure out to make it build packages
<lfam>What can I say. Help wanted
<singpolyma>For sure. Not trying to criticize your work. It works
<lfam>There are patches pending final review to begin overhauling go-build-system: <>
<unmatched-paren>but the zig compiler seems pretty unstable, since they're basically trying to sever dependencies with c-land completely
<raghavgururajan>nckx and roptat: Works perfectly now.
<singpolyma>unmatched-paren: zig is also another manual memory management without guardrails language. If I want that I can use C
<nckx>raghavgururajan: What was the problem? I wasn't following along at home.
<unmatched-paren>singpolyma: wait, really? i thought it had some safety guards (that you can remove in certain compilation modes if you wish to improve performance)
<raghavgururajan>nckx: Using "/" did work.
<unmatched-paren>the default safe mode doesn't let you read past the end of an array, for example
<unmatched-paren>also, it's much easier to read than c :)
<singpolyma>unmatched-paren: oh, I don't really consider "sized array" a guardrail, but sure
<lfam>I would really appreciate some more testing on the Go patches. They work for me, but I only use Syncthing
<singpolyma>I can do that one in C too :)
<guixy>There's nothing like running Guix on a HDD to make you appreciate having an SSD.
<unmatched-paren>there's also Odin, but i haven't tried it yet since it's not in guix
***iyzsong- is now known as iyzsong
<unmatched-paren>V is just too badly packaged to contemplate using
<nckx>raghavgururajan: But what was the problem with git/config?
<nckx>unmatched-paren: Also… not a very… good… language.
<unmatched-paren>most of its features require its elf binary to be in a mutable directory :(
<unmatched-paren>nckx: i didn't really look into it that much, what are the problems?
<guixy>Has anyone been able to get Eclipse to run, or is it considered WIP?
<raghavgururajan>nckx: There wasn't any. We were looking at different errors but presumed it is for same thing.
<unmatched-paren>singpolyma: maybe it doesn't have as much safety as i'd like, but there's still a few other neat features
<nckx>Let me rephrase: how did you get rid of the git/config error in the end?
<unmatched-paren>e.g. comptime and its emulation of the target architecture as an alternative to macros
<lfam>To summarize my unfocused rambling... let's improve Rust support in Guix :) C is already quite good
<apteryx>nckx: for me when there's no (guix gexp) it looks like: "packages/check.scm:1883:10: warning: 'replace' may only be used within 'modify-inputs'" [...]
<unmatched-paren>it looks like we're making good progress on better rust support, at least
<lfam>We're on our way!
<unmatched-paren>i'm curious: what are the problems with rust on other archs, exactly? surely the compiler bootstraps itself there fine outside of guix?
<yewscion>All: I just submitted my first bug report! Please let me know if I did anything incorrectly/non-idiomatically!
<unmatched-paren>hm, looks like odin only supports x32/x64...
<apteryx>unmatched-paren: mrustc
<unmatched-paren>apteryx: ah, ok
<unmatched-paren>so i certainly can't help because c++ :)
<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
<rekado>I second the recommendation for K&R C
<nckx>lfam: Will do.
<rekado>not to write code that they present, but to get how this language ticks
<raghavgururajan>tissevert: I am bit confused about passing two values to local-file for shell.
<avp>Guile-SSH 0.14.0 is out:
<avp>Please test it with GNU Guix.
<nckx>Is there a built-in way to list all guix hash --serializer=TYPES?
<apteryx>nckx: you can slap this in check.scm (without the #:use-module (guix gexp)):
<teddd>is there a way to run an equivalent to "git submodule init; git submodule update;" in a package def ?
<vivien>teddd, would that download things from the internet?
<unmatched-paren>is K&R available online somewhere, or do i have to purchase a physical copy? i'd like to have a look before i buy the deadtree form
<unmatched-paren>i like buying the physical copy even if an online version is available, since a book is generally more portable than a laptop
<vivien>Unfortunately, guix won’t let you do that :(
<unmatched-paren>teddd: do you mean grabbing the submodules? fairly sure (git-reference) has a (recursive?) field for that
<lfam>unmatched-paren: You want the 2nd edition: <>
<teddd>I see. So I am better off packaging the submodules then.
<unmatched-paren>teddd: you're probably better off doing that anyway, but (recursive? #t) works
<unmatched-paren>lfam: thanks!
<nckx>teddd: If you're modifying an existing (non-recursive) git-fetch, negate the first character of the hash, or you'll keep fetching the non-recursive version.
<teddd>I see. Is it then enough to add these dependencies in the inputs of the package or so I then need to trick the install when ghe is looking for the submodules ?
<teddd>Is it then enough to add these dependencies in the inputs of the package or do I need to trick the installer when it is looking for the submodules ?
<lfam>That depends on the build scripts used by the package in question
<teddd>I see
<unmatched-paren>recursive? goes in git-reference like this: (uri (git-reference [...blah...] (recursive? #t)))
<teddd>no general way to do this for cmake then
<unmatched-paren>that will fetch the submodules
<unmatched-paren>when creating the source derivation
<teddd>ah I see. Maybe that will be enough. Thanks
<unmatched-paren>guix doesn't allow internet connections during package builds, but it has to for fetching source code, of course
<unmatched-paren>presumably allowing arbitrary downloads during builds would break reproducibility
<unmatched-paren>if you download some bash script from to build the package, there's a chance that url would not point to the same thing during someone else's build
<teddd>it makes sense.
<lilyp>you mean curl-bash-build-system is broken?
<roptat>one way to work around that is to download the things in advance, have them as input and copy them to the build directory
<unmatched-paren>roptat: (recursive? #t)
<roptat>sometimes it's more complex than that, but that's what we do for icedtea that comes from multiple sources
<roptat>one issue with recursive? #t is that git submodule don't always correspond to a fixed commit
<roptat>but otherwise, it's a good solution
<guixy>Is there a sample system config file that demonstrates how to append items to modprobe.blacklist?
<nckx>guixy: Why didn't the example I gave earlier not work?
<guixy>It works from grub, I just want it permanent.
<nckx>There's an ‘example’ in (guix)operating-system Reference but there's only so much you can do to show ‘this is what a list of strings looks like’.
<nckx>guixy: Then scroll up, I gave an example.
<nckx>Didn't I?
<nckx>Otherwise, (operating-system … (kernel-arguments (list "blah=bloo") ) …)
<nckx>Otherwise, (operating-system … (kernel-arguments (append %default-kernel-arguments (list "blah=bloo"))) …) ; if you want to keep the defaults.
<nckx>Of which I do not know what they are.
<nckx>The example I gave earlier was for someone else, never mind, stop scrolling before you kill us all.
<guixy>Next time I search IRC history in icedove, I'll start from the bottom...
<nckx>One thing that HexChat does right, at least.
<V>nckx: this is like the one thing I don't know how to set up highlight ignores for lol
<V>I wish people wouldn't be bought in by the claims do easily, there are far better projects and languages to contribute to
<V>so easily*
<teddd>(recursive #t) doesn't seem to download the submodules. At least I can't find them in the source dir
<nckx>V: Lol. Is there a ‘C’ user? They must have a bad time.
<nckx>teddd: Did you adjust the hash?
<teddd>hmm no
<teddd>why is it important ?
<V>nckx: not one I'm familiar with!
<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.
*nckx AFK.
<unmatched-paren>that short nickname makes you look extremely enigmatic for some reason :)
<teddd>I see. So if I chnage something in the source, I should change the hash, right? Like, if I want to change the commit, I should change the hash.
<unmatched-paren>my first impressions of K&R are good, but i can definitely see its age
<unmatched-paren>teddd: yep
<unmatched-paren>every time the source changes, the hash must change with it
<teddd>ok. tks!
<unmatched-paren>i find it easy to paste a hash from somewhere else, then wait for the `Wrong checksum' complaint; it gives the correct one :) there's probably an easier way to do it tho
<unmatched-paren>i think you can clone a repo and do guix hash, but i can never be bothered :P
<unmatched-paren>wrong terminal pane :)
<roptat>unmatched-paren, "guix download" for a tarball
<unmatched-paren>yeh, but what about a repo?
<unmatched-paren>i think there should be a `guixx
<roptat>otherwise, flip the first character in an existing hash :)
<unmatched-paren>`guix git-download` command
<unmatched-paren>that should be a thing
<unmatched-paren>wouldn't be too hard to implement, right?
<apteryx>phew, pylint 2.12.2. what a rabbit hole.
<teddd>Yeah this copying another hash is also what I do each time.
<apteryx>tissevert: o/
<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
<NicholasvonKlitz>from git diff I can see it is untouched
<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 pkgname@0.1.0") forms?
<apteryx>NicholasvonKlitz: yes, but (inherit librsvg)
<unmatched-paren>that prints the hash at the end
<NicholasvonKlitz>apteryx: ooh I see
<apteryx>that seems backward though
<NicholasvonKlitz>Now is there anyway to avoid all the rebuilds?
<apteryx>if librsvg-bootstrap's intent was to be fixed, it shouldn't inherit from the one that is bound to be changed
<teddd>are there guix related envent in Berlin maybe ?
<NicholasvonKlitz>apteryx: Is the only solution you see removing the inherit?
<apteryx>hopefully the inherit can be removed, you'll have to ensure the resulting package definition is strictly identical to avoid rebuilding rust
<apteryx>it should be possible, if you manually copy the fields it was inherited before the update
<unmatched-paren>wait, does this mean rust depends on librsvg itself? why else would it rebuild?
<apteryx>because the hash mechanism uses the fields of the (expanded) packages object IIUC (after the package macro, which inherit is part of, is expanded)
<apteryx>ah, yeah, no that shouldn't cause rustc to rebuild (although it'd cause the whole GTK world to)
<apteryx>on x86_64 at least
<NicholasvonKlitz>apteryx: im updating librsvg to update gtk so that's fine
<NicholasvonKlitz>if it's not librsvg-bootstrap causing rust to rebuild, any other ideas what it might be?
<rekado>teddd: there are guix related events in Berlin almost every day. No public events though.
<NicholasvonKlitz>Or is there a guix command to find out?
<apteryx>NicholasvonKlitz: not sure; you could review the dependency graph of rust
<apteryx>there shouldn't be much there
<NicholasvonKlitz>ah is there a way to visualize/interact with it?
<unmatched-paren>`guix graph` iirc
<apteryx>guix graph rust | dot -Tsvg -orust.svg
<NicholasvonKlitz>I'll give that a try
<NicholasvonKlitz>I think I found it!
<NicholasvonKlitz>python which depends on tk which depends fontconfig-minimal which depends on freetype
<NicholasvonKlitz>and I updated freetype
<apteryx>yes when you touch somethnig better do 'guix refresh -l that-something' to know how much rebuilds you caused
<rekado>oh, GC lock has been released
*rekado installs btrfs-progs
<KarlJoad>Is there a way to force a personal instance of Cuirass to build something?
<unmatched-paren>why on earth would a programming language depend on a widget toolkit?!
<unmatched-paren>...don't tell me tk bindings are included in the python distribution by default.
<apteryx>unmatched-paren: we're probably talking about build dependencies
<teddd>@rekado what do you mean by not public events ?
<roptat>unmatched-paren, tk bindings are included by default, though they're installed in a separated output
<asdf-uiop>Hi! I just watched the 'asking for help' video and noticed it references freenode instead of
<roptat>oh nice catch, these videos are older than the switch to libera
<asdf-uiop>An update would be nice, but I think a notice below the video on would make sense.
<nckx>We are sorry for pointing you to Freenode.
<asdf-uiop>No problem. And you did not, I knew the server had changed
<asdf-uiop>But I thought I'd mention it in case it discourages someone else
<unmatched-paren>roptat: "tk bindings are included by default" || that's horrifying
<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 :)
<rekado>it’s an event for sure
<rekado>FYI I’m copying /gnu/store/trash to the SAN for some perf tests
<jonsger>rekado: which SAN vendor is your storage from?
<rekado>jonsger: it’s all Dell here
<rekado>special contracts with massive discounts mean that they almost always win any bid
<jonsger>we are all HPE and I hope for you that Dell is cheaper and less bloated :)
<jonsger>but storage is NetApp. Thats fun and fast :)
<teddd>rekado: sounds big. What data center is that ?
<rekado>it’s the data centre of the MDC, a research institute in Berlin Buch.
<rekado>jonsger: the E in HPE stands for bloat
<rekado>I feel that all the enterprise stuff was designed to be an exercise in patience.
<rekado>I’m currently struggling with one of the servers we bought in 2019/2020 for the build farm.
<rekado>(wait, was it 2019 or 2018…? I don’t recall.)
<rekado>we never quite got it to run
<rekado>yesterday I had to get it unstuck because its lifecycle controller was disabled, but the management system insisted to wait for it to come back up
<teddd>ah I see. I've been there with the bike lately
<rekado>of course none of this information was displayed in the management web app
<rekado>right now it’s supposed to install a BIOS upgrade, but the logs are hidden and cryptic
<mroh>universe was designed as an exersise in patience.
<rekado>but the web interface looks fancy
<rekado>priorities with all this enterprise stuff seem all wrong
<jonsger>joa, and always 1h+ for updating Firmware + BIOS :(
<rekado>yeah, what’s up with that!
<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…
<teddd>sounds lame
<apteryx>jonsger: like this?
<rekado>most of the servers we bought (around maybe 28 of 30 or so) worked just fine.
<rekado>but some had problems and you can’t get support (or send them back) if you’re not “in compliance” = latest firmware everywhere.
<KarlJoad>Ok, so I found the root cause of my Cuirass issue. The default Guix channel is returning a "SSL certification is invalid" error. How is that possible? How can i fix it?
<jonsger>apteryx: ppc64le is difficult as its not x86 or at least aarch64 :(
<rekado>KarlJoad: probably means that nss-certs isn’t installed, or its outputs are not found
<rekado>GIT_SSL_CAINFO, SSL_CERT_DIR, and SSL_CERT_FILE may need to be set.
<KarlJoad>rekado: The server does not have nss-certs in its `operating-system` packages list.
<apteryx>jonsger: part of the deal to break the status quo -- but ISTR they had something to make it easy to run x86_64 binaries, I'm guessing QEMU-based.
<mala>Wow, justine has been busy:
<apteryx>not sure what is so difficult about it otherwise, red hat has full support for POWER9 with their distro
<jonsger>yeah, I know SUSE as well. But I guess our software vendors not, although most of it is Java stuff...
<jonsger>and I think an EU/Germany based reseller would be required...
<nckx>mala: Neato.
<KarlJoad>rekado: The nss-certs thing seems to have made things work. Now I need to find out how much memory is required by Cuirass...
<KarlJoad>Just as a point of curiosity, shouldn't the `cuirass-service-type` automatically come with the nss-certs package defined as a runtime requirement?
<ArneBab>I just released wisp 1.0.7 that fixes a dumb bug in 1.0.6 which broke the wisp repl (using ;; as comment in a shell-script …):
<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
<Gooberpatrol66>rekado: info --file=./doc/
<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
<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
<Gooberpatrol66>ah, it has to be ./doc/
***easbarbosa is now known as easbarba
<teddd>is there a command to get the size of a profile ?
<teddd>would guix size profile.drv work ?
<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?