<Jookia>Appraising a GuixSD port to ARM is an interesting task <Jookia>I'll have to write a post to guix-devel about how to handle the idea of boards <lfam>Jookia: By boards do you mean single-board-computers? <Jookia>lfam: Yeah- since they generally have their own kernel forks and bootloader forks and it's a mess <Jookia>lfam: NixOS handles this by having a list of platforms with attributes that derivations read and configure themselves with <lfam>It is a huge mess. Thankfully many of the popular SOCs have good support in mainline Linux <Jookia>lfam: Even if they were all mainline (which they aren't), there's still the issue of per-platform configs and bootloader configuration to use device trees <Jookia>lfam: I think the 'right' solution is to make it configurable then have a function that will do it for you based on the board, rather than derivations all reading off of a platform file <Jookia>lfam: ie, package u-boot-novena, novena-linux, have some scripts for configuring u-boot, all independent of each other- then have a function that ties this all together based on a platform <lfam>Novena still isn't in mainline Linux? <Jookia>It's getting there- you can run it with mainline but I think some laptop-specific stuff is still happening <lfam>CompanionCube: Probably there is less demand now <Jookia>Either way with ARM systems you have to specify per-board kernel options too, which would have to be factored in to the configuration of the kernel <lfam>Jookia: Right. You should bring it up on guix-devel. I don't know enough about GuixSD yet to say what a good approach is. <zacts>if I donate a beagle bone black to the project would it be utilized? <CompanionCube>ACTION desires to give guix a spin on his current arch install <Jookia>CompanionCube: Neat! I did that on my machine <Jookia>lfam: I will once I think more about it, because my line of thinking isn't how NixOS did it <CompanionCube>also I heard you can rollback to previous OS configurations very easily <Jookia>lfam: I'm also compiling Guix on my T400 and wringing out some bugs <CompanionCube>also configuring services / init in a non-bash but still programmable / scriptable language sounds cool <lfam>zacts: I don't know, bring it up on the list. It might not be powerful enough to be really useful but you never know. <lfam>Jookia: Ah, thanks for squashing bugs. Be sure to send patches ;) <Jookia>I'm so tired of having to write bash scripts that go with systemd's weird services that break for me all the time because I haven't looked at the obscure bugs <Jookia>It's nice but it's just so complex <Jookia>I hit so many systemd oddities that aren't bugs but more because the software is hard/complex to understand <Jookia>As a dummy I'm against things that I have trouble formulating a mental model of <zacts>lfam: I posted to guix-help@ <lfam>I like how many different ways systemd units can relate to each other. But it can be daunting trying to figure out how to express the correct relationship <lfam>And then communicating it to other people is impossible, IME. I don't think anybody has read the manual. <Jookia>Is there a way to globally define which compiler flags to use? <lfam>What, the systemd manual? <CompanionCube>ACTION feels like building guix from source because he can and because why not <Jookia>lfam: Yeah, see the container section <Jookia>CompanionCube: It's not that hard :) <lfam>I don't know where the container section is. There is no systemd.container man page on my system <zacts>CompanionCube: yeah, that's probably cool now too, at least until the guix project gets more hardware. I'm wondering, but don't know, if it reduces load on their servers <lfam>`gpg --verify filename.sig filename` <CompanionCube>gpg: Signature made Wed 04 Nov 2015 12:23:33 GMT using RSA key ID 3D9AEBB5 <lfam>I think it imported the key for me automatically. Do you have any keyservers in your gpg.conf? That may be what's missing <CompanionCube>also, I want to mount /gnu/store to an external disk. Will I need to do that before compiling guix or can it wait until after it's compiled / installed <Jookia>CompanionCube: Probably shouldn't compile if you don't have time for it <Jookia>0123456789abcdefghijklmno p qrstuvwxyz <CompanionCube>so, why would it be downloading bootstrap things for armhf and mips? <CompanionCube>/dev/sdb1 on /gnu/store type btrfs (rw,nodev,relatime,space_cache,subvolid=1153,subvol=/guix,user) :> ***JamesJRH is now known as JRHaigh
<Jookia>Also is coreutils supposed to be reproducible yet <lfam>Anyone familiar with cmake? I'm trying to package something but the build fails right away with "CMake Error: The source directory "..." does not appear to contain CMakeLists.txt." https://github.com/nemtrif/utfcpp <lfam>But that file is in the source code repo <CompanionCube>Jookia: tomorrow I'll do whatever needs to be done after running 'sudo make install' <lfam>Jookia: Try challenging hydra and find out <Jookia>lfam: I did challenge it, but I'm not sure if I've broken something? <lfam>Sounds like it's not reproducible. You could also try `guix build --rounds` to test it against your own machine <lfam>The source tarball of that upstream project, found on that github page <lfam>Working repos usually don't match distribution tarballs. Ideally, upstream does some things to prepare the tarball for distribution (such as `make dist`) <lfam>Sometimes on github that is not the case, because apparently github rolls a tarball of HEAD anytime you make a release tag. But not in this case. Just wondering if this is something I can work around or if it's a bug. I'm not familiar with cmake. <Jookia>If it differs and there's no CMakeLists.txt, there's no way to build it- it's like the 'bootstrap' and 'configure' scripts <lfam>I've seen so many broken releases from projects fleeing one proprietary host (sourceforge) for another (github). Really sad <Jookia>It could also be that they're just shipping the include files since that's what you use? <Jookia>You don't need to compile headers <lfam>Oh, it's just headers. I didn't realize that <Jookia>"#ifndef UTF8_FOR_CPP_CHECKED_H_2675DCD0_9480_4c0c_B92A_CC14C027B731" wow <lfam>What is that? Is that a UUID? <Jookia>In C you usually have header guards with the file name but I guess they added a UUID too? <Jookia>Which could probably be a very bad idea <Jookia>Well, assuming they shuffle the UUID around - Say it's just #ifndef UTF8_FOR_CPP_CHECKED_H, there's two possibilities when conflicting: That it's a library conflict, or that someone's used the same #define . Adding a UUID means there's a chance you might be able to include two utf8cpp libraries that don't conflict in #define but do in code <lfam>Things like this make me thing twice about packaging stuff <lfam>Who knows what else could be weird <lfam>This is a dependency of ledger-cli <Jookia>It's probably not a big deal at all, I just use to write C++ and my feathers get ruffled at seeing weird quirks like this <lfam>Like... when would you want to include multiple utf8cpp libraries? Do people actually write same-named libraries with different interfaces and expect them to be used together? <Jookia>No, which is why it's so weird there's a UUID <iyzsong>I believe the macro guards are from an smart IDE :3 <lfam>Oh that would "make sense" <lfam>They didn't convert the sourceforge svn repo to git when they migrated :( <lfam>This thing is in the first commit of the svn repo "Initial import of the project tree" anyways, so no insight there <Jookia>The best thing to do is just copy your SVN repo in to your Git repo <Jookia>then delete it after the next commit <lfam>You mean put the SVN metadata in a git blob? <Jookia>I mean just taking the SVN repo, adding it all to a git commit named 'initial commit' then removing all the .svn directories in the next commit <lfam>Oh, throwing away the history? I think it would be better to convert it if possible. <Jookia>It doesn't throw away the history, it archives it so you can go back and use a SVN program to look over it- it's lossless <Jookia>It's not as cool as converting history to Git but it means you have exactly all the history <lfam>It's a different perspective on the topic <Jookia>I'm hitting strange glib test bugs <lfam>Like what? The glib package already has a few tests disabled or "massaged". <Jookia>I'll see if I can bump glib and get a fix <Jookia>If the tests were failing it'd report that <Jookia>Changing glib's version seems to make it want to recompile a lot more things <lfam>Things that depend on glib? They would have to get rebuilt since their dependency graph will have changed. <Jookia>coreutils depends on glib? Maybe glib is part of the bootstrap? <Jookia>Oh, for some reason I was changing the hash on coreutils, not glib <Jookia>I have a feeling most of my issues are from running an old kernel <efraim>Jookia1: I believe for vm support you need kernel 3.19 or higher, I don't remember what the minimum version is for working guix, but I know for sure the minimum is higher than 3.10 <sneek>Welcome back efraim, you have 1 message. <efraim>lfam: I haven't seen this bug report before now. pre-2.0 we only had the 2.0-beta <efraim>you can't migrate a database from 2.0 back to 0.4.x so I don't think it's worth trying to get that packaged <lfam>No, doesn't look there's anything to do yet. I "subscribed" to the bug report with my browser. I've never done that before but hopefully it will notify me when the bug is fixed. <civodul>alezost: are you hacking the good hack? :-) <civodul>i'm asking because i'm trying the shepherd in GuixSD <civodul>and i wouldn't want to step on your toes ;-) <alezost>civodul: I'm going to begin dmd->shepherd renames in guix source. For the shepherd itself I don't do anything <civodul>alezost: oh could you push the patch for conflicts-with? <efraim>i took another look at aria2 and I've figured it out finally <efraim>one test tries to open a socket and its pair tries to read from it <efraim>I also noticed that there's an emacs major mode for interacting with it ***raulet_ is now known as raulet
<civodul>alezost: i've pushed a bunch of things to shepherd <civodul>more testing in GuixSD, and we're approaching releasable state :-) <Jookia1>Does guixsd-usb-install-0.9.0.x86_64-linux use isolinux? <alezost>civodul: oh great! there are man pages now, and conflicts are displayed, thanks! <alezost>Jookia1: isolinux is a boot-loader, right? I think our usb images use grub2 <Jookia1>I don't think there's a Libreboot command to boot GRUB off a USB :( <Jookia1>Oh well, I guess I'll have to try Debian for bootstrapping <petter>Jookia1: doesn't Libreboot recognize your USB? <Jookia1>petter: Dunno, I hit the 'u' button to boot from USB and it doesn't work <Jookia1>Until GRUB gets a screen reader that's about all I can fathom <petter>Jookia1: try going into command mode and run "ls" <Jookia1>Even if I did that I couldn't read it <NiAsterisk>hm. is the file selected by make (make -f filename) also something which can be specicied in #:make-flags ? <NiAsterisk>I want to package something which has Makefile.unx Makefile.win Makefile.osx and no special requirements, it can be compiled with just make -f Makefile.unx for gnu/linux <taylan>NiAsterisk: the sequence of strings "-f" "Makefile.unx" in #:make-flags should do I think <NiAsterisk>hm... latest checkout from master fails to run 'make' in 'guix environment guix' for me.. is it just me? <Jookia1>I haven't gotten that far yet, I'm still stuck at glib <NiAsterisk>could be just the environment though.. doc/guix-environment.1 fails ***nckx is now known as nckx|offline
<efraim>bad news, looks like we're affected by cve-2016-0755 against curl <jin>hi guixsd`s, i try to guix in guixsd to build mypackage, <jin>i install autoconf, autotool and pkg-config <jin>yes, appear the same message <NiAsterisk>it currently fails for me in environment with latest master, trying to testbuild a new package i added, different messages though <jin>NiAsterisk, what is the diference i use './pre-inst-env guix build mypackage' vs 'guix build -f mypackage' ? <NiAsterisk>i have not much insight yet, but I run ./pre-inst-env in the environment as iirc it does not affect the local store/state, the later run not in an env would build it with affecting the local store? <NiAsterisk>i guess it fails for me as I forgot to pull in make on this new system. <NiAsterisk>or not. as this got pulled in automatically. hrm <jin>i resolve the issue with 'guix environment guix', thanks NiAsterisk <jin>i don`t know if it`s correct way <NiAsterisk>my checkout is still failing. my standard is an environment with just guix, but I'll try variations now <jin>may be you need some package dependence <civodul>alezost: i've updated NEWS for the Shepherd, you're welcome to double-check! <NiAsterisk>davexunit: it's the latest checkout done some minutes ago which I merged into my current working branch.. should I report it, although I can't get a full log output? <davexunit>'make clean-go' may be needed if you are trying to rebuild and some ABI breakage has occured. <NiAsterisk>on guixsd, in a recent pulled guix.git, in guix environment <davexunit>NiAsterisk: but have you built it successfully before? <davexunit>it looks like a relatively easy thing to fix. <NiAsterisk>yes, but on a different system. this is a new one. <civodul>mark_weaver: what about merging core-updates, and then tackling the cURL CVE that efraim mentioned? <davexunit>I'll build from scratch on the latest master and see if I can reproduce. <NiAsterisk>i think while running ./configure --localstatedir=/var there were already errors <davexunit>NiAsterisk: built without errors on latest master <NiAsterisk>maybe I just rollback completely and redo what I worked on. I am not entirely new to git, but branching workflow is something I am not so good at (yet). I did guix pull, guix package -u, git pull (in master) and then git pull on my local-lispf4 branch which tracks origin/master to rebase it, but I removed the *.po files with git rm --cached -r *.po before I merged. <NiAsterisk>okay I think I merged in the wrong way. I'll do a completely new checkout. <NiAsterisk>which is likely avoidable, but i don't know much about head resets. <alezost>civodul: I've double-checked the NEWS, great! <civodul>alezost: how is the renaming going? :-) <alezost>civodul: well, it is going…, but it will not be ready today if that's what you are asking <mark_weaver>civodul: In addition to cURL, the OpenSSL folks have announced that there's a "high" severity vulnerability in OpenSSL 1.0.2, which is the one we're using, but they're keeping the details secret until tomorrow. <mark_weaver>I guess we better build both of those out in the same branch. <civodul>mark_weaver: indeed! so what about merging core-updates, and immediately after creating a branch with these two things <mark_weaver>civodul: well, we can't do it until tomorrow because we don't have the OpenSSL fix yet. <civodul>i just checked the failure/scheduled counts actually <civodul>there are already some more failures <civodul>ACTION is happy to report that it worked :-) <civodul>well, except when i tried to reboot after 'guix system reconfigure' <civodul>because i would have needed to run the old 'deco', which implements the old protocol <civodul>instead i ended up pressing the button, hehe <mark_weaver>civodul: I'd been hoping to let armhf build out more before merging core-updates, but maybe it would be better to just merge now. <mark_weaver>civodul: actually, I would prefer to wait until GC finishes, because after it's merged, hydra will be heavily loaded generating nars as people download new substitutes, and it's probably bad if that all happens while GC is running. <civodul>mark_weaver: if there are no major packages failing on armhf currently, i'd be in favor of merging now <NiAsterisk>i have 1.5 hours until I need to leave for a talk by richard dyer, i'll post the failure to the bugs list <mark_weaver>civodul: okay, how about merging after the GC finishes? <NiAsterisk>is it okay to CC help-guix@ when I send something to bug-guix? I already did so, but this was my first interaction with bug- <a_e>jin: Hello! I just read up on the channel archive. It looks like you were missing guile in your environment. "guix environment guix" will have remedied this. <jin>a_e yes, i run the command <jin>i have another issue whe run 'make check' command, but i ignored <a_e>Yes, I saw it. Installing guile would have been another possibility. <jin>3 steps fails (FAIL: tests/store.scm, FAIL: tests/lint.scm, FAIL: tests/download.scm) <jin>but ./pre-inst-env works <a_e>Maybe it would be worth reporting them on the maiing list. <jin>ok, i send an email. ***kelsoo1 is now known as kelsoo
<davexunit>Pjotr is using the phrase "write once, deploy anywhere" when talking about Guix. I like it. <zacts>how often does the guix mailing list archives get updated? <civodul>mark_weaver: re merging after GC, sure! <zacts>(/me is just eager to possibly donate my beaglebone black board to the project) <davexunit>I don't know if the beaglebone black is powerful enough to build much, but civodul or mark_weaver would know better. <zacts>(which is another fsf distro) <zacts>davexunit: I think it's ARMv8 <davexunit>how do we deal with build slaves with a small amount of RAM? <davexunit>some packages require a lot of memory when building <zacts>also I have a desktop I can donate <jin>civodul, i will attach the complete log to send email. <zacts>but you may not like it, as it uses an intel CPU <civodul>jin: cool; the page above explains which .log files are needed <zacts>but it's like 2 years old with >= intel dual core cpu <zacts>and you can virtualize with it <zacts>kvm and vbox work pretty fast on it <davexunit>zacts: for intel boards, I think we are looking for this with libreboot support, but I'm actually not sure if its a strict requirement. <zacts>if it's not a strict requirement, I'll just give you guys this box <calher>Writing GSD to a USB. Following some guy's instructions. <zacts>but I understand wanting libreboot <calher>For installing GSD on Libreboot with FDE. <calher>Does Libreboot know how to boot into the GSD installer or do I have to tell GRUB where to go? ***nckx|offline is now known as nckx
<lfam>davexunit, zacts: The Beaglebone Black is armv7 (32 bit). The Cortex-A8 refers to something else besides armv8 (64 bit). ***calher is now known as calher|Nibbler
<zacts>ah ok thanks for the clarification lfam <zacts>(I'm still learning about the board) ***ktosiek is now known as ja_chce_jeszcze_
***ja_chce_jeszcze_ is now known as ktosiek
***jonsger1 is now known as jonsger
<petter>mark_weaver: i've sent an e-mail to the mailing list with the installation draft now <petter>how/where did you make it pretty? <calher|Leela>petter: it's on my mom's laptop and i can't log in and get the file because it's asleep <petter>mark_weaver: btw. i'll be going to FOSDEM in 15 hours and i'll be gone till monday. So i'm not going to be active on the mailing list <petter>calher|Nibbler: cool, what kind of font is that? <bavier>ACTION wishes everyone fun times at FOSDEM <petter>thanks, it sure is an exciting font :) <petter>calher|Nibbler: i do now. I only understand "petter" and "ASAP" though <calher|Nibbler>petter, my handwriting matches the style of the printed text. It, too, is in blackletter and monospaced. <calher|Nibbler>In handwriting, I use Sütterlin for text and Grundschrift for monospace. <calher|Nibbler>Too bad all these were used during the Nazi Era and then quickly banned by Hitler in 1941. <calher|Nibbler>Or maybe it's not racist, since Hitler banned them. Hitler liked Helvetica, I think. <mark_weaver>calher|Nibbler: thanks, but these are proposed additions to the Guix manual, which is written in texinfo. <calher|Nibbler>who was the guy who posted this plain text guide that was not written in any sort of markup language and was really scattered? <petter>i think only suitsmeveryfine and myself have posted installation guides recently <mark_weaver>I don't know what plain text guide you're referring to. <mark_weaver>but in any case, I appreciate them working on the text, even if they don't want to take the time to write the corresponding texinfo code. <calher|Nibbler>i need to get better at texinfo. perhaps i should write my webpages in texinfo lol <petter>i usually use sprunge, so it was probably me <petter>once we get text that's good we'll do it in texinfo <calher|Leela>petter: that's fine but please look at the way i did it. the version that was published sucked. <petter>it wasn't published in that sense. It's a work in progress that was shown to others <mark_weaver>calher|Leela: the important part was the actual instructions on how to do the job. it's very rude to insult him for the efforts. <bavier>in the case of a draft meant for discussion, plain text is fine IMHO <calher|Leela>mark_weaver: i mean the style. the style needed to be changed because it skipped to different phrases without stopping. <mark_weaver>calher|Leela: it doesn't matter what you're referring to. he did us a service, and saying that it "sucked" is very rude. <mark_weaver>it was a useful contribution, which is more than you've ever done for us. <petter>calher|Leela: i don't get what you mean by messy though. It's organized in subchapters. <calher|Leela>i'm sorry, i couldn't find the right way to say that even a basic write-up like that should have more care in how it's written <mark_weaver>calher|Leela: I disagree. what we needed was *information* on how to do the job. <calher|Leela>petter: Stuff like capitalization and writing proper sentences. <petter>this is currently focusing on organizing the content <petter>calher|Leela: can you show some examples of what's not good? <mark_weaver>calher|Leela: if you want to get nit-picky, how about calling our system by its actual name, GuixSD. GSD was a proposal that was dropped long ago. <calher|Leela>But yeah, I guess the roughness of the rough draft was so rough that it surpassed the threshold into absurdity. <a_e>That dispute should be easy to settle: There is a draft with useful instructions; someone who complains about the style can proofread it and we can get the best of both worlds. <mark_weaver>calher|Leela: your attitude on this channel has fairly consistently "sucked". go away <a_e>(Actually, I did not read the draft. So I am making no claim as to whether its style is good or bad.) <calher|Leela>mark_weaver: I understand. Could you provide examples in the past? <petter>a_e: the point holds anyways i think <mark_weaver>calher|Leela: you're not worth the time. you've wasted enough of my time already, without contributing anything. <davexunit>calher|Leela: I know that you've had issues in other channels for the same reasons. <calher|Leela>Please stop being hostile. My English teacher ingrained in me certain expectations of rough drafts. <a_e>petter: What you sent to the mailing list looks more polished. Is it a rewording of the web address Mark just sent? <petter>what mark showed was probably the first draft. And, yes, what i sent to mailing list has evolved from this <mark_weaver>a_e: the link I just sent is the draft that calher says is "so rough that it surpassed the threshold into absurdity" and "It's like the roughness was engineered" <davexunit>calher|Leela: we think it is you who is being hostile by *insulting* people that are trying to help. <a_e>calher|Leela: Look, we all know English more or less well, it may or may not be our mother tongue. And we have a more or less good sense of language. <a_e>mark_weaver: Well, it is a rough collection of information and quite understandable. I suppose the first level of "proofing" was to check that the facts are right. <petter>calher|Leela: and i think if you find a draft/suggestion on IRC too rough. Just let it be and wait for it to mature <a_e>It looks tremendously useful. One of the reasons I had not switched to GuixSD in the past was the question of disk encryption. So this excuse has been taken away from me :-) ***jonsger1 is now known as jonsger
<a_e>As petter asks on list, the next level of polishing would be to decide if the structure needs to be modified, and where it should go in the manual. <a_e>The last level would be polishing the language. <a_e>calher|Leela: If you want to constructively help at any moment of this process, you are very welcome. <calher|Leela>a_e: I did show how to clean up 1/3 of the text. I rearranged it and fixed some sentences. It's in the image I posted earlier. <calher|Leela>Unfortunately, I don't have the plain text to my rearrangement. <mark_weaver>calher|Leela: I hear that you were banned from #fsf recently. <mark_weaver>apparently I am not alone in my negative impression of you <a_e>calher|Leela: Good! Sending the plain text to the list would probably be useful. <davexunit>paroneayea: off-topic but: wow, edward snowden will be doing the opening keynote for libreplanet! <a_e>I am dreaming of a world where he could take part in person! <kristofer>I'm using guix on ubuntu! Is it possible to build a guix system that will boot on my machine? <davexunit>kristofer: sure. dual booting isn't straightforward right now, though. <davexunit>it would be easy to replace everything with GuixSD, though. ;) <kristofer>I'm not necessarily interested in a dual boot scenario, but my 2006 macbook won't boot from usb <calher|Nibbler>mark_weaver, don't question it. Just accept it. If I told you, I'd have to take a Xanax. <mark_weaver>kristofer: I would advise against taking advice from calher seriously. <kristofer>the bootloader will only read osx over usb.. <davexunit>kristofer: the reason why dual booting is currently hard is because we don't detect other OSes and add GRUB menu entries like other distros do. if we were to do that, dual booting would be fine. <davexunit>but since you aren't necessarily introduced in dual boot, maybe it's not an issue. :) <kristofer>like I said, I'm not really interested in dual booting, but booting from usb is difficult for me.. I'm a little concerned about bricking my system if I replace the bootloader with 32bit grub-efi <mark_weaver>davexunit: I haven't tried it, but we have a way to add one kind of grub menu entry.... for booting linux. <calher|Nibbler>The system should detect non-free operating systems and write over them with /dev/urandom. <kristofer>so if I could use a CD to boot and install guix this would be a lot easier/safer for me :) <davexunit>kristofer: we don't currently provide ISOs, unfortunately. <alezost>civodul: oof, I've sent "dmd→shepherd" patches :-) <civodul>i have preliminary code for 'guix system reconfigure' to load/start new services, things like that <civodul>it seems everything we need is in place <mark_weaver>civodul: ah, nice! will bad service code crash the system? <civodul>well the 'load' and 'eval' action definitely protect against that <davexunit>civodul: oh wow, I was just thinking about that problem. <civodul>i think it's immune to bad start/stop code <davexunit>I have a particularly tricky use-case in mind. ;) <civodul>well this is just the beginning of a solution <civodul>it will load new/stopped services and remove old ones <civodul>basically 'guix system reconfigure' is a shepherd client just like 'herd' <davexunit>I would ultimately like things to be robust enough to satisfy the following the use-case: reloading the nginx service without stopping nginx. <davexunit>nginx knows how to do this, but the trick is telling shepherd to trigger 'nginx -s reload' with a new config file upon reconfigure. <civodul>i think we'll need to add custom actions for that <davexunit>nginx also supports replacing the nginx binary without downtime. <civodul>what you suggested some time ago actually ;-) <davexunit>civodul: IIRC, it spawns a new process with the new binary, and stops taking requests with the old one. <davexunit>once there are no more clients connected to the old, it drops all of the old processes. <davexunit>and what mark_weaver posted has some good details. <davexunit>for production web applications these are really killer features that I want to ensure are accessible to GuixSD users. <davexunit>so I'm curious what kind of API shepherd could provide to allow us to do these specializations upon system reconfigure <civodul>davexunit: i was thinking of an 'upgrade' action that services could optionally provide <civodul>which would be passed the new argv, for instance <davexunit>one thing I don't yet know about nginx is if you can tell it reload *and* use a new config file. <davexunit>I know it can reload updated config in the same file <davexunit>but on GuixSD the file will obviously be different. <civodul>i was planning to release, like, tomorrow... 