IRC channel logs

2021-01-20.log

back to list of logs

<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
*lfam brb
<jgart[m]>It would be nice to have this surf kiosk as a service in guix system: https://search.nixos.org/options?channel=20.09&show=services.xserver.desktopManager.surf-display.defaultWwwUri&from=0&size=30&sort=relevance&query=surf-display
<jgart[m]> https://github.com/NixOS/nixpkgs/blob/nixos-20.09/nixos/modules/services/x11/desktop-managers/surf-display.nix
<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]>paulj: One way is to create a git repository with your changes to config.h and then to create a package definition for it as I did here with Luke Smith's st fork: https://gitlab.com/libremiami/guix-packages/-/blob/master/packages/st-luke.scm N.B. I should have probably inherited from gnu packages suckless #:select dwm. I'll refactor it soon. I wouldn't recommend this option if you want to work with patch files. I'm treating
<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>Hi all, I would like to once more bring up ZFS on Guix. http://issues.guix.gnu.org/45692 http://issues.guix.gnu.org/45722 http://issues.guix.gnu.org/45723 http://issues.guix.gnu.org/45734
<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
*jgart[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/HaXmeAlkmTvXaiCxbynNWRzL/message.txt >
<raid5atemyhomewo>jgart[m]: sure, though I do not have a PGP key yet
<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...
<raid5atemyhomewo>thank you
<jgart[m]>there you go! awesome!
***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>Hello Guix!
<raghavgururajan>leoprikler: Do you want me to remove recursive on telegram-desktop as well?
***jgart[m] is now known as jgarte[m]
<leoprikler>That was my point, was it not?
<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")
<PurpleSym>True, will try that.
<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
<sundbry>because no stdin
<leoprikler>raghavgururajan: ah, no, that was probably directed at someone else
<raghavgururajan>Oh shoot. Okay, I'll send a v16 soon.
<leoprikler>v17?
<raghavgururajan>Ah yeah, v17.
*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>if I press tab, nothing happens
<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`
<mothacehe>abcdw: yes same behaviour here
<mothacehe>it's probably indented "by-hand"
<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.
<mothacehe>nope fixing it would be nice
<leoprikler>to fix it, simply add a newline after build
<leoprikler>but first pull ;)
<raghavgururajan>What is the command to clear substitute cache?
<mothacehe>rm -rf /var/guix/substitute/cache/*
<abcdw>leoprikler: ok, it works, thank you)
<raghavgururajan>thanks
<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?
<liltechdude>how to fix this http://paste.debian.net/1181882/ ?
<abcdw>sad, but ok, will be importing by hands) Doesn't look like unsolvable problem, but not the easiest one)
<raghavgururajan>leoprikler: I have sent v17. :-)
<liltechdude>why python3 look for library in python2?
<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?
<liltechdude>this is a recipe for brocken package http://paste.debian.net/1181883/ that i import with `guix import`
<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
<rndd>rekado_: thank you
<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).
<raghavgururajan>Cool!
*rekado_ updates CRAN packages
<leoprikler>If no one else weighs in, you can also push v18 (see my change requests) on Feb 3rd + delta.
<raghavgururajan>me? I don't have push rights.
<leoprikler>Ah, okay, then I'll do that in your stead.
<raghavgururajan>Thanks!
*mothacehe is trying to reproduce the Cuirass "guix-master" evaluation issue locally
<mothacehe>oh I can reproduce it, there's a hidden exception in "guix repl -t machine", which is probably an inferior: https://paste.debian.net/1181892/
<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>hmm https://ci.guix.gnu.org/eval/38787/log/raw is empty, and /var/log/cuirass/evaluations lacks the logs
*civodul launches "make cuirass-jobs", goes have lunch
<mothacehe>will do! looks like this one is swallowed
<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>extended trace here: https://paste.debian.net/1181899/
<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?
<leoprikler>liltechdude: vorbis-tools
<liltechdude>thanks!
***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>but either solution I am interested
<dftxbs3e>chdir where?
<leoprikler>after unpack
<dftxbs3e>before 'unpack and it'll work?
<dftxbs3e>oh yes after
<dftxbs3e>will try this thanks
<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?
<raghavgururajan>How to backtrace a seg-fault?
<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)
<raghavgururajan>ah thanks
<dftxbs3e>raghavgururajan, you need debug symbols so it's the most useful
<civodul>mothacehe: well done!
<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
<dftxbs3e>so forget me
<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?
<dftxbs3e>(and others)
<mothacehe>civodul: thanks, the inferior is probably the one used by "channel-instances->derivation" in (gnu ci).
<raghavgururajan>dftxbs3e, thanks@
<raghavgururajan>leoprikler: Oh okay.
<leoprikler>leoprikler: yes, use something like (lambda args (apply (assoc-ref gnu:%standard-phases 'configure) args) )
<dftxbs3e>leoprikler, thanks a lot!
<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
<raghavgururajan>Sure!
*leoprikler compiles Guix to test telegram-desktop
<civodul>mothacehe: yeah, i'm on it
<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>efraim: ah sorry, haven't seen them
<civodul>but yeah, in general, i'd keep only one toolkit, preferable gtk+3
<leoprikler>raghavgururajan: did anything else change between v18 and v19?
<leoprikler>efraim: which package do you mean?
<raghavgururajan>leoprikler: I updated versions.
<raghavgururajan>telegram-desktop v2.5.5
<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
<apteryx>will do
<raghavgururajan>leoprikler: telegram-desktop seg-faults on answering calls.
<leoprikler>since v20 or earlier versions as well?
<raghavgururajan>latter
<raghavgururajan>It tried updating to v2.5.5 to see if it fixes it. but no.
<leoprikler>perhaps a missing input?
<raghavgururajan>I think something to do with accessing mic.
<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
<omnivg>~/.guix-profile/bin/guix
<raghavgururajan>When I get a call, I get ringtone, but when I answer it, it seg-faults. So propbably while trying to access mic.
<pineapples>Uh oh, a Telegram issue I presume?
<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
<leoprikler>raghavgururajan: good ol' gdb
<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
<raghavgururajan>leoprikler
<raghavgururajan>oops
<raghavgururajan>I am trying to use gdb, but keep failing.
<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
<raghavgururajan>pineapples, yeah. crashes on answering calls.
<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>Reading symbols from sh...
<raghavgururajan>(No debugging symbols found in sh)
<raghavgururajan>(gdb)
<leoprikler>run
<raghavgururajan>okay crashed now. gdb says: --Type <RET> for more, q to quit, c to continue without paging--
<raghavgururajan>Should I do c?
<leoprikler>ret, then up
*roptat just pushed the changes to switch to weblate \o/
<roptat>and we have a blog post too: https://guix.gnu.org/en/blog/2021/adding-translations-to-guix-website/
<raghavgururajan>leoprikler, https://paste.debian.net/1181927/
<leoprikler>interesting
<leoprikler>you can go up a few steps to see the call stack
<leoprikler>but it seems you have to look for the issue in tg_owt somewhere
<raghavgururajan>leoprikler: https://paste.debian.net/1181928/
<leoprikler>#4 → #3 seems interesting, I believe something from there ends up being the thing that's copied
<pineapples>Anddd this here is beyond my debugging skills
<leoprikler>How did you even figure that other thing out?
<rekado_>roptat: I think it should be “Guix’s” instead of “Guix’”; https://ell.stackexchange.com/questions/6295/when-a-word-ends-in-s-or-x-do-you-add-s-or-just-an
<leoprikler>english is weird, x's looks so wrong imo
<rekado_>roptat: very nice blog post! Thanks!
<roptat>rekado_, that's not my blog post ;)
*raghavgururajan is exhausted with telegram
<raghavgururajan>leoprikler: Help! 😵
<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
<avalenn>guix environment --ad-hoc gcc ?
<zimoun>roptat: nice blog post!
<leoprikler>you probably want gcc-toolchain though
<raghavgururajan>leoprikler: You mean disable calls?
<retropikzel>avalenn, I have it, I just got it fixed. Fixed it in the makefile which should fine now
<retropikzel>Thanks :)
<leoprikler>If anything else fails, yes
<raghavgururajan>leoprikler: https://github.com/telegramdesktop/tdesktop/issues/10182
<raghavgururajan>the last comment. Do you know anything about it?
<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?
<roptat>bavier[m], that would be nice
<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!
<roptat>thanks :)
***rekado_ is now known as rekado
<leoprikler>raghavgururajan: interestingly, my telegram-desktop build fails in kwayland, not tg_owt
<vagrantc>howdy guix!
<leoprikler>I'd really suggest just disabling calls until they've definitively been fixed upstream
<lfam>Howdy
<lfam>Hi vagrantc! I have a question for you :)
<lfam>Can you decide about <https://bugs.gnu.org/45998>?
<lfam>You have a better handle on the kernel variants being discussed there than I do
<raghavgururajan>leoprikler: That's odd.
<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
<lfam>Alright
<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
<lfam> https://beagleboard.org/beaglev
<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
<lfam>Oh, that's great news!
<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
<vagrantc>e.g. upstream maintains the defconfig
<lfam>Right
<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>t be useful
<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>Ah
<lfam>So we'd need a fresh core-updates cycle to be ready?
<vagrantc> https://wiki.debian.org/RISC-V#Toolchain_upstreaming_status
<lfam>Sorry if this has already been discussed, but it sounds like a good topic for the next Guix Days
<vagrantc>when is that?
<lfam>The (currently virtual) Guix meeting / mini-conference
<lfam>Oh, I'm sorry. I thought you asked "what is that"
<lfam>facepalm
<vagrantc>heh :)
<lfam>There's one around FOSDEM: https://libreplanet.org/wiki/Group:Guix/FOSDEM2021
<lfam>So, February 8
<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. "
<vagrantc>lfam: west coast here, so even worse :)
<lfam>Oof
<lfam>Hence the "cascadian", I suppose :)
<vagrantc>i just pulled an all-nighter :)
<lfam>I find it easier to stay up late than that get up early
<jonsger>+1
<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 :)
<lfam>Heh
<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>thorwil: Hm...
<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
<lfam>Okay
<thorwil>for root, guix is /gnu/store/wkxkx61cmgvl6jav05i8c8y5kd430qh3-guix-command
<lfam>Is this problem for user 'thorwil' or 'root', or for both?
<thorwil>only for thorwil
<lfam>Okay
<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> <https://bugs.gnu.org/45992>
<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>Does that make sense?
<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>Okay
<lfam>At least we know it's not a new kernel bu
<lfam>bug
<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>Heh
<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
<lfam>🤷
<lfam>Adventures with UNIX
<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
<lfam>Exactly thorwil!
<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>Agreed
<lfam>I'm grasping at straw
<lfam>s
<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?
<lfam>Yes thorwil
<lfam>Thanks a lot!
<roptat>thorwil, has this generation ever worked?
<thorwil>lfam: nah, i thank you! :)
<thorwil>roptat: i’m not sure.
<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>select path from ValidPaths
<roptat>from nix/libstore/local-store.cc
<vagrantc>hah, RISC-V was already mentioned at https://libreplanet.org/wiki/Group:Guix/FOSDEM2021 and i added a duplicate
<vagrantc>so much for reading what i edited... :)
<lfam>It's a good problem!
<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>I'm guessing ~/.guix too?
<Kabouik>And is it safe to remove /gnu by the way? I think it's only guix-related, but never know.
<Kabouik>Found that list of folders to remove: https://lists.gnu.org/archive/html/help-guix/2019-05/msg00106.html But I don't know if it's exhaustive.
<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.
<thorwil>umount /gnu/store?
<roptat>there's /etc/systemd/system/{guix-daemon.service,gnu-store.mount} too
<roptat>yes
<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>or test it :p
<lfam>True
<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>Why is that?
<roptat>they're all just symlinks
<Kabouik>A lot of matches
<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
<roptat>yep
<Kabouik>Thanks, let's move the whole info/ dir then
<Kabouik>I found /etc/profile.d/guix.sh too
<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>Kabouik, it's fine :)
<roptat>you can delete that file too
<Kabouik>I did, yes
<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
<lfam>Right
<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>Check /etc/profile
<lfam>Also, try logging in again
<lfam>`bash --login`
<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)
<Kabouik>Maybe I should try that
<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?
<leoprikler>do you have a pulseaudio process running?
<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>And tty stays black
<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>That was it roptat
<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
<roptat>alright, that's fine then
<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>s/there was/they were
<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
<Kabouik>in a container*
<roptat>well, it also supports that writing an uninstaller is not an easy task :p
<Kabouik>Indeed :>
<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