IRC channel logs


back to list of logs

<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>but then thought that maybe it is
<civodul>(the problem solved by this patch is exposed by Guile's test suite)
<braunr>what problem ?
<civodul>the time unit thing discussed at the URL above
<civodul>ACTION -> zZz
***jonsger1 is now known as jonsger
***orly_owl_ is now known as orly_owl
***jonsger1 is now known as jonsger
<civodul>Hello Guix!
<rekado>I’m having problems with i686
<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: so, what problem ? :)
<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
<civodul>braunr: i was referring to this discussion:
<civodul>efraim: yeah, you're probably right
<braunr>civodul: yes i got that
<braunr>but i still don't see the question
<braunr>ah the question is : is glibc the right place ?
<civodul>sorry :-)
<braunr>why wouldn't it be ?
<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>let me check
<braunr>well my description is too light :)
<thomasd>Hi #guix
<civodul>hey thomasd
<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>ah yes
<braunr>the real problem is a discrepancy between glibc (which was fine) and /proc
<civodul>could you reply in that thread (, just to keep track of it?
<braunr>what do you call core-updates ?
<civodul>it's a branch
<civodul>this question was for Manolis
<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.
<efraim>Oooh that sounds fun
<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>so far it’s just me :)
<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
<braunr>that looks nice indeed :)
<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
<civodul>rekado: sounds cool!
<civodul>rekado: when would that be?
<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>i feel honored :-)
<civodul>i'll see if that's doable
<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
<efraim>I wonder if it would be hard to extend so it also reported FTBFS or unsupported platforms
<civodul>efraim: i tried but stumbled into a unreliable test:
<efraim>mmm, i see
<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..
<efraim>I was going to use vim-pathogen and mr to keep my plugins up-to-date
<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
<rekado>ACTION --> lunch
<ng0>oh, speaking of funding. for people living in Germany, the second round of prototypefund is on. 46 days until deadline of submissions
<rekado>ng0: neat!
<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 :)
<civodul>the fun begins ;-)
<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.
<roelj>rekado: Ah.. right.
<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
<roelj>rekado: Wow..!
<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.
<civodul>rekado: is lsyncd a tool you wrote?
<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.
<efraim>non-free firmware?
<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>fun :-)
<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.
<ng0>I already sent an correction to the name, but is the maintainer field I suggested okay with all of you? or should it just be "The Guix team"?
<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 :)
<ng0>okay, thanks :)
<ng0>these are just my words, and I'm only adjusting myself in this whole freesoftware politics.. but I think the reason I gave is half-correct:
<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>hmm, ok
<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.
<civodul>rekado: and no solution?
<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>let me check
<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>and I can hear the audio.
<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>I'm adjusting this now.
<civodul>great, thanks
<rekado>oops, the end is not on video at all.
<rekado>it just goes black before we were done.
<rekado>oh well.
<civodul>that's because it lasted longer than expected presumably :-)
<civodul>would anyone like to get weekly messages like this: ?
<thomasd>civodul: I would love that ;-)
<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>did you install guix before 1/2? because I see that the user-homes service was only added to guix recently (to fix
<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
<thomasd>ACTION scratches forehead
<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
<thomasd>snape: yes it is. thanks.
<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.
<braunr>"failed" ?
<braunr>because of the api you mean ?
<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]>is one example
<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?
<luser1>I can see it here
<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
<luser1>lfam: Thanks
<lfam>Of course, you can also use Git to clone the repo
<luser1>Which do you prefer and why?
<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
<luser1>Will do
<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?
<luser1>I can only run it system wide?
<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.
<lfam>I'm actually not sure what is the best documentation to show you for user services. The shepherd manual does describe it in general. I found the examples in this file useful when I was getting started:
<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.
<luser1>tor daemon
<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 :)
<lfam>Yes :)
***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>efraim: Seems this is it:
<luser1> (setq tramp-remote-path
<luser1> (append tramp-remote-path
<luser1> '(tramp-own-remote-path)))
<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)?
<bavier`>mekeor: (gnu packages xdisorg)?
<rekado>some of our FOSDEM videos are already available here:
<mekeor>nice :3
<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 ;)