<SeerLite[m]>f1refly: I had to install lxappearance and my themes in my system configuration so it could see them. It's still kinda glitchy though, it seems to "forget" what my theme is whenever I launch it, but it applies the theme fine otherwise <f1refly>Well, it found the themes fine when I symlinked .guix_profile/share/themes to ~/.themes and it keeps the selection, but thunar doesn't seem to care about the theme setting there <the_tubular>Disregard the above, but I still feel like my CPU is dying though :( <nckx>(As you probably found out in your penultimate message, that directory existing has nothing to do with your CPU, and a dying CPU does not make some directories vanish — if only 😉) <the_tubular>nckx you are right, I jumped to that conclusion because I'm having other CPU related problems <the_tubular>And both problems started at the same time, so i though they were related <fnstudio>hi there! i'm in the process of setting up a personal guix channel and i'm working on the authentication part (adding my key to the repo and configuring it as the required signing key in my channels.scm) <fnstudio>now... as it happens, i actually have a separate gpg sub key for signing <fnstudio>when creating my .key file (to be added to the keyring branch of my channel/repo), should i only use the subkey? <fnstudio>never mind, i think i'm not making sense <fnstudio>but i might have figured out what the problem was... ***jonsger1 is now known as jonsger
<vagrantc>i haven't tried writing a system service before, but i need a service that can set the date if the date is older than, say, 2020 or something <vagrantc>because NTP refuses to update the clock when it's 1970 even though it's configured to force-set the time <mroh>maybe run `ntpdate -b` once? <vagrantc>mroh: that fails when the date is that old <vagrantc>drakonis: probably need to replace the battery, but this would be a useful workaround for machines that don't have a built-in clock either <kitty1>Has anyone managed to get kmonad working (and managed via system)? Looks like it requires some guix-specific instructions and im struggling to get it to like me so was wondering if anyone here knew lol <kitty1>if not I will look for their chatroom and ask them xD <SeerLite[m]>kitty1: Hi! All you need is add an udev-rules-service with kmonad to your services <kitty1>I needed to change the input in the .kbd file I was trying to load <SeerLite[m]>Oh, well you should still need the udev rules for it to be able to grab the keyboard I think. At least I had to do that ***califax- is now known as califax
<the_tubular>Is there a way to assure you build the least amount of packages ? <drakonis>what do you mean least amount of packages here? <drakonis>my suggestion is pinning your own dependency chain <bdju>vagrantc: iirc the date command can manually set the time and then whatever tries to sync it should kick in since you're close enough <bdju>the_tubular: do upgrade commands with --dry-run to see how much would be built or use `guix weather` to see how much stuff is built / if a particular thing is built. if something big isn't built yet, wait 1-3 days and upgrade again <bdju>if I do a fresh guix install on a new drive sometime soon would the "latest" iso be the way to go? I know often the release ISOs get some installer bugs in them <bdju>does anyone know if Guix System installs okay from a flash drive set up with Ventoy? (multi-boot, you just drop an ISO on) <zamfofex>bdju: Is it possible for you to try somewhere before committing to it? <vagrantc>bdju: yes, that's what i do manually, but i just need to wrap my head around a system service that does that :) <vagrantc>date --set --date=2022-01-01 would probably work well enough <bdju>zamfofex: well, it's to go on a new SSD for my machine already running Guix System, so if something was wrong I would just redo the install another way I guess. it would just be easier for me this way than to go find a different drive to wipe clean <zamfofex>> “if I do a fresh guix install on a new drive sometime soon would the "latest" iso be the way to go?” <zamfofex>I think “standard” gets transformed into “latest” when you run ‘guix pull && sudo guix system reconfigure …’ <vagrantc>in shell ... something like: test $(date +%s) -lt $(date --date=2022-01-01) && date --set --date=2022-01-01 <vagrantc>oops: test $(date +%s) -lt $(date --date=2022-01-01 +%s) && date --set --date=2022-01-01 <bdju>yeah, my worry is just the install going well mostly. I would be running updates right away once things were up and running <bdju>I have used guix system for several years now but only actually done two installs and neither went quick/well to be honest <bdju>but I want FDE enabled so I was gonna do an install instead of cloning my drive probably <bdju>since I didn't set it up last time <gnoo>while doing 'guix shell blender', guix's downloading 'blender-3.0.0.tar.xz', is it downloading the binary or is it the source? <gnoo>(it's 38.8 mb so could it be compressed binary?) <gnoo>oh yeah, it's in the configure phase now <gnoo>any way to download an old version of blender that has been built ? <efraim>Does anyone have a link to the guix vm download? I want to test my guix-home config without worrying about locking myself out <vivien>gnoo, try 'guix time-machine --commit=<past commit> -- shell blender' with a commit in the past (I don’t know how far in the past) <gnoo>vivien: thanks, i'll try 3f66b4c2664fef98bcd15a9a63f62fb45f2d9b18 as that was the commit before when blender was updated <mroh>gnoo: Try one before all the rust packages update (which triggers librsvg...). e.g. `guix time-machine --commit=d07a89d645 -- weather blender` returns substitute. ***rber_ is now known as rber
<tschilptschilp23>I'm just trying to build guix to test a small patch, and so far it looks good (from a 'guix shell -D guix --pure'): <tschilptschilp23>Do I have to run this from outside the shell to have my guix-command? I still don't really understand the concept, honestly. ***califax- is now known as califax
<lilyp>tschilptschilp23: do you have a valid signature on your own commits? I doubt it <tschilptschilp23>lilyp: you're completely right -- right now I'm struggling with uncommiting unsigned commits in magit <lilyp>tschilptschilp23: git reset HEAD~N <taxuswc>Hello! I'm trying to install a few LaTeX packages with guix. Is there any sort of cross-match list between guix texlive-latex-* packages and CTAN packages? In particular where can I find pdflscape.sty? <lilyp>taxuswc: I think the mapping is texlive-latex-CTAN_PACKAGE <lilyp>We don't have an importer for CTAN yet, though <taxuswc>lilyp: it works most of the time indeed, but not for pdflscape unfortunately <lilyp>which means no one's packaged it yet -- you can be that fortunate person :) <taxuswc>that's odd, because it's apparently a pdfpages dependency, which is packaged <lilyp>hmm, it could be bundled with pdfpages then, no? <taxuswc>unlikely, I've pdfpages, latex-base etc installed and run find -name *pdflscape* on the store, no results apparently <lilyp>I guess it's not a pdfpages dependency then 🙃️ <taxuswc>(well, it seems I could install something like full texlive and figure an appropriate package, but I don't have that much space on the drive :) <lilyp>Alternatively, our pdfpages package could be broken, but idk about the state of modular texlive nearly well enough to make such a statement <lilyp>If you need only that package, it'd make sense to package it for yourself, no? <taxuswc>sure, no problem, will give it a try in the evening <taxuswc>I've just thought it must be packaged somewhere, because some distros ship it in the texlive core (arch, for example), on debian it's in texlive-latex-recommended <lilyp>we do have texlive-latex-base, but since you report it as missing, I'd guess it's not part of that <lilyp>we don't have a counterpart to texlive-latex-recommended afaik <taxuswc>it would probably also be quite nice to have some sort of file-based search, like what pacman -F does. if it's possible with guix, then please correct me, I migrated from arch a week ago) <lilyp>it's a common complaint, there's some work to make CI report that data <taxuswc>thanks anyway, I'll give pdflscape another look in the evening then; for now i've just downloaded it from CTAN and everything works. So, apparently, all its dependencies are packaged) <rekado_>lilyp: texlive-latex-base is not what you think it is <rekado_>the package you want is texlive-base <rekado_>texlive-latex-base should be called texlive-latex, ad it corresponds to the “latex” package in the tlpdb <rekado_>there is no mapping from CTAN to packages in Guix. <rekado_>we package whatever is in tlpdb, and with the name texlive-<name>, where <name> is the name in the tlpdb. <rekado_>we used to have a CTAN importer, but it wasn’t really useful. It’s now the texlive importer. <lilyp>rekado_: thanks for the corrections <rekado_>and we didn’t get where we are now by design, but by progressively fixing mistakes I made earlier <lilyp>I haven't read it all, but re: cross-profile search paths, that's not something you can achieve without invoking a guix command <lilyp>guix package --search-path -p profile1 -p profile2 should give you what you want and you can stuff it into eval and everything, but it's not something guix can bake into the relevant etc/profile files <thang>hi, I've downloaded the guix vm disk image. I'm already running it and seeing the xfce desktop environment. But there's no /etc/config.scm file in it. Am I supposed to write a completely new config.scm or can I get it elsewhere? <thang>my bad, I've seen the path under /run in doc. Never mind <florhizome[m]><lilyp> "I haven't read it all, but re..." <- The issue has nothing to do with cross compiling, it was just sth I didn’t understand (bc native inputs) <florhizome[m]><lilyp> "guix package --search-path -p..." <- @thang:libera.chat: ? <florhizome[m]><lilyp> "guix package --search-path -p..." <- I don’t know how this relates to my patch which fixes an issue I had with foot. <lilyp>I wasn't talking about cross-compiling tho? <florhizome[m]>If installing alacrity to the same profile results in foot working it’s nothing cross profile <florhizome[m]>also, you wanna tell me if my patch works or not when I tested it? <Christoph[m]>Hi guix! The output of guix pull is kind of opaque for me. Most of the time, it's only a list of new and updated packages, most of which I don't know. Would there be a possibility to highlight the ones that I have installed, and maybe those which trigger rebuilds or grafts of ***npoirot is now known as user_46
<florhizome[m]>a lot of stuff that’s not working well can be fixed if search–paths would be used more. I don’t understand the permanent non–consideration of the possibility. <lilyp>florhizome[m]: cross-profile meaning optimizing for the case where alacritty and foot are not in the same profile <lilyp>littering search-paths everywhere is not a viable option; propagating would be, but isn't currently implemented <unmatched-paren>i've updated guix's nim to 1.6.2, it was incredibly easy... surprising for a compiler <florhizome[m]><lilyp> "littering search-paths everywher..." <- You mean propagating ncurses in this case ? <florhizome[m]>Since ncurses is probably not really changing, that would probably be viable, but otherwhere (propagating gtk, which propagates wayland, f.e.) really not. <florhizome[m]>Can you give me a link or sth why „littering search paths“ is so nonviable? Or when one may actually use this feature? <florhizome[m]>for qt–plugins or rofi–plugins, (most things „plugins“) I would think it’s a good solution. <florhizome[m]>On the other side, I don’t really see how the one patch to foot litters all the search–paths. <lilyp>I mean propagating search paths. It's a known bug, that environment variables don't end up where they need to be (e.g. TERMINFO_DIRS in the case of ncurses) <lilyp>speaking of ncurses, there's roughly 20k packages that have it as input <singpolyma>TERMINFO_DIRS is an interesting case for search paths, because it expresses runtime mutability instead of expressing a dev-or-build-time "look here". <lilyp>As for the rationale on when to use search-paths, see Mwhat Maxime wrote <singpolyma>The latter being what search paths is mostly for <lilyp>nah, search-paths are also for runtime mutability <lilyp>see each and every plugin path in existence <singpolyma>I'm not saying that such env vars don't exist, but that the design or search paths in guix does seem to be primarily with the latter in mind <lilyp>I think people outside of Guix are too busy thinking about build and run times as inherently distinct. <florhizome[m]>I can’t really hold up with discussions about mutability and stuff. I don’t pursue computer sciences. <florhizome[m]>So maybe Maxime has exposed some truth to me, that I’m not worthy for ;) <lilyp>the_tubular: well yes, but actually no ***rnst is now known as rnst_
<nckx>The whole point of search paths is run-time mutability. They don't even make sense outside of that. <lilyp>like obviously some env vars only make sense if you're currently compiling (like INCLUDE_PATH) and setting that for all profiles does not make much sense ***rnst_ is now known as _rnst
***_rnst is now known as rnst2
<lilyp>but even then as nckx points out, you are actually using the run-time mutability of the compiler <lilyp>also for many flags typically associated with "compile time", there's probably some interpreter out there consuming it at runtime <nckx>Let's incept deeper and ask ‘who suggested anybody suggested that?’ and see what happens. <nckx>florhizome[m]: Mutable just means ‘value can be changed’, as opposed to immutable, which cannot. There are no course requirements to Guix ☺ <nckx>If there were, many of us would fail them. <florhizome[m]>nckx i kinda understood that before but not the conflict at whole. <lilyp>And I thought CPSC 432 was a requirement... <florhizome[m]>nckx: Me, i feel like these discussions are way out of scope. <singpolyma>nckx: I agree you are right and my words were bad. I was trying to get at this "when would a user need the search path to make it to the profile when running guix install" question. <singpolyma>For example installing ghc-text I would need GHC_* to be set to use it (but I also need ghc to use it, so it works out). But for pandoc I don't need GHC_* for anything set. But of course the builder needs them set when building pandoc <singpolyma>So this kind of search path does not propagate in the ideal case. But a plug-in path kind of one, ideally does <singpolyma>Which makes me feel like there are "two kinds" in some sense I'm obviously not communicating well <lilyp>well, ideally the GHC_* would propagate, but match nothing :P <singpolyma>lilyp: I don't think I would say ideally there, but maybe that works out to the same result in practise <singpolyma>I mean, by that logic search paths could be global instead of attached to a package <florhizome[m]>I just want foot to be treated like alacritty, i don't need that to be for every terminal emulator ;P <lilyp>is foot a terminal emulator though? <lilyp>I already said I have no context <lilyp>I mean my foot certainly isn't. <lilyp>I already said, I have no context. <nckx>singpolyma: Sorry, got called away, but did not mean to imply ‘badness’. I think we were all somewhat confused and trying to figure out what the other meant (which seems to have happened, somewhat, in my absence). <florhizome[m]>you said pretty much before for now thinking you don't have no context at all. <nckx>florhizome[m]: That was the answer, by the way, not more questions. <nckx>That's more of a rhetorical strategy & doesn't pay off well in good-faith text. <nckx>lilyp: And aside, a pretty good one ☺ <nckx>florhizome[m]: <the conflict at whole> I might be wrong but I don't think there's a conflict here. As for scope, I'm not sure which scope you mean, but ‘doing things right’ is a Guix value, and that includes discussions that go beyond ‘this code works because we got result X — ship it!’. Reflecting on the nature of things is not a waste of time, although it's important that patches do follow at the end. <nckx>But the real patches are the friends we make along the way. <nckx>Any ideas what could have gone wrong? <florhizome[m]>nckx: i understand that but i meant to implicate exactly that i consider the discussion to have gotten derailed. TERMINFO_DIRS of foot is not INCLUDE_PATH for all profiles. There seem to be better solution for the case of terminal emulators though, maybe, although it seems to be out of hand. <florhizome[m]>Then there is QT_PLUGIN_PATH or ROFI_PLUGIN_PATH where i would still think using search-paths seems to be viable. <florhizome[m]>In my understanding it's enough to set them at runtime and if search-paths is not a good solution then i don't understand what to use it for anymore :) <nckx>M-hm. That unsatisfying guess is as good as any of mine, lilyp. <lilyp>Where is QT_PLUGIN_PATH defined as search path? <lilyp>Where is it bound in a wrapper? <nckx>florhizome[m]: It's not clear to me which properties of TERMINFO_DIRS and INCLUDE_PATH you're comparing. They are certainly quite different in some respects, but it's not clear to me why they need to be handled differently. I don't understand why having TERMINFO_DIRS as a search path is not ‘viable’, once the permabug of to propagate or not to propagate is decided. <nckx>This ‘propagation’ not necessarily related to the propagated-inputs ‘propagations’ to be clear. <nckx>You'd want TERMINFO_DIRS to trickle down to all users of ncurses without propagating ncurses. <nckx>I know I'm not making any new points. <florhizome[m]>nckx: Alacritty already sets it as a search-path, as i said. <lilyp> ;; FIXME: This should only be located in 'ncurses'. Nonetheless it is <florhizome[m]><nckx> "This ‘propagation’ not necessari..." <- So far i have been understanding the use as for a search path being set by a profile as if a propagated package could do it <lilyp>I clearly wrote search path propagation *and* explained the concept. *nckx shrugs, I don't get why this of all topics seems to be the heated one… <gnoo>how do you use wpa-supplicant properly in guix? i used wpa-supplicant-service-type but after it connects to the wifi i have to manually 'sudo herd restart networking' <nckx>florhizome[m]: I know that many terminal emulators include it — I added some of them. What I'm saying is this should not be necessary in a more perfect world: everybody using ncurses should get its terminfo search path for free, and this is what ‘propagation’ means in this context. <nckx>gnoo: What exactly gets ‘stuck’? <ss2>I’m trying to write a config serialiser: https://paste.rs/7Gw. I hope I’m not running into a dead end, and am using the example serialiser from the config. <ss2>But Samba’s config style is as such that everything is defined in smb.conf, where the parameters can be freely placed. <ss2>And the sections are interchangable too (hope that makes sense) <ss2>anyway, so I’d like to write the serialiser so, that it basically reimports all the smb-conf fields. <ss2>yeah, not so sure if this is a bit complicated for me. :) <florhizome[m]>> * <@nckx:libera.chat> shrugs, I don't get why this of all topics seems to be the heated one… <florhizome[m]>bc we started from a patch I sent that would add said variables to foots search paths, as alacrity has it now, and i asked, how to progress with it. And I have some more packages that I got working by using search paths (you might remember wayfire), and some patches (for qt5ct, lxqt–qtplugin, qtwayland), that add search paths. <ss2>anyway, hope somebody wants to have a look at it. ^^ <lilyp>florhizome[m]: Again, the solution is not to litter search paths everywhere. <lilyp>I'm sorry if I misunderstand something here, but the way you're talking suggests to me that you just recently discovered search-paths and are trying to hammer every vaguely nail-shaped issue with it. <lilyp>"We can solve this with search-paths" != "We should solve this with search-paths" <jgart>Guix packaging meetup today. Come join us for some free software wrangling 🦬 🤠 <mbakke>is it kosher to use #:imported-modules (source-module-closure ...) in (gnu packages foo)? <lilyp>Can't those modules be enumerated easily? <lilyp>If there's a list, you might want to splice it <jgart>danialbehzadi[m], It's just more work to have to mirror the event on some Mobilizon instance that few people will see and I'm too busy/lazy. Much easier to just send out an email from my terminal to guix-devel than have to fiddle with a graphical UI. <jgart>Does Mobilizon have an API endpoint I can use to automate event creation? <jgart>How can I disable all tests for a rust package? <jgart>danialbehzadi[m], I'll have to find the time to research that. Maybe for next meetup I'll use it. <jgart>re: disable rust rests: `#tests? #f` should work <gnoo>nckx: after connecting to wifi, i'll have to manually restart isc-dhcpd <gnoo>i use this little command to do so: sudo herd restart wpa-supplicant && sleep 4 && sudo herd restart networking && sleep 2 && ping -c 3 gnu.org <atw>"guix system: error: you may need these modules in the initrd for /dev/sda: virtio_scsi" thank you to everyone who wrote these checks, awesome stuff! <florhizome[m]><lilyp> "I'm sorry if I misunderstand..." <- I don’t think I’m trying to solve everything, again. <florhizome[m]>Not sure how much context you have; you can kick foot into the bin of you don’t apply some solution, same for the qt programs I mentioned. <lilyp>"some solution" doesn't necessarily imply search paths though <lilyp>And imo Maxime made a good argument against using them everywhere. <lilyp>And yes, it wouldn't be literally "everywhere", but you get the idea. <lilyp>In other words, I have no intention to go against Maxime's decision here, particularly not if prompted from IRC. <civodul>atw: heh, thanks for your feedback, it's good to see it's useful! :-) <civodul>mbakke: i'd say it's okay to use source-module-closure in package definitions, though it's nice if it can be avoided (source-module-closure does a bit of i/o and cpu that's best avoided on the host path) <civodul>or, you can call 'source-module-closure' outside of 'arguments' and keep its result around <florhizome[m]><lilyp> "And yes, it wouldn't be literall..." <- I am simply thinking it is underused, as it’s documented pretty poorly. the foot/terminfo thingy might not to be a very good example. <civodul>re union-build, hmm, i need to take a closer look! <podiki[m]>rofi-calc: great! (handy qalc is very handy) <podiki[m]>union-build: some of us discussed here, but no good ideas. perhaps the rewriting for the graft and when that happens with union-build's own linking? <podiki[m]>(I don't know the union-build or graft internals enough to more than speculate based on the symptoms) <ss2>okay, second try: I shifted the sections, but still get the same error, at the same spot: https://paste.rs/mFd, would someone like to give me a little hint? <lilyp>The rofi-calc definition takes up a little too much vertical space imo. Other than that LGTM, but I'm currently busy running my post-world-rebuild updates <mbakke>using cargo with python-build-system went smoother than expected <podiki[m]>lilyp: you mean that substitute with the escaped quotes? I was debating that, a little confusing on one line, but weird also with more lines <mbakke>would it make sense to introduce a (gnu packages crates-crypto)? <ngz>mbakke: IMO, this is a burden. You have to guess where a new crate goes. Sometimes it is obvious, sometimes not. Sometimes more than one location could be appropriate. <ngz>mbakke: If big modules are considered harmful, I would vote to for "crates-af.scm" "crates-gl.scm" … so inserting a new crate would trivial. <jgart>gnoo, how can I attribute you on the two packages you sent? <skye>how could I fix "include/bits/errno.h:26:11: fatal error: 'linux/errno.h' file not found"? is guix missing that file for some reason? <skye>and since I'm not too familiar with guix yet, is it better to write packages for these things rather than building from source like normal? <efraim>mbakke: I'm in favor of more crate files <ngz>efraim: You just need a better editor ;) <efraim>skye: I find writing packages to often be more easy. And make sure you're using gcc-toolchain, not gcc+binutils or the like <efraim>vim with vim-guix-vim works pretty well for me:) <florhizome[m]><civodul> "speaking of search paths: https:..." <- I think it would be good to cross-refer to them from sections where propagated inputs and profiles are defined/referenced. <florhizome[m]>It would help to understand how propagating a package can make a difference in guix vs usual connotations of runtime. <skye>efraim: is there a good tutorial for writing packages like that? the regular docs aren't quite enough for me <skye>I got stuck when it was time to make the hash from the git repo so maybe I'll start there. how do I do that? <florhizome[m]>> <@florhizom:matrix.org> I think it would be good to cross-refer to them from sections where propagated inputs and profiles are defined/referenced. <florhizome[m]>> It would help to understand how propagating a package can make a difference in guix vs usual connotations of runtime. <rekado_>for weeks I haven’t been able to run ‘guix pull’ to completion on my i686 machine <rekado_>it’s like I *never* see substitutes for the guix-* derivations. <rekado_>it’s not something recent. It’s really been weeks, which made me think it was my mistake. <rekado_>I’ll try commit 4d7a997ee, which is listed as having been built successfully on ci.guix.gnu.org <drakonis>what does it take to host multiple channels on a single repository? <podiki[m]>(since you can specify a branch in a channels.scm) <podiki[m]>though not sure if there would be any conflict having multiple of the same git url with different branches; I'd guess fine as long as they have different names specified <lfam>rekado_: For some time, the Guix package hasn't built successfully on non-x86_64 platforms ***iridium.libera.chat sets mode: +o ChanServ
<lfam>There are bug reports in the tracker <lfam>For i686, the first problem is that memory is exhausted <lfam>(Maybe there will be other problems later) <lfam><issues.guix.gnu.org/52752> <---- fix pending update of the Guix package? <efraim>aarch64 has an issue with tests-pypi <luishgh>hi guix! i have been working on updating the neovim package from 0.4.4 to 0.6.1, the newest release. i already managed to build it with lua 5.1, but wanted to try writing a modified version using luajit, as it is vital to many plugins. i found this patch [1] on the guix bug tracker, but it doesn't work on my updated definition. the main problem is that the error is a guile exception and i don't have a clue how to inspect it better or <luishgh>interpret it. i wanted to post the build logs here (through a pastebin link of course) in case anyone can help me understand what's wrong, but i'm not sure which flags to use in order to provide the best output. thanks! <lfam>I'm not sure if Guile 2.0.14 matters for `guix pull` or the Guix package <lfam>Or, send a message to <help-guix@gnu.org> <rekado_>that worked, but i got this lovely message at the very end: #<unknown port>:6:133: Unknown # object: "#<" *efraim is building the ~55 packages with python-pillow as a direct input <rekado_>lfam: since today I also see the Guile 2.0.14 build — not a build failure, but there’s no substitute and I know my i686 doesn’t have enough memory to build it. <lfam>rekado_: I haven't paid close attention to these issues, but I think the build fails despite how much memory the x86_64 host system has. The memory available to the build is being limited to a 32-bit limit, IIUC <efraim>rekado_: GUIX_DAEMON_SOCKET=ssh://bayfront guix build --no-grafts --no-substitutes guile@2.0 --system=i686-linux <lfam>That's for the recent bug fix in pillow? <efraim>lfam: yeah, I saw it in the debian-security bug list and then saw we have about a dozen others building up <efraim>didn't check to see if they were also 9.8 <lfam>Pillow is a critical one, usually <efraim>one of my pending patches adds the cpe-name to properties, so it should show up more often <efraim>we'd probably do well to adjust (probably) guix/cve to drop the 'python-' part of the name when searching for CVEs <podiki[m]>luishgh: in case it is helpful to you, there is now lua 5.4.3 (pretty current) <lfam>I even looked at adding a proper CPE name for the package, but nobody reports bugs for qtwebkit anymore <lfam>Maybe we should change the cpe-name to "webkitgtk" <efraim>it was part of my ~5000 'needs action' emails in my guix folder :/ <lfam>Some of the dependents can be upgraded, but for some we will have to wait, or lose them. It's going to be a bit painful no matter what <lfam>efraim, I actually declared email bankruptcy somewhat recently. I archived a few thousand unread emails <efraim>I spend some time checking for patches that overlap with what I'm thinking of working on, but mostly I feel like I only make it to them after someone else has applied it <lfam>I'm not sure the linter is finding CVEs reliably, or else I don't understand how it works <lfam>It's a thing in the sense that Guix has it <lfam>Back to the linter, `guix lint -c cve webkitgtk` reports nothing <lfam>It should definitely report something <lfam>Is the cpe-name set incorrectly? <lilyp>is cpe-name case-sensitive? in that case try with WebkitGTK <lfam>I don't know how to look at a CVE report from MITRE or NVD and map it to a CPE name <efraim>I understood it as CVEs are at a standstill for the past several years, but existing projects can still find a way to get CVEs issued <lfam>Yeah, the primary CVE system, which was an arm of the US gov, seemed to come to a halt in 2016 <lfam>It might be something for the EU to take over from us <efraim>down to 4 builds, I might be nearing the end for python-pillow rebuild tests <lfam>Or whatever governing body aims to govern <podiki[m]>qtwebkit the one that takes super long to build, limited to one thread or something? <lfam>I don't know. It's a browser engine, so it's definitely an expensive build <efraim>not as bad as qtwebengine or icecat, don't remember how it compares to full qemu <lilyp>I do think I recall it being worse than normal webkitgtk <lfam>Yeah, that's my impression as well. <lfam>QEMU is easy to build for me <efraim>maybe we limited it to a single thread? I can't remember <efraim>I think I normally end up catching qemu when it's building on slow hardware <luishgh>because of the size limit, i only pasted the build phase output <luishgh>podiki[m]: as far as i know, the neovim project only supports lua 5,1 and luajit as build dependencies <luishgh>and the version of luajit already packaged on guix is enough <lfam>luishgh: Is there nothing after the final line of your paste? <lilyp>I think it'd be the check phase et al. but they only pasted the build <lfam>It's always worth making sure <lfam>Sometimes people omit important information <lilyp>That's why I typically make sure by building myself :) <lilyp>but I know you're on other big projects now and I myself are rebuilding my OS... still <lfam>Exactly :) That's why I ask these basic questions, to keep the debugging conversation moving <lilyp>meanwhile my other machine has two threads downloading rust deps <lilyp>I think I might just kill those updates and try again tomorrow <lfam>It's unusual that a phase crashes with a Guile backtrace when the phase is not customized <lilyp>Hmm, whatever this build system is, it appears to be logging to strange places. <lfam>luishgh: This package depends on some other pending patches? <lfam>I don't seem to have 'tree-sitter' <luishgh>what bugs me the most is that the only difference from this package and the one using normal lua is a input field and the removal of one configuration-file <luishgh>lfam: oh, i had to package it myself <lilyp>Why does "[ 0%] Generating auto/window.c.generated.h" show up in (guix ui) and not the log? <luishgh>i will send the whole file, just a minute <lfam>Looks like ci.guix.gnu.org is just totally stuck again <efraim>I wouldn't mix luajit with lua5.1 packages. is prevent-embedding-gcc-store-path <luishgh>i just copied all imports from guix's vim.scm, so there's probably a lot of unneeded imports there <lfam>I think it's been garbage collecting <efraim>i'm putting my money on the question marks and luajit <lilyp>Well, let's be glad that guix is a source-based distro then :) <efraim>part of my question seems to have been dropped: is prevent-embedding-gcc-store-path in the original package? <lilyp>yep, exactly that thing modulo indentation <efraim>I'd say send it through again with --cores=1 and see if it does it again <luishgh>i basically only changed dependencies and the lua input <lfam>luishgh: I took your packages and did `./pre-inst-env guix build --no-grafts neovim-luajit` based on Guix Git commit cafc272462eefae087ee75158b6312295aad8874, which is very recent <lfam>It built successfully for me <lfam>So, something is either non-deterministic in the build, or your hardware is failing, causing miscompilation <luishgh>hm, i'm using cadcbbaf655953b28df9466c07b4b5c63d29b00b, will try running guix pull and running guix build again <lfam>I also agree with efraim's suggestion to use cores=1 *vivien is downloading unsettling amount of rust packages source code <lfam>vivien: There was a big update of Rust packages and the build farm got stuck 2 days ago <luishgh>lfam: ok, when guix pull concludes i'll try building it with one core. thanks for the help guys! <vivien>lfam, you need to lubricate the CI so that it does not accumulate rust <lfam>In general, we are often performing too many rebuilds due to changes in Rust, and doing it blindly because Guix's Rust packaging doesn't allow use of the normal tools <lilyp>I think I'll write up some cycle detection in Scheme so that we can hopefully go to rust inputs as normal inputs soon. <lilyp>Still, lack for grafts is extremely concerning <lfam>Yeah, it's definitely concerning lilyp. But it's no worse than we had it before recursive grafting was implemented, and we did survive ;) <lfam>Also, even with grafting, a similar bug in GCC would give us the same problem. Bugs in compilers can't be fixed with grafts <lilyp>apropos recursive grafting, there are concerns regarding union-builds raised recently <lilyp>(as well as the double grafting issue) <lfam>In some sense, the union-build issue is like going to the doctor and saying "it hurts when I use my arm like this" <lfam>The doctor says "Okay, don't do that" <luishgh>ok guys, i updated guix and now it builds successfully, even without limiting cores <vivien>Would someone with python knowledge look at my patch? I have made python-mne available: 53402, and in the process I discovered a slight imperfection in the pypi importer that I think I fixed: 53395 <vivien>That would be a nice break from all your rust annoyances :P <luishgh>now there is only one question left. it was discussed before on the guix bug tracker if guix should package neovim with luajit or remain with lua 5.1. The problem with the latter being that a lot of lua plugins for neovim abuse luajit only features and the problem with the former being that luajit is not available in all platforms supported by guix. what if we maintain the neovim package using lua 5.1 and use a modified version with <luishgh>luajit that only is avaliable at the supported platforms? <mhj[m]>What are the best eMacs packagesto use with guix? <mhj[m]>s/What are the best eMacs packagesto use with guix?/What are the best eMacs packages to use with guix?/ <vivien>mhj[m], your modification to fix just a space while keeping the case in "eMacs" makes me ask whether you’re talking about the text editor <vivien>I use the elfeed emacs package a lot <luishgh>i think the neovim with luajit version could be easily maintained through a package variant using `inherit' <lfam>luishgh: Really, this question will be answered by whoever decides to work on the packages. So, if that's you, it's up to you :) <lilyp>Well, there's the classics like magit and yasnippet, but thanks to emacs-27 there's also great auto-completion (I like corfu and that other capf-frontend for the minibuffer) *efraim is happy with vim <lfam>We do have package variants that differ across architectures <lfam>It's kind of annoying to deal with them, but also unavoidable when upstream support is limited to certain architectures <efraim>is it just riscv64 and powerpc64le currently that don't use luajit? <mhj[m]>I blame my iPhone autocorrect lol. Sorry, I do know that it is a separate thing… I suppose I meant stuff to work to with guile scheme <lilyp>electric-pair-mode and geiser <lilyp>if you want to, paredit or something like that as well <lfam>Apple made the eMac computer :) <lfam>Not surprising they added it to the iPhone dictionary <attila_lendvai_>speaking of Rust, i have 49 cust commits, most of them additions, but some updates were also needed. maybe someone can take a quick look and apply if appropriate, before too many merge conficts develop... https://issues.guix.gnu.org/53401 <efraim>python-scipy takes longer than qtwebengine <mhj[m]>And thanks lilyp for those packages, I’ll give them a try! <lilyp>I think we should s/rust/crust/ from now on 🙃️ <ngz>attila_lendva: I started looking at it, and there are merge conflicts already =/ I pushed 200+ Rust commits over two days, so I need to take a break before resuming the review. <attila_lendvai_>ngz, it's appreciated, thanks! i may look at rebasing it then and... then resend it? 49 more emails? ***attila_lendvai_ is now known as attila_lendvai
<efraim>I need to futz with %final-inputs and gnu-build-system to pass system to make sure it's building for the correct system <lfam>attila_lendvai: Also, you don't have to send 49 emails. You can do `git format-patch origin/master --stdout > my-patch-series` and just send the my-patch-series file <lfam>I actually prefer that as a reviewer <lfam>At least, I prefer it for long patch series *attila_lendvai made notes <vivien>are there people using paredit to edit scheme code? <lilyp>yep, many of them in this very channel <efraim>I didn't like it when I tried it so I don't use it <jgart>vivien, do you prefer evil mode with emacs or vanilla? <jgart>I haven't been using paredit either <jgart>But I do similar things that paredit does with just modal editing <vivien>jgart, I’m using emacs as vanilla as possible <jgart>for raising an sexps I just use visual mode and % <jgart>% to select matching paren of current s-expression <vivien>I don’t know what visual mode is <jgart>when I use emacs I usually use evil but sometimes I pair with friends on emacs and they're using vanilla emacs <jgart>I know enough vanilla emacs keybinds to get around but I really prefer evil when using emacs <luishgh>ok guys, just managed to transform my neovim with luajit to a package. i'll just study how to format a patch with git and send it to the guix bug tracker. thanks a lot for your help lfam and lilyp! <lfam>If you get stuck with the Git stuff, don't worry, you can also send your contribution as regular code <lilyp>git format-patch HEAD~1 should do the thing :) <lilyp>if you want to send it as attachment that is <lilyp>if you do want to go the extra mile to set up git send-email, by all means go ahead <luishgh>i guess at first i'll try to git send-email following jgart's link, if it gets to daunting i'll try these other options. anyhow, i'll come back here if i get into trouble haha. thanks everyone and have a great week! <tschilptschilp23>I almost fully migrated to guix-home now and like it a lot. One thing I miss though -- how would I get this neat 'package-version-overview' that can be retrieved through 'guix package --list-installed' when the packages are installed via 'guix install'? <rekado_>oof, this version of Guix is no good <lfam>(gnu packages crates-io) is 67597 lines long <rekado_>but I don’t think it’s the size that leads to ‘Killed’ here <lfam>What do you think it is? <rekado_>my guess was some sort of cycle, yes <rekado_>commit 014f1b607f1d88a8e733017afaca006545b7d99b (which works here) has a crates-io.scm with 59192 lines. <rekado_>I’ll try to get a more recent commit to compare. <jgart>is there a way to make the guix output more verbose to show what it is doing when building a .drv? <jgart>for example, building /gnu/store/8i7p4mp2nr32w9hf0llv12rzw9aby5av-compute-guix-derivation.drv... <jgart>what steps are being computed for that derivation? <rekado_>the computation details are in the associated builder <jgart>rekado_, thanks, how can I view the associated builder? <lfam>It's name is in the .drv file <nckx>E.g., pretty-print $(guix build -d PACKAGE) <estraw>Hey, has anyone encountered "configure: error: The Guile bindings of GnuTLS are missing; please install them." while trying to build Guix from Git on a foreign distro? <estraw>Never happened to me until somewhat recently and I'm not sure what to do about it <lfam>Did you make the development dependencies available with something like `guix shell --development guix`? <estraw>Yeah, i'm using `guix shell -D guix` <lfam>And, is your version of Guix fairly recent? <lfam>You can check with `guix describe` <lfam>We did a major update after that commit <lfam>So, it probably can't be used to build current Git revisions <estraw>oh i see, okay, let me try it again after pulling <lfam>Overall it seems that either Guile or some Guix / Cuirass components aren't stable on aarch64, causing frequent crashes and taking these machines out of the build farm <estraw>Yeah, same error with guix 8ef0473, weird <estraw>`find $GUIX_ENVIRONMENT -name gnutls.scm` returns `$GUIX_ENVIRONMENT/share/guile/site/3.0/gnutls.scm` too <lfam>You might want to `make clean` and try again <estraw>no rule to make target clean apparently <lfam>There is, I'm sure of it <estraw>makefile probably didn't get generated yet <lfam>Did you already try to start over with `./bootstrap`? <lfam>Then you can re-do configure and make <estraw>just did, removed cache and did `./bootstrap` then `./configure --localstatedir=/var` and it failed with the same gnutls error <estraw>yeah, it's strange, I've had it on a foreign distro for a long time and never ran into this before <lfam>My `guix describe` shows that I'm using Guix Git commit d331bd0a39. I made a fresh Git checkout of 8ef04739695 (from today) <lfam>Then I did `guix shell -D guix --pure`, and `./bootstrap && ./configure --localstatedir=/var` succeeded <ngz>Hmmmm is it me, or ci.guix.gnu.org is frozen? <estraw>I'm also on x86_64 on Ubuntu 20.04 <lfam>estraw: I recommend trying to reproduce what I did exactly <lfam>Or `guix pull --commit=....` <ngz>lfam: OK. It's reassuring… I guess. Thanks. <lfam>If that doesn't work, then something is breaking `guix shell`. Possibly improper use of ~/.bashrc to export some environment variables <estraw>perhaps yeah, i can check that too <lfam>ngz: The head node of the build farm has been collecting garbage for ~2 days. It can't keep building while it does that <lfam>It's a chronic problem and we are working to address it <ngz>Ah yes, I read about it. It does not seem easy to fix. <lfam>I think the fix is "use SSDs" <lfam>Or keep everything in RAM <rekado_>sneek: later tell apteryx Two of the aarch64 machines are running as usual. I just connected to pankow. The cuirass-remote-worker.log doesn’t indicate anything is wrong. <rekado_>FYI the last of the six SSDs we ordered should arrive tomorrow <rekado_>if it arrives early enough I’ll bring them all to the data centre and install them <lfam>ngz: I could cancel the garbage collection but I try to avoid doing any system-level stuff on that server <rekado_>if it arrives too late I’ll install them on Tuesday. <lfam>And we might as well just let it finish, or we'll run out of storage soon enough <lfam>Thanks again rekado_, for your effort <ngz>Sure. Cancelling GC is probably not an option. <lfam>Others have been doing it frequently in recent weeks... <rekado_>lfam: I’m glad I get to do *something* about it! <lfam>I mean, there's still some free terabytes <estraw>lfam just checking, is it correct to do `export GUIX_PROFILE="/home/evan/.guix-profile"` and then `source $GUIX_PROFILE/etc/profile` in .bashrc? <lfam>You have to do it in ~/.bash_profile <lfam>In general, ~/.bashrc shouldn't be a place where you export environment variables <estraw>i've been doing that wrong for a long time haha, that's good to know <lfam>Because, ~/.bashrc is invoked *every time* you start a new shell, whereas ~/.bash_profile is only invoked when you log in <lfam>Because `guix shell` works by starting a new shell, you can imagine it might get clobbered by things in ~/.bashrc <rekado_>sneek: later tell apteryx The problem with kreuzberg (10.0.0.9) was that it doesn’t do the wireguard handshake regularly. All of them have that problem. And I can’t upgrade the systems because ‘guix deploy’ sends x86_64 binaries to them. <podiki[m]>lilyp: what did you mean by vertical space on the rofi-calc patch? just that last substitute*? (line might be too long all as one though) <estraw>is .profile equivalent to .bash_profile? My system has the former but not the latter <lfam>The manual does instruct us to put these exports in ~/.bash_profile <nckx>estraw: If .bash_profile exists, bash will source it and not .profile. Otherwise, it will source .profile. <lfam>Check the FILES section of the Bash manpage, estraw <lfam>It will concur with nckx, authoritatively :) <nckx>It's a rather old-fashioned convention now that most bash ‘alternatives’ aren't actually syntax-compatbile AFAIK (although I don't use any of them). <nckx>*most used in practice, I mean, by which I really mean zsh & fish. <nckx>lfam: I like it when things do thay. <estraw>lfam: yep, works after making that change <estraw>seems like a user error moment, haha <nckx>Lots of Rust was touched today/yesterday. <nckx>I think lfam was involved, but blameless :) <civodul>i thought librsvg-bootstrap was going to help us avoid that <nckx>Of course. I don't think there is a reliable way to count the number of Rust rebuilds, correct me if I'm wrong. <civodul>i guess a rough approximation would be the number of librsvg rebuilds <civodul>but yeah, you can't see the path from librsvg to these crates <ngz>civodul: besides rust-cargo-c, do you know any Rust crate that is used as an input and not as a source? <civodul>but fundamentally, we'd end up with something less expressive <civodul>anyway, i actually know little about Rust packaging, so your input on this is welcome! <drakonis>the golang importer is otherwise very very borked without it <ngz>civodul: Would it make sense to define a "source" output, so we could tell the difference between ,rust-foo and `(,rust-foo "source")? <civodul>ngz: that'd just duplicate things, not great IMO <drakonis>that's what the author has set out to fix <ngz>civodul: OK. Hmmm, then what about creating a cargo.toml-union function that would take care of creating the guix-vendor directory necessary for Rust build-system, using its arguments as sources: (inputs ,rav1e ,(cargo.toml-union rust-foo rust-bar))? (I'm grasping at straws here) <ngz>(inputs (list ,rav1e ...))