<lf94>gov.uk offers a URL shortener? <lf94>I'm new to guile / scheme in general, and this terrifies me. <nckx>Make sense. gov.uk/learn-about-covid -style URLs are quite common in campaigns. <lf94>In other languages like TypeScript and Rust, sure there are plenty of imports, but I build them up one-by-one as I need them and look at documentation <lf94>Is this the same case here? <nckx>What makes you think this is different? <nckx>For Guix packages, ‘guix show <foo>’ shows the module name. <Sharlatan>When I pack I just go from missing inputs and add required modules <nckx>(srfi srfi-1) is like [but not] stdio.h in C: you just know, after a brief while. <nckx>Yeah, Guix will try to suggest missing package modules, although it's best-effort. <Sharlatan>by the way guix is lacking good warning system on which module is required sometimes it has good suggestion sometimes it needs more time to search manually <Sharlatan>I can't say right now, I'll probably collect them in one issue <lf94>Oh I didn't know it tells you what's missing <lf94>Most software doesn't tell you sh-t :) <lf94>I will have to try packaging one of my projects as a first experiment. <lf94>I was actually thinking how come we have a "guix interface" for cargo but not npm? Or maybe I missed over the part where it said we do <nckx>Doesn't every language suck? :-) Guile's Achilles' heel is its [lack of] good error reporting. Enjoy your backtrace, buddo. <nckx>lf94: npm is basically impossible to package. <lf94>So why do we try with crates / cargo? <lf94>I mean it's ok if it's just an experiment <nckx>lf94: Because that actually seems feasible. <lf94>I'll read that after supper :) Thank you! <nckx>And without Rust no software in 10 years, so... <Sharlatan>do not start with NPM debian just dropped support completely of all node.js and Go packages ;) <guix-noob>so, to make my suspending fix permanent, I guess I need to execute a shell command as root every boot. What's the proper way to do this in Guix? am I right to say I need to make a new service in config.scm? <nikita`>lf94: there's some notes on npm in the mailinglist archives, at least prior to 2019 <Sharlatan>guix-noob: on Gnome Guix there is no any issues, wake up on mouse move, key press is by disgne (at least was for 10y on Fedora Gnome) <nikita`>people gave it multiple tries and attempts and packaging npm modules is just pandoras box as a jigsaw puzzle or something <raghavgururajan>leoprikler: Could you reverse the commit 5da7b2d05092829f922512a0674810f3895d88b3, the build failure has been fixed. <leoprikler>is that the one that commented materialdecoration from telegram-desktop? <xelxebar_>vim-full is failing to build from dd5e879c for me: ld: /gnu/store/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.a(pyexpat.o): undefined reference to symbol 'XML_FreeContentModel' <leoprikler>I'm currently a bit busy, but I'll add it to my imaginary TODO list. Does Oleg frequent IRC? <leoprikler>raghavgururajan: building rn, but I'm tired, so I'll go to bed *raghavgururajan is already on bed <pineapples>I'm building all three telegram-related packages, including telegram itself, with the #:strip-binaries? flag set to #f to, hopefully, put an end to the WebRTC crash <pineapples>Well. There's more than three packages but you get the gist—I'm only building these that are connected to the crash <procra>does some one know if the status on the rx 4xx or rx5xx graphics cards has changed on guix scince version 1.0? <donotshake[m]>In general those are more driver specific. Guix has the video-amdgpu which is the free driver for amd graphics cards. You could also use the proprietary one with a little more work. <terpri>my guix only has xf86-video-amdgpu which is loaded by default. the kernel driver is blacklisted by linux-libre and won't work with linux-libre even if you install the firmware <terpri>(or maybe "blacklisted" is the wrong word, but it definitely refused to load any firmware last time i tried) <terpri>for recent amd gpus to work, you'd have to use the (non-libre) linux kernel and the standard linux-firmware repo (both of which are insufficiently free by guix standards) <awb99>In my docker image the root user works fine. But additional users don't have environment variables setup. How can I get gyix to add all this config files for the other users? Any ideas? <dftxbs3e>awb99, the docker image runs GNU Guix System? <dftxbs3e>I don't think there's any simple way for this, maybe if you create the users in the operating-system definition <awb99>I do create the users in the operating system definition <awb99>For the root user everything gets added automatically <awb99>But for newly added users not. <dftxbs3e>awb99, this is handled by gnu/system/shadow.scm <dftxbs3e>awb99, do you regenerate the docker-image using a different operating-system definition to try out different users? Also how do you get a shell as these users? Do the files .bash_profile etc. exist in these user's home? Does the home exist already when the account-service creates the users? <awb99>So for root it creates /root with all the bashrc files <awb99>For the additional user it creates /home/username automatically <awb99>However this dir has owner root <awb99>And no profile config files there <awb99>I have installed bash package <awb99>I am generating the entire docker image from guix <awb99>I can docker exec to root user <dftxbs3e>awb99, can you send what "ls -lGha" returns when within a user's home directory? <dftxbs3e>awb99, can you send your config file so I can fiddle with it? <awb99>I am rebuilfing the docker image right now .. this takes 30 Minutes <awb99>Testing with empty Passwort now <dftxbs3e>awb999, operating-system things are handled by gnu/system.scm relative to GNU Guix git repo, also reading there <kondor>Can I skip package checks while building an image (guix system vm-image ...) <dftxbs3e>kondor, you mean tests? what checks exactly? <dftxbs3e>awb999, is shepherd running when you start the image using docker? <kondor>And whats this with system vm-image ... --dry-run reporting completely different results before and after doing a 'guix gc'. The weird thing is it wanted to build much less *after* the gc <dftxbs3e>kondor, disabling tests for all packages is not something GNU Guix can do, and package transformations don't work with GNU Guix System AFAICT. Basically disabling tests is not universal for all packages and when it is standard basically it modifies the hash of package derivations so.. can't you use substitutes? <dftxbs3e>kondor, re different results: can't say without more context <kondor>dftxbs3e apparently there is no substitute for python 3.8.2 <awb99>@dftxbs3e: i will check for shepherd when my image Is rebuild <dftxbs3e>awb99, it may be that docker does not start shepherd and users are actually made once the image is being run by shepherd services <awb99>@dftxbs3e: thanks! Good point! <dftxbs3e>awb99, where do gorilla packages come from? <awb99>Gorilla: from the GitHub repo in pinkgorilla/scm/gorilla <dftxbs3e>kondor, well then, you can try checkout out GNU Guix locally and modifying the package definition to disable tests then run "./pre-inst-env guix system vm-image" with that <dftxbs3e>kondor, I have substitutes for it over here it seems <awb99>I am trying to organize my guile code in a reuseable manner <kondor>dftxbs3e i am building the image off a 14 Feb commit ... maybe that's the difference <kondor>Anyway, there wasn't much to build <awb99>I build it with ./docker-build.sh <awb99>Then I start docker image with ./docker-start.sh <awb99>And ./docker-exec.sh rubs bash inside docker <kondor>So what's the strategy with the official substitute server? Does it attempt to only keep up with master branch, or are there other versions of guix on there which are fully built? <dftxbs3e>awb99, docker-image is building for me too <dftxbs3e>cbaines, hello! is it possible that substitutes are lost for the lle-bout/wip-ppc64le branch and it keeps scheduling new packages forever? <dftxbs3e>kondor, I am not sure it qualifies for this awesome list since this seems specific to your university? <dftxbs3e>kondor, I think we should somehow make a service that's able to search packages in all revisions of a list of all known guix channels <dftxbs3e>This would mean we need to compute derivations for all revisions of all guix channels <dftxbs3e>And then we could list such a (web?) service inside the awesome-guix list <dftxbs3e>kondor, I've seen tons of personal guix channels that I am not sure I should add to the awesome-list or not <dftxbs3e>Maybe I should create a separate file where all of them are listed no matter their content <abcdw>In someone's repo I saw a shepherd user service for gpg agent, but can't find it right now. Please share it if you have one. <kondor>Well, it's not specific to myself, rather the mass-spec subcommunity of bioinformatics. I only pinged you because earlier you seemed to ask for people to add channels independent of how awesome the channel looks like. :) <dftxbs3e>kondor, okay well! let's specify mass-spec then! I didnt know about that. <kondor>dftxbs3e yeah, with a special focus on environmental chemistry <dftxbs3e>kondor, could you add that to your README? <kondor>dftxbs3e it's in early stages tho (the channel) <kondor>dftxbs3e yes, as soon as i have time. Lets say i ping you when the channel is ready for wider audience <abcdw>dftxbs3e: I think it will be cool to have a separate section for now and maybe later (when the number of items in the list will be too big) a separate file for user channels/configurations, like this one: https://github.com/caisah/emacs.dz <dftxbs3e>abcdw, yes that table looks awesome! we could have a separate file with all of those and linking to it from the README <abcdw>dftxbs3e: A separate file with a table sounds good to me. Someday we can additionally make a simple web page with list of user's channels automatically grabbed from git forges. <awb99>Shepherd is not running, even with base-services added <dftxbs3e>awb99, I think you have to pass it paths to the store since that's where things are.. but also somehow try to display the manifest of the image, does it contain a default command? <dftxbs3e>awb99, my system has this for example: /gnu/store/18hp7flyb3yid3yp49i6qcdq0sbi5l1n-guile-3.0.2/bin/guile --no-auto-compile /gnu/store/655wq4zm0j9fh05xzzr1hc6a2z5y8dra-shepherd-0.8.1/bin/shepherd --config /gnu/store/27pssm17yyclgcs6plmmkkjvrj0bj3ds-shepherd.conf <dftxbs3e>awb99, I could not docker exec because I didnt have the path of a working shell in there but I think shepherd ran for me <dftxbs3e>awb99, you can probably: find /gnu/store -name '*shepherd.conf' <kondor>Wow, i finally realised what triggers so much compilation during the building of vm image. I took a shortcut and `eval`ed my own replacement definitions into guix modules (the second argument to `eval`). Clearly not the most amazing idea if you want to depend on substitutes. <kondor>More specifically, replacing `net-base` package did it. <mdevos>When running ./pre-inst-env guix build abiword -d, guix tries to <mdevos> download tiff-4.1.0.tar.gz (and other things). Does anyone know why? <mdevos> I only want the derivation (the location <mdevos> /gnu/store/...abiword-VERSION.drv is all I need <cbaines>regarding substitutes, everything that is built should be kept forever (just because I haven't sorted out a mechanism to delete things yet) ***apteryx is now known as Guest77115
***apteryx_ is now known as apteryx
<dftxbs3e>cbaines, okay! :-D - Good morning to you too! <dftxbs3e>cbaines, do you know who are GNU Guix project maintainers besides Ludo? <dftxbs3e>cbaines, okay I see, because I have a pending Commit Access application with necessary vouches and wondered who was intended to ever approve it <ss2>I think I'm felling a bit confused at the moment; I'd like to hack on the guix git tree, and then deploy the changes on my guix machine, as if it where it's own local channel. <ss2>I'd like to modify a package, or try to some changes on it, and see how it works out. <dftxbs3e>ss2, for that you can get a clone, then ./configure --localstatedir=/var, then make -j$(nproc), then ./pre-inst-env guix <ss2>that's in the manual too? <dftxbs3e>and before configure you also need ./bootstrap <efraim>I went to bisect guile on powerpc32 and started with the git checkout for 3.0.2, which I know is a good release, and one of the tests failed. since I'm bisecting for failing to build and not the tests I think I'll just skip the tests for now <mdevos>I'm writing a patch that replaces almost all mentions of autoconf with autoconf-wrapper ... <mdevos>it would cause many rebuild. Should I just submit it as-is, or determine for which packages *not* to use autoconf-wrapper to avoid most rebuilds? <leoprikler>I think this is one of those core-updates kind of deal <mdevos>leoprikler: if it's going to be for core-updates, then it doesn't make much sense to disable the change in strategical places, right? <leoprikler>Not sure what counts as "strategical place" here, but you could partition your changes so that they go to the respective branch according to rebuilds as well <leoprikler>i.e. push those with less than 300 to master, and so on <leoprikler>another "strategical place" would be autoconf instead of autoconf-wrapper for bootstrapping, but I don't think that's what you have in mind when you're asking that question <mdevos>"strategical place" = package with lots of dependent packages. E.g. replacing autoconf with autoconf-wrapper in openldap causes many rebuilds <mdevos>I mean, it's not like I'm updating any package. No new updates and bug-fixes. To the user, whether we use autoconf or autoconf-wrapper doesn't really matter, *as long as there are substitutes*. So myself, I'm in favour of targeting the patch to core-updates. But I can ‘partition’ the patch somewhat, by leaving a few of these ‘strategical places’ for ‘core-updates’. <leoprikler>In terms of substitute availability, pushing this to c-u is the best solution <leoprikler>things changed since the Guix Days and I haven't kept up with it tbh <mdevos>leoprikler: ok, seems like we agree about which branch. (idk about the new workflow, though) *mdevos has to leave for an hour or so <nckx>leoprikler, mdevos: Very little has changed; only that cu/st are never frozen, a copy is made ({cu,st}-frozen) which is then frozen & merged. c-u is still the place for this patch. <leoprikler>Ahh, that's certainly less confusing than the alternative. <jlicht>I'm getting the chance to use `guix pack` at work, I couldn't be more pleased right now :) <pineapples>jlicht: May you elaborate? I'm curious as to what your usercase is :D <jlicht>making sure that some scipy/numpy/numba-using Python project "Just Works" on a wide variety of hosts, so nothing silly <pineapples>That's fair. I don't have a use for `guix pack` myself so all I can tell that it is a piece of cool tech from the looks of it alone ***bqv is now known as bao
***bao is now known as bqv
***nckx is now known as jorts
<pineapples>abcdw: Unfortunately, this is not a pernament solution. Either adding the LID_PRELOAD_LIBRARY wrapper or patching paths at the source are, again, the proper way to do it <abcdw>pineapples: I agree, just an idea of a hotfix to continue work. Can you send a patch to mailing list, please? I'm sure that it will be merged relatively fast. <jorts>pineapples: Sure, but why the LD_ hack over Marius's fix? ***jorts is now known as nckx
<nckx>s/fix/hack/, no comparison intended. <pineapples>nckx: Less headache-incuding and prone to breakages <nckx>It's just a bigger hammer (those cause headaches too). <pineapples>abcdw: I can at best incorporate the LD_LIBRARY_PATH hack but nothing else. Besides, I'm hoping someone would do it for me; I'm not ready to contribute to the project yet <jlicht>so I just sent an email to the security mailing list; my apologies in advance if I'm worrying about nothing, I know folks reading that list have more fun things to do in life as well. *nckx moderates it while nobody's looking. <nckx>Oh interesting. Thanks for worrying. <jlicht>nckx: That is one word to describe it :P. Thanks! <nckx>I'm very new to security@ & don't have the list password yet so in limbo you will stay. Sorro. <pineapples>nckx: Idk. It's a responsibility I'm not willing to take if something breaks beacuse of me. Here's a deal: if I can replace my daily driver with Guix, and don't have to boot into it within the next coming months, I'll consider contributing my first package or something :') <efraim>I have a patch for rust crates that'll let us patch the library and then carry it forward, patched, to all the subsequent builds <nckx>That's perfectly applicable. <nckx>Better than the mess I'm currently making patching a rust-smithay-client-toolkit that isn't a direct input ☺ <pineapples>This may be a dumb question, but would it be applicable to the Alacritty issue? <efraim>I need to check again if we can create an ad-hoc registry as a local mirror of sorts, for people using the crates directly <efraim>it means we could patch, say, rust-wayland-sys-0.23 just the once time in its own package definition to refer to the wayland libraries, and then when it gets pulled into another later build it'll already refer to the libraries <efraim>and we won't have to patch it in alacritty <nckx>pineapples: From my limited understanding/liking of Rust, the alternative to the big LD_LIBRARY_PATH hammer (which I'm less fond of) is to patch rust-smithay-client-toolkit to refer to libxkbcommon by its full file name. But that requires each end user to do so, which is blech. <nckx>pineapples: The responsibility would be the reviewer's, not yours, and everyone's broken something before. But no rush. Boot whatever you prefer. <pineapples>Anyway, debugging Telegram is my top priority right now.. except.. I can't read a segmentation fault backtrace hahahah <bqv>Segfaults I would presume to be upstream bugs <bqv>Unless it's been linked very very wrong <nckx>Things that ‘never happen’ on non-Guix systems can lack proper error handling (since they've never happened!) and cause a segfault due to broken assumptions. <bqv>How often is that the case? It's pretty rare in the nix world <bqv>(Segfaults, not broken assumptions, of course :p) <pineapples>raghavgururajan readched out to the upstream but they were uncooperative <nckx>Alacritty takes eons to build. <pineapples>Oh. Apparently gdb can't catch the segmentation fault now that webrtc-for-telegram was compiled with the debug release flag. Interesting.. <nckx>‘Bug: -g breaks debugging.’ <mdevos>pineapples: do you have link to the bug report? I'm wondering why they would be uncooperative, segfaults are ‘serious business' after all <nckx>They sound as cooperative as I'd expect. <nckx>Alacritty's been building for 20 minutes now. <nckx>It really is compiling every input from source. <bqv>The best ones are where enabling debugging fixes the bug <bqv>I had that with haskell a while back, it made me irate <pineapples>I wish it at least did that. Enabling debugging for telegram-desktop makes it fall apart and refuse to start up <nckx>bqv: I'm currently ignoring a bug like that in Linux. It... kind of make sense there, since the extra debugging options probably disable some measure of KASLR or whatever. <roptat>I've defined a procedure, make-ocaml-llvm that takes an llvm package as argument, and returns a package that contains the ocaml bindings. Defining ocaml-llvm is a one-liner: (make-llvm-package llvm), and same for the three versions of llvm we have: (define-public ocaml-llvm-10 (make-ocaml-llvm llvm-10)). There are four packages: ocaml-llvm{,-9,-10,-11}. Should I send four patches, with three of them adding one line, or can I send a single patch? <kondor>Hi guix, ... i notice the choice of several display managers among packages (lightdm, gdm, sddm, ..) , but as far as i can see there is only gdm and sddm implemented as services <nckx>abcdw, pineapples: I've restored Marius's fix for now. <kondor>How do people use, say, lightdm as their login manager, on startup? <roptat>kondor, they don't, if there's no service <nckx>I tested with DISPLAY= and it works where it didn't before, but let me know if it doesn't on a ‘pure’ Wayland system. <roptat>a package is a pre-requisite for a service, so it makes sense we lack services for some packages, and not the other way around :p <nckx>pineapples: I just copied someone else's code, cursed at a screen, edited it a bit, cursed some more and pushed. <roptat>but yes, it's kinda useless without the service <kondor>... short of writing a shepherd service themselves <roptat>if you write a service for lightdm, you're more than welcome to share it by sending a patch :) <pineapples>Would someone take a look at my Telegram backtrace? I tried staring at it and looking up what code it makes references to, but I couldn't figure out what's wrong *shrugs* <mdevos>pineapples: where can I find the backtrace? <mdevos>wild guess: there may be memory corruption somewhere (maybe use-after-free)? Run Telegram under valgrind and see what heppens <pineapples>mdevos: I made an attempt to have valgrind possibly tell me what is wrong but it just terminates itself as soon as Telegram crashes <mdevos>pineapples: do you have a log of valgrind's output? <mdevos>btw, this looks like a use-after-free. In first backtrace line: <error: Cannot access memory at address 0x10000bb80> <mdevos>or maybe trying to use a function pointer as data <mjw>pineapples, that is odd, what is the output without valgrind? <mjw>it is as if valgrind looses control. <mjw>pineapples, could you try with valgrind --trace-children=yes telegram-desktop <boombim>Hey guys. Why guix pull use so much cpu? It runs my cpu to maximum. I supposed it should work like apt-get update in debian. <kondor>... whic i see someone did on a branch .. and it looks huge and messy, so probably not something to do in an afternoon <valerii_leontiev>Hey guys. Why guix pull use so much cpu? It runs my cpu to maximum. I supposed it should work like apt-get update in debian. <pineapples>mjw: Is there any other public serive, such as Debian Pastezone? <civodul>hey boombim & valerii_leontiev; 'guix pull' does more work than 'apt-get update', that's why <civodul>though it'd be great to make it about as fast <nckx>pineapples: paste.gnome.org? <nckx>Note the default expiry though. <mjw>pineapples, hmmm, seems valgrind is getting a little confused, it starts with an ioctl valgrind does know about, which makes it tricky to catch real stuff. <mjw>then it finds some issues, but has no idea where they are from. <mjw>pineapples, I am afraid valgrind is not of much help in this case. <mjw>we do have a backtrace of the crash, which might be helpful <boombim>civodul is it posible to build nothing locally? And just download everything from server <mjw>I think the actual issue is here: <mjw>==14949== by 0x6B35089: WebRtcAudioReceiveStream (webrtc_voice_engine.cc:1087) <mjw>==14949== by 0x6B35089: cricket::WebRtcVoiceMediaChannel::AddRecvStream(cricket::StreamParams const&) (webrtc_voice_engine.cc:1882) <roptat>boombim, if there are substitutes, and you authorzie them, guix will download them instead of building them locally <pineapples>mjw: Would compiling webrtc-for-telegram-desktop with debbuging enabled helped a little? <pineapples>I disabled it for this webrtc fork since it prevented GDB from catch the segmentation fault but perhaps this will not be an issue for Valgrind <mjw>pineapples, maybe, but valgrind doesn't even know which object some of the code comes from (it might have been jit compiled or some ffi issue) <mjw>pineapples, it also won't help with the ioctl and fcntl issues, does need to be fixed in valgrind. <mjw>which has a patch, will try to get that applied upstream <pineapples>mjw: Okay. So, now that webrtc-for-telegram-desktop has been built with the -DMAKE_SOMETHING=Debug flag, Valgrind goes down along with Telegram itself. <mjw>The ioctl is a bit more mysterious, I wonder what QFileSystemEngine::cloneFile does <nckx>Some newish CoW ioctl perhaps? (Guess.) <mjw>that rings a bell... <boombim>civodul I've added this to my channels.scm <boombim>(list (channel-with-substitutes-available <boombim>hint: Did you forget a `use-modules' form? <boombim>home/tim/.config/guix/channels.scm:1:0: error: channel-with-substitutes-available: unbound variable <mjw>OK, so that is fixed upstream, but not in any released valgrind. So not really that helpful. <mjw>I can get the F_ADD_SEALS also upstream and then in the next release. <mjw>But I doubt it really helps with the current case, even if we get a new valgrind release <civodul>boombim: like i said it's recent, so maybe your Guix doesn't have it yet; you'll have to pull first :-) <mjw>pineapples, valgrind going down when there is debuginfo seems really bad. <mjw>pineapples, do you have any more hints about what might be going on there? <boombim>civodul using guix in debian. I pulled 30 minutes ago... <roptat>boombim, can you check you have ~/.config/guix/current/bin first in your $PATH? <mjw>Also, I guess this isn't really about your issue anymore, but about debugging valgrind, which is probably not as useful (to you) <roptat>also, if "type guix" doesn't tell you it's ~/.config/guix/current/bin/guix, then make sure it's first in $PATH, and type "hash guix" to refresh bash's cache <boombim>roptat looks like i haven't this directory in path. <boombim>home/tim/.nvm/versions/node/v10.23.0/bin:/home/tim/bin:/home/tim/bin:/home/tim/.guix-profile/bin:/home/tim/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games <roptat>just add that directory to you $PATH the usual way (.bash_profile or .bashrc, not sure), that's where guix pull installs the new guix it pulls <nckx>.bashrc is for unexported things. <pineapples>mjw: It's certainly not a problem with whatever code responsible for capturing audio using a microphone; I can send voice messages just fine. I checked if all dependencies of telegram-desktop and webrtc-for-telegram-desktop are present and of correct revision, and they were, so nothing suspicious there. What caught my eye was libtgvoip-for-telegram-desktop, which we need to build with the "--disable-dsp" <roptat>you can skip the first part, until you see the example with "guix pull", that's the part that's interesting to you <pinoaffe>DSP is digital signal processing, don't know what it does exactly in the context of libtgvoip <raghavgururajan>"--disable-dsp" flag in libtgvoip-for-telegram is equivalent to "disable-webrtc" patch in libtgvoip. <raghavgururajan>Btw, you were debugging webrtc-for-telegram using gdb right? Were you able to debug directly at telegram-desktop? <raghavgururajan>Before, I packaged foobar-for-telegram stuff separately, I tried building telegram-desktop with it's bundled stuff. I still got the seg-fault on run-time. <pineapples>I attached GDB to a telegram process, reproduced the crash, loaded debug symbols for gcc (as if it made any difference..), set "directory" to two paths containing unpacked sources of both telegram itself and webrtc-fo-telegram, and ran `bt full`. <raghavgururajan>When libtgvoip build along with telegram-desktop (bundled), it does static libs. So it didn't "--disable-dsp". <raghavgururajan>I think, if you try to build libtgvoip-for-telegram-desktop, without both "--disable-static" and "--disable-dsp"; but with "--disable-shared"; the buid would pass. *raghavgururajan forgot the syntax to build a hidden package *pineapples is having lunch *mdevos is back and doesn't have info about telegram <mdevos>pineapples: sorry, was that your lunch? (-: *raghavgururajan orders lunch via uber-eats <kondor>Btw, where is the system log in guix? :) <raghavgururajan>Okay, today seems to be the today to figure the telegram shit out. So lets do it. :D <mdevos>kondor: there are various logs under /var/log, like on other distributions <mdevos>what do you mean with ‘system log’? <mdevos>kondor: I have /var/log/Xorg.1.log <kondor>mdevos: yeah, to be more accurate, i'm trying to figure out why my vncviewer is showing a black screen when connecting to a guix VM <kondor>mdevos: i don't. Though I do have gdm <boombim>I remove ungoggled-chromium package with guix remove. Then did guix gc -D. But ungoogled-crhomium still in my gny/store and it take more than 300 mb. Why it is happened? <mdevos>boombim: it's still referred to by the previous profile generation <mdevos>use "guix package --delete-generations=SOMETHING" <kondor>raghavgururajan it's just called gdm <boombim>mdevos how can i delete all previous generations and packages accept current? <kondor>Actually, `/var/log/gdm/greeter.log` <mdevos>boombim: did you install chromium in the system profile at some point? (the packages field of (operating-system ...) IIRC) <raghavgururajan>boombim: Check if there are any other gc-roots for it. `guix gc --list-roots` <boombim>i just did guix install ungoogled-chromium <boombim>hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining `GUIX_LOCPATH', along these lines: <boombim> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" <boombim>See the "Application Setup" section in the manual, for more info. <boombim>var/guix/profiles/per-user/tim/current-guix-3-link <boombim>var/guix/profiles/per-user/tim/current-guix-3-link <boombim>var/guix/profiles/per-user/tim/guix-profile-31-link <boombim>var/guix/profiles/per-user/tim/guix-profile-31-link <boombim>var/guix/profiles/per-user/tim/current-guix-3-link <mdevos>boombim: keep in mind that IIRC guix' gc will look at the environment variables (and some other things) of running binaries. <mdevos>if the output path of ungoogled-chromium appears there, ungoogled-chromium won't be gc'ed <mdevos>so maybe log off and log on again? *raghavgururajan forgor how to fine-tune gc <raghavgururajan>if see path for chromium, then it is being used by one of the processes <boombim>I'll try to kill everything and try gc again <valerii_leontiev>Reboot helps. Actually I don't understand why it's happened but thanks everyone <boombim>I get this error when i try to open configuration of it <boombim>terminate called after throwing an instance of 'std::runtime_error' <boombim> what(): locale::facet::_S_create_c_locale name not valid <pineapples>mdevos: Did you see the valgrind logs? mjw suggested where the actual issue might be, although it's not certain so we're now at a dead end now <mdevos>pineapples: I've only looked at the first log <mdevos>where's the latest log to look at? <mdevos>pineapples: ‘The page you are looking for does not exist’ <efraim>nckx: alacritty launches just fine on my enlightenment/wayland desktop <pineapples>nckx: It now launches under Sway without Xwayland. Thanks! <mdevos>pineapples: did you notic the attempt to access a null pointer (line 33)? I don't have more ideas. <pineapples>==14949== by 0x6B35089: WebRtcAudioReceiveStream (webrtc_voice_engine.cc:1087) 5 ==14949== by 0x6B35089: cricket::WebRtcVoiceMediaChannel::AddRecvStream(cricket::StreamParams const&) (webrtc_voice_engine.cc:1882) <pineapples>Also: the second log have gotten deleted as well <mdevos>pineapples: pastes on paste.gnome.org have a 30 minutes expiration by default <mdevos>maybe change to a week (bottom-right, next to the ‘paste’ button) <pineapples>I did change its expiration period to 6 hours. This is just odd *pineapples will be right back <raghavgururajan>> pineapples: raghavgururajan readched out to the upstream but they were uncooperative <raghavgururajan>pineapples, mdevos: Folks in #guix prefer paste.debian.net, as it doesn't require JS. <pineapples>raghavgururajan: You've forgotten to mention the user I was talking to <pkill9>also it works via tor apparently <pkill9>paste.debian.net raghavgururajan <nckx>raghavgururajan: paste.debian.net was rate-limiting them at the time. <nckx>Also paste.gnome.org works fine in links here. <nckx>And eww. I don't think it needs JS. <lf94>I'm surprised steam hasn't been packaged yet :) <nckx>When I think ‘Steam’ I don't think ‘free software’ or ‘FSDG-compliant’ but I'm no gamer. <lf94>I forgot guix is free software focused, my bad! <lf94>I guess the only way to do it would be to depackage the debian package <lf94>Figure out the dependencies, and re-package it <mdevos>civodul: I plan to use it for substitutes over GNUnet <leoprikler>lf94: Even then it won't be acknowledged into Guix upstream due to its heavy focus on non-free software. <nckx>If there's an official Debian Steam package that's a good sign. ‘We’ disagree about a few details but share the same values. <nckx>leoprikler: *cough* Wine. <leoprikler>IIRC the debian packages for it are strictly in the non-free category <leoprikler>Wine does not promote non-free software, it lets you deal with it. <nckx>As would an FSDG-compliant distribution of Steam. <lf94>leoprikler: I would have no intention to get it upstreamed <lf94>I fully respect Guix community's decision for free software only. I think it's good actually <lf94>Decentivizes non-free :) <raghavgururajan>> nckx: raghavgururajan: paste.debian.net was rate-limiting them at the time. <civodul>mdevos: thanks for the reminder, and sorry for not getting to it before <civodul>(i'm getting back from a break and trying to get some focus) <leoprikler>Steam is a proprietary content delivery and launcher application [...]. It is packaged for Debian in the non-free section. <nckx>What's the use for it then? <mdevos>civodul: no problem (-:. I think I'll have a try at a hook mechanism for the substituter <nckx>I mean, why do people run it? <nckx>Meh. Off topic. Just weird. <leoprikler>It is the de-facto platform to host games on and some don't even run without it. <leoprikler>commercial games of course, meaning those that won't ever be considered free software mostly <nckx>It's proprietary *and* supports DRM. Why would anyone install this. <leoprikler>Capital G Gamers are tricked into believing, that Steam (and similar marketplaces) are merely convenient tools to manage their game libraries in. <reepca>Because most people don't want to be the change they want to see in the world; they want to simply be. <leoprikler>They only care about DRM once it perceivably impacts the performance of whatever game they happen to be playing. <nckx>Thanks for the reality check leoprikler gaming legend. <leoprikler>it probably is possible, but I don't see much reason to do so <jgart[m]>well, just for experimentation. I'd be curious. <leoprikler>just try to write your next guix.scm as a guix.wisp instead <leoprikler>as for OS config.scm, that needs to be written in lisp, but you can just load some wisp file from it if you really feel the need to <jgart[m]>why is wisp not able to handle an OS config.scm? <leoprikler>it's an implementation detail, but guix loads the config.scm and wisp is not actually implemented as a guile "language" <leoprikler>so you don't have the means to switch to wisp from within a file <jgart[m]>Is there any guile "language" that would work, currently for writing a config.scm? <mdevos>sneek: later tell civodul: I also have a patch that implements an appropriate service extension (unsubmitted), but I couldn't test it yet <pineapples>nckx: Ohhh, don't get me started on the topic of the modern game industry.. <nckx>I obviously live a sheltered life, game-wise. <leoprikler>It is a very sad statement, that even anticapitalist pundits like Jim Sterling need to praise proprietary software from time to time. <pineapples>Jim Sterling? That's the name I haven't heard for a while <leoprikler>They're still shitting on Ubisoft, EA et al. for obvious reasons. <jgart[m]>bavier: What has been your use case for that package? Would you like to be able to write a systemd service with guile someday that way it can currently be done with nix in NixOS? <jgart[m]>the above two questions are not necessarily related <bavier[m]>jgart: only use case so far has been to satisfy a dependency for anbox. That could possibly be made slimmer, since I think anbox only needs some of the systemd support libraries. <bavier[m]>I've been fine with shepherd, so have no aspirations of systemd-in-guile 🙂 <pkill9>you have anbox working in guix bavier[m]? <bavier[m]>"working". I've not been able to launch anything with it yet. There are some kernel modules and support services that I haven't sorted out yet. If you'd like to help... 🙂 <civodul>raghavgururajan: you can use "guix build -e ...", see the examples in the manual <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, mdevos says: I also have a patch that implements an appropriate service extension (unsubmitted), but I couldn't test it yet <rekado_>game industry? I packaged “passage” yesterday. It’s … sad. <rekado_>leoprikler: wisp is implemented as a Guile language. <rekado_>leoprikler: but in Guix we don’t select it when presented with a wisp file. <rekado_>in the Guix Workflow Language I’m checking for the extension and use Wisp to load the file. <rekado_>it wouldn’t take much to make Guix support wisp files. <jgart[m]>rekado_: What would it take for Guix to support wisp files? What's left to do? <rekado_>we just need to tell it to use the wisp reader if it’s a wisp file <jgart[m]>If the guix community didn't want it would it be practical to offer it in a third-party guix channel? <rekado_>I’d first discuss this on guix-devel and make the case for it. *civodul already sees twice as many stat(2) calls... <rekado_>civodul: not if there’s a magic S-expr at the top to indicate wispness. <pkill9>bavier[m]: since you packaged systemd, could you run guix on systemd? lol <jgart[m]>pkill9: There's someone that proposed writing a guile wrapper around systemd a while back. <civodul>rekado_: true, that could be an option <jgart[m]>It would be nice to extend the idea of "universal package manager" to "universal init system manager". To treat the different init systems as something that guile/guix can interface with so that you can write all your init scripts in the one true language. I don't know what kind of rabbit hole I am creating by suggesting the above though. I wonder if it would be feasible or even elegant to do. <lfam>I feel like "rabbit hole" doesn't even begin to describe it :) <lfam>There's a shared goal between Guix System and systemd in that both projects aim to integrate the functionality of the system and provide a unified interface <jgart[m]>would it be a rabbit hole to create a systemd, openrc, runit, etc... service file compiler/generator with guile? <lfam>Can you clarify what you mean? <roptat>a single definition, that would give you equivalent services for systemd, openrc, runit, ... ? <jgart[m]>roptat: exactly! you explain in much better than I did <lfam>I don't know about openrc or runit but systemd has so much more sophisticated functionality than shepherd in Guix System that I don't think it would be possible to express an equivalent service <lfam>And, we want to close that gap! It's not a goal for services on Guix System to be simplistic <lfam>But, the work has to be done, and it's a lot <lfam>But, I do think we have basically the same goals as systemd <lfam>Despite some people choosing Guix because it's not based on systemd... <jgart[m]>yes, systemd has sandboxing/isolation options and much more stuff built in that openrc, runit, etc... don't <lfam>Yeah, and that's just one of many integrated features! <lfam>It's a really sophisticated and expressive way of managing the system <lfam>It's basically the same as Guix except that we are only just getting started, while systemd is mature <lfam>The only significant difference is that we expose a programming language, but systemd uses ini-style configuration files <jgart[m]>On another topic, I have been dreaming of a vps cloud provider that offers one-click install apps (i.e. services) via an html5 interface. I've been speaking about this with various people to get opinions on the idea. Something like this: https://www.vultr.com/features/one-click-apps/ but entirely managed by guix system. The html5 interface would provide a small curation of services to choose and combine that guix can deploy. I <jgart[m]>imagine I would have to limit the combinatorial possibilities of what users could select. <lfam>I've wanted something similar. A VPS service that accepts a config.scm and gives web-based virtual console to access the result <lfam>The tricky thing is avoiding expensive compilation on behalf of the user while creating the VPS <jgart[m]>i.e. instead of selecting vim plugins that generates a vim config the user selects packages and services for a guix system <jgart[m]><lfam "The tricky thing is avoiding exp"> yes, can substitutes be provided by guix system images? <jgart[m]>or would that not be the way to go about it? <lfam>I'm confused by your question. Substitutes are provided by an HTTP server <lfam>I guess that new images could always be based on the latest Guix release, and the service could run a mirror to improve caching <jgart[m]>What I meant is to provide a substitute (can an iso image be called a substitute?) for a guix system image that can be uploaded to vultr or digital ocean and deployed <lfam>A substitute is just something that Guix built. So anything that Guix builds can be substituted <lfam>My idea is not to provide an artifact that can be used on another site, but to be the VPS host <jgart[m]>so you would build the api for your cloud platform from scratch? <lfam>Going back, Guix is a build-from-source distro. These builds can be transparently "substituted" due to the precise dependency tracking that Guix uses. So yes, the result of `guix system vm-image` can be substituted <lfam>If I were to do it (probably not), I would start simple. An HTML form that the user pastes their config.scm into <lfam>I guess that if the business took off, the sky would be the limit <jgart[m]>then the html5 gui what make a request to that api <jgart[m]><lfam "If I were to do it (probably not"> this sounds very doable <lfam>I mean, the simple thing would be to pass the result of the form directly to `guix system vm-image` in a sandbox <lfam>I think fancy APIs come once there are some paying customers <lfam>It would be way more computationally expensive than a traditional VPS hoster <lfam>Yes, I think it's doable. I'm not motivated to start businesses <rekado_>you can avoid a lot of work by fixing the version of Guix in use and/or by building permitted/expected configurations in advance. <lfam>Right, like always basing new images on the latest Guix release <lfam>It could create a funding stream for someone to maintain a "stable branch" <lfam>Then users can pay for their own CPU time to update their systems to the latest, just like with other VPS / distro situations <jgart[m]>The html5 gui would also make it easy to onboard guix users in the cloud space <jgart[m]>I think ambrevar was working on a local/offline gui for guix with a similar motivation of onboarding non-technical users <jgart[m]>I'm sure that wasn't his only motivation but it was one of them <lfam>Tbh, if it were me, I'd try to discourage "non-technical" users. I think they'd probably cost too much in support <sundbry>Hello #guix, what is the scheme function to get the path to a package output? I am not in a g-expression <sundbry>I need to do something like (file-append clang:extras "/bin/clang-tidy") <jgart[m]>I'm not a business man but I'm also not excited to work for a corporation or company. I've worked as a freelancer most of my life just scraping by. <sundbry>In a package argument, a configure flag <sundbry>I have it defined as an input but I need to specify the exact path for this Cmakefile I am workign with <rekado_>sundbry: you would use (assoc-ref %build-inputs "the-name") there <lfam>daviid: It's based on Electron which presents challenges for Guix <lfam>It could be achieved but so far it hasn't been done <sundbry>rekado_: Wrong type (expecting string): (string-append "-DCLANG_TIDY_BIN=" (assoc-ref %build-inputs "clang-extra") "/bin/clang-tidy") <raghavgururajan>Am I doing this wrong? `guix build --expression=(@ (gnu packages telegram) libtgvoip)` <rekado_>sundbry: is there an input with a label “clang-extra”? <rekado_>sundbry: would be easier to diagnose this and recommend action if you could share your code <sundbry>you will not be able to build this since i have some extra code in (gnu packages java-databases) and (arctype packages llvm) <rekado_>libpulsar inherits from pulsar, which doesn’t have any input named “clang-extra” <rekado_>that’s why the assoc-ref returns #false <rekado_>and #false is not a string, so the string-append fails <roptat>sundbry, you have #:configure-flags '(...) so the content is not evaluated <roptat>replace with ` (backquote) and add a , (comma) before your (string-append ...) calls <rekado_>I missed it because I didn’t expect it so far up! <roptat>yeah, it took me some time to realize too :) <roptat>we usually declare inputs after the arguments, so that was a bit confusing ^^ <sundbry>I already tried that, error: %build-inputs: unbound variable <apteryx>hi! I'm trying to use Guix on a foreign distro, and it's been a long time (all my machines are using the Guix System). Reading the binary install section of the manual, I should install one of the glibc-locales packages and set GUIX_LOCPATH. That needs to be done per-user, correct? <leoprikler>rekado_: my bad, TIL there is actually a compilation from wisp to Tree-IL <roptat>raghavgururajan, but actually I think with @@ it's a different package, because it has a different name in telegram.scm: guix build --expression='(@ (gnu packages telegram) libtgvoip-for-telegram-desktop)' should give you the correct one <leoprikler>apteryx: you can do it for the system, but per-user sounds good <leoprikler>adding a systemd compatibility layer in shepherd would be nice <jlicht>didn't someone start working on a signalfd-loop to support the socket-based activation of systemd in shepherd? <g_bor[m]>There was some work on that in an internship <g_bor[m]>I also spent some time investigating what would be needed for get services working <nckx>Was just going to say: sounds like a GSoC kind of thing. <g_bor[m]>The main problem I see is the very different dependency model. <jgart[m]><lfam "Tbh, if it were me, I'd try to d"> I think it is important to prepare future generations for becoming stewards of free software. We need more maintainers and more packagers that can join in the effort of auditing, updating, and packaging free software. I think this can be learned by "non-technical" users in the same way that amateurs can learn to maintain their own/community gardens. <apteryx>leoprikler: on a foreign distribution, per system means installing things as root, right? <g_bor[m]>Systemd has an ordering graph and a dependency graph <leoprikler>installing as root and manually messing with /etc et al. where needed <lfam>jgart[m]: Absolutely! I agree with your goal and it's part of why I'm involved here. I was just speaking about what *I* would do if I was starting a business, which is different. And the business would eventually aim to be accessible to non-technical users too <lfam>Personally, I know I would run out of energy and get tired dealing with constant questions about locales warnings and that kind of thing <lfam>apteryx: You need to do it per-user and also in the environment where the guix-daemon runs (probably in a systemd service file) <jlicht>leoprikler: no, not yet as far as I'm aware. <nckx>That alone would be awesome (and maybe a more realistic internship). <apteryx>lfam: I used the install script, so the systemd service and GUIX_LOCPATH environment got covered automatically for the guix-daemon. Neat! <apteryx>for the jenkins user I'll use guix for, I had to install 'glibc-locales' instead of the 'glibc-utf8-locales' as hinted, as that one didn't have en_CA amongst its locales. A bit confusing, but this was noted by others before. <apteryx>the hint could maybe look at the current locale to suggest a better one <lfam>We should remove glibc-utf8-locales. Or at least hide it and just use it internally <lfam>It was never meant to be something that people use <apteryx>the problem is that glibc-locales weights about 1 GiB <apteryx>even if it compresses to about 12 MiB IIRC the download size <apteryx>I use zstd compression atop Btrfs, so I don't care personally, but ;-) <lfam>We could rename it to glibc-test-locales or something, to at least reduce the confusion <lfam>Rename glibc-utf8-locales, that is <nckx>lfam: This conversation has been had before (probably more than once) but I don't remember if there were any counter-arguments. I agree with you. It's misnamed. <g_bor[m]>nckx: the primary intended feature of the internship was socket activation, but they didn't manage to create useful code. <g_bor[m]>I guess Ludo might have some more info, he was the leading mentor there. <lfam>nckx: I think the counter argument is that 1 GB is a lot <lfam>And that we should instead develop an abstraction so users will only need to download / build the locales the want <lfam>We could rename the package, add a deprecated alias "glibc-utf8-locales", and then remove the alias in a year or something <nckx>Right, now it comes back to me. We currently have that for Systems only. <leoprikler>what's the default value for locale-definitions? <nckx>%default-locale-definitions 😛 <nckx>(See gnu/system/locale.scm; too much to list here.) <nckx>So the usual ‘too much and probably not enough’.