<    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 _3_0 31
00:35 blueness joined
01:28 Emperor_Earth joined
02:54 s33se_ joined
03:00 minimalism joined
03:47 shad0 joined
03:47 <shad0> TemptorSent, did you push on the same branch?
03:47 <TemptorSent> shad0 : Pull the current tree and take a look at the format.
03:48 <TemptorSent> Yes, keeping it on the same branch since it's essentially evolutionary at this point :)
03:48 <shad0> so pardon if this is ignorant, is mkimage.sh for making an iso?
03:48 <TemptorSent> Once the big refactoring of everything into it's own plugin, things tend to be farily easy to keep track of.
03:49 <TemptorSent> Not just isos, images of any sort, including rootfs, arm, etc. It also is learnign how to make any part of an image.
03:49 <shad0> from what I've skimmed from xplugin-mkinitfs.sh so far, seems pretty well organized
03:49 <shad0> ahh, gotch
03:50 <shad0> *gotcha
03:50 <TemptorSent> So it will be able to build whatver you request based on whichever profile you want.
03:50 <shad0> so this seems like an overhaul of a lot of the existing parts
03:51 <TemptorSent> Yeah, I basically just axed out everything but the functions from the existing mkinitfs, and the next step is to get rid of the horrible file loading glob mess.
03:51 <shad0> this looks pretty slick
03:52 <TemptorSent> Yeah, it basically already canabalized update-kernel (so we can make modloops without the ENTIRE module set being included) and now mkinitfs (So we can sanely add files/modules/init fragments to the initfs.
03:52 <TemptorSent> Oh, and fakeroot (see utils-fkrt.sh)
03:53 <TemptorSent> Its far from perfect, but hopefully it's at least an approachable starting place.
03:54 <shad0> I already saw hints of fakeroot stuff in the overlays section
03:54 <TemptorSent> I basically encapsulated the fakeroot functionallity and allow for multiple intances.
03:56 <TemptorSent> So it can be used inline in a script rather than having to write an external script and call it through fakeroot.
03:58 <TemptorSent> Basically the flow is that mkimage.sh loads the utilities (including the plugin loader), calls the plugin loader, then parses the command line, sets some values (WORKDIR, OUTDIR, etc) and goes on to the ARCH loop.
03:59 <shad0> so it'll all be driven from the command-line interfacing with whatever plugins can be loaded?
03:59 <TemptorSent> The ARCH loop creates an apk tree for each arch, then runs the build_profiles in a subshell. The rest is all loaded and populated by the plugin loader.
04:00 <shad0> command-line+profiles+arch-loop, it sounds like
04:00 <TemptorSent> The arch loop is actually outside the profile loop
04:00 <shad0> my bad :)
04:00 <TemptorSent> so its plugin loader, then arch-loop, then profile-loop inside that.
04:01 <TemptorSent> See profiles/plugin-profiles.sh
04:01 <shad0> and I'm guessing the command line options are fairly high level for control of output, selecting plugins and architectures... not necessarily nitty gritty profile(or lower) details?
04:01 <TemptorSent> Some of these need to be rearranged for clarity I suppose.
04:02 <TemptorSent> They don't do anythign with plugins, just select which profiles and archs (along with repos, keys, and the like)
04:02 <TemptorSent> The plugins are ALL autoloaded :)
04:02 <TemptorSent> Even the build system itself.
04:03 <TemptorSent> Take a look at the plugin loader.
04:03 <shad0> ok
04:04 <TemptorSent> It's actually quite simple, but it bootstraps what to load based on the plugins it finds in the target directory structure named 'plugins-*.sh'
04:04 <shad0> that sounds reasonable to me.
04:05 <TemptorSent> So plugin-overlays.sh implies that any overlay-*.sh is to be loaded.
04:05 <TemptorSent> (that's 'plugin-*.sh', no 's')
04:06 <shad0> ahh, ok.
04:06 <TemptorSent> It simply strips the trailing 's', nothing fancy on plurals.
04:07 <TemptorSent> If you're really bored and want to implement plural-parsing, be my guest :)
04:07 <shad0> this all sounds good. do you need help testing it, or more cleanup, patching holes from the re-organization, or all of the above? :)
04:07 <TemptorSent> *lol* D. All of the above.
04:08 <shad0> ok
04:08 <TemptorSent> mkinitfs integration hasn't begun beyond splicing in the code and converting a few features.d files.
04:09 <TemptorSent> And I've only built features for the thigns I need or want to test thus far, and not terribly completely at that.
04:09 <shad0> well, that sounds apropos since I may need that for my nvme device.
04:09 <shad0> (assuming it isn't already fixed)
04:10 <TemptorSent> Well, the code should actually work as it calling mkinitfs with the right options if you make a profile (unless I broke somethign with a random 'i' again)
04:11 <TemptorSent> But the organization of features.d is painful at best, and to get basic scsi you end up with over a hundre drivers. Let's not look at ata, or network, shall we?
04:13 <TemptorSent> Many/most of the initfs features should eventually likely find their way into a top level feature, but we can rearrange that later with minimal pain since the loader doesn't care where under the base it finds the files to load.
04:14 <TemptorSent> Actually, names don't matter beyond making sure they get loaded.
04:15 <shad0> true, but I still like naming things so that people don't have to wonder what it does
04:15 <TemptorSent> You can call the plugin loader with a single file with a complete profile, initfs, overlay, bootloader, etc defined in it.
04:15 <shad0> (as much as is possible without making 100-char names)
04:15 <shad0> this sounds like docker for alpine
04:15 <shad0> sort of
04:16 <TemptorSent> Yeah, that's why I'm naming the initfs features as initfs-<kernel tld>-<feature name> where appropriate.
04:16 <TemptorSent> It can either work stand alone, or be used to make tailored docker images.
04:18 <TemptorSent> It should shave a signficant amount of overhead off a base VM image, as well as building pre-configured rootfs and overlays.
04:19 <shad0> out of curiosity/ignorance, how big are the base VM images now?
04:20 <TemptorSent> Well, they include the entire modules hierarchy from the kernel package at the least, I think we were looking at 50MB with a rootfs?
04:21 <shad0> horrendous ;-)
04:21 <TemptorSent> Let me build one and see what it comes up as.
04:21 <TemptorSent> That's one of the images I've been using to test the build system isn't broken :)
04:24 <TemptorSent> Okay, not that bad on the virtio-only one I have, only 28M
04:25 <TemptorSent> Still, it could be half that.
04:28 <TemptorSent> Anyway, you can more or less see the template I'm using to replace the files from /etc/mkinitfs/features.d in the ones I've done so far, essentially once the existing ones are converted, I was going to split the general ones down to size (acutally, I've already sorta done so in a local dir tree, but it's not great because I was trying to hobble by with the existing notation.
04:29 <TemptorSent> What needs to happen is common features need to be extracted to their own functions and called from those that depend on them.
04:30 <TemptorSent> Since we're just using cat and HEREFILEs, it's pretty straight forward.
04:33 <shad0> ok. I'll let you know what I can contribute. hopefully it's > 0
04:34 <TemptorSent> *lol* There's always that nvme to start with :)
04:34 <shad0> that might be where I end up starting. I'd like to set alpine up as a docker host
04:35 <TemptorSent> It should do that happily.
04:35 <shad0> hey, silly user question. I have two vm's, one with the -standard image, and one with -extended. however, they both seem to install to the same 310mb size in /
04:35 <TemptorSent> Hmm.. dunno there.
04:36 <shad0> ok. just curious
04:36 <TemptorSent> I'm not involved in the devs release cycle, this whole mkimage mess is on my head :)
04:39 <shad0> gotta love the pressure, eh? ;-)
04:39 <TemptorSent> In theory, standard should be a fair bit smaller than extended.
04:39 <shad0> the iso is
04:39 <TemptorSent> I need it so I can use it, might as well do it right.
04:39 <shad0> so maybe it's just the apk cache that's bigger.
04:40 <TemptorSent> Yeah, the isos don't actually install anything but the base system until you ask them to.
04:40 <shad0> hey, did you hear that? I think someone's swinging a cluebat my direction ;-)
04:41 <TemptorSent> Isn't that a clue-by-four? Or is that too bass-ackward of a measurement these days?
04:41 <shad0> either one's gonna sting
04:42 <shad0> might depend which neighborhood/city you're from
04:42 <TemptorSent> I live in Foresthill, California -- it's more rural than it sounds ;)
04:43 <shad0> geez that's fairly middle of nowhere.
04:44 <shad0> but scenic AF, I imagine
04:44 <TemptorSent> Although somewhat more modern than Iowa Hill in most respects -- we actually have electricity here at least! The next hill over, it's all generators or solar.
04:44 <shad0> lol
04:44 <TemptorSent> But it's easier to pay my bar tab in gold in Iowa Hill -- the scale's always ready.
04:45 <shad0> funny enough my brother lives within "I can hear that shit" distance of a wind farm. he gets some stipend from the power company. loves everything about it, but he's a techie. most local folks are deep in NIMBY land.
04:46 <shad0> I thought you were kidding about Iowa Hill. do you just speed through Yankee Jims?
04:46 <TemptorSent> It's amazing what people will push for in someone ELSE'S backyard, but the moment you suggest they put it in theirs.
04:47 <TemptorSent> Not so much speed :) I actually live on the road that intersects YJ.
04:47 <shad0> most of these people aren't anywhere near the wind farm, either, they're in shitty little dying towns...but it's rural IL so they've got to drive through it to get anywhere else.
04:47 <shad0> and being rural IL, the average intelligence level is......... low.
04:48 <TemptorSent> It's actually pretty good around here, but not the most socially acceptable lot, to put it quite mildly :)
04:50 <TemptorSent> What's awesomely ironic is that they DO have fiberoptic internet service in Iowa Hill, while I'm stuck on a delapidated old copper drop with DSL that can't get out of it's own way and dies every time a rain-storm fills the splice-boxes.
04:51 <shad0> ouch. my bro's work is actually a POP for some crazy ass internet 2+ level backbone running up and down the state. he used to have a hard time finding speed test servers that could saturate his line. O_O
04:51 <TemptorSent> Okay, I believe I've ticked off all the filesystems that existed in features.d already, but which other should we include?
04:51 <shad0> I've got like 50mbit and he makes me feel like I'm on dialup
04:52 <shad0> ext2/3/4/xfs/btrfs/ntfs?
04:52 <TemptorSent> Damn, I'm happy to see sustained >1mbps
04:52 <shad0> and/or vfat/fat16?
04:52 <shad0> I'm in the Chicago suburbs. if I wanted to sacrifice my soul to comcast, I could see more. but screw them.
04:53 <shad0> his home line is maybe 1-2mbps. I think he does it via radio/microwave
04:53 <TemptorSent> I have the fat somewhere in my other tree, let me grab it. I didn't do ntfs since I think ntfs3g is the preferred method.
04:53 <shad0> right
04:53 <TemptorSent> And I *HOPE* we don't need that at boot, although it's not impossible I suppose.
04:53 <shad0> but fat/vfat/exfat would be helpful for anyone who's hooking up usb devices (and possibly running/loading from usb)
04:53 <shad0> it's a fair thing to leave out, I think
04:54 <shad0> anybody who cares about ntfs for boot should probably just convert to ext/xfs/btr
04:56 <TemptorSent> Does anyone actualy use msdos fs driver?
04:57 <shad0> probably not. but is it a dependency of exfat or vfat/fat32?
04:59 <TemptorSent> It appears to depend on fat but have no deps on it.
05:00 <TemptorSent> I believe it's a case-insensitive, 8.3 only driver for fat, vs vfat, which is anything since the early 90s.
05:01 <TemptorSent> We can add 'em as we need 'em to some extent -- deps will be pulled in automagically.
05:04 <TemptorSent> CIFS, NFS, NBD, etc. next.
05:05 <shad0> people using CIFS or NFS in the initfs will probably be pretty few and far between. even fewer for NBD, I would guess
05:06 <TemptorSent> Not really, PXE boot is pretty common.
05:06 <TemptorSent> Even SSH is a viable possibility.
05:06 <shad0> oh, true
05:07 <TemptorSent> Especially embedded/virtual stuff.
05:07 <shad0> makes sense
05:07 <TemptorSent> You might be running VMs on a diskless host.
05:07 <TemptorSent> In which case you bring up the initrd, mount the iscsi, and go.
05:09 <TemptorSent> So, do we support all flavors of nfs with a single feature, or do we break it out similar to ext2/3/4?
05:24 <TemptorSent> Anyway, as we develop more specific features (filesystems especially), we can move the initfs-*.sh files to their appropriate location and nicely encapsulate everything.
05:29 blueness joined
05:32 <TemptorSent> I went with the all in one for now. We can add them broken out if we need to at a later date.
06:01 <shad0> you might want to separate nfs v4 (and possibly v3?) from v2. v2 is pretty basic afaik
06:01 <shad0> eh, I'm sure it won't be hard to split later if that ends up being better
06:04 <TemptorSent> shad0: Yeah, it's just a matter of adding a set of more specific functions.
06:11 fabled joined
06:13 <TemptorSent> G'd evening fabled ;)
06:20 <fabled> TemptorSent, morning
06:22 <TemptorSent> How was your weekend?
06:26 <fabled> still not all good. had some weird flu earlier. hopefully getting finally back on track
06:26 <fabled> hunting coffee now...
06:26 <fabled> back in 15mins...
06:29 <TemptorSent> fabled: Ug, yeah - flu going around here too, along with an ugly preview of allergy season.
06:29 <TemptorSent> Coffee helps. Good coffee helps significantly :)
06:37 <kaniini> ncopa, fabled my conclusion on splitting PaX into small patches is -- it's looking more towards impossible
06:37 <kaniini> there's a lot of reformatting that is going on making it very hard to do by hand
06:39 <TemptorSent> kaniini: How would it fair against an unformated comparison approach? Is it just whitespace/line breaks, or major reordering?
06:39 <kaniini> TemptorSent: there's other problems, such as changing type declarations to macros
06:40 <TemptorSent> kaniini: Irritating. I'd be tempted to run just cpp against both the patched and vanilla source then compare the resultant files.
06:41 <TemptorSent> kaniini: That will give you enough to make a translation table most likely.
06:41 <kaniini> TemptorSent: across 1800 files it is really not worth it
06:41 <TemptorSent> kaniini: Yeah, that's why you'd have to automate most of it, then review.
06:42 <TemptorSent> By then, you might be better off reimplementing what's good and scrapping the rest.
06:42 <kaniini> TemptorSent: my conclusion is ultimately that hardening the applications themselves is just as valid of an approach as using PaX as a catch-all
06:43 <TemptorSent> kaniini: Agreed. PaX is useful for catching things that slip through the cracks, but your better off reducing the cracks first.
06:43 <kaniini> well
06:44 <kaniini> PaX is being closed is the problem
06:44 <kaniini> :p
06:45 <TemptorSent> Yeah, I'll take a peek at it later perhaps, but unless there's a major win to be had, it's not worth both the initial effort and ongoing maintence if it's never getting upstreamed.
06:51 slukin joined
07:34 tty` joined
07:38 <fabled> kaniini, you working on splitting pax ?
07:40 <TemptorSent> kaniini: ^^^ He appears to be leaning towards throwing in the towel on that mess.
07:40 vakartel joined
07:40 <TemptorSent> er, fabled: ^^^
07:41 <fabled> yes, i saw the backlog. that's why asking.
07:42 <TemptorSent> I'd have to sit down and look at it when I was feeling a bit more alive. It sounds like it's worse than the last time I looked at it in gentoo land years ago.
07:42 <TemptorSent> I'm afraid my eyes just can't handle that abuse anymore.
07:47 <TemptorSent> I'm getting towards the end of my night, no watchign the sunrise for me again with any luck.
07:48 <TemptorSent> Anyway, I'm chewing through the mkimage/update-kernel/mkinitfs mess and have just about finished the major surgery to meld everything.
08:23 <kaniini> fabled: i gave it a go
08:33 tty` joined
08:34 <ncopa> kaniini: morning
08:34 <ncopa> yeah i kind of expected it to be a close to impossible task
08:38 <ncopa> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80094
08:38 <ncopa> i dunno if we need/want to patch our gcc
08:39 <kaniini> i think it is worthwhile
08:40 <kaniini> even if the situation is that we drop grsecurity (it appears this is probably the situation), we do want gcc plugins support to work reliably
08:46 t0mmy joined
08:54 stwa joined
09:04 fekepp joined
09:15 czart__ joined
09:20 t0mmy joined
09:28 <TemptorSent> Alright, I'm calling it a night -- most of the first cut of mkinitfs work is staged, will enable and test tomorrow.
09:29 <TemptorSent> Everything is pushed, feel free to comment.
09:30 <TemptorSent> G'night all, have a great day.
09:37 KSD joined
09:53 royger joined
10:40 leitao joined
10:54 blueness joined
11:39 <ncopa> im thinking of tagging abuild not
11:39 <ncopa> now*
11:40 <ncopa> maybe 3.0.0_rc1
11:40 <ncopa> are there anything else important we should pull in before i tag?
11:41 <clandmeter> why the major version bump?
11:42 <fabled> clandmeter, "set -e" is now default
11:46 <ncopa> im thinking we should not remove the || return 1 from APKBUILDs til after v3.6 release
11:46 <ncopa> even if we enable set -e as default
11:47 <pickfire> return 1 is problematic
11:47 <pickfire> But what happens if we remove it?
11:47 <ncopa> becomes more work to backport fixes
11:47 <pickfire> I mean why remove it?
11:50 <ncopa> because we are about to enable set -e
11:50 <ncopa> so || return 1 will not be needed
12:09 <^7heo> ncopa: we could just change the travis process to fail if the script contains 'return 1'
12:10 <^7heo> which brings us back ot what I wanted to do eons ago
12:10 <^7heo> i.e. pattern matchingon the APKBUILD contents
12:11 <^7heo> matching even
12:11 <^7heo> matching on* actually
12:25 leitao joined
12:26 leitao joined
12:30 farosas joined
12:45 <ncopa> abuild 3.0.0_rc1 pushed
12:46 <ncopa> i think we should keep the || return1 til after we have branched 3.6-stable
12:56 stwa joined
13:07 farosas joined
13:15 stwa joined
13:20 tmh1999 joined
13:44 ferseiti joined
13:45 alacerda joined
14:05 <^7heo> TemptorSent: not sure if you're here yet
14:05 <^7heo> TemptorSent: but from the docker images, I identified 67 files, 79 directories, and 30X links needed.
14:06 <^7heo> most of them system binaries and links thereof.
14:34 <pickfire> !3188
14:34 <pickfire> %3188
14:35 <algitbot> [alpine-aports] main/linux-grsec: Add support for hid wacom tablets - Patchwork: http://patchwork.alpinelinux.org/patch/3188/
14:35 <^7heo> ! would be a great addition for github
14:36 <pickfire> ncopa: Sorry axout that, did rebase but looks like patchwork doen't look into --in-reply-to 20170320144517.79035661@ncopa-desktop.copa.dup.pw
14:36 <pickfire> I mean that's a git command
14:37 <pickfire> %3187 can be deleted
14:37 <algitbot> [alpine-aports] main/linux-grsec: Add support for hid wacom tablets - Patchwork: http://patchwork.alpinelinux.org/patch/3187/
14:37 <pickfire> ^7heo: How should we send patch v2?
14:38 <^7heo> with github, you just git push
14:38 <^7heo> with the ML, I'm not sure.
14:38 <ncopa> https://wiki.alpinelinux.org/wiki/Creating_patches
14:38 <ncopa> pickfire: ^^^ see last section
14:38 <pickfire> http://patchwork.alpinelinux.org/patch/3184/ Is v2
14:38 <pickfire> http://patchwork.alpinelinux.org/patch/3187/ is broken
14:39 <pickfire> ncopa: Thanks a lot
14:39 <pickfire> ncopa: Those py-* from github can be pulled
14:39 <pickfire> I just version bump, I build it successfully on my computer.
14:40 <pickfire> I won't push to github for the time being.
14:40 <pickfire> Shupid branches gone horribly wrong.
14:50 fekepp joined
14:52 <pickfire> ncopa: http://git.pickfire.tk/aports/refs/
14:53 <pickfire> I hope you can pull in firefox (not fully tested), python and upgrade.
14:54 <pickfire> jirutka: ^
14:54 <pickfire> Happy?
14:54 <pickfire> It is also in github as well. But just that pull requests are not fixed.
14:54 <pickfire> Next time.
14:55 <pickfire> Need to shower and sleep
14:57 <jirutka> pickfire: have you noticed https://github.com/alpinelinux/aports/pull/1020#issuecomment-287494669 ?
14:58 <pickfire> Yes
14:58 <pickfire> Saw that before I went for holiday.
14:58 <jirutka> pickfire: ad py-*, have you checked dependencies? i.e. that the upstream hasn’t added new dependency to the package
14:58 <pickfire> ?
14:58 <pickfire> jirutka: Example?
14:59 <pickfire> Ah
14:59 <jirutka> pickfire: uff, python packages usually depends on another python packages, this is specified in setup.py and currently must be reproduced in abuild
14:59 <pickfire> jirutka: I did it in python branch instead of update-py
14:59 <jirutka> pickfire: name of the branch doesn’t matter
15:00 <pickfire> I haven't checked dependencies
15:00 <pickfire> Because I don't think dependencies change regularly
15:00 <jirutka> pickfire: what problem do you have with branches? it seems that you’ve successfully created new branches in your git repo, so what is so difficult to just push them also to GH?
15:00 <pickfire> I had also pushed them to GH
15:00 <jirutka> pickfire: aha, you just _hope_ that they are still correct…?
15:01 <pickfire> No
15:01 <pickfire> jirutka: What do I do then?
15:01 <pickfire> https://github.com/pickfire/aports
15:01 <pickfire> jirutka: It is in GH as well because GH is the mirror
15:01 <jirutka> I see, branches are here, so just create PR for each of them
15:03 <jirutka> you can use e.g. https://github.com/Idnan/github-pr (just don’t install with sudo!) or manually (click on New pull request in your repo)
15:03 <jirutka> but GH usually provides you tooltip to directly create a PR when you push new branch
15:04 <pickfire> jirutka: Yes
15:05 <pickfire> I will click on that link later on.
15:05 <jirutka> okay
15:05 <pickfire> github-pr doens't looks nice
15:05 <jirutka> yes, it doesn’t
15:05 <pickfire> jirutka: Can't you click on those tooltip?
15:06 <jirutka> but can’t find any better that is not unnecessary complex
15:06 fabled joined
15:06 <jirutka> I should finally write some simple and foolproof cli tool for alpine contributors
15:07 <jirutka> like behalf of you? hm, dunno, I can try it
15:07 <jirutka> afk
15:07 <pickfire> jirutka: I hope it's a one run command to automatically click those thing. Of course, everyone who seldom use github can use that.
15:07 <pickfire> :)
15:08 <pickfire> It's interesting to hear auto github upstream pull request
15:10 <pickfire> By the way, can I use travis to build on my github repo?
15:11 <* pickfire> just click on those slow links
15:11 <pickfire> Done
15:17 blueness joined
15:19 <pickfire> Looks like everything is broken now
15:19 <pickfire> ERROR: libarchive-3.3.1-r0: package mentioned in index not found (try 'apk update')
15:19 <pickfire> https://alpine.mirror.wearetriple.com/edge/main/all/
15:19 <pickfire> Why is there "all"?
15:25 <pickfire> And as well, github builds are failing.
15:33 minimalism joined
15:37 <nmeum> > fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
15:38 <nmeum> > ERROR: http://dl-cdn.alpinelinux.org/alpine/edge/main: No such file or directory
15:38 <jirutka> pickfire: yes, you can, see https://github.com/jirutka/user-aports
15:38 <nmeum> what's wrong with dl-cdn?
15:38 <pickfire> nmeum: Not only dl-cdn
15:39 <pickfire> I think all mirrors gone wrong.
15:39 <jirutka> yes
15:39 <ncopa> what!
15:39 <ncopa> what just happened
15:41 <pickfire> jirutka: Nice, then we can use travis-ci as our builder.
15:41 <pickfire> ncopa: Black magic.
15:41 <pickfire> Looks like https://alpine.mirror.wearetriple.com/edge/main/all/ is not the only one
15:46 <jirutka> Huston, we have a problem… currently investigating what has happened, please keep calm and do not panic, I repeat, DO NOT PANIC
15:48 <ncopa> so x86_64 was removed
15:48 <ncopa> x86 too
15:48 <ncopa> and armhf
15:48 <ncopa> aarch64 seems to be there
15:49 <ncopa> i wonder what happened
15:50 <nmeum> wait what?
15:50 <nmeum> so we have to rebuild all packages for those architectures?
15:51 <clandmeter> no
15:51 <ncopa> the builders have the files
15:51 <ncopa> they got deleted from master mirror
15:51 <ncopa> i wonder how
15:51 <clandmeter> keep calm, its a push issue, source is still here
15:52 <* fcolista> keep calm.
15:52 <ncopa> hum
15:52 <ncopa> i think you can panic now
15:52 <* fcolista> started to scream louder
15:53 <ncopa> aarch64 disapeared too
15:53 <* ^7heo> rushes to the big "PANIC" button
15:53 <* ^7heo> spams on it
15:53 <* fcolista> runs away
15:53 <jirutka> nmeum: hopefully not
15:54 <ncopa> i think its abuild that broke it
15:55 <clandmeter> hmm
15:56 <^7heo> I have 0 visibility, so I can't help anyway
15:56 <^7heo> So good luck guys
15:58 <jirutka> I’ve reviewed the last two commits in abuild later and haven’t find anything wrong, I’ve checked it again now and still nothing wrong…
15:59 <jirutka> aha, but there are many more commits after the last stable
16:00 <jirutka> ^7heo: you have more than 0 visibility, you can help to find the bug in aports, check commits since 2.29.0
16:00 <^7heo> but what should the bug be like?
16:00 <^7heo> I don't even know what happened.
16:01 <ncopa> wild guess
16:01 <ncopa> abuild -R is broke
16:01 <ncopa> no
16:01 <ncopa> i mean
16:01 <jirutka> -K is broken btw
16:01 <jirutka> but that is a different story
16:01 <ncopa> abuild -A
16:02 <ncopa> yeah
16:02 <ncopa> thats it
16:03 <ncopa> huh
16:03 <ncopa> but why
16:04 <ncopa> ok
16:04 <ncopa> i found it
16:04 <jirutka> abuild -A removes files? o.O
16:05 <ncopa> no
16:05 <ncopa> arch=$(abuild -A)
16:05 <ncopa> rsync .... $foo/bar/$arch
16:05 <ncopa> and it does not break on my dev box
16:05 <ncopa> it only happens on build box
16:06 <ncopa> build-edge-x86_64:~/packages/main/x86_64$ sh -x -e /usr/bin/abuild -A 2>&1 | tpaste
16:06 <ncopa> http://tpaste.us/0NEd
16:06 <jirutka> I don’t understand, what can be wrong with abuild -A? it just prints arch
16:08 <ncopa> so arch=""
16:08 <ncopa> and we end up missing last element of path in rsync --delete
16:09 <jirutka> aha…
16:09 <ncopa> http://tpaste.us/aQxK
16:09 <ncopa> that should be the fix
16:10 <jirutka> the rsync script must be fixed
16:10 <ncopa> yes
16:11 <jirutka> btw are these builder scripts somewhere in git?
16:11 <ncopa> yes
16:11 <ncopa> aports/main/aports-build/aports-build
16:11 <ncopa> there is the rsync script
16:12 <jirutka> do you have the deleted data somewhere?
16:13 <clandmeter> its not deleted on the builder
16:14 <jirutka> okay
16:14 <clandmeter> it deletes when it pushes to the mirrors
16:14 <jirutka> afk, I’ve just arrived to Prague
16:14 <^7heo> ncopa: good find
16:14 <clandmeter> going home, dinner time.
16:14 <^7heo> yeah it makes sense
16:14 <^7heo> the deletion happens at the rsync level
16:14 <^7heo> not at the build level
16:30 <TemptorSent> ^7heo: 'morning - just catching up on the backlog.
16:31 <^7heo> TemptorSent: you can ignore anything after 1500 CET
16:31 <^7heo> i.e. anything younger than 2.5h
16:40 BitL0G1c joined
16:44 <TemptorSent> ^7heo: You mean the fun as the world implode briefly?
16:45 <BitL0G1c> http://nl.alpinelinux.org/alpine/edge/main has disappeared
16:45 CnTLDude joined
16:46 <ncopa> BitL0G1c: should be restored on next mirror sync
16:46 <ncopa> 15 mins or so i guess
16:47 <BitL0G1c> ok np - just wondered if you were aware
16:52 <^7heo> TemptorSent: yeah
16:52 <TemptorSent> ^7heo: So, got a list of which files are actually used?
16:53 <^7heo> yeah
16:53 <^7heo> wasn't too hard
16:53 <^7heo> $ docker run --rm -it alpine:latest find | grep -v '^\./sys/\|^\./proc/\|^\./dev/'
16:53 <^7heo> here.
16:54 <^7heo> it's mostly links tho
16:54 <TemptorSent> Ahh, does it actully use all of those files even I wonder?
16:54 <^7heo> like around 60 files, 70 directories
16:54 <^7heo> and the rest is links
16:54 <TemptorSent> Most should be BB links
16:54 <kaniini> hi
16:54 <^7heo> exactly
16:55 <^7heo> BB links. To link BB guns
16:55 <^7heo> :D
16:55 <^7heo> hi kaniini
16:55 <^7heo> TemptorSent: 60 files is fine tho
16:55 <^7heo> TemptorSent: we can copy that :P
16:55 <^7heo> most of it is in /etc/
16:55 <TemptorSent> ^7heo : Yeah, that's within the realm of reason at least.
16:56 <kaniini> did we accidentally delete our archive?
16:56 <kaniini> :D
16:56 <^7heo> kaniini: there's been a fuckup with a rsync script relying on abuild -A returning a value, while abuild -A returned "" at times.
16:56 <TemptorSent> ^7heo: We can probably thin that out a bit one we start testing.
16:56 <^7heo> kaniini: therefore effectively deleting packages from the mirrors
16:56 <^7heo> kaniini: it's patched now afaik
16:56 <kaniini> :D
16:57 <ncopa> kaniini: yeah, first "catastrophe" from the abuild set -e change
16:57 <kaniini> that doesnt seem that bad
16:57 <ncopa> must admit that it was a bit unexpected
16:57 <TemptorSent> Good thing to get the blood pumping on a Monday anyway ;)
16:57 <^7heo> :D
16:57 <ncopa> ha
16:58 <^7heo> ncopa did most of it anyway
16:58 <ncopa> i actually thought about pushing is on friday
16:58 <^7heo> ncopa: we can now see that you value your weekends ;)
16:58 <^7heo> ncopa: good.
16:58 <ncopa> this is why it is a bad idea to push scray things on fridays
16:58 <^7heo> s/scray/scary/
16:58 <^7heo> s/scary//
16:58 <ncopa> yeah i value weekends
16:58 <^7heo> ;)
16:59 <ncopa> must do that to be able to maintain opensource for a decade without burning out
17:01 <skarnet> Google has a policy: no pushes to production on Fridays. Now you know why. :)
17:01 <ncopa> yeah
17:01 <^7heo> nobody pushes to prod on friday
17:02 <^7heo> unless they have their week ends on wed-thu
17:02 <ncopa> lol
17:02 <scadu> xD
17:02 <skarnet> also, it would be nice to have a canary, so a bad push doesn't blow up the world
17:02 <^7heo> yep
17:02 <^7heo> I agree with that
17:02 <ncopa> yep
17:03 volleyper joined
17:03 <TemptorSent> skarnet: Canaries are happier in pairs, we need two :)
17:03 <skarnet> isn't that turtledoves?
17:04 <skarnet> or humans?
17:06 <TemptorSent> skarnet: Well, most creatures if you put it that way I suppose.
17:07 <TemptorSent> skarnet: But 1. Yes, canaries do pair strongly. and 2. Having a canary both on the rsync script and in the abuild would be wise.
17:07 <^7heo> ncopa: what's in /usr/lib/engines/?
17:10 <TemptorSent> skarnet: At the very least, a verification that all expected variables have values before proceeding, preferably with some explicit checking, and a canarry value that will cause failure if missing or altered (catch run-away sed scripts and such)
17:41 BitL0G1c joined
17:45 tmh1999 joined
17:46 Somasis joined
17:46 Somasis joined
17:53 <^7heo> TemptorSent: I'm actually thinking of doing a distribution of the minimal files needed
17:55 <TemptorSent> ^7heo: We can do that fairly easily under mkimage at this point I believe. Take a look at the new initfs directory.
17:56 <^7heo> nah but
17:56 <^7heo> https://nl.alpinelinux.org/alpine/v3.5/releases/x86_64/alpine-minirootfs-3.5.2-x86_64.tar.gz
17:56 <^7heo> that should do it
17:56 <^7heo> or?
17:56 <TemptorSent> ^7heo: Yeah, that's still not slimmed.
17:57 <^7heo> ?
17:57 <TemptorSent> ^7heo: Take that as the basis, then remove everything you don't need.
17:57 <^7heo> yeah well
17:57 <TemptorSent> ^7heo: Or more to the point, take that as the base, then extract to the target everythign you do need.
17:57 <^7heo> yeah
17:58 <TemptorSent> ala mkinitfs_feature_files
17:59 <^7heo> tbh
18:00 <^7heo> it contains about as many files as the docker image.
18:00 <TemptorSent> You give it a set of paths with globs, it only copies those paths and their discovered deps.
18:01 <TemptorSent> ^7heo: I wouldn't be surprised if that is essentially what the docker image is based on.
18:02 <^7heo> yeah
18:02 <^7heo> I mean
18:02 <^7heo> files only
18:02 <TemptorSent> ^7heo: Since mkimage knows how to make a rootfs for any profile now, we can tailor what we generate to the specific VM environment rather than including the kitchen sink.
18:02 <^7heo> the only differences are super minimal
18:02 <^7heo> the docker image has /etc/localtime
18:03 <^7heo> the miniroot one more apk key
18:03 <^7heo> the docker image has /etc/resolv.conf too
18:04 <TemptorSent> ^7heo: Yeah, it sounds like the docker image is probably based on the previous rev minirootfs and adds the required files to bootstrap the image and connect to the outside world.
18:04 <^7heo> yeah
18:05 <^7heo> and basically
18:05 <^7heo> if you add libcrypto to the miniroot
18:05 <^7heo> you get the docker image.
18:05 <^7heo> so there's that
18:06 <TemptorSent> ^7heo: Okay, so we can trim the fat from miniroot.
18:06 <^7heo> well
18:06 <^7heo> there's not much fat to trim
18:06 <^7heo> it's 1.9MB compressed ;)
18:07 <TemptorSent> ^7heo: Hmm, still won't fit on a floppy.
18:07 <^7heo> yeah but it's compressed anyway
18:07 <^7heo> you can't fit a kernel on a floppy...
18:08 <TemptorSent> ^7heo: Not these days, sadly.
18:08 <TemptorSent> ^7heo: I used to boot an entire system off a pair of floppies!
18:08 <^7heo> sure
18:08 <^7heo> with space to spare
18:08 <^7heo> but we're in 201
18:09 <^7heo> 7
18:09 <^7heo> anyway
18:09 <^7heo> basically
18:09 <^7heo> downloading the miniroot and extracting it is a good base
18:09 <^7heo> then there's libcrypto, for whatever it's needed
18:10 <TemptorSent> ^7heo: probably ssl libs.
18:11 farosas joined
18:11 <^7heo> ncopa: why is /dev/null needed in the miniroot fs?
18:12 <TemptorSent> ^7heo: /dev/null is one of the very few devices that posix REQUIRES.
18:12 <^7heo> yeah but it doesn't have to be in the archive, or?
18:12 <TemptorSent> ^7heo: Otherwise consider what happens when you do $cmd > /dev/null.
18:12 <^7heo> I know.
18:12 <TemptorSent> ^7heo: Yep, if it's not there, nothing in the archive will necessarily work right.
18:12 <^7heo> I'm just wondering how important it is that it is in the archive.
18:13 <^7heo> well, it could be created after.
18:13 <^7heo> but I see.
18:13 <TemptorSent> ^7heo: Critical to proper operation :)
18:13 <^7heo> I didn't know archives could attempt to mknod btw.
18:13 <^7heo> I mean, tar
18:15 <TemptorSent> ^7heo: Yup, it's a requirement for both tar and cpio to support device nodes.
18:16 leitao joined
18:17 <^7heo> ok
18:17 <TemptorSent> ^7heo: They're not special other than being devices, they act like 'normal' files to archive utils.
18:17 <^7heo> but now I'm really wondering
18:17 <^7heo> 1.
18:17 <^7heo> how many of those files are actually required
18:17 <^7heo> and
18:17 <^7heo> 2. especially in /etc
18:17 <TemptorSent> ^7heo /dev/null and /dev/zero should be there at the least.
18:17 <^7heo> no but for dev
18:17 <^7heo> I plan to mount -o bind /dev dev
18:18 <^7heo> so...
18:18 <TemptorSent> ^7heo: Likely not more than a few are actually required in /etc actually.
18:18 <TemptorSent> (from the department for redundancy deparment)
18:18 <^7heo> basically
18:19 <TemptorSent> ^7heo: Yeah, you can always bind mount dev if you want it available in the image, but in most cases you don't want nor need the entirely of /dev
18:19 <^7heo> we need to mount /dev, /dev/pts, /sys and /proc
18:19 <^7heo> copy a few files here and there
18:19 <^7heo> and that should do it.
18:19 <TemptorSent> ^7heo: Do you really need /dev/pts in a docker image?
18:19 <^7heo> that isn't for the scope of the docker image
18:19 <TemptorSent> Or /sys for that matter?
18:19 <skarnet> how would you ssh into it without /dev/pts
18:19 <^7heo> that is for the scope of a chroot
18:20 <TemptorSent> skarnet: I'd have to check whether ssh requires a pty if you're just running commands (sshv2 only obviously)
18:20 <^7heo> and basically, I think that the chroot can happen with less files than what is in the miniroot
18:21 <^7heo> also
18:21 <^7heo> my initial idea was to reuse the files from the running system
18:21 <^7heo> not to download anything.
18:21 <TemptorSent> ^7heo: Agreed, it would be good to get a bare-minimal system.
18:21 <skarnet> by default yes, there's an option to avoid requiring a terminal
18:21 <skarnet> I can provide bare-minimal systems but that won't be Alpine :P
18:21 <TemptorSent> ^7heo: The only problem you'll run into there is versioning I suspect.
18:21 <^7heo> ?
18:22 <TemptorSent> skarnet: The idea is to have the ability to spit out an absolutely minimal environment that can be used to bootstrap itself.
18:23 <skarnet> to bootstrap itself? that won't be minimal at all, you'll need a toolchain etc.
18:23 <TemptorSent> skarnet: Just enough to fetch the rest.
18:23 <skarnet> you mean a minimal production environment as opposed to a minimal development environment.
18:23 <TemptorSent> skarnet: No, I don't mean build everything from scratch, I mean pull the basic system using APK.
18:23 <BitL0G1c> jirutka - on travis: ERROR: openrc-0.24.1-r0: package mentioned in index not found (try 'apk update') - can you trigger a rebuild on wireguard when dl-cdn has updated ?
18:23 <skarnet> and even that is bigger than you think if you want it to be secure: to fetch the rest, you'll need the ability to d/l over HTTPS while verifying certificates etc.
18:24 <TemptorSent> skarnet: From there, it can be used for either development or production.
18:25 <TemptorSent> skarnet: Yeah, I realize the dep on ssl. We probably only need half of what ships in libcrypto though to get through bootstrapping.
18:26 <skarnet> tell fabled/kaniini to switch apk to BearSSL already.
18:26 <TemptorSent> skarnet: I have skel profiles which should provide the minimal set of packages, but even those contain far more extraneous stuff than we need.
18:27 <TemptorSent> skarnet: Does BearSSL support everything needed?
18:27 <^7heo> skarnet: verifying certificates is trivial if you have only one hardcoded cert you trust
18:27 <skarnet> depends on what's needed. The only thing missing from it atm is client certificates.
18:27 <^7heo> skarnet: much in the way apk keys work
18:28 <TemptorSent> ^7heo: There's actually quite a bit of overhead in verifying the keys.
18:28 <skarnet> ^7heo: even if you only have 1 hardcoded cert, you still need the engine, which is the hard part.
18:28 <TemptorSent> ^
18:28 <^7heo> yeah you need the engine
18:28 <^7heo> but since it's about using the installed files of the running distro to start the chroot
18:28 <TemptorSent> ^7heo : It needs the ssl transport and the ssl utils currently.
18:28 <^7heo> you just take that.
18:29 <^7heo> TemptorSent: hence the libcrypto.
18:29 <^7heo> my current problem is that I can't seem to chroot tho.
18:29 <TemptorSent> ^7heo: Yeah, the trick is to figure out what part of libcrypto we actuall use.
18:29 <TemptorSent> ^7heo: grsec hell?
18:29 <^7heo> not sure yet.
18:30 <^7heo> I'll copy more stuff there
18:30 <^7heo> I guess busybox isn't compiled statically.
18:30 <skarnet> TemptorSent: libcrypto is a monolithic monster. You're better off using another implementation if you want to cut through fat.
18:30 <^7heo> nah it's not.
18:31 <skarnet> it's not? then why does s6-tlsc weigh 1.5 MB when linked against LibreSSL ?
18:31 <^7heo> ok it's actually easy.
18:31 <^7heo> skarnet: it's not compiled statically.
18:31 <TemptorSent> skarnet: Yeah, agreed. For now, we can at least reduce the amount of non-necessary stuff installed by just cherry-picking the part we actually need. The initfs pulls a minimal set.
18:31 <^7heo> skarnet: that's what I meant.
18:32 <^7heo> I have a minimal shell in the chroot
18:32 <^7heo> copied two files over.
18:32 <^7heo> now time to create symlinks.
18:32 <jirutka> ^7heo: I think that for minimal chroot environment you need just busybox (and prepare /dev, /sys etc.)
18:32 <jirutka> ^7heo: but I’m late to this discussion, so don’t know context
18:32 <^7heo> nah you're right
18:33 <^7heo> the assumption I made was that busybox was statically linked against musl
18:33 <TemptorSent> jirutka: Yes, that should get you a working chroot -- but to pull alpine, you need a handful more files.
18:33 <^7heo> so I just stupidly copied only busybox
18:33 <TemptorSent> ^7heo: Try bb-staic :)
18:33 <TemptorSent> s/staic/static/
18:33 <^7heo> yeah my brain corrected already
18:33 <^7heo> but it's not in the default system
18:33 <^7heo> nor it is in the minirootfs
18:34 <jirutka> TemptorSent: what do you mean by “pull Alpine”?
18:34 <jirutka> TemptorSent: to have working apk?
18:34 <TemptorSent> jirutka: Have working apk and be able to verify integrity.
18:34 <jirutka> so busybox + apk.static :P
18:35 <^7heo> yeah but that's the catch
18:35 <^7heo> my idea is to replace the network by local copy
18:35 <^7heo> (i.e alpine to alpine file copying)
18:35 <^7heo> and by default you don't have apk.static
18:35 <kaniini> skarnet: we use openssl for legal reasons
18:35 <jirutka> or dynamically linked bb and apk-tools, so this would also pull musl, libressl, zlib
18:36 <TemptorSent> jirutka: bb-static + apk.static should be pretty much the minimal set. But pulling the deps for the dynamic versions is easy enough (see lddtree usage in mkinitfs)
18:36 <jirutka> ^7heo: apk-tools-static https://pkgs.alpinelinux.org/package/v3.5/main/x86_64/apk-tools-static
18:36 <kaniini> skarnet: if openssl is a dependency on a core system tool, then it is arguably a core system component, per GPLv2/GPLv3
18:36 <jirutka> TemptorSent: you don’t need to do it manually, you can just install it using apk…
18:36 <skarnet> kaniini: ... and? what is the goal here?
18:37 <jirutka> TemptorSent: `apk --root /chroot --update-cache --initdb add alpine-baselayout apk-tools busybox`
18:38 <TemptorSent> jirutka: Right, except that ends up pulling a lot of unnecessary stuff as well.
18:38 <jirutka> TemptorSent: no, it does not
18:38 <TemptorSent> jirutka: Look at the resulting tree.
18:38 <jirutka> TemptorSent: that what I did
18:39 <^7heo> jirutka: it's exactly the same thing your alpine chroot script does, tho.
18:40 <^7heo> jirutka: (the dl-ing of the https://pkgs.alpinelinux.org/package/v3.5/main/x86_64/apk-tools-static file)
18:40 <kaniini> skarnet: if openssl is a 'core system component', then it is legal to link to openssl even without an openssl exception in the license
18:40 <^7heo> jirutka: apk --root /chroot --update-cache --initdb add alpine-baselayout apk-tools busybox
18:40 <^7heo> does that need root?
18:41 <^7heo> well I guess I'll just try.
18:41 <kaniini> ^7heo: in general, chroot() requires root privilege
18:41 <^7heo> yeah, but that is a folder name.
18:41 <skarnet> kaniini: that still doesn't tell me why it is useful now that Alpine has switched to LibreSSL
18:41 <kaniini> skarnet: because libressl is still under the openssl license
18:41 <^7heo> kaniini: if you follow my drift.
18:41 jirutka joined
18:41 <^7heo> jirutka: w
18:41 <^7heo> b
18:41 <TemptorSent> jirutka: Exactly why do we need anything in /etc/modprobe.d, /etc/sysctl.d, /etc/profile.d/color_prompt, /etc/chrontabs/root, /var/spool/chron/chrontabs in a chroot?
18:41 <^7heo> damn, two letters, I manage to miss one v_v
18:42 <skarnet> so you want to make libressl a core component, ok, got it
18:42 <jirutka> ^7heo: exactly, except I install alpine-base by default
18:42 <^7heo> TemptorSent: we don't.
18:42 <jirutka> ^7heo: skarnet: then you can replace apk-tools with apk-tools-static
18:42 <^7heo> anyway
18:42 <TemptorSent> ^7heo: Take a look at apk info -L alpine-baselayout :)
18:42 <^7heo> yeah
18:43 <^7heo> seems that this is what I was seaching for.
18:43 <jirutka> TemptorSent: these are just static configs, but well, if you want to strip them down, you can write your own alpine-baselayout pkg ;)
18:43 <TemptorSent> There's some trimming.
18:43 <^7heo> using apk for it is a very good idea.
18:43 <^7heo> nah but for now
18:43 <^7heo> I needed something minimal
18:43 <TemptorSent> jirutka: Much easier - just grab the files we actually need out of baselayout
18:43 <jirutka> yes, just use existing pkgs and maybe modify some, apk gives you all you need
18:43 <^7heo> with busybox, and apk installed
18:43 <^7heo> and that's exactly what you gave us :P
18:43 <^7heo> so thanks a lot jirutka
18:44 <jirutka> ^7heo: don’t thank me, but ncopa, fabled and others who wrote apk-tools! :)
18:45 <kaniini> skarnet: the situation is the least bad option
18:45 <^7heo> yeah
18:45 <^7heo> however
18:45 <^7heo> is there a way to fetch those packages from a local cache instead of from network?
18:45 <kaniini> skarnet: the problem is when a new maintainer takes over a GPL package, and then links against openssl/libressl
18:45 <^7heo> because the offline goal is still here =/
18:45 <kaniini> yes, create a local repo from the cache
18:46 <kaniini> by generating an apk index and signing it
18:46 <^7heo> kaniini: ok thanks :)
18:47 <kaniini> skarnet: the new maintainer, of course, does not have the rights to grant an openssl exception in their license
18:47 <TemptorSent> Question - is there any reason when generating an image we would NOT want to include the host-keys by default?
18:47 <_ikke_> ssh host keys?
18:47 <kaniini> yes
18:48 <kaniini> such practice is insecure
18:48 <kaniini> because it means someone else can replay your ssh sessions later by just downloading the same image
18:49 <_ikke_> They wouod
18:49 <jirutka> . /etc/ssh/sshd_host_* must be of course removed from image, this is beginner’s mistake to not do that ;)
18:49 <skarnet> kaniini: I'd still like to keep the legal bugware as separate as possible from the good tech
18:49 <TemptorSent> kaniini: Sorry, not ssh host keys, apk host keys
18:49 <_ikke_> would be able to mitm you without you noticing, right?
18:49 <jirutka> apk host keys?
18:49 <kaniini> _ikke_: that too, yes
18:49 <jirutka> you mean /etc/apk/keys ?
18:49 <jirutka> or your developer’s key?
18:50 <TemptorSent> jirutka, kaniini: Yes. mkinitfs has the --hostkeys option, and failing to enable it will cause an unbootable system unless you have explicitly included keys from elsewhere.
18:50 fabled_ joined
18:50 <kaniini> skarnet: i don't disagree, but the reality is what the reality is
18:50 <kaniini> skarnet: for what it's worth, apk-tools 3 will likely use nacl instead
18:51 <jirutka> TemptorSent: still don’t understand, what keys exactly do you mean?
18:51 <TemptorSent> jirutka: Yes, --hostkeys enables the copying of /etc/apks/keys/*
18:51 <kaniini> skarnet: since we are looking at curve25519
18:51 <kaniini> (although libressl has curve25519 too so...)
18:51 <jirutka> TemptorSent: keys in /etc/apk/keys are public, these are of course safe
18:51 <jirutka> TemptorSent: there’s no reason to remove them from image
18:52 <TemptorSent> jirutka: Right, which is why I'm wondering why they are NOT included by default under existing behaviour (got bit by that one and went nuts trying to debug it in init)
18:52 <skarnet> kaniini: this contradicts directly what you previously said. If you're using a new SSL lib for apk-tools 3 (which is inherently a good idea), then how will you pretend that LibreSSL is a core component of Alpine?
18:52 <jirutka> TemptorSent: these keys are installed with some base package
18:52 <jirutka> TemptorSent: there are in the package https://pkgs.alpinelinux.org/package/v3.5/main/x86_64/alpine-keys
18:53 <TemptorSent> jirutka: Right, I'm just looking at changing the logic to take --no-hostkeys if you really DON'T want to include the host keys in the image.
18:53 <TemptorSent> jirutka: Since broken by default seems like a bad thing.
18:53 <jirutka> TemptorSent: when you’re preparing the image, you should imo install alpine-keys
18:54 <TemptorSent> jirutka: So on dist builds, you may want to enable --no-hostkeys.
18:55 <TemptorSent> jirutka: For dists, that takes care of it, but for local builds, you may have apk keys that aren't in the alpine-keys package that need to be included.
18:55 <jirutka> TemptorSent: yes
18:58 <^7heo> damn, apk fails
18:58 <jirutka> b/c of mirrors?
19:01 <TemptorSent> jirutka: Okay, logic inverted - should be sane defaults for the most part now.
19:02 <^7heo> jirutka: yeah I think.
19:02 <^7heo> jirutka: I sent that to my VPS so I can work on it from anywhere.
19:02 <^7heo> jirutka: I have to move now :)
19:03 <tmh1999> sorry to interrupt, but for now we have any option for vnc server ? x11vnc seems to be in unmaintained mode.
19:04 <TemptorSent> tmh1999: Ouch, hadn't noticed that since I haven't need it yet on Alpine. Is it dead upstream?
19:06 <tmh1999> TemptorSent : x11vnc ? probably dead I guess
19:07 <tmh1999> TemptorSent : ah no : https://github.com/LibVNC/x11vnc
19:07 <TemptorSent> tmh1999: Quick search is referring to 'tigervnc' as an alternative.
19:08 <skarnet> rawr
19:08 <TemptorSent> tmh1999; It looks like that spun off from TightVNC, which is what I was using almost 20 years ago I think :)
19:10 <tmh1999> TemptorSent : I think I am gonna work on a vnc server for Alpine and submit an APKBUILD
19:10 <TemptorSent> tmh1999: Are you actually using a head on the machine you need it for?
19:11 <tmh1999> TemptorSent : pardon me ?
19:12 <jirutka> XD
19:12 <TemptorSent> tmh1999: Do you actually need x11vnc, which gives you a remote connection to a real, running X server, or do you need an X server that you can connect to using VNC?
19:12 <skarnet> never ask for head when you don't need it
19:13 <TemptorSent> *lol*
19:14 <tmh1999> the thing is I guess Alpine already had X server package somewhere
19:14 <tmh1999> so first choice I guess
19:15 <TemptorSent> tmh1999: That's not quite what I mean -- are you trying to remotely connect to a machine running a real, headed Xserver with it's own kbd/mouse/display, or are you trying to establish an Xserver to connect to using only VNC?
19:17 <tmh1999> oh the second choice TemptorSent
19:17 <TemptorSent> tmh1999: (in jargon 'headless' referrs to running without a locally attached display and input)
19:17 <TemptorSent> tmh1999: Okay, then you don't necessarily want x11vnc :)
19:18 <TemptorSent> tmh1999: Take a look at the TigerVNC package perhaps, or consider spice if that fits your needs.
19:19 <TemptorSent> tmh1999: Xvnc (stand alone X server with virtual head) is what you're after, not x11vnc (attaches to running X server and provides remote desktop function)
19:19 <tmh1999> TemptorSent : I try to run a docker container on my laptop, with x server on it, then use a vnc client to connect to it.
19:21 <TemptorSent> tmh1999: Yeah, x11vnc would be for controllng your desktop's headed X server from your laptop remotely, not running an X server in a virtual environment to connect to using VNC.
19:21 <tmh1999> TemptorSent : I understand. Thank you !
19:21 <TemptorSent> tmh1999: No problem.
19:22 <TemptorSent> tmh1999: You might still have to build a package to get what you want, but at least you'll be getting the right thing :)
19:24 <tmh1999> TemptorSent : Yeah :) Let me try
19:28 farosas joined
19:41 Emperor_Earth joined
19:44 <TemptorSent> Bureaucat: Madgod's observation on #alpine-linux, do we want to fix busybox's broken 'uname -p' implementation so we have less collateral damage in builds/scripts that use it?
19:45 <TemptorSent> Er, that was supposedto be RE:, damn autocomplete.
20:04 <jirutka> TemptorSent: hmm, is it already reported to busybox devs?
20:04 <TemptorSent> jirutka: It appear entirely intentional, which is bad IMHO.
20:05 <jirutka> TemptorSent: how can be broken behaviour intentional?
20:05 <TemptorSent> jirutka: Both platform and processor are hard-coded.
20:05 <TemptorSent> jirutka: A consious choice to return 'unknown'.
20:05 <jirutka> I get "unknown"
20:05 <jirutka> for uname -p
20:06 <TemptorSent> jirutka: Exactly, rather than x86_64 or whatever machine is at least.
20:06 <skarnet> some GNU systems also return "unknown"
20:06 <skarnet> so it's not more broken than anything else out there
20:06 <jirutka> skarnet: well, but as we already know, GNU is broken all the way down, so… :)
20:07 <TemptorSent> skarnet, yes - it appears BB is intentionally emulating broken behavior and hard-coding it.
20:07 <skarnet> so, um, why exactly do build/scripts use something that is broken everywhere, again?
20:07 <TemptorSent> skarnet: Because autotools :)
20:08 <skarnet> and what would be the benefit in changing busybox if things can break on other systems anyway?
20:09 <skarnet> don't tell me autotools does not care about GNU brokenness, it's about the only thing it cares about.
20:09 <TemptorSent> skarnet: So we actually get sane and useful output perhaps? If we actually chould check the cpu, that'd be cool.
20:09 <TemptorSent> skarnet: Yeah, which is why eveythign built with autotools is so fragile and randomly incompatible with stuff built on the same machine using apparently the same config.
20:12 <TemptorSent> skarnet: Much GNU stuff is subtly or outright broken, emulating that seems like a bad idea.
20:12 <skarnet> you don't need to advertise against autotools to me. My only point is, busybox usually makes choices for a reason, and if you question those choices, you should ask on the busybox ML.
20:34 irclogger_com joined
20:34 Topic for
20:56 vakartel joined
21:25 andypost joined
21:28 stwa_ joined
21:46 vakartel joined
22:15 <nmeum> are the mirrors still in the progress of being fixed? Because I still get errors when running apk upgrade…
22:16 <nmeum> > (1/3) Upgrading linux-grsec (4.9.15-r0 -> 4.9.16-r0)
22:16 <nmeum> > ERROR: linux-grsec-4.9.16-r0: package mentioned in index not found (try 'apk update')
22:16 <_ikke_> nmeum: apparently
22:22 <jirutka> nmeum: try https://nl.alpinelinux.org/alpine or https://repository.fit.cvut.cz/mirrors/alpine, both are currently up-to-date
22:39 <jirutka> many mirrors are still broken :/ mirrors monitoring would be really handy
22:40 <_ikke_> jirutka: How would something like that look like?
22:40 <_ikke_> jirutka: I have set up some priliminary monitoring for alpine
22:41 <jirutka> _ikke_: something like this https://mirrorstats.gentoo.org/rsync/
22:43 <_ikke_> jirutka: page says it's using mirmon
22:43 <_ikke_> https://www.staff.science.uu.nl/~penni101/mirmon/
22:46 <jirutka> hmm
22:53 vakartel joined
23:44 minimalism joined
23:57 <nmeum> hm, our mdocml configuration file seems to contain configuration options that are not even suppored by mdocml anymore
23:57 <nmeum> at least according to man.conf(5)