<vixus>gnu/system/install.scm doesn't seem to have anything to account for UEFI <nckx>As in the installer doesn't work on UEFI systems? I'd be surprised but can't confirm or deny it. <vixus>the downloaded ISO works fine when written to a USB <vixus>but if I `guix system disk-image gnu/system/install.scm` and then try and write the result to a USB it doesn't seem to work <vixus>the partition table of the former looks completely different to that of the latter <nckx>Oh, I thought you were talking about the ’graphical’ installer. The installation medium definitely supports UEFI. <nckx>I've never installed on anything else ☺ Weird... <vixus>the guixsd-install-*-linux.iso certainly supports UEFI, but the image produced by `guix system disk-image gnu/system/install.scm` doesn't seem to be at all bootable and definitely doesn't seem to support UEFI <nckx>vixus: So you mean that omitting file-system-type doesn't work? What's the use case here? *nckx is building the latter. <vixus>where should I be omitting file-system-type? :o <nckx>vixus: ‘the guixsd-install-*-linux.iso [that] certainly supports UEFI’ *is* the image produced by `guix system disk-image gnu/system/install.scm` <nckx>The only difference is the --file-system-type=iso9660 argument. <nckx>(Section 3.9 in the manual.) <vixus>section 3.9 is "Invoking guix describe" :s <nckx>Heh. Here it's ‘3.9 Building the Installation Image’. <nckx>′The installation image described above was built using the ‘guix system’ command, specifically: guix system disk-image --file-system-type=iso9660 gnu/system/install.scm’ being the relevant bit. <vixus>oh man I really want access to that manually <vixus>I'll give it a go with iso9660 <nckx>I didn't realise section numbers were so unreliable, sorry. <nckx>Yeah, maybe there's an unnoticed regression where it adds more than just a different file system. I guess you'll find out. <Krafter>Can guix only be used as a "system package manager" or could I use it only under my own user? <buenouanq>whatever difference there is between those is fairly arbitrary <buenouanq>guix is just a package manager done so right that a whole OS just sort of falls into place out of and around it effortlessly <buenouanq>praise guix, long live the system distribution! <joshuaBPMan>Hello, I recently started trying the idea of packaging my .emacs.d as a guix package...Right now it only uses guix instead of use-package. I could use it to package plugins that rely on external tools: lsp, rtags, plugins that rely on nmp packages, etc... <joshuaBPMan>It would also be cool to integrate it with services that guix offers...What else could I do? <quiliro>there has been an arrest locally of a friend of assange, ola bini <quiliro>ola bini was detained without charge <joshuaBPMan>ahh, the wiki leeks founder guy. It's a really intesting free speech case. Is it a violation of the constitution to prosecute whistle blowers? <quiliro>it is a violation of the constitution to detain without charges <quiliro>only in cases of flagrant crime it is allowed for 24 hours <quiliro>he could impended see his lawyer until more than a day passed <joshuaBPMan>I guess I am grossly unfamiliar with his case. Was he arrested over-seas? <quiliro>ola bini is a swede and is a resident of ecuador which was arrest before leaving for a conference in japan <quiliro>acused of cracking computers in association with julian assange <joshuaBPMan>I have been thinking about compiling a custom kernel. Would a custom kernel have a lower "memory footprint"? Also what does that mean? would it be substantial? Say 1MB or more? ***jonsger1 is now known as jonsger
***ng0_ is now known as ng0
***Guest30717 is now known as benny
<roptat>civodul, what was the translation error you found again ? *puoxond wonders why sneek_ is ignoring him <roptat>is sneek_ registered with NickServ? <ebrasca>I get this error "zsh: command not found: gpg2" after some update. <OriansJ>do you have gpg2 installed in your profile? <ebrasca>I have gnupg pinentry pinentry-tty pinentry-gtk2 pinentry-emacs <OriansJ>ebrasca: does guix package --roll-back solve your issue? <OriansJ>it is more about reducing the problem space to a single update and thus knowing it is in that (you can always roll forward) <ebrasca>I have go 10 version back and gpg work. <ebrasca>But now if restart my x11 don't work. <OriansJ>ebrasca: you can use guix package -l to list generations and guix package -S to switch <civodul>roptat: i think it was "10 nouveau paquets" (no 'x') <OriansJ>ebrasca: ok; so we have to look at the generation where it stopped working to figure out how to fix it <OriansJ>So what changed between when it worked and it stopped working? <ebrasca>OriansJ: It can be my bad config of gpg. *civodul is frustrated by broken pdf2ps <pkill9>is it possible to allow the build system to build in the root ( "/" ) of the build container? <pkill9>hmm actually there's probably a better way, plus i don't relaly need to do this, just doing unneccessary things again <pkill9>i should just make a chroot inside the container, lol ***vixus_ is now known as vixus
<civodul>pkill9: the build doesn't happen as root so chroot(2) is not available <roptat>I've updated bap but it fails in the install phase: <roptat>cp: cannot create regular file '/gnu/store/rx9vm264sxkja0h9jaacplw1ja720l63-bap-1.6.0/share/primus/site-lisp/warn-unused.lisp': Permission denied <roptat>that store path is the output of the package, so it should be able to write there <roptat>mh... for some reason the file already exists and is read-only <Formbi>how to make «guix pull» show all updated or new packages? <pkill9>Formbi: doesn't it do that by default? You can run `guix pull --list-generations` to show package changes for each generation <pkill9>by default, i mean when you pull a new guix ***jonsger1 is now known as jonsger
<pkill9>oh, if you run `guix pull --list-generations` i think it doesn't do that <pkill9>that does that just after running `guix pull` <Formbi>can I display only the latest generation? <pkill9>yeah, you need to know which number it is <ebrasca>Now I get this "gpg: signing failed: No pinentry" <pkill9>`guix pull --list-generations=<last-generation-number>` <pkill9>ebrasca: have you specified a pinentry-path in the gnupg-agent config? or maybe you just need to kill the gpg-agent <pkill9>ebrasca: i have in ~/.gnupg/gpg-agent.conf: "pinentry-program /home/itsme/.guix-profile/bin/pinentry" <ebrasca>I have "pinentry-program ~/.guix-profile/bin/pinentry-tty" <pkill9>ebrasca: try `pkill gpg-agent`, maybe the new version of gpg-agent needs to be running <ebrasca>pkill9: "pkill gpg-agent" don't help me <kmicu>ebrasca: what did you do to get ‘gpg: signing failed: No pinentry’ ? <ebrasca>kmicu: echo "test" | gpg --clearsign <kmicu>ebrasca: could you change ‘pintentry-tty’ to ‘pinentry’ in gpg-agent.conf (the same thing as posted by pkill9), execute ‘gpgconf --kill gpg-agent’ and then try again? <ebrasca>kmicu: Now I have "pinentry-program ~/.guix-profile/bin/pinentry" and I get same error. <kmicu>Could ‘gpgconf --kill gpg-agent’ to kill current agent then start agent manually in another shell with ‘gpg-connect-agent /bye’ to check its log? <kmicu>BTW do you use SLiM by any chance? <kmicu>A login (display) manager. Nevermind. <kmicu>Could you now try to sign in another shell? <kmicu>Just to be sure, do you see pinentry in ~/.guix-profile/bin/ ? <kmicu>Could you switch from pinentry-program ~/ to absolute path? <kmicu>‘pinentry-program /home/ebrasca/.guix-profile/bin/pinentry’. Do not use ~ <kmicu>(That issue is not related to Guix.) <kmicu>Not everything know how to expand ~, generally is always better to use absolute paths. <kmicu>Just to be sure: did you restart gpg-agent with ‘gpgconf --kill gpg-agent’ after making changes to gpg-agent.conf? <ebrasca>Normal pinentry try to run some GUI app, it is very bad think. <ebrasca>pinentry-tty work inside my terminal <kmicu>pinentry-tty should not be used (as recommended by GPG devs) but now you can use ‘pinentry-program /home/ebrasca/.guix-profile/bin/pinentry-tty’ if you really want that. <kmicu>ebrasca: what emacs version? <kmicu>How did you generate that git signing log? In magit or somewhere else? <ebrasca>kmicu: Inside magit menu press key "$" <kmicu>My guess is that your emacs sees different PATH. You could check with M-x getenv PATH. <ebrasca>Result is : "/run/setuid-programs:/home/ebrasca/.config/guix/current/bin:/home/ebrasca/.guix-profile/bin:/home/ebrasca/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin" <kmicu>Did you test signing a commint in a shell (not in Emacs)? Does that work? <ebrasca>kmicu: Yes in shell work. I need to fix my emacs magic mode. <joshuaBPMan>Hello, I'm trying to use an external file for iptables rules... <joshuaBPMan>(service iptables-service-type (iptables-configuration (ipv4-rules (local-file "ipv4-iptables.txt")))) <pkill9>joshuaBPMan: have you tried with an absolute pasth? <nckx>☝++ I've had seemingly random results with relative paths. One moment they work, until they don't. <pkill9>joshuaBPMan: you could possibly use relative directory with something like (local-file (string-append (getcwd) "/ipv4-iptables.txt")) <joshuaBPMan>Also, It's a bit tedious to keep having to add more EXPORT lines to .bash_profile. Doesn't guix have a way to automate this? <joshuaBPMan>export ASPELL_DICT_DIR="/home/joshua/.guix-profile/lib/aspell" <joshuaBPMan>and a ton of other things that guix tells me to for various programs. <joshuaBPMan>I think the manual mentions how to avoid this. let me try to read it for a bit. <pkill9>i think you just need to login and out again, it exports those automatically on login <pkill9>on Guix System anywya i assume you're using that as you asked abou tthe iptables configuration <joshuaBPMan>I am using guix system. Ok. I did not realize guix system exposed those automatically. Good to know. <joshuaBPMan>pkill9: and your local-file string-append magic worked. thanks. <nckx>joshuaBPMan: Yeah, remove all those exports. <nckx>And I'm being pedantic, but Guix did *not* tell you to add them to your startup files. ;-) <joshuaBPMan>nckx: fair enough. It just said I might want to export said variables <joshuaBPMan>weird. gnome is being weird and is not opening up a terminal. <nckx>joshuaBPMan: Sorry, I wasn't being that serious. You're not the first to do so. <joshuaBPMan>nckx: I'm not mad. I thought your comment was funny. :) <joshuaBPMan>does anyone know if gdm default login in still broken? *nckx bites their tongue. <nckx>joshuaBPMan: Not a great answer, but there's always testing in a VM or rolling back... <nckx>‘Still faster than #guix on a Sunday.’ <joshuaBPMan>nckx: I never had gdm auto login' me in to begin with. <nckx>joshuaBPMan: I only use & know SLiM's auto-login, sorz. <nckx>(No security in entering my password thrice instead of twice when using LUKS.) <joshuaBPMan>nckx: I would be nice to only have to enter your LUKS password once eh? <nckx>joshuaBPMan: Sure would. Would be even nicer if we didn't have to roll our own solution but GRUB & Linux just implemented some hand-off protocol. <nckx>But I guess we could roll our own with passphrase'd keys in the initrd or some other baroque masterpiece. <nckx>Would make debugging Guix's boot even more fun!!!! <joshuaBPMan>ok. I'm going to try sway. So I will probably be rebooting in a bit. <joshuaBPMan>well, I also need to get the dvorak layout working too..... <nckx>joshuaBPMan: What's missing? <joshuaBPMan>idk. sway didn't seem to like my configuration. I did not honor my dvorak layout. <nckx>So if I switch to GDM running Wayland+‘i3’ is trivial? Hmm. <nckx>Ah. I read somewhere that part of the reason for this pu{s,tsc}h towards GDM was because nothing smaller works well with Wayland. Don't know if that's true tho'. <joshuaBPMan>I'm running wayland right now on sway, and it seems pretty cool. <joshuaBPMan>I've got emacs, icecat, and vlc running. All seemed pretty cool. <joshuaBPMan>I've also got 8GB of RAM. But the laptop is 9 years old. <nckx>Downloads/ guix/ pf-kernel/ Pictures/ <joshuaBPMan>technically I'm cheating. I'm running emacs on gnome-terminal <joshuaBPMan>anyone know how to try out icecat on wayland? Is it working well enough for that? <buenouanq>I'm sort of confused by that whole mess... Gnome uses Wayland, but most of the graphic applications don't yet themselves? so do they all run through the Wayland Xorg translator layer thing? <resttime>After building guix in a 'guix environment' and exiting the environment, the newly 'built' guix can't be used because now the libs environment are missing <resttime>Is there a way to get the load path of those libs in the store to use? <resttime>Errr, I check the guix executable script for the binary install and it seems to do that <resttime>(I don't have guile-json and guile-sqlite3 etc. installed natively, but they should exist in the store) <resttime>I guess another way to put it is that the binary installation's guix executable is a script which adds to the GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH the guile libs needed to run guix <resttime>I'm wondering how to do the same when building the repo myself without copy-pasting from the binary installation's guix script since that doesn't seem the 'correct' way to do it <nckx>resttime: I'm confused. You're building guix inside a git checkout using ‘guix environment’? <nckx>If so, what does a ‘binary installation’ have to do with it? <resttime>It's able to run guix without the environment, so I'm copying the solution it does <nckx>Very roughlyguix environment guix … -- sh -c './bootstrap && ./configure --... && make' <nckx>* and your new guix is useable as ‘./pre-inst-env guix’. <nckx>The build environment is then no longer needed to run the resulting guix. <nckx>resttime: That's probably a very bad idea. <nckx>Blackbeard[m]: Instead of what? <nckx>Blackbeard[m]: The FILE-NAME field just changes the source directory name in the store (/gnu/store/hash+file-name) <nckx>This name should contain the package name and some kind of version/commit/revision/... <resttime>nckx: That didn't seem to do it, it seems to add guix repo to the %load-path of guile trhough GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH but not the libs contained in the store <resttime>I guess maybe I'm doing something not suppose to be done *resttime made assumption that because binary installation could do it, it's something normal <nckx>resttime: Hm. Not necessarily, I just checked and I've installed these libraries to my profile as well, presumably (long ago) to make ‘./pre-inst-env guix’ work. Any reason you prefer not to install them that way? <nckx>i.e. my manifest contains the line <nckx>"gnutls" "guile" "guile-gcrypt" "guile-git" "guile-json" "guile-sqlite3" "guile-ssh" ; ./pre-inst-env guix! <nckx>which I don't remember writing... <nckx>(The quotes is because I use specifications->manifest.) <resttime>More just testing I suppose, because I thought it'd be really cool to keep the libs in the store but still use them without having the actual package in the rest of the filesystem <resttime>Separating the build environment yet linking to the libs in the environment after you leave it <nckx>Blackbeard[m]: It's only for the benefit of humans looking at the store and wondering what /gnu/store/ah7ud5eo1ahdu-svn-checkout is. /gnu/store/ah7ud5eo1ahdu-babel-english-1.0 is much more clear ☺ <nckx>resttime: It would be really cool. If your goal is to experiment in that spirit, ignore my ‘bad idea’ — you already know you'll be outside of officially supported territory. <nckx>I'd also ask civodul or so why the current set-up is what it is, though. I.e. why ./pre-inst-env takes Guile modules from the user's environment and doesn't embed only store references. *nckx really AFK, have a nice day/night y'all. <nckx>Blackbeard[m]: It's mandatory. resttime: Good luck. <Blackbeard[m]>pkill9: I am trying to add some packages for babel spanish support :) <Blackbeard[m]>I will send it upstream when it finish and I am sure it is working :) <resttime>Blackbeard[m]: Something I'm a bit curious about, how are the 'paths' resolved for tex packages? <resttime>Like I'm assuming they live in the store so do you need to add the path somewhere? <Blackbeard[m]>resttime: I don't know :/ I just add al the environmet variables <joshuaBPMan>hey, what's a wayland based terminal that'll work pretty well? <kmicu>Where ‘pretty well’ means what? xD <joshuaBPMan>I basically want a wayland terminal that'll work with sway <joshuaBPMan>Blackbeard[m]: thanks, but I'd rather be able to Mod+Ret to open a terminal and not open emacsen <vagrantc>joshuaBPMan: i was using sakura under sway, but i suspect it was using xwayland compatibility layer <joshuaBPMan>If the eyes follow you around, then the application is using X <pkill9>weston provides a wayland terinal <vagrantc>joshuaBPMan: so you're looking for a native wayland terminal? <joshuaBPMan>I could install wayland and run weston. I think it has weston-terminal? <kmicu>(If you can accept compiling Rust and some bugs then Alacritty is the next best thing after wlterm/kmscon.) <joshuaBPMan>kmicu: Would you say it is fairly important to package libtsm ? <kmicu>joshuaBPMan: libtsm is already in Guix. *nckx recommends termite too, Wayland aside. <nckx>kmicu recommends... dumpster diving for real ones instead? <nckx>I've got some bad news about their Unicode support. <kmicu>To be constructive I recommend using a different terminal emulator for different tasks e.g. one for fast compiling, one for user interaction, one for VT-100 emulation, and so on. <nckx>I was going to say that every VTE is a (conscious) trade-off between unsatisfiable requirements so I agree 100%. <kmicu>Yep, double trade-offs all the way! <nckx>‘Nobody’ actually wants an accurate VTxxx emulator to work in. <kmicu>Hey, some folks like standards. DEC’s VTs are (old, idiosyncratic but) standard. <kmicu>(mlterm or Emacs’ terminal emulators are good with Unicode or R2L languages. So we can enjoy writing Persian with emojis ヽ(*＾▽＾)／ (though they are painfully slow so bad choice for compilation)) *nckx didn't know about mlterm. <nckx>vagrantc: I presume yes. <kmicu>Guix گویا سیستم عامل مورد علاقه من است. 😺