IRC channel logs
2019-09-10.log
back to list of logs
<quiliro>Emacs Magit and on Emacs shell don't dispaly special characters (such as ñ, í, ó). But they are displayed correctly on afairs such as openning a file with those characters. With 'emacs -Q' I did not have that problem. But when copying .emacs.d to another directory, setting that directory as HOME and running emacs with 'mkdir ~/temp', 'cp ~/.emacs.d ~/temp/' and 'HOME="~/temp" emacs', it would not use my configurations. But it would not <quiliro>have the problem with Emacs shell. Emacs Magit would not be available. The same situation with 'emacs -Q' as with 'HOME="~/temp" emacs'. <rekado_>vagrantc: multiple machines can use the same store only if write requests are serialized through a shared daemon. <rekado_>that’s essentially how the cluster deployment at my institute works <quiliro>is this something i should report on the mailing list or is it something trivial? <rekahsoft>nckx: Sorry for the slow response; I searched for `fzf` and found nothing. Should have searched for `.*fzf.*`, as the package is called 'go-github-com-junegunn-fzf' <nckx>fzf is equivalent to .*fzf.*. <nckx>rekahsoft: You're saying that ‘guix package -s fzf’ does *not* return go-github-com-junegunn-fzf on your end? 🤔 <rekahsoft>nckx: Well the results of `guix package -s fzf` and `guix package -s '.*fzf.*'` are different on my two machines <nckx>Here it works as expected. <nckx>I'll pull from guix master & try again… <rekahsoft>I packaged fzf and some additional dependencies and after starting to submit the patch and noticing it is already packaged 😢 <nckx>I've been there, it totally sucks. <rekahsoft>nckx: More info: it does not happen in guixsd, but does from another distro with guix installed as a package manager <nckx>…huh. I like the way your plot thickens. *nckx cancels there guix pull since it's a bit too expensive at this time. <nckx>rekahsoft: The only non-Guix System I have access to is running, er, Ubuntu ‘Disco Dingo’ (I shit you not) with guix c383c36edeb7eb358f142c52276d6e5d32bda044. Both regexes return go-github-com-junegunn-fzf there, too. <rekahsoft>nckx: Lol, wow..thats an oldie 😛. I'm running archlinux on a few machines (still early in my transition to guix, but I'm sold!) <nckx>So I can't really help you, but this is definitely one bug I'll be following with morbid interest. <nckx>rekahsoft: The guix definitely needs pulling, but I'm not that into Ubuntu to be honest (it's my mother's machine). Is that ancient? Should I upgrade it? <nckx>It does say ‘0 updates can be installed immediately. 0 of these updates are security updates.’ *nckx shrugs, doesn't feel like joining #ubuntu. <quiliro>what should i search fer in the forum? <rekahsoft>nckx: This returns the expected results: `guix environment guix --ad-hoc guix help2man git strace -- guix package -s fzf`, and I noticed that my versions of guix vary (the archlinux guix was installed via the binary installation method around 1.0 and hasn't been upgraded since) <rekahsoft>nckx: No disco-dingo is not old..my mistake. <nckx>Don't search the text of the entire mailing list, that will be far too noisy. <nckx>quiliro: Just submit your bug to bug-guix@gnu.org 🙂 <nckx>(Maybe the first answer will be an easy fix, but that will make a very helpful archive too.) <quiliro>nckx: i think it is not particular to emacs...because i have some characters which also display incorrectly <nckx>rekahsoft: We did change the way regexes are matched, especially across fields, this year. If your Guix is really old it might predate that. <nckx>I say ‘we’. I think it was Chris Marusich. <nckx>erudition: Sounds like a hell of a drug. *nckx wonders what Nix's code name is nowadays… <nckx>(It's alphabetical, so it makes sense, but what's wrong with ‘Killer whale’…) <nckx>quiliro: Thanks for the bug report. <nckx>Does ‘locale’ return something different when run in M-x shell and your regular terminal? <nckx>That's the only thing I can think of for now. <sturm>To globally change substitutes on Guix running on a foreign distro, do I amend the guix-daemon services to add a --substitute-urls option? When I make this change to my systemd service and daemon-reload/restart Guix starts building openssl. :/ <sturm>I'm no systemd expert, but even this doesn't seem to work as I'd expect: <sturm>ExecStart=/var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon --build-users-group=guixbuild --substitute-urls='https://ci.guix.gnu.org' <nckx>sturm: I think guix-profile should be current-guix. <nckx>If that doesn't fix it, define ‘work’ and what happens instead. 🙂 <sturm>hmmm, it's just started hitting the substitute server now which is a bit weird - maybe something wasn't right with the reloading <sturm>thanks nckx: using guix-profile doesn't seem to bother it <sturm>nckx: by the way, is that an emoji character above? I don't seem to be able to see it in quaternion running on GuixSD <nckx>Hm. I'm not well-versed enough in foreign Guix to be sure, but it feels like another layer of indirection, no? current-guix is what root ‘guix pull’ed; guix-profile is… I don't even have that. <sturm>could be, it's just a copy/paste from whatever was in the manual at the time I did the install <nckx>sturm: Yeah, yeah, it's a thumbs-up mojo. Maybe I should just drop them. Nobody's Guix System can render the damned things anyway. <sturm>I just fired up the Riot web client for Matrix and that renders fine <nckx>Which is normal since I think it's just a missing font (and installing exotic fonts is probably best left as a user choice), but I get the question daily. <nckx>Never used quaternion; only Hex- & Weechat. <sturm>no smiley in hexchat for me unfortunately <nckx>(Which isn't technically a mojo and might render?) *nckx sees that weechat has a new version out, too. <quiliro>nckx: will post my answer to the mailing list <nckx>quiliro: I remember us talking about this yesterday, but not if it went anywhere. Could/did you try replacing ‘es_EC.UTF-8’ with ‘es_EC.utf8’ in your system configuration (and re{configur,start}ing)? <quiliro>nckx: oh...did not understand to do that <nckx>That's fine, I think the conversation just didn't get that far. <quiliro>but i only see es_EC.UTF-8 with 'locale -a' <nckx>quiliro: Politics aside, could you try ‘es_ES.utf8’ for now? <quiliro>i see there is en_US.utf8 and en_US.UTF-8...but there is not both for es_EC <nckx>This is because gnu/system/locale.scm has a small (but also far too large) list of hard-coded utf8 locales. I had to add eo.utf8 myself too, I now remember. <nckx>quiliro: No problem, I'll be here when you get back. <quiliro>and keep: (keyboard-layout (keyboard-layout "es" "dvorak")) *nckx learns about es-dvorak. *nckx .oO why move the ( ) brackets? <quiliro>I think reconfigure switches to the latest config...as per the manual...."Build the operating system described in FILE, activate it, and switch to it"...So there should not be a need to restart the system. <quiliro>I think that activating the system that has just been reconfigured is very risky. <quiliro>oh you mean the brackets over the 9 an 0....that is how they are normally in es keyboard <nckx>Activating a new system a) leaves a lot of ‘old’ services running (this shouldn't affect this problem) 2) does not propagate the new environment variables to your current X session (this does). <quiliro>they are normally in es keyboard over the 8 and 9 <nckx>Try ‘locale’ after reconfiguring if you don't believe me. <nckx>As to ‘risky’, I don't understand. <quiliro>on another machine today, when i removed gnome from config.scm....the gnome session did not stop during reconfigure...which was nice because it would have stopped the reconfigure...but it removed all the gnome icons <nckx>quiliro: I thought as much (that it was inherited from a previous us/es difference). Still doesn't explain the original shift by 1 key… <nckx>quiliro: Sure, but that's not unexpected if you make changes like that. Here, we're *only* changing the locale (I hope? Please don't make any unrelated changes, even to save time). Nothing will be restarted or vanish. <nckx>At worst, your computer will speak with a slightly different accent when it comes back. <quiliro>yes...it is a problem when the keyboard is not configured as local yet....you look for ) and get ( the disadvantage is that :-) would became :-( ... :-D <nckx>I could understand it if it were to make room for ¿, but it's not. Ah, nationalism ¯\_(ツ)_/¯ <nckx>Sounds like you've guix-pulled since your last reconfigure. Changing your locale won't rebuild any packages. <nckx>So they already had room for ¿ <nckx>but they decided that = belonged somewhere else <nckx>this was very important to them <quiliro>the main diff between for me was r for h were switched <nckx>ah, =, that uniquely Spanish symbol. <nckx>Hah! Of course I didn't even notice that. <nckx>At least there's probably a plausible frequency argument for that. <quiliro>perhaps because of the spanish revolution! <nckx>OK, but it's the *only* letter difference, and it doesn't exactly seem like the biggest phonetic difference between the two languages… <nckx>Substitute and not .tar.xz, I hope? <nckx>Otherwise, it might not make my bed time… <quiliro>it does not say on other packages...did not see for linux-libre <quiliro>some are gzip and others are lzip directories <nckx>I'm surprised some are still gzip. I guess the next core-updates merge will take care of that. Or do you use substitute servers besides ci.guix? <nckx>(ci.guix switched to lzip a few months ago, so everything /gzip/ was created before that and hasn't changed since, including a single input. No small feat.) <quiliro>guix (GNU Guix) 1d03a9198db6f3656a34d62eb89e5f7d5a99e76a <nckx>Anyway, I'm going to go get ready for bed, but take your time, I won't go to sleep just yet. <apteryx>sneek: deep down the rabbit hole; the dbus-launch command line is in glib, at gio/gdbusaddress.c:1131 :-) <apteryx>sneek: later tell civodul deep down the rabbit hole; the dbus-launch command line is in glib, at gio/gdbusaddress.c:1131 :-) <quiliro>nckx: will restart and check if it worked <quiliro>and 'Modificación remota' appears as 'Modificaci<C3><B3>n remota' <quiliro>on eshell error messages have no errors because they are in english <nckx>My system is .utf8 and those accents display just fine in eshell. <nckx>And I have no special configuration at all. <quiliro>i thought we ahd changed it to es_EC.utf8 <quiliro>but es_ES is so standard it should not fail <quiliro>I checked the config.scm and it is es_ES.utf8 <quiliro>What I said it that I thaught it was the other. <nckx>Yep, you pasted it correctly above before reconfiguring. <quiliro>The operatien was a success. But the patient died! :-D <nckx>Did you say your system is speaking English now? <nckx>No, emacs speaks only English (27 will bring some very very basic locale support, I think). <quiliro>will you please type one of those weird characters you type which normally do not render correctly <nckx>But the fact that we set your system locale to es_ES.utf8, a valid and not exactly obscure locale, and yet nothing is in Spanish, just means that something is wrong. So we can't say if it would fix your eshell issue or not. <nckx>That's a font issue, though. <nckx>I still don't think it's related to your eshell trouble. <nckx>quiliro: Let's call it a day (night for me); restore your locale to es_EC.UTF-8 for now & reconfigure & tomorrow is another day. <nckx>Sorry it didn't work out. I hope someone else has a bright idea. Note that we never got to test .utf8 because we're still missing a piece to make it work, we didn't actually find out if it could fix the problem. Big difference. Good night! <quiliro>guile: warning: failed to install locale <quiliro>hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and defining `GUIX_LOCPATH' <quiliro>is the first message when reconfiguring now <rople>figured it out, need to use a substitute servers <efraim>sneek: later tell civodul we have #:cargo-{development-,}inputs because it needs the recursive sources. There is some work to link to dynamic libraries, but in my tests it normally wants the sources also. <Snai1>hi, i'm writing my scheme configuration and now i'm stuck because i use a custom xkb layout and i don't know how to declare it into. I was thinking that i could declare a skeleton file with the keyboard definition, do you think about a better solution? <sneek>Welcome back civodul, you have 2 messages. <sneek>civodul, apteryx says: deep down the rabbit hole; the dbus-launch command line is in glib, at gio/gdbusaddress.c:1131 :-) <sneek>civodul, efraim says: we have #:cargo-{development-,}inputs because it needs the recursive sources. There is some work to link to dynamic libraries, but in my tests it normally wants the sources also. <civodul>apteryx: so it's probably not patchable because dbus depends on glib <civodul>efraim: still still, why not inputs and/or native-inputs? <Snai1>civodul: Yes I did, the guide assume that the xkb layout already exists <civodul>oh, and you want a layout that's unavailable by default? <efraim>civodul: I'll look at the sources in a little bit, I assume it's to help with unpacking the sources in the correct directory <civodul>efraim: yeah, i'm sure you or Ivan or someone explained it before, but it still looks weird to me <civodul>and potentially problematic, because "guix refresh -l", "guix graph", etc. don't provide useful info <efraim>And the whole packaging thing is hard, its never clear how far to go when essentially packaging sources <efraim>Last time I bumped something in guix I figured I just had to build all the rust packages to make sure nothing broke <civodul>it's very different from the experience we have with other packages <civodul>so perhaps we should hold our horses until we've figured this out <efraim>I think the short version is if we were to install shared libraries then in some cases cargo inputs could ALSO be regular inputs, but not only regular inputs <efraim>If we split them as sources and packages then it might be easier to package <civodul>i mean technically, inputs and native-inputs are also passed as arguments to the build system, just like #:cargo-inputs and #:cargo-development-inputs <civodul>so it's not clear to me what doing this buys us <efraim>The hard part is each package wants all optional dependencies when building and testing, but will accept whatever's available if only installing <efraim>I think cargo-inputs are recursively imported forever, dev-inputs are for tests primarily and aren't imported recursively <efraim>So all distro packaging schemes end up building with all the available options <efraim>I'm not in love with my hidden packages either, or with the build-arguments not carrying over with the sources to future builds <efraim>Also, the cargo-build-system only accepts .tar.gz sources due to some unpacking logic <efraim>Leo's looking at not actually building most go packages, rust and even perl6 are probably similar in this casr <civodul>dev-inputs sounds like native-inputs in a way <civodul>BTW, congrats janneke on the Mes release! <dfeng>How to remove a channel from the channel list? <civodul>there's only one channel in %default-channels, which is 'guix <civodul>but if you want to use a different copy of Guix, you can say "guix pull --url=..." <civodul>or you can have ~/.config/guix/channels.scm not refer to %default-channels <dfeng>civodul: I have added another channel <dfeng>civodul: I tried to delete ~/.config/guix.channels.scm but... <civodul>sounds like they more or less correspond to what you're asking <dfeng>civodul: my custom channel is probably saved in %default-channels <civodul>no, %default-channels is a variable that doesn't change <civodul>unless you 'set!' it, but that's a bad idea <dfeng>civodul: ;; Add my personal packages to those Guix provides. <dfeng> (name 'my-personal-packages) <dfeng>civodul: 'cons' pushes the "channel object" in %default-channels? <civodul>dfeng: cons returns a list where your own chanels is added to the front of the %default-channels list <civodul>the page above has links explaining 'cons' <dfeng>civodul: you're right. Usually, in Elisp, I store the resulting list in the same variable. <civodul>here channels.scm just return a new list without modifying any variables <dfeng>civodul: 'guix pull' triggers an error: 'updating channel "foobar"[...]\nguix pull: error: Git error: failed to connect to http://...' <dfeng>civodul: I deleted my custom repository which acts as a custom guix channel <roptat>that will pull from the official guix repo, instead of your repo that disappeared <dfeng>roptat: in my case (configuration) 'guix pull' still tries to use both channels <dfeng>roptat: the same error occurs <roptat>if you put only %default-channels there, it should work <roptat>guix won't try to pull your additional channel I think <civodul>it preserves additional channels when you pass --url <civodul>so if you really just want the defaults back, you can "rm ~/.config/guix/channels.scm" <dfeng>roptat: "cons" does not reinitialize the channel list <dfeng>civodul: I removed "mv -v ~/.config/guix/channels.scm ~/Documents" but the same error triggers <dfeng>roptat: my channels.scm is like the snippet presented in the Guix manual "4.7.2 Specifying Additional Channels" <dfeng>roptat: of course, I have adjusted the information <civodul>dfeng: thanks; removing ~/.config/guix/channels.scm should definitely fix it <dfeng>civodul: oops, you're right. Maybe, it didn't work because of the backup file "~/.config/guix/channels.scm~"? <dfeng>civodul: you're right! I probably missed something, previously. <roptat>last time I said I wouldn't buy a windows license to port guix, but I could actually install a reactOS system :) <roptat>I wonder if the PE format has a notion of a rpath though... <efraim>What about WSL? Also IIRC Nix is looking at Darling to replace Xcode for MacOS <rekado>AFAICS Darling is for running MacOS applications on GNU+Linux. How can it be used to replace Xcode? <roptat>if I'm using reactOS, I won't have access to WSL I think <dfeng>Can we define a "package" interactively using "geiser" and "guix-repl"? <dfeng>I know geiser may use several different scheme REPL <dfeng>the Guix manual also mentions "geiser" <null_radix[m]>anyone know if there is a way to do `echo "fs.inotify.max_user_watches=204800" | sudo tee -a /etc/sysctl.conf` but in config.scm? <roptat>what do you mean? what do you want to do with this? <roptat>there's no /etc/sysctl.conf on my guix system, I'm not even sure anything would try to read it... <roptat>but if something does, I guess you can try to configure the file with etc-service-type <roptat>oh, that's better than my suggestion then :) <null_radix[m]>roptat, yeah i know... i guess that question didn't make alot of sense... but i was just asking how to set `fs.inotify.max_user_watches`.. lol <roptat>yeah, it read like you wanted to run a command from a configuration file ^^' <roptat>then I reread more carefully and started to understand :) <civodul>roptat: with WSL, there's no point in porting software to Windows: you can just run GNU/Linux binaries directly <civodul>MinGW, Cygwin, CMake, all these things have become kinda obsolete <civodul>or so i'm told, i've never actually tried :-) <roptat>but that won't work with older versions of windows, reactOS, and it seems you need to do some specific actions to make it work <roptat>I'd like to make native binaries, but the lack of rpath is not going to help <bmwiedemann>I wonder why curl -I shows the file's mtime as 1970-01-01 00:00:01 though - SOURCE_DATE_EPOCH affecting it? <apteryx>civodul: wrong, dbus does *not* depend on glib :-) So I could patch glib successfully! I'll send this to guix-patches soon <apteryx>tested with workrave -- successfully started dbus without having it in the profile :-) <roptat>why does the shepherd need that much memory? it takes 50 MB of RAM on my small server, so 10% of available memory :/ <efraim>I'm still on the fence that when user Shepherd crashes it doesn't take its spawned processes with it <efraim>On one hand I'm glad to have them, on the other I feel compelled to pkill them to get them managed with a relaunched Shepherd <nly>what packages do i need to use beamer on guix? user-error: Unknown LaTeX class ‘beamer’ <nly>I have no idea about Latex, but i guessed it might be package related? Maybe i should ask #emacs? <bmwiedemann11>nly: beamer is probably a latex module - and since there are thousands, not all of them are installed by default <nly>bmwiedmann11 thanks, progress :) <civodul>efraim: shepherd's not supposed to crash though, so when it does, be sure to report a bug :-) <roptat>civodul, right now it's the process that uses the most memory, with 43,0m resident <civodul>there are libgc env vars that you could try to tweak <civodul>also, we don't have a heap profiler, and that sucks <nly>which package contains geometry.sty for latex? <bmwiedemann11>wingo: depends. we have OpenStack python processes average 256 MB each. and there are ~70 of them <wingo>sure, but for an init manager, it doesn't need to do much <wingo>systemd has many more processes but pid 1 is only 3 MB private dirty memory on this ubuntu machine <bmwiedemann11>grep ^Vm /proc/1/status shows 6MB RSS and 27 MB Data on openSUSE <rekado>nly: not too surprisingly it’s texlive-latex-geometry :) <rekado>nly: the best way to answer questions of this kind is to look at $(guix build texlive-bin)/share/tlpkg/texlive.tlpdb <nly>thank you rekado :), i am stupid lol <rekado>no no, this whole texlive stuff is confusing <rekado>the package should actually be called “texlive-geometry” <rekado>it’s from before the enlightenment. <nly>rekado will look at it after i get through with this :) <nly>ah rekado, i was thinking it might be nice to have an 'animate' function in pict, from racket's animate, wdyt? <rekado>nly: that would be nice! Would this generate a list of frames? <rekado>(actual animations cannot be displayed by the variant of librsvg that’s used by Emacs) <rekado>at least I wasn’t able to make them work <rekado>same with effects like blur or noise generators <nly>rekado, yes if i understand correctly <nly>mathias felleisen has awesome talks about animate <nly>I wanted to use them in nomad <gnu_srs1>Hello, I sent this (and other stuff) to guix-devel: So you say that <gnu_srs1>> I probably have to compile latest autogen with guile-2.2-libs and after that gnutls28 again. <gnu_srs1>will not be enough? Is that so? Then how to proceed with the Hurd port until the guis and the cross-built binaries are guile2.0 only (not 2.2). <sneek>Welcome back Minall, you have 1 message. <sneek>Minall, quiliro says: Ya pude levantar el servicio. Conéctate por el puerto 2222 al tercer usuario y copia al repositorio tu tarea. <Minall>Is it secure for my user to be on wheel user and be able to have sudo privileges or not? <roptat>as much as with other distros I'd say <Minall>Yes, I normally feel unsecure using sudo, I feel more secure, but... I don't know of any reason why <jboy>has anyone created a guide to installing guixsd on vultr or ramnode using the custom ISO? I can run the installer on Vultr, but after installation the virtual server won't boot from the installed system. <rekado>Minall: what do you mean by “secure”? What’s the threat? <rekado>gnu_srs: the suggestion is to change Guix so that it builds Guile 2.0 as the bootstrap Guile. <Minall>Is it safer to use sudo, or to not have a 'sudo capable' user and use su -? <bandali>Minall, didn’t we discuss this a month or two ago? :p <Minall>bandali: yep, but I'm not sure of it yet lol <bandali>basically, the additional attack vectors when using sudo are: <bandali>1) your account getting compromised and thus becoming a means of obtaining root <bandali>2) the program sudo having critical bugs that would allow privilege escalation and someone obtaining root through it <Minall>That's what I mean... A user with sudo is like the root user, it has privileges <bandali>for 1), you’d have to consider how secure your password is, and what programs do you run on your user (do you trust them?) <bandali>for 2), you could look through the track record of sudo’s security throughout the years, and e.g. how many CVEs were filed against it <bandali>note that running a system only comprised of free software helps with the peace of mind about 1) <Minall>My user gets attacked, and now my password is compromised <Minall>IF my user has sudo, coudn't the hacker use sudo to control my pc, or to take control of it? <Minall>If it doesn't have sudo privileges, is just a normal user when I can enter on root and delete <Minall>Yes, totally!, that's why guix is so beautiful <bandali>:) on a side note, i don’t think that’s unique to Guix <Minall>Then, If I'm right, wouldn't that make sudo unsecure? <gnu_srs1>rekado: Is somebody looking into using Guile 2.0 as bootstrap Guile ? Until then, I'm stuck. Or is there something that can be done before? <nckx>Minall: sudo is extremely configurable, you can also configure it to ask for root's password. <bandali>to be honest, labelling something “unsecure” isn’t a black/white or 0/1 thing <Minall>Yes, it isn't, but for example, if I need to install a package on any other system, I would need root privileges, then I enter the password, and it can be compromised <rekado>“sudo” gives someone with knowledge of your password and user name access to root. You have to decide if that’s a problem for you. <Minall>But, in guix you don't need root to install package <rekado>how would an attacker obtain your user password? <rekado>maybe your account password is the same as other passwords that you use on the internet <Minall>THe only reason I would enter root is to guix pull and guix upgrade, but in other distros is more insecure since I need to use root all the time to install packages <Minall>Thus, guix is safer not using sudo, since you don't need privileges to isntall packages <rekado>if an attacker could log onto your machine and install a keylogger they could read your password, but perhaps then they could also see the root user’s password. <Minall>In that case, it doesn't matter lol <rekado>Minall: you can configure a list of commands that should be permitted when using “sudo”. <nckx>Minall: Yes. This is why calling sudo ‘unsafe’ or ‘insecure’ doesn't make sense. <rekado>if you only ever want to use “sudo” with the “guix” command, then I’d suggest configuring it to only allow that. <nckx>It can be used (like any tool) to make your workflow much more secure, or leave gaping holes if you don't understand it. <Minall>If i were to configure sudo to just be able to run guix pull and guix upgrade, wouldn't it be the same? since I'm running it on the user <Minall>Or since I'm using sudo, i would be on the root user? *rekado does not understand the question <rekado>Minall: what do you mean by “wouldn’t it be the same”? The same as what? <nckx>Minall: the only Guix thing I need root privileges for, ever, is ‘guix system reconfigure’. I've never pulled as root. My root user doesn't have a profile. <rekado>when “sudo” is configured with a whitelist of commands then only those commands can be run as root. <rekado>you could then only do “sudo guix system reconfigure”, for example, but not “sudo bash”. <Minall>One question just to clarify, in the case you would like to limit the commands by whitelisting with sudo, which commands would you allow the user to use? <Minall>Because whitelisting any commands that need root, would be unsecure too <rekahsoft>I have built of a series of patches which I am working on submitting before the end of my vacation. I am not as familiar with submitting patches via a mailing list and wanted to make sure I'm following the expectations of the guix project. Yes, I have read the contributing section of the docs and everything seems clear. I just wanted to double check with folks here regarding the two I've already submitted (https://i <rekahsoft>ssues.guix.info/issue/37365, https://issues.guix.info/issue/37365) so that I can be confident to submit the remaining 25 or so. They are simple package additions. Thanks and really excited about getting more involved with Guix! <nckx>Restricting sudo to run only whitelisted commands will stop casual attackers (many exploits are automated, so this can be significant) and slow down all others, but there's almost certainly a way to get guix to execute arbitrary code so it's not a hard security feature. It's one layer of several you should have. <rekado>rekahsoft: you don’t need the Signed-off line; that’s for people who commit this on your behalf. <rekado>rekahsoft: for the description field please use full sentences. <nckx>sudo guix build -e "(system* \"ls\")" 🙂 <rekado>rekahsoft: (delete 'check) is not great; we usually do #:tests? #f with a short comment as to why tests are disabled. <rekado>rekahsoft: other than that it looks really good. <rekado>rekahsoft: if you have a series of patches that should go together, please open one bug, wait for acknowledgement, and then send all the patches as replies. <nckx>bandali: Hm. On foreign distroes, maybe? <rekado>nckx: I think for “guix build” we shouldn’t just evaluate anything but use Guile’s sandbox feature. <Minall>¿Can you build something on guix?, I think that to build it correctly, one would have to make a package definition <nckx>On Guix System, you can just ‘guix pull && sudo guix system …’, using your user's Guix. <rekado>Minall: you can pass an expression to Guix that would eventually evaluate to something buildable (like a package definition) <nckx>Minall: To whom are your last 2 lines addressed? <rekado>“guix build -e” just takes some Guile code, runs it and hopes that in the end that code evaluates to something it can build. <rekahsoft>rekado: Great! I appreciate the feedback! Sorry for coming to IRC to double check before proceeding, but I figured that would be better then wasting reviewers time. I will make the suggested changes. Thanks again rekado! <rekado>rekahsoft: checking on IRC is the right thing to do <rekado>we’re regretfully slow with reviews <Minall>Thanks guix, it makes sense now! <nckx>My point with the ‘sudo guix’ command above is to show that whitelisting only ‘guix’ in your sudo configuration will not stop an attacker who can think/do research. But it will stop scripts and their kiddy masters for sure. <bandali>rekado, would it make sense to increase the number of “reviewers” (those with commit access)? or is that somewhat orthogonal ? <bandali>the reviews are indeed sometimes painfully slow <rekado>bandali: we curretnly have quite a few people with commit access <rekado>bandali: but not all of them do reviews <rekado>I’m happen to be one of them at the moment :-/ <nckx>bandali: Commit access isn't required to review code. <nckx>I really don't think we're lacking committers. Reviewers, dearly. <bandali>rekado, nckx, ha :) so i guess i wish more people in general would do reviews *nckx is as guilty as everyone. <rekado>we are increasing the number of committers whenever we feel that someone produces patches that don’t require much review, but we like to keep the circle of committers to people that have been with the project for long enough to know how we work and what our conventions are. <rekado>I still think that issues.guix.gnu.org doesn’t do a great job to aid the review process. <rekado>I’ve been meaning to improve the search, but … well, that all eats up time that I could probable use for patch reviews :) <nckx>‘Hm, I should check out issues. again…’ ‘504 Gateway Time-out’. Damn it. <rekado>I’d be thrilled to see some contributions to mumi (the software behind issues.guix.gnu.org) <rekado>nckx: I don’t see a timeout right now. <nckx>rekado: Only part of the page, under Recent activity. <rekado>that part is AJAXy precisely because it’s so slow to compute. <nckx>rekado: ‘Cannot reproduce reliability issue, closing as invalid.’ <bandali>for one thing, i find mumi’s default font size kind of large <bandali>a zoom of 80% makes it look a fair bit better <rekado>I wished Debbugs had a better API and more endpoints to get useful information. <nckx>Yes! The font size is slightly too ‘modern’ for me, but it does look good. <nckx>I feel guilty for never using it. <rekado>I have this Librem thing and everything just seems tiny to me… <rekado>having more than one person hacking on mumi would help avoid these problems :) <rekado>I think it’s just a medium-dpi device <bandali>i might be able to set aside some time :) <nckx>rekado: I already set layout.css.devPixelsPerPx to .92 to zoom out the entire Web. Mumi still looks a bit too big. <rekado>I always zoom in on all web sites. It’s all uncomfortable to read to me. <rekado>(it’s not my eye sight, is it…?) <bandali>re wishing for more useful info out of debbugs: yeah… <nckx>rekado: Oh, I understand. You won't notice the slight increase in zoom requirements. It's also far from as bad as some sites, don't worry. <rekado>we’re just sticking with debbugs because GNU. <bandali>but i think it’s still got some more maturing to do. plus, we (the gnu project) will probably end up forking it to make some changes for better defaults (sourcehut is quite opinionated) <nckx>I don't mobile, but the UA situation there must be atrocious if all these sites need ‘font-sizes: x-honking-redonkulous’ just to accomodate user devices… <rekado>I hope the fork would be a little less painful than the Debbugs fork. <nckx>That's a browser's job ☹ <bandali>rekado, yeah… i’ve brought it up with the fsf sysadmins, and they seemed excited about it. i wonder at one point into the future we might be able to run a sourcehut instance, at least alongside savannah *bandali bookmarks the mumi link <civodul>so we have "ctest" (from cmake) that uses libcurl, and that doesn't find certificates <civodul>"ltrace -e getenv" says it doesn't honor any cert-related env var <nckx>I had a similar question about weechat. Is there any standardisation amongst libcurl users, or does every client just pass a string it got Somehow? <nckx>‘curl error 60 (server certificate verification failed. CAfile: none CRLfile: none)’ <nckx>I can't find any relevant getenv calls, and the build system sets CA_FILE to /etc/ssl/certs/ca-certificates.crt (which exists at run time), but it still says ‘none’ above. <civodul># define CMAKE_CAFILE_FEDORA "/etc/pki/tls/certs/ca-bundle.crt" <nckx>So add CMAKE_CAFILE_GUIX? Simple. <Minall>I'm trying to make a public key, install GNUPG and runned 'gpg --gen-key' <Minall>And I got the error 'no pinentry' <Minall>I installed pinentry and nothing, how could I solve this? <nckx>Minall: I added ‘pinentry-program /home/nckx/.guix-profile/bin/pinentry-tty’ to my /home/nckx/.gnupg/gpg-agent.conf. <civodul>nckx: looking at cmCurlSetCAInfo, it seems we're stuck: we have to rebuild the damn thing <nckx>civodul: Oh, thanks. This has probably been suggested before, but would just patching our libcurl to respect *something* be an option? Or is getenv from library code behind callers' backs evil somehow? <civodul>it's kinda evil, but the status quo is terrible too <nckx>We'd still have to add a search-path for every libcurl user due to that other bug, but it would be something. <nckx>Yeah, it's one kind of suck or another. *nckx goes to change a light bulb. *civodul would rather change a light bulb than fiddle with cmake <roptat>I still don't understand why you would reject a patch to propagate search-paths... why would I care if I have more search paths than I actually need? <quiliro>What is the difference between: 'gpg --gen-key' and 'ssh-keygen'? <roptat>gpg would add the key to a keyring, while ssh-keygen just generates a key pair <roptat>maybe gpg has some option to prevent it from updating any keyring though <civodul>roptat: please reply in the issue tracker :-) <PotentialUser-91>Hi! I have a problem. I tried to put together a program. Make: <linux/config.h> error not found. What to do? <nckx>PotentialUser-91: Hm. Which programme is this? That's a pretty kernel-specific thing to be demanding if you're not a kernel module or similar. <nckx>It's not even installed by our linux-libre package, AFAIK. <nckx>But maybe this is a completely unrelated linux/config.h 🙂 <leungbk> How can I ensure that other people can verify the signature of <leungbk> my gpg key? I've given Ricardo my public key and signed an email to <leungbk> him with the key, but he told me he can't verify the signature in <leungbk> spite of being able to find it on keys.openpgp.org. (The key is <nckx>Installing packages generally does't affect builds, although I don't know how you're trying to build it, of course. <rekado>sneek: later tell civodul it’s up to the user of libcurl to check environment variables; the library itself doesn’t care, but can be built with a default to fall back on. <nckx>PotentialUser-91: This package actually does include a kernel module, so it will have to use (parts of) the linux-module-build-system. <rekado>leungbk: it’s possible, of course, that it’s my fault. Maybe you can let somebody else try to verify the signature. <nckx>PotentialUser-91: make && make install doesn't work on Guix. Write a package instead. <nckx>Also note that this package is 6 years old and looks like large parts snake oil to me. <rekado>leungbk: could you perhaps write a short message into a text file, sign that, upload the signed text to a paste site, and then post it here? <rekado>PotentialUser-91: no. “guild” is for compiling Guile code. <nckx>PotentialUser-91: I'm not really familiar with Guild, sorry. <rekado>PotentialUser-91: have you tried writing a package definition for this application? <rekado>leungbk: please upload a plain text file. This looks like a binary, which is more easily corrupted. <leungbk`>rekado: The command I entered was "gpg --output some-doc.sig --sign some-doc". Aren't signed messages supposed to be binary files, readable after decryption? <rekado>no, signed messages don’t need decryption. <rekado>a signature just indicates that you are indeed the author of that message (well, at least that the author has control of your private key) <rekado>signatures can be done as a plain text “wrapper” around the message, or as a separate file. <rekado>leungbk`: for sharing as a text file, generally use “--armor”; in this case, though, please use “gpg --clear-sign”, which creates a file that includes the message and the signature. <nickey>hi guys! i'm trying to install guixsd with bios-grub and luks-encrypted root filesystem. and always get an error like "file /gnu/store/...-linux-libre... not found". should grub load the kernel from encrypted filesystem? <rekado>grub should decrypt the filesystem <nckx>nickey: Does GRUB not prompt you for a passphrase? <nckx>nickey: Did you set up a luks-device-mapping in your system configuration? Could you share your configuration? <nickey>nckx: the only difference I see is that I'm using device label instead of direct /dev/mapper path <nckx>I haven't tried that but it should work. <nckx>…we *unconditionally* call grub-install with GRUB_ENABLE_CRYPTODISK=y, so that can't be it… <nckx>nickey: Oh, is that where you use label? That might not be equivalent. Could you use (device "/dev/mapper/rootfs") instead? <nickey>nckx: label is what I've used on mkfs.ext4 -L rootfs /dev/mapper/... but i'll try to use it with direct path <nckx>In the first ‘/’ file-system. <nckx>nickey: Yeah. We do our own label sniffing in Guile, though, so it might not be wired up to catch all cases including devices mapped later in the boot process like this. It's worth a try. <rekado>leungbk`: this one worked fine: “Good signature from 3D69840652089BBA Brian Leung <bkleung89@gmail.com> (trust undefined) created at 2019-09-10T19:52:09+0200 using RSA” <rekado>leungbk`: could you please use this key to sign your email and to sign future commits? <rekado>leungbk`: sorry for the hassle. Getting GPG to work is tricky. <leungbk`>rekado: OK, I haven't figured out how to integrate it into my mail client (Gmail) smoothly, so is it generally OK if I simply sign a plain-text message on my computer and attach that to the email? <leungbk`>rekado: OK, I've emailed you using this latest gpg key to sign. <nickey>nckx: nope, using direct path doesn't help <nckx>leungbk`: Once you set up git to sign your commits, ‘git send-email’ can be made to send via Gmail so you won't have to deal with its horribleness when sending patches, at least. <nckx>nickey: Pity. I'll blankly stare at your configuration for another while in case anything jumps out at me. <nckx>Nothing does, sorry. The only differences between our setups is my two "/dev/" names instead of UUID/LABEL. <nickey>nckx: Ok. Anyway thanks for help. I will try to install it without luks and then again when I'll have totally working configuration. <pinoaffe>nckx: one thing speaking for the "unsafety" of sudo is the fact that it's relatively easy for an attacker to modify the shell environment such that instead of sudo, their evil keylogging wrapper is run instead <nckx>Er, libreoffice is broken on master? Really? <pinoaffe>this allows for relatively easy escalation of privileges from a user account to root <rekado>leungbk`: hmm, I still can’t verify your signature :( It’s fine for what you pasted earlier, but not for your email. <nckx>pinoaffe: That applies to ‘su’ too, so… adminning from a dedicated root getty session? <nckx>mbakke: I see you just updated libabw and libvisio. I tried to do that when they first came out but got errors (‘configure: error: Required boost headers not found.’). That's still happening for me, breaking libreoffice. Could you take a look? <dongcarl>Does anyone know if rhelling checks IRC? <nckx>pinoaffe: At which point the attacker replaces your ‘switch user’ and ‘log out’ buttons with evil twins and your shell with one that doesn't really ‘exit’ or ‘logout’ and you're looking at a power cycle for ever administration command, just in case. You're right, of course, but… eh. :-) Threat models. <nckx>dongcarl: A quick grep of the ol' logs says no, at least not under that name. <pinoaffe>nckx: sure, all software is broken, but I'd treat any account with sudo'ing rights as if it was root with the added benefit of it being a tad more difficult to shoot myself in the foot <rekado>does anyone know of a good introduction to configuring PXE? I only found outdated or incomplete tutorials that involve unpacking some Ubuntu ISO — but I want to generate all of these config files from scratch. <nckx>pinoaffe: I was arguing against anyone claiming that ‘sudo’ is in any way ‘insecure’ because of that, or similar FUD, not you. You weren't wrong. *nckx doesn't even understand the difference between all the [ijklmno]PXEs. <rekado>I feel like I’m trying too many things at once, none of which I fully grok. <rekado>I’m running dnsmasq to offer DHCP + PXE for a Qemu VM, all connected via some bridge interface that includes a clone of my wifi NIC, using PXE configs that I don’t understand <vagrantc>rekado: got a paste of your dnsmasq configuration? <rekado>sudo $(guix build dnsmasq)/sbin/dnsmasq --dhcp-range=192.168.178.0,proxy,255.255.255.0 --port=0 --pxe-service='x86PC, "Boot from network", /pxelinux' --enable-tftp --tftp-root=/srv/tftboot --log-dhcp --log-queries --dhcp-leasefile=/tmp/dhcp-leases <rekado>I’m starting the VM with this command: qemu-system-x86_64 -m 1024 -hda testpxe.vmdk -boot n -option-rom $(guix build qemu)/share/qemu/pxe-rtl8139.rom -net nic -net tap,ifname=virttap,script=no,downscript=no <rekado>(testpxe.vmdk is just a blank disk image) <rekado>I can’t add my Wifi to a bridge interface; I first need to create a separate interface where wds is enabled and bridge *that* one. <rekado>i.e.: sudo iw dev wlp1s0 interface add wds.wlan0 type managed 4addr on <nckx>mbakke: Now after clearing the cached failure and building them again they… substitute fine. That boost error is *not* one that should depend on the phase of the moon. Very strange. <rekado>then create a tap interface for the VM: sudo -E ip tuntap add dev virttap mode tap user $USER <rekado>and then the bridge: sudo brctl addbr virtbr; sudo brctl addif virtbr wds.wlan0; sudo brctl addif virtbr virttap <rekado>the first problem is that the VM can’t configure the network interface. I do see dnsmasq activity in the logs, though <nckx>mbakke: But at least you're off the hook, sorry ;-) <civodul>rekado: same here, i'm clueless about everything you write :-/ <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, rekado says: it’s up to the user of libcurl to check environment variables; the library itself doesn’t care, but can be built with a default to fall back on. <rekado>oh, so I actually *do* need to run a full DHCP server, not just a DHCP proxy <vagrantc>rekado: the DHCP proxy works if you have another DHCP server on the same network <leungbk`>rekado: OK, I tried again with a different key and email provider. Please check your inbox. <jsgrant_>Going to try to get this box on Guix again this week; Kept having a weird failure running through the tui setting up my luks partitions last time. Gonna figure it out -- even if it takes me 10 hours. lol <jsgrant_>Been looking back into the guile ecosystem generally; First time in like near 5 years, sadly it looks like guile-gnome is effectively dead? Shame since it looks like GNOME is somefactor of the "default desktop" for Guix <rekado>vagrantc: I actually do have another DHCP server :-/ <rekado>but I guess my network bridge isn’t working correctly <rekado>jsgrant_: today there are more projects that serve a similar purpose: g-golf and guile-gi. <jsgrant_>rekahsoft, Oh sorry; Was trying to say that I haven't looked into Guile (and Guix generally) for about 5 years. <jsgrant_>Was saying the last commit I saw was 2 years ago; And I think that was in-sync with that release <jsgrant_>Also, thank you; Will bookmark those two and look into them. :^) *rekado isn’t rekahsoft :) <rekado>leungbk`: hmm, I still get “bad signature” when trying to verify the signature on your latest email. <rekado>to be sure that it’s not just a problem on my end I’d be happy if someone else could try this. <rekado>civodul: were you able to verify the signature on leungbk`’s emails? <jsgrant_>Just doing a quick browse; But both suggestions look at the very least promising. <rekado>all right, this PXE environment seems to work now. <rekado>on to the next problem: boot Guix System <iv-so>guys, how can I set the dependencies individually for each output? <iv-so>like, I have a package with three outputs, one with emacs mode and the others with helm and company integrations <nckx>iv-so: Hi (we prefer gender-neutral salutations)! Inputs in Guix aren't per-output, since they are all built at the same time in the same environment. The outputs that retain references to the inputs will cause them to be pulled in, the ones that don't, won't. Does that make sense. <iv-so>I read that `guys' are gender neutral, not native speaker ofc <dutchie>historically not, some now consider it to be gender-neutral <jsgrant_>iv-so: It typically is, colloquially. But it comes from the term guy which is male -- I have no stake in it either way; I typically use "guys" in that way, but just for background *nckx wonders how many who consider it gender neutral would use it spontaneously (not to make a point) when addressing a group of girls or women. But's that's probably beyond #guix… <nickey>maybe it's stupid question (I'm very sleepy): i've install xorg-server and slim packages. how should I enable slim display manager to login through it? <mbakke>nickey: if you are on Guix System, you should instead add (service slim-service-type) to the "services" field of your system configuration and reconfigure. <nckx>nickey: It's not stupid at all. This is one of the areas where Guix System differs starkly from other operating systems. You don't install Xorg and SLiM to ‘enable’ them (in fact, you can uninstall them now, you won't need them). Instead, you add ‘slim-service-type’ to your operating-system form in your system configuration. <nckx>I'm not sure if you need to delete, for example, gdm from the default list to make that work but I'm sure mbakke can help you with that 🙂 <mbakke>nickey: I guess you are using %base-services? <nickey>mbakke, nckx now I've got it, thanks <rekado>ArneBab: not usuable yet, but many dependencies packaged. <ArneBab>I saw that there’s plasma-framework; is there a plan what’s needed to get kde usable as desktop on Guix? <rekado>ArneBab: Hartmut probably knows. I don’t know of anyone else working on it right now. <nickey>mbakke: seems like I still need help... I've added (gnu services xorg) to use-modules. and added slim-service-type to services. but now I've got error "Wrong type argument #<service-type slim ...>" when trying to run guix system reconfigure <rekado>can you show us your configuration? <nckx>erudition, ArneBab: I don't think there are many (any?) Guixers willing to actually use and work on KDE, so what's needed most is +yourself, really. 🙂 <nckx>Chickens, eggs, all that. <ArneBab>nckx: I meant what’s needed in terms of packages so I could see if I could package some to get towards that :-) <nckx>ArneBab: I know, I probably shouldn't have included you, then it seemed rude not to, I don't know, how do I social ¯\_(ツ)_/¯ <ArneBab>mbakke: wow, that looks useful! Thank you! <nckx>nickey: You need to write (service foo-service-type). <nickey>nckx: not too obvious. but error is gone, thanks 
