IRC channel logs
2017-01-01.log
back to list of logs
<bldtg>why am I building guix? isn't setting GUIX_PACKGE_PATH enough for testing packages before submitting? <ng0>to submit and be integrated into master, they must be patches based on what's in the repository, not outside of it <bldtg>if I clone the repository, change the package, and submit the patch, isn't that correct? <ng0>bldtg: Don't understand my silence as anything more than me just being too tired to explain or understand all of your problem today. <mange>Does anyone use awesome 4.0 on GuixSD on a laptop here? I'm having an issue with my windows disappearing if I put my laptop to sleep by closing the lid. It looks like the display is removed when I close the lid and re-added when I re-open it. Does anyone have any idea what might be going on? <ng0>mange: I have other problems here with the new awesome version. <ng0>but I have yet to replicate them to see if they weren't just problems of other pplciations <mange>What problems have you been running into? <ng0>occasionally when I switch the screen (tag? I never used awesome words) from 1 to 2 for example, I get to see pieces of the application I saw in the previous screen, visible in a space between the new added window bar (the one with the name and on the right with action symbols) and the application itself <ng0>one of these things you better make an screenshot of then to explain <ng0>btw, I'm trying to fix bug25304 (libtool ltmain) <ng0>have you checked your config for incompabilities to 4.0? <mange>I started with the 4.0 config and modified it. <mange>But given nobody else has this problem I was wondering what was different about my GuixSD setup that would cause this. <ng0>okay, I've read the issue and it might affect other people too. depending on how this ends up in their source, can you try to act accordingly, for example add the patch to guix? of course only when the issue is resolved from both yours and their side <mange>I don't think we should patch it on the Guix side unless it's a Guix-specific issue. <ng0>it's an application specific issue <mange>Then we should get it patched upstream rather than patching it ourselves. <ng0>that#s not what i meant <ng0>try to read again what I wrote <rekado>I remember some of you were really interested in coordinating bootstrapping efforts <rekado>this is why I’d like to point you at bootstrappable.org <mange>"... for example add the patch to guix?" <rekado>it still needs some editing, but it’s close to becoming the home for the bootstrappable builds project, which was started at the last reproducible builds summit. <ng0>If the patch is in upstream, a commit in their master, we can add it to our patches if it really affects more people. that's my opinion, as I don't really believe in the "we should carry as little patches as possible" makewish <rekado>I’d be happy if someone could take a look at the pages and provide some edits to make them clearer. <rekado>I’m a little preoccupied for the next couple of days, so I won’t be able to do this myself. <mange>So far I'm the only person who's had the issue (according to them on IRC), so it's a bit premature to say it's a significant bugfix. <rekado>ng0: the policy does not prevent us from adding patches that are already included in upstream. <rekado>ng0: we want to avoid debianification, where we essentially fork upstream packages. Ideally, this means that we don’t carry any patches that are not in upstream releases. <ng0>I think that's a utopian dream... but we'll see sooner or later <rekado>looking at gnu/packages/patches you see that we already have quite a few patches. This doesn’t contradict what I wrote above. <ng0>that's not what I meant <ng0>I mean last year I talked to some people involved in Gentoo, and I always thought they had a very liberal approach at including patches. But it seems that very often this is because communication with upstream doesn't work out, etc. Oh, this reminds me that I really like their deprecation strategy for packages.. could be useful for us as we have no policy for that at the moment <ng0>anyone got an idea why (add-after 'patch-shebang 'restore-ltmain-shebang (lambda* (#:key inputs #:allow-other-keys) (substitute* "build-aux/ltmain.sh" (((string-append (assoc-ref inputs "bash") "/bin/sh")) "/bin/sh")))) doesn't work out and the shebang remains the same? <rekado>use a fixed expression, not (string-append …) <rekado>also, ltmain.sh comes from ltmain.sh.in <ng0>sure, but the last patch.shebang phase will override anything i've restored <ng0>so I need to do this after the patch-shebang phase <mange>'patch-shebang isn't a phases, I don't think. 'patch-shebangs is, though? <mange>That's ironic that I would accidentally type "phases" there. <ng0>yeah, but how would you fix it otherwise, rekado ? won't the second run of patch-shebangs, the one after patch-source-shebangs, change the shebang if we would fix it in the .in file? <ng0>oh, you mean like an regexp for a the line including /gnu/store after #! instead of the string-append <ng0>but regarding patches, I'm only half pessimistic. I'm working on a build system for GNU Health only after I got positive feedback from upstream.. As we need something different than they have now, and every other distro needs this too.. so that's something where distro micro-forks can be avoided. So maybe it's not so bad.. <ng0>fixed... althought it can be done more pleasantly, i'll sent a first patch version for the bug #25304 <ng0>what's the service to add the console keyboard layout again? I want to try and add neo2 layout now <rekado>ng0: try the manual index searching for “console” <ng0>rekado: thanks, I'll separate the commit <ng0>I think I should add a package for the neo layout for kbd, because there should be a license mentioned... right? <ng0>otherwise I can just use what I have now and put that into the kbd package <cbaines>Does anyone happen to know how files in the store often end up with a modifed date of 1st of Jan 1970? I have written a derivation that generates files in the store, but I've obviously missed/broken this feature, as the files generated have different timestamps. <cbaines>Ah, I've just found the reset-timestamps function, which looks promising :) <civodul>cbaines: the daemon resets timestamps upon completion of a build, i think it's called canonicalizePath in the C++ code base <civodul>but yeah, same thing as reset-timestamps :-) <ng0>I think I need help with adding this input to kbd.. what I tried ends up as being downloaded but inaccessible to the kbd package <ng0>I'll send the patch for review <quigonjinn>Is it ok to bump a patch in the mailing list, which has been accepted for a month now, and not pushed? <JamesRichardson>Hello #guix. I'm trying to utilize the offload feature of guix daemon. Is there a howto or anything other than the manual? <JamesRichardson>I've managed to get ssh james@thor guile -c "'(use-modules (guix config))'" to work. guix offload test fails. <civodul>JamesRichardson: could you paste the 'guix offload test' diagnostic? <JamesRichardson>guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... <JamesRichardson>guix offload: 'thor.jamestechnotes.com' is running guile (GNU Guile) 2.0.13 <JamesRichardson>2404: 18 [save-module-excursion #<procedure d17900 at ice-9/boot-9.scm:4051:3 ()>] <JamesRichardson>1727: 16 [%start-stack load-stack #<procedure d25440 at ice-9/boot-9.scm:4047:10 ()>] <JamesRichardson> ?: 14 [primitive-load "/gnu/store/4b04yirlgvx3qapw6yb8j7sxrymfc09w-guix-0.12.0-2.b291/bin/.guix-real"] <ng0>please use a paste service <JamesRichardson> 160: 12 [catch srfi-34 #<procedure 1b5d760 at guix/ui.scm:426:2 ()> ...] <JamesRichardson> 639: 9 [for-each #<procedure assert-node-has-guix (node name)> (#) ...] <JamesRichardson>ERROR: In procedure regexp-exec: Wrong type argument in position 2 (expecting <ng0>rust build system is now usable.. I think I'll give mass importing a go, fix the packages next week and send in the chain of rust packages then <jmi2k_>How can I keep some personal recipes in my home dir? <jmi2k_>but it should point to a folder that has gnu/packages subfolder? <rekado>jmi2k_: create a file $GUIX_PACKAGE_PATH/my/packages/something.scm <rekado>with a module name (my packages something) <rekado>it’s important that the path and the module name match. <rekado>it doesn’t need to be a gnu/packages subdirectory. <jmi2k_>So guix will find it no matter the name of the subfolder? <rekado>the import thing is that the module file is in a directory that is in GUIX_PACKAGE_PATH <rekado>but make sure that the path to the file and the module name match. <civodul>JamesRichardson: could you check if there's a 'guile' process running, with the --listen argument, on the target machine? <ng0>building rust is weird <ng0>most weird is the winapi crate I need to package because... reasons... <rekado>bah, Hugs cannot be used to run GHC 3.02 as is, because of recursive module dependencies in the GHC sources. <rekado>Hugs implements almost all of Haskell 98 except for recursive module imports <ng0>we should somehow configure our rust <ng0>I hope I can just ignore this <ng0>because it would mean packaging 30 - 40 packages less <rekado>even ghc 0.29 has a recursive module dependency <rekado>I don’t think we’ll be able to bootstrap GHC with Hugs alone. <rekado>next attempt: run nhc with Hugs and use that to build a version of GHC. <ng0>okay, it seems that dependencies which are windows platform specific can be ignored.. if this turns out to be true (so far i have just "bulk" packaged), I will add this to the documentation <ng0>Any rust hackers interested in helping to edit synposis and descriptions of lots of rust packages? <sneek>lfam, albertoefg says: that I think he is hiding to not play hedgewars <sneek>lfam, albertoefg says: happy new year <davidl>If I add (gnu services networking) I can add (dhcp-client serivce) but I will get an error saying it's been added more than once - probably because I have %desktop-services declared, however if I remove it I get an unbound variable error for dhcp-client-service. Is there a way to go about this? <thomasd>lfam: I left without a thank you last time... so thank you :) <lfam>thomasd: Did you figure out the problem? <thomasd>turns out I couldn't login with xfce or gnome due to bad ownership on my /home <lfam>Did Guix create that /home for you? <thomasd>yes, but I remember that I originally messed up the file-systems record in my system config, so perhaps that caused the problem <lfam>Do you remember how the ownership was incorrect? Who owned it? <thomasd>ouch, should have taken a note but.. no, it was a number, something like "3301" or so, ... <lfam>Maybe your user and your user's home directory were created, and then there was an unrelated problem, as you mentioned. You fixed the problem and re-started the initialization. Your user was recreated with a different UID, which no longer corresponded to the existant /home <lfam>Was it /home, or /home/thomasd that was owned by the non-existant user 3301? <thomasd>so yes, you explanation sounds very plausible <lfam>We try not to clobber existing /home/thomasd directories, so I'm not sure the best way to avoid this issue <lfam>Hopefully it doesn't come up too often :) <paroneayea>dumb question: which package provides lpr in guix, if any? <ng0>rust dependency trees are a rusty jungle <lfam>paroneayea: Could it be in CUPS? <ng0>I feel like falling down the rabbit hole <ng0>oh, almost done. oops, 20 more <thomasd>lfam: I suppose it's a matter of not messing up your system configuration description. Maybe installer/configuration tools can help with that in the future. <ng0>paroneayea: but it is in cups in guix <paroneayea>guess I had the cups service running but not the cups package inmy environment :) <lfam>thomasd: Most of the problems I've had my configuration cause the `guix system` action to fail completely, rather than leave the user with a subtle problem like yours. <lfam>Initialization is brittle compared to reconfiguration <lfam>As always, Help Wanted :) <paroneayea>lfam: but thomasd is right in that installer/configuration tools can probably help get initial installation right :) <thomasd>I'd be happy to help. I've only been using Guix on top of ubuntu so far, but will probably try dual-boot soon in order to experiment more <thomasd>I'm already very impressed with the system as it is :) <thomasd>in an unrelated question: the manual mentions running a system in a container, sharing the store with host. I wonder how that works with garbage collection roots? <lfam>What is possessive form of 'curses'? <civodul>thomasd: running processes in general lead to more GC roots <civodul>so if a running process has /gnu/store/foo in an env var, then /gnu/store/foo is not GC'd <thomasd>and will the container know about the gc roots of the host? <thomasd>I'd like to share a store between a full GuixSD system and Guix running in an another distribution on the same machine. Are people doing such a thing? <lfam>civodul: We're still waiting for the guix-daemons on the armhf and mips64el builders to be updated, right? <civodul>lfam: i think so! seems like people have been partying or something ;-) <jmi2k_>davidl: did you solve your problem? <lfam>civodul: Just that package? <lfam>Right. I just `guix build -S certbot --no-substitutes` and the PyPi URL redirections worked as expected <alezost>thomasd: I share the store between GuixSD and Guix on another distro <ng0>I think it's not very review friendly if I post a 50+ patches series for "please help me fix descriptions and synopsis because I have 0 clue about the rust language"? <thomasd>alezost: how does GuixSD know about user profiles on your other distro? <thomasd>I'm afraid running `guix gc` on one side would clean up stuff required by the other side <lfam>civodul: Yup. I'll push a fix to make it use pypi-uri <alezost>thomasd: I use the same profiles on both systems, so 'guix gc' doesn't remove needed stuff <thomasd>you mean you also share /var/guix/profiles between both systems? <thomasd>or you choose to install the same stuff on both sides? <alezost>thomasd: I use the same store, the same /var/guix/profiles and actually the same HOME on both systems. I just have several lines in my /etc/fstab on a foreign system that make several bind mounts to a partition where GuixSD is placed; here is an excerpt from the /etc/fstab: http://paste.debian.net/905947 <davidl>jmi2k_ thanks Im gonna try that and then Ill reply back how it went. <thomasd>alezost: great, thanks! I'll try to set up something similar. not having to retrieve everything twice should save some time! <buenouanq>so, postgres and php and things should be installed under the nginx user right? but the nginx user"s shell is set to nologin and I'm not supposed to change this <buenouanq>it also never made /home/nginx which seems strange <buenouanq>I'm just unsure as to how I should be approching this, and everything written about it assumes you're using something Debian based. <jmi2k_>Any ideas of why setting the suid bit of X causes a kernel panic? It seems GuixSD can't find the file at boot and suddenly it crashes. <jmi2k_>I have an screenshot (taken with my phone, I couldn't do better) of the kernel output just before it crashes <lfam>jmi2k_: You're trying to alter the files in /gnu/store? <buenouanq>so it seems the nginx service makes it"s own nginx user that over rides my explicitly declared user of the same name? <davidl>jmi2k_ I got stuck at Unbound variable: remove and I don't know how to enable that expression. <jmi2k_>davidl: did you add (gnu services networking) ? 