<pkill9>maybe a custom alpine linux ISO could be used to initialise guix on a VPS automaticlaly ***chipb_ is now known as chipb
<genr8_>It actually was needlessly complex because of slight differences in the programs on alpine <genr8_>doh. i lost the modifications i made to the install script :/ <genr8_>there was a discrepancy in "adduser" and "mktemp" <genr8_>the init.d script for the daemon was also missing <genr8_>I seem to prefer foreign distros to the GuixSD distro , so alpine was a good base <jeko_>youhou I can ssh to my guix system vm from internet! <jeko_>do i need to install a specific package to run emacsclient? ***leo[m]6 is now known as lle-bout[m]
<apteryx>lle-bout: for long url I typically break them with a \ escape, continuing on the first column of the next line. <aaauser>on my computer, i want to update a library package and recompile all installed programs depending on it. is there any way to do this? I can make a package variant in my local channel with the update, but other packages still depend on the old version from guix. ***iyzsong-- is now known as iyzsong-w
<jackhill>(I don't have a good example at hand, unfortunately, so I think you'll have to be at the mercy of the manual ☺) <aaauser>Those work, but you have to use those options manually to build with the modified version. I was hoping there was a way to automatically rebuild them all as if the original library definition changed. Thanks anyway though. <aaauser>I think I'm probably going to try to clone and automatically patch a local copy of the guix repo. <jackhill>aaauser: yep, that's definitely one way, and may make the most sense depending on what you're really trying to do. There's also a way to do it with scheme code that you could use with a manifest. The documentation for which is evading me right now… <jackhill>ah: here's what I was thinking about. see the options->transformation procedure. You could then map the tranformation over a list of packages. <ryuslash>Hello :) I don't suppose anyone who's knowledgeable about the go-build-system is online right now? <jackhill>ryuslash: I once added the env var to it to set GO111MODULE=no to preserve the old behaviour when working on a go update, but I don't know if that's the sort of knowledge you seek. What are you trying to do? <ryuslash>I'm guessing it would be too simple to think that changing the variable you added to on and changing the union we make to tmpdir/pkg/mod/ would be enough to make things work? I'm guessing the problem with the go modules was that Go would try to download them during build? <jackhill>ryuslash: yay, improvement of the go build system would be most welcome! My feelings alight with Leo's last comment that it might be easiest to start with at new build system (of course looking at the current one). I think the problem is not even that finding the expertiese in the current build system, but expertiese in how go wants to do things post moduels. <ryuslash>post-modules? Are they planning to move to something else already? <jackhill>It would be intereresting to know if the minimal change you proposed would work, so that could be a good place to start. Otherwise, if you could document what needs to happen to do module-aware go building and share that on guix-devel@ you might find the needed help. <ryuslash>To be honest though, I don't know much about Go, I haven't tried anything with it I think since it was still in Beta or something <jackhill>ryuslash: no, I ment post-modules as in after the change to modules (where before modules existed, I would call it pre-modules) <ryuslash>I just really want to update Syncthing :) (and learn more about Guix) <ryuslash>thanks :) I'll try it and see if I can figure some more things out. <jackhill>a new importer for go was recently added, looking through the commit logs for the people who worked on that may be a good way to find other interested people <jackhill>ryuslash: cool. IRC is more active daytime European time as well <ryuslash>Yeah, I try to be online, but during work hours I'm frequently just too busy to even log on <jackhill>Amusingly, I worked on that one go upgrade becasue I was thinking about getting more into go, and wanted to start with a module-aware version, so I could learn the new thing, but I got distracted by other projects before really learning go… <ryuslash>yeah, I've been getting distracted a lot by other things and it's making me feel bad. I really do want to try and do this if I can. <ryuslash>I just have too many things I want to do :) <jackhill>haha I know the feeling. Hopefully it will at least be enjoyable to work on. <ryuslash>It's in guile at least, how bad can it really be :D I need more Lisp in my life <jackhill>lfam: we were just talking about https://issues.guix.gnu.org/45476 Vaguely, well, what a module-aware go build system would be like :) Although, I guess you said you were burt out on go for now, which is fine. <jackhill>I don't want to punish your other good deeds with more go thinking :) <lfam>Oh cool! I'll read the logs, but might have much to contribute on this topic <ryuslash>lfam: that would be cool, I'm still trying to figure out how things fit together and what needs to be done. so far I'm hoping that I can turn on modules and change the unioned directory to put everything under tmpdir/pkg/mod, assuming that the issue was that Go tries to download things during build and not something else. But other than that there doesn't seem to be anything that I can see so far that gives us a whole lot of control <lfam>I know that aptery has also been thinking about how to achieve this... maybe the two of you could compare notes <tissevert>still lost with this custom init system, herd: I tried to replace network-manager by connman in my config.scm, now I don't see any of them in herd and I still got nm-applet in my systray somehow ^^ <tissevert>I read gnu/services/networking, so the definition of connman but that doesn't really understand what is (not) going on <leoprikler>I wouldn't be surprised if nm-applet was somehow propagated by GNOME. <tissevert>but I don't see the network-manager daemon running <tissevert>either in herd, or even greping the output of ps <tissevert>and the applet looks fine, not reporting any trouble, handling its connections and all <tissevert>shouldn't it complain about being the lone survivor and missing the daemon ? <tissevert>dammit I was sure I had grep -i ! my bad, it's there <tissevert>ohhhh, I thought «networking» was a meta something with a wider focus, comprising several other services, all services providing it are named «networking» ? <leoprikler>it is, similar to how xorg-server <-> GDM if you're using desktop.scm, but can be anything else, that satisfies it <leoprikler>What I mean to say, is that nm probably doesn't export itself through any key but networking. <tissevert>well I still wouldn't know how to disable network-manager to test another networking daemon since removing the service from %desktop-services doesn't work <tissevert>do you all run network-manager ? if not, how do you achieve it ? <leoprikler>I personally haven't tried setting up connman, but perhaps your code is lacking something? <tissevert>it most certainly is, so I take it you're running network-manager ? <leoprikler>Needless to say, the values obtained from herd status match up with ps. <tissevert>what do you mean ? the name of the processes ? <leoprikler>'herd status <service>' gives you the pid of the process <leoprikler>[well, mostly, you can code services, so that it doesn't, but that's advanced trickery] <tissevert>ohh «Valeur d'exécution», that's what it means <tissevert>(I had directly skipped this line ^^ not understanding it) <tissevert>well I don't have much more time for that right now so I'll set the config back to «network-manager but not by accident» <tissevert>for the first time shepherd doesn't look like a scary black box to me ***apteryx_ is now known as apteryx
<vldn>hi :) is it possible to disable creation of Manpages while running guix system reconfigure? ***Kimapr1 is now known as Kimapr
***drakonis- is now known as drakonis
<civodul>rhou[m]: yes, try "guix show net-tools" <Ikosit>Is it possible to specify, that a package runs only on specific cpu architecturs and OS? <efraim>Ikosit: you'll want the supported-systems field of the package definition <civodul>kisaja[m]: hi! Guix is hackable so you can add support for your favorite init system <civodul>maintainers are likely to consider that maintaining one init system is already enough work, tho :-) <i1l>why maintain init at all? either upstream did supplied a unit file, or someone asked them to do so, or maked a package "service-this-thong". then make a 'union-services for oprenrc, runit, systemd, and shepherd. <i1l>after all, if someone uses non default init, that is not a maintainers, or Guix, but community (the exact users) issue. <i1l>who need them, those will make. no maintenance.. <i1l>and it will work as good as openrc in Arch. <lle-bout[m]>i1l: I would rather encourage people to use Shepherd (constraint) than have an easy systemd init system and nobody has incentive to improve Shepherd support <kisaja[m]>Ppl would expect guix to be atleast cool as devuan, we surely have brains to implement init freedom with less human power, btw we probably also want onion repo address. <kisaja[m]>We all know we dont want systemd instead of shepherd, but openrc souns cool <i1l>kini: > we surely have brains <i1l>speec for yourself, Noldor :D <i1l>openrc is worse i think, too. <i1l>used on Alpine. openrf upstream initscript was not designed to deal with subvolumes of btrfs. <lle-bout[m]>I don't feel like messing with the init stuff of GNU Guix is at my fingertips now, it's not as easy as you make it sound <i1l>.. so my mount options were not applied if i used a subvolume as /. <kisaja[m]>Ill probably try my best because of freedom and security <lle-bout[m]><kisaja[m] "We all know we dont want systemd"> I don't get behind the arguments against systemd FWIW, it's a good init system to me, just there's so much more to do with GNU Guile and the Shepherd vision I feel <i1l>last man tried to support systemd here seems disappeared. blackbeard? <i1l>sneek: seen blackbeard? <sneek>blackbeard?, pretty sure was seen in #guix 4 months ago, saying: hello guix! :). <i1l>no, alive. fake news. *i1l sees rekado's magic amulet. morale -100 <davidl>i1l: there is a systemd guix package floating around somewhere in the mailing lists, but maybe you're aware of that already. <kisaja[m]>I've seen systemd init in some video from the site, it drew me away from guix few times <maxxcan>one question. GuixSD will continue to support gnome? <davidl>maxxcan: I can't give an official answer, but, almost certainly. There is currently work on gnome40 <maxxcan>I like gnome but I don't like the Gnome Foundation. I am at a crossroads <davidl>maxxcan: would enlightenment suit your needs? I have used it on Guix before. There should be quite a few desktop environments that work fine. <davidl>maxxcan: whats wrong with the Gnome foundation b.t.w.? <maxxcan>But the Gnome Foundation sign the open letter againts RMS <maxxcan>I understand the free opinion of the people but not like foundation <kisaja[m]>At least they made a list haha, must package xenocara instead of xorg <i1l>davidl: it was an 1 April joke, afaik (the systemd) <maxxcan>yes Hyperbola use it like the default display server <maxxcan>the problem is that Gnome+GTK+SystemD all controlled by Redhat/IBM <i1l>maxxcan: consumerism w/o control is worse. Шляпа доин райт. betta than Mac/Win. <maxxcan>i1l: any choice allways will be better than win/mac <i1l>maxxcan: did thee seen KDE on laptops with narrow screen, with HUGE pop-ups w/o a scrollbar? <davidl>i1l: yes, but it actually works, or at least a later version of it. <i1l>*KDE: soon in Guix.. loading.. <davidl>i1l: hehe, yeah, or just guix-skills showoff ^^ <maxxcan>i1l: I want to try KDE but don't works on GuixSD for now <i1l>btw the letter against chief Gnuisance is a good thing. he is just a bit old, phisically. old leaders are bad ones. <maxxcan>i1l: the problem is that we haven't another options. RMS is old but his thoughts are corrects <raghavgururajan>sneek, later tell lle-bout: I think we could merge (after test-build) the gst patches to master instead of c-u, because, it indirectly enables A/V support in XMPP clients like Gajim. WDYT? <maxxcan>if you want to kick someone out, to do with correct arguments <i1l>maxxcan: nit kick.. it would be non inclusive. to retire :P *i1l nckx enters, with ol good chainsaw (model Trusty Thar) <i1l>maxxcan: бля, нах.. (better than this i use) <i1l>lle-bout[m]: > Running on the Hurd was always a goal for Guix, and supporting multiple kernels is a huge maintenance burden. <i1l>Thee right. burden is already unbearable, no more inits ;) <lle-bout[m]>raghavgururajan if they don't cause too many rebuilds sure we can look at that ! <lle-bout[m]>raghavgururajan still havent figured shepherd, GNU Guile issues are obscure to me, nonetheless I have yet to investigate better, got few ideas I couldnt pursue yet <i1l>> expected ... 1.1 release <i1l>btw, we need ask IBM for an Hat executive. Guix failing the schedule! shurely, a professional management and releases every 6 months would help. <i1l>Hurd planned at 1.1. now is 1.2, but Hurd is not a default yet. <lle-bout[m]>i1l: Don't expect Hurd to be a default until Hurd receives some significant changes <lle-bout[m]>i1l GNU Guix is not *failing* to release, we're going at the pace we can afford to go, but some project management would help, I heard plans about this it'll come along <leoprikler>corollarily don't extrapolate from April Fools ;) <kisaja[m]>Where can i see that strong message from site on april 1st <leoprikler>btw. don't do anything funny to #47458; I'm currently in the process of building a "more user-friendly" emacs <leoprikler>but I have to go now and let my machine compile in the meantime *leoprikler crosses fingers and hopes it works. <raghavgururajan>lle-bout[m]: Cool! Btw, I think we can divide and conquer in this way: I can take care of updating/patching packages from the chart. You can take care of updating stuff to make sure that the branch as whole builds. Sounds good? <i1l>kisaja[m]: (2.0-1.1) * time... medic! an executive feels bad! <raghavgururajan>lle-bout[m]: Also, if we get stuck on something for too long, we'll post it on the guix-devel thread for help/ideas. <cbaines>civodul, I don't remember exactly, but I think I encountered that with a fresh install of 1.2.0 <cbaines>I haven't attempted to reproduce the issue since then <efraim>does anyone have experience using guix and netbooting? <civodul>cbaines: yes but how is it possible, i wonder <clacke>TIL there has been a Guix Europe for half a decade <civodul>hey clacke! yup, it's a stealthy organization :-) <civodul>there are talks of finally having a web page <clacke>I used to use guixsd.org to go to the GNU page <clacke>now I learned that guix.info is the new one <efraim>If I want to use GUIX_DAEMON_SOCKET on Guix System I suppose I should just remove the guix-configuration service and add an environment variable <efraim>if guix by default has a daemon socket at /var/guix/daemon-socket/socket and I export /var/guix over nfs then I suppose I could point GUIX_DAEMON_SOCKET at "unix:/var/guix/daemon-socket/socket" <i1l>why daemon-socket is a dir? <efraim>I'm sure there's a reason once upon a time it was set that way <civodul>efraim: Unix-domain sockets don't work over NFS <civodul>the suggestion here is to talk to the daemon over TCP (on the LAN) <efraim>looks like we inherited daemon-socket as a directory <efraim>civodul: I have it open in front of me. I figured since I already had it over NFS I could try talking to it <efraim>I bet I could forward it over SSH or use munge, but TCP sounds much easier <civodul>yes, you just need to run "guix-daemon --listen=..." on the head node and set GUIX_DAEMON_SOCKET=guix://... on the other nodes <cdegroot_>that's a scenario where I'd be tempted to use AFS though, not NFS. <cdegroot_>(I don't like pulling software installations over network connections. Might just be me, got bitten too often in the past ;-)) <cdegroot_>efraim: the reason to use unix domain sockets is speed/overhead, nothing else. If you only need localhost, it's the quickest portable way and you don't need to deal with IP or even TCP overhead. <davidl>I sent a patch earlier today, should I just wait for someone to review it, or ask someone here with commit access? (I sent one in the past that never got a reply) <i1l>davidl: link? commiter usually dare to review, if that is not a cat in the bag deal. <i1l>post a link here as a bait for a commiter.. sometimes people catch fat ones <i1l>mine catch has 4 letters long nick. but they escaped. <Noisytoot>What's the difference between guix.info and guix.gnu.org? <nckx>Noisytoot: There isn't a hard answer to that. guix.gnu.org is currently more ‘official’. <nckx>But guix.info is older, IIRC, and also completely under project control. <davidl>nckx: I got that rpm package done yesterday, in the patch link I just pasted. <nckx>What's the criterion for which patches to apply? <davidl>nckx: yep :-) are you asking me that about criterias or general in the channel? <nckx>Just the (patches ...) in the above link. <davidl>aha. All of them that were inside the CentOS rpm. <nckx>TIL p7zip is the lightweight rpm alternative. o_O <nckx>Ah, because rpm pulls in Guile... <NikaZhenya>Hi, everyone, I now it is not officially supported, but I would be glad if someone point me where to dig for non-free firmware <efraim>does anyone have an example of NFS mounts in their OS config? <i1l>maybe instead of swarm the patches dir inside the git tree (srpm bundles many), can an guix invoke a `patch` inside the build in 47495? <nckx>NikaZhenya: Please ask such questions elsewhere, they are off-topic for all Guix help channels. <nckx>Use ‘patch’ instead of ‘git am’? <i1l>nckx: srpm has all the patches bundled. no need to copy them to the Guix tree. <nckx>I must say, I don't quite grok why the package does what it does. <i1l>i am about (patches field <nckx>What do you mean by copy? <i1l>aww, it is 'let. nothing. <i1l>i thought it is inside 'source.. <ennoausberlin>Hello. I wonder if there was a mongodb package. I can not find it anymore <nckx>ennoausberlin: It was removed because the last free version no longer received upstream security attention. <nckx>i1l: I'm going to try to rewrite it by parsing vsftpd.spec ourselves, instead of relying on a brittle hard-coded list of ‘all patches’. And hope to get rid of the git stuff too, although davidl probably had their reasons? <nckx>davidl: What does ‘el8’ signify in CentOS land? I'd like to factor it out as well, like CENTOS-VERSION, but don't know what to call it. <nckx>ennoausberlin: There was general mumbling after the fact and a consensus that next time, at least a news item announcing the removal is appropriate. <davidl>nckx: I know the package def is quite ugly. I am a guile noob, so this was a quick way to go about this. I was not aware of the patch procedure. The patches need to be applied in order written (there are multiple 0001-....patch files) - maybe the patch procedure can handle that if you also manage to read the patch-list in order from vsftpd.spec. <davidl>nckx: I was perhaps too eager to submit a patch, and should have worked on it longer. OTOH, getting the reviews is very helpful to learn more. <davidl>nckx: I don't know myself what el8 signifies <davidl>nckx: I wish I didn't have to put a let clause inside the replace 'unpack lambda procedure for the version variables, but didn't know how to make the more top level let provide variables for inside that lambda procedure. <nckx>davidl: That's all right! I noticed that Scheme was not your native language after asking those questions. The good news is that this means you can delete a lot of stuff 😉 No need to (let ((version ...))) again, for example, just use ‘,version’. <nckx>My psychic powers would have been more impressive had I hit Send sooner. ***Noisytoot is now known as noisytoot[x]
***noisytoot[x] is now known as Noisytoot
<clacke>civodul: no mean guix.info is the short one that redirects to guix.gnu.org saving me two keypresses <davidl>nckx: By the way, if this rpm package gets accepted: it may instead be better to extend or modify the 'unpack phase in gnu-build-system which looks at the suffixes, and do unpacking there. If there is a pattern in how the unpacked rpm package provides patches and the source-code tarball inside, we could perhaps make a more general solution for rpm-packages. <nckx>Meaning to impugn my own lazy use of SYSTEM; not your original, davidl. <davidl>nckx: for example; inside the rpm package there is vsftpd-<version>.tar.gz, which is perhaps standard place for the package source for rpm (I haven't checked), and the vsftpd.spec is probably standardized too like <package>.spec. <nckx>davidl: That's for sure a possibility. <raghavgururajan>If a pack-def has both snippet and patches, which will be applied first? <davidl>nckx: well bash is basically my native language, so personally I am ok with it :-) (but really, yeah it would be nicer to write the equivalent code directly in guile). <nckx>Yeah, that's the next step, but same so I have the bad habit of falling back to bash for prototyping. <nckx>raghavgururajan: I'm pretty sure it's patches. That would definitely make the most sense. Patches assume the unmodified source. <davidl>nckx: another or final consideration is that software heritage don't let you request storage of rpm's. <davidl>nckx: pretty much impossible to get rid of that habit ^^ <nckx>Bash is the Perl of programming languages. <apteryx>raghavgururajan: any idea why visiting "tel:XXXXXXXXXX" phone number URL wouldn't get dialed in linphone? The .desktop file it installs is supposed to enable that. <raghavgururajan>apteryx: Hmm. Works on my end with icecat. May be missing XDG stuff somewhere? <apteryx>I see linphone as an application to open the link, but then nothing happens <apteryx>OK, good to know that it's not just me :-) thanks for checking <apteryx>raghavgururajan: i've found out that it works if I add a sip: URI and specify which proxy to use (e.g., sip:XXXXXXXXXX@my-proxy-url); there's a discrepancy between the UI (does that for me) and the CLI (doesn't). <apteryx>leoprikler: do you still see value in https://issues.guix.gnu.org/45316 ? I'm not sure I do. The affected packages were very rare IIRC; our original idea to fix them up on a case by case basis still sounds like a better idea than introducing extra complexity. There'd be many packages to adapt for the reintroduction of a subdirectory too. <apteryx>It's nice to have this clever option ready to test should the problem become serious though! <lfam>Wow, that's really great! <lfam>Indeed, we (the Guix project itself) will have to put more effort into this kind of thing going forward <nckx>Also: I'm considering applying to that, because, c'mon, $, Nix. <apteryx>civodul: just sent a rebased version of the append-separator? patches; it's for core-updates, haven't retried it there but the resolved conflicts were simple to resolve, so I'd expect it to work as it used to. ***to-hu1 is now known as to-hu
<rekado>civodul: let’s do that and pay 2800 EUR ;) <efraim>Actually it'd be a better deal to front them 280 years of Guix Europe membership <civodul>rekado: sounds like a great idea :-) <civodul>"The program is set up to train up to 30 participants", woow <lfam>Indeed, it's a really significant <civodul>we need to cheer Pjotr so we can do 10x that :-) <civodul>(we'd also need to recruit mentors, oops!) <link2xt>anyone using official debian sid or testing package here? <link2xt>I installed it with apt-get install guix <link2xt>but installed binaries are not available in the PATH <link2xt>I added the following lines to .bashrc: <link2xt>GUIX_PROFILE="$HOME/.config/guix/current" <link2xt>but for some reason there is also $HOME/.guix-profile, and symlink to installed packages goes there <rekado>link2xt: there are two locations that Guix uses <rekado>link2xt: the profile at .config/guix/current is for “guix pull” only <rekado>this is convenient because you can use Guix on the installation of Guix itself <link2xt>yes, there is my updated guix which I pulled with guix pull <rekado>e.g. to roll back to a previous version etc <rekado>the ~/.guix-profile location is where *you* install packages with Guix. <rekado>so you need two things: ~/.config/guix/current/bin should be first on PATH (so that you can use the freshest “guix” command), and the variables defined in ~/.guix-profile/etc/profile need to be set <rekado>so in ~/.bash_profile you should also have “GUIX_PROFILE=$HOME/.guix-profile” and then “source $GUIX_PROFILE/etc/profile” <rekado>don’t worry about GUIX_PROFILE being used a second time; the variable is not exported, but it is checked when sourcing the etc/profile file. <raghavgururajan>rekado: I often get hint to set "GUIX_PROFILE" after guix package transactions. But I use guix system. Shouldn't be exported by default? <rekado>link2xt: the hints that Guix prints about these two profiles can be a little confusing. I know I have been confused by them before, and I should definitely know better :) <rekado>raghavgururajan: when new variables appear in etc/profile your *current* shell session will not automatically set these variables. <link2xt>probably makes sense to explicitly say that it's ok to have two similar snippets in whatever order in .bashrc <rekado>raghavgururajan: that’s why the hint exists; to tell you that if you want to use the new software right now in this session, you’ll need to update the variables <rekado>link2xt: yes, I think a sentence acknowledging the potential confusion would be good there. <rekado>Guix as a sub-process of your shell cannot change the variables of its parent. <rekado>raghavgururajan: one could think of an overengineered “GNU Screen”-like setup, where the shell is the child of a long-running Guix process that will modify the shell state. <rekado>but … that’s probably not a good idea to pursue <link2xt>from the UX point of view it's probably ok to put things in some profile.d and just ask the user to logout and login again <lfam>Bad news: The newest release of WebKitGTK depends on newer versions of a bunch of packages <lfam>Oh wait, I misread the errors <lfam>It does fail to build, nevertheless <lfam>"libmanette is required for ENABLE_GAMEPAD" <lfam>I'll try building without this feature <lfam>We can always add it later <i1l>then it would fail because "gamepad's vibrator" needs libvib. and when HP going down, the thing SHOULD vibrate. yes, in browser. <lfam>I'm not sure I understand <lfam>I don't think we have libvib packaged <i1l>99 bugs on the wall. take one down. 4 234 890 999 little bugs on the wall. fix a feature today, then it will need another _ENABLE later.. <lfam>I don't see a reason to believe that <lfam>I just didn't know what they were talking about :) <i1l>vagrantc: remember FREEZER on aarch64? thing broke anyway, later. features. <i1l>honestly, i dont know what is more disturbing. be calling a bot, or in plural? both sucks. <roptat>and it didn't really sound like a bot, I found it a bit obscure, but somehow it made me smile ^^ <lfam>Yeah, I use "they" for people I don't know <lfam>Sorry if it sounds weird to you <lfam>sneek: later tell i1l: I use "they" for people I don't know. I'm sorry that it made you feel bad <vagrantc>wow, the first message from i1l that i could understand appears to have been a ragequit <lfam>I googled "libvib" and there doesn't seem to be anything relevant <vagrantc>did almost seem like a bot to me ... i've seen bots that assemble semi-relevent messages from mailing lists that ... almost seem like human ... but almost not <lfam>I think there was a language barrier, vagrantc <lfam>But also some messages there were... less than serious <roptat>I think it was all just a light joke, but we didn't understand <vagrantc>the FREEZER comment was probably a reference to a bug maybe we had both worked on ... <lfam>Well, hopefully they come back <vagrantc>yes, hopefully they-singular come back :) <roptat>I know it was supposed to be a reference to "99 bottles of beer", but it made me think (and listen again to) 99 luftballons <vagrantc>as if we're not huge multicellular cooperative colonies of organisms <lfam>In English, what I said makes the most sense. But I'm sure that for people who think in other languages, it must have sounded weird <vagrantc>lfam: apparently, they-singular in some parts of the world is insulting ... roughly similar to being called "it" <roptat>well, you don't learn singular they in school <lfam>It's not easy to choose another word, vagrantc <lfam>It's why I left an apology via sneek <lfam>roptat: That's interesting. It's completely common usage in the US, unless there is a clear indication of gender <roptat>lfam, I only learned about singular they very recently <vagrantc>the "mainstream" way of dealing with unknown gender is typically kind of insulting too ... e.g. assuming one identity or another <lfam>I know that people have decided to attempt to make it controversial but they are bullshitting <roptat>more or less when joining guix actually ^^ <lfam>It's like, "Who's car is blocking the road? I hope they move it soon." <roptat>and many languages don't have that notion, so it might be difficult to understand the notion of a gender neutral pronoun <lfam>"When will the technician arrive? I hope they know what they are doing." *vagrantc speculates there is some knee-jerk reaction to some people explicitly identifying with "they" as a pronoun <lfam>Yeah, I think that's part of it <vagrantc>anyways ... i should get some work done :) <vagrantc>oh dear ... guix in debian is marked for autoremoval ~2 days before it the fix will migrate ... e.g. ... no guix in debian <lfam>I don't understand why they would do that after all your work <vagrantc>there was a change in process for this release cycle that maybe had unintended consequences <vagrantc>the security bug on guix-daemon is fixed in debian/unstable, but the version in testing will get removed on april 16th, and then will be blocked from migrating <vagrantc>hopefully i can convince them to bump the migration delay fast enough <lfam>For a distro that is assembled in such an ad-hoc way, I hope they would be flexible about this kind of thing <lfam>Although I understand the value of deadlines and process, too <leoprikler>apteryx: w.r.t. 45316 the fix I'm trying to push (not in git terms, at least not yet) is mostly backwards compatible – i.e. it shouldn't matter if a package doesn't use a subdirectory at all <leoprikler>what does change are hardcoded paths for packages, that now install to subdirectory, which is to be expected <leoprikler>in particular, we still use EMACSLOADPATH to detect site-lisp, but none of its subdirectories <leoprikler>Adding direct store paths should also improve UX in the 47458 sense. <oreoking[m]><roptat "maybe you're not using gdm?"> I dont use login manager <oreoking[m]>This probably has to do with the fact that guix does not use systemd <roptat>right, then you're missing something that creates a session (through elogind I think) <roptat>not sure how it's done, but gdm (maybe other login managers) automatically run it <roptat>we don't use systemd, but we package some components because they are required to run gnome and other stuff <roptat>it's supposed to be a drop-in replacement <roptat>I should stop answering on IRC just when I'm about to go afk ^^' <civodul>vagrantc: ouch! the security issue is a short patch against the C++ code base, maybe they'll agree to just apply it? <civodul>what do they do if there's a libc security vulnerability the day before release? <vagrantc>civodul: either delay the release or upload a fixed package through the security updates <vagrantc>looks like i nudged the right people and it should be fine, fwiw *nckx barging in somewhat contextless; apologies: does this have anything to do with not having a CVE, vagrantc? <nckx>Always has [for logind-type stuff]. <nckx>Some people told me that Debian wouldn't apply security patches without a CVE number, which was too weird to believe. <vagrantc>civodul: oh, the other option is, of course, to remove said package :) <nckx>Don't :) that you madperson. <roptat>I'm back, sooner than I thought ^^' <vagrantc>civodul: obviously with libc ... not an option <nckx>If it ‘needs systemd’, then: not, but that's a big if. Are you sure it ‘needs’ systemd? <apteryx>has anyone ever seen: 'fatal error: charconv: No such file or directory' on a #include <charconv> ? <leoprikler>you can replace instances of libsystemd-login by elogind <roptat>I saw "User has no sessions" and "Couldn't find an active session or a greeter session", so I assumed logind? <apteryx>ah, it's supported only from GCC-8.1. Hm. <leoprikler>see weston for a package, that has elogind substitute*d in rather than providing it OOTB. <roptat>oreoking[m], I'd open an issue on pkill9's repo and wait if you don't feel like fixing the issue yourself :) <apteryx>is adding a newer gcc to the native-inputs sufficient to have it used as the compiler? I was assuming not, but some packages seem to get away with it. <leoprikler>apteryx: charconv is C++17, so if you compile with an earlier std, it probably fails in such a manner <roptat>apteryx, I think it only works because the implicit gcc is added after explicit native-inputs to the $PATH <roptat>or maybe it's even that assoc-ref only finds the explicit one if you use the same name <oreoking[m]><leoprikler "substitute* is your friend :)"> wait subsitutes are just prebuilt binarys <roptat>oreoking[m], we're talking about the procedure that you can use in a recipe, not the substitute mechanism in Guix (confusing ^^) <apteryx>roptat: I see! Thanks for clearing my doubts. <leoprikler>In any way, it's a feature that many Guix packages already depend on, so it's unlikely to change ;) <leoprikler>I wonder if you could do the same in other build systems like python 🤔️ <apteryx>leoprikler: it already compiles with -std=gnu++17; I guess I need a newer GCC <nckx>Thanks! As it happens, I was just reading yours. <nckx>Totally unjust random review queue anarchy strikes again. <apteryx>rekado: did I read that we can replace jack-1 by jack-2? *raghavgururajan is mighty pissed with GitLab <raghavgururajan>Freezes the icecat and whole system (not talking about CDN/cloudflare issue) <raghavgururajan>Damn it! It was another gitlab instance. My browser+system froze again. *raghavgururajan opens link in surf *civodul merged wip-build-systems-gexp in core-updates <raghavgururajan>Wow! Surf handles JS better than Firefox. What does it say about software design and code quality? <leoprikler>it seems based on webkitgtk, does it ship it's own js engine? (i doubt so) <leoprikler>either way, gitlab has no issue with our webkitgtk-based browsers (like epiphany) <leoprikler>civodul: w.r.t. garbage collection, how costly would it be to track references in more than one encoding scheme? <civodul>leoprikler: "very" is what comes to mind :-) <civodul>it'd be a pretty fundamental change to the GC *and* grafting <civodul>but really, i'm sure we can get SBCL to store literals as ASCII, UTF-8, or whatever rather than UCS-4 <cbaines>civodul, woo, congrats on getting the build system changes merged <civodul>cbaines: thanks! the support you and others expressed helped me cross the finish line <civodul>i'd like to think it's not my fault but... <civodul>i'll check what the Data Service thinks of the branch <leoprikler>btw. what is needed to get a wip-* branch on savannah? <leoprikler>can I just push to one without oversight, should I inform someone ahead of time, ...? <civodul>leoprikler: you have to apply and at least 5 committers must vouch for the branch <civodul>leoprikler: yes, you push it and you announce on guix-devel what it's about <apteryx>and most importantly, you clean it up after its done/abandoned/x :-) <leoprikler>'twas a joke, because the gnome wip branches have to my knowledge not been cleaned up <apteryx>I may have a brain fart; but... do propagated inputs of inputs used as native-inputs of X end up in a user profile when the user install X ? <apteryx>what if I s/native-inputs/inputs/ in the above sentence? <leoprikler>apropos inputs vs. native-inputs, do we have a (core-updates) plan on resolving this weirdness <leoprikler>only inside propagated-inputs it should be propagated further <malik>im trying to define a new guix package, and if i dont have the sha256 line i get an error missing field initializers (hash) and if i include it it extraneous field initializers (sha256) ? I'm sure its something obvious, but I'm building off the seeminlgy offical hello package example <leoprikler>malik: the sha256 bits should go inside the origin 