<gnutec>mange: It's because there is no link to manual for guix in guix site. But here it is. guix.gnu.org/manual/en/ <gnutec>vixus: Do you have the guix manual? guix.gnu.org/manual/en/ <gnutec>Now, in guix SD, the Network Manager "generating" DNS to /etc/resolv.conf. ***CcxWrk_ is now known as CcxWrk
<Franciman>hi, so I have an issue with guix import crate <Franciman>I try to import a package, I use guix import crate getopts --recursive <Franciman>but at some point I receive an error regarding the certificate of crates.io <Franciman>I thought this may be the case that I make too many requests to crates.io which bans me <efraim>yeah, sometimes you just need to restart it <sneek>civodul, you have 1 message. <sneek>civodul, raghavgururajan says: nckx mbakke After removal of ungoogled-chromium from guix, is there a viable replacement that can be an alternative to icecat, by having a different rendering engine from icecat? I have seen some web pages performing differently between web-engines gecko and blink. :-) <rndd>hi everyone. I use guixsd with gnome and I have some issue with sysmbols in gnome aps. Some words are [][][][], some icons just empty frames. I had this issue in nixos, and I fixed after installing some gnome packages. Does annybody know what I need to install using guix? <sneek>Welcome back rndd, you have 1 message. <rndd>nckx: thanks for this link =) <leoprikler>at least on my machine, symbols displayed fine after refreshing it <efraim>After changing the way rust works I really should work on combining the two rust importer parts into something that works with the new system :/ <vup>efraim: will the new rust stuff still use cargo to compile everything or actually compile dependent crates in a seperate step? <efraim>vup: It'll still use cargo to compile everything. Rust doesn't have a good story when it comes to compiling intermediate crates so we're now just treating them as shared sources instead of shared libraries. <efraim>well, compiling intermediate crates works, using those compiled crates takes planning ahead of time by upstream, and very few of them do it unless they have a project which combines together a few of their own parts <vup>Yeah i know, but recompiling bigger rust programs takes quite long this way <vup>Also for nix there is carnix so in theory it should be possible to replicate that in guix <reepca>Hm, murmur (the mumble server) seems to fail to start, and logs this message: murmurd[13859] general protection fault ip:7ff811d672f1 sp:7ffc009d8670 error:0 in libQtNetwork.so.4.8.7[7ff811ca6000+ca000] <reepca>I'd assume so, that's what is listed in its inputs and what ldd says murmurd links to <reepca>that's interesting, it's a different qt from the one produced by "guix build -e '(begin (use-modules (gnu packages qt)) qt-4)'". Which is the one listed in mumble's inputs... <civodul>vup: it'd be great if you could contribute to the crate importer that comes with Guix! <vup>civodul: yeah i am planning to, just need to get a bit more acustomed with scheme <reepca>"warning: 'qt' is deprecated, use '(quasiquote qtbase)' instead". <raingloom>is something up with claws-mail? it doesn't seem to remember which emails i've already read. it's getting tiring. is it something to do with the purging of stateful directories on startup? <reepca>ah, never mind regarding mumble's qt reference - I forgot about grafts <Tirifto>Question: Where might Icecat need to get its fonts from? I'm trying to get Icecat installed with Guix to run inside Firejail on Parabola, and I got it to run, but it shows me tofu in place of letters. <Tirifto>I previously had this issue when running Icecat normally, but installing fonts in Guix and running fontconfig (or whatever the command was) solved the issue, so I'm thinking Firejail might be restricting access to some places Guix-installed Icecats needs access to. <nckx>Tirifto: Have you installed font-gnu-freefont-ttf into the same profile as IceCat (and run fc-cache -r)? <nckx>That's the only common IceCat tofu problem+fix of which I'm aware. <Tirifto>nckx: ‘guix package -I’ should tell me that, right? <Tirifto>nckx: Well, works when ran normally, but Firejail still can't get them. <nckx>Tirifto: Never used Firejail I'm afraid. <Tirifto>The file ‘icecat.real’ is present, but I'm not sure what the appended colon with number signify. <nckx>Tirifto: Line numbers (the convention is <file name>[:line[:column]]). <raghavgururajan>Something wrong with NetworkManager after upgrading system just now. 1) Even after turning off the WiFi, the connected icon appear on nm-applet (gnome). 2) I have configured to automatically connect to VPN via nm-connection-manager; but VPN does not connect/appear. <leoprikler>So you are not connected via cable and also not connected via WiFi. However, it appears as if you are connected via WiFi and VPN does not connect. <leoprikler>Would VPN connect if WiFi was enabled, or does it never work? <raghavgururajan>leoprikler Yes, it appears as connected even though I turned off my WiFi. VPN is separate issue, when I turn wifi back on and connect to my home network, vpn is not automatically getting connected (as I configured it to do so in nm-connection-manager). <raghavgururajan>leoprikler nckx Okay, so it seems like issues are with indications/appearance. All the follwowing happened after recent system upgrade. 1) When WiFi is off, it appears/shows to be connected on nm-applet. 2) When I turn back WiFi on and connected to home network, both WiFi and VPN gets connected in background (I configured to automatic vpn connection in nm-connection manager), but only WiFi is shown i <raghavgururajan>n nm-applet as connected. I check VPN connection by testing at ipleak.net. 3) The whole VPN menu in nm-applet has disappeared. <nckx>raghavgururajan: Sure it wasn't just split over 2 lines above? <nckx>Anyway, that commit includes the fix, so it would be good to know if your previous (working) nm-applet was an older version or not. <raghavgururajan>leoprikler nckx [...] but only WiFi is shown in nm-applet. I tested vpn via ipleak.net. 3) The whole VPN menu disappeared from nm-applet. <nckx>Yes, that had already been sent. <nckx>Long messages are simply split across multiple lines, the line above ‘guix 0b3ec89’ was ‘<raghavgururajan> n nm-applet as connected […]’ <nckx>Ugly but it works 🙂 Sounds like your client's a bit broken then. <raghavgururajan>nckx Oops! I garbage collected before doing the upgrade :( So I can't check whether I was using older version right? <leoprikler>the older version should not be gc'd if you can still roll back to it <raghavgururajan>I am using XMPP-IRC Bridge (Biboumi) Service provided by Disroot at irc.disroot.org. So I am messaging from Gajim. <nckx>raghavgururajan: Depends on what you gc'd. ‘guix package -l’ will show previous user profile generations, if that's where you've installed nm-applet. <raghavgururajan>leoprikler Ah I see. Let me check what commit my previous generation was. <raghavgururajan>nckx Before I upgraded the system and user, I did 1) `guix package --delete-generations` && `guix gc --delete-generations` as user 2) `guix system delete-generations` && guix gc --delete-generations` as root. <nckx>leoprikler: It wouldn't surprise me if IRC had a line length limit (say, 255) and relies on clients to split longer lines, leading to implementation-specific fun. <raghavgururajan>It is good that I did not go `guix system delete-generations` after the upgrade. So there is atleast one old generation left. <nckx>raghavgururajan: ‘Douse the crime scene in bleach and set in on fire’ OK. Not much left to investigate. <nckx>raghavgururajan: But is it the known-good one? <nckx>OK, which Guix commit created the good times? *nckx doesn't know the command to find that out. *nckx just looks at /var/guix/profiles directly. *nckx also has to go AFK for social times, good luck. ***ng0_ is now known as ng0
<raghavgururajan>nckx leoprikler Yessss!!! Bash history. I usually do not do just `guix pull`. I do `guix pull --commit=[...]` *raghavgururajan is checking root profile's bash history to find out the commit. <raghavgururajan>nckx leoprikler Gotcha! The old good generation was on commit "fd423e4". :-D <nckx>raghavgururajan: …oh. Damn. That's long after I last touched network-manager-applet. There goes my hypothesis that I was somehow to blame (and an easy fix). I'll read your further debugging adventures later. *nckx mutes their laptop this time 😊 *raghavgururajan will be right back after reboot <frantellato>Hello Guix, I'm setting up grub for a dual boot. I was wondering: how can I find the filenames for the "linux" and "initrd" sections of a menu-entry? I have grub-efi as a bootloader but I can't find anything like "vmlinuz" in my /boot/efi. <frantellato>Maybe I shoud point out that I'm doing all of this via the Guix configuration system. <leoprikler>frantellato: you enter the respective values of the foreign system <frantellato>Ok but how can i find them without booting Debian (that's the dualbooted distro i'm using) <frantellato>should i just mount debian partition and "find / -name vmlinuz" ? <leoprikler>then you probably want to use the "device" field <leoprikler>if e.g. your guix system is on /dev/sda1 and your debian on /dev/sdb1 <leoprikler>"device" would be the label or UUID of /dev/sdb1 <leoprikler>and then you have to look there for linux and initrd <frantellato>So being my partition layout shared-boot -> guix-root -> shared-store -> debian-root -> swap -> shared-home, I should just set the UUID of the device field to debian-home's UUID and search in /dev/sda4 for vmlinuz and initrd right? <leoprikler>assuming debian-root lives on its own partition, yes <leoprikler>(since you can mount debian-root everywhere, not just as /shared-boot/guix.../debian-root) <leoprikler>if debian-root was just a folder on the same device as GRUB, you'd have to enter the full path <fps_>did anyone consider using systemd instead of herd? ***fps_ is now known as fps
<frantellato> I think I did it http://paste.debian.net/1113394/ , the system is now reconfiguring. Also I have another question even if it's not that related. How often am i supposed to run "sudo guix pull" just once after installation or every now and then just as guix pull ? Does guix pull update even the system's guix? <leoprikler>there is a (imo misleading) warning message on reconfigure if you don't do it at least once <leoprikler>but if you do "sudo guix system ..." after a normal "guix pull", you will use your own guix and not root's <fps>this suppression of search results if not piped is hugely annoying <fps>[of guix package -s] <fps>is there a way to toggle that behaviour off? <leoprikler>you could write a shell command, that does guix package -s ... | lolcat :) <fps>personally i think this behaviour is as non-unixy as possible.. i'll report it as a bug ;) <fps>if people want to page the results, nothing is stopping them <fps>suppressing results if not piped is definitely not the unix way <fps>imaging grep worked like that <leoprikler>if you don't suppress the output, the package on the bottom (the one you see as the result) will be the least relevant <fps>-- only showing lines 1-10 if you want to see more please pipe through less <fps>the relevancy calculation has never been any help to me yet <fps>i _always_ have to pipe through less <raghavgururajan>fps `guix package -s` program is not viwer. There are instances where the output will go out of screen full. Anyway, you will have to use viewer like more or less. <leoprikler>I rarely have to pipe to less, but if I do, it's likely that the search term was too generic. <fps>systemd's utilities at least have a --no-pager option <fps>but the default is still the wrong way around <raghavgururajan>fps Two programs `guix package` and `less` are doing one thing and that one thing well. They can be piped for diffrent outcome. I would say this unixy. :-) <fps>raghavgururajan: yes <fps>i'm not arguing agains less <fps>i use it all the time <fps>i'm arguing against supressing results if not piped <fps>how is it not totally obvious that that is the wrong thing to do if one has _any_ unix experience <fps>the sharp wording was not in bad spirit, but just to be clear ;) <raghavgururajan>fps leoprikler Yeah, `guix package -s` does not have to supress the output. If it goes out of screen full, one can use pipe with less. I think fps is correct here. <leoprikler>How is it obvious regardless of Unix experience? <fps>it's making assumptions about what the user wants to do with the output <fps>instead of just providing the output <raghavgururajan>> fps: it's making assumptions about what the user wants to do with the output <leoprikler>not doing that would be making the opposite assumption <fps>filtering in a particular way as opposed to not filtering at all <fps>which makes more assumptions? <leoprikler>filtering assumes, that you're going to use a pipe if the result you wanted doesn't show up and you're able to read the note <leoprikler>the last part of this assumption is implied by the first <leoprikler>not filtering assumes that you're going to use a pipe when you're bombarded with too much info to scroll in a meaningful way <leoprikler>but does not provide you with the hint that this option exists <fps>you could also use | more <fps>or you could pipe into a file <fps>or pipe over netcat to a remote server <fps>the possibilities are limitless <fps>why should guix -s teach people shell basics? <fps>did you talk to any users of accessibility functionality? <leoprikler>it has Emacs, but people who use Emacs won't have problems with command line interfaces <fps>it's not documented, it's not configurable, it annoys the hell out of me <fps>it breaks the principle of least surprise <fps>it's alien in a unix environment <leoprikler>functional package management itself is already more alien to what most people would consider unix <fps>actually it's really orthogonal to the good parts of unix :) <leoprikler>hell, FP itself is already alien to lots of programmers, who have to discover its features twenty years in the future <raghavgururajan>> leoprikler: functional package management itself is already more alien to what most people would consider unix <fps>if you want to provide such a result limiting functionality add a commandline switch --limit N <fps>then people can alias it and be happy <fps>or a distro might even alias it by default <leoprikler>raghavgururajan: thanks, but that is really up to interpretation <leoprikler>but since we're on the topic of core unix principles <fps>guix package -s is supposed to search through the synopsis and description of all packages and output them if they match <fps>if a package's description or synopsis mtches the regular expression it should be output <raghavgururajan>Yeah, FPM can never produce unnessary output, because of it's mathematical design, output is purely based on input. Correct? <leoprikler>raghavgururajan: that's not a breakage of unix principles, I use this as argument for the current behaviour of "guix package -s" <leoprikler>if you do guix package -s gnome for example, "all matches" would very likely be unnecessary <fps>if it limits the output it is _not_ showing what it is supposed to show <fps>not doing what's necessary <leoprikler>guix as a whole is also certainly not a filter :) <raghavgururajan>leoprikler fps I think we are going in circles. In simplest terms, `guix package -s` should give it's *raw* output. In this way, raw output can be piped with another program of *choice* for *desired outcome*. <fps>yep, filtering should be left to other tools <leoprikler>filtering N packages via pipe is harder than | cat <fps>i would even go further: even having a regex seaarch over a particular choice of fields is less useful than a generic query over the package db <fps>i'd love to have a guix package --show=name <fps>and it shows me all package names <raghavgururajan>If am executing `ls`, I am execpting it show all the output. What I want to see should *not* be decided by the program, it should be done by the user. Same applies here. :-) <leoprikler>ls decides to hide files leading with a dot by default... <leoprikler>and you have to explicitly specify -a to show them <leoprikler>ls also has tab-delimited output instead of line-delimited when outputing to console, but switches to lines in certain cases <leoprikler>again a DECISION OF THE PROGRAM DUN DUN DUUUUUUUUUUUN *raghavgururajan ran out of thoughts xD <leoprikler>GCC decides to accept C programs, that are not ANSI C. <leoprikler>It's where those assumptions clash with user expectations, that this becomes a problem. <fps>how much code do you have to write to not filter though <leoprikler>And different users have different expectations. <fps>none, the choice on how to filter is left to the user <fps>i'm not arguing against providing tools that do more magic <fps>but they should be optional <leoprikler>a package manager which forces you to implement custom filtering in sh is not that <fps>nah, we just have to agree to disagree <fps>you're wrong though :)) <leoprikler>or grep, hiding all the lines starting with "relevance" if that annoys you ;) <mbakke>uh oh, www.x.org seems to have been taken over by spammers <Franciman>hey I have a new issue. I reinstalled guix system <Franciman>I have this message shown when I run a guix command: <Franciman>hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining <Franciman> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" <Franciman>but I read that I shouldn't anything on a guix system <Franciman>this is only needed when using guix on a foreign distro <nckx>fps: ‘filtering should be left to other tools’ — so… recutils? <fps>nckx: at least it should be optional <nckx>Can't agree, good thing we don't have to. How does ‘guix package -s . | recsel -p name’ not do what you want? <nckx>We could further improve that if needed. <fps>nckx: i can also do grep name: <fps>that's besides the point. all i'm arguing against is supressing output if not piped <nckx>Heh. So have I, but it wasn't worth my time. <fps>do you happen to know what the argument in favor was that swung the tides? <nckx>Nope. I don't even remember if it was here or via mail. <nckx>I agree with your opinion, but ‘it's not Unix’ isn't going to sway anyone. Unix sucks. <anon987321>how am i supposed to install a specific version of a package? <fps>nckx: yeah, you're right on that regard <nckx>fps: I just added a shell alias (or wrapper, even that I've forgot). <nckx>anon987321: You can only install versions explicitly in Guix, though, and Guix is not in the habit of packaging multiple versions of packages like other distributions. <nckx>So if foo@1.3 is in Guix, chances are slim that ‘guix install foo@1.2’ will work. <fps>it would be awesome though if that could be made easier :) [installing different versions] <fps>i would reckon that often just substituting the version string and ignoring the hash might lead to a usable result <nckx>fps: [How] do tools that, for example, auto-less output (like systemctl IIRC) allow users to opt out? <fps>in journalctl and systemctl you have a --no-pager option <fps>they use a pager by default <fps>which is equally annoying <nckx>fps: Right, but that's as annoying as adding ‘| cat’ after guix. No environment variable or anything? (Setting PAGER=cat doesn't count 😉 ) <nckx>anon987321, fps: For package versions not ‘in Guix’, --with-source and other transformation options might get you most of the way there. ‘guix install foo@whatever’ might be a bit *too* magical and inviting bad practice. Dunno. <nckx>It seems like the kind of bazooka so heavy that it can only be aimed at the foot. <efraim>looks like we have two very similar bash-*-pgrp-pipe.patch files on core-updates <efraim>well, I can confirm that scroll works as a pager <efraim>from joey hess for a 7 day roguelike ***modula is now known as defaultxr
<nckx>Package it and set it as the default pager on Guix System. <efraim>GHC is a big dependency though :( <nckx>Sacrifices must be made. <mbakke>efraim: IIRC you mentioned a couple of other qtbase packages failing to build similar to qtwayland, do you remember which? <efraim>qtgamepad? I think they were all leaf packages <efraim>grep define-public gnu/packages/qt.scm | cut -f2 -d' ' | grep ^qt | sed -e '/qt-4/d' | sed -e '/qt$/d' | sed -e '/qtwebkit/d' | xargs ./pre-inst-env guix build --no-grafts --keep-going <vixus>For some reason, I can't get rid of gdm from %desktop-services in my system config <vixus>I've got (remove (lambda (s) (eq? (service-kind s) gdm-service-type)) %desktop-services) where just %desktop-services used to be <efraim>hmm, I'm getting glibc-stripped failing on bootstrap-tarballs on master <leoprikler>that does look like the example in the manual, with service shortened to s <leoprikler>do you also have (use-modules (srfi srfi-1)) somewhere? <vixus>leoprikler: Hmm, no, I have (use-modules (rnrs lists)) *raghavgururajan had to file multiple bug reports today <vixus>leoprikler: Oh yeah you might be right <vixus>rnrs remove takes an object, not a predicate <vixus>Ha, well GDM did not like that <vixus>Is there a way to stop everything logging to my currently active TTY? <leoprikler>I don't know of any other than switching to tty2 after messages have stopped <vixus>I'm guessing when I install a package like sway, guix won't provide things like the example config or background image in the store <vixus>Not really sure how to check <vixus>Oh no guix please stop making weird noises at me D: <vixus>Seems like anything to do with graphics starts causing weird stuff to come out of the speakers <pkill9>sneek later tell vixus sway's example config is in <sway-package>/etc/sway/config <nunzarius>Hi, I was having trouble with install script. It asks me to get an openPGP public key. After getting the public key the script still complains that I don't have it. <mange>Hmm, that's strange. What's the exact error message you're getting? And what command did you run to get the public key? <nunzarius>Missing OpenPGP public key. Fetch it with this command: <nunzarius>i used that command. It disliked when I ran it with fish so I switch to bash and it seemed like it worked <nunzarius>gpg: key 090B11993D9AEBB5: 126 signatures not checked due to missing keys <nunzarius>gpg: key 090B11993D9AEBB5: "Ludovic Courtès <ludo@gnu.org>" not changed <nunzarius>gpg: key 090B11993D9AEBB5: "Ludovic Courtès <ludo@gnu.org>" not changed <mange>Did you run that command as your normal user? I think you might need to run the wget/gpg command as root so when you run the install script as root it can see the public key. <nunzarius>I tried running it as sudo but that didn't seem to change anything. The script still fails in the same way. <lfam>nunzarius: Try running it as root, not with sudo. Do `sudo --login` and then try all the commands again <lfam>Just using `sudo` doesn't make you root