IRC channel logs

2021-05-26.log

back to list of logs

<bone-baboon>Just wanted to share what I saw happen in #guix@Freenode here it is:
<drakonis>freenode staff took over #guix
<bone-baboon>*** Join: freenodecom (~com@freenode/staff, freenode-placehol: www.freenode.net)
<bone-baboon>*** Mode change: +o freenodecom on #guix by freenodecom (~com@freenode/staff)
<bone-baboon>*** Topic change by freenodecom (~com@freenode/staff): This channel has moved to ##guix. The topic is in violation of freenode policy: https://freenode.net/policies
<bone-baboon><freenodecom> This channel has been reopened with respect to the communities and new users. The topic is in violation of freenode policy: https://freenode.net/policies
<bone-baboon>*** Mode change: -ov nckx[llcoolj] nckx[llcoolj] on #guix by freenodecom (~com@freenode/staff)
<bone-baboon>*** Mode change: -v ChanServ on #guix by freenodecom (~com@freenode/staff)
<bone-baboon><freenodecom> The new channel is ##guix
<bone-baboon>*** Mode change: +pimf ##guix on #guix by freenodecom (~com@freenode/staff)
<bone-baboon>*** Mode change: +f ##guix on #guix by freenodecom (~com@freenode/staff)
<bone-baboon>*** Part: freenodecom (~com@freenode/staff) left #guix: [No reason given]
<bandali>they just did the same to #emacsconf-org and #emacs as well
<drakonis>yes
<drakonis>this is fucked up
<bone-baboon>They also changed the topic for #guix to:
<bone-baboon>*** Topic for #guix: GNU Guix | 1.3.0 is out! https://guix.gnu.org/en/blog/2021/gnu-guix-1.3.0-released | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org
<bone-baboon>*** Topic set by nckx on Wed May 19 17:06:32 2021, 6 days 5 hours 59 minutes 8 seconds ago
<drakonis>isnt this the wrong topic?
<bone-baboon>The way they changed the topic makes it look like they are impersonating nckx.
<bone-baboon>Recently the topic for #guix@Freenode was saying go to Libera.
<drakonis>you cant even access #guix anymore
<bone-baboon>lfam: freenodecom has been changing #guix@Freenode.
<lfam>I just saw that
<drakonis>they even attacked haskell
<drakonis>holy shit.
<bone-baboon>Probably any channel that had a topic directing users to Libera.
<lfam>Yes
<bone-baboon>Can someone explain the mode changes that freenodecom did on #guix@Freenode?
<drakonis>#hurd hasnt been hit yet
<drakonis>but it will soon
***illegal is now known as V
<bone-baboon>If having the topic direct people to Libera is in violation of Freenode policy then I wonder if telling people to go to Libera like roptat was doing is also against Freenode policy?
<lfam>The "policy" that suddenly appeared
<pushcx>If a channel had 'libera' in its topic, all channels in that namespace were taken over. wikimedia lost a lot of private channels for wikipedia editors.
***lfam is now known as zebracloud
<bone-baboon>I received this message on Freenode:
<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 contact-us@freenode.net. 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.
<vats>Nevermind, found --do-not-upgrade.
***MidAutumnMoon0 is now known as MidAutumnMoon
<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?
<nckx>This was bound to happen.
*nckx → work
<vats>People who have texlive in their manifests here. How do you deal with guix package downloading the huge texlive package when applying the manifest after a guix pull?
<vats>The --do-not-upgrade option doesn't work with manifests, in my experience.
<lfam>vats: I don't have texlive in my profile / manifest, so I'm not sure exactly what's up
<lfam>Is it downloading an updated version of the package you have in your manifest? Or is it downloading something else, maybe used to build the new profile generation?
<vats>texlive is a huge package (a 2.6GB download). Whenever I apply a manifest after guix pull, it downloads the whole package even thought it's exactly the same version.
<Guest27>vats: probably guix inferior feature may help you pinning your texlive version https://guix.gnu.org/manual/en/html_node/Inferiors.html
<lfam>vats: Yeah, I understand that. But I'm trying to understand something more subtle
<lfam>If the thing being downloaded is not listed in your manifest, it will be subject to garbage collection
<lfam>Do you know if you collected the garbage since your last `guix pull && guix package -m ...`?
<vats>I see. Yes, I did collect the garbage.
<lfam>Gotcha
<vats>And the 2.6GB download is texlive-texmf, which is not in my profile.
<vats>Thank you.
<lfam>You can make a "gcroot" (a thing that is registered against garbage collection) by symlinking the store path to /var/guix/gcroots
<vats>If I add texlive-texmf to my profile, it would not be downloaded each time, I hope.
<lfam>For example, `ln /gnu/store/...texlife-texmf-version /var/guix/gcroots/texlive-texmf-version`
<Guest27>I'm trying to understand why `guix graph --type=bag lua` doesn't have Python dependency while --type=derivation has it
<lfam>vats: That would also work, because your profiles are also gcroots
<lfam>But, maybe in the future texlive-texmf will not be required to build your profiles, and then you would have to notice that change and adjust your manifest
<lfam>Both methods (the manual gcroot and adding the package to your manifest) will solve the problem of "big package got garbage collected and I need it again"
<lfam>Guest27: Did you check the manual section on `guix graph` yet? <https://guix.gnu.org/manual/en/html_node/Invoking-guix-graph.html>
<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
<lfam>This comment might help, Guest27: <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm?h=v1.3.0#n66>
<vats>lfam: Adding texlive-texmf to my manifest doesn't work because that package is not defined publicly (using define-public).
<lfam>vats: Then you'll need to set up the gcroot with the symlink
<vats>Yeah. Adding to manifest would have been a more neat solution. I might ask on mailing lists if they'd consider defining it publicly or if there's any other solution.
<vats>Thanks for the help.
<lfam>It's been a longstanding annoyance that has stubbornly resisted improvement :/
<vats>I could modify the package definition too, I guess.
<lfam>I'm not sure but I think this is the most recent discussion: https://lists.gnu.org/archive/html/guix-devel/2020-07/msg00062.html
<lfam>It would be useful to figure out why texlive-texmf is required by your manifest. Maybe some package could be adjusted to use the modular packages mentioned in that thread
<lfam>Texlive is another thing I don't know much about
<vats>lfam: texlive-texmf is an input to texlive.
<lfam>Right
<lfam>You have texlive in your manifest?
<vats>I do.
<lfam>That explains it :)
<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
<vats>I see.
<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
<solene>hello
<lfam>You can do `guix gc --references $(guix build --no-grafts texlive)`
<lfam>That was for vats
<Guest27>I found out that bash-mesboot and other things are not public packages that you can install or search via `guix search`. `guix graph --type=module` shows modules where those things are though
<Guest27>so for offline bootstrap I'd need to generate manifest importing those modules and mentioning things from `guix graph --type=derivation` I guess
<solene>it seems patches are registered in gnu/local.mk, yesterday I removed a patch and added another and I didn't touch it. I can't run "make" in guix now because I have a missing patch
<mothacehe>hey guix!
<solene>the manual doesn't give much information about this file
<rekado_>I suggest removing texlive and installing texlive-base alongside all texlive-* packages you know you need.
<tissevert>hello guix
<rekado_>this “freenode” takeover has removed all doubts.
<tissevert>no kidding
<rekado_>I wouldn’t have imagined someone making such an obvious strategic error, after all that has happened.
<tissevert>our new «official» chan is at ##guix
<leoprikler>super official :)
<tissevert>isn't it ?
<tissevert>that's really awful, they moved «us» there and allowed themselves to qualify it as «The community channel for #guix»
<tissevert>(yeah, I changed it)
<tissevert>do you reckon the new topic is clear enough or should I include the port ?
<leoprikler>Praxis :)
<bkilz>Hi!
<sneek>bkilz, you have 1 message!
<sneek>bkilz, mdevos says: "EDITOR=echo guix edit package", and open the file in your favourite editor
<bkilz>I can't run: ./pre-inst-env guix environment --help
<bkilz>I get: `guix: environment: command not found`
<bkilz>I can't run some commands using pre-inst-env
<bkilz>Anyone facing similar issues?
<tissevert>uhh no Oo
<raghavgururajan>Hello Guix!
<jonsger>hi
<bkilz>hi raghavgururajan o/
<jonsger>has someone a working setup where coredumps where saved? mine does not work: https://paste.opensuse.org/view/raw/51923415
<ss2>hello!
<ss2>I'm just trying out guix system init, and the manual says that it would install the bootloader to where the declaration says to put it into.
<ss2> https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-system.html
<ss2>unfortunately, that would be /dev/sda, where which is the host's own hard disk.
<Guest27>you need to change declaration to put it where needed
<ss2>just temporarely then, thought so too.
<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?
<civodul>cbaines: hey! i was looking at the unknowns at http://data.guix.gnu.org/revision/b84ead8c045f7921131dc66ab85ee1db3113607a/package-reproducibility :-)
<civodul>is it due to the missing notifications we discussed a while back?
***ArneBab_ is now known as ArneBab
<vats>Nevermind. I found a solution to my problem regarding sudo on the help-guix mailing list: https://lists.nongnu.org/archive/html/help-guix/2019-11/msg00170.html
<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
<roptat>tissevert, now they'll move to ###guix :)
<dstolfa>tissevert: at this point, might as well get rid of the freenode channel...
<dstolfa>can't say i'm surprised though
*NieDzejkob_ registers ###guix
***NieDzejkob_ is now known as NieDzejkob
<projectmoon>Did they take over the secondary name too?
<brendyn>Marked by a total eclipse here in Tasmania. hell is spilling over.
<NieDzejkob>they didn't yet, but I'm curious how they'll react if ###guix is taken
<roptat>lol, it was just a joke, more likely they'll take over ##guix and change the topic
<allana>Hi guix. Anyone know how to "import" a custom certificate authority? For example with p11-kit or otherwise?
<projectmoon>There's a script running
<ruffni>hello guix!
<tissevert>roptat: :D oh no ! no one saw that injection to ℕ coming ! what are we gonna do ?
<tissevert>yeah, getting rid of it could be a solution as long as we're sure it's not used against our community
<tissevert>need some way to converge, hmmm… «join us on #ℵ0.guix» ?
<dstolfa>tissevert: i agree, but can that even be guaranteed by staying there? after all... it was just taken over
<dstolfa>the only way this could be avoided is by making a public statement on guix-controlled media (website)
<tissevert>no, we have no guaranty, you're absolutely right
<ruffni>or have a bot regularly posting in there?
<dstolfa>"guix channel was taken over by freenode, please do not trust anything, etc etc"
<tissevert>why not
<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.
<dstolfa>mjw: hostile takover by andrew lee's bot
<dstolfa>nothing less, nothing more
<projectmoon>With the express intention of stealing the channel and being confusing of course
<mjw>aha, ok, that is sad.
<tissevert>…and this is why we've gotta keep it open just a little longer ^^'
<raingloom>ah dang, i think (gnu packages chez) is borked. i can't import it. tried on two machines with different channels, and in time-machine with just the default channel, got the same error.
<soheil> http://issues.guix.gnu.org/48260
<soheil> http://issues.guix.gnu.org/48414
<canant>Hi cbaines, I hope you're good. If you have some time to talk about SQL indexes, please let me know.
<civodul>cbaines: oh ok; so it's just that narinfo fetching is currently disabled?
<canant>cbaines I'm getting this error on private msg " You must log in with services to message this user "
<cbaines>canant, ah, I guess that means nick registration https://libera.chat/guides/registration I've also changed my user mode to allow messages from unidentitied users
<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
<Guest26>New irc home at last
***Guest26 is now known as telugodu
<guile-guest>test message
<taylan>strange, guile-guest can message here but not on #guile even though the channel flags are more or less the same
<taylan>(it's a kiwiirc connection from connecting via the link on gnu.org/s/guile/learn.)
<Guest13>i've been unable to do a guix pull for at least two months
<Guest13>guix pull: error: corrupt input while restoring archive from #<closed: file 7f6ad334c150>
<Guest13>full message: https://gist.github.com/apa512/dda835bafceb040257a001b452787aba
<Guest13>has anyone else had this problem?
<roptat>no it's working great here, but it seems you've hit a bug that is fixed now, but since you can't guix pull you're stuck with it
<roptat>I think the easiest solution is to pin guix pull to a specific revision until you manage to build it, like "guix pull --commit=2aa622c"
<roptat>then everytime you try, it'll be able to make some progress, until it finally succeeds
<roptat>once you're there you will most likely be able to guix pull properly again
<civodul>Guest13: right, like roptat says, you're running a version of guix-daemon that contains a bug fixed earlier: https://issues.guix.gnu.org/47157
<civodul>another option on Guix System is to roll back to a previous system generation, with a working daemon
<civodul>and from there, run "guix pull && sudo guix system reconfigure ..."
<Guest13>thanks, good to know it's a well known problem. i'll see if i can get it working.
<ruffni>i have "python" defined as an input to a package, but patch-shebang says: "warning: no binary for interpreter `python' found in $PATH". what did i miss? is it a propegated-input?
***ksroot is now known as KC1NCN
***ChanServ sets mode: +o civodul
***ChanServ sets mode: -o civodul
<guile-guest>test
<solene>test
<Guest13>i got it working with a system rollback. thanks for helping!
<efraim>ruffni: python provides the python3 binary. If you need want python as python3 then you need python-wrapper, if you want python2 as python then you need python-2
***KC1NCN is now known as ksroot
<ruffni>efraim: thanksalot!
<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?
<leoprikler>no, it's typically "no one has done it yet"
<leoprikler>you could be the one doing it if you want :)
<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"
<lfam>Try using specifications->manifest instead
<lispmacs>lfam: that makes sense, but I would need then I think help understand how to tie some things together:
<efraim>Wasn't it also (list transmission "gui")
<leoprikler>or specification->package+output :)
<lispmacs>(packages->manifest
<lispmacs> (append (list (first (lookup-inferior-packages inferior "linphoneqt")))
<lispmacs> (map specification->package
<lispmacs> '("abbaye" ... ))))
<lispmacs>you can see I'm using packages->manifest and specification->package in order to use an inferior
<lispmacs>could I just add (list tranmission "gui"( at the end of my packages->manifest list?
<leoprikler>assuming you have transmission bound correctly, yes
<leoprikler>also consider using cons* instead of (append (list (first ...
<lispmacs>efraim: (list transmission "gui") doesn't quit seem to work. It seems like guile wants something else instead of a string for the "gui" part
<lispmacs>I'm having trouble finding information on how to use specification->package+output in info manual
<lispmacs>i think i just figured it out
<lispmacs>yes, working now
<lispmacs>My current combination of appends, lists, and quotes are definitely not very elegant, but some crazy things get hashed together when you are busy caring for a family of preschoolers
<lispmacs>I'll have to smooth that out later
<Noisytoot>a bot has closed #guix on freenode
<Noisytoot>it closes all channels with "libera" in the topic
<roptat>the #hurd people have been smart, they changed it to "we moved to a well-known network" :)
<ssouth>Freenode in damage control I suppose.
<Noisytoot>You could also use "ʇɐɥɔ.ɐɹǝqᴉʅ.ɔɹᴉ"
<Noisytoot>It has caused many users to switch to libera, so it isn't a very good idea
<mason>Hey all. It was recommended that I ask here in case there's something being missed somewhere. https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/file-systems.scm#n1114 seems to be factually incorrect, as the goal there isn't compiling Linux with ZFS but just using a module. Has this come up previously?
<vagrantc>mason: facts are a bit complicated in the land of licenses, what is the free software foundation's or gnu projects stance on ZFS?
<vagrantc>mason: that's more likely the metric by which it should be evaluated
<mason>vagrantc: Hrm. I'd have to look to see if there's an organizational stance as opposed to individual stances.
<mason>vagrantc: But factually "the license terms don't allow for distributing it" shouldn't probably be said about a copyleft license.
<vagrantc>there is debated about the interplay of licenses, it is not a straightforward issue
<mason>vagrantc: There's a debate about what "derivative" means certainly.
<mason>Ah, there is a stance. Reading it: https://www.fsf.org/licensing/zfs-and-linux
<GNUtoo>Noisytoot: interesting
*GNUtoo used Freenode in the topic
<GNUtoo>and pointed to wikipedia
<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"
<nckx>Good morning Guix.
<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
<cbaines>I think import loops should be managable
<raingloom>or from anything later
<cbaines>loops in the inputs between packages will cause problems
<raingloom>cbaines: well, when i comment the chez import in gnu packages racket, i can import chez again
<raingloom>and it's an import issue, i'm not building anything. just running (use-modules (gnu packages chez)) or (load "gnu/packages/chez.scm")
<roptat>I think there are issues when using inheritance, say on a package from another module that needs this module too
<roptat>(I've seen that when I was working on maven/java modules)
<raingloom>cbaines, roptat: maybe the log will look familiar https://paste.debian.net/1198909/
<raingloom>the input script without newlines: (set! %load-verbosely #t) (load "gnu/packages/chez.scm") ,bt
<raingloom>guile just dies while printing the backtrace
<raingloom>well, in any case, i don't think i can debug this today and it doesnt look like there is an issue about it, so, time to make one.
<roptat>that doesn't ring any bell, sorry
<bone-baboon>I saw this and thought I would post it here as the Guix log in prompt says "This is the GNU system". <https://www.fsf.org/events/community-meeting-on-the-future-of-our-irc-presence>
<projectmoon>Freedom status!
<nckx>bone-baboon: We're very much part of GNU, so thanks for sharing!
<projectmoon>surprised that FSF doesn't run their own server
<projectmoon>For irc
<Noisytoot>projectmoon, <Noisytoot> Can the FSF host its own IRC network?
<Noisytoot><ggoes> i don't think we have the (staff) bandwidth to do that
<Noisytoot><ggoes> i'd also personally rather us be where other libre projects are and not off on an island
<nckx>I think the FSF sysadmins are fine with that.
<ggoes>it's not off the table. that was just my personal thought on it
<nckx>Fine with NOT having one, to be clear. That was directed at projectmoon.
<projectmoon>I think it makes sense to be with others yes
<nckx>I agree with ggoes on both points, also when folks suggest Guix should host one.
<cbaines>civodul, I think I had a breakthrough with the write to session port issue I've been having in the Guix Build Coordinator today
<civodul>nckx: thoughts on Matrix?
<civodul>cbaines: oh you were having that kind of problem?
<civodul>it's haunting us!
<cbaines>civodul, my theory now is that it's not related to threads, but the garbage collector triggers it https://paste.debian.net/plain/1198914
<cbaines>I've just written the reproducer, but it seems pretty solid
<civodul>cbaines: you're aware of <https://issues.guix.gnu.org/46330>, right?
<civodul>in Guix proper, we use a trick to work around that
<civodul>if you use guile@3.0.7 from Guix, you're also safe
<civodul>be if not, there's a risk
<cbaines>I was aware of that, but only because I knew it was causing Debian packaging issues
<cbaines>civodul, I'm using Guile 3.0.7 from Guix to run https://paste.debian.net/plain/1198914 and it's breaking
<civodul>argh, i'm tempted to stick my head in the sand
<roptat>civodul, that can't work long term, you'll need to breath pretty soon :p
<civodul>yeah, i'm afraid you're right :-)
<civodul>cbaines: i'm sending requests to your server!
<civodul>so far, so good
<cbaines>did the script crash for you?
<cbaines>it's never failed to break for me
<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).
<cbaines>(the few times I've run it)
<jackhill>I wonder if you can run other qt app?
<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
<pkill9>what's wrong with them?
<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
<pkill9>yea
<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
<tissevert>yeah I understand perfectly what's going on
<cbaines>civodul, and did that only happen after it "starting making garbage"?
<tissevert>and I call that a design fault
<vagrantc>the problem with xmpp is that people who are too excited about matrix will balk at it, and the problem with matrix is that the people who are happily using xmpp for ages will balk at it
<tissevert>(I'll balk at matrix even though I'm not using any of them ^^)
<vagrantc>heh
<dstolfa>*insert obligatory xkcd about irc*
<vagrantc>also an option!
***mason is now known as ChibaPet
<civodul>cbaines: no
***ChibaPet is now known as mason
<civodul>cbaines: but anyway, this is fixed at https://gitlab.com/gnutls/gnutls/-/merge_requests/1417 and can be worked around by catching it in the meantime (not great, i admit)
<civodul>cbaines: but note that libgc uses signals for inter-thread synchronization, so that can indeed lead to EINTR on syscalls, which can lead to GNUTLS_E_{INTR,AGAIN} down the road
<vagrantc>civodul: oh, very interested in getting that fixed in Debian too ... as it blocks using guile 3.x with guix in the Debian package
<civodul>vagrantc: the problem that blocked guile 3.x in Debian is another one :-) but it i posted workaround in the past
<cbaines>civodul, right, OK, that's how I spotted this, I was watching strace, and saw SIGPWR right when things went wrong
<civodul>vagrantc: and now Guile 3.0.7 can be built with --enable-mini-gmp, which which solves the problem altogether
<vagrantc>oh, it sounded so similar
<civodul>yeah both are about GnuTLS causing scary-looking problems :-)
<roptat>jackhill, okular works for me... I'll just test on a guix system
<vagrantc>ok, so i should nudge to get guile 3.0.7 into debian with --enable-mini-gmp ?
<civodul>vagrantc: definitely!
<civodul> https://reproducible-builds.org/contribute/guix/
<jackhill>roptat: interesting. Clearly there is a bug somewhere, but I don't know where.
<civodul>cbaines: i wanted to refer to the Data Service in the page above, but we'd need a URL like /revision/latest/package-reproducibility (or a separate "skin")
<cbaines>civodul, there is this URL http://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/package-reproducibility but as you noted earlier, the data isn't there yet
<nckx>Does Matrix *require* an account? I created one, but maybe that wasn't needed. If it does, that's a huge barrier IMO.
<dstolfa>nckx: matrix requires an account on a homeserver, not on matrix.org
<dstolfa>matrix.org is just one homeserver
<nckx>So ‘yes’.
<dstolfa>yep :)
<dstolfa>(i just said it this way because it's a common misconception, apparently)
<nckx>I knew it was federated, but in a way that's similar to IRC, which doesn't have that hurdle.
<cbaines>civodul, but I think having a different page that uses that data would also be better, as that could easily include other information
<civodul>cbaines: right; we can leave it as "future work", but i agree there's nice things to do here!
<civodul>nckx: re matrix, yeah, i've read about the "is typing" notification and that's a real misfeature
<civodul>(i'm typing, BTW)
<nckx>Hehe.
<civodul>as for clients, there's an Emacs client in Guix
<nckx>I know. I'm typing too! It's the principle of the thing (but the discomfort *is* real).
<civodul>yeah
<dstolfa>i think this is just a client thing, namely an element thing
<dstolfa>that's kind of why we need better clients...
<roptat>that must be part of the protocol
<jlicht>hey guix
<solene>I've read there is neochat that is usable and supports E2E now
<solene>I'm wrong: "NeoChat is still missing a few features to become a full-featured
<solene>Matrix client (most notably encryption support and video chat support)"
<dstolfa>:(
<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.)
<civodul>plus decentralization/self-hosting
<civodul>but... i've never tried it
<jlicht>'no need to learn the etiquette' smells like folks wanting to tackle social challenges with technical means ;)
<dstolfa>matrix is great in many ways, but i think XMPP is more of a thing that guix would work better on
<dstolfa>and i say this as someone who runs a matrix homeserver
<dstolfa>:)
<civodul>ok
<civodul>heh
<civodul>jlicht: it sounds like it, but isn't in this case: the fact that you're not supposed to paste snippets on IRC is kinda weird and bites every newcomer
<dstolfa>btw... one relevant thing might be that the only real viable client for matrix at the moment can't be included in Guix at the moment because evaluation of electron is still going on
<solene>so it's ok to paste 10 lines of text on matrix?
<dstolfa>so anyone who uses GuixSD won't be able to join with a desktop application
<civodul>heh, kind of a problem :-)
<civodul>we'd have a channel only for non-users
<civodul>solene: yes; i've seen that on Mattermost too (well, their web client)
<solene>why not xmpp?
<civodul>yes, why not, i don't know
<dstolfa>xmpp has very few downsides for free software projects
<dstolfa>it doesn't have all the fancy bridging of matrix, but it's not like we need that?
<civodul>in the end, i'm happy with IRC, just wondering if we're missing out on things that might be nicer for newcomers or somehow enable new things
<dstolfa>civodul: yeah... some people will always prefer irc, and that's fine. ultimately anything that is run aside from irc for newcomers can be bridged to irc.
<jackhill>The people behind cheogram, and especially the offer to host rooms for free software projects, https://cheogram.com/freedomware-muc/ , would be great people to answer questions about xmpp I think
<nckx>dstolfa: That's most important to me (but my opinion is just one). Not splitting the community. A lot of inspiration happens in chat & that includes lurkers.
<dstolfa>nckx: agreed
<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’.
<projectmoon>dstolfa: does guix not have electron?
<vats>nckx: I used guix package -m /link/to/manifest.scm to apply my manifest (with custom substitute-urls) which contains texlive. I did reboot my machine but haven't yet collected garbage.
<nckx>projectmoon: No.
<projectmoon>ok
<nckx>vats: .drvs are low-level build recipes and you can always ‘guix build <...drv>’, but they are small text files and won't save you any time or bandwidth.
<sharlatan>hi all
<nckx>vats: That is really... weird. I'd use stronger words if I was a Tex user and familiar with its particular build/ecosystem.
<vats>nckx: I just need that input in my store so I can symlink it.
<roptat>you can get it with something like "guix build texlive -S"
<vats>roptat: I tried guix build -S texlive but it says texlive has no sources. And guix build <...drv> does it. Thanks nckx.
<nckx>vats: But why is it deleted in the first place? That's not normal. You shouldn't need to do any of this if you're not collecting garbage.
<nckx>That said I do run my daemon with --gc-keep-outputs=yes --gc-keep-derivations=yes, which means ‘keep more roots’. Still, that should only affect *GC*.
<nckx>Hi sharlatan.
<nckx>projectmoon: TD;DR it's very, very hard to package.
<nckx>*TL; sigh.
<projectmoon>yeah, i know that much
<projectmoon>it was a pain in void
<projectmoon>although i was not involved with that 🙃
<sharlatan>I try to pack the last bit of ViralityEngine (Commmon Lisp game engine) - cl-sdl2, but build failed with this https://paste.debian.net/1198922/
<sharlatan> https://github.com/Hellseher/guix-channel/blob/main/ffab/packages/lisp-xyz.scm#L1844 package sample
<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.
<civodul>vagrantc: speaking of which, i just posted a patch to drop Guile 2.2 support: https://issues.guix.gnu.org/48685
<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.).
<nckx>I'm sure you forgot.
<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?
<leoprikler>Nothing
<nckx>vats: IME should help with this specific file as well!
<leoprikler>You simply put that site-lisp file into EMACSLOADPATH
<vats>I'm not sure what IME is.
<Noisytoot>Intel ME?
<vats>That's what came to my mind as well, but that doesn't make sense, yet.
<dstolfa>i'd assume "in my experience"
<vats>I see.
<ieure>Intel Management Engine.
<ieure>The corporate IT management backdoor stuff built into the silicon of every Intel CPU.
<nckx>Of course I meant Intel Management Engine yes.
<chikamungus>I'm not sure how I export EMACSLOADPATH in exwm
*nckx /s
<vagrantc>civodul: oh, that bumps the pressure up a bit on the switch to guile-3.0 ...
<leoprikler>chikamungus: You're hitting http://issues.guix.gnu.org/48223
<vats>Haha. Thanks for all the help.
<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
<dstolfa>don't forget that
<leoprikler>Isn't that kinda non-free though?
<nckx>We abide by the Kinda Free System Distribution Guidelines so it's OK.
<drakonis>kinda free eyyyyyyyyy
<drakonis>real talk though
<Noisytoot>Since Guix is free software, everybody now knows about the proprietary Intel® technology
<drakonis>it should be fine to send patches for supporting zfs on the system config, right?
<drakonis>also relevant, offering the vanilla kernel should theoretically be fine if it uses a debian-ish model where the nasty bits arent available for usage but not straight up disabled?
<chikamungus>thanks leoprikler. I guess I need to investigate .exwm
<nckx>drakonis: What's the difference? (Serious kvesh.)
<dstolfa>drakonis: re vanilla kernel, i don't think it is. it makes it easy to install non-free firmware by accident which i think is against the GNU guidelines?
<nckx>drakonis: AFAIK IANAL WTFBBQ ZFS is totes fine yes.
<dstolfa>nckx: mainline linux makes it trivial to load nonfree firmware
<dstolfa>linux-libre prevents all accidental loading of it
<nckx>drakonis: Remember that stuff like ‘Failed to load propgrbg4504E2.bin’ in dmesg is a problem already.
<drakonis>yes
<drakonis>right.
<drakonis>its generally because it is annoying to have to manually compile the vanilla kernel
<nckx>dstolfa: Which is why I don't understand drakonis's distinction between ‘not available for usage’ and ‘not straight up disabled’.
<nckx>The two are synonymous to me.
<drakonis>hmm
<drakonis>i meant that the firmware lives in a different repository on debian i suppose
<drakonis>its not shipped alongside the kernel
<dstolfa>drakonis: yeah, and that's why it's not endorsed by the FSF
<drakonis>i'm aware.
<drakonis>yeah.
<nckx>I've never used LL (not for the non-L bits; because I apply patches that track mainline). Guix makes it a total breeze.
<drakonis>except for having to wait it compile
<drakonis>but it is otherwise very easy to do it
<nckx>True.
<vagrantc>/23/23
<nckx>This is not the first time I have seen ☝
<drakonis>i've had people complain about vanilla kernel not being in the baseline tree
<nckx>what does that, vagrantc?
<drakonis>someone's trying to switch buffers i see?
<nckx>Ah.
<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.
<drakonis>time is valuable
<nckx>~ for Linux-Libre.
<dstolfa>i'm still not convinced about offering mainline linux in the tree personally
<dstolfa>linux-libre does all the things you'd want it to do to begin with for a free system
<nckx>solene: Few gigs is fine.
<dstolfa>i don't see why another kernel is needed
<drakonis>it matters to some users i guess
<leoprikler>I don't think there's even an argument to be had here. If you really want the mainstream kernel, seek out places that define a package for it.
<nckx>dstolfa: The discussion is purely hypothetical BTW. Mainline Linux won't be offered unless cats & dogs start doing some very disturbing things.
<nckx>Agreed.
<leoprikler>If you're worried about compile time, just trust some rando on the internet to not put any bad bits into it, surely nothing bad will happen.
<drakonis>yes i have that already
<drakonis>but its largely for dealing with people complaining about guix not having certain packages
<leoprikler>nckx: Or mainline puts all the nasty bits elsewhere and becomes linux-libre :)
<leoprikler>no, let's add rust instead
<vagrantc>leoprikler: that's what debian does, and it's not good enough for the FSDG
<leoprikler>wdym?
<drakonis>i dont particularly care about it myself
<dstolfa>nckx: makes sense, that's kind of what i thought, but thanks for clearing it up
<vagrantc>leoprikler: the nasty bits are elsewhere, but the ability to even load nasty bits is a sticking point
<drakonis>the fsdg has a very hardliner stance on things
<leoprikler>I'm not quite sure about that one, some say it's rather a technical limitations.
<dstolfa>i remember reading somewhere that linux-libre considers it a bug that one can't load proprietary things
<dstolfa>something about the interface
<solene>is it possible to display the download url of a distfile? When I bump a version number I want to download the file to verify checksum and update the file
<solene>but building the url by hand is tedious
<dstolfa>ideally, linux-libre would allow you to load whatever you want, but it would have an interface that asks you about it like 10 times before doing it
<leoprikler>Either way, if the mainline kernel also disabled nasty bit loading and instead required patching to enable it, that'd also work for me.
<dstolfa>to prevent any kind of accidental loads
<drakonis>i'm pretty sure it does that already
<leoprikler>what does what?
<vats>I'm running into a conflict while applying my manifest which contains both ecl@21.2.1 and guile@3.0.7. They both propogate different/conflicting entries for libgc@8.0.4. How can I resolve this?
<leoprikler>vats you might be interested in --with-input=
<nckx>leoprikler: Now you're describing Linux-Libre with a different logo.
<nckx>And minus the ‘bug’ that nobody cares to fix.
<drakonis>nasty bit disabling?
<drakonis>it isnt something like deliberately ripping chunks of code from the kernel to disable things
<leoprikler>nckx: That's exactly what I said earlier though. If Linux was Linux-Libre, but with the penguin logo :P
<dstolfa>:)
<dstolfa>that would be nice leoprikler
<nckx>Hah.
<nckx>Missed that.
<leoprikler>"and becomes linux-libre" was meant to be just that
<leoprikler>followed by "no, let's add rust instead" because we all know which is likelier ;)
<vats>leoprikler: I just looked into --with-input. Do you mean to suggest I replace libgc with some other version for one of the packages?
<leoprikler>yes, though perhaps the logic for that might be too complicated for command line usage
<leoprikler>(then again, since you're already writing a manifest, things are fine, because you have the full power of scheme)
<leoprikler>on a related note, why are we using propagation for those inputs anyway? this doesn't sound very guixy