<    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 24 25  
26 27 28 29 30 31
00:13 ostera joined
00:27 ostera joined
00:41 ostera joined
00:41 blueness joined
00:54 ostera joined
01:08 ostera joined
01:21 ostera joined
01:35 ostera joined
01:38 blueness joined
01:48 ostera joined
01:49 eleksir joined
01:50 s33se_ joined
02:02 ostera joined
02:16 ostera joined
02:29 ostera joined
02:39 Emperor_Earth joined
02:43 ostera joined
02:56 ostera joined
03:10 ostera joined
03:15 <TemptorSent> ncopa: When you get a chance look at latest rev of my mkimage branch. mkinitfs.sh wrapper top level, a feature converter script in the initfs directory, and all existing mkinitfs features in a compat dir.
03:16 <TemptorSent> ncopa: Plus all command-line options supported, and listing gives you a complete list of files and deps, not just globs.
03:23 ostera joined
03:24 <TemptorSent> ncopa: Okay, and it lists features too :)
03:31 blueness joined
03:37 ostera joined
03:51 ostera joined
04:04 ostera joined
04:18 ostera joined
04:31 ostera joined
04:45 ostera joined
04:58 ostera joined
05:03 fabled joined
05:03 <TemptorSent> Hello fabled.
05:12 ostera joined
05:18 blueness joined
05:20 <TemptorSent> fabled: Is there any convenient way of reading the checksums for the files out of an apk tarball?
05:26 ostera joined
05:32 <fabled> TemptorSent, apk does that internally, 'apk audit' can check disk against the installed db
05:36 <TemptorSent> fabled: Hmm. what I really need is actually getting the hash and filename so I can make a manifest.
05:36 <fabled> manifest? for what?
05:36 <TemptorSent> fabled: I can find the hash in the extended headers, but it needs parsing.
05:36 <fabled> yes, it's in the standard pax header
05:37 <TemptorSent> fabled: Kernel files ( kernel/modules/dtbs), as well as individual files out of apks.
05:38 <TemptorSent> fabled: When we create the initramfs and install kernels, we no longer have any information on the file origins or checksums, let alone signatures.
05:39 ostera joined
05:40 <TemptorSent> fabled: Speaking of pax, why do we not have a pax tool?
05:53 <TemptorSent> fabled: Or any way of extracting them short of writing a minimal tar parser?
05:53 ostera joined
05:54 faffolter joined
05:54 faffolter joined
06:06 ostera joined
06:20 ostera joined
06:34 ostera joined
06:47 ostera joined
07:01 ostera joined
07:14 ostera joined
07:16 t0mmy joined
07:28 ostera joined
07:30 tmh1999 joined
07:42 ostera joined
07:51 faffolter joined
07:55 ostera joined
07:57 royger joined
07:57 leo-unglaub joined
08:03 tty`_ joined
08:09 ostera joined
08:22 ostera joined
08:31 tmh1999 joined
08:32 vakartel joined
08:36 ostera joined
08:38 ncopa joined
08:38 ncopa joined
08:40 czart_ joined
08:49 ostera joined
09:03 ostera joined
09:05 blueness joined
09:17 ostera joined
09:30 ostera joined
09:34 fabled joined
09:35 fab joined
09:44 ostera joined
09:51 medber joined
09:56 ncopa joined
09:57 ostera joined
10:11 ostera joined
10:21 ostera joined
10:49 blueness joined
10:53 blueness joined
11:17 blueness joined
11:33 blueness joined
11:41 LouisA joined
11:51 rdutra joined
12:08 leitao joined
12:09 farosas joined
12:11 ferseiti joined
12:20 gromero joined
12:21 medber joined
13:18 vakartel joined
15:27 t0mmy joined
15:47 pickfire joined
16:44 ferseiti joined
16:49 <leitao> how do I check which error my APK is complaining about?
16:49 <leitao> $ sudo apk -v --allow-untrusted add bc
16:49 <leitao> 1 errors; 355 packages, 2621 dirs, 32461 files, 1434 MiB
17:05 ferseiti joined
17:06 rdutra joined
17:08 t0mmy joined
17:24 <kaniini> apk fix
17:31 <TemptorSent> kaniini: Any secret way you know of getting xattrs out of the pax headers in apks?
17:37 <kaniini> no
17:37 <TemptorSent> Damn. Okay, who's got a good version of pax to port?
17:40 <TemptorSent> I'd rather not try to mess with gnu paxutils, as that appears to be a mess without any musl fun.
17:41 <Shiz> 'of pax'?
17:41 <Shiz> pax is part of grsec
17:42 <TemptorSent> No, pax, not PaX or whatever.
17:42 <Shiz> aah
17:42 <Shiz> my bad
17:42 <TemptorSent> pax is THE posix archive tool, but we don't have it.
17:43 <Shiz> THE posix archive tool nobody ever uses
17:43 <Shiz> :p
17:43 <TemptorSent> Shiz: Except we do -- take a look at the headers in apks.
17:43 <Shiz> what about them?
17:44 <TemptorSent> Shiz: I need to read the pax headers, and I'd prefer it to cpio for bulk copies.
17:45 <Shiz> ? pax headers
17:46 <TemptorSent> See 'pax - portable archive interchange' in opengroup base spec issue 7 of IEEE Std 1003.1-2008,2016
17:46 <algitbot> Bug #7: -u option will upgrade all packages not just deps. - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7
17:46 <TemptorSent> WTF?
17:46 <Shiz> 'issue 7'
17:46 <algitbot> Bug #7: -u option will upgrade all packages not just deps. - Alpine Package Keeper - Alpine Linux Development: http://bugs.alpinelinux.org/issues/7
17:46 <TemptorSent> *lol* Ahh.
17:47 <nmeum> TemptorSent: You could port (Open|Net|Free)BSD pax
17:47 <Shiz> anyway
17:47 <Shiz> gnu tar should be able to handle it just fine as well
17:48 <TemptorSent> nmeum: Yeah, that's what I'm currently thinking. I was hoping someone had a nice, small, clean standalone version I could snag right off :)
17:48 <TemptorSent> Shiz: Yeah, which requires gnu tar, which is a big mess.
17:50 <TemptorSent> Shiz: And I'm not sure gnu tar properly implements the list mode output options, which is what I need.
17:50 <nmeum> porting OpenBSD pax should be quite simple
17:51 <nmeum> and avoiding gnu tar sounds like a good idea
17:52 <TemptorSent> nmeum: Any idea on a link to the primary development source for openbsd's pax? Straight to their tree?
17:52 <TemptorSent> Really, pax should be added to busybox/toybox.
17:54 <TemptorSent> nmeum: Hmm, the version of openbsd pax I'm looking at doesn't look great :/
17:54 <Shiz> https://github.com/vapier/openbsd-pax
17:55 <Shiz> slightly outdated
17:55 <Shiz> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/pax/
17:55 <TemptorSent> Shiz: Yeah, that's what I'm looking at...
17:55 <Shiz> their cvs
17:55 <nmeum> TemptorSent: why does it look bad?
17:56 <TemptorSent> nmeum: It's tar/cpio/pax all in one, which is okay, except they use lots of global scope, which might be a problem.
17:56 <nmeum> ah well that sucks
17:56 <Shiz> well, pax is just tar
17:56 <Shiz> :p
17:56 <Shiz> global scope is ugh
17:57 <TemptorSent> Yeah, I haven't looked too close yet, but it would require some surgery I'm thinking.
17:58 <TemptorSent> Yeah, pax.c is a real turn-off.
17:59 <TemptorSent> Why, oh why, did they NOT encapsulate a dozen flags and state information in a struct?
18:00 <TemptorSent> Okay, any other contestants?
18:01 <Shiz> https://github.com/freebsd/freebsd/tree/master/bin/pax
18:01 <Shiz> seems to be mostly the same
18:02 <TemptorSent> Yup. Crappy coding practice IMHO.
18:06 <TemptorSent> Looking at gnu paxutils... even worse, it dependsd on a bunch of OTHER gnu crap to build.
18:07 <TemptorSent> gnulibs specifically
18:10 <skarnet> you want good software, don't look at software specifically made by distributions
18:10 <skarnet> be it GNU or *BSD
18:11 <nmeum> are you aware of any other pax implementation?
18:11 <skarnet> unfortunately I'm not
18:11 <TemptorSent> skarnet: Yeah, I'm looking for anything BUT and not finding it.
18:12 <skarnet> but honestly only people who need scrupulous posix compliance are going to implement pax
18:12 <skarnet> so I don't think you'll find any other implementation :(
18:13 <TemptorSent> skarnet: Looks like I get to do surgery :/
18:14 <TemptorSent> Hmm, MirOS maybe?
18:18 <nmeum> debian seems to have ported MirBSD pax to linux already https://anonscm.debian.org/git/collab-maint/pax.git/tree/pax.c#n56
18:18 <skarnet> MirBSD is a good idea indeed
18:19 <TemptorSent> Yeah, that's the one I was looking at... at least likely a better starting point.
18:20 <skarnet> still the same old BSD origins, but, eh.
18:22 <TemptorSent> Yeah, but hopefully at least someone has already caught the worst gotchas.
18:26 <TemptorSent> Still same crap in there... I was hoping to merge it into bb/tb without that much pain.
18:30 <TemptorSent> Hmm... Take a look a this: https://sourceforge.net/projects/heirloom/
18:33 <TemptorSent> Old code, but looks half sane...
18:34 <TemptorSent> Formatting is FUBAR though.
18:36 <TemptorSent> skarnet: What's you take on the heirloom stuff?
18:37 <skarnet> I have no idea what it is and I'm not going on sourceforge
18:38 <TemptorSent> Updated implementations of classic unix tools by a guy named Gunnar Ritter... about 10 years old.
18:39 <TemptorSent> heirloom.sourceforge.net for the home page -- looks like it was pre-SF stupidity by quite a bit.
18:43 <TemptorSent> Hmm, not seeing ANYTHING from the author since then.
18:47 <TemptorSent> Well, I guess that's a bust. 2010 is last activity I can find.
18:48 <TemptorSent> And license is simple, but non-standard.
19:16 <TemptorSent> It looks like MirCPIO (paxmirabilis) is the best option.
19:28 <kaniini> mircpio is already packaged in adelie (a psuedo-fork of alpine using gentoo ebuilds)
19:28 <kaniini> i'll copy it over
19:29 <asie> "Caused by: java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/libfontmanager.so: Error relocating /usr/lib/jvm/java-1.8-openjdk/jre/lib/amd64/libfontmanager.so: AWTFontDefaultChar: symbol not found" happened again, still not sure why it happens
19:30 <kaniini> does it only happen on openjdk8?
19:30 <kaniini> (have you tried openjdk7)
19:31 <asie> Same issue on Java 7
19:31 <asie> it began with a fairly recent OpenJDK update, IIRC
19:31 <asie> as in, in Alpine's repos
19:33 <asie> though openjdk7 wasn't updated them
19:34 <asie> so it might be something related
19:35 <asie> i feel it might be related to libawt_*.so not being loaded correctly?
19:38 <jirutka> looks like ABI incompatibility…
19:39 <jirutka> maybe just rebuild openjdk?
19:40 <asie> might be
19:40 <asie> AWTFontDefaultChar sohuld be provided by java itself, though, but maybe something else gets broken earlier
19:40 <TemptorSent> kaniini: Thank you, much appreciated!
19:41 <TemptorSent> kaniini: I was just about to start packaging it from scratch and ran into bb tar/cpio not being able to read the distfiles!
19:42 <TemptorSent> kaniini: It looks like debian has a ustar version in their download pool.
19:44 <TemptorSent> kaniini: You might want to make the installed links as 'paxcpio' 'paxtar' 'paxar', unless we want to consider that toolset as the default for alpine.
19:48 <TemptorSent> kaniini: From deb description: "Note that ACLs and Extended Attributs not supported." WTF?
19:50 <TemptorSent> kaniini: All I want is POSIX tools that support POSIX extensions!
19:51 <TemptorSent> I don't want to have to use bloody libarchive to read a few checksums!
19:51 <* TemptorSent> opened a can of worms
19:57 <kaniini> why not just add the feature to apk tools
19:58 <TemptorSent> kaniini: Immediate term, all I'm trying to do is build a manifest of individual files based on the checksums found in our signed apks, and be able to verify an individual file is unchanged from the version in the archive eve if it's NOT installed elsewhere.
19:58 <TemptorSent> kaniini: Yeah, that's what's looking like the easiest solution at this point.
19:58 <TemptorSent> kaniini: But proper pax archive support would be very nice to have.
19:59 <TemptorSent> kaniini: Neither cpio nor tar are reliable when it comes to dumping a filesystem with attributes.
20:00 <TemptorSent> kaniini: Any chance a signed manifest file might make its way into the next APK spec?
20:00 <TemptorSent> kaniini: I could see downloading all such manifests from a repo to get a list of providers of files across the entire ecosystem.
20:01 <kaniini> why not use libarchive then
20:01 <TemptorSent> kaniini: Right now, I'm working on making mkinitfs know where it's files should come from and knowing if files are missing.
20:02 <TemptorSent> kaniini: in initfs? No thank you!
20:02 <TemptorSent> kaniini: I'm using apk.static and busybox.static and that's it!
20:03 <TemptorSent> kaniini: I could stomach adding a static linked pax tool, but it doesn't look like it solves the problem anyway.
20:03 <TemptorSent> kaniini: so teaching apk to spit out the checksums given an apk and a filename is probably my best bet.
20:04 <TemptorSent> kaniini: It means we need the whole apk to verify the manifest though.
20:06 <TemptorSent> kaniini: Two questions I'm trying to get it to answer automatically: "What packages do I need to get the required files" and "Where does each file in the initfs come from and what are it's checksums"
20:08 <TemptorSent> kaniini: The issue is that update-kernel currently basically blindly installs whatever it finds and doesn't store any information about what it did.
20:08 <TemptorSent> kaniini: And mkinitfs is fed a base directory and kernel version, but has no idea where it's files came from.
20:12 <TemptorSent> kaniini: Where are you at with install stuff?
20:16 ysh joined
20:17 <kaniini> installer isn't happening until after 3.6
20:17 <TemptorSent> kaniini: Hmm, okay... What's missing for it at this point?
20:36 <TemptorSent> kaniini: Also, we may want to take a look at this: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git
20:38 <TemptorSent> kaniini: Secure-boot might not be too hard where available anyway.
20:40 <kaniini> TemptorSent: everything, because i am still designing the configuration database layer
20:41 <TemptorSent> kaniini: Okay :) Does that layer play nicely with dialog by chance?
20:41 <kaniini> TemptorSent: it is the goal that it will
20:41 <TemptorSent> kaniini: That makes me smile :)
20:41 <kaniini> TemptorSent: what i am aiming for is debconf done right
20:41 <kaniini> TemptorSent: and not used everywhere
20:41 <kaniini> TemptorSent: like in debian, if you want to configure something, it should be optional instead of how debian does it
20:42 <kaniini> so if you do
20:42 <TemptorSent> kaniini: Exactly - it should be a tool, not the system.
20:42 <kaniini> apk add --configure mariadb-server
20:42 <kaniini> then it will try to set up the package for you
20:42 <kaniini> but if you just do
20:42 <kaniini> apk add mariadb-server
20:42 <kaniini> then it will assume you know what you are doing
20:43 <TemptorSent> kaniini: Or at least a config option could decide the default action.
20:43 <kaniini> it should track which packages it configured automatically so that it can reconfigure those on upgrade
20:43 <TemptorSent> kaniini: Ideally, with markers IN the config files that it can scan.
20:44 <kaniini> that's outside of the scope
20:44 <kaniini> the idea is to leverage a new script type: package.configure
20:44 <kaniini> which runs after package.post-install
20:44 <kaniini> or maybe before package.post-install
20:44 <kaniini> not sure
20:44 <TemptorSent> kaniini: I mean when writing values to config files, it should have tokens that indicate what configured it and why.
20:45 <kaniini> that's also outside the scope
20:45 <TemptorSent> kaniini: Let it run before/after each script with hooks as needed.
20:45 <kaniini> the software itself will not generate configuration files
20:45 <kaniini> that is up to the maintainer scripts to do
20:45 <kaniini> but yes, probably
20:45 <jirutka> no, no, please not anything like debconf!
20:45 <kaniini> it's not like debconf
20:46 <kaniini> debconf is a giant pile of garbage you cant opt-out
20:46 <jirutka> when you need to configure some software, you should edit its config files, easy
20:46 <TemptorSent> kaniini: Right, but you can pass both the value and the context back to your calling program with an option.
20:46 <jirutka> it’s user’s responsibility to configure software, not ours, for the god sake
20:46 <kaniini> jirutka: this is more to replace things like setup-xorg-desktop
20:46 <kaniini> not really to sit there and configure software
20:47 <jirutka> kaniini: so just for desktop users?
20:47 <TemptorSent> jirutka: That's great up to a point, but makes autodeployment rather prolematic.
20:47 <kaniini> jirutka: well, setup-alpine itself too
20:47 <kaniini> jirutka: just the setup-* scripts
20:47 <jirutka> hm
20:47 <kaniini> jirutka: and make it possible for package maintainers to add new ones
20:47 <kaniini> jirutka: and move all of that mess out of /sbin
20:47 <TemptorSent> /usr/share/alpine perhaps?
20:47 <jirutka> yeah, it’d be cleaner to move configuration script out of init script e.g. for PostgreSQL…
20:48 <kaniini> jirutka: it's "like" debconf, in that it asks questions and stores data in a database. it's not like debconf in that you have to explicitly ask for it
20:48 <jirutka> but we can do this already, it’s just a simple shell script
20:48 <jirutka> why it should store some data in database?
20:48 <TemptorSent> jirutka: PostgreSQL does a setup-if-not-existing optionally.
20:48 <kaniini> jirutka: preseeding
20:48 <jirutka> configuration is in textual configuration files, not some fucking registry…
20:48 <kaniini> jirutka: so that you can do unattended installs
20:49 <TemptorSent> Or duplicate a configuration with variations.
20:49 <kaniini> jirutka: yes, a directory tree of files
20:49 <jirutka> this is job for configuration management tool…
20:49 <jirutka> just all existing tools totally sucks
20:49 <kaniini> jirutka: okay and ansible can install alpine to disk ?
20:49 <TemptorSent> I think the point is to make tools that don't suck :)
20:50 <jirutka> kaniini: if you’re insane enough, you can surely write hundreds of lines of YAML to do that…
20:50 <kaniini> jirutka: my point is that we may as well go all the way and provide one configuration manager that does not suck
20:50 <kaniini> jirutka: since 90% of it is needed to allow unattended installs anyway
20:50 <TemptorSent> I already already have autoconfig for ssh and postgress working in overlays using mkimage.
20:50 <jirutka> kaniini: then I believe that CFM should not be tightly coupled with particular linux distribution
20:50 <TemptorSent> I'll pass on the yaml, thanks!
20:51 <jirutka> TemptorSent: what? no!
20:51 <jirutka> TemptorSent: scripting in YAML and Jinja2 is the most stupid idea ever
20:51 <kaniini> jirutka: there's no reason why the CFM could not be reused by other distributions. the only thing i propose is adding awareness of it to apk-tools.
20:51 <TemptorSent> jirutka: *LOL*
20:52 <jirutka> kaniini: okay, I’ll wait for some design ideas… I’m just totally terrified since you’ve mentioned debconf
20:52 <kaniini> debconf is the only thing really close in terms of what our setup-* scripts presently do
20:52 <kaniini> our scripts ask questions, get answers, and then do things with those answers
20:53 <kaniini> this is precisely what debconf does
20:53 <jirutka> eh…
20:53 <kaniini> the problem with debconf is that debian crams it down your throat
20:53 <TemptorSent> jirutka: I need similar functionality to make building custom profiles cleaner.
20:54 <kaniini> what i want to be able to do is boot an alpine ISO with preseed=http://whatever.com/blahblah.conf
20:54 <kaniini> which has things like
20:54 <TemptorSent> If we could do things like do some hardware autodetection and preload defaults, most of the setup issues we hear would be solved.
20:54 <kaniini> setup/target-disk sda;
20:54 <kaniini> setup/target-disk/sda/usage-type sys;
20:55 <jirutka> autodetection usually leads directly to hell…
20:55 <kaniini> setup/passwordhash $6$...;
20:55 <kaniini> and then the installer can use those answers
20:55 <kaniini> instead of asking questions
20:55 <TemptorSent> jirutka: Yes, that's why we just preload defaults and give it to the users to look at, rather than just loading them like we currently do.
20:56 <jirutka> isn’t easier to just directly provide plain configs? something like overlay for /etc
20:56 <kaniini> jirutka: how does that solve setup-alpine problem ?
20:56 <jirutka> kaniini: what problem exactly…?
20:56 <kaniini> jirutka: i want it automated
20:57 <jirutka> kaniini: I want it *simple* and transparent
20:57 <TemptorSent> jirutka: How do you use an overlay to actually format drives, install filesystems, setup bootloaders, etc?
20:57 <kaniini> jirutka: okay, and foo=$(aconf get-var setup/target-disk) is not transparent ??
20:57 <jirutka> every system that tried to automate such thing that I’ve seen (OpenSUSE, Debian, Ubuntu, …) was directly against these principles
20:58 <kaniini> foo=$(aconf get-var setup/target-disk) is not transparent ??
20:58 <kaniini> yes/no
20:58 <jirutka> kaniini: it depends…
20:59 <jirutka> TemptorSent: well, this is basic installation of system, not configuring arbitrary software like debconf do…
20:59 <jirutka> kaniini: it depends on how and where are these variables stored, how you set them and how you can change them
20:59 <kaniini> the idea is that it invokes a tool to search for /etc/aconf/answers/setup/target-disk, if it doesn't find one, it looks for /etc/aconf/templates/setup/target-disk and asks the question
21:00 <TemptorSent> kaniini: you might even make that ': "${foo-"$(aconf get-var setup/target-disk)"}"' and make it so the vars can be preset
21:00 <jirutka> I’d like to finish something now; I’d like to discuss this later, if we talk about more-or-less generic CFM, I have some ideas about it
21:00 <kaniini> the template would define a reasonable default, so that's not necessary
21:01 <jirutka> now I’ll try to forgot about that you’ve ever mentioned debconf as inspiration :)
21:01 <TemptorSent> Ideally, packages should know how to configure themselves and ask the right questions.
21:01 <kaniini> i think having a CFM built-in to alpine is the next logical step
21:01 <kaniini> but no, it should not be like how debian did debconf
21:02 <kaniini> i don't want to have it crammed in my face if i install apache
21:02 <TemptorSent> What I have in mkimage is very simple, but it already delegates the actual config to the inidivual feature providers and just takes high-level requests.
21:02 <kaniini> what i propose there is adding a new maintainer script: configure, which is optionally invoked if asked for
21:03 <jirutka> TemptorSent: and that’s exactly what I don’t want to; every software has its configuration file(s) or CLI arguments, it’s easier to learn just the software itself instead of learning that and also how to set something using some debconf-like tool; that’s exactly what I hate about debconf and similar
21:04 <TemptorSent> jirutka: Okay, for instance I have the ssh feature that knows how to autogenerate keypairs -- it will work with both openssh and dropbear without having to have two seperate profiles and configurations.
21:04 <jirutka> TemptorSent: no, it’s just another layer of abstraction
21:05 <kaniini> jirutka: right now i am mainly interested in leveraging this infrastructure to replace the current installer stuff
21:05 <TemptorSent> jirutka: Yes, and for automated installation, its the only sane way of handing similar systems with different specific requriements.
21:05 <kaniini> jirutka: that it could be used more deeply in the system (if done right) is an interesting evolution of it, but not my primary goal right now
21:05 <TemptorSent> jirutka: Do we really want to write a totally differnt installer for every filesystem we might support?
21:05 <jirutka> TemptorSent: no, no and no. additional layers of abstraction over configuration are a road to hell
21:06 <TemptorSent> jirutka: Most of the context is the same (what kaniini is working on), only the details change.
21:06 <TemptorSent> jirutka: Um, why exactly do we have the VFS in the first place, if not ABSTRACTION to the point of common function?
21:07 <jirutka> but most likely we have very different mindset now so I see something different above these words
21:08 <TemptorSent> jirutka: I'll let you write setup-alpine-disk-afs .. setup-alpine-disk-ext2 and setup-alpine-disk-ext3 and.. setup-alpine-disk-zfs
21:08 <jirutka> no, that’s not what I wanted
21:08 <TemptorSent> jirutka: How about one setup-alpine-disk program, and each FS we support knows how to take what we specify and turn it into a FS on disk?
21:08 <kaniini> jirutka: at any rate, what debian does is not what i have in mind. what i want is an optional CFM system that is used for the installer, and then maybe later for commonly used packages
21:09 <jirutka> ofc it’s okay to have setup-disk that can handle multiple FSs
21:09 <TemptorSent> jirutka: What kaniini is doing is writing a means of capturing that configuration in a portable fashion, so we can let whichever specific utility we need do the heavy lifting and not have to ask the questions itself.
21:10 <TemptorSent> I'd be happy with even a flat kernel .config style output to be honest.
21:13 <TemptorSent> jirutka: The point is make one piece of code do the work of collecting answers regardless of who's asking.
21:13 <TemptorSent> ...kinda like the guy running around with the clipboard and mike at meetings to take speakers comments.
21:14 <kaniini> for what it's worth, debconf itself isn't a bad software. it was just implemented very obnoxiously in debian
21:15 <TemptorSent> kaniini - I haven't looked at the guts of it, but debian used to be near the top of the heap in quality -- what a long slide.
21:16 <kaniini> debconf was a victim of the 90s
21:17 <kaniini> they wanted to make installing things in the distribution feel like InstallShield
21:17 <kaniini> (ew)
21:17 <kaniini> but the core software itself isn't bad
21:17 <kaniini> it's just written in perl
21:17 <kaniini> which makes it useless for us
21:18 <TemptorSent> Yeah, I'd almost be tempted to see if theres a nice small lisp we could use.
21:18 <kaniini> debconf is basically a tale of taking a good idea (configuration management) and going completely insane with it (because of 1990s thinking)
21:18 <kaniini> lisp???
21:18 <TemptorSent> It is almost ideal for such tasks.
21:18 <kaniini> i can write this in C in a day
21:19 <TemptorSent> s-expressions -- take a quick look.
21:19 <kaniini> i know what lisp is
21:19 <TemptorSent> You could probably write the parser for it in seconds flat.
21:19 <kaniini> yes and then we have to include a lisp as a dependency
21:19 <kaniini> no thanks
21:20 <TemptorSent> No, you just embed it in your tool.
21:20 <kaniini> i already have a format: rfc822, and i already have a parser: the one in pkgconf
21:20 <TemptorSent> it's TINY
21:21 <jirutka> why not write it in Lua?
21:21 <kaniini> i dont know lua
21:21 <jirutka> if you need to parse text, LPeg is awesome
21:21 <kaniini> and lua isn't an alpine-base dependency
21:21 <TemptorSent> jirutka: lua is huge compared to lisp.
21:22 <jirutka> lol
21:22 <TemptorSent> lisp parsers can be written in less than a hundred lines of code.
21:22 <jirutka> show me reasonable fast implementation of Lisp with binary less than 148 kiB
21:22 <jirutka> many tools in Alpine are written in Lua
21:23 <TemptorSent> jirutka: I wouldn't object to lua, but for storing data, it's probably not as nice as lisp s-exprs
21:23 blueness joined
21:23 <jirutka> C, POSIX-sh, Lua are three most common langs in Alpine toolset
21:24 <jirutka> what data do you want to store?
21:24 <TemptorSent> jirutka: Okay, but what do we have for storing list structured data well?
21:25 <jirutka> btw I’m not entirely against Lisp, it’s one of the better options, just your argument about that Lua is huge…
21:26 <TemptorSent> jirutka: Just compared to a lisp parser for the same application.
21:26 <kaniini> the answers are just text man
21:26 <kaniini> there's nothing to parse
21:26 <kaniini> the one thing i havent figured out is
21:27 <kaniini> how to ask questions from a subshell
21:27 <kaniini> because
21:27 <kaniini> $() will capture stdout
21:27 <jirutka> parsing is not all what you need
21:27 <jirutka> use stderr instead of stdout
21:27 <kaniini> what about stdin
21:27 <hl> kaniini: 'ask questions from a subshell'?
21:27 <jirutka> well, that’s another story…
21:28 <TemptorSent> kaniini: What lisp gives you is the ability to handle complex expressions and lists of lists, AND pass them as plain text.
21:28 <kaniini> and what if i want to use dialog()
21:28 <jirutka> dialog()?
21:28 <kaniini> er
21:28 <kaniini> dialog(1)
21:28 <kaniini> GNU dialog
21:28 <hl> ah
21:28 <skarnet> don't backtick
21:28 <skarnet> obviously
21:29 <jirutka> uh, why?
21:29 <jirutka> why dialog?
21:29 <skarnet> because then stdout will be a pipe and you just lost the ctty
21:29 <hl> basically, you want the dialog process to have isatty(stdout)==true? hmmm
21:29 <TemptorSent> dialog knows how to use other fds iirc
21:29 <kaniini> jirutka: as an optional way of sexing up the installer
21:29 <skarnet> fd manipulation is a solved problem
21:30 <hl> man dialog: --input-fd, --output-fd
21:30 <jirutka> do you really want to provide the same awful experience as debconf with its superugly ncurses dialogs or what the heck is that?
21:30 <kaniini> not really
21:30 <hl> if subshells replace fds 0/1, just use sh exec to dup them, I think
21:30 <TemptorSent> yeah, dialog makes handling long lists of items and selecting a few a lot easier (think devices)
21:30 <hl> jirutka (IRC): hey, take that back, whiptail is beautiful
21:31 <hl> jirutka (IRC): if you have some weird retro fondness for DOS GUIs >:D
21:31 <jirutka> hl: exactly opposite, I hate DOS-like GUIs
21:31 <kaniini> jirutka: gtk+ may make more sense
21:31 <kaniini> jirutka: than dialog
21:31 <kaniini> jirutka: say we have an alpine desktop livecd (this used to exist actually)
21:31 <kaniini> jirutka: and on there is an icon that says "Install alpine"
21:32 <skarnet> if I need a GUI to install alpine
21:32 <kaniini> jirutka: then we would want to ask questions in a gtk+ mode
21:32 <skarnet> I won't install alpine
21:32 <hl> kaniini: you'd better not be requiring GUIs to install alpine now
21:32 <jirutka> skarnet: exactly!
21:32 <kaniini> omfg
21:32 <jirutka> skarnet: oh, you’re my man
21:32 <skarnet> why? because headless
21:32 <skarnet> because qemu
21:32 <kaniini> i didn't say anything about a GUI requirement
21:32 <TemptorSent> dialog also speaks gtk if you need it, AND works over MY serial console.
21:32 <kaniini> you fucking morons
21:33 <skarnet> either we're fucking morons or you did a bad job of expressing yourself :P
21:33 <kaniini> i said, in a hypothetical situation
21:33 <kaniini> if you booted an alpine desktop livecd
21:33 <kaniini> WHICH MEANS YOU ARE ALREADY IN A GUI LOL
21:33 <kaniini> then you would probably want to keep using the GUI to install the damn thing
21:33 <jirutka> then make proper GUI in e.g. Gtk or something like that
21:33 <jirutka> for GUI people
21:33 <hl> kaniini: __maybe__
21:33 <kaniini> hmm
21:33 <kaniini> jirutka: you speak a lot of sense
21:33 <hl> kaniini: it pisses me off when programs executed from terminals (on a GUI desktop) launch dialogsd
21:34 <kaniini> jirutka: because it could just ask itself and then put all the values in aconf itself
21:34 <kaniini> i didn't think fo that
21:34 <skarnet> obviously on a livecd I'd use a GUI, but from a dev pov, the gui needs to be a layer above the installer
21:34 <kaniini> maybe all it really needs is a terminal prompt by default
21:34 <jirutka> but to be honest, I totally don’t care about Alpine desktop; I don’t believe that you can make one distribution to perfectly fit both lightweight server and desktop requirements; or maybe you can, but with really huge resources that we don’t have
21:35 <kaniini> okay
21:35 <hl> he's probably right.
21:35 <kaniini> so what we really need is
21:35 <kaniini> two things
21:35 <TemptorSent> Anyone remember the linux config system? make config; make menuconfig etc..
21:36 <jirutka> that said, I’d love to see Alpine on my desktop, totally, but I see it more as a sci-fi or wet dream
21:36 <kaniini> 1) infrastructure for handling the questions/answers
21:36 <kaniini> and
21:36 <kaniini> 2) infrastructure for importing a set of already answered questions
21:36 <skarnet> kaniini: aaaand you just reinvented Horizon
21:36 <kaniini> no i didn't
21:37 <skarnet> aiui that separation (which is imo the right design) was the point of Horizon
21:37 <kaniini> because (a) horizon hasn't shipped yet, and (b) horizon is strictly about installing things
21:37 <kaniini> what we want is a CFM system that is leveraged by the installer
21:37 <skarnet> ah
21:38 <skarnet> ok, I see what you mean
21:39 <kaniini> if a CFM is in the heart of the distribution, then it allows us to do other things optionally like what Nix does
21:39 <TemptorSent> FWIW, see https://github.com/msiemens/mlisp for an example of a lisp parser that's tiny (in src/parser.c)
21:39 <kaniini> Nix is another offender when it comes to badly implementing CFM
21:39 <kaniini> Nix is arguably worse than Debian, you are required to use their CFM, at least in debian you can turn off debconf
21:39 <hl> kaniini: what did nix do wrong?
21:39 <skarnet> Nix is unflexible, that's both an advantage and a drawback
21:39 <hl> hmm
21:40 <hl> yes, totalitarianism is a double edged sword
21:40 <kaniini> what i propose is a CFM platform that is initially used only by the installer, but later used by common packages if asked
21:40 <kaniini> the opt-in part is really a hard requirement
21:41 <kaniini> because alpine is about up-front configuration (i.e. you're in control, have to ask for it and everything we do you are advised is going to happen before you say yes or no), not necessarily CFM system controlling everything
21:41 <TemptorSent> kaniini: Do you see any reason a package couldn't provide a means of bidirectional interchange so you could alter configuration with it later for packages that understand how?
21:42 <kaniini> sure, that is just a matter of doing a reconfig
21:42 <hl> Ooooh. That's a tricky one.
21:42 <kaniini> every CFM already does this
21:42 <TemptorSent> kaniini: At least from a CM standpoint, it would be very useful to say update all installations to fix a security issue without them being necessarily under CM.
21:42 <hl> Well, there's augeas.
21:43 <TemptorSent> kaniini: So you could run CM against user-generated files when requested basically./
21:44 <kaniini> that seems really difficult to do
21:45 <TemptorSent> kaniini: So you could do things such as update logging targets, data directories, etc.
21:45 <kaniini> if you want that you should use a tool designed for that
21:45 <TemptorSent> kaniini: Yeah, I already kinda started doing that :)
21:45 <skarnet> being flexible enough to be opt-in and keep the standard location and format for every config fine under the sun sounds pretty hardcore
21:45 <skarnet> file*
21:46 <kaniini> the proposed CFM aspect in alpine is meant to be more for people who just want reasonable defaults
21:46 <kaniini> and don't want to deal with configuring stuff
21:46 <kaniini> i.e. the type of people who would be using ACF
21:46 <TemptorSent> Right now, it's very simplistic and parses a file, editing config directives if found, (commented or not), inserts them near a mention if not found in the first couple columns, or inserts at end of file.
21:46 <kaniini> and, assumedly, ACF would be able to make use of this infrastructure
21:47 <kaniini> but right now i just want to install the damn OS
21:47 <TemptorSent> skarnet: Yeah, that's why I was thinking s-expr files that could be handed back and forth, appended, whatnot, and just drop them at the bottom of config files when we edit them in a comment we can look at later.
21:48 <TemptorSent> skarnet: Not to evaluate, just to build the data structure quickly and cleanly.
21:48 <TemptorSent> skarnet: json without the pain perhaps? :)
21:49 <skarnet> kaniini: how about starting with an installer then (with cfm hooks in mind) and think about the cfm later?
21:49 <kaniini> cfm comes first
21:49 <TemptorSent> skarnet: Agreed -- the installation logic and configuration is the important part.
21:49 <kaniini> the whole point of redoing the installer
21:49 <kaniini> is to have the cfm
21:50 <TemptorSent> kaniini: Right, but you don't need the modify/update portion right away, just install
21:50 <kaniini> ??????????????
21:50 <kaniini> what modify/update portion
21:50 <kaniini> are you people illiterate
21:50 <TemptorSent> kaniini: You only have to worry about building a configuration database right now, not modifying it and chasing the deps.
21:51 <kaniini> i am describing a configuration database ONLY
21:51 <skarnet> hey, you're American and I'm not, you don't get to call me illiterate
21:51 <TemptorSent> kaniini: Right, not YET the tools to run CM against that database.
21:51 <kaniini> future use as a CFM for alpine, modifying and updating and all that stuff is not related to this, and would be handled by maintainer scripts
21:52 <kaniini> so ignore it
21:52 <kaniini> it has nothing to do with the present discussion
21:53 <kaniini> it is just a possible area of FUTURE APPLICATION for such a tool
21:53 <TemptorSent> kaniini: In other words, the issue is not with initial configuration (which is what you're currently working on and part of the mess I'm workign on) but with updates to existing configurations (which I'm starting to run up against)
21:53 <kaniini> what the fuck does that have to do with anything i am doing????
21:54 <TemptorSent> kaniini: just how your work would be applied to a full CM solution.
21:54 <kaniini> okay, and when we get to that point we discuss it then
21:54 <kaniini> right now it is about collecting information for an installer
21:55 <TemptorSent> Right, the question is about interfacing more.
21:55 <TemptorSent> kaniini: Such as using dialog -- if you're starting with a blank slate, easy enough, but if you're going to later be able to start with existing settings, more thought is required.
21:55 <kaniini> i am just saying lets not get into a huge feature creep discussion when right now it is about collecting information for an installer
21:55 <skarnet> key/value text file, a TUI, a GUI, done.
21:56 <kaniini> which is basically what i proposed skarnet
21:56 <skarnet> so what are we arguing about? XD
21:56 <TemptorSent> skarnet: The problem is a k-v store doesn't work well for the type of configuration info we need.
21:56 <kaniini> sure it does
21:56 <TemptorSent> skarnet: namely tree structures with both subtrees and options.
21:57 <kaniini> so you use the fucking filesystem
21:57 <kaniini> like i said
21:57 <kaniini> okay fuck this, i am not working on this anymore
21:57 <TemptorSent> kaniini: Yes, but shipping a filesystem around is impractical.
21:57 <kaniini> my interest in this has been completely demolished by the stupidity of this conversation
21:58 <skarnet> sounds to me like you were pretty angry for likely unrelated reasons before even starting it
21:58 <kaniini> no
21:58 <kaniini> i actually wasn't
21:58 <skarnet> and so far all I've done has been asking for clarifications and realizing I was agreeing with your design
21:58 <kaniini> it's not you :)
21:59 <TemptorSent> I've been on board with your design all along.
21:59 <kaniini> then why do you keep making it more complex
21:59 <jirutka> kaniini: I’m sorry for that, I’m too tired now and I have very bad experience with realization of the ideas that you’ve proposed that it terrified me
21:59 <TemptorSent> I'm just wondering how to handle shipping information around.
22:00 <kaniini> it is very simple
22:00 <kaniini> /etc/aconf/[tree here]
22:00 <kaniini> the tree is literally the bloody file system
22:00 <ashb> Oh
22:00 <ashb> segfault at 0 ip 00007ff397e17908 sp 00007ffe54e054f8 error 4 in ld-musl-x86_64.so.1[7ff397dc9000+88000]
22:00 <ashb> That's not promising
22:01 <TemptorSent> Okay, so for things like versioning and other CM tasks, would we just use git?
22:01 <kaniini> yes
22:01 <kaniini> the point isn't to provide full CM, it is to provide plumbing
22:01 <TemptorSent> okay!
22:01 <TemptorSent> kaniini: That's what I was trying to understand, what is the plumbing.
22:01 <kaniini> it is a common plumbing that all tools could use to leverage pre-existing infrastructure
22:02 <kaniini> thus simplifying things like
22:02 <kaniini> - the installer
22:02 <kaniini> - ansible
22:02 <kaniini> - ACF
22:02 <kaniini> - etc
22:02 <TemptorSent> So for CM, we can ask for the git diff between two different revs through the tool perhaps?
22:02 <kaniini> the idea is instead of having tons of jinja2 yaml whatever bullshit like ansible does to generate configs on alpine
22:03 <kaniini> it can use this infrastructure
22:03 <kaniini> and maintainer scripts to generate configuration
22:03 <TemptorSent> And have it check in all changes with a branch or somethign per namespace
22:03 <kaniini> but THAT IS WAY OFF IN THE FUTURE
22:03 <kaniini> SO I DO NOT WANT TO TALK ABOUT IT RIGHT NOW THANKS
22:03 <kaniini> if you want to continue talking about it, then you are going to just wind up killing it
22:03 <TemptorSent> Right, I'm just trying to understand how the CONFIGURATION and changes to it are handled.
22:03 <kaniini> and since i do not want to work on something that is dead on arrival
22:03 <kaniini> then i will just not work on it to begin with
22:04 <kaniini> by pontificating about future applications of this, you just create opportunity for people to misunderstand and create FUD
22:04 <TemptorSent> Basically, can I see what was set before and after I run a given config? If so, I'm happy :)
22:04 <kaniini> i don't want anything to do with it
22:04 <kaniini> sure if you use a tool like etckeeper
22:04 <kaniini> that is already a solved problem
22:04 <TemptorSent> But that doesn't tell me WHAT changed it.
22:05 <TemptorSent> That's what I'm getting at.
22:05 <jirutka> btw etckeeper is really badly implemented
22:05 <kaniini> okay
22:05 <kaniini> well
22:05 <kaniini> i'm done with this
22:05 <kaniini> somebody else can solve this problem
22:05 <TemptorSent> A git branch would be perfect imho.
22:05 <jirutka> oh, no, sorry
22:05 <jirutka> really sorry
22:05 <skarnet> please don't break kaniini
22:05 <kaniini> because people wont just shut the fuck up and let me work
22:05 <jirutka> I’m closing IRC now
22:05 <kaniini> not you
22:06 <TemptorSent> I'm gone.
22:06 <kaniini> it is TemptorSent who is pissing me off
22:06 <skarnet> you scared him away
22:06 <kaniini> like seriously, we are talking about a directory tree called /etc/aconf
22:07 <kaniini> it is not actual system configuration
22:07 <kaniini> if you really care who/what changed it, it is literally just like any other config file
22:07 <skarnet> tbh if you want to just work you better do it without irc... when I write real code I close it else I can't get anything done
22:08 <skarnet> if you come on irc you gotta expect discussion, including on subjects you don't want to handle right now
22:08 <kaniini> sure but when i explain 30 times that it's not relevant at this time
22:08 <kaniini> that is 29 times too many
22:08 <skarnet> just ignore and move on, follow your idea
22:08 <kaniini> and very frequently with TemptorSent that is the situation
22:09 <kaniini> and because of it
22:09 <kaniini> people ACTIVELY ignore #alpine-devel now
22:09 <kaniini> i had to disable push notifications to my phone because my phone started dinging every 5 seconds earlier with highlights
22:09 <skarnet> the reason it's getting ignored is traffic has exploded in the last few months
22:10 <skarnet> TemptorSent is partly to blame, but it's not only him
22:12 <kaniini> so i mean i dont even really want to work on this anymore, because it just means dealing with FUD created from questions that have nothing to do with what i am doing
22:14 BitL0G1c joined
22:16 <skarnet> you got what you wanted, he got out, so now, please talk about what you wanted to talk about
22:20 <kaniini> i did not want him to 'get out', i wanted him to chill out
22:20 <kaniini> but if that is his choice, that is his choice
22:22 <skarnet> either way you won't get interrupted now, so are you finally going to talk about tech stuff or are you going to primadonna until we beg?
22:22 <kaniini> i already said what i said way above
22:22 <kaniini> i dont feel like repeating it
22:22 <kaniini> i will just make a prototype
22:23 <skarnet> tbh you could then have started with that and avoided drama
22:24 <kaniini> well, initially i wanted input on it
22:24 <kaniini> but after having it turn into some discussion about something i did not have in mind, and ultimately about a system like etckeeper
22:24 <kaniini> frankly at this point i do not even wish to work on this problem anymore
22:25 <kaniini> like the whole experience has demolished any interest in working on this
22:25 <skarnet> ok, then I want my hour back
22:25 <kaniini> i mean, basically if you want to know the details
22:25 <skarnet> I have no time to be baited into seemingly interesting tech stuff and have primadonnas bail out on me
22:25 <kaniini> something like /var/lib/aconf/[tree of template files]
22:26 <kaniini> and /etc/aconf/[tree of answer files]
22:26 <kaniini> so you might have
22:26 <kaniini> /var/lib/aconf/setup/target-disk
22:26 <kaniini> which contains
22:26 <kaniini> Default: sda
22:26 <kaniini> Description: Target disk to use for installing Alpine
22:26 <kaniini> and then in /etc/aconf/setup/target-disk
22:26 <kaniini> you would have
22:26 <kaniini> sda
22:27 <kaniini> so then in a script you would have
22:27 <kaniini> target_disk=$(aconf get-val setup/target-disk)
22:27 <kaniini> which would either prompt or use the default or use an already known setting
22:28 <kaniini> this somehow turned into a discussion about managing /etc with git or updating config files outside of /etc/aconf or whatever
22:28 <kaniini> and historically, such discussion is really used to bury things
22:28 <kaniini> so there you go, that is what i had in mind
22:28 <kaniini> what do you think about it
22:31 <skarnet> you still have kv pairs in /var/lib/aconf/setup/target-disk
22:31 <skarnet> why not have /var/lib/aconf/setup/target-disk/default contain sda
22:31 <kaniini> yes
22:31 <skarnet> if you really want to use the fs as a full kv store :P
22:31 <kaniini> that is also a possibility
22:32 <skarnet> you know I'm all for using the fs as a kv store
22:32 <kaniini> and that works nicely if we want to make the questions translatable
22:32 <skarnet> always
22:32 <kaniini> because you could have
22:32 <kaniini> /var/lib/aconf/setup/target-disk/description.fr
22:32 <skarnet> indeed
22:32 <kaniini> be whatever is french for "Target disk to use for installing Alpine"
22:32 <kaniini> now
22:32 <skarnet> if you want to expand the kv pairs in the fs, do it all the way
22:32 <kaniini> do you understand my frustration about how this became a discussion about rewriting config files
22:33 <kaniini> and managing /etc with git
22:33 <kaniini> it is insane
22:33 <kaniini> but what pissed me off is how he tried to triangulate what i was saying into that
22:33 <kaniini> that's the problem i had
22:33 <skarnet> yes
22:34 <kaniini> if he wants to run away because he is told that i do not want to work on this anymore because he did that, it is his decision
22:34 <skarnet> but you let him drive the convo
22:34 <skarnet> you should have followed your idea
22:34 <kaniini> i see it differently: he was drowning out the conversation
22:35 <kaniini> jirutka and i had pretty much come to a reasonable conclusion on how to handle it
22:35 <kaniini> and then he came in and completely demolished the progress i had made on coming up with a reasonable spec to implement
22:35 <kaniini> that's the damn problem
22:36 <skarnet> that's an awful lot of power you're giving him
22:36 <kaniini> well i could have set +q on him but that just makes him run away still
22:37 <kaniini> and then embedding lisp or whatever like
22:37 <kaniini> what the fuck do we need lisp for
22:38 <kaniini> he has good ideas, but he needs to chill the fuck out
22:38 <skarnet> yup
22:39 <skarnet> and you need to be able to pace a discussion without getting scary :P
22:39 <kaniini> not really, i can do that fine
22:39 <kaniini> and if "i am not working on this anymore because you keep turning it into something it isn't" scares him, then too bad
22:40 <skarnet> that one is not about him
22:40 <skarnet> it's about the project
22:40 <skarnet> if one guy is able to take away your motivation just by making irrelevant comments on irc
22:40 <kaniini> it's about me haivng to deal with things i don't want to deal with, because other people jump on his train
22:40 <skarnet> you're giving him a hell of a lot of power and I question your motivation on the first place
22:41 <skarnet> in*
22:41 <skarnet> I didn't want to jump on his train, I wanted *clarity*
22:41 <skarnet> thanks for eventually making things clear
22:42 <kaniini> yes, you wanted clarity. next time i will just discuss with you in PM instead of participating in said wankery
22:42 TemptorSent joined
22:43 <kaniini> but the problem is
22:43 <kaniini> if you don't shut down that type of wankery, people will assume the wankery is what you are doing
22:43 <kaniini> and work to resist your perceived wankery
22:43 <kaniini> as if it were systemd
22:44 <kaniini> they are not fighting what you actually produce, they are fighting what is perceived, which means the thing you produced is dead on arrival
22:45 <kaniini> because /somebody else/ now convinced that your product is the latest evil thing after systemd will work very hard to ensure your product has no future
22:45 <TemptorSent> Sorry kaniini, I didn't mean to push any buttons.
22:46 <kaniini> it's not pushing buttons, it's about making sure the scope of the project is understood
22:46 <kaniini> if the project is understood wrongly, then people will work to ensure it is dead on arrival
22:46 <TemptorSent> kaniini: Yeah, that's what I was trying to understand. What parts fit together how in the big picture.
22:46 <kaniini> when it is really something completely different than what is perceived about
22:47 <skarnet> I don't think anybody is going to read the backlog and get any false ideas about your project anyway. :P
22:47 <kaniini> but you already knew, because you explained it perfectly at first :/
22:47 <kaniini> it is plumbing for other tools to get configuration data
22:47 <TemptorSent> And I finally fixed my bloody kernel/module mismatch *AND* upgraded my RAM because I was starting to get weird artifacts showing up, like files with 8-bit names.
22:48 <TemptorSent> kaniini: The part I was trying to understand is how those other tools use your tool in context.
22:48 <kaniini> from my perception, it appeared like you were trying to change the focus of the proposed project to be some systemd-like monster that takes over /etc
22:49 <TemptorSent> Certainly not!
22:49 <kaniini> it takes only one idiot seeing such a thing to start writing crank emails to alpine-devel
22:49 <kaniini> and creating trouble
22:49 <TemptorSent> If systemd ever comes near alpine, I'm bringing the flamethrower!
22:49 <kaniini> and if systemd is legitimately the best solution for our needs?
22:50 <skarnet> I very much doubt it will be
22:50 <kaniini> i'm not saying it is, i am just asking a hypothetical
22:50 <TemptorSent> Then alpine probably isn't the best for mine.
22:50 <kaniini> fair enough, but you have to be more open minded than that
22:50 <skarnet> and if my aunt had balls
22:50 <skarnet> not saying she does, it's a hypothetical
22:51 <kaniini> then she'd still be your aunt
22:51 <skarnet> right answer :)
22:51 <kaniini> and probably also on a porn dvd somewhere
22:51 <TemptorSent> kaniini: If alpine went that direction, I'd be back at funtoo and adding some binary packing help from adeile
22:51 <kaniini> why not adelie?
22:52 <kaniini> i mean i do not want to run you away, but it does seem like a better fit in some ways
22:52 <awilfox> TemptorSent: irl, you don't have to worry, because it won't build against musl and surprise as lennart, kay, and friends do not want patches to make it work
22:52 <kaniini> its ok
22:52 <TemptorSent> kaniini: I'd probably merge funtoo features into that if I went that way.
22:52 <kaniini> we are switching
22:52 <kaniini> in approximately 68 minutes
22:52 <kaniini> i wonder how much shit i would get
22:52 <kaniini> if i added a fake systemd package
22:53 <kaniini> and had it depend on alpine-base
22:53 <TemptorSent> kaniini: How deep is your bomb shelter?
22:53 <TemptorSent> :)
22:53 <kaniini> so then people do
22:53 <kaniini> apk upgrade
22:53 <kaniini> and they get
22:53 <kaniini> Installing systemd
22:53 <TemptorSent> And that *WOULD* be awesome.
22:53 <kaniini> hahahahahahaha
22:53 <kaniini> that would be the best april fools troll ever
22:53 <TemptorSent> Couldn't pick better timing.
22:54 <awilfox> TemptorSent: hopefully deep enough for me to hide in as well, since I can see his apartment from my window.
22:54 <awilfox> but hey
22:54 <awilfox> I can do
22:54 <awilfox> facebook live stream
22:54 <awilfox> of bombing
22:54 <TemptorSent> awilfox: *LOL* Beter get moving, this just might happen!
22:54 <skarnet> I'll provide the nuke
22:54 <kaniini> god
22:54 <kaniini> can you imagine all the people coming into #alpine-linux
22:55 <kaniini> screaming WTF
22:55 <TemptorSent> kaniini: give it a three-mile-long dep list of fake systemd-* packages...
22:55 <kaniini> do you happen to have a list
22:56 <TemptorSent> ...with the last one being systemd-march31st-april2nd-fix
22:56 <kaniini> well
22:56 <kaniini> i do not really wish to die
22:56 <TemptorSent> Hmm, not off hand -- I don't let it close enough :)
22:56 <kaniini> so i think i will not do this
22:56 <kaniini> although it would be funny
22:56 <kaniini> jirutka would probably have a stroke
22:57 <TemptorSent> It would be one for the books!
22:57 <kaniini> i do not think the systemd guys would believe it though
22:57 <TemptorSent> kaniini: Maybe you need an obituary to go with it...
22:58 <kaniini> anyway
22:58 <TemptorSent> "well, he said over his dead body..."
22:59 <kaniini> the immediate idea (thanks to jirutka and skarnet for input) is basically a tree of files
22:59 <awilfox> kaniini: https://bpaste.net/raw/3035baa23211
22:59 <kaniini> /var/lib/aconf/setup/target-disk/description
22:59 <kaniini> and so on
23:00 <TemptorSent> Sounds good.
23:00 <TemptorSent> That allows translations and so forth easily it seems.
23:00 <kaniini> and then /etc/aconf/setup/target-disk
23:00 <kaniini> contains the answer
23:00 <skarnet> awilfox: that's a pretty impressive list
23:00 <kaniini> as files
23:00 <TemptorSent> awilfox: Nice!
23:01 <kaniini> so you could have
23:01 <TemptorSent> kaniini: All sounds good.
23:01 <kaniini> /etc/aconf/setup/target-disk/sda/filesystem
23:01 <kaniini> which contains 'zfs'
23:01 <kaniini> or whatever
23:01 <TemptorSent> kaniini: can a file contain multiple values for the answer in that case?
23:01 <kaniini> sure, just put whitespace between each answer
23:02 <kaniini> keep in mind shell scripts are the main consumer of this
23:02 <TemptorSent> Newlines work?
23:02 <kaniini> sure
23:02 <TemptorSent> Yeah, that's exactly what I'm thinking.
23:02 <TemptorSent> setting IFS to \n makes spaces safe to consume.
23:03 <kaniini> the only remaining question i have is
23:03 <skarnet> just don't split what you read from those files.
23:03 <kaniini> how do you read portably
23:03 <kaniini> from alternative fd's
23:03 <kaniini> in a shell script
23:03 <TemptorSent> And you could use symbolic links in a sane manner where you have multiple questions that should get the same answer.
23:03 <kaniini> cause ive never done it
23:03 <skarnet> 3</blah/file
23:03 <skarnet> -> reads file on fd 3
23:03 <kaniini> yeah but how do you get that into a variable
23:04 <TemptorSent> kaniini, newline seperated works well in most cases.
23:04 <kaniini> is what i mean
23:04 <kaniini> so that 0,1,2 can be used for tty
23:04 <skarnet> ah, you can't
23:04 <kaniini> so we can use readline
23:04 <skarnet> (PSA: in execline, you can)
23:04 <kaniini> we have to be able to somehow
23:04 <kaniini> because
23:04 <TemptorSent> I use heredocs
23:04 <kaniini> debian does it
23:05 <TemptorSent> or just do exec 3>file
23:05 <TemptorSent> where file can be a fifo if you need it.
23:05 <kaniini> i mean in reality
23:05 <kaniini> i guess it doesnt matter
23:05 <kaniini> as any more fancy installer frontend can just collect the details itself
23:06 <kaniini> and write the necessary config
23:06 <TemptorSent> If you need newline safe and shell parseable, you can use a token.
23:06 <TemptorSent> kaniini: But setting IFS=
23:06 <skarnet> again
23:06 <TemptorSent> and doing while read -r
23:06 <skarnet> do not split
23:06 <skarnet> ever
23:07 <TemptorSent> I think that's what I jsut said?
23:07 <skarnet> no
23:07 <TemptorSent> Read raw and split it yourself?
23:07 <skarnet> that's exactly what I said not to: split
23:07 <skarnet> if you need to split, it means you have several kv pairs in the same file
23:07 <TemptorSent> skarnet: How do parse it apart then?
23:07 <skarnet> don't
23:08 <TemptorSent> Yes, that's exactly the idea.
23:08 <skarnet> instead, have ONE value in every file
23:08 <kaniini> skarnet: what if you have a list of packages that you want installed
23:08 <TemptorSent> skarnet: You're saying only one key per file?
23:08 <skarnet> one filename = one key, contents = the value
23:09 <skarnet> if you can't do that, settle on something that cannot have \n
23:09 <skarnet> for a list of packages in a file, package names can't contain \n
23:09 <skarnet> so it's ok to have one per line
23:10 <awilfox> skarnet: you can't do VAR=`cat <3` or something? don't child processes inherit fds in some cases?
23:11 <TemptorSent> Right, the issue is going to be when you need fragments.
23:11 <awilfox> I mean I typically avoid shell at all costs but I thought this was possible in posix sh
23:11 <TemptorSent> var="$(cat <<EOF
23:12 <TemptorSent> cat <3
23:12 <TemptorSent> EOF
23:12 <TemptorSent> )"
23:12 <TemptorSent> But that's fugly.
23:13 <skarnet> awilfox: it should be possible to hack something like that but shell is ugly and I'm tired.
23:13 <TemptorSent> I'm not sure you can do it on one line posixly without making a helper fucntion to do a lot of quoting.
23:14 <TemptorSent> Really, set -- is the only sane way to handle messy data
23:14 <TemptorSent> See www.etalabs.net/sh_tricks.html for some solutions.
23:15 <awilfox> skarnet: lol, +1
23:15 <TemptorSent> There's a 'save' function about halfway down that will do the quoting so you could cat directly into it.
23:16 <skarnet> TemptorSent: it's not about parsing, it's about fd mangling, and the shell's backtick and pipeline primitives are limited so you need to work around the limitations.
23:16 <TemptorSent> skarnet: Yeah, that's why the heredoc trick.
23:16 <kaniini> TemptorSent: anyway you would version the aconf database the same way you would version anything else in /etc
23:17 <TemptorSent> kaniini: Understood - What I was looking for was a means of tracking what packages changed which configuration options without having to write it out explicitly.
23:18 <kaniini> packages would not automatically change anything in the configuration database
23:18 <TemptorSent> kaniini: For CM, that is almost necessary.
23:18 <kaniini> i mean -- they would -- with upgrade maintainer scripts and so on
23:18 <TemptorSent> kaniini: Right, not automatic changes - I mean which options get set for a given package, so that can be replicated.
23:18 <awilfox> looks to me it'd be /etc/aconf/$package
23:19 <awilfox> so you just copy that tree
23:19 <kaniini> seems like that would be a matter of searching the templates to find what is valid
23:19 <TemptorSent> kaniini: So I can take a configuration of a given service and apply it elsewhere, even if I don't have all the same packages installed and configured.
23:19 <kaniini> oh
23:19 <TemptorSent> kaniini: Even a simple diff with a before/after of the tree for a given package would do it.
23:19 <kaniini> that is a little harder
23:20 <kaniini> you just copy the /etc/aconf tree for that package in that case
23:20 <kaniini> but
23:20 <TemptorSent> kaniini: That's all I was trying to get at.
23:20 <kaniini> you would need to know what packages to install, too
23:20 <kaniini> so you would also want to copy /etc/apk/world
23:20 <TemptorSent> Right.
23:20 <kaniini> then you can apply all that configuration with `apk fix`
23:20 <kaniini> wtf matrix has syntax highlighting for apk commands
23:20 <kaniini> fucking weirdos
23:21 <kaniini> TemptorSent: but for now, lets concentrate on proof of concept before we get that far
23:21 <TemptorSent> Basically, just configuring something on my home box (which probably has a lot of different packages) then applying it to a remote machine.
23:22 <TemptorSent> kaniini: Of course, I was just looking at a use and wondering how to do it given the framework you're building.
23:22 <kaniini> basically, as a CM platform, the idea is that packages would have a configure script
23:22 <TemptorSent> kaniini: So running git against the directory and maybe linking world in so I can get a good snapshot would be a viable way to do it.
23:23 <kaniini> which would read from aconf and build a configuration file using whatever method the maintainer wishes
23:23 <kaniini> then the package manager has a new option --configure
23:23 <kaniini> which will invoke the configure scripts
23:23 <TemptorSent> Not necessarily the general way, but a means of versioning that would give me very fine-grained info when I need it personally.
23:23 <kaniini> and track in /etc/apk/world which ones it should continue running configure scripts for
23:23 <kaniini> use etckeeper for that :)
23:23 <kaniini> it has apk integration
23:24 <TemptorSent> kaniini: Yeah, but not so much versioning logs.
23:24 <kaniini> anyway
23:24 <kaniini> i will accept patches for whatever crazy shit you need
23:24 <TemptorSent> anyway, what you suggest looks like it will work without any hassle.
23:24 <kaniini> so figure out what it is you want to do and send me a patch :p
23:25 <TemptorSent> I can package it up using cpio/tar/whatever, move it around, manipulated it, dump it in git, and still have it make sense.
23:25 <TemptorSent> I'm happy :)
23:25 <TemptorSent> If you can toss a few comments in the files about the context of the written information, that'd be cool
23:26 <TemptorSent> Checksums or something for bonus points :)
23:26 <kaniini> since it's files
23:26 <kaniini> you should be able to do whatever you want
23:26 <TemptorSent> Yup, that's what I was hoping for.
23:27 <kaniini> hmm, that's an idea
23:27 <kaniini> what if a preseed file
23:27 <kaniini> was just a tarball
23:27 <TemptorSent> That's what I was talking about.
23:27 <kaniini> and it reads the tarball
23:27 <kaniini> and merges it into the current config db
23:27 <kaniini> actually that would be REALLY COOL LOL
23:28 <TemptorSent> Yup.
23:28 <kaniini> and the merger could validate
23:28 <kaniini> based on what is in the templates
23:28 <TemptorSent> That's what I meant by fragments -- you can take the config for one feature and apply it as a tarball.
23:28 <TemptorSent> So you just ship that with the packages.
23:28 <kaniini> you mean the package list?
23:29 <TemptorSent> That's what I have layed out for the new initfs.
23:29 <TemptorSent> You could include it in the .apk control.tar.gz itself, then you just copy it in on install and call with your --configure
23:30 <kaniini> yuck
23:30 <TemptorSent> The tree is just a set of tarballs.
23:30 <kaniini> i don't like that one :p
23:30 <TemptorSent> Why?
23:30 <kaniini> i want the aconf system itself to be distribution independent
23:30 <TemptorSent> I would be.
23:31 <TemptorSent> You could call it from whatever tool you want.
23:31 <TemptorSent> In which ever distro you want.
23:31 <kaniini> if including preseed files is inside apk headers
23:31 <kaniini> that is not independent
23:31 <kaniini> :p
23:31 <awilfox> didn't think it was actually called control.tar.gz in apks
23:31 <awilfox> that is a .deb thing
23:31 <kaniini> it's not
23:31 <kaniini> it's just an opaque blob
23:32 <TemptorSent> kaniini: Well, for distributing the apks it would go with the rest I would think?
23:32 <kaniini> TemptorSent: we're not distributing configuration settings in alpine that way
23:32 <TemptorSent> Or just have a well known directory that they install to in the FS and version the tarballs so they don't collide.
23:32 <kaniini> that's what the templates are for
23:32 <kaniini> so i dont understand your usecase
23:32 <TemptorSent> kaniini: So the templates aren't distributed with the apks?
23:32 <kaniini> the templates live elsewhere than /etc/aconf
23:33 <kaniini> they live in /var/lib/aconf or such
23:33 <kaniini> i havent decided where to put them
23:33 <TemptorSent> Right, but they wouldn't look any different than the tarballs you'd make off the configured /etc/aconf, would they?
23:33 <kaniini> no, but they can just be in the APK themselves
23:33 <kaniini> as files
23:34 <TemptorSent> In other words, you could make a template by configuring it on your system, then creating the tarball diff?
23:34 <TemptorSent> From an unconfigured or partially configured state.
23:34 <kaniini> sure, but i don't like that
23:34 <kaniini> i would prefer something like
23:34 <kaniini> aconf-merge < your-tarball-here.tar
23:35 <TemptorSent> Right, I mean to create the templates in the first place.
23:35 <kaniini> sure
23:35 <kaniini> i just dont want it to be inside the APKs
23:35 <TemptorSent> So you configure your system to reasonable defaults and bake that.
23:35 <TemptorSent> kaniini: So what provides defaults in the apks?
23:36 <kaniini> the package maintainer does
23:36 <TemptorSent> kaniini: Can the package maintainer just include a tarball with the defaults?
23:36 <kaniini> yes, they would do so to /var/lib/aconf
23:36 <TemptorSent> That way various archs can have different defaults as needd.
23:37 <kaniini> yes, they would do so to /var/lib/aconf
23:37 <TemptorSent> Okay, so how do they create that default is what I'm asking?
23:37 <kaniini> they just do
23:37 <kaniini> i dont understand your question
23:37 <TemptorSent> Can they build it by just running the configuration tool?
23:37 <kaniini> how do you create any other default
23:37 <kaniini> you just make it up
23:37 blueness joined
23:37 <kaniini> what i am figuring is
23:37 <kaniini> there will be a file
23:37 <kaniini> foo/bar baz
23:38 <kaniini> foo/bar1 baz2
23:38 <kaniini> [...]
23:38 <TemptorSent> I mean do they have to manually create it, or can they run your tool, enter the defautl values, and package the result
23:38 <kaniini> and then you run a tool
23:38 <kaniini> to install those settings
23:38 <kaniini> either into the template database
23:38 <kaniini> or the real database
23:38 <TemptorSent> So why wouldn't that just be a tar file?
23:38 <kaniini> (because the templates themselves are just another instance of the config database, in this case a config database about the config database itself)
23:39 <kaniini> because we would like to edit it in human-readable format
23:39 <kaniini> i wasn't aware a tarball was editable in git
23:39 <kaniini> er, in a text editor
23:39 <TemptorSent> kaniini: I mean the actual installation of such config files being stored as a tarfile.
23:40 <kaniini> because that seems kinda pointless
23:40 <TemptorSent> So you can have the entire fs hierarchy and apply new parts from a single file.
23:40 <kaniini> https://memegenerator.net/instance/76383210/yo-dawg-yo-dawg-i-put-a-tar-in-your-tar-so-you-can-tar-while-you-tar tbh
23:41 <kaniini> TemptorSent: packages should never be touching /etc/aconf is my point
23:41 <TemptorSent> So the package maintainer can include a .settings-defaults.tar (or .pax :P) that gets installed to /var/lib/aconf
23:42 <kaniini> TemptorSent: why not just ship them as files in /var/lib/aconf
23:42 <kaniini> TemptorSent: keep it simple
23:42 <TemptorSent> Right, they wouldn't, but the packger could create the tarfile that will be installed in /var/lib containing defaults based on extracting a tarball of the settings in his /etc/
23:43 <kaniini> sure, but instead we would just have a dumptree tool to create a human editable file for that
23:43 <TemptorSent> kaniini: A tarball can get passed around easily, while a fs hierarchy tends to get mangled.
23:43 <kaniini> i'm getting irritated again
23:43 <TemptorSent> just dump it to another directory?
23:43 <TemptorSent> Sorry, not trying to.
23:43 <kaniini> aconf-dumptree package/* > package-conf.txt
23:44 <kaniini> git add package-conf.txt
23:44 <kaniini> package() { aconf-preseed --from-plaintext package-conf.txt --out "$pkgdir"/var/lib/aconf }
23:44 <TemptorSent> kaniini: Okay, but then you end up having to collapse the fs to a file again and have the same issue regarding splitting.
23:44 <TemptorSent> That's what I was trying to avoid.
23:45 <kaniini> i want the config database to be human readable
23:45 <kaniini> the tools around it are conveniences
23:45 <kaniini> as jirutka puts it, it shouldn't be the windows registry
23:45 <TemptorSent> kaniini: the config database would just be the fs.
23:45 <kaniini> yes, i think the defaults should be too
23:45 <kaniini> skarnet can you back me up here
23:46 <TemptorSent> the tar/cpio files would just be how you copy those files around in a portable manner.
23:46 <kaniini> i'll keep your idea under advisement
23:46 <TemptorSent> Rather than trying to make a flat-file out of a directory struture.
23:46 <skarnet> as usual, I'm kinda trying, and failing, to get something else with my life before going to sleep. And I'm sick today.
23:47 <skarnet> something else done*
23:47 <TemptorSent> skarnet: Sorry to hear that.
23:47 <skarnet> but yes, if you're looking for a kv db, the fs is exactly the structure you need
23:47 <skarnet> the POINT of the fs is to be a kv db
23:47 <kaniini> yes, but not tarballs added to APKBUILDs in git
23:47 <kaniini> that is the type of insanity that will kill this thing dead
23:48 <skarnet> a tarball, by definition, is neither a key nor a value
23:48 <TemptorSent> skarnet: My suggestion was that moving that k-v store around using tools made for archiving the fs seemed logical.
23:48 <kaniini> it is logical, but not for maintainers
23:48 <kaniini> need something more usable for that
23:48 <skarnet> TemptorSent: you mean like cp -a and mv? :P
23:49 <TemptorSent> skarnet: cp -a to a remote host is not my favorite trick.
23:49 <kaniini> yes, for all of that, use tarballs
23:49 <skarnet> obviously ^
23:49 <kaniini> my objection begins when you say "dump a tarball inside the package"
23:49 <kaniini> that's insane
23:50 <TemptorSent> kaniini: How so? Should we instead tar them up after extracting if we need to send them across the wire?
23:50 <kaniini> you're doing it again
23:50 <kaniini> TemptorSent: what is a package
23:51 <kaniini> TemptorSent: an apk file, what is it?
23:51 <skarnet> what is love
23:51 <TemptorSent> kaniini: it's a pair of tarballs currently, appended together.
23:51 <kaniini> and what is a tarball?
23:52 <TemptorSent> so you have a nice archive with everything that gets installed.
23:52 <kaniini> what is a tarball?
23:52 <skarnet> baby don't hurt me
23:52 <kaniini> (i am making a point here, entertain me for one second)
23:53 <skarnet> don't hurt me
23:53 <skarnet> no more
23:53 <skarnet> (are you entertained?)
23:53 <TemptorSent> A tarball is a collection of files with headers for metadata -- the metadata is the important part IMHO.
23:53 <kaniini> so you would say a tarball is a container
23:53 <TemptorSent> Yes, certainly.
23:53 <kaniini> so then, why would we want to place another container of files inside a perfectly good container of files?
23:54 <kaniini> when it's all going to the same place anyway
23:54 <TemptorSent> Becaue you very likely will want to operate on one of those containers of files as a unit.
23:54 <kaniini> who?
23:54 <TemptorSent> Upgrades, for instance.
23:54 <kaniini> and?
23:54 <TemptorSent> Do you really want to just overwrite those files, or do you want to merge them?
23:55 <kaniini> they're templates. they're meant to be overwritten.
23:55 <kaniini> that's the point of them
23:55 <kaniini> (and your tarball would be overwritten too)
23:55 <TemptorSent> kaniini: The point was you could untar them to two directorys and run a diff.
23:55 <TemptorSent> And know which came from which version
23:55 <awilfox> TemptorSent: the package doesn't have any files in /etc/aconf. the package puts its configuration options (and defaults) in a separate path on the FS
23:56 <awilfox> TemptorSent: so /etc never changes due to apk actions (except apk configure)
23:56 <kaniini> TemptorSent: you can do that by diffing the APKs themselves
23:56 <awilfox> at least that is how I understand this system
23:56 <kaniini> TemptorSent: see also previous point about APK just being a container of files
23:56 <TemptorSent> kaniini: The apk is just a LOT bigger than the config.
23:56 <kaniini> TemptorSent: you have to unpack the APKs anyway
23:56 <TemptorSent> kaniini: Fully understood.
23:57 <TemptorSent> kaniini: But you often don't store previous version of them
23:57 <kaniini> TemptorSent: so then why waste time unpacking another tarball when you can just diff the old APK to the new one.
23:57 <TemptorSent> How do upgrades work when defaults change?
23:57 <kaniini> TemptorSent: alternatively, you could write a tool that installs a trigger on /var/lib/aconf and does this backup for you
23:57 <TemptorSent> kaniini: many megabytes vs a few k?
23:58 <kaniini> how upgrades work when defaults change is that it uses the new default
23:58 <kaniini> this should be pretty obvious
23:58 <awilfox> TemptorSent: probably a "HEY! NOOB! HEADS UP!" message printed during post-install?
23:58 <TemptorSent> kaniini: In my experience, what should be obvious in CM often turns into a mess.
23:58 <kaniini> unless you have explicitly answered configuration questions, in which case your version in /etc/aconf is the one that is used (and if there is a problem you are asked what to do)
23:59 <TemptorSent> awilfox: Yeah, that's be nice.
23:59 <kaniini> the /var/lib/aconf is only consulted for the default once
23:59 <TemptorSent> kaniini: Yeah, the real problem comes when some default name has changed, like what was MAX_LOG_SIZE to LOG_SIZE_MAX, and now you fill up a FS.