<    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:00 <TemptorSent> jirutka: No, not until you have an actual breach of contract that you've been implicated in causign.
00:00 <kaniini> TemptorSent: all they do is facilitate grants
00:00 <kaniini> TemptorSent: they do not employee any devs
00:00 <TemptorSent> kaniini: Right, I'm just saying how much it costs to keep that funding legal.
00:01 <TemptorSent> kaniini: Not paid devs, paid administrative and legal staff.
00:01 <kaniini> sure
00:01 <TemptorSent> kaniini: Either that, or they're getting a big in-kind donation in billable hours.
00:02 laj joined
00:02 <awilfox> TemptorSent: 150k out of 2m is 7.5%, just noting that.
00:02 <TemptorSent> kaniini: That's the danger with setting up a NPO and funding through it.
00:02 <awilfox> and if there is not so many donation, they don't need so much auditing
00:02 <awilfox> so it is no longer two full time people
00:02 <awilfox> it scales out
00:03 <kaniini> all i know is
00:03 <TemptorSent> awilfox: Yeah, that would actuall be pretty damn good if that's their total overhead. I'd be surprised if they didn't have a fair amount in other fees too.
00:03 <kaniini> there's companies out there who want to execute grants concerning alpine
00:03 <kaniini> and so we need a structure of some sort to facilitate that
00:03 <jirutka> maybe I can ask people from Gentoo how they manage their foundation
00:03 <kaniini> yes
00:03 <kaniini> it is certainly something we need to do at this point
00:04 <jirutka> also I know people from SUSE and RedHat
00:04 <TemptorSent> awilfox: I know the organizations I've been on the board of (501(c)(3)/(4)) with very minimal funds ended up costing us about 60% overhead.
00:05 <TemptorSent> awilfox: And at that, we probably would have problems if someone wanted to press the issue.
00:05 <awilfox> TemptorSent: $165,472.50 for administrative costs of the Foundation, $956,190.00 in grants paid out to devs/web site admins/etc etc etc, $127,198.50 for fundraising costs including taxes/fees/CPA
00:06 <awilfox> TemptorSent: out of $1,250,000.00 donation
00:06 <TemptorSent> Sounds about right, and still pretty damn good.
00:06 <awilfox> https://www.freebsdfoundation.org/wp-content/uploads/2015/12/Budget2016.pdf
00:06 <awilfox> so yes I would say they are doing very well
00:07 <awilfox> jirutka: the gentoo foundation is not an example of what to do.
00:07 <TemptorSent> A bit shy of 300k, so a 3+/1 ratio service/costs.
00:07 <awilfox> TemptorSent: yeah, they run it quite well.
00:07 <awilfox> jirutka: it lapsed for some years and now they are trying to reassemble it. it's a huge disaster.
00:08 <TemptorSent> awilfox: Yes, that is far better than the usual <0.5/1 you see, and even 2+/1 is considered pretty damn good.
00:12 <TemptorSent> awilfox: If a foundation could be set up approaching that kind of utilization ratio, it would indeed be worth while, but it's also a big time investment to consider)
00:12 <TemptorSent> awilfox: You've done your homework :)
00:13 <awilfox> TemptorSent: I have, yes. I'm involved with another project that has considered setting up a NPO
00:13 <awilfox> open source software project that is
00:13 <awilfox> so I did a lot of research so I could help them make an informed decision
00:13 <awilfox> "it is possible to run it well, but you will need to find people to help, and it will be a large amount of time spent"
00:14 <TemptorSent> awilfox: That is spot on.
00:14 <TemptorSent> awilfox: Along with the big warning '..and if any of those people move on, you're probably screwed.'
00:14 <kaniini> well this is a fascinating conversation but fedex decided i hadn't been screwed over enough this week
00:15 <kaniini> so i have to go to their stupid depot
00:15 <awilfox> I thought the FedEx depot closed at 19:00?
00:15 <TemptorSent> kaniini: Be glad -- they could have put it on the truck anyway.
00:15 <kaniini> awilfox: it's at the airport, thankfully. they close at 21:00.
00:15 <jirutka> yeah, this conversion was really very interesting and useful
00:16 <TemptorSent> jirutka: Hopefully not too offtopic for -devel ;)
00:16 <jirutka> TemptorSent: no, this was very on-topic! :)
00:16 <awilfox> kaniini: oh, good
00:17 <TemptorSent> Pages of on-topic discussion and not a line of code!
00:17 <awilfox> it's like we have more knowledge and talents than just C and Lua!
00:18 <TemptorSent> You mean there's more to a project then code?
00:18 <skarnet> nonsense
00:20 <TemptorSent> Like ROUS...
00:21 <TemptorSent> Just because you believe they don't exists doesn't prevent them from biting your ass in the fire swamp.
00:23 <TemptorSent> Anyway, I'm going to run off now and head up to the local pizza joint to see if any of the other local gold miners show up between storms.
00:26 <TemptorSent> I'm heading out in a bit and will be back on in a few hours - I expect to see my scrollback overflowing by then.
00:30 breno joined
01:03 <kaniini> jesus
01:03 <kaniini> fucking
01:03 <kaniini> christ
01:03 <kaniini> fuck fedex
01:05 <kaniini> my review of the ubuntu unity desktop: no
01:07 <jirutka> XD
01:39 Emperor_Earth joined
01:55 <kaniini> argh
01:55 <kaniini> no wifi support in kernel 4.4 for this thing
01:55 <kaniini> its unfortunate that
02:50 s33se joined
02:57 <kaniini> yeaaaaaah
02:58 <kaniini> we really need to up our installer game
02:58 <kaniini> lol
03:13 <TemptorSent> kaniini: Build yourself an image ;)
03:15 <kaniini> this connman thing is junk
03:16 czart_ joined
04:00 <kaniini> pickfire
04:00 <kaniini> you did not bump the NSS rdepends :(
04:00 <pickfire> kaniini: What do you mean?
04:01 <pickfire> How do I do that?
04:01 <pickfire> abump -r?
04:05 <pickfire> What do I do now?
04:05 <pickfire> Ah!!
04:05 <* pickfire> red alert
04:06 <kaniini> i can't wait for xfce to support gtk3 fully
04:07 <pickfire> kaniini: I can't wait for lxde to have support gtk2 and gtk3 as separate packages as well.
04:11 <pickfire> kaniini: By the way, why do you choose xfce?
04:25 leprechau joined
05:05 BitL0G1c joined
05:11 BitL0G1c joined
05:13 BitL0G1c1 joined
05:25 <kaniini> ncopa: i think we must revert NSS change
05:27 <kaniini> ncopa: basically nothing builds against it
05:45 <TemptorSent> kaniini: I must have missed it, what nss change?
05:47 scadu joined
05:49 <kaniini> NSS 3.30
05:51 <TemptorSent> Crap, I feel old -- here I am thinking you were talking something entirely different. I was wondering why Novel Storage Services were an issue.
05:51 <TemptorSent> Or worse, yp.
05:52 <TemptorSent> If you were talking nss over LDAP, I'd be smiling :)
05:53 <TemptorSent> I'd love to tell the windoze boxes where to really shove it on my client networks.
05:56 <TemptorSent> Whats the netscape security suite used in?
05:56 <TemptorSent> Or whatever they're calling the moz version
05:57 <TemptorSent> Oh, bloody hell - yeah I see what you mean. it's in all sorts of crap.
06:00 <kaniini> i'm starting to agree with jirutka
06:00 <kaniini> tired of 'suck it and see' in edge
06:01 fabled joined
06:04 <TemptorSent> kaniini - Yeah, it's one thing to have occaisional minor breakage, but things that take out the whole system really should be caught before they hit public consumption if possible.
06:04 <kaniini> this NSS thing is bad
06:04 <kaniini> i am reverting it, but i have to rebuild everything because i dont know if anything succeeded in rebuilding against NSS 3.30
06:05 <TemptorSent> Ouch.
06:09 dfgg joined
06:13 sean__ joined
06:24 <pickfire> kaniini: Can you please tell me how do you rebuild it so that I won't make the same mistake next time?
06:27 <TemptorSent> Question - what level of obsolete hardware support do we need in the default images? All the old pata stuff?
06:38 <TemptorSent> In the same vein, should we build a virtio-only minimal VM image as the standard one and a 'compat' version that includes the other vms+common emulated HW?
06:44 BitL0G1c joined
06:46 <TemptorSent> fabled: I just finished excising all remaining assignments from the profiles and it doesn't seem to have broken, so I'll push that once the build of virt finishes
06:47 <TemptorSent> fabled: Also, strangly, despite -e being set, it's not bailing on a fubard funciton name, but it at least is warning about it.
06:47 <fabled> TemptorSent, it depends how the function is called
06:47 <TemptorSent> fabled: Which already let me catch one bug before it got anywhere.
06:47 <fabled> if do
06:47 <fabled> function_foo || bar
06:47 <fabled> it inhibits -e in all function_foo
06:48 <fabled> or similar
06:48 <kaniini> this is a goddamned mess
06:48 <TemptorSent> fabled: Nope, just set_foo "bar"
06:48 <fabled> yeah, -e is funky
06:48 <fabled> TemptorSent, is that called from another function? how is that function called?
06:48 <fabled> it inherits all the way
06:48 <TemptorSent> But hey, at least I hear about it rather than silently failing in weird ways.
06:49 <TemptorSent> Yeah, it's all called within the profile.
06:49 <fabled> how the profile function is then called?
06:49 <TemptorSent> But I buggered an alias name and it bitched, but didn't fail
06:49 <TemptorSent> Good point, I haven't gone through to make sure that bit is fail-fast.
06:50 <TemptorSent> There are bits I haven't totally overhauled yet, the profile builder itself is one.
06:51 <TemptorSent> All calls like that should probably be function_call || ! warning "Function failed with input $foo"
06:54 <TemptorSent> fabled: Pushed, further replacement of all such checks throughout the code to follow.
06:56 <TemptorSent> fabled: While I've got you, what exactly do we want to see in terms of HW support for each of the various images and should we do both 'standard' and 'compatible' version where it might be appropriate?
06:57 <TemptorSent> fabled: We can now break down HW drivers into chunks much more easily, and presumably could even stick them in their own cpio.gz to tack on as-needed to the initramfs.
07:01 <TemptorSent> fabled: For now the aliases are in the plugins functions, but I think I'm going to add an optional helper function for them instead so we can decouple the plugin implementation from the content entirely.
07:02 <TemptorSent> fabled: It would be very helpful to have an intended features/pkgs / arch / bootloader / imagetype matrix to work off
07:03 <TemptorSent> fabled: Then I can actually put togteher something to TEST! :)
07:03 XgF joined
07:04 stateless joined
07:07 vakartel joined
07:10 <TemptorSent> fabled: Well something broke in init for no apparent reason, let me take a look.
07:11 <TemptorSent> I lost the bootable flag...
07:15 <TemptorSent> *facepalm* var_not_empty() { [ "$(eval "echo \$$1")" ] && return 1 || retrun 0 ; }
07:15 <TemptorSent> Yeah, that might do it.
07:18 <TemptorSent> Pushed, now to test ;)
07:20 <TemptorSent> The nice thing is I only have to debug my fubard logic once, not every time I do the check.
07:22 <kaniini> at any rate
07:23 <kaniini> i'm not sure what has happened to nss, but reverting to 3.28.1 did not fix it
07:23 <kaniini> sigh
07:23 <TemptorSent> Okay, that's weird -- looks like I'm only missing mkinitfs?
07:23 <TemptorSent> nlplug is MIA, but the rest of the bins made it.
07:24 <pickfire> TemptorSent: Did you changed the init script?
07:25 <TemptorSent> NM, I fubard something and spit out entirly the wrong thing.
07:25 <TemptorSent> Nope, this is stock init script
07:26 <TemptorSent> pickfire: I think I've been staring at code to long and I'm starting to not see my obvious mistakes.
07:27 <pickfire> Ah
07:28 <pickfire> TemptorSent: +5,427 −872 I don't dare to test it out
07:28 <TemptorSent> Like the fact that I was trying to run the previous image still because the date rolled over in the mean time.
07:28 <pickfire> What is different compared to back then?
07:29 <TemptorSent> pickfire: I fixed the problem already, I was just still looking for it because I was testing the OLD image in qemu, not the new one.
07:29 <pickfire> Fixed what problem?
07:29 <TemptorSent> pickfire: It's much more functional now and debugable.
07:30 <TemptorSent> pickfire: The stupid mistake that led to it failing in init. Now I just need to figure out why it doesn't like the modloop.
07:30 <pickfire> I want to test out my setup too, any tips on how to test and debug it easily?
07:30 <pickfire> Ah
07:30 <pickfire> Maybe check for regression?
07:30 <pickfire> I wanted to test out my everytime I boot to emergency shell.
07:30 <pickfire> why*
07:31 <* pickfire> wanted to review as well
07:31 <TemptorSent> Yeah, I got it past that again, now it's acting weird after startup.
07:32 <TemptorSent> Cool, no /lib/modules.
07:32 <pickfire> TemptorSent: Will that make boot slower?
07:32 <kaniini> pickfire: i do not think this is directly your fault, i think something else has broken
07:32 <pickfire> kaniini: Okay
07:33 <TemptorSent> Getting an invalid agument, that's bad.
07:33 <pickfire> kaniini: By the way, can you please tell me how should I bump it next time?
07:33 <kaniini> i think this is an example of "maybe we should not upgrade NSS 1 week before freeze"
07:33 <kaniini> pickfire: grep nss-dev */APKBUILD tbh
07:33 <TemptorSent> Anything break that would be causing BB mount to give me an invalid argument for no apparent reason? Or did I fubar my modules?
07:33 <pickfire> And then apkgrel other stuff?
07:34 <pickfire> BB mount?
07:34 <TemptorSent> BusyBox's mount command.
07:34 <kaniini> pickfire: just update the pkgrel yes
07:34 <pickfire> Yes, I got that as well.
07:34 <TemptorSent> mounting /dev/loop0 on /.modloop/ failed: invald argument
07:36 <kaniini> likely missing filesystem module
07:36 <kaniini> squashfs iirc
07:36 <TemptorSent> Hmm, where'd my squashfs go?
07:36 <TemptorSent> It WAS there.
07:36 <kaniini> i give up on this NSS situation for now
07:36 <kaniini> hopefully ncopa or somebody else can fix it
07:37 <pickfire> TemptorSent: How do you test?
07:38 <pickfire> TemptorSent: Actually, why don't you put mkimage as another project?
07:39 <TemptorSent> pickfire: qemu-system-x86_64 -nographic -cdrom $image
07:39 <pickfire> Ah
07:39 <TemptorSent> pickfire: That's the plan, it just needs to be ready for fabled & ncopa to feel comfortable using it to build releases before getting a repo I believe.
07:40 <TemptorSent> pickfire: For now, its easier not to break tracking until it has a final resting place.
07:49 <TemptorSent> Unknown symbol in squashfs!
07:50 <TemptorSent> squashfs: Unknown symbol lz4_decompress_unknownoutputsize (err 0)
07:52 <TemptorSent> So much for automagical kernel module symbols....
08:05 <TemptorSent> Hmm, adding the entire lz4 suite of modules seems to have fixed it, but lz4_decompress didn't. Very strange.
08:05 <TemptorSent> this is -virtgrsec FWIW.
08:07 <TemptorSent> That seems broken, it shouldn't require any of the other mods according to depmod.
08:09 <TemptorSent> pickfire: Okay, what's I just pushed is working for me with the virt image and qemu with no noted issues, if you can give it a run and verify at least that is working elsewere, I'll start tying up loose ends.
08:09 <pickfire> I can't find your branch
08:09 <TemptorSent> (my brain apparently isn't working, but the code is :)
08:10 <TemptorSent> https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
08:10 <TemptorSent> (unless I can't type again, sanity check if link fails)
08:11 <clandmeter> almost 1k backlog for one mist evening/night
08:11 <clandmeter> good morning
08:11 <pickfire> clandmeter: evening
08:12 <TemptorSent> clandmeter Good morning, and yeah, we had quite a discussion regarding both security and implications and some depth on how to deal with commiter granualrity and solving some of the breakage issues with tools.
08:12 <pickfire> No wonder
08:12 <TemptorSent> pickfire : an hour and a half ago it would have been good evening still ;)
08:12 <pickfire> TemptorSent: I get the wrong url
08:13 <pickfire> TemptorSent: It is already night nowL
08:13 <TemptorSent> pickfire: Sorry, I'm braindead tonight.
08:13 <pickfire> ?
08:13 <pickfire> I thought it is just aroud 7 there?
08:14 <TemptorSent> pickfire: I'm Pacific time - PST8PDT
08:14 <pickfire> pasific time?
08:14 <pickfire> Thu 23-Mar-2017 01:14 A.M.
08:14 <pickfire> Wow
08:15 <pickfire> It's too late
08:15 <TemptorSent> https://github.com/TemptorSent/aports/tree/mkimage-refactor-scripts/scripts/mkimage
08:15 <pickfire> TemptorSent: I just run that or build that package?
08:16 <TemptorSent> pickfire: it's shell script :) ./mkimage.sh --help should get you started.
08:16 <pickfire> I don't like --help
08:16 <pickfire> -h works?
08:16 <TemptorSent> pickfire: Um, yes, it does :)
08:17 <pickfire> Of course it does >>> WARNING: mkimage.sh: Unrecognized option '-h'
08:17 <TemptorSent> pickfire: Because it doesn't exist otherwise.
08:17 <pickfire> Yeah
08:17 <TemptorSent> For that matter, neither is --help :P
08:17 <pickfire> TemptorSent: Have you tested it without gnu userland and bash?
08:18 <TemptorSent> I suppose I could fix that tno noop.
08:18 <TemptorSent> bash? What bash?
08:18 <TemptorSent> It should be pretty much 100% BB compliant
08:18 <pickfire> TemptorSent: Segmentation fault
08:19 <TemptorSent> The only 'bashism' is one of the ones in ash that's used all over the place ${var//s/re/}
08:19 <TemptorSent> pickfire : Woah! Segv?
08:19 <TemptorSent> pickfire : On what?
08:19 <TemptorSent> oh, needs fakeroot installed, but that shouldnt' segv
08:20 <TemptorSent> What was the message before it died?
08:20 <pickfire> ${var//s/re/} is acceptable but note that it is not in dash
08:20 <pickfire> TemptorSent: http://ix.io/pc2
08:21 <pickfire> I run it with ./mkimage.sh
08:21 <TemptorSent> pickfire: Noted, which is a PITA.
08:21 <pickfire> Because the help is TL;DR
08:21 <TemptorSent> Oh, shit -- I haven't even tried without giving it a profile in a long time!
08:21 <TemptorSent> give it --profile virt
08:21 <pickfire> Yes, getting help is slo
08:21 <pickfire> I mean getting help takes seconds
08:22 <pickfire> TemptorSent: Where did you test it on?
08:22 <TemptorSent> pickfire : Yeah, it loads the plugins and loads everything before it displays help so it can give you the lists of located plugins and whatnot.
08:23 <pickfire> Loads plugin took so long?
08:23 <TemptorSent> pickfire: I could short-circuit to short-help I suppose.
08:23 <pickfire> Yeah, probably
08:23 <TemptorSent> pickfire: Scans directory hierarchies, finds all functions, inits vars.
08:23 <pickfire> TemptorSent: The output is in stderr, are you sure about that?
08:24 <TemptorSent> pickfire: Which output is in stderr?
08:24 <pickfire> TemptorSent: Want me to test that out in pi?
08:24 <pickfire> I mean just to test performance.
08:24 <TemptorSent> Please! I haven't gotten to even attempting those targets.
08:25 <TemptorSent> The killer currenty is the list building that ends up with a lot of calls to sort -u
08:25 <TemptorSent> I'm on a second-hand mid-gen xeon
08:28 <TemptorSent> pickfire: There is definitely some room for improvement in terms of efficency, but at current the tradeoff for simple implementations with easy debugging seems more important than speed for something that should't be a high-duty-cycle utility.
08:29 <pickfire> Okay so it is built for ease of use instead of performance
08:29 <pickfire> TemptorSent: Which profile should I build?
08:30 <TemptorSent> pickfire: It was built for ease of modification/extension/maintainability really.
08:30 <TemptorSent> pickfire : Try virt
08:30 <pickfire> TemptorSent: http://ix.io/pc3
08:30 <pickfire> Fail to build
08:30 <ncopa> kaniini: did nss break ABI?
08:30 <pickfire> ncopa: Yes
08:30 <ncopa> ugh
08:30 <pickfire> ncopa: Now nss uses ABI 7
08:30 <pickfire> What is that actually?
08:31 <ncopa> sounds like a version number
08:31 <pickfire> Wait, is it?
08:31 <TemptorSent> pickfire: Is apk working properly on your system otherwise? That looks like what's dying.
08:31 <pickfire> ncopa: I might be mistaken that for imagemagick
08:31 <pickfire> Oh oshi
08:31 <pickfire> kaniini: imagemagick is another case of nss
08:32 <pickfire> GG
08:32 <ncopa> i think i rebuilt all affected packages for imagemagick abi breakage
08:32 <pickfire> Ah
08:32 <pickfire> ncopa: How do you do that?
08:32 <ncopa> bump pkgrel
08:32 <ncopa> to make it rebuild
08:32 <pickfire> clandmeter: With grep?
08:32 <TemptorSent> pickfire: can you run with sh -x to verify that it's apk?
08:32 <pickfire> ncopa: ^
08:33 <ncopa> apk search -r so:libfoo.so.$oldverion
08:33 <ncopa> first i do checkapk
08:33 <ncopa> find out the old SONAME
08:34 <ncopa> then i search for packages that depends on that
08:34 <ncopa> using apk search -r
08:34 <ncopa> for each of those i bump pkgrel
08:34 <ncopa> and rebuild
08:34 <ncopa> zbar had some hardcoded path to a library file
08:34 <ncopa> which i had to update
08:34 <ncopa> i dont know if it still works
08:34 <TemptorSent> Ouch, that's just sick.
08:36 <pickfire> TemptorSent: paste
08:36 <pickfire> shitty
08:36 <pickfire> TemptorSent: /dcc?
08:36 <pickfire> ncopa: Wow, so complicated
08:37 <pickfire> TemptorSent: https://transfer.sh/ea7OH/out⏎
08:37 <TemptorSent> sh -x ./mkimage --profile virt --repository-file /etc/apk/repositories
08:38 <pickfire> TemptorSent: that works right now
08:38 <pickfire> mv: replace '/tmp/tmp/mkimage.Gxt2Zi/apks-x86_646fd4-c104e5692bddd66d7f78c999836b16a11eab4e70.work/apks/x86_64/APKINDEX.tar.gz', overriding mode 0644 (rw-r--r--)?
08:38 <pickfire> What do I do?
08:38 <TemptorSent> Yeah, that's a bug in abuild-sign
08:38 <TemptorSent> Hit yes.
08:39 <TemptorSent> Sorry, forgot to figure out where to report it.
08:40 <pickfire> TemptorSent: mail to alpine-bugs
08:40 <TemptorSent> Is there a way to directly tag a line in a file in github.
08:41 <TemptorSent> https://github.com/alpinelinux/abuild/blob/master/abuild-sign.in#L39
08:41 <TemptorSent> Now can I send that to a bugbot?
08:41 <ncopa> whats wrong with nss?
08:42 <TemptorSent> Or do I need to go find a windoze box and log into my gmail.
08:43 <pickfire> yes, I had built it
08:43 <pickfire> ncopa: I heard the package that depend on nss are not bumped.
08:44 <TemptorSent> Okay, looks like apk has a another bug if you're getting a segv without specifying the repo...
08:44 <ncopa> did the SONAME change?
08:45 <TemptorSent> pickfire: I'm getting the same when no repo is specified, let me see if it will strace
08:45 <pickfire> ncopa: Not sure about that.
08:46 <ncopa> $ apk info --provides nss | tpaste
08:46 <ncopa> http://tpaste.us/NRMv
08:46 <ncopa> AFAICS it didnt
08:48 <ncopa> https://bugzilla.mozilla.org/show_bug.cgi?id=1340103
08:48 <TemptorSent> pickfire: strace appears to confirm that apk is being forked and puking, not sure how to easily instrument the called apk without breaking the rest.
08:52 <TemptorSent> pickfire: Found cause of apk being fed bogus command line, out of order var assignment, but apk should still not segv.
08:52 <TemptorSent> ncopa: I have a reliable reporoduceable segv in apk for you :)
08:53 <ncopa> thanks
08:53 <TemptorSent> pull current rev of my branch and run with ./mkimage --profile virt WITHOUT specifying a repo.
08:53 <pickfire> TemptorSent: how do I remove the block device from console to test modloop?
08:53 <ncopa> can you reproduce it without needing pull any branch?
08:53 <ncopa> i am in the middle of kernel build...
08:53 <TemptorSent> pickfire: Block device from console?
08:53 <pickfire> TemptorSent: Yeah
08:54 <ncopa> + im am trying to figure out how to clean up the nss mess
08:54 <pickfire> I don't know how to remove that
08:54 <ncopa> + i need make sure ppc64le builder continue build
08:54 <TemptorSent> ncopa, no problem I'll make the commit msg obvious.
08:54 <TemptorSent> pickfire: modloop?
08:54 <ncopa> + i need figure out why scp the buildlogs from ppc64le builder is so slow
08:54 <pickfire> Yes
08:54 <pickfire> Oh
08:55 <ncopa> + i need get the s390x builder up
08:55 <TemptorSent> pickfire it's in the image :)
08:55 <pickfire> TemptorSent: I mean I just want to test it out
08:55 <TemptorSent> to unmount it do umount /.modloop
08:55 <pickfire> No
08:55 <pickfire> TemptorSent: I mean remove the block device
08:56 <pickfire> Like how I remove the usb drive
08:56 <TemptorSent> pickfire: qemu-system-x86_64 -nographics -cdrom $.iso
08:56 <pickfire> Then?
08:56 <TemptorSent> pickfire: loop0?
08:56 <TemptorSent> pickfire : You should have a virtual environment :)
08:56 <TemptorSent> $ being your filename
08:56 <pickfire> Yeah
08:57 <TemptorSent> pickfire: I believe that is what's mounted on /mnt/.modloop
08:57 <pickfire> TemptorSent: ide1-cd0 (#block109): alpine-virt-20170323-x86_64.iso (raw, read-only)
08:57 <pickfire> Removable device: locked, tray closed
08:57 <pickfire> Cache mode: writeback
08:57 royger joined
08:58 <TemptorSent> pickfire : Okay, no idea what's going on there.. that's the cdrom image, right?
08:58 <pickfire> Yeah
08:58 <TemptorSent> pickfire: Is that inside or outside the vm?
08:58 <pickfire> TemptorSent: In qemu console, do info block
08:59 <TemptorSent> pickfire : Oh, okay!
09:00 <pickfire> TemptorSent: wait4(-1, 0x7338522881ec, WNOHANG, NULL) = -1 ECHILD (No child process)
09:00 <pickfire> Something is wrong with something
09:00 t0mmy joined
09:01 <TemptorSent> Yeah, it sounds like it! I have been getting qemu issues too, but I can't see anythign in the images that would be any more of a problem.
09:01 <pickfire> TemptorSent: stat("/tmp/tmp/mkimage.olsHp2/.apkroot-x86_64/etc/apk/repositories", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
09:01 <pickfire> Looks like that apk repo is empty
09:02 <TemptorSent> pickfire: If modloop is mounted, your cd device will remain busy unless loaded to ram.
09:02 <pickfire> TemptorSent: How to load to ram?
09:02 <TemptorSent> pickfire: Non-existent, which is what's crashing apk, since it doen't have any defined.
09:02 <pickfire> I want to see if it really loaded in ram, that's why I am trying to remove that block device.
09:02 <pickfire> TemptorSent: What is 17:02 < TemptorSent> pickfire: Non-existent, which is what's crashing apk, since it doen't have any defined.
09:02 <TemptorSent> pickfire: I think it's on the wiki :) You make a tmpfs and copy it there.
09:03 <TemptorSent> pickfire unmount the modloop, then unmount the cd
09:03 <TemptorSent> pickfire I don't think there's anything on the modloop you need.
09:04 <pickfire> TemptorSent: Normally, I would just remove the usb straight without unmount.
09:04 <TemptorSent> pickfire: The repo it's trying to init is non-existent, and since no repo was passed, it fails miserably.
09:05 <pickfire> TemptorSent: Tested and working.
09:05 <pickfire> No need to unmount
09:05 <pickfire> Just remove the disk
09:06 <pickfire> AH
09:07 <pickfire> TemptorSent: lololol
09:07 <pickfire> drive_del ide0-hd0 * Remounting devtmpfs on /dev ... [ ok ]
09:07 <pickfire> (qemu) * Mounting modloop ... [ !! ]
09:08 <TemptorSent> pickfire: Not sure why it thinks it's busy.
09:08 <pickfire> * ERROR: modloop failed to start
09:08 <pickfire> * Loading modules ...modprobe: can't change directory to '/lib/modules': No such file or directory
09:08 <pickfire> [ ok ]
09:08 <pickfire> Why?
09:08 <TemptorSent> probably the rc-script :)
09:08 <pickfire> What is modloop exactly? It works without modloop as well.
09:08 <TemptorSent> I haven't modified anythign in that respect that I'm aware of.
09:08 <TemptorSent> modloop is the entire mass of kernel drives in a squashfs
09:09 <pickfire> TemptorSent: What if there is no modloop?
09:09 <TemptorSent> pickfire; You're fine as long as you don't need to load any modules not already present :)
09:09 <pickfire> TemptorSent: No, the one above, I have remove the drive before modloop was mounted
09:10 <pickfire> TemptorSent: I think modloop should be mounted in sysinit
09:10 <TemptorSent> pickfire: I believe it is?
09:10 <pickfire> Because others wants to unplug their usb as soon as possible.
09:10 <pickfire> not sure, didn't check
09:10 <TemptorSent> pickfire: or perhaps boot.
09:11 <pickfire> Sysinit is before boot right?
09:11 <TemptorSent> pickfire: We could copy it to ram with a cmdline option perhaps.
09:11 <pickfire> What is it?
09:11 <TemptorSent> pickfire: Yes, the way it works now is it tries to load all hw modules before you yank the drive I believe.
09:12 <pickfire> Probably.
09:12 <TemptorSent> modloop is in sysinit.
09:13 <pickfire> Ah, looks like apks are mounted in /media/sda1/apks/x86_64/ as well in ram.
09:13 <TemptorSent> The reason for using modloop in the first place is to avoid the memory usage of loading the entire module repo into ram
09:13 <pickfire> TemptorSent: Then where did it store?
09:13 <TemptorSent> pickfire: Yeah, forgot the boot repo too.
09:14 <TemptorSent> pickfire : It's on the media, allowing you to only load what you need to ram.
09:14 <pickfire> Yeah
09:14 <TemptorSent> As long as you load all needed modules at boot, you should be able to safely unmount it.
09:14 <pickfire> And apk does't check /media/sda1 from what I last checked.
09:14 <TemptorSent> pickfire: On VMs, we probably don't want nor need it.
09:15 <pickfire> Oh
09:15 <pickfire> TemptorSent: What about containers?
09:15 <TemptorSent> pickfire: nlplug + .bootrepository
09:15 <pickfire> ?
09:15 <TemptorSent> pickfire : It knows how to make rootfs images too, although I haven't tested that lately.
09:15 <pickfire> I mean why would one want to use alpine in VM?
09:16 <pickfire> TemptorSent: Rootfs is the first choice for me to install alpine alongside other distro.
09:16 <TemptorSent> pickfire: Because VMs let you run different kernels for differnt needs.
09:16 <pickfire> Like what?
09:17 <TemptorSent> pickfire: I have enabled the profiles building in apks to the root fs, and added a flag to include all apks as rootfs apks, so it shoouldnt be far off.
09:17 <pickfire> ?
09:17 <TemptorSent> pickfire: network, file server, storage, etc.
09:18 <pickfire> ?
09:18 <TemptorSent> pickfire: You can build small, tight kernels for each application, including doing things like runing BSD for your ZFS if you want to :)
09:18 <pickfire> Oh, like running windows.
09:18 <TemptorSent> pickfire: Take a look at profiles/minirootfs
09:19 <TemptorSent> pickfire: Yeah, if you need to spin up a windoze instance, you don't have to share your box with it :)
09:20 <pickfire> Yeah, that's what I like but it is slow.
09:20 <TemptorSent> pickfire: Having your kernel for your DB server tuned to the same page size, as your db record chunk size can be a BIG win, but is really wastefull of ram for things throwing around a lot of small data.
09:21 <TemptorSent> pickfire: It certainly is applicaion dependent.
09:21 <pickfire> Oh, that's weird. Haven't heard of it.
09:21 <TemptorSent> pickfire: PostgreSQL likes 8k, for instance
09:22 <TemptorSent> pickfire: As do many SSD
09:22 <pickfire> Oh
09:22 <pickfire> 8k what?
09:22 <TemptorSent> pickfire: The default 4k can cause write-amplification and alignment issues
09:22 <TemptorSent> page size
09:23 <pickfire> I didn't know page size affects
09:23 <TemptorSent> IO page size
09:23 <pickfire> I also like vm for dev, alpine musl is too broken
09:23 <TemptorSent> pickfire: We've come a long way since 512byte io chunks.
09:24 <pickfire> Ah
09:24 <TemptorSent> pickfire: PostgreSQL uses 8k pages, so aligning everything to that is a big win.
09:25 <pickfire> export PACKAGES="alpine-baselayout,apk-tools,alpine-keys,libc-utils", that's on alpine
09:25 <pickfire> Maybe switch to that?
09:26 <pickfire> Weird, why arch is armhf
09:26 <TemptorSent> pickfire: Where is that?
09:26 <pickfire> No, armv6l? armv6h? armv7l? armv7h? Like the one provided in alarm.
09:27 <TemptorSent> Oh, the rpi profile?
09:27 <fabled> it's armv6 with hardfloat
09:28 <fabled> basically for rpi1 cpu
09:28 <TemptorSent> I just ported over the existing profiles for the most part, so if we need to fix them, let me konw.
09:28 <pickfire> fabled: But we don't do build for different versions?
09:28 <fabled> not yet
09:28 <fabled> we do have armv7 arch defined but not built
09:28 <TemptorSent> I know I'd like to see my pi with 64bit support.
09:28 <fabled> that'd be aarch64
09:29 <fabled> but i'm not sure if that works on rpi yet
09:29 <fabled> even upstream that is
09:29 <pickfire> No
09:29 <TemptorSent> fabled: Sorta, pis are weird :)
09:29 <pickfire> It does't work
09:29 <pickfire> doesn't=
09:29 <pickfire> https://archlinuxarm.org/about/downloads
09:29 <TemptorSent> There's some trickery that needs to be fixed with the bootloader handoff still, and I don't think it has vcore yet.
09:29 <pickfire> fabled: pi 3 is armv7 although capable of using armv8
09:30 <pickfire> pi 1 need armv6
09:30 <TemptorSent> pi2 is v7 as well IIRC.
09:30 <pickfire> TemptorSent: Yeah
09:30 <pickfire> Same as pi 3 although it can use arcch* or whatever called
09:31 <pickfire> TemptorSent: https://archlinuxarm.org/platforms
09:31 <pickfire> Look at the architecture supported
09:31 stwa joined
09:33 <TemptorSent> pickfire yeah, V6 fo pi1, v7 cortex a7 for pi2 series, and v8 cortex-a53 for pi3s
09:33 <pickfire> TemptorSent: -rw-r--r-- 1 ivan users 1.9M Mar 23 17:33 alpine-minirootfs-20170323-x86_64.tar.gz
09:33 <pickfire> TemptorSent: I will send in a patch
09:34 <TemptorSent> pickfire: Sounds good.
09:34 <pickfire> TemptorSent: Can we set the output format?
09:34 <pickfire> https://github.com/gliderlabs/docker-alpine/blob/60d6d06885459a9fa7e5d51d986be89ce61d9c41/versions/library-edge/options
09:34 <TemptorSent> pickfire: Yes, what do you want?
09:34 <pickfire> TemptorSent: tar.xz?
09:35 <TemptorSent> holy crap, I hope I don't have to type that.
09:35 <pickfire> Or uncompressed
09:35 <TemptorSent> pickfire: Sure, give me a minute.
09:35 <pickfire> Type what holy crap?
09:39 <TemptorSent> pickfire that URL.
09:40 <pickfire> Cannot copy paste?
09:40 <pickfire> TemptorSent: Here https://github.com/gliderlabs/docker-alpine/blob/master/versions/library-edge/options
09:41 <TemptorSent> pickfire: no, not on this terminal since somone killed GPM off.
09:41 <pickfire> GPM?
09:41 <TemptorSent> pickfire: tar and tarxz added.
09:41 <TemptorSent> General Purpose Mouse :)
09:42 <pickfire> Ah
09:42 <pickfire> Then no tmux?
09:43 <pickfire> TemptorSent: Why don't we use short flags?
09:43 <TemptorSent> pickfire I have tmux on my dev output term, but it doesn't help across terms.
09:43 <pickfire> Ah
09:43 <TemptorSent> pickfire: I didn't make them up :)
09:43 <pickfire> How did you get it then?
09:43 <TemptorSent> pickfire: So far, it's mostly compatible with the old mkimage.
09:44 <TemptorSent> pickfire: I started with a small mess and made a big one *GRIN*
09:44 <pickfire> Ah
09:44 <pickfire> I think I have tried the old one out, simple to use.
09:45 <TemptorSent> pickfire: Yeah, as long as you wanted to build the existing profiles.
09:45 <pickfire> TemptorSent: tarbzip
09:45 <pickfire> Lol
09:45 <TemptorSent> pickfire: or add a few more apks.
09:46 <TemptorSent> tarbz2 good enough? :)
09:47 <TemptorSent> pickfire: Any OTHERS? Do you want tarlzo and tarZ too?
09:48 <TemptorSent> pickfire: I guess I need to add my archive util afterall.
09:49 <pickfire> TemptorSent: http://ix.io/pca
09:49 <pickfire> Yes there are others
09:49 <pickfire> lz4
09:49 <pickfire> lz0
09:49 <pickfire> zip
09:49 <TemptorSent> pickfire: Give me a list, I'll add 'em.
09:49 <pickfire> zstd
09:49 fekepp joined
09:49 <pickfire> bro
09:50 <TemptorSent> pickfire : For images, not every compression format known!
09:50 <pickfire> TemptorSent: But those are the popular ones
09:50 <TemptorSent> I've got a util that detects an extracts pretty much all of 'em.
09:51 <TemptorSent> pickfire: I mean what else do we need for image files
09:51 <pickfire> Nothing much
09:52 <TemptorSent> pickfire: Oh, yeah - that's redundant in miniroot :)
09:52 <pickfire> Weird, gliderlabs alpine is 4MB and ours is 1MB
09:52 <TemptorSent> pickfire: Hmm, what's missing/broken?
09:53 <pickfire> TemptorSent: I haven't tested out everything since it's so messy.
09:53 <pickfire> I mean the output
09:53 <TemptorSent> pickfire: ??
09:53 <pickfire> 1 --help 2 while running
09:54 <TemptorSent> Which output is messy?
09:54 <pickfire> I mean no color
09:54 <TemptorSent> Oh, export USE_COLORS :)
09:54 <TemptorSent> or 'USE_COLORS=1 ./mkimage.sh'
09:55 <pickfire> $scriptdir/utils/utils-basic.sh
09:55 <pickfire> Ah
09:55 <TemptorSent> I suppose I could default that on.
09:55 rrx joined
09:55 <TemptorSent> Same env as elsewhere in alpine I believe.
09:56 <TemptorSent> 1 --help 2 ?
09:56 <pickfire> TemptorSent: What is the difference between --repository-file and --repository
09:57 <TemptorSent> --repository-file lets you include a file like /etc/apk/repositories, --repository sets a single repository, and --extra-repositories adds additional repos to the list
09:57 <TemptorSent> I inherited the latter behavior and left it just in case somethign is using it.
09:57 <pickfire> I think the output need redesign.
09:57 <pickfire> >>> mkimage.sh:x86_64:minirootfs:build apk repo:x86_64: Fetching required apks recursively...
09:57 <pickfire> alpine-baselayout alpine-keys apk-tools busybox libc-utils
09:58 <pickfire> I don't understand what is that.
09:58 <TemptorSent> pickfire: Debugging sanity :)
09:58 <pickfire> Ah
09:59 <pickfire> What about those not debugging?
09:59 <TemptorSent> pickfire: It's the stage at the build we'er at.
09:59 <pickfire> Is it optional?
09:59 <TemptorSent> pickfire: I need to add back the quiet option.
09:59 <pickfire> Nice
09:59 <TemptorSent> pickfire : It's all in utils-info.
10:00 <TemptorSent> pickfire: At some point I was going to clean it up into a couple levels of verbosity, but that's later.
10:00 <pickfire> TemptorSent: utils/info.sh is nice, why go utils/utils-info.sh
10:00 <TemptorSent> For now, debugging is good.
10:00 <TemptorSent> pickfire: Because I can glob utils-* :)
10:01 <TemptorSent> pickfire: Which I intend to do rather than loading each individually.
10:01 <pickfire> TemptorSent: glob utils/*.sh?
10:01 <pickfire> Then make those utils/* without .sh inactive
10:01 <TemptorSent> pickfire: No, because I want to be able to mix and match in user profiles easily stil,.
10:02 <pickfire> TemptorSent: Does it supported building multiple arch without rebuilding?
10:02 <TemptorSent> I can load additional utils using the plugin loader :)
10:02 <TemptorSent> pickfire: Yup, I had it building aarch64 until I hit an apk bug.
10:02 <pickfire> TemptorSent: So it can build all the arch at once?
10:03 <TemptorSent> Now I can't build aarch64 because I have my x86_64 local repo, but no aarch content and apk pukes.
10:03 <pickfire> ?
10:03 <TemptorSent> pickfire: It should accpet multiple archs.
10:03 <TemptorSent> pickfire: I havenn't given that much testing, but it's just fed into the outer loop.
10:04 <TemptorSent> pickfire: The profiles and features themselves determine if they work on that arch.
10:04 <pickfire> Ah
10:05 <TemptorSent> pickfire: the invocation and command parsing actually needs to get thrown into a function too, then we can use it as a multi-call script that does mkimage, mkinitfs, and update-kernel.
10:05 <pickfire> fcolista: Is testing/subtitleeditor: new aport the format for a newapkbuild?
10:05 <TemptorSent> pickfire: and add mkapkovl, mkmodloop, etc.
10:06 <fcolista> pickfire, no
10:06 <fcolista> did it by hand
10:06 <pickfire> fcolista: Need not to do so
10:06 <pickfire> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Commit_your_work
10:06 <fcolista> or if you are referring generally at the new format and not to newapkbuild, then yes
10:06 <pickfire> Huh?
10:06 <fcolista> The command
10:06 <pickfire> I mean commit format
10:06 <fcolista> newapkbuild "PKG
10:07 <fcolista> *$PKG
10:07 <pickfire> TemptorSent: What's that?
10:07 <pickfire> fcolista: No, I mean git commit format
10:07 <TemptorSent> pickfire: Since it has the ability to build a complete image, or any part of one, it would be nice to expose those other functions directly so we can use them at will.
10:07 <fcolista> pickfire, since when this become the standard, and where it was announced?
10:08 <pickfire> fcolista: git show 800fc5058
10:08 <pickfire> I am not sure but it was in the wiki
10:08 <pickfire> I thought this is a standard?
10:08 <pickfire> TemptorSent: Ah
10:09 <pickfire> Haven't fully review yet but at least working for me.
10:09 <TemptorSent> pickfire: mkmodloop is going to learn how to make a cut-down modloop as soon as I get time.
10:10 <pickfire> How is that different from modloop?
10:10 <TemptorSent> pickfire: run unsquashfs -l on /boot/modloop-grsec on your box...
10:10 <fcolista> pickfire:
10:10 <fcolista> git log --all --grep="new aport"
10:11 <fcolista> does not seems it's "a standard" followed by many apparently
10:11 <pickfire> fcolista: Followed by some
10:11 <fcolista> probably, if this is the standard, should be announced
10:11 <fcolista> This is the first time i heard that..
10:12 <pickfire> fcolista: Where should it be announced?
10:12 <pickfire> Maybe ask ncopa
10:12 <TemptorSent> pickfire (or build one of the other profiles)
10:13 <pickfire> TemptorSent: Like?
10:13 <TemptorSent> pickfire: it contains the ENTIRE set of kernel modules for your installed kernel.
10:13 <fcolista> ML? By saying that there's a new doc in the wiki where was updated info about how to create APKBUILD?
10:13 <pickfire> Wait, I am packaging other stuff new
10:13 <TemptorSent> Every useless driver.
10:13 <pickfire> now*
10:13 <fcolista> Just wondering.
10:14 <pickfire> fcolista: alpine-devel?
10:14 <fcolista> That's the most natural place
10:14 <pickfire> Ah, I actually thought that is a standard.
10:15 <TemptorSent> pickfire: If we want a kitchen-sink-support image, that's great, but for something that's supposed to be lean, incuding 50mb of modules is absurd!
10:15 <pickfire> Yeah
10:16 <TemptorSent> pickfire: Most modern pcs just need the ahci driver and usb drivers and not much else for storage.
10:17 <TemptorSent> pickfire: Add a few common raid / sas cards and you've covered 75% or better with a significantly smaller footprint.
10:17 <pickfire> TemptorSent: lvm?
10:17 <pickfire> TemptorSent: Does it have a rescue disk?
10:17 <pickfire> I mean rescue disk profile.
10:17 <TemptorSent> pickfire: lvm isn't too big, but it's not always needed.
10:18 <TemptorSent> pickfire : there wasn't one existing, but I think it would be useful.
10:18 <TemptorSent> pickfire: everything critical in the initramfs so you can exit to boot after fixing things.
10:18 <pickfire> luks?
10:19 <pickfire> ecryptfs?
10:19 <TemptorSent> cryptsetup is in with lvm and raid under md.
10:19 <pickfire> dmcrypt?
10:19 <pickfire> TemptorSent: Why is cryptsetup with lvm?
10:19 <TemptorSent> The rest I'm not aware of previously existing boot support unles it's through nlplug
10:19 <pickfire> I thought it should be separated?
10:20 <TemptorSent> pickfire: They'er all part of the dm subsystem. They are separate initfs-features, just in the same dir
10:20 <pickfire> Ah
10:21 <TemptorSent> I tried to make the initfs-feature nameing more or less follow the kernel convention where it makes sense.
10:21 <TemptorSent> I'd love to have someone else go over the names because I just threw it at a wall.
10:22 <TemptorSent> pickfire: I haven't gone as far as analyzing all the interdependencies between modules because depmod is SUPPOSED to do that, excpet for the damn lazyloaded symbols in the libs.
10:22 <pickfire> depmod?
10:23 <pickfire> I don't have much knowledge about modules
10:23 <TemptorSent> pickfire: But as the features mature, the cooresponding initfs features should migrate there.
10:23 <pickfire> Ah
10:23 <TemptorSent> pickfire: It nicely pulls the dep chain, except it misses lazy-loaded symbols, like the lz4 decompression libs.
10:24 <TemptorSent> pickfire: So when you enable a feature such as zfs, it includes the appropriate modules, adds the initfs features, and includes the init code needed.
10:25 <TemptorSent> As well as adding the userspace, setting up runlevel links, installing config files, and the rest.
10:25 <pickfire> Wow, I know that getting zfs is impressive
10:25 <TemptorSent> pickfire: Eventually (soon) it will know something about filesystems and how to make them.
10:26 <TemptorSent> pickfire: zfs works now :)
10:26 <pickfire> TemptorSent: But I hope you still keep the core prinsiple of alpine - Small. Simple. Secure.
10:26 <pickfire> Well, it isn't small
10:27 <TemptorSent> pickfire: That's the whole point of this exercise, let the tools do the heavy lifting so you can make a system that's exactly what you need and nothing more.
10:27 <pickfire> At least, creating plugin is still simple
10:28 <TemptorSent> pickfire: Yeah, you create a file called plugin-whatever.sh either in the mkimage dir, your ~/.mkimage, or some other dir adn point mkimage to it.
10:28 <TemptorSent> Define the plugin-whatever() function which is called when the plugin is loaded, and do whatever you want from there.
10:28 <TemptorSent> er plugin_whatever() :)
10:30 <ncopa> kaniini: it looks like fedora is switching to pkgconf
10:30 <TemptorSent> pickfire: If a meg worth of shell script gets us down to a meg or two containers, it pays off.
10:31 <TemptorSent> pickfire: especially if we can preconfigure images for specific hosts easily.
10:31 <ncopa> kaniini: maybe you told me earlier and i forgot. in any case, pkgconf is taking over the world!
10:31 <TemptorSent> pickfire: take a look at the features/ssh for instance.
10:32 <pickfire> Ah
10:32 <ncopa> https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
10:32 <pickfire> ncopa: I actually thought pkgconf is pkg-config
10:33 <ncopa> well
10:33 <clandmeter> http://pkgconf.org/features.html
10:33 <ncopa> there used to be only a freedesktop implementation of it
10:33 <ncopa> they use glib
10:33 <ncopa> it worked all fine
10:33 <ncopa> til one day
10:34 <ncopa> when they stopped bundle glib in pkg-config
10:34 <pickfire> What happened next?
10:34 <ncopa> which means you need system glib to build it
10:34 <clandmeter> chicken egg story :)
10:34 <* pickfire> is exciting
10:34 <ncopa> but glib needs pkg-config to build
10:34 <pickfire> Looks like an interesting story
10:34 <ncopa> so you get circular dependency
10:34 <pickfire> excited*
10:34 <ncopa> and need bootstrap it
10:34 <pickfire> Ah
10:34 <ncopa> you'd need build limited version of glib first
10:35 <TemptorSent> What's old is new again :)
10:35 <ncopa> then with that, you'd build pkg-config
10:35 <pickfire> So pkg-config is egg and glib is chicken
10:35 <ncopa> and with that pkg-config you'd build full glib
10:35 <TemptorSent> Anyone remember bootstrapping all three levels of GCC?
10:35 <pickfire> I thought glib is fat?
10:35 <ncopa> just crazy
10:35 <ncopa> yes
10:35 <skarnet> can't pkgconf build full glib?
10:35 <skarnet> I thought it could.
10:35 <ncopa> and the use of glib in the first place was mostly for convenience
10:35 <ncopa> it think we complained about it
10:35 <ncopa> but nobody cared
10:36 <clandmeter> kaniini cared :)
10:36 <pickfire> So it get into a fat chicken.
10:36 <ncopa> so kaniini made his own implementation of pkg-config, pkgconf
10:36 <skarnet> convenience?
10:36 <pickfire> I cared
10:36 <skarnet> how can glib possibly be convenient
10:36 <ncopa> without the glib depndency
10:36 <pickfire> Ah, I didn't know pkgconf was made by kaniini
10:36 <ncopa> skarnet: i have no idea why they used it
10:36 atmoz joined
10:37 <TemptorSent> skarnet: you can shoot yourself in the foot twice as fast with it! That's convenience!
10:37 <ncopa> we switched to pkgconf relatively early
10:37 <pickfire> ncopa: Why not we use it?
10:37 <ncopa> we have used it for years
10:37 <pickfire> Since when?
10:37 <ncopa> since it worked
10:37 <clandmeter> check gitlog
10:37 <TemptorSent> glib has some useful utility functions and isn't too hideously overweight.
10:37 <pickfire> ncopa: We are not using iproute2
10:38 <pickfire> We still use the ancient net-tools in busybox
10:38 <skarnet> TemptorSent: there's nothing you can achieve with glib you cannot achieve with just a libc
10:38 <ncopa> what is interesting is that it is fedora/redhat that pushed freedesktop?
10:38 <TemptorSent> skarnet: Agreed, just explaining why it's actually useful, as opposed to pure bloat.
10:38 <skarnet> but I guess g_ prefixes look beautiful to GNU people
10:38 <ncopa> so i actually expected them to stick to freedestop pkg-config
10:39 <pickfire> g_ = fat
10:39 <ncopa> but now they are switching to pkgconf
10:39 <ncopa> which i think is the only sane thing to do
10:39 <pickfire> s_ = slim
10:39 <ncopa> i think openbsd had a pkg-config implementation in perl
10:40 <skarnet> well the thing about freedesktop is that they provide the only implementation for their demented specs, that's why people use their stuff
10:40 <pickfire> ncopa: What about xdg-open alternatives?
10:40 <skarnet> when a sane implementation comes around, of course people will switch to it
10:40 <TemptorSent> skarnet: It's mostly useful in cases where you have to deal with things such as plugins and late-defined functions/callbacks
10:40 <ncopa> so basically, freedesktop messed up, and kaniini saved the world
10:40 <pickfire> Aha
10:40 <skarnet> TemptorSent: you mean, like, exactly what you shouldn't do in well-designed software?
10:41 <ncopa> i have no opinion about xdg-open
10:41 <pickfire> skarnet: Like what TemptorSent did
10:41 <skarnet> ncopa: well summed up
10:41 <pickfire> Ops
10:41 <TemptorSent> skarnet: Well, if you want something you can extend, it's hard to have a fixed entry.
10:41 <pickfire> ncopa: Nice story, applaud.
10:41 <ncopa> its kaniini that should have the applaud
10:42 <* ncopa> lift the hat off for kaniini
10:42 <TemptorSent> skarnet: And rolling your own reference manager every time gets old.
10:42 <TemptorSent> *applause*
10:42 <skarnet> TemptorSent: I have no idea what you're talking about and I strongly suspect you're making things way more complicated than they should be
10:43 <TemptorSent> skarnet: plugins with functionality not defined in the main program.
10:43 <TemptorSent> skarnet: Used extensivley in many realms of computing.
10:43 <pickfire> kaniini, applaud.
10:44 <pickfire> :)
10:44 <TemptorSent> Personally, I don't use glib because I don't interface much with other glib based software at that level.
10:44 <ncopa> kaniini: https://s-media-cache-ak0.pinimg.com/originals/f8/0b/33/f80b33b86bcb4d7934e879db667d2fbd.gif
10:44 <TemptorSent> skarnet: But a discoverable symbol table, reference counting, and callbacks are pretty universally useful.
10:44 <skarnet> you can write plugins without having to load them into the main program's address space. That's why Unix has processes
10:45 <TemptorSent> skarnet: Okay, try that with the GIS datasets I work with.
10:45 <skarnet> I would, if I was working with that kind of app
10:46 <TemptorSent> skarnet: individual channels with tiles approaching a gig.
10:46 <skarnet> data size is not an issue
10:46 <TemptorSent> skarnet: Moving it is.
10:46 <skarnet> but who's talking about moving data
10:46 <TemptorSent> skarnet: How many syscalls do you really want to make when you have say a dozen operations to run on an image.
10:47 <TemptorSent> skarnet: There are many times it is perfectly appropraite to import functionality into an existing context.
10:48 <skarnet> yeah, now you're talking about in-memory representations of large objects, which has nothing to do with the original discussion about pkg-config
10:48 <skarnet> an image processor is a specific type of application where other rules apply
10:48 <TemptorSent> skarnet: No, I was talking about why libraries such as glib are useful, in that they standardize types and interfaces so you can implement such plugins and reasonably expect them to work for a while.
10:49 <pickfire> ncopa: My C skills still sucks, any suggestion for learning C?
10:50 <TemptorSent> skarnet: Compression, encryption, audio/video processing, FEA, database objects (PostGIS!), etc.
10:50 <skarnet> I'll keep on disagreeing, because all my interactions with glib have been on the side of "useless layer of bloat making building stuff actually more difficult instead of easier as they pretend it is", but I have no experience with it from a developer's pov, so I'll take your word for it as far as convenience for the dev goes
10:50 <TemptorSent> pickfire: 'The C Programming Language' 2nd+ edition, K&R
10:51 <pickfire> TemptorSent: Ah, same thing suckless dev told me.
10:51 <TemptorSent> skarnet: I didn't say I *like* glib, only that I undstand it's application and appeal in environments that need to try to interoperate.
10:52 <skarnet> TemptorSent: I guess a bad standard is still better than no standard at all. :P
10:52 <TemptorSent> pickfire: The Art of Computer Programming, D.K.
10:52 <pickfire> Ah
10:52 <TemptorSent> skarnet: In that sort of situation, absolutely.
10:52 <skarnet> well TAOCP is much more generic than K&R
10:53 <pickfire> TemptorSent: from https://teachyourselfcs.com/?
10:53 <skarnet> but really if it's about C for Unix I'd stick to K&R as well as the Stevens books
10:53 <TemptorSent> pickfire Dunno? I have it on my bookshelf somewhere :)
10:53 <skarnet> (starting with Advanced Programming in the Unix Environment)
10:53 <pickfire> I had read unix programming book IIRC
10:54 <pickfire> skarnet: Haven't heard of that.
10:54 <TemptorSent> Yeah, Advanced Programming in the Unix Environment
10:54 <TemptorSent> *lol* Seconded then.
10:54 <ncopa> glib has alot of completely useless things like g_uint
10:54 <skarnet> with the K&R and Stevens books you should mostly be set
10:54 <pickfire> Maybe I will read that as well.
10:54 <TemptorSent> ncopa: Yes, but they are CONSISTENT useless things.
10:55 <skarnet> because unsigned int isn't consistent enough >.>
10:55 <pickfire> ncopa: Yes, I those looks ugly. Like g_str, g_int
10:55 <TemptorSent> skarnet: Actually, its not even a little consistent!
10:55 <skarnet> it's not *less* consistent than g_uint
10:56 <TemptorSent> skarnet: is that a 16 bit int? a 32 bit in? is it bigendian, littlendian, NBO, carry flag available?
10:56 <skarnet> teach me more about problems with integer representation in C
10:57 <ncopa> :)
10:57 <TemptorSent> skarnet: Until you try writing code on all sorts of different hardwre and libs with some crazy ideas of sizes, you THINK they're well defined.
10:57 <ncopa> #include <stdint.h>
10:57 jirutka joined
10:57 <TemptorSent> skarnet: I've seen all of the above and then some when I defined unsigned int
10:57 <TemptorSent> ncopa: Yeah, if you're on a standards compliant system, that works.
10:58 <TemptorSent> Keil C 5 on QNX with oddball ARM HW? Not likely.
10:59 <TemptorSent> M68k? Not looking good.
10:59 <skarnet> I don't even want to imagine building glib and glib-using stuff on those machines
10:59 <TemptorSent> skarnet: Agreed, but I've had to interface such things with worse libraries.
11:00 <TemptorSent> skarnet: I won't even get into trying to write a jtag test program and run it on different harware.
11:00 <skarnet> it's not the job of application software to work around the inconsistencies and bugs of toolchain and board support software
11:01 <TemptorSent> skarnet: So a type with a well-defined specification that I can expect will do the same thing on any platform I'm compiling for is VERY useful in some situations.
11:01 <skarnet> yeah, like uint32_t
11:01 <TemptorSent> skarnet: When that's what you need to talk to, that's what you get.
11:02 <TemptorSent> skarnet Yeah, as long as you don't flip data from one endian machine to another.
11:02 <ncopa> TemptorSent: do you have much experience with glib?
11:02 <skarnet> what are you talking about? you don't pass integers from one machine to another without marshalling it
11:02 <TemptorSent> ncopa: No, I avoid it as much as possible.
11:02 <skarnet> if you do, it's an application bug
11:03 <ncopa> same :)
11:03 <TemptorSent> skarnet: No, it's unfortunate reality.
11:03 <TemptorSent> ncopa: I've had to deal with a lot worse to interface with proprietary hardware/software.
11:03 <skarnet> bugs are an unfortunate reality, it doesn't mean they shouldn't be fixed where they occur
11:03 <ncopa> sorry about that
11:04 <TemptorSent> skarnet: When you have two different endian processors reading from the same address space, you have to be damn careful.
11:04 <ncopa> and yeah, im with skarnet, better fix the bug properly, rather than adapt to a broken real-world
11:04 <ncopa> i mean, when possible
11:04 <skarnet> "two different endian processors reading from the same address space"
11:05 <skarnet> who the hell thought it was a good idea
11:05 <TemptorSent> SMP has spoiled us to thinking our data is generally portable within our systems.
11:05 <TemptorSent> skarnet: FPGAs, video processors, UARTS, network engines, etc... MANY things are layed out for speed, not host convenience.
11:06 <skarnet> that is true, but don't tell me g_uint is the answer
11:06 <TemptorSent> skarnet: word-lengths that are a power of two are a quirk.
11:07 <TemptorSent> g_uint isn't the answer, it's an answer to "How do I write software that I can get the same behaviour on multiple platforms AND have those multiple platforms be able to exchange data seamlessly.
11:08 <skarnet> "use stdint.h and proper marshalling routines"
11:08 <TemptorSent> skarnet: A set of common definitions from a single source that isn't subject to the whims of your OS is a very useful thing in a hostile environment.
11:09 <TemptorSent> skarnet: On what platform?
11:09 <skarnet> in your software. No matter the platform.
11:09 <TemptorSent> stdint.h doesn't even exist on some platforms glib supports IIRC.
11:09 <skarnet> I question that.
11:10 <TemptorSent> that's the point of glib an thigns like it - to provide a consistent set of definitions across all supported platforms, or at least inform you of WHAT it supports.
11:10 <skarnet> More accurately, I question the possibility and easiness of building glib, and applications using it, on such a platform.
11:12 <TemptorSent> Read the wiki on glib :)
11:12 <TemptorSent> Like I said, I don't like it, but I get it.
11:12 <skarnet> anyway, to each their own, but my pov is that it's not a good idea to bloat your software with compatibility layers that may or may not work with weirdo platforms, at the detriment of leanness on standards-respecting platforms.
11:13 <TemptorSent> skarnet: And that tradeoff depends entirely on your application.
11:13 <skarnet> and that's exactly why I spent the past 2 months cleaning up skalibs of 15-year-old compatibility cruft
11:14 <TemptorSent> skarnet: But believe it or not, there are still people out ther running machines that haven't been down in more than 20 years!
11:14 <skarnet> yeah, yeah, I'll get them a medal
11:15 <TemptorSent> skarnet: I don't mean PC's setting uptime records, I mean machines working day in and day out.
11:15 <TemptorSent> skarnet: A lot of those are still running on old Sun, HP, and DEC hardware.
11:16 <skarnet> what, you want a dark chocolate medal instead of a cheap Hershey's one? ok, ok, dark chocolate it is
11:16 <TemptorSent> So when you look at data portability, you get to consider everything from Sparc to Itanium to Alpha.
11:17 <TemptorSent> skarnet: Okay, you got me - I'll take the dark chocolate :)
11:17 atmoz joined
11:18 <skarnet> tell you what, get me an account on an Itanium and an Alpha, and I'll make sure my stuff runs on it, guaranteed glib-free
11:18 <skarnet> Sparc I already have. :P
11:18 <TemptorSent> skarnet: I don't have an Alpha laying around any more unfortunately - that was my frineds chunk of hardware.
11:19 <TemptorSent> I never did get on with itanium, but I have a pizza box around here someher still.
11:19 <TemptorSent> skarnet: But the point is interoperability and well-defined and versioned interfaces are immensuely important.
11:20 <skarnet> no shit, Sherlock
11:20 <TemptorSent> OpenGL wouldn't work if it weren't rigerously standardized, no matter what the the host or the card thinks.
11:21 <TemptorSent> If you use OpenGL, you write using types defined by the OpenGL headers and nothing else to interact with the pipeline.
11:22 <skarnet> That obviously makes sense since OpenGL is a backend
11:22 <TemptorSent> Standards, even bad ones, are better than no standards when you want two things to work together.
11:23 <TemptorSent> With glib, or other abastraction libraries, you very frequently have distinct front-end and back-end components - they may even be on different machines.
11:24 <TemptorSent> skarnet: Remember CORBA?
11:24 <skarnet> I'd rather not. Especially not before lunch.
11:24 <TemptorSent> *LOL* Good answer!
11:25 <TemptorSent> Glib was in response to people needing CORBA like dispatch, but without vomiting.
11:25 <skarnet> as far as I'm concerned, they failed with the "no vomiting" part
11:26 <TemptorSent> skarnet: Yeah, well, it started back in the early days of GIMP, so by comparison to a lot of crap out there, it's actually not THAT ugly.
11:26 <skarnet> but we should stop flooding the chan with talk about badly designed software, and I should get back to writing good software
11:26 <TemptorSent> skarnet: Good point.
11:26 <TemptorSent> I think I'd better sleep before I touch the repo again.
11:27 <skarnet> gn :)
11:27 <ncopa> gn
11:27 <TemptorSent> Goodnight, have a good day ;)
11:55 ferseiti joined
12:09 leitao joined
12:19 <^7heo> guys
12:19 <^7heo> let's say a package needs half an OS
12:20 <^7heo> like usr files, libs, etc etc
12:20 <^7heo> how can I package that SEPARATELY from alpine
12:20 <^7heo> ?
12:21 <skarnet> wdym?
12:21 <^7heo> well
12:21 <^7heo> in my current case
12:21 <^7heo> the software (in erlang) comes from the erlang runtime
12:22 <^7heo> it's literally hundreds (more than a thouthand) of files
12:22 <^7heo> I'd like that separated from the normal OS
12:23 <^7heo> kinda like python separates its files
12:23 <skarnet> put everything under a specific hierarchy?
12:23 <^7heo> yeah but where, etc
12:23 <skarnet> ah, policy.
12:24 <^7heo> I mean, do we have established ways to do that?
12:24 <^7heo> yeah that
12:24 <skarnet> certainly, but I don't know to what extent this applies to non-library files
12:25 <skarnet> the policy would be to put erlang-specific files into /usr/lib/erlang
12:25 <skarnet> but if there are etc files or whatever, I'm not sure. ncopa should know.
12:26 <skarnet> (really we should put everything under /p/erlang-$version, but we're not ready for that quite yet ;))
12:28 <^7heo> yeah
12:28 <^7heo> I'd like that last one
12:28 <^7heo> sounds easy and clean
12:30 <skarnet> it would definitely be, but switching to non-FHS is a big task that should be undertaken globally and after serious discussion to establish policy and round out all potential issues, not done package per package à la Wild West. :D
12:31 <^7heo> yeah
12:31 farosas joined
12:31 <^7heo> or a-la-suckless
12:32 <^7heo> :p
12:32 <skarnet> suckless has policies? *zing*
12:32 <^7heo> huhuhuhu
12:32 <^7heo> nice one
12:40 gromero joined
13:15 <^7heo> but so
13:15 <^7heo> if I create a package with /usr/lib/erlang
13:15 <^7heo> I put all the stuff from its /lib in there
13:16 <^7heo> which is 1760 files
13:16 <^7heo> so it's like 94% of its contents
13:16 <skarnet> more like /usr/lib/erlang/lib I guess, so you have the rest of /usr/lib/erlang for other files
13:16 <^7heo> but should I install the rest on the normal system layout?
13:17 <^7heo> it has something that would go in /erts-8.1
13:18 <skarnet> put everything under /usr/lib/erlang except the entry points for users: the erlang binary itself, the config files if any, etc.
13:18 <^7heo> how is it gonna find its files?
13:19 <skarnet> there should be configuration switches when you build it... aren't there?
13:19 <^7heo> maybe.
13:19 <^7heo> I didn't look at that specifically.
13:19 <^7heo> but I'll look now.
13:19 <^7heo> Thanks for all the help.
13:20 <skarnet> again, wait for ncopa's green light, because I'm no Alpine policy expert
13:22 <ncopa> how does other distro do it?
13:23 <skarnet> with blood, sweat and tears, most likely :P
13:40 <^7heo> okay so
13:40 <^7heo> change of plans
13:40 <^7heo> the erlang apps are supposed to EACH contain their own erlang distribution with it, according to what the developer of the software is telling me.
13:41 <^7heo> i.e. disk is cheap, so let's package the entire runtime with every app.
13:41 <^7heo> which is simple at least.
13:41 <^7heo> so long story short:
13:41 <^7heo> is there a policy about that in alpine?
13:42 <skarnet> sounds just like Go, except at least Go apps are static
13:42 <^7heo> I'd basically install the app in /usr/local/erlang_apps/$software_name/
13:42 <^7heo> and make a symlink to the binary into /usr/local/bin/
13:42 <^7heo> any feedback about that approach?
13:43 <skarnet> what's the point of having a shared runtime if you're going to duplicate it for every app?
13:43 <^7heo> don't ask me. I didn't design erlang.
13:43 <^7heo> it apparently has "interesting features"
13:43 <^7heo> point is, I need that app, for last week.
13:44 <^7heo> my boss isn't too happy about the time it takes for packaging this
13:44 <skarnet> I'm saying, did the app dev tell you that, or an Erlang dev?
13:44 <^7heo> so I don't want to rush it and fuck it
13:44 <^7heo> but I kinda have to rush it nevertheless.
13:44 <skarnet> I'd check on Erlang's site, because it sounds fishy
13:44 <^7heo> the app dev.
13:44 <skarnet> I'd definitely check
13:44 <^7heo> yeah but "checking on the Erlang's site" is gonna take a lot of time.
13:44 <^7heo> I'm not familiar at all with that lang.
13:45 <skarnet> neither am I, but I'm familiar with lazy devs who just don't care
13:46 <skarnet> also, I can't say for your specific case, but for Alpine (or any distro) /usr/local is out of bounds
13:46 <skarnet> since by definition it's something the distro's not touching
13:47 <^7heo> yeah
13:47 <^7heo> you're right.
13:47 <^7heo> it's me used to deploy stuff for myself
13:47 <^7heo> but that case is different.
14:05 tmh1999 joined
14:16 leitao joined
14:55 fabled joined
15:15 ferseiti joined
15:25 stateless joined
15:46 leitao joined
15:46 BitL0G1c joined
16:00 leitao joined
16:09 <pickfire> Can I do something like check() make -C "$builddir" test
16:09 <pickfire> Without {}
16:10 <kaniini> no
16:17 <pickfire> Okay
16:22 leitao joined
16:33 atmoz joined
16:33 <pickfire> kaniini: Can I send in a patch which have multiple files that fixes check and return?
16:37 <kaniini> in general, i want to kind of impose a soft freeze on the tree for right now
16:38 <ncopa> +1
16:39 <ncopa> i want hold commits that risk breaking stuff
16:41 <ncopa> also, we should wait with removing || return 1 til after 3.6-stable is branched
16:41 <ncopa> eg til v3.6.0 is out
16:41 blueness joined
16:41 <ncopa> that is to reduce work overhead when backporting security fixes
16:45 <pickfire> Okay
16:48 dsabogal joined
16:55 <pickfire> ncopa: Will firefox in testing be in stable release?
16:56 <* kaniini> sends out some spam
16:56 <pickfire> If yes, I hope that it can be updated to 52.0 after NSS update.
16:56 <kaniini> we only ship -esr as part of stable
16:59 <dsabogal> nmeum: did you see my (and pickfire's) reply for mdocml? i noticed our posts didn't make it to lists.a.o nor patchwork.a.o
17:08 <nmeum> dsabogal: I saw pickfires comment, I will change the two things he pointed out. I didn't get your mail though
17:09 <nmeum> ah your mail is currently greylisted
17:12 t0mmy joined
17:13 leitao joined
17:19 tmh1999 joined
17:27 rrx joined
17:31 <kaniini> the firefox pulseaudio situation makes me glad i implemented Provides: in pkgconf
17:31 <kaniini> because we can hae
17:31 <kaniini> fake-pulseaudio.pc Provides: pulseaudio
17:32 <kaniini> :D
17:32 <asie> huuuuuh.
17:33 <^7heo> right
17:33 <kaniini> my plan for mitigating the pulseaudio requirement is to create a library which emulates pulseaudio's ABI/API
17:33 <^7heo> and does NOTHING with it :D
17:33 <^7heo> \o/
17:33 <algitbot> \o/
17:34 <kaniini> right, it sends it straight to a backend (OSS or ALSA)
17:34 <^7heo> yeah
17:34 <^7heo> :P
17:34 <^7heo> I'd love that.
17:34 <asie> kaniini: you mean apulse?
17:34 <^7heo> oh nice
17:34 <^7heo> https://github.com/i-rinat/apulse
17:34 <^7heo> noiiiice.
17:34 <asie> it was created for Skype
17:34 <asie> but it might have far more uses soon
17:35 <kaniini> asie: even better
17:35 <^7heo> freaking neeeeat
17:35 <^7heo> thanks asie for that info ;)
17:35 <kaniini> i like it when i don't have to do any work
17:35 <^7heo> same here :P
17:35 <asie> don't we all?
17:35 <^7heo> yeah
17:40 <skarnet> "apulse wasn't designed to be a drop-in replacement of PulseAudio. It's pointless, since that will be just reimplementation of original PulseAudio, with the same client-daemon architecture, required by the complete feature set. "
17:41 <skarnet> yep, that's the exact same with systemd. Lennart really knows how to make closed architectures. :/
17:41 <kaniini> either way
17:41 <kaniini> pkgconf has a feature pkg-config does not
17:41 <kaniini> if a .pc does
17:41 <kaniini> Provides: foo
17:42 <kaniini> then if pkgconf cannot find foo.pc
17:42 <kaniini> it will scan for packages that "provide" it
17:42 <kaniini> so, for example
17:42 <kaniini> libressl.pc could Provides: openssl
17:42 <skarnet> if you try to write something compatible, you end up reimplementing the whole thing, because that's the way the software is designed. And that's how you take over a software market.
17:42 <kaniini> and if openssl.pc does not exist, libressl.pc would be used again
17:42 <skarnet> yes, Provides is good
17:43 <kaniini> apulse seems limited to ALSA only
17:43 <kaniini> i think we could do better
17:43 <skarnet> what, you want to support OSS too?
17:43 <kaniini> yes
17:44 <skarnet> slap the ALSA OSS emulation on it if you want that :P
17:44 <kaniini> *BSD (at some point i would like to see Alpine/kFreeBSD) and OSS4 drivers are sometimes superior to ALSA drivers
17:53 <kaniini> skarnet: it is at least a personal goal of mine that any alpine tools are portable beyond linux
17:54 <skarnet> oh, I definitely agree with that, but in that case, *maybe* it would be a good idea to avoid things limited to a PulseAudio backend in the first place
17:56 <TemptorSent> skarnet: Can we force them to us JACK instead of PA at least?
17:57 <kaniini> that does not make any sense
17:57 <kaniini> JACK is meant for professional audio engineers
17:57 <kaniini> PA is meant for grandma
17:58 <TemptorSent> Right, I mean the packages -- JACK at least looks like real software!
17:58 <kaniini> but it's a bad experience
17:58 <TemptorSent> kaniini: How so?
17:58 <kaniini> grandma does not want to connect firefox to her speakers in order to watch youtube
17:59 <kaniini> JACK requires you to do this by design
17:59 <kaniini> it's a soundserver that works like a mixing board
17:59 <TemptorSent> kaniini: Obviously, but IIRC it's not that difficult to default.
18:00 <TemptorSent> kaniini: Right, which is the same BASIC function PA has, mix multiple streams from multiple sources and output to given outputs
18:00 <kaniini> okay
18:00 <kaniini> let me put it this way
18:00 <kaniini> PA does not make you connect firefox to your speakers manually
18:00 <kaniini> JACK does
18:00 <kaniini> that's the point i am making
18:00 <TemptorSent> Hmm, I seem to remember being able to drop in a config and have it 'just work' unless I was doing something special
18:01 <kaniini> the obvious solution is to emulate the pulseaudio API and do something else with it
18:01 <kaniini> --> configs
18:01 <kaniini> yes, losing again
18:01 <TemptorSent> The nice thin about JACK is that's it's REALLY cross platform.
18:02 <duncaen> maybe sndio but you need to setup the server, no auto magic like pulse does
18:02 <kaniini> we would like sound to 'just work' on the desktop
18:02 <kaniini> thusly, again,
18:02 <kaniini> the obvious solution is to emulate the pulseaudio API and do something else with it
18:03 <kaniini> right now, sound 'just works' on alpine
18:03 <kaniini> we would like to keep it that way
18:03 <duncaen> with pulse?
18:03 <kaniini> with your choice of either alsa/dmix or OSS4
18:04 <duncaen> ah and the problem is that firefox is going to drop alsa support at some point?
18:04 <kaniini> yes
18:04 <kaniini> so emulate pulseaudio api, done
18:04 <skarnet> or drop firefox, since they don't care about portability
18:04 <kaniini> that sounds like a great plan
18:05 <kaniini> what do you propose i use to browse websites
18:05 <skarnet> I don't know, but firefox will be dead in a few years anyway
18:05 <kaniini> keep in mind that we package firefox because quite literally everything else is worse
18:05 <duncaen> but emulating a api seems like one of the worst things to do if its not designed for it
18:05 <kaniini> seems to work for WINE
18:06 <duncaen> doesnt make it good tho
18:06 <duncaen> tbh i dont think its too much work to maintain the libcubeb alsa stuff
18:07 <kaniini> can't do that if we want to keep official branding
18:07 <duncaen> why?
18:07 <kaniini> because mozilla says so
18:08 <skarnet> don't you love politics
18:08 <duncaen> can they force it? some clause in mpl?
18:08 <kaniini> are you fucking kidding me
18:09 <kaniini> duncaen: the branding elements are not licensed under MPL
18:10 <asie> AlpineCat
18:10 <duncaen> oO
18:10 <asie> calling it
18:10 <skarnet> asie: I already called Alpine Foxling!
18:10 <asie> works
18:10 <kaniini> to use the official branding, you have to have an existing relationship with mozilla (we do). hope voidlinux does, because if not they are breaking the law etc
18:10 <asie> but not catch enough
18:10 <skarnet> look it up
18:11 <kaniini> anything we do like that is discussed with them
18:11 <duncaen> lol what a shitshow
18:11 <kaniini> if they say no, we don't do that
18:12 blueness joined
18:12 <kaniini> duncaen: they have legitimate concerns -- an amateur distro could damage firefox's reputation by producing a buggy build of it
18:13 <duncaen> lol they do it theirself
18:13 <asie> but it's on them then
18:13 <asie> it's different if it's their fault
18:13 LouisA joined
18:13 <TemptorSent> The real issue is things like someone releasing a copy with intentional malicious code.
18:13 <kaniini> a lot of distros were applying patches that broke things badly, which is why they started cracking down on it
18:13 <kaniini> that too
18:14 <duncaen> so we cant redistrubute it with --enable-official-branding, do we have to rename it too?
18:14 <TemptorSent> There were instances of browsers being shipped with built-in malware.
18:14 <kaniini> you can use the name they generate without --enable-official-branding (Aurora i believe it is?)
18:16 <kaniini> technically, the --enable-official-branding situation is contrary to alpine's free software guidelines, but we choose to make an exception in this case because it is mutually beneficial to everyone involved
18:17 stwa joined
18:17 <asie> what's the point of the guidelines if exceptions are being made when convienent?
18:17 <duncaen> and debian, dont they use the official builds now too?
18:17 <kaniini> no
18:17 <kaniini> debian ships iceweasel
18:18 <duncaen> they ship firefox
18:18 <kaniini> hmm
18:18 <kaniini> that's new
18:18 <duncaen> https://lwn.net/Articles/676799/
18:18 <asie> "The Firefox logo was released under a free copyright license which matches the DFSG"
18:19 <kaniini> in that case
18:19 <kaniini> continue using --enable-official-branding i guess, but don't be surprised if they come yelling at you
18:19 <kaniini> when you do something they do not like
18:19 <duncaen> and mozilla approved the musl patches?
18:19 <kaniini> yes
18:19 <kaniini> largely, they are upstream even
18:19 <duncaen> for debian i can understand, backporting all this shit over years is impossible
18:20 <duncaen> there are still many patches for musl that are not upstreamed
18:20 <duncaen> ok just asmall ones
18:21 <kaniini> only mallinfo.patch is related to musl in alpine
18:21 <kaniini> the rest are related to other things we do
18:22 <duncaen> i have a few more, maybe because of esr vs release
18:24 <duncaen> fix-tools.patch has some musl related changes too
18:25 <duncaen> fix-toolkit.patch too
18:28 <kaniini> hmm ok
18:28 LouisA joined
18:29 <kaniini> well, either way, mozilla does not care about that. they do care about keeping the ALSA backend.
18:29 <mitchty> quick question on stuff moving from testing to community, is there a page that describes how one goes about getting that done?
18:29 <kaniini> you ask, but there is a soft freeze in place
18:29 <kaniini> so what do you want moved to community
18:30 <skarnet> I'm confused: does mozilla insist that the ALSA backend should be kept, or removed?
18:30 <mitchty> well ghc and cabal seem to be working based on all my testing
18:30 <kaniini> skarnet: removed when they remove it
18:30 <skarnet> yeah, so they're hopeless
18:31 <kaniini> emulating PA should not be that difficult as a solution tbh
18:31 <duncaen> too bad that there is no --enable-system-cubeb and then we could just maintain alsa support in cubeb
18:31 <kaniini> i am pretty sure that would piss them off too :P
18:31 <TemptorSent> kaniini: How do you handle the sample rate/format conversion without some sort of audioserver?
18:31 <skarnet> emulating poetterware is always difficult
18:31 <kaniini> however, we will look into that
18:32 <kaniini> TemptorSent: libresample
18:32 <kaniini> and there is a soundserver in most cases -- dmix
18:32 <TemptorSent> kaniini: Does that merge multiple streams these days?
18:32 <duncaen> this is what dmix does
18:32 <TemptorSent> kaniini: Oh, yeah - forgot that dmix existed.
18:33 <TemptorSent> kaniini: I used that back in the bad-old-days :)
18:33 <duncaen> but dmix is only there if your hardware doesnt do the mixing?
18:33 <kaniini> right
18:33 <TemptorSent> kaniini: I recall at the time it was somewhat flaky.
18:36 <TemptorSent> kaniini: My audio usages tend to be either DAW/Signal Processing or radio, so I haven't done much with the 'normal' consumer setups.
19:01 fekepp joined
19:13 <kaniini> mitchty: i think it is okay to move haskell over. which packages should i move?
19:14 <mitchty> kaniini: before you do, i want to check with fabled, not entirely sure how the cross compilation stuff works for now, it can wait no rush on moving things
19:17 <mitchty> just want to be sure that armhf will be ok, but I presume it would be ghc-bootstrap, ghc, and cabal
19:26 <skarnet> kaniini: if OpenSSL is changing its license to Apache, as I've heard, does the "needs to be a core component of Alpine so we don't have to grant license exceptions for individual packages" thing still apply?
19:27 <kaniini> i do not believe it is possible for them to do so
19:27 <kaniini> some openssl contributors are dead
19:28 tmh1999 joined
19:28 <kaniini> what this will result in is a package of dubious legality
19:28 <TemptorSent> kaniini: They'd have to go to the estates of the deceased, but it's not impossible.
19:28 <kaniini> so, short answer: no, longer answer: we will probably have to be very careful about using such a version
19:28 <kaniini> even longer answer: since we use libressl, they would have to make a decision on accepting the changed license
19:29 <kaniini> so, assuming that
19:29 <kaniini> - openssl is able to *legally* change the license (seems questionable, they will need to prove they have legal permission to do so)
19:29 <kaniini> - libressl accepts that change
19:29 <kaniini> then yes
19:29 <kaniini> that would be fine
19:30 <skarnet> I see, thanks for the answer.
19:30 <TemptorSent> Where's the MIT/BSD licensed code when you need it?
19:31 <* skarnet> whistles
19:31 <kaniini> i hope if they do this, that they do it properly and prove that everyone has signed off on it
19:31 <kaniini> if it is a "lol the core team decided to change the license", that is not legal
19:32 <TemptorSent> Software 'freedom' has become anything but! (Thanks RMS)
19:32 <skarnet> it's not like I've talked about BearSSL for several months, or even released a package implementing a SSL tunnel using it, amirite
19:32 <kaniini> TemptorSent: openssl license is rightly GPL-incompatible
19:32 <TemptorSent> skarnet: How far from feature-parity is Bear?
19:32 <kaniini> feature-parity is not relevant
19:32 t0mmy joined
19:33 <kaniini> for it to be releant, it needs to emulate the openssl api
19:33 <TemptorSent> kaniini: Maybe, or at least be wrappable with an openssl api layer.
19:33 <skarnet> yeah, that's not gonna happen. What it can do is emulate the libtls api, which is a part of libressl, but not openssl
19:34 <kaniini> then it is yet another TLS library "great"
19:34 <kaniini> does not solve our core objection to openssl, libressl solved the other already
19:34 leitao joined
19:34 <TemptorSent> I take it the issue is libssl itself?
19:35 <skarnet> it's the only one that yields me a 110k static binary implementing a SSL tunnel, using 300k of RAM
19:35 <TemptorSent> skarnet: Nice!
19:35 <skarnet> you need 10x those resources to achieve the same with libressl
19:35 <TemptorSent> skarnet: I could almost use that in an embedded system.
19:35 <kaniini> the issue is libssl's license
19:35 <kaniini> skarnet: cryptlib does better tbh
19:35 <skarnet> that's one of BearSSL's avowed goals
19:36 <skarnet> yeah, I trust BearSSL's author to get his crypto right though
19:36 <TemptorSent> kaniini: I mean implementing the features of libssl.
19:36 <kaniini> TemptorSent: yes
19:36 <kaniini> we need to use apps that exist now
19:36 <skarnet> like s6-networking
19:36 <TemptorSent> kaniini: Of course, that's why I'm wondering if we can wrap a more friendly library.
19:37 <kaniini> good luck ;)
19:37 <skarnet> the libssl api is a pile of pain, you don't want to wrap something else *into* it
19:37 <kaniini> if you do this and release it under a sane license (i.e. BSD) that depends on another sane license (i.e. BSD), then great, we'll look at it
19:37 <TemptorSent> kaniini: Libcrypto is solved, correct?
19:37 <kaniini> no
19:37 <skarnet> far from it
19:38 <kaniini> both need to be emulated by your emulation layer
19:38 <TemptorSent> Crap, that gets irritating quickly.
19:38 <kaniini> why do you think i havent done anything about it yet
19:39 <skarnet> because you're a busy man and can't fix the world on your own
19:39 <skarnet> even I cannot do that :P
19:39 <TemptorSent> kaniini: Because you have so many other more pressing projects?
19:39 <asie> wait i just realized you're the s6 wizard!
19:39 <asie> took me far too long
19:39 <asie> aww, you updated skabus's site to "next years" - i was looking forward to the constantly changing date :-<
19:40 <skarnet> asie: sorry about that, it's a moving target because not prioritized
19:40 <kaniini> TemptorSent: that, but it's prioritized low because its a pain in the ass
19:41 <kaniini> what i would like: one sane crypto/tls library, wrappers for everything else
19:41 <skarnet> kaniini: BearSSL is my favorite for the "sane crypto/tls library" part
19:41 <kaniini> why is it called BearSSL
19:42 <skarnet> Because it's written by Thomas Pornin, whose totem is a bear
19:42 <TemptorSent> skarnet: It looks pretty damn good to me on fist glance.
19:42 <kaniini> i see
19:42 <skarnet> I'm even willing to write the libtls wrapper at some point
19:42 <skarnet> I'm *not* willing to write the libssl/libcrypto wrappers without mass $$$
19:42 <kaniini> i'm not willing to write those without mass drugs
19:43 <skarnet> that too
19:43 <skarnet> what do you think the $$$ are for
19:43 <TemptorSent> Yeah, I'm seeing that, especially to Bear, which has a 0-alloc policy
19:44 <skarnet> TemptorSent: it uses like 32k of stack and nothing else, all the complexity is in the text. It's simply awesome.
19:44 <kaniini> so french cultural appropriation of my culture aside
19:44 <* kaniini> mutters about White Privilege
19:44 <TemptorSent> skarnet: Yeah, I like it. I'll have to take a look at it for really small stuff.
19:44 <kaniini> what does BearSSL actually support
19:45 <skarnet> TemptorSent: check out s6-networking, it can be built against BearSSL, and provides a SSL tunnel
19:45 <skarnet> kaniini: check the site. But 1.0 isn't even out yet, so it may be wise to wait for a few months for any official stuff :P
19:46 <skarnet> (that said, 0.3 works)
19:46 <TemptorSent> skarnet: Cool! Will it run on bare (bear? :P ) metal?
19:46 <skarnet> BearSSL will (that's one of its goals), s6-networking won't (because I assume a POSIX environment)
19:47 <TemptorSent> skarnet: Gotcha -- how much posix does it need?
19:48 <skarnet> not sure. I think the superservers need fork() at least, so nommu is out for the time being
19:49 <skarnet> (you can still run clients though)
19:49 <TemptorSent> It looks like the sanest way to do a libssl wrapper may be to split it into two layers, a compatability layer and feature layer.
19:49 <kaniini> skarnet: apk-tools does not depend on libssl, but libcrypto
19:50 <TemptorSent> Much of the api appears to be reduntant definitions that could be marshaled after some logic.
19:50 <skarnet> kaniini: yeah, about that... has the "not checking the CA database" thing been fixed?
19:51 <duncaen> apk-tools depends on libssl here
19:51 <kaniini> define 'here'
19:51 <duncaen> void
19:51 <kaniini> because the libssl dependency comes from libfetch
19:51 <kaniini> not from apk-tools itself
19:51 <kaniini> :p
19:52 <duncaen> but it uses the bundled libfetch
19:52 <kaniini> sure, but apk-tools itself only uses libcrypto
19:52 <TemptorSent> What does BearSSL NOT have that we would need to implement libssl/libcrypto as far as the actual algos go?
19:52 <duncaen> yea for signatures i get it
19:53 <skarnet> TemptorSent: for now, a usable API for client certificates
19:54 <TemptorSent> skarnet: I mean, what would need to be implemented from scratch rather than wrapped to make a libssl/libcrypto wrapper around the functions in BearSSL, at least for those protocols we want to support.
19:55 <skarnet> TemptorSent: I'm not sure. I won't do crypto from scratch, I'll wait for the specialist to write it, and then I'll wrap it. That's what I've done so far and it has worked.
19:55 <duncaen> this sounds like a really ugly task
19:59 <duncaen> wouldnt surprise me if adding native support to each project instead of a wrapper that would have to follow openssl stable releases, implement all quirks and strange apis correctly in the long term
20:04 <kaniini> duncaen: the problem is that upstreams do not care
20:05 <^7heo> hey guys
20:05 <duncaen> thats bad, welcome to the new world of linux, compatibility layers for all kind fo apis instead of replacing/improving them
20:05 <^7heo> I'm trying to use install(1) on a directory on my APKBUILD
20:06 <^7heo> it fails with install: omitting directory
20:06 <^7heo> any idea what I'm doing wrong?
20:06 <^7heo> I'm calling: install -D -m755 $src_dir $dest_dir || return 1
20:07 <kaniini> you use only $dest_dir just to create a directory
20:07 <kaniini> src dest is to copy files
20:07 <^7heo> I don't comprehend.
20:07 <TemptorSent> skarnet: Yeah, I won't do the crypto without some expert help, but protocol I can handle for the most part.
20:08 <^7heo> how can install(1) know where to copy or what to copy if I omit either of the src or the dist?
20:08 <^7heo> s/dist/dest/
20:08 <duncaen> install != cp -r
20:08 <^7heo> yeah so far so good.
20:08 <^7heo> And so, how do I use it?
20:09 <^7heo> or rather, if I have to copy a bunch of files around
20:09 <^7heo> should I just cp -r?
20:09 <skarnet> I don't like install. It doesn't work atomically.
20:09 <kaniini> yes
20:09 <^7heo> as far as I understood, install == cp -r && chown
20:09 <TemptorSent> ^7heo: cp -a or cpio
20:09 <skarnet> cp -a to a temporary place, then rename :P
20:10 <TemptorSent> ^7heo: Or, if we were REALLY POSIXly correct, pax!
20:10 <^7heo> skarnet: why temporary?
20:11 <duncaen> because you dont want to lose src while renaming
20:11 <skarnet> you need to copy $src into the same directory as $dest to make sure it's on the same filesystem as $dest
20:11 <skarnet> then you can rename your temp file to $dest
20:11 <TemptorSent> ^7heo: You can also do tar -c -C $src ... | tar -x -C $dest
20:12 <^7heo> skarnet: you mean, I need to create $dest in the same directory as $src to ensure it's on the same filesystem as $src, so the rights copying won't fail?
20:12 <skarnet> no.
20:12 <^7heo> lemme re-read
20:13 <skarnet> say you have /staging/foo that you need to install as /bin/foo
20:13 <^7heo> skarnet: basically, it's for an APKBUILD
20:13 <^7heo> yeah?
20:13 <^7heo> what's the problem with doing `cp -a /staging/foo /bin/`?
20:13 <skarnet> it's not atomic.
20:13 <^7heo> ah
20:13 <^7heo> sure.
20:14 <skarnet> rm -rf /bin/foo.tmp && cp -f /staging/foo /bin/foo.tmp && mv -f /bin/foo.tmp /bin/foo
20:14 <^7heo> but neither is `cp -a /staging/foo /bin/.temp.foo && mv /bin/.temp.foo /bin/foo`
20:14 <skarnet> the latter is
20:15 <^7heo> well
20:15 <skarnet> you get either the old foo or the new foo
20:15 <TemptorSent> rename syscall
20:15 <^7heo> the mv is basically doing a rename on a folder right
20:15 <skarnet> there's no state where you get a partial file
20:15 <^7heo> but the cp -a is still not atomic.
20:15 <^7heo> well, during the cp -a you do.
20:15 <skarnet> you don't care about that
20:15 <^7heo> why not?
20:15 <TemptorSent> No, but if it fails, you still have a valid state.
20:15 <skarnet> nobody's going to try and run your temporary file
20:16 <^7heo> well, nobody's gonna try and run my permanent file either.
20:16 <^7heo> it's only gonna exist when the service file will exist.
20:16 <^7heo> s/exist/be used/
20:16 <^7heo> which is gonna be created last.
20:16 <^7heo> so...
20:16 <TemptorSent> ^7heo: The issue is a failed copy which leaves either a truncated file or part of the FS copied but not all
20:16 <skarnet> think about upgrades
20:16 <^7heo> TemptorSent: sure, but I don't get how the other solutions work for that.
20:17 <skarnet> if you get a partial copy, you revert and abort the transaction
20:17 <skarnet> only if the copy is complete do you commit the transaction with rename()
20:17 <TemptorSent> ^7heo: Because you are using the && between operations, so it never has a state when it's out of sync
20:17 <^7heo> skarnet: I see what you mean
20:17 <^7heo> so basically
20:18 <TemptorSent> It should be in the order cp -a $src $dest_tmp && rm -rf $dest && mv -f $dest_tmp $dest
20:18 <skarnet> nope
20:19 <^7heo> rm -rf $dest ${dest}.tmp && cp -a $src ${dest}.tmp && mv ${dest}.tmp $dest || rm -rf ${dest.tmp}
20:19 <^7heo> that would work right?
20:19 <TemptorSent> So until you have successfully coppied the entire new structure, you still have the original intact and working.
20:19 <skarnet> yeah, something like that
20:19 <skarnet> TemptorSent: don't rm the old binary, else there's a window where you have no binary at all
20:20 <TemptorSent> skarnet: Yeh, if we're talking a file, but if it's a directory, we either have to do that, or use non-posix tools.
20:21 <skarnet> if it's a directory then it's another problem entirely
20:21 <^7heo> skarnet: it's a dir.
20:21 <^7heo> so yeah
20:21 <^7heo> I can't mv without doing the rm first.
20:21 <skarnet> ok, then different strategy
20:21 <^7heo> hence my `rm -rf $dest ${dest}.tmp` at first.
20:21 <kaniini> i like how gtk2 assumes all screens are 96 dpi
20:22 <^7heo> kaniini: at least they don't assume everything is 300dpi
20:22 <kaniini> that assumption, while bad, would be better for me than 96
20:22 <^7heo> :P
20:22 <skarnet> ensure your published path is a symlink
20:22 <^7heo> ahah :P
20:22 <^7heo> ok gotcha.
20:22 <kaniini> 192dpi would be preferable
20:22 <^7heo> skarnet: I do that too, tbh
20:23 <skarnet> then copy your new dir to something unique, atomically rename the symlink, then delete the old directory
20:23 <kaniini> also i have a touchscreen, and it "just works" on alpine
20:23 <TemptorSent> ^7heo: Yeah, do 'rm -rf .tmp-${dest} && cp -a $src .tmp-${dest} && mv -f $dest .old-${dest} && mv -f .tmp-${dest} $dest && rm -rf .old-$(dest)
20:23 <kaniini> that is very odd
20:23 <^7heo> kaniini: that's Linux for you.
20:23 <^7heo> kaniini: try with NetBSD and tell me ;)
20:24 <^7heo> TemptorSent: no, ${dest} can be /foo/bar/baz so bad idea to prefix it.
20:24 <skarnet> TemptorSent: I'd love it if you would stop providing unsafe solutions
20:25 <^7heo> TemptorSent: also the last one should be ${dest} rather than $(dest)
20:25 <^7heo> TemptorSent: and what I already do for directories is what skarnet said, ie. using sylinks.
20:25 <^7heo> TemptorSent: that's the only way to make atomic operations.
20:25 <TemptorSent> ^7heo: Oh, if you're trying copy something other than the single src/target, you'll have to use caution.
20:25 <^7heo> TemptorSent: no I'm saying: if it's an absolute path, you'd better not prefix it.
20:26 <^7heo> TemptorSent: so since we don't know, it's best to SUFFIX it.
20:26 <^7heo> TemptorSent: like skarnet did.
20:26 <TemptorSent> ^7heo: The prefixing was intended to BREAK absolute paths so you don't find recursion.
20:27 <^7heo> but then we don't know on what device we are
20:27 <^7heo> and there's no atomic operation.
20:27 <^7heo> we don't know if it's a rename or a copy.
20:27 <TemptorSent> ^7heo: I use that when I'm trying to force exactly one directory to copy to exactly one location.
20:27 <^7heo> I don't.
20:27 <TemptorSent> ^7heo: It keeps you from having the cross-filesystem possiblity
20:28 <^7heo> I don't see how
20:28 <^7heo> .tmp-${smth} is bound to be local
20:28 <^7heo> to your $CWD
20:28 <TemptorSent> Right, you run that IN your dest dir.
20:28 <^7heo> ah yeah but that was not written anywhere :P
20:29 <TemptorSent> I use a subshell and doe '(cd $dest && ...'
20:29 <^7heo> I'm not an oracle dude :P
20:29 <^7heo> I'm more like a sun tbh
20:29 <* ^7heo> hides
20:29 <TemptorSent> ^7heo: *LOL*
20:29 <^7heo> anyway
20:29 <^7heo> since it's a full dir
20:29 <^7heo> and I don't want to complicate the task
20:29 <^7heo> and I will assume that nothing is there already
20:29 <^7heo> because it's a name unique enough
20:30 <^7heo> (ie. the software name itself)
20:30 <skarnet> again: upgrdes
20:30 <skarnet> of course there's no problem on your first install
20:30 <^7heo> yeah
20:30 <^7heo> true
20:30 <skarnet> make it a symlink
20:30 <TemptorSent> ^7heo: Change to the dest dir, copy source to temp in dest dir (mktemp if you want), rename dest old , rename temp dest , rm old
20:31 <skarnet> you never need to change your cwd
20:31 <^7heo> skarnet: yeah ok.
20:31 <^7heo> skarnet: seems like a very good option in the end.
20:31 <TemptorSent> skarnet: Yeah, symlinks are easy :)
20:31 <TemptorSent> ln -sfT
20:31 <TemptorSent> don't forget the T!
20:31 <skarnet> not posix
20:32 <^7heo> also,
20:32 <^7heo> it WILL be a dir.
20:32 <TemptorSent> Then force the actual link name
20:32 <^7heo> yes.
20:33 <TemptorSent> -T prevents you from recursing into hell :)
20:33 <skarnet> I really have no idea where you get that recursion idea from
20:33 <TemptorSent> /boot :)
20:34 <skarnet> when you're copying a single item and not a shell wildcard, you won't recurse
20:36 <TemptorSent> skarnet: given dir /tmp/foo, you run ln -sf making a link from /tmp/foo/bar -> /tmp/foo, now you run the same command again, what do you get?
20:36 <^7heo> dudes
20:36 <skarnet> why would I ever do that
20:37 <^7heo> if I do `install -D -m755 "$pkgdir"/var/lib/"$pkgname-$pkgver"`
20:37 <^7heo> why is it fucking calling usage()?
20:37 <TemptorSent> Because when ln is invoked without somethign to limit it's handling of links, you'll get different results by running the same command.
20:37 <^7heo> isn't it the way you use it?
20:37 <skarnet> busybox right?
20:37 <^7heo> yeah
20:37 <^7heo> Usage: install [-cdDsp] [-o USER] [-g GRP] [-m MODE] [-t DIR] [SOURCE]... DEST
20:38 <TemptorSent> Some option gon wrong.
20:38 <^7heo> and I'm calling `install -D -m775 $DEST`
20:38 <skarnet> I think it's broken somehow - yet another reason not to use it
20:38 <^7heo> dafuq.
20:39 <skarnet> even when it's not broken, strace it to be convinced it's not doing things atomically
20:39 <TemptorSent> ^7heo: It needs at least one more option to tell it what its putting where.
20:40 <duncaen> or -d
20:40 <TemptorSent> -t DESTDIR perhaps?
20:40 <^7heo> duncaen: does -D does the same as -d?
20:41 <duncaen> no
20:41 <skarnet> why am I even trying
20:41 <^7heo> ah
20:41 <^7heo> skarnet: trying to?
20:41 <duncaen> -D creates folders in the path, -d creates the folder
20:41 <^7heo> ah ok
20:41 <TemptorSent> ^7heo: -D essentially does mkdir -p, -d creates a new directory
20:41 <duncaen> s/folder/directories
20:41 <^7heo> skarnet: I replaced it with mkdir -p
20:41 <skarnet> trying to get you to do the right thing
20:41 <TemptorSent> ^7heo: Good call :)
20:41 <^7heo> skarnet: which is?
20:41 <duncaen> not using install
20:41 <^7heo> skarnet: sorry, but it's fucking not clear.
20:41 <TemptorSent> Not using install
20:41 <^7heo> yeah, I'm NOT using it.
20:41 <TemptorSent> *LOL*
20:42 <^7heo> so I don't see why the fuck there is so much commotion.
20:42 <^7heo> I asked about it, skarnet said "it sucks", I switched to mkdir -p
20:42 <skarnet> you're not using it, that's why you're asking why it's showing you a usage line
20:42 <skarnet> that's very clear
20:42 <^7heo> because that was BEFORE you said it's broken
20:42 <TemptorSent> Why is there not a good atomic version of install?
20:42 <^7heo> also, I like to understand stuff.
20:42 <skarnet> one of us has a very weird perception of time and it's not me
20:43 <duncaen> its broken since there is no standard
20:43 <^7heo> so when it's broken, I'll use something else
20:43 <^7heo> but I'll still try to check why it's broken
20:43 <^7heo> hence why I was continuing the discussion.
20:43 <TemptorSent> I'm tempted to write insanestal.
20:43 <^7heo> skarnet: here's the perception of time issue ^
20:43 <^7heo> (what I just said before)
20:43 <TemptorSent> er insanestall.
20:43 <^7heo> anyway thanks a lot skarnet
20:44 <^7heo> mkdir -p works very well
20:44 <duncaen> there are different install(1) implementations, autoconf seems to check for bsd like ones whcih is gnu ones too, i guess busybox too
20:44 <duncaen> but they ship a install-sh script anyways
20:44 <TemptorSent> ^7heo: Don't forget to check the created directory is RWX before trying to actually write to it!
20:44 <skarnet> never check before
20:44 <skarnet> that's a recipe for toctou
20:45 <skarnet> do the thing you want to do, and if it failed, then you had a problem
20:45 <^7heo> TemptorSent: umask is 022
20:45 <TemptorSent> skarnet: RO root causes that often.
20:45 <TemptorSent> ^7heo: That's not where you have a problem, it's when you're on a RO mounted FS and the directory you mkdir -p already exists.
20:46 <^7heo> skarnet: it's weird to read a C developer advocate for exceptions rather than pre-checking.
20:46 <skarnet> in a single-threaded C program you can rely on state
20:46 <duncaen> but its shell it fails :D
20:46 <skarnet> in a multi-process Unix you can't
20:47 <TemptorSent> I've replaced all the mkdir -p calls in mkimage with mkdir_is_writable which tests the resulting directory and pukes if it's not actually writable (including r/x for dirs)
20:47 <skarnet> TemptorSent: better to perform the operation and check for ROFS than to pre-check, see it will work, perform the operation, still fail because your fs was just remounted ro, and crash. :P
20:47 <skarnet> check for EROFS*
20:49 <TemptorSent> skarnet: That's fine when you are handling everything in your local function, but when you start calling other programs with your directory name as the target and THEY puke, it's a bit harder to clean up if they did a partial job.
20:49 <duncaen> but more shell code just makes it harder to debug for edge cases like this :D
20:49 <TemptorSent> (tar extracting to / with a file on a RO mounted FS is still a gotcha :/)
20:50 <ncopa> kaniini: re the email about the freeze
20:51 <ncopa> we will not branch 3.6-stable until we do the release
20:51 <kaniini> ok
20:51 <TemptorSent> duncaen: I try to keep my code split out so I can debug my logic separately from my utilities.
20:51 <kaniini> ignore that part then :D
20:51 <kaniini> sometimes we have branched prior
20:51 <ncopa> that must been long time ago
20:51 <ncopa> i cannot remeber that we ever have
20:52 <ncopa> however
20:52 <ncopa> the plan is aprox like this:
20:52 <ncopa> in beginning of april we set up the builders for 3.6
20:52 <kaniini> yeah in 2.x days we used to branch and then use the builders on that branch
20:52 <ncopa> those will build from git master
20:53 <^7heo> skarnet: one more thing
20:53 <ncopa> edge and 3.6 builders will build the same thing up to the 3.6.0 release tag
20:53 <ncopa> and after tag we branch
20:53 <^7heo> skarnet: the removal of the directory of the previous version, during an upgrade...
20:54 <^7heo> skarnet: it should happen in .post-install ?
20:54 <ncopa> once the builders are up, then we cannot do big changes in the build scripts
20:54 <ncopa> eg we cannot change abuild to build packages differently
20:54 <^7heo> skarnet: and what if the people want to keep their data?
20:54 <ncopa> and we can not jump to new gcc version
20:54 <ncopa> at least not new major gcc version
20:54 <ncopa> we should avoid header changes
20:54 <ncopa> etc
20:54 <skarnet> ^7heo: config management is hard, if it's a config directory (or anything else where users put their data) then you need to keep it somehow
20:55 <TemptorSent> ^7heo: Do a comparison between the old-unmodified and the fs version, if they differ, leave the dir.
20:55 <skarnet> different package managers have different policies
20:55 <ncopa> and after that we need to get in everything that should be included in the release
20:55 <^7heo> TemptorSent: how do I know the old-unmodified version?
20:55 <^7heo> TemptorSent: it's not THAT easy to find.
20:55 <skarnet> if you want or need to remove it, just do it after the rename(), if the transaction has succeeded
20:55 <^7heo> TemptorSent: we're not using overlays...
20:55 <TemptorSent> ^7heo: Existing installed apk hopefully :)
20:56 <^7heo> TemptorSent: we don't cache them by default.
20:56 <ncopa> i have done ABI braking changes after build servers are up, but i try avoid since it adds work
20:56 <TemptorSent> ^7heo: Can't we pull a specific version of an apk?
20:56 <^7heo> TemptorSent: not if it's not on the remotes anymore.
20:56 <^7heo> TemptorSent: we can't assume the users are upgrading from the very next previous version.
20:56 <^7heo> TemptorSent: many don't.
20:56 <TemptorSent> ^7heo: That's bad.
20:57 <^7heo> TemptorSent: that's how it is for now.
20:57 <TemptorSent> ^7heo: That will be a major issue for configuration management.
20:57 <^7heo> yeah
20:57 <^7heo> it's already the case.
20:57 <^7heo> that's why I run mirrors
20:57 <^7heo> and I keep old packages.
20:57 <^7heo> but unfortunately they're not really reliable
20:58 <TemptorSent> ^7heo: On first install, make clean copy of dir store to .dir-dist
20:58 <^7heo> because I odn't need them much
20:58 <^7heo> don't*
20:58 <^7heo> TemptorSent: do you have ANY idea of the size of the thing I'm installing?
20:58 <TemptorSent> ^7heo: Compare and roll against that, preferably with some checksums
20:58 <^7heo> it's bigger than the default alpine dist...
20:58 <^7heo> I'm not gonna copy that...
20:58 <^7heo> it's just crazy
20:58 <TemptorSent> ^7heo: Right, you don't copy the whole mess, just the config part!
20:59 <^7heo> I was thinking about the checksum route.
20:59 <^7heo> tbh doing a recursive checksum would be a good thing.
20:59 <^7heo> and storing that file.
20:59 <^7heo> so we know what changed.
20:59 <^7heo> there's also apk audit or something
20:59 <TemptorSent> ^7heo: Yeah, I try to do a fully checksummed ls -lR when I'm versioning something.
21:00 <^7heo> but apk audit is only auditing /etc
21:01 <TemptorSent> ^7heo: Any reason you couldn't get it to audit anything you want?
21:01 <^7heo> no idea, no clue how that works.
21:02 <TemptorSent> ncopa? ^^^
21:02 <kaniini> ncopa: i guess we need to decide grsec
21:02 <^7heo> TemptorSent: fabled would be the one knowing AFAIK
21:03 <TemptorSent> ^7heo: Yeah, but I haven't seem about lately and figured ncopa might know something.. :)
21:04 <ncopa> apk audit --system
21:05 <TemptorSent> :)
21:05 <TemptorSent> Thanks ncopa!
21:06 <^7heo> ncopa: how is that working?
21:06 <TemptorSent> As far as keeping old package revs, can we at the very least keep ALL kernels for some significant period of time?
21:06 <^7heo> ncopa: how is alpine knowing what file has changed, etc?
21:06 <ncopa> checksum is stored in db
21:06 <^7heo> ah.
21:06 <^7heo> for EVERY file?
21:07 <ncopa> yes. have a look in /lib/apk/db/installed
21:07 <TemptorSent> ^7heo: I would think so...
21:07 <^7heo> Ok
21:07 <^7heo> pretty cool.
21:08 <^7heo> ncopa: any idea of the meaning of the status letters?
21:08 <^7heo> ncopa: there's nothing in -h
21:08 <^7heo> I see 'U' and 'X'
21:08 <TemptorSent> Wait, given that, what prevents us from versioning directly off the apk database and reverse-finding packages by any file?
21:09 <TemptorSent> Can we grab just the db entries via APK for the whole repo for instance?
21:09 <TemptorSent> I'll take a WAG of Update and deleted?
21:10 <^7heo> yeah possibly.
21:10 <^7heo> but then what is D?
21:10 <^7heo> :P
21:10 <TemptorSent> Hmm, X may be masked due to modified file?
21:10 <TemptorSent> Not sure then :)
21:11 <TemptorSent> ncopa: Also, is there any database/listing of all known users/uids groups/gids used by all packages in the repos?
21:16 <TemptorSent> ncopa: Also, is it ever valid for a .apk to include a dotfile in the root directory that is NOT swallowed by apk? In other words, can I tell tar to ignore ^\..*
21:16 <TemptorSent> (and \./\..*)
21:17 <^7heo> ncopa: are you around?
21:17 <^7heo> ncopa: I get some weird stuff when I try to package the software I'm working on
21:18 <^7heo> ncopa: >>> ERROR: dalmatinerdb*: Has /home/... in rpath
21:18 <^7heo> I have no clue what rpath is, but my package definitely doesn't do anything with or to /home/
21:19 <kaniini> ^7heo: rpaths are additional locations to look for .so's
21:19 <kaniini> ^7heo: if you are packaging someone else's binaries, or building in $HOME, then you would have those paths
21:19 <kaniini> ^7heo: use chrpath to delete them
21:19 <^7heo> kaniini: I have no such binary.
21:20 <kaniini> i would check all the binaries with scanelf for rpaths
21:20 <kaniini> because you clearly do have such binary somewhere
21:20 <^7heo> no I mean
21:20 <^7heo> chrpath(1)
21:20 <^7heo> I do not have that.
21:21 <^7heo> which is weird, because then how does abuild use the call?
21:21 <^7heo> aports/main/chrpath
21:21 <^7heo> I have an abuild for it.
21:22 <^7heo> ok installed.
21:22 <^7heo> I'm not used to have a package that goes by the name of the program I want. That was an easy one.
21:24 <kaniini> you would use chrpath to delete the rpaths in the apkbuild
21:24 <^7heo> yeah but it would be very convenient to know what binary is faulty.
21:24 <kaniini> humm
21:24 <kaniini> it used to say
21:24 <^7heo> because right now I kinda have to hunt for it.
21:24 <kaniini> try abuild -v
21:24 <^7heo> ok
21:25 <^7heo> rebuilding, thanks :)
21:25 <kaniini> duncaen: can you help with http://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/xbps/xbps-0.51-r0.log
21:35 <^7heo> kaniini: no rpath or runpath tag found.
21:35 <^7heo> v_v
21:36 <kaniini> :(
21:37 <^7heo> yeah
21:37 <^7heo> also the whole thing uses bash
21:37 <^7heo> I think I'm dropping it.
21:37 <^7heo> It's cool and all but...
21:37 <^7heo> dafuq
21:38 <^7heo> I burnt so many hours on that stuff...
21:48 <^7heo> ahahahahahahahahahahahaha
21:48 <^7heo> apk add graphite2
21:48 <^7heo> http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_home
21:48 <^7heo> that is the software you get.
21:49 <^7heo> I was like "weird that there's a 2 at the end...
22:21 <TemptorSent> Okay, that was easy -- hooks added to plugin loader in mkimage so we can totally separate the plugins from their plugs.
22:23 <TemptorSent> Now I just need to get them called automatically :)
22:37 vakartel joined
22:38 blueness joined