<    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 _2_9  
00:00 <consus> #define OVERHEAD (2*sizeof(size_t))
00:00 <consus> I used this formula to get the working address
00:01 <consus> But the compiler can screw things up
00:03 <Shiz> if it did that i think we would have issues in everything that uses malloc() in alpine
00:03 <Shiz> i think it's in opensmtpd code somehow...
00:04 <consus> Perhaps
00:04 <consus> Then why and how =/
00:04 <consus> Cause code looks pretty normal to me
00:04 <consus> I guess it's time for hardcore asm dumping shit
00:06 <consus> https://paste.pound-python.org/show/J41EG8uBGDXTFd7Xrgot/
00:06 <consus> > 18
00:06 <consus> down vote
00:06 <consus>
00:06 <consus> cltq promotes an int to an int64
00:07 <Shiz> that seems somewhat weird
00:07 <Shiz> since that sounds like
00:07 <Shiz> sign extension
00:07 <Shiz> :P
00:07 <consus> :D
00:07 <consus> Oh yeaaah
00:07 <Shiz> >Effect
00:07 <Shiz> It sign extends 4 bytes into 8 bytes
00:07 <Shiz> booya
00:07 <consus> Yes
00:07 <consus> The question is
00:07 <consus> WHY
00:08 <Shiz> i think i nkow why
00:08 <Shiz> actually
00:08 <consus> Huh?
00:08 <Shiz> opensmtpd fails to include the correct header for reallocarray
00:08 <Shiz> and thus the C compiler assumes a signature of int reallocarray(...)
00:08 <Shiz> and sign-extends as necessary
00:08 <consus> Good point
00:08 <consus> Gonna check
00:11 <Shiz> consus: ../../smtpd/util.c:599:8: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration]
00:12 <Shiz> tmp = reallocarray(args->list, nalloc, sizeof(char *));
00:12 <Shiz> yayaya
00:12 <consus> Yap
00:12 <consus> Sound like it
00:12 <Shiz> ../../smtpd/enqueue.c:783:16: warning: implicit declaration of function 'reallocarray' [-Wimplicit-function-declaration]
00:12 <Shiz> if ((nrcpts = reallocarray(msg.rcpts,
00:12 <Shiz> ^~~~~~~~~~~~
00:12 <Shiz> and there's our issue
00:12 <consus> Yes
00:12 <Shiz> it's not adding -include openbsd-compat.h
00:12 <consus> With defined prototype it works
00:12 <Shiz> for some reason
00:12 <consus> Just missed that
00:12 <consus> I guess I should send them a patch
00:13 <Shiz> hmm wait
00:14 <consus> 783 if ((nrcpts = reallocarray(msg.rcpts,
00:14 <consus> 0x0000000000005dd3 <+84>: movslq %eax,%rcx
00:14 <consus> 0x0000000000005dd6 <+87>: mov 0x23cd7b(%rip),%rax # 0x242b58 <msg+24>
00:14 <consus> 0x0000000000005ddd <+94>: mov $0x8,%edx
00:14 <consus> 0x0000000000005de2 <+99>: mov %rcx,%rsi
00:14 <consus> 0x0000000000005de5 <+102>: mov %rax,%rdi
00:14 <consus> 0x0000000000005de8 <+105>: callq 0x2a3b3 <reallocarray>
00:14 <consus> 0x0000000000005ded <+110>: mov %rax,0x28(%rsp)
00:14 <consus> 0x0000000000005df2 <+115>: cmpq $0x0,0x28(%rsp)
00:14 <consus> 0x0000000000005df8 <+121>: jne 0x5e30 <rcpt_add+177>
00:14 <consus> cltq is gone
00:14 <consus> :D
00:15 <consus> clit queue
00:15 <consus> sorry
00:15 <Shiz> please use a pastebin for that in the future
00:15 <Shiz> :p
00:15 <Shiz> i'll figure out why it doesn't work
00:15 <Shiz> and format a patch for the alpine package at least
00:16 <consus> What doesn't work?
00:16 <Shiz> the openbsd-compat.h include
00:17 <consus> It's not that simple
00:17 <consus> There is a HAVE_REALLOCARRAY macro
00:17 <Shiz> yes
00:17 <Shiz> i know :p
00:17 <Shiz> it's from config.h
00:18 <consus> It set to one =/
00:18 <consus> Strange
00:19 <Shiz> yeah...
00:19 <jirutka> Shiz: unfortunately it didn’t fix the bug with dynamic linking of cargo :(
00:19 <Shiz> so it's just not sending the right includes
00:19 <Shiz> jirutka: that is odd...
00:20 <jirutka> Shiz: https://hastebin.com/raw/aracuhasar
00:20 <Shiz> jirutka: it did though!
00:20 <jirutka> Shiz: what?
00:20 <consus> Shiz: I got it
00:20 <Shiz> jirutka: it fixed part of it
00:20 <Shiz> :)
00:20 <consus> Shiz: includes.h does not include config.h
00:20 <Shiz> consus: that's not relevant
00:20 <jirutka> Shiz: then I’m blind…
00:20 <Shiz> openbsd-compat.h does
00:21 <Shiz> jirutka: it failed against different symbols before
00:21 <jirutka> Shiz: really? it looks exactly the same from firsh sight
00:21 <Shiz> the symbols you gave me before were from libc
00:21 <consus> Shiz: no it's not
00:21 <Shiz> this is not from libc
00:21 <consus> Shiz: in latest git at least
00:21 <jirutka> aha, yes
00:21 <jirutka> hmm
00:22 <Shiz> consus: https://github.com/OpenSMTPD/OpenSMTPD/blob/portable/openbsd-compat/includes.h#L19
00:22 <Shiz> ?
00:22 <Shiz> jirutka: so it seems easy to fix
00:22 <Shiz> there's two more things here
00:22 <consus> Huh
00:22 <consus> ok
00:22 <Shiz> libunwind should apparently be linked dynamically
00:22 <Shiz> or not dynamically
00:22 <Shiz> but without static=
00:22 <Shiz> and
00:23 <Shiz> jirutka: if -C prefer-dynamic is passed, it should imply -C rpath
00:23 <Shiz> for alpine
00:23 <Shiz> because we don't ship dupe libs in /usr/lib
00:23 <Shiz> consus: the issue is that it sees reallocarray as defined
00:23 <Shiz> and arc4random stuff
00:23 <jirutka> Shiz: but we don’t wanna link rust libs dynamically
00:23 <Shiz> which may be true
00:23 <Shiz> but then it's not including the right headers
00:23 <Shiz> jirutka: that's where the failures come from
00:24 <Shiz> jirutka: also, we have little say in this
00:24 <Shiz> we surel shouldn't dictate for our users if they want to link rust dynamically
00:24 <Shiz> and those test cases are testing -C prefer-dynamic cases
00:24 <jirutka> aha
00:25 <consus> Shiz: How does it discover that you have/have not reallocarray?
00:25 <Shiz> consus: configure.ac test
00:25 <Shiz> jirutka: in support-dynamically-linked-musl.patch
00:25 <Shiz> i think we should change this
00:25 <Shiz> +#[link(name = "unwind", kind = "static", cfg(target_feature = "crt-static"))]
00:25 <Shiz> +#[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))]
00:25 <Shiz> to
00:26 <Shiz> #[link(name = "unwind")]
00:26 <Shiz> and it'll be all good
00:26 <jirutka> yeah, I was thinkign about this
00:26 <jirutka> and then we must probably fix similar problem in all other libs… omfg, rust!
00:27 <Shiz> jirutka: i don't think that many libs are hit by using target_feature = crt-static actually
00:27 <Shiz> since it's pretty new
00:27 <Shiz> and also not relevant to a lot of stuff
00:27 <consus> Shiz: They changed the check
00:27 <consus> Shiz: In later versions
00:28 <Shiz> well
00:28 <Shiz> i'm checking against opensmtpd 6.0.2
00:28 <Shiz> which isn't the newest, but
00:28 <Shiz> :P
00:28 <consus> #if !defined(HAVE_REALLOCARRAY) || defined(LIBRESSL_VERSION_NUMBER)
00:28 <Shiz> consus: do you have a commit #?
00:28 <consus> Seems like libressl defines reallocarray already
00:29 <consus> f948b923873a93472dea9b786cf60a3472b0ddc8
00:29 <consus> fix compatibility with libressl
00:29 <Shiz> ah right
00:29 <Shiz> nice
00:29 <consus> This avoids implicit function declarations and the resulting crashes due
00:29 <consus> to pointer truncation.
00:29 <consus> xD
00:29 <consus> Dammit
00:29 <Shiz> i'll add that to the 6.0.2 apkbuild
00:29 <Shiz> and request for a backport to 3.5
00:29 <consus> Just bump the whole stuff
00:30 <Shiz> well, yes
00:30 <Shiz> 6.0.2 is the latest release
00:30 <consus> It's clearly not being used by anyone
00:30 <Shiz> ¯\_(ツ)_/¯
00:30 <Shiz> we can't ship unreleased versions
00:30 <consus> Except for me
00:30 <consus> > Date: Wed Jan 11 17:35:29 2017 -0600
00:30 <Shiz> yes, 6.0.2 is from oct 2016
00:31 <consus> Now I feel really stupid
00:31 <Shiz> they're currently doing a big rewrite
00:31 <Shiz> also jirutka small world
00:31 <jirutka> Shiz: ?
00:31 <Shiz> the guy who made this libressl patch is the same guy who did the initial musl dynamic support patch for rust
00:31 <Shiz> :P
00:31 <jirutka> wow :)
00:32 <consus> Okay
00:32 <consus> It was good and productive
00:32 <Shiz> consus: rebuilt locally
00:32 <Shiz> gonna check if it works
00:33 <consus> It could've been much more productive if we'd care for git log's
00:33 <consus> But well
00:33 <consus> It's the way it is xD
00:35 <consus> Shiz: Thank you for your help
00:36 <Shiz> np
00:36 <Shiz> https://txt.shiz.me/ZWYxN2I1MW
00:36 <Shiz> gonna PR this to aports in a bit
00:37 <Shiz> look good to you?
00:37 <Shiz> / # echo 123 | sendmail root
00:37 <Shiz> / #
00:37 <Shiz> :)
00:38 <consus> :D
00:38 <jirutka> wat? XD
00:38 <consus> Looks good
00:38 <consus> How someone becomes a maintainter?
00:41 <Shiz> consus: https://github.com/alpinelinux/aports/pull/1235
00:41 <Shiz> :)
00:42 <Shiz> consus: you step up to the ask ;)
00:42 <Shiz> might be useful to contatct the current maintainer to see if they are still interested though
00:42 <Shiz> s/ask/task/
00:43 <Shiz> although i'm currently semi-maintaining opensmtpd i'm not the official maintainer (and i'd be happy to offload it to you :p)
00:49 <Shiz> thx jirutka :)
00:49 <jirutka> Shiz: yw
00:50 <Shiz> this patch probably needs a backport to 3.5
00:50 <Shiz> who's in charge of those decisions?
00:50 <jirutka> Shiz: opensmtpd in v3.5 is also affected, i.e. broken?
00:50 <Shiz> yes
00:51 <Shiz> afaik that is
00:51 <jirutka> Shiz: there’s 5.9.2p1 in v3.5, could you please backport your patch to this version?
00:51 <jirutka> Shiz: and open a PR against 3.5-stable
00:52 <Shiz> i'll double-check first
00:52 <Shiz> :)
00:52 <Shiz> confirmed
00:52 <Shiz> i'll backport it
00:54 <Shiz> jirutka: btw, motion to move the rust pkg to llvm-libunwind
00:54 <Shiz> since that is what upstream uses too
00:54 <Shiz> if we haven't changed that already
00:54 <jirutka> okay
00:54 <Shiz> (and it's easier to debug)
00:54 <Shiz> (4real)
01:03 <Shiz> backporting...
01:09 <jirutka> llvm3.9 landed in the testing repo
01:09 <jirutka> going sleep
01:09 <jirutka> gn
01:10 <jirutka> Shiz: if you’d like to build rustc against llvm 3.9, just change llvm-root from /usr to /usr/lib/llvm3.9
01:10 <Shiz> gotcha :)
01:10 <Shiz> night!
01:25 s33se joined
01:33 s33se joined
01:35 rdutra joined
01:54 <Shiz> jirutka: the static PIE issue is resolved!
01:54 <Shiz> it takes a patch to musl
01:54 <Shiz> and llvm-libunwind
02:08 <tmh1999> beautiful work jirutka :) I have been waiting for llvm3.9 for a while
03:02 <Shiz> jirutka: btw, that build failure on x86 for llvm-libunwind should be an easy fix
03:35 <kaniini> oh, somebody already did llvm3.9?
03:36 <kaniini> cool
03:36 <kaniini> jirutka: great work on llvm3.9 :)
03:36 <kaniini> jirutka: i think it can go to main
03:37 <kaniini> assuming rust is good, anyway
03:48 <Shiz> kaniini: we're weeding out the last stuff in rust :P
03:48 <Shiz> kaniini: on that note, musl patch incoming
03:48 <kaniini> give me an mbox and i will take care of it
03:56 <Shiz> kaniini: https://txt.shiz.me/YmE2ZGYwZD
04:45 <Shiz> jirutka: list of remaining test failures in cargo and their reason: https://txt.shiz.me/OTU3YzBmNz
04:50 <kaniini> Shiz: done
04:50 <Shiz> \o
05:05 terra joined
05:11 fabled joined
05:44 fekepp joined
06:05 vakartel joined
06:42 czart__ joined
06:53 LongyanG joined
06:55 skarnet joined
06:55 algitbot joined
06:56 XgF joined
06:57 al3hex joined
06:57 mitchty joined
06:57 th joined
07:01 royger joined
07:24 t0mmy joined
07:28 stwa joined
07:35 minimalism joined
07:53 <ncopa> jirutka: i dont remember llvm print_context.c
08:28 stwa joined
09:14 kaniini joined
09:20 hl joined
09:22 consus joined
10:21 blueness joined
10:26 tty`_ joined
10:45 blueness joined
11:29 <fcolista> hi all
11:30 <Shiz> hiya
11:31 <consus> Guys
11:31 <consus> How do you (auto-)test your packages?
11:31 <Shiz> a good question
11:31 <Shiz> a relatively new feature in edge is that APKBUILDs will define a check() function
11:31 <Shiz> that performs automated tests
11:31 <consus> Hm
11:32 <Shiz> as policy, all new packages (and preferably the existing ones too) should have that check(), or explicitly opt out with features=!check
11:32 <Shiz> in the future I think abuild will reject APKBUILDs that do neither
11:32 <consus> And what check should a maintainer write for e.g. a opensmtpd?
11:32 <Shiz> well, if the package has a test suite, running that would be appropriate
11:32 <consus> I was thinking about autotesting the packages that I use daily
11:32 <Shiz> also I don't think you caught my last message to you yesterday
11:33 <Shiz> Shiz │ consus: you step up to the ask ;)
11:33 <consus> Like setting up a VM that will grab new stuff and test it for me
11:33 <Shiz> Shiz │ might be useful to contatct the current maintainer to see if they are still interested though
11:33 <Shiz> Shiz │ s/ask/task/
11:33 <Shiz> Shiz │ although i'm currently semi-maintaining opensmtpd i'm not the official maintainer (and i'd be happy to offload it to you :p)
11:33 <consus> Oh, nice
11:33 <consus> Much easier than Gentoo
11:33 <consus> With all that insane interview crap
11:33 <Shiz> i would recommend getting approval from the existing maintainer
11:34 <consus> Of course
11:34 <Shiz> consus: well, with alpine being a maintainer doesn't mean you have commit access
11:34 <Shiz> so it's a bit different from Gentoo
11:34 <Shiz> you still have to get your updates through github PRs with peer review
11:34 <Shiz> :p
11:34 <consus> Being maintainter in Gentoo doesn't mean that too
11:34 <Shiz> ah
11:34 <Shiz> i thought it did
11:34 <consus> Proxy-maint
11:34 <consus> And stuff
11:34 <consus> I was trying to become a full-blown developer
11:35 <consus> The fact is -- those guys are really touchy
11:35 <Shiz> eh, I can see why they would need to
11:35 <Shiz> it's also something that kinda changes with project scale -- at some point it's hard to keep tabs on everybody
11:35 <consus> I mean I was literally banned from IRC for cursing about some stuff during my debug session
11:35 <Shiz> not sure if that's the approach Alpine will take, but I can see some reasons why they would do it
11:35 <Shiz> heh
11:36 <consus> Yeah
11:36 <clandmeter> ah so we know what to expect :p
11:36 <consus> :D
11:36 <consus> Hey, I'm a nice guy
11:36 <clandmeter> when all goes well ;-)
11:36 <^7heo> So you're a terrible person?
11:36 <consus> I just something use the f word during the late-night attempt to fix some crashing app
11:37 <consus> *sometimes
11:37 <clandmeter> ^7heo, we dont want to remove your title.
11:37 <^7heo> (When people communicate about themselves, they usually communicate only to hide their flaws/shortcomings)
11:37 <^7heo> clandmeter: I'm totally okay when I have eaten.
11:37 <consus> ^7heo: +1
11:37 <^7heo> consus: about which part?
11:37 <consus> About the food
11:37 <^7heo> ah yeah
11:37 <^7heo> Well, that's the pyramid of needs
11:37 <^7heo> Maslov's pyramid or whatnot.
11:38 <consus> For sure
11:38 <consus> Shiz: So there is no some adopted autotesting toolset that you guys have, right?
11:38 <^7heo> the 1# guideline to social life.
11:38 <Shiz> consus: not as i know it, but I'm not intimately familiar with Alpine's infra
11:39 <Shiz> I just create and edit APKBUILDs, mostly
11:39 <Shiz> maybe clandmeter knows more definitively
11:39 <Shiz> :)
11:39 <consus> Got it, I'll ask around
11:39 <^7heo> and our society is kinda perverted about the priority according to that hierarchy of needs; but le'ts talk about that on -offtopic instead.
11:39 <^7heo> consus: you're not there btw.
11:39 <Shiz> (don't go to -offtopic)
11:40 <consus> Shiz: So how long it will took the 6.x opensmtpd to go through all the necessary step to 3.5.x?
11:40 <Shiz> consus: i don't think 6.0.2 is going to land in 3.5
11:40 <Shiz> i backported the crash patch to 3.5 though
11:40 <consus> =/
11:40 <consus> Oh
11:40 <consus> Okay
11:40 <consus> So how long?
11:40 <Shiz> uhm
11:40 <Shiz> when someone merges my PR and then when a new point release of 3.5 is made
11:40 <Shiz> :P
11:40 <clandmeter> until check() it was up to the maintainer to manually verify the aport.
11:40 <consus> Wow
11:41 <consus> It's a long run
11:41 <Shiz> https://github.com/alpinelinux/aports/pull/1236
11:41 <Shiz> this is the backport PR if you're interested in tracking it
11:41 <Shiz> I suspect jirutka will merge it today for me
11:41 <Shiz> :P
11:41 <consus> Okay, I can use aports of course
11:41 <Shiz> as for point releases, i have honestly no idea when those are made
11:41 <consus> Hmm
11:42 <Shiz> clandmeter: is it right that point releases only matter to ISO distributions or am I wrong there?
11:42 <Shiz> as in, stable will always get what's new in the 3.x-stable branch in aports
11:42 <consus> So the repo is fixed in time or what?
11:42 <consus> Ah
11:42 <Shiz> consus: that's what I'm asking clandmeter
11:42 <Shiz> :P
11:42 <consus> I guess so
11:43 <Shiz> my (maybe wrong) interpretation is that edge gets branched off to 3.x-stable for a 3.x release, and that the repo mirrors are always up-to=date with that branch
11:43 <consus> How else whould you land security fixes fast?
11:43 <Shiz> and that point releases only matter for the .isos on the site
11:43 <consus> E.g. in case of another heartbleed you should act as fast as you can
11:43 <Shiz> yup
11:43 <consus> And waiting for a point release in that case would be a huge design drawback
11:43 <Shiz> so in that case it would be whenever my PR is merged and the buildbots are done with it
11:43 <Shiz> :)
11:43 <clandmeter> we generate our iso/tarballs from tags in stable repo
11:44 <clandmeter> err stable branch
11:44 <Shiz> clandmeter: right, but the apk repo?
11:44 <Shiz> like, dl-cdn etc
11:44 <Shiz> the ones users use to get packages on an installed system :P
11:44 <clandmeter> it follows the branch?
11:45 <consus> clandmeter: My point is -- can I receive critical updates on openstmtpd before the next point release?
11:45 <Shiz> right
11:45 <consus> clandmeter: Through the regular channesl
11:45 <Shiz> clandmeter: that was my question
11:45 <consus> clandmeter: And not aports
11:45 <Shiz> so whenever my PR is merged, it will be available for 3.5 users once the buildbots are done, right?
11:46 <clandmeter> the pr's are against master
11:46 <consus> It's against 3.5-stable
11:46 <Shiz> no
11:46 <consus> https://github.com/alpinelinux/aports/pull/1236
11:46 <Shiz> my PR is against 3.5-stable
11:46 <Shiz> :P
11:46 <Shiz> it's a backport of a fix in master
11:46 <Shiz> that already got merged
11:46 <clandmeter> ah right
11:46 <clandmeter> yes that will get into 3.5 repo
11:47 <Shiz> :)
11:47 <consus> =/
11:47 <Shiz> consus: ?
11:47 <consus> zsh has wrong PS1
11:48 <consus> Due to sourcing /etc/profile and not defining it's own
11:48 <Shiz> 'wrong'?
11:48 <consus> \h:\w$
11:48 <consus> It's not expanded in zsh
11:48 <consus> Because it has no meaning
11:48 <consus> For zsh
11:49 <Shiz> ah
11:50 <clandmeter> Shiz, i think thats the first time ive seen a PR against stable branch.
11:51 <Shiz> that's what jirutka told me to do
11:51 <jirutka> clandmeter: that’s quite possible :)
11:51 <Shiz> the patch required manual adjustments so it couldn't be trivially cherry-picked from edge
11:51 <consus> jirutka: For the love of god, push it! :)
11:51 <jirutka> clandmeter: it’s a backport
11:51 <clandmeter> and travis runs on edge, but maybe jirutka changed something?
11:52 <jirutka> clandmeter: no, still runs on edge, but that doesn’t matter, I just needed a patch and not a fan of sending patches via email ;)
11:53 <Shiz> btw
11:53 <Shiz> https://github.com/alpinelinux/aports/pull/1204
11:53 <Shiz> this PR now LGTM
11:58 leitao joined
12:02 rdutra joined
12:06 <Shiz> consus: and it's merged
12:06 <Shiz> so when the buildbots are done, it'll be in your local 3.5
12:08 <Shiz> jirutka: did you see my messages from last night?
12:08 <consus> Shiz: ^^
12:09 <jirutka> clandmeter: Shiz what msg?
12:09 <Shiz> Shiz │ jirutka: the static PIE issue is resolved!
12:09 <Shiz> Shiz │ it takes a patch to musl
12:09 <Shiz> Shiz │ and llvm-libunwind
12:09 <Shiz> Shiz │ jirutka: btw, that build failure on x86 for llvm-libunwind should be an easy fix
12:09 <Shiz> Shiz │ jirutka: list of remaining test failures in cargo and their reason: https://txt.shiz.me/OTU3YzBmNz
12:09 <jirutka> Shiz: wow! that’s awesome! \o/ \o/
12:09 <algitbot> \o/\o/
12:10 <jirutka> Shiz: you’re our hero!
12:10 <Shiz> :p now now
12:12 <consus> Yay!
12:12 <consus> smtp is working!
12:13 <Shiz> :)
12:13 farosas joined
12:16 gromero joined
12:21 <jirutka> Shiz: I’ve pushed updated rust and cargo to testing
12:21 <jirutka> and go to lunch now
12:22 <consus> Hmm
12:22 <consus> Who creates /var/mail symlink?
12:22 <consus> What package?
12:23 <jirutka> could please someone verify if mesa (https://pkgs.alpinelinux.org/package/edge/main/x86_64/mesa) is compatible with llvm 3.9 and try to build it against it?
12:23 <jirutka> and also afl (https://pkgs.alpinelinux.org/package/edge/testing/x86_64/afl)
12:24 <jirutka> so we can eventually get rid of llvm 3.8
12:24 <jirutka> afk
12:24 <consus> Shiz: A sidenote
12:25 <consus> Shiz: OpenSMTPD fails to deliver to mailbox if /var/mail does not exist
12:26 <consus> It may be a good idea to add /var/mail -> /var/spool/mail
12:26 <consus> Either to the opensmtpd or to the base layout
12:26 <consus> Since mailx and other tools will look there for mboxes
12:27 <consus> $ strace mail 2>&1 | grep /var
12:27 <consus> open("/var/mail/root", O_RDONLY)
12:27 <consus> E.g.
12:28 <consus> clandmeter: Who maintains the base layout in Alpine?
12:29 <^7heo> ncopa, clandmeter, fabled, and a few others.
12:29 <consus> I have a proposition, where to send?
12:29 <clandmeter> our ml
12:29 <consus> http://bugs.alpinelinux.org/issues/5091
12:29 <consus> Ah
12:29 <consus> There is already one
12:30 <consus> http://bugs.alpinelinux.org/issues/5604
12:30 <consus> And this
12:30 <consus> Target versions set to 3.6 =/
12:55 stwa joined
12:57 terra joined
12:59 stateless joined
13:25 blueness joined
14:05 <jirutka> Shiz: you’ve said that llvm-libunwind’s build failure on x86 can be easily fixed… how? -fno-stack-protector?
14:30 <consus> Seems like /etc/init.d/hostname ignores /etc/conf.d/hostname
14:30 <consus> How about removing /etc/conf.d/hostname?
14:31 <jirutka> consus: /etc/conf.d/hostname is for /etc/init.d/hostname
14:31 <consus> jirutka: look at the /etc/init.d/hostname
14:31 <jirutka> consus: I did it
14:31 <consus> jirutka: it does not use the provided variable
14:32 <consus> jirutka: it looks at /etc/hostname
14:32 <jirutka> consus: aha, right
14:32 <jirutka> consus: yes, then we should remove conf.d/hostname, good point!
14:32 <consus> :)
14:44 <consus> Should I file a bug or something?
15:06 fabled joined
15:18 amcleod joined
15:34 awilfox joined
15:46 <xsteadfastx> clandmeter: so now im back. what you wrote about the circular dependencies for snapcast
15:46 <xsteadfastx> but what if someone wants to install both through apk add snapcast
15:46 <xsteadfastx> thats wouldnt work no more
15:46 <xsteadfastx> its no meta package no more
15:53 <Shiz> recovered
15:53 <Shiz> jirutka: no, that'd just be a hack
15:53 <Shiz> :P
15:53 <jirutka> Shiz: okay, so how? :)
15:53 <Shiz> jirutka: do you have an x86 builder i could access?
15:53 <Shiz> i don't have one myself :
15:53 <Shiz> (
15:54 <Shiz> jirutka: it's not linking in -lssp_nonshared because of -nodefaultlibs i think
15:54 <jirutka> Shiz: no, I haven’t seen x86-only machine for more than 10 years…
15:54 <Shiz> and it should
15:56 <TemptorSent> *LOL* I'm using an x86 only machine for my daily use still browsing on windoze. It's painful, but I'm stuck with it because of some proprietary crap I need to support.
16:06 leitao joined
16:37 <Shiz> time to boot an x86 iso
16:52 <Shiz> lol
16:52 <Shiz> i can't compile libunwind because the x86 builder is MIA
16:52 <Shiz> cc jirutka
16:53 <Shiz> (for the llvm3.9 dep)
16:55 <awilfox> libunwind doesn't build unpatched on x86_32 last I checked, it needs some fluffing first
16:55 <Shiz> awilfox: i already fixed the issue
16:55 <Shiz> :)
16:55 <Shiz> just now
16:55 <awilfox> I have an x86_32 builder here, but it's an adelie builder, not alpine one
16:55 <awilfox> Shiz: oh nice! let me know when the patch is published, it'd be very helpful :3
16:56 <clandmeter> xsteadfastx, check https://github.com/alpinelinux/aports/blob/c0722a089a60fe9b1e957735939774a1cf6ba4f9/testing/snapcast/APKBUILD
16:59 <Shiz> so fr some reason -DCMAKE_SHARED_LINKER_FLAGS isn't working...
17:00 <xsteadfastx> So you did it by yourself?
17:00 <xsteadfastx> And an empty depends does what?
17:05 <clandmeter> Unset the main deps
17:05 <jirutka> Shiz: MIA?
17:06 <clandmeter> Missing in action?
17:06 <jirutka> aha :)
17:07 <jirutka> Shiz: maybe it prioritizes flags with release_type suffix
17:07 <clandmeter> That's a band from the 90
17:07 <jirutka> Shiz: something like CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL ?
17:07 <Shiz> i'll try that
17:08 <jirutka> Shiz: this is probably wrong, run cmake -LAH and see what flags are there
17:08 <Shiz> sadly no cigar
17:08 <jirutka> I don’t remember all these crazy cmake flags from head :)
17:08 <jirutka> cigar?
17:08 <Shiz> https://en.wiktionary.org/wiki/close,_but_no_cigar
17:08 <Shiz> :P
17:09 <jirutka> heh
17:09 <xsteadfastx> I don't get it. So if I install snapcast-client... How does the package know to install the meta main package?
17:09 <Shiz> so the flag is there
17:09 <Shiz> i guess it's just not used...
17:10 <Shiz> xsteadfastx: it doesn't and it shouldn't
17:10 <Shiz> it's the other way around
17:10 <clandmeter> It's different now
17:10 <Shiz> when you install the meta package it installs both -server and -client
17:11 <xsteadfastx> So no seperation
17:11 <clandmeter> I'm on mobile now... Difficult to type...
17:11 <xsteadfastx> Me too
17:11 <clandmeter> The subpkg will now install the user
17:12 <jirutka> install the user? we have scripts to install our users now? wow! :)
17:12 <clandmeter> So no need for main PKG to do that, so no reason to pull it in
17:12 <jirutka> but I’d more appreciate the script to uninstall the user :)
17:12 <Shiz> xsteadfastx: it's like this
17:12 <Shiz> you can install snapcast, which will install both the server and client
17:12 <Shiz> or you can install snapcast-server and snapcast-client separately
17:12 <Shiz> that's the idea
17:13 t0mmy joined
17:13 <clandmeter> Your version would introduce circular deps
17:13 <clandmeter> We try to prevent that
17:14 <jirutka> clandmeter: circular dep between origin and subpkgs?
17:14 <clandmeter> Yes
17:14 <jirutka> clandmeter: then it’s more a bug (or missing feature) in abuild imo…
17:14 <jirutka> clandmeter: we can/should handle this situation
17:14 <jirutka> clandmeter: also I’ve already used this few times and no problem so far o.O
17:14 <Shiz> circular deps?
17:16 <clandmeter> Ncopa, save me with your keyboard :-)
17:17 <* ncopa> slaps clandmeter with the keyboard
17:18 <ncopa> feel better?
17:18 <clandmeter> Yes
17:18 <^7heo> #alpine-bdsm
17:18 <ncopa> :)
17:18 <^7heo> that would go well along with skarnet's #alpine-fantaisies suggestion.
17:19 <awilfox> jirutka: you could use `pushd gcc; abuild` if you want to uninstall a user from a laptop at least
17:19 <awilfox> not sure about desktops, they don't usually cause third degree burns while building a compiler
17:20 <Shiz> jirutka: success!
17:20 <jirutka> what? :)
17:21 <jirutka> clandmeter: actually, I’m quite sure that it does not cause any problem, I’ve used it even in rust pkg
17:23 <Shiz> jirutka: https://txt.shiz.me/NDE2MDI3OT
17:23 <Shiz> this patch is against llvm-libunwind 3.8 since i can't build 3.9 on x86 (because no llvm3.9 because missing builder)
17:23 <Shiz> but i think it should work for 3.9 too
17:24 <jirutka> Shiz: nice!
17:27 blueness joined
17:28 <jirutka> Shiz: the resulting binaries are exactly the same on x86_64 :)
17:28 <Shiz> :)
17:28 <Shiz> it just removes some nonsense
17:28 <Shiz> not sure why they use -nodefaultlibs at all
17:29 <Shiz> it just makes you vulnerable to deviating compilers (like ours)
17:29 <Shiz> because they're just re-adding the implicit deps manually...
17:31 <Shiz> jirutka: btw can you look at pr 1204?
17:32 <Shiz> https://github.com/alpinelinux/aports/pull/1204
17:32 <jirutka> not now, later
17:33 <Shiz> \o
17:44 vakartel joined
19:12 <leitao> gromero, have you ever heard about pt_regs redefinition ?
19:12 <leitao> /usr/include/bits/user.h:1:8: error: redefinition of 'struct pt_regs'
19:12 <leitao> and
19:12 <leitao> /usr/include/asm/ptrace.h:31:8: note: originally defined here
19:18 <Shiz> ah yes, a classic
19:22 <leitao> Shiz, what would you recommend?
19:22 <leitao> one pt_regs come from the kernel
19:22 <Shiz> package compilation error?
19:22 <leitao> the other one from musl-dev
19:22 <leitao> yes
19:22 <leitao> http://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/psmisc/psmisc-22.21-r2.log
19:23 <Shiz> yeah it's because the kernel headers don't particularly interact nicely with the userspace headers
19:23 <Shiz> it's being worked on upstream, but in the meantime you can hac karound it
19:24 <Shiz> i see something like this used elsewhere:
19:24 <Shiz> https://txt.shiz.me/ODM0MDRiMG
19:24 <Shiz> keeping in mind that its a rather ugly hack until kernel upstream fixes their stuff
19:26 <leitao> Shiz, nice, let me try it
19:27 xfix joined
19:33 terra joined
19:33 <leitao> Shiz, why would #define pt_regs uapi_pt_regs avoid the naming clash?
19:34 <Shiz> leitao: when the kernel header file does struct pt_regs { ... }
19:34 <Shiz> it will be expanded to struct uapi_pt_regs { ... }
19:34 <Shiz> thus avoiding the clash
19:36 <leitao> makes sense.
19:36 <gromero> "<Shiz> ah yes, a classic" yes, it is
19:36 <gromero> for instance: strace: <Shiz> ah yes, a classic
19:36 <gromero> sorry: https://github.com/alpinelinux/aports/commit/70e8624cec8394b1517a6a0dcba72bbb0c9b9e74
19:36 <Shiz> i see that works around it in a different way
19:36 <gromero> leitao: so just workaround at the moment...
19:37 <Shiz> yeah
19:37 <Shiz> there's upstream work to fix it though
19:37 <Shiz> or at least, a discussion
19:37 <Shiz> dalias sparked one on the kernel ML i think
19:37 <gromero> Shiz: recently or that one: http://www.openwall.com/lists/musl/2016/12/30/5
19:38 <Shiz> gromero: kernel ML, not musl ML
19:38 <Shiz> :P
19:38 <gromero> Shiz: ah, ok
19:38 <gromero> Shiz: reading too fast...
19:38 <Shiz> i think it was at least somewhere this year
19:39 <Shiz> forget exactly when, don't have a link handy either
19:39 <gromero> Shiz: ok. I talked to him a couple of weeks ago a he said there is no solution at the moment, just workarounds...
19:39 <Shiz> yeah, as of right now, sadly not
19:39 <gromero> *and he said
19:39 <Shiz> but there's hope, maybe....
19:39 <gromero> yep...
19:40 <Shiz> hope for the future
19:40 <gromero> I *do* really hope for the future :)
19:40 BitL0G1c joined
19:47 <Shiz> jirutka: ping?
19:54 rdutra joined
20:17 vakartel joined
20:24 stateless joined
20:28 <jirutka> Shiz: pong
20:28 <Shiz> got a patch for rust for you
20:28 <jirutka> Shiz: great!
20:28 <Shiz> also
20:29 <Shiz> the remaining cargo failures are a logical result of creating a dylib on crt-static
20:29 <Shiz> of courrse that won't work
20:31 <Shiz> jirutka: https://txt.shiz.me/Y2NjMzFmZT
20:31 <jirutka> Shiz: why you’ve removed llvm-dev? o.O
20:32 <Shiz> it's already in depends=
20:32 <Shiz> i removed llvm-libunwind-dev that is
20:32 <Shiz> not llvm-dev
20:33 <jirutka> no, see your patch…
20:33 <jirutka> you’ve removed llvm$_llvmver-dev from makedepends
20:33 <jirutka> aha, pardon
20:34 <jirutka> too tired…
20:34 <Shiz> :P
20:34 <jirutka> I’ll rather apply it and examine in terminal
20:37 <jirutka> aand now I see it better; yes it’s okay, sorry for false negative :)
20:38 <Shiz> i'm going to make an internals.rust-lang.org post about CRT-static semantics
20:39 <jirutka> Shiz: is this patch ”only” quality improvement or does it solve some bug?
20:40 <Shiz> it solves a bug
20:40 <Shiz> specifically, libunwind being linked wrongly possibly
20:40 <Shiz> and it simplifies the patch even too
20:40 <jirutka> where/how does this bug manifest?
20:40 <jirutka> I see that it simplifies it :)
20:40 <gromero> does anyone ever got "sh -x /usr/bin/abuild -r" working but "/usr/bin/abuild -r" not working?
20:40 <Shiz> there were some cargo build errors
20:41 <Shiz> of linking against libunwind symbols
20:41 <Shiz> err
20:41 <Shiz> not build
20:41 <Shiz> test errors
20:41 <jirutka> ah, these errors
20:41 <jirutka> great!
20:41 <jirutka> so the rest build errors in static and dynamic cargo are only incompatible tests?
20:42 <Shiz> do you mean those as two things or one thing?
20:42 <jirutka> as two
20:42 <jirutka> there are some failures for both static and dynamic
20:42 <Shiz> oh?
20:42 <Shiz> oh right
20:42 <Shiz> the -lstd thing
20:42 <jirutka> yes, exactly
20:42 <jirutka> aha, but I know why this
20:43 <Shiz> right, rpath.
20:43 <jirutka> it’s because we don’t have rust libs on ld path
20:43 <Shiz> jirutka: we probably need to make -C rpath default
20:43 <Shiz> with that patch too
20:43 <Shiz> should be easy enough
20:43 <jirutka> yeah, that’d be perfect
20:45 <jirutka> btw I was thinking about your idea to change default linking to dynamic on Alpine… I’ve changed my mind; it’s a compiler after all, we (and even other distros) already change some default settings for gcc and clang
20:45 <Shiz> :)
20:46 <Shiz> if people want static linking, they can simply pass RUSTFLAGS='-C target-feature=+crt-static' to cargo
20:46 <Shiz> which is easy enough
20:46 <jirutka> and also our static is not “standard” as well, b/c we use PIE :)
20:46 <Shiz> (making it even better!)
20:46 <jirutka> yes
20:46 <Shiz> after the uhm
20:46 <jirutka> yes, but it’s also quite distro-specific, b/c -C target-feature is not normally allowed in stable rustc
20:46 <Shiz> musl bugfix
20:46 <* Shiz> whistles and crabwalks away
20:47 <Shiz> jirutka: one thing i want to address in my internals.r-l.org post is whether crt-static will be stabilized or not
20:47 <jirutka> well, this was the only one problem on the musl side, all others were on Rust side (or ours, libunwind…)
20:48 <Shiz> dalias was very helpful in finding the bug btw :P
20:48 <jirutka> Shiz: Alex wrote in the RFC for crt-static that it will be never stabilized, but don’t understand why…
20:48 <Shiz> no no
20:48 <Shiz> that's not what wasn't going to be stabilized
20:49 <Shiz> #[link(cfg(...))] isn't
20:49 <Shiz> but it says nothinga bout the crt-static target-feature satbilisation
20:49 <Shiz> stabilisation.
20:49 <jirutka> aha, yes, you’re right
20:49 <jirutka> I’ve read it once more time https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md
20:52 <jirutka> Shiz: will you also write some summary to https://github.com/rust-lang/rust/pull/40113 ?
20:53 <Shiz> I will write it as background, yes
21:02 <jirutka> Shiz: hm, but how rpath in rust works? I’m afraid that it will use rpath even for non-rust libs
21:02 <Shiz> i don't think it will
21:02 <Shiz> and if it does, does it matter? :P
21:03 <jirutka> well, as with other software, when the shared lib is on standard path, then rpath should not be used
21:03 <jirutka> will try that
21:06 <jirutka> Shiz: it looks okay https://hastebin.com/raw/amomekazod
21:06 <Shiz> :)
21:06 <Shiz> jirutka: i think it should only enable rpath when doing -C prefer-dynamic...
21:07 <jirutka> Shiz: yes, that would be logical… but not how it works now :/
21:07 <jirutka> Shiz: however, this should not harm, or does it?
21:08 <jirutka> Shiz: but it seems that there’s no config option in Cargo to enable rpath by default, so it will require patching it anyway, so we can also add a logic to use it by default only in combination with prefer-dynamic
21:09 <jirutka> Shiz: but not entirely sure if this should be patched in cargo or rustc
21:09 <Shiz> rustc, evidently
21:10 <jirutka> but then user would not be able to disable it, right?
21:10 <jirutka> or is there some option opposite to -C rpath?
21:11 <jirutka> btw Cargo allows to set defaults via profiles and this includes even rpath; but it seems that the default profile is hard-coded
21:11 <Shiz> hehe
21:11 <Shiz> well, i'm not sure if it's reasonable for the user to disable it
21:11 <Shiz> if it's implied by -C prefer-dynamic, it HAS to have rpath to even work at all
21:11 <Shiz> since libstd is in the rustlib folder
21:12 <jirutka> hm, right
21:12 <jirutka> and rustlibs does not have stable ABI, so it will not be usable on other system anyway
21:12 <jirutka> s/does/do/
21:13 <jirutka> well, maybe theoretically on the same version, but still, it’s quite useless
21:14 <jirutka> and actually only compiler plugins use prefer-dynamic
21:17 fekepp joined
21:19 <Shiz> jirutka: possible for you to push that patch I linked if you approve of it?
21:19 <Shiz> I want to include it in my patch overview in the internals post
21:20 <jirutka> yes, ofc, I just wanted to enable rpath by default together with that
21:20 <jirutka> I think that this https://github.com/rust-lang/rust/blob/master/src/librustc_trans/back/linker.rs#L275 may be the right place
21:20 <Shiz> hmm?
21:20 <Shiz> rpaths are not just for dylibs
21:20 <Shiz> they are for final dynamic executables too
21:21 <jirutka> eh, right
21:21 <Shiz> also this seems too low-level
21:21 <Shiz> i think you should simply check if the prefer-dynamic codegen option is set and then also set rpath
21:21 <Shiz> wherever codegen options are processed
21:23 <jirutka> yes, but the question is where to put this
21:25 <jirutka> okay, this looks like the code that really adds rpath to args https://github.com/rust-lang/rust/blob/910c4816fdee01a1299d11a5e85ebb4aceee6d1a/src/librustc_trans/back/link.rs#L985
21:26 <jirutka> hm, maybe not
21:26 <Shiz> jirutka: https://github.com/rust-lang/rust/blob/da32752d92589e99feab80921b9eecb6090cf310/src/librustc/session/config.rs#L1433
21:26 <Shiz> after here.
21:26 <Shiz> https://github.com/rust-lang/rust/blob/da32752d92589e99feab80921b9eecb6090cf310/src/librustc/session/config.rs#L1526
21:26 <Shiz> i'd put it here
21:28 <Shiz> if cg.prefer_dynamic {
21:28 <Shiz> // Force rpath addition on prefer-dynamic output.
21:28 <Shiz> cg.rpath = true;
21:28 <Shiz> }
21:29 <jirutka> okay! :)
21:37 <leitao> for the first time we have alpine running on a POWER9 machine
21:37 <leitao> # cat /etc/os-release | head -n 1
21:37 <leitao> NAME="Alpine Linux"
21:37 <leitao> # cat proc/cpuinfo | head -n 2
21:37 <leitao> processor : 0
21:37 <leitao> cpu : POWER9 (raw), altivec supported
21:39 <Shiz> leitao: good job :)
21:45 LongyanG joined
21:50 LongyanG joined
21:51 <kaniini> leitao: where can i purchase
21:51 <kaniini> :D
21:57 <Shiz> jirutka: https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085
21:57 <Shiz> here's my post
21:57 <Shiz> care reading through it to see if I'm not saying something wrong?
22:01 <jirutka> Shiz: http://tpaste.us/5vP7 ?
22:01 <jirutka> Shiz: wow, such long post!
22:01 <Shiz> :P
22:01 <Shiz> jirutka: i'd append it to the current rpath patch, but yes
22:02 <Shiz> i think all rpath changes should be in a single patch file
22:02 <jirutka> Shiz: I was thinking about it, but the current rpath patch do quite different thing
22:02 <jirutka> Shiz: it’s to link rustc and rustdoc against libs in /usr/lib/rustlib/<TARGET>/lib
22:03 <Shiz> right
22:03 <Shiz> fine then
22:03 <Shiz> just let me know the filename of the patch so I can edit in the internals.rust-lang.org post
22:03 <Shiz> :P
22:03 <jirutka> Shiz: force-rpath-on-prefer-dynamic.patch
22:04 <jirutka> Shiz: I’m still building rust, wanna verify that it really works as intended before pushing
22:04 <Shiz> :)
22:04 <Shiz> it may not directly work for cargo yet
22:05 <jirutka> Shiz: “in Windows, dynamic libraries can have their own statically linked C runtimes” … WHAT?!
22:05 <jirutka> Shiz: this sounds like quite crazy idea
22:05 <Shiz> jirutka: yep
22:05 <jirutka> Shiz: Windows really allows that?
22:05 <Shiz> yeah
22:05 <Shiz> there's a _DLLMainCRTStartup() functio that gets called for every DLL
22:05 <Shiz> that start ups that DLL's CRT runtime
22:06 <Shiz> if you're thinking "this means i can't share data between DLLs with different C runtimes"
22:06 <Shiz> you're right
22:06 <Shiz> at least, not libc-specific data like a FILE*
22:06 fekepp joined
22:11 <jirutka> wow
22:12 <jirutka> you’re also a Windows programmer?
22:13 <Shiz> no, i just know a bit about it
22:13 <Shiz> and i talked to someone in #rust-internals about it
22:13 <Shiz> :P
22:14 <jirutka> aha :)
22:15 <jirutka> your post https://internals.rust-lang.org/t/refining-cross-platform-crt-static-semantics/5085 is excellent, I’ve already read it
22:15 <Shiz> :)
22:15 <jirutka> just one note, I’d also add a note that we actually don’t use jemalloc, b/c it increases size of static binaries significantly for just a little performance gain (that may be even negative in some tests)
22:16 <jirutka> I’ve described it in https://github.com/alpinelinux/aports/commit/eadd59359eb8e801e4e15a6611b4981e6d967ad2
22:17 <jirutka> the exact numbers would be a bit different now, after some changes (probably updating llvm and also switching to llvm-libunwind), statically linked binary is even smaller (~ 168 kiB or something like that)
22:18 <jirutka> I think that jemalloc has more importance for glibc than for musl :)
22:26 <Shiz> righ, but it's a patch that's already merged anyway
22:26 <Shiz> :P
22:26 <Shiz> also: https://twitter.com/dev_console/status/852285655564550145
22:27 <Shiz> tweeted about it since it may be interesting to people tracking rust progress on alpine
22:30 <jirutka> Shiz: works great! pushed to aports
22:30 <Shiz> \o
22:52 <jirutka> Shiz: and maybe I’d also add that installing (duplicated) rust shared libs into /usr/lib is not just waste of space, but also wrong, b/c of unstable ABI etc.
22:52 <Shiz> ?
22:52 <Shiz> how do you mean
22:54 <jirutka> Shiz: as stated in commit msg https://github.com/alpinelinux/aports/commit/eadd59359eb8e801e4e15a6611b4981e6d967ad2
22:54 <jirutka> Shiz: pardon, not this one
22:55 <jirutka> Shiz: and also not a commit message, but patch :P https://github.com/alpinelinux/aports/blob/eadd59359eb8e801e4e15a6611b4981e6d967ad2/testing/rust/change-rpath-to-rustlib.patch
22:55 <Shiz> jirutka: this is fine though
22:55 <Shiz> since they are suffixed with a hash
22:55 <Shiz> that's kind of there for that reasonafaik
22:56 <jirutka> Shiz: so when you update rust-stdlib, you get probably totally different has, and so different lib and your binary linked against it is now unusable
22:56 <Shiz> sure, but that has no bearing whether it's in /usr/lib or elsewhere
22:56 <jirutka> s/has/hash/
22:57 <jirutka> hm…
22:57 <jirutka> i think that from this nature, they really should be treat as private libs
22:58 <jirutka> and as skarnet told me, such libs should not be in /usr/lib or other standard LD path
22:59 tmh1999 joined
23:39 <kaniini> i agree with that, it shouldn't be in /usr/lib
23:40 <Shiz> oh, i dont disagree
23:40 <Shiz> i think because of their overly-generic names they shouldnt be there anyway
23:40 <Shiz> it just has no bearing on wrongness from their perspective i think
23:40 <Shiz> just from ours as a distro one
23:41 <kaniini> sure
23:42 <Shiz> so that's why i didn't mention it in the post i made on their forum :P
23:48 <jirutka> Shiz: @rustlang liked https://twitter.com/jakubjirutka/status/852296489355423744 :)
23:49 <Shiz> yeah saw it
23:49 <Shiz> :p
23:49 <Shiz> also liked my orig tweet
23:49 <Shiz> maybe gotta poke ncopa to rt it on the alpine linux twitter
23:49 <Shiz> wee visibility
23:50 <jirutka> Shiz: ncopa unfortunately don’t retweet even his own tweets about Alpine :(
23:50 <jirutka> Shiz: via Alpine account
23:50 <Shiz> :P
23:57 <kaniini> i think clandmeter actually runs the twitter
23:57 <kaniini> not sure
23:59 <jirutka> IIRC it’s ncopa