<tschilptschilp23>Hi guix! Cheers to the folks who packaged linux-libre 5.15.6 -- it's the first kernel newer than the 5.10.x-series, that does not break my laptop's dual-monitor setup! Not that I was not happy with 5.10.x though :) <jab>tschilptschilp23 I'd be interested to hear the story about updating linux/how hard it was. <jab>I also wonder what's going to happen to my T400 that only supports OpenGL 1. I think Mesa may be dropping support for it...not that I need it. I'm not really a gamer. <tschilptschilp23>jab: I'm on a 5-yearish fujitsu lifebook on a LAN-cable with the built-in Intel HD 620. I typically do 'sudo guix system reconfigure MYCONFIG.scm' if I upgrade the system and not only the packages, which I get through 'guix install PACKAGE'. This will put me to the newest version of the kernel. So not to lose my laptop's screen (externally connected monitor stayed functional in any case), I had to pin the kernel to one of the <b3>Hi, after setting up mcron in my guix home config (using home-mcron-service-type), how can I check what is scheduled? Should it display in `sudo herd schedule mcron`? <lilyp>tschilptschilp23: I know it wasn't really what you were going for, but please avoid talking about the evil channel :) <lilyp>b3: the home-* services should run under your normal user, so no sudo ought to be required <b3>lilyp: I thought that might be the case, but trying it without sudo I got `error: connect: /run/user/1000/shepherd/socket: No such file or directory` <lilyp>tbh I haven't experimented with mcron, so I don't know the command to control it, but do a ps and you will find the user it's running as <rekado>can and should I use search-input-file with gexps? <rekado>(gnu packages java) has a definition for java-commons-collections4, which looks up inputs and then uses find-files on them. <rekado>in a first pass I was going to replace the make-flags with an unquoted gexp that uses this-package-native-input instead of assoc-ref %build-inputs. <rekado>oh, I see roptat has already pushed a commit that switches to the gexp. <tschilptschilp23>lilyp: I just couldn't find this info in the (very) good guix manual and didn't want to post my config... <lilyp>Well, it does exist in the manual, but it's well hidden so you're pardoned <lilyp>You're basically using inferiors to point to some bespoke commit/kernel version *raghavgururajan peeps-in <pyrotek45[m]>emacs just has more than i need tbh and i would need evil mode for it to be usable <pyrotek45[m]>ive got some books on emaca but neovim is just exactly what i need <pyrotek45[m]>easy to customize and works great with a tiling window manager <raghavgururajan>Telegram blocked older versions. So telegram clients in guix has stopped working. <KE0VVT>raghavgururajan: How can I tell if my Telegram is not working? <singpolyma>I'm surprised a telegram client is allowed in guix <KE0VVT>singpolyma: So is Chromium. If you don't like it, use Parabola, where even emulators are banned. <KE0VVT>because you can load nonfree roms on it - oh no! <KE0VVT>even though you can easily write your own software to experiment with the old hardware platforms <KE0VVT>The rabbit hole is deep, singpolyma. Don't go there. <singpolyma>KE0VVT: sure, but license isn't the only criteria usually :) otherwise Firefox would be allowed for example <raghavgururajan>apteryx: It is to force reception of "Sponsored Messages", which I think is an euphemism for Ads. <KE0VVT>Parabola is out of control, removing packages left and right because a Nintendo emulator supposedly only exists to run proprietary software. <KE0VVT>raghavgururajan: So, how did they do this? How do custom clients no longer work? <raghavgururajan>singpolyma: I think you referring to FSDG. I removed the bundled stuff and there was no referrers to non-free stuff. <singpolyma>raghavgururajan: isn't telegram itself "nonfree stuff" that must be referred to / promoted by the client? <KE0VVT>singpolyma: Network services are neither free nor nonfree. Free clients can be used to interact with communication platforms that are private software. *raghavgururajan was waiting for c-u --> master merge, as new telegram versions dependencies are in c-u <KE0VVT>singpolyma: Should you text your friends on it? No. Can you use it as a public forum like Reddit? Yes. <raghavgururajan>singpolyma: telegram client is free, where as the telegram server is not. <singpolyma>raghavgururajan: right, but the client promotes the server, no? <KE0VVT>What runs on another person's computer is not our concern. What is our concern is what that person does. <singpolyma>Since there is only one server you can use the client with <KE0VVT>I have trained myself very well to strictly define the line between what is my computing and what is someone else's. <raghavgururajan>It doesn't promote the user to run any non-free software on their device, including telegram server. <KE0VVT>It is important, in cases like workplaces. Users should not be allowed to install anything they want on a work computer. It is not their computing. <KE0VVT>singpolyma: Importnat is the distinction between private software and proprietary software. Private software is technically free software. <raghavgururajan>I do hate Telegram because of being centralized and not self-hostable (non-free server). I find users using it as an alternative to WhatsApp, whose client is non-free. <singpolyma>KE0VVT: this all seems rather besides the point. The question isn't about what one can or should do, only about my surprise at this particular application of the FSDG and guix policy in general <KE0VVT>it falls within the philosophical line, singpolyma <KE0VVT>The software is free. The service is a separate concern. <jgart>I think guix ignores the fact of a free client made to only connect to a proprietary server as long as the client is free software <raghavgururajan>We have reddit client which is free software, but the server is not. <singpolyma>jgart: right. But rejects free software that has a link to a website that may have links to nonfree software <KE0VVT>Curse me for understanding the finer, hairier points of free software. <jgart>Clearly, telegram is only used to connect to propietary server software <KE0VVT>jgart: What software they run on their computer is none of your business, just as the software you run on your computer is none of mine. <singpolyma>jgart: right. I guess the argument is that since *all* their clients are free then their website doesn't promise running anything nonfree locally. <jgart>There does exist server side software that is free software ;) I understand the notion of private servers <singpolyma>Again, I'm not really interested in these finer points of philosophy, which are well worn and understood. Only in the policy itself WRT guix <KE0VVT>jgart: Then you should understand that communication can happen on, for example, Craigslist. <pyrotek45[m]><KE0VVT> "raghavgururajan: How can I..." <- I watched it but I still like nvim better <KE0VVT>jgart: And that you shouldn't use Craigslist <raghavgururajan>You know hypothetically, free software clients that *currently* *only* connects to proprietary server, could connect to free server alternatives, if they exist. <jgart>I understand these notions I'm just trying to nod at some of the loopholes in the legalese <raghavgururajan>For example, protonmail client is free whereas protonmail server is non-free. But there is neutronmail server (free alternative to protonmail server) which can be used with PM clients. <KE0VVT>raghavgururajan: This also applies to Dolphin, the GameCube emulator. It allegedly only exists to run proprietary software, but people could write programs for it. Don't exclude it from the repos for assumed uses. <singpolyma>raghavgururajan: yes, but my thought is that they promote the service. And in the case of a service with nonfree apps, also promotes those apps since the website of the service certainly pushes them. Reddit pushes their app very hard <jgart>singpolyma, parabola community is understands your points <KE0VVT>singpolyma: So, you want everyone to be cut off from the conventional internet, and not even use workarounds? No YouTube access at all? No Craigslist or petition websites? RMS poses workarounds for these all the time. <singpolyma>raghavgururajan: well, but policy extends beyond that. Else links to addons.mozilla would be allowed for example <KE0VVT>singpolyma: No. Mozilla Addons is a software repository that contains proprietary software. There is no comparison. <KE0VVT>singpolyma: Great. Use Parabola and be cut off from the whole world. <singpolyma>Reddit.com is a website that tries to trick me into installing nonfree apps every time I load it. Much worse than addons.mozilla <raghavgururajan>singpolyma: Correct. But telegram doesn't refer to a place to obtain/run non-free software. <jgart>Should we package the free skype client? <singpolyma>raghavgururajan: yes, yes. I conceded that telegram has only free apps so is an interesting case too <jgart>these are interesting loopholes <KE0VVT>jgart: if there is a way to access the Discord service without proprietary software, that is a good thing in general. Of course, one should evaluate what the service does with your data. <singpolyma>KE0VVT: I think you continue to misunderstand me. I use nonfree software and services when there is a reason to. I'm interested in the policy interpretation, nothing more <jgart>but yeah, people should be allowed to shoot themselves in the foot with proprietary software <jgart>I do so all the time for work <KE0VVT>singpolyma: I'm concerned that you want Guix's repositories to become as terrible as Parabola's. <raghavgururajan>free clients for skype and discord will be great for user's privacy. The software can be tweaked to encrypt/decrypt between clients. <KE0VVT>Removing SNES emulators, for example. <jgart>Those zoom meets we have to attend every now and then <singpolyma>KE0VVT: I don't want anything. Except to understand the policy <singpolyma>If I had a say it would be to include more not less, but I'm not interested in pushing a position <KE0VVT>jgart: Remove Python repo, and make no effort to provide a replacement Python repository containing only free software. <raghavgururajan>Free clients for non-free servers offer advantages like protection from tracking, remote-code-execution etc. <KE0VVT>I need to get out of here. I'm sorry I'm so heated. *jgart exits telegram client <singpolyma>I had never thought of that angle. That having pip or gem available also connect to repos that have some nonfree things if you look hard enough <KE0VVT>singpolyma: It breaks things a lot. It is not fun. This road is trecherous. (That said, a free Python repo should be made.) <jgart>the free python repo is called guix main channel <KE0VVT>I have looked into creating a free Flatpak repo. <singpolyma>KE0VVT: good idea. Let's call this free python repo guix <jgart>I'd like to get Guix working on some kisslinux fork with GNU C library support <singpolyma>I am about halfway into a guix package for a pypi package where the wheel has no instructions on how to build it at all, and it's all written in ocaml actually. That one really surprised me <jgart>I haven't come across something like that yet <singpolyma>It's like a small python shim over the ocaml, all distributed via pypi wheel. The setup.py just assumes the ocaml binary is there and copies it. Crazy stuff <raghavgururajan>jgart: I think that some kisslinux fork can be created using guix. It would be a dedicated channel, with guix connecting to different build-daemon (from kisslinux). <jgart>The world is a scary place. Let's continue the hard work of creating the Guix Utopia <jgart>I like the idea of a distro being easily forkable like dwm is <singpolyma>jgart: you mean kiss or guix? Guix is pretty forkable <jgart>I'd like to see some Guix forks in the future <raghavgururajan>singpolyma: Just saw your message regarding reddit. I see. Not long ago, I packaged Giara, a gtk+ client for reddit. <singpolyma>I think channels being so powerful makes forks less likely, but since it's all from source and updates are done via git it seems very forkable <jgart>Guix main channel is not forkable by one person without a ton of full time work <singpolyma>jgart: you mean because you need to run CI for substitutes? <jgart>The monolithic repo would have to be majorly reduced to be manageable to be maintained <singpolyma>raghavgururajan: yeah. I use all manner of shit, but have been avoiding reddit since they went nonfree. But going back a bit recently for work <jgart>would a single person maintain rust, python, go, c, c++, etc...? <raghavgururajan>singpolyma: Same here. I deleted my account. Currently using a fake account to read stuff that are not found elsewhere. <singpolyma>jgart: ah, well, I guess it depends on your goals for sure with a fork <jgart>maintaining a software ecosystem packaged and updated is a ton of work for one person <singpolyma>jgart: yes, for sure. Even Ubuntu doesn't bother trying they just ride on Debian <jgart>but if guix had a small core of packages it would be doable <singpolyma>I have some ideas about doing more automated guix stuff to package even more of the world faster. But I have lots of ideas. Sometimes one of them happens. Sometimes it was even me who did it 😅 <jgart>kiss's repos are only 121 packages as can be seen in section 003 in the link above <jgart>nixpkgs has some updater bots that we can maybe look into <jgart>Guix could use some automation for simple bumps to a package version <jgart>Maybe CI can help with that too, not sure <singpolyma>Well, we have guix refresh but could run a CI wrapper on it for example. Then make a branch / channel of everything that builds <jgart>I'm not entirely sure how nixpkgs does it <jgart>singpolyma, that would be cool <jgart>We should definitely take advantage of something like that given we can easily rollback :) <singpolyma>I also have this idea I call Big Ball of Guix which would be a channel where every patch that comes in with only added lines gets auto committed if it builds <pyrotek45[m]>I like guix installer and language choice but nix has no free kernel and up to date packages <jgart>singpolyma, that would be cool too <singpolyma>pyrotek45[m]: if nonfree kernel is something you need there are channels we can't talk r out here that are maybe a better compromise than nix <jgart>What would be the benefit of python packages, for example being in its own dedicated channel versus a monorepo? *raghavgururajan whispers "Guix" at pyrotek45[m] <singpolyma>jgart: oh yeah. A pypi or rubygems or cargo channel that runs the importer on the fly or something. Or just import everything and run CI, but working out a way to do it in demand feels coolest. I think someone did something like that for R <raghavgururajan>jgart: When kisslinux talks about monolithic repo, do they mean repo containing software-packages? like what debian has? <jgart>raghavgururajan, > monolithic repositories is that they have no clear end <jgart>> They have infinite growth possibility, <singpolyma>Where the distro tries to package all useful software <jgart>> very broad scope and rely on volunteer effort to keep everything fresh. <raghavgururajan>Repositories with sources for lot of software, yes, are hard to fork. <singpolyma>Instead of just a core and then encourage use of other channels <jgart>> They become harder to maintain over time and unless their growth is checked, <jgart>> will eventually become unsustainable. <singpolyma>raghavgururajan: yeah, I agree only having definitions makes it simpler. But I think the argument from jgart is that then it's up to the forker to update all defs <apteryx>but why would you want to fork guix if what you wanted to fork is just a subset of packages? You could have your own channel corresponding to that subset <jgart>> The distribution explicitly excludes logind, udev, dbus, <jgart>> systemd, polkit, pulseaudio, electron and all desktop environments. <jgart>with lock-in, too complex or otherwise out of scope. <apteryx>yeah, I don't get the argument (the maintenance load of the forker is on... the forker). Only seems fair to me? <jgart>channels depend on the main channel <jgart>if something breaks in the main channel then the channel also breaks unless you get lucky with `guix time-machine` but I've gotten burned with `guix time-machine` <raghavgururajan>Hmm. When channels depends on main channel, aren't they depending on some base portion/contents of main channel? <jgart>anyways, guix is the best thing we got! Let's make it work better :) <raghavgururajan>One could create a channel that inherits only few things from main channel right? <apteryx>how would a fork help? you'd have to fix these same breakages, and you wouldn't pass the benefit back to the guix community as a whole... seems counter productive <jgart>My custom python-flask package in my channel can depend on deps from the main channel *raghavgururajan likes modularity over monolithic, just trying to understand how it applies to repos <jgart>The kisslinux philosophy is to not package "the world" <jgart>but only a tiny core of stable packages from which everything else can be built *raghavgururajan sips latte <jgart>The each have their own pros and cons (no pun) *jgart sips proprietary frappuccino <singpolyma>jgart: the issue I see is that to install a useful system you will need many channels, so you will end up with a large list of "suggested channels" which mimic the boundaries of a monolith anyway <jgart>yup, that might be one of the cons <apteryx>jgart: not sure what you are arguing about still; you can make guix as minimal as you want, e.g.: gnu/system/examples/bare-bones.tmpl <raghavgururajan>Hmm. I wonder if a channel can be created having a definitions for modified guix's base stuff like cli daemon etc. <singpolyma>raghavgururajan: channel can't change a common input, right? Only define a new package using new input <raghavgururajan>After pull from both channels, will resulting guix be guix-original or guix-modified? <apteryx>channels can't modify guix, just add to it <apteryx>jgart: components in Guix you don't install don't need to be a cause of concern to you <raghavgururajan>apteryx: I see. What we could do though is separate guix itself from package+service stuff, into two repos. <apteryx>Having Guix as a mono repo is too valuable to part with <jgart>apteryx, what are some of the pros of the mono repo? <apteryx>maintenance is much easier, git grep, changes can be applied easily to the whole of it, etc. <jgart>besides encouraging users to look at all the code in one place <apteryx>you'll see an example soon when 'guix style' is applied to the whole repo <jgart>where can I read about guix style? <apteryx>doc/guix.texi on the core-updates-frozen :-) *raghavgururajan would like to apply `guix style` on his hair <lfam>Do I remember correctly that it's not possible to create files in the store that are not world-readable? <lfam>I guess that canonicaliseTimestampAndPermissions is called every time something is added <jgart>specifically: `$out/bin/git-absorb --gen-completions $shell > git-absorb.$shell` <jgart>what's the usual thing to do in guile/guix? <jwinnie>I am SO frustrated with this Guix thingy! <jwinnie>How do I prevent Guix from installing a bunch of extraneous packages like gcc, gnutls, etc.? <lfam>Packages like gcc and gnutls are low-level dependencies of all of Guix. They will always be present and used if you use Guix <jwinnie>My services is %base-services and my packages is (append %base-packages-utils base-packages-linux base-packages-interactive) <lfam>It's similar to any other operating system <jwinnie>But why does it try to pull in xlib? <jwinnie>And I think I saw librsvg in there too <lfam>librsvg is suprisingly a low-level dependency. By xlib, do you mean the xorg window server? <jwinnie>lfam: yeah, that's why I was surprised, since there are a lot of GUI related packages in there that get installed, without having a GUI <lfam>I don't recall exactly where librsvg enters the dependency graph but it is expected to be present <lfam>All these things are used or at least required by higher level packages <jwinnie>sorry I am acting like this, I'm very tired and trying to install guix which is pretty hard <lfam>It can be frustrating waiting for things to download <lfam>Or build, depending on how you are doing it <jwinnie>I don't mind waiting, I just want to understand what's going on with my system <jwinnie>Yeah thank you, I am trying to read that, and building my system based on it :-) <lfam>The people in this channel can help you find your way around the codebase and learn the tools that Guix has to explore the dependency graph <jwinnie>b/c it seems like the default %desktop-services contains *a lot* of stuff <lfam>Those tools are mainly `guix graph` and `guix gc` <lfam>Yes, it aims to provide a fully-featured set of services for desktop environments <lfam>In general, Guix tries to provide fully-featured packages and services. It's not a minimal distro <lfam>Oh, also the `guix size` tool which helps with profiling disk usage of packages <jwinnie>Well, I tried Guix with GNOME but it didn't work so well (bluetooth was broken, and so was a bunch of other stuff) so I'm now trying to figure out how to get a minimal install going, maybe that will be more successful <florhizome[m]>You can start with %base–services and then add more I guess. <lfam>I wonder if bluetooth hardware often works on Guix... it may be like wifi hardware in that the drivers seldom have free licenses <lfam>I don't use bluetooth really so I don't have a sense of that <jgart>jwinnie, those variables are lists that can have items removed from them <jwinnie>but GNOME isn't able to control it for some reason <jwinnie>In the logs it shows that the bluetooth adapter is detected, but then it says "not interested in bluetooth adapter" and then shows "bluetooth not enabled"... facepalm <jwinnie>yeah I'm beginning to think that nobody uses GNOME on Guix <lfam>Personally I don't use a DE <jwinnie>do you know how to write /etc/* files in the config.scm? <jwinnie>I want to write my swaywm config into config.scm <jwinnie>hm it's still kind of confusing to me <jwinnie>this config seems to abstract the config with a bunch of functions and stuff <jgart>What were you thinking you'd like to see for a sway config API? <jwinnie>I don't think I have time to write or import a custom sway config API :-) <jwinnie>I just want to be able to write my own Sway config verbatim and have it placed in /etc/* <jwinnie>(at least for now, while the API isn't in the main guix repo yet) <jgart>won't sway find the config in the usual place? <jgart>have you been able to start sway from Guix System? <jwinnie>I can just edit the file imperatively <jwinnie>I'm just used to NixOS where /etc is read only (AFAIK) <jwinnie>jgart: sorry, another question, do you know why guix likes to download things repeatedly? <jwinnie>I just ran `guix pull` and it has already downloaded libx11 3 times, I think <jgart>are you running the garbage collector a lot? <jwinnie>no, it's in the same invocation of `guix pull` <jwinnie>I am still installing guix, I have never ran `gc` <jwinnie>(and in my experience it does that even when I don't run `guix gc`) <jgart>guix pulls in a lot deps compared to other distros <jgart>I don't fully understand everything that's going on at a low level with that to explain it <jgart>maybe ask in the mailing list <jgart>or start investigating the code starting from `guix pull` to see what you end up understanding <res0Nanz>Hi! Can anyone help me figure out guix manifest with a patched package? <res0Nanz>in './test/my-hello.scm' I specified a patch: (patches (list (string-append (dirname (current-filename)) "/empty.patch"))) <res0Nanz>'./manifest-my-hello.scm' is (specifications->manifest '("my-hello")) <res0Nanz>this works: guix shell -L ./test my-hello <res0Nanz>but this doesnt: guix shell -L ./test -m manifest-my-hello.scm <res0Nanz>and the one worked doesnt work too until touch ./test/my-hello.scm <res0Nanz>it seems that (current-filename) returns #f <lilyp>I think we ought to rename it to something more appropriate while keeping the general theme: dirt. <lilyp>raghavgururajan: re telegram, I tried bumping the package but linkage currently fails, maybe you can have a look? <mekeor[m]><jgart> "rust should be rebranded to..." <- this has been discussed here already. afaik we agreed to wait until the rust-committe contacts us when they decide to be against our patches <florhizome[m]><pyrotek45[m]> "How do you start sway from gdm?" <- gdm can’t start wayland sessions in guix (well, yet, it’s been committed to the core-updates-frozen branch) <florhizome[m]>you can use sddm for that - but you will need to remove the gdm service for that. <pyrotek45[m]><florhizome[m]> "gdm can’t start wayland sessions..." <- So it will be fixed with gem in the future? <florhizome[m]><raghavgururajan> "jgart: I think that some..." <- gnukiss? honestly i'm not so sure what's the point about it -- and getting access to guix repos kind of destroys it? sth that'd also be cool though would be reviving kfreebsd with guix :D <florhizome[m]><apteryx> "but why would you want to fork..." <- i have been thinking that too, any fork would also have way less trust then guix main, since you would always want to to hash against the most trustable resource of your guix + package definitions (and their origin), the central repo lying at GNU is a nice default. hard to imagine prefering a guix source from somewhere else longterm. <florhizome[m]><pyrotek45[m]> "* So it will be fixed with gdm..." <- yup *near future* :D hopefully we will also get greetd etc then. the patch has stalled. regarding pipewire, jpoiret seems to be working on it, but there also is a video on the "andrew tropin" youtube channel about getting it working. personally i have not used it yet... <unmatched-paren>i think i'm going to update vlang, it's intriguing me but the latest version in guix is really old <pyrotek45[m]><florhizome[m]> "yup *near future* :D hopefully..." <- Oh? Any ETA? <tschilptschilp23>Hi! I just ran into a rather strange emacs behaviour with 'ido-everywhere' set to 't'. It heavily interfered with C-x C-f FILE. Basically finding the file (I'm talking about ~/.emacs, but true for any -- at least dot-file) with tab-completion did not work at all, and when typing it out and hitting RET it brought me to the suggestions '~/pictures/' (german though [~/Bilder])! At first I thought the culprit is global-company-mode set to <tschilptschilp23>'t' , or some lines set by emacs-guix and emacs-geiser, that I didn't write manually myself. But no, it was ido-everywhere. I do have a very clean init file now :) I've had this issue two years or so ago, but became brave and enabled it again a while ago. Probably I will again at some point, but only after I found a proper reason. Any idea, what that could be, or which benefit one can get from this setting (sorry for the implicit rant)? <tschilptschilp23>(still a little upset having to type 'emacs .emacs' from bash for about 15 times) <tschilptschilp23>'did not work at all' = show me pretty much everything in the completion-buffer, but the file I need! <florhizome[m]><tschilptschilp23> "Hi! I just ran into a rather..." <- uhm are you sure it's a guix problem? <florhizome[m]>can i just guix build a service actually? i never thought of that... searching fow a way to test service definitions without doing system reconfigure... <GNUHacker>I try connect with "ssh -X" to my guix server (wayland), from a Trisquel client (X11), but dont load the graphical env, only normal ssh <tschilptschilp23>florizhome: I'm fine with just not using ido (never really understood how it would benefits my workflows anyway ;) ) <tschilptschilp23>florizome: managed to mess it up on debian and win10 the same way before :) <tschilptschilp23>s/florizhome: I'm fine with just not using ido (never really understood how it would benefits my workflows anyway ;) )/florizome: I'm fine with just not using ido (never really understood how it would benefit my workflows anyway ;), but I like to try the 'specials' every now and then! )/ <attila_lendvai>is there something special with the behavior of dlopen and LD_LIBRARY_PATH on Guix? what i'm seeing is SBCL cannot find a .so, even though LD_LIBRARY_PATH is set, the dir contains the file, and dlopen is called with a non-absolute pathname (libffi.so.6) <attila_lendvai>damn... LD_LIBRARY_PATH is read only at the start of the binary: "If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain..." <lilyp>attila_lendvai: you probably ought to use the full sopath instead of patching environment variables <attila_lendvai>lilyp, this is not a usual situation: i have a script that builds an SBCL heap image that contains all the CL libs that my project depends on. then, when i want to work on my project, i start SBCL with this image. this is fast. the issue is that the CL codebase, somewhere deep down, ends up calling dlopen on "libffi.so.7. <attila_lendvai>lilyp, normally, in this build script, i capture such things at image build time, and restore them at image start time... but apparently for LD_LIBRARY_PATH that's too late. <attila_lendvai>for this setup to work, i'll need to produce the image file, and a image.library-path file, and from the starting environment (emacs lisp) read the new file and set LD_LIBRARY_PATH. or at least that's the only way i can see now. <lilyp>can't you hardcode the path to libffi at configure or something like that? <attila_lendvai>lilyp, that idea/workflow is completely alien to the CL codebase/environment. <tschilptschilp23>s/florizhome: I'm fine with just not using ido (never really understood how it would benefits my workflows anyway ;) )/florhizome: I'm fine with just not using ido (never really understood how it would benefit my workflows anyway ;), but I like to try the 'specials' every now and then! )/ <attila_lendvai>i.e. my project has no idea that the lib loading libffi.so is part of the transitive closure of dependencies that end up being loaded <tschilptschilp23>s/florizome: managed to mess it up on debian and win10 the same way before :)/florhizome: managed to mess it up on debian and a win10 the same way before :)/ <zimoun>Why «guix shell -C emacs-minimal emacs-tuareg -E TERM -- emacs foo.ml» does it not open directly in the tuareg-mode? Is it a bug? Or do I miss something? <unmatched-paren>since the Makefile doesn't mention $HOME, it must be somewhere in the actual source... <unmatched-paren>`rg HOME .` doesn't return anything about getting $HOME except for in a file called `vlib/os/os.v/`, which I presume is just the stdlib... <psyklax>Is it normal for a FDE install to require your passphrase twice? Grub asks, and then the init system asks. <unmatched-paren>grub needs to unlock the root to get to the kernel and initrd, then init needs to unlock everything else <nckx>psyklax: Yes, it is, for now. <psyklax>Is this unique to guix? I haven't seen that before. <nckx>Relatively. It's because the kernel is stored is inside the encrypted /. Most distributions support a separate /boot but Guix does not yet. <rekado_>other distros may try to avoid it by passing the passphrase around or storing it on disk <nckx>unmatched-paren: You can (setenv "HOME" "/tmp") as an accepted work-around. <rekado_>re gdm and wayland: on core-updates-frozen I use gdm and wayland. I don't use sddm. <ns12>Hi, when I try to install atlas (`guix install atlas`), the install fails with this error: "fatal error: atlas_pthreads.h: No such file or directory". How do I fix the problem? <rekado_>apteryx: we should merge "master" into "core-updates-frozen" again <rekado_>ns12: I don't know. Atlas cannot be built on the build farm because it insists on tuning itself to the current CPU. ***yewscion44 is now known as yewscion
<rekado_>apteryx: any objections to me trying the merge? Or should I better wait? <unmatched-paren>there's just a few errors related to trying to delete tests that don't exist anymore, i'll just fix those... <daviwil>Hey Guix! what's the best way to diagnose Guile compiler errors when defining and using a new service configuration type with `define-configuration`? I've defined a simple configuration but when I use it in another module I see get this error: "Syntax error: unknown location: source expression failed to match any pattern in form package" <daviwil>Yeah, no indication of the offending source text at all <nckx>What's not clear about ‘there was a certain error, somewhere’. /s <nckx>‘In form package’ is the only hint you have, so what's the most package-looking thing you wrote? <daviwil>Ahhhh... That must actually be it. The configuration I wrote has a `package` field <nckx>Or do you have a mismatched ) that makes Guix think it's still parsing a <package>? (Unlikely in a service, but who knows.) <nckx>If you don't manage to find the culprit we'll need the complete patch/file to search along. <daviwil>Ouch, figured it out. Apparently I had passed an invalid variable name to a struct accessor function of the configuration type <daviwil>I would have expected to just see a variable about the binding not existing in scope <daviwil>Got it all working now, thanks for the help! <unmatched-paren>they expect you to dump the cloned repo in your $HOME somewhere and then symlink $V_DIRECTORY/v to somewhere in your PATH <unmatched-paren>okay looks like v looks for wherever its executable is (something about '/proc/self/exe'?) and finds the docs in $V_EXECUTABLE_PATH/cmd/v/docs <unmatched-paren>so all i have to do is copy the docs directory to the $V_LOCATION_IN_STORE/bin/ directory <unmatched-paren>(turns out v is pretty readable, even if you haven't read the docs! seems like my wish of a more readable C has been fulfilled, and with rust-style memory management, too!) <nckx>Pity it's about as well packaged as Rust, too. <nckx>daviwil: Hm! But glad you figured it out. <stikonas>if I remember correctly, v is not bootstrappable <unmatched-paren>V is really just a C transpiler, and the C it generates is reasonably readable (if you can read C at all :P) <stikonas>well, that's the thing, machine generated C is not the same as human written C <stikonas>but you don't need that C code to build mrustc itself <stikonas>althogh defintely better than reading disassembly <stikonas>unmatched-paren: looks like older C generated source is needed <unmatched-paren>looks like v was originally written in Go, but... well, it's Gone :) <unmatched-paren>ah "First, the C source of an older version of the Nim compiler is needed to bootstrap the latest version" <V>Is there actually any real world software written in vlang at this point, or is it still largely vapourware <unmatched-paren>actually pretty impressive for such a young language; an os that can run several GNU utilities and V itself, a client for multiple chat applications, etc. <unmatched-paren>ah well, it doesn't look like it'll be merged anytime soon so i'll add my one to my channel <civodul>vivien: re gtranslator, good catch! fixed <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, avp says: Yeah, I'm the under-the-cover version of Artyom V. Poptsov ;-) <stikonas>actually things like bison and flex are also not being bootstrapped in Guix, they depend on themselves to generate some C files (those C files are shipped in tarball) but in case of bison and flex there is a bootstrap path and one can avoid using generated C parsers <civodul>stikonas: would be nice to fix this one! do you have pointers (or patches? :-)) on how to get that done? <stikonas>civodul: no patches, although there are a couple of pointers <stikonas>it was gio who did that, so his repos is one source <civodul>stikonas: awesome, thanks for the link <stikonas>and the second source is scripts in live-bootstrap <civodul>stikonas: thank you! i've opened an issue to keep track of this <stikonas>although later stages don't work with mes libc... which might be tricky in Guix... <civodul>i think we don't need flex/bison this early <stikonas>it's just that corresponding .c/.h files are often shipped together <stikonas>some of the stuff that uses it is coreutils, gawk, perl, gcc and bash <lilyp>tschilptschilp23: for the records, vertico completes dot-files correctly in my experience <tschilptschilp23>lilyp: thanks for the hint! I'm not even sure anymore if it even only were dot-files. I had some mess-up, but will try with vertico! If I wouldn't have forgotten about `M-x dired` in my hassle, I could have avoided my rant :) <lilyp>Oh, I completely understand your concerns, though. <lilyp>Using autocompleting stuff can work against you in really unintuitive ways <lilyp>I'm glad I set up vertico the way I like a few weeks ago, but trying out three frameworks in a day was no fun at all <tschilptschilp23>A while ago I had elpy with ido-everywhere and global-company-mode set up in a way that I thought I'd fly, now I'm back on earth! <tschilptschilp23>Well, right now TAB has to do it with ido set to nil. I'm kinda OK with that though <unmatched-paren>i guess it's because the author uses mac (judging by the screenshots), which doesn't have a package manager <lilyp>master → core-updates-frozen? <lilyp>sorry, I probably contributed towards those as well <unmatched-paren>to make v usable on guix or with pretty much any package manager we'll probably need to patch it a lot <lilyp>why trust package managers when you can implement your own? <unmatched-paren><><> conf-gtk3.18 troubleshooting <><><><><><><><><><><><><><><><><><><><><><><> <unmatched-paren>=> This package requires gtk+ 3.0 development packages installed on your system <sailorTheCat>Let's assume I have 2 channels with the same package: new and old version. Which definition will be used? I expect it depends on the position of a channel in the %default-channels variable, either first match or last match will be used. <unmatched-paren>sailorTheCat: From experience it seems to be the one with the new version <nckx>sailorTheCat: The newest as determined by Guix (highest version number; few fancy heuristics). <nckx>If the version numbers are identical channel order might matter, never actually tried. <florhizome[m]><daviwil> "Hey Guix! what's the best way..." <- uhm I wanted to quote this in the ranty post above >.> <unmatched-paren>lablgtk3 is trying to link to libgtk3.so, which doesn't exist even though i have gtk+ installed... <unmatched-paren>ok i just had to set LD_LIBRARY_PATH to $LD_LIBRARY_PATH:~/.guix-profile/lib <tex_milan>Hello, I installed Guix, default gdm and with i3. It booted OK. I then removed gdm and used slim. It booted OK. I then reverted to gdm and it did boot but gdm doesn't show up. It is in the list of processes but it loks like xorg is somehow nonworking. I restarted to generation containing the slim and it works. I restarted to generation zero, containing the gdm and it doesn't work. <tex_milan>Looks Guix configuration is not reproducible? <attila_lendvai>i'm having a lot of headache with this: something that works in guix repl doesn't work in a shepherd serivice. e.g. date->string from (srfi srfi-19), even though i have it listed in the service's (modules ...) entry, and i have a (with-imported-modules (source-module-closure ...)) around the gexp. any hints? <attila_lendvai>shepherd's guile is a little older than guix repl, but date->string should be there since forever... <lilyp>attila_lendvai: are you expanding the modules in the correct position? ***the_tubular57 is now known as the_tubular
<lilyp>I'm pretty sure you'd want the use-modules clause in the generated shepherd code <rekado_>merged "master" into "core-updates-frozen". Lots of rebuilds again. Sorry. <civodul>do you know if there are Rust-induced rebuilds? <civodul>those are the worst, because of librsvg/polkit <notmaximed>attila_lendvai: is (srfi srfi-19) exported from the gexp side? <notmaximed>IIRC, there's probably some 'modules' field where you can add (srfi srfi-19) <notmaximed>IIRC, with-imported-modules does not actually import a module <notmaximed>Instead, it makes sure the relevant modules will be in %load-path and the like <notmaximed>with-imported-modules is only for (guix build ...) / (gnu build ... things) <tschilptschilp23>Hi! I'm having troubles adding a dbus service to my config.scm. I'd need it, as a program is complaining about it being missing (Error, g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.pantalaimon1 was not provided by any .service files (2). I try to add it the following way: https://paste.debian.net/plain/1222151. If I go for a reconfigure, guix system answers with 'guix system: error: more than on <tschilptschilp23> guess I should probably add it to %desktop-servicesas these will carry dbus-services if I understand right, but don't really understand how. Any hint is appreciated! <rekado_>civodul: yes, librsvg is among those that are rebuilt. And a whole bunch of rust variants too. <rekado_>something caused a rebuild of cmake-minimal <notmaximed>attila_lendvai: The naming of with-imported-modules is a bit confusing. <patched[m]>I'm trying to make a package using trivial-build-system. I just want to `invoke` some commands. guix build complains that there's no code for module X. What could be wrong here? I can list it under \#:modules, but then it complains about another package again and again <notmaximed>attila_lendvai: About your previous question about macro's in G-exps: <notmaximed>attila_lendvai: The G-exp machinery doesn't care whether you're using macros or procedures <notmaximed>attila_lendvai: It doesn't expand what's inside the G-exp <notmaximed>attila_lendvai: Just make sure that, if you use a procedure or a macro inside a G-exp, that the procedure or macro is defined inside the G-exp (possibly using use-modules or (@ (some module) something) ...) <notmaximed>attila_lendvai: (If macros wouldn't work inside a G-exp, then you couldn't use any 'lambda' or 'let' inside a G-exp, because 'lambda' and 'let' are macros.) <notmaximed>patched[m]: Can I see the package definition + error message + backtrace? ***yewscion is now known as Guest2713
***yewscion_ is now known as yewscion
<rekado_>civodul: I don't understand where the changes come from. <rekado_>did I make a mistake in the merge...? <unmatched-paren>is there a reason why haskell's stack isn't in guix, or has it just not been packaged yet? <notmaximed>attila_lendvai: Is there any reason why we couldn't substitute "libffi.so.7" --> "/gnu/store/.../libffi.so.7" in the cffi package? <notmaximed>unmatched-paren: Do you mean the haskell stack, or the haskell tool named ‘stack’? <patched[m]>tried to enter all modules it complained about so quite a list, still not happy though ;^) *rekado_ reads the 37+MiB diff <notmaximed>If it's the latter: one possible reason is: why use stack / pypi / $LANGUAGE_PACKAGE_MANAGER when you can do "guix shell ghc-this python-that ..."? <notmaximed>unmatched-paren: To be clear, I don't see any fundamental reason why stack couldn't be packaged. <notmaximed>unmatched-paren: The (use-modules (gnu packages cmake)) doesn't do anything useful. It only makes the package object 'cmake' (& cmake-minimal etcetera) available), but you're not using it in the builder. <notmaximed>In the builder, you're using the "cmake" binary from the $PATH, which is another thing. <notmaximed>In general, importing (gnu packages ...) inside the builder doesn't do anything useful, with as exception some machinery behind "guix pull". <attila_lendvai>notmaximed, thanks for the help, i'll take a look now in the lights of that. re libffi: the reason is that the codebase is already there, and built with the CL native build system (ASDF), and there's no point in converting it to guix packages. simply put, it's not the guix machinery that builds the codebase, and coverting it would be a nightmare of a task. <tschilptschilp23>patched: there is a cmake-build-system in GUIX, which could take away quite some of the dependencies. Also, you could be off better using 'inputs for dependencies. That way things stay more connected and logical! <notmaximed>attila_lendvai: IIUC, you are not using the {sb,e,}cl-cffi package from guix, but a cffi outside guix? <notmaximed>tschilptschilp23,patched: cmake must go into 'native-input', not 'inputs' <attila_lendvai>notmaximed, yeo, it works when i add a use-modules form into the service activation gexp. with-imported-modules indeed has a very unfortunate name... completely misled me, even though i even looked at its code. <tschilptschilp23>notmaximized: if you use cmake-build-system it does not have to go anywhere <notmaximed>FTR, that package definition has a bug. The check phase doesn't respect #:tests? <notmaximed>(respecting #:tests? is important for --without-tests=PACKAGE and cross-compilation) <attila_lendvai>notmaximed, yes, i'm using the official repos of CFFI, and even that of SBCL. some of them are patched, many of them are outdated, etc... 100+ dependencies. <notmaximed>And including #:tests? #true is a bug that would be flagged by the linter. <notmaximed>derby: Whatever that is, it seems more a linux than a guix issue. <notmaximed>People at #linux on OFTC will be more likely to be able to help you. <patched[m]><notmaximed> "In general, importing (gnu..." <- Thanks for the hint about import (gnu packages ...) <patched[m]><tschilptschilp23> "patched: there is a cmake-build..." <- Yeah I saw the cmake-build-system, but wanted to try just a trivial build to get a feel for the system first. I'll keep in mind to put dependencies in inputs. Should you somehow separate build dependencies and runtime dependencies? <notmaximed>Strictly speaking, guix doesn't have a build-time/run-time dependencies, though native-inputs is roughly equivalent to build dependencies and inputs is roughly equivalent to runtime dependencies. <notmaximed>Separating them into native-inputs / inputs is important for cross-compilation reasons. <notmaximed>Because when a package is cross-compiled, ‘runtime dependencies’ _must_ be cross-compiled, and typical ‘build dependencies’ must _not_ be cross-compiled <tschilptschilp23>patched: that's what the differences between native-inputs, inputs, and for python-packages propagated-inputs do in my eyes. I've just been packaging some python-stuff and gcc-based things so far. I've also tried with trivial-build-system, but my conclusion is, whenever possible, make use of the specialized build systems, as they save one from hell :) <rekado_>civodul: a big contributor to rebuilds is ... php <notmaximed>trivial-build-system is only trivial in the sense that it doesn't do much by itself. It's not trivial to use. <notmaximed>tschilptschilp23: FTR, the official name is Guix (or sometimes lowercase guix), never GUIX <patched[m]><notmaximed> "trivial-build-system is only..." <- Is there some build system you can use if you just want to manually run some shell commands that creates the binary? <lilyp>patched[m]: use copy-build-system and add a phase before install that simply invokes whatever <rekado_>civodul: here's a list of packages that have been changed since 6db3c536e8, the last state before the merge <patched[m]>lilyp: Allright, I'll try that. Want to get something that werks before I delve into better practices <rekado_>I already removed packages where it's obvious that they have no impact, e.g. the r-* or coq-* packages. <lilyp>do you have issues with the phases or is it just inputs? <KE0VVT>What package would I need to convert a PostScript document to a PDF? <KE0VVT>Evince no longer opens them, and GV looks like it was written in Motif. <rekado_>civodul: looks like commit 1cb72b147354f760907d1e0c023a969a478dd0a5 is the problem here? <rekado_>nckx: when I revert 1cb72b147354f760907d1e0c023a969a478dd0a5 locally on c-u-f I can avoid all these rebuilds <rekado_>we still have a bunch of rebuilds because of the php version bump, but at least that doesn't involve rust. <civodul>rekado_: indeed, libnftnl has 12K dependents on core-updates-frozen and only 122 on master <civodul>"guix graph --path rust libnftnl" on core-updates-frozen shows why <civodul>rekado_: i'd say the solution is to introduce libnftnl/fixed stuck at the previous version, and to have Rust depend on it <civodul>after that we can cancel pending builds for that evaluation <KE0VVT>I installed emacs-poly-mode, but I cannot find it in my Emacs client. <ngz>KE0VVT: You probably need to restart Emacs <civodul>mbakke: good catch on "guix import pypi" and signatures :-) <civodul>tex_milan1: looks like a bug, indeed! <patched[m]>Using git-fetch as source method doesn't include .git, which causes issues for cmake. How do I solve this? <patched[m]>I guess the reason for .git not to be included is for reproducability? <rekado_>civodul: done in 0f2a77e14f8080a9f158f75d2634664565e81173 <pkal>Any tips on installing a cross-compilation toolchain? Can something like guix shell be used for that? <civodul>rekado_: thanks! i've canceled pending builds for evaluation 51601, which corresponds to the merge commit <civodul>pkal: currently "guix shell" doesn't support that <civodul>you cannot really install the cross-toolchain in a profile <pkal>So it has to be done programmatically? <awb99_>Is it possible to run qemu-binfmt-service-type with multiple cores? <civodul>pkal: if you want to cross-build a package, run, say, "guix build --target=aarch64-linux-gnu PKG", and the cross-toolchain for aarch64-linux-gnu is automatically created <civodul>programmatically you can use roughly (cross-gcc "aarch64-linux-gnu") and similar calls <pkal>civodul: Yeah, I'm not building packages but trying to compile C files to object files for different systems <jgart>This is a really great tool I use daily in my git cli workflow <jgart>tig || git <-> vis <-> git-interactive-rebase-tool <jonsger>tex_milan: its indeed a bug and some leftover... <jonsger>the configartion type with the long list of options is the right to choose from :) <tex_milan>jonsger: I figured it out as it accepted my xorg-configuration :) but anyway would be nice to fix it for beginners as me <singpolyma>pkal: even if "not building a package" writing a simple package def may be your ticket <civodul>so there's a path from gtk+ to php, seriously... <privacybuilder>hello! first time guix user here. Looking to run a guix image. When I follow the instructions using the iso image, I get "Unable to init server: Could not connect: Connection refused gtk initialization failed". I am assuming this iso wants to run a desktop? I am experimenting on a remote server, is there a headless guix server image somewhere I can get started with? <opalvaults>pyrotek45[m]: go to the systemcrafters youtube channel <opalvaults>that's how I originally learned earlier this year. <KE0VVT>pyrotek45[m]: I don't know how to set Emacs up for Vim users. <opalvaults>KE0VVT: try out evil mode, it's Emacs with vim keybindings (but you can still learn some of the Emacs ones as it keeps some of them.) <opalvaults>I also recommend trying out Doom Emacs first, as it has some sane defaults. <KE0VVT>pyrotek45[m]: I've hear people like Spacemacs, but I found it had too many extensions that weren't Vim-like. <opalvaults>Then, I recommend creating your own configuration <KE0VVT>opalvaults: I use some guy's config from GitHub. I think it uses Doom Emacs. <opalvaults>KE0VVT: the config itself won't contain the evil keybindings. <KE0VVT>opalvaults: My Emacs is regular style, not Vim style. <opalvaults>KE0VVT: I'm responding to your comment 'I don't know how to set Emacs up for Vim users.' <singpolyma>I use spacemacs, but did have to write some elisp to disable incremental search <opalvaults>Doom Emacs is specficially a "Emacs for Vim Users". <singpolyma>I should try doom maybe. I only use space because a friend did <pyrotek45[m]>i tried dooom emacs but its just to much things going on that i doot understand <singpolyma>Does too use the show keys stuff like spacemacs space-space ? <pyrotek45[m]>not saying its bad, its actually pretty nice, but i ran into issues with setting tab sizes <opalvaults>pyrotek45[m]: Emacs is an incredibly diverse tool that takes a while to use but the rewards are quite obvious the more time you spend in it. Like I said, I'd install Doom Emacs, and then watch the SystemCrafters youtube videos 'Emacs From Scratch'. <singpolyma>pyrotek45[m]: oh yeah, emacs does insane things with indentation by default. I had to write some elisp to hack all that back also <opalvaults>singpolyma: yes, it uses SPACE as the leader key <singpolyma>opalvaults: ok, so maybe It'll feel the same as spacemacs to me, heh *jgart started using and reading through the viper code base today <opalvaults>singpolyma: it's quite a bit more lightweight than Spacemacs, so that might be to your liking as well. <singpolyma>opalvaults: likely. The main thing I like is that when I ask for a layer I get the mode and whatever is needed to "evilify" it, like evil-org <jgart>I'm impressed with how much viper-mode implements. It's not evil though... no text objects, etc.. <opalvaults>singpolyma: it's about the same in Doom Emacs. When I press space, it pops up a minibuffer that (usually) shows both Evil and Emacs keybindings. <opalvaults>It also works in org-mode, and other packages that doom lets you install usually come bundled with the correct keybindings automatically. <rekado_>civodul: frustrating, isn't it!? It gets there via libsoup IIRC. <opalvaults>singpolyma: I definitely recommend it! Emacs changed my life so I like spreading the gospel. ;) <civodul>rekado_: yes, i'm cleaning all this up <civodul>that'll trigger another bunch of rebuilds but it seems to be the only way <singpolyma>I started trying emacs because I'm exploring malleable systems and accidental programming in general <KE0VVT>opalvaults: I think it uses Helm to have fuzzy search inside M-x and other things. <opalvaults>singpolyma: well at the very least, if you're exploring topics org-mode is invaluable. Check out the systemcrafters videos on making Org-mode more interesting to look at. It definitely makes for a great tool for academic use. <opalvaults>KE0VVT: Helm is great, I think I use company and vertico for completions and fuzzy searching and such but I can't remember off the top of my head. <the_tubular>Someone made a nice home.scm for bash and emacs so I can reference while building mine ? <opalvaults>singpolyma: and if you're exploring programming, you can do cool things like literate programming and configuration with org-babel. What this means is that you can create an org document, and use special source block codes within the document, and then "tangle" or push those source blocks to specific files. <opalvaults>you can also execute codes within those source blocks, which will give you the result below the source block, so it can be great for learning <raghavgururajan>KE0VVT: Were you able to get the tor working and setup X without display-manager? <civodul>i feel like a hamster with this whole core-updates-frozen effort <KE0VVT>raghavgururajan: I got Tor working. I use Wayland compositors. <singpolyma>opalvaults: yeah. Advanced org is on my list to try. So far just doing the Todo list thing :P <jgart>I haven't used to many advanced org features yet. Mostly just watched others use it. <KE0VVT>raghavgururajan: Yes, I fell back to GNOME again. Can't get a hang on Sway. <opalvaults>It also is its own markdown syntax which is read correctly by more popular git repo websites. <KE0VVT>raghavgururajan: In Sway, UK QWERTY and Hebrew keyboards do not work. <opalvaults>anyways sorry for proselytizing in the guix chat. singpolyma feel free to pm me if you need help getting yours set up at some point. <jgart>oh nm it's already packaged ;)