<kete>Does something like console-keymap-service need a root reconfigure or a regular user system build?
<brendyn>/gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/sh: /bin/sh: No such file or directory
<brendyn>I get this error during tests despite it existing
<kete>I ran as root and it appears to be updating packages.
<kete>It doesn't help the login or typing password for /home partition. It only works on the *consoles* which is what I hoped would not be the limit. I remember configuring login managers through their settings, so I'll look for those.
<ng0>yes. because that's the sad limitation of slim (the login manager we currently have)
<darkpsi>yeah i am downloading the guixsd 0.11 will take some time as my connection is not great.about 20 mins
<kete`>sneek: later tell jmd: Yes, Gnome doesn't provide a logout button, but I found out how to log out by running gnome-session-quit. lfam also showed me https://bugs.gnu.org/23193 to make a logout button appear.
<ng0>hm... if i need to insert a new commit before a commit I did, do I use interactive rebase? I imagine select commit before my commit to edit, commit that change, do some change git add + git commit, git rebase continue?
<rekado>(In my opinion we should hide the "gcc" packages in the UI.)
<civodul>rekado: why not; we could easily hide it, with 'hidden-package'
<snape>rekado: in my case, I have to use a very specific ARM toolchain
<ng0>okay, we can package it. this license issue exists when you build dulwich with tests enabled. I'll comment it and inform upstream about it.. first kallithea a d if they refer me to dulwich i'll report it there etc
<joshuaBPMan_>hello, I am dual booting guixSD and Parabola. For about a week guixSD was working stellarly. I was running gnome just fine. Then a week ago or so, I could no longer properly log into gnome or any other desktop environment or window manager
<joshuaBPMan_>I am getting seeing this error in X's logs when I try to log into gnome on guixSD
<joshuaBPMan_>libinput bug: bcm5974: Internal or external? Please file a bug.
<joshuaBPMan_>I believe that my Parabola install is using libinput too, so I'm not sure what the issue is.
<joshuaBPMan_>I've also tried booting guixSD into the older configurations, but I'm still not able to log in.
<ng0>for one, i am too used to look at the source and not at pypi, so i did not see the missing license part which are stated in pypi. for the rest I really don't know at the moment where this setuptools extension bug comes from
<darkpsi>i am setting guix up with full disk encryption and so i have put "/dev/mapper/root" as the device and the type as ext4 but it keeps saying at the grub installation stage 'lvm/root' not found despite my system not using lvm and lvm not being referred to in the config
<sankey1>is there a good way to determine which substitute keys are already authorized?
<ksjogo>Another thing: Is it possible to let guix system reconfigure generate the grub.cfg but not run the grub-install? I have a grub installed by Ubuntu and just added a link to the guix grub.cfg. At the moment I just changed the install.scm, but that is not that nice.
<mark_weaver>janneke: also, if you create a /usr/bin/env on your system, then there's a good chance that at some point, you'll contribute to guix a package that works for you and fails for others.
<mark_weaver>janneke: in most cases, software installed by guix should refer to other software by absolute file name directly into /gnu/store, rather than searching for programs in PATH, so /usr/bin/env doesn't do what we need.
<efraim>then I saw the cython-something in the download
<rekado>lfam: do you happen to know if the full documentation can be built, too?
<lfam>efraim: I did not realize there were generated files
<rekado>the man page has a very different format from the HTML docs.
<mark_weaver>jmd: there are two ways we could handle that: (1) we could search for mount.nfs in PATH in that case, or (2) make the package containing mount.nfs an input to util-linux, and the mount-nfs package would take as input a modified 'util-linux' package that removes the nfs package from its inputs.
<efraim>i should search through python.scm, i'm sure there are more that we haven't noticed before
<mark_weaver>we use approach (2) to handle the circular dependency between cairo and poppler.
<lfam>rekado: I don't know. I haven't tried to build any documentation beyond what the package does now
<mark_weaver>jmd: see the "cairo" input to poppler in gnu/packages/pdf.scm line 83
<jmd>mark_weaver: I thought about both of those. (1) for reasons you just mentioned, is undesireable. (2) would work, But how would guix package -i know which util-linux to install?
<jmd>mark_weaver: But, in fact, the same problem exists with mount.fuse
<mark_weaver>jmd: if adding 'nfs-utils' doesn't increase the closure size of 'util-linux' by much, then it's probably fine.
<rekado>lfam: this works: LANG=iso-8859-1 man borg
<rekado>it’s the conversion to en_US.UTF-8 that fails.
<mark_weaver>jmd: it's possible that this is a case where we should be looking in PATH, dunno.
<ng0>yeah... i know. i won't fix that one. I've tried to contribute and I don't want to. there have been discussions outside of logged/public history which make me question decisions peter surda decides on...
<rekado>currently, they are practising this whole email-based workflow by sending patches for our custom Guix repo. Eventually, I’ll upstream the packages.
<ng0>I'm looking to update ghc to 8.0.1, ran into problems there too.. packging darcs was my first contact with haskell i think. it's on my gitlab mirror archive, or should be, if someone is interested in the wip
<ng0>I'll also update the ghc darcs patchset one more time as i discovered that i packaged something which is part of ghc itself. I'd be interested in what the expectation of ghc/haskell users is.. multiple versions available, 7+8? or just one version?
<rekado>Haskellers usually upgrade immediately, but whether it makes sense to keep older versions around depends entirely on compatibility.
<efraim>we build gst-plugins-base without opus support
<mark_weaver>it's not good that we use the suffix "/fixed" in package variable names for two very different purposes: (1) for packages that have had some fix applied, e.g. security fixes, and (2) for packages that are keep unchanged.
<mark_weaver>I'm currently working on security updates for flex, and have need for both of these categories. if I follow our conventions, it's going to be very confusing.
<mark_weaver>it turns out that most packages that use 'flex' can be updated without many rebuilds, so I want to create a 'flex/fixed' that *doesn't* have the security update, which will be used by the few packages that need flex and would force too many rebuilds.
<lfam>What do you think we should call packages that have security updates applied?
<mark_weaver>but then I also want, in the same patch, to create replacements for packages that use 'flex/fixed', to graft in variants that use the updated 'flex'.
<mark_weaver>so, I'll end up with packages like 'linux-pam/fixed' that distinguish themselves by using 'flex' instead of 'flex/fixed' (the unfixed one :)
<ng0>i need to beat this going back and forth between wip's.. if I am convinced that a service works, but I can't test it *fully* because the VM I use for testing is readonly, is a 99% 'it works' enough for sending it in for QA review?
<mark_weaver>ng0: can you try using the service on your bare-metal machine?
<mark_weaver>how can you be convinced that a service works if you haven't tested it?
<mark_weaver>Testing a service on a completely read-only system does not lead to 99% confidence that it will work properly.
<ng0>being exposed to and working with the software for a rather long time.. I am convinced that it works in theory, I know what I need to fix and what needs to be applied. I have tested it, but the real test requires write access to receive a file. i can not test on bare-metal because I have not set up my guixsd systems like that
<mark_weaver>many of the most common potential problems with services would only show up when the service tries to write something.
<ng0>my 99% can also be seen as the 80% where you work on the last 20% for a long time... I'm 99% finished with gnunet suite on gentoo for a long time now. I'll never say 100%.
<mark_weaver>e.g. sometimes software is built without --localstatedir=/var, or for some other reason ends up trying to mutate data in /gnu/store/*, and so it can't write to the places it expects to be able save data to. testing on a read-only VM would not discover those common problems.
<ng0>is there some guide to either a rw VM (I have tried changing the qemu and appending settings, nothing worked) or running a system from a checkout without damaging the core system?
<lfam>ng0: You can use `guix system vm-image`. Once the VM is built, you need to copy it out of /gnu/store and change the permission to make it writeable
<mark_weaver>ng0: I run all of my GuixSD systems from git checkouts. I can be relatively fearless about reconfiguring new systems that might or might not work, because I can always choose an older system from the GRUB menu.
<ng0>doesn't work for me. building vm-image makes some part of my disk run out of space
<brendyn>So I think I am too dumb to understand the manual. How can I make it so that I'm using guix package definitions from my git repo and things like M-. and C . b actually work?
<mark_weaver>brendyn: my preferred approach is to make ~/.config/guix/latest a symlink to the top directory of the (built) git checkout.
<brendyn>mark_weaver: Does that also work for using guix it's self from git?
<brendyn>And do I need to build it from a different working directory?
<brendyn>What I don't understand is that guile is supposed to be able to do development with REPL so there can be incremental changes but so far I've never figured out how to actually do that with guix, I just save files then run guix build to test changes
<mark_weaver>brendyn: I'm not sure I understand your questions, but the normal 'guix' command will look for an updated version of guix in ~/.config/guix/latest and use that if it exists. that's the symlink that's updated by 'guix pull', so if you point that symlink to your git checkout, you should avoid using 'guix pull' in order to leave the symlink intact.
<brendyn>Oh ok. Currently when I run M-. t takes me to a Scheme file in /gnu/store
<mark_weaver>if you make that symlink, you won't need to prefix commands with ./pre-inst-env either
<mark_weaver>brendyn: presumably M-. brings you to the definitions that are actually used by guix, and that will normally be something in /gnu/store
<mark_weaver>or at least I thought it was unfortunate. I think I wanted that for the kernel packages at some point, although I've forgotten why. maybe as a way to pass in desired kernel configuration options, or something
<lfam>brendyn: Mailing lists for packages and security updates (debian-security-announce and oss-sec), GitHub tag feeds in my web browser, hang out in the upstream IRC channels
<brendyn>I probably shouldn't be packaging anything where security matters.
<lfam>brendyn: That's what peer review on guix-devel is for :)
<brendyn>Actually, I started packaging an update to duplicity, so I may end up destroying some backups in the near future, Muahahaha
<ng0>I just follow what I package in email/irc/websites/otherwise or am involved .. there are also security related mailing lists, but the main ones get so much traffic that I just follow via web browser for now
<lfam>brendyn: BTW, it's not so far-fetched to say that security matters for *every* package.
<brendyn>lfam: When should I add my name to the copyright notice on a file?
<lfam>brendyn: When you feel you've made a significant contribution. I basically never ask a submitter to remove a copyright line they have added. I'm sure there are some guidelines if there are disagreements about this.
<brendyn>Yeah, it's just in practice, code in the wild is suprisingly friendly (unless it's a .exe file)
<ng0>gentoo has a project which follows the main security announcement and cve lists... sometimes it helps
<lfam>brendyn: That's what we _think_, but how can we know?
<ng0>0days are being used and sold brendyn.. there are also bug hunters of all kinds, either interested in fixing and receiving payment or selling to the democracy destroyers of all kinds..
<brendyn>lfam: Yes, of security exploits that exist. But what are the chances that we've actually had our home directories scanned by some invasion looking for credit card details or something like that
<lfam>brendyn: There is an endless stream of remote code execution bugs being disclosed as a result of cutting-edge fuzzing technology.