IRC channel logs


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?
<PotentialUser-24>OriansJ`: yes exactly
<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`
<lo_mlatu>Anyway thank you OriansJ` :)
<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
<PotentialUser-53>Do I just try and make a regular bootable usb from it?
<buenouanq>the installation image basically is a live usb
<PotentialUser-53>okay so I managed to unxz the file
<PotentialUser-53>and im left with an iso
<buenouanq>so now dd that to the flashdrive
<civodul>Hello Guix!
<civodul>ACTION listens to
<civodul>great talk
<civodul>davexunit: are your slides available on-line?
<civodul>awesome, thanks!
<civodul>we should write a blog entry
<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.
<rekado>What am I doing wrong?
<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.
<thomassgn>you mean the section "the perfect setup"?
<rekado>yes, that’s the one
<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
<thomassgn>cool, thanks wigust and rekado
<jboy>rekado, I just noticed a little error on this page: -- the quasiquote example is missing a few commas
<rekado>oh, looks like they didn’t survive the conversion.
<rekado>thanks for letting me know.
<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>oh, that’s good to know.
<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
<thomassgn>hahaha perfect
<thomassgn>(the paragraf right above this section 3 for anyone interested:
<civodul>thomassgn: excellent :-)
<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
<civodul>so less i/o, less memory, less CPU
<rekado>sounds good
<rekado>would it make “guix pull” slower or is it just a matter of dumping information that we compute anyway on “guix pull”?
<civodul>the latter
<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?
<mbakke>Oh, I see Cabal is indeed failing on Hydra:
<civodul>howdy mbakke!
<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>civodul: After updating to the new Shepherd on a headless node, I get this backtrace trying to run it as my user:
<mbakke>I'm not sure what creates the /run/user entries, I assumed it was elogind.
<mbakke>azertzy: You can click on the build and select the 'inputs' tab to see which Guix commit it was built from:
<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>Errh XDG_RUNTIME_DIR.
<mbakke>Hmm, the XDG spec does not recommend any particular default for it:
<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>see the bug-mcron archive
<civodul>but i think you can work around it by expressing it differently
<civodul>test coverage of the C++ code:
<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).
<bavier`>ACTION afk
<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
<bavier`>yeah, optional as an optimization.
<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
<PotentialUser-31>I was told I need to rerwrite the ISO to the USB
<PotentialUser-31>So lets give it another go..
<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>Hey civodul!
<civodul>hey hey lfam!
<civodul>what's up? :-)
<lfam>I'm curious, do you run an OpenSSH sshd on GuixSD?
<civodul>i do!
<lfam>I'm having some issues since the upgrade to shepherd 0.4.0. sshd is killed just after it starts with signal 15
<lfam>Bug report incoming
<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?
<davidl>don't know how to check that :/
<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>Oh right, you can't
<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/
<lfam>Great :)
<davidl>thx =)
<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
<civodul>what's the TZ story?
<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
<civodul>woow, short notice indeed
<lfam>And the Palestinian Cabinet announced this change only a few days before:
<mbakke>Yes, weird stuff. Sounds good!
<lfam>I believe on March 12
<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
<civodul> has other crazy stories on timezones
<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
<civodul>right, and to actually model it
<lfam>The best part is that the updates are deployed unevenly :)