<nckx>The fact that neither maintainer replied to your last message isn't malicious; my *personal* impression reading between the ML lines for the last few months is that there's simply too much work to respond to everyone in time.
<nckx>I understand that it's unpleasant but I don't think ‘rude’ is fair at all.
<nckx>(Looking at the patch: all that is missing, if upstream has no opinion, is a comment saying so and an explanation of what the code does. That would be required for any patch like this: it takes someone who knows the code (you!) to tell clueless readers (me!) what the hell's going on there 😃)
<nckx>amz3: IMO that's literally the only blocker, and it's something only you can do. I'd merge it then, if that's any help…
<quiliro>minall: trisquel tiene drivers libres y puedes ver si dá indicios de solución tu problema de vídeo
<quiliro>también puedes probar parabola que también es libre y es basado en arch que ya conoces
<minall>quiliro, es que parece que ni en guix, ni en parrot se me cargaron los modulos openchrome, en cambio, en parrotOS, basado en devian pero privativo, me va mejor, mas eestable, y con un desktop environment, el cual es mas pesado
<quiliro>minall: creo que puedes conseguir hacer la ingeniería inversa de tu tarjeta de vídeo!
<minall>quiliro, Ire por trisquek, aunque tambien estaba pensando en clearos, me encanta la presentacion de su pagina!
<quiliro>minall: estoy seguro de que es Xorg porque no te dá problemas si no lo inicias
<Dynamicmetaflow>Greetings, I have a program I had to build from source, hugo, since I couldn't create a guix package. I want take hugo and put it inside ~/bin and then have it be recognized when I use the terminal. How should I go doing this? I don't want to accidentally screw up Guix paths etc
<quiliro>Dynamicmetaflow: you must make a guix package
<Dynamicmetaflow>I tried for a few hours and couldn't figure it out, I will try again in the future but I have a website I'm trying to make a website for a friend who works at a non-profit and I sadly can't figure it out in time
<Dynamicmetaflow>los themes que tiene hugo, y tambien que es un static site generator
<Dynamicmetaflow>uno podria usar lo que esta integado en emacs para hacer algo parecido, me gusta hugo por los themes que ya estan hecho y despues de ahi solo tengo que enadir los contenido y hacer unos cambios
<dfeng>Hi! I would like to install the source of Emacs. Does anyone know how to procceed?
<dfeng>For example, I can't find the definition of `car' using "C-h f".
<roptat>dfeng, if you want the sources of emacs, you can run "guix build -S emacs"
<dfeng>roptat: thanks. Unfortunately, I need to rebuild Emacs from sources to display C definitions from *Help*
<roptat>dfeng, I'm not an emacs user, but you can probably download the sources with "guix build -S emacs", unpack them, enter the source directory, run "guix environment emacs" and them ./configure && make?
<roptat>guix environment will create a new shell where every build dependency of emacs is available which should help you compile it
*rekado-bad-hotel is on vacation, wanted to hack on wip-texlive, but hotel wifi blocks everything but HTTP.
<rekado-bad-hotel>I just found that guix-daemon won't work with torsocks. Is there any other way of running it over Tor or over an SSH socks proxy?
<nothingmuch>also i just realized i'm an idiot and that i've been reading a stacktrace as if it was for a warning, not an error ((gcrypt hash) module missing), i bootstrapped and configured guix in guix environment --pure guix
<nothingmuch>config.log claims (gcrypt hash) is available, -lgcrypt and gcrypt.h also found, and the actual error is s/missing/no code for module/ sorry
<civodul>hey, how's your stay, rekado-bad-hotel? :-)
<civodul>nothingmuch: to run the daemon from your build tree, you should do: sudo -E ./pre-inst-env guix-daemon ...
<roptat>ArneBab, I'm just a few commits more recent than your version and I don't have both libpng versions in pngcrush's derivation
<ArneBab>roptat: at the company we use git lfs with gitlab, but it’s only worth using it over regular git if you expect to have really repositories. If your <100 MiB or so, the added complexity isn’t worth the saved storage.
<civodul>and i hear we should default to Wayland too, because on X11 any client can fiddle with any other client
<civodul>mbakke: BTW, i was traveling and i just realized the July 9th deadline was behind us :-)
<civodul>so i'm really eager to get core-updates merged, so i'll do some testing, and i hope others will too!
<mbakke>civodul: I'm currently writing a summary email and call for testing :-)
<mbakke>Though we should wait for cbaines gobject-introspection fix before the Big Rebuild.
<Dynamicmetaflow>hi mbakke, out of curiosity have you executed your idea? Yesterday I had a similar idea of using QubesOS and the Guix package manager in the template VM's. I actually am workin on getting my backup machine (X230) running QubesOS to tinker with the idea. Been trying to find other posts related to this but not much is showing up
<emacsen>What is the guix approach when packaging to when a source goes away? like if you downloaded it from https://foo.org/.... and foo.org goes away?
<mbakke>Dynamicmetaflow: Cool! I have not explored it further, the implementation is still up for grabs ;-)
<Dynamicmetaflow>lol, I was and still am excited that there was someone else thinking about this after hours of searching online
<mbakke>emacsen: Guix will try a few content-addressed mirrors, such as the CI systems of Nix and Guix, as well as the recent "software heritage" effort.
<Dynamicmetaflow>The roadbump I'm hitting now with the x230 is related to the sys-net and sys-firewall that Qubes uses, prevents other vm's from loading. Hopefully once I figure that out I can experiment with Guix in and see what we can do
<emacsen>mbakke, so there's no place where guix caches old versions?
<lispmacs>hi, having been trying out Guix for the first time over the last few days. my understanding is that Guix uses a rolling release model, but I am wanting a pretty stable production environment, where interfaces and such don't change often. Is there anything I can do toward that end without ending up with an insecure system?
<lispmacs>And on a related note, does the package database have something like version release tags, so I focus on only updating to version points believed to be well tested?
<minall>lispmacs: Such a nice question, I'll give you what I would do, but I'll make that question too
<minall>I'll install everything I'll need and use, and then update all the system, and since I already updated it, it has the latest security updates, so I'll remain without updating unless I encounter a problem
<minall>guix gives you the option to do that!, but that's my opinion of course, I've never heard of release tags, maybe someone has?
<lispmacs>my thought was that I could just only update packages that become vulnerable, but I'm not sure where to easily get notified of just vulnerabilities. I looked on the site for something like Debian Security Announce but didn't see it
<minall>Yep, the reason that debian is stable, is because they use not new packages, but very tested and patched ones, I had that question too, How example, If I can replicate a debian like stable system on guix, and, If needed, updae something
<minall>Actually, I'm making that question too... teach me guix-irc!
<Fzer0>Hello everyone, how can I make Fish the global shell?
<roptat>we have a rolling-release model, so security fixes come in with every update we make to packages
<minall>roptat: But is there a version of any package that would be considered more stable?
<roptat>there's really not much more testing being done on releases compared to just any other commit in master, so the 1.0.1 commit for instance is a bit arbitrary
<roptat>there isn't, mostly because we don't have enough power (in terms of people and build machines) to maintain both models
<roptat>especially for system configuration, it's mostly all or nothing: you either upgrade your whole system to a newer package set, or don't upgrade it at all
<roptat>but that's not a problem at all, because you can always roll-back in case of troubles
<mbakke>lispmacs: You can use `guix lint -c cve` to check for vulnerabilities in packages, but there's currently no way to use it on just a profile.
<erudition>sure it is. what if you want a new version of package A, where a vulnerability is patched, but you want to keep your old version of package B, because the latest one is broken to you?
<minall>Well, that's right, guix would be a free option, when you can test the latest technologies o packages in this case as fast as possible
<minall>But it isn't unstable as archlinux for example
<lispmacs>practical question, then: what is easiest way to view master branch of package database, so I can get a view of what is coming down the pipe?
<minall>It let's you fall back so... I think the system is actually pretty stable!!!
<roptat>for user profiles, you can always keep some packages to what they were, but for the base system, it's not easy (you can use inferiors though)
<erudition>quick recovery is nice, but not to be conflated with stability
<roptat>so you could have your system on a specific commit of guix, and use some packages from a newer guix, as an inferior package
<minall>Actually it is rare for a rolling release to have problems, for example, archlinux is not TOTALLY unstable, it just isn't stable
<minall>But things may happend, the difference is that archlinux won't allow you to roll back
<erudition>But as far as I know you can still downgrade a package in arch
<minall>So if you have important information, you won't be able to get to the system on arch
<lispmacs>what is easiest way to view master branch of package database, so I can get a view of what is coming down the pipe?
<minall>erudition: Yes, it's possible, but it may break something, a program for example, also, just in guix you can test a whole new system safely!
<minall>Is there a way of testing a config.scm after build it? like a Virtual system or something
<erudition>That's one thing I'm struggling with in guix - I thought I'd have more freedom and flexibility with packages across the board, but things like upgrading and downgrading individual packages seem to be designed against
<erudition>minall: I guess it could break something if it's a system package, but most user packages shouldn't matter. Like if I want an older version of blender, for instance. On Debian-based I could just downgrade it.
<minall>erudition: as easier as downgrading in guix? but you're right, that's an option!
<minall>But I like more guix since I can test the latest of everything, but being 'stable'
<minall>On debian some packages are not upgraded, BUT, as you said, you could install a debian based distro, or go to debian unstable
<quiliro>minall: Ĉu vi skribis al la liston de poŝto?
<minall>quiliro: I haven't fixed anything yet, the module is now loaded, BUT, the performance is not... I'll test some things after going on my house... Then I am planning on updating the mailing list, so I can make a problem, but also the fix
<nly`>> what is easiest way to view master branch of package database, so I can get a view of what is coming down the pipe?
<nly`>lispmacs: the comprehensive way would be to keep a local guix checkout
<roptat>kaj offlate-on, sed ĝi nur ne estas tre uzebla
<nly`>and point your guix channel to the local checkout
<roptat>minall, you can build a system with "guix system build" (without executing it), you can create a vm with "guix system vm" or "guix system vm-image" (either read-only or read-write image) and they are all going to be the same system
<roptat>now usually, I don't install too many things in the system config, and use my user profile to install everything I need
<roptat>the user profile is much more flexible because it doesn't have to be built in a declarative way
<roptat>it's easier to lose track of things when it's not declarative though...
<roptat>and as I said, you can use inferiors to get packages from another guix commit (either past or future compared to your current guix installation)
***nly` is now known as nly
<Formbi>actually why are things in Guix built with GCC 5.5.0?
<mbakke>Because upgrading to GCC 7 was really difficult.
<mbakke>Formbi: ^ but the 'core-updates' branch has GCC 7 now.
<mbakke>I hope the switch to GCC 9 goes smoother :-)
<ArneBab>I’m used to Gentoo where I can just get a testing version with a single command, and that indeed feels cleaner. With additional people working on packaging, there could simply be multiple versions of packages (for some packages there already are), but until then I’m happy that my system won’t break due to a mid-update power-outage.
<rvgn>civodul It would be better to migrate guix-hpc to guix.gnu.org as hpc.guix.gnu.org?
<Formbi>ArneBab: you can use package transformation options