<    April 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
00:24 <jirutka> kaniini: are you here?
00:30 <kaniini> jirutka: yes and no
00:30 <jirutka> kaniini: huh, like Schrödinger’s cat? :P
00:31 <kaniini> jirutka: if you need a rebuild or such i can set it up in about 2 hours, presently driving (stopped to take a break)
00:31 <jirutka> kaniini: nn, just wanna ask, is it possible to use clang with different version of llvm? like clang 4.0 and llvm 3.9
00:32 <jirutka> kaniini: cause currently we have just one clang pkg…
00:34 <mitchty> from what i've seen from llvm ir and stuff like ghc, i'd be surprised if that worked :)
00:35 <mitchty> it was interesting seeing how much ir can change incompatibly in one version
00:36 <mitchty> also no rush on it but curious if the changes i made for idris make it ok...ish https://github.com/alpinelinux/aports/pull/684
00:37 <Shiz> jirutka: id very much doubt it
00:39 <TemptorSent> Okay, is there anything other than the skel passwd/group/fstab and initramfs-init that come from anywhere other than directly from apks needed in the userland of the initfs?
00:45 <kaniini> jirutka i don't think so
01:11 <jirutka> kaniini: about rebuild, could you please build and verify clang 4 on armhf and aarch64 then? https://github.com/alpinelinux/aports/pull/1261
01:14 s33se_ joined
01:25 <jirutka> kaniini: also please take a look at https://github.com/alpinelinux/aports/pull/1273 :)
01:34 LouisA joined
01:53 tmh1999 joined
01:54 blueness joined
02:26 <xentec> uh.. building cross compiling tools is broken on edge. for having such a nice distribution for embedded devices, you're making it sometimes really painful to work with. :(
02:28 <xentec> in abuild, after fakeroot was set, including functions.sh results in termination. more specifically after CBUILDROOT (functions.sh:123) was set
02:30 <TemptorSent> xentec: I'm not currently messing with abuild, but I have a pretty good solution for fakeroot included in my work on mkimage/mkinitfs/etc.
02:32 <TemptorSent> xentec - take a look at utils/utils-fkrt.sh under https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage/
02:32 <TemptorSent> You can source it and use it from your interactive shell if you need to even!
02:35 <TemptorSent> jirutka: Nearly ready to split, need to confirm everything has an appropriate home and finalize filenames.
02:35 <xentec> thanks, but thats overkill in this case. functions.sh:123 fails, because it is the last instruction in readconfig() and the condition check triggers set -e to terminate
02:36 <TemptorSent> I could *REALLY* use some additional eyeballs on the code and some testing of the various base functionality before we go live with it.
02:36 <TemptorSent> xentec: Ahh, a victim of the great 'set -e' :)
02:37 <xentec> appending a simple || true fixes it
02:37 <TemptorSent> Yeah, those are easy ones :)
02:38 <TemptorSent> The messy ones are where you have multiple fakeroot invocations, which usually breaks horribly.
02:40 <xentec> considering "additional eyeballs" I'd be already happy if binutils and gcc would be tested for cross compilation
02:40 <TemptorSent> The other outstanding question is how do we want to handle non-apk sourced files to be included in the initfs.
02:40 <TemptorSent> xentec: Yeah, I've run into a few gotchas on cross-building that I'm trying to get fixed in apk.
02:40 <xentec> apkovl?
02:41 <TemptorSent> No... I'm working on replacements for mkinitfs and update-kernel.
02:42 <TemptorSent> So artifacts to be built into an initfs (userland) which don't come directly from apks.
02:42 <xentec> I know. If by "non-apk" you mean configs in /etc or some other files, you could use the apkovl format
02:42 <TemptorSent> Thus far, the only ones I'm aware of are the contents of /usr/share/mkinitfs
02:43 <TemptorSent> Nope, it doesn't work that way -- the initfs is a set of gziped cpio archives.
02:43 <TemptorSent> The apkovl gets extracted by the initscript which is included in the initfs.
02:45 <Shiz> xentec: whoops
02:45 <Shiz> lol
02:45 <TemptorSent> I have lots of tools for building apkovls too though :)
02:45 <xentec> Isn't lbu not good enough? ;)
02:46 <TemptorSent> xentec: Not really great for automation purposes.
02:46 <TemptorSent> mkimage can build overlays with baked-in ssh keys, preloaed data, etc.
02:47 <TemptorSent> xentec: So you can build one-off images with the exact config required for each one with a few lines.
02:49 <TemptorSent> And I just got through making it downright easy to build custom modloops, initfs module subsets, and initfs userspace file subsets.
02:51 <TemptorSent> Shiz: Any thoughts on handling non-apk managed files in mkinitfs? Directory structure in /usr/share/mkalpine/initfs perhaps?
02:51 <Shiz> none
02:52 <TemptorSent> Hmm... where's fabled or ncopa when you need them? :P
02:55 <TemptorSent> xentec: What systems are you building for?
02:55 <xentec> armhf
02:56 <xentec> https://github.com/alpinelinux/abuild/pull/16 kaniini or fabled: would you take a look?
02:56 <TemptorSent> Bootloader?
02:56 <xentec> more specifally rpi3
02:57 <TemptorSent> Ahh, gotcha - yeah, have that theoretically suppored in mkimage already, and have plans for a few specific projects based on the rpi3.
02:57 <TemptorSent> Are you using any of the GPU accelerated code?
02:58 <xentec> not really, it's more for work using rpi3 as a base for our IoT project
02:59 <xentec> well rpi3 and alpine :)
02:59 <TemptorSent> *shakes head* the IoT is taking over the world, mostly in a bad way :(
03:00 <xentec> I know, that's why I'm working extra hard not to fuck it up
03:00 <TemptorSent> I really don't need my vodka bottles running wifi hotspots, thank you!
03:00 <TemptorSent> (Yes, seriously)
03:28 <xentec> TemptorSent: I've looked over your mkimage overhaul. Imo it looks like overkill but I look forward to use it :D
03:32 <TemptorSent> Oops, I need to set my flags to keep track of which channel again. Haven't taken the time to configure bx the way I like it and can't find my old config.
03:32 <TemptorSent> xentec: Which part was looking overkill to you?
03:33 <xentec> everything. Or maybe I'm just underestimating the complexity of such an endeavor
03:36 <TemptorSent> xentec: It handles everything required to build images, including the mkinitfs tool, the update-kernel tool, a kernel staging tool, an apkroot staging tool, support for configuring and setting up various bootloaders, building the output images, and building apkoverlays.
03:37 <TemptorSent> Since it requires the functionality of system tools to work, and the existing tools (mkinitfs, update-kernel) were broken, this is replacing the mkinitfs package as well as the old mkimage package and moving to a top level repo 'mkalpine'
03:38 <xentec> Did you also rewrote initramfs-init?
03:39 <xentec> s/Did/Have/
03:39 <TemptorSent> It also contains a replacement 'fkrt' wrapper for faked instead of the fakeroot tool, a number of basic utilities for scripts, and a lot more sanity checking :)
03:40 <TemptorSent> Yes, although that is pending and not likely to be in 3.6.0
03:41 <TemptorSent> I can support reasonably secure boot (if you can secure your kernel) and verification of integrity in the initfs, although the existing apk implementation needs fixing to work well.
03:43 <TemptorSent> A couple of packaging changes would be very helpful, as probably 30%+ of the code in there is working around apk bugs or deficiencies.
03:44 <TemptorSent> Manifests, indexes, and deptrees by checksum are the most important, as right now it can take entirely too long to build the manifest and deptree for the kernel modules.
03:45 <xentec> It would be awesome, if you could establish some central shell framework for abuild/alpine-sdk and alpine-conf.
03:45 <TemptorSent> And extracting pax headers from the raw tarstream from uncompressing the .apk for the sha1sums using awk is painful.
03:45 <TemptorSent> Yeah, that's what I'm working towards.
03:47 <TemptorSent> The utils could use some cleaning up still, but they are very useful for common tasks ( mkdir_is_writable being one I use all the time to do both the mkdir -p and the test for dir rwx)
03:50 <TemptorSent> The list utils are currently slow, but quite useful. Some optimizaion is needed there, as well as support for unsorted lists and ordered lists in addition to the current sorted lists. I also plan a general stack utility and a fifo utility, but I'll get to those as needed.
03:52 <TemptorSent> apkroottool supports building an apkroot for an arbitrary arch, setting up it's repo/keys, and running arbitrary apk commands or general commands in that root, all under fkrt with stored state.
03:53 <TemptorSent> Then dumping a subset (with all deps) based on a set of globs directly to a cpio archive (optionally compressed).
03:54 <xentec> with various compression formats?
03:54 <TemptorSent> And mkinitfs now has modular configuration files (which will be gaining further functionality soon), so you can include various features sanely.
03:55 <TemptorSent> Currently gzip -9 is implemented there, but I have the logic for doing everything the kernel supports already done :)
03:56 <TemptorSent> I'm trying to refactor out as much of the old code and logic as I can so we have a set of individually useful tools and a bit of glue.
03:57 <TemptorSent> multitool and the plugin loader will eventually handle everything, with the last of mkinitfs and mkimage turning into tools so we can parse the common options in one place.
03:58 <xentec> would rename from mkimage to buildbox :D
03:58 <TemptorSent> I'm just trying to track down any important corner cases before I do the re-overhaul of mkinitfs (I already rewrote it once :)
03:58 <TemptorSent> actually, mkalpine.
03:59 <xentec> fine too
03:59 <TemptorSent> It will be the basis of the installer as well.
04:00 <xentec> So I guess this will be the base for alpine 4.0?
04:00 <TemptorSent> And once I get done with the refactoring, the various tools will be able to be installed independently and autoload their deps.
04:00 <TemptorSent> 3.6 hopefully, at least in part.
04:02 <TemptorSent> I just need to firm up filenaming/directories/formats with ncopa and fabled, finish cutting over to the new staging tools, and axe the old code. The repo split is ready to happen any day now, with nlplug-findfs becoming it's own package.
04:03 <TemptorSent> But what is really needed is testing of the various functions that follow EXISTING functionality to make sure it's not breaking things.
04:04 <TemptorSent> There are a couple whole classes of cases I haven't even touched yet because I haven't experimented with them on runnign hardware yet.
04:04 <TemptorSent> Such as boot on arm :)
04:05 <TemptorSent> If I had a good document explaining where, say, rpi1 vs rpi2 vs rpi3 find their various artifacts, I could close that out.
04:05 <TemptorSent> *wink*
04:07 <TemptorSent> The other thing I know is broken is reverse detection of arch from kernel .config files, which needs to be fixed to make custom-build kernel directories reliable.
04:07 <TemptorSent> Basically, I need a matrix of header + config opts for each arch .config
04:08 <TemptorSent> Because x86_64 is indicated as 'x86' in the .config files, and I need to parse for BITS to find out if I'm 32 or 64 (or x32!?).
04:11 <TemptorSent> xentec: Does your boot config look essentially standard or do you use a custom boot setup.
04:26 <xentec> right now I use the more or less standard "run-in-ram" variant, but my plan is to use a custom design. An immutable squashfs-root with overlaytmpfs and and apkovl+apk upgrade on top of it
04:27 <xentec> >TemptorSent: If I had a good document explaining where, say, rpi1 vs rpi2 vs rpi3 find their various artifacts, I could close that out.
04:28 <xentec> all rpis with arm32 use bootcode.bin,start.elf,fixup.dat
04:29 <xentec> or start_cd.elf+fixup_cd.dat if gpu_mem=16 has been set in config.txt
04:29 <xentec> rpi3 with aarch64 uses uboot afaik
04:31 <xentec> there are funny bits here and there. e.g. rpi3 not always finding its firmware if boot partition has a label in it
04:37 <TemptorSent> I see some funny existing code putting things in different places on different pi
04:37 <xentec> in current mkimage?
04:38 <TemptorSent> in existing update-kernel IIRC.
04:39 <xentec> ah yes, I forgot about device trees
04:39 <TemptorSent> Take a look at the bottom of /sbin/update-kernel... it's confusing what exactly the intent is there.
04:40 <TemptorSent> What's the differnce between MEDIA and non-MEDIA on a rpi anyway?
04:40 <xentec> I've been rewriting it for my goals, so I pretty much know that you mean.
04:41 <TemptorSent> Oh, what are you trying to get it to do?
04:41 <xentec> my custom boot
04:41 <xentec> also only installing overlays I've specified in config.txt
04:42 <TemptorSent> Right, what do you need for that? I'd be surprised if mkimage and friends can't already do most of that, including the bootloader config.
04:43 <xentec> ah and since I'm compiling my own kernel with some firmware blobs included, I needed to purge the linux-firmware parts in it
04:43 <xentec> TemptorSent> What's the differnce between MEDIA and non-MEDIA on a rpi anyway?
04:43 <TemptorSent> Right, no assumption on firmware, and multiple custom build directories are coded and supported, given a bit of testing and tweaking.
04:43 <xentec> good question. rpi only looks in /boot for device trees
04:44 <TemptorSent> Got it. That's where we'll install them then :)
04:45 <TemptorSent> I need to flesh out some device support in addition to the arch support for strangeness like that.
04:46 <TemptorSent> But it's staged in such a manner you can grab what you need and copy it into place easily.
04:47 <xentec> you should a an optional filter for device tree overlays that parses config.txt. something like http://npaste.de/p/JN/
04:47 <TemptorSent> What sort of format are the custom firmware blobs coming in? I still have generic directory/tarball support.
04:47 <TemptorSent> Sounds good!
04:49 <TemptorSent> No problem.
04:49 <xentec> http://npaste.de/p/6fLW/ corrected a path*
04:51 <xentec> however the device trees themselves are a bit trickier to filter
04:51 <xentec> http://npaste.de/p/6k/ this is the full list
04:52 <xentec> if all are present in /boot, rpi will select a fitting one. if I can't find one, boot will simply fail
04:52 <xentec> If it*
04:54 <TemptorSent> Ahh, okay - and they get rendered to .dtbo?
04:55 <xentec> no, the dtbos (the overlays) are layered on them
04:55 <xentec> (dtbo and dtbo are both binary)
04:55 <xentec> dtb and dtbo* damn it
04:57 <TemptorSent> Okay, so ideally we want to figure out both deps and install only those?
04:58 <TemptorSent> How large are the dtbs?
04:59 <xentec> yes, *ideally*. but for a standard image you'd want to put all of them in there so it always boots
04:59 <xentec> they are not large. biggest is 15.2 KiB
04:59 <TemptorSent> Methinks we'll end up wanting a rpitool at some point because it has so very many oddities.
04:59 <xentec> smallest 8.8 KiB
05:00 <TemptorSent> Okay, nothing I'm going to cry over on a sd card, and not even ugly over a slow radio modem, I can live with installign all of them :)
05:00 <xentec> all together with overlays sum up to 740 KiB
05:01 <xentec> correction: 347 KiB
05:01 <TemptorSent> We can filter as needed where needed, but not something that's going to be an issue on a standard image.
05:07 <TemptorSent> I scratched the filter into my working dir for when I add the devices directory to the tree.
05:08 fabled_ joined
05:08 <TemptorSent> The kerneltool-kbuild.sh tool is pretty flexible in terms of what it supports for targets and config opts, let me know how far that is from meeting your needs.
05:08 <TemptorSent> Hello fabled_?
05:11 asonge joined
05:57 vakartel joined
06:18 <kaniini> xentec: it looks okay to me. i will integrate it in a bit
06:19 <xentec> thanks!
06:21 BitL0G1c joined
06:33 t0mmy joined
07:05 tmh1999 joined
07:59 royger joined
08:01 blueness joined
08:27 fekepp joined
08:30 xming joined
08:30 xming joined
08:47 minimalism joined
09:13 blueness joined
09:22 t0mmy joined
09:42 blueness joined
09:53 <tmh1999> Hum, looks like sourceforge screwed up pyxml package
09:54 <clandmeter> unfortunately its not the only thing they screwed up...
10:35 blueness joined
10:44 czart_ joined
10:51 minimalism joined
11:00 <^7heo> So yeah, the xterm in community now has sixel support
11:00 <^7heo> \o/
11:00 <algitbot> \o/
11:00 <^7heo> I wonder if someone can display sixels on IRC.
11:00 <^7heo> technically it should be possible...
11:02 <^7heo> I guess not, since ansi colors cannot be sent over IRC.
11:04 blueness joined
11:30 blueness joined
11:45 <skarnet> Why do you say that.
11:46 <^7heo> skarnet: #define that
11:46 <^7heo> (I'm unsure as to what to answer)
11:48 <skarnet> sending ansi colours over IRC looks doable to me
11:48 <skarnet> (I said nothing about desirability)
11:48 <^7heo> Well, IRC has its own serializing for colors, does it not?
11:49 <skarnet> yes it does, but afaik it's 16-color ansi encoding
11:49 <^7heo> as in, it is the job of the irc client to convert those colors in a way that the terminal/window can display.
11:49 <skarnet> it's not rgb or anything :P
11:49 <^7heo> well they have 256 color support I think
11:49 <^7heo> s/they have/it has/
11:49 <skarnet> maybe
11:49 <^7heo> But yeah, however
11:49 <skarnet> anyway I like a medium that focuses on content
11:49 <skarnet> not on pretty colours
11:50 <^7heo> It doesn't have the support for other ANSI codes than color, I think.
11:50 <^7heo> I mean, arbitrary ANSI codes.
11:50 <^7heo> for example, the clear screen is a feature of the client.
11:50 <^7heo> you can't clear the screen of the people remotely ;)
11:50 <skarnet> arbitrary ansi codes? what could possibly go wrong
11:50 <^7heo> hahah ;)
11:50 <^7heo> Right.
11:50 <^7heo> But Sixel is using ansi codes.
11:50 <^7heo> and so does ReGIS.
11:51 <^7heo> and using Sixel/ReGIS support would allow for graphics IN irc.
11:51 <skarnet> I strongly suspect those words refer to something graphical I'm happy not to care about
11:52 <^7heo> That might be true.
11:52 <^7heo> But on the other hand, I struggle to get people to adopt irc because of the lack of graphical support.
11:52 <skarnet> I'm also quite certain I do NOT want graphics in IRC
11:52 <^7heo> of course, like with colors, there must be a channel mode to refuse graphics.
11:53 <skarnet> those people can use fancy-IM-app-of-the-month for their special needs
11:53 <^7heo> But refusing the support of something others might need/want just because you don't want it is the wrong behavior.
11:53 <^7heo> Not caring about it is fine.
11:53 <skarnet> that's not what I'm doing
11:53 <^7heo> yeah ;)
11:53 <skarnet> I'm saying IRC is the wrong protocol for this
11:53 <^7heo> I'm not sure.
11:54 <^7heo> Afterall, it's all printable characters.
11:54 <skarnet> text
11:54 <^7heo> yeah.
11:54 <skarnet> KISS
11:54 <^7heo> (aside from the control characters in the beginning)
11:54 <^7heo> well yes, KISS.
11:54 <^7heo> Sixel and ReGIS are kiss.
11:54 <skarnet> of course
11:55 <skarnet> tell that to IRC client implementors
11:55 <^7heo> I did, they came up with a concern about spam countermeasures.
11:55 <^7heo> Which is valid.
11:55 <^7heo> But so is copy/pasting a file over IRC.
11:55 <^7heo> so...
11:56 <^7heo> I dunno.
11:56 <^7heo> I feel like it would be worth having that in the protocol.
11:56 <skarnet> it won't surprise you if I tell you I find that feature of IRC is bad engineering
11:56 <^7heo> of course it could be possible to implement that as plugins.
11:56 <^7heo> the counter-spam measures?
11:57 <skarnet> copypasting a file, dummy.
11:57 <^7heo> but it's not a feature of IRC...
11:57 <skarnet> DCC is
11:57 <^7heo> ah DCC is.
11:57 <^7heo> but DCC isn't spam.
11:57 <^7heo> copy/pasting a file in a channel is spam.
11:58 <^7heo> (and that is what I referred to)
11:58 <skarnet> ah, ok, got it now.
11:58 <^7heo> yeah.
11:58 <^7heo> so basically, my point is:
11:58 <^7heo> people who copy/paste files on IRC are ejected by counter-spam measures.
11:58 <^7heo> and so would people copy/pasting sixels on IRC.
11:58 <^7heo> however having the sixel support might help the adoption.
11:59 <skarnet> I disagree
11:59 <^7heo> it could be supported in many other ways than one-to-many (channel) communication.
11:59 <skarnet> call me conservative
11:59 <skarnet> but the people who would adopt IRC because it can have graphixx won't stop there
11:59 <^7heo> I definitely can see bots using ReGIS to display graphs or stuff.
12:00 <skarnet> next thing they'll ask for audio chat or something
12:00 <skarnet> those are not the people who *use* irc
12:00 <^7heo> for monitoring, code tendencies, etc.
12:00 <^7heo> maybe.
12:00 <^7heo> but IRC is gonna die because of this...
12:00 <^7heo> which is sad.
12:00 <skarnet> no
12:01 <^7heo> look at matrix.
12:01 <^7heo> I can't tell if it's just hype or actually adopted enough to weaken IRC.
12:01 <skarnet> it's gonna die because nobody can take the time and energy to design a decent unifying version of the protocol
12:01 <asie> i feel that the only way IRC can differentiate itself is by being conservative
12:01 <skarnet> it's dying from vendor lock-in
12:01 <^7heo> skarnet: maybe yes.
12:01 <skarnet> adding more features won't help that
12:01 <asie> if IRC tries to be another matrix, or discord, it has already lost
12:01 <skarnet> ^
12:02 <^7heo> skarnet: ok you're right.
12:02 <asie> the reason people use IRC in 2017 is precisely because it's not matrix, or discord
12:02 <skarnet> I'm with asie there
12:02 <^7heo> That's true.
12:02 <asie> it's simple, runs on anything and is not dependent of any large commercial entity that needs to monetize to survive
12:02 <^7heo> nah, you're right.
12:03 <asie> the one thing that could happen is unifying nickserv/chanserv/etc. behaviour to not be a hack on top of IRC, but see the xkcd standards comic for how that would end
12:03 <^7heo> But then *someone* would need to take the time and energy to design a decent unifying version of the protocol
12:03 <asie> IRC is 25 years old and writing a client is very simple. therefore, we have very many clients
12:03 <^7heo> before we end up being 3 or 4 per server/channel
12:03 <asie> you won't create a unifying version of the protocol because you won't make everyone agree on it
12:03 <^7heo> a lot of communities have already moved over to gitter/slack
12:03 <asie> it's about 15 years too late for that
12:04 <^7heo> yeah
12:04 <asie> yes, for dev communities it's gitter/slack
12:04 <asie> for gamers it's discord
12:04 <asie> etc, etc
12:04 <^7heo> yeah but what do we do now?
12:04 <^7heo> do we just watch it die?
12:04 <asie> yes, or make something **new**
12:04 <asie> that is not irc
12:04 <asie> can be backwards compatible
12:04 <asie> and should be, even
12:04 <asie> but is fundamentally not called IRC
12:04 <skarnet> what do we do now? I for one will enjoy the sunshine and the scent of the flowers
12:05 <asie> i wouldn't be opposed to the idea of a new protocol-based server with limited IRC backwards compatibility
12:05 <asie> but the moment you break an IRC client is the moment you failed to unify IRC
12:05 <^7heo> skarnet: there's no sunshine and scent of flowers in Germany.
12:05 <^7heo> skarnet: enjoy it where you are.
12:05 <skarnet> look better
12:05 <^7heo> I can't.
12:05 <^7heo> The sky is freaking bright, but white.
12:05 <^7heo> it's like the sky is made of neon lights.
12:05 <skarnet> Take a hike in the country
12:06 <^7heo> yeah I should go to the south.
12:06 <^7heo> to remember how it is to feel alive.
12:06 <^7heo> Anyway, the IRC discussion was borderline -offtopic but the weather-sun-alive discussion definitely is.
12:06 <^7heo> ;)
13:02 fabled joined
13:07 tkharju joined
13:07 sigtrm joined
13:27 sigtrm joined
14:05 t0mmy joined
14:22 <ncopa> https://twitter.com/n_copa/status/855426268111802374
14:23 <ncopa> this is crazy...
14:23 <ncopa> but i wonder if the ppc64le config is a bit smaller than the x86*
14:25 <TemptorSent> Woah!
14:25 <TemptorSent> That's insanity.
14:26 <ncopa> yup... total insane
14:27 <TemptorSent> Massive parallelism works :)
14:27 <ncopa> thats what i wanted to test :)
14:27 <ncopa> now
14:27 <ncopa> add a configure script...
14:27 <ncopa> and guess what happens
14:27 <TemptorSent> Yeah, bottleneck time.
14:29 <TemptorSent> You'd need dispatchers and a workqueue to get any of the efficiencies of scale when building out packages.
14:29 <ncopa> yeah i thought about that today
14:30 <ncopa> thanks to autoconf it is probably better to build multiple packages at the same time with make -j1
14:31 <TemptorSent> Or run a configure round with -j1, then a build round with -j 32 x 8
14:31 <TemptorSent> Keep the cache misses from getting totally out of hand anyway.
14:31 <ncopa> best would be get rid of configure/autoconf
14:33 <TemptorSent> Yeah -- I remember being happy when a package had a configure script and I didn't have to hand-edit the source to run it on linux, but now we've got configure scripts that take longer to run than it does to compile the software they build!
14:33 <ncopa> and is bigger than the application itself
14:33 <ncopa> both source and compiled
14:34 <TemptorSent> Sanely, nearly everything autotools does should be checked once and cached.
14:34 <ncopa> i think that is problematic
14:35 <TemptorSent> Once it knows which functions my libc supports and how to handle the bugs, it doesn't need to rerun the bloody test on EVERY package I install.
14:36 <TemptorSent> We're talking something between 50 and 1000 tests!
14:37 <ncopa> i know gentoo experimented with configure cache
14:37 <ncopa> but i think it was not really recommended
14:37 <ncopa> caused some issues
14:37 <ncopa> i dont remember the details
14:37 <TemptorSent> Mostly, it was because configure was broken IIRC
14:39 <TemptorSent> You had to have autoconf-2.13 or whatever for EVERY package, because minor point releases broke things.
14:39 <ncopa> ah
14:39 <ncopa> that makes sense
14:39 <TemptorSent> And it still took a long time just to scan the cache.
14:40 <TemptorSent> It was just a raw cache, no versioning, checksums, timestamps, etc, so it was easy to break :)
14:42 <TemptorSent> The whole design of the autotools caching mechanism is horribly ugly.
14:43 <TemptorSent> And some config scripts break just because you use a cache because they rely on side-effects of one check to run another.
14:45 <TemptorSent> Or in other words, autotools has outlived its usefulness, especially for building large quantities of simple packages.
14:48 fabled joined
14:49 <TemptorSent> ncopa: Do you have a few minutes to go over boring details, like file naming, installation directories, and the like for the mkalpine toolsuite?
14:50 <ncopa> not really
14:50 <ncopa> do you have a proposal?
14:50 <ncopa> do you want be backwards compat?
14:51 <ncopa> or we drop backwards compat and introduce this as something new
14:51 <ncopa> which replaces the old
14:51 <TemptorSent> I've just thrown in something usable for the moment, but names for manifests, indicies, and deplists is one issue.
14:52 <TemptorSent> For the most part, not much is an issue for backwards compat in that regard.
14:52 <ncopa> ok
14:52 <TemptorSent> It's more forward compat I'm looking at, as well as consistency
14:52 <ncopa> ok
14:53 <TemptorSent> /usr/share/mkalpine for the tools / standard files, /var/cache/mkalpine for staging
14:54 <ncopa> sounds good
14:54 <TemptorSent> /usr/share/mkinitfs can stay or go, depending on preference.
14:54 <ncopa> mkinitfs will be a standalone tool right
14:55 <ncopa> which can be installed separately
14:55 <TemptorSent> What I'm doing currently is dropping the manifest/index/deps in the root of the staging dir.
14:55 <TemptorSent> Actually, mkinitfs becomes a couple calls to kerneltool and a couple calls to apkroottool
14:57 <ncopa> which needs /usr/share/mkalpine?
14:58 <ncopa> if we can have mkinitfs without dependencies in /usr/share/mkalpine, then i think it makes sense with /usr/share/mkinitfs
14:59 <TemptorSent> kerneltool stage latest-$flavor <kernel pkgs> ; kerneltool mkmodcpiogz <kver> <mod globs> ; apkroottool setup <dir> ; apkroottool <dir> apk add --no-scripts <file globs> ; apkroottool subset-cpiogz <dir> <out>
15:01 <TemptorSent> So yes, all of the tool use the common functions in mkalpine. The only thing currently in /usr/share/mkinitfs is a set of skel passwd/group/fstab files and the initramfs-init itself.
15:03 <TemptorSent> Also, since kerneltool can do all of the fetching, we can call it to update the kernel without doing an apk upgrade.
15:04 <TemptorSent> mkinitfs' job becomes just translating the arguments to commands, then doing the final copy of files to their destination.
15:05 <TemptorSent> update-kernel is the same way, all it needs to do is the unmounting/mounting and copying of generated files to their dests.
15:07 <TemptorSent> To build the initfs, mkinitfs will take the two generated cpio.gz from kerneltool and apkroottool, along with a third containing the skel files/init, and cat them together.
15:08 <TemptorSent> So really what I'm after is where do we want to keep the files it includes in that last cpio.gz, which currently live in /usr/share/mkinitfs, and do we need to handle any other external files besides those?
15:09 <TemptorSent> As well as where do we want to install manifests/deps/indicies on the system for what we've actually installed?
15:10 <TemptorSent> Ideally, apk learns to handle the manifests itself and we can get rid of a heaping chunk of the code in mkalpine.
15:11 <TemptorSent> Failing that, I'll probably end up writing a manifest tool in C that can offload most of the slow work.
15:14 <TemptorSent> So nailing down file/field formats for the manifests is a reasonably high priority.
15:15 <TemptorSent> And there are still a few pain points I think I can shave some time off with a refactor of the order of operations before having to go there.
15:19 <TemptorSent> I haven't replumbed the last bits of mkinitfs/update-kernel yet, as I want to make sure I'm missing any major corner cases in their use.
15:19 <TemptorSent> For instance, WTF is with MEDIA vs non MEDIA on rpi?
15:20 <TemptorSent> And generally, is MEDIA supposed to just be used for images, or is that also intended for other uses?
16:16 scadu joined
16:44 al3hex joined
16:59 tmh1999 joined
17:14 <ashb> No armhf builds of mongodb (oddly?) http://pkgs.alpinelinux.org/packages?name=mongodb*&branch=&repo=&arch=&maintainer=
17:17 <ashb> Oh, possibly because mongodb doesn't support 32bit platforms, or non linux
17:22 <tmh1999> clandmeter : could you put pyxml package on dev.a.o or distfiles.a.o for now ?
17:23 <tmh1999> clandmeter : looks like it's already there : http://distfiles.alpinelinux.org/distfiles/PyXML-0.8.4.tar.gz
17:23 <ncopa> i think we shoudl set the DISTFILES_MIRROR in /etc/abuild.conf
17:31 <tmh1999> ncopa : hah never come across DISTFILES_MIRROR before. seems cool. so pr to abuild ?
17:41 <TemptorSent> It would be nice if apk could resolve mirrors when one craps out...
17:49 <ncopa> tmh1999: abuild has support for DISTFILES_MIRROR
17:49 <ncopa> its just a config option
17:49 <ncopa> but we should probably use it for s390x
17:50 <tmh1999> ncopa : yeah I mean make it default on /etc/abuild.conf
17:50 <tmh1999> ok cool
18:13 vakartel joined
18:21 t0mmy joined
18:48 <TemptorSent> ragechin_ : Probably here if it has to do with the build system.
18:55 ragechin_ joined
18:55 <ragechin_> I'm trying to create a custom package for personal use. The end goal is that I have services running on my server and I provide the config files for those services through the custom packages.
18:56 <ragechin_> In my first attempt at this, I'm simply trying to provide a custom /etc/dnsmasq.conf through the 'test-package' package. Well, this happens..
18:56 <TemptorSent> ragechin_: Hmm, I'm not sure a package is the appropriate means of doing that unless the config is static.
18:56 <ragechin_> ERROR: test-package-0.01-r3: trying to overwrite etc/dnsmasq.conf owned by dnsmasq-2.76-r0.
18:56 <ragechin_> TemptorSent: It is in my case.
18:56 <ragechin_> Or close enough to static.
18:56 <TemptorSent> You probably want to use overlays, not packages.
18:57 <ragechin_> I'm trying to discern the best way to go about it from a package perspectivel.
18:57 <TemptorSent> Is this for provisioning new builds?
18:57 <ragechin_> No, not necessarily.
18:58 <ragechin_> The other option I could think of is to roll my own custom version of dnsmasq and include my custom config file in it. I'd prefer to not do that, if it can be avoided.
18:58 MH0815 joined
18:58 <TemptorSent> My suggestion is to either use lbu or create a tarball with the required files in the right places, then apply that as an overlay.
18:59 <ragechin_> Changes to overlays require a reboot, correct?
18:59 <TemptorSent> No, you can just untar them :)
18:59 <ragechin_> Hmmm
18:59 <TemptorSent> So install the new overaly, and untar it to apply.
19:00 <ragechin_> That is an option.
19:00 <TemptorSent> I'm working on tools that handle most of the config stuff.
19:00 <TemptorSent> But right now it's somewhat tied to mkimage.
19:00 <Shiz> must you bring mkalpine into everything
19:00 <Shiz> lbu already just works
19:01 <TemptorSent> lbu isn't great for making a config for distribution from my experiences with it.
19:01 <Shiz> has always worked for me
19:02 <TemptorSent> So how do you package up just a couple of specific files using lbu without taking care to not touch anything else?
19:02 <TemptorSent> My lbu-foo is lacking ;)
19:03 <Shiz> lbu ex /
19:03 <Shiz> lbu in /myfile1
19:03 <Shiz> lbu in /myfile2
19:03 <Shiz> etc
19:04 <TemptorSent> Doesn't that alter the entire state?
19:04 <Shiz> ?
19:05 <Shiz> the entire point of lbu is that it captures the system state...
19:05 <TemptorSent> Say I wanted to send out ragechin_'s "/etc/dnsmasq.conf", is there an lbu command to just extract that file to an overlay?
19:05 <Shiz> sure, # tar -cf toot.apkovl.tar.gz etc/dnsmasq.conf from /
19:05 <TemptorSent> Right, which is not so great when you want to extract portions of it independent of the rest.
19:05 <TemptorSent> ...which is exactly what I suggested :)
19:05 <Shiz> which is not the point of lbu
19:06 <Shiz> the point is to capture the system state
19:06 <Shiz> if you need to pack up individual files, that's what tar is for
19:06 <Shiz> lbu doesn't /need/ to support that use-case
19:06 <TemptorSent> Can it conveniently apply such tarfiles TO the system?
19:07 <TemptorSent> (as in add them to be tracked upon overlaying)
19:08 <Shiz> so you only care about system state when unpacking, but not creating?
19:08 <Shiz> that seems rather silly
19:08 <TemptorSent> Hmm, doesn't look like it, which means you need to manually add it.
19:09 <TemptorSent> Did you read what ragechin_ is trying to accomplish?
19:09 <Shiz> i diid, and they can do it just fine with lbu
19:09 <TemptorSent> He wants something he can distribute and install that will replace /etc/dnsmasq.conf.
19:10 <Shiz> yes, so an apkovl
19:10 <TemptorSent> Not the entire system state.
19:10 <Shiz> he said absolutely nothing about tracking it further after unpacking
19:10 <Shiz> which is also not something they'd get through packages, their initial idea
19:10 <TemptorSent> Then upon reboot, it's gone.
19:11 <Shiz> apkovl= command line parameter exists
19:11 <TemptorSent> package in world = persisted.
19:11 <TemptorSent> Yeah, take a look at how it's implemented.
19:11 <Shiz> i already have
19:11 <TemptorSent> It will pick up the default iff there is ONE apkovl in the root.
19:11 <TemptorSent> Otherwise, it requires explicit modification to the boot config.
19:12 <ragechin_> I'll chime in here - define "packaging"
19:12 <ragechin_> er, "trackign"
19:12 <TemptorSent> So to have it persist, it needs to be applied to the apkovl as well as the running system.
19:12 faffolter joined
19:12 faffolter joined
19:12 <TemptorSent> Persisted across reboots and available for backup by lbu so a restore returns the system to the same state.
19:13 <TemptorSent> Preferably without manual intervention or scripting required.
19:13 <Shiz> but this is not something they mentioned at all
19:13 <Shiz> you're making up use-cases now
19:14 <TemptorSent> Shiz: Go grab a cup of coffee, then read the last page in the backlog.
19:14 <ragechin_> He's actually not.
19:14 <ragechin_> I need a way to distribute custom configuration files, ideally through packages.
19:14 <ragechin_> I don't want chef, puppet, or any of that. I want a repo that I can generate a package from.
19:15 <ragechin_> SSH into $(X) machines, apply updates, restart services as needed, done
19:15 <Shiz> TemptorSent: you can just point me to where i'm wrong instead of condescendingly implying things
19:15 <Shiz> anyway.
19:16 <TemptorSent> I figured you missed it on the first reading, since it was one of the first thing ragechin_ said. The coffee is to make the task more pleasurable :)
19:16 <Shiz> i don't like coffee
19:16 <Shiz> so i doubt it will
19:16 <TemptorSent> (Tea works too, or a nice scotch if that's your preference)
19:16 <Shiz> my point was that there was nothing said about creating a new version from the machines those configs are applied to
19:17 <Shiz> which is part two of what you said
19:17 <Shiz> so it's better to ask them directly
19:17 <Shiz> ragechin_: is that part of your use case :P
19:17 <TemptorSent> The requrest was for a means of creating a package to be distributed to machines that would override an existing configuration file, and presumably ONLY tha configuration file, in a persistnet manner.
19:18 <Shiz> ragechin_: fwiw, i do think packages are a wrong way toapproach this, as packages should never conflict in the files they install
19:19 <Shiz> ragechin_: what if it would work, and say
19:19 <Shiz> dnsmasq gets updated, so you upgrade
19:19 <TemptorSent> Breaking other standard behavior (i.e. not persistign on reboot) compared to a package isn't useful.
19:19 <Shiz> if the package manager would never overwrite config files, you'd keep your old custom config files
19:19 <TemptorSent> That's exactly what I said above.
19:19 <Shiz> but that'd also mean it wouldn't update config files when your custom package updates, which would be presumably the intention
19:20 <Shiz> i think by design packages shouldn't conflict in their files since it creates weird update situations like that
19:20 <TemptorSent> An overlay is the appropriate solution because it's already manged properly by both apk and lbu.
19:21 <TemptorSent> The problem is only in how to apply one to a running system in such a manner that it persists the same way it would if it had been added to the overlay and the machine restarted.
19:21 <ragechin_> fwiw, I don't really care about the system state.
19:21 <Shiz> TemptorSent: i'm not sure if that is what needed at all
19:21 <TemptorSent> So you couldn't tell the differnce between a machine which had it applied live, vs one which it was applied to the overlay and the machine rebooted.
19:21 <ragechin_> The larger goal is that I can take this device, nuke it, do a reinstall of base, then add my custom packages.. and be done
19:21 <Shiz> ragechin_: right
19:22 <Shiz> TemptorSent: mabye i'm understanding you wrong, but
19:22 <TemptorSent> ragechin_: Presumably, you don't want to have to reboot for changes to take effect, and you don't want changes lost upon reboot, correct?
19:22 <Shiz> your implication seems to be that it should also survive local changes made after applying the apk overlay?
19:22 <ragechin_> TemptorSent: Correct.
19:22 <Shiz> and i'm not sure i saw that mentioned anywhere
19:22 <TemptorSent> That's simply normal expected behavior.
19:23 <TemptorSent> Rebooting to install changes is a Windoze thing.
19:23 <ragechin_> The most I want to bounce are local services - and that, too, is expected behavior.
19:23 <Shiz> i'm not talking at all about rebooting though?
19:23 <TemptorSent> So the idea is business as normal, but with added custom overlay for config files.
19:23 <Shiz> so i'll ask again directly :P
19:24 <* ragechin_> grabs popcorn
19:24 <TemptorSent> *lol*
19:24 <Shiz> ragechin_: is it in your use case that local changes not in your custom config system (however you do it, packages or otherwise), survive reboot?
19:24 <Shiz> e.g. say the system installs a custom dnsmasq.conf
19:24 <Shiz> you edit it locally
19:24 <Shiz> you reboot
19:25 <Shiz> should those changes survive or should it be reverted to the custom dnsmasq.conf from before
19:26 <TemptorSent> They should act exactly as they would had you installed a package which installed the same files, if you stored your modifications with lbu, they should be applied presumably. To act otherwise is unexpected behavior.
19:26 <Shiz> i'm expecting them to answer, not you
19:27 <TemptorSent> I'm stating expected behavior from the standpoint of consistency.
19:27 <Shiz> and i'm stating that when i explicitly addressed them to clear a confusion up you shouldn't bump in with assumptions
19:28 <Shiz> :P
19:28 <ragechin_> Shiz, let's say that dnsmasq does an update, and the default dnsmasq.conf is thrown back into /etc/dnsmasq.conf. I would expect the package manager to notice that I've modified the config - in some way - and not blow away my configs.
19:28 <Shiz> ragechin_: right, it already does that
19:28 <ragechin_> Perhaps save the new default config as /etc/dnsmasq.conf.rpm or whatever.
19:28 <ragechin_> Ok.
19:28 <Shiz> it'll save as .apk-new i think
19:28 <ragechin_> FWIW, I won't be editing these configs locally on disk.
19:28 <Shiz> alright
19:28 <ragechin_> Unless it's an emergency
19:28 <TemptorSent> The system behavior must be consistent regardless of the tools used, otherwise things will break if done in different order or on different configs.
19:29 <ragechin_> and honestly - in that case, I'd prefer that my out-of-band changes are *NOT* persistent.
19:29 <Shiz> right
19:29 <ragechin_> So that I can go through and commit my changes to the appropraite development cycle and (...)
19:29 <Shiz> ragechin_: so the fun part of lbu, and this may be a bit subjective cause i'm using it in prod
19:29 <Shiz> (:P)
19:29 <TemptorSent> I'm spending enough time fixing 'special cases' scattered through code as it is.
19:29 <Shiz> that in a lot of cases you don't even need a persistent install at all
19:30 <Shiz> not all cases, of course
19:30 <Shiz> but its funny how much you can get away with, and then you have a system completely bootstrapping itself on every boot and applying lbu changes
19:30 <ragechin_> A workaround, I guess, would be an overlay thrown into a package and have it untarr'd?
19:30 <TemptorSent> By persist, it need not be resident, mearly stored in a manner that restores to the same state.
19:31 <ragechin_> Shiz: that's fair, are you fetching the overlays from external, or do they reside on disk?
19:31 <Shiz> externally
19:31 <TemptorSent> ragechin_: That might be a sane option for now, although I'm lobbying to get apkovl handling in apk itself improved for such needs.
19:31 <Shiz> ragechin_: the initramfs allows fetching apkovls over http
19:32 <Shiz> and when you put packages in /etc/apk/world that's stored into the apkovl, it'll automatically install them
19:32 <ragechin_> Shiz: Interesting. Unfortunately that doesn't scale as well for me. My intiial use case is my home router. I need to bring up all of my VLANs and other interfaces before I allow outbound traffic.
19:32 <TemptorSent> I have code that takes a set of features and spits out a configured overlay.
19:32 <ragechin_> Shiz: Indeed. I took advantage of that to bootstrap an EC2 instance to create an AMI.
19:32 <Shiz> of course, you can also store the apkovl on some local medium
19:32 <TemptorSent> What we need is /etc/apk/overlays or some such
19:32 <Shiz> it doesn't make a difference for the boot process much
19:33 <ragechin_> Fair enough.
19:33 <TemptorSent> Which would load overlays stored on the rootfs early in the init process.
19:33 <ragechin_> How does it handle multiple overlays? I could, in theory, have multiple services w/custom configs that need to be put in place.
19:33 <Shiz> right now, not very much
19:33 <Shiz> :P
19:33 <TemptorSent> That's what it doesn't do now.
19:34 <ragechin_> That's unfortunate.
19:34 <Shiz> however
19:34 <TemptorSent> You can simply concat them all together though :)
19:34 <ragechin_> I'll take "that doesn't scale" for 1,000, Alex.
19:34 <Shiz> hehe
19:34 <TemptorSent> It only accepts one overlay, but I think it will keep reading through headers.
19:35 <Shiz> ragechin_: so what you could do
19:35 <TemptorSent> Right, that's why I'm working on fixing the root problem, namely the support for only a single apk in the root of the boot media
19:35 <ragechin_> heh. I'm trying to get away from unicorn-purposed servers, not add more.
19:35 <ragechin_> TemptorSent: I've come to the conclusion that you like to talk for the sake of talking
19:35 <Shiz> is have one apkovl that contains a simple /etc/local.d script that reads a list of apkovls and unpacks them
19:36 <ragechin_> (Or bake that into a package, if I so choose)
19:36 <Shiz> yes, that is one thing you can do in a package :)
19:36 <TemptorSent> *facepalms*... see suggestion above to load contents of /etc/apk/overlays above.
19:37 <ragechin_> Isn't that file managed by another package?
19:37 <Shiz> the file doesn't exist
19:37 <Shiz> he's thinking of a hypothetical file
19:37 <TemptorSent> It doesn't exist, so make it.
19:37 <Shiz> that would hypothetical apk integration
19:37 <Shiz> and don't add random files to /etc/apk, the package manager might use them in the future in a different way than you'd expect
19:38 <TemptorSent> Um, what part of my suggestion as an addition to apk did you not see there?
19:38 <Shiz> yes, and it's just that
19:38 <Shiz> a suggestion
19:38 <Shiz> unless you can guarantee it gets exactly added to apk in the way you specify, it is useless
19:38 <Shiz> don't barge into restricted namespaces
19:39 <Shiz> unless you're the owner of that namespace, aka apk :P
19:39 <TemptorSent> Bloody hell, I submit patches AFTER I test tme.
19:39 <Shiz> yes, that's fine
19:39 <Shiz> who says they'll be accepted?
19:39 <Shiz> patches get judged on more of whether they work or not
19:39 <TemptorSent> So you're saying don't mess with apk, go create your own solution instead of contributing it to the primary tool.
19:39 <Shiz> all i'm saying is, don't go preparing that /etc/apk/overlays is gonna work unless your patch is in HEAD
19:40 <Shiz> until it is, use some other path...
19:40 <TemptorSent> Chicken, meet egg.
19:40 <Shiz> anyway
19:40 <Shiz> side-tracking aside
19:40 <TemptorSent> Fine, call it /etc/notapk/overlays
19:40 <Shiz> ragechin_: i think that's the path of least-resistance for you
19:40 <Shiz> an apkovl or package that adds a simple script to read and extract apkovls on boot/init time
19:40 <Shiz> and those apkovls contain your custom config overrides
19:41 <TemptorSent> The point is the solution is simple enough, requires no significant modifications, and uses existing tools.
19:42 <TemptorSent> Ideally, it gets baked into apk (at least the apk package) so it can be generally used by all, not just one special case.
19:42 <TemptorSent> ragechin_: And I don't particularly like to talk, I do like to actually solve problems.
19:42 <Shiz> i don't see at all how it's apk's responsibiltiy to have anything to do with apkovls, but let's leave that for another time
19:42 <ragechin_> Shiz: That handles boot, fair enough. I'm still struggling with runtime config changes.
19:43 <TemptorSent> Because it needs to know about them when extracting apks to not overwrite things at boot.
19:43 <Shiz> ragechin_: right so
19:43 <TemptorSent> tar works :)
19:43 <Shiz> ragechin_: there the case is more so
19:43 <Shiz> do you still expect to run a command on your boxes when the config updates?
19:43 <Shiz> (e.g. # apk update as before with the package istuation)
19:43 <ragechin_> Yeah, something like that.
19:43 <Shiz> right
19:43 <Shiz> in that case
19:43 <ragechin_> In some form. It might be automated later.
19:43 <TemptorSent> I believe that hooks can handle that.
19:43 <Shiz> you could simply restart the local service
19:44 <Shiz> :P
19:44 <Shiz> and it'll re-fetch/extract apkovls
19:44 <Shiz> maybe something with lbu first to reset stuff...
19:45 <TemptorSent> Yeah, there should be nothing different between running it live and running after reboot, so long as you have it persisted with lbu for anything needed at boot.
19:46 <ragechin_> IIRC there's a way to have a directory monitored for changes, and a script executed at that point.
19:46 <TemptorSent> Then you can package up custom configs as packages and have them selected by a single config file
19:46 <TemptorSent> inotify
19:46 <Shiz> inotify or fanotify, yes
19:46 <TemptorSent> but that's heavy for the application
19:46 <Shiz> or dnotify
19:46 <Shiz> there's like 3 kernel mechanisms
19:47 <ragechin_> Here's my current thought...
19:47 <TemptorSent> incron is good for monitoring for files, but this really is a case of you know when the changes happen.
19:48 <ragechin_> Custom configs into an overlay, included in a package. On package install, the APKVOL is moved to /usr/local/apkovl_storage. I have a local.d service that is told that something changed (either through SIGINFO, or whatever mechanism I choose), and it goes back through apkovl_storage and extracts the new contents somewhere.
19:49 <Shiz> hmm
19:49 <ragechin_> It's a little heavy.
19:49 <Shiz> so my question there is
19:49 <Shiz> why include the overlays in a package, and not just simply a list of URLs?
19:49 <Shiz> for instance
19:50 <ragechin_> My CI lifecycle is geared a bit towards packaging and I've invested a significant amount of time in developing it.
19:50 <ragechin_> I really don't want to start it from scratch
19:50 <Shiz> :P
19:50 <Shiz> ragechin_: so if you include it in a package
19:51 <Shiz> you can actually simply extract the apkovls in a post-install script
19:51 <Shiz> don't need the local.d service
19:51 <Shiz> as soon as you # apk upgrade, the post-install script gets run
19:51 <ragechin_> and apk doesn't complain about the file conflicts because dnsmasq.conf isn't a file that the package profides.
19:51 <ragechin_> It's dnsmasq_config.apkovl.tar.gz or whatever
19:51 <Shiz> right.
19:52 <ragechin_> I can install it to /tmp/, and delete the apkovl when I'm done
19:52 <Shiz> it's a bit abuse of packaging, but it'd work I suppose
19:52 <ragechin_> Heh.
19:52 <Shiz> I think the apkovl url list is cleaner, but it's up to you and your existing investment
19:52 <Shiz> of course
19:53 <ragechin_> Well, my "prod" isn't public facing.
19:53 <ragechin_> It's my home network.
19:53 <ragechin_> I have a horrible tendency to edit my code in production and cause problems for the Mrs when I'm not home.
19:53 <ragechin_> Ba didea.
19:53 <ragechin_> bad idea*
19:53 <Shiz> hehe
19:54 <Shiz> i would like to add multiple apkovl support to mkinitfs
19:54 <Shiz> it should be fairly trivial
19:54 <ragechin_> brb, testing this out
19:55 <ragechin_> Hrmm. I do need to create the archive before I create the package...
20:45 <jirutka> ragechin_: if you wanna override some files installed by another package, then use "replaces" (e.g. replaces="dnsmasq"
21:00 bfritz joined
21:07 <TemptorSent> Question, do we need anything in the initfs for apk to be fully functional besides /etc/apk/(arch|keys/|repositories)?
21:13 <Shiz> hmm
21:14 <Shiz> it seems like a bad/unstable idea to rely on a few files being there
21:14 <Shiz> is it not possible to look at what apk --initdb creates?
21:14 blueness joined
21:15 stwa joined
21:21 <TemptorSent> Shiz: The problem is apk --initdb creates a whole lot we don't need in the initfs too.
21:21 <Shiz> like?
21:22 <Shiz> honest question, i dont know
21:22 <TemptorSent> A rather extensive directory structure.
21:22 <TemptorSent> We want to be able to run apk --initdb from within the initfs, and to actually do anything, we at least need keys and a repository file.
21:23 HRio joined
21:24 <TemptorSent> And unless it's customized, we probably want to default to the user's current alpine release official repos.
21:24 <TemptorSent> ...but I'm not sure how to get that either.
21:24 <HRio> hi why is the u-boot directory empty in https://nl.alpinelinux.org/alpine/v3.5/releases/armhf/alpine-uboot-3.5.2-armhf.tar.gz but not in alpine-uboot-3.4.6-armhf.tar.gz?
21:25 <TemptorSent> Shiz: We want just enough to overcome the chicken and egg problem.
21:27 <HRio> the uboot-3.4.6-armhf.tar.gz contains u-boot for wandboard_quad, Cubieboard2, rpi_2, wandboard_dl, wandboard_solo, am335x_boneblack and rpi
21:28 dfs joined
21:33 arch3y joined
21:37 <TemptorSent> HRio: No idea, are any of them relocated in the new package?
21:37 <Shiz> i dont think thats handled by any package
21:39 <HRio> the are built e.g. http://nl.alpinelinux.org/alpine/v3.5/main/armhf/u-boot-beagleboard-2016.07-r2.apk but not packaged in the .tar.gz anymore
21:39 <TemptorSent> Ahh, looks like they were split out to individual packages then.
21:39 <Shiz> right
21:40 <TemptorSent> Does extracting that new apk result in the expected files?
21:40 <Shiz> the package have the same names in 3.4 TemptorSent
21:40 <TemptorSent> It likely has a trigger?
21:42 <arch3y> I was a developer for ArchStrike a archlinux based pentest distribution, I see there are some security pkgs being added to alpine
21:42 <TemptorSent> Hmm, I haven't looked at uboot.
21:42 <arch3y> would it be acceptable to work on adding in more pkgs to alpine that are security-related as apkgbuilds are basically ArchLinux pkgbuilds
21:42 <HRio> the expected files are in u-boot-beagleboard-2016.07-r2.apk under usr/share/u-boot/am335x_boneblack
21:44 <TemptorSent> HRio u-boot should use that if installed I would guess. try installing u-boot-all
21:44 <TemptorSent> arch3y: Keep in mind libc and shell differences.
21:44 <HRio> in 3.5 that is. for v3.4 the file is u-boot-beagleboard-2015.04-r1.apk and the path is usr/share/u-boot/am335x_boneblack/ so looks same
21:46 <HRio> but its still a bit unexpected to find an empty u-boot/ dir in alpine-uboot-3.5.2-armhf.tar.gz as its described as "Includes the uboot bootloader" on https://alpinelinux.org/downloads/
21:46 <TemptorSent> Hmm, yeah, that part seems off. Possibly a package version issue caught the builder flat-footed?
21:47 <Shiz> yeah it seems like a bug HRio
21:47 <Shiz> definitely not indended
21:48 <TemptorSent> Yeah, it sounds like the profile was missing a few things perhaps or something was otherwise changed.
21:48 <TemptorSent> Looks like one of the issues I'll have to make sure I have fixed in the new image building logic.
21:49 <TemptorSent> Just checked on what I have and it appears it should work, but having not tested it, I'm not going to swear to it.
21:50 <HRio> http://bugs.alpinelinux.org/issues/7181 created
21:51 <TemptorSent> I also don't have any u-boot configurator code yet, so if you have thoughts there, I'll gladly add them.
21:51 <arch3y> TemptorSent: understood I plan on building an lxc container and making sure I understand the build process before I work on building stuff
21:52 <arch3y> TemptorSent: Ill play around with alpine locally before I build and focus on maintaining any pkgs
21:53 <TemptorSent> arch3y: Yeah, but ask here before you start working on anything too much -- I got bit by that after spending a few weeks turning the old iso builder into something useful before finding out it was ancient and had been replaced by mkimage
21:53 <arch3y> TemptorSent: sure understood I will be around here and talking daily
21:54 <TemptorSent> Cool deal arch3y :)
21:54 <arch3y> I am looking for a new home and very used to maintaining pkgkbuilds
21:54 <TemptorSent> I'm working on some basic auditing and verification abilities for the installed system.
21:55 <HRio> TemptorSent & Shiz thanks. time for bed ;-)
21:55 <arch3y> that should be interesting, I am used to compiling most of the pkgs via gcc so I wonder how musl will work
21:55 <Shiz> uhm
21:55 <Shiz> musl also uses gcc?
21:56 <Shiz> or well, alpine does
21:57 <arch3y> my bad still used to the idea havent used alpine at all yet
21:57 <arch3y> but Ill learn quickly
21:59 <Shiz> gcc is the compiler, different from the libc
21:59 <Shiz> musl is the libc, as opposed to e.g. glibc
22:00 <arch3y> gotcha makes more sense apologies for the confusion, I hope to test builds on armv6, armv7 and aarch64 as well as x86_64 and i686
22:00 <arch3y> so it should be an interesting project
22:07 faffolter joined
22:07 faffolter joined
22:28 tty` joined
22:41 BitL0G1c joined
23:10 leitao joined
23:25 leitao_ joined
23:38 <tmh1999> jirutka : Thank you ^^