IRC channel logs


back to list of logs

<Sleep_Walker>thanks, it really helped
<dadinn>hi all!
<dadinn>quick question: I have am just trying out guixsd booted from a usb drive. I have tried NixOs the same way before, but since I am more into lisp, I thought that guix might be something I would be more comfortable with (not a fan of curly brackets, and static typing, prefer parentheses and decent macro facility). I have ran into two main obstacles so far: 1) it seems that unlike NixOs, the GuixSD does not
<dadinn>contain the ZFS kernel modules and binaries by default. Why is this and is there a guide to set it up? 2) I don't have wired Ethernet, is there a guide how to configure the wifi WPA2 connection? Or should I just try to follow an Archlinux guide?
<lfam>dadinn: Configuring wifi in the installer image should work like it does in other systems, assuming your wifi hardware can be used with free software (we only package free software).
<lfam>Do you know what wireless chip you are using?
<lfam>Regarding ZFS, the Guix and GNU communities will need to decide if the license is compatible with the kernel. My impression is that the other distros simply don't care about these issues very much. But we do care, as a GNU project.
<dadinn>lfam: about the chip, not sure of the exact chip right now, but Fedora runs fine on it, so I suppose it should be supported...
<lfam>I haven't looked into that very closely, so I don't have an opinion
<lfam>dadinn: There are very few wifi chips that can be used with free software. Try `lspci` in the GuixSD installer image to see what you have
<dadinn>lfam: the network controller is Qualcomm Atheros AR922X
<lfam>Considering this recent statement from RMS, I doubt we will be shipping ZFS kernel modules: <>. But, the first of the 4 softare freedoms is the freedom to use the software as you see fit. Guix makes no effort to prevent you from using whatever software you prefer.
<lfam>That wifi chip works with free software, so it should be possible to set up a wifi connection in the normal way
<lfam>In the installer image, you'll probably set it up "by hand" using ifconfig, wpa_supplicant, etc
<lfam>In GuixSD, we have system services to set it up automatically
<lfam>We have a wicd-service, a network-manager-service, and a connman-service to choose from. There is also a static-networking service although I haven't tried it and I'm not sure how it handles wifi authentication
<dadinn>lfam: regarding zfs I am using zfsonlinux, which is essentially an FREE layer between the OSS code of zfs OSS code (not FREE according to RMS), so it work together with the GPL kernel. In the github sources it is under spl dir. considering it is quite similar in concept to fuse, I would think it worths a look. I actually possibly would be fine with fuse for testing/recovery
<dadinn>purposes, or at least a guide with instructions somewhere to copy/paste to set it up
<lfam>The CDDL (ZFS's license) is a free license, but my understanding is that it is incompatible with the GPL, and so it can't be distributed with Linux. I'm really not an expert on this issue, however.
<lfam>Personally, I think it would be awesome to have ZFS available. If it's possible to do that within the GNU Free System Distribution Guidelines, I'd be thrilled.
<dadinn>lfam: yes, I have all my NAS/server storage running on ZFS, and with NixOS I was quite thrilled that I can set up everything in a Live env. So I am missing that.
<dadinn>lfam: lspi says the kernel driver is ath9k, so it should work. I suppose I should just follow the Arch wiki?
<lfam>Sure, if that works for you
<dadinn>lfam: thx for the help
<lfam>Is it working?
<dadinn>lfam: trying to set it up according to Arch wiki, but I don't have wlan0 device... the closest is wlp6s6
<lfam>Yes, the device names will probably be different from what you're used to
<dadinn>lfam: ip link set w* up says: IPv6 ADDRCONF blabla: link is not ready
<lfam>dadinn: That may just be a warning message. Can you do any further steps?
<dadinn>lfam: can't figure out what's next, shall I be using iw something* or wpa_supplicant, and how...
<lfam>dadinn: I skimmed the Arch wiki page and the basic example is under "Here is a complete example of setting up a wireless network with WPA supplicant and DHCP. "
<lfam>Although we have dhclient instead of dhcpcd
<lfam>Our manual also has more detailed instructions:
<lfam>I recommend using our manual instead of Arch's wiki
<dadinn>lfam: Ok, I'll check it
<dadinn>lfam: I like the `loadkeys dvorak` as first step, btw why dvorak is not the default anyway :P
<lfam>It's not the first step. Did you read the earlier sections?
<lfam>If you haven't, I recommend it:
<lfam>Else you will get confused
<dadinn>yeah, I have already booted in the live USB guix system, so I suppose the Preparing for Install is the I should read, actually I remember looking at thot wpa_supplicant.conf code before and I was thinging why I cannot find it on the Arch wiki...
<lfam>The "live USB" system is actually an installer. It's not much of a system on its own. If you just want a custom live system, you can use `guix system disk-image` to create one to your specifications
<dadinn>lfam: you mean I can't install things with `guix package -i` while running it?
<lfam>dadinn: Yes, but it won't persist
<dadinn>lfam: it seems the dhcpclient command ended with "NO DHCPOFFERS received. No working leases in present database - sleeping"
<lfam>Sounds like it didn't get a DHCP lease
<dadinn>lfam: retrying doesn't work either
<lfam>Did wpa_supplicant exit successfully?
<dadinn>lfam: same message
<lfam>wpa_supplicant printed something about DHCP?
<dadinn>lfam: ping says network is unreachable
<lfam>What do you mean by "same message"?
<dadinn>lfam: wpa_supplicant does not print anything, and psgrepping for it doesn't return any pid, I suppose it is not running
<lfam>It should be running in the background if it worked correctly
<dadinn>lfam: but the -B should make it run as daemon no?
<lfam>Yeah, that would background it
<lfam>Try running it in the foreground, to see what it prints
<dadinn>lfam: Uhh, sorry my mistake, had an 'echo' in front of it while putting together the command :P
<lfam>That'll do it :)
<dadinn>now dhcpclient worked, and able to ping, so I suppose I'll be able to install stuff too ;)
<lfam>Yay :)
<dadinn>lfam: wow, thx for everything
<lfam>No problem!
<dadinn>lfam: are you involved / contributing to GUIX yourself?
<lfam>Yes, I contribute to Guix
<lfam>(Not all caps ;) )
<lfam>dadinn: By the way, if you are using the 0.11.0 install image, beware all the security vulnerabilities we've fixed in packages since that was released. To get the latest package definitions, use `guix pull`
<lfam>To upgrade any installed packages once you've done `guix pull`, use `guix package --upgrade .` (the . is a regex)
<lfam>And remember that Guix provides per-user package management, so `guix pull && guix package --upgrade .` is per-user
<dadinn>lfam: I would possibly like to be involved too in the future, I am already getting so excited lol (can't wait to dive into the Emacs-mode, this is the best thing since sliced bread!). What main channels (mailgroups, etc.) would you recommend to be in the flow with the community?
<lfam>guix-devel is the primary mailing list for development, and this IRC channel is where we chat about Guix. This page should help you find your way:
<dadinn>lfam: it store the packages (links to them) under /var/guix/per-profiles/username if I am correct.
<dadinn>If I create a new user with useradd, will the new profile for it be automatically created/set up?
<lfam>The actually package binaries are installed to /gnu/store. User "profiles" are symlink forests in /var/guix, and the current profile is symlinked to ~/.guix-profile
<lfam>Users are not created with useradd, but rather by editing a GuixSD system declaration / configuration file, and then running `guix system reconfigure path/to/configuration-file` as root
<lfam>The system is declarative
<lfam>Check section 7 of the manual for details :)
<dadinn>lfam: I mean is there a guix command to manage/create/delete user profiles? or everything is manual?
<lfam>But remember that no changes will persist in the live image
<lfam>You have to create an OS configuration file (there are templates in /etc/configuration), edit it, and then reconfigure. But from the live image it's more typical to install, which is `guix system init`
<lfam>What do you mean by "manage/create/delete user profiles"?
<lfam>If you mean create users, then you have to reconfigure. To manage the "profile", which is the set of software visible to a user, use `guix package` as that user
<lfam>I recommend the manual. It's good :)
<dadinn>lfam: sure, I mean those profile folders under /var/guix/profiles are updated based on the name of the actually logged in user?
<lfam>Here is the section on user accounts:
<lfam>dadinn: Right, although I bet you could do it as another user with `su`
<lfam>When you create a new user, that stuff in /var/guix is updated automatically
<dadinn>lfam: really? but that means adduser/useradd has that functionality built-in?
<dadinn>lfam: or what creates those folders?
<lfam>We don't use useradd or adduser. If you use those programs, they won't work as expected
<lfam>Edit the configuration file and reconfigure the system
<dadinn>lfam: ok, I see. Makes sense.
<lfam>But like I said before, there's no point in doing this in the live image. Your actions' effects won't persist
<lfam>If you want a live image with different users, use `guix system disk-image` to create one
<lfam>You probably won't have the space to do that in the live image, btw
<lfam>It's really just an installer, designed to install GuixSD on a computer
<dadinn>but if I run guix package -i then it will be reflected in the /etc/configuration? and I can send it by email to myself?
<dadinn>lfam: I know, I am quite noob, even with NixOs
<lfam>No, those configuration files are only examples, and they have no relation to the live USB install system you are running
<lfam>Also, the configuration file never gets updated automatically. It's one-way
<lfam>And, it also doesn't describe users' installed packages.
<lfam>I recommend reading section 7 of the manual fully
<lfam>It will help you understand how to use the system
<lfam>I also recommend the introduction, and section 3 Package Management
<lfam>You will understand it better if you do that than if you ask questions here :)
<dadinn>lfam: so if I run 'guix package -i hello', and don't update the config to reflect it... esentially means 'guix package -i' shouldn't really be used if I am correct?
<lfam>No, it doesn't mean that.
<lfam>Package management is per-user. Each user can install their own packages at will.
<lfam>The GuixSD system configuration doesn't control what packages users install.
<lfam>The GuixSD system configuration can be used to make packages available for all users, but that is a different mechanism.
<lfam>If you want to export your own user's list of installed packages, you can create a package manifest, which is described in the manual
<lfam>The config is *never* updated to reflect anything. It's something for a human to edit and then use to build or reconfigure a GuixSD system.
<dadinn>lfam: I thought package management is not per user in the sense that one package gets installed once system-wide and placed in the /guix/store, and different users can link to it differently from their profiles.
<lfam>It's per-user in the sense that users control what software is available to them
<lfam>Unlike, for example Debian, where only the administrator can install or remove packages
<lfam>But yes, packages are deduplicated in /gnu/store
<lfam>Even the list of packages available is per-user
<cehteh>there where some discussion to install packages per groups .. i would really like to have such an official blessing
<cehteh>because not all users want to care for everything
<lfam>If you are interested in the basic model, there are two papers that explain it well.
<lfam>Nix: A Safe and Policy-Free System for Software Deployment, by Eelco Dolstra et al
<dadinn>I gpt thatp I actually use similar concept in my movie/audio/ebook database, I store them in a eachs store folder, and my category folders like byDirectory/byGenre just link to them ;)
<lfam>Functional Package Management with Guix, by Ludovic Courtes
<lfam>Those papers explain the functional package management model, and the 2nd one also explains the improvements made my Guix
<lfam>s/made my/made by/
<lfam>Of course, it's an opinion to call them improvements. But I think so :)
<lfam>cehteh: Yeah, it would be useful for institutional deployments, for sure
<cehteh>even for home installations, i am administrating the computer for my wife for example :D
<lfam>Yes, I was thinking of that too :)
<dadinn>found them articles, gonna read them tomorrow. thx
<cehteh>also on a security note, currently its possible for a user to install binaries which are suid-root? would be nice to have some ways to prevent that
<lfam>Really? Can you give a reproducer?
<cehteh>restriting those then to groups or in the system definition only
<lfam>What package can I use to reproduce that?
<cehteh>that was a question, but cant a user for example guix package -i sudo ?
<lfam>Sure, but does it work? :)
<lfam>A user could even do `cd /gnu/store && echo *sudo*` and then run the binary from there
<lfam>But, it shouldn't work
<cehteh>for what definition of "work"
<lfam>If a user can use Guix to install setuid binaries that allow then to act as root, that's a bug and we need to fix it
<cehteh>i mean yes he is not in sudoers
<lfam>"Can a user escalate their privileges?" is what I mean
<cehteh>well i am a bit careful/anticipatory
<lfam>Did you read the manual on setuid binaries? Seciton 7.2.8
<lfam>If there is an issue, *please* file a bug
<lfam>Or mention it here, or guix-devel, or anywhere we can see it.
<lfam>But ideally, file a bug
<cehteh>ah ok i tihnk that answers my question
<lfam>We should err on the side of caution ā€” if you see what looks like a vulnerability, please report it
<cehteh>i havent it was just some hunch, but seems its addressed
<lfam>Okay, stay on the look-out for more bugs :)
<Apteryx>What could this be caused by: guix build: warning: failed to load '(guix build-aux build-self)'
<Apteryx>Maybe the daemon had crashed?
<Apteryx>My previous error got resolved after I rolled-back to my last generation. This was before I installed git.
<Apteryx>Nevermind what I just said. Happened without git installed too. Maybe my package definition is at fault.
<Apteryx>Arg. I cannot get guix lint nor guix build to run anymore.Here are the errors I see:
<fps>Apteryx: linting other packages works?
<alezost>Apteryx: my guess is: your GUIX_PACKAGE_PATH (or GUILE_LOAD_PATH) contains some directory that it shouldn't
<alezost>Apteryx: try "GUIX_PACKAGE_PATH= guix lint udisks"
<thomasd`>Hi #guix!
<thomasd`>I have a package with (source (local-file "." #:recursive? #t)), and guix complains with "invalid name '.'"
<thomasd`>when I move to a higher directory and make it (source (local-file "./subdir" ...)), it works.
<thomasd`>I believe "." used to work?
<alezost>thomasd`: hm, I recall it worked; anyway I would replace "." with (dirname (current-filename))
<efraim>is this right? /gnu/store/8ar8n9p27cf2r07xk6lnnmgrfq9fl66r-static-binaries-0/bin/egrep: a /gnu/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-bash-4.3.42/bin/bash script, ASCII text executable
<efraim>is egrep in static-binaries supposed to point to /gnu/store/eeee..-bash
<efraim>its the same for the mips one I have (for some reason), so I assume its right
<efraim>gcc-4.7 failing on core-updates has been bothering me for a while, so i'm going to fix it
***Deys_ is now known as Deys
<Digit>;max-bugs=100 makes for interesting reading
<Apteryx>fps: No, linting other packages doesn't work. It was because of my GUIX_PACKAGE_PATH, as Alezost guessed.
<Apteryx>It was set to GUIX_PACKAGE_PATH=/home/maxim/guix-stuff, where I had a folder "my-packages" in there containing the package I'm working on. But the problem started after I decided to git clone the guix repo at /home/maxim/guix-stuff/guix. I guess that wasn't a good idea as it must have created conflicts.
<Apteryx>Thanks for helping, fps and Alezost!
<rekado>since updating to latest master I get an error about the certificate of
<rekado>I suppose I need to set some environment variable...?
<alezost>Apteryx: yes, adding the whole guix repo to GUIX_PACKAGE_PATH is not good: this env should contain only modules with packages: when guix looks for packages, it loads all(!) guile modules from GUIX_PACKAGE_PATH
<rekado>(oh, looks like I don't have gnutls in my Guile path...)
<alezost>Apteryx: so guix tried to load all scheme files from your git checkout including, for example, "guix/build-aux/build-self.scm"
<Apteryx>alezost: I see! Thanks for explaining.
<alezost>rekado: did you install gnutls? I have ~/.guix-profile/share/guile/site/2.0/gnutls.scm here and ",use(gnutls)" works
<alezost>Apteryx: np :-)
<paroneayea> looks like gnome components + rust are looking increasingly likely
<paroneayea>I wonder how that'll affect our packaging
<paroneayea>maybe not much? I dunno?
<paroneayea>I guess if autotools is still used, probably not much
<rekado>alezost: it's a problem with my remote-guix wrapper.
<Apteryx>Is there a way to tell pass an environment variable to the configure script so that it will be used for every makefiles of the project?
<Apteryx>I got the xsltproc command to successfully run using: XML_CATALOG_FILES="/gnu/store/4dsa1sq71020vl8n27fp409ymkvv77c6-docbook-xsl-1.78.1/xml/xsl/docbook-xsl-1.78.1/catalog.xml" xsltproc -path ./.. udisksctl.xml. The only difference is setting the XML_CATALOG_FILES envar.
<Apteryx>So I'm wondering how to coax the gnu build system into using this envar.
<Apteryx>So far I've tried passing it to the configure script, but the build fails in a way that tells me the environment variable was not set when it ran make.
<rekado>Apteryx: you can add a build phase where you run (setenv "XML_CATALOG_FILES" value)
<rekado>Apteryx: but this seems familar. Grep the sources for XML_CATALOG, there's probably another package dealing with this.
<Apteryx>rekado: there is in gnome.scm
<Apteryx>But it's rewriting the and hardcodes it to where it actually lives in the store.
<Apteryx>In my case it seems like setting XML_CATALOG_FILES would be sufficient, since this is only used at build time anyway.
<quigonjinn>I want to mail a package upstream, to ask them to provide a mirror for some software I want to package, because they currently send links by mail. Any recommendation on where to redirect them, to point to the benefits of functional package management for the multiple build variants of their software?
<Apteryx>And I was thinking that if there was support in autotools to just set any envar you want by passing it to the configure script, it would be taken care of without needing any special guix facility :). But it doesn't seem to work like thta.
<htgoebel1>Hi guix,
<htgoebel1>I wonder if we can merge wip-python-build-system anytime soon, since keeping track of all the changed python-packages become more and more laborious
<lfam>htgoebel1: I've been thinking of wip-python-build-system, too.
<lfam>I think we should wait until we finish this core-updates cycle and then rebase or merge wip-python-build-system on top of the new release
<lfam>Otherwise, there will be more than one tricky merge to do. What do you think?
<lfam>Also, if we build the wip-python-build-system branch now, the results will be totally invalidated after core-updates is merged into master, since we are updating the Python interpreters too
<lfam>I'm eager to move forward with it but I don't see an alternative to this schedule. If there is one, I'm happy to hear it :)
<htgoebel1>lfam: This is the way to go. But want to have this finished :-)
<lfam>Me too :)
<htgoebel1>lfam: How long is the core-update cycle supposed to take?
<lfam>Until it's ready :) Basically, we compare core-updates and master on Hydra. Once there are not too many new failures, and we have added all the features we want to add, it's ready.
<lfam>Then someone (civodul) follows the steps in 'doc/' of the maintenance.git repo, and issues a new release.
<lfam>I'd share a link to the Hydra comparison page, but Hydra is not responding to me on port 80 or 443 at the moment (it must be busy)
<lfam>In order to make wip-python-build-system go a little faster, I think we should try building it without any package updates. If that works, we merge it and make a python-updates branch, and do all the updates there. WDYT about that?
<lfam>Otherwise we risk it diverging from core-updates again, and that's a pain
<lfam>The comparison link will look like this, except the jobset ID is probably wrong in this URL:
<efraim>For those emacs and emms users out there, new release
<lfam>htgoebel1: What do you think of Marius's fix for python2-tempest-lib on guix-devel?
<htgoebel1>lfam: mompl
<rekado>Apteryx: you should be able to pass environment variables as make flags.
<Apteryx>rekado: OK! Would this be cleaner than adding a pre-configure phase where all I do is a (setenv) ?
<lfam>Interesting. I can't build libgit2 on btrfs, but it works on ext4.
<rekado>Apteryx: if you can do it with make-flags this would be prettier.
<Apteryx>trying it :)
<htgoebel1>lfam: Re. wip-python-build-system:
<htgoebel1>What do you mean with "building it without any package updates"?
<lfam>htgoebel1: I had thought that we should try updating the core Python packages (setuptools etc) before merging the new build system into master. But I'm worried about that taking a long time to finish
<lfam>But I'm not sure... what do you think?
<lfam>In general, I'd like for these branches to be finished more quickly than we've been doing
<htgoebel1>lefam: Re. python2-tempest-lib: The inputs need to be either propagated or native. Which of both need to be verified in detail. This IMHO is the authors job.
<htgoebel1>lfam: Updating all these "core" packages on the separate branch is okay.
<htgoebel1>But keep in mind that "setuptools" will no longer be a "core" package, since only very few packages required it ā€“ most will use the version bundled in python.
<htgoebel1>Auch, I just discover that we need to verify the case: If setuptools is an additional input, does this package overwrite the one bundled with python? I hope so, but we need to verify this is deterministic.
<efraim>i think i'm the one that added python-tempest-lib
<quigonjinn>is it normal for a program ran in 'guix environment --pure --ad-hoc', not to find the header linux/limits.h?
<lfam>htgoebel1: Re python2-tempest-lib: Can you say that in an email reply? :)
<Apteryx>rekado: Do you know if I can pass multiple paths to the environment variable I am passing to make (using make flags)?
<lfam>htgoebel1: I guess that for the question about overriding setuptools, we will learn the answer when we build wip-python-build-system on Hydra
<Apteryx>I've tried the XML_PACKAGE_PATH="catalog1-path:catalog2-path" way but it doesn't work.
<Apteryx>If I use a single path it registers it correctly.
<lfam>quigonjinn: It depends entirely on the arguments to that command.
<lfam>But what you are doing with that command is creating a new enviroment that unsets *all* environment variables from your normal shell, and only has the argument to --ad-hoc on $PATH
<quigonjinn>lfam: it's a program i'm currently packaging, which uses gcc to compile at runtime.
<lfam>quigonjinn: If your shell initialization files make the mistake of setting environment variables in the interactive shell init scripts (like .bashrc or .zshrc), then --pure won't be able to unset all variables, all bets are off.
<quigonjinn>lfam: they don't make that mistake
<lfam>Okay :)
<lfam>I can't really tell what the issue is without seeing the full `guix environment` command you are using
<lfam>And also without seeing your WIP package
<lfam>But you probably want to add whatever provides limits.h to your environment
<efraim>from `guix import gnu emms': (home-page "htmlxref")
<lfam>Which I believe is the linux-libre kernel headers
<quigonjinn>lfam: i think it's the kernel headers. i'll try that
<lfam>Add that to the arguments to --ad-hoc
<quigonjinn>lfam: right, let me try
<lfam>And I recommend running `env` before and after `guix environment --pure`, to see exactly what it does
<Apteryx>rekado: OK, got my answer: "If you have more than one catalog file, then separate the URIs with spaces in the environment variable" from here:
<jmd>If I understand the grub-configuration correctly, the "device" option must always be the disk which contains the partition on which /boot/grub is mounted.
<sneek>Welcome back jmd, you have 1 message.
<sneek>jmd, civodul says: re nfs, i was trying to see how the set of services is supposed to be used and whether it could export or simply mount NFS trees; IOW, i was looking for an example :-)
<jmd>sneek: later tell civodul I am glad that I am not the only person frustrated by the lack of examples in the Guix manual.
<efraim>only requires.private is propagated?
<efraim>from foo.pc?
<rekado>efraim: at least those
<efraim>does it also need the 'requires' ones?
<rekado>Iā€™m not sure
<efraim>looking at the ones in gnome.scm, i'm pretty sure they don't specifically need to be propagated
<efraim>and at efl in enlightenment.scm
<buenouanq>throughout the day, I'm going to probably be asking some dumb questions as I play with and try to set things up - I hope you'll forgive and bear with me.
<buenouanq>first, why does guixsd ship with the config ~/.guile-wm but not the package guile-wm?
<buenouanq>have nothing but %base-packages and %base-services but this guy still shows up when I make a new user
<efraim>that one I have no clue about
<buenouanq>it has made me aware that guile-wm exists and I plan on using it now if it works
<buenouanq>maybe this was their plan all along
<efraim>does ratpoison use that dir? I think its included by default in some of the configurations
<taylan>efraim: which dir?
<buenouanq>it's a file not a dir
<taylan>ratpoison certainly doesn't use that
<taylan>(it has no relation to guile)
<jmd>Presumably .guile-wm is in the skeleton
<buenouanq>ok, next question
<buenouanq>transmission didn't install it"s gui like it should have
<buenouanq>is this on my end or something in the package?
<efraim>you have to install transmission:gui
<OrangeShark>buenouanq: I believe it a separate output
<buenouanq>oh weird - this is the first I've seen that mentioned
<OrangeShark>packages may have multiple output, you can just specify which one you want like package:output
<buenouanq>I think an important part of how to think about this just came together for me - thank you.
<buenouanq>if I install package:gui is everything in the default (package:out) also installed or do I have to specify both?
<efraim>you have to install both to get both
<buenouanq>is there a package:out,gui syntax or something?
<efraim>you can install both at once with `guix package --install package package:foo'
<buenouanq>if I su to root or another user, no commands can be found
<buenouanq>what is actually going on here?
<Sleep_Walker>what is recommended way to add wpa_supplicant DBUS configuration to system configuration?
<Sleep_Walker>/etc/dbus-1/system-services is symlink to store
<efraim>buenouanq: packages are installed on a per-user case, except for those installed in the system config, which are available to everyone
<buenouanq>shouldn't things like ls and cp be in the %base-packages? and they are, this isn't the issue - it's only when i su that I can't run/find anything
<buenouanq>ssh or logging in normally works fine
<buenouanq>it's like a bizarre PATH issue I can't navigate
<lfam>buenouanq: Are you using su like this? `su root`?
<buenouanq>well, for that I'd just use su by itself
<lfam>You have to use `su --login root`. Check the su man page for the message
<lfam>Sorry, my message was cut off
<buenouanq>oh, interesting
<efraim>fixed the mate packages on core-updates
<lfam>I meant to say, check the su man page for an explanation of how the new shell is set up. Without --login, you get a bunch of bogus entries in $PATH that don't apply to GuixSD, and only apply to other distros by accident
<buenouanq>awesome - thank you lfam
<lfam>I hit the same issue when I first tried a non-FHS distro :)
<buenouanq>I guess I'll just alias su to su --login then
<buenouanq>any potential problems with this?
<efraim>re qjson: I think that was just about the fastest review we've had
<lfam>efraim: I thought it was a simple review, but then I found a comment from myself on a bug report about Qt versions on the qjson bug tracker. I'd already forgotten :p
<efraim>i keep on coming back to it with owncloud-client and dianara
<lfam>buenouanq: It depends on if you always want to get a login shell. It's up to you, really
<buenouanq>if literally nothing can be found/run without it, what could possibly be the use of su then?
<lfam>buenouanq: On distros that use the traditional filesystem hierarchy, I bet most people don't notice this issue, since su's default PATH roughly corresponds to what is expected
<efraim>looking at openstack.scm, that module really needs a smackdown
<lfam>Yeah... it needs some attention
<efraim>another case of "if I knew then what I knew now"
<lfam>Heh :)
<lfam>I wonder about GNU Netcat. No work since 2004 on a program designed to take input from the network...
<efraim>i saw tempest-lib got updated, it also got replaced with just "tempest" (iirc) almost a year ago
<lfam>Looks like a lot of unreleased work has been done on GNU Netcat:
<lfam>efraim: Replaced in our packages, or upstream?
<lfam>Apparently GNU Netcat has code in SVN to support ipv6, written in 2004
<buenouanq>xinit: unable to run server "gnu/store/...xinit-1.3.4/bin/X": No such file or directory
<buenouanq>xinit and xorg-server are both installed
<buenouanq>something I'm missing?
<lfam>Somebody else mentioned that on IRC recently. It needs a bug report!
<buenouanq>well, X is indeed not there
<buenouanq>I've no idea where to look for what it actually might be though
<efraim> I wonder if a bit of substitute* magic can make this work for us
<lfam>buenouanq: No, it would be in the xorg-server store directory instead. But on GuixSD, the supported way to have a graphical system is to add %desktop-services to the (services) field of your GuixSD configuration file and reconfigure the system.
<lfam>Check the manual section 7 for more information about how to configure the system
<lfam>Especially section 7.2
<buenouanq>That's how I have been doing it, but I want less.
<Sleep_Walker>it looks like xinit package needs to be fixed
<lfam>Yes, it does
<buenouanq>The graphic login doesn't work for me.
<lfam>What goes wrong? That should work
<buenouanq>oh, it's just off screen of my primary display
<buenouanq>but moreso, I came to like just logging in to a headless tty and startxing
<buenouanq>maybe it's time to let go of that though
<lfam>I actually like that workflow too. I use it on my main computer (Guix on Debian)
<buenouanq>xfce4-terminal is eating my alt/M
<buenouanq>any ideas? didn't happen on debian
<Sleep_Walker>if it is bash/readline, check this configuration file
<lfam>Superbly annoying to me:
<lfam>A RCE in libxslt, fixed in Google's products but not libxslt for several months
<civodul>lfam: ouch! thanks, Google
<sneek>civodul, you have 1 message.
<sneek>civodul, jmd says: I am glad that I am not the only person frustrated by the lack of examples in the Guix manual.
<lfam>civodul: I guess that everyone has to make a living. It's good that Google buys bugs.
<civodul>sneek: later tell jmd re examples, please consider adding one for NFS: you can choose whether or not to contribute to the lack of examples in the manual :-)
<buenouanq>Sleep_Walker: there isn't any inputrc (neither in ~/ nor /etc/)
<Sleep_Walker>but there can be - either /etc/inputrc or ~/.inputrc - see or
<Sleep_Walker>you can compare it with your debian installation
<Sleep_Walker>C-v M-m will tell you what to look for
<buenouanq>but the whole problem is that M isn't being recognized
<buenouanq>ok, my debian indeed has an /etc/inputrc with stuff in it
<civodul>i realize i have this in ~/.inputrc:
<civodul>set convert-meta off
<civodul>set input-meta on
<civodul>set output-meta on
<civodul>it's been there "forever", i forgot whether/why it's useful
<buenouanq>without it Ms are eaten is seems
<Sleep_Walker>I'm not sure what M-m should do
<Sleep_Walker>I usually map pageup/pagedown for history search
<buenouanq>M-m is undefined in stock emacs
<Sleep_Walker>I thought that you're interested in shell configuration
<Sleep_Walker>are you interested in emacs bindings in terminal?
<buenouanq>well, if my Ms don't get through at all, emacs isn't very usable
<buenouanq>there's the ESC workaround, but
<Sleep_Walker>you mean M as meta
<buenouanq>what else would it be?
<Sleep_Walker>I understood that as M-m
<Sleep_Walker>(in emacs convention)
<buenouanq>no no, what else would I have meant by M, what did you think I was taling about?
<Sleep_Walker>in that case it sounds like terminal configuration problem
<Sleep_Walker>I assume you have set $TERM to xterm in your xfce4-terminal, right?
<Sleep_Walker>(this is really absurd, as there are programs imitating behavior of other programs which are emulating hardware which is not available for decades)
<Sleep_Walker>buenouanq: disable menu hotkeys in xfce4-terminal configuration
<Sleep_Walker>Edit -> Preferences -> Advanced -> Disable all menu access keys
<buenouanq>done that
<Sleep_Walker>it did not help?