<roptat>guix import opam -r <the-package-name> <roptat>will probably give you screens and screens of package definitions <roptat>but that's how we got our current set of OCaml packages <roptat>I mean, it doesn't build anything, it just converts the opam file to a guix package definition <roptat>then you can use these definitions to build your package. you review them, fix them and send them as a patch so other guix users can benefit from your work <roptat>if you're happy working with opam, it's fine with me, but I really don't like it <roptat>especially when compared to guix <nckx>marmulak: Run ‘guix import opam <opam package name>’. It won't do anything besides print something to your screen. It's not scary. <marmulak>well I can try to make the program work without opam, just install ocaml and the needed libs through guix <marmulak>although I don't see ocaml-tls, maybe I'm looking wrong <roptat>I guess it's something different <roptat>there are some dependencies of tls that i don't recognize <marmulak>I'm running "guix import opam tls" to see what it does. I'm curious what "opam tls" means to guix in this context, since afaik "opam tls" is not any valid command <roptat>the command is guix import <importer> <package-name> <roptat>you can list all available importers with "guix import --list-importers" <marmulak>ah so this has previously been set up to work? <roptat>that was a bit hard, but it tought me how to use the peg parser in guile ^^ <marmulak>guile is my favorite interpreter these days <marmulak>apparently --list-importers doesn't make guix import happy <roptat>oh right, guix import --help will give you the list already <marmulak>glad to see ocaml is a first class citizen <roptat>one of my first big contributions I think <roptat>not really, but I needed some OCaml packages <roptat>I've been around for some years now, don't worry about me disappearing :) <simonsouth>vagrantc: Thanks for the response to my email. I'm building a new disk image now, we'll see how it goes... <dissoc2>im trying to run guix system on a desktop with nvidia video card. when i get to GDM it displays but it doesnt really respond/update properly. for example if I type in password it wont show. if i click the gear the drop down doesnt show properly. any ideas? <dissoc2>I'm able to login to gnome. and it also doesnt display properly. the mouse clicks dont correspond to the location of the mouse. similar refresh issues <vagrantc>simonsouth: i've also got a rock64, so i'll be curious how it goes for you! <alextee[m]>anyone has steps somewhere to install guix on hetzner? <alextee[m]>doing the binary installation for now, dunno if this will result in a guix system or a foreign distro + guix, let's see :-) <nckx>alextee[m]: Only the latter, until you run ‘guix system init …’. <nckx>Good night, Guix. (Yes! I'm going to bed at 01:30. Truly the end-times.) <GuixGuy>alextee: I found a deb.scm and deb-build-system.scm in my travels through Github and Gitlab if you want to try and make it work <alextee[m]>i want to convert my debian distro to a guix distro <GuixGuy>I thought you were talking about packages <alextee[m]>im using it as a foreign distro now, trying to understand how to specify services when using a foreign distro <GuixGuy>vagrantc: I also have the code for the patchelf and patchelf-build-system. Do you want to see it as well? <GuixGuy>I am not experienced enough to make it work <vagrantc>mostly interested in building debian packages in guix containers ... <vagrantc>does it extract the .deb build-dependencies, or does it build using the guix toolchain? <vagrantc>i've vaguely thought about building a debian chroot by unpacking each package into an input, and then building a chroot out of the inputs <vagrantc>and then ... once you have a chroot, you can build a package in it... <GuixGuy>I wish I could help you. Unfortunately I am fairly new to guix and programming in general. <GuixGuy>I just spent time searching Git* for packages that other people have made to see what was out there <GuixGuy>Found some neat packages including Firefox <vagrantc>how i wish there were a way to build "dirty" objects using ccache ... <vagrantc>the whole build process could do everything but put it in the store, stashing it somewhere else for you to explore ... kind of like --keep-failed <pkill9>if you run `guix system init` on a foreign distro, does that make Guix a chestburster? <vagrantc>i've definitely used guix system init from a foreign distro on several occasions ... to install armhf and aarch64 systems <alextee[m]>it looks like it needs some kind of configuration <alextee[m]>i think that configuration gets generated automatically with the GUI installer, but if i have to write it manually it's gonna be hard <vagrantc>i see --root=ROOT --system=/gnu/store/...-system --load=/gnu/store/...-system/boot <alextee[m]>so say i run mailman from guix on a foreign distro, how do i configure the mail services? <lfam>alextee[m]: Shepherd can be used on any system but the services that come predefined on Guix System only work on Guix System <noobly>hello, how might i verify that a c++ program I'm trying to compile has access to the freeglut library I just installed? I imagine this is some sort of profile variable that I haven't set properly? ***pie_[bnc] is now known as pie
***pie is now known as pie_
<Blackbeard>noobly: try running the script from the same terminal where you installed freeglut <noobly>Blackbeard: boilerplate.cpp:15:10: fatal error: GL/freeglut.h: No such file or directory. im not sure if this has to do with me not knowing guix or not knowing freeglut, but i believe -lfreeglut is the appropriate flag for compiling <iyzsong>noobly: in 'guix environment hello --ad-hoc freeglut', 'g++ main.cxx -lglut' works for me. Maybe you install the toolchain and freeglut into your profile, but don't have a 'CPATH' set? <iyzsong>or 'CPLUS_INCLUDE_PATH', 'C_INCLUDE_PATH', i'm not sure.. <noobly>Blackbeard: no, same one it was installed in. <noobly>iyzsong: trying that now, thanks <noobly>iyzsong: looks liek that almost worked and that I just need some other package now, thanks! why are you using the -glut flag? <iyzsong>noobly: yeah, i try '-lfreeglut' but it doesn't work. turn out that 'freeglut' provides 'libglut.so' not 'libfreeglut.so'. <guix-vits>'FAIL: tests/inferior.scm' on bootstrap-20190815-11646-gaec0ae2712 <noobly> iyzsong: it's working completely now, thanks a bunch! I wasn't sure if freeglut was a drop in replacement for glut but it seems it is, all compiler flags are identical which, while confusing at first, is super handy <Blackbeard>Should I report it or change the readme inside guix to the appropriate <KE0VVT>Blackbeard: I would upstream it, if possible. <seepel>Hi Guix! Has anyone here heard of anyone installing Guix System on a Pine Phone? <bavier`>seepel: I haven't heard of installation on the Pine Phone, but installation on the Pine Book has been done <jsoo>Is there a way to read all news for a channel, in case some news item was missed? <seepel>bavier: Thanks! I just got one, I might give it a shot. <Blackbeard>I have a problem with an emacs mode I am trying to package <Blackbeard>it says "Opening input file: No such file or directory, /home/blackbeard/.guix-profile/share/emacs/site-lisp/dict/english.txt" <Blackbeard>that is correct the file is in "/gnu/store/jgh8n39aia9riai0xi29d7dzzazgs3y9-emacs-typit-0.2.1-checkout/dict/english.txt" <Blackbeard>is there a way to put the file in the directory .guix-profile/share/emacs/site-lisp/ <anadon>Is anyone on who can help me debug a package? <anadon>The stack trace does not make sense and does not tell me where the error is. I'm not even sure that it is the actual error. <anadon>I checked all the files I manually modified, they all import the crypto module, and rebuilt everything but I'm still getting the error that the crypto module is missing. <anadon>I can't make sense of it from that trace. <anadon>Nope, can't connect to the daemon -- the connection is refused. <anadon>`sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild` is running in another terminal. <anadon>This might highlight a point where switching from a seperate server architecture and an invoked build program would be easier to figure out. <anadon>Hello. It's past midnight where I am, so not quite morning :P <Veera>Does anyone knows how to configure dicod service; it does not provides usual dicod-service-type variable <Veera>anadon: why does mpd-service-type need a existing user account; it does not works with a new user definition is config.scm <Veera>can a bug report be filed for this <guix-vits>Hi Veera; anadon `guix environment --pure guix`? <dissoc2>how do I just use startx instead of gdm? gdm isnt working for me <dissoc2>there's a xorg-start-command. do I just put my command in there? and when i run startx that script will execute? <raghavgururajan>dissoc2, You can give SLiM a try. `(service slim-service-type)` instead of `(service gdm-service-type)`. <Veera>dissoc2: which dm you are using? <dissoc2>and I have it working on my laptop. but now im trying to get it to work on my desktop. buy gdm appears off the screen. i can only see part of it. <dissoc2>i'll give SLiM a shot first. i think my issues may be from the nvidia video card. <raghavgururajan>dissoc2: BTW, what do you mean by gdm not working? Does gdm start and show you the login screen? <dissoc2>i went from gentoo with nvidia proprietary drivers and now trying to get nouveau working. maybe i need xorg.conf? <dissoc2>well i can see like 10% of what i think the gdm screen will look like. everything is off screen. I try to login (but i cant actually see it). and it seems like it starts to login but fails and goes back to login screen <dissoc2>and no errors in the /var/lib...Xorg log files <raghavgururajan>Ah I see. I am familiar with that issue, but, not sure how to overcome it. I would try some other display manager. <dissoc2>thanks. i will try that first. worth a shot since it will only take a few minutes <dissoc2>like i said i have everything working as expected on laptop. now that im happy with guix i am replacing gentoo on desktop <dissoc2>so I'm close. just have to battle through whatever this issue is <dissoc2>i dont have a service gdm-service-type in my config.scm. if i just add service <dissoc2> slim-service-type is that good enough? <raghavgururajan>dissoc2, You have delete `(service slim-service-type)` and replace it with `(service gdm-service-type)`. <dissoc2>is there not a way just to do simple startx? <brendyyn>try just installing xinit and running it? <sneek>Welcome back brendyyn, you have 1 message! <sneek>brendyyn, GuixGuy says: I need python-evdev for packaging Lutris <brendyyn>dissoc2: i think the startx command is in xinit. good luck tomorrow <jsoo>dissoc2: I just spent a week getting simple startx done <dissoc2>brendyyn: yeah i got that far. thanks <jsoo>I think I might add some patches or maybe a cookbook entry about it <dissoc2>jsoo: you shouldn't have told me that haha. at least give me hope <jsoo>I have a solution on my dotfiles <jsoo>First off: gotta make a service to extend the setuid program service to setgid xorg <jsoo>Then make a custom startx function <jsoo>Then maybe use a patched xinit <vagrantc>i've been using sway on machines that can handle it <vagrantc>which is pretty much the same as my startx -> i3 ... <dissoc2>jsoo: thanks. i will take a look. but i have to take a break for today. otherwise i will go crazy <jsoo>Nice! Man I really want an xmonad port to Wayland vagrantc <jsoo>Do you have an example of your sway setup vagrantc? <raghavgururajan>Folks! For "pre-inst-env", do I have to do bootstrap, configure and make for each branch? <jsoo>raghavgururajan: you should only need to configure after a guix gc *vagrantc hasn't made a habit of publishing local configuration <jsoo>Oh ok. I don’t really publish it on purpose. Mostly I just want to share dotfiles with ny friends and it’s easier to just share it <raghavgururajan>jsoo I meant inside git repo. After `git clone`, only master is checked out. If I do `git checkout -B core-updates --track origin/core-updates`, do I have to `./bootstrap`, ./`configure` and `make` again? Even though I did them for master. <jsoo>raghavgururajan: nope! Like I said, I’ve only ever had to do configure or bootstrap after a guix gc <jsoo>I use the repo as my primary channel <brendyyn>sneek: tell GuixGuy I have sent a fresh python-evdev patch, so hopefully it should be pushed soon. <sneek>GuixGuy, brendyyn says: I have sent a fresh python-evdev patch, so hopefully it should be pushed soon. <vagrantc>in adding support for the pinebook, i finally figured out how to get it working with sway by just building up from %base-services rather than %desktop-services <jsoo>I think the error I see when I need to configure is that a store reference will be stale in the pre-inst-env script. Then you will know to do a configure raghavgururajan <vagrantc>i think it's the minimal, or nearly minimal config to do that ... though probably some cruft leftover <jsoo>Interesting. I did something like that too for just startx. What does starting sway require that’s different from x? I haven’t used Wayland <jsoo>Ah nice. X has fiddle permissions issues to deal with that made startx very hard <brendyyn> exec dbus-launch --exit-with-session sway 2>~/.swaysession-errors <jsoo>yeah I cant wait for an xmonad port to Wayland haha <vagrantc>jsoo: the magic was adding elogind-service-type and adding the user to the video group so they can access the dri devices <vagrantc>jsoo: doesn't require setuid or anything (except for the screen lockers) <jsoo>vagrantc: Nice! I got my solution working only with setgid and a udev rule for the input group but it’s much much less nice than sway it sounds like <anadon>guix-vitas: No luck. Cleaned, recompiled, followed your suggestion, but stil connection refused. <anadon>I'll try again tomorrow. I'm dead tired. <raghavgururajan>jsoo I see. My warning messages are like "foobar.scm is different from foobar.go". <vagrantc>now i'm trying to get elogind-service-type working on the veyron-speedy using linux-libre-arm-generic ... but it seems to be missing some cgroup stuff <jsoo>raghavgururajan: that is expected since it’s going to compile the .go files during make. <vagrantc>damo22: pinebook boots, pinebook-pro is a work-in-progress ... see the wip-pinebook-pro branch <vagrantc>i haven't, ironically, tried this configuration on the regular pinebook yet <jsoo>vagrantc: clean! I don’t think I see an error. Maybe the x11-socket-directory-service? <vagrantc>jsoo: oh, i mean the double-pasted url :) <vagrantc>trying to do the same for the veyron-speedy/asus c201p <jsoo>vagrantc: oh! Haha! Ok no worries. I am really new to irc so I make faux pas mistakes a lot I imagine <vagrantc>all these boot with kernels from master ... but getting proper video support is another story. <jsoo>thanks for your porting work vagrantc <jsoo>It’s really awesome to see <vagrantc>oh, it's more stubborness than porting :) <damo22>has anyone tried a corebooted board with guix? <vagrantc>they veyron-speedy i'm working on uses libreboot ... but it's way out of date from modern coreboot <damo22>im kinda wondering if we could build a payload for coreboot that boots into a minimal shell with guix package manager <damo22>but its needs a linux kernel right? <damo22>probably cant fit linux-libre + initrd(guix) in 7MB <vagrantc>i wonder how small civodul got with the bootstrappable initrd... <damo22>vmlinuz-5.6.3-gnu: Linux kernel x86 boot executable bzImage, version 5.6.3-gnu (rms@mit-oz) #1.0 SMP Tue Sep 27 12:35:59 EST 1983, RO-rootFS, swap_dev 0xB, Normal VGA <damo22>why is the 5.6.3-gnu kernel 11.8MB? :( <nckx>damo22: Were you expecting more or less? Hard to tell. <damo22>nckx: i was kinda hoping i could fit a bootable system in 7MB <nckx>You can get a custom Linux kernel down to 2-3 MiB. <damo22>maybe i could do that and make it support kexec and a disk driver, then kexec the kernel on disk <nckx>I made something like that when I was planning on flashing it to my ROM. <vagrantc>there's an implementation called petitboot that does just that <nckx>Smol kernel + initrd = the best bootloader. <nckx>Yeah but what's the point if it's not 100% custom and runs dropbear with your key. <nckx>2.7M ./linux-5.0.9/arch/x86/boot/bzImage <nckx>Remember that your 11.8 MiB kernel has to support all the machines. The one you build to flash only has to support one. <damo22>would it be useful if the machine booted into a minimal shell with guix? <vagrantc>you'd need all of guile for that to work <nckx>That's a very personal question. <nckx>Useful to you is all that matters. <nckx>My 2.7M kernel supports crazy stuff like networking or it would be even smaller. Because I wanted it to double as a tiny rescue environment. But I don't expect others to know their way around. There's not enough space for that. <nckx>*wireless networking, I forgot. Huh. <damo22>imagine you needed to rebuild gcc in an emergency, wouldnt it be nice if your bios had an option to recover and walk you through a full system bootstrap <nckx>As I said, so very personal 😉 <damo22>well it would be useful to more people than just me <nckx>I'm trying to divine the emergency model here but I don't see it. <nckx>‘imagine you needed to rebuild gcc in an emergency’ is hard. <damo22>in australia, our internet is so poor, i might not even be able to access a binary distro <Blackbeard>nckx: hahahha nah I've not. It would be a pain. It takes forever. <damo22>imagine you can hand someone a usb key and give them the gift of GNU without them having to trust a huge binary <damo22>so yeah, but integrate it into a coreboot payload that optionally boots into a rescue mode <nckx>I don't see where trusting megabytes of Linux kernel on a ROM chip come in. If you're the kind of person who's rebuilding GCC from scratch, why would you be OK with cutting a huge corner. Why not actually bootstrap from Mes as intended? <damo22>i dont know how mes works but maybe it could drive an output that saves to a disk or something <nckx>I should have said stage0 though, that's closer to what I think we're discussing. <nckx>I still don't actually know what we're discussing 😛 <jsoo>I was thinking recently about system sizes and I had a bit of an idea. Functional package management as laid out in eelco dolstra’s thesis is kind of a misnomer. It’s more like memory management for your filesystem. So what if we could use some of the newer ideas in memory management and apply them here? Namely systems like rust that have the <jsoo>notion of a lifetime or affine type systems or quantitative types which allow you to express the number of references to some item and thus can tell when it can be safely deallocated. If there were some quantitive information about references on each package or artifact, then some items might be deallocated immediately. So for instance, if make is <jsoo>just a build time input to some other package, it might have some information to track that and not need to be kept in the store. What am I missing there? <jsoo>Whoa that was large. Sorry for the wall of text <nckx>jsoo: Why would make be kept in the store now? <jsoo>It is currently in the closure of the package (declared as an input) <jsoo>I could be missing something here <nckx>I think you might be misunderstanding what a closure is in Guix, yes. <nckx>Guix doesn't know about inputs when garbage collecting. <nckx>They are exclusively a ‘make sure this exists before building foo’ thing. <jsoo>Ok I should read more then <nckx>Nothing to do with ‘dependencies’ (in the colloquial non-Guix package manager sense of ‘stuff that stays installed because I have foo installed’) or closures. 🙂 <nckx>Applying new lessons in memory management to the functional package model or whatever you want to call it is definitely a great idea, but the parallels between what Nix/Guix do and heap management are quite well known. Explicit, even. Even in Nix AFAIK. <jsoo>Yeah for sure. I like that a lot. I think having that idea of heap management as a fundamental concept when working with guix/nix makes the whole process make a lot more sense <nckx>jsoo: I'm not a CS person. What kind of coolness would counting references (beyond the ‘some/none’ we already do) bring? <jsoo>well the things that rust gets out of it is that the language user doesn’t have to manage memory, yet there is no garbage collector <nckx>jsoo: Yeah, and there are probably undiscovered ways of extending that metaphor. It's just already there in the code & many names for things. <nckx>And this is not a language game? <jsoo>Idris 2 has quantitative types which lets gives the compiler enough information about what things will not exist at runtime <jsoo>What is a language game? Sorry <nckx>‘We don't have garbage collection. We have this process called The Cleanup Crew but that's *toootally* different.’ <nckx>(I don't know nuffin bout Rust…) <jsoo>nckx: ah no. The compiler has enough information about your program to know when to allocate and deallocate. So there is no gc at all <nckx>jsoo: But ‘the compiler’ (Guix) can't know you're debugging Gnome this week and are going to be very cross if you suddenly have to rebuild stuff you already built because it was'n referenced (we already know that build inputs aren't referenced — we don't have manual ‘guix gc’ because it's hard to automate, but because only the user has the information to do so). <nckx>Maybe I'm the one missing something now 🙂 <ATuin>mmm i'm having problems with stumpwm and ASDF <jsoo>nckx: I think there would be several effects of such a thing like that. Plus one other goal is to have source always available for one of the freedoms <nckx>The counting isn't the hard part; I don't see how counting more cleverly would help us. <nckx>(Still part of the previous message.) <jsoo>I think we would maybe not do counting but maybe do something closer to what the counting compiles to. <nckx>jsoo: I'd love to hear more about those effects. <jsoo>Hmm. I think we could get smaller system footprints. But on the flip side maybe we would lose some richness of information about a system that would be available for inspection when the user is working in the environment <nckx>Source doesn't have to remain cached on the system as long as the binary is, though. <jsoo>Hmm. I thought I saw a thread in the mailing list from long ago about that. I might be misremembering though <krusnus>Hey everyone! For some reason when i run "which guix" it returns "/run/current-system/profile/bin/guix" and not "~/.config/guix/current/bin/guix". It's messing everything up. How do i set it to the correct one permanently? <jsoo>krusnus: have you installed guix in your profile? <jsoo>ATuin: what problems are you having? <ATuin>after upgrading my stumpwm takes like 1-2 mins to initialize <ATuin>after debugging the problem seems to be with ASDF (the problem happens when running asdf:load-system :module <krusnus>jsoo: what does that mean? i'm running guixSD and i actaully have no idea of how i got in this mess <ATuin>asdf loads itself and that takes a lot of time <nckx>jsoo: So the way Guix currently manages dependencies is scanning for references: if /gnu/store/…gcc/ contains the string /gnu/store/…glibc anwyhere, glibc is a dependency of gcc. Otherwise it's not, and (if GCC is the only ‘live’ package on your imaginary 2-package system 🙂) glibc will be deleted. That's… pretty binary, and minimal assuming there are no bogus references [and if there are, I don't see how you can safely tell]. How are <nckx>you going to shrink that further? <jsoo>Oo. I don’t know much about the common lisp situation right now. Might be a bug ATuin <ATuin>yeah looks like a problem with the paths or something, but im quite new with common-lisp :D <ATuin>anyway seems that there are some configurations that manage to make it work properly <nckx>jsoo: In your opinion, what's currently most lacking about how Guix manages its ‘heap’? <jsoo>krusnus: if you say guix package -i guix then you will be using guix in your profile (~/.guix-profile) <ATuin>by configuration i mean derivations <nckx>Eh, I'm not following the other thread but definitely do not ‘guix package -i guix’ ever. <ATuin>mmm jsoo regarding guix binary, is not enough "guix pull" <alextee[m]>So the only way to get a guix system on hetzner is to write a configuration manually and execute guix init? <ATuin>i only do that and i have it in my "./config/guix" profile <alextee[m]>I also saw you can probably attach boot media. Gonna try that first <nckx>alextee[m]: That's the only way to install Guix System in places that don't let you mount the installer. <nckx>Strongly prefer the installer 😉 <ATuin>jsoo: i will keep debuging this cl problem then <jsoo>nckx: aha. Right. Which is close to standardish garbage collection I think. The change would be to mark in the package definition when it would be ok for a package to be removed. <nckx>alextee[m]: Even then, it's much easier/safer/pleasant to install from a ‘rescue’ system if they offer that. Even if it's not Guix. Boot the rescue system, run the binary installation script to ‘install’ Guix to RAM, then run ‘guix system init …’ on the separate drive. You'll have so much more hair left at the end. <jsoo>The current heap management is like java whereas if we give more information up front about runtime liveness that would be closer to rust <krusnus>jsoo: I'll give some more context. I'm new to guix so I'm 90% sure I'm wrong about this, but I think I've somehow messed with an env file after accidentally selecting it when choosing a wm for lxqt. anyway, now everything is messed up. None of the user installed programms work and most guix commands return "error: unsupportet manifest format" <jsoo>krusnus: ah I see. That is the problem. So probably don’t install guix in your profile as nckx says. <nckx>My problem is that I know a great deal about Guix (but not everything!), a bit about Lispy memz, and absolutely nothing about Java or Rust or …. So ‘like Java’ means nothing to me, as frustrating as that is for the conversation. <jsoo>Ah right. When I say java memory, think lisp or python or JavaScript. <ATuin>interesting "DISPLAY=:1 $(readlink /home/atuin/.guix-profile/bin/stumpwm)" makes stumpw to fail, while "DISPLAY=:1 /home/atuin/.guix-profile/bin/stumpwm" seems to work fine :D <jsoo>meaning a separate process must stop the world and scan for live objects <jsoo>krusnus: what file did you edit? <nckx>Oh wait. We're discussing the implementation of the GC and not the reference model? That's a huge difference. Nix GC isn't quite stop-the-world but can be made even less so without having to change the model. I think. <nckx>Thing is that for Guix/Nix's definition of ‘run-time liveness’, the GC already has 100% accurate information at any time. <nckx>If I understand you correctly. <alextee[m]>nckx: i'll try mounting the installer, thanks. I dont care what happens to the server, can always reset it to a distro they offer <jsoo>nckx: ah now I’m probably getting out of my depth since I’m no compiler writer. I think maybe you are right if the retained pointers to store paths can always be scanned correctly <jsoo>The bigger win would be that I think if the runtime references were declared earlier then certain packages might never have to go in the store at all and the gc might never have to happen <jsoo>That’s why I was thinking it would help reduce, say, vm image sizes <krusnus>thats the thing, i dont really know. And I'm probably wrong about the cause, but I was checking out lxqt and after i started x it prompted me to choose window manager, and the only file in the promt (which whas a filemanagery kind of prompt) was a file called "env", I didnt even look at the icon, assuming it was some sort of folder, and double clic <krusnus>ked it lxqt went black, i couldnt exit and i rebooted the system. and everything's basically been fucked since. I think i've messed things up even more by trying to reset my user and stuff so i have no idea what to even do <jsoo>Ah man sorry krusnus I gotta go. It’s night here. Thanks for the discussion nckx! <nckx>jsoo: Just so we're clear: you realise that if I add ‘wine’ as an input, and ‘qtwebkit’ as a native input, to ‘hello’, this will not in any way affect the size of the resulting hello package, its closure, or the final system/vm image/… containing it, right? <nckx>If so, you make me extremely curious 😉 Bye! o/ <jsoo>nckx: ciao! I will look more into it and read the paper again <krusnus>the signature for the guix installation image has expired :o <ATuin>ok, the problem with stumpwm + ASDF seems to be a package problem, related to paths <ATuin>so i would say it's a bug, ASDF has problem when running stumpwm from the store (/gnu/store/...) <efraim>does anyone know of a distro with good julia support? So far it looks like the AUR is using Debian's dh_julia and has the most "complete" collection of packages, with about 30 :/ <dissoc2>i got my base system working now. im using gdm+stumpwm. how do I configure screen layout? xorg.conf file? ***calher is now known as KE0VVT
<dissoc2>is there a way to get a list of installed packages? If i want to mirror packages across systems what is the best way? <brendyyn>dissoc2: You would manage your profile with a manifest instead of a profile. But there is a script somewhere ive seen that can generate one from your profile <efraim>'guix package -I' will list all the installed packages <efraim>' guix package -I | cut -f1,3 --output-delimiter=:' will give you a list of packages you can feed into 'guix install' <efraim>as long as you're not looking for specific versions that is <dissoc2>thank you. i will look into manifest. efraim: that works for now. thanks <ATuin>seems that when building stumpwm the make-image.lisp is not used at all ... which seems to do some clever stuff <usney>I figured out how to set the environment variables in openbox so I can open guix packages when using that window manager. <usney>where can I post the how to guide for this on guix website or do they have a forum? <usney>This is for a foreign distro that used the guix installation script. <efraim>usney: start it as a post to guix-devel and then from there we'll see about turning it into a blog post or adding it to the cookbook <xelxebar>./pre-inst-env guix build <pkg> is giving me a permission denied error when run from within guix environment guix --pure <usney>I am sure it will work with lxde currently I am messing around with just openbox with tint2 as the panel. <xelxebar>Trying to package something for the first time, so I must be doing something silly <usney>they have help videos on guix.gnu.org xelxebar <usney>I think even for making your own package for guix <xelxebar>Oh wait. Do I need to compile the source first? <xelxebar>Something do do with doc/guix.de.info missing references. <usney>I have never made a guix package. But at least you have some videos to show you how. <usney>what is the actually output error? <xelxebar>Output of whole make command. It's really just a bunch of errors about missing references in doc/guix.de.info <usney>do you speak german xelxebar ? <usney>I am just guessing because of the de in guix.de.info <usney>it seems that person has a similar issue. <usney>if it doesn't then post to the guix-devel mailing list like that person did and see if you can get an answer that will help <krusnus>I just reinstalled guix and everything was working fine untill i rebooted and now none of my manually installed programms work and guix install [anything] returns "guix install: error: unsupported manifest format" <mekeor>PotentialUser-73: i don't celebrate easter, i don't believe in christianity, i pay homage to St. Ignucius only <PotentialUser-73>tomorrow it'll be released the new version of guix, if I want it an a pre installed version can I just run: guix pull && guix upgrade and it is the same thing? <mekeor>PotentialUser-73: sorry, i was just trying to make a joke :) <mekeor>krusnus: sounds like your manifest has a bad format? <mekeor>PotentialUser-73: i don't really understand your question, to be honest <krusnus>mekeor: dope, do you know how to fix it? <mekeor>PotentialUser-73: so, you want to install the version of guix which will be released tomorrow? <pkill9>PotentialUser-73: yes, the new version will be in the main repository <pkill9>is core-updates getting merged tomorrow then? <krusnus>mekeor: did that and nothing changed :/ <PotentialUser-73>my ester bunny give to me a Gigabyte GA-G41M-ES2L librebooted and I'll install guix on it to study guile/guix <mekeor>krusnus: i don't know. i am a guix-noob. but i think your problem is that your guix-daemon and your guix-command-line-program have different versions. <xelxebar>usney: Thanks for the links. They're not directly relevant, unfortunately. However, I did find an open issue on the tracker that seems relevant, but the server is returning 500 when I try to open the link. <xelxebar>Yeah, the errors happen when building the german info file, it looks like, but I don't have any german locales set. Don't speak much German, I'm afraid to say. <mroh>xelxebar: try `make SUBDIRS=` as a workaround. <rekado>xelxebar: if “the server” that is “returning 500” is issues.guix.gnu.org: that’s because it cannot currently update (since a few days) because I’m waiting for a response from the maintainers of debbugs.gnu.org. <ATuin>is there any option to keep the source build even for successful builds? <ngz>ATuin: I don't think so, but you can insert an error in one of the phases to at a given point. <rekado>e.g. (add-after 'build 'fail (lambda _ (error 'fail))) <jonsger>hm building. /gnu/store/...-guix-1.1.0rc2.drv takes pretty long while installing Guix System in Qemu <ATuin>ngz: i did that (error "foo") <ATuin>btw seems that lot of packages build using asdf-build-system complain about the version scheme not being asdf compatible <xavierm02>I tried 3 random commits (a few months ago, six months ago and a year ago if I remember correctly) and couldn't get xen to compile in any of them. The two recent ones had the same error, and for the older commit make failed before for some seemingly unrelated reason <xavierm02>Is there really no way to get a commit where xen works? <pinoaffe1>I want to be able to compile for an esp32 on guix, (I think I would need a crosscompiling gcc toolchain targeting xtensa), anyone got pointers / has anyone played with this before? <ngz>Last successful build on x86_64 was on 11 Sep 11:19 +0200 <xavierm02>I've looked a bit into why the xen build fails. And it seems to be because (getenv "C_INCLUDE_PATH") and (getenv "CPLUS_INCLUDE_PATH") return #f, and some procedure later on really wanted those values to be strings ***ChanServ sets mode: +o civodul
***civodul changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | Test: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00224.html'
<kraai>I'm trying to package diceware. When I run guix lint, it says "source not archived on Software Heritage". What do I do about that? <ngz>kraai: Nothing. It is an harmless warning. <xavierm02>What's the minimal stuff I need to do to check if xen builds at a commit? I've been doing make clean && make && ./pre-inst-env guix build xen <ngz>xavierm02: maybe with guix time-machine <xavierm02>xen builds on ef640db2f509f51ebfe3a6a66ba837ef3103bbb7! <guix-vits>nly and folks: First of all, i'm sorry i'd claimed that tor-service-type doesn't working properly. It's my crappy 'firehole' was misconfigured. <xavierm02>Is it possible to write a package in current guix that has as input a package from a past commit? <pkill9>xavierm02: I think it could be possible with an inferior package <pkill9>then again, probably not, because accessing the package metadata requires functions just fo rinferior packages, so the build systems and whatnot probably will give an error if they try to use the normal functions to access the package metadata <xavierm02>(I tried fixing xen, but making filter-environment! work when (getenv "C_INCLUDE_PATH") if #f brings a new problem: It can't find Python.h. And I tried adding (assoc-ref inputs "python") "/include/python2.7/" to the C_INCLUDE_PATH but it still doesn't find it so I give up) <jayspeer>Hi guix! I see that hurd is live, thanks for the hurd work guys :) <ecbrown>unfortunately i got hung up trying to get emacs-no-x :-( <xavierm02>It seems to work! (Or at least I get a new error when trying to build my package, and not one when trying to build xen) <mbakke>xavierm02: if you want to fix Xen, it might be easier on the 'core-updates' branch, as master does not use C_INCLUDE_PATH & co. <mbakke>xavierm02: I tested just now and it fails due to some -Wdeprecated compiler warning that can be disabled. <anadon>Continuing from last night, I can't figure out where a few errors are in my modifications to update packages and the behavior and stack traces just haven't related to any actual problem. Here's where I'm at: https://imgur.com/a/N9jci7u <bavier`>anadon: It looks like you don't have guile-gcrypt in your build environment <bavier`>and maybe also don't have the guix-daemon started <homocarbonis>Does anyone know how I can refer to a file in a package in the store from my system definition? <homocarbonis>I am trying to set up nginx and I want to refer to put "include /gnu/store/*-nginx-*/share/nginx/conf/fast_cgiparams" <bricewge>homocarbonis: “file-append” from (guix gexp) I think <anadon>bavier`: If it was missing from my build environment then it should fail to build in the first place. That isn't happening. <anadon>From my understanding, in order to use the new packages the daemon has to have those packages and thus the new daemon must be running in place of the old one. <homocarbonis>That looks right, thank you. I should have read the manual again. <anadon>bavier`: A guix daemon has to be started for anything to work. As you can see in the image, the old one was stopped and the new one was run. <mbakke>anadon: did you configure with "--localstatedir=/var --sysconfdir=/etc" ? <mbakke>anadon: unless you are testing changes to guix-daemon itself, you don't have to run it from the checkout <reepca>do we have any tools packaged that can let me play through multiple sets of headphones at once via pulseaudio? <lfam>I would look at pavucontrol, but I don't know <reepca>I've got pavucontrol and can't find a way to create that kind of virtual sink <homocarbonis>Hmm, file-append produces a file object which can be used in a gexp but I don't know how to turn that into a plain string containing the filename. <anadon>These errors just don't make sense and don't trace back to the actual error point. It is killing me. <mbakke>anadon: it's looking for the daemon socket under /usr/local, you should run "./configure --localstatedir=/var --sysconfdir=/etc" <anadon>mbakke: That fixes the connection issue. Now it doesn't know of the package I modified. <mbakke>anadon: you probably mean to build 'python-django', not 'django' <bricewge>homocarbonis: Can you share your code? What is your end goal here? <nly>guix-vits: no problem <nly>glad you've got it working <homocarbonis>I'm trying to write a line in the body of an nginx location which will compile to say "include /gnu/store/...nginx/share/nginx/conf/fastcgi_param;" <bricewge>What strange is that “nginx-php-fpm-location” seems missing from the code base... <reepca>aha, got it figured out with arch wiki and pacmd 👍 <lfam>bricewge: I'm testing it now. I think the file-system-type->utils procedure is not in the preferred style (there's a section in the manual) <lfam>I wonder about what's the best way to record this info about packages and file systems but that's overthinking it a bit <lfam>There are only 9 of them <bricewge>lfam: WDYM? I sould extract “pattern->utils» <lfam>I'm not that sharp in Scheme <lfam>This is a great channel for somebody else to offer more specific advice :) <bricewge>lfam: There is file-system-packages in (gnu linux system linux-initrd) that is related to matching FS to FS utils <bricewge>I thought about this when implementing it. but the code was trivial so I went with it. <mwette>in guix package -d [PATTERN], what is the syntax of PATTERN ? <lfam>mwette: No, you don't delete packages here, you delete generations <lfam>The generations are numbered <lfam>You can also give it time periods like 1m for "delete anything older than 1 month" <lfam>I'm not sure where it's defined <mwette>that's what I thought, but if I want to delete 1-9 can i use '? <vagrantc>anyone know what features are needed in the kernel for the cgroup memory mount? <vagrantc>when trying to enable elogind on armhf with linux-libre-arm-generic (+a bunch of additional CONFIG_CGROUP flags), i get a bunch of messages: cgroup: Unknown subsys name 'memory' <ngz>mwette: It would be 1..9 <vagrantc>previously, it was missing a few others ... i'm hoping this is the last <ngz>mwette: according to (info "(guix)"Invoking guix package) <ngz>err (info "(guix)Invoking guix package") <bricewge>lfam: I could drop the pattern thing and just use a simple alist <bricewge>lfam: I wasn't too sure about adding “file-system-utils?” as just a boolean. Or adding “file-system-utils” accepting a package or #f. WDYT? <vagrantc>ugh. the inability to select a system generation on this chromebook is really frustrating ... i have to have external boot media and do a system reconfigure pointing to that first *vagrantc switches computers <vagrantc>appear to be a few patches in v1.1.0rc2 git that aren't in the tarball ... *sigh* <vagrantc> gnu/packages/patches/rust-1.30-gdb-llvm.patch | 89 ------------------------------------------- <vagrantc> gnu/packages/patches/streamlink-update-test.patch | 70 ---------------------------------- <vagrantc>simple enough to fix ... easy enough to forget to do :/ <vagrantc>though, they don't appear to be referenced by anything ... maybe they're dead patches? <lfam>vagrantc: If they don't get used anywhere, they were probably erroneously preserved in a Git merge. It's a common mistake <vagrantc>better than the converse ... being deleted or not added to gnu/local.mk <vagrantc>why is the typo "This packages" impossible to kill? <vagrantc>on a positive note, 1.1.0rc2 built fine on debian ... typo/spelling fixes on their way! <xavierm02>mbakke: I'll try core-updates then. Thanks :) <xavierm02>Is there a simple way of getting the phases of a package? <rekado>xavierm02: there’s no short or generic way to do that. <rekado>xavierm02: because of inheritance and overriding of arguments <rekado>but you can get the specified phases for pkg with (and=> (and=> (package-arguments r-minimal) (cut memq #:phases <>)) cadr) <rekado>i.e. we get the arguments field, and if it exists go to the #:phases element in the arguments list, and if that exists we fetch the value right after it. <rekado>you can wrap this in (or … ) and get the %standard-phases for the given build system <pkill9>does anyone know how to use pulseaudio with jack on guix system? <xavierm02>I'm trying to make creating packages faster by caching some phases (so that when you are working on the install phase, you can test it without recompiling everything). I was trying to do so by splitting a package into several packages, one per phase, and having each package have the previous one as input and performing a single phase. But I'm starting to wonder whether this is how it should be done, the alternative being <xavierm02>editing the script behind guix build. What do you think? <vagrantc>i still haven't decided what to do regarding the "(allows|permits) to" grammar with "(allows|permits) one to" ... as neither sound right to my ear <efraim>That sounds like my 'one of these days I'm going to make the backslashes in gnu/local.mk all line up' ooohs <vagrantc>just have emacs fix it in how it's displayed :) <vagrantc>gah. every one of these requires a different rewrite ... it's not straightforward <vagrantc>the grammar of the whole thing is a bit weird <alextee[m]>what is the right way to give credit? is the text also under the AGPL? or just mentioning that we took text and ideas from there? <alextee[m]>or would just mentioning that we took text and ideas from there be ok? * <alextee[m]>oh it's in the public domain nvm: Initially written by sirgazil who waives all copyright interest on this file <anadon>When building my django modifications, there's a failure in the django tests but the test file doesn't exist in the django repo. The file does exist under the django directory in guix. Could this be a misdirection and the failure is actually in another package, django doing something non-obvious, guix, doing something non-obvious, or something else I haven't thought of? <anadon>I'm running it again for something clean to post. <Formbi>what does «RUNPATH validation failed» mean? <Formbi>or how can I do something about it? <Formbi>(I'm trying to package Rust 1.40) <efraim>we don't have it already in a patch or on staging/core-updates? <civodul>seen in real life: error: file-append*: unbound variable <civodul>hint: Did you forget `(use-modules (#g117 #))'? <efraim>sad news, vim needs some love to cross compile to i586-pc-gnu <efraim>anadon: that's the triplet for THE HURD <atw`>vim supports, like, the amiga, but not hurd, heh <Formbi>that's probably something in Guix <efraim>yeah, i'll fix cross compilation later. <civodul>efraim: does cross-compilation of vim work in general? <efraim>civodul: I've never tried it otherwise <efraim>I was thinking of causing trouble and trying to build a hurd vm from aarch64 but decided it probably wasn't worth it ;p <efraim>it said something about one of the checks not working <efraim>anadon: all architectures use a triplet. x86_64 is x86_64-linux-gnu, windows can be x86_64-w64-mingw32, there's a lot of options out there <anadon>Is this to say that the Hurd is aimed at 32-bit x86? <anadon>Why? It seems bizarre to support something that old. <Formbi>Hurd's development isn't particularly vibrant <Formbi>well, when Linux came out, Hurd almost stopped <Formbi>and after that the developers discovered some design defects <efraim>I personally try hard not to know. Sometimes it's developer interest, sometimes its drama, sometimes its lots of drama, mostly it's interesting to me as another option to make work <efraim>talking to other people at FOSDEM recently, I mentioned "I don't like saying Linux is 'just a kernel', but there's a bunch of options out there and there's no reason to not support more of them" <anadon>Steering back towards my question, I'm having a tough time making sense to the build failure. <rekado>luckily there are ways for the Hurd to reuse modern drivers; they don’t have to be written from scratch. <rekado>porting it to a different architecture doesn’t need to be that big a problem <civodul>vagrantc: i think we should add a lint checker for "allows to" :-) <vagrantc>i finally figured out what felt wrong about it ... <vagrantc>debian's lintian suggested to change it to "allows one to" but that just makes it longer and more cumbersome <vagrantc>civodul: "This packages" -> "This package" also, please! <civodul>would it help with lintian if those patches are applied to the 1.1.0 tarball? <vagrantc>eventually i figured out the usual patter is "allows to (do) X" can usually be changed to X's plural form <vagrantc>but i figured at least getting them on master would eventually resolve them <civodul>perhaps we have translations applying to the non-grammatical English actually <vagrantc>most of these "allows to" fixes actually shorten the number of characters significantly :) <vagrantc>as you pretty much just drop that part out <Blackbeard>dustyweb: yeah. I am trying a few Emacs packages I want to send <Blackbeard>dustyweb: is your idea of guix-deploy like a guix ansible,? <dustyweb>Blackbeard: yes'ish... not expecting to do all the stateful things ansible does <dustyweb>Blackbeard: thanks to Jakob's GSoC last year, we actually have a lot of this now <Blackbeard>I was just reading about adams, a common lisp ansible-like on lobste.rs <nckx>vagrantc: I just boldly replace ‘This package allows [one] to X’ with ‘This package Xs’. It's usually more correct, too. (‘ls’ allows me to shut down my machine; it just doesn't help.) <civodul>Blackbeard: 'guix deploy' is already pretty nice! <civodul>Jakob wrote a couple of blog posts about it <Blackbeard>is it ok if I send a few emacs independet packages on a row <Blackbeard>or should I send one and wait until it is approved for the next one <Blackbeard>most of them are just a file without dependencies <nckx>Blackbeard: Send 'em all! <Blackbeard>guix deploy enables you to use those same operating-system declarations to manage multiple remote hosts at once as a logical “deployment”. <dustyweb>I need to switch my server over to "guix deploy" <nckx>When ‘cssh’ is ‘good enough’… :-/ <vagrantc>oh noes... master seems to have a bunch more "allows to" than version-1.1.0 branch <vagrantc>guix lint apparently doesn't have any special parsing for -rc versions <vagrantc>i'd just ignore it ... or file a wishlist bug on guix lint <roptat>(version>=? "1.0.0" "1.0.0-pre1") returns #f <Formbi>actually I don't see Rust 1.40 on staging…