<lfam>paulj: Configuring dwm is such an unusual yet common thing that it should definitely have an entry in the cookbook <lfam>If it's missing, let us know how we can help <jgart[m]><lfam "paulj: Configuring dwm is such a"> My understanding of a way is to inherit from dwm and then use the patches and search-patches forms. Is this correct? <jgart[m]>Should that method be added to the cookbook as an example? ***iyzsong-- is now known as iyzsong-w
<lfam>jgart[m]: I've never used dwm. I just know that it is configured by recompiling, and is commonly asked about by new Guix users. So, whatever works <jgart[m]>Luke's fork as an end-user package for distribution instead of as a personal package that is configured and rebuilt with a quicker feedback loop. <raid5atemyhomewo>I have more patches as well, but if the current set is not going in any time soon, I am not enocuraged to bring teven more patches in at this point <raid5atemyhomewo>So... any chance of ZFS on Guix getting any attention? I already submitted patches <raid5atemyhomewo>though note that some of the patches for ZFS change things in the gnu/build/ as well, can a channel override those? <jgart[m]>That's fine. Let's keep in touch. I still have to sign all the packages/rewrite git history in that channel. It is currently not "ready for production" <jgart[m]><raid5atemyhomewo "though note that some of the pat"> Maybe we can ask the community what would be the best way to go about this. A macro might help out here. Let me take a look at your patches first and I'll get back to you. <raid5atemyhomewo>for example, it changes the dependencies of the file-systems Shepherd service, makes it extensible as a Guix service that accepts Shepherd provisions it should wait for <raid5atemyhomewo>which is needed for /home on ZFS, otherwise /home will not get mounted early enough <raid5atemyhomewo>as well as changes to allow a Guix service type to add kernel loadable modules <jgart[m]>raid5atemyhomewo: feel free to reach me at #libremiami:matrix.org or the xmpp-matrix gateway to the same channel. I also check the logs at #freenode_#guix:matrix.org daily <iyzsong-w>raid5atemyhomewo: your ZFS work look great! I'd likely look into them this weekend... ***sorki is now known as srk
<jmarsden>I am seeing hostname return the correct hostname I defined in config.scm, but hostname -s and hostname -f return localhost. Is this a known guix quirk? <lfam>I can reproduce that jmarsden <lfam>I don't know much about that stuff but it would better if it worked. Help wanted! <raghavgururajan>leoprikler: Do you want me to remove recursive on telegram-desktop as well? ***jgart[m] is now known as jgarte[m]
<PurpleSym>Can I somehow get a shell (not a Guile prompt) when booting fails in the initrd? <allana>Hi, anyone know if/why git.savannah.gnu.org is down? I'm unable to "guix pull". <sundbry>@PurpleSym you cloud try (invoke "/bin/sh") <rekado_>allana: I can connect to git.savannah.gnu.org <allana`>rekado_: Thanks for checking. It was a local networking problem. <raghavgururajan>leoprikler: You asked me to wait, as you said you gonna investigate? <sundbry>i just tried it (system* program args) is the low level fn (invoke) uses but you just get an exited process <leoprikler>raghavgururajan: ah, no, that was probably directed at someone else *raghavgururajan needs đ” <abcdw>Hi guix! In guix/scripts/system.scm line 1314 if I press tab line will be realigned. rule for case is missing in dir-locals? or am I doing something wrong? <leoprikler>for the record, this is inside process-command, right? <abcdw>it's inside define-command, inside case statement <abcdw>probably my guix revision is a little outdated <abcdw>line with ` extension-graph shepherd-graph` <abcdw>mothacehe: ok, do we need to add a rule to dir-locals? or just keep it as it is? A little annoying, when some code randomly jumps, but not critical. <abcdw>leoprikler: ok, it works, thank you) <abcdw>Is it possible to automatically add #:use-module directive with gieser for current symbol under the point? <civodul>abcdw: nope! it'd be nice, but the problem is that Geiser would need a way to determine which module the symbol might be in <mdevos>did I just sent a message, or was it eaten by the network? <abcdw>sad, but ok, will be importing by hands) Doesn't look like unsolvable problem, but not the easiest one) <mdevos>apparently it has been eaten, it doesn' appear on logs.guix.gnu.org. Resend: <mdevos>Hi Guix! What's the recommend method for compiling a single C source file, depending on some shared libraries from a package, to a single executable in the store? (To be used in a service definition)? c-compiler in guix/scripts/pack.scm perhaps? <leoprikler>does the single c source file come with no makefile whatsoever? <leoprikler>liltechdude: `guix import` does not necessarily cover all the cases, when the source lacks metadata <leoprikler>python is notorious for not having its inputs specified in a meaningful manner <liltechdude>well, may be in channel exist some packages where same problem was solved succesful? <mdevos>leoprikler: no, I'm writing this C source file myself. It wraps a C function from a library from the gnunet package, which I find useful to use in an activation script <rndd>hi everyone! where i can read about new keywords in asdf build system (#:asd-files and #:asd-systems). there were #:asd-file and #asd-system-name last year <mdevos>The (not yet existing) C source file doesn't have a use beyond guix. Currently the service definition is rather incomplete, but I can post a paste <rekado_>rndd: in the build system source code at guix/build-system/asdf.scm; see asdf-build there <mothacehe>mdevos: in (guix self), look for "gcc" there's an example of compiling a single C file. <raghavgururajan>leoprikler: Just to double-check, for #45721, we are waiting on someone to do a second-review correct? <leoprikler>Yep, I'm no longer a blank slate, because I actively modified your stuff (v16). *rekado_ updates CRAN packages <leoprikler>If no one else weighs in, you can also push v18 (see my change requests) on Feb 3rd + delta. *mothacehe is trying to reproduce the Cuirass "guix-master" evaluation issue locally <mothacehe>civodul: any idea how to get more info about that one? <civodul>mothacehe: hey! could you pass "-s 1000" to strace? :-) <civodul>inferior exception are passed to the inferior user <civodul>so normally the inferior user gets an &inferior-exception *civodul launches "make cuirass-jobs", goes have lunch <mothacehe>oh! didn't know about this Makefile target, after all this time! <mothacehe>civodul: found it, thanks for the "-s 1000" tip. I was the culprit. Should be fixed with c64adff4. <mothacehe>trying to find why the backtrace doesn't make its way to the evaluation log <liltechdude>ogg123 is part of some library? Or it not yet packaged? ***spk121_ is now known as spk121
<dftxbs3e>hello! is it possible to create a package with multiple build systems for subdirectories inside etc? Trying to make a mingw-w64-tools package <leoprikler>yes, you just need to get the right modules imported and adjust #:phases accordingly <dftxbs3e>leoprikler, do you have an example package? <leoprikler>Not sure whether there are packages, that come close to what you're trying to do, but emacs-xyz has a number that mix gnu-build-system and emacs-build-system. <dftxbs3e>leoprikler, I mean that mingw has programs in subdirectories with their separate build system (gnu-build-system) but from the root directory it wont build those <leoprikler>do you want to make those individual packages or build them together? <dftxbs3e>leoprikler, I'd rather create a mingw-w64-tools package like in Debian <leoprikler>if you want those as individual packages, you can simply inherit mingw and then chdir <dftxbs3e>leoprikler, if I wanted to build them together, how could I do it? <dftxbs3e>I guess I'd build them individually then copy binaries into a single package <dftxbs3e>leoprikler, how would you reference package name from within a phase? <dftxbs3e>raghavgururajan, in GNU Guile? Otherwise just GDB, $ thread backtrace <raghavgururajan>dftxbs3e: In general to backtrace an application. So the command is `gdb app-name backtrace`? <dftxbs3e>raghavgururajan, gdb ./app - then interactively, "$ c" for continue, then when segfault happens, "$ bt" (shortcut for $ thread backtrace) <dftxbs3e>raghavgururajan, you need debug symbols so it's the most useful <civodul>now i wonder why the exception doesn't get through <civodul>the caller of the inferior should stop with an uncaught exception <leoprikler>dftxbs3e: If you want to build them together, just invoke the phases in a meaningful way <raghavgururajan>dftxbs3e, if the app insstalled, should I do something other than `gdb ./app`? <leoprikler>e.g. (add-after 'configure 'configure-subdirectory) (add-after 'build 'build-subdirectory) ... <dftxbs3e>raghavgururajan, if it is installed, it needs full path, so do $ gdb $(which app-name) <PurpleSym>sundbry: /bin/sh does not exist in the initrd. Any other ideas how to get a shell? <dftxbs3e>raghavgururajan, maybe it doesnt need full path, I just tried and it works with just app-name <leoprikler>raghavgururajan: I just now noticed, that 12 has a broken commit message. In case you need to send a v19, drop the line "fixup tg-owt" <dftxbs3e>raghavgururajan, instead of "$ c", use "$ r", for run, then if it breaks for any reason besides segfault use "$ c" <dftxbs3e>leoprikler, can I somehow copy the 'configure phase? <mothacehe>civodul: thanks, the inferior is probably the one used by "channel-instances->derivation" in (gnu ci). <leoprikler>leoprikler: yes, use something like (lambda args (apply (assoc-ref gnu:%standard-phases 'configure) args) ) <leoprikler>raghavgururajan: in 0013, you should really add a comment for USE_PACKAGED_FONT as in my example, because it is a very confusing option *leoprikler compiles Guix to test telegram-desktop <efraim>the fcitx package that uses gtk2,gtk3,qt4,qt5, I'd drop gtk2 and qt4 from the list <civodul>efraim: i don't see qt in "guix show fcitx" <civodul>but there are two gtk+, and i agree it makes sense to drop one of them :-) <efraim>civodul: i mean for raghavgururajan's telegram patches <civodul>but yeah, in general, i'd keep only one toolkit, preferable gtk+3 <leoprikler>raghavgururajan: did anything else change between v18 and v19? <apteryx>is there a reason we're keeping *all* of rust version in the bootstrap chain? I'd expect some hops are possible. <apteryx>It's a waste of CPU and disk space usage, in my opinion, unless there's a good reason. <leoprikler>afaik each version requires the previous one, but you're welcome to try hopping <omnivg>Hi, I have a beginner's question regarding installing guix. I am running a foreign distro and performed the binary installation as described in the manual. I also would like to use emacx-guix (guix.el) to manage the system. Instructed by the README in guix.el, I installed guix and guile to my user profile (~/.guix-profile). Now, I am confused because the ~/.config/guix/currentbin/guix is shadowed by the newly installed <raghavgururajan>When I get a call, I get ringtone, but when I answer it, it seg-faults. So propbably while trying to access mic. <omnivg>Could anyone tell me the effect of this? <roptat>omnivg, that's not good, the guix in .guix-profile is older than the one in .config/guix/current <omnivg>roptat, yes it seems to be the stable version 1.2 ***str1ngs_ is now known as str1ngs
<roptat>yes: the one in .config/guix is the latest you pulled, and it defines a guix package. Since it cannot know of itself, that package is necessarily at least one commit earlier than what you pulled <roptat>if .guix-profile/bin/guix shadows the latest pull, next time you do "guix upgrade", it will use its own definition of guix, which is older than itself, so you'll keep downgrading guix without even noticing <roptat>that's the whole reason why we have a separate profile for guix pull <roptat>now I don't use emacs, so I'm not sure I can help, but I'd say you probably need to make sure .config/guix/current is first in $PATH <leoprikler>raghavgururajan: `gdb --args sh telegram-desktop` should do the trick <omnivg>roptat, Thanks! I understand. I will whether there're other ways of exposing the guile module to the emacs frontend. <leoprikler>then run until you hit the segfault and navigate the stack <raghavgururajan>okay crashed now. gdb says: --Type <RET> for more, q to quit, c to continue without paging-- *roptat just pushed the changes to switch to weblate \o/ <leoprikler>but it seems you have to look for the issue in tg_owt somewhere <leoprikler>#4 â #3 seems interesting, I believe something from there ends up being the thing that's copied <rekado_>roptat: very nice blog post! Thanks! <roptat>rekado_, that's not my blog post ;) *raghavgururajan is exhausted with telegram <retropikzel>I'm trying to build code in guix environment but it keeps complaining that "cc: no such file or directory". How can I add it into the environment? <leoprikler>raghavgururajan: If anything else fails, we can disable webrtc by setting DESKTOP_APP_DISABLE_WEBRTC_INTEGRATION=ON <retropikzel>avalenn, I have it, I just got it fixed. Fixed it in the makefile which should fine now <zimoun>roptat: on the Weblate instance, I do not see the âUploadâ section in the bottom of âFilesâ. After âCustomise downloadâ. Do I miss something? <roptat>zimoun, you need to be logged in <leoprikler>raghavgururajan: I can't recommend turning off shared libs in Guix. <roptat>retropikzel, most of the time you can pass CC=gcc to the Makefile <leoprikler>other than that, you can (peek make-flags) if you really need to <bavier[m]>will the website eventually be displaying synopsis and description strings on the "packages" page in the users chosen language too? <zimoun>roptat: yahoga! The process to create an account at some steps. :-) <roptat>well, compared to the TP, at least it's usual steps <rekado_>roptat: oh, right. Thanks to pelzflorian! <zimoun>yeah and the fancy interface is an invitation to contribute⊠the TP robot is⊠a dump robot. :-) <civodul>roptat: kudos for the weblate migration & to pelzflorian for the blog post! ***rekado_ is now known as rekado
<leoprikler>raghavgururajan: interestingly, my telegram-desktop build fails in kwayland, not tg_owt <leoprikler>I'd really suggest just disabling calls until they've definitively been fixed upstream <lfam>Hi vagrantc! I have a question for you :) <lfam>You have a better handle on the kernel variants being discussed there than I do <vagrantc>lfam: i'm of the opinion in general that anything anyone wants on any of the -generic kernels that doesn't interfere with the "linux-libre" kernels (e.g. no-op because already enabled) is a good thing <jonsger>hm, I cannot reach savannah from my server anymore. Its strange as it works on my desktop and on an other server... *jonsger thinks the problem is in front of the keyboard, but doesn't know what he broke ^^ <jonsger>ports 80 and 443 of git.savannah.gnu.org are closed from it... <vagrantc>lfam: as long as they're not platform-specific ... although even then, i wonder if the kernel config will just toss it out ... <lfam>jonsger: You might ask in #savannah <lfam>vagrantc: I think this option is useful for all the platforms <lfam>Although I suspect it's only intended for aarch64 <lfam>jonsger: I nmap-ed savannah once, twice in a row, and my IP was banned from all of gnu.org <lfam>So, it could be something like that, or it could be a cached DNS failure <vagrantc>lfam: in that aarch64 is currently the only other semi-serious architecture? :) <lfam>In that they specifically are talking about needing it for some arm64 kernel that I don't pay attention to :) <lfam>But yes, I agree with your point as well <lfam>I was also thinking that perhaps some enterprising Guix porters should apply for early access to the upcoming BeagleV RISC-V computer from BeagleBoard. They will be making them available to developers early <lfam>It would be nice if Guix System was supported when they were released. I bet there will be a small surge of interesting in this platform at that time <vagrantc>lfam: i was thinking of hitting up the beaglev when it's further along, and also will soon have access to a couple capable risc-v boards <vagrantc>in fact, one is sittle on the floor next to me right now <lfam>Do you think we'll be able to support them with a "regular" Guix kernel, or will we need to make some more of the device-specific packages? <vagrantc>risc-v has largely learned from the mistakes of arm, in that sense, a single kernel should probably work <vagrantc>though, for the "following upstream" there might still be value in a -generic kernel <lfam>Well, Guix will follow the lead of the person with patches ;) <vagrantc>if nothing else, diffing the hand-crafted kernel against the -generic one migh <vagrantc>i haven't ever tried bootstrapping a port ... that part seems a bit intimidating <lfam>Well, I think there will be people who want to help <vagrantc>main thing is the toolchains require even newer versions than the power9 stuff <lfam>So we'd need a fresh core-updates cycle to be ready? <lfam>Sorry if this has already been discussed, but it sounds like a good topic for the next Guix Days <lfam>The (currently virtual) Guix meeting / mini-conference <lfam>Oh, I'm sorry. I thought you asked "what is that" <vagrantc>i'll try to keep it in mind ... timezone skew makes it a bit hard for me to join many of these things <vagrantc>i'm sure there will be more announcements on the list before then <lfam>Yeah, I struggled with that too for the last Guix Days (East coast USA) <lfam>I see they mention "We will cover 12 hours to cater for Asia, Europe and the USA time zones. " <lfam>Hence the "cascadian", I suppose :) <lfam>I find it easier to stay up late than that get up early <apteryx>mrustc uses at some point 5 GiB of memory to build Rust 1.29! <lfam>Although, as I get older, I find that staying up late hurts more the next day than getting up early <vagrantc>lfam: oh, i didn't say anything about not hurting :) <thorwil>hi! the `guix` command suddenly stopped working (every argument is taken without effect). /home/thorwil/.config/guix/current/bin/guix points to /gnu/store/xa1xx4gpnvvf4wpzx63v1swl7gvqyw5d-guix-command <thorwil>which `file` tells me is empty! any idea how something like this can happen? <thorwil>meanwhile, `sudo guix pull` still works. is there any chance of repair short of installing guix anew? <lfam>Can you show `which guix`? <lfam>It's definitely possible to repair <thorwil>which guix -> /home/thorwil/.config/guix/current/bin/guix -> /gnu/store/xa1xx4gpnvvf4wpzx63v1swl7gvqyw5d-guix-command <thorwil>for root, guix is /gnu/store/wkxkx61cmgvl6jav05i8c8y5kd430qh3-guix-command <lfam>Is this problem for user 'thorwil' or 'root', or for both? <lfam>I reported something similar yesterday, although that was for the "default" profile for package installation, not the current-guix profie <thorwil>cani just change the symlink to have /home/thorwil/.config/guix/current/bin/guix point to the same? or are there sideeffects? <lfam>I recommend looking in '/var/guix/profiles/per-user/thorwil' and changing the symlink to point to the previous generation <lfam>That is the directory where profiles are managed from <lfam>Then, please send mail to my bug <lfam>It's weird. That store item you said is empty â that file exists but is zero bytes? <thorwil>yes, `file` just says empty, ls -s reports 0 <lfam>It would be great to get some more anecdata in that bug report. I'm not sure it's the same bug but is does share the similarity of "live profiles are missing / broken" <thorwil>i was just going to say it doesnât necessarily read like the same, but yeah, agreed <lfam>So, in '/var/guix/profiles/per-user/thorwil', you should change the 'current-guix' symlink to point the latest 'current-guix-NNN-link' profile that actually works <lfam>It's definitely suspicious that we both have broken profiles in the same couple days. It's not exactly a common bug <lfam>I'm curious, what filesystem are you using for /gnu and /var? I'm using ext4 with a 5.10 kernel <thorwil>ext4 on a new computer, barely a week old <lfam>Kernel version? `uname -a`? <lfam>Also, is it Guix System or Guix on another distro? <thorwil>foreign, Ubunttu Unity. kernel 5.8.0-38 <lfam>At least we know it's not a new kernel bu <lfam>Well, ubuntu could have backported the bug to their distro kernel :) <thorwil>heh! also funny that i dared to use btrfs on my data partitions, to have a file go (almost) poof on ext4! <lfam>It's *probably* not a filesystem bug <lfam>I use btrfs for /home but I use /gnu so heavily and I've been worried about performance there with btrfs <lfam>Anyways, after you change that symlink and get your Guix working again, please send your info to the bug thread <stikonas[m]>btrfs is alright... Especially if you do incremental backups <lfam>thorwil: The questions I asked should be answered in your reply. The history of your current-guix profile will also be important. You can use `guix package -p ~/.config/guix/current -l` to show it <vagrantc>debian now enables user namespaces by default ... that's more-or-less good news for getting guix running on debian *vagrantc suspects to see more test suite failures <thorwil>lfam: ok. still a bit puzzled by the structure in /var/guix/profiles/per-user/thorwil ... but iâll get there <lfam>thorwil: The 'current-guix' file is the profile updated by `guix pull`. The 'guix-profile' file is the default profile for package installation, like with `guix install foo` <lfam>The numbered variants of those files are the previous generations of those profiles <lfam>And these numbered profiles ultimately point to their "real" location in /gnu/store <lfam>I hope that helps! Please ask questions if you are stuck <thorwil>oh well: ln: failed to create symbolic link 'current-guix/current-guix-4-link': Read-only file system <lfam>Can you share the command you tried? <thorwil>`/var/guix/profiles/per-user/thorwil: ln -sf current-guix-4-link current-guix` <lfam>I think you need to reverse the arguments <thorwil>i even did `man ln` to reread that itâs target, link-name <lfam>I have etched "TARGET LINK_NAME" into my brain <lfam>That way, I only have to decipher what those words mean, every single time ;) <thorwil>order doesnât matter, it always claims read-only file system. it most definitvely is not <lfam>The error message looks weird, as if the two arguments are being concatenated into a single path <lfam>For example, this worked for my case: `ln -sf guix-profile-196-link guix-profile` <lfam>It's a different profile that broke for me, but the command should work the same way <lfam>Sometimes, a file-system becomes read-only in response to hardware errors. You might check in `dmesg` <thorwil>oh, so i had to move the existing current-guix out of the way. and here i thought the -f would take care of that! <lfam>Yeah, that's surprising! <thorwil>so basically: cd /var/guix/profiles/per-user/thorwil; rm current-guix; ln -sf current-guix-4-link current-guix <lfam>But it happened to me too with current-guix, although not with guix-profile <roptat>I've had empty files before, when ext4 tried to recover from a power failure <thorwil>heh yes, though it bothers me that i still donât know what it is that i do not know in this case! <roptat>but I don't think I've ever had files become empty in the store <roptat>the only times I had anything weird happen to my store were because of a corrupted fs <lfam>I was suspicious of changes in ext4 in Linux 5.10, but it seems unlikely that Ubuntu would have already backported them (or will) <lfam>I'm worried it's a Guix bug <thorwil>this machine hasnât seen any power failure, only clean shutdowns ... a few resets, though. <lfam>I wonder if "empty file" and "dangling symlink" (my problem) are caused by the same problem <roptat>what could cause both of them though? <roptat>I can imagine a bug in the gc causing a dangling symlink, but not an empty file <lfam>It could be something multithreaded exiting early. In my case, before the referent is created, and in thorwil's case, after the store item is created but before it is populated <thorwil>lfam: to reply to your bug, i simply send to 45992@debbugs.gnu.org right? <roptat>thorwil, has this generation ever worked? <lfam>Is there a command to list all store items that Guix knows about? I know about --list-live and --list-dead. Together, do they categorically list everything that is registered? <lfam>Or is there some sql query I can use? <roptat>from nix/libstore/local-store.cc <lfam>Indeed, my missing store item is not in the database <thorwil>scrolling back, i just notice that `sudo guix pull` led to several "removing corrupted link â/gnu/store/.links/xxxâ" <Kabouik>Hello #guix. I'm new to guix and still into the testing phase. Could anyone confirm that if I installed it using the guix-installer.sh script, deleting /gnu would delete everything guix related including installed packages and dependencies, or is there something else I would need to clean to start from scratch? <Kabouik>And is it safe to remove /gnu by the way? I think it's only guix-related, but never know. <Kabouik>Seems I cannot sudo rm -rf /gnu, it complains about being a read only file-system. <lfam>Kabouik: /gnu is only used by Guix, so removing it will only affect Guix <lfam>In general, there are quite a few other locations in the filesystem that are created by Guix <lfam>In order to start from scratch, you would also want to remove /var/guix, ~/.config/guix, ~/.guix-profile <thorwil>what is it with "read only file system" today? <lfam>The store (/gnu) is supposed to be read-only <roptat>you should be able to unmount it <lfam>This ensures that it can only be written to via the guix-daemon <roptat>it's mounted read-only to ensure you can't directly write to it and modify a store item yourself <lfam>There are other paths that are related to Guix, Kabouik, but they aren't as important to remove in order to "start fresh". For example, /etc/guix, which contains substitute signing keys <roptat>but if you want to remove guix entirely, just unmount it and remove the directory <Kabouik>Thank you, I'm removing the other folders. Not sure yet how to make /gnu rw though. <roptat>there's /etc/systemd/system/{guix-daemon.service,gnu-store.mount} too <Kabouik>(By the way it would be nice to have an --uninstall command option to guix-installer.sh, running rm -rf as sudo multiple times makes me a bit uneasy!) <lfam>One is less motivated to create the uninstaller ;) <roptat>plus a bunch of files in /usr/local <roptat>after all, why would you ever want to uninstall guix? ;) <lfam>There should never be a case where Guix breaks and must be removed completely and uninstalled. Maybe something goes wrong but we can always work through it with you <Kabouik>It's true it must be less motivating, but since several folders are being populated by the installer, getting back to a state prior to guix installation is not straightforward <lfam>It was discussed recently (I think on the mailing list?). There is energy to make it happen <lfam>I'd assume the installer also edits ~/.profile or ~/.bash_profile <Kabouik>tree /usr/local | grep guix makes me sweat :p <lfam>If you are trying to reinstall, I think you shouldn't worry too much about them <lfam>The important things are /gnu and /var/guix <Kabouik>I will do my tests within a LXC container instead, so would like to clean those files <Kabouik>But that's info files in /usr/local/share/info, shouldn't be big indeed <Kabouik>Am I right that this is safe to remove all those files in /usr/local/share/info since they seem to be only symlinks to /var/guix stuff? https://0x0.st/-itL.png <Kabouik>Thanks, let's move the whole info/ dir then <Kabouik>I'm sorry to flood the channel about how to remove guix! I really liked the tool, but don't want to do my tests on this machine. And unfortunately removing guix is not as easy as getting it ready with the install script. <roptat>check .bashrc and .bash_profile (and their /etc version too) for references to guix <roptat>not sure there is any, but just to be sure <Kabouik>I couldn't find anything, perhaps the script doesn't automatically echo to them <Kabouik>But guix did advise to run some export commands, so I assume my $PATH was just temporarily updated <Kabouik>Actually I might have missed one because now that I removed /etc/profile.d/guix.sh, bash is complaining when I start a new terminal <Kabouik>bash: /etc/profile.d/*.sh: No such file or directory <Kabouik>So I need to find what tries to load that <lfam>Also, try logging in again <Kabouik>There's indeed something in /etc/profile trying to load any .sh file in /etc/profile.d/, but it doesn't mention guix anywhere and the modification date is older, I can't tell if it was there before <lfam>It's a normal mechanism for extending /etc/profile <lfam>What I mean is that most (all?) distros will have it <lfam>I think the existence of that guix.sh file is probably cached by bash somehow, which is why I suggested logging in again <Kabouik>I tried logging in again (just with bash --login, not by restarting my full session) <surpador>So just installed espeak on guix system without any DE installed, and it seems really quiet. Might just be my speakers- is there any concept of a global volume setting other than espeak's own command line option for amplitude? And if so how would I change it? <roptat>Kabouik, if the directory is empty, maybe remove /etc/profile.d entirely (loading its content is probably guarded only by the existence of the directory?) ***iyzsong- is now known as iyzsong
***leoprikler_ is now known as leoprikler
<Kabouik>Uh oh, I can't log into my user session anymore. lightdm is just flashing black and then shows the logon screen again <Kabouik>Ok, got into tty, it fails because no *.sh file in /etc/profile.d. Will try what you recommended roptat <roptat>or you could add a blank .sh file there <roptat>but it's weird the directory is empty <Kabouik>Phew, thanks a lot. Quite a scare there. <roptat>I have 36 files there, including guix.sh (on Fedora) <Kabouik>I really had no other file than guix.sh and I checked my command history, I just removed guix.sh <surpador>leoprikler: No. I don't know anything about pulse but there doesn't seem to be a pulseaudio process running <Kabouik>I have other .sh files in /usr/local/defaults/etc/profile.d, but I am assuming there was not active anyway. Or guix-installer.sh removed them somehow? <Kabouik>I am a noob, don't get me wrong, but I guess this supports that a graceful uninstallation of guix with the script would be great for people like me <Kabouik>And those sudo rm -rf never feel great <Kabouik>Anyway thanks a lot for the help! I'll keep guix in an installer for now, to get more familiar with it <roptat>well, it also supports that writing an uninstaller is not an easy task :p <leoprikler>surpador: in that case you might be talking "directly to hardware" through alsa <lfam>Right, and in that case, you'd want to check the volume levels with alsamixer <lfam>There's also espeak-ng in case the espeak package is starting to work poorly <surpador>Ah ok thanks! Looks like I didn't have alsa-utils installed so now that I do I'll take a look through those 