<everstone>I'm redefining a default variable in my scheme file. When I feed it into guix repl, it works exactly how I want it to. When add my (operating-system ...) bit at the bottom, it says "Not a list: #<unspecified>". I don't understand why <roptat>BlackMug, sorry, I don't know what's wrong there <BlackMug>roptat whos the author of that wiki part? maybe he know whats going on <lle-bout>civodul: hey! about updaters I am thinking one category of packages that are uncovered would be those like 'umoci', it's hosted on github but downloads from releases, not sure why they arent covered <BlackMug>because either something is done wrong or its a bug one of the two <lle-bout>civodul: glad these last patches were merged! <jgomo3>I noticed the --profile parameter in the example, mention twice "my-project". Do you know the reason? why not simply once? <jgomo3>i.e: `guix ... --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project` <jgomo3>Why not `guix ... --profile="$GUIX_EXTRA_PROFILES"/my-project` ? <jgomo3>Ok, I see. At the first level, guix creates some symlinks. So the extra level is needed. <BlackMug>said fixed but i dunno... sad that i cant bypass latest step for the installation. <BlackMug>graphical installer seems to be solving this issue, nixos took me like 20-30 minute for full installation <BlackMug>or no sorry it wont fix this issue , but just speedup the set up <everstone>I don't know what I did, but I shuffled thing around and now it works. Can't complain ***sneek_ is now known as sneek
<jgomo3>When will an profile created by `guix environment` be removed? <jgomo3>Will the garbage collector take care of those profiles? <apteryx>unless you registered a garbage root for the profile via the --root=FILE option <apteryx>or provided the --profile=PATH option, which creates a profile symlink which also acts as a garbage root, I believe <jackhill>apteryx, jgomo3: and as long as the process spawned by guix environment is running it is also protected, right? <jackhill>cool, it definitely seems like a reasonble design <apteryx>by the way did you end up getting btrfs subvolumes going? <apteryx>(if my memory/nickname association serves me right, you had asked about it on the mailing list) <jackhill>apteryx: uh, I don't remember asking about it on the mailing list, but I do use btrfs subvolumes. I just add them as additional filesystem in config.scm (or create them in the same place where I want them mounted). <jackhill>I did find that I couldn't use a different subvolume thatn subvolid=5 for /gnu/store, because I didn't know how to tell grub to use it when finding the kernel. <jackhill>Another rough edge I ran into was creating subvolumes for each user's home directory. If I pre-created them the skeleton files didn't get copied in. Would be cool to teach Guix about more btrfs operations, something else for the project queue. <jackhill>Oh, and I would really like to be able to create btrfs filesystems with subvolumes and everything using the system image API. <jackhill>apteryx: cool, I'll have to give that a try <emacsen>ashishdev, no one can answer your question because it's not answerable <emacsen>because it's like asking "Is blue a better color than purple?" <emacsen>ashishdev, Some people like muffins. Others like cupcakes. <jgibbons[m]>On a desktop install, some processes dump their output to tty1 <ashishdev>Why to develop a another language if c is there <Frosku>Because performance isn't the primary concern of *most* development tasks <emacsen>ashishdev, no one is forcing you to use any languages or operating systems. If you like another one better, that's what's wonderful about choice. <Frosku>If what you're doing is incredibly dependent on vertical performance, use C <Frosku>If it's not in the 0.01% of programs where raw performance is the main requirement, there are other options <Frosku>In general, Guile is pretty performant <Frosku>But it's not going to beat optimized C <ashishdev>so why not make a language is compatible with c like c++ <Frosku>Because C is optimized for working on bare metal and lisp is optimized for data-oriented design <emacsen>ashishdev, do you understand why people use some people use, eg Python and others use C? Or why someone uses C and not Assembly? <jgibbons[m]>One suggestion to clean up tty1, set the logfile of elogind, geoclue, and ntp to a log file that rottlog can take care of. These programs can give hints about location and other habits, so I think there should be an option to turn off loggin. <emacsen>there are good reasons for language choices <Frosku>If you think of programming languages as like vehicles <Frosku>There's a reason we don't all drive Formula One cars <emacsen>Frosku, this is a very good analogy! <Frosku>They're not very comfortable, for one. But they are very very fast. <emacsen>and why aren't all cargo trucks Formula One cars? <Frosku>Different vehicles are optimized for different use cases, whether it's ease of use, ease of repair, hauling heavy goods, etc <ashishdev>I don't like that people developed many languages to do different things <ashishdev>It's like a real world where there are hundred of languages. <emacsen>ashishdev, You don't seem to be listening to either me or Frosku, so then I wonder if you're just trolling <Frosku>There are different use cases in software development <Frosku>One of those is "I need this thing to run as fast as possible on a single machine" <ashishdev>What is a c developer want to contribute to non-c program <Frosku>They would need to learn the language, which usually isn't very hard <ashishdev>I can learn the language but the optimization and experience <Frosku>What if a Formula One driver wants to haul a cargo container? <Frosku>She probably has to learn to drive a semi <ashishdev>what about make good code, there are hundred guideline. <emacsen>ashishdev, Have you ever tried to write a web application in C? <emacsen>ashishdev, have you ever tried to write a highly scalable program that has multiple programs running a simulation and which all interact with one another in C? <Frosku>Even managing threads in C is a pain in the ass <Frosku>Whereas other languages make asynchronous processing easy <emacsen>Frosku, threads? heck, memory management! and basic security like buffer overflows <emacsen>Frosku, hehe, ever seen bad C that assumes language architecture baked into it? :) <Frosku>In general the reason languages are becoming more abstracted is because we have more processing power <Frosku>So we can enjoy the 'luxury' of putting more work on the computer and less on the developer <Frosku>(Turns out developers cost more than more CPU cycles) <ashishdev>i think a only language i like is c++ which compatible with c <emacsen>Exactly, in 99% of cases, developers are the most expensive part of any program. Also computers are cheaper to scale, in most cases <emacsen>the exception is when you are at Google-type scale <Frosku>Yeah, but even Google tend to use Go over C <Frosku>Even though C is more performant <emacsen>Frosku, yup yup. As for compatibility, there are and have been efforts to make software more compatible by abstracting out the runtime. That's what the JVM tried to do. With Webassembly we may even get it in our lifetime. <emacsen>ashishdev, yes but you see, D is one more than C. :) <emacsen>that's why J is better than APL, because it's lower in the alphabet. <Frosku>Well, asm is faster than C (assuming you can write better ASM than the C compiler, which often isn't true) <ashishdev>I don't know why people like to rewrite whole thing in other languages which are written in c. why not make a language that is compatible with c and add some compiler abstraction <emacsen>Frosku, by your analogy, assembly is the formula one car without the safety harness or colission resistant frame. ;) <Frosku>emacsen: Assembly is the land speed record car with the rockets on <Frosku>It goes very very fast and occasionally just explodes <emacsen>Frosku, I was going to say it's a little red wagon with a rocket on it, but sure :) <emacsen>ashishdev, if we only ever learn one language, we'd be bad programmers. Also if that were true, I'd be writing programs in LOGO :) <ashishdev>I think C is not less secure but compiler is. <Frosku>C requires the developer to think about things which other languages don't <ashishdev>but if u make some library on top of c and add some compile flags that's would be nice <emacsen>ashishdev, anyway, as the song goes, God wrote in Lisp, so that's why people use Guile :) <DanklyTuned>If I want to use ``(use-modules (gnu packages))`` instead of specific modules, then I must use the ``(map specification->package ...)`` form? ***iyzsong-- is now known as iyzsong-w
<DanklyTuned>Or can I just have ``(use-modules (gnu packages))`` along with ``(use-package-modules ...)``? <DanklyTuned>I should clarify, my desire is to name specific packages I want to install without worrying about what specific namespace they come from, example I want to install "mg" but it'd be nice if I didn't need to know it belonged to the "text-editors" namespace. <DanklyTuned>Hm, I think this question came from a poor approach, doing something different now. Also need a better understanding of Guix, will come with use and more reading :) <jgibbons[m]>I just use ``(map (lambda (pkg) (specification->package (symbol->string pkg))) '(...))`` <jgibbons[m]>It allows me to specify packages by name without worrying about namespace or specifying strings. <jgibbons[m]>I can even ``(define %packages '(...))`` and use %packages in the above snippet. <DanklyTuned>jgibbons[m]: Seems a lot of work to avoid using a list of strings, isn't it? <DanklyTuned>I guess not a lot of work, just more typing/round-a-bout. <jgibbons[m]>But it would be nice to have a `symbols->packages` function or syntax in (gnu packages)... <jgibbons[m]>In an old system configuration, a lot of my system packages were xfce apps with the same prefix. I used ``(map (lambda (pkg) (specification->package (string-concatenate ("xfce4-" (symbol->string pkg) "-plugin"))) '(...))`` That config was organized in an interesting way. <jgibbons[m]>On a desktop install, some processes dump their output to tty1. This makes that tty unusable because I don't know when it will be interrupted. <jgibbons[m]>One suggestion to clean up tty1, set the logfile of elogind, geoclue, and ntp to a log file that rottlog can take care of. These programs can give hints about location and other habits, so I think there should be an option to turn off loggin. <jgibbons[m]> * One suggestion to clean up tty1, set the logfile of elogind, geoclue, and ntp to a log file that rottlog can take care of. These programs can give hints about location and other habits, so I think there should be an option to turn off logging. <DanklyTuned>jgibbons[m]: That doesn't sound like overthinking given there's a straightforward option available to you. <jgibbons[m]>Are those daemons enough of a privacy concern to bother with the option to turn off the logging? If someone is able to read the logs, then the device has already been compromised. <jgibbons[m]>It looks like avahi-daemon, nscd, and NetworkManager make their home on tty12, which is means it's useless as tty1 except it's not even in the default config. Why/how do these daemons choose different ttys for their default output? <jgibbons[m]>I saw a dbus message on tty12 and decided to stop the dbus service with herd. Then I couldn't log in with another vt. Hacking is so fun! <jgibbons[m]> * Good thing shepherd forgets everything on reboot... <i1l>hi. any chance to get an .iso for aarch64 on Downloads page? <i1l>or Armbian -> Guix -> Guix System is the only way? i may be missing something. <brendyyn>i1l: I suggest posting this request to the mailing list. It's much more likely developers will read your message and respond <abcdw>sneek: later ask pineapples I've not recieved a private message, please send it agin or drop an email. andrew [-at-] trop.in <abcdw>sneek: later ask pineapples Probably it was an issue with my client. <efraim>nckx: I don't think your tmux-xpanes commit did what you think it did ***iyzsong-- is now known as iyzsong-w
<wingo>dunno if guix's progress spinners / updates are rate-limited but probably they should be <wingo>gosh that blog's notes regarding compression are very related to guix substitutes server discussions ***jx97 is now known as jx96
<brendyyn>wingo: the background on that blog Suprisingly Hurts my Eyeballs <brendyyn>actully, i realised its because i have Dark Reader mode. it makes it much more dramatic ***jx97 is now known as jx96
<sneek>pineapples, you have 2 messages! <sneek>pineapples, abcdw says: I've not recieved a private message, please send it agin or drop an email. andrew [-at-] trop.in <sneek>pineapples, abcdw says: Probably it was an issue with my client. <rekado_>lle-bout`: the URL I sent you doesn’t return a page that can be rendered. It returns an mbox that your browser will download. <davidl>Hi, how can you keep a build output directory when the build succeeds? <davidl>guix build -K <package> only keeps it when the build fails. <allana>Hi Everyone. I recently submitted a patch for the first time in a good while, and I made a mistake in the package license metadata. How does one go about fixing this kind of mistake? <sneek>allana, nckx says: Reddit links are fine; AFAIK we don't really have a link policy beyond ‘nothing obviously evil’. Almost every Web site apart from fsf.org will lead you to unfree things if you click often enough :) Just try to avoid non-free JS if there's an alternative without. <brendyyn>allana: you make a new patch and send it in with [PATCH v2] <PotentialUser-27>To send a package to (guix-patches@gnu.org), requires a specific format? Or Copy and Paste? <brendyyn>PotentialUser-27: its possible that copy-pasting can mess up the formatting. so you would either send it as an attachment, or is the command line git send-email to send it <pkill9>does anyone have a decent way of knowing what the current working directory is at the beginning and end of the build phase of a package? <pkill9>hmm actually it would be trivial to add a phase that does this <pkill9>then again can't tell when it fails build phaswe <brendyyn>is there a simple way to add variables to /etc/environment in my os definition? <abcdw>brendyyn: something like that <abcdw> session-environment-service-type <civodul>mothacehe: nice! so the dashboard gives an overview of all the builds of a given evaluation, right? <Arnik>I have configured my confi.scm in this way: http://ix.io/2Va3 and I get this error: guix system: error: service 'console-font-tty1' provided more than once <mothacehe>civodul: Thanks. Right, there's a new "Jobs" table that records all the jobs for an evaluation. <civodul>mothacehe: i like the dot map, but what about also having numbers of succeeded/failed jobs that you could also click on? <mothacehe>sure that can be done, i though that browsing a 17k+ list would be somehow inconvenient <civodul>well, the list of failed builds is the one that makes most sense <mothacehe>yes right, i would also like to be able to diff evaluations <mothacehe>and there's a new "/api/jobs" API that I plan to use to extend channel-with-substitutes <civodul>perhaps there should be a way to see the total numbers too? <civodul>(i think Hydra would show total numbers) <mothacehe>yes, having both relative and absolute numbers could be interesting indeed <civodul>maybe with a toggle between absolute and relative <pkill9>how do i make guix fix all the other areas of my life? <tissevert>Arnik: I suppose console-font-tty1 must already be declared in some of the %desktop-services <morgansmith>when I build something with the "with-branch" package transformation does it store the commit anywhere? I think it'd be nice to have the version include the commit short hash instead of just saying "git.master" <apteryx>does anyone know why pulseaudio can't connect to an already started pulseaudio server when ran in a pure environment? Which environment variables should I leak? <lubrito>Hi everybody. I'm an Outreachy Applicant. I had followed all the local environment setup instructions until "2.5 Building the source files". I could run ./bootstrap.sh but ./configure is giving me an error :"./configure: line 2365: syntax error near unexpected token `3.0' <lubrito>./configure: line 2365: `GUILE_PKG(3.0 2.2)' ". I would appreciate if anyone could help me to understand it. <tissevert>apteryx: isn't DISPLAY the xorg thing ? I'd be surprised it worked to fix pulseaudio <morgansmith>apteryx: env | grep -i pulse might help. I'm not sure though <civodul>mothacehe: i just did M-x build-farm, which i hadn't done in a while, and it seems to suffer from bitrot <morgansmith>apteryx: also try exposing /tmp too. I've found that fixes common issues <mothacehe>civodul: didn't even know it ever existed :p <morgansmith>apteryx: oops, you said pure, not container. ignore the /tmp thing <apteryx>morgansmith: yeah, there aren't any PULSE* variables set on my Guix System, and it works :-/. <apteryx>so it can't be a pulse-specific environment variable <morgansmith>apteryx: Odd. I have PULSE_CLIENTCONFIG and PULSE_CONFIG set. Not sure why <apteryx>morgansmith: is this on Guix System? <morgansmith>also you should have some pulse cache stuff in ~/.config/pulse I would think <apteryx>I ran the command in another env... lol <apteryx>I'll try adding a --preserve=PULSE and see <brendyyn>morgansmith: pulseaudio-service sets those <morgansmith>brendyyn: Oh good. I did some weird stuff a while back and wanted to make sure it wasn't just me :) thanks <brendyyn>in xfce i cant edit any network manager connections with insufficient privileges ;/ <morgansmith>I always just do sudo nmtui. There is probably a group that I should be in <apteryx>weird, still doesn't work even with -E PULSE -E DISPLAY <morgansmith>it keeps home right? Like it's still able to see ~/.config/pulse? <morgansmith>apteryx: What are you actually trying to do? I tried this and it seems to work fine: guix environment --pure --ad-hoc pulsemixer -- pulsemixer <morgansmith>oh wait, that doesn't work. It doesn't update when I change the volume and stuff. It appears to work but I don't think it's actually connected to the system pulseaudio <apteryx>try pavucontrol; it fails to connect <apteryx>something like: $ killall pulseaudio; pulseaudio; guix environment --pure --ad-hoc pavucontrol -- pavucontrol <morgansmith>when I slide the slider up and down it beeps at me so I think everything is all good <apteryx>ah, so it's probably something else in the manifest I'm using that is causing a problem then <apteryx>thanks for making me realise that :-) <morgansmith>I think there is still some odd things going on though. outside of the environment I couldn't play my music until the environment had been shutdown for like 10 seconds. <apteryx>no, it's working fine too. it seems the key was restarting pulseaudio on the host <morgansmith>and if I start the environment with my music already playing, it can't find my audio devices. It seems like the environment trys to reserve the controls or something. If it's working for you, all the power to you, but it is certainly acting funny on my computer. But my audio setup is pretty terrible so it's probably just me :P <apteryx>morgansmith: ah really? I've had that observation before; I could either run pulse in the environment, or on the host, but not both <apteryx>when already running on the host in the pure environment it wouldn't be able to connect to; if starting a fresh one from inside the environment the inverse situation would occur (cannot connect to it from the host) <morgansmith>ya idk. This is certainly above my pay grade. But at least we got the behaviour characterized. To go deeper I think you'd have to understand how pulse does its client server thing or whatever <brendyyn>pulse has a socket in XDG_RUNTIME_DIR it connects to <morgansmith>can confirm, this work absolutely beautifully. Thanks brendyyn!! guix environment --pure --ad-hoc pavucontrol -E XDG_RUNTIME_DIR -- pavucontrol <morgansmith>intrestingly enough, guix environment --pure --ad-hoc coreutils -- env, shows that DISPLAY is perserved for me without specifiying it <apteryx>morgansmith: perhaps it's special cased? to allow the common use case of running graphical applications? <apteryx>indeed it seems to be: %precious-variables is set to: '("HOME" "USER" "LOGNAME" "DISPLAY" "TERM" "TZ" "PAGER")) <morgansmith>debatable how precious pager is but ok. also what's TZ? <brendyyn>apteryx: morgansmith I think XAUTHORITY is also needed too. since you killed pulseaudio and ran it yourself it will work without it, but if your using gdm then pulseaudio will be started by it <apteryx>OK! Good to know. I wouldn't have noticed as I'm using ratpoison, and the applications start the pulse server on demand (e.g., icecat) <brendyyn>I was actually thinking of making a bisecting tool for environment variables. you could run a command in a loop, where each time it adds another env back in to the pure environment until it works <morgansmith>oh my xauthority is totally messed up. I didn't want it appearing in my home so I set the environment variable but now it doesn't generate an xauthority anywhere from what I can tell. Am I supposed to set the variable to the file I want it to create or to a folder that exists? <brendyyn>mine is set to /run/user/1000/gdm/Xauthority <morgansmith>mine is set to /run/user/1000/Xauthority but there is not file there :/ <morgansmith>slightly offtopic, why we gotta shorten user to usr almost everywhere but not in /run/user? Are we really saving that many characters? Why does the command have to be umount instead of unmount? unix stuff makes me a little mad sometimes :/ <brendyyn>dunno i think if its unset ~/.Xauthority will be used ? <morgansmith>that file used to exist but since I set the variable in my profile it stopped existing <morgansmith>idk. I haven't seen any issues yet so I'm going to assume everything is fine :P <tissevert>morgansmith: you mean for /usr/* or are there other occurrences ? <morgansmith>usrmod too. I'm kinda shocked it spells it out in full. I don't think I've ever seen user spelt out except in documentation <morgansmith>I guess I'm an idiot and maybe it is usually user :P <tissevert>plus I think /usr is actually supposed to stand for User System Resource but apparently that's a backronym and it was originally supposed to mean user like you said (in which case, being some super old arcane UNIX stuff, the length argument is probably most valid) <morgansm`>I'll still be salty about grp and umount but I guess usr gets a pass then <morgansm`>oh no, how do I get my name back? irc really confuses me something... ***morgansm` is now known as morgansmith
<pkill9>saves one character in exchange for mental confusion <morgansmith>to be fair, typing nm is kinda difficult for me. not a common combo and I type them with the same finger <morgansmith> Anyone know where the package transformations set the version? I want to make a patch so that the version would be something like "git.master-a0609772" instead of just "git.master". guix/transformations.scm looks pretty complicated :P ***morgansm` is now known as morgansmith`
<morgansmith`>oh wait, I don't know if that change is actually possible. It looks like the version is set in transform-package-source-branch which I think is run before we ever hit the remote server. Meaning we set the version before we know the commit. ***morgansmith` is now known as morgansmith
<morgansmith>leoprikler: Should I rebase my geiser patches on the wip-emacs branch so they can just be commited there instead? <morgansmith>oh god why do I keep spamming empty messages... I think my irc client is funky <morgansmith>I don't irc too often, but when I do, there is always issues... <leoprikler>I only had a short look at them, but imo they should be fine (modulo rebase, of course) <morgansmith>not going to lie, I did not test guile-studio. I built it, opened it, and then it complained about ivy so I just assumed something else must've already been broken. It didn't seem to complain about geiser <morgansmith>also I'm not sure when alezost took over emacs-guix. I remeber when jsoo1 took it over, but I couldn't find any announcment from alezost <leoprikler>tbf I'm not the target audience of guile-studio either, so 🤷️ <morgansmith>jsoo: You cool with us updating emacs-guix using the source from alezost? It seems to be 3 commits ahead of your copy <leoprikler>morgansmith: the comment already says, there's no official source, so you can pick whatever you want :) <morgansmith>leoprikler: I suppose. I just don't want anyone to get upset for me accidentally making unofficial forks canonical for no reason. <Ikosit>Does sb know a good development stack for java? <leoprikler>btw. what's wrong with the expand-file-name code in geiser according to your opinion? <morgansmith>leoprikler: If you're talking to me I'm not quite sure what you're referring to <morgansmith>oh I dunno. Anytime I can hard code a path I just do. I assumed the elisp union or whatever would mess up the src location <morgansmith>I did it proactively. I didn't check if it worked without it <morgansmith>Also how come the emacs-build-system always throws everything in include under /share/emacs/site-lisp? <morgansmith>Now I'm looking back at all the times I've used it to see if I've abused it or not. I guess most things do want to be right next to the elisp so I guess it makes sense. It'd be interesting to have a more generic include that is like an alist where you can specificy the output directory and then have that avaliable in all the build systems <leoprikler>hmm, it seems I can't set my implementation any more <morgansmith>I'll fully admit I never figured out how to use geiser because it seemed really buggy and me sending these patches was part of my trying to learn geiser again :P <morgansmith>but the implementation setup completely changed. Now each implementation is in a seperate repo and the commands for loading the implementations are different <roptat>did I find the only package that builds on arm but not on intel architectures? :D <leoprikler>fwiw the value of geiser-guile-scheme-dir is sane even without your changes <morgansmith>how are the name colors on logs.guix.gnu.org decided? idk if it's just my browser but my username seems to show up white on a white background (so it's invisible) <morgansmith>uhhh, so, I never checked if that phase actually did anything and it actually doesn't. I've been doing my (limited) testing with the guile-scheme-dir set to the default <leoprikler>well, better to just strip it, because then you can push to master, provided that geiser actually behaves sanely <morgansmith>do you have multiple implementations installed? if you only install geiser and geiser-guile than there is only one implementation to pick from <leoprikler>You mean the only implementation not to pick from. <morgansmith>oh I set geiser-active-implementations in my init. maybe that's why I don't have an issue <morgansmith>I don't think you're supposed to have to set that variable. Now that I've unset it I see the issue <morgansmith>I think it's supposed to be able to grab implementation from geiser-implementations-alist <i1l[m]>nckx: hi. will you ever unban the glat-agent? his term is ended i think. <morgansmith>leoprikler: I think this is an upstream bug? The code looks a little funky. If you run run-guile to get a guile repl you can then run run-geiser and that will successfully run a guile repl because the active buffer is a guile repl. <leoprikler>As far as your patches are concerned, if you refrain from doing meaningless patches, they don't need to be filtered through wip-emacs. <morgansmith>what's the big difference? Is it just all the file paths will change so I shouldn't specify file paths? Or are we changing the emacs-utils.scm stuff? <leoprikler>also package-internal relative paths are pretty sane on wip-emacs <morgansmith>oh I see. we're trying to stop files from overlaping each other. We really should make unions throw errors when that happens. That's how the openrc bug happened, why our arm-none-eabi-gcc is currently messed up (someone please accept my patch), and I guess what we're fixing here <leoprikler>meh, I'd rather fix the instances, where it really leads to issues, than have union-build hard error <morgansmith>wait, it's possible to have an unversioned emacs binary? <leoprikler>there are many sane cases for union-build to overlap <leoprikler>the unversioned emacs binary points to the versioned one <leoprikler>another instance, where it makes sense to not hard error with union builds <leoprikler>that way you can test out both emacs and emacs-next in the same environment :) <morgansmith>I can't say I quite understand how the unions work but I'm seeing way too many bugs coming from overlaping files. I'd really like to have at least some kind of optional warning or something. <leoprikler>you can crank up the verbosity to see all conflicts <leoprikler>you may not like it, but this is peak warning level <morgansmith>I'm just really really salty that no one is accepting my conflict patch for arm-none-eabi-gcc. Like once a week I gotta go bang my head against the wall because it's still broken. Like someone please. Who do I gotta pay off? <morgansmith>and then I contributed the openrc thing and went to use it like a week later and found that someone else had changed the paths so there was a union conflict and then I couldn't use it. I just gave up at that point honestly <morgansmith>yep. that's it. until that's accepted you cannot do non-trivial c++ on arm <morgansmith>The minute you include any of the std library that overlaps it just dies ***EdmundMiller[m] is now known as Edmund[m]
<leoprikler>tbf I don't really understand paths like /arm-none-eabi/include/arm-none-eabi/c++/arm-none-eabi <morgansmith>ya idk I didn't think to hard about it. I work in embedded and no-one seems to care about paths so they just get uglier and uglier over time. <morgansmith>oh I now see why you couldn't open scheme files. Did geiser autostart on file open in version 0.12? I didn't think it did <leoprikler>yes, it did, but it could guess the implementation <morgansmith>bug 47325 is a great example of how no-one cares about paths. No-one uses the paths as they come out of the upstream project. Everyone just changes the names themselves for some reason. Except the upstream project creates files that refer to the renamed files. I really hate embedded a lot of the time. There isn't a single thing about it that feels clean or proper <morgansmith>I was meaning to create a proper patch for 47325 (the current patch works but isn't proper) but I got discouraged because of bug 44750 <morgansmith>leoprikler: So I downloaded the official pre-built arm-none-eabi toolchain from arm.com and the include paths look like this: arm-none-eabi/include/c++/7.3.1/arm-none-eabi <morgansmith>it does mean we are currently slightly wrong though, but like not by much <morgansmith>I've been using the current patch a bunch and can confirm it work pretty good in multiple projects. especially with the patch from 47325 added on as well <leoprikler>tbf I don't understand the issue in 47325 at all <leoprikler>like why tf do you need a shell function to install the things to their correct location? that's what make install should do <morgansmith>so gcc comes with a file that helps it find the libc or whatever. That little file says hey go look for libc_nano.a. but the upstream project only produces libc.a. this is because the upstream project is a fork of the fatter libc that creates a libc.a file. but also the file that says go look for libc_nano.a is in the upstream too somehow? It gets confusing real quick cuz there is sorta two upstreams in this specific case <morgansmith>also the shell function clearly copies, but we should probably symlink or something. maybe hardlink? I've never done a hardlink before <morgansmith>oh dear. the pre-built has a differnt sha1sum for libc.a and libc_nano.a. I guess we're supposed to just have one toolchain that supplied both the fat one and the nano one <morgansmith>I think it makes more sense the more you know. I think the idea is that the nano lib deviated as little as possible from the project it's based on to limit the work they have to do but then people wanted toolchains that supported both newlibs instead of just one. So to build these toolchains, custom scripts where made <leoprikler>As a user of Guix, it still doesn't make sense :P <morgansmith>although that explanation still doesn't justify the nano.specs references to libc_nano.a. ugh. Ok make it doesn't make sense <morgansmith>ok so the pre-built has a path of c++/7.3.1 but ours has a path of arm-none-eabi/c++. I guess I should figure out why that is... <pkill9>here's an idea: if you try to open unknown filetype/URI with xdg-open, it offers you software that can be used to open it and guix gets the software ot open it <morgansmith>that'd mean we'd make a system package that includes a custom desktop file that points to a script in the same package? Seems doable I think. <morgansmith>if we can't do it using a custom desktop file we'd have to wrap xdg-open, right? <morgansmith>Would this mean we'd extend the package definition to include an alist of binaries and the filetypes/URI's they open? Or is there a better way to collect this metadata <morgansmith>oh actually the metadata would need to include the calling convention for the binaries as well I think <leoprikler>well, you could just install a bunch of .desktop files, that launch guix environment with appropriate parameters instead <leoprikler>(that way you could also choose to containerise as you want) <pkill9>it would be a wrapper pretty much <pkill9>but it requires metadata on packages <pkill9>which is why I need all the .desktop files of all the packages <morgansmith>would you have to scrape every package for it's desktop files then? So we'd have a package that depends on every other package? I feel like collecting the metadata is the hardest part right? <pkill9>which has been talked about before <pkill9>well ideally the guix data service would be extended to allow you to search for and download individual files from all the packages <pkill9>which would be useful for other things, like finding out which packae provides a given library or binary <morgansmith>the other day I was trying to figure out what package provided the dig binary. That is a really hard thing to do currently. <morgansmith>I'm much more interested in that feature then the xdg-open stuff <morgansmith>leoprikler: so the arm-none-eabi/include/arm-none-eabi path doesn't exist and I made a mistake on the axoloti patch. I really think my gcc patch is gold though. I'm looking at axoloti now <Arnik>I have configured my confi.scm in this way: http://ix.io/2Va3 and I get this error: "guix system: error: service 'console-font-tty1' provided more than once". How can I fix this problem? please give me an example of corrected config.scm. <morgansmith>tty1-7 are already defined. You could switch your tty definition to tty8 if you want. <Arnik>morgansmith: How can I edit the previous defined , please show me an example. <morgansmith>s/(service console-font-service-type `(("tty1" . ,(file-append/(service console-font-service-type `(("tty8" . ,(file-append <morgansmith>that probably didn't format nicely. Just change the "tty1" to "tty8" <Arnik>No, I need the changes on tty1 <morgansmith>Then you'll need to use the modify-services function thingy <Arnik>morgansmith: I'm not pro of conif , How is it possible? <morgansmith>I'm also not a pro and I'm well known to tell people the wrong thing confidently. I'm looking it up. One sec <Arnik>morgansmith: I know , thanks, I'll wait <morgansmith>Arnik: wait, did you modify this yourself at all or did this come out of the graphical installer this way? <Arnik>morgansmith: this came out from graphical installer, I just hide some private info . I did not select any wm at all <morgansmith>So this is a bug with our graphical installer? The tty1 stuff was added by the installer? <roptat>echosa, do you have ~/.config/guix/current/bin first in $PATH? <Arnik>morgansmith: no I add the tty1 stuff <morgansmith>Arnik: Ok, all good. Just wanted to make sure :) I'm still working on it <katco>putting this out into the ether: i wish there was a way to specify a memory constraint to `guix environment --container` <echosa>@roptat, Yes, though looking at my path, apparently I have a lot of duplicates. <echosa>guix is hashed (/home/echosa/.config/guix/current/bin/guix) <roptat>is the issue with sudo or not sudo, and foreign or guix system? <roptat>mh... I don't know what's happening then, everything looks alright <roptat>what does "guix desribe" tell you? <echosa>Ah. It shows I'm on generation 9, but the latest generation is 18 <echosa>I'm switching to the latest, pulling, and upgrading again <roptat>oh, why didn't it switch to the latest? <echosa>I had switched it back manually to completely undo a previous bad upgrade. When you set it manually with `guix package -S` does that pin it so that it doesn't switch on future upgrades? <roptat>no, it's just switching to that generation, and then guix pull is supposed to switch to the one it pulls <roptat>there's no really point in building a new generation and not switching to it <echosa>Huh. My latest generation is 18. When I do `guix package -S 18` it says it switched, but when I do `guix describe` it still shows generation 9 <roptat>guix package -S 18 switches your default guix profile, in .guix-profile, not in .config <roptat>you can use guix pull for that: "guix pull -S 18" switches guix pull generations <roptat>alternatively, specify guix package -p ~/.config/guix/current <echosa>Tried `guix pull -S 18` and got "guix pull: error: cannot switch to generation '18'" <echosa>I'm tempted to just delete guix and reinstall from scratch, just to start fresh and avoid any issues I've inadvertently caused. <echosa>but I'd like to understand and fix the issue, for the learning experience if nothing else :-) <morgansmith>Arnik: sorry for taking so long. This service is different from other services for some reason. Do you want only tty1 changed or all ttys? <echosa>`guix describe` says gen 9 is current. `guix package --list-generations` says gen 18 is current. <echosa>Ah, since I'm "stuck" on gen 9, `guix pull -S` won't let me switch to anything newer than gen 9. However, `guix package --list-generations` still shows gen 18 as current. I don't know why. <lfam>ochosa: By default, those commands use a different profile, and their respective profiles will have different history of generations <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, apteryx says: I just sent a patch addressing the QEMU 9p performance warning you reported <lfam>echosa: Sorry, I wrote your name wrong <echosa>lfam, Which profiles do each use that they are different? <lfam>`guix pull` uses the profile at ~/.config/guix/current, and `guix package` uses ~/.guix-profile <lfam>The former is used for Guix itself, and the latter is used for the packages you install <lfam>`guix package` can be used to inspect any profile, by passing the --profile argument <lfam>Inspect, operate, any type of thing you want to do with a profile <lfam>So, for example, you can list the generations of the `guix pull` profile like this: `guix package --profile=$HOME/.config/guix/current --list-generations` <echosa>Ah. Well, right now since I'm "stuck" on gen 9, I'm making sure that both pull -S and package -S are set to 9, deleting all gens past 9, running garbage collection, and pull/upgrade again <lfam>Sorry, that's based on a misunderstanding <lfam>The profiles are numbered, but the two profiles are different, and don't have the same history <lfam>It's like, you had a 9th birthday, and so did I. It was not the same event :) <lfam>We each have our own history <echosa>When I `guix pull`, do I need to `hash guix` before I `guix upgrade`? <lfam>Or like, Guix has a 3rd commit in its Git repo, and so does Linux <lfam>They have nothing to do with each other, and focusing on the "3" is not very useful <roptat>echosa, hash guix would ensure the guix command is found from .config/guix/current, which is already the case on your system <lfam>So, you are trying to figure out why Guix is warning you that it's getting old? <echosa>Yes. But I already switched to an older generation (9, because of the misunderstanding), deleted the newer generations (they were just upgrades, no new installs), and am running pull and upgrade. <echosa>We'll see what happens after that <echosa>If you know why I was getting the "old" message, though, please tell me. :-) I'd love to know <lfam>Let's wait until your current `guix pull && guix upgrade` finishees <lfam>I would expect that to solve it <echosa>Yep. No more "x days old" message. <leoprikler>building profile with 968 packages... Is that how people use Guix? :) <morgansmith>Yo, I cannot figure out this damn console-font-service-type for the life of me. I got some error like this somehow: guix system: error: invalid character `*' in name `console-keymap.***-builder' <morgansmith>is this not how you're supposed to do it? (modify-services %base-services (console-font-service-type s => (map (match-lambda ((tty . font) `(,tty . ,my-font))) s))) <morgansmith>(define my-font (file-append font-terminus "/share/consolefonts/ter-132n")) <lfam>I thought I had a lot with 115 packages <leoprikler>It's just my wip-emacs environment for "all" Emacs packages <echosa>Where do you get a package count? <lfam>`guix package --list-installed | wc -l` <lfam>At least, that's what I just did :) <lfam>I think the Guix UI prints the number during certain operations <lfam>But if it were, leoprikler would win <leoprikler>Nah, my profile with day to day packages contains 57. <leoprikler>The branch on which I do all the malicious changes, that I plan to silently sneak onto master. <vincele>Hello, I'm trying to guix pull on a very old i686 guixsd install, but it fails DL'ing "Git error: the SSL certificate is invalid" is there anything I can try ? <lfam>vincele: I guess that your copy of the x509 / SSL / TLS certificates is so old that it no longer works :/ <lfam>If you are feeling adventurous, you could try obtaining a more recent copy of the certificates somehow, and figure out how to make Guix use it until you are able to update <lfam>I'm curious, how old is old? <vincele>lfam, almost a year old... (842a9d8), I'll try with a recent binary tarball extracted upon /gnu/store... <morgansmith>what's the best way to check if two build are identical? Like locally when making packages. I got two file paths. Do I just diff them? <lfam>You could use `guix build --check` or `guix build --rounds=4` <lfam>If you are comparing different package recipes (different "derivations" in Guix lingo), then you can use the diffoscope program to compare the results <morgansmith>yep different derivations. Thanks you very much. will do the diffoscope thing <lfam>I like to do `diffoscope --html report.html thing1 thing2`. It's easy for me to read the HTML report, which uses colors to highlight differences <morgansmith>that is a very long ETA. I think I'm just call it fine. I don't think axoloti-runtime is super popular anyways. <kisaja[m]>Hello, does "USE flags" like feature have some docs or directions it is going to go? <lfam>morgansmith: Yeah, it's pretty slow : <leoprikler>there's some wip in the mailing lists, but afaiu it's not yet very clear how we want them to be applied <leoprikler>(other than that we certainly don't want to be gentoo) <morgansmith>leoprikler: So about bug 44750, I'm super convinced that the gcc-arm-none-eabi v3 patch there is correct. I just sent a new patch (v4) that does axoloti a little nicer. So if you could commit those two patches, I would be super grateful! <utkarsh181>Is it possible to use guix without linux-libre as my craptop doesn't support linux-libre? <morgansmith>leoprikler: Thanks for finishing of the geiser stuff! <leoprikler>It is and people are doing it, but we can't instruct you on how to do it here. <apteryx>utkarsh181: doesn't support as in 'the wifi chip doesn't work'? <roptat>morgansmith, policy is to not mention them, as they provide non-free software <roptat>we don't recommend running non-free software <morgansmith>roptat: like at all? Is it against policy to mention it even if you condone it in the same sentence? <utkarsh181>So how the functional aspect of Guix help you in your day-to-day task? <morgansmith>Not arguing, I just want to be know the policy so I can follow it <roptat>clearly, even if you condone them in the sentence, you're still encouraging users to use non-free software, that's a big no :) <morgansmith>roptat: Sounds good. I apologize for mentioning them. I should've clued in when I read leoprikler's response. I won't do it again <apteryx>is anyone actively using the go importer? <vagrantc>i vaguely recall talk of releasing 1.2.1 april 18th ... is that still likely to happen? will there be release candidates over the coming week? <morgansmith>utkarsh181: Instead of writing a 42 page document on how to setup an embedded development environment and build our projects I can just write a package definition that is only like 50 lines long. Easy reproducibility is crazy cool. That's probably the main time save for me :P <vagrantc>nicer to have a release candidate tarball to run my magical spellcheck powers over :) <leoprikler>morgansmith: regarding embedded development environments, tbph I don't have the guts to touch bootstrap packages of arches I don't use <vagrantc>in similar news, would be nice if there was a "make dist" job running on ci.guix.gnu.org that exported the tarball somewhere <morgansmith>leoprikler: do we actually use that package for much? To be clear, this toolchain is for bare metal development. So I doubt it is in heavy use at all. There is a completely separate toolchain for compiling packages to run on linux or herd on arm. This toolchain is completely different from that one. <utkarsh181>Is this true that mojority of guix user are also emacs user? <morgansmith>leoprikler: I'm like 99% certain I already investigated every other thing in guix that uses it and I've vetting it on multiple other projects. <lfam>vagrantc: Yes, that is the plan <lfam>The CI makes installer images as part of its regular activity <morgansmith>utkarsh181: I think it'd be hard to be a guix user without also being a guix developer. I keep finding myself needing to make more packages to keep up with the tools I use. Guix is built using scheme, and I'd say it's likely that most scheme/lisp developers use Emacs. <vagrantc>lfam: but i need a release tarball, not an installer image :) <leoprikler>To the extent, that I don't know how well parts of our manual would be received by users of other editors. <roptat>utkarsh181, you don't have to use emacs to use guix :) I'm a vim user <lfam>vagrantc: The binary installer tarball for Guix on other distros? <morgansmith>I mean I don't think I actually benifit too much from emacs for guix development. Maybe that's just because I still haven't figured out geiser :P <morgansmith>oh god the newlines again. I don't know what causes it... <lfam>vagrantc: Let me see if the CI is making these <lfam>If it is, it's basically the same thing we'd release <leoprikler>90% of my Lisp hackings I don't even (actively) use Geiser <vagrantc>lfam: when i've run it manually ... it tends to pick weird versions ... e.g. git describe --match=v'*' tends to return 1.0.1 or something <morgansmith>so about bug 44750, is it going to just remain in limbo? Is there someone that feels comfortable with embedded stuff enough to commit to the arm-none-eabi toolchain? I do want to point out that the toolchain is very clearly broken currently and I don't think we can make it too much worse <lfam>vagrantc: To clarify, which command are you running? <kisaja[m]>about mentioning non free software. Maybe there should be a link to h-node so ppl can easily check their components before hopping on <vagrantc>e.g. on current git master: $ git describe --match=v'*' <lfam>kisaja[m]: Yeah, perhaps. I think a lot of people don't even know that it could be an issue, or what to look for <lfam>Like, I know that wifi is probably going to be a problem. But most people don't seem to know that <vagrantc>which is basically whay ./build-aux/git-version-gen runs <lfam>I see, how strange. Same here <vagrantc>lfam: something to do with the git merge lineage <lfam>Alright, I'll start coordinating release candidates later today, vagrantc. Hopefully they are ready by this Friday, and we can have a test-a-thon over the weekend <vagrantc>i could run "make dist" on my own, but if it's happening anyways, i might just as well wait <leoprikler>IIRC, the manual clearly mentions both RYF and h-node, or at least RYF. <echosa>lfam, Welp.... I'm back. I had to do a system restore to fix a driver issue, had to redo a bit of my guix setup, and I'm back to having the "x days old" message. <leoprikler>morgansmith: I had a look at cbaines' patchwork, but it seems while your series exist, there is no data for them, which is… strange <morgansmith>what's this patchwork? some CI system? Sorry I'm really uninformed when it comes to our infastructure <lfam>echosa: A system restore? <leoprikler>This thing should make review easier by automatically checking whether everything builds fine. <morgansmith>I see 5 successes. Is there supposed to be something else? <echosa>lfam, Point is, I'm back to having the "x days old" message, even though I've run pull and upgrade, as recommended <lfam>echosa: Basically, look at `guix describe`. If the date is old, then it's old :) <lfam>I don't know what "timeshift restore" is. But it sounds like maybe it rolled back the updates somehow? <echosa>Ignore the timeshift. Red herring for this issue. :-) <echosa>guix describe shows march 25, which is indeed "old" <lfam>I know, you already did that <lfam>Remember, with Guix, this stuff is per-user. So, if you do it for root, it's only for root. If you do it for user 'echosa', it's only for echosa <leoprikler>morgansmith: the comparison one is a false positive; it always signals success even if the link to click on serves nothing <morgansmith>leoprikler: I probably should've just resubmitted my patch v3 1/2. I didn't realize we have this system. The v4 patch replaces the v3 2/2 so it should fail unless v3 1/2 is applied <leoprikler>thing is, I tried checking out v3 1/2 (which exists in patchwork), but it doesn't yield a useful comparison either <echosa>lfam, I did it for both. `guix package --profile=$HOME/.config/guix/current --list-generations` shows 9 generations, all only involving `guix` package. gen 9 is the march 25 generation shown by `guix describe`. On the other hand, `guix package --list-generations` shows 4 gens, with my user packages (emacs, httpie, rlwrap, etc) with a date of april 7 (today). <lfam>Okay echosa. That sounds good <echosa>so it's the $HOME/.config/guix/current profile that needs to be updated, I guess. <lfam>And that's done with `guix pull` <morgansmith>leoprikler: axoloti builds quite quickly but the toolchain will be a pain if you have to compile it locally. <apteryx>vagrantc: try with git describe --debug --match=v'*' <echosa>lfam, ah. `guix pull` updates $HOME/.config/guix/current and `guix upgrade` updates `$HOME/.guix-profile`, right? <apteryx>vagrantc: for some resaon 1.2.0 is farther than 1.0.1. I'm not sure how that makes sense. <leoprikler>that'd be better, because then reviewers at least have the full series <lfam>Are you familiar at all with managing packages on Debian / Ubuntu? Like, apt-get? <echosa>Ok. So then `guix pull` isn't upgrading correctly I guess? <echosa>Yes. I use Pop!_OS, which uses apt <leoprikler>I can't promise you that patchwork delivers results for the rebuild quickly, though. <lfam>Okay. `guix pull` is similar to `apt-get update`. It updates the list of available packages (and services, on Guix). Whereas `guix upgrade` is like `apt-get upgrade`; it updates the packages you've installed <lfam>echosa: Is it not upgrading correctly? What happens if you run `guix pull` now? <morgansmith>leoprikler: I'm upset because this patch is really important to my work and got stalled. The moment I can say it's no longer stalled, I'm happy. It doesn't need to be in today. It'd just be nice if someone said they would do it eventually. <echosa>lfam, guix pull downloaded a bunch of things then said "nothing to be done". guix upgrade still says its out of date. <echosa>and guix package --profile=$HOME/.config/guix/current --list-generations still shows march 25 as the latest/current generation <roptat>`type guix` rather, which is usually more accurate that which <morgansmith>ok, I've been stumbling around in the dark for long enough I guess. I'd like to learn about the support systems we have running for guix. Like the data service, and patchwork, and all the other things. Where can I find information on all the services? <roptat>echosa, what is /home/echosa/.config/guix/current/bin/guix ? Is it a symlink as expected? <roptat>er, /home/echosa/.config/guix/current <echosa>Yes, symlink: /home/echosa/.config/guix/current -> /var/guix/profiles/per-user/echosa/current-guix <lfam>Hm, can you share the full output of `guix pull`, too? It's weird that it doesn't see that there is new code available <roptat>something you can try is have a look at the cached checkout you have in ~/.cache/guix/checkouts (in one of the directories, I have pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq, but it can be another directory for you), check with "git status" that it's not dirty, and with "git log" that it's on the latest commit <apteryx>is the new power architecture covered by qemu? (e.g., can I use the transparent emulation feature to build POWER packages?) <roptat>looks like it's stuck at that old revision, not seeing newer ones <lfam>It's weird, echosa, it got stuck on an old commit <rhou[m]>I can `docker create`, `docker start` and `docker exec` my docker image created with `docker system docker-image` but I can't just run `docker run`, why is that so? <lfam>I would just delete the checkouts directory that roptat mentioned <lfam>It would be great to understand why this happened <echosa>roptat, the git status is there is clean <roptat>right, I agree, it should solve the issue, but we would never understand <echosa>so `rm -r ~/.cache/guix/checkouts && guix pull` ? Or do we still want to see if we can figure this out? <BlackMug>I was wondering does guix comes with ssh-server preconfigured by default? if yes why? <roptat>echosa, is the checkout directory owned by your user? <morgansmith>wait, what does patchwork actually do? Does is only check if the patch can be applied? It finished my patches way too quickly ***jx97 is now known as jx96
<BlackMug>apteryx so i see ssh generating keys message when first time booting guix for installation what is this message for? <BlackMug>generating keys for ssh-client = weird because client should do that if he needs it and if its for server then there is ssh-server in guix boot which is weird as well <apteryx>I'm guessing the installation image does include an ssh-server, for convenience <echosa>lfam roptat so I should so `rm -r ~/.cache/guix/checkouts && guix pull` ? <lfam>Yes, I recommend trying that <lfam>It will take a few minutes to clone the Git repo again <apteryx>BlackMug: yes, check the (gnu system install) module; it defines the list of services that are included in the installer image <leoprikler>morgansmith: it should also check whether it builds, but I have so far only gotten that info once <apteryx>more specifically, the %installation-services variable. It includes openssh-service-type. <apteryx>but if you use for example desktop.tmpl as the base template of your system, it doesn't include it. <leoprikler>and that was when Christopher himself gave me a link <BlackMug>apteryx i see, doesnt this bring security concerns to have openssh-server included by default? <apteryx>no, it's just in the installer image while you would be installing, not in the resultant installed system <leoprikler>And wow, will you look at this, the package I've submitted is already scheduled. <BlackMug>apteryx yeah i know but since ssh-server included by default any vulnerability exploited (known or unknown) will give malicious access to the distro before even fully installing it <echosa>lfam roptat I deleted the checkouts directory and ran guix pull. It recloned the git repo, but it is still at the same commit and I still get the "x days old" warning. However, this time, the `git status` says I'm 474 commits behind. I don't konw why `guix pull` isn't updating it or why I seem to be stuck on this particular git commit. <nckx>BlackMug: That is untrue. <roptat>do you use a mirror of the repository? <roptat>echosa, oh it says you're using the official repo from your previous paste, so never mind <echosa>lfam where should I run that? Just anywhere? <nckx>It doesn't matter that it's included. You can't exploit a service that isn't running. <BlackMug>nckx ssh-server not included in guix by default? <lfam>echosa: Yes, wherever is convenient. I want to see if it fetches the up to date repo or not <nckx>Are you talking about the installer, BlackMug? <nckx>Then: It doesn't matter that it's included. You can't exploit a service that isn't running. <BlackMug>nckx its disabled by default? (i mean not listening to predefined or the default port) <echosa>lfam cloned fine, git status is clean <lfam>echosa: And it shows commits from today? <apteryx>BlackMug: so unless you do 'herd start ssh', you won't have the SSH service running with the Guix installer <nckx>BlackMug: apteryx already told you about %installation-services where it's quite clear that it's not listening by defaulting. <echosa>lfam, yes, `git log -n 1` shows commit 02297d3fe680371a4b97b9c1b770932cbdd55615 from Wed Apr 7 15:25:34 2021 <nckx>Plenty of security vulnerabilities in Guix (most of them fixed, we hope ☺); no need to fear ones that aren't there. <echosa>lfam, should I do a manual `git pull` from the repo in the checkouts directory? <echosa>still dont' konw why it isn't automatically doing it <lfam>You could try `guix pull --commit=02297d3fe680371a4b97b9c1b770932cbdd55615` <echosa>Ok, did that, and now I'm just one commit behind. I'm going to see if `guix pull` with update to that one commit now <roptat>echosa, mh rightly so, but it's still weird it thinks 3f1b2bd is the latest commit <echosa>the checkout is back to being 477 commits behind. <roptat>I'm so confused, I have no idea what's happening <roptat>so now you're on generation 10, right? <nckx>i1l[m]: No, the earth will hurtle into a dying sun at great speed with G.L.A.T. and their agents banned in #guix. The name itself is designed to troll, and that's the *cheritable* interpretation. <nckx>Assuming that all who claim to've sent $ were trolling in return. <echosa>roptat, Yes. `guix describe` now shows gen 10 and is commit 02297d3fe680371a4b97b9c1b770932cbdd55615 from Apr 07 2021 14:38:16 <nckx>Strange seeing all of lfam's commits/mails go by. But for the best. <nckx>Thanks for taking care of it. <echosa>lfam roptat So, should I just completely remove guix from my system then reinstall it from scratch? Happy to do so, but wanted to try and help diagnose the issue for the benefit of all. <lfam>I really would like to figure out what is wrong... I don't know how to debug this :/ <lfam>I'm sorry you're experiencing this annoying bug <roptat>echosa, I don't see how it would help, but I don't have other suggestions either so... <lfam>I wonder if there is any "state" that echosa can preserve before reinstalling :/ <lfam>I wonder if it's a weird problem with `guix time-machine`? Or inferiors? <lfam>echosa: Maybe, you could do `guix pull -l 2>&1 | tee pull-generations.log` and send us the log ***ChanServ sets mode: -b PotentialUser-28!*@*
*roptat needs to go, see you soon <lfam>This bug has security implications, in that you can't get security updates :/ <echosa>I've apparently created too many pastes at debian.net because it won't let me paste anymore and tells me not to spam :-P <echosa>I'll create a github gist instead <lfam>Can you attach the log to an email to <bug-guix@gnu.org>, along with a description of the problem, and what you tried? <lfam>It's good that Guix warned you that something was weird, at least <lfam>Thanks for your patience <echosa>lfam, email sent to what I assume is a mailing list. Is there a web UI where I can see it and ensure it made it through? <echosa>Ah, nvm. I just got the automated reply. <echosa>is the URL the automated reply gave me <echosa>Thank you! Hopefully this can get figured out and fixed. <apteryx>civodul: can you wait a bit before pushing the qt-build-system related change <apteryx>I think I we can add QTWEBENGINEPROCESS_PATH to it <nckx>raghavgururajan: Why? (Disclaimer: I don't.) <nckx>I haven't noticed a significant increase over the years for which I could reasonably blame Guix git commits. <apteryx>raghavgururajan: you don't have to put your password in there if you don't want to <nckx>raghavgururajan: I wouldn't store any password, primary account or not. <nckx>I type mine every time. Perhaps you can GPG it, never tried. <apteryx>yeah, I wish it was as convenient as Emacs' .authinfo.gpg <raghavgururajan>I setup git send-email, but when I do the command, after yes/no/all, nothing happens. <nckx>There's apparently a ‘helper’ option in .gitconfig. <nckx>raghavgururajan: That sounds like a different issue. You should get a password prompt. <apteryx>raghavgururajan: is this on a remote machine you access through SSH? <nckx>Oh, I see where you're going. Clever. <raghavgururajan>Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=smtp.migadu.com encryption=tls hello=localhost.localdomain port=465 at /gnu/store/842fj3y7kv2vdlrddbnf04nm973wzml8-git-2.31.1-send-email/libexec/git-core/.git-send-email-real line 1566. <nckx>(I think you can add assume8bitEncoding = UTF-8 to the [sendemail] section to skip that first prompt.) <nckx>465 is suspicious, raghavgururajan. Sure it shouldn't be 587? <nckx>(It's not wrong per se, but less common.) <nckx>raghavgururajan: Then use ‘ssl’, not ‘tls’. <pkill9>i want to use one language for both scripts and the command line <Arnik>morgansmith: did you find the answer for setting tty1 font ? because I lost irc chats unfortunately. <nckx>raghavgururajan: That's how it works? <nckx>Hence the procedure described in ‘Sending a Patch Series’ in the manual. <nckx>So you don't open one bug number per related patch. <raghavgururajan>My daily outgoing email quota is 100. I spent 22 of it in less than a minute. xD <nckx>I have several questions, but am speechless. <nckx>Anyway, your patches have arrived safely. <raghavgururajan>Good that I got bug # first and used git send-email on that. else there would have been # for each patch. <Noisytoot>raghavgururajan, What email provider are you using? <civodul>apteryx: re qt-build-system, sure! efraim also listed a number of issues, but i haven't yet taken the time to look at them <raghavgururajan>Few Reasons I chose Migadu: [1] Web-portal works without JS [2] People behind it are fellow free software activists [3] Fair billing (by usage and not by no. of address/mailboxes/aliases etc.) [4] Excellent Support [5] They are working with SourceHut folks to create JS-free webmail system. <nckx>raghavgururajan: All right, that answers most of my questions :) I'm very happy you're supporting decent humans, even if I wonder how they compete even within the Free software advocate space. *raghavgururajan orders latte <raghavgururajan>Yo! When can I expect response for my application for commit access. :D <BlackMug>nckx what prevent malicious package to run commands within guix system? I tried to find that in the wiki but i failed. e.g malicious maintainer -> malicious package order it after installation to execute guix do x or (passwordless) sudo do x <nckx>I can't say. I think it's delayed (more than usual :) for various other unrelated reasons. <BlackMug>i know sandboxing is not yet implemented within guix, but any other mechanism used to defend suck attacks? <nckx>BlackMug: We're a traditional distribution in that as a user you implicitly trust maintainers (committers). Unix isn't built to defend against malicious software you yourself run; we haven't yet adapted any of the retrofitted hacks like sandboxing. <BlackMug>i know maintainer -> attacker -> distro is good defended by guix , but wonder if the maintainer himself is intended to develop malicious package what are the defends against that <nckx>None; that's not a threat model unixes ever addressed. <nckx>Hence any mitigations are fragile & high-effort (and we have several conflicting candidates). We haven't the human resources to integrate them into the OS so far. <BlackMug>but this just bring us to the previous discussion if openssh-server maliciously implemented it will just take over every distro produced by guix <BlackMug>because there isnt defends against this package when its malicious <nckx>Guix is (currently) a Linux distribution, nothing more. It shares their weaknesses. <nckx>From that perspective I'd say moving Guix to another kernel is more promising than trying to sandbox on Linux. <leoprikler>well, if someone sneaks a bug into openssh upstream it will be replicated by every linux distro, not just guix <raghavgururajan>sneek, later tell lle-bout: It have sent patches to #47643. Could you specify the spots you were referring to regarding comments, via replies? I'll edit and resend that patch. Also, could you start a new branch 'wip-gnome' on savannah please? Thanks! <nckx>But Hurd doesn't run on anything. <bdju>new wlroots and sway releases as of a couple hours ago in case anyone wants to start updating the guix packages <nckx>It also runs on obsolete hardware. Neither are much help in securing actual use cases. <BlackMug>nckx yeah but major distros currently comes with sandboxing abilities... but yeah got your point <nckx>If your security model is ‘the bad is running in QEMU’ (a bad model!), you don't need the Hurd. Just run Linux in the VM. <BlackMug>leoprikler no its not about upstream, the maintainer of openssh for guix specifically can just add his malicious code and silently take over guix until he will be detected <nckx>s/the maintainer/any committer that doesn't get caught/ <nckx>(A nitpick; but we don't have maintainers or restrict who may change what.) <BlackMug>nckx true, but for e.g in debian it has many stages for the app before reaching stable from sid to stable (years) <BlackMug>sadly this isnt the case in where we are talking about continuous upgrading to the package <nckx>I'm not convinced that increases security, it's just a very different way of doing things. <BlackMug>nckx agree it doesnt increase security but it increase the probability of catching the wrong thing <BlackMug>because package will go into development stage then tester then later stable <BlackMug>and after all of that it has sandboxing ability specially major distros like debian , fedora ... <nckx>(If ‘sandboxing’ is the new ‘containers’ buzzword, that doesn't bode well.) <nckx>What does ‘sandboxing’ actually mean here? <BlackMug>i refer to minimalise/restrict the package reach for resources <Noisytoot>guix pull: error: Git error: failed to resolve path '/home/ron/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq': No such file or directory" <BlackMug>namespaces good but it has more surface attack than MAC (if we look at firejail,bubblewrap) <nckx>SELinux and sandboxing are completely different things, which is why I'm so reluctant to discuss anything based on buzzwords. *nckx needs to reboot, and it probably won't go well, so see you whenever. <BlackMug>yeah sorry, i used MAC before then someone asked me what is MAC so stopped using it <rekado_>it’s complicated and error-prone, and all it gets you is an extra layer of kernel-checked access permissions <rekado_>it’s only as good as your labels and context definitions <rekado_>getting it right is notoriously difficult <lfam>Debian doesn't even have full corresponding source code for their binaries. For both Guix and Debian, maintainers are trusted <lfam>At least on Guix, you can see exactly how a program was built <lfam>On Debian, there is some source code, and a binary, and a promise that they are related <BlackMug>lfam debian with root rights for the packages has way more damages than guix (not declarative) <lfam>Overall, we should keep making improvements, but Guix is doing better than almost any other system in this regard <rekado_>BlackMug: I wouldn’t say apparmor is better; just that use of SELinux is probably best limited to well-known domains, such as restricting file and network access of web servers. <lfam>I don't think you understood my point <BlackMug>rekado_ i didnt say better, but preferable because it solves the complexity issue <lfam>The way that Debian works is that maintainers upload binaries, and that's what users get. In Guix, we upload source code, and binaries are built from the source code <lfam>It's categorically better in terms of how much you have to trust the distro <lfam>But, in both cases, you have to trust the people involved <BlackMug>exactly thats why i think android AOSP is a head upon solving this issue <lfam>Anyways, if you are very concerned about security, I advise you to avoid Linux <BlackMug>in gnu/linux world something can be achieved within Qubes is having Appvm removed from roots rights (but sorta complex to reach to that point but yeah maybe i would call best security available) <zzappie>Im not sure that debian is the best example btw since they have ReproducibleBuilds. But I don't know much about it <lfam>Yeah, you see how hard it is to even begin securing it <BlackMug>zzappie debian is heavily you must trust their devs, malicious package would take over your entire distro <lfam>Until Debian builds their packages centrally based on source code... <lfam>Not to put them down. Debian is still my main OS <BlackMug>yeah same here i only use debian and Qubes <lfam>That's what they need to adopt, universally <lfam>And then, a monorepo for the source code, so that users can actually understand where the binaries came from <lfam>Right now it's very chaotic <lfam>Yeah, maybe another 20 years ;) <BlackMug>maybe if hurd wont move to anything new , maybe guix can take a look at sel4 <BlackMug>but not sure how free it is , but it has active community <lfam>I think we'll always use Linux <lfam>We could add sel4 as a third option, I suppose <BlackMug>yeah the focus now on guix the package manager not the distro <raingloom>BlackMug: AFAIK yes. there are some examples in the info pages. <BlackMug>raingloom i mean not https over onion , i mean if the repo is on hidden services then guix gonna download the source over Tor encryption not TLS <raingloom>oh. no clue. but i think i've seen interest in it on the mailing list, so someone has probably done it. <raingloom>should be as simple as setting up the correct proxy settings for guix-daemon, right? and then just point it at an onion domain to get substitutes from. <BlackMug>similar to this ability should be added to guix, it need to communicate with hidden services over tor <BlackMug>since guix at the moment doesnt has onion repo, its hard to tell if guix implemented that <raingloom>although NDN allows for more diverse options, such as mesh or sneakernet. it does have an anonymization layer too, called ANDANA. <raingloom>the thing i just linked. named data networking.