<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! <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 <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? <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>the init system is already running with root priviliges <suitsmeveryfine>I just wanted to show how easy it is to just run the program from inside the system, post-init <suitsmeveryfine>it requires setting a linux flag also, which I've done in the OS config <davexunit>that is something that could be moved into the service <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 <suitsmeveryfine>the conf file could be put elsewhere also but then thinkfan must be told explicitly where to look for it <lfam>mark_weaver: I pushed the libxml2 update to Savannah ***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. <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_>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>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. <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 2f30.org 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_>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 <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>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' <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 <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>so we could have --method and have it default to 'url-fetch' <davexunit>civodul: and what about extra information like the commit SHA? <civodul>the method handler would be passed a list of arguments <civodul>ACTION will happily wait for a patch ;-) <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>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 <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 github.com still helps <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 git.sv.gnu.org port 22: No route to host <lfam>Maybe it's just a transient error. I'll wait a short while before alerting them <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?: <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>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" <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? <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>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>(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>guix environment gives an opaque error message <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>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 <janneke>davexunit: node is fine, `guix environment' does not work for me <davexunit>janneke: could you maybe provide some details? <janneke><janneke> Failed to write XML file; For permission problems, try rerunning as <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>'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>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. <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. <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>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. <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 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. <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. <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: 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>I've been neglecting the container stuff lately... mostly just packaging software that helps me at the day job. <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>emacs packaging is pretty simple, which is a welcome relief. <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 :) <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? <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 <Sleep_Walker>btw. it was interesting reading getting to know which part of the commit is actually signed <civodul>Sleep_Walker: not yet, this requires some thought <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>it must be a scheme file that evaluates to a list of packages <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... <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 was so excited about getting rails in I forgot :) <civodul>it's part of %desktop-services, so many/most run it <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 + hydra.gnu.org <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 libgcc_s.so.1 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 <lfam>This is an exciting development :) <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>just looking at the go build script can be quite depressing :( <lfam>Thanks for taking the hit ;) <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"? <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 <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 :) <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>oh, and the confgiure script is called by gpt/build_gpt.sh just for good measure