<lfam>When I try to reconfigure my GuixSD system from a desktop environment to something else, I can't complete the reconfiguration, because the X server is killed, killing the terminal emulator and reconfiguration process as well <lfam>I can't even do anything on a TTY after the X server is stopped, because the keyboard doesn't work. The kernel registers a USB keyboard when I connect it, but the keystrokes don't show up on the console <ajgrf`>lfam: that is pretty weird. is it still stuck or did you reboot since then? <lfam>I've rebooted several times. I've done several hard reboots and attempts at workarounds <lfam>The reconfiguration mechanism is trying to start and stop services without requiring the user to reboot, but obviously it would be better if it didn't try to do that <ajgrf`>you could try running your commands from screen or tmux so that it doesn't matter if X gets killed. also enter your reboot command at the same time so it doesn't matter if you lose the keyboard <Acou_Bass>lfam: have you tried running the reconfigure in a console? or that ^ <lfam>Acou_Bass: I don't know how to get a console on our desktop system. Do you? <Acou_Bass>same way you do on any other gnu/linux - ctrl-f2 <lfam>I didn't realize that was possible. I'll try it now! <Acou_Bass>i still reckon ajgrf`'s suggestion stands though, run it in a screen session <lfam>ajgrf`: Good idea. I'll probably try that too <lfam>Something broke so that even though I've rolled back the system, I can't launch GNOME as my unprivileged user <lfam>The issue with my user not being able to log in (except from root with `su`) is that UIDs are not preserved across reconfigurations that add and remove users. <lfam>So, not very hard to fix <ajgrf`> lfam: phew! i was hoping it wasn't data loss from your hard resets <lfam>Reconfiguring never deletes anything in /home, at least AFAIK <lfam>It will create a home directory if it doesn't exist yet <lfam>Anyways, this system is my least critical one: the "brain" of my home stereo. So, very important to me, but only to me :) <lfam>And of course all the music is replicated and backed up <sneek>quiliro, you have 1 message. <sneek>quiliro, bavier says: I fear I might not but of much more help in debugging your wireless firmware; perhaps some at the openfwwf project might be able to give suggestions? <quiliro>kyamashita: how are you and what are you up to? <kyamashita>quiliro: I'm doing fine. I'm looking to finish packaging Red Eclipse for Guix and move on to new packages. What about you? <quiliro>i typed an h because the Esperanto keyboard has the h on the o key.... <ADFENO>Hey! I also try to study Esperanto sometimes, but I find that it's often difficult to find good and shareable materials. So far I found a free software called Kurso de Esperanto, that I'm liking very much. :D <quiliro>but i could not install it in trisquel <kyamashita>quiliro: goblinrefuge is an instance of MediaGoblin. I believe ADFENO added one of my posts to a list of theirs. <ADFENO>I use Trisquel. And perhaps I remember you there too :D <ADFENO>quiliro: In my case, I didn't try to instal Kurso de Esperanto (actually, since I lost my copy, I must get a new one), but I remember that I had to edit the Bash script responsible for starting it to correct some minor mistakes. <mark_weaver>kyamashita: 'wrap-program' renames the program to something else, and then creates a shell script with the original program name that sets environment variables before running the program. <mark_weaver>kyamashita: on a GuixSD system, 'guix' itself is wrapped, so you can see what the generated shell scripts look like. <kyamashita>mark_weaver: Hm. I'm looking for a way to run my binary from within the /gnu/store directory. <kyamashita>mark_weaver: It does not appear that the wrappers launch the binary from within the /gnu/store directory. Red Eclipse is looking for folders in its relative path. <mark_weaver>kyamashita: do you mean that the current directory needs to be set to something specific before running the program? <kyamashita>mark_weaver: Yes. Specifically, one needs to be in the same directory or the directory just above that of the binary for it to run. <mark_weaver>you'll probably need to make your own wrapper to accomplish that. <mark_weaver>but that seems very unusual. usually programs will look at argv[0], and the wrappers generated by 'make-wrapper' take care to preserve argv[0] <mark_weaver>(that's the purpose of the -a "$0" arguments to 'exec') <kyamashita>Right. Red Eclipse seems to be hard-coded to use those relative paths unless I run "make system-install", but the system-install doesn't run. <mark_weaver>ah, but typically argv[0] will not contain the full path, and PATH will contain something like $HOME/.guix-profile/bin which isn't what the program wants. <mark_weaver>kyamashita: the best solution might be to patch the relevant code from a custom phase, to hardcode the /gnu/store directory where the files are located, replacing the logic to figure it out dynamically. <kyamashita>Is there a custom wrapper that I can base this one on? <mark_weaver>kyamashita: see the 'wrap-program' phase in the 'brdf-explorer' package in gnu/packages/graphics.scm <mark_weaver>although instead of using #!/bin/sh in the shebang, better to do what done in the 'conkeror' package in conkeror.scm, where the shebang is #!~a/bin/bash with the ~a replaced with (assoc-ref inputs "bash") ***Bobbejaantje is now known as NoorulIslaam
<mark_weaver>iyzsong: and since we use inkscape to build our grub background image, I guess it will not be possible to build systems <mark_weaver>iyzsong: I very much appreciate your work on gnome-updates, but I would have preferred to wait a bit longer before merging it. there are still over 2200 builds to do, and new failures such as inkscape that are needed to build systems. <mark_weaver>I would prefer to find and fix problems like that before merging <iyzsong>mark_weaver: fair enough. I should be more careful.. thanks. <mark_weaver>iyzsong: gjs failed to build on x86_64. I've asked hydra to try again, in case it was a non-deterministic failure. <mark_weaver>(when hydra starts the next attempt, that log will be replaced with the new one) <iyzsong>oops, gjs fails on my machine too.. I'll look to fix it. <mark_weaver>iyzsong: okay, thanks! I'll take care of inkscape. I have a patch, just waiting for my test build to finish before pushing it. <mark_weaver>hmm, the gtkmm-3.20.0 build failed twice in a row on armhf, but that's a lower priority <NoorulIslaam>I made a minimal guile programme that slept for 2000 seconds and did nothing more and it used quite a bit of RAM. <alezost>NoorulIslaam: sorry I have no idea how guile uses memory, it's probably a question for #guile <jlicht>hello guix! What an amazing afternoon, finding out I have a very nice few months of GSoC ahead :D! ***mevirus is now known as Guest68430
<janneke>ACTION pours another beer on phant0mas ;-) <janneke>phant0mas: freshly built: /gnu/store/678z1dffnnrmnka5w8qlal8pr59diaap-bootstrap-tarballs-0 <janneke>16:08:05 janneke@drakenvlieg:~/src/mingw-guix <mark_weaver>there were some updates with potential security implications that people will not be able to easily update to because 'master' is currently broken :-( <iyzsong>right.. i just find that it need a new version of geoclue. i did't build them locally and miss to check them on hydra, sorry :x <mark_weaver>iyzsong: ah, I see now that you already fixed that. thanks. <janneke>i'm now working to get rid of cross-gcc-core as civodul suggested <mark_weaver>janneke: what architecture are those bootstrap-tarballs for? <mark_weaver>wip-hurd+mingw is an intriguing name. what does it mean? <phant0mas>mark_weaver: the current wip-hurd which was rebased on master cannot build the bootstrap tarballs <phant0mas>because it takes into account native headers <phant0mas>janneke: suggested to try his patches on my branch <phant0mas>and proved that his fixes work for me as well <phant0mas>the question now is at which point was this problem introduced <janneke>phant0mas: i did do some minor things after the rebase... <paroneayea>if it's going to try to emulate full bourne shell, it'll need access to stdin, stdout and stderr of processes <mark_weaver>paroneayea: yes, it will need to deal with that, but there's no difficulty in fixing that. <janneke>phant0mas: the unset is no longer needed, just setting C_INCLUDE_PATH and CROSS_C_INCLUDE_PATH etc <mark_weaver>paroneayea: the thing is, our existing popen API can't really accommodate this. We need a new API. <mark_weaver>the current popen API combines the input and output pipes into a single bidirectional scheme port, which is a bad idea on many levels, but one reason it's bad is because it cannot be generalized to more than two ports. <mark_weaver>another reason is that it's not possible to close the input pipe before closing the output pipe <mark_weaver>that latter problem could be addressed by adding new procedures to close half of the combined port, but it still wouldn't generalize to more than two ports. <jmd>What is the status of LVM in GuixSD ? <mark_weaver>also, the combined bidirectional port is very slow, because it's implemented in terms of guile's legacy "soft ports" which are terrible and need to be deprecated and replaced with something better. <mark_weaver>the soft ports are textual only and work one character at a time, because of the nature of the API <ajgrf>gedit just failed to build for me because "gspell library not found or too old" <ajgrf>so i can't install the new gnome updates <iyzsong>ajgrf: my bad.. i can fix gedit next day :x <ajgrf>is it okay for my user profile to have the new gnome packages if my system is running the old gnome? or should i roll back my user profile too? <ajgrf>also, no worries ;-) i don't mind a little wait <mark_weaver>I tried restarting the armhf build, but it failed three times, and now I see it fails on x86_64 as well <mark_weaver>if we can't build updated systems soon, we should consider reverting the gnome-updates merge for now. <mark_weaver>I pushed some potentially important updates for linux-libre and webkitgtk very soon before gnome-updates was merged <paroneayea>mark_weaver: interesting, thanks for the context! <mark_weaver>iyzsong: I think we should revert the gnome-updates merge for now and continue fixing these problems on the gnome-updates branch. wdyt? <janneke>how do i insert a no-op into a modify-phases list? <janneke>(modify-phases phases (add-before) ,(if libc <no-op-here> `(,@'(replace ...)))) <janneke>`(,@'(add-before 'configure 'foo-bar (lambda _ #t))) ;; FIXME <mark_weaver>you can only use unquote where an expression is expected, and that is not such a place. rather, the 'modify-phases' macro looks at the form directly to decide what to expand into. <mark_weaver>,EXPR is read as (unquote EXPR) and that's what modify-phases sees <janneke>hmm, i don't understand yet...currently, i have <janneke> `(,@'(add-before 'configure 'foo-bar (lambda _ #t))) ;; FIXME <janneke> (zero? (system* "make" "install-gcc" "install-target-libgcc")))))))) <janneke>this is inside `(modify-phases ,phases (add-before ...) <HERE>) <mark_weaver>sorry, I was confused by the client-side vs build-side code distinction. the build side manipulates these expressions as data before they are macro-expanded and compiled for the build-side <janneke>do you know how i can clean-up the ;; FIXME line <mark_weaver>janneke: yes, I know how to clean it. give me a minute. <mark_weaver>`(modify-phases ,phases <...> ,@(if libc '() '(replace 'install ...))) <mark_weaver>`(modify-phases ,phases <...> ,@(if libc '() '((replace 'install ...)))) <mark_weaver>so, a couple of things here. the key idea is to use ",@(" instead of ",(", so that instead of inserting a single s-expression, a *list* of s-expressions is spliced in. <mark_weaver>and the other arm of the if must be a list of forms, so an extra set of parens is needed. <mark_weaver>but then the other thing is that `(,@'(...)) is equivalent to '(...) <janneke>splicing in a null list dissolves to nothing, that makes sense <janneke>ah, yes it must be a list; thanks mark_weaver! <jmd>What can be done about the multitude of "arbitrarily choosing ..." warnings? <mark_weaver>jmd: find ways to reduce the number of conflicts, one at a time... <jmd>Is there anything in place to prevent new conflicts arising? <kristofer>I'm running gnome, and in the top panel it says Sat 13:46, only the : is not rendered, it is just a box <jmd>kristofer: My guess is, that it's a fonts issue. ***NoorulIslaam is now known as Poetterware
<ADFENO>Thank you, I was about to paste "that interjection". <Dumitru_Nicolaev>OS kernel is a very special package. It's pointless to install it to users profile, it could be installed only systemwide. <Dumitru_Nicolaev>Maybe I should include mylinux.scm in my system configuration and do "guix system reconfigure"? <ADFENO>When reading the "Invoking guix system" section, this is exactly what comes to my mind. <Dumitru_Nicolaev>I'm not good at Scheme. How do I include mylinux.scm into /etc/config.scm? <ajgrf>Dumitru_Nicolaev: make sure that mylinux.scm is in $GUIX_PACKAGE_PATH (you will have to set that environment variable). then in /etc/config.scm, add (use-modules (mylinux)) to the top and (kernel mylinux) somewhere within (operating-system ...) <ajgrf>most people here probably run their system from a git checkout where they do their customizations, but that adds a bit more complexity to the process <cbaines>I've just installed emacs using guix on Debian, and I was wondering if there is an easy way to get the application to appear in the Gnome Shell? <ajgrf>cbaines: cp ~/.guix-profile/share/applications/emacs.desktop ~/.local/share/applications/ <ajgrf>you might need to restart gnome-shell afterwards <ajgrf>(i.e. log out and then log back in) <lumidragon>is there a way to search for package by it contents? such as find the package that has /bin/ls for example. <ajgrf>lumidragon: unfortunately not, unless the package is already on your system somewhere <lumidragon>ah ok, just something I got used to with rpm/deb based package managers. np and thanks. <ajgrf>lumidragon: i remember some devs talking about adding that feature, but i think they wanted to avoid having to trust a build server to do it (which makes it into quite a hard problem) <lumidragon>ajgrf: oh kk I could see how that would be case. Unless they make a p2p cache that would be shared between users. Each updating on what they know. <paroneayea>if I had a package like fmt which i wanted to package for guix and guile <paroneayea>is there some place in guix recipes to say "hey, copy in these files from this place <paroneayea>they're just files to provide a place to import into guile <lumidragon>I'm learning Guix and GuixSD myself, but you could take a look at guix build --load-path=directory <ajgrf>paroneayea: it's hard to understand what you mean. you want to import an outside library in order to package some other software? <paroneayea>I mean more a file to dump into the built package output :) <paroneayea>they're pretty short. I wonder if I should add them as patches or actually copy them in from tne guix source tree. <ajgrf>idk, probably a patch would be the clearest way, or maybe add them with scheme code right in the package definition if they're *really* short <lumidragon>This might seem like a simple question, but how do you set the domain name from the system config.scm? <ADFENO>lumidragon: I think there is an option to declare a host-name/hostname <lumidragon>yeah I saw that, but isn't that just for the hostname? <ADFENO>Oh... Sorry, I thought they were the same thing. :( <lumidragon>np, just I'm running my GuixSD via libvirt/virsh so it would nice to beable to ssh to it usiing a friendly name. Like I do with my other distros. <ADFENO>Hm... The best thing I could find in the documentation was host-name <lumidragon>I saw some package that might be in that area like avahi and nss-switch. But I'm not to familiar with them. So I'll just add it to learning list. <ADFENO>No problem, perhaps someone with network knowledge can cooperate with us (or you, because I'm not that good when it comes to programing), and implement domain name seting. <lumidragon>would be nice, but either way I plan to bring my knowledge of guix at a similar level to my knowledge of debian. <lumidragon>no Guix and GuixSD are awesome. even when compared to Arch. <lumidragon>it's almost like wrapping up GNU Stow with Guile.