IRC channel logs


back to list of logs

<zpiro>antipode: don't be weird, especially for crypto.
<antipode>This is all interesting, but I don't think it has anything to do with the expiring (test-only!) certificates in openssl and such.
***A_Dragon is now known as Awoobis
<zpiro>It may be relevant or it isn't, but it is a better practice to do things like what you would expect banking people in their pipelines do. Because you can be sold a laptop that wouldn't be allowed by major powers if it could be used to spy on banking.
<zpiro>I'm not saying it is practially possible, but by virtue, not inviting such possibilities from timing events. It may be bad enough that it is guile.
<zpiro>no need to remind anyone the bandwidth availvble in L0 and L1 cache on 3 ghz processors operating on 512 bit data per cycle per core.
<lilyp>I'm pretty sure those bankers with their highly secure Windows XP machines have heard of cache template attacks.
<zpiro>for anything crypto, do it as if you work for a bank and can trust services from your own customers.
<zpiro>and for open ideals, think about being quicker and shorter.
<zpiro>because it is tight and strict, data inn and out of microps is secure, as being slow is staitstically caught on what you want to do.
<zpiro>most crypto and certificate CVE involves side leaks, and the underlying concern is exactly this.
<zpiro>optimal and fast, you can count cpu cycles and be sure that compromising arithemtic isnt possible based on amount of rounds required to break things like AES.
<nckx>You clearly haven't a clue what antipode was talking about. Please stop spamming the channel with your incoherent and irrelevant ramblings.
<lilyp>To add to that, I doubt you even have a clue what you yourself are talking about.
<zpiro>"zpiro: mbakke: A 'detect certificates' phase sounds nice to me, though I think it needs to be an error, not a warning, otherwise it seems too easy to merely disappear in the logs to me."
<zpiro>nckx: care to clarify?
<nckx>You should have asked that first, not spew of twenty lines of irrelevant gibberish.
<nckx>They have left.
<zpiro>nckx: I answered the question and still here, what do you mean? After having it references.
<nckx>You did not answer the question, you just strung random words together.
<zpiro>23:34 < zpiro> checking the weather, scheme is great for homework, tied to early adopters with acqquanties of newphe of author of book of pf.
<zpiro>The weather say fewer spies, nckx.
<zpiro>I belive, and have since a long time, that there is a future in guix for science. And that is my weather.
<ae_chep>installing something that has rust as a dependency does take some patience, gosh
<zpiro>ae_chep: yeah, that is fascinating! And time required to bootstrap all of it seem to involved being caught aback. No, or serious CVE that demands hours on end improving and moving on to later versions.
<zpiro>Rcently many versions are released, and just wokrining through a minal set neded for the latest version and keeping with it until major software changes that dependent on it solves that conundrum.
<zpiro>and is a lot of compute and compile power to work on it to fix your typos.
***jess is now known as jess-o-lantern
<zpiro>most of core interests does not involve rust, and 99/100 know it is is not their respoonsbility to cover the need.
<pkill9>why have all my icons in gnome-shell decided to bork?
<pkill9>even though they're in XDG_DATA_DIRs
<pkill9>specifically application launcher icons
<ae_chep> zpiro: core interest? typos? I am a bit stupid. I lose my focus reading sentences with that many words, I'm sorry.
<zpiro>ae_chep: most bugs doesn't matter - if rust support is dragged along for the things required. On the other hand, if not interested in building rurst, can you write this in C, so I can avoid this bug in nftables? At least this works, in spite of bit errors likely still in your kernel. you find my script by following around, for me and openwrt.
<pkill9>found the culprit, celluloid
<one>isn't that missing a maintainer?
<pkill9>found the problem, celluloid has icon cache in it's package
<one>also, side question, is cheese the same thig as celluloid or am I confusing packages?
<pkill9>no, celluloid is a frontend for mpv
<one>oh ok
<ae_chep>zpiro: I have to build rust because it's a dependency of a tool I'm trying to install. I don't understand. Do you want me to replace rust with C in a software I'm simply a user of?
<one>Are the rust packages incomplete? Or do you need to compile to remove things you don't need?
<cyberkefir>hi guix!
<ae_chep>no I was simply commenting that it takes quite a bit of time trying to install things that have rust dependencies as they take a while
<one>ae_cheap, isn't that the beauty of free/open source? You can shape your own things if you have the fortitude and follow through
<one>well, maybe its the substitutions?
<cyberkefir>i have a question about guix service - what is "(inherit config)" in guix-service-type definition?
<one>no subs if implemented might kick it up a notch
<pkill9>glad i have my icons back :3
<one>Curious if anyone in here has anything critical to say about SystemCrafters? I've used it a bunch, and I like it. Probably my go to actually.. Would love to hear if anyone is sour on it or has any particular thoughts
<one>oh, just thought of a random qustion. where in the hell does the black theme store?
<one>I am blanking on he actual pkg, but I always think Back In Black
***nckx is now known as nckhexen
<pkill9>what is systemcrafters?
<zpiro>ae_chep: nah, it was more that there is alot of room to build less, have it run faster, and perhaps offer later version for use by those maintaining what you need. But yes, it is slow and takes a long time, especially for guix. if you have a fast machine you can do it better with trial and error.
<pkill9>apparently it's a community rather than somehting you use
<zpiro>ae_chep: that it works and build is at the core of things, and those that buy into it can get so busy doing it that nothing get written about it and no experience shared.
<one> is just a couple Emacs/Guix tutorials that helped me in the past. Thought they were the easiest to follow from a noob standpoint. But I may have also missed some things. Was just curious to hear others thoughts if they had seen it. On youtube too
<pkill9>how do you enable wayland for gnome-shell?
<pkill9>well, gnome-desktop
<pkill9>no, on guix system
<ae_chep>zpiro: I still don't understand but that's okay. I am simply interested in installing a piece of software. But if you know about packaging tricks that make it better please submit some packages for rust packages :)
<ae_chep>anyway, I am out \o
<one>Its been a minute since i actually used the system... I thought there was an issue with a conflict and unprovisioned packages though... as if you need to install wayland while removing xorg components? Does that sound familiar to anyone else?
<zpiro>ae_chep: that is a general problem for guix, you can be scheme dyslexic and write code. But at the end of the day you need copy pastable examples from those that work with on a daily basis. As long as you are still building you are likely find, and will certainly get help if it is crashed hanging out here for rust and your tool.
<one>I can see what you mean, and get it bc Im clearly noobish. But, I was really drawn to the project bc whatever difficulty arises in assembly or build, maintaining and replicating afterwards are easier I think.
<one>Like reallocating frustration up front so you can sail smoothly(or smoother) later.
<pkill9>I think you can get away mostly with knowing only a surface level of guile
<zpiro>pkill9: yes, I agree, but guile dysleic has become on a joke on par with perl dyslexic whithe the share amount of books covering perl and recipies for how to do useful things every day tasks.
<zpiro>and that more users just really need to have neough to find for copy paste solutions as not covering it all can't be done.
<zpiro>aerh, porely written. copy paste and howtos neded, and community required. More so than books like those covering perl and general tasks and needs.
<zpiro> I wrote that in 2016, and would need to copy paste as sometimes and more often, what you need cant be done programatically. While this should build what you need to analyse and simulate data from major LHC experiments.
<zpiro>If you are a good sys admin you work yourself out of jobs for someone nicer to take over - less of a bastard operator from hell.
<zpiro>guix allow you to do it out of time, to stamp the state of affairs with a git commit and a file. and certainly for a development initiative.
<zpiro>didnt know it at the time, but apprantly, the only way to get to IRC from CERN is from a gateway at one of the primary LHC experiments.
<pkill9>how do you enable wayland for gnome-shell?
<lechner>one: daviwil spoke at the ten-year event
<nckhexen>Lies are not allowed in this channel.
<zpiro>pkill9: if you want to be secur, the orld and tursted is a better starting point. But x11 applications in wayland should not be a porblem.
<whereiseveryone>nckhexen you caught me in the lie, I admit it ;)
*nckhexen shocked!
<zpiro>pkill9: defaults are usually better, but there is a sickening amount of concerns around copy paste and mouse capture around x11 - not likely to be as strict around wayland.
<zpiro>but generally, terminal applications work.
<zpiro>one of those slippery slope unless someone spends time on it.
<zpiro>guix has a pass store interfance, but yeah, it is terrible. highly attratice future development to play with. But as it defaults it should come with realistic convictions about safety of copy paste.
<zpiro>or that is, if you ask to experiment, share and give feedback. have fun, if it just that wayland is cool and you have other things to focus on, just walk away.
<pkill9>rekado: I got gnome-calendar to work, it requires evolution-data-server to be installed
<zpiro>there are lots of shell application terminals that may cater to the needs of active users, gnome-shell... there are so many alternatives that if you are using sway or anything other than gnome og kde you find something better rather quickly without the adoption of broad considerations.
<zpiro>most would go to suckless and tmux, and find that most needs are covered.
<zpiro>for the cool kids do this and consider kde and gnome as cruft around pitful terminal application offerings.
<zpiro>and this goes far back, most people using gentoo were not using gnome or kde, but it was and is popular.
<zpiro>it is generally not good questions that lelader to answers for these ecosystems.
<zpiro>so gnome-shell or xterm, or hsitoric rants from xscreensaver about nobody ever being abloe to do better to prevent leaks and incorrect screen, keyboard and moasgrabs.
<zpiro>A fine rant about not needing your app to run on a library you wont work with if you not supported and offered by default.
<lechner>zpiro: you are still taking to yourself. maybe you can find a local linux user group? there are a lot of good social opportunities around the world, especially on weekends. start something new tomorrow!
<lechner>zpiro: sports are also good. i like swimming, biking and medium-distance running
<zpiro>lechner: look, you speak a lot of nonsense here and go on and on by things as if you have a special position and persective that everyone needs to be belssed with. Can you show me, or just shut up?
***ChanServ sets mode: +o litharge
***litharge sets mode: +q $a:zpiro
***litharge sets mode: -o litharge
<jgart[m]><rekado> "does anyone here want me to..." <- I want you to review my rust packages. I have to send them first
<pkill9>I can't seem to open gnome-maps from the gnome-shell application launcher, but I can launch it form the terminal
<lilyp>pkill9: IIRC the launcher uses a different command, so you might want to check if that's properly wrapped
<tsvallender>Is there a Guix equivalent to Debian's build-essential package that will install gcc, make etc?
<unmatched-paren>tsvallender: Well, there is ``gcc-toolchain'' for GCC, binutils, etc
<unmatched-paren>but it doesn't include make or anything
<unmatched-paren>so no
<tsvallender>Okay no worries, thank you
<klm_>When I run `guix build kdenlive`, I get "waiting for locks or build slots ..." but nothing is is happening. `hurd restartd guix-daemon` doesn't help. any pointers?
<pinoaffe>hi guix! I want to be able to install guix to another disk using my running guix installation - would it be sufficient to add (and start) the cow-store service when adequate? or am I missing something?
<pinoaffe>the cow-store herd-service is currently not exported btw, so I'd have to use @@, but I don't think that would cause problems
<apfel>is there some problem with qt oder kde related packages? if i want to install okular it will be always build from scratch and does not use substuitutes. Event though i run my own cuirass which is building okular...
<apfel>even on the host running my cuirass instance will rebuild okular when i run "guix shell okular" in this machine. The funny thing is, after building okular on the cuirass host using the guix command line i can use this new substitute on my client machines. Any ideas?
*klm_ rebooted, and that solved the problem...
<unwox>klm_: just wanted to report that i built kdenlive successfully
<tsvallender>I'm getting error: make: unbound variable when adding that to my packages in my config, but I've added (use-modules (gnu packages base)) which looks like where it is. What am I missing here?
<unwox>tsvallender: try gnu-make
<tsvallender>unwox: Thanks! How should I have known that? Where should I look for things like that in future?
<unmatched-paren>tsvallender: ``guix edit make'' probably
<unmatched-paren>``make'' likely conflicts with something else i guess.
<tsvallender>Ah okay, thanks :)
<unmatched-paren>``gettext'' is bound to ``gnu-gettext'' because ``gettext'' is a procedure for localization
<unmatched-paren>for example
<tsvallender>That makes sense
<tsvallender>I just thought that meant the name of the package in the listing would be gnu-make, but I'm still acclimating to the whole Scheme thing, so I think I get why it's different
<klm_>unwox: thanks. It's building now for me too after I restarted. I was doing clever tricks like C-z to suspend build processes before, maybe that's what caused the problem.
<unmatched-paren>Ahh, yes, the discrepancy between "bound symbol" and "package name" can be confusing at first
<unmatched-paren>(package ...) both returns a package record and adds the package (under the name given in the ``name'' field) to the list of packages available in the UI
<jpoiret>unmatched-paren: Ackchyually, (package ...) doesn't really add anything (ie no side effects), it's just that the specification->package commands scan all of the exported symbols from the gnu/packages/*.scm modules
<jpoiret>they use a cache created at guix pull time to speed up the results, it's all in gnu/packages.scm
<unmatched-paren>jpoiret: Huh, okay, that makes a lot of sense. I was wondering how that was done even though ``package'' is just a record constructor.
<nckhexen>klm_: Did that actually do what you wanted? I'd expect it to suspend the foreground ‘guix’ client, not the build. Although builds would eventually stop when all running ones finish.
***Dynom_ is now known as Guest2902
<xd1le>hi guix
<unmatched-paren>xd1le: hello!
<Not_Leader>xd1le: also hello
<xd1le>btw the join message still says to use bordeaux
<xd1le>as in still says under maintenance
<Not_Leader>wait what's bordeaux
<unmatched-paren>Not_Leader: there's a server farm in bordeaux, france
<xd1le>substitute server
<unmatched-paren>so we just call it bordeaux, like how we call the main one berlin sometimes
<Not_Leader>guix has more than one sub server?
<Not_Leader>i did not know that
<unmatched-paren> is in berlin, is in bordeaux
<nckhexen>xd1le: <the join message still says to use> You are 100% error free. Whoops. Thanks.
<Not_Leader>tbh i thought ci was in massachussetts
<Not_Leader>or however you spell it
<nckhexen>We don't have any boxen that side of the big wet, I think?
<xd1le>nckhexen, yeah not the channel topic, idk what to call it but the message that message that ChanServ gives I guess
<xd1le>s/that message/
<xd1le>s/that message//
<unmatched-paren>Not_Leader: why'd you think it was there? :)
<Not_Leader>i have no idea
<nckhexen>I know. The entrymsg. It's the one I always forget to change, and the one I always forget to change back.
<Not_Leader>probably the lack of a .de domain lol
<unmatched-paren>nckhexen: Ah, okay, I didn't know exactly where in teh Murica the FSF was headquartered.
<nckhexen>I mean, they graciously provide us with Savannah, Debbugs, multiple e-mail lists, and probably something I forgot, but we just don't have any Guix hardware there.
<unmatched-paren>but yeah, the guix community seems to be largely centred in western europe
<Not_Leader>unmatched-paren: me in the middle east
<xd1le>cool, I'm from down under :0
*nckhexen likes learning folks' TZs, just wishes they could remember 'em.
<nckhexen>Oh, sorry: I'm from the boring Western-Europe contigent.
<Not_Leader>* Not_Leader wonders what the origin of this is
<Not_Leader>wait that doesn't bridge right does it
<unmatched-paren>Not_Leader: the * name does things thingy is done like ``/me ...'' in an IRC client
<unmatched-paren>I have no idea how it would be done on Matrix, if that's what you're using (given "bridge")...?
<Not_Leader>/me test
<pkill9>lilyp: which command does it use?
<Not_Leader>okay backslashes don't work
<Not_Leader>!me test
<Not_Leader>okay i think i'm flooding
<pkill9>lilyp: which command does it use?
<nckhexen>Not_Leader: /me is it, something just made it not work.
<nckhexen>Which is weird, because I've used in on Matrix before?
<nckhexen>Not_Leader: You can test in PM if you like.
<unmatched-paren>I'm in the UK, which is obviously also Western Europe, though many here would prefer that not to be the case :P
*Not_Leader oh wait
<nckhexen>*Now* you're an adult.
*xd1le claps
*Not_Leader wonders what the origin of /me is
<Not_Leader>no i am still very much 16
<unmatched-paren>Congratulations on graduating to Real IRC User. :)
<Not_Leader>without even using irc
<nckhexen>(This was your first-ever message, right? What a beautiful journey.
<chungy>The command originated with IRC. I don't know if it was there from the very beginning (IRC came out in 1988...), but it's been there as long as I can remember.
<Not_Leader>also would it be theoretically possible for guix to manage flatpak generations?
<Not_Leader>oh right
<Not_Leader>that was when i was actually using an irc client
<nckhexen>Oh :(
<nckhexen>A backward journey is also a journey 🌈
<nckhexen>(Nah. Be welcome here! I've used Matrix before, it's… something that exists.)
<Not_Leader> that message was a reference to this i think
<nckhexen>Not_Leader: I don't see any technical arguments on why it couldn't be made to do that. It's more likely to be considered out of scope or turn out to be gnarly code, than impossible.
<nckhexen>We're not against Flatpak but it is not Guixy by nature.
<Not_Leader>i'm guessing it'd need guix ostree integration somehow
<nckhexen>I could see it ending up in guix home eventually, possibly through a ‘community’ channel like whereiseveryone or so.
<Not_Leader>yeah i think i asked here if there was a guix-home flatpak service yesterday
<nckhexen>Not_Leader: Oh, I was just thinking of monolithic store items, nothing fancy like that. Hence the unguixy part: it would be managed by Guix, but not actually use any of the Guix software distribution.
<Not_Leader>> With Flatpak, each application, runtime and extension is a branch in a repository. An identifier triple, such as is a reference to that branch. The output of a Flatpak build process is a directory of files which is committed to one of these branches.
<Not_Leader>> like this "repository" thing just sounds like a store
<Not_Leader>and i keep on getting quotes wrong
<Not_Leader>though yeah integrating guix with ostree somehow seems like the first requirement for a flatpak service
<Not_Leader>> systemd to set up cgroups for sandboxes
<Not_Leader>i'm assuming this is also done by elogind?
<nckhexen>Probably Shepherd.
<nckhexen>It's not a 1:1 systemd:Shepherd mapping but that sounds like a Shepherd job.
<nckhexen>By which I really mean, Guix system service, which are the sheep.
<unmatched-paren>anyone here using the mako daemon who could review my home-mako-service-type once it's done?
<florhizome[m]><Not_Leader> "i'm guessing it'd need guix..." <- If you don't need it to be in the Store it should be easy to make a Home service that automatically updates your flatpaks , saves some metadata maybe, etc.
<unmatched-paren>would this be a decent configuration schema for home-mako-service-type?
*nckhexen reading man 5 mako
<nckhexen>I don't have a bot in this specific fight, but it seems like this can express any valid mako/config one could imagine? That's good. The home-make-options look clunky but (1) I'm not used to reading guix home code, maybe that's what it looks like (2) if that's the price for being complete, sure.
<unmatched-paren>yes, that was the main concern i had
<nckhexen>(Actually I lied about the fight: I was bitten yesterday by a service that can't express basic upstream things, otherwise probably wouldn't have responded :)
<nckhexen>I like that concern 👍
<florhizome[m]><dirtcastle> "I care abt it. the next thing..." <- Do you have the packages?
<florhizome[m]>For me the part where i stopped was that sourcehut needs ja packages that it would fetch from node but it cant in guix
<Not_Leader><florhizome[m]> " If you don't need it to be in..." <- i was thinking a home service that integrates flatpak's generations with guix-home generations, and can also manage flatpak packages
<florhizome[m]><iyzsong> "um, emacs-guix doesn't work..." <- This is about an Update in geiser that deleted the company support. There is an issue about it on the guix-emacs gitlab, we should be able to Patch it out by deleting that line
<mekeor[m]>hello. opening this website, makes my icecat crash on guix system. do you share that experience?
<florhizome[m]>Not_Leader as long as you don't need the store and it's things you can do by the cli it could Just be a Home service
<florhizome[m]>mekeor i actually have been using gnome web recently since icecat is very Bad Out of Date and i sit on staging and certain third Party Channels don't Work for me
<nckhexen>mekeor[m]: No crash here. Do I have to do anything?
<mekeor[m]>florhizome, i see. i use the master-branch. it has 102.3.0 packaged
*nckhexen erfahrt mehr…
<mekeor[m]>nckhexen: no, it happens just after opening the link
<nckhexen>This is 102.3.0.
<nckhexen>With an empty (=no) profile.
<nckhexen>You could try shutting down all instances & moving ~/.mozilla out of the way, just to check if it's something configuration-related.
<mekeor[m]>thank you, nckhexen. i'm unfortunately still on 91. i'll upgrade. thanks for checking :)
<nckhexen>> i use the master-branch. it has 102.3.0 packaged
*nckhexen confused.
<mekeor[m]>i did not upgrade yet :D
*mekeor[m] runs 'guix upgrade icecat'
<florhizome[m]>nckhexen: Could that have been a pretty recent Upgrade maybe
<nckhexen>There was one recently, yes, but not from 91!
<florhizome[m]>9x i had in mind
<Not_Leader>nckhexen: but not from 135200152767840296255166568759495142147586866476906677791741734597153670771559994765685283954750449427751168336768008192000000000000000000000?
<Not_Leader>and i replied by accident
*nckhexen dives into the git log to check.
*nckhexen doesn't use IceCat 👀
<mekeor[m]>nckhexen, which browser do you use?
*mekeor[m] disables all addons of the freshly upgraded icecat
<nckhexen>No, you're right: ‘[description]: "IceCat 91" --> "IceCat 102".’ Huh. I had no idea it was so far behind. I'm assuming ESR, because anything else would be spooky, and it's only the 1st of spooktober, we need to ramp up gently.
<nckhexen>mekeor[m]: Just Firefox.
<nckhexen>With dubious stuff like wasm disabled as much as possible.
<mekeor[m]>nckhexen, yes, esr
<nckhexen>Good, good. So it being ‘recent’ now is more of an anomaly in general.
<mekeor[m]>neither 91 nor 102 are official releases of gnu icecat afaik
<nckhexen>No, Guix is special in that regard.
<mekeor[m]>60.7.0 is last official release
<mekeor[m]>exactly. it's also commented in the package-description
<nckhexen>Right. It's not like we're yolobuilding our own random git commit either. It's a weird situation. But the best possible in theses circumstances. Guix is lucky. And that's all I know about IceCat.
<elaexuotee>Should I be prefixing "[PATCH]" in the subject line of patches? My issue doesn't have the "patch" tag:
<nckhexen>elaexuotee: Git (send-email, format-patch, etc.) does this.
<abhiseck> seems dormant, last commit is 1 year ago
<abhiseck>Is someone else maintaining it?
<nckhexen>It's not mandatory, that's why guix-patches@ is its own thing, but it can help people who just read mail, so if you don't mind adding it, please do.
<davidl>this unsupported manifest format error was fixed, but, what range of commits in the time-machine must I avoid? Could we have a warning pop up when using guix time-machine that Im about to travel to a commit that doesn't work.
<elaexuotee>nckhexen: Cheers. My patch is created with format-patch, but I've been manually composing messages. Guess It's time to try using send-email.
<nckhexen>I've tagged it ‘patch’.
<mekeor[m]>abhiseck: iirc, emacs-guix was taken over / forked by the guix-project. iirc, it's complicated
<nckhexen>It wasn't hostile.
*nckhexen ~> work.
<mekeor[m]>nckhexen: the above mentioned website works with icecat@102, yippie
<nckhexen>Hurrah! Guix banks the unbanked. o/
<pkill9>anyone know why chromium doesn't show up as an option to set as default application for web?
<pkill9>on gnome shell
<abhiseck>I found the emacs-guix repo on savannah I want to submit a bug fix patch, which mailing list to use?
<unmatched-paren>abhiseck: probably just
<unmatched-paren>but you might want to prefix the subject of your patches with [emacs-guix] or something
***Noisytoot_ is now known as Noisytoot
<abhiseck>unmatched-paren: thanks!
<unmatched-paren>abralek: Aha: ``git send-email --subject-prefix="PATCH emacs-guix"''
<unmatched-paren>will output ``[PATCH emacs-guix] ...''
<ae_chep>Does a failure here mean if I attempted a build myself I'd guarantee getting a failure?
<unmatched-paren>not necessarily
<unmatched-paren>it might not be reproducible
<unmatched-paren>e.g. there might be a problem to do with microarch-specific tuning
<unmatched-paren>Could we have an ``file-include'' procedure in ``(guix gexp)'' that looks like this?
<ae_chep>I was going to complain about how kak-lsp isn't building. Turns out I packaged it
<unmatched-paren>is it okay to make the default value of a service configuration field *unspecified*? because i seem to remember there being a very long discussion on that
<abralek>unmatched-paren: Yes, you are correct )
<unmatched-paren>abralek: on what? :)
<abralek>unmatched-paren: As I understood, you accidentally sent a message to ME, but the 'aha moments are important', so I confirmed )
<unmatched-paren>Ahh, right, I see now :)
<unmatched-paren>abhiseck: Aha: ``git send-email --subject-prefix="PATCH emacs-guix"''
<Not_Leader>ae_chep: so are you going to complain to yourself
<unmatched-paren>Ugh, that "me" guy is such a loser. :P
<a12l>Does the Emacs IRC channels still exist? Can't find any information about them on Emacs' website. And Element (Matrix) doesn't allow me to use the search command to search for channels on
<unmatched-paren>a12l: pretty sure #emacs still exists
<unmatched-paren> <- yup
<a12l>Weird, doesn't show up when I try to find it in Element, but no problem finding this channel :-/
<Not_Leader>a12l: it doesn't?
<Not_Leader>and i replied again
<a12l>Not_Leader: Nope :/
<a12l>unmatched-paren: thanks
<Not_Leader>did you set your homeserver for searching as
<a12l>Don't know
<a12l>But it's the first Libera channel that I can't find
<a12l>I've joined around ten channels on Libera, and I haven't had any problems finding the channels using Element's room discovery interface.
<Not_Leader>a12l: it works if you set the search homeserver to
<a12l>Found it by filtering by homeserver.
<a12l>Thanks Not_Leader!
<a12l>rekado: Can you link Hinzen's talk about using GT as a Guix UI?
<a12l>Know that he has worked on some Guix stuff from the GT disc, but haven't seen him posting anything there about it lately
<nckhexen>What's GT?
<nckhexen>You mean this?
<nckhexen>(It's Hinsen, just to help you search.)
<Not_Leader>is there a guix-devops channel?
<nckhexen>Nope. I think the other channels in active use are #guix-hpc, #guix-riscv, and #guix-offtopic.
<nckhexen>This is #guix-anythingelse, and also more of the same (none of that stuff is off-topic here, except for, uhm, -offtopic).
<nckhexen>* -risc-v, excuse me.
<sektor[m]>Morning, Guix.
<unmatched-paren>Hi :)
<a12l>nckhexen: Thanks! GT is an abbreviation for Glamorous Toolkit (
***tsv is now known as tsvallender
<sektor[m]>Thinking of contributing an accessible installer to Guix. Working on building an image with necessary modules enabled.
<sektor[m]>Then I need to go write the espeakup service.
<ae_chep>when guix complains about no free space, where exactly does it want the space (in a foreign distro). I am checking my `df -h` and I have tens of gigs of empty space
<Not_Leader>the partition on which /gnux/store is located
<nckhexen>ae_chep: We can't answer unless you show the error.
<ae_chep>which is `/` and I have "43G avail"
<Not_Leader>i'll back nckhexen here
<ae_chep>nckhexen: `guix upgrade` failed at "telegram-desktop" with a warning saying it may be due to a lack of free space.
<nckhexen>sektor[m]: Cool! I didn't know speakup was still alive, albeit through a soft wares.
<nckhexen>No no no. Please share the actual error, not a paraphrase :)
<ae_chep>yes yes, I'm getting there
<nckhexen>Good good.
<nckhexen>Is your /tmp in RAM?
<nckhexen>Foreign distroes often do that, and then you run out of RAM.
<ae_chep>I attempted a `guix install telegram-desktop` and saw the same error. I then bzcat'ed the error and saw lines like "{standard input}: Fatal error: CMakeFiles/Telegram.dir/SourceFiles/history/view/reactions/history_view_
<ae_chep>reactions_selector.cpp.o: No space left on device"
<ae_chep>Okay, yes it is likely due to tmp. that makes sense
<sektor[m]>Yeah, I started by packaging it a few months back, got aggrivated by changing the kernel, and got generally distracted by life.
<nckhexen>So… I can see two ways around this: not mounting /tmp as tmpfs, or setting TMPDIR in the *daemon's* environment (so .service, if systemd) to something else.
<nckhexen>Something not on tmpfs.
<nckhexen>Maybe /var/tmp/, or /var/guix/build if you want to get creative.
<nckhexen>Be sure to set the same permissions (sticky bit et al), there might be security concerns otherwise.
<nckhexen>sektor[m]: Changing the kernel for this?
<sektor[m]>It needs two modules:
<sektor[m]>CONFIG_SPEAkup = m and CONFIG_SPEAkup_SOft=m
<nckhexen>Oh, I read that as changing the kernel code, not just configuration, ne'er mind.
<nckhexen>That can certainly be upstreamed, although it shouldn't be aggravating to do so yourself. Sorry it was.
<sektor[m]>Yeah that is my idea for a Hacktoberfest project.
<nckhexen>(Guix isn't on GitHub so we can't get you swag, but maybe we could arrange something.)
<lilyp>pkill9: look at the .desktop file
*sektor[m] is presently looking into how to operate make-linux-libre
<nckhexen>sektor[m]: Did you see the blog post?
<sektor[m]>I might have it in my elfeed.
<nckhexen>I don't think things have majorly diverged since then.
<pkill9>ty lilyp
<pkill9>ah yeah special launcher, interesting
<pkill9>it launches with `gapplication org.gnome.Maps` or something
<antipode>If someone is interested in an OpenTTD network game, please contant #guix-offtopic for details
<pkill9>has there been any work getting kotlin into guix?
<sektor[m]>Whatis a proper string for the extra-version keyword?
<lilyp>pkill9: yeah, you have to either patch org.gnome.Maps or the desktop file
<nckhexen>sektor[m]: Whatever you want. "-sektor" for example, but don't discount "" — do you really need an EXTRAVERSION?
<sektor[m]>No. I was looking at the cookbook and noticed it there.
<sektor[m]>So wasn't sure if it was a common archetectural thing.
<pkill9>crazy freedesktop things
<pkill9>why does it not just run gnome-maps? what is the puprose of gapplication
<pkill9>what are all these org.* things
<pkill9>which flatpak does as well
<lilyp>reverse domain name
<lilyp>gapplication seems to allow binding actions to applications, which is "more powerful" than simply launching them
<nckhexen>sektor[m]: It is purely informational, no effect on anything but the version string (5.19.0-my-awesome-kernel).
<sektor[m]>Okay, running a build on it now.
<sektor[m]>*I think, at least; ,build hasn't written anything back yet.
<unmatched-paren>pkill9: re kotlin, there appears to be some crazy gradle <-> kotlin bootstrap loop
<unmatched-paren>along with the issue of "kotlin is written with kotlin"
<Andronikos>On the link under package points to a 404.
<civodul>Andronikos: noted, thanks!
<unmatched-paren>Hello civodul :)
<civodul>howdy unmatched-paren!
<Andronikos> is the new one
<civodul>yes, i fixed it locally and will push later
<Andronikos>How would I configure unbound? Did not see anything related to it in the docs.
<Andronikos>Can I still use services like httpd if I use Guix on a foreign distro?
<lilyp>Andronikos: you can install the package as root, but you'll have to configure it by hand
<civodul>lechner: just read your message about the golden takins, wonderful! :-)
<old>Does someone know a way to allow a build container to access `/dev/dri/*`
<old>I have a package that run test with rocm-runtime that needs access to the GPU
<lilyp>old: --share?
<old>lilyp: But is there a way to share the `/dev/dri` folder for building a package?
<old>I don't see any way of doing so currently
<lilyp>I don't think so; that kind of package wouldn't be reproducible anyway
<jeko92>Yo Guixters !
<jeko92>My Emacs complains and crash (installed via guix home on a fresh guix)
<jeko92>« /home/jeko/.guix-home/profile/bin/emacs: symbol lookup error: /home/jeko/.guix-home/profile/bin/emacs: undefined symbol: rsvg_handle_set_stylesheet »
<lilyp>jeko92: your rsvg package might be broken, you can try to guix build --repair it
<nckhexen>You can also get out the big gun that is ‘sudo guix gc --verify=contents,repair’.
<sektor[m]>Built the kernel; time to throw it on an image.
<sektor[m]>Here's hoping ti worked.
<nckhexen>The kernel's store output will have a /.config file, if you want to sanity-grep it.
<jeko92>lilyp: yeah I did try to repair emacs haha but I miss to think to try to repaire rsvg (aka librsvg?)
<jeko92>nckhexen: Will try that if guix build --repair fails (hopefully it won't)
<nckhexen>jeko92: Well, it shouldn't fail (that would be a separate issue), but I'd feel better in your case if I scanned my entire store for corruption (which is what that gc command does). You stumbled upon one by accident, and you might be ‘lucky’ that it's the only one, I can't say. It's up to you.
<jeko92>Damnit! So I will fire the gc just before going to bed haha
<jab>lilyp: I wish librsvg didn't take ssoooo long to build
<jeko92>haha finger crossed
<jeko92>in fact I know it takes a pretty long time with my hardware
<jeko92>plus it needs to download a loooot of rust libs
<davidl>anyone who has a functional guix time-machine --commit=<somemonthsoldormore> -- package -i some-package ?
<davidl>I only get unsupported manifest format errors
<jab>serenityOS's libWeb has svg support:
<spacecadet[m]>anyone know a way to limit network namespace with guix environment --container? looking for something akin to doing --net=enp1s0 with firejail
<nckhexen>I don't think there's anything more granular than --network (no, no arguments) for now.
<nckhexen>Manual seems to agree…
<spacecadet[m]>bummer, will have to bank on that "for now", thanks
<nckhexen>(Minor, but you might want to get used to typing ‘shell’ instead of ‘environment’. It won't be deprecated overnight but you don't want it slipping into scripts etc.)
<spacecadet[m]>thanks, didn't know about shell
<nckhexen>It is almost drop-in compatible, but not quite: ‘guix environment thing-I-want-to-build --ad-hoc extra-build-tool’ becomes ‘guix shell -D thing-I-want-to-build extra-build-tool’.
<nckhexen>But otherwise it's the same thing underneath, with the same options.
<spacecadet[m]>absence of --ad-hoc was the first thing I noticed, this syntax makes a lot more sense anyways
<nckhexen>Yeah, that was the consensus. RIP environment (some day).
<nckhexen>Oh, just one more detail: IIRC --ad-hoc was ‘everything after this’; --development is a ‘this one next package’. So the short form may be very welcome.
***ChanServ sets mode: +o nckhexen
***nckhexen sets mode: -q +q!*@*
<nckhexen>…that just looked like a typo.
***ChanServ sets mode: -o nckhexen
<nckhexen>Hm. Shall we? I guess we must.
***ChanServ sets mode: +o nckhexen
***nckhexen sets mode: -q $a:zpiro
***ChanServ sets mode: -o nckhexen
<nckhexen>Insulting anyone will be a ban.
<podiki[m]>all this talk of guix shell, reminds me I gotta finish the requested revisions on the fhs container option
<podiki[m]>(despite using it locally)
<nckhexen>podiki[m]: Is it finished®?