<civodul>braunr: sorry i emailed you and others the details in the meantime <braunr>civodul: first, I'm currently not part of the hurd project any more <braunr>but maybe i didn't get the mail because of greylisting <braunr>civodul: second, i do remember that, but i'm asking what the problem is <civodul>braunr: i was wondering whether libc was the right place for this fix <civodul>(the problem solved by this patch is exposed by Guile's test suite) <civodul>the time unit thing discussed at the URL above ***jonsger1 is now known as jonsger
***orly_owl_ is now known as orly_owl
***jonsger1 is now known as jonsger
<rekado>I’m asked to build bash from soure. <rekado>not going to happen on this underpowered machine <civodul>probably related to grafts, but i'm not sure why <efraim>build just the bash, and then see if it grafts everything after that <efraim>that's what's been going around since the bash CVE replacement <rekado>that’s going to take me too long right now <rekado>I need to install bash to get screen <civodul>you could always install with --no-grafts if you're in a hurry <civodul>but then i recommend installing the grafted thing <civodul>building Bash is usually fast, even for a underpowered machine <braunr>civodul: if the patch fixes it, i mean <efraim>I would stick it in glibc, to me it seems more of glibc not correctly interpreting Hurd's time <braunr>but i still don't see the question <braunr>ah the question is : is glibc the right place ? <civodul>it could have been that Guile is making wrong assumptions <civodul>wrt. the whole "time units per second" thing <civodul>but if that's a widespread assumption, then libc is the place to fix it <braunr>the patch description by phant0mas looks wrong <braunr>well my description is too light :) <civodul>braunr: it's true that it's not really verbose ;-) <braunr>but iirc, our sysconf(_SC_CLK_TCK) returned 100 <braunr>and since that's what the kernel actually uses, and because of overflow issues, i decided to make it that way too in glibc <braunr>which is the right place for this kind of change <braunr>the real problem is a discrepancy between glibc (which was fine) and /proc <civodul>could you reply in that thread (25463@debbugs.gnu.org), just to keep track of it? <thomasd>I implemented a version of "guix system delete-generations", but am not sure how to best handle regeneration of grub.cfg <civodul>(guix scripts system) has everything to do that, but possibly in an inconvenient form <civodul>if you want, you can ask for suggestions on the list <civodul>Chris Marusich looked into that code for instance <thomasd>yes, I might. If someone has time for a quick question, the main issue is the following: is there a way to retrieve the current grub-cfg's custom boot menu entries, or do you need a system.scm configuration for that/ <rekado>our institute considers hosting a two day Guix workshop. <rekado>anyone interested in joining us in Berlin as an instructor? <rekado>we’re looking for funding so travel+accomodation for instructors would likely be covered <thomasd>hmm, sounds fun indeed. I'd like to join/help (don't know what level of expertise you're looking for, and what level of experts are available :-) ). <rekado>the target audience will be bioinformaticians, mostly <rekado>we’d like to show how Guix can be used for reproducible science. <thomasd>Where I'm working, it's mostly about earth sciences, so I'm not familiar with typical bioinformatics tools (R?), but I suppose there are similarities. <rekado>bioinfo uses R extensively, but reproducibility isn’t limited to R, obviously <efraim>I'm very interested. I don't know a lot about R but I'd like to think I know a lot about working with guix <rekado>we’re aiming for June, so if anyone would like to participate in shaping the programme as an instructor please write me an email. <rekado>roelj: we were also thinking of you and the GWL here. <civodul>yeah roelj would be the right person i guess :-) <rekado>it’s all in very early planning stages at this point, but we’re serious about this. As soon as we can think of a reasonable programme we’ll try to move it forward. <rekado>civodul: my boss also specifically asked for you :) <efraim>civodul: always nice to be asked for by name <civodul>thomasd: very roughly, i think 'reinstall-grub' is the procedure you should be using <thomasd>civodul: thanks. That's what I was using though, so I'll have to ask the mailing list for some more advice :) <efraim>has anyone else tried updating guile-next? it took ~4 hours the last time I tried <civodul>hmm, i apparently forgot to type in a subject for that message <ng0>some people around here use vim, right? Did you already investigate how to deal with the VIMPLUGIN_PATH or whatever the variable is called, for Guix? I have a couple of plugins, including the scheme one, but it's not just copy and paste and it works. <efraim>I currently use vundle, and that automagically takes care of everything <efraim>I did want to get rid of that and just use mr (myrepos) to handle it all <ng0>okay. I want to get rid of that. I'm currently looking into how it'll work <ng0>there is "set runtimepath" .. but this will start to look very akward with store paths. but at least I know what I need to look into now :) <ng0>as a simple workaround, set runtimepath=^=~/.guix-profile/where/ever/vim/is/ could work.. <ng0>I mean, I use guix. why use vundle and other software when I have the power to not use them :) <ng0>or does pathogen add more than just a way to install addons? <ng0>reading on stackexchange I see why my first try didn't work. some wrapping and/or variable setting on user side needs to happen <ng0>seems like nix does almost just this, skipping through their documentation. <roelj>rekado: Sorry for the late reply. I like the idea! Maybe we could also host a similar programme in Utrecht as well? <ng0>efraim: I've got the plugins to work. I'll submit the first vim plugins tomorrow if I have the time. <rekado>roelj: I'd be up for it, though I wouldn't be able to organise it myself. Funding we could obtain for the event in Germany would require our research group / core unit to be hosting the event. <rekado>i.e. one of the conditions is that we conduct trainings within the framework of the German bioinfo network. <roelj>rekado: Of course, organizing in Utrecht would be my responsibility :) Let's first work towards Berlin <ng0>oh, speaking of funding. for people living in Germany, the second round of prototypefund is on. 46 days until deadline of submissions <civodul>roelj: BTW, how was your Guix session at work last week? <roelj>civodul: Good. We now moved on to the actual testing phase / Guix is running on a single compute node on the cluster with /gnu mounted. I'm now doing performance tests to see whether it scales :) <roelj>That will take a couple of days at least. <civodul>then we'll see you grumble about NFS like rekado does <roelj>civodul: Heh, we have a little different setup. <roelj>We have /gnu on the same machine as where guix-daemon is running, and we expose that to other nodes in the cluster. <roelj>The guixr script from rekado is really cool! I think we should make it a little more generic and then package it for Guix. <civodul>yeah, we'll integrate that functionality directly in Guix <civodul>have /gnu and guix-daemon on the same machine probably helps <roelj>civodul: By the way, I did a binary install and then used NIX_STATE_DIR to change the state directory to /gnu. <rekado>it should avoid most of the problems we face here <rekado>I'm close to deploying lsyncd to speed things up here. <rekado>(lsyncd listens for inotify events and then kicks off rsync or cp to sync local changes to the remote target) <roelj>Looking forward to read about how it works. <roelj>I can share my performance report as well for the single-build-node-that-does-all. <rekado>roelj: I just have no trust at all in our ability to guarantee uptime of the Guix node. <rekado>or at least to guarantee that it stays up while the cluster is up. <rekado>I'd be more embarrassed about downtime than I am about offering a patience-testing variant of Guix on NFS. <rekado>roelj: how many build users do you have on the Guix node? <rekado>I started out with the usual 10 and as demand grew I had to increase the number. <roelj>rekado: Currently 10. Do you have any figures of the load? <rekado>a few weeks ago I increased the number to 50, I think <rekado>we had some users report that they were stuck "waiting for build slots" <rekado>it can help to have a bit more headroom when things get busy <rekado>I don't have any load stats though <roelj>rekado: How come users need to build so much? Do people maintain their own package recipes? <rekado>haven't really thought about how best to collect them. <rekado>civodul: no, it's not something I wrote <rekado>I was about to write something like that when I discovered that it already exists. <civodul>i wonder if we should use it for 'guix publish' <civodul>that is, to pre-build the narinfos and nars <rekado>I'm not sure I follow. How would that work? <rekado>on Friday rms was in Berlin and he blessed my laptop. Ever since my laptop freezes and the WiFi card seems broken for good. <rekado>I think it's actual hardware failure :-/ <rekado>this is the same laptop that's cracked wide open on the side since kissing concrete. <rekado>roelj: re 50 build users: you need to consider that building a new profile generation also requires a build process. <civodul>rekado: re guix publish, we'd have an "off-line mode" for it <civodul>like 'guix publish --generate=/var/cache/publish' <civodul>and it would spit out all the files in there, where nginx could pick them up <civodul>as opposed to relying on the web server embedded in 'guix publish' <roelj>rekado: re 50 build users: How many users do you have there? <rekado>roelj: I haven't checked recently, but I think we have about 100 active users. <rekado>50 build users seems to be fine for now, but 10 wasn't enough for when many people would play with Guix at the same time. <rekado>ng0: it says "The GNU Guix team" now; this looks okay to me. <ng0>i meant the name.. Guix GNU/Linux looked wrong to me <ng0>I suggested to change it to just GNU Guix <ng0>their community is very welcoming and includes packagers in future decisions etc :) <roelj>rekado: Ok, that's really cool! <rekado>ng0: yes, I understood. But you also asked about the maintainer field :) <rekado>Well, calling it "GNU Guix" is okay because that's the package manager (and it can be used on other variants of GNU). <rekado>If the name "GuixSD" were to be used then I think adding "(GNU/Linux)" would be fine, too. <ng0>hm.. right. but they picked Guix not GuixSD, so the correction is fine <ng0>I have to go now, refresh some math :) <rekado>civodul: I don't think lsyncd works at the right level for this use case. <rekado>it aggregates inotify events and then copies files from the source to the target. <rekado>in the "guix publish" case the directories don't/shouldn't change. <rekado>unless you'd want a daemon mode where guix publish observes changes and regenerates /var/cache/publish on demand. <rekado>but even then using inotify seems like a hack. <civodul>well a build-complete notification from the daemon would be better <civodul>rekado: i just realized i got the video editing message from FOSDEM <civodul>but the thing doesn't work in IceCat/Conkeror <civodul>i remember you mentioned it before, so what did you do? <civodul>or maybe roelj or janneke or paroneayea have a solution? <civodul>ACTION naively hoped he wouldn't have to do anything <rekado>civodul: yeah, it didn't work for me in IceCat. <rekado>it seems to work somewhat better in epiphany after installing gstreamer and gst-libav <rekado>but I haven't been able to really do anything there <rekado>(and my laptop froze while trying) <civodul>so gstream and gst-libav need to be in the profile? <rekado>I noticed that the audio is not in sync with the video, so maybe that's enough to mark the videos as broken and request a re-encoding <rekado>I installed gst-libav (for the video) and gst-plugins-{base,good,ugly} as well (not sure if needed) <rekado>I have GST_PLUGIN_SYSTEM_PATH and GST_PLUGIN_PATH set to whatever the search path specifies. <rekado>(it's $GUIX_PROFILE/lib/gstreamer-1.0) <rekado>with these settings the videos appear in epiphany <rekado>last I tried I can only hear audio from one of the three videos. <civodul>they have a "direct download" link to the MP4 <civodul>it looks as if that one had 1 frame per second or something <rekado>I'm looking at the Future of Guix recordings. I don't see 1 fps here. <civodul>yeah that one LGTM, apart from the sound/image delay <rekado>and obviously the start and end times are wrong. <rekado>oops, the end is not on video at all. <rekado>it just goes black before we were done. <civodul>that's because it lasted longer than expected presumably :-) <thomasd>but seriously, could be useful to keep track of old bug reports. <civodul>thomasd: right, though we can see them anytime by looking at the list of open bugs :-) <thomasd>yes, with emacs-debbugs that's also an option (in the debbugs web-interface, this is spread across different pages, less handy) <snape>"shepherd: Service user-homes could not be started." Is that a bug? <snape>(on guix system reconfigure) <snape>I can't find any relevant log <thomasd>snape: I have the same issue. do you have /home on a separate partition? <thomasd>so I wonder if it could be that guix is trying to start a service "user-homes", but fails because this service isn't implemented in the installed version of guix? <thomasd>I've been wondering recently how that works: if you reconfigure from a git checkout, and a new service is added (e.g. user-homes), how is this service found later on? <snape>thomasd: I'm not sure I understand how it works either. But I think my version of Guix is up to date. <thomasd>yes, I just updated here, and the error remains. I'm now pretty confused about which version of guix is where, though. :) <thomasd> sudo /gnu/store/hnbqdmfh...-guix-0.12.0-4.d9da/bin/guix --version => guix (GNU Guix) 20170213.1 <thomasd>/gnu/store/hnbqdmfh...-guix-0.12.0-4.d9da/bin/guix --version => (GNU Guix) 20170208.21 <bavier`>thomasd: the version reported will depend not just on the path, but on the latest 'guix pull' done by the respective user <thomasd>bavier: is this a link in the user profile somewhere? I naively thought the user's guix would be in ~/.guix-profile/bin, but that's not true <snape>thomasd: the user's guix is ~/.config/guix/latest, I think <jmi2k>Future packages should be sent to guix-patches, right? <efraim>is there an easy way to import patches that haven't been merged to guix-patches? <efraim>or is forwarding them the best option? <rekado>efraim: I don't know. Maybe there's a debbugs feature to import an existing mbox. <clacke[m]>I just had some trouble doing guix pull, because I have left my machine untouched since November or so. <clacke[m]>Had to install binary guix-0.12.0 to pull latest. <clacke[m]>Has anyone thought about how to do upgrades painless when there are API-breaking changes to the package definition code? <avoine>clacke[m]: at fosdem we talked about how the guix pull was not optimal <clacke[m]>Detect if current daemon is new enough, otherwise spit out "hey, maybe pull --url=...guix-1234lkajsdfl....tar.gz and install guix before trying again". Something like that would be a good first step. <clacke[m]>Now I tried pulling like 8 different commits with "updated guix-devel" and they all failed, so I gave up and took the binary. <avoine>IIRC most of Guix developers are getting updates directly from Guix's git repos <clacke[m]>Yes, "unbound variable" or "parameter blah expected". <clacke[m]>As long as you are up-to-date continually it's fine. But if you are out of the loop for a while, you have missed the upgrade treadmill and a big leap is not possible. <clacke[m]>;;; Failed to autoload canonical-package in (gnu packages base): <clacke[m]>;;; ERROR: In procedure module-lookup: Unbound variable: license:wtfpl2 <clacke[m]>The other examples have been pushed out of my scrollback now. But I think one was, some function received only "#f" when it expected two parameters. <clacke[m]>So there's a commit somewhere that is the turning point, which can be compiled by the old guix, and which can compile the new guix. <clacke[m]>Would be great if that were documented somewhere useful. <luser1>Under (info "(shepherd) Jump Start") there's a reference to ‘doc/examples/’, but I can't find it on my system. Is it included on guixsd systems? <lfam>luser1: I'm not sure if it's included in the generated info document or not. But, you can get the Shepherd source tree like this: <lfam>`tar xf $(guix build --source shepherd)` <lfam>And, those files will be in the source tree provided by that command <lfam>Of course, you can also use Git to clone the repo <lfam>luser1: Are you looking for examples of Shepherd services, in general? <luser1>My use case is simple, I just want to create a tor daemon. <lfam>I recommend cloning the Guix Git repository and looking at the services in 'gnu/services/' alongside their documentation in section Services of the Guix manual <lfam>Those are the system services that we currently have available. In fact, we have a tor-service available <efraim>signing keys from FOSDEM, almost signed my own key <luser1>lfam: These system services, I can only enable them as root? <lfam>luser1: Right, only a privileged user can use `guix system reconfigure` <luser1>What does reconfigure have to do with anything? <luser1>So, a user can't run his own instance of the tor service? <lfam>luser1: `guix system reconfigure` is used to change the installed GuixSD system. Since it affects all users, it requires root privileges. <lfam>Users can run their own services, using a different mechanism. <lfam>I don't have much experience with Tor, so I don't know whether or not it requires privileges to run a Tor daemon <luser1>Hm, so enabling services system wide is considered changing the GuixSD system and that requires a system reconfiguration? <luser1>lfam: On a debian system, users can run tor as a daemon, iirc. <luser1>I'll take a look and poke around. <lfam>I also recommend you read or at least skim the Guix manual section 'GNU Distribution'. GuixSD is quite different from Debian <luser1>Was just curious if a user could interact with the services provided by networking.scm <lfam>Those are system services, so you need root to enable them. But, in some cases you could adapt the code and use them unprivileged. <luser1>Is there a reason why they aren't also provided for users? <luser1>Or a mechanism to for the admin to enable them for users? <lfam>Well, in many cases an unprivileged user simply can't use the software <lfam>For example, unprivileged users can't bind to port 22, for SSH <lfam>Of course all users can use the running SSH daemon <luser1>I suppose it doesn't make sense for each user of a system to be able to run a tor service, lol. <lfam>For many questions about Guix and GuixSD that start with "Is there a reason why...", the answer is "because nobody has done the work yet" :) <lfam>But many of the networking services do require privileges to start <luser1>lfam: Areas to possibly contribute :) ***kelsoo1 is now known as kelsoo
<luser1>I can't join #emacs due to not being registered so hope you all don't mind: I'm getting: Wrong method specification for ‘ssh’ <luser1>When I try to edit a file from tramp. <luser1>Trying to edit a local file as root from emacs. <luser1>And I get the same error when trying sudo: instead. <luser1>I simply get the same error with s/ssh/sudo/ <amz3>luser1: what is your ssh password? <luser1>My root password, as that's who I'm trying to login as. <efraim>didn't we have something special you had to do with tramp and guix/guixsd? <luser1>I really should start looking at the mailing list for things. <mekeor>where would you prefer to put a package for dzen? (gnu packages wm)? <slyfox>every time i do 'guix pull' during compilation the same message pops to break percentage: 'loading... 24.4% of 577 filesrandom seed for tests: 1487022547' <slyfox>should not that 'random seed for tests' be printed only at failure? <slyfox>seems to come from 'guix/tests.scm: (format (current-error-port) "random seed for tests: ~a~%"' <lfam>rekado: Thanks for working on the videos <lfam>"I would try not to upgrade because I want to use the computer" ;) <luser1>First time rebuilding my system; was beautifully painless. <lfam>Be sure to tell us about any painful parts, too <luser1>When I experience pain, I will be sure to yell and throw bananas at you all. <lfam>It's okay, if you wrap the bananas in patches ;)