IRC channel logs


back to list of logs

***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
<civodul>Hello Guix!
<rekado_>when R sees that JAVA_HOME is defined at configure time it will compile ./tools/ 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>so, let's drop it?
<rekado_>yes, I think that's okay.
<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.
<civodul>yes, Info is important
<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>shouldn't be too hard
<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>ACTION adds to TODO list
<davexunit>for instance, nginx needs a 'reload' action
<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
<civodul>well, i'll give it a try if you don't beat me at it :-)
<davexunit>shouldn't be too hard
<davexunit>but I haven't looked at the details
<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!
<civodul>ah sure :-)
<civodul>that would be ideal indeed
<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
<davexunit>civodul: that is nice.
<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
<davexunit>they are static :(
<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?
<davexunit>and recompile nginx entirely
<civodul>oh, indeed
<civodul>really static
<davexunit>yeah, it's a shame.
<davexunit>everything else about nginx is more dynamic
<civodul>i guess it's for Performance Reasons
<civodul>i must say i'm impressed by how fast and lightweight it is
<davexunit>yeah it's very impressive in that regard
<davexunit>low-level C crazy stuff
<rekado_>ugh, ruby!
<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.
<davexunit>rubyists disagree.
<rekado_>dependency cycles in packages made by the same person!
<davexunit>yup, seen it.
<davexunit>rugged is one such example.
<davexunit>I think.
<rekado_>and advertising packages as "light" but they have massive dependency graphs
<davexunit>or maybe it was libgit2 in general... which isn't ruby.
<rekado_>shindo and formatador.
<rekado_>depend on one another.
<davexunit>rekado_: I'm terrified to try to tackle nodejs.
<davexunit>but that's next up.
<davexunit>if you think Ruby is bad...
<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>I was noticing that.
<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.
<civodul>you mean quit Ruby/Java work?
<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?
<rekado_>here's the rakefile:
<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>once to run tests
<davexunit>and then again when running 'gem install'
<rekado_>I see.
<davexunit>libffi can be a regular input
<davexunit>thanks for this, btw. ruby-ffi is important.
<davexunit>the smallest ruby application requires 76 ruby gems transitively.
<davexunit>at work, that is.
<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> <- the part on apt's security is worth a look
<davexunit>civodul: is it good?
<civodul>apparently it's getting better ;-)
<civodul>"First, downloads are now performed as the unprivileged user "_apt" rather than as root."
<davexunit>ah yes, that is good.
<civodul>"Earlier releases only checked uncompressed hashes, and only on some files"
<davexunit>yeah I didn't realize how insecure apt was.
<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
<davexunit>oh wait, we're on the "waiting list"
<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
<mark_weaver>okay, sounds good
<davexunit>we didn't update the snapshot at the time due to pending security updates
<mark_weaver>go ahead and enable them
<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>wingo: and the same for me.
<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 :)
<mark_weaver>*that I
<wingo>happily you can configure the lid action ;)
<mark_weaver>yes, I saw that :)
<mark_weaver>and was glad
<wingo>so first of all, i guess that if you run ps auxw you see the elogind process, right?
<mark_weaver>yes, I checked that :)
<wingo>and if you manually echo mem to /sys/power/state it suspends
<davexunit>oh wow never knew about that
<mark_weaver>yes, that's what I do :)
<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>that i didn't know
<davexunit>yeah we probably have to handle those ;)
<wingo>anyway that's been a real problem working on services
<mark_weaver>I avoid using tty1 because it gets so much output
<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
<davexunit>get some details figured out amongst us
<wingo>so, if you run elogin directly from the console what does it print?
<mark_weaver>davexunit: yes, dmd definitely needs a lot of work
<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
<davexunit>wingo: okay it's running
<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>New seat seat0.
<davexunit>Failed to save seat data /run/systemd/seats/seat0: No such file or directory
<wingo>yes that's the other thing
<wingo>the /run/systemd and /run/user mounts
<wingo>see civodul's response there
<mark_weaver>ah yes, thanks!
<mark_weaver>I guess we should probably just add those to %base-file-systems, as civodul suggested
<wingo>yes i guess so
<mark_weaver>I'll try it and see if it fixes it for me.
<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
<davexunit>odd restriction.
<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
<davexunit>I see.
<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?
<wingo>if not i wouldn't bother
<wingo>mho :)
<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>(unless (file-exists? "/run/systemd") ...)
<wingo>that could work
<davexunit>wingo: agreed.
<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."
<mark_weaver>(no additional output when closing the lid)
<mark_weaver>(but no need to debug it now, just fyi :)
<wingo>there's no output when the lid closes? strange
<wingo>i get something printed out
<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
<mark_weaver>no rush :)
<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
<mark_weaver>I'm also using XFCE
<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>ACTION unplugs
<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>New seat seat0.
<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.
<davexunit>yeah I get none of that :(
<wingo>the last line might be because of my things
<wingo>but the buttons... humm.
<wingo>there's one more thing.
<wingo>did my commit add elogind to udev?
<wingo>if not perhaps that's the problem
<wingo>yeah i think it didn't
<davexunit>it's the in the dbus-service list
<mark_weaver>indeed, it didn't
<wingo>which is irritating
<wingo>because it's a base service
<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.
<mark_weaver>ACTION tries adding elogind to udev
<wingo>mark_weaver: yeah me too re base-services
<wingo>ACTION biab, dinner
<mark_weaver>yes, that fixed it for me!
<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.
<mark_weaver>*my laptop
<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>wingo: yeah, this is nicely done :)
<mark_weaver>thanks for taking on these hard bits!
<wingo>tx! :)
<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>(or while connected to IRC or whatever)
<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>wingo: yeah, I don't see why it would be hard.
<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>ACTION looks for link
<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.
<mark_weaver>wingo: ah, thanks!
<wingo>i wonder what writing disk to /sys/power/state does when you didn't boot with resume=/dev/sda2 or whatever
<wingo>civodul: good evening :)
<mark_weaver>I strongly suspect that it hibernates.
<wingo>mark_weaver: to where tho?
<wingo>the currently configured swap, i guess?
<mark_weaver>oh, hmm. good question.
<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.
<wingo>how to do that?
<mark_weaver>wingo: it's very gross. I made the changes needed (although I only added elogind)
<civodul>hey, wingo
<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
<civodul>similar to what is done for nscd
<wingo>so i duplicate the mentions of lvm2, fuse, etc?
<civodul>not perfect, we'll do better eventually
<wingo>yeah sadpanda
<mark_weaver>I've already done it, no need to do it again.
<civodul>ah, even better then :-)
<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>i dinnit even ask
<mark_weaver>wingo: yes, of course!
<wingo>cool :)
<mark_weaver>I'm glad you fixed it up and got it pushed
<wingo>and thanks :)
<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.
<mark_weaver>wingo: oooh! congratulations! :)
<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
<wingo>but that's not great either
<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
<wingo>and i don't even use it
<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>me neither
<mark_weaver>but I can imagine better approaches.
<davexunit>wingo: congrats!
<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.
<wingo>same for dbus, etc.
<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?
<civodul>wingo: heheh :-)
<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
<mark_weaver>but I put that trust in services.
<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>or would it, humm
<wingo>mark_weaver: that can work too!
<wingo>so many possibilities :)
<mark_weaver>indeed :)
<mark_weaver>I guess it warrants discussion on the ML.
<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.
<civodul>wingo: why make them procedure?
<wingo>civodul: to be parameterized on the set of packages that could contribute udev, dbus, etc rules
<civodul>(and +1 for the ML :-))
<wingo>but mark is offering other things too
<wingo>pam also
<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 :)
<wingo>but yeah.
<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>and agree that it's too much.
<davexunit>nixos has just been around longer.
<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.
<civodul>yes, definitely
<civodul>but we need a way to express this
<wingo>everytime we require a user to set two settings we lose some percentage of users
<davexunit>agreed. we do not want that.
<davexunit>services should be self-contained.
<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
<wingo>that can work too
<davexunit>you get the idea.
<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
<davexunit>codemac: I do.
<wingo>dunno what user-space init tools are for
<davexunit>both at home and at work.
<mark_weaver>alezost also does
<wingo>ok, zzz, night
<mark_weaver>wingo: sleep well!
<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>davexunit: nice!
<davexunit>it's hard to tweak services right now
<codemac>yes, it really is.
<codemac>systemd is not great at it, but dmd is worse
<codemac>systemctl daemon-reload && systemctl restart X
<davexunit>but you could say that I have a pretty serious userspace dmd config:
<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
<davexunit>anyway, gotta go afk!
<davexunit>happy hacking
<codemac>sneek: later tell davexunit my baby config. I'd love to fully replace/replicate the systemd user unit files I have:
<codemac>sneek: botsnack
<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.