IRC channel logs


back to list of logs

<mark_weaver>suitsmeveryfine: yes, I believe so
<suitsmeveryfine>mark_weaver: you were right about the encrypted /home issue. Now I can see more of the boot process and when to input the LUKS password. Thanks again!
<mark_weaver>suitsmeveryfine: I'm glad to hear it! :)
<suitsmeveryfine>I'd like to add a service that runs as root but reading the manual doesn't make me understand unfortunately.
<davexunit>suitsmeveryfine: then I recommend reading the source code for the services in gnu/services
<suitsmeveryfine>davexunit: ok, I'll have a look!
<davexunit>the services will be run as root since PID 1 is running as root
<davexunit>sometimes the program you are writing for a service for will handle dropping privileges as necessary, sometimes you have to do it yourself
<suitsmeveryfine>davexunit: will I need to have the system configured from a git checkout?
<suitsmeveryfine>I'm not talking about adding a not-yet-existing package
<davexunit>suitsmeveryfine: but you are talking about adding a not-yet-existing service
<davexunit>which will require hacking guix itself if you want to submit it upstream
<davexunit>you can also just hack away in your system config source file
<suitsmeveryfine>I'd like to contribute if I can, but maybe this service is so simple that it's easiest to just add it directly to the OS config.
<suitsmeveryfine>The only thing I do right now is to run `sudo thinkfan`. What do you think?
<davexunit>suitsmeveryfine: for now, try to implement it in your config and see where that gets you and share it when it works
<davexunit>note that sudo will not be necessary
<davexunit>the init system is already running with root priviliges
<suitsmeveryfine>yes of course
<suitsmeveryfine>I just wanted to show how easy it is to just run the program from inside the system, post-init
<suitsmeveryfine>other services seem much more complicated
<suitsmeveryfine>I'll look at some of the other services and then try. thanks
<davexunit>is thinkfan a daemon?
<suitsmeveryfine>it requires setting a linux flag also, which I've done in the OS config
<suitsmeveryfine>(for unlocking the fan controls)
<davexunit>that is something that could be moved into the service
<davexunit>once you get the basics
<suitsmeveryfine>I see
<davexunit>so this service would extend the shepherd service
<suitsmeveryfine>But a problem here is that there are no real defaults in this program
<davexunit>and it could also extend the activation-service-type as well to do the kernel settings
<suitsmeveryfine>It's hardware dependent and the user must be very careful when modifying the thinkfan configuration file
<davexunit>suitsmeveryfine: a good thinkfan service would handle all of that
<davexunit>or just let the user provide the config file
<suitsmeveryfine>the program is meant to be used like this: copy either thinkfan.simple.conf or thinkfan.complex.conf into /etc/thinkfan.conf and then modify according to your specific computer model
<davexunit>so it could also extend the etc-service
<suitsmeveryfine>the conf file could be put elsewhere also but then thinkfan must be told explicitly where to look for it
<suitsmeveryfine>davexunit: this is the systemd service file for thinkfan which came with the guix package (for some reason):
<lfam>mark_weaver: I pushed the libxml2 update to Savannah
<civodul>Hello Guix!
***kelsoo2 is now known as kelsoo
***kelsoo2 is now known as kelsoo
<rekado_>is it normal to experience problems when using PAM from Guix with a PAM installation on a foreign distro?
<rekado_>I'm trying to run my new rstudio server application on CentOS and authentication is performed via PAM.
<rekado_>I get a not so helpful error message upon attempting authentication: pam_authenticate failed: Error in service module
<rekado_>I wonder if this could be caused by using PAM from Guix with PAM on CentOS.
<efraim>I would assume so
<rekado_>this would be pretty bad as it limits the amount of software that can run via Guix on a foreign distro.
<efraim>on a similar vein, although I've not done any debugging, I started running into sound issues on my laptop after I installed mpv from guix (pulse from debian and from guix)
<efraim>what if you installed pam into your profile and edited .guix-profile/etc/pam/something.conf to have it talk to /etc/pam/something from CentOS?
<rekado_>I don't know how this would help
<rekado_>The application uses the Guix PAM.
<rekado_>which seems to read configuration files from /etc/pam.d
<rekado_>in there I've got a file for rstudio, which tells it to load up a couple of modules
<rekado_>I would expect it to fail if it loaded up CentOS modules
<rekado_>not sure what modules it really loads -- the one from Guix?
<efraim>I assume the guix application would call guix's pam module
<rekado_>in that case things really should be okay.
<rekado_>I think the problem in this case is that users are authenticated via sssd, but our pam package does not provide the modules needed for sssd authentication.
<civodul>rekado_: i think PAM modules are .so that get loaded into the process
<civodul>thus things could easily go wrong
<civodul>NSS has a similar problem, except that using nscd basically solves it
<civodul>to check this hypothesis, you should strace the thing that segfaults
<rekado_>there is no segfault. Looks like it's loading Guix pam modules as it should, but this means that the authentication defaults on this system simply fail as the required modules cannot be found.
<rekado_>(as they are not available in the Guix pam)
<rekado_>so I need to try to replicate authentication against ldap without the sssd modules
<rekado_>...or try to hack around with LD_PRELOAD to use the system pam for everything, or use a pam helper that was linked with the system's pam.
<rekado_>so far ABI mismatch is the biggest inconvenience of using Guix on a foreign distro.
<rekado_>I wonder if there's something we can do about this.
<rekado_>looks like it's beyond our means
<ng0>whoever is working on torbrowser for guix, 6.0 was released yesterday which is based on firefox 45.1.1esr .. I started to work on it for gentoo, maybe it turns out to just work and not need the load of patches the 38.0esr needed
<efraim>does it get patched over time with the patches firefox-esr gets?
<ng0>Ihave to look at it myself. torbrowser ships patches. gentoo provided patches too and then we also sourced another bunch of patches. if you take the vanilla torbrowser only from torproject itself there is no problem
<ng0>as torbrowser tracks esr, it gets the patches esr gets
<ng0>ACTION afk for a while
<rekado_>overriding the pam helper with one compiled on centos seems to work better.
<ng0>my website is now git push to publish and run Makefile to compile based... maybe this could be simplified with guile web.
<rekado_>ng0: I use haunt. I compile the static pages locally and sync the generated stuff to the server.
<ng0>I use an altered system of what uses
<ng0>involving markdown and html mixture
<ng0>it compiles on the server when I have pushed
<rekado_>I like to keep as little as possible on the server, so I only ever copy the compiled artifacts.
<ng0>possibly i should strip the /static/pub/ from it
<ng0>no one cloning the www wants to have all the pub data
<ng0>i'm subscribed to the oss-security list.. should I forward to guix-devel when I notice a package we have, or just directly submit the fixes? I'm still temporarily without guix or guixsd, but I'll either get a new machine for it or use the desktop computer.. or vm..
<civodul>rekado_: re ABI mismatch, i think there's nothing we can do
<ng0>longterm what I plan for guixsd I need an extra laptop.. or more than 1.. concetration on other things
<civodul>rekado_: but there aren't so many problematic cases AFAIK (anything apart from NSS and PAM?)
<civodul>fun: nix-daemon has removed the substituter mechanism, which is now built in the C++ code base
<rekado_>we have similar issues (but less severe) with languages such as R or Python that cannot load modules with native parts linked to system libs.
<rekado_>mixing R libs is fine as long as no native components are involved.
<rekado_>this means that using Guix R one cannot use the "install.packages()" mechanism as these libs could just crash.
<rekado_>due to ABI mismatch.
<rekado_>to avoid this one would have to also override the compiler toolchain and so far that's not working so well in Guix.
<rekado_>we have a working C and C++ compiler toolchain, and fortran might also work.
<rekado_>but anyway, this requires more effort than just packaging everything with Guix.
<rekado_>In my workshop I told people not to mix libs and use Guix for everything if possible.
<civodul>rekado_: for R, i think users should use all the packages from Guix
<civodul>mixing stuff doesn't seem advisable in general
<rekado_>yes, that's how we do things here.
<civodul>but yeah, there are other problems like gfortran
<civodul>ACTION pushes a bunch of nix-daemon backports
<jlicht>How does guix calculate sha256 for directories?
<civodul>jlicht: it's the hash of the "nar" serialization of the directory
<civodul>where "nar" (Nix archive) is an archive format as manipulated by 'guix archive'
<civodul>however, you shouldn't have to worry about how it's computed :-)
<jlicht>Let me rephrase in that case: How can I let guix calculate the sha256 of a git checkout, with the .git folder removed? I'm trying to extend `guix download` with git support to make npm-import somehow usable
<jlicht>civodul: but thanks anyways for the proper explanation :-)
<civodul>jlicht: git clone foo && rm -rf foo/.git && guix hash -r foo
<jlicht>civodul: perfect! thank you. I just had a look at how the guix hash command implements recursive checks, and it is actually quite an elegant solution
<civodul>did you find anything inelegant in this project? :-)
<jlicht>well, the current way of packaging something which is only available in a git repo, but that is also why I'd like guix download to just work :-)
<civodul>good point :-)
<civodul>so like "guix download git://foobar cabba9e"?
<jlicht>I am currently looking at url fragments
<jlicht>guix download git://goobar#commit-or-tag-here
<davexunit>civodul: I was once going to implement git support for 'guix download' but stopped because it wasn't clear what the UX should be
<davexunit>like maybe 'guix download <url>' will assume HTTP download, but there could be other subcommands like 'guix download git'
<civodul>davexunit: good point, i'm not sure
<jlicht>davexunit: I did not yet have a look at that possibility. currently, there is a case statement switching on the uri scheme (ie, ftp, git, https), which is what I decided to extend
<civodul>maybe subcommands would be nice
<civodul>or a --method flag
<davexunit>yeah I toyed with something like --method
<davexunit>switching based on url scheme is clearly inadequate
<davexunit>is that a http download or git download? what commit should be used?
<davexunit>a heuristic that treats anything with .git at the end as a git repo would work OK, but I don't ambiguity where it doesn't need to exist.
<civodul>yeah, an additional know is needed
<davexunit>I don't like*
<civodul>so we could have --method and have it default to 'url-fetch'
<davexunit>civodul: and what about extra information like the commit SHA?
<davexunit>additional positional arguments?
<civodul>as extra arguments
<davexunit>that works for me
<civodul>the method handler would be passed a list of arguments
<civodul>ACTION will happily wait for a patch ;-)
<davexunit>jlicht is going to write it, right? :)
<civodul>could be ;-)
<jlicht>davexunit: I'd love to, but first I'd like to continue some work on the importer. So it would be weekend work then ;-)
<jlicht>I really needed any kind of git support, because an importer that could not take care of hashes was making me very grumpy very quickly
<davexunit>jlicht: for now you could make a git repo hashing procedure that is only used in your importer
<davexunit>that would be pretty easy
<davexunit>and then it could be hooked up to the 'guix download' CLI later
<jlicht>davexunit: I have the scheme (ie, based on uri scheme, and using fragments for commits/tags) working as of now. And I just verified it to actually do the right thing
<davexunit>jlicht: great!
<jlicht>and it actually turned out to be just a simple calll to git-fetch in (guix build git), the hash calculation logic from (guix scripts hash) and of course some plumbing in-between to make it work with guix download
<civodul>jlicht: you could do something akin to 'download-to-store', but using 'git-fetch' instead of 'url-fetch'
<jlicht>civodul: exactly what I did. Then I needed to change some things, as guix download expected to deal with a single file everywhere.
<jlicht> ... although I just thought about the `(setenv "GIT_SSL_NO_VERIFY" "true")` in git-fetch. This is an issue, as we do not know the hash yet.
<civodul>yes, but again, authenticating the Git server does not help
<civodul>it's the code that needs to be authenticated
<civodul>well, if you trust GitHub Inc, authenticating still helps
<adfeno>ACTION doesn't trust
<efraim>I'm about a half-hour late, but I haven't given up yet on building a torrent-download option
<jlicht>efraim: that sounds interesting. Would you use an external torrent client, or write one in guile?
<efraim>I was planning on using aria2 for the actual downloading, but it'd be nice to have one in guile
<lfam>ssh: connect to host port 22: No route to host
<civodul>oh, again?
<lfam>Maybe it's just a transient error. I'll wait a short while before alerting them
<lfam>http pulling works
<efraim>I added .tgz to the github updater, fixed the backtrace I was getting
<lfam>Can an upstream source distribution be distributed under the lgpl2.0 but contain some gpl (no version specified) components?
<adfeno>lfam: I guess distributions are "aggregations" under the GPL.
<adfeno>See the latest version of the GPL and the FAQ regarding the licenses.
<adfeno>Optionally, I'm uder a similar situation... And I have emailled the people related to answering licensing questions. I'm still waiting for the answer. Although I'll probably email them again (just in case that the email got lost in transit).
<emyles>Hmmm, why can't I uninstall uwsgi?:
<emyles>$ guix package --list-installed
<emyles>$ guix package -r uwsgi
<emyles>nothing to be done
<mark_weaver>emyles: guix package -r uwsgi:python
<mark_weaver>it's the "python" output of that package that's installed. third column of the --list-installed output
<mark_weaver>in the absense of an explicit output in the package specification, "out" is assumed
<emyles>mark_weaver: ok, thanks for explaining, I see it is also in the info under 'Packages with Multiple Outputs'
<lfam>After the recent announcement of the popen() file-name vulnerability in graphicsmagick, I "ported" the fix to imagemagick locally just to see if it would work. Now, I see that they have suggested a very similar solution to my own on their forums:
<lfam>They also have a more complete mitigation in their Git repo:
<lfam>So, any opinion on whether I should cherry-pick their Git commits or instead use the one-liner suggested on the forum?
<janneke>is npm install supposed to work -- latest master
<janneke>ACTION is getting Error: Cannot find module 'npmlog'
<davexunit>janneke: it seems to have been broken with the upgrade to node 6
<janneke>davexunit: good to know it's not me!
<davexunit>so that's my bad. if anyone knows how to fix... would love help
<janneke>davexunit: i'm trying to bump node to 6.2.0 -- that may work
<janneke>of course, it would be nice to never use npm...I haven't looked into that. are we packaging node packages yet?
<davexunit>janneke: no, that's what jlicht is working on. long story short: it's quite complicated.
<janneke>i can imagine. good to know, thanks davexunit
<davexunit>the npm logo is official logo of "dependency hell"
<janneke>exactly why my comment above ;-)
<emyles>Is there a way to find out which package owns a file in the store?
<emyles>actually the 'orphan' file is 'owned' by a generation of my profile
<lfam>Can you be more specific?
<lfam>emyles ^
<mark_weaver>emyles: it's simple. the only files owned by a package in the store are in a directory /gnu/store/*-<package-name>-<version>[-<output>]
<mark_weaver>profiles are composed of symlinks to those files
<mark_weaver>so, e.g. if you want to know which package contains the "ls" program, try: ls -l $(which ls)
<mark_weaver>or if you want to know which package contains ~/.guix-profile/lib/libgcrypt*, just ls -l it
<mark_weaver>it will be a symlink
<mark_weaver>(although it should be noted that if there's an entire directory in a profile that contains only files from a single package, then the directory itself is made a symlink instead of the individual files)
<mark_weaver>(the symlinks are made as high up in the directory tree as possible)
<efraim>my first thought when I learned how it worked was "its like stow! but for everything!"
<jlicht>janneke, davexunit: I had a cursory glance at this issue: it seems that our build of npm 6.0 installs a _copy_ of the npm script in `/gnu/store/abcabd-node-6.0/bin/npm`, whereas in 5.10 and earlier, this script is a symlink to the npm script at /gnu/store/abcabd-node-5.10/lib/node_modules/npm/bin/npm-cli.js
<jlicht>I checked, and this npm-cli.js script does indeed work with node 6
<janneke>jlicht: that helps, thanks
<janneke>guix environment gives an opaque error message
<janneke>I/O error : Permission denied
<janneke>Failed to write XML file; For permission problems, try rerunning as root
<jlicht>janneke: seeing it as well, also on any package installation
<janneke>jlicht: thanks...I'm reverting to 0.10.0
<davexunit>janneke: why?
<davexunit>just grab the old node package recipe
<janneke>oh,node is going fine now, thanks
<davexunit>going back to 0.10.0 means exposing yourself to a lot of unpatched security vulnerabilities
<efraim>or the old tarball and use --with-source
<janneke>guix environment does not work for me
<janneke>davexunit: 0.10.0 seemed my best guess for stable, what commit/tag could you recommend?
<davexunit>I recommend nothing less than the latest master
<davexunit>just grab the old node
<janneke>davexunit: node is fine, `guix environment' does not work for me
<davexunit>janneke: could you maybe provide some details?
<janneke>I/O error : Permission denied
<janneke><janneke> Failed to write XML file; For permission problems, try rerunning as
<janneke> root
<davexunit>that error doesn't make any sense
<davexunit>guix doesn't output any such mentions or write to XML files
<davexunit>what is the exact command that you are running?
<janneke>guix environment -L release/ dezyne-server --ad-hoc ccache coreutils git guix emacs
<jlicht>janneke: I get that message as well when installing any package
<emyles>mark_weaver: thanks that is helpful, I was having trouble understanding that I had only removed the package from my profile but it is still in the store
<janneke>davexunit: now I tried: guix environment guile
<davexunit>does this happen when grafting or something?
<janneke>I get no error, but also no new PATH setting
<davexunit>janneke: what is the output of 'guix environment --search-paths guile'
<davexunit>I ran 'guix environment --ad-hoc ccache coreutils git guix emacs' without any problems
<janneke>davexunit: and your PATH gets updated?
<janneke>ACTION is running --search paths now
<davexunit>janneke: you probably have some bad stuff in .bashrc
<janneke>davexunit: oh, that must be it...damn
<davexunit>that's almost always the problem people have
<davexunit>they use 'export' in .bashrc
<davexunit>'export' should only be used in .bash_profile
<janneke>yes, I'm doing that -- I seem to need that in Debian, cannot remember
<jlicht>davexunit: the Internet is littered with bad advice then :O
<janneke>I removed it and something broke, I'll have to check (or not; I'm trying to switch to GuixSD again right now)
<jlicht>in general, of course, but about this specific bashrc thing then ;-)
<lumidragon>Hi all, I have a ruby package with the mit license. Is that license accepted and if so how should proceed?
<janneke>davexunit: sure enough, --search-paths list a new profile, *thanks*
<davexunit>jlicht: yup, it is.
<davexunit>janneke: np
<davexunit>lumidragon: "MIT license" is ambiguous because MIT publishes software under many licenses. usually people mean the Expat license.
<davexunit>and that license corresponds to the "expat" variable in (guix licenses)
<lumidragon>so any MIT packages can have the expat as the license setting then?
<lumidragon>davexunit: I know I looked at that file, but didn't see anything for MIT which is why I ended up here.
<emyles>Does anyone have uwsgi working with python? I am getting "no app loaded" and the advice is to 'not use the distribution package'
<davexunit>lumidragon: *usually* it means the Expat license, but sometimes it also means the X11 license, which is why saying "MIT license" is ambiguous and should be avoided.
<lumidragon>ah kk, you learn something new each day :)
<lumidragon>will need to remember that.
<davexunit>lumidragon: being pretty familiar with Ruby, I am guessing that it's the Expat license. it's very easy to verify if you read the license text and compare it to the original expat license.
<lumidragon>oh kk
<efraim>"For convenience the tarballs contain both the Cython sources and generated intermediary C sources, meaning you do not need Cython to compile the bindings.
<efraim>Full cython sources are also publicly accessible from our git repository at:" means we should be building the "intermediary C sources", right?
<davexunit>efraim: yes
<efraim>yeah thats what I thought
<davexunit>for "convenience", they make us do extra work ;)
<efraim>looks like I'll be fixing the python-efl packages soon
<lumidragon>I'm thinking about making some packages with clojure, as this language is hosted on the jvm I'm wondering if these should be built from source too?
<lumidragon>just a general question, don't want to start a java war or anything.
<davexunit>lumidragon: absolutely they should.
<lumidragon>okay, cause know Java peeps tend to worship jars. So wasn't sure what the Guix stance on that was.
<davexunit>it's an ongoing problem to figure out how to deal with java
<davexunit>since there's so much binary bundling going on
<lumidragon>I know.
<civodul>nginx issue:
<lumidragon>I already started looking a clojure and it's thw saem thing :(
<emyles>ACTION wondering what C-c C-d does
<rekado_>lumidragon: we build all jars from source.
<lumidragon>at least with clojure (since it's lisp) I may be able to generate a clojure build script to get things going. To replace the project.clj.
<rekado_>lumidragon: we have an ant-build-system that I'm using to package the dependencies of maven.
<davexunit>lumidragon: we probably need some sort of clojure-specific build system to be created
<lumidragon>hmmm could prb use that to build the clojure compiler.
<rekado_>I still have a couple of Java packages that haven't been pushed yet.
<rekado_>there's still a lot to be done.
<lumidragon>kk when I get rails out of way, I'll be dropping my questions here.
<lumidragon>cause I was thinking about a clojure build system too, just not sure how to approach that though.
<davexunit>civodul: I really enjoyed your recent patch to call-with-container that sent exceptions within the container back to the parent process.
<efraim>i'm building nginx-1.10.1 now
<davexunit>at work the nginx we deploy comes bundled with a piece of software called Passenger, so I guess we depend on Passenger to provide nginx security patches
<civodul>davexunit: ah, thanks!
<civodul>davexunit: i didn't send it to the ML, hope that's fine
<civodul>that bug had been sitting there, and i thought this must be the only way to fix it ;-)
<civodul>efraim: thanks for picking it up, super fast service :-)
<davexunit>civodul: I appreciate you fixing it!
<davexunit>I've been neglecting the container stuff lately... mostly just packaging software that helps me at the day job.
<civodul>oh, new EMMS release! \\o/
<davexunit>heh, was just about to check if we had a package for that
<davexunit>I'm packaging up all of the elisp packages I use from MELPA and finally going full-Guix
<efraim>too late on emms, I already got that one too
<davexunit>got 6 new things to submit
<lumidragon>hey save some emacs packing for new peps lol.
<davexunit>emacs packaging is pretty simple, which is a welcome relief.
<civodul>efraim: wonderful :-)
<davexunit>most packages have no dependencies
<efraim>`guix refresh -u emms' isn't too hard :)
<davexunit>breath of fresh air compared to what I am used to
<lumidragon>I barely got helm in before I had to rebase because of the changes :)
<civodul>reviews are lagging ;-)
<davexunit>I don't review nearly as much as I should
<lumidragon>speaking of emacs, is the color-theme packge supposed to come with? or is that something I should package?
<ijp>surely color-theme is best forgotten?
<lumidragon>so it's not needed to load themes then?
<civodul>themes are built-in, no?
<ijp>modern themes don't use it
<lumidragon>hmm kk, I'll modify my config later and see how it goes.
<lumidragon>just I had and error with (require 'color-theme) on guix emacs, so was wondering.
<ijp>but yeah, color-theme was never built in
<lumidragon>the things I take for granted on Debian :)
<Sleep_Walker>OK, first signed commit pushed
<Sleep_Walker>btw. it was interesting reading getting to know which part of the commit is actually signed
<Sleep_Walker>did you decide some keyring for GPG keys?
<civodul>Sleep_Walker: not yet, this requires some thought
<Sleep_Walker>and do you want to review even update commits like ?
<rekado_>Sleep_Walker: often we push update commits directly. When it builds fine, doesn't break any dependent package, and doesn't cause a rebuild of too many packages.
<civodul>yeah, check 'guix refresh -l the-package' and the 'HACKING' file :-)
<janneke>i'm trying to replace a `guix enviroment' with a named profile
<janneke>guix package --profile=.profile --manifest=/gnu/store/85iz08xcbi3wndrckzaqsvprvbc6l08n-profile/manifest
<janneke>/gnu/store/85iz08xcbi3wndrckzaqsvprvbc6l08n-profile/manifest:1:0: error: Wrong number of arguments
<janneke>but i don't even know how to interpret the error message
<davexunit>janneke: that manifest file is wrong
<davexunit>it must be a scheme file that evaluates to a list of packages
<civodul> :-)
<davexunit>the error message is terrible here, though
<civodul>the option name is slightly misleading too
<civodul>but people aren't supposed to know about this 'manifest' file
<janneke>that manifest file I found seemed to be just what I needed..hmm
<lfam>So many patches to review...
<lfam>And only from the last few days...
<lumidragon>afaid I'm gonna be adding more the pile.
<lfam>Okay, please make sure to run `guix lint` on every package addition or update :)
<lfam>I think many submitters have not been doing this :)
<lumidragon>I know my last ones where guilty of that :)
<lumidragon>I was so excited about getting rails in I forgot :)
<lumidragon>just updated helm with the output from lint :)
<lumidragon>I'll try to remember in future though.
<civodul>heh :-)
<Sleep_Walker>does anyone have success with running UPower?
<civodul>it's part of %desktop-services, so many/most run it
<civodul>is it not working as expected?
<Sleep_Walker>%desktop-service, unexpected innovation :)
<Sleep_Walker>I'm still with %base-services
<Sleep_Walker>I'll reconfigure and recheck
<davexunit>ah, I'm updating an old profile with --manifest right now and I'm very pleased with how much more reliable substitute downloading has become.
<civodul>speaking of which, i think the default list of substitute URLs should only include the mirror, instead of mirror +
<lfam>You don't think it's better to have a fallback if the mirror goes down? Although, our current hydra machine would probably go down if everyone started using it in that situation...
<lfam>lumidragon: Regarding your Go patches: do they address that problem with the linker?
<lfam>The one where can't be found?
<lfam>The one that everyone has gotten stuck on so far ;)
<lumidragon>lfam: the ones I sent last wrap the go compiler in a script.
<lfam>Should I try building Syncthing with them?
<lumidragon>sure feel free, I build rkt and acbuild locally.
<lfam>Okay, cool. I will try that soon
<lumidragon>woudl have sumitted those too but acbuild need systemd-nspawn :(
<civodul>what lumidragon sent + what wingo added should provide a working Go compiler, AIUI
<lumidragon>at least rkt packages it in stage1.aci file.
<lfam>This is an exciting development :)
<lumidragon>I"m hoping so too :)
<lumidragon>I literally had to decidate a weeked to workong on those :)
<lumidragon>as soon I get chance I'll send an updated set up patches.
<lumidragon>for the go compilers.
<lumidragon>definately be I start looking at clojure.
<lumidragon>just looking at the go build script can be quite depressing :(
<lfam>Thanks for taking the hit ;)
<Digit>i cant read/hear "clojure" now without thinking of
<roelj>I reconfigured my Guix git with --localstatedir=/var. I received a warning that kind of scares me.. ;) Why would changing the localstatedir "corrupt the store"?
<lumidragon>gimme min I'll take a look.
<civodul>roelj: see the intro at
<lfam>AIUI The localstatedir contains metadata of the store. If you have two localstatedirs for the same store, then things could get messy
<roelj>Oh right, but the store does not link to things in the localstatedir, does it?
<lumidragon>lfam: np I'm loving guix so far. So to me it's worth it in the long run. :)
<lfam>lumidragon: I agree, this project is worth it to me, too
<civodul>roelj: more explanations about localstatedir at
<lumidragon>Digit: funny so far.
<roelj>civodul: Thanks.
<janneke>how do you handle the resolv.conf update with the openvpn package?
<Digit>lumidragon: educational too i hope. maybe even (dangerously) inspirational as it goes on.
<lumidragon>we'll see ^_^. Wouldn't mind 3D printing my keyboard though. Listining to it as get some stuff done.
<civodul>this gcc bootstrapping issue on ARM is "interesting"
<ifur>i need to patch-shebang an additional file prior to configure step, trying to find a simple and straightforward example :)
<lfam>ifur: You should grep for patch-shebang in gnu/packages. There are only a few results so hopefully one of them help :)
<lfam>I'm glad to see this commit in the certbot (formerly letsencrypt) repo:
<ifur>decided to drop that package for now, it has something called gpt bundled, which is the grid packaging tool released in 2004 where the configure script is in another subdri, so "source/gpt/packaging_tools/configure :)
<ifur>ACTION faints
<ifur>oh, and the confgiure script is called by gpt/ just for good measure