***iyzsong1 is now known as x-iyzsong
<davexunit>hmm, I reconfigured my system with elogind but I still don't have working suspend when I close the lid of my laptop <rekado_>when R sees that JAVA_HOME is defined at configure time it will compile ./tools/getsp.java whose only purpose is to be used by "R CMD javareconf". <rekado_>all that javareconf does is to update some files in $R_HOME/etc that contain environment variables. <rekado_>this is used when the system java has changed relative to the java version that was used at the time R was built. <civodul>maybe just add this explanation in a comment <civodul>in case someone in the future wonders <rekado_>I also noticed that the info docs are not built, but the vignettes are. I think the info docs are more important than any vignettes for base packages. <rekado_>this requires a new build phase to run "make info" <rekado_>I'm building the modified version locally right now. Will prepare patches once I confirmed that it all works as expected. <davexunit>so Debian is reporting that they have a reproducible linux kernel build <davexunit>civodul: when writing nginx-service, I couldn't find a way to add arbitrary additional actions using the Guix service interface. am I missing something or is it not yet supported? <civodul>davexunit: indeed, that's unsupported <civodul>we need to extend <service> for that <civodul>and then dmd itself allows you to define whatever action you want for services <davexunit>civodul: yes, I use that dmd feature a bit and was sad when the guix wrapper didn't support it. <davexunit>so in the future when we don't have to reboot after reconfigure, we can tell nginx to 'reload' its config rather than kill and restart the process <davexunit>which is a crucial feature for us web folks that need 0 downtime config updates <civodul>yeah definitely, i've used it a lot while fiddling with nginx on hydra.gnu.org <civodul>well, i'll give it a try if you don't beat me at it :-) <davexunit>civodul: if only all servers had REPLs, then everything would have a "live reload" mechanism. <civodul>davexunit: you mean one REPL per dmd service? <davexunit>civodul: I meant in a glorious utopian world where people used languages with REPLs :) <davexunit>why do I have to send SIGHUP to nginx? I should just be able to connect to the REPL! <davexunit>nginx is a big improvement on apache, but it has one huge regression: all extensions *must* be linked at compile time. <civodul>not as expressive as a REPL, but in the Hurd every process can reply to a bunch of RPCs <civodul>which include queriying/setting env vars, file descriptors, etc. <davexunit>the hurd sounds nicer and nicer the more I hear about it. <civodul>i guess i don't know much about nginx's extension <civodul>i suppose on hydra we just use the built-in caching policies and stuff <civodul>static as in you choose them a configure time? <civodul>i guess it's for Performance Reasons <civodul>i must say i'm impressed by how fast and lightweight it is <davexunit>rekado_: what terrible thing have you discovered this time? <rekado_>nothing new. I'm surprised the rubygems situation continues to disgust me for so long. <davexunit>it's nice to be among people that realize there's a problem. <rekado_>dependency cycles in packages made by the same person! <rekado_>and advertising packages as "light" but they have massive dependency graphs <davexunit>or maybe it was libgit2 in general... which isn't ruby. <davexunit>rekado_: I'm terrified to try to tackle nodejs. <rekado_>I have difficulties figuring out what's worst: Ruby, Java, or nodejs. <rekado_>with Java there's the problem that people rely so much on binaries. <davexunit>in my very brief look at what a maven importer would look like. <davexunit>sometimes I just want to flip a table and quit. <rekado_>I seriously thought about this many times. <davexunit>quit software development, go into the woods, build a house, never come back. <civodul>we need to contribute to the software mess in our own ways <davexunit>I'm thankful that the Guile community generally understands these issues and has avoided them. <efraim>you could go into the woods, build a house, and code anyway, ala joeyh <davexunit>joeyh is a haskell-writing, off-the-grid-living machine. <davexunit>as long as I don't have to confine myself to a language with static types <davexunit>I read a section of SICP yesterday that slipped in a nice little argument against static typing. <rekado_>davexunit: I'm trying to package ruby-ffi. The build phase is very short, but during the check phase it tries to compile libffi. <rekado_>does this mean that it actually needs libffi as an input at runtime? <davexunit>rekado_: that is because it uses native extensions, it's unoptimal but I don't know a way around it. <davexunit>basically, the extension needs to be compiled twice. <davexunit>thanks for this, btw. ruby-ffi is important. <davexunit>the smallest ruby application requires 76 ruby gems transitively. <rekado_>ruby-ffi is just one of the nodes on this big graph for buildr. <davexunit>there's a tool in nixland called "bundix", which reads in bundler Gemfiles and spits out a big nix expression <rekado_>I'm just doing all this because I want to have a reason not to work on that poster for an event next week... <davexunit>I'd like something like that, but it's quite ugly and prone to issues. <civodul>"First, downloads are now performed as the unprivileged user "_apt" rather than as root." <civodul>"Earlier releases only checked uncompressed hashes, and only on some files" <davexunit>mark_weaver: I forgot where we ended up after our last conversation about this: is it okay if I re-enable container tests for the guix-devel package? <davexunit>ACTION realizes that we aren't on distrowatch.com <mark_weaver>davexunit: I don't remember exactly what the issues were before, but if you think they've been addressed, then feel free to re-enable them :) <davexunit>mark_weaver: I've addressed them awhile ago and built guix-devel successfully on my own computer <davexunit>we didn't update the snapshot at the time due to pending security updates <davexunit>hmm, I wonder what is needed to make the volume up/down buttons work on my thinkpad <alezost>davexunit: at first I would check with "xev" whether the keys are recognized <mark_weaver>wingo: earlier, davexunit wrote: <davexunit> hmm, I reconfigured my system with elogind but I still don't have working suspend when I close the lid of my laptop <mark_weaver>(although I'm somewhat unusual in that actively don't want my laptop to suspend when I close the lid, but that's a separate issue :) <wingo>happily you can configure the lid action ;) <wingo>so first of all, i guess that if you run ps auxw you see the elogind process, right? <wingo>and if you manually echo mem to /sys/power/state it suspends <wingo>so do a ps auxw, find your elogind, then dmd stop elogind <wingo>then run it manually from the console so you get logs <wingo>incidentally does dmd send the logs anywhere? <davexunit>wingo: it's up to the program in question to write logs <mark_weaver>I think the stdout and stderr of things just goes to tty1 now, which is terrible :-( <wingo>davexunit: what about stdout/stderr <wingo>mark_weaver: does it go to tty1? <wingo>anyway that's been a real problem working on services <wingo>but happily you can run elogin on its own and you get them in the terminal <davexunit>I think we should prioritize some dmd hacking <wingo>so, if you run elogin directly from the console what does it print? <wingo>what does it print initially, and then what does it print when you close the lid and reopen <wingo>running it directly without setting the env var will effectively load the default config <wingo>which is the same as the default (elogind-configuration) <mark_weaver>ACTION boots up his Thinkpad; been using the YeeLoong lately <wingo>what did it print at startup? it should be only like 5 lines so you can paste here <davexunit>$ sudo /gnu/store/00hn46n50s1li7whb8lzir2670pls3a8-elogind-219.12/libexec/elogind/elogind <davexunit>Failed to save seat data /run/systemd/seats/seat0: No such file or directory <wingo>the /run/systemd and /run/user mounts <wingo>see civodul's response there <mark_weaver>I guess we should probably just add those to %base-file-systems, as civodul suggested <wingo>you might be able to try locally without rebooting <wingo>not the guix way, but maybe it's useful ;) <davexunit>why do they have to be tmpfs mounts? does this thread explain <wingo>they have to be tmpfs or ramfs <wingo>the idea is that they are not persistent <wingo>and that logind when it starts wants to rm -rf some parts of them <wingo>but if they aren't tmpfs or ramfs it gets cold feet, thinking maybe it would rm-rf some important part of the filesystem <wingo>"it gets cold feet" <- it == systemd's rm_rf() routine <davexunit>what do you folks think about adding a 'file-systems' field to <service>? <davexunit>like how we have 'user-accounts' and 'user-groups' <wingo>davexunit: would it be useful for any other service? <davexunit>not sure yet, but I don't like that the service isn't self-contained <wingo>you'll lol when you see the pam stuff :P <davexunit>maybe we can just tweak the activate script then <davexunit>such that it mounts the needed file systems. <wingo>i think the file systems should be there regardless. they form a kind of api to user space <mark_weaver>davexunit: can you post to the ML about it? maybe as a reply to civodul's response to wingo's post, where civodul suggested adding them to %base-file-systems? <wingo>and you'd want to allow userspace to attach monitors on those directories <wingo>and if restarting the logind service unmounted and remounted the directories, that would be pretty unkind to apps <davexunit>wingo: it wouldn't unmount and remount, just mount if they didn't exist yet. <wingo>regardless i think civodul's suggestion is the right thing in the short term, seems to me anyway <davexunit>prior art: the postgresql-service has an activate script that ensures the DB cluster has been initialized <mark_weaver>wingo: fyi, after adding the filesystems, suspend-on-lid-close still doesn't work for me. <mark_weaver>the only output from elogind now is "New seat seat0." <wingo>there's no output when the lid closes? strange <mark_weaver>I wonder if it's related to the fact that I'm using libreboot <mark_weaver>I'll be curious to hear if adding the filesystems fixes it for davexunit <davexunit>mark_weaver: haven't tried yet, been busy with other things <wingo>the other possibility is that your DE is catching the lid switch event <wingo>evidently my xfce is not as good as it could be <davexunit>it seems that we don't yet have the xfce power management utility <wingo>apparently elogind grovels through udev looking for input subsystem devices that have the 'power-switch' tag <wingo>also, mark, you're not docked are you? <wingo>the default for docked lid-close is not suspend <davexunit>okay, that didn't work. but I'm on AC power, so maybe that makes a difference. <davexunit>my elogind log is the same as mark's: New seat seat0. <wingo>lemme dump what it prints for me <mark_weaver>wingo: I'm not docked. I was plugged into mains power, but just now I tried unplugging and then closing the lid, and that still did nothing. <wingo>mine when it starts does this: <wingo>Watching system buttons on /dev/input/event2 (Power Button) <wingo>Watching system buttons on /dev/input/event9 (Video Bus) <wingo>Watching system buttons on /dev/input/event0 (Lid Switch) <wingo>Watching system buttons on /dev/input/event1 (Sleep Button) <wingo>Watching system buttons on /dev/input/event5 (ThinkPad Extra Buttons) <wingo>New session c1 of user wingo. <wingo>the last line might be because of my pam_elogind.so things <wingo>did my commit add elogind to udev? <wingo>if not perhaps that's the problem <wingo>so i guess we need to map over base services and add elogind to base udev <mark_weaver>yeah, we definitely need a better way of dealing with these things :-( <davexunit>this is why we feel the need to move away from using monadic values for this <mark_weaver>for now, I don't use %base-services. I just have all of it extracted out into my OS configuration. <mark_weaver>but obviously that has its own problems, like having to update it manually when I see commits to %base-services or %desktop-services <davexunit>to use SICP terms, the "means of combination" is lacking here. <wingo>mark_weaver: yeah me too re base-services <davexunit>I still don't understand what udev and dbus do :( <davexunit>mark_weaver: awesome. I'll reconfigure after work. <mark_weaver>the thinkpad hotkey (Fn F4) for sleeping also works. <mark_weaver>now, to see if I can disable suspend-on-lid-close but keep that hot key working... <davexunit>I wonder if there ought to be desktop-services and base-services procedures to parameterize the variable stuff <mark_weaver>they should probably be procedures, but I'd rather not have to pass the lists to those procedures by hand. <mark_weaver>my current thought is that maybe services should be able to request for things to be added to udev and dbus. <mark_weaver>preferably using a general mechanism, not one that makes 'udev' and 'dbus' special. <davexunit>mark_weaver: there could be sane defaults for those arguments. <davexunit>mark_weaver: and yes, that would be nice if it were generalized. <mark_weaver>I see that our elogind service is quite admirably customizable :) <mark_weaver>so, I set 'handle-lid-switch' to 'ignore', but I wonder if I also need to set 'lid-switch-ignore-inhibited?'? seems odd to have to avoid inhibiting my own customization. <mark_weaver>the default value of lid-switch-ignore-inhibited? is #t. I wonder why. <davexunit>that leads me to wondering if we should be encouraging more scheme->config-file converters <mark_weaver>we'll have to be careful with the "hibernate" hotkey, since at present our initrd doesn't handle resume from hibernate. <davexunit>for elogind it was rather simple to cover all the possible config values, but other software is more complex. <davexunit>so I guess we should always deal in terms of text files, but provide nice procedures that generate them where feasible. <mark_weaver>okay, good, I didn't have to change 'lid-switch-ignore-inhibited?'. <mark_weaver>hmm, although I wonder if turning that option off will mean that my suspend might spuriously wake up from suspend while inside a bag. <wingo>yay that the udev thing fixed it :) <mark_weaver>I found that to be an issue with my thinkpads, so I worked around it by making a little script that repeatedly suspends every 10 seconds. I Ctrl-C out of the loop when I really mean to wake it up. <mark_weaver>maybe I should give up on my preference to inhibit suspend-on-lid-close. <mark_weaver>the reason is that I like to close the lid when I carry my laptop around the house, even while it's currently working on a compile or something. <mark_weaver>wingo: I wonder if 'handle-hibernate-key' should default to #f for now, since we don't yet handle resume-from-hibernate in our initrd. <davexunit>I wish it were easier to dynamically specify the behavior <wingo>mark_weaver: sounds fine to me <wingo>how difficult would it be to fix our initrd? <wingo>sounds like it wouldn't be that bad but i dunno <davexunit>things always sound easy when you aren't intimately familiar with the implementation details :) <mark_weaver>I actually need this anyway, since my YeeLoong has issues with suspend-to-ram, and my Thinkpad recently lost it's ability to charge batteries :-( <mark_weaver>but I've got too many high-priority things to work on right now. I'm spread too thin. <wingo>so apparently resuming is easy <wingo>if you have a swap partition anyway <wingo>just write something to /sys/power/resume in the initrd and you are done <mark_weaver>the method I've always used is to simply pass 'resume=/dev/sdaN' on the kernel command line, but I know there's another way to do it from within the initrd, and that's more general because it supports cases where modules need to be loaded in order to access the swap partition. <wingo>i wonder what writing disk to /sys/power/state does when you didn't boot with resume=/dev/sda2 or whatever <wingo>the currently configured swap, i guess? <mark_weaver>if there's only one swap device/file, they could use that one, but I don't know what it would do if there's more than one. <davexunit>that reminds me, I need to configure a swap device on here <mark_weaver>the thing is, passing 'resume=' is not usually how things are done in practice these days, and I kind of doubt that the kernel remembers that the initrd made a failed attempt to resume by writing something to /sys/power/resume <wingo>civodul: so. base-services defines the udev service. but desktop-services should add upower, colord, and elogind udev rules. <mark_weaver>wingo: it's very gross. I made the changes needed (although I only added elogind) <mark_weaver>I haven't pushed them yet, because, well, they are gross :-( <civodul>wingo: i would map over %base-services, bind the services, and just replace the one that corresponds to udev <wingo>so i duplicate the mentions of lvm2, fuse, etc? <civodul>not perfect, we'll do better eventually <mark_weaver>I just need to make them into nice(r) commits and post them. <wingo>was it ok that i stole your polkit patch mark <wingo>still should do the thing civodul said about mentioning services by name, but oh well <wingo>though, if we did make udev look for rules in the system profile that would be another way of fixing udev :) <mark_weaver>for that matter, I'd be thrilled if someone looked more at my 'wip-network-manager' branch and got it working :) <wingo>probably won't be me in the near future :) getting married next w/e, whee <mark_weaver>wingo: it's very tempting isn't it? the one reservation I have is this: I want to be able to install packages without worrying that they might do something dumb. basically, I don't want adding a package to 'packages' to run any code unless I ask for it. <wingo>as regards udev, dbus, etc and the profile... i dunno :( gives more control to person building the os-config.scm but we could check for implications on udev etc using tools <wingo>i.e. you could add a post-pass or something that verifies that only a certain set of packages install udev rules, system dbus services, pam things, or the like <mark_weaver>yeah, I thought of that too, but I'm not sure it would end up any nicer or simpler than doing it another way. <wingo>%desktop-services is a pretty crappy compromise <mark_weaver>well, I certainly agree that we need a better solution :) <mark_weaver>I don't use it either. I don't even use %base-services. <wingo>so here's what i would want. by default udev-service looks at the packages installed in your profile and also some base set of packages. you can override and specify the full set of packages manually. <civodul>wingo: ooh next week-end, pressure increases! ;-) <mark_weaver>e.g. changing %base-services and %desktop-services into procedures, and provide some way for services to advertise themselves to other services, e.g. elogind should be able to tell 'udev' and 'dbus': "hey, please add me to your list" <wingo>civodul: :) things are all done, madame la procureur has signed off on the thing ;) <mark_weaver>wingo: how about 'udev-service' looks at your other services, instead of the full set of packages? <wingo>mark_weaver: that can work too :) <mark_weaver>I would prefer an approach more like that, because I'm already putting a lot of trust in services to not be dumb, whereas I don't put the same trust in packages. <wingo>you can audit services, to a degree <mark_weaver>e.g. I would not normally allow most packages to run code as root, or with any similar privilege. <wingo>you can't audit all packages <wingo>ok i get that. civodul what do you think about having a base-services procedure, and a desktop-services procedure? <mark_weaver>the other thing is, it might make more sense for 'elogind' to tell 'udev' and 'dbus' about itself, rather than expecting 'udev' and 'dbus' to look through the list of services and recognize which ones should have rules or whatever. <wingo>it would be simpler if dbus were in base-services... <mark_weaver>but maybe services like 'elogind' could provide an alist with keys that 'udev' and 'dbus' know about. <wingo>mark_weaver: that can work too! <mark_weaver>although I like to hash things out on IRC, I find that civodul much prefers the ML, and I think that's reasonable, since people not on IRC (or not right now) should be able to participate in the discussion. <wingo>civodul: to be parameterized on the set of packages that could contribute udev, dbus, etc rules <wingo>but mark is offering other things too <wingo>though pam modules aren't services <davexunit>wingo: I had the same idea. it will get us over this issue, not sure how much farther. <mark_weaver>civodul: IMO, base services like 'udev' and 'dbus' should be able to get their lists from looking at the full set of services you've included, somehow. <wingo>dbus is currently marked as a desktop service :) <davexunit>that means that something about the full service configuration must be delayed until the full service list is accumulated <wingo>they could be declared as metaservices <mark_weaver>my current idea is that services should be able to ask 'udev' and 'dbus' to add certain packages to their lists. <wingo>operating-system could have (service-services ...) <wingo>defaulting to udev-service and dbus-service <mark_weaver>and one way would be for services to publish an alist, and for the 'udev' and 'dbus' services to iterate over the other services looking at those alists. <wingo>so you'd never have to specify it in practice <civodul>mark_weaver: i agree, but i'm not sure how to do it <wingo>service-services would then get to examine the list of services to know how to build themselves <civodul>maybe adding an intermediate representation for services, something like that <wingo>whatever we do, we must avoid the thought patterns that led to vtable-vtables :P <civodul>in NixOS services basically have access to the whole OS config <civodul>but i'd like to avoid that, because that's just too much <davexunit>I noticed that when looking through the docs <wingo>as a user nixos services work much better ;-) <davexunit>guixsd will work way better when we've hacked a bit more. <wingo>in this particular instance srsly we need to avoid having to set things up in more than one place. <wingo>everytime we require a user to set two settings we lose some percentage of users <davexunit>which is why I also want to get those elogind file systems mounted as part of the service definition <civodul>that could be done just like for user accounts <civodul>that is, add a 'file-systems' field to <service> <wingo>i'll give it a poke tomorrow, will add file-systems to service, maybe pam modules too <davexunit>civodul: I proposed that, wingo questioned if this would be a common enough occurence to merit the new field. <civodul>what's harder is what wingo discusses, which is to pass info about other services to dbus-service <davexunit>civodul: the other option is to just call 'mount' in the activation script if needed. <civodul>davexunit: good point, i guess it's quite unusual, so i dunno <davexunit>in which case the service just needs (guix build syscalls) <civodul>oh right, it could mount things "manually" <davexunit>(unless (file-exists? "/run/systemd") (mkdir-p "/run/systemd") (mount ...)) <davexunit>or whatever, I think 'mount' takes care of creating the mount point <mark_weaver>davexunit: in general, those bits of code might have to be ordered in a certain way. <mark_weaver>e.g. what is some other bit of code handles mounting /run <davexunit>wingo: it would the quicker option for right now while we figure out generalizations. <codemac>Does anyone run dmd as a user here? I tried it for a while but went back to systemd. <wingo>ACTION never used dmd as a user <wingo>dunno what user-space init tools are for <codemac>wingo: night! (and user space init tools == replace DE's for people use use i3-ish things ( I use ion3)) <davexunit>codemac: the one big feature I want is a REPL <codemac>systemd is not great at it, but dmd is worse <codemac>systemctl daemon-reload && systemctl restart X <davexunit>to work around the hard to tweak stuff, I use 'deco load dmd scratch.scm' where scratch.scm is some file that I throw little bits of code in to run <davexunit>if they work, I move them to ~/.dmd.d/init.scm <lfam>haha: "no article allowed at the beginning of the synopsis" <lfam>I should have had guix lint in college <civodul>guix lint is like this, always nitpicking <mark_weaver>ACTION sent the gross patches to fix elogind-service to the list.