<bone-baboon>-rasengan- [Global Notice] In the recent policy enforcement, some channels were erroneously included. We greatly apologize for the inconvenience. Please contact us in #freenode-services or firstname.lastname@example.org. Thanks for your patience and choosing freenode!
<vats>Hello, is there a way for guix package to not update some package in the manifest? I would rather not download texlive (2.6GB) each time I want to install a package.
<vats>I mean, each time I want to install a package after a guix pull.
<bone-baboon>With the help of `/msg chanserv help` I have a better idea of what freenodecom did to #guix@Freenode.
<Guest27>guix build --sources=transitive seems to be not enough to build packages offline, even if I have bootstrap-binaries and bootstrap-tarballs installed. Is there an option for saving necessary bootstrap binary minimum plus package sources for offline building?
<vats>Thanks. I'll make sure to keep that dependency info as a comment in my manifest. But I don't think texlive package changes that much.
<lfam>vats: Yeah, it seems to change once a year or less
<lfam>I did the gcroot thing for a while and had to adjust it very infrequently (I noticed it was updated because I was waiting for the long download)
<Guest27>lfam: yes, now i'm trying to understand 1) why lua package needs python at all 2) why it doesn't have python in bag deps if it needs that
<lfam>Did you look at the graph? Or just grep the output?
<Guest27>I grep because navigating such graph is a problem for me
<lfam>Yeah, these big graphs are difficult to inspect. It would be great to have a better tool than `dot` or `xdot`
<lfam>Anyways, Python is part of the bootstrap path of the entire distro (see the python-boot0 package in gnu/packages/commencement.scm), so every package depends on it
<lfam>It would be great to understand why it is not shown in --type=bag
<Guest27>but I have bootstrap-tarballs installed, shoudn't python-boot0 be inside that?
<lfam>The manual says this about the 'derivation' graph type: "
<lfam> This is the most detailed representation: It shows the DAG of derivations (see Derivations) and plain store items. Compared to the above representation, many additional nodes are visible, including build scripts, patches, Guile modules, etc. "
<lfam>Whereas the 'bag' type is only about packages, if I understand correctly
<lfam>So, my guess is that this dependency "goes through" something besides a package, like those "build scripts, patches, Guile modules" mentioned
<lfam>I don't pay much attention to bootstrapping, so I might be wrong, but I think that bootstrap-tarballs containes the "bootstrap binaries". The things in gnu/packages/commencement.scm are packages built from source
<lfam>I guess they are the next step above the bootstrap binaries
<lfam>Scrolling, I see your message about working offline. I'm sure it's possible to achieve but it's not really supported at this point
<Guest27>yes, such amazing feature would be described in manual. But i'm still trying to achieve it. I'll try to see reverse-graphs of python-bootstrap packages to understand if there is some kind of package having everything needed for bootstrap as dependencies
<Guest27>oh and i'll take a look in bootstrap.scm thanks to you
<vats>That discussion does propose a solution, --gc-keep-outputs which doesn't seem to be configurable per package. So either I can save the outputs of all live derivations, or none. I'd rather save my disk space, so that doesn't work for me.
<vats>I guess I'd define texlive-texmf publicly for myself then, for now.
<lfam>gc-keep-outputs is an option for the daemon, and affects handling of all Guix operations. There's no way to apply it for a particular package
<lfam>vats: I checked the "references" of the built texlive package and it does keep a reference to texlive-texmf. These references are not subject to garbage collection, so it's not clear to me what's going on
<Guest27>I always struggle with those bootloaders and all the partition shame
<Guest27>i would prefer to generate some .img that can be installed with dd
<vats>Hello, I did a system reconfigure recently, and after that I get the following error when running any command with sudo "sudo: /var/guix/profiles/per-user/vats/guix-profile/bin/sudo must be owned by uid 0 and have the setuid bit set". Somehow permissions for the sudo binary have been changed. The system configuration I used to reconfigure does not list sudo package in its manifest. Has anybody experienced this before?
<cbaines>civodul, not particularly. Build information is coming through from the Guix Build Coordinator on bayfront at least, it's just that the narinfos aren't being fetched.
<cbaines>I started changing the code to improve this, and I'll hopefully get that done soonish, as I want the build and narinfo on data.guix.gnu.org to be up to date
<cbaines>although, they'll need to be data from more than just bayfront to make that page work, so I guess it also depends on getting build+narinfo data from ci.guix.gnu.org, or another substitute server
<dstolfa>besides, if i saw someone under the #guix name saying weird things, i'd make sure to check that it's an official channel on the website itself. if i saw a message saying that the channel was taken over without the consent of guix itself i wouldn't believe any of it
***pkill9_ is now known as pkill9
<tissevert>yeah, I think the idea was to avoid confusion right after it happened but it's losing value as time passes, the word has had time to spread
<mjw>so, uhm, who/what generates that * #guix ##guix :Forwarding to another channel message on freenode? I missed it at first. It isn't very clear that the official channel has moved to libera.chat instead.
<cbaines>civodul, getting narinfo fetching working smoothly will mean there's data from bayfront, but you're right in that not having builds information from ci.guix.gnu.org will pose a problem for the package reproducibility page
<ruffni>shouldn't this be an error, though? failing to replace a binary which is not in the path usually means something is missing or misconfigured
<lkg_guix_qa>Hi, I have a question: openjdk 15/16 has been released long ago and openjdk 17 LTS will be released in September; currently Guix has only up to openjdk 14 in java.scm; are there any special reasons (besides no one has update java.scm yet) that we don't have openjdk 15/16 in Guix yet?
<lispmacs>hi, I was trying to put "transmission:gui" in my package manifest file. "transmission:gui" works fine in the cmd-line interface, but doesn't seem to work as an parameter to "specficiation->package"
<dstolfa>based on In other words: dynamic vs. static linking never makes any difference on the outcome of the analysis.8 The FSF has been advised by several US lawyers on this matter over the years, and the answer is always this one. it seems one would need to have a semantic discussion of: "is loading a kernel module the same as linking"
<dstolfa>in any case, that comment in the guix source is a bit vague, maybe changing it to: "The ZFS kernel module should not be downloaded since the license terms don't allow for distributing derivative work that is not under the GPL license (see FSF statement on it for more detail)" or something?
<mason>dstolfa: Yeah, the argument there comes down to what linking means, largely.
<mason>dstolfa: That states an opinion about what it means to be a derivative work.
<dstolfa>mason: yeah, but even if one were to follow the FSF statement on it, i was a bit confused by the original comment
<dstolfa>i read it as: "the CDDL does not allow you to redistribute modified stuff"
<mason>dstolfa: The point is, the end user is free to link things as they see fit, and the statement that a bit of binary resulting from compiling copyleft code cannot be downloaded is factually incorrect and a burden on the user, complete with environmental impact.
<mason>dstolfa: I want to help my neighbor, and the comment doesn't.
<dstolfa>it would be worth checking two things specifically: (1) does ZoL use *any* linux interface (including allocators) that are under the GPL; (2) does the linux kernel grant permissions to modules to not be GPL'd in any way if those parts are used?
<mason>dstolfa: ZoL interfaces with SPL and doesn't use any interfaces marked GPL.
<raingloom>i think i found an import loop in guix... investigating a bit more...
<raingloom>could someone check if they can build gnu/packages/chez.scm from this commit? ae88e30a0f8403e781f8b01262766cdc46b1018a
<jackhill>roptat: nheko at least opens a register/join window for me as does quaternion. I wonder there is a bug that is causing qt/qml to not work for you. I'm on x86-64 running sway with Mesa DRI Intel(R) HD Graphics (ILK) for graphics (I think Qt apps are still using xwayland for me).
<roptat>jackhill, I'm on a foreign system, have any qt app suggestion I could try?
<roptat>(maybe it's not representative of my use, I wouldn't use matrix on that computer anyway)
<jackhill>I've had sucess with linphone (from linphone-desktop) and jami-qt, but niether of those are light on dependencies. There's probably something lighter, but I don't do much in qt land.
<jackhill>oh, okular might be a good one (pdf/document reader)
<nckx>civodul: Sigh. I want to like it? The quality of graphical clients is abysmal compared to IRC (I triend Nheko & Quaternion because they are packaged). The official Web client Element is notoriously heavyweight and distractingly slow. I was also shocked that it sends ‘nckx is typing’ to everyone with no obvious way to turn it off. I quit because of that. That attitude worries me.
<nckx>I really hope someone writes HexChat for Matrix (or I like one of the emacs clients when I try more this weekend, but they seem ever more immature).
<dstolfa>the downside of all other matrix clients is that end to end encryption isn't fully supported. unless matrix clients improve drastically i fear that it might stay irrelevant forever
<dstolfa>the protocol is fine for the most part, but my god the clients suck
<jackhill>where does xmpp fall into the calculus of chat options?
<tissevert>I'd add that Element does a weird thing with keys that breaks when using private browsing
<dstolfa>pkill9: element is the only one that really "supports" matrix how you'd want it supported, and it's a mess in a lot of ways
<dstolfa>you can try using it... limitations become obvious very quickly
<tissevert>it can't save some randomly generated keys, doesn't say a word about them, then, when you try to log back in, moans that the (new) session is unidentified and asks you to bring your old session back from the dead to confirm it
<tissevert>you have to manually go to some unobvious place to ask for your keys by hand, with nothing at least giving you a hint that such process 1) exists 2) is necessary for a regular usage
<tissevert>failing to do that, when you log back in your own messages are encrypted and can't be read
<projectmoon>That's the nature of using it in a web browser, in private mode
***iskarian is now known as Guest557
<tissevert>I expect a chat to be as stateless as : «log in / log out», I save my password, that's my business, I manage to type it back, my business too, from there the experience should be the exact same as if I'd never left
<tissevert>I can save a lot of logs and such for IRC if I want to but it's not necessary
<civodul>cbaines: it took several minutes but eventually failed with gnutls-error = GNUTLS_E_AGAIN (the thing for which i submitted a fix upstream a few weeks ago)
<tissevert>I can open a netcat in any shell and start a new session and have exactly what I have right now
<tissevert>storing necessary things without letting the user know about it is not a normal part of «using a chat»
<pkill9>the problem is e2ee is client to client, and with element the client is a web browser, so it needs to save the keys, but it doesnt in private mode
<civodul>the NixOS folks had good arguments in favor of Matrix, mostly that it lowers the barrier to entry (for instance, you can paste snippets and clients DTRT; no need to learn the etiquette, pastebins, etc.)
<nckx>Of course not everyone on the ML IRCs, but that's ‘different’.
<vats>Hello, I'm trying to figure out how to symlink an input to texlive from /gnu/store/ to /var/guix/gcroots/. The input is a 2.6GB tar archive texlive-texmf.tar.xz which gets deleted after applying the manifest, and needs to be downloaded again and again upon each application. After the build for texlive finishes, I can't find that archive in /gnu/store/ anymore. How can I have it preserved in the store after the build?
<vats>I do see a .drv file for that input in store. Could I use that to build that input again?
<nckx>vats: <The input is a 2.6GB tar archive texlive-texmf.tar.xz which gets deleted after applying the manifest> Unless I'm missing something, that is not how things work. Which exact commands do you run before it's gone? You can use a pastebin if it's more than a few lines.
<nckx>If it's in the store during the build, it must be there afterwards unless someone runs ‘guix gc’.
<vats>nckx: Does --gc-keep-outputs=yes speed up application of your manifest a lot? I'm looking for ways to do that. Mainly to save the time it takes to download everything. Even if I exclude that 2.6GB file, I'd need to download 1.5GB on each application after a guix pull.
<nckx>vats: It means that fewer build-only inputs of live store items are deleted when I run ‘guix gc’, and since I build a lot from source it saves my poor laptop a lot of time & heat.
<nckx>vats: Again, unless I'm missing something obvious, if Guix is downloading 1.5 (or 4.1!) GiB that means you didn't have it to begin with, or you deleted it by running ‘guix gc’. There's no way around that.
<nckx>You seem to think (or observe?) that Guix just starts deleting random stuff from the store after applying a manifest. It doesn't (shouldn't, ever, bug, bad one).
<vats>I do collect garbage after applying manifest to save space. But I didn't this time around (or I could have forgotten, it is possible, though I'd have a lot more space in root partition if I had.).
<vats>Thanks nckx. I guess I understand why I had to download 4GB+ files each time.
<nckx>So mystery solved \o/ --gc-keep-outputs=yes --gc-keep-derivations=yes would save you downloads (at the expense of disc space) when GC'ing.
<chikamungus>Hi all. Any guix emacs gurus on here can help me understand how the guix emacs package system works? How do I get emacs to read subdirs.el in ~/.guix-profile/share/emacs/site-lisp ? What magic do I put in my init.el?
<nckx>Guix is designed to leverage proprietary Intel® technology to download tarballs through the covert NSA backdoor sidechannel to your Wi-Fi chip, so your ISP doesn't see it and can't bill you for the bits.
<dstolfa>nckx: it also uses SGX to hide its inner workings from the evil browser on your system
<leoprikler>Why is everyone so salty about compiling the kernel? Gentoo has been doing that for 10 years.
<drakonis>of course that in most clients its /buffer or /b <window>
<drakonis>leoprikler: trying to get people from nixos to move into guix
<solene>leoprikler: how many GB of disk space do you need nowadays to compile a kernel?
<vagrantc>nckx: that's when i blindly type my irc client's command to switch to another window, and then keep reading the current conversation not realizing i've already typed the switch to another window :)
<drakonis>the first nitpick is usually the lack of the vanilla kernel
<nckx>I compile everything (night time is partner complaining about the fan time) so I honestly forgot about that argument.