<    April 2017    >
Su Mo Tu We Th Fr Sa  
                   1  
 2  3  4  5  6  7  8  
 9 10 11 12 13 14 15  
16 17 18 19 20 21 22  
23 24 25 26 27 28 _2_9  
30
00:07 <jirutka> okay, next round (rustc)
00:08 <Shiz> progress?
00:09 blueness joined
00:09 <jirutka> compiling
00:10 <jirutka> it takes forever to compile it
00:11 <kaniini> seems to solve it
00:11 <kaniini> no dependency graph breaks
00:11 <kaniini> more cleaning is necessary though
00:12 <Shiz> i was wondering...
00:12 <Shiz> what happened to py3-pip?
00:12 <kaniini> humm
00:12 <kaniini> should be there
00:13 <Shiz> tried to install it in a docker container for alpine:3.5 and it gave a weird dependency break that the resolver couldn't print
00:13 <Shiz> and couldnd't find it on pkgs.a.o either
00:13 <kaniini> humm
00:13 <jirutka> python3 provides pip
00:13 <jirutka> so there’s no separate py3-pip pkg
00:14 <kaniini> python3 may want to provides=py3-pip
00:14 <kaniini> just to avoid surprises
00:14 <Shiz> jirutka: i figured that was the case, just wondering on why it broke apk
00:14 <jirutka> I think that it’s alrewady there, but not sure now
00:14 <Shiz> :p
00:14 <Shiz> (it's not)
00:14 <jirutka> yes, provides=py3-pip
00:14 <Shiz> oh wait
00:14 <Shiz> i was on the wrong branch
00:14 <Shiz> still weird that it broke apk then
00:15 <jirutka> IIRC there’s some problem when it’t used in makedepends
00:15 <jirutka> it doesn’t not resolve it via provides
00:15 <jirutka> however, there should not be any makedepends=py3-pip in aports tree…
00:16 <jirutka> and it’s really not
00:16 <jirutka> so where’s the problem?
00:16 <Shiz> i just did # apk add py3-pip
00:16 <Shiz> and it broke it
00:16 <Shiz> i'll try to repro
00:16 <Shiz> 1sec
00:16 <jirutka> it do nothing when I run it
00:16 <Shiz> maybe my alpine:3.5 base is outdated
00:16 <jirutka> maybe b/c I have python3 currently installed?
00:18 <Shiz> okay, repro'd
00:18 <Shiz> it doesn't repro when I *just* add it
00:18 <Shiz> https://txt.shiz.me/ZjQyZjFjYT
00:18 <Shiz> ^ docker log
00:19 <Shiz> if i add python3 to that add line it works
00:21 <kaniini> fffff
00:21 <kaniini> i wonder if provides broke in apk-tools
00:21 <kaniini> okay, i will look into that
00:22 <kaniini> because it used to work
00:22 <Shiz> lemme see if updating my alpine base image works
00:22 <kaniini> i'm fixing php5 first
00:22 <Shiz> nope
00:22 <jirutka> huh, supervise-daemon doesn’t have any option how to limit how many times it can restart crashed service?!
00:24 <Shiz> nope, doesn't look like it
00:24 <Shiz> from the code either
00:24 <jirutka> I know that skarnet warned me…
00:25 <jirutka> but that it’s really soo bad?
00:25 <Shiz> it's just very simple, mostly
00:25 <jirutka> I’d say even dangerous if it doesn’t have any limits
00:25 <Shiz> i still have dreams of one day finishing my own hybrid rc of openrc and s6 :p
00:25 <Shiz> s6 for supervision, openrc for the... interface
00:26 <kaniini> if this run passes
00:26 <kaniini> i am pushing php5 change
00:27 <Shiz> seems prudent to check with the ohters first
00:27 <jirutka> Shiz: that’s exactly what I’d like to have too!
00:27 <Shiz> :)
00:28 <jirutka> so I’ve tried to use supervise-daemon, start service, kill it multiple times, every time it started it again… what could possibly go wrong…
00:28 <Shiz> free ASLR bruteforce vector
00:28 <Shiz> ;P
00:32 minimalism joined
00:32 <jirutka> “One reason the Omnibus package is more reliable is its use of Runit to restart any of the GitLab processes in case one crashes.” … yeah, when it constantly crashes, just use supervisor to restart it immediately… sure… very reliable… omfg
00:32 <jirutka> “The GitLab Rails application code suffers from memory leaks. For web requests this problem is made manageable using unicorn-worker-killer which restarts Unicorn worker processes in between requests when needed.” … sarcasm?
00:33 <Shiz> lol
00:33 <Shiz> gitlab is not great resource-wise
00:33 <Shiz> in my own experience
00:33 <jirutka> it’s from official manual
00:33 <Shiz> switched to gitea and it's a delight
00:33 <jirutka> I know
00:33 <Shiz> i had to restart gitlab every ~20 hours
00:33 <Shiz> because it would just hang
00:33 <jirutka> that must be a problem on your side
00:34 <Shiz> ¯\_(ツ)_/¯
00:34 <Shiz> i used the official docker image
00:34 <jirutka> I manage GitLab on faculty for… hmm… 4 years? and I don’t remember any situation when I needed to restart it
00:34 <jirutka> and ofc it runs on Alpine :)
00:34 <jirutka> https://github.com/jirutka/user-aports/tree/v3.5/bundles/gitlab-ce
00:34 <awilfox> gitlab is fine without omnibus. it is not good with omnibus.
00:34 <Shiz> all i know is that the site wouldn't load anymore
00:35 <Shiz> or the ssh
00:35 <jirutka> aha, that’s why it crashes :)
00:35 <Shiz> and restarting the container would fix it
00:35 <jirutka> heh
00:36 <jirutka> I should finally write to GitLab and offer them my packages; i’m quite tired updating them and fixing what they screwed all the time :/
00:36 <Shiz> upstream them to alpine
00:36 <Shiz> :p
00:37 <jirutka> 1st I can’t, beucase it’s a bundle, so it violates Alpine policy :/
00:37 <jirutka> 2nd who else would maintain it? ;)
00:37 <jirutka> but I’d like to open discussion about adding new repository: bundles, for stuff like this
00:38 <jirutka> b/c it’s total nonsense to package very GitLab’s dependency separately
00:38 <jirutka> uff, so pkg upgrade to 8.17.5 almost finished
00:38 <Shiz> that's why people use containers :P
00:38 <Shiz> how's rustc?
00:39 <jirutka> to restart them all the time…? XD
00:39 <jirutka> no, still compiling…
00:40 <Shiz> one of these days i may make a PR against gitea for LDAP group support
00:40 <Shiz> so much stuff lacks LDAP group support :/
00:41 <jirutka> I’d rather write truly lightweight alternative in some sane lang…
00:42 <Shiz> i've got little issues with gitea
00:42 <Shiz> not a huge fan of go, but it seems light enough
00:42 <Shiz> with a good set of features
00:45 <jirutka> Shiz: rustc still doesn’t work :(
00:45 <Shiz> :(
00:45 <Shiz> same err?
00:45 <jirutka> Shiz: https://hastebin.com/raw/lamewiwaze
00:45 <Shiz> ah
00:45 <Shiz> tihs is just forgetting -lunwind
00:46 <Shiz> i think
00:46 <Shiz> or -lgcc_eh?
00:46 <Shiz> one of these two
00:46 <jirutka> but where the heck should I add it?
00:46 <jirutka> and why it’s not here already?
00:47 <Shiz> libunwind is somewhat special
00:47 <Shiz> iirc
00:48 <Shiz> jirutka: see if
00:48 <Shiz> /usr/lib/rustlib/x86_64-unknown-linux-musl/lib/libunwind-1e0a4dc78495337e.rlib
00:48 <Shiz> has that symbol
00:48 <skarnet> why oh why are people talking about supervise-daemon
00:48 <Shiz> go to bed skarnet :p
00:49 <skarnet> yes daddy
00:49 <jirutka> skarnet: I’ve just discovered that you were not overreacting when you said that it’s a total shit
00:50 <skarnet> I was being moderate
00:50 <Shiz> jirutka: https://github.com/rust-lang/rust/blob/1a9b382168cbf405589fbba7215ace700c067879/src/libunwind/build.rs#L17
00:50 <Shiz> the issue right here
00:50 <skarnet> but hey, there's worse: immortal
00:50 <Shiz> i think
00:51 blueness joined
00:51 <jirutka> Shiz: this is patched in that PR
00:51 <Shiz> what does the new ver say?
00:53 <Shiz> ah, i see it now
00:54 <Shiz> https://github.com/smaeul/rust/blob/706fc559532f24e77d0f0c1319723848ed82eb67/src/libunwind/lib.rs#L32
00:54 <Shiz> this, right?
00:54 <Shiz> i think libgcc_s doesn't include unwind stuff
00:55 <Shiz> oh, it does
00:57 <Shiz> hmm
00:57 <Shiz> i think it's not getting linked in properly somehow
00:57 <Shiz> jirutka: i'd check the above libunwind-*.rlib
00:57 <Shiz> see what it links against and its symbols
00:57 testing101 joined
01:03 <jirutka> Shiz: if you wanna continue: https://github.com/jirutka/alpine-aports/commit/e7f48af4953453d4b1b5b9a3812088eca6b6722f
01:03 <jirutka> Shiz: I’m going to sleep, too tired
01:03 <Shiz> :)
01:04 <Shiz> sleep well
01:04 <jirutka> thanks
01:15 <Shiz> jirutka: fwiw, the abuild isn't working because wrong stdlib and cargo-nightly checksums
01:15 <Shiz> if i fix them, it complains about stdlib being compiled with a different rust
01:16 <Shiz> = help: please recompile that crate using this compiler (rustc 1.16.0)
01:16 <Shiz> = note: crate `std` path #1: /alpine-aports/testing/rust/src/stage0/lib/rustlib/x86_64-unknown-linux-musl/lib/libstd_unicode-e7785092bfb3c649.rlib compiled by "rustc 1.16.0 (30cf806ef 2017-03-10)"
01:18 <Shiz> it works if i change the rust-std url to https://repo.voidlinux.eu/distfiles/rust-std-$pkgver-$_arch-unknown-linux-musl.tar.gz
01:19 <Shiz> after that it fails with "error[E0432]: unresolved import `syntax::ast`"
01:19 <Shiz> :p
01:31 s33se_ joined
01:35 <Shiz> (the new rust-std url also has the same checksum as your apkbuild, so that part's fixed)
01:40 <Shiz> jirutka: ok, found the matching cargo gitrev too (not the one in the APKBUILD): 333a79884d2463b11f279d815284b6406656c949
01:40 <Shiz> using that one fixes the last error too
01:41 <Shiz> the gitrev you put in there is way too new
01:43 <Shiz> iow: https://txt.shiz.me/OWJiOGE0Nz for it to start building in the first place :P
01:45 tmh1999 joined
01:46 testing101 joined
01:59 Emperor_Earth joined
02:03 <Shiz> and repro'd your error :)
02:14 <Shiz> jirutka: got it to compile by manually adding -lgcc_s \o/
02:14 <algitbot> \o/
02:47 <Shiz> / # rustc -o hello hello.rs
02:47 <Shiz> / # ./hello
02:47 <Shiz> The program "+ + * - /" calculates the value 1
02:47 <Shiz> :)
02:47 <Shiz> bit of a hacky patch, but whatev
02:49 <Shiz> jirutka: https://txt.shiz.me/MTM4NjNmN2
02:49 <Shiz> patch to your APKBUILD for a (superficially) working rustc
02:52 <Shiz> there's a nasty duplication of libs in /usr/lib and /usr/lib/rustlib/$(triplet)/lib right now, though
02:53 <Shiz> error: specifying the `crt-static` target feature is only allowed on the nightly channel with `-Z unstable-options` passed as well
02:53 <Shiz> and we should patch out this
02:55 <TemptorSent> So, I have a stupid question -- is it possible to tell apk to fetch by complete package atom, or are we stuck with fetching by name and hoping the versions line up?
02:56 testing101 joined
03:01 <Shiz> jirutka: we should also patch https://github.com/rust-lang/rust/blob/a5dac7a2af3ee444817eb7bfbba3539be8c06cf1/src/librustc_back/target/linux_musl_base.rs to include base.no_default_libraries = false;
03:02 <Shiz> TemptorSent: apk add pkg=ver
03:14 <TemptorSent> Shiz: Ouch. Okay, I can't use what apk search -x gives me back the :/
03:14 <Shiz> ?
03:16 <TemptorSent> Shiz: I'm trying to pin the atoms fetched to the atoms returned when I first start staging.
03:16 <TemptorSent> Shiz: And in some cases, I have complete atoms with versions, in others I don't.
03:16 <Shiz> why does that mean you can't use what apk search -x gives you back?
03:17 <TemptorSent> for $pkg in pkgs; do apk fetch $(apk search -x $pkg) ; done
03:17 <Shiz> apk fetch doesn't do versions, no
03:17 <Shiz> just trim the last two -
03:18 <TemptorSent> Yeah, it means I have to download everthing, then double check that the version didn't change while I was in the process of staging.
03:18 <Shiz> i don't really see why you need to check the versions so strictly until you start fetching them anyway
03:18 <TemptorSent> Otherwise, broken system -- it happened to me on my previous kernel version.
03:19 <TemptorSent> Because they're staging into a kernel-version/arch/and kernel flavor specific directory.
03:21 <TemptorSent> So if between staging the kernel 'linux-grsec-4.9.20-r0' and the zfs modules, the repo bumped a version, I'd end up with missmatched kernel and modules, and if doing so using fetch ...| tar -x, it breaks systems.
03:23 <TemptorSent> I guess the solution is to download everything, iterate through and verify versions, then rerun the fetch if anything has changed or if there is any missmatch, then run verify, then untar them.
03:24 <TemptorSent> I'm wasting more time working around limitations in apk than I am actually coding useful logic at this point.
03:29 <kaniini> maybe you should join the apk project :)
03:30 <kaniini> MAGA make apk great again
03:30 <kaniini> think of the hats
03:30 <kaniini> hats are the most important component of a FOSS project
03:37 <TemptorSent> kaniini *lol*
03:37 <TemptorSent> I don't like creating race conditions :(
03:37 <kaniini> i'm serious we could use the help
03:38 <kaniini> the exciting world of package management has never been more exciting
03:39 <TemptorSent> Yeah, let me get the major overhaul done on what I'm in the middle of, then I'll probably jump in.
03:39 <TemptorSent> ncopa wants the functionality I'm working on now yesterday apparently.
03:41 <TemptorSent> and doing it right so it will put up with being fed some pretty random formatted version strings is turning out to be entertaining.
03:41 <TemptorSent> The kernel versions vs. package names aren't consistent, unfortunately, which is leading to things like extracting the /usr/share/kernel directory of the tar file to stdout
03:42 <TemptorSent> And I know I'm going to have a headache to work out on the bloody reverse-parsing of the kernel arch from .config to our system arch.
03:43 <TemptorSent> but the result should be a set of simple tools and configurations that handle all of the kernel-artifact related tasks.
03:46 <kaniini> TemptorSent: it is true that we are getting very close to getting into release mode
03:46 <TemptorSent> kaniini: But I definitely have some thoughts on how to improve auditing, authentication, and versioning capabilities in apk, as well as some tools that would be very useful to expose externally.
03:46 <TemptorSent> Yeah, and apparently I'm not the only one running into issues with the current setup, so fixing it is needful.
03:46 <kaniini> ncopa wants to know about this work because it's something he wants to include in the release
03:47 <kaniini> like this is just solely a matter of release engineering at this point
03:47 <TemptorSent> mkinitfs has many broken bits as it stands.
03:47 <kaniini> we are trying to figure out what our position presently is, so we can figure out what to do next in terms of preparing the release
03:47 <kaniini> yes, no doubt
03:47 <kaniini> i am just saying
03:47 <kaniini> don't stress quite yet
03:48 <TemptorSent> The fixes for that are part of what I'm working on, which is high-priority apparently.
03:48 <kaniini> you still have probably 2 or 3 weeks
03:48 <TemptorSent> People are endeing up with unbootable systems when a repo does weird things.
03:48 <kaniini> before a final decision has to be made
03:48 <TemptorSent> Yeah, how about some testing time in there? :)
03:49 <kaniini> you mean before freeze? because fixes are allowed through after freeze :)
03:49 <TemptorSent> Anyway, mkinitfs itself I have reimplemented and working AFAIK, emulating the existing script cleanly.
03:49 <TemptorSent> kaniini: Yeah, it's a pretty major overhaul for a 'fix', considering the entire code of mkinitfs and update kernel are going away and being replaced essentially.
03:49 <kaniini> i meant
03:50 <kaniini> if you get the rewrite in before we freeze
03:50 <kaniini> then we can fix it
03:50 <kaniini> if there is problems
03:50 <kaniini> because what we start doing is mock releases
03:50 <kaniini> every day or two
03:50 <kaniini> and then some of those mock releases are done as RCs
03:50 <TemptorSent> (only the mkinitfs script, NOT nlplug-findfs -- we discussed splitting that to it's own repo so we don't have arch-dependent and arch-independent repos comingled needlessly.
03:51 <TemptorSent> Yeah, I like to have stuff not broken before going into mainline if I can help it :)
03:51 <kaniini> right, it makes sense
03:52 <TemptorSent> But mostly, I'm trying to finish doing the rolling-refactor from the original scripts to somethign that is modular, and thus have some more general cleanup of globals and such to finish before it even can be called baked.
03:53 <TemptorSent> In the mean time, I'm still renaming functions and rearranging directories periodically to keep everythign making sense.
03:53 <kaniini> i mean, your dedication to this stuff is certainly admirable
03:54 <TemptorSent> That's why I haven't commiteed the current chunk of crap I'm hacking on, it's still too tangled.
03:54 <TemptorSent> I want it to work without giving me grief, and if it goes mainline, that's less hassle for me :)
03:54 <kaniini> meanwhile i am just doing test rebuilds and trying to make sure that when we freeze it goes smoothly :P
03:56 <TemptorSent> Testing is the most critical part.
03:56 <TemptorSent> By cleaning this up and isolating the functions, we should be able to actually write tests against it.
03:58 <TemptorSent> I think we can unscrew the kernel/module package building mess using it too, and maybe make abuild use it to generate the packages from a single package file instead of dozens.
03:59 <TemptorSent> Do you know if any of the modules are building with something other than kbuild?
04:04 <TemptorSent> Also, is there any good reason whatsoever to NOT compress the modules?
04:13 minimalism joined
04:40 tmh1999 joined
04:45 <TemptorSent> kaniini: For splitting package name off, is "${pkg%%-[0-9]*}" safe to use?
04:45 <kaniini> no
04:45 <kaniini> well
04:45 <kaniini> actually
04:45 <kaniini> i think so
04:46 <TemptorSent> IOOW, do we have any stupid crap to worry about like gtk-3, or are they underscored?
04:46 <kaniini> oh
04:46 <kaniini> we do
04:46 <kaniini> there is stuff like
04:46 <kaniini> gtk+3.0
04:46 <TemptorSent> *facepalm* Okay, what is the SAFE way to split the package version, since I can't just pass it the full atom!
04:48 <TemptorSent> If we can't depend on the first '-' followed by a digit, this is going to get ugly, fast.!
05:54 <TemptorSent> Query - is it expected that the kernel pkgver and module pkgver in their respective .PKGINFO files match exactly? It appears the install-if does not.
06:24 <clandmeter> jirutka, is cargo broken atm?
06:33 <clandmeter> ah, i guess rust needs a version bump?
06:39 fabled joined
06:41 t0mmy joined
06:44 <Shiz> TemptorSent: ${pkg%-*} twice
06:55 <TemptorSent> Thank you Shiz, time to go chase code -- probably tomorrow, because I'm too tired to do it now.
07:03 ostera joined
07:10 <TemptorSent> Shiz: Confirmed that quite a number of packages do in require the annoying form.
07:12 <TemptorSent> Although it appears that all packages DO work with "${pkg%-*-*}" that I can check with a loop through the result of apk search
07:13 <ncopa> morning
07:13 <ncopa> <TemptorSent> ncopa wants the functionality I'm working on now yesterday apparently.
07:14 <ncopa> TemptorSent: dont stress with it
07:14 <ncopa> might be we merge it in right after v3.6 release
07:14 <ncopa> which probably is more sane that rush it
07:14 <ncopa> then we also have longer testing period for 3.7
07:15 <ncopa> i was hoping that we could use your stuff for v3.6, or at least bits of it
07:16 <ncopa> but its not worth burning out people
07:16 <TemptorSent> ncopa: I'm not stressing, just prioritizing :)
07:16 <ncopa> good
07:16 <ncopa> if we reach it, the fine
07:16 <ncopa> if not, then we'll do it for v3.7
07:16 <TemptorSent> And getting a little frustrated with spending more time working around apk than actually writing logic at the moment.
07:17 <TemptorSent> Not being able to fetch by complete atom is painful.
07:18 <TemptorSent> It means trimming every package every time I need to do something with it, then double checking that the version didn't change on me while I wasn't looking.
07:18 <ncopa> so we should probably fix apk-tools first
07:18 <TemptorSent> ncopa: Any chance there's and easy fix for that in apk?
07:18 <ncopa> fabled is the right person to ask
07:18 <TemptorSent> Yeah, I figured as much, but haven't seen him on while I've been on.
07:18 <ncopa> you need apk search $pkgname=$version
07:19 <ncopa> and apk fetch $pkgname=$version
07:19 <ncopa> that means that it needs to go via the dependency resolver
07:19 <TemptorSent> ideally, take the result of apk search -x $pkgname
07:20 <ncopa> do you have example of shell syntax you want?
07:20 <ncopa> i mean, do you need the apk search at all?
07:20 <TemptorSent> so apk search -x $pkgname-$pkgver would ideally return the same as apk search -x $pkgname
07:21 <TemptorSent> Yes, because I check the package exists and get the version.
07:21 <ncopa> why do you need the version?
07:21 <TemptorSent> essentially, it would be great if apk would accept atoms specified in the same form it returns them from 'apk search -x $pkgname'
07:22 <TemptorSent> because kernels and modules don't tend to get along too well if they don't match.
07:22 <TemptorSent> I had my system partially broken for a while because I had a mismatch when a repo was acting up.
07:22 <ncopa> ok
07:23 <ncopa> in which case you should have gotten an error message
07:23 <ncopa> so you get the kernel and moduels with apk fetch?
07:23 <ncopa> and they need to match?
07:23 <TemptorSent> So if I get a list of packages for 4.9.20-r0-grsec and 4.9.21-r0-grsec comes out while I'm working, it'd be nice to throw an error rather than silently breaking things.
07:23 <ncopa> i understand
07:24 <ncopa> and i agree
07:24 <ncopa> do you apk fetch the kernel package and modules packages in same shot
07:24 <ncopa> or in different apk fetch calls?
07:24 <TemptorSent> Multiple calls, and with apks staged in a cached direcotry.
07:25 <ncopa> so
07:25 <TemptorSent> I need the apks themselves because I'm parsing them with an awk script to extract the checksum headers.
07:26 <ncopa> one option is to have apk check the cached directory that dependencies are met?
07:26 <TemptorSent> As well as allowing a user to download a set of apks for offline work.
07:27 <TemptorSent> This allows including both apks and custom built kernels/modules, so dep resolution might not work.
07:27 <TemptorSent> All deps are being resolved using depmod/modinfo
07:27 <ncopa> so kernel modules might not be in an apk package
07:27 <ncopa> and apk cannot check that
07:28 <TemptorSent> Right.
07:28 <ncopa> other option would be to have depmod exit with error if deps are unmet?
07:28 <TemptorSent> People building custom modules, but using stock kernels is an issue there.
07:28 <TemptorSent> Yeah, I'm going to run depmod with -e
07:29 <TemptorSent> So everything will be fully resolved, AND I'll have a link between packages and files installed even after slicing and dicing for both modloop and mkinitfs
07:30 <ncopa> i think fabled is busy this week
07:30 <ncopa> and i will not have time today either
07:30 <TemptorSent> Which means we don't have too much of a kitchen-sink problem any more.
07:31 <TemptorSent> A user could select only the modules he needs and they'd all be resolved without including a bunch of unneeded cruft.
07:31 <ncopa> that is great
07:31 <ncopa> and it could pull in the firwmare needed too
07:31 <TemptorSent> Right now, mkinitfs will silently not find files and give you an unbootable machine.
07:32 <ncopa> yeah
07:32 <TemptorSent> Yeah, already has that logic :)
07:32 <ncopa> ok
07:32 <ncopa> i think what we can do for now
07:32 <ncopa> 1) report the needed feature on bugs.alpinelinux.org
07:32 <ncopa> eg create issue
07:32 <ncopa> with the details
07:32 <TemptorSent> It can also handle installing headers from custom builds.
07:33 <ncopa> 2) separate out your work from the aports git tree, into its own git repo
07:33 <ncopa> so we handle this as a separate project
07:33 <ncopa> 3) separate out nlplug-findfs into its own git repo
07:33 <TemptorSent> Okay, what's the best way of splitting it out so it doesn't get confusing?
07:34 <ncopa> good question
07:34 <ncopa> also, how do we do it and keep the hisotry?
07:34 <ncopa> how much history do we need to keep?
07:34 <TemptorSent> I'm not sure, TBH.
07:35 <ncopa> for nlplug-findfs i think we could probably just rename mkinitfs.git -> nplug-findfs and purge the shell scripts
07:35 <TemptorSent> This is one of those corner-cases I haven't gotten myself into before :)
07:35 <ncopa> since the mkinitfs shell scripts is moving out
07:35 <TemptorSent> agreed, that would make sense
07:35 <TemptorSent> or initfs-helpers perhaps?
07:36 <TemptorSent> I could see other small tools joining it in time.
07:37 <ncopa> one way to separate from aports:
07:37 <ncopa> git log scripts/
07:37 <ncopa> all those commits should not touch the APKBUILDs
07:38 <ncopa> so we can probably just carve out those commits
07:38 <TemptorSent> Right, I didn't touch anything outside the scripts dir in my working tree.
07:38 <ncopa> and apply them to new git repo
07:38 <TemptorSent> Then do a git mv to put things where they belong?
07:40 <TemptorSent> Bug or Feature tracker?
07:45 <ncopa> i suppose feature
07:45 <ncopa> yes then git mv where they belong
07:45 <ncopa> that way we keep the history
07:46 <TemptorSent> Sounds sane :)
07:46 <ncopa> the scripts/bootstrap.sh
07:46 <ncopa> do you ever touch it?
07:47 <TemptorSent> Haven't touched it :)
07:47 <ncopa> ok good
07:47 <ncopa> im looking at the commits
07:47 <TemptorSent> I did my best to keep it as clean as possible.
07:47 <ncopa> then we need to filter out the commits that touches scripts/bootstrap.sh
07:47 <ncopa> and keep that in aports
07:47 <ncopa> sounds like we have a plan
07:47 <TemptorSent> I haven't commited a large chunk of work on the kerneltool quite yet.
07:48 <TemptorSent> Indeed.
07:48 <ncopa> i need to work on the s390x builder
07:48 <TemptorSent> I may need a little help figuring out how to split the bootstrap commits out.
07:48 <TemptorSent> I *think* I have most of whats needed in place for that already in mkimage.
07:49 <TemptorSent> I picked up an account to play with it, but haven't gotten there quite yet.
07:49 <ncopa> $ git log --format=oneline scripts/
07:50 <TemptorSent> But it already knows about the s390x arch.
07:50 <ncopa> good
07:51 <TemptorSent> Oh, not too bad, only 5 commits to bootstrap
07:51 <ncopa> its doable
07:51 <TemptorSent> What else is needed for the s390x builder?
07:52 <ncopa> i need make sure the build logs are copied
07:52 <ncopa> and that the builder can upload the packages
07:52 <ncopa> thats basically it
07:52 <ncopa> i will have to go in 30 mins
07:52 <ncopa> so kinda busy now
07:52 <TemptorSent> Cool, so building images should be able to be tested soon :)
07:53 <TemptorSent> No problem, I'll post the feature request and then get some sleep.
07:53 <TemptorSent> It's pouring rain here right now, so I'm expecting to have a power-outage to deal with at some point... My poor UPS isn't going to take much more of this.
08:05 <ncopa> s390x builder is up!
08:05 vakartel joined
08:06 <TemptorSent> Awesome!
08:08 <TemptorSent> Alright, I'm heading to bed -- I have a workaround that doesn't appear to break anything currently in the x86_64 repo at least :)
08:08 royger joined
08:32 ostera joined
08:45 ostera joined
08:49 <ncopa> kaniini: thank you! for the mate update
08:49 <ncopa> was hoping to get that in before v3.6
08:50 <ncopa> so then we have llvm 4 and php5 cleanup left?
08:50 <ncopa> of the big things
08:50 <ncopa> and uefi support in installer?
08:50 <ncopa> need to go out for a while
08:51 fekepp joined
08:52 ostera joined
08:54 <Shiz> @ncopa │ s390x builder is up!
08:54 <Shiz> nice :)
08:54 <Shiz> speaking of builders, any reason why the buildlogs/ dirs are mostly empty for x86_64 at least?
08:54 <Shiz> ncopa: llvm 4.0 may be an issue
08:54 <Shiz> jirutka is trying to package rust in community/ before 3.6 and it does not like llvm4
08:57 xsteadfastx joined
09:00 <xsteadfastx> clandmeter: i created a PR for the snapcast splitting https://patchwork.alpinelinux.org/patch/3271/
09:00 <clandmeter> xsteadfastx, is it possible to create a gh pr?
09:01 <xsteadfastx> sure... you mean i clone aports from github, make the changes and do the PR on github?
09:02 <clandmeter> yep thats it
09:02 <clandmeter> i try to keep away from patchwork
09:03 <xsteadfastx> hehe ok :)
09:04 <clandmeter> and i dont have an mail client setup on my alpine container
09:04 <clandmeter> do you think you can also add check() and initd?
09:05 <fcolista> there are issues with qt5-qttools-dev
09:05 <xsteadfastx> clandmeter: sure... but how does the check work? what kind of test should i write?
09:05 <clandmeter> the basic is --help :)
09:06 ostera joined
09:06 <clandmeter> if that doesnt return an error, we concider its working
09:06 <clandmeter> just pipe it to devnull
09:06 <clandmeter> err redirect..
09:07 <xsteadfastx> ok
09:07 <xsteadfastx> i never wrote a initd... i have to dig the wiki
09:08 <Shiz> xsteadfastx: i'd check the openrc-run manual :)
09:08 <Shiz> and existing good .initd scripts
09:08 <clandmeter> man openrc-run
09:08 <clandmeter> Shiz!
09:08 <Shiz> (if it doesn't have a manual start()/stop() implementation, it's likely good)
09:08 <xsteadfastx> ok cool... i will do that
09:08 <clandmeter> :p
09:08 <Shiz> hullo
09:09 <Shiz> the base openrc-run script is like
09:09 <Shiz> #!/sbin/openrc-run
09:09 <Shiz> depend() { ... }
09:09 <Shiz> command=...
09:09 <Shiz> command_args="<flag to make it run in foreground> ..."
09:09 <Shiz> command_background=yes
09:09 <Shiz> pidfile=/run/$RC_SVCNAME.pid
09:09 <_ikke_> Shiz: please use a pastebin
09:10 <Shiz> sorry, i typed all of those out myself
09:10 <Shiz> :p
09:10 <xsteadfastx> and also... im sure snapcast-server should have a own user
09:11 <clandmeter> check the pre-install scripts
09:11 <clandmeter> in aports tree
09:11 <clandmeter> or the wiki
09:12 <clandmeter> and if you really wanna impress you should provide a sample conf ;-)
09:12 <xsteadfastx> hehehehe... ok... step by step... first check... :)
09:13 <clandmeter> you can add all to one pr if you like
09:13 <xsteadfastx> thats what i want to do
09:13 <clandmeter> and travis will check your skillz
09:15 <clandmeter> xsteadfastx, ill reject your patchwork patch (although it looks good) :)
09:15 <xsteadfastx> ok... do that
09:15 <xsteadfastx> :)
09:19 ostera joined
09:22 <xsteadfastx> clandmeter: would be "snapclient --help > /dev/null 2> /dev/null || return 1" ok?
09:23 <Shiz> or even --version
09:23 <clandmeter> fabled: can i use apk info also on a specified apk version? its seems currently it will list info about all version found of an apk.
09:24 <clandmeter> is &> not posix?
09:24 <clandmeter> not sure it matters --version/--help
09:26 <xsteadfastx> sure &> should work too i think...
09:26 <xsteadfastx> shorter
09:26 <clandmeter> i think its not posix, but our ash shell supports it
09:27 <clandmeter> im sure there are users who will be against using it skarnet?
09:31 <fcolista> qt5 should be upgraded to 5.8.0, it's going to be huge..
09:33 ostera joined
09:36 <clandmeter> fcolista, sounds like a busy weekend for you :)
09:38 <fcolista> I think we need a script to update those packages (qt/gtk/mate/xfce)
09:39 <clandmeter> xsteadfastx, i think it would even make more sense to only redirect stdout.
09:39 <clandmeter> so we can see on builders log what actually was the error msg.
09:40 blueness joined
09:43 terra joined
09:44 <xsteadfastx> clandmeter: ok... i will do that
09:46 ostera joined
09:53 <jirutka> Shiz: aha, sorry for that, I’ve changed it many times and probably messed something; that’s why WIP :)
09:59 <jirutka> Shiz: that should not be a problem, we will just move current llvm to llvm3.8 and update llvm to latest version
10:00 ostera joined
10:09 <jirutka> ncopa: I’d like to also move ghc, cabal and maybe idris to community before branching v3.6
10:10 <jirutka> ncopa: TemptorSent: about extracting scripts into separate repo, I’ll do that, I’ve already done this few times :)
10:10 <jirutka> ncopa: TemptorSent: just let me know when I should do it
10:14 ostera joined
10:21 fekepp joined
10:27 ostera joined
10:33 <xsteadfastx> snapcast wants it config in /etc/default... would that be allright?
10:34 blueness joined
10:37 <jirutka> xsteadfastx: no, this is for debian(?), just remove it
10:38 <xsteadfastx> thats where snapcast looking for its config...
10:39 <skarnet> &> is not posix indeed, and confusing (think people who just learned what >& does and see &> and go wtf?)
10:40 <skarnet> (or just people who casually glance at the code while not being entirely awake or in full possession of their brain cells. Like me.)
10:40 <jirutka> skarnet: &> redirects both 1 and 2 and yes, it’s not POSIX and hence should not be used
10:41 ostera joined
10:41 <jirutka> xsteadfastx: IIRC /etc/default is for configs for runscripts…? so the same as /etc/conf.d on Alpine
10:42 <xsteadfastx> now i need to find out how to patch snapcast to use this instead
10:42 <jirutka> xsteadfastx: if it really looks for application config here, then move that to /etc/snapcast.conf or /etc/snapcast/whatever.conf or something like that
10:47 <Shiz> jirutka: anyway it works :D
10:47 <Shiz> rustc that is
10:47 <jirutka> Shiz: what does it produce for you? statically or dynamically linked executable?
10:47 <Shiz> dynamic
10:48 <Shiz> and with -C prefer-dynamic, dynamic rust libraries too
10:48 <Shiz> (and a small additional patch)
10:49 <jirutka> Shiz: can you try to specify `-C target-feature=+crt-static` ?
10:49 <Shiz> already did
10:49 <Shiz> doesn't work
10:49 <Shiz> since it's anightly feature
10:49 <Shiz> see your highlight log above
10:49 <Shiz> i documented all of that :p
10:49 <Shiz> 04:53:56 Shiz │ error: specifying the `crt-static` target feature is only allowed on the nightly channel with `-Z unstable-options` passed as well
10:49 <Shiz> 04:53:58 Shiz │ and we should patch out this
10:50 <jirutka> Shiz: yeah, that’s what I thought… so I will patch this stupidity out
10:51 <Shiz> jirutka: in base_linux_musl.rs, set base.no_default_libraries = true;
10:51 <Shiz> to make -C prefer-dynamic right
10:51 <Shiz> err
10:51 <jirutka> Shiz: why the hell Rust team must throw stones and sticks on my road all the way?
10:51 <Shiz> or maybe = false;
10:51 <Shiz> either way you want to make it omit the -nodefaultlibs stuff
10:51 <jirutka> what no_default_libraries do?
10:51 <Shiz> when doing -C prefer-dynamic
10:51 <Shiz> it emits -nodefaultlibs
10:51 <Shiz> which you don't want
10:51 <Shiz> afk for a b it
10:52 <Shiz> jirutka: also we have a nasty rust lib duplication right now
10:52 <Shiz> rustc links against the rust libraries in /usr/lib, but they are also in /usr/lib/rustlib/$(target)/lib
10:52 <jirutka> Shiz: I think that I’ve already solved that by symlinks
10:52 <Shiz> considering their names, it would be preferable to have them link to the ones in rustlib
10:53 <Shiz> and have them not in /usr/lib at all
10:53 <Shiz> :)
10:53 <Shiz> brb
10:53 <Shiz> for real now
10:53 <jirutka> I prefer opposite, symlink from /usr/lib to /usr/lib/rustlib/$target/lib; currently it does not matter, b/c rust depends on rust-stdlib, but theoretically you may use rust without stdlib…
10:54 <jirutka> but not sure what is really better
10:55 ostera joined
10:56 <jirutka> okay, now I verified that RUST_CRT_STATIC really works; I was in suspect that it has no effect, b/c I don’t see any target-feature=-crt-static in logs and also when no static, it should link gcc_s (or how’s that called) instead of unwind
10:59 <^7heo> ncopa: ping mkinitfs release
11:02 <jirutka> Shiz: lol, the title :) https://github.com/rust-lang/rust/issues/39998
11:08 ostera joined
11:11 gromero joined
11:18 <ncopa> hum its friday
11:18 <ncopa> i was thinking i should spend rest of the day on things that i want work on, not on things that i have to work on
11:19 <skarnet> why not do that the other days too? :P
11:19 <scadu> ncopa: hm, I start my shift in one hour :p
11:19 <ncopa> because then the things that *needs* to be done will never get done
11:22 ostera joined
11:22 <ncopa> jirutka: can we upgrade llvm to 4.0?
11:22 <ncopa> or will that cause problems for rustc ghc and others?
11:22 <jirutka> ncopa: yes, just copy current llvm to llvm3.8
11:23 <ncopa> ha
11:23 <jirutka> ncopa: then check what pkgs depending on llvm are compatible with llvm 4.0 and replace llvm with llvm3.8 for the ones that do not like 4.0
11:23 <ncopa> i was hoping to hear: "no we cannot upgrade. lets stay on 3.8 for now"
11:23 <ncopa> :)
11:24 <^7heo> unfortunately we cannot stay on a given version for all time.
11:24 <^7heo> we're not debian.
11:24 <jirutka> yeah
11:24 <jirutka> ncopa: we already have llvm3.7, so this can be used as template for llvm3.8; but don’t remember how many differences are here
11:24 <jirutka> ncopa: I’ll look at it later today
11:25 blueness joined
11:25 <ncopa> can we get rid of llvm3.7?
11:26 <jirutka> ncopa: not sure
11:26 <ncopa> and upgrade everything that needs llvm3.7 to llvm3.8
11:26 <jirutka> llvm is very problematic in regards of backward compatibility
11:26 <ncopa> :-/
11:26 <ncopa> so we risk to need to maintain infinite versions of llvm
11:26 <jirutka> ncopa: ghc requires llvm3.7 and IIRC mitchty told me that it does not work with llvm 3.8
11:26 <^7heo> well, when you have GCC as an example of backwards compatibility, I can understand why you wouldn't want that...
11:27 <^7heo> ncopa: if it's just a version that is "set in stone", it's a bit much to call it "maintain"
11:27 <jirutka> ncopa: and since he already invested A LOT of time to get ghc working on Alpine and really like to finally see it in community, I’d rather not ask him about trying to update it to llvm3.8 :)
11:27 <^7heo> maybe "serve in our repos" at the most.
11:28 <jirutka> ncopa: I’ll try to find or ask Rust guys what LLVM version they currently targets
11:28 <^7heo> jirutka: yeah but maybe it would be worth letting him know of the evolution on the llvm side...
11:28 <ncopa> ok
11:28 <^7heo> jirutka: just, you know, in case he has a LOT of free time right now ;)
11:28 <jirutka> ^7heo: he knows that
11:28 <^7heo> ok then
11:29 <ncopa> jirutka: sounds good to me
11:29 <jirutka> ^7heo: but as you know, LLVM is real PITA
11:29 <^7heo> no I don't
11:29 <^7heo> I'm not much looking at compilers atm.
11:29 <^7heo> and for quite some time.
11:29 <jirutka> ncopa: btw it’s even worse… do you know about emscripten-fastcomp? :)
11:30 <jirutka> ncopa: that’s emscripten’s fork of LLVM, emscripten currently does not work with upstream LLVM… they should merge JS backend someday, but not done yet
11:30 <jirutka> (merge into upstream)
11:31 <ncopa> that is the C compiler to asmjs?
11:31 <^7heo> You know all hope is lost when people start forking a project rather than using it.
11:31 <jirutka> ncopa: yes, basically
11:31 <ncopa> problem is that people dont seem to think longterm maintenance
11:32 <ncopa> make it run and get famous. job accomplished
11:33 <jirutka> yes, that’s emscripten exactly
11:34 <jirutka> ncopa: look at number of patches to make it at least a bit friendly with distribution: https://github.com/alpinelinux/aports/tree/master/testing/emscripten
11:34 <jirutka> ncopa: the whole directory structure of emscripten is huge mess
11:35 <^7heo> ncopa: http://4.bp.blogspot.com/-RO-OobNCXG4/UYiJq-d8LHI/AAAAAAAALnI/Jlvw0-HZLMk/s1600/bush-mission-accomplished-iraq-thumbsup.jpg
11:35 ostera joined
11:35 <scadu> lul
11:43 t0mmy joined
11:49 ostera joined
11:53 gvb joined
11:54 ic3cdr joined
12:01 <_ikke_> scadu: I would not say that to a dutch person :P
12:02 ostera joined
12:03 <scadu> _ikke_: meh, this language is really weird :P
12:14 <terra> Want to make a Cmake package via "newapkbuild -C $pkgname" but it isn't working. Says "Illegal option -C". Is this a bug?
12:16 <Shiz> jirutka: i mean, not having any rust libs in /usr/lib
12:16 <Shiz> and jamming them all in /usr/lib/rustlib/$(target)/lib
12:16 <Shiz> because their names are rather... generic
12:16 ostera joined
12:16 <Shiz> no symlinks from /usr/lib either
12:17 <Shiz> jirutka: rust targets llvm <4
12:17 <Shiz> it supports 3.9 afaik
12:17 <jirutka> terra: not a bug, just using it incorrectly ;)
12:18 <jirutka> Shiz: yeah, that’s probably a good idea
12:19 <terra> jirutka: Any link for this? I just need a standard Cmake APKBUILD template.
12:20 <jirutka> terra: newapkbuild -n <name> -d <desc> -u <pkgurl> -C <srcurl>
12:21 <terra> jirutka: hmm. I thought it is going to be simpler like "newapkbuild -a $pkgname"
12:22 <jirutka> terra: newapkbuild --help
12:22 <jirutka> terra: you should specify at least -n NAME, otherwise how can it know where you want to create the apkbuild?
12:23 <jirutka> terra: but you should fill desc, pkgurl and srcurl anyway, so why not feed it right into newapkbuild?
12:24 <terra> jirutka: but newapkbuild -a <name> works as expected
12:24 <jirutka> terra: aha, din’t know that
12:24 <terra> jirutka: I don't know why situation is different for -C ?
12:24 <jirutka> terra: aha, yeah, according to --help it’s also valid, hm
12:28 <jirutka> Shiz: I’ve tried another way, removed all expect lines 14, 24 and 72 from opts() in https://github.com/rust-lang/rust/blob/master/src/librustc_back/target/linux_musl_base.rs … and it also works :)
12:28 <jirutka> Shiz: so it’s *again* problem with these stupid hackery to compile against musl and link statically on glibc systems
12:29 rdutra joined
12:30 ostera joined
12:30 <jirutka> hm, but `rustc -C target-feature=+crt-static test.rs` fails with undefined reference to `_Unwind_Resume'
12:31 <jirutka> Shiz: so I need to make these options conditional
12:31 leitao joined
12:32 <jirutka> kay, it’ll be probably the best to summarize what we found to that PR now, and then try to figure out how to fix it
12:43 ostera joined
12:53 farosas joined
12:56 <jirutka> ncopa: I suggest to copy pkg llvm to llvm3.9, update it to 3.9 and update pkg llvm to 4.0
12:57 ostera joined
13:08 leo-unglaub joined
13:09 ic3cdr joined
13:11 ostera joined
13:11 <ncopa> and drop llvm3.8?
13:12 <jirutka> ncopa: yes
13:13 <ncopa> is that better than dropping 3.9 and keep 3.8?
13:13 <jirutka> ncopa: it seems that it’s not needed, but I’ve checked it only briefly now
13:13 <jirutka> ncopa: I guess that newer is better
13:13 <ncopa> except that it means more work
13:14 <ncopa> 3.8 works as is now
13:14 <ncopa> 3.9 may need rebase the patches
13:14 <jirutka> ncopa: hm, that’s true
13:14 <ncopa> what needs llvm 3.8 or 3.9? rust?
13:14 <Shiz> yea
13:14 <jirutka> ncopa: so start with llvm3.8 and then maybe upgrade it to llvm3.9?
13:14 <Shiz> and ghc?
13:15 <jirutka> ncopa: as Shiz said, both 3.8 and 3.9 should be okay for rustc
13:15 <ncopa> i thought ghc needs llvm3.7
13:15 <jirutka> Shiz: ghc needs 3.7
13:15 <Shiz> right
13:15 <jirutka> Julia currently use 3.7 too, but it’s outdated, I don’t know what version the latest Julia needs
13:15 <jirutka> I’ll check this later
13:15 <ncopa> ok
13:16 <ncopa> are there any reason to not upgrade go to 1.8?
13:16 <ncopa> i think ppc64le needs go1.8
13:20 ostera joined
13:24 <jirutka> I’m using our yesterday’s conversation on IRC as backlog to write a bug report to rust-lang/rust :) without that I’d be quite lost, don’t remember all steps I did
13:24 <jirutka> Shiz: ^
13:30 <Shiz> :)
13:33 ostera joined
13:40 tmh1999 joined
13:47 ostera joined
13:57 mitchty joined
13:58 <dfs> is anyone having issues with the kernel 4.9.20-r0 and zfs.ko missing?
13:59 <dfs> i've upgraded the kernel to get rid of the sshd delay on startup but then it brought me the missing zfs module
13:59 <yMGJRgi997ZH> are you on edge?
13:59 <dfs> 3.5 - only wanted to upgrade the kernel to solve the sshd delay issue
14:00 <dfs> but now zfs is broken
14:00 <dfs> had to rollback to 3.5 again and leave the edge kernel out
14:00 <yMGJRgi997ZH> dunno about 3.5 but on edge a kernel upgrade removes the /lib/modules for the running kernel
14:01 ostera joined
14:01 <yMGJRgi997ZH> maybe i misunderstand you. sorry for confusing you, ignore what i said.
14:02 <dfs> no problemo man
14:02 <dfs> https://git.alpinelinux.org/cgit/aports/tree/main/linux-grsec/APKBUILD
14:02 <dfs> there's a mention of zfs-fix.patch but i'm not sure if this is working
14:02 <Shiz> dfs: if you upgrade the kernel to edge, you should also add zfs-grsec@edge
14:02 <Shiz> since kernel versions and kmod versions need to match
14:03 <dfs> hmmmm
14:03 <dfs> Shiz: let me try that then
14:03 <jirutka> Shiz: https://github.com/rust-lang/rust/pull/40113#issuecomment-292544819
14:05 <dfs> Shiz: works :) thanks man
14:10 ncapo joined
14:11 <Shiz> jirutka: nice
14:14 ostera joined
14:14 <pickfire> I wanted to create a breeze gtk theme engine package for alpine.
14:15 <pickfire> But I found out that there are no common naming scheme for that.
14:15 <pickfire> What should I choose? gtk-engines-breeze? gtk-breeze-engine?
14:16 <pickfire> Should I split it into gtk2 and gtk3? Or split it as dark and light theme?
14:17 <Shiz> i'd do gtk2-breeze or gtk2-engine-breeze
14:17 <Shiz> it should be split in gtk2/3 i think
14:28 ostera joined
14:32 <ic3cdr> Hi
14:40 <pickfire> Ah
14:40 <pickfire> But not gtk-engines-*?
14:40 <* pickfire> personally think that gtk-engines-* name is ugly.
14:41 ostera joined
14:42 <jirutka> Shiz: reaction from japaric https://github.com/rust-lang/rust/pull/40113#issuecomment-292555595
14:52 leo-unglaub joined
14:55 ostera joined
15:07 farosas joined
15:09 ostera joined
15:10 minimalism joined
15:22 ostera joined
15:27 <ncopa> ok its weeked for me
15:27 <ncopa> and im happy with the status of ppc64le and s390x
15:27 <ncopa> and very happy with the alpine team in general
15:27 <skarnet> have a nice week-end :)
15:27 <ncopa> have a nice weekend everyone
15:34 <leitao> how often the binaries from the builder is synced with http://rsync.alpinelinux.org/alpine/ ?
15:36 ostera joined
15:39 <jirutka> leitao: IIRC once per 15 minutes or something like that
15:39 <jirutka> leitao: I’d like to shorten it, it took forever when I need new package to be available for another build :/
15:40 <leitao> jirutka: yes, I am not able to try to reproduce some build issues I am seeing at #alpine-commits
15:49 ostera joined
15:59 <clandmeter> Sync is after build
15:59 <clandmeter> Directly
16:00 <jirutka> clandmeter: so why it always take some time until pkg is avaialable at nl.a.o?
16:00 <clandmeter> Leitao ^
16:00 <clandmeter> Cause that's another box
16:00 <jirutka> clandmeter: so what is actually the primary source?
16:00 <clandmeter> Nl2
16:02 <clandmeter> nl.a.o has long time been non master
16:02 <clandmeter> We changed to fr.a.o
16:03 <clandmeter> And now nl2
16:03 ostera joined
16:03 <jirutka> omg, can we create some web site that will just show what is the primary source this week?
16:03 <jirutka> it’s changing all the time XD
16:07 <TemptorSent> jirutka: Thank you for offering to help with the splitting. We're probably a couple of days before doing that, but not more than a week I would think.
16:08 <jirutka> TemptorSent: ok, just let me know when it’s ready
16:16 ostera joined
16:19 <TemptorSent> jirutka: Will do.
16:30 farosas joined
16:30 ostera joined
16:41 czart_ joined
16:44 ostera joined
16:57 ostera joined
17:11 ostera joined
17:22 t0mmy joined
17:25 ostera joined
17:35 ostera joined
18:15 rdutra joined
18:21 blueness joined
18:32 blueness joined
19:14 s4nni joined
19:16 tmh1999 joined
19:26 minimalism joined
19:33 ostera joined
19:55 ostera joined
20:02 ostera joined
20:17 tmh1999 joined
20:25 ostera joined
20:33 ostera joined
20:41 ostera joined
21:01 <jirutka> Shiz: are you here?
21:01 <Shiz> yeah
21:02 <jirutka> Shiz: I’m trying to understand what’s going on in rustc
21:03 <jirutka> Shiz: to recap, now we are able to build rustc and use it with dynamic linking, but static linking is broken
21:04 <jirutka> Shiz: we need to somehow get work both
21:04 <Shiz> yeah
21:05 <Shiz> jirutka: does -C prefer-dynamic work?
21:05 <jirutka> Shiz: if I understand it correctly, we don’t need rustc to pass crt*.o files for static linking, it can (and probably should) use system-provided, since we’re on actual musl system
21:05 <Shiz> yes
21:06 <Shiz> jirutka: rustc has 3 modes of linking
21:06 <Shiz> default: statically link rust libs, dynamically link crt
21:06 <Shiz> -C prefer-dynamic: dynamically link rust libs, dynamically link crt
21:06 <Shiz> -C +static-crt: statically link rust libs, statically link crt
21:06 <Shiz> does -C prefer-dynamic work in your current ver?
21:08 <jirutka> Shiz: https://hastebin.com/raw/yizaxibame
21:09 <Shiz> yep
21:09 <Shiz> jirutka: to fix the -C prefer-dynamic thing, a simple patch is needed
21:09 <Shiz> that I forwarded last night to you
21:09 <Shiz> :p
21:09 <Shiz> at least, the idea
21:09 <Shiz> https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/hack-linux_musl_base.patch
21:09 <jirutka> Shiz: what bothers me more is that -C target-feature=+crt-static does not work…
21:09 <Shiz> add + base.no_default_libraries = false; to this patch
21:09 <Shiz> jirutka: got an error?
21:10 <jirutka> Shiz: but what exactly does this option do? I know that it disables passing -nodefaultlibs to linker, but how will it affect dynamic/static linking?
21:10 <Shiz> very strange that it works with -C prefer-dynamic -C target-feature=-static-crt
21:10 <jirutka> Shiz: ad error, see https://github.com/rust-lang/rust/pull/40113#issuecomment-292544819
21:11 <Shiz> jirutka: it erroneously passes -nodefaultlibs to the linker
21:11 <Shiz> which inhibits linking libc
21:11 <jirutka> Shiz: the second stack trace
21:11 <Shiz> while it is dynamically linking
21:11 <Shiz> that's why oyu get //lib/libc.musl-x86_64.so.1: error adding symbols: DSO missing from command line
21:11 <Shiz> ah yes, unwind
21:13 <jirutka> Shiz: I didn’t get DSO missing…
21:13 <Shiz> it's right there in your log?
21:14 <Shiz> 23:08:52 jirutka │ Shiz: https://hastebin.com/raw/yizaxibame
21:14 <jirutka> Shiz: aha, tihs one, pardon
21:14 <Shiz> :)
21:14 <jirutka> Shiz: I’d like to solve static linking problem now
21:14 <Shiz> yeah
21:14 <Shiz> just giving you a solution to make -C prefer-dynamic work without target-feature=-crt-static
21:14 <Shiz> re:static linking...
21:15 <jirutka> Shiz: hm, should the first example work at all? this is trying to statically link C, but dynamically Rust…
21:15 <Shiz> i have a feeling this is not adequately solved by the parti n libunwind
21:15 <Shiz> jirutka: why would it statically link libc?
21:15 <Shiz> did we not flip the switch?
21:15 <Shiz> my rustc links dynamically by default...
21:16 <jirutka> Shiz: that’s because of https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/hack-linux_musl_base.patch#L54, I’ve already put it back
21:16 <Shiz> why put it back?
21:16 <Shiz> i think it's not unreasonable that alpine-packed rustc links dynaically by default
21:17 <jirutka> Shiz: I’d like to stick to the default behaviour, to not confuse ppl even more, so link statically on musl by default
21:17 <jirutka> Shiz: we can use -C target-feature=-crt-static to link dynamically
21:17 <Shiz> in that case i think -C prefer-dynamic should imply -C target-feature=-crt-static
21:17 <Shiz> should be a simple patch i think
21:17 <Shiz> anyway, back to static linking then
21:18 <jirutka> Shiz: the current default behaviour, when glibc is dynamically linked by default, but musl libc is statically linked, is IMO bad, it’s inconsistent, but that’s what rustc currently do on all other platforms…
21:18 <Shiz> i think it's fine for us to differ on that
21:18 <Shiz> if people want to really statically link, they can use -C target-feature=+crt-static...
21:18 <Shiz> anyway
21:19 <jirutka> Shiz: let’s discuss this later
21:19 <Shiz> yes
21:19 <Shiz> :)
21:19 <Shiz> im looking at rustc atm
21:19 <jirutka> Shiz: when we look at https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/hack-linux_musl_base.patch; is -nostdlib really needed for static linking on musl host?
21:20 <Shiz> i'm not sure what they put in liblibc.rlib
21:20 <Shiz> however, the linker already passes -nodefaultlibs
21:21 <jirutka> yes… and should it really pass this on musl host?
21:21 <Shiz> and that is correct
21:21 <Shiz> yes
21:21 <Shiz> jirutka: i believe liblibc.rlib statically embeds libc.a
21:21 <Shiz> so that is fine
21:21 <jirutka> hmm…
21:21 <Shiz> -nodefaultlibs inihibts linkage of libc and (i think?) libgcc
21:21 <jirutka> Shiz: https://github.com/rust-lang/rust/pull/40113#issuecomment-292561266
21:21 <Shiz> but DOES include the platform start files
21:21 <Shiz> which is what you want
21:21 <Shiz> (crt*.s/c)
21:22 <jirutka> Shiz: rustc build system assumes that musl is used only as a target on non-musl system, so they somehow bundle musl libc… I don’t think that we want this behaviour, it’d be imo better to make it use our system-provided libc.a
21:22 <Shiz> i'd agree, but i don't think you can fi that easily
21:23 ostera joined
21:23 <jirutka> okay
21:23 <Shiz> jirutka: essentially rust presumes the .rlibs have all dependencies
21:23 <Shiz> rust code itself doesn't rely on libc except if you use liblibc
21:23 <Shiz> so liblibc statically embeds libc.a
21:23 <jirutka> so since linker passes -nodefaultlibs, -nostdlib is not necessary for static linking, do i understand it correctly?
21:23 <Shiz> special-casing libc is going to be hard for that
21:23 <Shiz> jirutka: correct
21:24 <Shiz> jirutka: essentially, it's like this:
21:24 <Shiz> -nostartfiles: don't include the C runtime startup files (crt*.s/c)
21:24 <Shiz> -nodefaultlibs: don't implicitly link libc/libgcc*
21:24 stwa joined
21:24 <Shiz> -nostdlib: -nostartfiles and -nodefaultlibs
21:24 <Shiz> for static linking we do want the start files, since they boot up the C environment
21:24 <Shiz> but we don't want libc, since liblibc.rlib embeds it
21:25 <Shiz> so -nodefaultlibs is accurate
21:25 <jirutka> okay
21:25 <Shiz> the issue is, that unwind isn't being linked in properly
21:25 <Shiz> and I think this is the patch's mistake
21:25 <Shiz> it shouldn't try to link in libunwind statically in rust's libunwind
21:25 <Shiz> because other code seems to implicitly use it too
21:26 <Shiz> maybe libunwind should only be added to the final linking step?
21:26 <jirutka> do we want to avoid -nodefaultlibs when linking dynamically?
21:26 <Shiz> yes
21:26 <Shiz> but it already does this
21:26 <Shiz> see your command line when you link with -C target-feature=-crt-static
21:28 <Shiz> jirutka: can you update your repo with your current apkbuild so i can keep up?
21:28 <Shiz> and we don't test things on diverging builds
21:28 <Shiz> :p
21:29 <jirutka> Shiz: no, it passes -nodefaultlibs even when linking dynamically https://hastebin.com/raw/uwajojozoz
21:29 <Shiz> oh
21:29 <Shiz> hum
21:29 <Shiz> well that is not an issue
21:29 <Shiz> since it explicitly passes -lgcc and -lc
21:29 <Shiz> in that case
21:29 <Shiz> so it is nothing to worry about
21:29 <jirutka> updated
21:30 <jirutka> so gcc just ignores it?
21:30 <Shiz> thanks :)
21:30 <Shiz> well, it's not ignored
21:30 <jirutka> but the result is the same?
21:30 <Shiz> gcc just drops the implicit -lc and -lgcc*
21:30 <Shiz> yes
21:30 <jirutka> okay
21:30 <Shiz> since they are added in the commandline again
21:30 <Shiz> :p
21:30 <Shiz> so it's fine like that
21:31 <Shiz> i'll guet the build on
21:32 ostera joined
21:32 <jirutka> Shiz: https://hastebin.com/raw/sifezukazu
21:32 <jirutka> Shiz: it should not pass -pie when linking statically :/
21:32 <Shiz> why not?
21:32 <Shiz> static PIE is fine
21:32 <Shiz> at worst, the compiler will ignore it
21:33 <Shiz> at best, you'll get a static PIE binary
21:33 <jirutka> really? I thought that PIE cannot be used together wih static
21:33 <Shiz> that's pretty old info ;P
21:33 <jirutka> and what the heck: "-Wl,-Bstatic" "-Wl,-Bdynamic"
21:33 <Shiz> static PIE exists these days, although i'm not 100% sure if alpine gcc supports it
21:33 <Shiz> jirutka: check the result binary with # file
21:33 <jirutka> aha, good to know! :)
21:33 <Shiz> if it's an ELF dynamic object, it's static PIE
21:33 <jirutka> there’s no result binary, because it fails…
21:33 <Shiz> uh, right
21:33 <Shiz> derp
21:33 <Shiz> sorry
21:33 <jirutka> :P
21:33 <Shiz> check when we get this working
21:33 <Shiz> :)
21:34 <jirutka> I’ll note it for my future myself :P
21:34 <Shiz> building now
21:34 <jirutka> why "-Wl,-Bstatic" "-Wl,-Bdynamic" ?
21:34 <Shiz> it doesn't really do anything, luckily
21:34 <jirutka> okay…
21:34 <Shiz> afaik -Bstatic and -Bdynamic are used to indicate what kind of file to use for -lfoo invocations
21:35 <Shiz> but there are no -lfoo arguments there
21:35 <Shiz> -Bstatic: libfoo.a
21:35 <Shiz> -Bdynamic: libfoo.so
21:36 <Shiz> jirutka: apparently when linking a static rlib it adds -Bstatic to the cmdline
21:36 <jirutka> okay, next spec: base.pre_link_objects_exe.push("crt1.o".to_string()); and similar are probably okay to get rid of for both static and dynamic on musl host, right?
21:36 <Shiz> and at the end of its processing it adds -Bdynamic
21:36 <Shiz> dumb, but harmless
21:36 <Shiz> jirutka: yes, yes, yes
21:36 <Shiz> :p
21:36 <Shiz> the current patch is basically fine, except for broken static linking
21:36 <Shiz> you never want to ship your own crt*.o, it's very dumb
21:36 <jirutka> great!
21:36 <Shiz> well, WE don't
21:37 <jirutka> so the only problem is with unwind
21:37 <Shiz> yeah
21:37 <jirutka> what’s so special about libunwind?
21:37 <Shiz> https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/support-dynamically-linked-musl.patch#L377
21:37 <Shiz> this is still fishy imo.
21:38 <Shiz> jirutka: actually
21:38 <Shiz> riddle me this
21:38 <jirutka> I remember that I hit some problems with libunwind before, but don’t remember where
21:38 <Shiz> what if you add this line
21:38 <Shiz> #[link(name = "gcc", kind = "static", cfg(target_feature = "crt-static"))]
21:38 <Shiz> below the unwind one
21:38 <Shiz> wild guess (my rustc is still building)
21:39 <jirutka> what is this supposed to do?
21:39 <Shiz> libunwind provides runtime stack unwind support
21:39 <Shiz> it links in libgcc (static version) on crt-static config
21:39 <jirutka> maybee… `cfg(target_feature = "crt-static")` doesn’t really work for some reason…?
21:39 <Shiz> libgcc_s = libgcc, shared (dynamic) version
21:39 <Shiz> libgcc = libgcc.a, static version
21:39 <Shiz> i think that one works
21:40 <Shiz> but maybe...
21:40 <Shiz> hmm
21:40 <jirutka> well, then how can `#[link(name = "gcc", kind = "static", cfg(target_feature = "crt-static"))]` work if gcc is dynamic version…?
21:41 <Shiz> read again
21:41 <Shiz> :)
21:41 <Shiz> gcc_s is the dynamic version
21:41 <Shiz> gcc is the static version
21:41 <jirutka> aha, pardon
21:41 ostera joined
21:41 <jirutka> but do we really wanna link whole gcc into static binaries…?
21:41 <Shiz> hehe
21:41 <Shiz> it's libgcc
21:41 <Shiz> not the entirety of gcc
21:41 <jirutka> well, libgcc…
21:42 <Shiz> that response tells me you're unfamiliar with what libgcc is
21:42 <Shiz> :p
21:42 <Shiz> it's not the gcc compiler or anything
21:42 <Shiz> it's gcc's runtime library
21:42 <jirutka> I know
21:42 <Shiz> every static binary needs it
21:42 <jirutka> this https://pkgs.alpinelinux.org/package/edge/main/x86_64/libgcc
21:42 <Shiz> every static binary links it in statically
21:42 <Shiz> else it just won't run
21:42 <jirutka> aha, okay
21:42 <Shiz> it's also fairly small
21:43 <Shiz> or at least
21:43 <Shiz> after linker optimisation
21:43 <Shiz> ;p
21:43 <Shiz> jirutka: if you compile a binary with cc -static, it already implicitly adds libgcc.a
21:43 <Shiz> :)
21:44 <jirutka> Shiz: https://hastebin.com/raw/aqeqakopey
21:44 <Shiz> well
21:44 <Shiz> we're making progress
21:44 <Shiz> yeah that actually doesn't work, i'm silly
21:44 <Shiz> jirutka: got another idea
21:45 <Shiz> jirutka: can you get the full final link step it tries to do?
21:45 <Shiz> the link arg
21:45 <Shiz> wanna test something
21:46 <jirutka> final link step in building rustc or hello_world…?
21:46 <Shiz> hello world
21:47 blueness joined
21:47 <jirutka> libgcc.a is not in /usr/lib, but /usr/lib/gcc/x86_64-alpine-linux-musl/6.3.0/, so maybe it just can’t find it on path…?
21:47 <Shiz> yeah i know what causes it
21:47 <Shiz> you're not supposed to add -lgcc manually
21:47 <Shiz> jirutka: in the final link args, try executing it manually
21:47 <Shiz> and replace
21:47 <Shiz> well
21:47 <Shiz> remove -lgcc
21:48 <Shiz> nd add after -nodefaultlibs
21:48 <Shiz> -static-libgcc
21:48 <Shiz> (rustc has an option to preserve artifacts)
21:48 <jirutka> Shiz: I think that this is what you’ve asked for: https://hastebin.com/raw/sifezukazu ?
21:48 <jirutka> aha
21:48 <Shiz> huh, that one doesnt have -lgcc?
21:49 <jirutka> yep, it doesn’t
21:49 <Shiz> or did you remove the line and rebuild already
21:49 <Shiz> :p
21:49 <Shiz> brb
21:49 <jirutka> I haven’t removed it
21:50 ostera joined
21:51 <jirutka> Shiz: I’ve tried to add -static-libgcc after -nodefaultlibs, but the same error about undefined reference to unwind
21:51 alacerda joined
21:53 <Shiz> back
21:53 <Shiz> jirutka: hmm.
21:53 <Shiz> that is somewhat odd
21:54 <Shiz> ah
21:54 <Shiz> static libgcc doesn't have the unwind stuff..
21:54 <Shiz> but static libgcc_eh does...
21:55 <Shiz> so how do we get it to link libgcc_eh
21:56 <Shiz> or maybe it's because the symbols are hidden
21:56 <jirutka> just adding -lgcc_eh doesn’t work
21:56 <jirutka> still same error
21:56 <Shiz> yeah that won't work
21:58 <Shiz> hmm
21:59 <Shiz> this is somewhat odd
21:59 <Shiz> jirutka: so, shot in the dark
21:59 ostera joined
22:00 <Shiz> what if you just add -lgcc_s instead of -static-libgcc
22:00 <Shiz> :p
22:01 <jirutka> still the same error
22:03 <Shiz> ah, my own rustc compiled now
22:05 <Shiz> right, so i'm looking at the cause
22:05 <Shiz> every error is caused by a use of rust's libunwind in some library code
22:05 <Shiz> ( https://github.com/rust-lang/rust/tree/1.16.0/src/libunwind )
22:05 <Shiz> because the dynamic version links -lgcc_s, it provides those symbols
22:06 <Shiz> but where are the symbols in static...
22:06 <TemptorSent> Shiz: Do you have a .a file for it to link?
22:07 <Shiz> libunwind.a simply doesn't have the necessary symbols
22:07 <TemptorSent> Does it have an additional library it needs linked as well to provide the remaining syms?
22:09 <Shiz> well, i'm trying to find out where static versions of _Unwind_* live
22:09 <Shiz> the dynamic ones live in libgcc_s.so
22:09 <TemptorSent> Were they even built/installed in the first place?
22:09 <Shiz> yes...
22:09 <Shiz> jirutka: i think it may be a build issue (yet again)
22:10 <Shiz> i have a feeling it should pass -static-libgcc to the build of rust's libunwind.rlib
22:10 <jirutka> Shiz: what else? :)
22:10 <jirutka> Shiz: but how it works on non-musl system when targeting static musl? o.O
22:10 <Shiz> well libgcc is kinda magic
22:11 <Shiz> it's a dded by the compiler
22:11 <Shiz> so a glibc-hosting compiler may behave differently than a musl-hosting compiler
22:11 <Shiz> :p
22:11 <Shiz> i'm not sure though...
22:13 ostera joined
22:13 <Shiz> jirutka: also, this patch changed semantics for static musl libunwind linking
22:13 <Shiz> so it's not that unsurprising if it would break it
22:13 <Shiz> :p
22:14 <Shiz> specifically https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/support-dynamically-linked-musl.patch#L344-L382
22:14 <jirutka> yeah
22:15 <jirutka> can’t we just move that condition static/dynamic to https://github.com/jirutka/alpine-aports/blob/rust-1.16.0/testing/rust/support-dynamically-linked-musl.patch#L353 ?
22:16 <Shiz> i don't think build.rs has access to that info
22:16 <Shiz> or the author would've done it already
22:16 <Shiz> well, maybe it does through RUST_CRT_STATIC
22:16 fekepp joined
22:16 <Shiz> that might be a hint
22:17 <Shiz> but i'm not sure if that propagates through the build script
22:17 <jirutka> hmm… I’ll try it
22:17 <Shiz> i think it's only passed to the rustc bootstrap
22:18 <Shiz> sigh
22:18 <Shiz> this is so fucked
22:18 <Shiz> why can't they just have rust-shared/static native-shared/static flags
22:18 <Shiz> :p
22:18 <jirutka> yes, you’re right, it’s only for bootstrap
22:23 <jirutka> cargo exposes it via env var CARGO_CFG_TARGET_FEATURE
22:24 <Shiz> ah
22:25 <jirutka> https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
22:52 <Shiz> back
23:17 ostera joined
23:27 <jirutka> Shiz: FUCK YEAH!!!
23:28 <jirutka> it works!
23:29 <jirutka> so the last issue is -C target-feature=+crt-static -C prefer-dynamic
23:34 <Shiz> oh?
23:34 <Shiz> what did you do?
23:34 <Shiz> jirutka: that one will never work, probably
23:38 <jirutka> what the hell…
23:38 <jirutka> no, it does not work :(
23:39 <jirutka> I’m idiot, I’ve run ldd on hello_world.rs instead of hello_world… somehow it always links dynamically now :(
23:39 <Shiz> ;p
23:39 <jirutka> nooooooo
23:39 <jirutka> I’ve updated my branch, so you can see what I did
23:40 <jirutka> I’ve modified support-dynamically-linked-musl.patch
23:41 <Shiz> lessee
23:43 <jirutka> Shiz: but something has changed, see the end of command: https://hastebin.com/raw/kejigucaka
23:43 <jirutka> and https://hastebin.com/raw/sewemiceha
23:44 <Shiz> yeah, because the code is wrong
23:44 <Shiz> :p
23:45 <Shiz> if features.contains("crt-static") {
23:45 <Shiz> try
23:45 <Shiz> if !features.contains("-crt-static") {
23:45 <Shiz> hmm
23:45 <Shiz> or is it
23:45 <jirutka> no, this should be righ
23:46 <jirutka> see the RFC
23:46 <Shiz> yeah but the pull request rearranges stuff
23:46 ostera joined
23:47 <jirutka> but not this
23:47 <Shiz> im unsure too
23:47 <jirutka> https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md#lowering-cfg-values-to-cargo-build-script-environment-variables
23:47 <Shiz> double-checking
23:48 <Shiz> but if it doesn't, it's weird that gcc_s somehow gets added
23:48 <jirutka> it’s going through default branch of the condition
23:49 <jirutka> I think that CARGO_CFG_TARGET_FEATURE is not set
23:49 <Shiz> ... oh
23:49 <Shiz> ./honk.patch:++ // To prevent some nasty linking errors, link in libgcc_s here.
23:49 <Shiz> ./honk.patch:++ base.pre_link_args.push("-lgcc_s".to_string());
23:49 <Shiz> thats just a local patch
23:49 <Shiz> nvm
23:49 <Shiz> yeah...
23:49 <jirutka> or maybe it just works totally differently
23:49 <jirutka> I don’t use this patch
23:50 <Shiz> jirutka: ... right
23:50 <Shiz> yeah it was just a leftover
23:50 <Shiz> jirutka: maybe our cargo is too old
23:50 <Shiz> buut
23:50 <jirutka> this lib is built when building rustc
23:50 <Shiz> this doesnt make sense
23:50 <Shiz> yeah
23:50 <jirutka> then it does not build it from source, doesn’t it?
23:50 <Shiz> the build.rs is for libunwind
23:50 <Shiz> the commandline you posted is for a simple hello.rs
23:50 <jirutka> so this modification in build.rs is totally useless
23:51 <Shiz> where does the gcc_s come from?
23:51 <Shiz> that's so weird
23:51 <jirutka> right
23:51 <jirutka> so it somehow affects it
23:51 <Shiz> no, since the issue is in libunwind
23:51 <jirutka> omg i have no clue
23:51 <jirutka> to tired
23:51 <Shiz> hehe
23:51 <Shiz> lemme do a rebuild from your updated repo
23:51 <Shiz> (also, I hope we're not using VERBOSE=1 in the final APKBUILD...)
23:52 <jirutka> why not?
23:53 <Shiz> it seems unnecessary verbose, but may be just me
23:53 <jirutka> I almost always build with verbose, so I can see what’s going on