IRC channel logs
2018-03-29.log
back to list of logs
<ryanprior>Being a source-based distribution, it seems to me like we should be able to set up continuous deployment to land security updates within minutes. <PotentialUser-24>Hi, every one. I have a question now. From the manual I know how to add a file to `/etc` through extending the `etc-service-type`, but how can I modify a file already populated by other service or package, e.g. add a line to it? <OriansJ`>PotentialUser-24: you mean append something to that file or modify the contents of it? <OriansJ`>well there are two types of files generally, those that are symlinked and you can simply create a derivative or normal files that are not specified by a guixsd configuration, which generally is not recommended because you lose the benefit of being able to rollback changes using guix <lo_mlatu>So I wonder if there is a recommended way (I'm the one ask the question, log out by accident) <lo_mlatu>By saying create a derivative, do you mean create a package witch just generate a new file in the `/etc` ? <OriansJ`>lo_mlatu: yes that is a possible solution to the problem <OriansJ`>you could also have a derivative of the other package which simply produces a modified version of the /etc file in question. <lo_mlatu>I see...I think guix prefer to configure a service rather than directly modify the file in `/etc` <PotentialUser-53>Im trying to put guix on a usb so I can live boot it to test my NIC on it, but It doesnt seem to be a normal iso <buenouanq>the installation image basically is a live usb <civodul>davexunit: are your slides available on-line? <thomassgn>Hey, I've been fixing the package definitions I sent in the other day. I'm writing the commitmessage now, but after reading the gnu changelog standards I have a few questions: My current commit message looks like "* gnu/packages/xdisorg.scm (screen-message): Add package definition" Should I add more explanation? and from before I'm used to putting just 68 characters on the first line no punctuation and then <thomassgn>blank line before any more descritpion, but the gnu standards seem to say differently. is that right? <roptat>thomassgn: it should be "* gnu/packages/xdisorg.scm (screen-message): New variable." <roptat>see other commit messages for examples <thomassgn>roptat: ah, I've tried looking at other commits and can't see any adding packages. I'm doing something wrong, yes. <rekado>I want to build “axoloti-patcher” but the patch for “axoloti-libusb” no longer applies. So I updated the patch, but Guix still insists on applying the old version of the patch. <roptat>thomassgn: I think I confused you: the message should be "gnu: Add screen-message", a blank line and then "* gnu/packages/xdisorg.scm (screen-message): New variable."" <roptat>and don't sign-off your own patch <snape>with a '.' after "Add screen-message" :-) <thomassgn>derp. ok, sent them allready. these guidelines are too complex/confusing for me it seems. <thomassgn>thanks for pointing it out though, next commit message will be a bit better. <rekado>thomassgn: if you’re using Emacs + magit you may find our commit message snippets useful. <rekado>they are in etc/snippets and can be used with yasnippet. <rekado>I only type “add” hit TAB and it expands to the right text for adding a new package. <thomassgn>rekado: cool, is there an easy way to add them? Ah, yasnippet: the plugin I've had since the start, but never used... :P <rekado>thomassgn: take a look at the contributing manual section. <rekado>it tells you how to set this up. <rekado>BTW my patch problem was due to GUIX_PACKAGE_PATH, which included a duplicate package definition <thomassgn>cause it assumes that I'm working in a git checkout of the guix source, which I don't. I remember I couldn't make it work, too much confusion between my running system and the git checkout... <rekado>you can also just copy the snippets to some other directory and refer to them. <rekado>you don’t need to wrok from a git checkout to use the snippets. <rekado>(but I do wonder how you submit patches when you don’t use a git checkout.) <thomassgn>I understand a lot more now, compared to last time I tried this. So I'll probably try again soon. <wigust>thomassgn: Also “C-x v l runs the command vc-print-log” in file you want to commit helps with a commit message. <thomassgn>oh I do use git, but I have my own repo where I write and test package defs. and then I copy the defs over to the guix src checkout and make the patch. Yes it's tedious, but I understand what's happening and I don't have errors I don't understand flowing around... :P <rekado>oh, looks like they didn’t survive the conversion. <rekado>fixing up the documentation there has been on my list for much too long. I’ll try to fix all problems with that page in April. <jboy>sure thing. thanks for putting up the documentation, it's helpful for users external to your org as well. <rekado>I hope that the official manual can satisfy these needs instead, but I guess it’s a little intimidating. <jboy>yes, and sometimes it helps to have a more opinionated guide. <thomassgn>rekado: I love your paragraf "...but for now Guix at the MDC also serves as a personality trainer..." :D <civodul>rekado: but the slow NFS days are mostly gone, right? <rekado>civodul: yes, but it’s still slower than it should be. It’s not Guix’s problem, though, but a file server appliance / configuration problem that is out of my hands. <civodul>BTW, i'm thinking of adding a "package cache" that 'guix pull' would populate, to speed up lookups by name <civodul>currently when you type "guix build foo" we start by loading all 7K packages <civodul>the cache would allow us to load the subset of modules that "foo" depends on <rekado>would it make “guix pull” slower or is it just a matter of dumping information that we compute anyway on “guix pull”? <azertzy>Hello, I was wondering if it's possible to reproduce a derivation from hydra with guix as it seems that both nix and cabal are currently not available for guix current? <mbakke>Oh, apparently the new Shepherd depends on 'elogind-service' (or at least /run/user/N). <mbakke>azertzy: I'm not sure what you mean, can you clarify? <civodul>i don't think the Shepherd depends on elogind, why would it? <mbakke>azertzy: Hydra continuously evaluates the latest code in Guix, so in general to reproduce a failure all you need to do is "guix build foo" with a current commit. <azertzy>would like to reproduce the working version Build 2243597 if possible of cabal <mbakke>I'm not sure what creates the /run/user entries, I assumed it was elogind. <mbakke>However, that commit is very old and we are unlikely to have substitutes for it, so be prepared for some building. <azertzy>That's not an issue as long as it works for now. Thank you <civodul>mbakke: comes from shepherd commit 11f1ae22854b9a165db5926ec92b98a8ce540654 <civodul>at least the shepherd could mkdir-p that directory <mbakke>Right. I'll try to set XDG_USER_DIR. <mbakke>civodul: Setting XDG_RUNTIME_DIR did the job, thanks! <mbakke>Oh no, mcron fails to read my jobs too :P <rekado>davexunit: great talk! Also: thanks for keeping with the tradition of mentioning Emacs :) <civodul>mbakke: yeah it's fixed upstream and a new release will be out soon <civodul>but i think you can work around it by expressing it differently <bavier`>civodul: only 'guix pull' would populate such a cache? it would seem useful also for search-package-by-name (or whatever it's called). <civodul>bavier`: 'guix pull' would populate it and lookup by name would use it, if it's available <civodul>i think it'd have to be optional so that we can still use $GUIX_PACKAGE_PATH without worrying about updating the cache <PotentialUser-31>So I burned the GuixSD ISO to my USB using Rufus, upon loading up the grub and getting to guile it was saying stuff like "waiting for partition to appear" and it ended up failing, then everything I did in command line wasnt working <lfam>mbakke: There's a new tzdata. Do you think the current core-updates branch will be finished quickly (I know it freezes Monday) or should I aim for a tz-updates branch? <lfam>mbakke: It's possible a tz-updates branch could be completed before Monday <lfam>Hm, the big time zone will probably be moot by the time we build it (DST for Palestine started a week early this year) <lfam>The big time zone change, I mean <lfam>I'm curious, do you run an OpenSSH sshd on GuixSD? <lfam>I'm having some issues since the upgrade to shepherd 0.4.0. sshd is killed just after it starts with signal 15 <civodul>"make check-system TESTS=openssh" passes, IIRC <lfam>I'll try that on this machine. Still gathering data and looking for interesting things <davidl>running guix system reconfigure for my local user gives me this error msg: <davidl>I think it’s inherent to the nature of installation tests, though if <davidl>this msg: guix pull: error: could not find bootstrap binary 'guile-2.0.9.tar.xz' for system 'x86_64-linux' <davidl>any ideas on how I can solve it? <civodul>could it be that you reconfigured GuixSD but your user's ~/.config/guix/latest lags behind? <lfam>david1: You can check your users's version with `guix --version` <davidl>absolutely behind: guix (GNU Guix) 20170930.14 <lfam>I recommend updating with `guix pull && guix package --upgrade .` <lfam>Maybe if you remove ~/.config/guix/latest and then try again <davidl>actually my root guix was from a specific commit as a workaround of some bug a few weeks ago. not sure if that matters. <davidl>lfam: no error message yet at least \\O/ <mbakke>lfam: What should we do about tzdata? <mbakke>Hydra just started a 'master' evaluation, so I guess we'll have to wait with staging/tzdata-updates. <lfam>mbakke: Let's just do it on core-updates. I'm testing it locally before pushing, in order to avoid the fiasco from last time <lfam>We wouldn't be able to deploy it before the relevant time-zone change becomes irrelevant (March 31) <lfam>There's not much we (and other OS distributors) can do if the relevant authorities decide to change their clocks with only days notice <lfam>civodul: There was a new tzdata release on March 22. The major change is that Palestine will start their summer time on March 24 instead of March 31 <lfam>These shenanigans exist in most of the TZ updates, I've found <lfam>"the decree did not specify the exact time of the time shift" <lfam>It's not that important, I suppose <lfam>Alright, I'm building Guile on core-updates now. I'll push the TZ update later today if all goes well <lfam>My favorite are the retroactive changes. The last version had a change like "1 hour difference in 1933 in South Sudan" or some other thing <lfam>It's a real "map vs territory" thing <lfam>Heh :) I think it's an unavoidable result of trying to systematically describe existence <lfam>The best part is that the updates are deployed unevenly :)