<DusXMT>I think Gentoo has an alternative to udev (so maybe we could use that?) and there's still alternatives to gem such as kdm, ldm (not sure if it's called that), and when everything else fails, there's still xdm <Ulrar>I'm using it right now, works well <Ulrar>I also heard that pulseaudio is getting hard to run without udev / systemd, and as skype is now dependent of pulseaudio it'll affect lots of users <Ulrar>Then again, that doesn't affect me that much <DusXMT>Unfortunately, it might slowly creep even up to us <DusXMT>It's strange that pulseaudio's getting dependent like that, I thought it's main advantage was being portable <Ulrar>I don't know if it's dependent because of udev or if there is direct dependency <DusXMT>jxself is right, the time has come to learn ObjectiveC <Ulrar>Meh, I'll stay on xmonad, I'd be surprised to see that getting systemd dependant :D <DusXMT>You know what'd be funny? If dmd became systemd dependent <jxself>civodul had some good ideas for it so no need to worry. <waxysubs>we can always implement the necessary systemd-like interfaces in dmd, and parse systemd configuration files. <waxysubs>hmm, well, admittedly, avoiding systemd may become increasingly difficult. ***tadni_` is now known as tadni_
<taylanub>hm, perhaps one could start an effort for standardized systemd-like functionality, independent of implementation and platform <taylanub>jxself: DusXMT: if you want to use GNUstep, update its Guile bindings! :) <civodul>taylanub: systemd unit files are actually quite abstract, so i imagine dmd, or Pies, etc. could read that <plotr>got question on guix.el - how do I give it a shot? <plotr>is it available through melpa and alike? <civodul>and there's a section of the manual that explains how to set it up <plotr>I've naturally expected to find it in elpa - any plans to push for it? <civodul>but i don't think it'd be very helpful <civodul>because one needs to install Guix to be able to use it anyway <alezost>plotr: the point is: “guix.el” is a part of Guix and is maintained inside of it. There are no plans to add it to melpa, because there may be problems with paths (you can install Guix wherever you want and “guix.el” will not know where to find Guix modules or user profile) <plotr>well, there're plenty of packages in emacs archives which interface to or rely upon external tools - they all have that potential problem of paths difference on the end system and it's usually solved rather trivially by introducing customize option with some sane default <plotr>there're other solutions like exposing dbus interface which is independent of installation paths for example <plotr>not sure if it's available in guix though <civodul>another thing to consider is that guix.el is quite tied to Guix's APIs <plotr>well, there're enough of packages in melpa with git commit-id in the version - nobody expect it to be rock-solid debian-style :) <plotr>thanks for tip - didn't know about quelpa <civodul>i wonder whether core-updates should be delayed <waxysubs>oh good, that makes it easy. core-updates should simply be updated to 2.20. <mark_weaver>civodul: when you ask whether core-updates should be delayed, what do you mean? <jxself>I assume so that libc 2.20 can be included? <jxself>If you've got to rebuild everything, you might as well throw it all in. :) <mark_weaver>and if not for 2.20, there was another CVE for glibc 2.19 that needed to be patched anyway. <mark_weaver>I'll take care of updating core-updates to glibc 2.20 <civodul>mark_weaver: yes, whether libc 2.20 should be included or not, as jxself ntoes <civodul>oh thanks for taking care of it, mark_weaver *civodul shouldn't reply before being done reading the backlog <mark_weaver>civodul: should we keep --enable-kernel=2.6.30 or move that to a higher version number? <civodul>the default in sysdeps/unix/sysv/linux/configure.ac is now 2.6.32 <civodul>anyway, something >= 2.6.32 sounds good <civodul>oh but wait, hydra.gnu.org runs a 2.6 kernel, and that's not something we can change :-/ <mark_weaver>I think the relevant question is: what is the oldest kernel version that end users of guix are likely to run, when run on top of another system. and I guess we should think of debian and ubuntu lts. <civodul>so maybe we can just leave the default, i.e., 2.6.32 <plotr>out of curiosity - why can't we change what's running on hydra? <mark_weaver>remove the option entirely, or just change it to 2.6.32 ? <civodul>mark_weaver: maybe the latter is clearer <civodul>plotr: hydra.gnu.org is a machine mostly under the FSF's control <jxself>Since they're slow moving I looked at Debian stable & it uses 3.2. <plotr>I mean not "why don't you have access to it", I mean "what prevent the upgrade" :) <civodul>plotr: sysadmins aren't very responsive these days, that's one of the reasons <mark_weaver>fsf servers are running trisquel 4 LTS, which has 2.6.32 <jxself>All the more reason to move it to another machine maybe? :) <davexunit>civodul: the problem right now we don't have plural, we have singular. <davexunit>mark_weaver: those are slowly being updated to trisquel 6, but the upgrade path is a bit difficult, I heard. <civodul>davexunit: yes, understood (i'm not blaming!) <DusXMT>I've packaged Abiword, there are just 8 out of 48 plugins that aren't in yet. Do you think I can commit, and other people who find the need for those can perhaps add them in? <civodul>if the main functionality is there, go ahead *civodul cleans up databases <davexunit>civodul: btw, I'm holding off on the minetest stuff for a bit. upstream found some (now obvious) issues with my patch that I need to take care of. :) <DusXMT>civodul: Okay, I'll clean it up a bit, try compiling everything on an up-to-date guix (since there's been some changes since I began the packaging) and send the patches to the ML today if all goes well :) <Ulrar>Is it guix package -r to remove a package ? <mark_weaver>that removes the package from your profile, meaning that it creates a new profile tree of symlinks with that package absent. if it said nothing to be done, that suggests that it thinks you don't have that package in your profile. <Ulrar>So how do I tell it that I want to force rebuilding it ? <mark_weaver>if there are no references to it elsewhere in the store (e.g. from your older profiles) then you can delete it with: guix gc --delete /gnu/store/... <mark_weaver>to delete all generations of your profile other than the current one: guix package -d <mark_weaver>but normally, if you made any change at all in the recipe, it will rebuild automatically <mark_weaver>in fact, I'm curious why you want to force a rebuild of the exact same recipe <Ulrar>It's not the exact same recipe, I changed it <mark_weaver>if you changed it then simply run "guix build" again, it will do the right thing <Ulrar>It just gives the /gnu/store/... of the existing <mark_weaver>normally there should never be a need to run "guix gc --delete" to force a rebuild. <mark_weaver>it must not be seeing your change. which copy of guix are you running to do the rebuild, and where are the files that you changed? <Ulrar>The things civodul asked me to change, nothing much. License, description, removed a coma <mark_weaver>if you make changes within a built git checkout, then remember to do: ./pre-inst-env guix build -K <package> <mark_weaver>so that it uses the version of guix in the git checkout, instead of the system-wide one. <mark_weaver>another way to do this is to put a little shell script in ~/bin/guix that does this: exec /home/XXX/guix/pre-inst-env guix "$@" <mark_weaver>ah, if you only changed license and description, then I guess that doesn't need a rebuild. <Ulrar>I guess not, just wanted to be sure <davexunit>yeah, that's not enough to trigger a re-build. <davexunit>no inputs to the build process have changed. <mark_weaver>I guess neither of them affect the contents of the build outputs <mark_weaver>more to the point, neither of them affect the derivation that gets generated from the package description. <bavier>I have a case where I need to wrap a program that's already been wrapped by python-build-system <bavier>if wrap-program is called again, the real program gets overwritten by the first wrapper... :(