IRC channel logs


back to list of logs

<milll>i'm trying to do an encrypted install and playing around with settings in the /etc/config.scm; since i'm getting stuck in grub boot, i want to just make a few changes to /etc/config.scm from the livecd and then reinstall the bootloader - can i do this w/o redownloading all packages (e.g. without guix system init).. i'm trying 'guix system reconfigure -r /mnt /mnt/etc/config.scm' but that seems to not recognize
<milll>the proper root filepath
<milll>e.g. can i use guix reconfigure from livecd with a target without chroot?
<milll>or how do i even chroot in livecd since chroot doesn't understand symlinks?
<apteryx>milll: the /gnu/store should exist on the partition you are trying to install to; unless you erase this partition, it should be preserved and when you guix system reconfigure the items there should be reused instead of redownloaded built. Think of /gnu/store as a cache.
<apteryx>there shuoldn't be a need to chroot
<milll>apteryx: thing is when i re-run the init command i can see it re-downloading all the packages, maybe it's a bug, basically i did one init as per the manual and then realized my boot config was messed up and now im trying to fix it without doing a full reinstall/init
<apteryx>milll: ah, maybe a new init would do that, but after you've init once, you should use reconfigure instead, which should preserve you /gnu/store and /var/guix
<milll>yeah but 'guix system reconfigure -r /mnt /mnt/etc/config.scm' doesn't seem to recognize the root?
<milll>i think the -r flag is for something else
<apteryx>yeah, -r in guix usually means: use this custom profile location instead of default one
<milll>ah i think i messed up either way now - cause i did re-init and then C-c
<milll>maybe that's why all my packages are dling even with reconfigure
<iyzsong>Hello (「・ω・)「
<Blackbeard[m]>iyzsong: hello
<quiliro>hello guix!
<quiliro>i have an error on guixsd that comes up every other boot....failed to start wpa_supplicant
<quiliro>i must start network manually
<quiliro>i tried to repair by reconfigure
<quiliro>but no luck
<quiliro>is there any updated light-desktop.scm sample file somewhere by the way?
<quiliro>foound it on section 6.2.1 of the manual...but i still have the wpa_supplicant problem
<quiliro>but on the sample template there is no keyboard-layout sample text
<quiliro>which i have found as a great addition
<quiliro>perhaps that is included in the graphical installation...but nothing on the manual installation
<wednesday>the (gnu system keyboard) stuff was only added a few days ago if that's what you're talking about, and about that stuff, for the keyboard-layout wont work for grub or the operating-system definition, also I think that update broke sddm because mine was starting with no x config
<th-end>how do i transfer my current build of icecat to another pc with guix-sd installed? assuming no internet connection (i.e. with a usb drive)
<quiliro>wednesday: thank you for the info... you mean that you suggest not to use it?
<quiliro>for themomont at least?
<th-end>alternatively how doi check an icecat binary is available so i can get one without recompiling it :)
<quiliro>if you do not use --fallback you get the binary
<quiliro>is what i understand
<quiliro>th-end: ^
<th-end>ok because as recently as last week there was no binary available for th elatest guixsd
<th-end>so i compiled icecat for about 30 hours
<quiliro>i think that either the info page or the online manual says something about what you are asking
<quiliro>not sure where
<quiliro>i was told binaries are generated at most 5 minutes after someone has asked for them with guix package -i
<th-end>where would i be able to see the latest builds of these binaries
<quiliro>i think the best is to search the manual and if not found, report on the mailing list with all the info you have researched...that would provide the best support
<quiliro>th-end: i do not know enough about guix to answor that question...what i would do is run guix package -i icecat... if it does not output an error and ask for adding --fallback, then it is using the binary
<quiliro>i asked about binaries some days must be on the guix chat log
<nckx><quiliro> i was told binaries are generated at most 5 minutes after someone has asked for them with guix package -i
<quiliro>nckx: did i understand wrong?
<nckx>^ Note that this was talking about compression (‘baking’) of the finished build into a NAR. The actual build can take less or much more time.
<nckx>s/this was/I was/, even, IIRC ☺
<th-end>nckx: is there a site tha twould show a completed icecat build
<th-end>because even as of just now typgin guix package -i icecat grabs the icecat source
<quiliro>th-end: how can you tell it is the source?
<th-end>it is a 260mb tar.xz
<th-end>matcing the nar for the source i alreadyt have extract on my filesystem
<th-end>also its grabbing clang
<nckx>th-end: A Web site? Not that I know of.
<quiliro>th-end: nckx has more knowledge...i will let him answer
<nckx>There M-x build-farm for emacs.
<nckx>th-end: Why?
<th-end>because if the buld passed youd thinkg a log would be available
<th-end>that says 'passed'
<nckx>th-end: Does guix package -i --dry-run not answer the question above?
<th-end>maybe a green checkmark for yes and a red x indication 'no'
<nckx>But this is under construction.
<th-end>unknown package?
<nckx>Don't just blindly copy things.
<th-end>i went through the same process last week to betold my version of guix has no icecat binary
<th-end>im just asking if thats still the case
<nckx>I obviously meant ‘guix package -i’ with ‘--dry-run’
<nckx>^ well, guix package -i icecat --dry-run will tell you what will be downloaded and what will be buildt.
<quiliro>th-end: perhaps you guix pull and immediately guix package -i icecat
<quiliro>then you have only source
<th-end>thanks for your time
<quiliro>beacuse it could be recently upleaded
<quiliro>but there could already be a binary
<th-end>and there could be flying pigs too but if there are maybe its documented which is why i asked
<quiliro>maybe you should ask on the mailing list
<quiliro>if you want a better answer....
<vagrantc>hrm. gnome seems rather dysfunctional ... it comes up, i try to do anything, and it just crashes, sometimes spinning gdm into a near-infinite loop until it decides to stop respawning...
<quiliro>vagrantc: while running what? epiphany?
<vagrantc>it also hangs selecting i3 from gdm.... and starts gnome when i select "i3 (with debug mode)"
<quiliro>sorry...not gnome yet
<vagrantc>quiliro: trying to bring up the application selection menu ... didn't even get as far as running anything
<vagrantc>oh, gnome starts, and it's a very pretty default gnome screen, but you want any applications? that's asking too much. :)
<quiliro>long ago i had that problem not remember circumstances now
<quiliro>i thought you said gdm will not start desktop
<quiliro>maybe a question of video drivers
<quiliro>because i use gnome on a core2duo with 3GB ram
<quiliro>it works decently until i open too many tabs or a javascript intensive side on epiphany
<vagrantc>gdm refuses to start "i3" when selected, it just drops back to the login screen.
<vagrantc>and selecting "i3 (with debug log)" drops me into gnome.
<vagrantc>which then has the aforementioned gnome behavior.
<quiliro>vagrantc: oh problem with i3 only... erase i3 configuration files...check location on manual
<vagrantc>i3 works fine if i start it from .xinitrc
<vagrantc>just not if i select it from gdm.
<quiliro>only with gdm
<vagrantc>if ~/.xinitrc is present, GDM uses that regardless of what you select, and i3 runs fine.
<vagrantc>if i remove ~/.xinitrc, then all the aforementioned behavior kicks in ... X eating multiple CPUs at full throttle
<quiliro>i have no problem booting into i3...but used a previous version of week ago or something
*nckx *gnome popcorn*
<vagrantc>i prefer i3 anyways, but every once in a while i figure i'll try these other fancy things.
<quiliro>why is the info page diferent from the online manual? not even the section numbers are the same
<vagrantc>maybe i have some old gnome configurations from previous attempts over a year ago ... and modern gnome just doesn't know what to do with it
<quiliro>are there two manuals?
<quiliro>maybe test on a vm
<nckx>quiliro: Because the on-line manual is for version 0.16.
<vagrantc>i guess i could start with a fresh user, too.
<vagrantc>testing on a VM wouldn't test if it was some weird hardware interaction
<quiliro>nckx: the online manual has keyboard-layout
<quiliro>vagrantc: fresh user...good alt
<nckx>quiliro: Huh? We're not talking about the same manual then.
<nckx>There's also
<nckx>and since I never use either I have no idea what the difference is or why there even is one. Weird!
<quiliro>section 6.2.1 on the info is 'Defining Packages'....section 6.2.1 on
<quiliro>is 'Using the Configuration System'
<nckx>quiliro: Are you sure they're in sync? I'm not. Anyway, /me is going to bed (ノ°Д°)ノ︵ 💻
*nckx has been fighting proprietary software all day.
<vagrantc>a fresh user was able to log into gnome and even do things
<vagrantc>but that user selecting i3 sent gdm into a crashloop
<vagrantc>such that "herd stop xorg-service ; herd start xorg-service" would just enter back into the crashloop
<vagrantc>need to reboot it to get gdm to behave again
<vagrantc>which makes it really hard to debug, because i basically have to wait until it decides to not respawn anymore
<vagrantc>er, ~/.xsession (not ~/.xinitrc)
<vagrantc>anyways ... enough of that
<quiliro>hello again
<quiliro>as i said previously, i hsee the www manual diferent from the info manual...will someone check please?
<atw>quiliro: I believe that the online manual is based on the latest release whereas one's local manual reflects one's installed version of guix
<quiliro>atw: will you please check the link and the info manual?
<quiliro>info does not have section 6. GNU Distribution
<quiliro>atw: did you check: info guix ?
<quiliro>would anyone check the info page please
<quiliro>for guix wntry that is
<marusich>Hello, Guix! Hope everyone is well.
<Blackbeard[m]>marusich: hello
<reepca-laptop>It'd be nice if our test logs gave useful information beyond the error type, like, say, where it occurred. For example, tests/pack.scm is failing for me (branch-local thing), and all I get in the log is that a wrong-type-arg error was caused because... something... was expecting its second argument to be a string and it wasn't.
<reepca-laptop>also, I get the feeling that "make" isn't properly detecting when go files need to be recompiled, as sometimes I'll do a "make clean-go" and wait an hour or so for everything to get rebuilt and then tests will pass that were previously failing
<quiliro> i am looking at info guix on section 8.6. Keyboard Layout:
<quiliro>at the bottom of the page there is a way to include a certain keyboard layout for console, for GrUB and for Xorg
<quiliro>but i do not understand how to integrate :
<quiliro>(services (cons* (gnome-desktop-service)
<quiliro> (xfce-desktop-service)
<quiliro> %desktop-services))
<quiliro>with the recommendation on the info page
<quiliro>(services (modify-services %desktop-services
<quiliro> (gdm-service-type config =>
<quiliro> (gdm-configuration
<quiliro> (inherit config)
<quiliro> (xorg-configuration
<quiliro> (xorg-configuration ;for Xorg
<quiliro> (keyboard-layout keyboard-layout))))))))
<quiliro>would this work_:
<quiliro>(services (cons* (gnome-desktop-service)
<quiliro><quiliro> (xfce-desktop-service)(services (cons* (gnome-desktop-service)
<quiliro><quiliro> (xfce-desktop-service)
<quiliro>(modify-services %desktop-services
<quiliro><quiliro> (gdm-service-type config =>
<quiliro><quiliro> (gdm-configuration
<quiliro><quiliro> (inherit config)
<quiliro><quiliro> (xorg-configuration
<quiliro><quiliro> (xorg-configuration ;for Xorg
<quiliro><quiliro> (keyboard-layout keyboard-layout))))
<quiliro>is there a recomended paste site that is best to use with emacs?
<quiliro>may i put cons and moodify-services on the services section?
<kmicu>Anything is better than pasting multiples lines into IRC log. There are many plugins on MELPA e.g.
<quiliro>i am using default emacs on guixsd. is there a default one? i am a newbie
<reepca-laptop>M-x eww RET RET
<reepca-laptop>I keep getting errors where modules that clearly have imported the right modules that are clearly exporting the right stuff get "unbound variable" errors
<kmicu>There is no paste service package by default in Emacs.
<reepca-laptop>I feel like I heard something about a miscompilation in guile awhile back that had symptoms like that
<kmicu>reepca-laptop: is that in a stock Guix or do you package something new?
<kmicu>(Cuz you are not the first one in Guix logs with strange unbound variable issue.)
<reepca-laptop>kmicu: uh, it's on a different branch, but I don't think I've touched the place htat's having issues
<reepca-laptop>(different branch is pretty up-to-date, rebased yesterday)
<reepca-laptop>guile thinks (guix utils) doesn't know anything about %system, even though it has a #:use-module (guix config) and (guix config) has %system in its #:export list
<efraim>After Ludo's changes?
<efraim>I had to make clean-go after that
<kmicu>‘make clean-go && make’
<reepca-laptop>last commit from master I have on my branch was 32e0f906d775679d8b4e770d267d29cb77724360, little over 1 day ago
<reepca-laptop>I have run make clean-go quite a few times since then
<efraim>(I'm on my phone, out of off the cuff ideas)
<reepca-laptop>well, I guess I can rebase again and see if it works out
*kmicu hopes that’s not a typo in modules/variables names xD
<reepca-laptop>quiliro: to answer your question, (modify-services ...) returns a list of services. So you can treat that entire form the same as %desktop-services. e.g. (services (cons* extra-service-1 extra-service-2 (modify-services %desktop-services <modification form go here>)))
<quiliro>reepca-laptop: great advice
<reepca-laptop>it's quite the nuisance rerunning make after a clean-go.
<quiliro>reepca-laptop: so modify-services goes inside cons* ?
<sarg>Hi, all. I'm completely sold to try guix after ambrevar's post. I've got it installed on top of my debian and now I'm moving my apps into guix one by one. I've typed `guix package -i flameshot` and was dazed that it tried to install `mariadb` and `postgresql`. I've looked at `guix package -i flameshot` and was deeply shocked how big is the dependency diagram. So I'm curious, how do I tell guix to install only absolutely necessary
<sarg>runtime deps?
<kmicu>quiliro: Yes, you can put it inside cons*. ‘(modify-services …)’ takes services and returns them (modified) so you can put it in any place with services list like e.g. ‘%desktop-services’.
<quiliro>reepca-laptop: or is it rather like this?: (services (cons* (gnome-desktop-service) (xfce-desktop-service) %desktop-services (modify-services %desktop-services <modification form go here>)))
<kmicu>‘(modify-services %desktop-services …)’ can be safely dropped in place of ‘%desktop-services’
<quiliro>kmicu: so it is not as i said but rather as reepca-laptop said: (services (cons* (gnome-desktop-service) (xfce-desktop-service) (modify-services %desktop-services <modification form go here>)))
<quiliro>kmicu: cool
<kmicu>sarg: currently you cannot cuz flameshot is packaged that way and pulls in Qt et al.
<quiliro>kmicu: isnt it possible to change any definition on guix?
<quiliro>to remove Qt unless the package really needs it of course
<kmicu>It’s possible to change it how we want it but it takes time and I assume sarg is after something like ‘guix package -i flameshot-minimal’ and not spending next week repackeging Qt stack xD
<reepca-laptop>"guix graph" could help you with seeing how exactly it gets pulled in
<reepca-laptop>'guix graph --type=references flameshot | dot -Tpdf > dag.pdf' tells me that the reference chain goes flameshot -> qtbase -> mariadb
<sarg>reepca-laptop: yeah, do you think it's sane? Maybe qtbase recipe should be updated?
<sarg>kmicu: debian packages allow to have "recommends" and "suggests" dependencies ( Does guix have something like that?
<reepca-laptop>sarg: well, assuming that qtbase can work properly for some applications without mariadb and the like, there's the simple issue of checking every single package that depends directly or indirectly on qtbase to see if it works without those features.
<reepca-laptop>AFAIK, no, we just use package variants. It's as simple as (package (inherit some-package-minimal) (name "some-package-not-minimal") (inputs (append `(("cool-new-dependency" . ,cool-new-dependency)) (package-inputs some-package-minimal))))
<reepca-laptop>... which doesn't look all that simple when it's forced on one line like that, but oh well
<reepca-laptop>in summary, it's not so much an issue of "can it be done", but rather of "who's gonna do it?".
<reepca-laptop>there's also the issue that qtbase itself (not including dependencies) is 67.7MiB, and a qtbase-minimal would probably not be much less (just less dependencies), so if you ended up using both qtbase and qtbase-minimal, that'd be a significant amount of extra space.
<reepca-laptop>though deduplication would likely help a lot with that
<reepca-laptop>aha, finally rebuilding all the go files is finished
<reepca-laptop>... and I still get the unbound variable issue
<tune> is this normal? looks like it's making me build 5 versions of rust...
<tune>it's been going since yesterday
<reepca-laptop>huh, I wonder if the rust toolchain was updated recently. You'd think at least one of those versions would have substitutes...
<sarg>`apt-rdepends -d flameshot | dot -Tpdf > deb.pdf` results in much smaller dep tree. And there are no DB server packages there.
<Blackbeard[m]>tune: it is not
<Blackbeard[m]>you can do
<Blackbeard[m]>guix package --delete-generations
<Blackbeard[m]>and then collect garbage
<Blackbeard[m]>but see the manual
<Blackbeard[m]>after that do a guix pull
<tune>how would that change which packages are being updated?
<Blackbeard[m]>you will build only latents rust
<quiliro>coul not use
<Blackbeard[m]>not all of them
<quiliro>Could not add your entry to the paste database:
<quiliro>Language not found
<quiliro>i am browsing with emacs
<tune>I'm hesitant to stop what it's doing in case that would mean having to start over building any of these rust things
<tune>since it takes so long
<reepca-laptop>Blackbeard[m]: I'm not sure that's strictly accurate, I think the issue here is that the latest rust depends on older rusts for bootstrapping. As far down the history of rust as substitutes aren't available, they'll have to be built all the way from there in order to get the latest, even if the latest is the only one that ends up being used
<Blackbeard[m]>reepca-laptop: yeah it might not be
<Blackbeard[m]>i only speak from experiencie
<Blackbeard[m]>it helped me to solve the same issue
<Blackbeard[m]>like 3 days ago
<kmicu>sarg: Guix is much younger than Debian. There is not many Qt users yet to polish every package. You’re welcome to report such issues and improve the situation.
<reepca-laptop>tune: have you authorized substitutes from hydra as well as
<kmicu>tune: stop it, use an older guix revision with rust substitutes.
<tune>I once authorized an alternative build server but I think that was when hydra was the main one. I don't know if it can use both
<tune>how do I check?
<tune>kmicu: I haven't installed any new packages in a while so shouldn't I already have some of this built?
<tune>I was holding back icecat, emacs, rust for a bit due to gtk issues and because icecat and rust have long build times
<quiliro>oh no! it is downloading rust when asked to install icecat.....ahhhhhh!
<reepca-laptop>tune: /etc/guix/acl should have the authorized keys
<reepca-laptop>you might need root access to read it though
<reepca-laptop>unfortunately they don't exactly include a human-readable identifier
<tune>it looks like there are two entries, one is ecc and one is rsa
<tune>I don't see titles to know what's what
<reepca-laptop>mine also has one ecc and one rsa
<reepca-laptop>and I think I've got both hydra and the other one
<kmicu>tune do you have 8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394 there?
<reepca-laptop>aye,, and #00DB163....
<tune>kmicu: yes that's my top one
<tune>reepca-laptop: and yes that'ss the other
<kmicu>tune then we need to find a revision with a working Icecat.
<tune>well my icecat works, it's just not the newest version
<tune>will finding this revision somehow make it unnecessary to build rust? I don't completely understand
<kmicu>Older than 60.6.1?
<tune>I'm on 60.3.0
<kmicu>Icecat (Firefox) needs rust, rust need rust, rust needs rust (bootstrapping chain).
<reepca-laptop>icecat only needs rust-1.24 though
<quiliro>(swap-devices (file-system-label "swap")) is correct?
<kmicu>guix pull --commit=fd9fe868f818b159b58c6a9811cc68e752a0af48 has Icecat substitute
<quiliro>assuming the partition label is swap and the filesystem is swap ofcourse
<tune>kmicu: so I should stop my current build, pull that commit, then update again and it should be faster overall?
<reepca-laptop>I'm curious what needs these high versions of rust
<kmicu>It should only download things and compile nothing. So we go from days to minutes.
<tune>I may have rust itself installed although I honestly don't use it
<tune>how do I check what's pulling it all in?
<tune>so after that pull do I do a normal update or do I also have to specify that commit when updating?
<kmicu>Hydra should be there by default. Sometimes is missing cuz it's newer.
<kmicu>(Sorry, was on a backlog xD)
<kmicu>tune: everything besides pull --commit should be as usual.
<tune>kmicu: here is the pull plus a dry run of updating. it looks like it will still build 4 rust versions
<tune>also all server mentions are rather than hydra I notice
<kmicu>Icecat is avaiable but it looks like you also want newer rust so that’s not available.
<tune>I'm going to uninstall rust and then see if the dry-run is changed
<tune>oh that appears to solve it. nice
<tune>I'll just install rust again in the future if I decide I want it. for now this should update quicker
<kmicu>Generally it’s possible to pull different packages from different guix revisions but I would like to avoid even bigger confusion xD
<kmicu>For example you could install rust from (guix rev c948cf90925dee5c07119140636e78877e9374b4).
<kmicu>(Though Hydra still shows tooltips how to do that with Nix 🤭)
<reepca-laptop>guix package -u "" --do-not-upgrade=rust
<kmicu>Or like that above ^^
<kmicu>Generally Guix is very flexible and there is (too) many ways to do more or less the same thing. That’s confusing for newcomers.
<quiliro>hello again...was disconnected
<tune>all updated now. thanks for the help
<quiliro>please tell me if (swap-service "/dev/sda1") is correct inside operating-system
<quiliro>for guix reconfigure
<quiliro>ERROR: In procedure scm-error:
<quiliro>In procedure map: Wrong type argument: "/dev/sda1"
<quiliro>tune: was it quicker?
<tune>much much quicker
<quiliro>tune: what did you do?
<tune>I got icecat from a different revision and then I uninstalled rust
<tune>I had rust in my package list from playing with it in the past but I wasn't using it anymore
<quiliro>i do not have rust installed
<tune>quiliro: for my swap I have (swap-devices (list "/mnt/swapfile"))
<tune>but that's for a swap file instead of a partition
<quiliro>oh! swap-devices!
<quiliro>i do have it that way...haha
<quiliro>(swap-devices ("/dev/sda1"))
<quiliro>but it is not a swap file
<quiliro>as yours
<quiliro>it is a partitiion
<quiliro>swap files will not work for hybernation
<quiliro>only for suspension
<quiliro>and virtual memory of course
<quiliro>tune: do you haveswap-devices inside of file-systems
<tune>it's next to file-systems but outside it
<quiliro>same here
<wednesday>why does my mpd service fail on every startup?: (service mpd-service-type (mpd-configuration
<wednesday> (user "wednesday")
<wednesday> (music-dir "/home/wednesday/Music")
<wednesday> (playlist-dir "/home/wednesday/.config/mpd")))
<quiliro>i have an error on reconfigure, something is wrong with my swap-devices sentence
<quiliro>would someone confirm if this is the correct syntax?:
<wednesday>(swap-devices '("/dev/sda2"))
<quiliro>wednesday: thank you thank you thank you
<quiliro>i saw no example in the manual
<wednesday>It should be in the operating system definiton part
<quiliro>works now wednesday
<quiliro>12 hours of pain just for that
<quiliro>yesterday i waswondering why the info page for guix is diferent than the manual on the web is either older than the web or a totolly diferent document
<quiliro>i am inclined to think they are diferent documents
<wednesday>I got no idea really, I tend to just look at the source and the website to get what I need
<wednesday>Id say the info pages are more up to date though from what I can tell
<nckx>quiliro: They are not. But as I pointed out yesterday, there are two different ‘manuals on the Web page’ so it would be helpful if you could be less ambiguous.
<nckx>Also, don't forget the mailing lists, which are usually better at handling questions like this.
<nckx>More eyeballz.
<nckx>And you can add links and quote the exact differences.
<nckx>♥ mail.
<wednesday>nckx: can you check if the recent keyboard stuff all works heh, with the boot loader keyboard-layout I would end up with the keyboard not working, and my sddm kept starting with no x config heh
<wednesday>also the keyboard-layout in the operating-system definiton was giving me syntax errors or something heh
<kmicu>FYI The manual has swap-devices with example values like default '() and '("/dev/sda3") or '("/swapfile")
<nckx>wednesday: I'd honestly love to, but I don't have time right now.
<wednesday>all good heh
<wednesday>was struggling with sddm for a couple days before I realised it was starting with no x config ha
<nckx>wednesday: What would be helpful would be pasting (a link to!) your full configuration either here or (heh) the mailing list. Good luck o/
*nckx ~> away.
<wednesday>I'll have to do that later because I'm off out now
<quiliro>yes there are examples for swap-devices but not as clear as the examples for file-systems
<quiliro>y posted the urls for the diferences on the manuals and detailed them yesteday....but you are right, the mailing list is a better place to organize this information
<quiliro>thank you all for the valuable help...i will reboot now to test my successful reconfigure :-)
<quiliro>see you soon
<kmicu>quiliro: you can also use code repos for real world examples
<kmicu>sneek_: later tell quiliro you can also use code repos for real world examples
*kmicu wonders whether something is broken or AI uprising has just started.
<Blackbeard[m]>apteryx: hi :D
<quiliro>hello again
<quiliro>i could activate the swap partition :-)
<quiliro>small victories sound so great, dont they?
<quiliro>i feel as if i had conquered mount chimborazo!
<quiliro>i still have problems to have keyboard defined for gnome before login
<quiliro>my use case is that i use dvorak-es and my fiancee uses querty-es
<quiliro>so she must gnome login with qwerty and i with dvorak
<quiliro>i dont think it is much of a fiancee will learn dvorak! haha
<quiliro>but on the end, this might be useful for other machines where the users are not so flexible
<quiliro>having a keybord choice for users on gdm login based on their specific keyboard choice inside the DM
<quiliro>kristianpaul: hola
<quiliro>no sabia que estabas hackeando guix!
<Blackbeard[m]>quiliro: hola
<Blackbeard[m]>creo que gnome usa GDM
<Blackbeard[m]>y debes poder agregar distribuciones de teclado a GDM
<Blackbeard[m]>quiliro: aquí mira
<atw>where is the source for I noticed that it doesn't seem to redirect to HTTPS, maybe I could try adding that
<atw>ah wait, is it
<quiliro>Blackbeard[m]: estoy poniendo un mensaje en help-guix
<quiliro>porque puse en el archivo de reconfigure
<quiliro>un parametro keyboard-layout
<quiliro>Blackbeard[m]: enviado
<atw>don't wanna speak too soon, but I think I just got a successful GuixSD install on prgmr!
<Blackbeard[m]>atw: ٩(◕‿◕。)۶
<quiliro>atw: prgmr?
<quiliro>b back
<apteryx>atw: sweet!
<atw>apteryx: I spoke too soon, I'm still having trouble with guix pull on the Frankenstein's-monster of a Guix system that I've got
<apteryx>uh uh :-/
<apteryx>why is it Frankeistein?
<atw>I am doing a Guix binary install on debian, then running guix system init
<apteryx>OK! I've heard success stories from that approach before.
<apteryx>What went wrong?
<atw>hard to say, but after rebooting and running guix pull, I get messages like error: executing `/gnu/store/vhx3sg5sqj0mnv4inkjhf7c8xvlmjhxh-guix-0.16.0-11.f970946/libexec/guix/substitute': No such file or directory
<atw>guix pull: error: unexpected EOF reading a line
<atw>and then "everything breaks" -- a lot of "no such file or directory" when trying to run the sshd, or guix, or agetty
<atw>I recognize that what I'm doing is a nonendorsed hack :)
<apteryx>Interesting! I wonder what is at play. At least it is booting up? Using linux-libre et al.?
<quiliro>i sent an email about keyboard-layout to the mailing list
<apteryx>atw: Where is your guix comming from? It should be from ~/.config/guix/...
<apteryx>not ~/.guix-profile/..., just to be sure
<apteryx>There was a change in the way 'guix pull' works, and the transition from the old mechanism to the new one is not without bumps. I already forgot if 0.16 was released with the old way of doing 'guix pull', but I have a feeling it was.
<atw>apteryx: re at least it boots: yeah! small victories! I have already learned a few things, like the necessity of removing Debian's /etc/ssl /etc/pam.d /etc/skel
<apteryx>atw: hehe, you can probably wipe /etc/ clean without much problems, as the essential things there should be populated at boot, when the operation system configuration is "instantiated" :-)
<atw>re where does my guix come from: it should be ~root/.config/guix, but let me reinstal and try again. I will also try wiping Debian's /etc in entirety
<efraim>try running reconfigure instead of init
<atw>efraim: that works even if the system has never been installed before?
<efraim>atw: it works better when installing over another system
<efraim>it'll also remove the extra debian users and groups iirc
<atw>ooh perfect, I'll try it. Should I guix pull before donig that?
<efraim>up to you, I'd say it depends on your config
*atw waits for the reconfigure
<atw>which guix gives /root/.config/guix/current/bin/guix , apteryx
<reepca-laptop>hmmm, do module-imports check if the file has been changed? I changed a file in my guix checkout, but no matter how much re-configuring, make clean-go, rebuliding, and ultimately running of make check I do, a test always fails because a module-import-compiled keeps on using old broken sources.
<atw>guix pull in the installed system is looking good! Thank you efraim and apteryx!
<reepca-laptop>now the module-import-compiled is failing by saying that %make-hash-table* isn't bound... but the only time it's ever even directly used is in the same module it's defined in! I am so confused.
<reepca-laptop>civodul: You wouldn't happen to know of any steps I need to do other than cut+pasting parts of (guix store) and (guix derivations) into (guix store files) and (guix store derivations), respectively, adding a define-module at the top of both of those with the right modules, changing (guix store) and (guix derivations) to use them and re-export the same bindings, and changing (guix store database) to use them, would you? I've done that
<reepca-laptop>and I'm getting bizarre errors in the test case where seemingly random variables end up unbound when they really shouldn't be.
<reepca-laptop>s/test case/tests
<civodul>reepca-laptop: the unbound variable errors may stem from circular dependency among the new modules you introduced
<civodul>you need to make sure there are no cycles there
<civodul>i could take a closer look if you post the patch that you have
<apteryx>atw: nice :-). So what did you end up having to do, exactly? One guix system init, then one guix system reconfigure?
<atw>I skipped the guix system init altogether and instead did a reconfigure. The resulting system does not break on guix pull
<reepca-laptop>civodul: (guix store files)'s only guix dependencies are base32, base16, config, and memoization, none of which cause circular dependencies, and (guix store derivations)'s only guix dependencies are base16 and memoization, which again don't cause circular dependencies.
<ngz>Hello. I often encounter the same issue while packaging stuff. I wonder if there's a common solution. So, let say the executable "fooexe" of a package "foo" is only in $out/share/foo/fooexe. I want it in $out/bin/ too. One solution is to symlink fooexe in bin/, but it messes with CWD, and the symlink may not find data in share/foo/.
<civodul>reepca-laptop: yeah sounds good; it's hard to tell more without looking at the code though
<civodul>ngz: share/ (aka. $datadir) is for platform-independent files
<ngz>I think I could create a script in bin that basically pushd "share/foo/", exec "fooexe" and popd thereafter. However, I don't think any packages does it.
<civodul>so there shouldn't be any binaries in there, normally
<ngz>civodul: as I said, it is an issue I often encounter, so we have to deal with it anyway.
<civodul>ngz: i'd suggest adjusting the makefiles so they install to bin/ or libexec/ or lib/ instead of share/ in the first place
<ngz>OK. And in the second place? :)
<ngz>Some of the packages have no Makefile, or the Makefile has no install phase, etc.
<ngz>It's the jungle out there ;)
<rekado>What do you think of the this POWER9 mATX board: ?
<pkill9>is it possible to put a manifest into the 'inputs' field for a package?
<civodul>ngz: well, if they insist to have share/foo as their CWD, then i guess you have to do it :-)
<civodul>pkill9: nope
<civodul>rekado: it looks nice
<civodul>you're thinking about the build farm?
<ngz>civodul: Certainly, but how? Is a bash script using pushd/popd dance an acceptable solution?
<rekado>build farm or as a replacement for my aging workstation at home.
<pkill9>civodul: i don't suppose you could post a snippet of a way to convert a list of package names into something that the 'inputs' field would take, that i could cargo-cult :P
<rekado>new old DDR2 RAM is still pretty expensive, so I wonder if it’s worth trying to do an incremental upgrade.
<pkill9>hmm i don't relaly need to do this really, nevermind
<pkill9>i'm just overthinking things
<rekado>it’s a bit too expensive for home use, actually, but the price for this board is a big improvement over the other Talos workstation boards.
<civodul>ngz: 'cd' is enough; i think OpenFOAM does that
<civodul>rekado: though the real issue is that it'd be unsuable until you've ported Guix :-)
<rekado>yeah… :-/
<civodul>or you could run everything under QEMU given that these CPUs are fast-paced ;-)
<civodul>(that's what HP did with the successor of the HP48!)
<ngz>civodul: I think OpenFOAM uses a symlink. Wouldn't `cd' change cwd for the user calling the executable?
<civodul>no, it would only change it for the wrapper script
<civodul>but it could be visible for instance in "open file" dialogs, etc.
<ngz>That's not great either…
<civodul>at any rate you should tell upstream to consider doing something about it
<vagrantc>huh. i just enabled network-manager on the novena only to discover the wifi is working ... i had assumed it needed firmware blobs or something
<vagrantc>i guess it's got an ath9k
<ngz>civodul: Of course. Still, the answer, if any, can take a long time, so this cannot be a short term solution.
<civodul>yes i agree, you need a fix in parallel, and it may not be ideal
<civodul>vagrantc: well that's good news!
<reepca-laptop>civodul: just realized that patch was from after one of my branch-local commits (left out some changes in (guix store database)), here it is against master:
<icarious>Hello. I read it spossible to use the guix package manager under an existing system. Is it containerized like snap in Ubuntu?
<icarious>Similar analogy?
<civodul>reepca-laptop: what's the error message or backtrace that you get?
<civodul>icarious: programs you install with Guix don't run in containers
<atw>icarious: I think it would be accurate to say that things are installed under /gnu/store and that environment variables like PATH are augmented to find things installed by Guix. Does that help?
<icarious>civodul: atw: So it won't conflict with system packages right?
<icarious>That's all I needed to know
<icarious>I use Gentoo and want to give it a try. I like the concept
<civodul>heh cool
<civodul>reepca-laptop: ooh i see
<civodul>it's not "your fault"
*reepca-laptop sighs in relief
<civodul>it has to do with <>
<civodul>there are already workarounds in (guix scripts pack)
<civodul>we'll have to fix it for good...
<reepca-laptop>So then if I change the relative order in which (guix memoization) gets compiled such that it gets compiled (before? after?) all the stuff that uses it, it should work?