<    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:07 <TemptorSent> Anyway, I'd like to continue with laying in the rest once at least the basics, if not the details, of the process I'm utilizing are agreable.
00:09 <TemptorSent> Part of my reasoning for the approach of mouting /.init.d as a tmpfs is knocking out privs for anything else installed in the root until we're done with any sensitive boot proceedure.
00:10 <TemptorSent> This makes run-from-ram a matter of installing what we want using totally normal apk, then nuking the .init.d dir and execing busybox init
00:13 <jirutka> wow, there are already at least 3 people from IBM working on building Alpine on PPC!
00:14 <TemptorSent> Awesome!
00:14 <jirutka> I’m quite impressed, I wouldn’t expect that from a company like IBM
00:14 <TemptorSent> Actually, if anyone, I guess I WOULD expect that of IBM.
00:14 <jirutka> why?
00:15 <TemptorSent> jirutka: They're the only one still standing that understands the concept of R&D
00:15 <jirutka> really?
00:15 <TemptorSent> Yes.
00:15 <TemptorSent> They engage in a lot more pure-science than any other company I can think of in the industry.
00:15 <TemptorSent> Probably by an order of magnitude at this point.
00:16 <jirutka> hmm
00:16 <jirutka> I know only about some shitty software from IBM, don’t know anything about their R&D
00:16 <TemptorSent> They have, by far, the largest patent portfolio and fastest growing of any tech company.
00:17 <TemptorSent> Something like 6000+ in a year IIRC?
00:17 <TemptorSent> And many, if not most of those are pure-research or early application engineering results.
00:18 <TemptorSent> jirutka: Their shitty software somehow still persists despite the fact that IBM doesn't think it's worth a shit either :)
00:18 <jirutka> heh:P
00:19 <TemptorSent> You know all those advances in hard drives that took us from 120MB drives to 12TB drives in a bit over 25 years?
00:19 <jirutka> yeah…?
00:19 <TemptorSent> I think 80% of those came directly from IBM's research.
00:20 <TemptorSent> Including finding the existince of GMR, which all high-density drives have relied on for the past 20 years.
00:21 <TemptorSent> IBM is very much at the top of the field in R&D and applied engineering.
00:22 <TemptorSent> They actually TEST things, not just talk about them.
00:23 LouisA joined
00:23 <kaniini> jirutka: actually the IBM guys have been helping with getting things working on non-x86 too
00:24 <kaniini> now if we could get docker to do the same!
00:24 <TemptorSent> kaniini: IBM was one of the first to support linux development in the first place.
00:24 <kaniini> i kid, i kid
00:24 <kaniini> (not really, it would be nice to see docker give back more)
00:25 <TemptorSent> kaniini: I'm still not sure I understand their business model.. but then again, I don't understand the business model of any of the blue-chips these days it seems.
00:25 <kaniini> well, IBM has an interesting possibility with Alpine that it doesn't really have anywhere else
00:26 <TemptorSent> Something not tied to GNU?
00:26 <jirutka> kaniini: ?
00:26 <kaniini> it's new, it's growing very quickly, and it's something they can secure a lot of influence over
00:27 <TemptorSent> kaniini: And, importantly, it's a very good fit for their SOA
00:27 <jirutka> hm, we should really hire a lawyer…
00:27 <kaniini> jirutka: indeed. it's getting pretty urgent to get a foundation up
00:28 <kaniini> IBM isn't the only people who we could get to roll the dice on alpine
00:28 <TemptorSent> kaniini: Just be very careful with any formalized organizaton -- the are far easier to abscond with by a good bad lawyer.
00:28 <kaniini> jirutka: it is known that IBM want to kill AIX. Alpine is something that they could potentially use as the basis of an AIX replacement.
00:29 <jirutka> hmmm
00:29 <kaniini> jirutka: that would actually *feel* like an AIX replacement, unlike RHEL
00:29 <TemptorSent> kaniini: AIX needs killing at this point.
00:29 <jirutka> I’m soo happy to be on this boat!
00:29 <TemptorSent> To make it happen, some serious work on BB or an alternative will be required.
00:30 <jirutka> if Alpine will rule the world some day, I will laugh to faces of these people who look at me as to weirdo now! XD
00:30 <kaniini> busybox in alpine is dead
00:30 <kaniini> at some point, it will be replaced with toybox
00:30 <TemptorSent> Having random bugs in find -xdev that causes dataloss isn't going to fly.
00:30 <jirutka> WHAT?!
00:30 <jirutka> what bugs in find causing dataloss?
00:31 <TemptorSent> jirutka... it just checks devid, so bind mounts and tmpfs mounts aren't picked up..
00:31 <jirutka> I remember few very weird bugs in busybox tools, but none that cause data loss
00:31 <TemptorSent> so find / -xdev on my system is happily giving me all of /dev and /sys
00:31 <jirutka> hm, when considering alternative, what about some core tools written in Rust? :P
00:31 <TemptorSent> ... Yeah, try a rm -r in a directory with a mount under it using xdev.
00:32 <kaniini> IBM tried with Debian a couple of years ago, but the collaboration didn't really work out
00:32 <TemptorSent> Goodby, bind mounted filesystem! (luckily apk cache when I actually did it.)
00:32 <kaniini> Alpine is at about the right stage of maturity where such collaborations can work well
00:32 <TemptorSent> Agreed.
00:32 <jirutka> heh, not surprised, Debian is like very heavy, messy and slow dinosaur
00:33 <TemptorSent> And not terribly AIX like ;)
00:33 <kaniini> and Alpine is basically a much leaner Debian-influenced OS :)
00:33 <jirutka> debian-influenced…? ಠ_ಠ
00:33 <kaniini> in some ways
00:33 <TemptorSent> Eh, more gentooish really.
00:33 <kaniini> there's a lot of gentoo and arch influence too
00:33 <TemptorSent> At least that's the flavor I get.
00:33 <jirutka> point to debian-influenced things, I’ll kill them with fire
00:33 <awilfox> have you ever looked at apk output strings :P
00:34 <kaniini> but if you look at apk, it is very much a debian-influenced software ;)
00:34 <awilfox> literally punctuation-compatible with apt-get
00:34 <TemptorSent> Good evening awilfox!
00:34 <jirutka> I see similarities mainly with Gentoo and Arch
00:34 <awilfox> so much so that I got confused for a moment, and thought I ended up on wrong box XD
00:34 <awilfox> good evening to you TemptorSent
00:34 <TemptorSent> I thought that was done as an ironic joke?
00:35 <awilfox> jirutka: alpine started as a gentoo fork basically, but there is a lot of debian influence, debian got some things very right with binary distribution
00:35 <kaniini> no
00:35 <jirutka> hm, but apk is like infinitely faster and simpler than apt XD
00:35 <awilfox> unfortunately, they also got some things very wrong politically
00:35 <kaniini> jirutka: apk is basically 'apt done right'
00:36 <jirutka> awilfox: I know about Gentoo origins; and since I was using Gentoo for 5 years on all servers, I’m very glad for this influence :)
00:36 <kaniini> jirutka: we basically just took everyone's good ideas i suppsoe ;)
00:37 <awilfox> jirutka: it is funny how almost every Gentoo fork (besides maybe exherbo) ends up being infinitely better than gentoo itself, community-wise
00:37 <awilfox> cite: I have some amount of involvement in six of them
00:37 <awilfox> lol
00:37 <jirutka> I’ve learned on Gentoo A LOT, it’s probaly the best distro for learning Linux and all principles around it
00:38 <jirutka> uh, almost 3 AM, I must go sleep
00:38 <jirutka> gn
00:39 <TemptorSent> I stuck with drobbins and went the funtoo route.
00:44 <awilfox> TemptorSent: drobbins ended up sniffing around 'original' gentoo last week, fun fact
00:45 <awilfox> funtoo is okay but imo a bit too extreme with the stages... each -march/-mcpu has its own... easier on everyone if you have a generic per-arch stage and let people compile their own stuff
00:45 <awilfox> it was overwhelming scrolling through over 50 stages to find the one that would work specifically on xeon haswell e5
00:45 <awilfox> and yeah, it was /that/ specific, when I was looking at it anyway
00:46 <awilfox> also the 'progress' overlay with dev python.. a bit "release often, break often" for me :P
00:46 <TemptorSent> awilfox: yes, it does have stage3s in just about every flavor imaginable.
00:46 <TemptorSent> What I really liked was the improved profile system and dependency sanity.
00:47 <TemptorSent> Goodnight jirutka
00:48 <awilfox> TemptorSent: you seem like the kind of person that would love my PORTAGE_BINFMT="apk" patch set lol
00:49 <TemptorSent> Okay, here's what I have for the stub currently: http://termbin.com/5cge
00:49 <awilfox> very excited to hear of the apk-tools 3 integration of creation of apk files themselves, so that the logic of creating the file is no longer a mess of python and shell
00:49 <TemptorSent> awilfox: Can we directly build a repo from that awilfox?
00:50 <TemptorSent> That would be VERY nice.
00:50 <awilfox> TemptorSent: that is literally adelielinux
00:50 <TemptorSent> awilfox: IOW, can we dump a custom funto install to apks, including configs?
00:51 <TemptorSent> awilfox: If so, that solves my other need :)
00:51 <awilfox> TemptorSent: theoretically, yes, though I never finished quickapk (like quickpkg)
00:51 <awilfox> TemptorSent: so BB can be unset if I want to use not-busybox? (like toybox or coreutils or whatever)
00:51 <TemptorSent> awilfox: I often need to build highly specific, tuned systems, for which funtoo is my go-to since I can control every aspect of it.
00:52 <TemptorSent> awilfox: this one relies on busybox.static and apk.static being in the initramfs cpio
00:52 <TemptorSent> awilfox: Toybox in static form should work fine if it supports everthing we need to use.
00:53 <awilfox> TemptorSent: ah, okay. that sounds good
00:53 <TemptorSent> awilfox: In fact, if so, I'd prefer that.
00:53 <awilfox> toybox?
00:53 <TemptorSent> Yes.
00:53 <awilfox> pretty sure it does support static
00:53 <TemptorSent> I'm already way larger than I'd like to be with busybox and apk
00:54 <TemptorSent> the later of which is 1.7mb by itself it appears!
00:54 <TemptorSent> All I really need is something that can read a apk-style tarball and verify the contents.
00:54 <awilfox> TemptorSent: haha, that is why I skipped over shell and busybox and all that and wrote my initramfs /linuxrc binary in C... mount(1) converts to mount(3) pretty easily
00:55 <awilfox> it's a rabbit hole... and a scary one... but
00:55 <awilfox> 911422 initrd
00:55 <TemptorSent> awilfox: Yeah, I was looking at just writing it in C, but it then becomes even harder to audit.
00:55 <awilfox> that includes udev to probe hardware devices...
00:55 <awilfox> 911KB
00:55 <TemptorSent> awilfox: Do you check sigs in the initrd?
00:55 <awilfox> well, eudev
00:56 <awilfox> TemptorSent: only of the overlayfs. haven't gotten as far as you have yet.
00:56 <TemptorSent> Yeah, that's where I ran into the wall 'fixing' init.
00:56 <TemptorSent> It was too broken to fix without major redesign.
00:57 <TemptorSent> Verifying the rest was easy, but how do I make sure someone didn't bugger my initfs?
00:57 <TemptorSent> Especially when I want to start appending user files intentionally?
00:59 <TemptorSent> And sadly, it appears adding arbitrary files to the initifs is very easy, and currently there is no way of verifying that we'er only running what we put there.
01:02 <TemptorSent> What we need is a minimal key verification tool build into our kitchen-sink box.
01:03 <TemptorSent> Or a stripped to death minimal static stand alone key tool
01:06 <awilfox> TemptorSent: does /dev/root still exist?
01:06 <TemptorSent> awilfox: Not that I'm seeing actually
01:06 <awilfox> theoretically, you could do something like roothash=$foo, then hash /dev/root and compare in the initramfs
01:07 <TemptorSent> awilfox: the problem is the root fs is made up of all appended files, and we don't want to have to include them ALL for every instance.
01:08 <TemptorSent> We also want to be able to include things like user data (keys, network config, whatnot) in a way we can check that it hasn't been altered.
01:09 <TemptorSent> But still allowing them to replace such keys without having to reinstall the entire kernel stack.
01:10 <TemptorSent> So we can have a fixed known hash and base set of keys for the tools we use to verify everything else, and only allow other files to load with a user-supplied key
01:11 <TemptorSent> ...which is a nonce key.
01:12 <TemptorSent> So we write our nonce key to /init along with the alpine keys when we write the initfs.
01:13 <TemptorSent> And verify from the file INSIDE the signed archive that nobody has altered us.
01:14 <TemptorSent> Any alteration results in a failure to verify and puking
01:16 <TemptorSent> And the stub is short enough that someone can visually inspect it and check the keys.
01:18 <TemptorSent> Oops, although I missed a circular on the first check -- obviously init has the checksums baked in, so it's own check sum depends on the checksum of the whole file including it's own checksum.
01:19 <TemptorSent> Either I can stick that at the end and read a fixed length for the internal checksum, or ignore it, since the second one would catch it.
01:20 <TemptorSent> Just a documentation change actually at this point :)
01:21 blueness joined
01:48 irclogger_com joined
01:48 Topic for
01:54 s33se_ joined
02:26 Emperor_Earth joined
02:28 gromero joined
03:04 blueness joined
03:50 blueness joined
04:26 leo-unglaub joined
05:01 leo-unglaub joined
05:11 leo-unglaub joined
05:23 fabled joined
06:33 leo-unglaub joined
06:37 <xentec> there is a slight cross compiling bug at http://git.alpinelinux.org/cgit/aports/tree/main/binutils/APKBUILD#n16
06:37 <xentec> after changing pkgname the source url (containing it) becomes invalid
07:06 royger joined
07:13 ppisati joined
07:16 al3hex joined
07:22 tty` joined
07:31 t0mmy joined
07:47 robilad_ joined
08:10 fekepp joined
08:15 fekepp joined
08:17 tty`_ joined
08:22 tty` joined
08:49 fekepp1 joined
08:54 <clandmeter> fcolista, around?
08:54 <fcolista> yes clandmeter
08:54 <clandmeter> can you fix py3-netifaces?
08:54 <clandmeter> its in both testing and community
08:55 <clandmeter> while the one in community should probably be removed
08:55 <fcolista> yes. The one in community it's for GNS3
08:55 <fcolista> it's a fork iirc
08:55 <fcolista> let me check
08:55 <clandmeter> oh
08:56 <clandmeter> i didnt notice they were different.
08:57 <clandmeter> strange as https://pypi.python.org/pypi/netifaces lists as py 3 compat
08:58 <fcolista> clandmeter, yes, at that time probably it was not.
08:59 <fcolista> let me check
08:59 <fcolista> "This a fork distributed on PyPi until this issue on upstream is solved: https://bitbucket.org/al45tair/netifaces/issue/13/0104-install-is-broken-on-python-3x"
08:59 <clandmeter> they way its not is confusing.
08:59 <clandmeter> now..
09:00 <fcolista> last comment is 2016-08-23
09:00 <fcolista> so I think this is fixed now
09:01 <fcolista> I'll remove the py3-netifaces on community and move py-netifaces from testing to community
09:02 <ncopa> jirutka: moving php5 to communitysounds good to me
09:02 <clandmeter> fcolista, thx
09:05 <fcolista> clandmeter, since i'm there:
09:05 <fcolista> check() {
09:05 <fcolista> cd "$builddir"
09:05 <fcolista> python2 setup.py check
09:05 <fcolista> python3 setup.py check
09:05 <fcolista> }
09:05 <fcolista> what do you think ? ^^^
09:05 <clandmeter> sure go ahead
09:06 <clandmeter> any test is better then no test :)
09:10 <pickfire> fcolista: Or maybe integrate it to _py?
09:11 <pickfire> _py() {
09:11 <pickfire> $python setup.py check
09:11 <pickfire> }
09:11 <pickfire> Of course that's an addition that doesn't breat since setup.py handles that.
09:12 <pickfire> After using alpine for quite some time, I still don't get how to search for installed packages.
09:15 <fcolista> pickfire, check should be in check()
09:19 <robilad_> is there some license URL for the isos?
09:29 <clandmeter> pickfire: apk info?
09:34 <pickfire> clandmeter: It shows those that aren't installed as well.
09:34 <pickfire> Ah, you mean grep apk info?
09:35 <pickfire> That works but troublesome.
09:35 <clandmeter> apk info shows not installed packages?
09:39 <pickfire> No
09:39 <pickfire> clandmeter: So I need to filter it out with grep?
09:39 <clandmeter> I dont know what you want to accomplish?
09:39 <pickfire> I did apk info 'pack-*' but that shows not installed packages as well.
09:40 <pickfire> clandmeter: I want to do something like search + installed only.
09:41 <clandmeter> you want to search and the output should tell you which packages are installed or not?
09:42 <pickfire> clandmeter: Yeah
09:42 <pickfire> Or even better, search only for installed packages.
09:42 <clandmeter> i think you will need to script that
09:42 <pickfire> clandmeter: Both of those need a script?
09:43 <clandmeter> i think so
09:44 <clandmeter> not sure anybody has tricks which i dont know off
09:44 <clandmeter> ncopa, i dont think we can search for installed packages only right?
09:45 <ncopa> hi
09:45 <clandmeter> i think i normally just use grep
09:45 <ncopa> apk info
09:45 <ncopa> list all installed packages
09:46 <pickfire> Ah, so you all normally use grep
09:52 <pickfire> ncopa: Do we still need to keep the || return 1 or throw it away?
09:59 <clandmeter> ncopa, fabled: are we going to add EFI support in 3.6?
10:00 <ncopa> pickfire: you dont need to add it if its not there already
10:00 <pickfire> What about removing it?
10:00 <ncopa> dont remove existing
10:00 <ncopa> til after 3.6.0 is out
10:00 <pickfire> Eg http://patchwork.alpinelinux.org/patch/3231/
10:00 <pickfire> T_T
10:00 <pickfire> Sorry about that.
10:01 <clandmeter> or what is the actual status of possible EFI bootloaders?
10:01 <clandmeter> are we still stuck on grub?
10:01 <ncopa> clandmeter: good questions
10:01 <clandmeter> i remember fabled mention something, not sure if that was an actual fix on some platform
10:01 <pickfire> I hope not systemd-boot
10:01 <ncopa> we should decide that
10:02 <ncopa> one option is that we use different bootloader for different arch
10:02 <ncopa> and fallback to grub as last resort
10:02 <ncopa> eg that we use syslinux for x86*
10:03 <ncopa> uboot for arm
10:03 <ncopa> etc
10:03 <pickfire> Maybe we should bump TemptorSent here as well. See if he did multiboot images.
10:03 <ncopa> other option is that we try use grub2 on every arch
10:03 <pickfire> I mean multiple bootloader* which supports both efi and bios
10:04 <ncopa> will change the ip addresses for build servers tomorrow morning
10:04 <clandmeter> they are moving?
10:04 <ncopa> so build.alpinelinux.org, git.alpinelinux.org, distfiles.alpinelinux.org will be down from 8.30 tomorrow morning
10:05 <ncopa> i expect it to be down for 1-2 hours
10:05 <ncopa> not moving
10:05 <ncopa> not physically moving
10:05 <ncopa> its switch reconfiguration
10:05 <ncopa> and moving subnet
10:05 <ncopa> so ip addr will change
10:11 kaiyou joined
10:13 <fabled> clandmeter, the image creation scripts support it, but the installer not yet
10:13 <fabled> and it's done with grub-efi which is in testing still iirc
10:13 leo-unglaub joined
10:16 <clandmeter> fabled, ok
10:16 <clandmeter> any plans for improved installer support?
10:16 <ncopa> good question
10:16 <clandmeter> anybody has a project up his sleeve?
10:16 <ncopa> i think that is needed
10:17 <ncopa> we should ask about that on ml
10:17 <ncopa> i mean
10:17 <clandmeter> we should ask kaniini to make it gtk based :)
10:17 <ncopa> we should make a list of what is needed to be done for the release
10:17 <ncopa> and ask who is doing what
10:24 stwa joined
10:35 czart joined
10:38 leo-unglaub joined
10:47 vakartel joined
10:52 blueness joined
11:07 blueness joined
11:11 LouisA joined
11:46 rdutra joined
11:54 tty` joined
11:55 gromero joined
12:04 ferseiti joined
12:14 leitao joined
12:15 farosas joined
12:36 Shiz joined
12:56 Emperor_Earth_ joined
13:14 <BitL0G1c> clandmeter - for an installer look at https://github.com/calamares/calamares - Distribution-independent installer framework
13:25 atmoz joined
13:27 tty` joined
13:56 <TemptorSent> *yawn* 'morning all..
13:57 <TemptorSent> starefossen: Multiboot -- mkimage is setup for making a multiboot iso image already with isolinux/extlinux/grub
13:57 <TemptorSent> WTF? How did RE: becomre starefossen?
13:59 <TemptorSent> RE: Installer - I started on that, but quickly got sucked into securing the init payloads.
14:13 <kaniini> clandmeter: actually i am working out a proper installer in my head and should have something for 3.7/4.0/whatever
14:14 <TemptorSent> kaniini: Can you share what you've got sketched out?
14:22 stwa joined
14:23 <kaniini> not much concrete yet :P
14:30 <TemptorSent> kaniini: Okay, _
14:31 <^7heo> mostly dust
14:31 <^7heo> concrete is deeper.
14:32 <TemptorSent> I've gotten as far as laying out the basics of an install function called directly out of init on the rootfs.
14:34 <TemptorSent> It uses the pre-boot environment setup by init, then will call the disk setup (needs work), then can mount directly to the final location, apk install the base system, run some configuration, and finish the init process to the new running system.
14:34 <kaniini> right now i am working out a tool which accesses a configuration parameter database
14:35 <kaniini> if it doesn't already have an answer, it asks what you want
14:35 <TemptorSent> cool.
14:35 <kaniini> and then returns that value to whatever requested it
14:35 <TemptorSent> I like it :)
14:35 <TemptorSent> How's it stored/accessed?
14:36 <kaniini> plaintext files
14:36 <TemptorSent> Anything not in bb/apk needed?
14:36 <kaniini> answer <question id> xyz
14:36 <kaniini> i am writing it in C
14:37 <TemptorSent> It can compile staticly to something under a few megs? ;)
14:38 <TemptorSent> And is question id the name of a variable, or free form or?
14:40 czart joined
14:48 <kaniini> TemptorSent: freeform, but basically: package/question
14:48 <kaniini> TemptorSent: so perhaps, setup-disk/disklabel-type
14:49 <TemptorSent> kaniini: Given that example, how would you go about laying out a somewhat complex disk setup?
14:51 <TemptorSent> Say a 3 disk raid with lvm, a nvme scratch drive, and a sata boot?
15:00 <kaniini> TemptorSent: that variable just says if you want GPT or MBR. you're overthinking things before anything is prototyped
15:01 <kaniini> TemptorSent: clearly it is possible to handle those things with such an architecture because it's how other installers work (debian-installer, and to some extent, anaconda too)
15:01 <TemptorSent> Right, I'm just trying to understand how the variables would lay out.
15:01 <kaniini> i'm working out the mechanism first
15:02 <TemptorSent> setup-disk/??
15:02 <kaniini> setup-disk/blahblah/blahblah/blahblah
15:02 <kaniini> it's a tree
15:02 <TemptorSent> Okay, it is a tree - cool!
15:02 <TemptorSent> That works then :)
15:03 <kaniini> and some questions' answers are synthesized on demand instead of hardcoded
15:03 <kaniini> since you need that for something like setup-disk
15:03 <TemptorSent> Right.
15:03 <TemptorSent> But I could dump in a tree struture and have it spit back the individual nodes to me when I ask?
15:03 <kaniini> yes
15:04 <kaniini> that is the plan
15:04 <TemptorSent> So globbing? regex? options?
15:04 <kaniini> it's not a tree of *files* though, it's just a stored as a tree in memory
15:04 <kaniini> to clarify :)
15:04 <TemptorSent> kaniini: Right.
15:04 <kaniini> all of that should be fine
15:06 <TemptorSent> I mean I could dump it something like setup-disk/pools/zfs/zpool/tank/usr/&mount-opts=...
15:07 <TemptorSent> And then ask setup-disk/pools/?list
15:08 <kaniini> why not just have
15:08 <kaniini> setup-disk/pools/zfs/zpool/tank/usr/mount-ops
15:08 <kaniini> setup-disk/pools/*
15:09 <TemptorSent> How do you distinguish a path from an option to apply to that path?
15:09 <TemptorSent> in zfs, everything is a dataset, for instance.
15:11 <TemptorSent> so setup-disk/pools/zfs/zpool/tan/usr/mount-opts would be indistiguishable from the path.
15:11 <kaniini> ok
15:11 <kaniini> so
15:11 <kaniini> setup-disk/pools/zfs/zpool/tank/usr:mount-ops
15:11 <TemptorSent> That works.
15:12 <TemptorSent> Somethign to distinguish the path from the option
15:12 <TemptorSent> so setup-disk/pools/**:mount-opts would ideally return a list of mount-opts for all paths under /pools
15:13 <TemptorSent> probably returning both path and option for each?
15:19 LouisA joined
15:40 Shiz joined
15:56 <^7heo> ncopa: I'd like to patch imagemagick to remove the --without-x
15:56 <^7heo> ncopa: I needed `display` to be able to work on fonts
15:56 <TemptorSent> ^7heo: No, thank you!
15:57 <^7heo> TemptorSent: yes, thank you.
15:57 <^7heo> TemptorSent: people need features, sometimes.
15:57 <TemptorSent> ^7heo: Package it seperately, or I end up with a HUGE dep list.
15:57 <^7heo> wtf are you talking about?
15:57 <jirutka> agree with TemptorSent
15:57 <^7heo> I built it locally, I didn't have to add any makedep.
15:58 <TemptorSent> ^7heo: ImageMagick without --without-x needs the x libs.
15:58 <^7heo> well
15:58 <TemptorSent> ^7heo: Run lddtree against it.
15:58 <^7heo> I don't think I have them installed
15:58 <^7heo> and I certainly didn't add them to the APKBUILD
15:58 <jirutka> if it produces separate so libs for x, then move them into separate subpkg; if it doesn’t, then build it twice (look e.g. into dnsmasq for example)
15:58 <TemptorSent> ^7heo: Yeah, certain dep detection is currently broken.
15:59 <TemptorSent> Exactly jirutka ^^^
15:59 <jirutka> I’m quite lost now
15:59 <^7heo> jirutka: I am okay to build it twice, tbh
15:59 <jirutka> so where exactly is the problem?
16:00 <^7heo> http://ix.io/pms
16:00 <TemptorSent> ^7heo: Run the X build as a subpkg would be my take.
16:00 <^7heo> it's not exactly *huge*
16:00 <^7heo> jirutka: I just wondered if it's REALLY necessary to disable X by default.
16:00 <TemptorSent> Um, that is huge!
16:00 <TemptorSent> Look at the size of those libs.
16:01 <TemptorSent> In fact, freetype should probably be taken out of the base install...
16:01 <jirutka> ^7heo: well, yes, b/c X is huuuuge and messy
16:02 <TemptorSent> ^7heo: I use imagemagick on very small systems to do transforms...
16:02 <^7heo> it's adding libXext.so.6, libX11.so.6, libxcb.so.1, libXau.so.6, and libXdmcp.so.6
16:02 <TemptorSent> ^7heo: Right... which means I need the X pkgs installed to use imagemagick.
16:03 <^7heo> ok libX11 is HUGE.
16:03 <^7heo> that is true.
16:03 <TemptorSent> ^7heo: subpackage it off or make a -kitchensink package that provides it.
16:04 <TemptorSent> ^7heo: It's not just the lib, to get libX11, I need to pull in everything libX11's apk depends on too.
16:04 <^7heo> right.
16:04 <^7heo> nah but ok, libX11 is huge.
16:05 <^7heo> the rest really isn't that big
16:05 <TemptorSent> ^7heo: Build a copy with X enable and put it in /usr/X11R6/libs... oh, wait -- they killed that.
16:05 <^7heo> (I mean, libxcb isn't small either, but it's 10x smaller than libX11)
16:05 <TemptorSent> ^7heo: It's about 5 times the size of everything else I need to process images :)
16:05 <^7heo> TemptorSent: yeah yeah
16:05 <^7heo> TemptorSent: I'll package it separately.
16:05 <TemptorSent> ^7heo: incron, ssh, imagemagick - done!
16:06 <TemptorSent> ^7heo: A pi0 has no problem with it.
16:07 <^7heo> a pi0 cannot be bought.
16:07 <^7heo> or found
16:07 <^7heo> or anything.
16:07 <^7heo> So not much of an argument.
16:07 <TemptorSent> ^7heo: (Yeah, making game-cams too eventually -- I've got highgradeders taking me for upwards of a troy pound a year on my claims)
16:07 <^7heo> But a Pi3, 2 or whatever version other than 0, ok.
16:08 rdutra joined
16:08 <TemptorSent> ^7heo: ?? What happened to them?
16:08 <^7heo> TemptorSent: people want them too much it seems.
16:09 <TemptorSent> ^7heo: Anyway, pi0 equiv or less hardware -- low end arm, 256mb ram..
16:09 <^7heo> yeah yeah
16:09 <^7heo> got it.
16:09 <TemptorSent> ^7heo: Bugger, guess I'll have to find something else to build the cams on.
16:09 <^7heo> tbh that's why I asked before even opening a PR
16:09 <^7heo> "One does not simply remove --without-x and submit a PR"
16:09 <TemptorSent> ^7heo: *lol*
16:09 <TemptorSent> Good call :)
16:09 <^7heo> TemptorSent: maybe you can buy them
16:10 <TemptorSent> ^7heo: I'd see what it would take to have it build it both ways.
16:10 <^7heo> TemptorSent: you're not exactly located in the same area
16:10 <^7heo> TemptorSent: so maybe they produce them in enough numbers to grant you a few.
16:10 <TemptorSent> We really need to bring back the practice of installing x libs in an x specific directory
16:10 <^7heo> (if your market has priority)
16:11 <TemptorSent> ^7heo: Yeah, probably better for me to layout my own and just sign the bloody NDA to get the specs on the camera interface.
16:11 <TemptorSent> ^7heo: I do embedded hardware, so it's not really that big of a deal -- I was just hoping to be lazy.
16:12 <^7heo> TemptorSent: or you can use the OEM compute module.
16:12 <TemptorSent> ^7heo: TBH, I can get lower power usage with a custom config anyway, only waking up the main system when it needs to and letting a daughtercard with some buffering and motion detection run the camera itself.
16:12 <^7heo> TemptorSent: that's available, and MUCH more powerful.
16:12 <^7heo> (ofc it sucks a lot more amps too)
16:12 <TemptorSent> ^7heo: Yeah, and WAY too much power.
16:12 <^7heo> yeah...
16:12 <^7heo> same problem here.
16:12 <^7heo> I need a pi0 for my washing machine
16:12 <TemptorSent> ^7heo: The zero was getting close to what I can support off small solar pannels and SLAs.
16:13 <^7heo> no way to buy one…
16:13 <TemptorSent> Yeah, that is a problem with the pi platform.
16:13 <^7heo> well, if ONLY they would understand how much of a market they have
16:14 <^7heo> maybe they'd build more.
16:14 <TemptorSent> ^7heo: Yeah, but there is a MUCH larger market for smartphones unfortunately, which is the primary concern of the upstream.
16:15 <TemptorSent> ^7heo: If it was microchip or TI under the hood, we'd probably see much more support, but also other hassles.
16:16 <TemptorSent> ^7heo: I'd love to be running on some sort of open arch, but it's not cheap to do it right.
16:16 <TemptorSent> IP costs $$$
16:16 <^7heo> IPv6 is free. :P
16:16 <TemptorSent> *lol*
16:17 <^7heo> Sorry ;)
16:17 <^7heo> (and super cheap != free but I disregarded that for the joke)
16:17 <TemptorSent> Speaking of IPV6, why aren't we using it by default for our internal networks still?
16:17 <^7heo> no idea
16:17 <^7heo> don't ask about the alpine infra.
16:17 <TemptorSent> We have 127.0.0.1... and?
16:18 <^7heo> it's top secret, it's weird, it's ...
16:18 <^7heo> don't ask.
16:18 <^7heo> I don't ask.
16:18 <TemptorSent> *lol*
16:18 <^7heo> so I can only advise you not to ask.
16:18 <^7heo> some people have access to some stuff.
16:18 <^7heo> if it breaks, pray.
16:18 <^7heo> aside from that, all good.
16:18 <TemptorSent> Yeah..
16:19 <TemptorSent> I'm more of the make it not able to break type :)
16:20 <TemptorSent> We have the ability to do real networking, including encapsulated routing and multipath redundancy and we're not using it WHY?
16:20 <^7heo> really, do not ask.
16:20 <^7heo> unless you can finance a better infrastructure. :P
16:20 <^7heo> if you can pay for it, then yeah let's do it!
16:21 <TemptorSent> ^7heo: No, I mean under our current infrastructure!
16:28 <kaniini> that is why i am interested in dalias/landley's J4 stuff
16:28 <kaniini> and possibly also a microblaze port
16:36 stwa joined
17:21 <skarnet> oh, this is good: https://wiki.mozilla.org/images/a/aa/Curl-report.pdf
17:22 <skarnet> and that is why simple libraries are better than complex ones :P
17:22 <skarnet> (tldr: 23 security-relevant discoveries in curl)
17:23 <skarnet> and with that, I go back to RL
17:24 <^7heo> that is dating from september, last year ;)
17:25 <^7heo> skarnet: has it been published recently?
17:41 t0mmy joined
17:51 leitao joined
18:11 farosas joined
18:27 andypost joined
18:55 ferseiti joined
19:30 fekepp joined
19:48 <leitao> fcolista, hi there. I just improved a package you maintain https://github.com/alpinelinux/aports/pull/1147
19:49 <leitao> and, I am wondering if it would be rude to upload it direct to the master git repo, since this is a community package.
19:50 <leitao> so, how is rules for pushing changes to community/testing repo?
19:51 <gromero> ncopa: looks like here the segfault issue on -static -pie is not fixed. I'm using musl-1.1.16-r7
19:52 <gromero> ncopa: did you update anything else aside musl?
20:01 <kaniini> hi, the musl patch is incorporated for that in musl 1.1.16-r4 and later
20:02 <kaniini> so the patch may be insufficient
20:10 <gromero> kaniini: I see. ncopa said once that problem disappeared on the latest update of musl... so I'm wondering what could be missing. maybe I understood wrongly that the issue was solved
20:11 <gromero> since I'm using musl-1.1.16-r7, and musl-1.1.16-r7 is > 1.1.16-r4 I'm indeed taking all the patches...
20:17 blueness joined
20:22 atmoz joined
20:29 <ncopa> gromero: hi, might be i did something stupid. i dont know
20:34 <gromero> ncopa: hm, right, so it might be that case indeed that it's fixed yet. ok. thanks
20:36 <TemptorSent> Okay, here's how the keys in the stub work: initial stub- http://termbin.com/7u8v key-baker: http://termbin.com/ensb baked-stub: http://termbin.com/jb45
20:36 <TemptorSent> Now, the question is how do we want to generate the nonce key?
20:37 <TemptorSent> Also, what does apk know about decryption? (is it built in for handling encrypted apkovls?)
20:40 <TemptorSent> And would it be insane to request users create and install their own keys to use anything but stock kernel/boot?
20:46 <TemptorSent> If that's reasonable, then we can make life very easy.
20:47 <TemptorSent> If not, we'll have to be careful about a nonce an give the user a way to verify it without having the private key.
20:48 <TemptorSent> My intention is to then have each feature in mkimage generate it's own signed tarball with the files it requires, to be added to the generated cpio
20:49 <TemptorSent> Ideally with the source package of those files tracked along with their hashes so everything can be authenticated and audited.
21:04 <TemptorSent> This leaves early init as the stub loader and init-basic, with the rest being loaded out of their respective signed tarballs as needed.
21:05 <TemptorSent> Other than very thin applications (which we will ship a slim-shim for), does this break anyones work badly?
21:06 <TemptorSent> kaniini, ncopa, fabled?
21:07 <TemptorSent> Oops, obviously I need to spit in '$BB cat' :)
21:10 <kaniini> https://www.amazon.com/dp/B00IA5J8M8?tag=wiki085-20
21:10 <kaniini> i think for alpine 3.7/4.0, i am going to port alpine to this
21:10 <kaniini> you can put up to 16gb ram in it
21:11 <kaniini> so pretty viable port target imo
21:12 <TemptorSent> (unlike the bloody laptop running my browser and crashing that can only address 3gb :/
21:13 <* TemptorSent> grumbles about autoupdating software that updates at the least convenient times.
21:14 <TemptorSent> Nice piece of hardware!
21:15 <TemptorSent> Too bad no 10GBPS uplink...
21:15 <kaniini> there are routerboards running on octeon that have 10gbps
21:16 <kaniini> the edgerouter is a better target for initial porting because it is easy to recover if you break it
21:16 <TemptorSent> kaniini: Yeah, I've been eyeballing those xeon-d boars too, but their pricing went UP.
21:16 <kaniini> (the flash is a USB stick inside the device)
21:16 <TemptorSent> kaniini: I'm used to jtag and serial ports :)
21:16 <kaniini> sure, so having the flash on a USB stick is a dream compared to that :P
21:17 <TemptorSent> Yeah, no kidding!
21:20 <leitao> Hi. I create a ppc64le at Alpine wiki to track the missing packages on ppc64le: https://wiki.alpinelinux.org/wiki/Ppc64le
21:20 <TemptorSent> kaniini: Does the keybaking look good for your purposes?
21:20 <TemptorSent> leitao: Do you have a writeup on the boot process by chance?
21:21 <kaniini> step 1 -- pay IBM lots of money for a server
21:21 <kaniini> step 2 -- boot it
21:21 <kaniini> i kid
21:21 <TemptorSent> *LOL*
21:21 <leitao> TemptorSent, no. this is still not done.
21:21 <leitao> TemptorSent, we are only running it on a virtual machine
21:22 <kaniini> although it would be nice if some of these openpower companies would actually sell hardware to individuals
21:22 <TemptorSent> leitao: Okay, let me know what's needed and I'll get VM images built.
21:22 <kaniini> you will need 1 x IBM POWER8 server
21:22 <kaniini> let me know when you have that
21:22 <kaniini> and we will talk ;)
21:22 <TemptorSent> kaniini: Yeah, I used to play with the old power harware... it's been a while since :)
21:23 <kaniini> i suggest american express will be useful for acquiring said server
21:23 <leitao> TemptorSent, kaniini: you can have some Vm if you wish
21:23 <leitao> http://openpower.ic.unicamp.br/minicloud/
21:23 <jirutka> leitao: what’s the problem with openjdk7?
21:23 <TemptorSent> But really, all I need to know is what's required in terms of both configuration and boot artifacts.
21:24 <leitao> TemptorSent, shouldn't be a big deal, but ppc64le just supports grub and yaboot.
21:24 <leitao> jirutka, checking
21:24 <TemptorSent> Okay, grub and yaboot -- that's a start!
21:24 <TemptorSent> Can you send me an example working config for each?
21:25 <leitao> jirutka, http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/openjdk7/openjdk7-7.131.2.6.9-r1.log
21:26 <leitao> TemptorSent, sure. What exactly do you need?
21:26 <jirutka> leitao: if IBM sponsored LuaJIT project (http://luajit.org/) to add ppc64le support and as a side effect also support for all Lua 5.2 and 5.3 changes, it would be super awesome! :)
21:27 <leitao> jirutka, we tried
21:27 <leitao> jirutka, there is a bounty open already
21:27 <leitao> let me get that
21:27 <kaniini> IBM should just buy docker and put it out of it's misery
21:27 <TemptorSent> leitao: Paths and contents of grub.conf as well as a any info on installing grub appropriately.
21:27 <jirutka> leitao: hm, this error in openjdk7 looks exactly like the one you (or your co-worker) have fixed in nodejs
21:27 <TemptorSent> Same for yaboot.
21:27 <leitao> jirutka, gromero^
21:28 <leitao> TemptorSent, can we focus on grub2? Yaboot is old and we are trying to get rid out of it.
21:28 <TemptorSent> leitao: Request for VM sent.
21:28 <kaniini> yes, yaboot needs to die
21:28 <TemptorSent> leitao: Of course.
21:28 <TemptorSent> leitao: If it's compatible with the same hw, no issue at all.
21:29 <leitao> jirutka, https://www.bountysource.com/issues/26806419-port-to-ppc64le
21:29 <jirutka> leitao: that’s great! have someone from LuaJIT already responded?
21:29 <TemptorSent> mkimage already knows about grub, so enabling images should be a matter of writing out the right config, sticking things in the right place, and giving it a list of packages.
21:30 <leitao> TemptorSent, right, I will need to spend sometime on it.
21:31 <TemptorSent> leitao: It should be pretty straightforward, given a working config and the fact that a VM is a pretty standardized environment compared to real hardware.
21:32 <leitao> TemptorSent, something like http://paste.ubuntu.com/24270280/ ?
21:32 <leitao> this is what Ubuntu grub.cfg Ubuntu is using
21:34 <TemptorSent> Holycrap! I thought that was a grub.cfg GENERATOR until I kept reading, that's huge!
21:34 <TemptorSent> Okay, better question -- what do we actually NEED/WANT? :)
21:35 <leitao> TemptorSent, Debian's jessie is also big http://paste.debian.net/924845/
21:35 <TemptorSent> Yeah, that's insanity.
21:35 <TemptorSent> Okay, we've got an emulated EFI boot?
21:36 <TemptorSent> I can't even tell what's used and what's not in this mess!
21:36 <TemptorSent> Does it actually use video_bochs / video_cirrus in the vm?
21:36 <leitao> No, probably not
21:36 <TemptorSent> Guess I'll hve to play with it..
21:37 <TemptorSent> Yeah, I didn't expect that!
21:37 <TemptorSent> And I was feeling bad about a stub loader getting hard to fit on one screen without the keys :)
21:38 <leitao> TemptorSent, I think that we should use insmod ieee1275_fb
21:38 <leitao>
21:38 <TemptorSent> Yeah, that's what I was guessing..
21:39 <TemptorSent> Or possibly an EFI buffer if that's how it works, but that would be strange.
21:40 <TemptorSent> I don't think we need to set the font, nor do a bunch of i18n in the early boot unless its critical to someone
21:41 <jirutka> leitao: what’s the problem with lua-lpeg?
21:48 <leitao> jirutka, the upstream tgz was hacked!
21:48 <leitao> http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/lua-lpeg/lua-lpeg-1.0.1-r0.log
21:48 <TemptorSent> FFS
21:49 <Shiz> lol
21:50 <TemptorSent> Broken upstream mirror?
21:50 <jirutka> I have the previous tarball on the disk
21:50 <jirutka> so I’ve compared them
21:51 <jirutka> https://hastebin.com/raw/imixutiros
21:51 <Shiz> so he silently changed something?
21:51 <leitao> we love when upstream change something and keep the same version, don't we?
21:51 <Shiz> i'd ask him to be sure
21:52 <Shiz> ;op
21:52 <jirutka> I’d like to kill them and ban forever for this… but… this is LPeg… it’s awesome…
21:52 <TemptorSent> Yeah, looks like fixed the test to match the output :P
21:54 <TemptorSent> lim uses 12 bit set rather than 16bit - 10 for whatever reason.
21:55 <TemptorSent> But then is checking below for 2^15, which may be an error.
21:57 <TemptorSent> Or at least self-inconsistent
22:00 tkharju joined
22:04 czart_ joined
22:04 fekepp joined
22:10 <kaniini> TemptorSent: powerpc iirc still uses openfirmware, not efi
22:17 rdutra joined
22:30 <TemptorSent> kaniini: Okay, that answers that.. If I get a vm, I'll see what a minimal grub.conf looks like.
23:15 farosas joined
23:38 <jirutka> is there anyone who can guide me through the LLVM jungle? I’m trying to package emscripten (C → JS via LLVM) and there’s a lot of bloat, I think that not all of it is actually needed
23:40 MH0815 joined
23:41 <Shiz> jirutka: all i can give you are my best wishes
23:41 <Shiz> :p
23:43 <TemptorSent> jirutka: Haven't looked at it lately.
23:43 s33se joined
23:44 <Shiz> jirutka: at least you should be able to make it use the host LLVM right
23:45 <jirutka> Shiz: unfortunately not, emscripten requires its own fork of LLVM…
23:45 <Shiz> oh, gross
23:45 <jirutka> Shiz: it seems that every project that uses LLVM has its own fork
23:45 <Shiz> i wonder why
23:45 <Shiz> (i actually don't)
23:45 <jirutka> yeah…
23:46 <jirutka> it’s terrifying
23:47 <Shiz> they have their own SDK package manager....
23:47 <jirutka> yeah
23:47 <Shiz> >Install Java using the system package manager:
23:47 <Shiz> oh no
23:48 <jirutka> they use Java for Closure, JS optimization tool
23:48 <TemptorSent> What a fugly mess!
23:48 <jirutka> maybe there’s a reason why no major distribution provides pkg for emscripten…
23:49 <TemptorSent> It sounds like it's its own distribution!
23:49 <jirutka> heh
23:49 <TemptorSent> All to compile C to JavaScript? Doesn't that seem a LITTLE bass-ackwards?
23:50 <Shiz> https://packages.debian.org/sid/emscripten
23:50 <Shiz> :p
23:50 <Shiz> it seems debian got it to work against system llvm?
23:51 <Shiz> ah
23:51 <TemptorSent> I wonder if they have the patches in their system llvm?
23:51 <Shiz> debian disables fastcomp
23:51 <Shiz> that probably explains it
23:51 <jirutka> nah, it’s more likely just outdated as hell
23:51 <jirutka> emscripten does not use its own fork (called fastcomp) since ever
23:52 <jirutka> so this pkg is probably from ages when it didn’t exist
23:52 <Shiz> they explicitly disable it
23:52 <jirutka> hm, I made a typo or search on debian page sucks, b/c I haven’t found this
23:52 <Shiz> http://http.debian.net/debian/pool/main/e/emscripten/emscripten_1.22.1-1.debian.tar.xz
23:52 <Shiz> check the patches/ folder
23:53 <TemptorSent> Hmm, anyone have any thoughts on how to handle a one-time key generation for the initramfs?
23:53 <Shiz> dd if=/dev/urandom?
23:53 <TemptorSent> Is it nuts to ask a user to create a key when they update the kernel?
23:55 <TemptorSent> Shiz: What I'm looking for is a way of having a key that is used to sign all artifacts installed in the initramfs that countersigns the keys of the packages the various files came from
23:55 <TemptorSent> then the private key is destroyed.
23:55 <TemptorSent> But how to create a verifiably signature on that nonce key is my issue.
23:56 <TemptorSent> Essentially, I'm thinking the ideal case would be the users create and install keys a'la abuild-sign.