<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 _2_4 25  
26 27 28 29 30 31
00:50 <kaniini> laskin: there is already an APKBUILD submitted pending someone sponsoring it for wireguard, but it has problems
01:23 <kaniini> laskin: you can see it here,
01:23 <kaniini> laskin: https://github.com/alpinelinux/aports/pull/708
01:44 <TemptorSent> fabled: When you get a chance, please take a look at http://termbin.com/ey7v -- that is the last major restructuring to modularize and cleanup the profile system. The individual profiles could probably use review and tweaking.
01:49 <TemptorSent> supporting various bootloaders is now very straightforward
02:32 minimalism joined
02:33 jailbox joined
02:36 s33se_ joined
02:40 <TemptorSent> ls
02:40 <TemptorSent> Oops, wrong term ;)
02:41 blueness joined
04:06 <TemptorSent> Who's the local guru on the bootloader situation for various architectures?
04:32 <kaniini> not me :D
04:46 <BitL0G1c> kaniini - finishing off wireguard now
04:47 <kaniini> sick
04:47 <kaniini> let me know, i will send it to the builders
04:52 <kaniini> BitL0G1c: why tcp-wrappers by the way
04:54 <BitL0G1c> kaniini - stunnel can be built with tcp wrapper support - I also noticed there is an nginx module for tcpwrappers
04:56 <BitL0G1c> if it works ok with just ip addresses - eventually I could replace the dns functionality that is missing - I saw a tiny dns library implemented in one c file
04:57 <kaniini> but do we want to do that
04:57 <kaniini> that is my question really
04:58 <BitL0G1c> red hat still uses tcp wrappers
05:06 <BitL0G1c> kaniini - wireguard rebased into 3 x APKBUILD
05:06 czart joined
05:09 <kaniini> ok
05:09 <kaniini> well
05:09 <kaniini> regarding tcp wrappers; redhat also uses systemd -- should we use systemd?
05:09 <BitL0G1c> hahahahaha no
05:09 <BitL0G1c> systemd is why i stopped using debian
05:10 <kaniini> but redhat is doing it
05:10 <kaniini> (see how this isn't a supporting argument?)
05:10 <kaniini> my understanding is that tcp wrappers has very little security benefit and has had security CVEs in the past
05:11 <BitL0G1c> ok
05:11 <kaniini> personally, that would lean me to not want to be the rabbit who put this in alpine
05:12 <kaniini> looking at one other package first and then i will put wireguard in
05:13 <BitL0G1c> ok
05:17 <kaniini> dear god this package is fucked (not wireguard)
05:17 <kaniini> completely wrong
05:20 <BitL0G1c> last cve on tcpwrappers was in 2007 - ubuntu use it too
05:27 <kaniini> but why should *alpine* use it
05:34 <kaniini> BitL0G1c: i think you forgot to update the grsec version, as it is still building tools :/
05:35 tmh1999 joined
05:49 <BitL0G1c> oops
05:55 czart_ joined
05:58 <BitL0G1c> I think I need to make a new pr for wireguard - local copies are ok - remote not
05:58 <kaniini> okay
05:59 <kaniini> let me know the PR number and i'll review
06:07 <fabled> tmh1999, re go pkgname, the intention is to ship go-bootstrap when compiled because it is limited package, so only native compiling provides the full package. however, to be able to recompile itself the native compiled version needs to provide go-bootstrap too. this makes the real go compiler to build itself on further rebuilds
06:10 <TemptorSent> Does anyone know off hand how to tell get fakeroot to run one instance of faked for multiple instantiations of fakeroot?
06:10 <TemptorSent> Or do I get to hack the script to make it work?
06:11 <kaniini> :D
06:14 <TemptorSent> Or, to be even more twisted, can I LD_PRELOAD fakeroot for just the subshell I need it in, keeping the same FAKEROOTKEY?
06:22 <BitL0G1c> kaniini - see https://github.com/alpinelinux/aports/pull/948
06:26 <kaniini> looks good
06:26 fabled_ joined
06:27 <pickfire> How do I use the subpackages?
06:27 <pickfire> I don't understand the "$pkgname-scrips-py:<py>:noarch"
06:27 <pickfire> I mean the <py> part, what does that do?
06:28 <kaniini> function to run
06:28 <pickfire> kaniini: What if it is not there?
06:28 <kaniini> then it may be a builtin :)
06:28 <pickfire> Oh
06:28 <pickfire> kaniini: %3089 that's what I send, weird. It have no name.
06:28 <algitbot> [alpine-aports] testing/libmediainfo: fix depend - Patchwork: http://patchwork.alpinelinux.org/patch/3089/
06:30 <tmh1999> fabled : I understand the steps of recompiling natively. It's just that I can't find other/better solution for the conflict error I got from $ apk install go-bootstrap when trying to natively compile the full go compiler
06:32 <tmh1999> fabled : do you have the same conflict problem on aarch64 ?
06:32 <pickfire> Looks like rust doesn't build yet on musl T_T
06:32 <pickfire> But go does
06:33 <pickfire> algitbot: Hello, where is your source.
06:35 <pickfire> kaniini: If a package has scrips (python, perl...), should it be included with the main packages as well?
06:35 <pickfire> Like john
06:35 <kaniini> it depends
06:35 <kaniini> if they are optional enhancements, may make sense to split them
06:36 <pickfire> I think I should split them
06:36 <pickfire> kaniini: Then for a all in one install do I use separate package like alpine-sdk or just set the version?
06:37 <pickfire> Like john-vjumbo1 vs john-vr1
06:37 <kaniini> im not sure what youre trying to do
06:38 <pickfire> kaniini: Like I want a package to include all the stuff john currently in.
06:38 <pickfire> have*
06:38 <pickfire> I want to keep john minimal
06:38 <pickfire> And then like apk install john-jumbopack to install all those stuff
06:38 <kaniini> you could make a subpackage that pulls everything else in i guess
06:38 <pickfire> A
06:38 <pickfire> Oka
06:56 vakartel joined
07:13 <tmh1999> fabled : https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#provides. APKINDEX shows : P:go, V:1.7.4-r2, A:s390x, ..., D:binutils gcc so:libc.musl-s390x.so.1, p:go-bootstrap=1.7.4-r2. This APKINDEX is the result of natively building go, using cross-built go-bootstrap with the patch I sent.
07:14 <tmh1999> I think it matches just fine the description in the APKBUILD references
07:28 <tmh1999> $ apk search bootstrap also show go package
07:34 fekepp joined
07:58 stwa joined
08:38 <TemptorSent> Okay, I think this will work for now for the fakeroot utility: http://termbin.com/cfin
08:39 <TemptorSent> I'd love it if someone who is a bit more familiar with how fakeroot works could take a look at it and let me know what needs to be done to make it solid for general use.
08:40 <TemptorSent> The idea being that you can wrap a section in a script that needs to be in the fakeroot with fkrt_enable/fkrt_disable at will.
08:43 <TemptorSent> It shouldn't take much more work to make it handle multiple distinct fakeroot environments that can be selected among at will if needed.
08:43 t0mmy joined
09:16 royger joined
09:52 <laskin> BitL0G1c: thank you for wireguard. Using it right now, works perfectly.
09:58 <tru_tru> ncopa: what are the implications of vsyscall=emulate ? and why it is required for running centos6 docker images?
09:59 <tru_tru> maybe it is required for other docker images, ... but not needed for centos7 ones, nor debian{7|8}
10:01 <ncopa> tru_tru: http://stackoverflow.com/questions/19938324/what-are-vdso-and-vsyscall
10:02 <ncopa> vsyscall has some security implication, which why i think most distros disables it by default
10:02 <ncopa> centos6 uses ancient glibc that uses vsyscalls
10:03 <ncopa> i dont know what version of glibc centos7 or if it needs vsyscalls
10:03 <ncopa> you should probably ask in some centos channel
10:05 <ncopa> some binaries that links to static dietlibc has also the same problem apparently
10:06 <tru_tru> glibc-2.17-157.el7_3.1.x86_64 for c7, glibc-2.12-1.192.el6.x86_64 for c6
10:07 <tru_tru> I don't need any additionnal vsyscall=... on c6/c7 to run the same docker images, hence my question.
10:08 <ncopa> that depends on the kernel config
10:10 <ncopa> i think centos7 works
10:10 <ncopa> its only centos6 that dependson vsyscalls in kernel
10:11 <ncopa> you have the same issue if you use arch linux as host
10:11 <ncopa> or recent debian
10:12 <tru_tru> thx for the info
10:13 <ncopa> centos6 needs kernel with vsyscalls support
10:13 <tru_tru> http://pastebin.centos.org/68626/ <- grep -i syscall on c6/c7 kernel config
10:14 <ncopa> old kernels which supports it
10:15 <tru_tru> https://github.com/CentOS/sig-cloud-instance-images/issues/62
10:15 <ncopa> http://tpaste.us/QD1E
10:15 <tru_tru> same issue as you mentionned
10:16 <ncopa> yes, newer kernels on newer systems disables vsyscalls by default
10:16 <ncopa> but let you emulate it with vsyscall=emulate
10:18 <tru_tru> -> FAQ or heads-up warning for containers hosting :P
10:51 <TemptorSent> Okay, util-fkrt is mostly done: http://termbin.com/ipnf
10:55 fekepp joined
11:01 <TemptorSent> Revision of mkimage, refactoring nearly complete: http://termbin.com/4pca
11:57 leitao joined
12:08 stwa joined
12:35 stwa joined
12:43 <^7heo> ncopa: did you see that yet? https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm#e20170301-tg_wlog-10
12:43 <^7heo> "certain content may no longer legally be pushed to GitHub"
12:44 <^7heo> I don't think we have problems with firefox being called firefox in alpine... yet.
12:45 <^7heo> But that might be a bigger problem right there.
13:03 <ncopa> ok?
13:03 <ncopa> so we stop use github?
13:07 <ncopa> ^7heo: did i read that right? its no longer allowed to put sources under GPL on github?
13:12 rnalrd joined
13:12 <coredumb> ncopa: it definitely requires clarification on their side
13:15 farosas joined
13:17 <yGweSm1OzVHe> hackernews comments has two laywers in the top comments that refute that blogpost
13:17 <yGweSm1OzVHe> afaics it affects mostly sw that is uploaded by someone who has no authority over sublicensing (aka is no the author)
13:24 <asie> yGweSm1OzVHe: refute it in what regard?
13:24 <asie> the blogpost has multiple points
13:25 <yGweSm1OzVHe> the lawyers comments cast some doubts on the interpretation in the blogpost
13:25 <yGweSm1OzVHe> so definitely something to clarify
13:26 <asie> mhm
13:28 <yGweSm1OzVHe> (i'm sorry to quote hn, usually reality is quite far from that crowd, but maybe this time the lawyers have a point)
13:32 fabled__ joined
14:09 dlintw joined
14:43 <dlintw> what's abuild up2date for?
14:53 <dlintw> Is there pkgbase support in APKBUILD for multiple package?
14:53 mikeee_ joined
14:54 <^7heo> ncopa: you read that right.
14:54 <^7heo> yGweSm1OzVHe: "it affects mostly sw that is uploaded by someone who has no authority over sublicensing"
14:54 <^7heo> yGweSm1OzVHe: like, say, package managers?
14:54 <^7heo> s/manage/develop/
15:36 <dlintw> apk Unable to lock database, how ? ps -ef can not found apk running
15:38 <dlintw> why firefox's UI seems haven't correct 'font'? Are it lack dependency?
15:39 <pickfire> There is no option to choose firefox-gtk2 and firefox-gtk3
15:39 <pickfire> Firefox in alpine is weird.
15:45 <dlintw> So, what's your browser in alpine? Are you using alpine for your desktop?
15:50 <pickfire> dlintw: Yeah, alpine for desktop, arch back then. I uses firefox.
15:51 <pickfire> I uses alpine for both desktop and server (raspberry pi)
15:51 <pickfire> dlintw: What about you?
15:53 <dlintw> My desktop for x86_64 is ArchLInux. I'm trying to use alpine for desktop for i686, but it seems difficult for me to use buggy firefox.
15:53 <dlintw> I don't know why the firefox@testing can not show menu font correctly.
15:55 <dlintw> pickfire, do your desktop use the 'ram','disk' or 'sys' mode? I found the 'sys' mode save more memory for my old note book.
15:56 <pickfire> dlintw: No, firefox not buggy but most stuff are buggy like pandas that I need to use vm.
15:56 <pickfire> dlintw: I use sys mode for both pi and laptop, I don't know how the others are useful.
15:57 <pickfire> So far, alpine is nice to replace arch. Just broken boot and network configuration isn't that easy.
15:57 <dlintw> so, what's your firefox version? are you using firefox@testing? is there require install other package before firefox?
15:58 <pickfire> One more thing, no chinese input which I really hate. (tried building fcitx but libintl error which is the same like cryptsetup)
15:58 <dlintw> I just install openbox, lxpanel, ttf-droid ttf-droid-nonlatin ttf-freefont
15:58 <pickfire> firefox 51
15:58 tmh1999 joined
15:59 <pickfire> Ah, lxde stuff. I am planning to update those old lxde stuff and add gtk3 subpackages as well.
15:59 stwa joined
15:59 <pickfire> I just use ttf-dejavu, ttf-mononoki and wqy-zenhei
15:59 <kaniini> github is just another channel for getting packages in the distro, i don't think it is a major loss if we lose it
15:59 <dlintw> You can try my main/lxterminal testing/gcin https://github.com/dlintw/aports
15:59 <pickfire> And manually build dwm.
16:00 <pickfire> Nice
16:00 <pickfire> gcin?
16:00 <dlintw> gcin is input method which for Taiwanese, there are also some common input methods.
16:01 <pickfire> Oh, I didn't know about that.
16:03 <dlintw> pickfire do you have your chinese input module package in your github?
16:03 <pickfire> dlintw: Where is gcin? I can't find it. I only tried building fcitx, not ibus.
16:03 <pickfire> dlintw: No, I didn't upload to github.
16:03 <pickfire> I mean my repo not on github.
16:04 tmh1999 joined
16:04 <pickfire> Why put it on github?
16:05 <dlintw> check myrepo in new-gcin2 & lxterminal-gtk branch
16:05 <dlintw> I put source on github, it is easier for other's review (pull&request). Instead of e-mail interface.
16:06 <pickfire> Ah, I didn't know you are from taiwan.
16:06 <dlintw> pickfire 你看的到中文嗎?
16:06 <pickfire> dlintw: Yes
16:06 <pickfire> But can't reply in chinese as well.
16:07 <dlintw> Why? what's your interface?
16:07 <dlintw> lxterminal?
16:07 <pickfire> No
16:07 <pickfire> st
16:07 <dlintw> what's your window-manager?
16:07 <pickfire> https://transfer.sh/bi2LV/2017-03-03-000720-1366x768-scrot.png
16:07 <pickfire> https://transfer.sh/bi2LV/2017-03-03-000720-1366x768-scrot.png
16:07 <pickfire> dwm
16:09 <pickfire> dlintw: 猜我从那来?
16:09 <dlintw>
16:10 <pickfire> Haha
16:10 <dlintw> China,America, now, many place are Chinese.
16:10 <pickfire> No
16:10 <pickfire> Lol
16:10 <dlintw> Taiwan?
16:10 <pickfire> No
16:10 <pickfire> I bet you can't guess it correctly.
16:10 <pickfire> dlintw: Tip, I learn simplified chinese.
16:12 <dlintw> Oh, are you Ivan Tham?
16:12 <pickfire> Yeah
16:13 <pickfire> I bet you saw where I am from.
16:13 <dlintw> Malaysia
16:13 <pickfire> Haha
16:13 <dlintw> Nice to meet you, I must go to sleep.
16:13 <pickfire> Okay, bye.
16:16 <yGweSm1OzVHe> ^7theo as a pkg manager you upload your buildscripts, not the sources of hthe packages.
16:16 <yGweSm1OzVHe> (laggy net, sorry for typos)
16:53 <BitL0G1c> laskin - no problem - thx for testing
17:03 mikeee_ joined
18:21 BitL0G1c joined
18:40 BitL0G1c1 joined
18:44 BitL0G1c1 joined
18:46 BitL0G1c joined
20:16 <ncopa> im tagging 3.5.2 now
20:21 <kaniini> what about abuild :P
20:28 <ncopa> should tag a release of that too
20:29 <ncopa> but will not be able to look at that this week
20:29 <ncopa> is the current git master of abuild good for release?
20:29 <ncopa> no big breakages?
20:29 <ncopa> should probably wait til monday though
20:36 <_ikke_> What could go wrong :P
20:41 Topic for
20:47 <_ikke_> \o/
20:47 <algitbot> \o/
21:00 tmh1999 joined
21:18 <mikeee_> hey, this may be a farfetched place to ask, but since you all seem so nice: does anybody know why autoconf doesn't produce new releases anymore?
21:21 blueness joined
21:22 <jirutka> maybe they finally realized how horrible mistake they did and stopped? okay, just kidding, I’m not so naive…
21:26 <mikeee_> :D
21:26 <TemptorSent> mikeee_: I suspect it's considered "stable" and "mature" by the upstream, thus won't see a release unless a major bug turns up.
21:27 <jirutka> and apparently they don’t consider horrible design as a major bug…
21:28 <TemptorSent> *lol* Nope, that's a FEATURE, not a bug :)
21:30 tmh1999 joined
21:31 <TemptorSent> Hey guys, can a get a few eyeballs and testing on this fkrt (fakeroot) utility script: http://termbin.com/p8o8
21:33 <TemptorSent> It lets you setup multiple fakeroot environments and switch between them from a shell or in a script.
21:33 <kaniini> ncopa: basically we have backported everything anyway :P
21:33 <TemptorSent> fkrt_enable <instance>
21:38 <jirutka> TemptorSent: why do you prefix even local variables with fkrt_fakeroot…?
21:39 <TemptorSent> jirutka: Refactoring artifacts :)
21:40 <jirutka> and some variables inside funcs are not declared as local and it’s not clear if it’s an intention or not, they are not differentiated from locals (e.g. by using capitals)
21:40 <TemptorSent> jirutka: Obviously, the local vars can get shortened.
21:40 <jirutka> mixed tabs and spaces…
21:41 <jirutka> fkrt_use_abs_lib_path is basically a constant (it’s not changed anywhere), so `[ $fkrt_use_abs_lib_path -ne 0 ]` doesn’t make much sense
21:41 <TemptorSent> jirutka: Thanks, it started as /usr/bin/fakeroot :)
21:42 <jirutka> `[ "$LD_PRELOAD" ]` … this is not very safe… use -n
21:43 <TemptorSent> AFAIK, [ "$str" ] is equal to [ -n "$str" ] in this case?
21:44 <jirutka> "Implement setvar function (Why is this missing from our version of ASH?)" … well, b/c it’s not in POSIX standard… actually I don’t know about any shell that implements this func
21:45 <jirutka> what are all these `[ "$1" ] && _inst="_$1"`?
21:45 <TemptorSent> jirutka: The ash man page states setvar is a builtin.
21:45 <jirutka> "AFAIK, [ "$str" ] is equal to [ -n "$str" ] in this case?" … no, it’s not
21:45 <jirutka> ah, you’re right about setvar
21:46 <TemptorSent> jirutka: Can you point me at a document for that? The man page for test states that equivilence explicitly.
21:48 <jirutka> pardon, it seems that you’re right about [ "$foo" ]
21:48 <TemptorSent> jirutka: the [ "$1" ] && _inst="_$1" statments check if an argument has been passed and set the instance suffix after adding a "_"
21:48 <jirutka> but it must be really quoted string
21:49 <TemptorSent> jirutka: Right, for safety, I always quote my vars unless I REALLY intend to pass the raw value.
22:25 irclogger_com joined
22:25 Topic for
22:35 <TemptorSent> jirutka: Revised per your comments, please take a look: http://termbin.com/wm7uc
22:36 <jirutka> so `fkrt_ld_preload` is meant to be global?
22:37 <TemptorSent> jirutka: Yes, that's what gets set into LD_PRELOAD when the a fakeroot is active.
22:37 <jirutka> then i’d name it in CAMEL_CASE, to be clear that it’s a global variable, not local
22:39 <jirutka> hm, actually…
22:40 <jirutka> all such variables are prefixed with fkrt_, so it’s probably clear enough
22:41 <jirutka> `[ -p "$fkrt_database_file" ] $$ fkrt_wait_in_trap=1` … shouldn’t be there && or || instead of $$?
22:41 tmh1999 joined
22:42 <TemptorSent> jirutka: Yeah, I cleaned up the prefixing to clarify that. All variables and functions start with fkrt_
22:43 <TemptorSent> Woah, missed that one!
22:43 <jirutka> why you’re doing this: `fkrt_inst_list="$fkrt_inst_list ${_inst#_}"; fkrt_inst_list="${fkrt_inst_list## }"`?
22:43 <TemptorSent> Currently, the db load/save are dead code.
22:44 <TemptorSent> Trimming leading spaces :)
22:44 <jirutka> do you really need to trim them…?
22:44 <TemptorSent> I'm tempted to just drag in my list util to handle it, nicely.
22:45 <TemptorSent> probably not absolutely necessary, but it keeps everything clean for inspection in the shell anyway :)
22:45 <jirutka> I don’t think that a single leading space can hurt…
22:46 <TemptorSent> Not until it gets used by something else later like awk :)
22:46 <jirutka> and yes, util function for appending to list would be better then this
22:47 <TemptorSent> jirutka: Easy enough to change it, since I'm using the util for mkimage anyway.
22:49 <jirutka> btw where’s this script actually used?
22:50 <TemptorSent> jirutka: I'm building it for use in mkimage for building overlays, but the intent is to have a general-purpose set of utilities for any scriping needs.
22:50 <TemptorSent> It also works right at the shell by sourcing and running the functions.
22:51 <jirutka> and what is it actually doing? it seems that it just sets LD_PRELOAD…
22:55 <TemptorSent> jirutka: Pretty much yes, along with starting faked and keeping track of keys and pids.
22:56 <jirutka> what does it do when fkrt_lib is not found? it does abort, right?
22:59 <TemptorSent> jirutka: Here's the revision and including the list utils: http://termbin.com/plcu
23:00 <jirutka> uff, why is there so many redundant code?!
23:00 <TemptorSent> Yes, it bails out with a return value of 1 and prints a warning on failure (actually, warning function defined by abuild utils)
23:01 <jirutka> then why it’s so unnecessary verbose? it can be shorten as https://hastebin.com/kolukoxoti.sh
23:01 <TemptorSent> jirutka: Agreed, I don't like the redundancy, but it ends up being simpler per function than than putting it all in a big case.
23:01 <jirutka> and I doubt if global variable fkrt_lib_found is needed at all
23:02 <jirutka> no, I don’t mean splitting code in multiple functions, but a lot of dead code or unnecessary verbose code
23:03 <TemptorSent> jirutka: the fkrt_lib_found signifies that init has run successfully. I suppose I could use fkrt_ld_preload for that purpose instead actually.
23:05 <jirutka> probably, there are so many vars that I can’t keep it in head
23:06 <TemptorSent> actually, I can probably eliminate the variable entirely and merge the if statement.
23:06 stwa joined
23:06 BitL0G1c joined
23:06 <jirutka> the actual lib is written in C, isn’t it? wouldn’t it be better to rewrite this script into C?
23:07 <jirutka> it doesn’t look like a task for which shell is a good tool
23:08 <TemptorSent> The issue is that I need to be able to toggle the fakeroot environment on and off in the shell scripts for building images.
23:09 <TemptorSent> And I might have several fakeroot environments going simultaneously during the build.
23:10 <TemptorSent> This lets me keep them all straight from within the script, using passing the section I'm building as the instance name.
23:11 <TemptorSent> I probably could have written the script from scratch instead of starting with the existing fakeroot script, but I'm not that familiar with fakeroot/faked, so I figured I'd start with somethign that worked and extend it.
23:13 <TemptorSent> I dont' currently have a need for the db save/restore abilities, but I figured I'd leave them in and make them work in case a need pops up later.
23:14 <jirutka> the only thing that these 273 (486) lines do is setting three variables: LD_PRELOAD, FAKED_MODE, FAKEROOTKEY, right?
23:14 <jirutka> ah and killing processes
23:15 <jirutka> and keeping track of pids
23:17 <TemptorSent> init sets up the environment, then faked_start runs a new faked for each instance, tracking pid, key, options, etc. for each.
23:17 <jirutka> maybe it may be simpler to store state in file(s) then in variables
23:18 <TemptorSent> enable runs init and starts the instance if not already running, then sets LD_PRELOAD FAKEROOTKEY and FAKED_MODE for that instance.
23:18 <TemptorSent> disable unsets the environment variables.
23:19 <TemptorSent> faked_stop shuts down an instance of faked and cleans up the environment.
23:19 <TemptorSent> cleanup stops all instances.
23:20 <TemptorSent> faked_kill does the actual killing of processes.
23:21 <TemptorSent> and cleanup is registered as the signal handler for INT/EXIT so we don't leave a mess behind when it exits.
23:22 <TemptorSent> part of the problem with storing state in files is that fakeroot is by design screwing with the apparent permissions and we don't necessarily have a designated storage location that isn't faked.
23:23 <TemptorSent> Needles to say, a couple arrays in bash would have made this all very simple indeed, but we're POSIXly correct (or mostly so) on Alpine, so it takes a bit of trickery to support.