<piyo>isn't 67 a prime number? <civodul>davexunit: yeah if the config file is too complex using a file-like object is probably best <davexunit>civodul: and now the other difficult problem: secret management. <davexunit>I want to secure the transmission daemon's web UI with a username/password <civodul>would be nice if it were in a state directory, /var/lib/transmission or something <davexunit>I want to make a redis service and that's the same way. <civodul>anything in the store is world-readable, so that would be challenging here <davexunit>I would like to be able to automatically provision things like database servers that have the correct permissions <davexunit>with Ansible/Chef/etc., you just mutate the state file you need to mutate. <civodul>NixOS has a Transmission service but it doesn't seem to treat passwords specially <davexunit>it probably just accepts a config file or some key/value pairs? <davexunit>so you must just have to keep your config private, but since any process can read that file... <piyo>help plz: How to set the source of a package to a checked out git directory? <davexunit>piyo: grep for 'git-fetch' in the gnu/packages directory <davexunit>civodul: so, passwords must not ever make it into the store, but one needs some way of authorizing machines as needed. <davexunit>civodul: in the case of transmission, I can write the service such that it reads the password from /var/transmission/password and passes it to the daemon via a CLI option <lfam>Can't user user read that from `ps`? <lfam>Should a makefile create the install subdirectories "bin", "lib", etc? Or does the gnu-build-system's install phase do that? I'm trying to workaround a "broken" Makefile by replacing the install phase but it fails because $out/bin/ doesn't exist: "cp: cannot create regular file ‘/gnu/store/...-peg-markdown-0.4.14/bin/peg’: No such file or directory" <lfam>The source file ./peg does exist <davexunit>I may be up against a wall here with transmission <lfam>Soooo many programs make this hard <davexunit>apparently transmission tries to write over its config file all the time <lfam>Yes, you can't edit the config file while the daemon is running <lfam>At the very least, the daemon rewrites the file when it exits. <davexunit>the recommended method to set a password is to edit the config file, add the plain text password, restart transmission, and let transmission overwrite the config file with a version that hashes the password. <lfam>I like transmission-daemon because I haven't found another bittorrent daemon that can actually seed a lot of torrents <lfam>Got any alternatives in mind? <lfam>Apparently deluge works but when I tried to use a GUI or TUI it crapped out for me <lfam>I don't authenticate my daemon, but then again I don't have any other users on that system <mark_weaver>davexunit: you could copy the code that hashes the password into a separate program, or, if it's simple enough, rewrite it in scheme :) <davexunit>I feel like I have to submit a bug report. I don't know how to workaround it without compromising security <lfam>Any ideas about my problem above? My custom install phase can't create $out/bin? <mark_weaver>lfam: normally the Makefile would do it. if not, then you'll need to do it in a custom phase I guess. <mark_weaver>in almost all upstream packages, "make install" creates all of those directories if they don't already exist. <davexunit>the folks in the transmission irc channel do not see the issue with a config file that contains passwords that the daemon writes to whenever it feels like <davexunit>so, while they are confused, what I get out of this is that we shouldn't be trying to manage this config with guix. <davexunit>since, now that I remember, you can tweak things via the web interface that will be written to that config file later. <davexunit>which is a shame, because it means that guixsd users can't version control their bittorrent settings. <piyo>So I'm using git-fetch syntax for a package def I am writing, but as a sanity test I try "guix download guile-emacs" and it fails with "guix download: error: guile-emacs: failed to parse URI". I then notice my guix based git exec is failing to retrieve https://github.com/...git urls with a message "fatal: unable to access 'https://github.com/.../': server certificate verification failed. CAfile: none CRLfile: none". Is my "guix package <piyo>-i git"-installed git correct? <civodul>davexunit: so just have that config file in /var/lib/transmission and let users manage it via the web UI? <civodul>that's what the NixOS service seems to be doing <piyo>oh, do I need to guix package -i nss-certs on this foreign distro? <piyo>nope problem not solved. also /usr/bin/git works correctly with https <davexunit>GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt <piyo>yes currently I don't have GIT_SSL_CAINFO set, will try <piyo>This info is mentioned in the manual at "7.2.9 X.509 Certificates". <piyo>Okay I fixed the $USER git problem <piyo>Now to fix the guix download problem. This probably means I need to inject GIT_SSL_CAINFO into my guix-daemon s env, which probably means I need root user to guix package -i nss-certs, right? <piyo>Still doesn't work after injecting GIT_SSL_CAINFO, SSL_CERT_DIR, SSL_CERT_FILE into guix-daemon env. e.g. export GIT_SSL_CAINFO=/root/.guix-profile/etc/ssl/certs/ca-certificates.crt <piyo>what doesnt work: guix download emacs-deferred , which is a package definition that uses "git-fetch" and is an example that I am trying to copy into my own config. <jroh>huzzah! testing in qemu i have finally figured out that the bare-bones config works, but my mods somehow cause a kernel panic on reboot <TML>anyone ever built a vagrant image for guix? <TML>davexunit: I haven't seen anything about that in the docs yet - where can I read more? <TML>I did notice it talking about qemu images during the "Install" section, but I haven't ever really used qemu, so I skipped over it. <davexunit>there's still much work to do, but the Guix tools effectively replace Vagrant, Ansible, Chef, Docker, Puppet, etc. <TML>Well, vagrant is just the mechanism I use today to manage my library of virtualbox images <davexunit>you could use vagrant to install guix on a non-GuixSD distro <davexunit>ACTION tries to hack nginx service extensions before bed <davexunit>when I'm done, users will be able to hand off extra config files to the nginx service <fps>hmm, interesting. during my build all endeavour i stumbled about this: <fps>fps@raksha ~$ find /gnu/store/ -maxdepth 1 -type d | cut -d - -f"2,3,4,5,6" | sort <fps>many packages seems to be in store multiple times <fps>it seems there are differing derivations for the same packages? ***cehteh_ is now known as cehteh
<yvm>Kernel panic after successful installation. No useful info displayed. <fps>yvm: on what kind of hardware? <fps>hmm, do we really need 8 builds of xz in the store? :) <iyzsong>I think some xz are bootstrap version, but I don't expect so much :- <fps>iyzsong: did you check out the paste i sent earlier? <fps>there's also 6 builds of pkg-config <iyzsong>no, but I know there must be multiple version of same packages, since the 'bootstrap' require them. I have't learn the detail yet. <yvm>MB: ASUS M5A78L/USB3, CPU: AMD Athlon(tm) II X3 445. <fps>iyzsong: ok. good point though about bootstrapping. if i filter through uniq i get: <fps>fps@raksha ~$ find /gnu/store/ -maxdepth 1 -type d | cut -d - -f"2,3,4,5,6" | sort | uniq | wc -l <fps>so, almost done i suppose :) <fps>fps@raksha ~$ guix package -A | wc -l <fps>yvm: but the installer image boots fine? <iyzsong>fps: and many will be opt-out if you don't bootstrap yourself (eg: I only have 1 xz on my GuixSD). <fps>iyzsong: not sure if i bootstrapped. i just guix pull'ed as user and then did a guix package -A | cut -f1 and did guix build for all of those :) ***user5252 is now known as QuiGonEmacs
<yvm>fps, installer image boots and works, installation finished successfully, grub installed to MBR of HDD loads the kernel, but kernel panics causing system hang. <cts>I'd like to install guix the package manager on top of my ubuntu. <cts>'wget ftp://alpha.gnu.org/gnu/guix/guix-binary-0.9.0.x86_64-linux.tar.xz' aborts with: "Error in server response, closing control connection.". <cts>Is there another way to get the file? <fps>yvm: hmm, and absolutely no console output that's usable? <fps>yvm: you might get a kernel panic if you specified the wrong label for the root fs <fps>if you followed the installation instructions the example configs expect the root fs to have the label "root" <fps>did you mkfs -L root for your root f? <fps>or changed the entry accordingly? <fps>civodul: quick question: when someone tries to grab a substitute from my machine that is running the publish service and a derivation output is not available due to a build failure <fps>civodul: what happens then? does the client trying to get the substitute try to build from source, too, which will subsequently fail? <fps>or does the publish service check the db for failed builds and communicates the failure to the client? <yvm>I did specify -L root for root partition, yep. <fps>this is kind of related to my question about explicitly representing failures in the store. if they were represented as such the substitute server could just deliver the archive containing the build failure <fps>and then the client wouldn't have to retry.. <fps>yvm: and you cannot provide the text from the kernel panic? <yvm>Ok, I'll check labels and make a photo. <fps>davexunit: oh ok. that's unfortunate <davexunit>in a future where builds are completely deterministic, then we could have such an optimization. <civodul>fps: yeah, clients will try to build <civodul>they can't tell why the build is unavailable <civodul>it could be because it failed to build, or because you don't like it ;-) <iyzsong>cts: I can wget the guix-binary tarball, no idea what's wrong. IIRC, @civodul also host it. <civodul>the release tarballs are only at alpha.gnu.org, but there are mirrors <fps>civodul: yeah, ok. if the build failure was represented in the store and subsequently delivered to the client, the client could determine whether to retry the build or not <fps>depending on the failure.. <civodul>fps: yeah we could do that, but as davexunit said, we live in a non-ideal world <fps>civodul: yes, that's why i said the client could then decide whether to build or not :) <fps>right now it doesn't have any information <iyzsong>I'd like to do pam and environment things, in next week.. <fps>if i understand it right the store is a memoization of the function mapping derivations to their outputs, right? <fps>so, if the function has never been attempted the store would have no result. that's fine.. <fps>but if it had been attempted and failed it would make sense to memoize that outcome, too, right? <fps>nothing is lost, much is gained. or do i miss something? <civodul>yes that's what "guix-daemon --cache-failures" does, but you already tried that, right? <civodul>we could allow 'guix publish' to publish that information optionally <civodul>feel free to leave an item on bug-guix@gnu.org! :-) <fps>yeah, if we made the store more expicit in this regard, then there would be no need to touch the guix publish service <fps>if the build failure was represented in store in such a way that an archive could be delivered containing it, then it would be more explicit and you'd gain the goodies <civodul>no need, there's already a query-failed-paths RPC for that <civodul>any volunteer to review the Let's Encrypt patch series? :-) <fps>yeah, hmm, but still, think more functionally and in a more type-strict way :) <fps>we really have a function f: derivation -> store-entry | some entries in some db (possibly, maybe) <fps>wouldn't there be something to gain from making it f: derivation -> store-entry, where store entry is an explicitly variant type modelling the failure modes, too? <davexunit>civodul: I've been meaning to review it, but haven't gotten to it. <rgrau>Hi guixers, I tried to build this package (imported from nix), and it fails on configure phase. the ./configure file is a perl one, and it seems it's not recognizing it as such (it errs with "./configure: line 3: use: command not found"). https://gist.github.com/e12b87eeec6c63f00971 . <fps>civodul: i'll leave a message on the bug list then... <fps>civodul: and yeah --cache-failures seems to work just fine, locally, here.. i was just pondering some more consequences of this non-explicit representation.. <davexunit>rgrau: the GNU build system assumes that 'configure' can be run with bash <iyzsong>rgrau: I think you should put perl into 'native-inputs', only that will be added to PATH. <davexunit>rgrau: so you'll need to replace the 'configure' phase with a custom one <iyzsong>or, I'm wrong about the reason, but it's still the right idea :- <rgrau>ooks. the configure file has a shebang and I thought it would catch it on the fly and run perl. will try both native-inputs and custom configure. I guess I didn't pick the easiest package to train myself.... <davexunit>it does something like (system* "sh" "configure") <davexunit>which explicitly says to use bash to run the configure script <cehteh>.o(with guile support in gnu-make, how about dropping automake :D) <rgrau>yup, then it makes sense it's failing. thanks! <davexunit>for packages that use the GNU build system, 'configure' is *always* a shell script <iyzsong>cehteh: make sense. I tried, and it seems that we can output all the Makefile rules using Guile, but currently, ugly #f (as empty string for success) and "false" (as false command for failure) is required :( <yvm>Labels set for all partitions: swap, root and home. <cehteh>would be a long term goal anyway <civodul>yvm: argh, too bad we don't see what comes before :-/ <civodul>yvm: i wonder if some "vga=xyz" would allow it to boot straight in framebuffer mode <civodul>another thing to try to to add "--repl" on the kernel command line in the bootloader <civodul>to check if we at least get this far <fps>yvm: can you paste your config.scm? <fps>or whatever file you used for guix system init.. <yvm>search --file --set /gnu/store/zbm09fk0wxkw2wyygnn4gcfxj8s31ajd-linux-libre-4.2.5/bzImage <fps>i don't see anything apparently wrong with that line per se.. <yvm>Whoops. Timezone mistype. <iyzsong>IIUC, we can replace all the external guild calls in Makefile to $(guile (compile-file ...) to gain speed up after the one-progress-guix-pull issue solved. <iyzsong>yvm: could use paste.lisp.org? pastebin.com having some issue :- <iyzsong>for most developers (tor, etc, and I'm blocked by my ISP) <iyzsong>I don't find any problem with your config :( <yvm>Ok, I'll try to make a photo with more output then. <civodul>iyzsong: i hadn't thought of using $(guile (compile-file ...)), but that's a good idea <civodul>with the caveat about compilation order and all that, though <davexunit>ACTION tries to figure out how to make nginx-service extensible <civodul>davexunit: your feedback on this particular case will be very useful <iyzsong>maybe just drop a nginx config file into the 'sites-enabled' directory? that's the only way I know.. <davexunit>iyzsong: that's the debian stateful way of doing it <davexunit>my strategy is to accumulate gexps or file-like objects <iyzsong>yes, but we can build the 'site-enabled' (or conf.d?) directory by services.. sure, gexps would have better interface than plain file. <davexunit>again, sites-enabled only makes sense for stateful configuration a la debian <davexunit>the nginx-service-type will allows extensions that specify vhosts <iyzsong>davexunit: um, I mean the conf.d is read-only in store, build from services. <fps> for n in `guix package -A | cut -f1 | grep -v chicken`; do guix build --no-substitutes "$n" || true; done <davexunit>iyzsong: we don't need conf.d, is what I'm saying. <fps>/dev/sda1 99G 38G 57G 40% / <fps>it only took like 4 days or so on this vm :) <fps>let's see what happens if i just do it again right away.. <davexunit>why are you are grepping for chicken when you could have asked guix to do that? <fps>i'm exluding chicken from the list <fps>sorry, still a guile noob. that was easier for me :) <iyzsong>cool, I think we can challenge him.. <davexunit>glad to see more people using 'guix publish' <fps>feel free to. it should have all packages that are in the list and that succeeded to build.. <fps>guix pull from 5 days ago or so <fps>i wonder what happens if i now guix pull and redo the whole exercise? <fps>will be interesting to find out a strategy to automate that to once a day or so and only gc enough to have the latest generation available at least plus some remains as long as they fit <fps>i might probably use a couple hundred more G's <fps>will have to check with my buddies first though :) <iyzsong>oh, only 2 module-import-compiled and glib contents differ? <davexunit>what we need is an easy way for people to replicate what hydra.gnu.org does <fps>if you want to go a more decentralized route, i suppose pimping the guix publish work flow mightpay off more in the long run <fps>once publishing uses gnunet, etc, there shouldn't really be a need for hydra anymore.. <davexunit>fps: you are re-inventing small parts of hydra in order to make guix build everything <civodul>davexunit: but this is OK: what's needed to build and publish stuff is really a few lines of shell/Scheme <davexunit>I'd like something more robust in the future, though. <davexunit>so other users can easily run their own build farma <civodul>the difficult part in Hydra is keeping track of everything in the database <davexunit>we need a Hydra replacement written in Guile <civodul>a brute-force system that just regularly git-pulls and builds is much simpler <davexunit>that could be the first version of 'guix farm' <fps>anyways, this vm will live for a while. if you want me to try things, just let me know.. <davexunit>we need to be able to check build status and logs and things <fps>need to go to work now.. <civodul>davexunit: 'guix publish' should publish /log URLs like Hydra does <iyzsong>gtk+ and openssl added, that's all for me :- <davexunit>in theory 'guix farm' would share lots of code with 'guix publish' <civodul>iyzsong: what do you mean? these are the only packages for which you have a local build? <civodul>davexunit: 'guix publish' would be part of it, of course <davexunit>civodul: yeah, but would there be a need for a standalone 'guix publish' anymore? <davexunit>or would users just use 'guix farm' instead? <iyzsong>civodul: that's the output for me, doesn't it only check for which I have a local build? <iyzsong>yeah, I haven't update my user profile for a long time :- <davexunit>civodul: thanks for the review on the transmission-service. I realize now that I forgot to drop privileges before forking. <davexunit>perhaps dmd should include a function that can be composed with 'make-forkexec-constructor' that will drop privileges? <df_>it's a guix sd system I installed a while back and only recent updated with a guix pull <df_>the same command works fine as root <davexunit>(compose (drop-privileges "user" "group") (make-forkexec-constructor ...)) <davexunit>er, other way around, but you get the idea ;) <civodul>davexunit: ISTR that wingo added such a thing a while back <df_>oh, and I also ran guix system reconfigure after the pull <civodul>davexunit: often daemons do it for you, though <civodul>df_: new (guix config) no longer has this %nixpkgs variable, but old (guix utils) wants it <civodul>df_: so it seems that you need to 'guix pull' <df_>as the non-root user? <df_>I was under the impression guix pull was a global thing <civodul>no it's per-user, which confuses many people it seems <df_>same error from guix pull :( <df_>is reconfiguring without that user then adding it back likely to help? <civodul>df_: you can simply "rm ~/.config/guix/latest" in the faulty user account and start from there <civodul>that way it will use the system-wide guix, which is known good <df_>then do a guix pull? <df_>ok, package -u is working, thanks :) <amz3>I'm back with my question about format-patch. Once you do format-patch do you "remove" the commit from git? <davexunit>so our packages are Scheme source code that describes where to get the source, what the dependencies are, how to build the source, etc. <rgrau>I'm trying to write a custom configure phase, and I see plenty of 'alist-cons-before' calls in the package recipes, but I see no clear way to remove a phase from %standard-phases or replace it. also, It's kinda difficult for me because I'm new to guile, and I don't know how to try things interactively. can I put some kind of breakpoint that will leave me in a repl while building the package? <rgrau>or some way M-. in geiser will bring me to the implementation of a function like alist-cons-before, for example <davexunit>(modify-phases %standard-phases (replace 'configure ...)) <desiderantes>is there any guide on how to add support to a build system? <davexunit>desiderantes: do you mean "how to add a new build system"? <rgrau>ACTION triggered the newbie question section :) <davexunit>I learned how by just reading the other build systems <desiderantes>davexunit, yes, i wanted to add support for the bake build system <civodul>davexunit: i've just opened a bug to track progress on 'guix system reconfigure' dynamic reconfiguration <jroh>i'm curious .. if I install emacs as root, and again as a user, they seem to have discrete packages in the store <rgrau>did you guix pull between installations? <cts>Thank you, iyzsong! I got the tarball from there. :) <df_>I seem to be missing the term(cap|info) entry for rxvt-unicode (various weird terminal behaviour, less reports "terminal is not fully functional" etc), is there a package that provides it? <mthl>df_: I have the same problem, you need to tweak you .Xresources <mthl>df_: "URxvt*termName: rxvt" <jroh>rgrau: that must be related. i just did another pull a bit ago and re-ran install from both users.. they seem to be on the same versions now <df_>hmm, they're not quite the same though are they? <df_>I've worked around it for now by grabbing the terminfo file from another machine with infocmp and installing it in my home dir with tic <mthl>df_: my solution is a workaround too, not a fix <df_>any idea what the correct solution is? should the rxvt-unicode package install it? <df_>I'll have a look, with any luck it will be a relatively easy problem to start learning how to hack guix packges ***trisquel is now known as HeisenbergsMirro
***HeisenbergsMirro is now known as HeisenbergsDog
<rgrau>for apps that spit logs (openresty, think nginx), where should we place the logs? in the profile's share dir, profile's var/log dir, or root /var/log ? <lfam>davexunit: Are you happy with the transmission service as it is? Or is the authentication system still insecure? <lfam>When packaging software that works with both python2 and python3, is it normal to have to add python2-setuptools as an input for the python2 variant? Not knowing this is one reason my WIP lets-encrypt patchset is WIP — I'm wondering how to approach this. I also need to read the ML stuff from a few days ago and python2 packaging issues <efraim>if python-setuptools are an input then package-with-python2 will translate that to python2-setuptools <efraim>the python2 problem is when the python2 variant has extra inputs, then whenever it is used it needs to be called specifically <lfam>efraim: Thanks, I really need to dig into it because I hit the exact issue on the ML (python2-ipaddress) and I thought I was losing my mind ;) <efraim>I'm still stuck at that same spot :( I can't figure out exactly which test is failing or why <civodul>i wasn't sure if i had missed something or not <rgrau>if in the configure phase I want to pass the path of the luajit package, how do I set it as a dependency and get its path? <civodul>rgrau: using the 'inputs' keyword passed to the phase's procedure <civodul>search for "(assoc-ref inputs" in gnu/packages/*.scm <rgrau>btw, I finally got to package this f*cking openresty. I'm now trying to polish it <rgrau>will try to write the associated tutorial (for things a bit harder than hello package) <mark_weaver>hmm, "guix system build" on my long-standing OS config is now failing with git master, and even when I incrementally strip down my config to an increasingly minimal desktop config, I cannot find a config that works. <mark_weaver>ERROR: In procedure append: Wrong type argument in position 39 (expecting empty list): #f <mark_weaver>I tried reverting b9c7ed71b1, 479b417b54, and fae685b9cc, and then a minimal desktop config fails with a different error: <mark_weaver>gnu/services/networking.scm:110:8: In procedure module-lookup: Unbound variable: %default-modules <mark_weaver>HeisenbergsDog: Guix would have to be cross-compiled and ported to work on XNU <mark_weaver>and it would still use all the GNU libraries right down to GNU libc, and the GNU toolchain (gcc, binutils, etc), so all of that would need to work well enough on XNU <mark_weaver>and probably a lot of problems would need to be fixed in packages throughout the distribution <mark_weaver>it would be a GNU system, almost the same as we have on GNU/Linux, except with the XNU kernel. <lfam>HeisenbergsDog: However, you can trivially use Guix on a not-GuixSD-linux. I run it on top of Debian. <civodul>mark_weaver: could it be an ABI issue? <civodul>in practice i usually limit myself to deleting gnu/*.go gnu/services/*.go in such cases <mark_weaver>I've also now found that at some point in a recent update, 'totem' stopped working, and actually I have no working video player at all :-( <civodul>mark_weaver: if you still have previous generations around, you could try to find out where it broke <civodul>i use mplayer or vlc most of the time <lfam>I just noticed a problem with my peg-markdown package definition. The package provides `peg` and `leg` and a manpage "peg.1" that documents both binaries. But `man peg` works while `man leg` doesn't. Any suggestions for a revision? I don't know how to approach this. <civodul>maybe make a leg.1 -> peg.1 symlink? <lfam>Is that all it takes? :) <civodul>we can do that, but it's a problem for upstream to solve ultimately <lfam>civodul: I don't think there is much an upstream for this one. I threw it together because rekado said it would be simple :p Is there a guile procedure for symlinks? Not much fun to grep for 'ln' <mark_weaver>civodul: I have generations going back about 6 weeks, but switching to old generations doesn't seem to fix the problem with totem, even though totem and associated plugins are in my user profile. I guess maybe I need to boot into older generations of my system to get back to a working state :-( <mark_weaver>or perhaps it some mutate state in my home directory. <civodul>mark_weaver: i don't think totem really depends on external system state <civodul>but the i don't know what the problem is either :-) <jin_>hi, how can start sshd service in guixsd ? <lfam>What is the significance of the '--fallback' build process option? It seems to describe the default behaviour. Am I misunderstanding it? ***HeisenbergsDog is now known as Guest50910
