<    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:06 <skarnet> you can hardly ever umount /proc
00:07 <skarnet> what else are you mounting, and what processes are you running at the time of the unmounting you want?
00:14 <TemptorSent> skarnet: Trying to make the iso boot!
00:15 <skarnet> I'm not asking you for a functional spec, but for an operational one :)
00:16 <skarnet> (iow, the low-level details)
00:16 <TemptorSent> Testing unde qemu and getting to the point of unpacking the inital root fs, then puking trying to unmount proc before getting ready to pivot root.
00:17 <skarnet> yes. That's why I'm asking what exactly is running when you're trying to unmount.
00:17 <TemptorSent> It appears somethign in the init script isn't getting along with the tools.
00:18 <TemptorSent> take a look at /usr/share/mkinitfs/initramfs-init line 610
00:18 <skarnet> online link?
00:18 <TemptorSent> That is where it's bombing out.
00:19 <TemptorSent> um, any alpine box or the git repo for mkinitfs I guess. I don't have a browser on this box.
00:20 <skarnet> you want me to help you, you gotta help me help you. Sorry, can't boot an Alpine box atm.
00:20 <TemptorSent> *lol* Okay, let me find a link and type it :)
00:21 <skarnet> I see http://git.alpinelinux.org/cgit/mkinitfs/ but are your contributions pushed?
00:21 <TemptorSent> skarnet: That's just it, I'm using the stock one!
00:22 <TemptorSent> I suspect recent kernel changes or busybox change may have an impact? Odd, to put it mildly.
00:22 <skarnet> holy fucking shell script batman
00:23 <skarnet> I can't believe we need ALL of this in an initramfs
00:24 <awilfox> skarnet: http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/
00:24 <TemptorSent> skarnet : Yeah, that's why I'm trying to modularize things a bit :)
00:24 <awilfox> especially http://git.kernel.org/cgit/boot/dracut/dracut.git/tree/modules.d
00:25 <TemptorSent> skarnet: Include the portions we need, not the rest.
00:25 <awilfox> though, dracut /is/ modular and only includes what you specify
00:25 <skarnet> awilfox: "the rest of the world sucks even more" has never comforted me
00:26 <skarnet> if I was comforted because other people suck more, I'd feel like a god all the time
00:26 <awilfox> bahaha
00:26 <TemptorSent> Do we actually need to bind-mount proc for that little operation, or can we just throw in a couple symlinks then kill them after?
00:27 <skarnet> you'd have to ask fabled, at a more EU-friendly time
00:27 <skarnet> my job is to write initramfs scripts that are 20 lines long
00:27 <skarnet> tios
00:27 <skarnet> tops*
00:27 <skarnet> not to analyze giant moussakas
00:28 <awilfox> hmph, ours is 329 lines :( https://code.foxkit.us/adelie/image/blob/master/cdinit.c
00:28 <skarnet> apparently that's the job *you*'ve decided to take, and in the wise words of Mr. T: I pity the fool
00:28 <TemptorSent> *Grin* Yeah, this is a bit painful..
00:29 <TemptorSent> I'm ALMOST tempted to just rewrite it, but I'm already a week late on a project for a client with this.
00:29 <skarnet> awilfox: ah, because initramfs scripts aren't hard enough to debug, so you want initramfs *binaries* instead :P
00:30 <awilfox> skarnet: not needing to pull in an entire busybox or bash or zsh or ash made it much smaller
00:30 <TemptorSent> skarnet: Actually, that might be less painful at this point ;)
00:30 <awilfox> I'm talking 2-7 MiB smaller, depending on which one of those I picked
00:30 <skarnet> awilfox: what the hell do you think execline is for
00:30 <awilfox> hm
00:31 <awilfox> didn't think to try execline. never have written a script in it before
00:32 <jirutka> skarnet: please, you can’t be serious with execline…
00:32 <skarnet> you need to say "surely you can't be serious"
00:33 <skarnet> so I can answer "I am serious, and don't call me Shirley"
00:33 <awilfox> what about Laverne?
00:33 <skarnet> Laverne?
00:35 <skarnet> jirutka: to clarify: I'm not suggesting using it for Alpine - you'd need to napalm the current initramfs first and spread ammonia on the ashes - but to replace Adélie's C program it's perfectly well-suited
00:35 <TemptorSent> awilfox : I guess we're the geezers in the room *lol*
00:35 <jirutka> wat? In file included from /usr/include/tclap/CmdLine.h:27:
00:35 <jirutka> #include <string>
00:36 <jirutka> In file included from /usr/include/tclap/CmdLine.h:27:
00:36 <jirutka> . /usr/include/tclap/SwitchArg.h:27:10: fatal error: 'string' file not found
00:36 <jirutka> #include <string>
00:36 <jirutka> clang complains, g++ does not
00:36 <skarnet> TemptorSent: or just the Americans. Foreigners don't know all the American sitcoms that come out. :P
00:37 <skarnet> string.h ?
00:37 <skarnet> maybe g++ automatically completes the extension while clang doesn't.
00:38 <awilfox> jirutka: clang++
00:39 <skarnet> awilfox: https://youtu.be/ixljWVyPby0?t=66
00:39 <awilfox> skarnet: <string> like that usually means C++ std::string, which is in header <string>
00:39 <jirutka> oh crap: error: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'?
00:39 <skarnet> ah, C++
00:39 <awilfox> skarnet: lol, yes, I've seen Airplane! :P
00:40 <TemptorSent> skarnet: Yeah, "Laverne & Shirley" was somewhat less widespread than some of the other shows of the time I guess.
00:53 <TemptorSent> Bingo! Looks like a change in busybox that doesn't like umount having multiple arguments!
00:54 <TemptorSent> Damn, nope... something still strange.
00:55 mikeee_ joined
01:00 <kaniini> a non-trivial chunk of the alpine initramfs is for boot from ram setup
01:07 <TemptorSent> kaniini: Which is exactly what I'm trying to use...
01:08 <TemptorSent> kaniini: The frustrating part is the rather less than clear codepaths and options, with random behaviours and NO debugging output.
01:09 <jirutka> awilfox: but why it can’t find it? I have installed clang, clang-libs, libstd++…
01:12 <TemptorSent> kaniini: Do you have any thoughts as to why I'm getting kicked to a rescue shell when trying to boot an iso that uses that standard initramfs?
01:13 <kaniini> :D
01:13 <kaniini> TemptorSent: i have no idea sorry
01:17 <TemptorSent> kaniini: Thanks :)
01:20 <TemptorSent> Okay, got it to boot after modifying the init script to use 'umount -l -r -f $mntpt 2> /dev/null' for each mountpoint.
01:20 <TemptorSent> Something is weird in mount-land somewhere, but I'm not seeing where yet.
01:23 <TemptorSent> Okay, that's cool... now where is my world file?
01:24 <TemptorSent> Hard for the overlay to run daemons that aren't installed :P
01:27 <kaniini> /etc/apk/world
01:32 <TemptorSent> Yeah, it's looking awfully empty :)
01:32 <awilfox> jirutka: are you running the binary 'clang++'
01:32 <jirutka> yes
01:32 <TemptorSent> I don't believe the build system previously installed anything other than base in the image.
01:32 <jirutka> when g++ is installed on the system, then there’s no problem
01:33 <awilfox> jirutka: that is because clang++ is built against the G++ headers on linux
01:33 <awilfox> jirutka: unless you enable libc++
01:33 <jirutka> i thought that for clang build I can install only clang and libdstc++
01:33 <jirutka> aha
01:33 <kaniini> TemptorSent: it didn't
01:34 <kaniini> TemptorSent: because the idea is to install the packages you need :P
01:34 <TemptorSent> kaniini: A bit of a probem when trying to use a run-from-ram box.
01:34 <kaniini> no?
01:34 <kaniini> you are supposed to use lbu(1) to commit the packages after installing them
01:34 <TemptorSent> kaniini: Autogenerating and installing ssh keys is nice and all, but it helps to actually have ssh install at boot.
01:34 <kaniini> the 'profiles' just determine what packages are available on the CD repository
01:35 <kaniini> sure, but that does not mean that you should be installing asterisk and starting it with a default configuration on first boot
01:35 <kaniini> for example
01:35 <TemptorSent> kaniini : Yeh, like I said, it needs a bit of help :)
01:36 <kaniini> what if the admin does not want SSH enabled by default?
01:36 <TemptorSent> kaniini: Actually, that's EXACTLY the type of thing I need. Services running by sticking media in a drive, rebooting, and walking away.
01:37 <kaniini> yes, but the current system intentionally isn't like that
01:37 <kaniini> it does not "need a bit of help", it is working as designed
01:37 <TemptorSent> kaniini - Yeah, for hands-on application it makes sense, but it's hard to ssh into a virtual host that doesn't have sshd running :)
01:38 <kaniini> if you need 'services running by sticking media in a drive' why not just run something like turnkey linux
01:38 <TemptorSent> kaniini - I understand it's well beyond the original scope of the project, but it is seriously useful.
01:39 <TemptorSent> I'm building custom, one off images with distinct configruation per image.
01:39 <kaniini> i mean, the difference here is simply that what turnkey linux does would be officially supported by alpine
01:39 <kaniini> not personally convinced its worth that :p
01:41 <TemptorSent> Current project: GIS datastore and DB, and contanerized applications sitting on a box a thousand miles away that has nobody that even remotely speaks unix.
01:41 <TemptorSent> Side project: rpi based weather stations/cameras that get a physical sd card per unit.
01:42 <TemptorSent> On the server side, I actually want to be able to build nested images, with the vm host running in ram and the vms running on whatever storage you want. PXE boot most likely.
01:44 <TemptorSent> Anyway, it shouldn't be too hard to convince the build system to make a world file to go with it when desired.
01:45 <awilfox> TemptorSent: I think the point is more that if you know it is well beyond the original scope of the project, why are you expecting the project to just work for your use case :P
01:49 <kaniini> don't get me wrong, i think adding more capability to customize the ISOs is a good thing
01:49 <kaniini> i am just concerned that people will start demanding lots of respins
01:53 <TemptorSent> kaniini - they can spin their own!
01:53 <awilfox> if the framework is flexible enough, sure
01:53 <awilfox> and it has good documentation
01:53 <TemptorSent> kaniini: in fact, an image for building images wouldn't be a bad thought.
01:54 <TemptorSent> As far as doing things it wasn't intended to do, the probems I'm running into are more peripheral than that.. I can spit out a world file easily enough :)
01:55 blueness joined
01:56 <TemptorSent> awilfox : Take a look at https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
01:57 <TemptorSent> I've at least put a pretty good start into documenting the code, and documenting the rest should probably wait until it's somewhat stable I guess...
01:58 <TemptorSent> Just pushed revision which I'm working with.
01:59 <pickfire> jirutka: I didn't know that people tried packaging ranger.
01:59 <TemptorSent> Building a new profile is childs play. For that matter, it's pretty easy to add new boatloaders, image types, and features too.
01:59 <jirutka> pickfire: well, always look into unmaintained first ;)
02:00 <pickfire> :)
02:00 blueness joined
02:01 <jirutka> pickfire: but to be honest, I also rarely looks into unmaintained :/ I remember ranger, b/c it’s one of the pkgs took over from one ex-contributor
02:02 <pickfire> Ah
02:03 <pickfire> Me too, I just look into those package useful for me.
02:31 s33se joined
02:47 Emperor_Earth joined
02:59 leo-unglaub joined
03:14 <TemptorSent> Question: If it makes sense to put a local repository on a cd or usb stick but not install it in the world file, does it make sense to do the same on a rootfs image?
03:14 minimalism joined
04:31 blueness joined
04:41 pickfire joined
05:55 <TemptorSent> Alright, just about there on something actually usable for actually building bootable media!
06:17 <TemptorSent> Eyes are bleadinng, but it appears to actually work! I'm going to have to call it an early night I'm afraid, so I'll miss the guys in europe.
06:17 <_ikke_> TemptorSent: night!
06:17 <TemptorSent> Not dead yet, just not even going to try for 4 in the morning again.
06:18 <TemptorSent> Anyway, mkimage now builds custom images, including ready-to-run overlays.
06:19 <TemptorSent> Still have to figure out why ssh it bitching about host pub key formats, but that's because I'm too tired to care about that kind of detail right now.
06:20 <TemptorSent> Oh, and it would help if I actuall populated authorized_keys, not just created the public keys for the root login :)
06:50 <TemptorSent> Okay, much better now.
06:51 t0mmy joined
07:24 NightKhaos joined
07:40 royger joined
07:41 pickfire joined
07:43 pickfire joined
07:55 t0mmy joined
08:26 vakartel joined
08:34 gromero joined
08:36 royger joined
08:43 <TemptorSent> Tried sleeping, not happing yet - might as well be productive... Anyone know who maintains the zfs package?
08:50 <scadu> TemptorSent: zfs is maintained by clandmeter
08:50 <* clandmeter> hides
08:50 <scadu> ;v
08:51 <scadu> clandmeter: run!
08:57 _errm joined
08:59 <TemptorSent> Hi clandmeter!
09:00 <TemptorSent> So I'm working on getting a rewrite of mkimage done, have it working, bringing up zfs, and everything... but it's bitchign about the initscript format :)
09:01 <TemptorSent> Thanks for outing clandmeter scadu!
09:02 <TemptorSent> clandmeter: So, do you have a working ZFS root setup?
09:02 <scadu> TemptorSent: I have no doubts he's the happiest man in the world now :f
09:02 <TemptorSent> *lol*
09:02 <TemptorSent> scadu: He may have taken your advice and headed for the hills ;)
09:04 <TemptorSent> Anyway, as far as I can tell the only missing link is probably the initfs/init
09:05 <TemptorSent> Oh, and a nice little auto-installer at some point if I'm on raw hardware.
09:06 fekepp joined
09:15 blahdodo joined
09:16 _errm joined
09:47 _errm joined
09:51 <clandmeter> TemptorSent, hi
09:52 <clandmeter> i was in meeting
09:52 <clandmeter> no im currently not using it.
10:02 blueness joined
10:06 <TemptorSent> clandmeter: No problem, I'm just looking to know what I'm getting into and if anyone else has already done the work :)
10:07 <clandmeter> its working
10:07 <clandmeter> ncopa uses it
10:07 <clandmeter> but he did have some issues with dual booting
10:08 <TemptorSent> Got it... I have it happily booting up into the ramfs, and running through import, mount, export, and zed.
10:09 <TemptorSent> The only thing it's complaining about so far is the format of the init.d scripts being unsupported.
10:09 <TemptorSent> I haven't thrown it on a real pool yet to see how it acts, just testing the startup process thus far.
10:09 m41 joined
10:10 <clandmeter> hmm, i never had issues with initd, but thats some time ago
10:10 <clandmeter> what is the error?
10:11 royger joined
10:11 <TemptorSent> it's just saying that it doesn't like the runscript header I believe.
10:12 <clandmeter> ah that one.
10:12 <TemptorSent> Simply adding a new first line with an appropriate #! should do it.
10:13 <clandmeter> just update it to #!/sbin/openrc-run
10:14 <TemptorSent> Yup. It doesn't actually break anything, but it makes the otherwise clean startup look a bit crufty :)
10:15 <clandmeter> i think zfs provides the openrc files theselves
10:19 blueness joined
10:20 <TemptorSent> I believe that's the case -- it should be easy enough to do some surgery on them.
10:21 <TemptorSent> (echo '#!/sbin/openrc-run' ; head -n -1 $file ) | cat - > $file
10:32 <TemptorSent> clandmeter: Here's what I'm using right now to bring zfs into an overlay and autostart it: https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage/features/zfs
10:37 <TemptorSent> I need to work on the nfs/iscsi features too, but it currently builds images with working overlays that populate tools and run services.
10:38 <TemptorSent> Anyway, I need to try again on the sleep thing. It's not a good idea to contniue coding when you can no longer see the screen clearly... it's worse to try to do anything with root :)
10:56 gromero joined
11:01 gromero joined
12:05 farosas_ joined
12:19 ferseiti joined
12:20 leitao joined
12:48 <pickfire> The patch that I have sent is superseeded? What does that mean? %3103
12:48 <algitbot> [alpine-aports] main/taskd: Add init scripts - Patchwork: http://patchwork.alpinelinux.org/patch/3103/
12:55 <clandmeter> pickfire, maybe there is something related on github?
12:56 <pickfire> clandmeter: ok
12:59 <clandmeter> doesnt look like it. does it mention who superseded it?
12:59 <pickfire> No
12:59 <clandmeter> changes are it was jirutka
13:14 <jirutka> pickfire: I’ve told you it three times: this package is broken
13:14 <jirutka> pickfire: http://bugs.alpinelinux.org/issues/6839
13:15 <pickfire> Oh
13:15 <jirutka> pickfire: I’ve tested it and the same problem as reported in #6839 persists
13:15 <algitbot> Bug #6839: ranger (curses file manager) segfaults. Workaround inside. - Alpine Linux - Alpine Linux Development: http://bugs.alpinelinux.org/issues/6839
13:15 <pickfire> Wai
13:15 <pickfire> t
13:16 <jirutka> wait a moment
13:16 <jirutka> sry, you’re talking about some other patch
13:16 <pickfire> jirutka: How is that related to ranger.
13:16 <jirutka> it’s not
13:16 <pickfire> sorry about typing slowly, still training on dvp
13:16 <jirutka> omg i hate patchwork so much
13:17 <pickfire> Why?
13:17 <jirutka> doesn’t matter now
13:17 <jirutka> this is right, http://patchwork.alpinelinux.org/patch/3103/ has been superseded by http://patchwork.alpinelinux.org/patch/3104/
13:18 <pickfire> Github workflow is the one that is complicated.
13:18 <scadu> XD
13:19 <pickfire> Oh
13:19 <* pickfire> my bad
13:20 <jirutka> complicated?!
13:20 <jirutka> it’s not complicated at all, you just create a branch and open PR for it, that’s all
13:20 <jirutka> then you can keep adding new commits into it
13:20 <jirutka> and it’s very clear that it’s related to the same thing
13:20 <pickfire> jirutka: No cli
13:20 <jirutka> there is CLI
13:21 <jirutka> actually there are multiple CLIs that you can use
13:21 <pickfire> patches are easier
13:21 <jirutka> patches via email may be easier for you, but it’s a nightmare for us
13:21 <pickfire> Just no CI
13:22 <pickfire> oh
13:23 <pickfire> jirutka: How's the github workflow?
13:24 <pickfire> Now, I just git send-email
13:24 <jirutka> pickfire: 1. create “Fork” of https://github.com/alpinelinux/aports, 2. clone it locally, 3. create new topic branch, 4. add/change whatever you want, commit and push, 5. open PR
13:24 <jirutka> pickfire: you do 1 and 2 just once
13:25 <jirutka> pickfire: maybe you misses the review process
13:25 <pickfire> jirutka: I had already did it.
13:26 <jirutka> pickfire: when you send a patch, someone should review it, write comments and then you should fix the issues, if any… with GH you just make changes in your branch, commit and push, it’s still in the same PR, very clear what have you changed
13:26 <pickfire> I just didn't submit PR
13:28 <jirutka> you’ve just sent two patches, when the second replaces the first, but on Patchwork they are two separate patches and we must figure out what the heck is that
13:28 <jirutka> this does not happen on GH, you can just fix your patch and force push into your branch
13:33 leo-unglaub joined
13:44 BitL0G1c joined
14:04 slukin joined
14:04 leitao joined
14:07 ferseiti joined
15:05 Emperor_Earth joined
15:33 leo-unglaub joined
15:48 <jirutka> can I somehow force make to not rebuild targets based on timestamp of files?
15:56 <ncopa> how woudl make know what to rebuild then?
15:56 <ncopa> only missing files?
15:56 <_ikke_> checksums :P
16:03 leitao joined
16:03 <jirutka> checksums is what i need and what I would expect from decent build system (that make is definitely not)
16:03 <jirutka> or even missing files would be suitable for one case i need
16:11 royger joined
16:54 leo-unglaub joined
17:22 leitao joined
17:25 mikeee_ joined
17:34 minimalism joined
17:47 leo-unglaub joined
17:50 <TemptorSent> 'mornning all. Does anyone happen to have any idea why the passwd file at /usr/share/mkinitfs/passwd is so extensive?
17:54 <TemptorSent> Do we really need 43 entries in the passwd file for the initfs?
17:56 czart_ joined
17:56 <TemptorSent> Is it just so we can resolve usernames in the early boot?
18:08 <kaniini> :D
18:09 <kaniini> i think most likely somebody just took their /etc/passwd and used that
18:09 <kaniini> :P
18:11 <TemptorSent> kaniini: I'm not sure about that.... Take a look at it.
18:12 <TemptorSent> portage?
18:12 <kaniini> mkinitfs predates modern alpine, when it was ncopa trying to make a gentoo binary distro
18:12 <kaniini> so yes, likely :P
18:12 <TemptorSent> Ahh, got it!
18:12 <TemptorSent> I was going to say, it looks more like gentoo than alpine :)
18:13 <TemptorSent> Okay, it can probably be trimmed to just a couple of lines then safely.
18:14 <TemptorSent> Or replace it with one that has every known account installed by any package on alpine so the userid->user resolving works.
18:14 <TemptorSent> Right now it's just confusing.
18:15 <kaniini> minimal mkinitfs file seems fine
18:15 <kaniini> initfs should not start any services really
18:15 <TemptorSent> Do we have a template passwd file with all the uids mapped?
18:15 <TemptorSent> No, but when you're in a rescue shell trying to figure out what broke, it can be useful to resolve the uids.
18:15 <kaniini> it only needs 1 uid in it
18:15 <kaniini> for root
18:16 <kaniini> :p
18:16 <kaniini> everything in the initfs
18:16 <kaniini> runs as root
18:16 <TemptorSent> Right, I mean when you get dumped to a rescue shell because the boot sequence failed.
18:17 <TemptorSent> It's nice to figure out that something isn't starting because it's the ownership on it's key is wrong.
18:18 <kaniini> just use the host's passwd file then
18:18 <TemptorSent> And especially useful if you have to use it as a rescue tool.
18:19 <TemptorSent> kaniini: Yeah, if your rootfs is mounting correctly.
18:20 <TemptorSent> When you're trying to recover a zpool with a crashed os drive, it can be not so easy :)
18:21 <TemptorSent> But that can be fscked with later if needed. For now, I'll plan on trimming the passwd and group file in mkinitfs
18:21 <TemptorSent> We can allways annotate it later if we find it needful.
18:24 <kaniini> i mean
18:24 <kaniini> copy it
18:24 <kaniini> when you generate the image
18:29 <pavlix> hi
18:29 <pavlix> TemptorSent: How are you doing?
18:33 <TemptorSent> pavlix: Still a bit bleary eyed, but doing pretty well otherwise. Yourself?
18:33 <TemptorSent> pavlix: Late start on the coffee :)
18:34 LongyanG joined
18:34 <pavlix> TemptorSent: I had quite some coffee and teas today and will have more during the week.
18:37 <TemptorSent> pavlix: I'm out of my preferred beans, so I need to take a trip down the hill into suburbia and visit my favorite roaster ASAP.
18:39 <pavlix> TemptorSent: Where are you from btw?
18:40 <TemptorSent> I live in Foresthill, California, U.S.A. up in the foothills of the Sierra.
18:42 <TemptorSent> pavlix: Just a bit below the normal snow-line - but we've been seeing quite a bit of white this year.
18:48 <pavlix> TemptorSent: Anyways, I'm in a pub... was waiting for a friend. He's arrived, so closing laptop.. :)
18:53 <TemptorSent> pavlix: Have a great evening then.
18:53 leo-unglaub joined
18:53 MH0815 joined
18:56 Fooster joined
19:01 farosas_ joined
19:03 leitao joined
19:18 leo-unglaub joined
19:19 <TemptorSent> Query regarding default work/output directories: Is it safe to assume that somewhere in /tmp is a good default location for building rather than $PWD unless specified? Output can default to $PWD as long as $PWD isn't the script's dir...
19:22 <TemptorSent> Once I figure out how to get apk to actually use the package cache specified by --cache-dir, that should be sane, right?
19:40 mikeee_ joined
20:35 Shiz joined
21:03 leo-unglaub joined
21:13 leo-unglaub joined
21:28 blueness joined
21:34 m4 joined
21:43 t0mmy joined
21:44 <skarnet> TemptorSent: avoid building in /tmp if you can. /tmp is most likely a tmpfs, i.e. every file you create there eats up RAM.
21:44 <skarnet> that's not a problem for small files, but for a build... not good.
21:44 <skarnet> Use /var/tmp if anything.
21:48 <jirutka> skarnet: what do you think, is it a good idea to mount /tmp as tmpfs at all?
21:50 <TemptorSent> I actually use tmpfs for building intentionally for both speed and auto-cleanup :)
21:51 <awilfox> on machines with large amounts of RAM, it's actually fabulous; my 24 GB build box chews up packages in seconds using tmpfs :P
21:52 <TemptorSent> That's my thinking as well. I use /tmp for exactly that on my machines usually.
21:53 <TemptorSent> skarnet: In low memory uses, specify a work dir somewhere with space to spare explicitly.
21:54 <TemptorSent> skarnet: What I don't like about /var/tmp is it often doesn't get cleaned up for long periods and can grow excessively on something like a flash card, not to mention thrashing.
21:54 <skarnet> that's all fine and dandy, but please bear in mind that Alpine has low-resource environments as an intended target
21:55 <TemptorSent> skarnet: So on things like a rpi, I'd probably want to run the build on a thumb drive or extenal device rather than the sd root.
21:55 fekepp joined
21:55 ferseiti joined
21:55 <skarnet> if you have a build process that doesn't clean up its temporary files, it's a bug and you own it
21:56 <TemptorSent> skarnet: Actually, in the case of mkimage, it's intentional.
21:56 <TemptorSent> skarnet: We really don't want to clean up after a run when we're going to use the same artifacts for several more images.
21:57 <skarnet> I guess you're not going to do this on a low-spec machine then. Have at it.
21:57 <skarnet> jirutka: yes, it's a good idea, because large builds blowing up /tmp are the exception, not the rule
21:57 <TemptorSent> skarnet: It should work fine on low-spec machines, just pass --workdir /var/tmp
21:58 <TemptorSent> skarnet: I suppose I could even check arch and possibly parse free to decide.
21:59 <skarnet> absolutely not. KISS please.
21:59 <skarnet> smart heuristics are the first step on the slippery slope leading to moussaka hell.
21:59 <skarnet> (aka GNU programs)
22:00 <TemptorSent> skarnet: *lol* I mean setting the default based on the arch and throwing a warning if we don't have much free space.
22:01 <TemptorSent> skarnet: It actually would be good to at least estimate space needs before building to avoid filling up filesystems accidentally on rpis and such with small sd cards.
22:01 <skarnet> that's more complex than it needs to be. If it's user-configurable then you're good, and you should focus on more important things until users come screaming at you that they blew up their /tmp.
22:02 <skarnet> if someone attempts to build 24 GB of images on a RPi then they have more problems than you can fix (i.e. pebkac)
22:02 <TemptorSent> skarnet : Of course it's user configurable! I'm just looking at where to default it, and where to default the output if the person happens to try to run it in the script dir.
22:03 <skarnet> I'd use /var/tmp as the default, but if you don't like it, /tmp is fine. Just add a warning in the mkimage man page and you're set.
22:03 <TemptorSent> skarnet: *lol* Yeah, noted -- but I'm also trying to make this something a user could use.
22:04 <TemptorSent> skarnet: Yeah, I've added significantly more informative text to the build process so it's easier to debug profiles and such. Uses msg, so it can be squelched if desired.
22:04 <skarnet> don't assume users are stupid and need pampering. Of course they are and they do, but you can't assume it - doing so leads to bad design.
22:05 <jirutka> XD
22:05 <TemptorSent> skarnet: Yeah, mostly I'm worried about making it obvious WHY something fails, since I wasted a couple days trying to track down stupid bugs I couldn't even find the realm of in the initfs stuff.
22:06 <skarnet> learning to print good error messages is a life's work ;)
22:06 <TemptorSent> When something FAILS, the quiet flag shouldn't inhibit the output!
22:06 <skarnet> yeah, warnings != errors. "quiet" should suppress warnings, but not errors.
22:06 <skarnet> to suppress errors, users can always 2>/dev/null
22:07 <TemptorSent> I couldn't find the stupid minor bug in my code because of error suppression in init.
22:08 <TemptorSent> When it fails to load the boot repository due to untrusted keys, I really DO want to know about it before getting unceremoniously dumped to a recovery shell.
22:09 <skarnet> init (and initramfs' pid 1 even more so) is a special case because you don't have a logging infrastructure in place so verbosity management is a bit complicated. If it feels raw, it's because it has to be.
22:09 <TemptorSent> skarnet: I prefer the precept of be verbose by default and put a gag on it if you want to.
22:09 <skarnet> that's not how Unix works.
22:10 <TemptorSent> Nope, take a look -- there's no reason why it shouldn't have thrown the warning! I had to force "noquiet" to get it to tell me what crapped out.
22:10 <TemptorSent> If noquiet let's me see the error, the verbosity management is broken.
22:11 <skarnet> that's very possible. Again, errors shouldn't be silenced by a "normal" quiet mode.
22:11 <TemptorSent> Actually, for the most part tools are (reaonably) verbose by default, and you have to pass a flag to shut them up.
22:12 <skarnet> Traditional Unix works the other way - terse by default, verbose with a flag.
22:12 <skarnet> but none of this matters when there are actual errors.
22:12 leo-unglaub joined
22:12 <skarnet> hey leo-cutie
22:13 <Shiz> flirting? in MY #alpine-devel?
22:13 <TemptorSent> skarnet: take a look at make, cc, etc.. they tend to give you info unless you ask them not to.
22:13 <TemptorSent> skarnet: If you want EXTRA verbose, you pass the -v flag
22:13 <skarnet> Shiz: anywhere is fair game! Unless you passed regulations?
22:13 <Shiz> i was just gonna say "it's more likely than you think"
22:14 <TemptorSent> *lol* What is this? Rusty & Eddies? ;)
22:15 <skarnet> TemptorSent: build tools are kind of an exception, especially GNU tools. GNU's not Unix and it shows a lot when you run make+gcc.
22:15 <skarnet> (arguably when you run a build, you *want* reasonable verbosity by default.)
22:16 <TemptorSent> skarnet: In the OLD days, things like init scripts used to give you a fair bit of info, or at least status as they went.
22:16 <skarnet> what init scripts? sysv-rc?
22:16 <TemptorSent> skarnet: In fact, they would often actually echo commands.
22:16 <skarnet> older?
22:16 <TemptorSent> skarnet: sys-v? Yeah that was the NEW init system!
22:17 <TemptorSent> bsd init was common, before that, it was often brewed-to-taste.
22:18 <skarnet> and again, init scripts are not a very good example because it's just lines scrolling on a terminal at boot time
22:18 <skarnet> and the verbosity is partly intentional, so it looks cool and techy
22:18 <TemptorSent> Right, which is exactly what I'm bitching about having NO output, even with noquiet it's very minimal and not useful for debugging.
22:19 <skarnet> Shiz: with the gender ratio around here, I doubt it's likely at all. https://plus.google.com/u/0/+LaurentBercotSka/posts/BuK7KxZ7y4U
22:19 <TemptorSent> skarnet: Wow, the world has changed since I got started in the unix world.. we didn't give a crap what anything looked like then, we just wanted to be able to make it work and keep it working. Readability was a plus.
22:20 <Shiz> skarnet: nothing wrong with a lil gay
22:21 <skarnet> Shiz: obviously, but I don't know that many gay tech guys. (It's not something you usually say out of the blue.)
22:21 <TemptorSent> skarnet: If you wanted pretty, you did ascii-art or went really out there and did ansi+IBM extended character drawing (remember slackware).
22:21 <Shiz> for what it's worth, i'm bi
22:22 <skarnet> TemptorSent: I know. I always hated that. Some people even used figlet. I wanted to kill them.
22:23 <skarnet> Shiz: that certainly opens up the possibilities in a 99% male world :D
22:23 <TemptorSent> skarnet: I still had a form-feed line-printer running into the late '90s for logging and even terminal use.
22:23 <Shiz> well, luckily you don't *always* have to combine work with pleasure
22:23 <Shiz> :p
22:23 <Shiz> (my last gf was an artist...)
22:24 <skarnet> of course you don't, but my point is that for us straight guys, we basically *cannot* combine
22:24 <skarnet> TemptorSent: lp1 on fire? :D
22:24 <TemptorSent> skarnet: What's the old line, "bis are better with statistics"? :)
22:25 <skarnet> and anyway leo silently rejected me
22:25 <Shiz> it is a curse
22:25 <skarnet> now I need to drink my heartbreak away
22:26 <TemptorSent> skarnet: Yeah, we used to have fun logging into each others BBSs and spamming the logs at 4 in the morning.
22:26 <TemptorSent> skarnet: It was a great way of pining someone without ringing the phone.
22:26 <skarnet> teenage mischievousness
22:27 <skarnet> with a geek tint
22:27 <TemptorSent> skarnet: Sometimes, more often than not it was to let them know a UUCP session failed or something and get them to log in and fix it while the phones were still cheap.
22:28 <TemptorSent> *lol* or FIDO in some cases.
22:30 <skarnet> even if you were well-intentioned, if you found a way to wake me up at 4 am by sending my noisy printer into overdrive, I'd delete your account right away, then disconnect, axe the printer and go back to sleep, and fuck the UUCP session
22:30 <skarnet> that's how friendly I am when something wakes me up
22:31 <skarnet> when I'm oncall, I get paid extra for it. :P
22:32 <TemptorSent> skarnet: Yeah, this was back in the days when that's the ONLY time you could actually tie up the phone lines for hours at a time, usually 3-6 sessions with different nodes each night on a fixed schedule.
22:32 <skarnet> I'm glad we have decent connections now :)
22:33 <TemptorSent> skarnet: So if a session died and didn't repop for some reason, an entire days traffic to a major hub might be delayed.
22:33 <awilfox> speak for yourself
22:33 <awilfox> 3G is the new UUCP
22:33 <skarnet> TemptorSent: and that's why we need supervision. #myworkhereisdone
22:34 <pavlix> TemptorSent: I had a great evening as you instructed me. :)
22:34 <TemptorSent> *lol* The difference between 3G and UUCP is I can actually use UUCP from home :)
22:35 <awilfox> skarnet: in re that G+ post
22:35 <awilfox> skarnet: from my mother's experience in hospital work, yes.
22:35 <skarnet> interesting data point, thank you :)
22:35 <awilfox> the hospital's CEO was a woman, the entire executive team were women, and the entire records division was women + 1 gay guy
22:36 <skarnet> not surprised one bit
22:39 <TemptorSent> Woah -- apk segfaulting.. that's not cool.
22:39 <awilfox> TemptorSent: is this by any chance during a removal?
22:43 <TemptorSent> awilfox Nope, bad options being passed.
22:43 <TemptorSent> My bug, but apk dumping core rather than just puking gracefully on the input.
22:45 <* skarnet> sobs
22:49 <TemptorSent> Bug found -- was simple transpose of $ and { when concatenating ${i}{$needle} is what I had, accidentally resulting in things like linux{-grsec}, which crahed apk when passed for some reason.
22:50 <awilfox> huh
22:50 <awilfox> TemptorSent: exact line passed to apk?
22:57 <TemptorSent> ug, I already fixed my bug :) it looks something like apk --cache-dir /tmp/mkimage.cache fetch --root $WORKDIR --link --recursive --output "$archdir" wit ha long line of apks, but some of the flavored ones malformed as {-grsec} for the suffix rather than -grsec.
22:59 <TemptorSent> Anyway, now that that's taken care of, everything is running happily again.
23:10 <kaniini> what G+ post
23:11 <TemptorSent> Google+ I'm guessing?
23:11 <kaniini> oh, i see
23:12 <TemptorSent> awilfox: Also, if you know anything about it, I can't seem to get apk --cache-dir to actually use the cache dir I specify!
23:12 <kaniini> humm, should be working
23:12 <kaniini> try apk fetch --cache-dir
23:13 <awilfox> I don't know anything about --cache-dir, sorry
23:13 <TemptorSent> kaniini: Oh, hope to hell I don't have to specify it after each command...
23:13 <awilfox> :)
23:13 <kaniini> TemptorSent: unless you link /etc/apk/cache to some place yes
23:13 <TemptorSent> I'm getting a cache dir created, but it's not actually caching anything but indexes to it.
23:15 <TemptorSent> I have four APKINDEX.tar.gz files and an empty 'installed' file in the specified cache dir.
23:15 leo-unglaub joined
23:17 <TemptorSent> Well drat, if the options can't preceed the command, the easy fix of changing the name of the apk command doesn't work.
23:17 <awilfox> that shouldn't be an issue afaik
23:18 <awilfox> apk --arch $ARCH -X "https://distfiles.adelielinux.org/adelie/1.0-alpha/$EXTRA_MIRROR" -U --root squashroot-$ARCH --initdb add $PACKAGES $ARCH_PKGS
23:18 <awilfox> in fact, I put it at the very end
23:18 <awilfox> but
23:18 <awilfox> I don't use cache-dir in this script
23:18 <awilfox> so I don't know if that option specifically is different
23:18 <TemptorSent> Yeah, --cache-dir is a new functionality.
23:19 <TemptorSent> Wait a sec, I think I know what the bug is in apk!
23:19 <TemptorSent> Does root just blindly set the cache dir to $apkroot/etc/apk/cache?
23:20 <TemptorSent> If so, having it parse AFTER the --cache-dir option may cause it to overwrite the explicitly specified location.
23:20 <TemptorSent> Subsequent --cache-dirs overwriting each other is fine, but if the root overwrites it, there's a problem.
23:21 mitchty joined
23:22 <TemptorSent> kaniini: Can you verify that?
23:24 leo-unglaub joined
23:24 <kaniini> no...
23:24 <TemptorSent> Anyone up for taking a look at the current state of my mkimage branch and seeing if it works for you?
23:24 <kaniini> the default is no cache dir is used
23:26 <TemptorSent> kaniini: Understood, what I mean is that we have a command the specifies an explicit cache directory with --cache-dir, then later explicitly specifies a root with --root. What I suspect happens in the code is the explicit path specified by the cache dir is overwritten by the one inferred from the root.
23:27 Shiz joined
23:28 mitchty joined
23:33 <TemptorSent> cachedir is set using "dbopts->cache_dir = optarg;" on line 134 of apk-static...
23:34 <TemptorSent> apk.c as well.
23:45 <TemptorSent> It looks like the --cache-dir is getting referenced in absolute terms in some places and relative to root_fd in others.
23:45 <TemptorSent> Hopefully ncopa or fabled can take a look at it.
23:48 <TemptorSent> fd = openat(db->root_fd, dbopts->cache_dir, ...
23:49 <TemptorSent> Maybe check for leading slash before prepending the --root root?