<  February 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
00:10 TemptorSent joined
00:20 tmh1999 joined
00:23 <TemptorSent> Good afternoon - is fabled on by chance (or another mkinitfs dev)?
01:07 tmh1999 joined
01:19 mikeee_ joined
01:53 blueness joined
02:56 s33se_ joined
03:25 ncopa joined
05:22 <TemptorSent> *ping* Any devs with repo admin abilities on? It seems busybox is broken in the latest index (on edge).
05:42 skarnet joined
05:48 <_ikke_> TemptorSent: Should be someone around in a couple of hours (European work time)
05:49 <TemptorSent> Thanks _ikke_! It looks like something broke with the busybox 1.26.2-r0 build as none of the apks are in the repo but they are in the index.
05:53 <_ikke_> TemptorSent: perhaps an rsync problem
05:54 <_ikke_> TemptorSent: http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/busybox-1.26.2-r0.apk
05:54 <_ikke_> This one?
05:54 <TemptorSent> Perhaps. Hopefully transient, as it's currently bjorking my work on revising alpine-iso
05:55 <_ikke_> That mirror seems to have it
05:55 <TemptorSent> It appears so.
05:55 <TemptorSent> Let's see which mirror is broken then :)
05:55 <_ikke_> what mirror are you using?
05:55 <TemptorSent> looks like it's leaseweb that's fubar.
05:57 <_ikke_> https://mirror.leaseweb.com/alpine/edge/main/x86_64/busybox-1.26.2-r0.apk
05:58 <TemptorSent> Forcing the main dl-cdn.alpinelinux.org worked.
05:59 <TemptorSent> And with multiple mirrors listed, it wasn't trying to fail over.
05:59 <_ikke_> Do you know where exactly it is missing?
06:02 <TemptorSent> No, I'm not sure what it was puking on -- apk upgrade was failing to find the package when mirror was set to leaseweb, but is happy as a clam on the primary cdn.
06:03 fabled joined
06:03 <TemptorSent> It gave a missing error, not a checksum error, but it's possible the file was corrupted.
06:04 <TemptorSent> Hello fabled.
06:08 <TemptorSent> @fabled - I'm working on doing a major rework of the alpine-iso build system, including some issues touching mkinitfs, and have found a few issues that I'm hoping you can help address.
06:14 <fabled> TemptorSent, morning, alpine-iso is deprecated
06:15 <fabled> TemptorSent, 3.5 and edge use aports.git/scripts/mkimage.sh
06:15 <TemptorSent> Oh! Um, what has replaced it?
06:15 <TemptorSent> That handles building the overalys, initfs, and isos?
06:15 <fabled> it builds isos, overlays etc. it uses mkinitfs to build initfs
06:16 <TemptorSent> Bloody hell, I wasted a lot of time making alpine-iso usable :)
06:18 <TemptorSent> Okay, let's see if my modified build environment will still be of any use...
06:19 <TemptorSent> Waiting for the bits to crawl across the string between the tin-cans in the rain.
06:21 <TemptorSent> My basic goal is to add the ability to add multiple 'features' to a profile, allowing the building of customized or even one-off isos/discs, usb sticks, and VM images.
06:22 <fabled> yes, mkimage.sh is much more well suited for that
06:22 <TemptorSent> In the old alpine-iso system I have it handling zfs, iscsi, nfs, samba, kvm, and xen.
06:22 <fabled> it's not perfect yet, and there's few pecularities in it. but it's much better than the alpine-iso makefiles
06:23 <TemptorSent> Yeah, I'm not bad with make, but it got pretty convoluted in places to do very simple things.
06:24 <TemptorSent> Oh, btw - bug in mkinitfs -- type: bashism - there is a spurious "local" outside a function in the code for "-L" which the shell pukes on
06:25 <TemptorSent> I speak bash fluently, so it took be a bit of looking to figure out what was going on there.
06:25 <fabled> i think some of the "local" things have been fixed recently, but if there's any left patches are welcome
06:28 <TemptorSent> Better yet would probably be just stick bit of code into a function and call it, "list_features()" or some such.
06:30 Guest85325 joined
06:31 <TemptorSent> Hmm, the new build sytem looks more workable...
06:32 <TemptorSent> Is there a means of stacking profiles easily that I haven't found yet?
06:32 <fabled> TemptorSent, they are stacked even now
06:33 <fabled> the profile function just calls the profile function it wants to stack on
06:33 <fabled> e.g. mkimg.arm.sh: profile_uboot() calls profile_base from mkimg.base.sh
06:33 <fabled> in fact everything is pretty much on top of profile_base
06:36 <TemptorSent> Okay, that side of it is easy :)
06:36 <TemptorSent> The overlays don't appear to stack though?
06:37 <fabled> oh, no. it only calls a script to create the overlay. we generally ship with minimal overlay if any
06:38 <TemptorSent> Ahh, got it.
06:38 <TemptorSent> That's part of what I was implementing, merging overlays to have a ready-to-run system.
06:40 <fabled> cool
06:40 <fabled> i would have use for it in few appliances i run too
06:40 <TemptorSent> I basically dumped each faature into a directory, then provided configuration for which packages to include for modloop, initfs, world, and pkg repo, as well as an overlay base directory and files.
06:41 <TemptorSent> So my alpine-kvm-host+zfs profile had the kvm-host, zfs, iscsi, nfs, and samba features enabled, with an overlay automatically generated that would start all services by default.
06:42 <fabled> nice
06:42 <TemptorSent> And the only packages I had to list explicitly in my profile were the ones for my particular application.
06:43 <TemptorSent> Took care of fixing the mkinitfs.conf file as well as world file and options to the kernel.
06:44 <TemptorSent> BTW - is there a way to tell mkinitfs what packages it needs?
07:01 <TemptorSent> I'm seeing 'kernel_addons', but it's used inconsistently it seems.
07:02 <TemptorSent> It looks like in some places it's adding modules, while elsewhere (xtables-addons) it's adding a package without a flavor.
07:05 vakartel joined
07:06 <TemptorSent> Would it make more sense to simply split out the kernel-specifc (-$kernelflavor) module packages from the support packages and handle them invididually so we don't have the ugliness found in the extended profile?
07:08 <fabled> TemptorSent, iirc, mkinitfs does not extract any packages itself. it's done in update-kernel via -p, and update-kernel calls mkinitfs
07:09 <TemptorSent> Okay, that's what I was seeing.
07:10 <TemptorSent> With the initramfs 'features' being part of mkinitfs, would it perhaps be appropriate to include the package dependencies for each feature so they can be autodiscovered if not autoinstalled?
07:11 <fabled> yeah, that would be nice
07:11 <TemptorSent> just add a file $feature.packages if follwing the current scheme.
07:12 <fabled> yes. ncopa might have additional thoughts...
07:13 <TemptorSent> I'd be happy help develop the build/provisioning system.
07:14 <fabled> we would appreciate that. you might want to email alpine-devel or ask here on the design first, so no surprises come like with alpine-iso
07:14 <TemptorSent> My 'other' distro is funtoo, having started with gentoo back in its infancy.
07:15 <TemptorSent> Will do -- just a note, the wiki is rather out of date :)
07:15 <TemptorSent> If nothing else, it knocked a fair bit of rust of my makefile skills :)
07:16 <TemptorSent> Alright, what I have in mind right off is just setting up a 'features' subdirectory (currently under scripts) that will contain one sub-directory per feature
07:19 <TemptorSent> each feature gets a script (call it 'feature-$feature.sh' for now), and optionally an overlay directory file-structure (call it apkovl).
07:20 <TemptorSent> It may also be logical to set up a directory structure for profiles in a similar fashion to make it easier to mix-and-match as appropriate.
07:23 <TemptorSent> Making things such as xtables-addons, dahdi, snmp, vpn into features and simplifying the actual profiles to a couple of packages and a list of features.
07:25 <TemptorSent> Allowing the easy creation of meta-features like all-fs or voip-server
07:27 <TemptorSent> It might be good to consider how to best handle packages that should be installed and auto-started vs those that should be installed, but not configured, or available on media but not installed.
07:31 <TemptorSent> Would you have ncopa give me a ping please?
07:33 <fabled> i'll mention this to him. he usually wakes up around this time, or a bit later. he might be here soonish.
07:33 <TemptorSent> Ahh, okay - I'm in California (PST8PDT)
07:34 <TemptorSent> Wish I would have known that before, I was burning the midnight oil and up anyway the past couple nights.
07:41 <TemptorSent> So if I need to have the packages spl-$kernelflavor, zfs-$kernelflavor, and zfs installed before pivot, where do I specify them? All in kernel_addons?
07:47 <TemptorSent> Hmm, no.. kernel_addons in base seems to handle the $kernelflavor
07:52 <TemptorSent> Hmm, it doesnt' currenly appear possible to pass additional packages through section_kernels, which seems like a significant problem.
07:54 <TemptorSent> Am I missing something there? Wouldn't that break anything that requires packages other than the module package to function?
07:54 <TemptorSent> zfs for instance?
07:56 s4nni joined
08:03 t0mmy joined
08:07 royger joined
08:13 tty`__ joined
08:22 stwa joined
08:37 <ncopa> hi
08:50 <Kruge> howdy
08:52 fekepp joined
08:56 fekepp1 joined
08:58 <TemptorSent> Good morning ncopa
09:02 <TemptorSent> I was talking with fabled earlier about some modifications to the iso/img build system.
09:03 <ncopa> ok?
09:04 <TemptorSent> I spent a couple days hacking the old alpine-iso package into usable shape and added a "features" feature before finding out from fabled that alpine-iso has been depreciated in favor of the new scrips.
09:05 <TemptorSent> What I'm looking to do is set the profiles to use sets of featurs for the majority of configuration, with application-specific configuration done at the profile level.
09:06 <TemptorSent> In the old alpine-iso system, I currently have features for zfs, kvm-host, iscsi, nfs, samba, and xen setup.
09:07 t0mmy joined
09:08 <TemptorSent> It handles both the packages (modloop, initfs, world, repo) as well as a feature-overlay to auto-start services, install base configs, etc. on a feature-by-feature basis.
09:09 <TemptorSent> Looking at the new abuild/scripts system, it should be very easy to adapt, but for best effect, will require some modifications to the existing scripts and possibly refactoring the profiles.
09:09 <TemptorSent> And some related changes for mkinitfs.
09:13 <TemptorSent> Essentially, each feature lives in its own subdirectory of a 'features' directory and contains a configuration script (feature-$feature.sh) and an optional apkovl directory structure (or tar/cpio archive).
09:16 <TemptorSent> Each feature configures a list of packages to include in the image (modules/initfs/world/local-repo), and optionally initfs features, boot modules, kernel-command-line options, and so forth using hooks.
09:17 <ncopa> ok
09:17 <ncopa> sounds good to me
09:18 <TemptorSent> Profiles could optionally be moved into their own directory structure as well, and the majority of the packages would be included through features rather than individually.
09:19 <TemptorSent> The first question I ran into is it currently possible to add a package to the initrd available before boot other than a kernel module?
09:20 <TemptorSent> It appeared the existing pathway through the sections_kernel is a dead-end for including packages to be used by update-kernel.
09:20 <TemptorSent> for instance zfs needs zfs-$kf, spl-$kf, and zfs.
09:21 <TemptorSent> but passing them using kerenel_addons appends the kernel flavor.
09:22 <TemptorSent> Would it make sense to have separate configuration directivces for modules and initfs packages?
09:22 <TemptorSent> And how attached are you to the existing naming?
09:24 <TemptorSent> The change to mkinitfs would be to allow a file specifying packages needed by each initfs feature, allowing discovery and/or autoinstallation
09:25 <TemptorSent> Also, the option to include a hook script may be desirable in mkinitfs as well.
09:25 <TemptorSent> If this generally makes sense and you don't see any red flags, I'll start poking at it tomorrow.
09:26 <TemptorSent> Time for me to get some sleep soon - my eyes are loosing focus.
09:36 <ncopa> sounds good to me
09:36 <ncopa> i think hooks would be nice in initramfs
09:36 <ncopa> you cannot add a "package" to initramfs, but you can add files
09:37 <ncopa> there is a script that will pull in the shared objects for binaries as well
09:37 <TemptorSent> Alright great, I'll take a deeper look and start tweaking with it in the morning.
09:37 <TemptorSent> A first cut should be pretty easy.
09:38 <TemptorSent> ldd each dep from files, right?
09:58 <skarnet> <ncopa>i think hooks would be nice in initramfs
09:58 <skarnet> PLEASE GOD NO
09:59 <skarnet> whenever you add a line of code to initramfs, a kitten dies
09:59 <skarnet> think of the kittens
10:00 <TemptorSent> I think we're talking mkinitfs for running the hooks, not the ram-disc
10:03 <skarnet> oh, so compile-time hooks? yeah, that's more reasonable
10:04 <skarnet> but that's still complexity that can very quickly get out of hand
10:05 <TemptorSent> skarnet: I think it would actually help reduce overall complexity and improve maintainabiliy because everything needed for each feature can be encapsulated in one place.
10:05 <skarnet> the devil, as usual, is in the details
10:05 <TemptorSent> Of course :)
10:06 <skarnet> abstractions are good... as long as they don't leak
10:06 <TemptorSent> But for instance setting up ZFS very easy with a simple hook.
10:07 <skarnet> "ZFS very easy" -> syntax error
10:07 <TemptorSent> *lol*
10:08 <TemptorSent> ZFS is much easier than trying to constantly juggle and reallocate space.
10:11 vakartel joined
10:13 <TemptorSent> Essentially, the only thing ending up in the initramfs are the actual files specified by the feature, their deps, and any direct additions or alterations by the hooks at build time.
10:14 <ncopa> TemptorSent: i have actually thinking of a rewrite of initramfs where most things are implemented as plugins
10:14 vakartel1 joined
10:14 <TemptorSent> For instance, modifying the kernel command line, adding a config file, or creating directories/links/devices.
10:14 <TemptorSent> ncopa: That would fit in nicely with the rest.
10:15 <TemptorSent> Doing so should be straight-forward and make the code much cleaner.
10:15 <ncopa> i also thought about using something like initramfs from debian, which as support for plugins
10:16 <TemptorSent> Too heavy IMHO
10:16 <ncopa> ok
10:16 tty` joined
10:16 <TemptorSent> The ability to keep it simple and easily adapted by anyone who needs somethign different is important.
10:17 <ncopa> yup
10:17 <pickfire> ncopa: What about dracut?
10:18 <ncopa> pickfire: its implemented in bash, which means you need bash to be able to upgrade a kernel
10:18 <ncopa> and it relies on udev
10:18 <pickfire> Oh, no. That happens to arch as well.
10:19 <ncopa> dracut is not an option due to that
10:19 <TemptorSent> Agreed, udev is fine when you need it, but a royal pain when you don't
10:19 <pickfire> ncopa: So now you are not using udev?
10:19 <ncopa> you can opt-in udev if you want
10:19 <ncopa> but its not a requirement
10:19 <ncopa> and, no we dont use it in initramfs
10:19 <TemptorSent> udev at the pre-pivot stage is rather heavy if you're just running a VM :)
10:20 <pickfire> I tried removing udev from rc-update and use mdev instead, xorg hangs
10:20 <ncopa> xorg needs udev for hotplug
10:20 <pickfire> No wonder setup-xorg-base require udev.
10:21 <ncopa> in theory you can run xorg without udev, but then you cannot hotplug keyboards and mouse
10:21 <TemptorSent> I'm having fun right now trying to setup someethign to build a single disc with a VM/Storage host, several service VMs, and a workstation VM over the top.
10:22 <TemptorSent> So in two of those, udev makes sense, but in the service VMs, they'll have fixed resources anyway and even mdev is almost overkill :)
10:23 <pickfire> ncopa: There is https://github.com/slashbeast/mdev-like-a-boss
10:24 <TemptorSent> Theoretically, nearly all of the commonly-used udev functionality can live in mdev.
10:24 <skarnet> the main issue is libudev
10:24 <skarnet> and the clients that use it, i.e. everything fdo
10:24 <TemptorSent> exactly.
10:25 <skarnet> in other words, fdo is a royal pita. Who would have thunk?
10:26 <pickfire> TemptorSent: How long does it normally takes for a aport in mailing lists to get merged into upstream?
10:28 <TemptorSent> pickfire: No idea whatsoever -- I'm new to Alpine. My main distro is funtoo, gentoo before drobins split, debian before that, and all the way back to Slackware on CD from Walnut Creek :)
10:29 <pickfire> TemptorSent: Ah, I am new to Alpine as well. Back then I was using Arch (for quite some time), I have tried Void before switching to Alpine.
10:29 tty` joined
10:30 <TemptorSent> Alpine hits a much needed niche for fast-deployment (binaries), small size, and essentially universal functionality.
10:31 <TemptorSent> Oh, and actually reasonably up-to-date or bleeding-edge, not stale.
10:31 skarnet joined
10:32 <TemptorSent> There's nothing worse than booting into a live environment and having the downloads required to update just as big as the original image file!
10:37 <TemptorSent> Being able to give someone a file that's possibly less than 100 megs and having that boot and run everything needed to support the application running on remote storage is huge, even better, I can quickly turn the minimal system into a full-fledged environment without things breaking.
10:40 <TemptorSent> Anyway, I need to kick off and get some sleep.
10:40 <TemptorSent> Goodnight (er, morning) all, and thanks!
10:42 ppisati joined
11:05 LongyanG joined
11:24 stwa joined
11:59 leitao joined
12:17 farosas joined
12:38 mitchty joined
13:12 blueness joined
13:15 farosas joined
13:17 NightKhaos joined
13:37 lucybun joined
15:11 <pavlix> ncopa: FYI https://github.com/docker/docker/issues/22853#issuecomment-281696430
15:38 <skarnet> FWIW, +1 to what pavlix said. rewriting resolv.conf is a terrible idea, and it should be vm-specific so no bind mount.
15:50 tmh1999 joined
16:32 royger joined
17:18 mikeee_ joined
17:34 geza6324 joined
17:37 <geza6324> Hi, trying to build a crosscompiler tool chain targeting RPi gen1. Found aports and bootstrap.sh script, but what target triple to use as arg for bootstrap ?
18:00 mikeee_ joined
18:09 geza6324 joined
18:13 t0mmy joined
18:22 czart_ joined
18:33 circ-user-q9jTH joined
18:40 <circ-user-q9jTH> test
18:44 <^7heo> ahah bahnhof.se
18:44 <^7heo> nice
18:45 geza6324 left
18:46 <geza6324> ;)
18:46 <geza6324> was thinking the webclient wasnt working
18:47 <geza6324> but perhaps this is the level of activity to expect
18:48 <geza6324> anyone succesfully managed to use the bootstrap script to build a cross compiler ?
19:14 cyteen joined
19:17 blueness joined
19:23 tty` joined
19:29 leitao joined
19:34 stwa joined
20:52 s4nni joined
21:01 vakartel joined
21:16 <mikeee_> FYI: http://mail.openjdk.java.net/pipermail/announce/2017-February/000221.html
21:19 <asie> i'm curious now - OpenJDK already runs on musl/Alpine, no?
21:21 <Shiz> asie: Alpine uses IcedTea
21:22 <Shiz> i think it's not the same
21:22 <mikeee_> IcedTea is based on OpenJDK
21:22 <mikeee_> but the "upstream" OpenJDK does not have all the patches in place
21:22 <asie> ah
21:22 <mikeee_> the goal of this project is to have OpenJDK "proper" support musl
21:22 <Shiz> :)
21:22 <mikeee_> (and Alpine)
21:23 <Shiz> may be redundant to say, but http://git.alpinelinux.org/cgit/aports/tree/community/openjdk8
21:23 <Shiz> is a good base to look at for patches
21:23 <Shiz> ;p
21:23 royger joined
21:23 <mikeee_> thx :)
21:23 <clandmeter> like the discussion we had at fosdem
21:24 <clandmeter> mikeee_ are you part of that project?
21:24 <Shiz> (i had assumed so by their vaguely resembling name and @*.oracle.com host)
21:24 <mikeee_> I'm the one who proposed it (so yes)
21:25 <clandmeter> nice
21:26 <Shiz> random question by someone who is mostly unfamiliar with the JDK infrastructure:
21:27 <Shiz> how does OpenJDK relate to the JDK oracle releases on their site?
21:27 <Shiz> (mostly asking because of the prospect of Oracle releasing static musl builds on their site if they were heavily intertwined :p)
21:27 <mikeee_> the OracleJDK is to 99.(some amount of 9's)% based on OpenJDK
21:27 <clandmeter> any plans to make an oracle musl release?
21:28 <Shiz> that's cool
21:28 <Shiz> glad that project is being undertaken then, good luck with it :)
21:28 <mikeee_> this project is for getting the necessary source code changes in place in OpenJDK
21:29 <clandmeter> i know there have been questions from the docker community for Oracle support.
21:29 <Shiz> one word of advice: the 'proper' way to fix stuff for musl is by testing for functionality, not identity
21:29 <Shiz> that's explicitly why there is no __musl__ or equivalent macro
21:29 <mikeee_> yup, I've noticed that :)
21:29 <Shiz> i also happen to agree with that mindset, but it sometimes confuses peole :p
21:30 <Shiz> adding a check for 'musl <1.1.2' is easier than 'check if function X is broken', i guess
21:30 <Shiz> or 'api Y missing'
21:30 <mikeee_> I've only found a single case (related to library loading) where it would be convenient to have a __MUSL__ define or whatever
21:30 <mikeee_> most of the changes are just cleaning up the code
21:30 <Shiz> :)
21:30 <mikeee_> making more portable
21:31 <kaniini> if it is related to RTLD_LAZY, musl 1.2 should have improvements that are sufficient for JNI
21:31 <mikeee_> add an 'it' to the above sentence where it makes sense
21:31 <Shiz> i'm sure the folks at #musl or here would be happy to help you figure out a proper approach if you're having trouble with that one
21:32 <mikeee_> I've talked to them a bit about it, and IIUC it's one of those cases where posix doesn't specify the behavior so it's up for discussion how things should be handled
21:32 <mikeee_> they (the #musl guys) have been very accommodating though
21:32 <mikeee_> and helpful
21:33 <kaniini> right, we are pushing for improvements that should be helpful for java
21:33 <Shiz> right
21:33 <mikeee_> in short, the issue in question is how the dynamic loader decides whether an already loaded library is a candidate for fulfilling an (implicity) library dependency
21:33 <mikeee_> and specifically how much of the path is used for the string comparison
21:34 <mikeee_> the file name only vs. the whole path
21:34 <Shiz> right
21:34 <kaniini> (the improvements are mostly related to making X work when people ignore the config we install, but would fix the java issue too)
21:35 <kaniini> oh, that one. humm
21:35 <mikeee_> I could go either way on it personally. we (the java launcher) seems to be relying on undefined behavior
21:38 <mikeee_> apart from a bug in musl I already reported, the library loading behavioral difference is the only "hairy" issues I've run into so far, so all in all I'm pretty happy about it all :)
21:39 <Shiz> :)
21:40 <Shiz> is that bug on the ML?
21:40 StarWarsFan|afk joined
21:41 <mikeee_> I submitted a patch and dalias already merged it - w8
21:41 <mikeee_> http://git.musl-libc.org/cgit/musl/commit/?id=27b3fd68f67b674440d21ea7ca5cf918d2e1559f
21:42 <Shiz> ah gotcha
21:42 <Shiz> nice
21:42 <mikeee_> it's a corner case of library loading failing
21:51 <* andypost> notes https://github.com/php/php-src/commit/513582814b0ca82d81eb6b98897d745e0f0eebf5 breaks lastest php7 on 3.17 kernels
22:18 mikeee_ joined
22:26 minimalism joined
22:56 blueness joined
23:01 blueness joined
23:13 minimalism joined
23:23 royger joined
23:28 tmh1999 joined
23:51 tmh1999 joined