<    April 2017    >
Su Mo Tu We Th Fr Sa  
 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  
00:00 <kaniini> # apk fetch --recursive .mkinitfs-dep
00:00 <kaniini> .mkinitfs-dep: unable to select package (or it's dependencies)
00:00 <kaniini> getting closer
00:12 <TemptorSent> Okay, what does it take to read against the apk_pkg_format_cache_pkg cache? Could we check against the string in that and render the dep automatically perhaps?
00:16 <TemptorSent> actually if apk_name_foreach_matching is doing the work, and the strings are in the apk_string_array *filter, and the database is passed, what prevents checking right there?
00:18 <TemptorSent> is genid simply to prevent backtracking?
00:18 <* kaniini> sent a long message: kaniini_2017-04-25_00:18:24.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/xRPKBtKjbCeQJRxNSjVBEGIU
00:18 <kaniini> BAM
00:18 <TemptorSent> Crap, I have to type that?
00:19 <kaniini> type what?
00:19 <TemptorSent> The URL for your message to see what you did.
00:19 <TemptorSent> I don't have a browser on my dev box.
00:20 <TemptorSent> I don't have GUI on it at all for that matter!
00:20 <Shiz> lol
00:20 <Shiz> the point is it worked
00:20 <kaniini> oh
00:20 <kaniini> oh
00:20 <kaniini> i see
00:20 <kaniini> b/c matrix is shit
00:20 <kaniini> gotcha
00:20 <Shiz> i'll paste it, it's only 4 lines
00:20 <Shiz> raccoon:~/apk-tools$ sudo apk fetch --recursive .mkinitfs-dep
00:20 <Shiz> Downloading linux-grsec-4.9.22-r0
00:20 <Shiz> Downloading device-mapper-libs-2.02.168-r3
00:20 <Shiz> Downloading zlib-1.2.11-r0
00:20 <Shiz> TemptorSent: ^
00:21 <TemptorSent> Thank you!
00:21 <TemptorSent> Really? It pastebinned four lines?
00:21 <Shiz> :matrix:
00:21 <kaniini> now
00:21 <kaniini> we just need a --recursion-depth flag
00:21 <kaniini> so we can do
00:22 <kaniini> apk fetch --recursive --recursion-depth=1 .mkinitfs-dep
00:22 <kaniini> which is probably useful anyway
00:22 <TemptorSent> Can we also have a flag to have fetch just give us the list of names as it fetches too?
00:22 <kaniini> you mean without "Downloading" ?
00:22 <Shiz> --pretend?
00:22 <TemptorSent> That would probably eliminate at least one loop
00:22 <TemptorSent> Yeah.
00:23 <Shiz> actually
00:23 <Shiz> --simulate
00:23 <TemptorSent> Yeah, that's nice, now I get to run apk 3 times, not just twice!
00:24 <TemptorSent> Once to search, followed by a loop to translate to deps (unless we can fix that somehow), then a loop to fetch, then another loop to figure out what we fetched.
00:24 <TemptorSent> Also, simulate isn't very helpful if your actual download is crapping out on a particular file.
00:25 <kaniini> TemptorSent: i was thinking about having apk search optionally format as dependency node
00:25 <kaniini> TemptorSent: but you have to pin to a virtual, so the depsolver is actually invoked to do the fetch
00:25 <TemptorSent> That would possibly help some, but the real pain point is having to do translations back and forth to deal with files vs. packages.
00:26 <kaniini> TemptorSent: at least with this patch you can do
00:26 <TemptorSent> So, I'll still have to loop over and first get one package, then get it's version, then set the pin to that, then get all packages.
00:26 <kaniini> TemptorSent: apk add --virtual .mkinitfs-dep linux-grsec=blah && apk fetch --recursive .mkinitfs-dep && apk del .mkinitfs-dep
00:27 <kaniini> TemptorSent: it's perverse but it works
00:27 <kaniini> TemptorSent: what is cool is,
00:27 <TemptorSent> Hmm, not sure how I get it to do what I need with that.
00:27 <kaniini> TemptorSent: you can declare your dependencies on the virtual in one go, and then apk fetch them all at once
00:28 <TemptorSent> The problem is I don't know what my deps are until I have my kernel package downloaded.
00:28 <kaniini> that is problematicv
00:28 <TemptorSent> so if I pin my kernel version, I might still end up with the wrong mods.
00:28 <kaniini> -v
00:29 <kaniini> anyway
00:29 <kaniini> try latest apk-tools git and see if it works for you
00:29 <kaniini> if the concept is sound, i will clean it up a little more
00:29 <TemptorSent> So what I do is fetch the kerenel to a temp dir, check its version, then set that the pin for the mods, then see which ones don't work, then try again without the pin?
00:30 <kaniini> probably :)
00:30 <TemptorSent> (since things like firmware don't follow the kernel version)
00:30 <TemptorSent> See the problem?
00:32 <TemptorSent> So the pinning may not work out too well without another set of checks either before or after.
00:34 <arch3y> Shiz: may I pm you a moment?
00:34 <TemptorSent> And I still can't sanely parse a kernel package :/
00:34 <kaniini> what you do is
00:34 <Shiz> sure?
00:35 <kaniini> you do
00:36 <kaniini> apk add --virtual .mkinitfs-dep linux-firmware linux-grsec=4.9.22-r0 dadhi-linux-grsec=4.9.22-r0
00:36 <kaniini> apk fetch --recursive .mkinitfs-dep
00:36 <kaniini> apk del .mkinitfs-dep
00:36 <TemptorSent> Right, again, that means I need to know the difference between the packages before I fetch them, which I don't
00:36 <kaniini> you use the virtual to make a dependency tree
00:37 <kaniini> you don't, apk will handle it because the depsolver will fail
00:38 <TemptorSent> so if the information I have is the following, how does it resolve? krel:4.9.22-r0-grsec packages "linux dadhi-linux zfs spl"
00:38 <TemptorSent> add linux-firmware, and the whole mess breaks.
00:41 <TemptorSent> What I'm doing now is doing is splitting off the flavor, then doing something like 'pkgname="$(apk search -x $pkg-$flavor || apk search -x $pkg)"
00:42 <TemptorSent> What I want is to do apk search -x $pkg-$flavor-$version instead, so I don't get wrong versions, and I find unflavored packages properly still.
00:43 <TemptorSent> And once I have that set of atoms, I pass them around and use them in all the other loops.
00:43 <TemptorSent> *lol* And I can't build anything until I upgrade due to a mismatched libssl it seems!
00:44 <TemptorSent> 6%.....
00:44 <TemptorSent> 10%....
00:45 <TemptorSent> (And this folks, is how I can get version-mismatches)
00:46 <TemptorSent> 16%
00:47 <TemptorSent> Rolling updates + slow, unreliable network + lack of explicit versioning = random results :)
00:47 <TemptorSent> 29%
00:54 <TemptorSent> Here's an example of an inner fetch loop currently : '_pkgfile="$_ddir/$_pkg.apk" ; for _a_ in 1 2 ; do apk file_exists "$_pkgfile" || fetch -o "$_ddir" "${_pkg%-*-*}" ; apk verify "$_pkgfile" && return 0 ; rm -f "$_pkgfile" ; done ; return 1
00:55 <TemptorSent> Adding the virtual fix makes this much longer, but at least I actually get the version I specified.
00:56 <TemptorSent> My goal was to REDUCE my code complexity, so while it fixes A problem, it doesn't fix THE problem, and frankly, it's not worth me wasting any more of my time or anyone elses working on this if the code complexity can't be reduced significantly.
00:57 <TemptorSent> Awesome, broken modules again!
00:59 <TemptorSent> 'depmod: WARNING: could not open /lib/modules/4.9.22-0-grsec/modules.builtin: No such file or directory
01:00 <TemptorSent> All I have in /lib/modules/4.9.22-0-grsec is the contents of zfs!
01:00 <TemptorSent> And this is STOCK everything upgrading.
01:01 blueness joined
01:01 <TemptorSent> Conveniently, I got a full set of kernel modules for 4.9.20-0-grsec thought.
01:01 <TemptorSent> Yeah, I give up.
01:02 <TemptorSent> This happens about every other apk upgrade for me, which is the whole thing I started trying to fix in the first place!!!
01:02 <TemptorSent> I think I'll just go back to funtoo :/
01:05 <TemptorSent> If it's going to take 500 lines of shell script just to ensure I can get a consistent kernel/modules (possibly after several tries), then start worrying about other deps, I'm probably in the wrong place anyway. I was after simple and intuitive, and this is anything but.
01:07 <Shiz> : /
01:09 <TemptorSent> Design principle: black magick should be done in the database, not through a sequence of scripts, intermediate files, check loops, and retries. Otherwise, WHY have a database?
01:09 s33se_ joined
01:11 <TemptorSent> Also, kernel version from (uname -r) should match the version from the package for vanilla kernels!!
01:12 <TemptorSent> I've been trying to fix the symptoms, but the underlaying cause apperars to be too deep to script over sanely.
01:15 <TemptorSent> kaniini: Unfortunately, apk-tools git isn't building for me, pkgconfig problems with openssl.
01:15 <TemptorSent> Where is config.mk that it's pulling in?
01:16 <kaniini> apk add libressl-dev file-dev lua5.2-dev zlib-dev
01:17 <TemptorSent> kaniini: Ahh, undocumented deps are fun :)
01:18 <kaniini> also libfetch-dev
01:18 <^7heo> arch3y: sorry was eating
01:19 <^7heo> and now, night everyone
01:19 <TemptorSent> kaniini: Yeah, just hit that one too.
01:19 <TemptorSent> ^7heo: G'night.
01:21 <TemptorSent> Well, at least the damn warnings to stdout is fixed!
01:24 LouisA joined
01:25 <arch3y> no problem
01:25 <arch3y> I just realized I did something dumb and pushed a pr gonna close it and fix up my stuff
01:26 <Shiz> you can always just force push
01:26 <Shiz> it'll fix the pr up too
01:26 <Shiz> no reason for duplicate prs
01:28 <arch3y> well I realized I messed up my branch but its all right I already closed it
01:28 <arch3y> cleaning up local then Ill resubmit
01:33 <arch3y> k I think its all fixed up now
01:37 doppo joined
01:48 <arch3y> are there any examples of pkgs where libtool is ran in the post-install
01:48 <arch3y> I have been grepping to see if I can find any lol
01:51 <Shiz> why would libtool be in the po-stinstall?
01:52 <arch3y> I dont know all of the particulars but after some pkgs compile they mention run libtool --finish /usr/lib/blah
01:52 <arch3y> but I see ppl doing libtoolize --force as well and that seemed to fix it
01:52 <Shiz> right, don't just say post-install like that, that's understood as referring to the package hooks that run on the systems packages get installed on
01:52 <Shiz> heh
01:53 <arch3y> yeah my apologies I should of phrased my question better
01:53 <arch3y> but it seems to be solved by adding the libtoolize in the build func
01:53 <Shiz> personally i'd go with the simplest build that works
01:54 <arch3y> yeah I basically have been making minor tweaks to things in unmaintained and getting them building
02:06 tmh1999 joined
02:23 blueness joined
02:28 blueness joined
02:37 blueness joined
02:38 blueness joined
02:42 blueness joined
03:02 blueness joined
03:18 Emperor_Earth joined
05:04 fabled joined
06:03 vakartel joined
06:09 rnalrd joined
06:17 scadu joined
06:17 t0mmy joined
06:31 czart__ joined
07:00 royger joined
07:32 consus joined
07:38 t0mmy joined
07:39 xming_ joined
07:39 xming_ joined
07:41 doppo joined
07:43 tg joined
07:48 MH0815 joined
07:59 ppisati joined
08:02 fekepp joined
08:31 przemoc joined
09:32 blueness joined
10:07 LouisA joined
10:07 <fabled> kaniini, i'm lurking here. please ping me / email me if you need things. yes, apk-tools would probably use a dot release soon
10:07 <fabled> kaniini, ncopa pointed out that we earlier changed stderr->stdout in https://git.alpinelinux.org/cgit/apk-tools/commit/?id=517378721855280d2e23d25d7529e6b9cbae9136
10:07 <fabled> kaniini, but making errors go in stderr makes sense. how it does not cause any regressions though
10:09 t0mmy joined
10:30 <Ganwell> How would you detect (#ifdef) an OpenSSL 1.0 style API vs 1.1 regardless if it is actually libressl?
10:45 <skarnet> just from a look at include/openssl/opensslv.h
10:46 <skarnet> hm, not the shlib thing, the numbering isn't the same
10:46 <skarnet> but OPENSSL_VERSION_NUMBER should tell you everything you need to know
10:47 <Ganwell> What is did is #if (OPENSSL_VERSION_NUMBER <= 0x10100000L)
10:48 <Ganwell> I don't support anything below 1.0 so this should be enough, right?
10:49 <skarnet> I don't know, it sounds good, but test it and tell us if it does what you expect it to :)
10:53 nightmared joined
10:54 <clandmeter> you could also grep aports tree for libressl :)
11:46 <fcolista> ScrumpyJack, yo uaround?
11:46 <fcolista> This patch contains a wrong comment
11:46 <fcolista> http://patchwork.alpinelinux.org/patch/3202/
11:47 <fcolista> upgrade is from 2.6.6 to 2.6.7
11:47 <fcolista> I've updated it
11:52 rdutra joined
11:58 leitao_ joined
12:36 t0mmy joined
12:39 gromero joined
12:50 <arch3y> I just want to say that I do love the features youve added into abuild it makes it easier to build pkgs and helps when you miss stuff
13:03 <Ganwell> skarnet: I couldnt create a ifdef without mentioning libress. Guess I have to live with that: https://gist.github.com/ganwell/5da1a98932b2f8ce6b27e194d205e9d1
13:08 t0mmy joined
13:11 <skarnet> Ganwell: I still think you shouldn't have to do that. You could just write your program with the libressl or openssl-1.1 API, and it will fail to build on older versions, and that's it. Not supporting openssl-1.0.* isn't an issue in 2017.
13:15 <Ganwell> skarnet: Well the slow distros like Debian still have OpenSSL 1.0, right? I don't want to force them to a non-standard TLS-lib.
13:16 <skarnet> the poor things
13:17 <skarnet> it's nice of you to show so much concern for slow distros, I'm certain they're also very concerned with your well-being
13:20 <Ganwell> skarnet: lol
13:33 <ScrumpyJack> fcolista: thanks dude! good spot!
14:04 fabled joined
14:09 royger joined
14:31 royger joined
14:53 duncaen joined
15:00 tmh1999 joined
15:05 t0mmy joined
15:11 kaniini joined
15:18 hl joined
15:29 <arch3y> so close to getting massscan working if only I can figure out a libmusl issue with AF_LINK
15:32 <^7heo> hey arch3y
15:32 <^7heo> still need me? ;)
15:33 <^7heo> (since you highlighted me last night)
15:33 <arch3y> ^7heo: nah I figured out my issue with the apkbuild
15:33 <^7heo> gut gut :)
15:34 <arch3y> I have 4 prs in the wings
15:34 <arch3y> working on masscan now, I just have to figure out why musl has issues when doing ifdef AF_LINK
15:44 <skarnet> arch3y: AF_LINK is a BSD extension, not a Linux thing, so maybe glibc supports it but chances are it aliases it to AF_PACKET
15:45 <skarnet> just patch the app's code replacing AF_LINK with AF_PACKET and it should work
15:45 <arch3y> skarnet: thanks I will do that
15:59 <arch3y> its close but still no cigar, its being a pain in the butt lol
15:59 <ncopa> ^7heo whast the staus on perl-time-hires?
15:59 <ncopa> we need the builder to move on
15:59 <ncopa> i think i just disable tests for now
16:05 <^7heo> ncopa: I'll try to work on it a bit later on today.
16:05 <^7heo> ncopa: is it urgent?
16:05 <^7heo> oh okay I didn't get the urgency of the task.
16:05 <ncopa> nah, i disabled tests for now
16:05 <^7heo> good
16:05 <ncopa> it is blocking build server
16:05 <^7heo> yeah sure.
16:05 <^7heo> makes a lot of sense to disable for now.
16:06 <ncopa> need get the 3.6 packages built
16:09 eleksir joined
16:10 <ncopa> clandmeter: py-gobject3 added depndency of gnome-common. was that intentional?
16:12 <ncopa> https://git.alpinelinux.org/cgit/aports/commit/main/py-gobject3?id=5bb8b3f9f4cead2c5ce2427a4ea85d657181a84a
16:12 <ncopa> i ask because gnome-common is not in main repo
16:15 <ncopa> i moved gnome-common to main
16:17 duncaen joined
16:24 <arch3y> skarnet: trying to fix the af_link code did not go well for me, but its close
16:24 <arch3y> Im stil gonna hammer away at it
16:25 <arch3y> just feeling like Im getting paste my knowledge point lol
16:25 <ncopa> jirutka did you submit bugreport for nginx/libressl2.5?
16:35 <Shiz> arch3y: fwiw, it's musl, not libmusl
16:35 <Shiz> there's no lib in its name
16:35 <Shiz> :p
16:35 <Shiz> it provides a libc though
16:36 <arch3y> Shiz: gotcha stil learning the nomenclature
16:36 <arch3y> thanks
16:37 <arch3y> yeah I have had to patch a few things because of it but not too bad
16:39 <arch3y> I have found by putting musl into google I sometimes get muscle lol
16:47 gromero joined
16:53 <jirutka> ncopa: eh… well… not yet, sorry
16:54 cyteen joined
17:00 LouisA joined
17:03 <clandmeter> ncopa, yes or it failed to build.
17:16 <jirutka> ncopa: https://github.com/libressl-portable/portable/issues/307
17:17 <jirutka> ncopa: any notes about the bug report before I sent it to nginx?
17:17 <jirutka> s/sent/send/
17:17 <ncopa> i mentiond it to void linux ppl
17:17 <ncopa> seems that they can reproduce too
17:18 <jirutka> on musl, glibc or both?
17:19 <ncopa> glibc
17:20 <ncopa> i suspect nginx does some #ifdefs
17:21 <ncopa> #if OPENSSL_VERSION> something || defined(LIBRESSL_VERSION_NUMBER)
17:21 <ncopa> and end up with some bad codepath
17:33 TemptorSent joined
17:39 <jirutka> what the hell? `#if OPENSSL_VERSION_NUMBER >= 0x10001000L`
17:39 <jirutka> `#if OPENSSL_VERSION_NUMBER >= 0x0090707fL`
17:39 minimalism joined
17:48 <jirutka> ncopa: reproduced even on OpenBSD https://github.com/libressl-portable/portable/issues/307#issuecomment-297108714
17:48 <ncopa> not surprised
17:48 <ncopa> this may result in a CVE :)
17:50 <Shiz> yipes.
17:50 <TemptorSent> Okay, why the hell do I have kernel version stuck at 4.9.20-r0, while it's updating everythign else to 4.9.22-r0 for linux-grsec
17:50 <jirutka> ncopa: hm, maybe I should reported that privately to nginx…
17:50 <jirutka> but too late, https://trac.nginx.org/nginx/ticket/1257
17:50 <TemptorSent> My system is officially bjorked.
17:52 <jirutka> ncopa: hm, I’ve never reported CVE issue, how does it work? who promotes issues for CVE…?
17:55 <Shiz> MITRE
17:55 <Shiz> but let's first determine if this is an actual vulnerability first
17:55 <ncopa> yes
17:55 <ncopa> and jirutka: nice catch! :)
17:55 <jirutka> ncopa: I’ve just run upstream tests, nothing more :)
17:56 <ncopa> isnt that what most of the "security researchers" does nowdays?
17:56 <Shiz> no, they also run fuzzers duh
17:57 <jirutka> I dunno, I always thought that CVEs are result of some more sophisticated work then just running provided test suite
17:57 <Shiz> CVEs are just that, vulnerability identifiers
17:57 <jirutka> I know
17:57 <Shiz> how that vulnerability was discovered can differ widely
17:57 <Shiz> like google discovering the glibc dns buffer overflow CVE because their internal hostnames were too long
17:57 <jirutka> lol
17:59 minimalism joined
17:59 <jirutka> grr, I don’t like when I can’t modify the issue, like fixing typos and grammar mistakes :/
17:59 <Shiz> btw since it's somewhat confusing, i'll note it down here for future reference:
17:59 <Shiz> IF it is a CVE:
17:59 <Shiz> IF the issue is in nginx: request the CVE through the DWF: http://iwantacve.org
18:00 <Shiz> IF the issue is in libressl: request the CVE through MITRE: https://cveform.mitre.org/
18:00 <jirutka> why different path for nginx and libressl?
18:00 <jirutka> and why the heck is the first one some crappy google form?
18:01 <Shiz> MITRE delegates CVE allocation to CVE numbering authorities (CNA)
18:01 <Shiz> the DWF is the catch-all CNA for open-source projects
18:01 <Shiz> open-source projects can also have their own CNA (openSSL does for instance)
18:01 <Shiz> but MITRE acts as the CNA for libressl specifically
18:01 <jirutka> interesting
18:01 <ncopa> hum
18:02 <ncopa> libbsd is a problem
18:02 <arch3y> has anyone seen faffolter recently
18:02 <ncopa> arch3y not here
18:03 <Shiz> ncopa: whats hte issue?
18:03 <arch3y> has he stopped contributing or just curious cause most pkgs I end up modifying are his
18:03 <ncopa> it does not build on a number of archs
18:03 <arch3y> but its not a big deal, dont want to derail the conversation
18:04 <Shiz> if they are in unmaintained/, it's likely he stopped
18:04 <Shiz> :p
18:04 <arch3y> gotcha
18:04 <ncopa> some things depends on libbsd
18:04 <jirutka> abuilds in unmaintained/ are… well… unmaintained :P
18:04 <Shiz> ncopa: got logs?
18:04 <Shiz> also, we should totally become our own CNA *gets shot*
18:05 <jirutka> :)
18:05 <ncopa> http://build.alpinelinux.org/buildlogs/build-3-6-armhf/main/py-libvirt/py-libvirt-3.2.0-r0.log
18:05 <arch3y> makes sense, just doing my duty to fix them and update them
18:05 <ncopa> libvirt has the archs disabled
18:06 <jirutka> Shiz: btw have you opened PR in rust-lang/rust for your recent patches?
18:06 <ncopa> i think also some package using libbsd on s390x had problem
18:06 <Shiz> jirutka: not yet, im waiting for #40113 to get merged because they depend on them
18:06 <algitbot> 404 - Alpine Linux Development: http://bugs.alpinelinux.org/issues/40113
18:06 <_ikke_> 404
18:06 <jirutka> algitbot: you’re not very useful right now! >_<
18:07 <Shiz> rust PR 40113, _ikke_
18:07 <_ikke_> haha
18:07 <Shiz> :P
18:10 <TemptorSent> ncopa - is there anywhere currently to document architecture discusison and decisions?
18:10 <mitchty> for the rust people the llvm 4 stuff got merged https://github.com/rust-lang/rust/pull/40123
18:10 <Shiz> very good
18:10 <Shiz> i wonder if it can be backported
18:10 <ncopa> TemptorSent we havent really had any official meetings
18:11 <ncopa> and no, we dont have any current architecture docs
18:11 <TemptorSent> ncopa Unofficial? Scratchings?
18:12 <ncopa> hm, clandmeter showed us a diagram today for server infra
18:12 <TemptorSent> Got it. I think something at least in broad strokes is needful.
18:12 <ncopa> yes
18:12 <skarnet> the historical precedent is "meet Alpine people somewhere, on IRC if you can't IRL, and try to grab their attention for an architecture discussion"
18:12 <ncopa> yeah, that works when you aare small
18:12 <skarnet> It could definitely benefit from improvements :P
18:12 <TemptorSent> Yeah, but if such discussion never gets recorded for reference, it's very hard to know what's going on.
18:13 <ncopa> yes
18:13 <ncopa> so
18:13 <TemptorSent> At least comments in code would help ;)
18:13 <ncopa> the original idea was to use the mailing list
18:13 <skarnet> that's something I often wonder about
18:13 <skarnet> why isn't the mailing-list more used for this
18:13 <TemptorSent> IMHO, the documents should be with the tools.
18:13 <Shiz> i wish we had somewhat documented the discussion we had at FOSDEM
18:13 <Shiz> it was fruitful imo
18:14 <ncopa> we need a secretary :)
18:14 <scadu> skarnet: why not using -devel and hide discussion between spam :P
18:14 <TemptorSent> That would not be me!
18:14 <Shiz> alpine-illuminati mailing list
18:14 <TemptorSent> Can we set a bot and keyword discussions?
18:14 <skarnet> I'd rather have signal on the -devel ML than only spam tbh
18:15 <TemptorSent> Finding things in context in the logs can be difficult -- I've tried :)
18:16 <skarnet> I'd rather not rely on IRC for architecture things
18:16 <skarnet> it's excellent for informal things, but there needs to be a trace somewhere else
18:16 <Shiz> jirutka: hmm
18:16 <Shiz> jirutka: ya think its worth trying to backport llvm4 fixes to our in-tree rust?
18:16 <TemptorSent> Yeah, I wouldn't want to rely on it, but it would be a convenient tool to archive such discussions.
18:18 <TemptorSent> Something like an arch-bot to query perhaps, and a muted channel to join to follow?
18:18 <jirutka> Shiz: ? I’ve already ported some fixes from rust to our llvm3.9
18:19 <Shiz> well i mean
18:19 <Shiz> upgrading our rust to llvm4
18:21 <jirutka> Shiz: does the latest Rust already support llvm 4?
18:21 <Shiz> yes
18:21 <Shiz> see mitchty's link at 20:10
18:22 <TemptorSent> What really would help is if related messages stayed together over several lines, which might mean using a little "markup" that the bot could parse and spit out to files.
18:22 <jirutka> I’ve suggested it some time ago to ncopa, it may be useful to agree on some periodical online meetings, once per two weeks or something like that, to discuss important things
18:22 <TemptorSent> jirutka - I think that's an excellent idea.
18:22 <ncopa> i think its needed yes
18:23 <jirutka> not sure if do it via text or speech
18:23 <ncopa> can we do that after v3.6 release?
18:23 <TemptorSent> Setup a sub-channel for meetings perhaps so the regular devel traffic isn't intermixed.
18:23 <jirutka> or mimics :P
18:23 <ncopa> i just want the 3.6 release out now
18:23 <jirutka> ncopa: please warn me *before* you branch out v3.6
18:24 <TemptorSent> Text - voice conferencing is way too painful with more than a few users at a time.
18:24 <ncopa> and not take any architectual discussions now
18:24 <ncopa> can we do this after v3.6 release?
18:24 <ncopa> well, we could have meetings about release progress :)
18:25 <jirutka> we’d like to move rust and ghc to community for v3.6, but it’s not ready yet; rust currently depends on binaries from VoidLinux for bootstrap and ghc needs more review
18:25 <Shiz> i agree with delaying it until after 3.6
18:25 <jirutka> and also php is blocking, it’s currently in horrible state
18:25 <TemptorSent> Probably wise, especially if 3.7 (4.0?) gets fast-tracked after doing the arch work.
18:25 <ncopa> aw
18:25 <ncopa> php
18:25 <ncopa> who is following up php?
18:25 <Shiz> jirutka: with my latest changes, the rust issue is trivially solvable
18:25 <Shiz> :)
18:25 <jirutka> Shiz: how?
18:26 <jirutka> Shiz: upstream still do not provide prebuilt binaries that can run on musl-based system and it doesn’t look like they will provide them soon
18:26 <Shiz> jirutka: but... we do!
18:26 <jirutka> Shiz: but bootstrapping…
18:26 <Shiz> the latest apkbuild should allow cross-compilation from glibc
18:26 <Shiz> if you get abuild running on a glibc host
18:26 <ncopa> we need figure out how to do bootstrapping
18:26 <ncopa> but lets do that after 3.6 release
18:26 <Shiz> and replace the relevant sources= lines
18:27 <ncopa> openjdk will need bootstrap, go, needs it and now rust
18:27 <jirutka> ncopa: so you’re okay with moving rust into community before solving bootstrapping issue?
18:27 <ncopa> will it build on all archs?
18:27 <jirutka> i mean solving without relaying on binaries from VoidLinux
18:27 <ncopa> which archs will have it?
18:28 <TemptorSent> Once bootstrapped, can it rebuild itself and newer revs at least?
18:28 <ncopa> yes
18:28 <ncopa> jirutka im kinda ok with it
18:28 <jirutka> no, currently just on x86_64; we can cross-compile our rust for other arches, but we need someone’s help, probably fabled, I still don’t understand how cross- support in abuild works
18:28 <TemptorSent> Then it shouldn't be an issue from the end-user's POV.
18:29 <ncopa> firefox 53 needs rust
18:29 <jirutka> it’s not issue for end-user, it’s issue for us, b/c we can’t bootstrap distro out of blue
18:29 <TemptorSent> Right, I mean as far as community vs testing.
18:30 <TemptorSent> From the end users pov, the generated package is stable (relatively).
18:30 <TemptorSent> So it either breaks or not before a package is generated.
18:31 <jirutka> ad php, we have bunch of patches from Valery, but no time to review them; tbh I don’t care about php very much, so I’ve decided to invest my time to rust and other issues
18:31 <TemptorSent> For me, that's good enough to use in community in a non-testing sense.
18:31 <clandmeter> Ncopa, which Arch's do not build with libbsd?
18:32 <ncopa> armhf and aarch64 apparently
18:32 <TemptorSent> As long as broken packages won't actually be generated, it's fine IMHO to be in community.
18:32 <ncopa> im working on it
18:32 <clandmeter> It can
18:32 <ncopa> we should have configure test for linux/a.out.h
18:32 <clandmeter> Refactor the patch
18:32 <ncopa> thats what im doing
18:32 <clandmeter> Ok
18:32 <ncopa> there was a patch some time ago for s390x
18:33 <clandmeter> Yes
18:33 <jirutka> btw I’m afraid that llvm4 does not work on x86 correctly; probably I made some mistake when updating the patches (there were a lot of changes)
18:33 <Shiz> so much to do
18:33 <Shiz> :D
18:33 <clandmeter> I asked the author to fix it
18:33 <jirutka> wait, not llvm, but clang
18:33 <jirutka> I’ve kinda verified that clang 4.0.0 works on x86_64, someone tried it on s390x
18:34 <ncopa> https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-support/libbsd/libbsd/0003-Fix-build-breaks-due-to-missing-a.out.h.patch
18:34 <clandmeter> a.out.h is x86*onlyafaik
18:34 <jirutka> hmm… a.out.h… this reminds me something…
18:34 <TemptorSent> Okay, ignoring the whole mess of the initfs and kernel, what is the most pressing work that needs to get done for 3.6 to drop aside from rust/php/libbsd?
18:34 <TemptorSent> Any other showstoppers?
18:34 <ncopa> TemptorSent: check #alpine-commits
18:35 <ncopa> those are the build errors
18:35 <Shiz> id like uefi boot to work but i have no idea what the status on that one is
18:35 <jirutka> no, that’s different issue: "hidden symbol `__stack_chk_fail_local' isn't defined"
18:35 <Shiz> oh
18:35 <Shiz> it's THAT issue
18:36 <jirutka> I suspect this: https://github.com/alpinelinux/aports/blob/master/main/clang/clang-0004-Add-musl-targets.patch#L56
18:36 <jirutka> should there be i386, not i486, or i686 or how is that already dead arch named these days…?
18:37 <TemptorSent> jirutka i386 is correct still I believe for the minimal supported cpu.
18:37 <jirutka> it builds fine even on x86, but we don’t run tests for clang, b/c it depends on some sources from llvm, so it needs some more work to get it working
18:37 <TemptorSent> There is some embedded stuff that still uses it.
18:38 <jirutka> TemptorSent: I’ll show more context…
18:38 <TemptorSent> And my old laptop :)
18:38 <TemptorSent> jirutka btw, are you using smart quotes or something? I'm getting default chars instead of ' and . from you.
18:39 <Shiz> jirutka: afaik the canonical alpine arch is i586
18:39 <Shiz> i586-alpine-linux-musl
18:39 <jirutka> this is important: https://github.com/llvm-mirror/clang/blob/release_40/lib/Driver/ToolChains.cpp#L4345
18:39 <Shiz> oh, it's used for that
18:39 <jirutka> TemptorSent: I’m using *correct* quotation characters, not a symbol for inches or seconds
18:40 <Shiz> in that case
18:40 <Shiz> http://pkgs.alpinelinux.org/contents?branch=edge&name=musl&arch=x86&repo=main
18:40 <Shiz> it's i386
18:40 <jirutka> hm, right, so this is ok
18:40 <TemptorSent> Hmm, looks like irc logs aren't updating :/
18:40 <jirutka> stupid me, I could verify this myself
18:41 <TemptorSent> jirutka: Yes, typographic quotes -- I know them well from my years doing DTP :)
18:41 <jirutka> anyway, I’ve switched lldb and creduce to clang and both fails to build on x86 with the same error, so I suspect there’s some problem in clang
18:41 <TemptorSent> jirutka I apparently have a charset that doesn't map them properly.
18:42 <jirutka> TemptorSent: don’t tell me that you don’t use UTF-8…
18:42 <TemptorSent> *lol* jirutka Yeah, I'm sitting on a console terminal with no custom font loaded.
18:43 <TemptorSent> jirutka running bx full screen.
18:44 <ncopa> re libbsd
18:44 <jirutka> TemptorSent: well, then I’m sorry, but I refuse to use *incorrect* symbols just b/c someone still live in 1970…
18:44 <ncopa> http://patchwork.alpinelinux.org/patch/3350/
18:46 <jirutka> TemptorSent: Czech lang uses characters that are not in ASCII, so I’m very allergic to ancient charsets and neverending problems with them
18:47 <jirutka> Shiz: so you propose to backport these patches to our rust pkg? https://github.com/rust-lang/rust/pull/40123/files
18:47 <Shiz> our llvm4 package and then link rust against llvm4
18:47 <Shiz> it seems there's actual changes to rustc
18:48 <jirutka> llvm3.9 is currently used just for rust; but I think that we should keep llvm3.9 in community anyway
18:48 <Shiz> there's no actual changes*
18:48 <jirutka> Shiz: this PR doesn’t look like no actual changes…
18:49 <jirutka> Shiz: agree with backporting fixes to llvm4!
18:49 <Shiz> yeah the PR has changes in the rust-lang/llvm stuff
18:49 <Shiz> which is their llvm branch
18:49 <Shiz> :P
18:51 <jirutka> Shiz: for example this https://github.com/rust-lang/rust/pull/40123/files#diff-2eac1efa08534eca4e1fb606ec02139b is definitely in rust code-base ;)
18:51 <Shiz> jirutka: yes but those are irrelevant to us
18:51 <Shiz> since we're not mingw
18:51 <Shiz> :P
18:52 <jirutka> yeah, it was just an example; but tbh I’ve just skimmed it, no time now to read it all
18:57 <TemptorSent> jirutka: Oh, no complaint - just wanted to verify what was going on :)
18:58 <jirutka> ad php: we’ve already removed all php5-* pkgs and keep only php5 itself, plus moved to community; this simplifies (avoids) the problem a lot; community/php7 should be updated to the latest version (7.1.3) and testing/php7 removed; then all working testing/php7-* pkgs moved from testing to community; relevant PRs: https://github.com/alpinelinux/aports/pulls?q=is%3Aopen+is%3Apr+label%3AC-php+label%3AP-high
18:59 <TemptorSent> jirutka: Although perhaps changing the default consolefont would be wise, since I'm on default everything.
19:01 <jirutka> I’ll hopefully allocate some time for it, get in touch with Andy and somehow solve it together
19:01 <jirutka> but if someone else would do it, I’ll be happy :)
19:02 <TemptorSent> Um, do I need to create a distinct account for the wiki? Not the same credentials as Redmine?
19:02 <jirutka> TemptorSent: unfortunately yes, you need different account
19:02 <TemptorSent> Okay, thanks -- that's slightly irritating.
19:03 fekepp joined
19:04 <jirutka> TemptorSent: that’s yet another thing nice to have, centralized user accounts management and ideally some login gateway (OpenID Connect)
19:04 <TemptorSent> Bloody hell, an ambiguous captcha?!
19:04 <TemptorSent> Given the number ....., what's the second digit?
19:04 <TemptorSent> WTF?!@?
19:04 <jirutka> I usually do this with LDAP, b/c it’s supported by most apps, but not sure if we really want LDAP…
19:04 <TemptorSent> Second in place value or second in reading order?
19:05 <TemptorSent> I'll take ldap or a sane datbase backend any day.
19:05 <jirutka> uff, there’s sooo many things need to do and so little time that it depresses me
19:06 <skarnet> jirutka: welcome to my world
19:07 <jirutka> I have even very simple single-purpose app for changing password in LDAP for end-users, but written in Python :/ and most importantly it lacks password reset feature (it’s okay for company, but not for us I guess) https://github.com/jirutka/change-password
19:09 <jirutka> skarnet: no, that’s MY world, so you welcome to my world! XD :P
19:17 <TemptorSent> Hmm, seeing spl-vanilla failing on s390x -- is zfs actually suppored there currently?
19:20 <TemptorSent> MediaWiki is broken, spitting out backtrace, error about version of user to be saved is older than the current version.
19:20 <TemptorSent> Can't resend the verification email.
19:41 <tmh1999> ncopa : the libbsd fix I already submitted to github, so the one you just merged on patchwork is obsolete :(
19:41 <ncopa> tmh1999 not really
19:41 <ncopa> the patches on github fixed only ppc64 and s390x
19:41 <ncopa> explicitly
19:42 <tmh1999> okay understand
19:42 <ncopa> the one you sent earlier, from yokoto or what its called
19:42 <ncopa> fixes it on all arches
19:42 <tmh1999> yeah technically they are all the same
19:42 <ncopa> arm and aarch64 had smae issue
19:43 blueness joined
19:43 <tmh1999> ncopa : other thing, llvm4 build good on my test s390x machine, and it fails on the builder both edge and 3.6. is there something ?
19:44 <ncopa> ah yeah
19:44 <ncopa> its the bootstrap go
19:45 <tmh1999> go bootstrap effect llvm4 ?
19:45 <tmh1999> *affects
19:45 <ncopa> apparently
19:45 <tmh1999> hum...
19:46 <jirutka> tmh1999: the problem is that somehow Go remained on the build server and stupid autodetection in LLVM build system detected it and enabled some Go integration that fails
19:46 <tmh1999> jirutka, ncopa : wow, I have never acknowledged that before. can you fix it on the builder ncopa ?
19:46 <ncopa> om in oit
19:46 <ncopa> hum
19:47 <tmh1999> ncopa : appreciate it
19:47 <ncopa> i think i already fixed it
19:48 <tmh1999> ah right. it's done. thank you !
19:49 <jirutka> wait a moment, this is a different issue
19:49 <jirutka> llvm3.7 failed on s390x due to Go
19:49 <jirutka> llvm4 is different http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/llvm4/llvm4-4.0.0-r0.log
19:50 <jirutka> the latest log http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/llvm4/llvm4-4.0.0-r2.log … please note that the test errors are still here, they are just ignored (i.e. it does not fail the build)
19:51 <jirutka> ncopa: tmh1999: ^
19:52 <tmh1999> jirutka : hum...
19:52 <TemptorSent> Would someone please bump the irclogger, it appears to be lost.
19:53 <jirutka> TemptorSent: alternatively you can use http://www.irclogger.com/.alpine-devel/2017-04-25
19:53 <TemptorSent> Thanks jirutka, I was trying to follow commits with my browser.
19:53 <jirutka> I kinda like its retro look&feel, but it’s not very good for searching in history of multiple days
19:54 <jirutka> aha, #alpine-commits are not logged on irclogger.com
19:54 <TemptorSent> Drat.
19:54 <jirutka> I’ve clicked to #alpine-linux just for curiosity… the first thing spotted “php in docker image”… as expected, closed it immediatelly XD
19:55 <TemptorSent> I was going to try to look at some of those logs real quick, but there's nothing real quick about it if I have to type 'em :)
19:55 <jirutka> but happy that some more patient of us are even in #alpine-linux, so I don’t have to :)
19:56 <jirutka> TemptorSent: it’s probably better to aggregate messages from relevant MQTT topics instead of parsing irc log
19:56 <jirutka> TemptorSent: mosquitto_sub -h msg.alpinelinux.org -v -t 'build/build-edge-s390x'
19:57 <TemptorSent> Yeah, that's the problem, the browser is a pos 32bit windoze box.
19:57 <TemptorSent> (which shares nothing with my dev box except the external network)
20:04 <tmh1999> jirutka, ncopa : re llvm4 test fail, skimming the bug and llvm source, I guess the test are about creating/editing filesystem. It is maybe due to we are running the s390x build in lxc.
20:04 <jirutka> tmh1999: x86_64, x86, armhf, aarch64 also runs in lxc
20:05 <TemptorSent> Finally got the wiki to send the confirmation email... might want to check the logs and see whats going on there.
20:05 <tmh1999> I thought they all run on alpine ?
20:05 <tmh1999> native alpine
20:06 <jirutka> yes, native Alpine, but inside LXC container running on Alpine ;)
20:06 <jirutka> it’s Alpine all the way down and then just turtles…
20:08 <tmh1999> hum let me work on it more
20:10 <TemptorSent> What Wiki category shall I start the architecture pages under? Developer Documentation?
20:10 fekepp joined
20:12 <jirutka> TemptorSent: probably
20:13 <TemptorSent> Okay, will do -- I'll stub it and someone that actually knows how things works currently can fill in the details :)
20:17 <tmh1999> jirutka : spl-vanilla s390x fail on checking whether modules can be built... yes , probably the linux-vanilla s390x config missed some CONFIG you think ?
20:17 <tmh1999> checking whether modules can be built... no
20:17 <tmh1999> http://build.alpinelinux.org/buildlogs/build-edge-s390x/main/spl-vanilla/spl-vanilla-4.9.24-r0.log
20:21 <ncopa> seems like it cannot build any kernel module at all
20:22 <tmh1999> probably I should disable spl-vanilla zfs-vanilla, I might misunderstood them before
20:23 <Shiz> hmm
20:23 <Shiz> that's odd
21:21 consus joined
21:21 <TemptorSent> Okay, take a look at https://wiki.alpinelinux.org/wiki/Architecture
21:22 <arch3y> its coming along
21:23 <TemptorSent> There are some stubs to start from anyway.
21:27 BitL0G1c joined
22:03 leitao_ joined
22:09 tty` joined
22:29 rdutra joined
22:33 blueness joined
22:51 Ayyad joined
23:01 vakartel joined
23:03 rdutra joined