2017-07-01 08:32:53 <fcolista> I'm wondering to move fail2ban from py2 to py3 : http://tpaste.us/nZbx
2017-07-01 16:12:31 <^7heo> so linux-grsec has been renamed linux-hardened?
2017-07-01 16:13:06 <_ikke_> yes, a while ago
2017-07-01 16:13:38 <^7heo> ok
2017-07-01 16:36:12 <^7heo> Alpine sure is robust
2017-07-01 16:36:18 <^7heo> I upgraded ~500 packages
2017-07-01 16:36:22 <^7heo> from maybe a year ago
2017-07-01 16:36:38 <^7heo> ended up with a no-disk-space-left
2017-07-01 16:36:51 <^7heo> rebooted
2017-07-01 16:36:58 <^7heo> (I use LUKS encryption)
2017-07-01 16:37:17 <^7heo> the system still worked enough for me to boot, decrypt my drive, and remove some big files
2017-07-01 16:37:32 <^7heo> and then I was able to reboot again after I made some room
2017-07-01 16:37:45 <^7heo> and the system looks good now.
2017-07-01 16:38:03 <^7heo> I really really like that.
2017-07-01 22:37:44 <foxkit> a test suite has failed because it was run under fakeroot
2017-07-01 22:37:58 <foxkit> the build documentation specifically says you must not be root when running the test suite
2017-07-01 22:38:02 <foxkit> how do we handle this?
2017-07-01 22:39:54 <foxkit> ah looks like "!checkroot" in options
2017-07-01 22:45:21 <Shiz> yep that
2017-07-01 22:45:25 <Shiz> recently added on my request :P
2017-07-01 23:54:00 <foxkit> libarchive fails its tests because musl /still/ doesn't support euc-jp or cp-1252
2017-07-01 23:54:07 <foxkit> I dunno what we want to do about that
2017-07-01 23:55:06 <skarnet> why does libarchive even care about encodings?
2017-07-01 23:59:20 <foxkit> it is testing its ability to unpack archives with bad encodings correctly
2017-07-01 23:59:36 <foxkit> as in "tolerant in what you accept, strict in what you provide"
2017-07-02 00:00:32 <foxkit> it only extracts utf-8 file names, but if you provide an option stating the input filename encoding, it will translate it for you
2017-07-02 00:16:55 <Shiz> disable the specific tests
2017-07-02 00:17:15 <Shiz> if not possible somehow, add a || true to make check with a comment next to it
2017-07-02 00:23:50 <^7heo> guys
2017-07-02 00:23:55 <^7heo> I'm building a new package
2017-07-02 00:24:18 <^7heo> and in the build() function, after entering the fakeroot, it complains about not being able to write to /usr/local/bin
2017-07-02 00:24:29 <^7heo> is that the expected behavior? should I change /usr/local/bin to something else?
2017-07-02 00:27:35 <foxkit> build should not be trying to write to /usr/local/bin
2017-07-02 00:27:45 <arch3y> sounds like its failing to write to the destdir which should be the fakeroot
2017-07-02 00:28:11 <foxkit> make sure DESTDIR is set correctly
2017-07-02 00:28:45 <foxkit> fakeroot is "fake being uid=0", not "fake / is somewhere else"
2017-07-02 00:29:22 <^7heo> foxkit: it's the default of $crapsoftware I'm using.
2017-07-02 00:29:27 <^7heo> foxkit: I changed it to /usr/bin
2017-07-02 00:29:34 <^7heo> foxkit: but anyway it fails...
2017-07-02 00:29:47 <foxkit> ^7heo: do you specify DESTDIR?
2017-07-02 00:29:59 <^7heo> well, I changed the prefix in ./configure
2017-07-02 00:30:09 <^7heo> but maybe DESTDIR would be better, you're right
2017-07-02 00:30:21 <arch3y> then specify DESTDIR=$pkgdir in your make install
2017-07-02 00:30:27 <arch3y> that should help
2017-07-02 00:30:42 <^7heo> ah right
2017-07-02 00:30:52 <^7heo> damn it's been some time since I wrote some APKBUILD
2017-07-02 00:31:00 <foxkit> some build systems need DESTDIR="$pkgdir" even in build()
2017-07-02 00:31:01 <^7heo> I don't know how I can have forgotten that.
2017-07-02 00:31:04 <foxkit> not just package()
2017-07-02 00:31:18 <arch3y> pkg depending ofc
2017-07-02 00:31:20 <^7heo> foxkit: yeah that's the thing here.
2017-07-02 00:31:53 <^7heo> thanks arch3y and foxkit
2017-07-02 00:31:57 <foxkit> np o/
2017-07-02 00:36:48 <Shiz> what's awos?
2017-07-02 00:38:37 <foxkit> Shiz: AWOS was my old kernel
2017-07-02 00:38:41 <foxkit> 2003-2009
2017-07-02 00:39:06 <Shiz> i seem to know a disproportionate amount of people that have written kernels
2017-07-02 00:39:08 <^7heo> AwilfoxOS I presume
2017-07-02 00:39:18 <Shiz> 
ACTION files that together with finns and trans* people

2017-07-02 00:39:20 <foxkit> tried to implement my own posix environment, writing a demand-paged SLAB allocator was just too hard.
2017-07-02 00:39:35 <foxkit> ^7heo: Advanced Workstation Operating System
2017-07-02 00:39:45 <foxkit> ^7heo: the fact it matches my initials is a happy coincidence.
2017-07-02 00:39:52 <Shiz> i'm sure
2017-07-02 00:40:16 <^7heo> :D
2017-07-02 00:41:09 <Shiz> workstations reminds me of workbench reminds me of... amiga?
2017-07-02 00:41:12 <Shiz> i think it was amiga
2017-07-02 00:41:31 <^7heo> ?
2017-07-02 00:41:47 <^7heo> Workstation is a term used daily to describe computers that people work on; or?
2017-07-02 00:43:30 <skarnet> ^7heo: if you're building a package for a distro, don't use /usr/local/bin
2017-07-02 00:43:50 <skarnet> that's basically reserved for not-distros
2017-07-02 00:43:53 <skarnet> like /opt
2017-07-02 00:43:56 <Shiz> skarnet: i think it's writing to /usr/local/bin on the *build* system
2017-07-02 00:44:05 <Shiz> so it's a case of wrong DESTDIR, among others
2017-07-02 00:44:09 <skarnet> wat
2017-07-02 00:44:37 <skarnet> there's no fakeroot for build(), is there?
2017-07-02 00:44:57 <^7heo> skarnet: it's the default in the ./configure
2017-07-02 00:45:03 <Shiz> no, only for package()
2017-07-02 00:45:06 <^7heo> skarnet: I didn't change it yet because the install failed.
2017-07-02 00:45:19 <skarnet> ^7heo: --prefix is hard
2017-07-02 00:45:35 <^7heo> especially not relevant.
2017-07-02 00:45:40 <^7heo> it's relevant once it builds.
2017-07-02 00:45:51 <^7heo> turns out the script invoked by "make install" didn't have +x...
2017-07-02 00:46:00 <^7heo> I didn't expect something that stupid.
2017-07-02 00:47:21 <skarnet> but why would you make install in build() instead of package()
2017-07-02 00:47:42 <^7heo> why would you imagine I'm doing the install in build()?
2017-07-02 00:47:44 <skarnet> generally you do "sudo make install", which is exactly what fakeroot is for, and that happens only in package()
2017-07-02 00:47:53 <^7heo> ok, so
2017-07-02 00:47:55 <^7heo> let's put it that way
2017-07-02 00:48:03 <^7heo> ./configure --prefix has to happen in build()
2017-07-02 00:48:10 <skarnet> yes
2017-07-02 00:48:13 <^7heo> exactly.
2017-07-02 00:48:36 <^7heo> now, it does *not* matter where you have your prefix set; if the package() fails.
2017-07-02 00:48:53 <^7heo> because you will *never* get to experience the effects of the wrong --prefix setting.
2017-07-02 00:49:12 <^7heo> and if the script invoked by make install doesn't have the exec rights, package() will fail.
2017-07-02 00:49:37 <^7heo> so first I had to fix that; and then I bothered to fix the actual path where the binary was located.
2017-07-02 00:49:38 <skarnet> ok... so what was that "build() is trying to write to /usr/local/bin" thing in the first place?
2017-07-02 00:49:53 <^7heo> a technically incorrect statement.
2017-07-02 00:50:04 <Shiz> he probably meant package()
2017-07-02 00:50:07 <^7heo> no.
2017-07-02 00:50:36 <^7heo> to be pedantic, I should have written: "build() is trying to set the destination of `make install` to /usr/local/bin"
2017-07-02 00:50:51 <skarnet> ... ok. that's much more reasonable :)
2017-07-02 00:50:56 <^7heo> I used "to write" instead of "to set the destination of `make install`"
2017-07-02 00:51:01 <skarnet> and explainable by a default prefix in configure
2017-07-02 00:51:05 <^7heo> yeah
2017-07-02 00:51:20 <skarnet> so now I want my 8 minutes back
2017-07-02 00:51:37 <^7heo> I'd gladly give you 10 bucks for that
2017-07-02 00:51:48 <^7heo> but unfortunately this month I'm rather... low.
2017-07-02 00:52:18 <skarnet> that's 75€/hr, I'm ok with that
2017-07-02 00:52:42 <^7heo> yeah I'd expect you to be ;)
2017-07-02 00:52:46 <skarnet> but I'll settle for you using more accurate terms next time :P
2017-07-02 00:52:51 <^7heo> thanks! :)
2017-07-02 00:53:14 <foxkit> oh good.
2017-07-02 00:53:25 <foxkit> libuv fails its test suite in different ways depending on CPU.
2017-07-02 00:54:02 <foxkit> test #179 fails on x86_64 edge, tests #183 and #275 (but not #179) fail on ppc32
2017-07-02 00:54:21 <foxkit> thanks, algitbot, for completely misinterpreting that
2017-07-02 00:54:38 <foxkit> now I know why gentoo's bot required 'bug #foo' instead of just '#foo'
2017-07-02 00:55:09 <foxkit> anyway, does libuv pass its test suite on the real alpine build cluster?  because it definitely doesn't here (can anyone with an up-to-date aports.git check on their box maybe?)
2017-07-02 00:56:48 <foxkit> it looks like `getaddrinfo_fail` may be breaking because my ISP intercepts DNS requests and will do the web ad crap on NXDOMAIN, which explains the x86_64 failure on test 179
2017-07-02 00:57:36 <skarnet> get an ISP who doesn't fudge your DNS
2017-07-02 00:57:59 <^7heo> yeah or run your DNS yourself.
2017-07-02 00:59:28 <foxkit> running DNS myself won't help
2017-07-02 00:59:38 <foxkit> I still have to forward requests to root servers, which are also intercepted
2017-07-02 01:00:11 <skarnet> that's what I was talking about
2017-07-02 01:00:31 <skarnet> your ISP is messing with your connection
2017-07-02 01:00:40 <foxkit> I am waiting (im)patiently for AT&T to offer fibre here
2017-07-02 01:00:44 <skarnet> oh, wait, of course, you're living in a 3rd world country with no net neutrality
2017-07-02 01:00:55 <foxkit> because we have actually hit a point in america where AT&T is the less-crap of the ISP options
2017-07-02 01:01:38 <foxkit> the only way I can even send email is because my current ISP is too stupid to filter IPv6
2017-07-02 01:02:00 <skarnet> get a VPS located in Canada or something, and do all your network tests there
2017-07-02 01:02:02 <foxkit> they won't let you use SMTP ports over IPv4 because "spam" (but really because they want you to use their mail service so they can read your emails and offer relevant ads)
2017-07-02 01:02:11 <foxkit> but it works quite well over v6
2017-07-02 01:02:35 <foxkit> hm actually that makes me wonder: do they intercept DNS over v6?
2017-07-02 01:02:51 <skarnet> don't worry, even if you could do SMTP from your own server it would fail on most MXes nowadays, because you'd be PBL-blacklisted
2017-07-02 01:03:04 <^7heo> < skarnet> get a VPS located in Canada or something, and do all your network tests there
2017-07-02 01:03:06 <skarnet> *including the alpinelinux.org MX*
2017-07-02 01:03:13 <foxkit> skarnet: it seems to work fine for me.
2017-07-02 01:03:14 <skarnet> no, I'm still not over that
2017-07-02 01:03:19 <^7heo> s/do all your network tests/setup a VPN server/
2017-07-02 01:03:40 <foxkit> skarnet: I mean I can't even connect to gmail over SMTP, let alone things like mail.foxkit.us.
2017-07-02 01:03:49 <foxkit> skarnet: I'm not trying to run an smtpd in my house, I'm trying to /connect/ to an smtpd from my house
2017-07-02 01:04:03 <foxkit> /outbound/ port 25/587 are filtered
2017-07-02 01:04:09 <foxkit> they only work to my ISP's mail server
2017-07-02 01:04:16 <skarnet> yes, that's what I'm talking about - even if you could, it wouldn't do you much good
2017-07-02 01:04:26 <skarnet> because your public IP would be PBL'ed
2017-07-02 01:04:32 <foxkit> skarnet: my emails seem to work fine on alpinelinux.org?
2017-07-02 01:04:40 <skarnet> sent over IPv6 ?
2017-07-02 01:04:45 <foxkit> skarnet: yes
2017-07-02 01:04:48 <skarnet> that explains
2017-07-02 01:04:51 <foxkit> skarnet: from mail.foxkit.us
2017-07-02 01:04:57 <skarnet> PBL is too dumb to list IPv6s yet
2017-07-02 01:05:20 <foxkit> skarnet: I don't think alpinelinux.org MX has IPv6 though
2017-07-02 01:05:25 <skarnet> and that reminds me I should configure my backup connection, which actually supports IPv6, and use that to send mail
2017-07-02 01:08:20 <skarnet> what do you do when some service has no IPv6? fall back on IPv4? and use your ISP's smtpd when it's mail?
2017-07-02 01:08:26 <skarnet> foxkit: ^
2017-07-02 01:12:05 <foxkit> skarnet: I think there might be a slightl misunderstanding:
2017-07-02 01:12:27 <foxkit> [my computer] => [mail.foxkit.us / mail.gmail.com / etc] needs to be IPv6, because my ISP blocks IPv4 connections to port 25/587/etc
2017-07-02 01:12:37 <foxkit> [mail.foxkit.us] => [some MX] will prefer v6, but use v4 when it can't
2017-07-02 01:13:11 <skarnet> ah, so mail.foxkit.us is your outbound server, forwarding everything coming from your home? ok.
2017-07-02 01:14:05 <skarnet> and that explains why the alpinelinux.org MX is ok with mail.foxkit.us: it's not in an end user ISP's IP list, so it's not PBL'ed.
2017-07-02 01:20:06 <foxkit> correct
2017-07-02 01:20:57 <^7heo> okay so I have submitted my aport
2017-07-02 01:29:20 <^7heo> if all goes well, alpine will soon have an accounting software.
2017-07-02 01:30:47 <kaniini> 
ACTION rejects because fuck numbers

2017-07-02 01:31:01 <foxkit> Numbers is a terrible spreadsheet, indeed
2017-07-02 01:31:04 <foxkit> but I thought it was macos only
2017-07-02 01:31:25 <foxkit> if there is an aport for Numbers, that would be significant
2017-07-02 01:33:12 <kaniini> ^7heo: merged
2017-07-02 01:33:25 <kaniini> ^7heo: how do i use this to hack banking accounts of my enemies
2017-07-02 01:33:39 <kaniini> 
ACTION wishes to alter poettering's net worth as a start

2017-07-02 01:33:59 <^7heo> kaniini: easy. get their qif files via social engineering
2017-07-02 01:34:01 <^7heo> kaniini: done ;)
2017-07-02 01:34:35 <foxkit> the fact that this thread test works on x86_64 and fails on ppc32 makes me nervous
2017-07-02 01:35:32 <^7heo> kaniini: btw, I'm not sure about the APKBUILD of the main software
2017-07-02 01:35:43 <^7heo> kaniini: so I'll submit it now but don't hesitate to be harsh about it ;)
2017-07-02 01:36:02 <kaniini> i think you want jirutka for that
2017-07-02 01:36:24 <^7heo> he's currently sleeping ;)
2017-07-02 01:37:12 <kaniini> i have to congratulate gdm on being opaque
2017-07-02 01:37:21 <kaniini> i have gdm itself working, but the user greeter is not working
2017-07-03 09:28:11 <fcolista> Do we have an example of "answerfile" for an alpine unattended installation?
2017-07-03 09:28:11 <fcolista> https://wiki.alpinelinux.org/wiki/Alpine_setup_scripts
2017-07-03 09:46:18 <ncopa> fcolista: i think you can generate an answerfile
2017-07-03 09:47:07 <fcolista> from an already-installed alpine ncopa ?
2017-07-03 10:42:29 <^7heo> who is tmpfile on ML/github?
2017-07-03 10:50:39 <ncopa> fcolista: setup-alpine -c FILE
2017-07-03 10:50:48 <fcolista> yup
2017-07-03 10:50:50 <fcolista> figured
2017-07-03 10:50:53 <fcolista> thx ncopa!
2017-07-03 11:08:39 <^7heo> I have a weird issue.
2017-07-03 11:08:55 <^7heo> I have written a new aport; it builds on my computer...
2017-07-03 11:09:11 <^7heo> but on travis, I get: sha512sum: WARNING: 1 of 1 computed checksums did NOT match
2017-07-03 11:09:35 <^7heo> I guess I'll try emptying the cache locally and re-downloading to see.
2017-07-03 11:12:17 <^7heo> So that's an issue.
2017-07-03 11:12:35 <^7heo> The remote file changed without the URL changing...
2017-07-03 11:14:37 <^7heo> how do we deal with such cases?
2017-07-03 11:17:53 <skarnet> the fact you got a warning is a good sign - this is exactly the attack the checksum is supposed to catch :P
2017-07-03 11:20:45 <^7heo> yeah
2017-07-03 11:20:59 <^7heo> now how do we deal with terrible providers that attack us?
2017-07-03 11:22:09 <^7heo> are there ways for a nobody like me (or at least having the rights of such in Alpine) to write cached content to an alpine server for use in my APKBUILD?
2017-07-03 11:34:21 <skarnet> have your local cache in your /etc/apk/repositories? I'm not sure what I'm saying is relevant because I don't fully understand your setup.
2017-07-03 11:34:47 <^7heo> skarnet: I'm not talking about the local cache
2017-07-03 11:35:44 <^7heo> skarnet: I'm asking what to do to prevent (what I will for now assume to be incompetence instead of malice) differing content from the source providers in APKBUILDs.
2017-07-03 11:36:04 <^7heo> differing over time, not between versions; where it's obviously correct to differ.
2017-07-03 11:38:16 <skarnet> fetch via HTTPS?
2017-07-03 11:38:33 <^7heo> you're assuming malice, and from another actor.
2017-07-03 11:38:46 <^7heo> I don't think it's what's happening.
2017-07-03 11:38:52 <skarnet> HTTPS doesn't only protect from malice.
2017-07-03 11:39:17 <skarnet> what do you trust here?
2017-07-03 11:39:26 <^7heo> Nothing.
2017-07-03 11:39:44 <^7heo> If anything I trust the sha512 binary
2017-07-03 11:39:46 <skarnet> if you can't trust the repo where you're downloading packages from, there's not much you can do besides curling up in a ball in a corner and cry.
2017-07-03 11:40:17 <skarnet> if you don't trust the outside world, keep a whole Alpine repository on your server.
2017-07-03 11:40:18 <^7heo> I was expecting us to already have a solution to that; since I think I remember reading we do.
2017-07-03 11:40:20 <skarnet> And never update it. :P
2017-07-03 11:40:48 <^7heo> s/that/"you can't trust the repo where you're downloading packages from"/
2017-07-03 11:40:50 <skarnet> I still don't understand what your problem is. It sounds like you want to distrust the world, and I can pretty much tell you there's no solution to that.
2017-07-03 11:41:01 <^7heo> my problem is:
2017-07-03 11:41:04 <^7heo> 1. Write APKBUILD X
2017-07-03 11:41:12 <^7heo> 2. run abuild checksum against it
2017-07-03 11:41:19 <^7heo> 3. run abuild -r
2017-07-03 11:41:22 <^7heo> 4. get package
2017-07-03 11:41:25 <^7heo> 5. wait one day
2017-07-03 11:41:31 <^7heo> 6. run abuild -r
2017-07-03 11:41:36 <^7heo> 7. get sha512 fail.
2017-07-03 11:41:43 <skarnet> aaaah.
2017-07-03 11:41:45 <^7heo> yes.
2017-07-03 11:41:57 <skarnet> send hate mail to the source maintainer.
2017-07-03 11:42:03 <^7heo> yeah that's one option.
2017-07-03 11:42:12 <skarnet> it's the only one.
2017-07-03 11:42:18 <^7heo> But I'm considering more diplomatic alternatives first.
2017-07-03 11:42:26 <skarnet> send diplomatic hate mail.
2017-07-03 11:42:30 <^7heo> ahaha
2017-07-03 11:42:37 <^7heo> Sometimes I really love you man.
2017-07-03 11:42:47 <^7heo> (honestly)
2017-07-03 11:42:59 <^7heo> your brain is pure gold :D
2017-07-03 11:43:24 <^7heo> I think one of the possibilities would also be to make a github mirror
2017-07-03 11:43:31 <skarnet> thanks. But I'm serious. This is likely a human issue: an admin changed a binary they weren't supposed to change
2017-07-03 11:43:43 <skarnet> they updated something without bumping up the version number
2017-07-03 11:43:43 <^7heo> that way I don't have to deal with a person who's brain is obviously subpar and flawed
2017-07-03 11:43:52 <^7heo> (why else would one use bazaar in the first place?)
2017-07-03 11:44:14 <skarnet> you can't fix human with tech
2017-07-03 11:44:17 <^7heo> skarnet: what I expect more is launchpad.net re-generating their tarballs in a cronjob
2017-07-03 11:44:30 <^7heo> skarnet: that way they don't have to make it happen witha hook
2017-07-03 11:44:56 <^7heo> skarnet: problems is, AFAIK, tarballs aren't reproducible
2017-07-03 11:45:14 <skarnet> they should be. If they aren't, they shouldn't re-generate them.
2017-07-03 11:45:17 <^7heo> (i.e. two tarballs contanining the same thing will be binary differently)
2017-07-03 11:45:22 <skarnet> -> hate mail to launchpad
2017-07-03 11:45:32 <^7heo> s/binary differently/different binaries/
2017-07-03 11:45:49 <^7heo> so tarballs with identical content should be identical?
2017-07-03 11:46:00 <^7heo> there's no timestamp anywhere that changes?
2017-07-03 11:46:17 <skarnet> "heya noobs, don'tcha know people are relying on tarball checksums out there, so would you kindly stop messing with them? Thanks a bunch."
2017-07-03 11:46:34 <^7heo> huhu
2017-07-03 11:46:46 <^7heo> I'm only assuming so because the checksum I see is different from day to day
2017-07-03 11:47:26 <skarnet> I guess reproducible builds are hard - but if they can't get reproducible builds they definitely shouldn't re-generate daily
2017-07-03 11:47:52 <skarnet> until they can get them, best bet is to choose one tarball and mirror it
2017-07-03 11:48:30 <^7heo> oh joy.
2017-07-03 11:48:53 <^7heo> I unpacked the two different versions with different checksums in folders called 1 and 2.
2017-07-03 11:48:57 <^7heo> $ diff -r 1 2
2017-07-03 11:49:10 <^7heo> diff: 1/.../compile: No such file or directory
2017-07-03 11:49:14 <^7heo> diff: 2/.../compile: No such file or directory
2017-07-03 11:49:19 <^7heo> ok...
2017-07-03 11:49:32 <^7heo> $ ls -l 2/.../compile
2017-07-03 11:49:35 <skarnet> dangling symlinks, nothing wrong with that
2017-07-03 11:49:52 <^7heo> lrwxrwxrwx    1 theo     theo            32 Jul  1 02:02 1/.../compile -> /usr/share/automake-1.15/compile
2017-07-03 11:49:57 <^7heo> THAT's what's wrong.
2017-07-03 11:50:02 <skarnet> shiny!
2017-07-03 11:50:17 <^7heo> Yeah.
2017-07-03 11:50:22 <^7heo> bioutifoule.
2017-07-03 11:50:28 <skarnet> are you still opposed to the idea of sending hate mail?
2017-07-03 11:50:32 <^7heo> ahahaha
2017-07-03 11:50:39 <^7heo> Less and less as I look in the project.
2017-07-03 11:51:07 <^7heo> Since the author is French I could even write it with florished language.
2017-07-03 11:51:16 <^7heo> and title it "Pardon my french"
2017-07-03 11:51:34 <^7heo> (but yeah it'd be a little too ad-hominem possibly)
2017-07-03 11:52:14 <^7heo> Ok so aside from those two symlinks: 1 and 2 are identical according to diff.
2017-07-03 11:52:28 <^7heo> (I mean, even those symlinks are identical, they just are pointing to shit)
2017-07-03 11:53:14 <skarnet> the contents are the same, and the tarballs are different? then the metadata embedded in the tarball changed
2017-07-03 11:53:28 <fcolista> jirutka, you around?
2017-07-03 11:53:30 <skarnet> not sure what metadata goes into a tarball - oh, file stamps
2017-07-03 11:53:39 <^7heo> vimdiff (which is able to read gz data) shows no difference.
2017-07-03 11:54:09 <skarnet> unpack, touch a file, repack - you'll probably get a different tarball
2017-07-03 11:54:48 <^7heo> yeah
2017-07-03 11:54:58 <skarnet> a workaround to that would be to checksum all the files in an archive instead of the tarball itself, but ugh
2017-07-03 11:55:05 <^7heo> yeah ugh.
2017-07-03 11:55:34 <skarnet> unpack archive, touch everything recursively, repack, take the checksum
2017-07-03 11:55:36 <^7heo> nah but I'm sure the launchpad.net tarball-building system is fucked up.
2017-07-03 11:55:46 <^7heo> and it's messing with the tarballs
2017-07-03 11:56:02 <^7heo> skarnet: that might work.
2017-07-03 11:56:12 <skarnet> it's heavy though
2017-07-03 11:56:13 <^7heo> skarnet: but the checksum is performed BEFORE extraction.
2017-07-03 11:56:35 <skarnet> yeah, and there's good reason for that too :/
2017-07-03 11:56:52 <^7heo> skarnet: also obviously, if I touch everything, I shall set a pre-configured time.
2017-07-03 11:57:07 <^7heo> skarnet: otherwise it won't change squat.
2017-07-03 11:57:11 <skarnet> indeed
2017-07-03 11:57:45 <^7heo> yeah so I might just try the diplomatic option first.
2017-07-03 11:58:03 <skarnet> that would be the real solution, yes
2017-07-03 11:58:37 <^7heo> write mail to author "We are experiencing technical problems with launchpad.net. Would you please be so kind to move your work to another hoster? Github, gitlab, there are multiple options. Thanks!"
2017-07-03 11:58:54 <^7heo> and get an answer "fuck you, I love bazaar; I hate git!"
2017-07-03 11:59:07 <skarnet> still a workaround: other people will still use launchpad
2017-07-03 11:59:12 <skarnet> you need to get launchpad to fix their shit
2017-07-03 11:59:23 <^7heo> ah yeah that.
2017-07-03 11:59:30 <^7heo> Getting ubuntu to fix something...
2017-07-03 11:59:37 <^7heo> Isn't that famous last words?
2017-07-03 12:00:42 <skarnet> we're outside of problem-solving now, so my competence and willingness to spend time on this stop here :P
2017-07-03 12:00:58 <^7heo> Right.
2017-07-03 12:01:00 <^7heo> Thanks for your help so far,.
2017-07-03 12:01:18 <^7heo> I'll try to write a nice mail to launchpad.
2017-07-03 13:51:32 <tdtrask> ^7heo: we've run into this problem before where tarball files are generated on the fly and binary different due to timestamp
2017-07-03 13:51:38 <tdtrask> that's what http://dev.alpinelinux.org/archive/ is for
2017-07-03 13:52:11 <tdtrask> you must have your key on the box to push
2017-07-03 13:54:10 <tdtrask> so, ask a dev for help
2017-07-03 13:55:07 <^7heo> < tdtrask> you must have your key on the box to push
2017-07-03 13:55:11 <^7heo>  tdtrask> so, ask a dev for help
2017-07-03 13:55:39 <^7heo> < ^7heo> are there ways for a nobody like me (or at least having the rights of such in Alpine) to write cached content to an alpine server for use in my APKBUILD?
2017-07-03 13:55:48 <^7heo> if I may, lemme add emphasis
2017-07-03 13:56:01 <^7heo> < ^7heo> are there ways for a nobody like me (or at least having the rights of such in Alpine) to write cached content to an alpine server for use in my APKBUILD?
2017-07-03 13:56:32 <^7heo> I.e. I'm aware of http://dev.alpinelinux.org/archive/ but as you precisely said: "you must have your key on the box to push"
2017-07-03 13:56:40 <tdtrask> no, not that I'm aware of
2017-07-03 13:57:03 <^7heo> Damn
2017-07-03 13:57:19 <^7heo> thanks tho; I'll stay around in case ncopa or fabled have an idea about that.
2017-07-03 13:57:28 <^7heo> another way would be to get upstream to fix their tarball
2017-07-03 13:59:57 <armin> hi. i would like to add some kind of help to the setup-acf script as it doesn't seem to have -h, --help, a man page, or some meaningful comment header, and, when called, does changes to your system configuration. is this the right place to ask how to contribute?
2017-07-03 14:01:24 <tdtrask> armin: https://git.alpinelinux.org/cgit/alpine-conf/tree/
2017-07-03 14:01:33 <tdtrask> clone the repo, make changes, submit patches
2017-07-03 14:02:57 <tdtrask> armin: https://wiki.alpinelinux.org/wiki/Development_using_git
2017-07-03 14:06:11 <armin> tdtrask: great. thank you.
2017-07-03 14:08:01 <tdtrask> yw
2017-07-03 15:15:22 <martell> Hey all, I'm trying to get support upstream for LLVM for alpine before the 5.0 branch.
2017-07-03 15:16:02 <martell> I'm currently looking at the llvm patches for alpine but have a few questions, who do I direct them at?
2017-07-03 15:17:15 <skarnet> Shiz
2017-07-03 15:19:31 <martell> Thanks skarnet
2017-07-03 15:20:39 <martell> Shiz: I'm currently looking at clang-0004-Add-musl-targets.patch which tries to override the default triple for the clib location for x86.
2017-07-03 15:21:29 <martell> For i686 alpine uses /lib/ld-musl-i386.so.1
2017-07-03 15:22:19 <martell> Clang will only support the triple i386-pc-linux-musl for this and not i686-pc-linux-musl
2017-07-03 15:22:33 <martell> Which translates as /lib/ld-musl-i686.so.1
2017-07-03 15:23:58 <martell> Would it be possible to write a symlink in the musl package for this instead?
2017-07-03 15:25:11 <martell> I am also not sure why this is done for powerpc also because that already is the default, code seems redundant.
2017-07-03 15:26:02 <martell> The last question I have relates to the rest of the content. alpine doesn't need to support musl for freebsd targets does it?
2017-07-03 15:49:54 <Shiz> martell: hi
2017-07-03 15:50:14 <Shiz> let me check
2017-07-03 15:50:20 <Shiz> martell: are you using the patches in my branch or?
2017-07-03 15:56:56 <martell> Shiz hi :) https://git.alpinelinux.org/cgit/aports/tree/main/clang/clang-0004-Add-musl-targets.patch?h=3.6-stable
2017-07-03 15:57:03 <Shiz> ah, stable
2017-07-03 15:57:12 <Shiz> i was just curious since my branch has even more patches
2017-07-03 15:57:13 <Shiz> :P
2017-07-03 15:57:29 <martell> Well I updated them to HEAD, and stripped unecessacry stuff.
2017-07-03 15:57:43 <martell> *unnecessary
2017-07-03 15:57:49 <martell> Where is your branch?
2017-07-03 15:58:18 <Shiz> https://github.com/Shizmob/aports/tree/system-llvm-elftoolchain
2017-07-03 15:58:26 <Shiz> but that's patches to make it work as the system compiler
2017-07-03 15:58:33 <Shiz> including a bunch of backported git patches
2017-07-03 15:58:38 <Shiz> and some patches i already upstreamed
2017-07-03 15:59:37 <martell> I can already link and use lld directly, I did have a question however
2017-07-03 16:00:10 <martell> crtbegin and crtend is part of the gcc package
2017-07-03 16:00:13 <Shiz> i think a symlink would be a decent approach
2017-07-03 16:00:25 <Shiz> martell: it's part of libgcc
2017-07-03 16:00:34 <Shiz> llvm compiler-rt doesn't support crtbegin/crtend
2017-07-03 16:00:39 <martell> can we just use cru from freebsd for crtbegin and crtend and have libgcc depend on that package
2017-07-03 16:00:40 <Shiz> in my branch i added substitutes
2017-07-03 16:00:47 <Shiz> we already have our own
2017-07-03 16:00:49 <Shiz> :)
2017-07-03 16:01:03 <Shiz> https://github.com/Shizmob/aports/tree/system-llvm-elftoolchain/main/compiler-rt
2017-07-03 16:01:06 <martell> http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/csu/common_elf/Attic/
2017-07-03 16:01:17 <Shiz> all the csu stuff from the bsds is too big and unnecessary
2017-07-03 16:01:21 <Shiz> modern toolchains don't need all of that
2017-07-03 16:01:31 <martell> ahh
2017-07-03 16:01:37 <Shiz> the crt{begin,end}.c in the branch above have all you need to bootstrap alpine itself at least
2017-07-03 16:01:43 <Shiz> i haven't found anything yet that breaks
2017-07-03 16:01:50 <martell> Okay this makes sense
2017-07-03 16:02:12 <Shiz> sadly LLVM has chosen to make lld emit __dso_handle automatically now
2017-07-03 16:02:14 <Shiz> which is the wrong approach
2017-07-03 16:02:17 <martell> So did you remove them from the gcc package and then have them in there own package?
2017-07-03 16:02:24 <martell> libgcc*
2017-07-03 16:02:27 <Shiz> since it breaks if you use compiler-rt and not lld
2017-07-03 16:02:37 <Shiz> no, I consider crtbegin/crtend part of the compiler runtime libraries
2017-07-03 16:02:45 <Shiz> so libgcc provides them, but compiler-rt does as well
2017-07-03 16:02:58 <martell> okay so you can't have both packages installed at the same time?
2017-07-03 16:02:58 <Shiz> if you want a more pure LLVM system, you'd install compiler-rt :)
2017-07-03 16:03:03 <martell> True
2017-07-03 16:03:04 <Shiz> you can, they install to different dirs afaik
2017-07-03 16:03:24 <Shiz> "mv "$builddir"/build/crt*.o usr/lib/clang/$pkgver"
2017-07-03 16:03:26 <Shiz> right
2017-07-03 16:03:30 <Shiz> gcc's one installs to /usr/lib/gcc/whatever
2017-07-03 16:03:40 <martell> Okay cool
2017-07-03 16:03:42 <martell> :)
2017-07-03 16:03:52 <martell> What about the path of libcompiler-rt
2017-07-03 16:04:03 <martell> Did you solve that problem?
2017-07-03 16:04:24 <Shiz> what problem specifically?
2017-07-03 16:04:33 <martell> I am currently doing this
2017-07-03 16:04:34 <martell> ln -s /usr/lib/clang/4.0.0/libclang_rt.builtins-x86_64.a /usr/lib/clang/4.0.0/lib/linux/libclang_rt.builtins-x86_64.a
2017-07-03 16:04:59 <Shiz> i fixed that in my branch i think
2017-07-03 16:04:59 <martell> because lld searches in /usr/lib/clang/4.0.0/lib/linux/ and not /usr/lib/clang/4.0.0/
2017-07-03 16:05:20 <Shiz> https://github.com/Shizmob/aports/blob/system-llvm-elftoolchain/main/compiler-rt/APKBUILD#L80
2017-07-03 16:05:22 <Shiz> :)
2017-07-03 16:07:37 <Shiz> gotta run for a tiny bit, i;ll be back later
2017-07-03 16:07:42 <Shiz> don't be afraid to leave any questions here
2017-07-03 16:07:44 <Shiz> :P
2017-07-03 16:13:50 <martell> hmm okay :)
2017-07-03 16:14:32 <martell> looks like a good patch for this
2017-07-03 16:14:48 <martell> Shiz: when will this land upstream?
2017-07-03 16:15:05 <martell> upstream being alpine official packages
2017-07-03 16:17:31 <martell> What does this do exactly? compiler-rt/fix-cross-compile.patch
2017-07-03 16:17:42 <martell> Something that can be upstreamed?
2017-07-03 16:23:04 <martell> Shiz: have you tried bootstrapping the kernel with clang compiler-rt and lld on HEAD btw?
2017-07-03 16:23:22 <martell> Something we should probably do before the 5.0 branch
2017-07-03 17:07:57 <skarnet> jlyo: props for your investigation work on s6-rc-compile. I've never really used the debugging options you've mentioned in #7386. :)
2017-07-03 17:09:04 <skarnet> now I kinda want to stick foxkit on the case, or anyone else who masters asm - that's really not my specialty
2017-07-03 17:10:42 <skarnet> ncopa, fabled, kaniini: do you have an estimation of the size gained by -Os vs. -O2 on Alpine on the whole? if -Os doesn't work, what would it cost to switch to -O2?
2017-07-03 17:13:02 <kaniini> sigh i said it was -Os a month ago and nobody cared
2017-07-03 17:13:48 <ncopa> can we fix Os?
2017-07-03 17:13:48 <jlyo> skarnet: Hey, thanks, I'm wondering if I should check out IDA pro, or the like. I'd like to see a good asm diff.
2017-07-03 17:14:01 <kaniini> however
2017-07-03 17:14:13 <kaniini> your code is wrong if it depends on implicit conversions
2017-07-03 17:14:47 <skarnet> why so? it will *never* reach 2^32.
2017-07-03 17:15:13 <skarnet> jlyo: try godbolt.org?
2017-07-03 17:16:01 <jlyo> Oooh, this looks interesting.
2017-07-03 17:16:06 <kaniini> for somebody who says you should learn C to know how the real machine works you're saying nonsense right now
2017-07-03 17:17:24 <skarnet> kaniini: I use uint32_t wherever it's important and unsigned int where it's not. What's wrong with that?
2017-07-03 17:17:49 <kaniini> yes the unsafe optimization could be disabled but he should also fix his code
2017-07-03 17:17:51 <kaniini> if you want uint32_t you need to stick with uint32_t
2017-07-03 17:18:15 <kaniini> it's packed differently by the compiler (top 32 bits aren't cleared) when you copy from uint32 to a 64 bit type
2017-07-03 17:18:26 <martell> Sorry ncopa I missed your pong on the musl channel :)
2017-07-03 17:18:55 <ncopa> np :)
2017-07-03 17:19:19 <martell> Might need your opinion on adding a symlink for musl x86
2017-07-03 17:19:19 <skarnet> kaniini: I have a lot of size_t (obtained by strlen() or the like) that fit in 32 bit. I use unsigned ints to store them. At the end, when they must be packed, I explicitly convert them to uint32_t.
2017-07-03 17:19:36 <ncopa> skarnet: i'd like to upgrade gcc to 7
2017-07-03 17:19:41 <ncopa> maybe its fixed there?
2017-07-03 17:19:53 <martell> ncopa: https://git.alpinelinux.org/cgit/aports/tree/main/clang/clang-0004-Add-musl-targets.patch?h=3.6-stable#n55
2017-07-03 17:20:05 <skarnet> kaniini: all the implicit conversions I'm using are defined, documented C behaviour. I still don't understand what I'm supposed to be doing wrong.
2017-07-03 17:20:10 <martell> can we use a symlink in the musl package instead of patching clang here?
2017-07-03 17:20:47 <skarnet> ncopa: maybe? now that I know how to reproduce, I'll see if gcc-7.1.0 -Os still breaks
2017-07-03 17:20:53 <skarnet> I'll keep you informed
2017-07-03 17:20:59 <kaniini> skarnet: mixing uint32 with wider types is dangerous unless you do explicit casts each time
2017-07-03 17:21:04 <ncopa> you have reproducer? thats great
2017-07-03 17:21:08 <kaniini> so if you have
2017-07-03 17:21:15 <martell> seems there is already one for a different name ncopa https://pkgs.alpinelinux.org/contents?branch=v3.6&name=musl&arch=x86&repo=main
2017-07-03 17:21:20 <kaniini> int64 foo = 1;
2017-07-03 17:21:42 <kaniini> int32 bar = foo;
2017-07-03 17:21:45 <martell> If I do a PR for /lib/ld-musl-i686.so.1 is that okay? :D
2017-07-03 17:22:11 <kaniini> that is safe
2017-07-03 17:22:14 <kaniini> but if you have reverse
2017-07-03 17:22:15 <kaniini> then the top bits may not be truncated
2017-07-03 17:22:16 <kaniini> it's not a compiler bug
2017-07-03 17:23:13 <kaniini> guess what happens if top bits aren't truncated btw
2017-07-03 17:23:24 <kaniini> it means calls to fortify can fail
2017-07-03 17:23:28 <skarnet> uint32_t foo = 1 ; uint64_t bar = foo ; -> bar might be n*2^32 + foo with n!=0. Is that what you're saying?
2017-07-03 17:23:33 <kaniini> raising SIGILL
2017-07-03 17:23:49 <kaniini> to prove this instead of compiling -O2
2017-07-03 17:23:56 <kaniini> compile with fortify disabled
2017-07-03 17:24:01 <kaniini> no
2017-07-03 17:24:04 <kaniini> i am saying
2017-07-03 17:24:06 <ncopa> martell: is your ld-musl-*.so.1 named ld-musl-i686.so.1?
2017-07-03 17:24:16 <kaniini> actually yes
2017-07-03 17:24:27 <kaniini> because only the bottom 32 bits get cleared
2017-07-03 17:24:36 <kaniini> as part of the copy
2017-07-03 17:24:41 <jlyo> I haven't been seeing many SIGILLs whith this bug, mostly SEGVs when writing out the compiled directory.
2017-07-03 17:24:55 <skarnet> kaniini: I will check this in the C spec, because this sounds very fishy
2017-07-03 17:25:47 <kaniini> build it without fortify
2017-07-03 17:25:50 <martell> ncopa no it is /lib/ld-musl-i386.so.1 but the triple is i686-musl not i386-musl so clang will look for /lib/ld-musl-i686.so.1.
2017-07-03 17:25:50 <kaniini> i bet you it will work
2017-07-03 17:25:57 <kaniini> $100
2017-07-03 17:27:15 <kaniini> skarnet: the C spec is more permissive than a compiler building with -Os
2017-07-03 17:27:41 <kaniini> however all type conversions technically invoke UB
2017-07-03 17:28:01 <skarnet> now you're being gratuitously nihilistic
2017-07-03 17:28:02 <martell> ncopa: the patch clang-0004-Add-musl-targets.patch currently overrides this in clang will also do that for other targets which is not what we want :)
2017-07-03 17:28:41 <kaniini> that's literally from the spec my friend
2017-07-03 17:29:28 <ncopa> martell: so the patch is incorrect?
2017-07-03 17:29:51 <ncopa> i need to go now, could you please file a bug on bugs.a.o with the details
2017-07-03 17:29:58 <ncopa> i want fix it
2017-07-03 17:31:47 <kaniini> anyway
2017-07-03 17:32:08 <kaniini> skarnet: you should be using size_t for everything instead of uint32_t
2017-07-03 17:32:18 <kaniini> if it involves stuff coming from strlen and friends
2017-07-03 17:32:30 <skarnet> at the risk of repeating myself: everything fits into 32 bits.
2017-07-03 17:32:59 <skarnet> I have a _guarantee_ that it will _never_ go above 2^32.
2017-07-03 17:33:09 <martell> ncopa: the patch is correct for what we want but it just blindly applies it so we will have problems using clang from alpine for cross compiling to another target.
2017-07-03 17:33:19 <skarnet> and I'm not much into filling memory with 0s just for the fun of it.
2017-07-03 17:33:33 <kaniini> doesn't matter
2017-07-03 17:33:44 <kaniini> it doesn't fucking matter skarnet
2017-07-03 17:33:55 <kaniini> the width of the value is irrelevant
2017-07-03 17:34:13 <kaniini> you're invoking UB by converting size_t
2017-07-03 17:34:47 <skarnet> please point me to the paragraph of the spec that says so
2017-07-03 17:35:05 <kaniini> welp i see we will be using openrc for the foreseeable future because it is not acceptable to have demoscene views with our init system
2017-07-03 17:35:18 <skarnet> because if "unsigned int n = strlen("blah") ;" invokes UB, then I'm definitely not the only one invoking UB
2017-07-03 17:35:45 <skarnet> and you can bet your ass that OpenRC invokes UB much, MUCH more than s6 does :P
2017-07-03 17:36:19 <skarnet> you're the only one talking about demoscene here. I'm talking about explicitly defined and documented C behaviour
2017-07-03 17:36:48 <kaniini> at least they shut the fuck up and fix it
2017-07-03 17:37:10 <skarnet> you have no idea how fast I fix my code when someone makes a bug report
2017-07-03 17:37:27 <skarnet> you still haven't made the first step of doing a bug report. You still haven't told me what I'm doing wrong.
2017-07-03 17:37:55 <kaniini> this conversation is a bug
2017-07-03 17:38:04 <skarnet> I'm currently browsing the C spec and it would go much faster if I knew what I'm looking for
2017-07-03 17:38:07 <kaniini> you cannot
2017-07-03 17:38:38 <kaniini> initialize a size_t (64 bits) with a 32 bits value
2017-07-03 17:38:39 <kaniini> only constants
2017-07-03 17:38:51 <kaniini> if you do
2017-07-03 17:39:07 <jlyo> https://stackoverflow.com/questions/19273658/integer-conversionsnarrowing-widening-undefined-behaviour
2017-07-03 17:39:09 <kaniini> size_t foo = 0;
2017-07-03 17:39:12 <kaniini> foo = bar;
2017-07-03 17:39:17 <kaniini> that would likely be safe
2017-07-03 17:41:00 <kaniini> anyway i grow tired of this conversation and will just block s6 until it's audited by a security firm
2017-07-03 17:41:15 <kaniini> 
ACTION thumbs up

2017-07-03 17:41:17 <skarnet> yeah yeah
2017-07-03 17:41:45 <skarnet> tell me when every package used in Alpine is of the same quality of s6
2017-07-03 17:41:48 <skarnet> starting with busybox
2017-07-03 17:42:19 <skarnet> have you looked at the bb init code? hint: don't do it if you want to avoid a stroke
2017-07-03 17:43:09 <skarnet> so, we'll talk when you've dropped the tough guy attitude, because I'm not interested in that either
2017-07-03 17:49:58 <jlyo> I think the s6-rc code is correct for databases < 4GB, my best guess is that -Os is eliminating a variable initialization that it shouldn't, but doesn't eliminate it when instrumented with ubsan or explicitly bounds checking the narrowing conversion.
2017-07-03 17:50:19 <kaniini> guess we will just stick with openrc then
2017-07-03 17:52:04 <jlyo> although if that were true, I'd expect valgrind to catch it.
2017-07-03 17:55:32 <jlyo> actually, valgrind does report an unitialized value.
2017-07-03 17:58:26 <skarnet> jlyo: where? can you bpaste your valgrind report?
2017-07-03 17:59:21 <kaniini> hmm who knew
2017-07-03 17:59:21 <kaniini> in an attempt to aggressively optimize he did something stupid
2017-07-03 18:00:45 <skarnet> kaniini: did your dog die today or something? you're obviously angry and that has nothing to do with me, so I'll kindly ask you to find another punching-ball, because I don't have a victim mentality
2017-07-03 18:01:17 <jlyo> skarnet: Here you go https://dpaste.de/PFGm/raw something in serviceblob
2017-07-03 18:01:55 <skarnet> jlyo: thanks, I'll check what's up.
2017-07-03 18:02:26 <jlyo> So maybe code is getting eliminated in the first loop of resolve_services.
2017-07-03 18:05:34 <kaniini> nope i just get angry when exposed to charlatans
2017-07-03 18:09:25 <skarnet> and I get angry when exposed to dumb executives who can't tell a charlatan from a damn good engineer. So make sure you're not one of those.
2017-07-03 18:17:08 <kaniini> > code crashes on a tool chain configured to crash on many UB cases
2017-07-03 18:17:12 <kaniini> > it's the toolchains fault
2017-07-03 18:17:26 <kaniini> let's "fix" the toolchain to make it highlight less security bugs brilliant
2017-07-03 18:18:17 <skarnet> did you read the part where UBSan never trapped on my code?
2017-07-03 18:19:22 <ncopa> kaniini and skarnet please cool it
2017-07-03 18:19:34 <ncopa> we have had issues in busybox and we have fixed them as they show up
2017-07-03 18:19:43 <ncopa> i think we can do the same with s6
2017-07-03 18:21:10 <ncopa> and i know skarnet well enough to trust that s6 code is not all garbage
2017-07-03 18:22:13 <skarnet> that's exactly what I was doing with jlyo - narrowing down the problem to find the real cause - until kaniini showed up and went all tough guy on me without even knowing what it's about
2017-07-03 18:23:04 <kaniini> no i do know what it's about
2017-07-03 18:23:20 <kaniini> it's about you shitting all over alpine toolchain for months elsewhere
2017-07-03 18:23:28 <kaniini> despite it doing its job as designed
2017-07-03 18:24:00 <skarnet> ah, that's what you didn't like
2017-07-03 18:24:08 <ncopa> well, it could have been the toolchain. those issues are non-trivial
2017-07-03 18:24:18 <skarnet> well what do you expect when it's the ONLY place where my stuff breaks
2017-07-03 18:24:44 <skarnet> sometimes OpenBSD breaks my stuff, too, and 9/10 of the time it's their fault
2017-07-03 18:24:56 <skarnet> (and the 10th time they found a genuine bug)
2017-07-03 18:25:12 <ncopa> but im glad we all are on same page. find *exactly* whats broke and fix that
2017-07-03 18:25:43 <kaniini> i expect you to fix your code
2017-07-03 18:25:59 <ncopa> im not gonna switch to -O2 withouth first fixing -Os (if its broke - which i dont think it is)
2017-07-03 18:26:17 <Shiz> jesus lord
2017-07-03 18:26:22 <Shiz> i leave for a few hours and this happens
2017-07-03 18:26:25 <skarnet> fixing my code is exactly what I will do once I know there's a problem with it, so get off my back yesterday
2017-07-03 18:27:08 <ncopa> skarnet: i never doubted you would fix it - if its broke. lets move on
2017-07-03 18:28:26 <ncopa> skarnet: did you try build it without fortify?
2017-07-03 18:29:37 <skarnet> everything is on #7386, and jlyo found it's -Os triggering something. Now I'm trying to isolate a minimal case.
2017-07-03 18:30:26 <ncopa> ah, perfect. yes bugs.a.o is better place to follow up this
2017-07-03 18:30:37 <ncopa> thanks for working on it
2017-07-03 18:30:43 <kaniini> IT IS NOT A TOOLCHAIN ISSUE
2017-07-03 18:31:09 <ncopa> should probably change the subject then
2017-07-03 18:31:32 <skarnet> kaniini: I heard you. I'm trying to understand what I'm doing wrong and where, if I'm doing something wrong.
2017-07-03 18:31:45 <kaniini> fuck it, i am auditing this thing right now
2017-07-03 18:32:21 <skarnet> You are biased, I don't trust your process.
2017-07-03 18:32:34 <kaniini> i will just fix it for you, we have spent too long arguing on this
2017-07-03 18:32:53 <skarnet> I AM FIXING IT RIGHT NOW, do I also have to yell for you to understand?
2017-07-03 18:38:13 <kaniini> skarnet: so have you finally built with fortify disabled like i asked earlier?  jlyo i guess built it with -O2 instead of -Os like i asked literally back in May
2017-07-03 18:38:43 <kaniini> 
ACTION awaits the "blah blah blah alpine toolchain is garbage" answer instead of an actual answer

2017-07-03 18:40:22 <skarnet> will do, if you give me some time.
2017-07-03 18:41:28 <kaniini> okay
2017-07-03 18:41:59 <ncopa> \o/ i finally figured out why cups-filters fails
2017-07-03 18:42:05 <ncopa> error message is misleading
2017-07-03 18:42:17 <ncopa> filter/braille/filters/liblouis1.defs.gen > filter/braille/filters/liblouis1.defs
2017-07-03 18:42:17 <ncopa>  /bin/ash: filter/braille/filters/liblouis1.defs.gen: not found
2017-07-03 18:42:28 <ncopa> i was convinced it was a parallel build issue
2017-07-03 18:43:05 <ncopa> but its #!/bin/bash
2017-07-03 18:43:09 <ncopa> and bash not installed
2017-07-03 18:43:21 <kaniini> skarnet: it looks to me that jlyo already gave you a patch fixing it
2017-07-03 18:44:08 <kaniini> why don't you just apply it
2017-07-03 18:45:21 <skarnet> because it's invasive and was designed to test the "what happens if everything is 64 bit" case, not to fix the issue, that still needs to be pinpointed
2017-07-03 18:46:15 <kaniini> why does it matter
2017-07-03 18:46:18 <kaniini> congrats: you saved 200 bytes
2017-07-03 18:46:54 <kaniini> stop trying to do demoscene shit
2017-07-03 18:47:03 <kaniini> and just do straightforward approach
2017-07-03 18:47:36 <kaniini> that stuff really bugs me about DJB fans, they all want to do demoscene shit when they write code
2017-07-03 18:48:10 <ncopa> hey... i did demoscene stuff when i was a kid...
2017-07-03 18:48:50 <skarnet> for the record: this is not about saving 200 bytes, it's about understanding exactly what is incorrect in my conversions
2017-07-03 18:49:29 <skarnet> also for the record: I just tested the "uint32_t a = 1 ; uint64_t b = a ;" thing while previously filling up the stack with 0xff
2017-07-03 18:49:36 <kaniini> ncopa: demoscene stuff is fine, but there's a time and a place damnit
2017-07-03 18:49:36 <skarnet> and b is 1, all the time
2017-07-03 18:49:39 <skarnet> even with -Os
2017-07-03 18:49:54 <kaniini> skarnet: that's too simple
2017-07-03 18:50:03 <kaniini> skarnet: a gets folded into a constant
2017-07-03 18:50:23 <skarnet> ok, I'll use a random 32 bit value
2017-07-03 18:51:44 <kaniini> i know it is possible to wind up with truncation
2017-07-03 18:51:54 <kaniini> because i have seen it before
2017-07-03 18:52:55 <kaniini> but that may be because of uninitialised value which you depend on to be 0 and turns out it's really 0xf00000000000 when uint64_t
2017-07-03 18:58:40 <skarnet> same results when a is randomly generated. I'll now reboot (because new VMWare version) and do the rest of the tests on Alpine.
2017-07-03 19:03:50 <kaniini> s6-rc/s6-rc-compile.c:      strerr_warnt7x("dependency from ", name, " to ", data.s + *p, " (", fmt, ")") ;
2017-07-03 19:03:54 <kaniini> this looks suspect
2017-07-03 19:05:34 <kaniini> but that's verbosity >= 4
2017-07-03 19:05:34 <kaniini> so
2017-07-03 19:05:59 <skarnet> why does this look suspect?
2017-07-03 19:08:33 <kaniini> skarnet: it's pointer arithmetic, for one
2017-07-03 19:08:42 <kaniini> skarnet: but it's not the problem
2017-07-03 19:08:53 <kaniini> skarnet: where is 'satmp' declared
2017-07-03 19:09:36 <skarnet> satmp is a global defined in skalibs. It's just a shortcut, another stralloc could be used instead.
2017-07-03 19:10:00 <skarnet> also, yes, pointer arithmetic, because everything is stored as indices pointing into the same string.
2017-07-03 19:10:23 <skarnet> so, to get to a string, you take the address of the string plus the index.
2017-07-03 19:10:36 <kaniini> 
ACTION makes a note to stab skarnet for magic globals later

2017-07-03 19:10:51 <skarnet> yeah, I'll give you that, magic globals are ugly
2017-07-03 19:10:53 <kaniini> that makes you a terrible person and you should feel bad
2017-07-03 19:10:59 <skarnet> I am feeling bad
2017-07-03 19:11:11 <skarnet> but I am also writing less code
2017-07-03 19:11:28 <skarnet> (tbh satmp doesn't save much, I could do away with it)
2017-07-03 19:12:10 <kaniini> the reason why i am looking there
2017-07-03 19:12:15 <kaniini> is because:
2017-07-03 19:12:39 <kaniini> Enabling unaligned access traps with asm("pushf\norl $0x40000,(%rsp)\npopf"); s6-rc-compile crashes early on in memcpy() from a call to strerr_warn...().
2017-07-03 19:13:23 <kaniini> so i am thinking it's a fortify violation
2017-07-03 19:13:26 <kaniini> on an invalid input to your various warn functions
2017-07-03 19:13:31 <kaniini> of which you seem to have a shitload
2017-07-03 19:13:31 <kaniini> :p
2017-07-03 19:13:33 <skarnet> I think it could be any place where strerr_warn gets a name
2017-07-03 19:13:43 <kaniini> right, exactly
2017-07-03 19:14:01 <kaniini> name/data.s + *p, for example, would be 2 names
2017-07-03 19:14:03 <skarnet> because at some point computing a name (or kname) index fails
2017-07-03 19:14:06 <kaniini> which is why that looked interesting to me
2017-07-03 19:14:27 <kaniini> where's the part that does the plasma effect
2017-07-03 19:14:28 <kaniini> ;)
2017-07-03 19:14:44 <skarnet> it's a char * plus an unsigned int
2017-07-03 19:16:44 <kaniini> that should be safe.  in theory, ptrdiff_t is same size as size_t, though.
2017-07-03 19:17:17 <skarnet> yes. ptrdiff_t is signed though, and I never used signed stuff, only beginning + index
2017-07-03 19:17:26 <kaniini> which means the compiler might take the unsigned int as a 64-bits int without widening it
2017-07-03 19:17:53 <kaniini> sure
2017-07-03 19:18:14 <kaniini> jlyo: what was the valgrind warning you were getting
2017-07-03 19:18:28 <skarnet> I'm investigating that
2017-07-03 19:30:20 <jlyo> kaniini: That's a read of an uninitialized value from servicesblob.
2017-07-03 19:30:48 <kaniini> do you happen to have the exact output
2017-07-03 19:30:52 <kaniini> of valgrind ?
2017-07-03 19:31:15 <skarnet> https://dpaste.de/PFGm/raw
2017-07-03 19:31:15 <jlyo> yeah, I pasted it.
2017-07-03 19:31:51 <kaniini> well
2017-07-03 19:31:59 <kaniini> first of all
2017-07-03 19:32:39 <kaniini> servicesblob is a VLA ;/
2017-07-03 19:32:55 <skarnet> yes.
2017-07-03 19:34:07 <kaniini> what happens if you add a memset(servicesblob, 0, sizeof(s6rc_service_t) * n); there
2017-07-03 19:34:55 <skarnet> I don't do defensive programming, and I would appreciate if you let me debug this
2017-07-03 19:35:49 <kaniini> who said
2017-07-03 19:35:55 <kaniini> it was to be defensive
2017-07-03 19:36:21 <kaniini> it is just a test, to see if that solves the problem
2017-07-03 19:37:07 <skarnet> I will try, now could you please do something else? like, anything else?
2017-07-03 19:38:01 <kaniini> nah i think i will continue doing this
2017-07-03 19:38:13 <jlyo> kaniini, skarnet. zeroing it seems to work.
2017-07-03 19:38:23 <skarnet> not surprised
2017-07-03 19:38:26 <kaniini> okay
2017-07-03 19:38:34 <kaniini> so that means that uninitialized value
2017-07-03 19:38:38 <kaniini> is the cause
2017-07-03 19:40:36 <skarnet> so, since I hate having people breathing down my neck when I'm working, and bullying me into doing things at their own pace, I'll just leave you to this. You can send me a bug-report when you've found the cause, if you find it before I do (which is likely since you seem hell-bent on having a bigger penis than mine today). Have fun.
2017-07-03 19:41:11 <kaniini> okay i will be sure to apply for a CVE too
2017-07-03 19:41:19 <_ikke_> skarnet left btw
2017-07-03 19:41:35 <Shiz> is there any reason to continue being a dick about it
2017-07-03 19:41:36 <Shiz> for christ sake
2017-07-03 19:44:48 <kaniini> Shiz: i take security bugs in software that people wish to jam down my throat in 12-18 months seriously
2017-07-03 19:45:47 <Shiz> i on the other side don't take extremely overblown statements seriously
2017-07-03 19:47:35 <kaniini> in fact, alpine being a security-oriented distribution should have the most secure init system
2017-07-03 19:48:11 <Shiz> /dev/null is pretty secure
2017-07-03 19:49:55 <kaniini> and to be clear: i do not consider it acceptable to run software written by someone who "does not do defensive programming"
2017-07-03 19:50:22 <kaniini> that is insane
2017-07-03 19:51:33 <kaniini> so really i think this conversation has been very productive and enlightening
2017-07-03 19:54:39 <kaniini> i mean, y'all can say what you want about openrc
2017-07-03 19:54:57 <kaniini> but at least the openrc crew knows that defensive programming can mitigate many classes of security bug
2017-07-03 19:55:54 <kaniini> so, given this, i find myself fundamentally opposed to using s6 as it stands as an init system.  it would take a fundamental change in skarnet's world view to make me reconsider that position
2017-07-03 19:57:29 <Shiz> *yawn*
2017-07-03 22:05:50 <foxkit> =!= 442 foxkit #gentoo :You're not on that channel
2017-07-03 22:05:55 <foxkit> could have fooled me, weechat!
2017-07-03 22:20:15 <terra> Guys, is it viable to propose a feature request for a package via git send-email instead opening a feature request at bugs.alpinelinux.org
2017-07-03 22:21:48 <kaniini> sure
2017-07-03 22:22:51 <terra> kaniini: Thanks
2017-07-03 22:32:25 <rdutra> when booting alpine from ISO (for example) it runs a "init" script, right? which package provide this script?
2017-07-03 22:34:48 <TBB> mkinitfs in an installed system; the ISO either has or has not a custom one, I don't know
2017-07-03 22:35:32 <TBB> but the init inserted to initramfs when mkinitfs is run is, if I remember correctly, also in the mkinitfs package
2017-07-03 22:35:39 <okeuday_bak> https://git.alpinelinux.org/cgit/mkinitfs/tree/initramfs-init.in
2017-07-03 22:37:10 <rdutra> thanks
2017-07-03 22:43:45 <rdutra> okeuday_bak: when booting Alpine do you know 'who' calls the init script or how it is called?
2017-07-03 22:44:31 <okeuday_bak> rdutra: I haven't looked into that
2017-07-03 22:49:12 <terra> rdutra: calling the init script is a kernel thing
2017-07-03 22:50:37 <rdutra> ah, ok, thanks
2017-07-03 23:03:49 <skarnet> jlyo: apparently that was it, I can't make the fixed version crash with -Os
2017-07-03 23:04:51 <skarnet> so, TIL I can't count up to 35 (more accurately, I can't perform the 28+7 addition)
2017-07-03 23:11:22 <Shiz> what ended up being the issue?
2017-07-03 23:12:07 <skarnet> I can't allocate an array of the proper size (there was one byte missing)
2017-07-03 23:12:27 <skarnet> what's killing me is that it manifested *only* with -Os and *only* on Alpine
2017-07-03 23:13:14 <skarnet> anywhere else (and I've tested with lots of options on a lot of systems) it worked
2017-07-03 23:14:02 <skarnet> so, kaniini: apologies for casting doubt on the toolchain, but damn it, I was justified - I'd expect a memory corruption to show up more easily -_-
2017-07-03 23:15:11 <kaniini> it's all good
2017-07-03 23:16:13 <kaniini> alpine has much stricter FORTIFY than GNU systems do
2017-07-03 23:16:28 <skarnet> but why does it only show up with -Os
2017-07-03 23:17:12 <skarnet> now I'm wondering what other errors are in my code that never manifest
2017-07-03 23:17:18 <skarnet> and getting paranoid
2017-07-03 23:18:25 <kaniini> :D
2017-07-03 23:19:46 <skarnet> I opened the bug, but I can't close it?
2017-07-03 23:20:04 <kaniini> DENIED
2017-07-03 23:20:35 <skarnet> seriously, there's no option for me to close with RESOLVED FIXED or something
2017-07-03 23:21:34 <skarnet> redmine doesn't give bug openers admin rights on the bugs they open?
2017-07-03 23:22:54 <kaniini> DENIED
2017-07-03 23:22:56 <kaniini> i closed it
2017-07-03 23:23:13 <skarnet> ok, thanks.
2017-07-03 23:23:23 <kaniini> if you want to make a bug tracker to replace redmine i am sure we would look at it
2017-07-03 23:23:30 <kaniini> as long as it didn't require something like
2017-07-03 23:23:36 <skarnet> I wasn't complaining, just being surprised.
2017-07-03 23:23:55 <kaniini> s6-reportbug .... | s6-processbug .... | s6-updatebugs .... | s6-makereportpage > bugs.html
2017-07-03 23:24:23 <skarnet> you KNOW it will look like that if I make one
2017-07-03 23:24:53 <skarnet> but don't worry, there would be execline scripts to glue it all together
2017-07-03 23:25:18 <kaniini> what psych ward did they throw you in for making execline
2017-07-03 23:28:27 <kaniini> i kid, mostly
2017-07-03 23:29:13 <skarnet> honestly? the same they threw Stephen Bourne and Kenneth Almquist in - and they were in the security wards I didn't have the rights to visit
2017-07-03 23:30:33 <jlyo> Is there something like electric fence for stack allocations?
2017-07-03 23:31:14 <skarnet> I'd love that tbh
2017-07-03 23:33:20 <jlyo> -fsanitize=bounds-strict maybe?
2017-07-03 23:34:41 <skarnet> looks close
2017-07-03 23:34:53 <kaniini> -fsanitize=bounds-strict -fsanitize=alignment -fsanitize=object-size
2017-07-03 23:34:54 <kaniini> should give you what you want
2017-07-03 23:34:56 <kaniini> it's what i use anyway
2017-07-03 23:35:39 <skarnet> fixed s6-rc version released, aports patch sent
2017-07-03 23:35:59 <skarnet> and NOW I can go on with my day, at 1:37 am
2017-07-03 23:38:09 <jlyo> The extra -fsanitize flags didn't catch it.
2017-07-03 23:38:53 <skarnet> ew
2017-07-03 23:40:38 <kaniini> skarnet: i committed your upgrade
2017-07-03 23:40:48 <skarnet> thanks
2017-07-03 23:42:46 <kaniini> skarnet: sorry about being a dick earlier, but it just seemed so fucking arrogant to me that you would blame the toolchain without even considering otherwise
2017-07-03 23:44:36 <skarnet> I did consider otherwise! I was suspecting the toolchain because the code broke on literally *no other system*
2017-07-03 23:44:58 <skarnet> you think I didn't extensively test first?
2017-07-03 23:45:44 <kaniini> i don't honestly know.  you didn't really go into much detail on what you tested :P
2017-07-03 23:46:20 <skarnet> yeah, well, I don't go accusing compilers when I feel like it
2017-07-03 23:47:20 <skarnet> and note that integer sizes had nothing to do with it
2017-07-03 23:48:04 <kaniini> no, it didnt
2017-07-03 23:48:09 <kaniini> ironically
2017-07-03 23:48:21 <kaniini> i thought that may have been the bug, but didnt bother to count it
2017-07-03 23:48:26 <kaniini> i figured "nah it couldn't be that"
2017-07-03 23:48:32 <kaniini> so i don't blame you for not finding it quickly :P
2017-07-04 00:28:21 <foxkit> the "sorry" up there is what separates alpine from other distros
2017-07-04 00:28:36 <foxkit> having been reintroduced to arch's community elsewhere today
2017-07-04 00:28:41 <foxkit> yeah, linux is in shambles
2017-07-04 00:28:56 <foxkit> I really hope that projects like alpine can continue existing and /not/ fall victim to that
2017-07-04 00:29:37 <foxkit> so it took me three days to manage to build cmake
2017-07-04 00:29:43 <foxkit> and now I've completely forgotten why I was building it in the first place
2017-07-04 00:29:45 <foxkit> haha
2017-07-04 00:32:11 <skarnet> what happened to "fuck the internet"
2017-07-04 00:32:23 <skarnet> go have an offline day with your cat! out with you!
2017-07-04 00:33:27 <foxkit> skarnet: I tried to go offline and I ended up catching up with people irl and it turns out my irl circle is full of unix and linux developers too :(
2017-07-04 00:34:34 <foxkit> Mr Gaz is all curled up sleeping on my office windowsill anyway.  so sitting at this desk I am spending time with him
2017-07-04 00:35:29 <skarnet> sounds like excuses
2017-07-04 00:41:46 <Shiz> i already wish the above hadn't happened in the first place..
2017-07-04 00:41:48 <Shiz> ah well
2017-07-04 00:43:10 <skarnet> you have the right to intervene when kaniini is being a dick, even if he has reasons for it :P
2017-07-04 00:44:50 <kaniini> i think it may be better to document what our fortify implementation does on failure
2017-07-04 00:45:20 <kaniini> then such things don't go down because then it doesn't sound like kaniini is pulling this out of his ass
2017-07-04 12:57:02 <ScrumpyJack> afternoon
2017-07-05 03:09:01 <foxkit> ncopa: still offering to move things from community to main for Adélie?  'at' would be pretty useful :)
2017-07-05 03:09:48 <foxkit> not sure how to best handle the sendmail requirement though.  the package just hard-requires 'ssmtp', which is an option, but the default server install of adelie will have postfix already filling that role.  a sendmail virtual would probably be useful.  but idk if Alpine itself would be interested in such a thing
2017-07-05 03:12:02 <foxkit> hm, actually, it looks like postfix may not include a sendmail applet any more
2017-07-05 03:14:58 <foxkit> oh no it is there.  /usr/sbin/sendmail
2017-07-05 03:29:28 <Shiz> :p
2017-07-05 03:29:34 <Shiz> i'm fine with a sendmail virtual personally
2017-07-05 03:29:47 <Shiz> but i think a cleaner way to solve is to add file dependencies
2017-07-05 03:29:54 <Shiz> which i think i once poked kaniini about
2017-07-05 05:12:31 <foxkit> is there any reason main/fts just blindly accepts github's bad file names?
2017-07-05 07:11:30 <ncopa> morning
2017-07-05 07:11:38 <ncopa> foxkit: so you want move "at" to main?
2017-07-05 07:14:14 <ncopa> hm, its suid
2017-07-05 16:48:43 <Xe> does `abuild` let you make a package that writes files to /opt?
2017-07-05 16:51:35 <skarnet> no
2017-07-05 16:52:00 <skarnet> it will complain at package() time, IIRC.
2017-07-05 17:04:48 <^7heo> guys, when I use man, in some occasions, I get: man: dbm_map(mandoc.db): Obsolete format based on SQLite 3
2017-07-05 17:04:56 <^7heo> man: /usr/local/share/man/mandoc.db: Invalid argument
2017-07-05 17:07:12 <^7heo> any idea how to fix that one?
2017-07-05 17:09:48 <^7heo> funny, when I `man mandoc.db` I get to see the sqlite db via mandoc
2017-07-05 17:12:01 <^7heo> ok `sudo makewhatis` fixed the issue.
2017-07-05 17:57:56 <Shiz> Xe: skarnet: it will, but you have to override it
2017-07-05 17:58:05 <Shiz> with a special options= flag
2017-07-05 17:59:12 <Xe> Shiz: which flag
2017-07-05 17:59:14 <Xe> ?*
2017-07-06 00:25:36 <terra> ncopa: mpv needs to be rebuild against new ffmpeg.. it doesn't run anymore.
2017-07-06 02:17:55 <Xe> Shiz: what flag do you need to set to let a package install files to /opt?
2017-07-06 02:25:27 <Xe> ah, it's "!fhs"
2017-07-06 06:44:55 <mosez> aw, nobody created a kibana package for alpine so far :(
2017-07-06 08:01:34 <xentec> mosez: be the first
2017-07-06 08:05:59 <mosez> xentec: never tried to package nodejs crap :D
2017-07-06 12:43:52 <pqatsi> Hello filks
2017-07-06 12:43:54 <pqatsi> *folks
2017-07-06 12:44:28 <pqatsi> I want to crosscompile a package for raspiberry but Im new to Alpine and dont know well how can I set-up a environment for abuild to use crosscompilers
2017-07-06 12:44:33 <pqatsi> There is some documentation about this?
2017-07-06 13:31:33 <Shiz> pqatsi: if you have a regular alpine development environment setup, buildlab will assist you
2017-07-06 13:31:56 <Shiz> https://wiki.alpinelinux.org/wiki/Setup_your_system_and_account_for_building_packages
2017-07-06 13:32:23 <Shiz> after you've done this, you can use buildlab to setup an armhf chroot
2017-07-06 13:32:41 <Shiz> # buildlab -C -p /some/directory -m nl.alpinelinux.org -v edge -a armhf
2017-07-06 13:32:58 <Shiz> # buildlab -b -p /some/directory /some/path/to/APKBUILD
2017-07-06 13:33:18 <Shiz> first command sets up the chroot, the other one build the specified APKBUILD in it
2017-07-06 13:40:43 <pqatsi> Shiz: this mirror can be any alpine mirror?
2017-07-06 13:41:23 <pqatsi> Shiz: Also, i want to send a little update to a APKBUILD in testing. Just a PR in github is enough?
2017-07-06 13:41:34 <Shiz> correct
2017-07-06 13:41:39 <Shiz> simes two
2017-07-06 13:41:41 <pqatsi> (little update == bump to latest stable)
2017-07-06 13:41:47 <Shiz> times*
2017-07-06 13:41:56 <pqatsi> Nice!
2017-07-06 13:42:19 <pqatsi> Shiz: Raspberrypi is a bit slow to compile, but if the latest APKBUILD works, Ill submit the PR.
2017-07-06 13:42:33 <pqatsi> And if not works, ill create the cross-build env
2017-07-06 13:42:35 <pqatsi> Thanks!
2017-07-06 13:42:39 <Shiz> :)
2017-07-06 13:42:58 <Shiz> generally for any change to an abuild, be it in main, community or testing, a github PR is sufficient
2017-07-06 13:43:13 <Shiz> i mean, unless it's a huge change like upgrading the system compiler (gcc), because we usually want to test that more intricately first
2017-07-06 13:43:15 <Shiz> :P
2017-07-06 13:43:38 <pqatsi> Shiz: https://github.com/alpinelinux/aports/blob/master/testing/zerotier-one/APKBUILD <--- bump to 1.2.4
2017-07-06 13:44:18 <pqatsi> Im trying to compile it, but Alpine found textrel and aborted the package compilation, so im trying now compile it with -fpic
2017-07-06 13:44:21 <Shiz> it seems zerotier themselves actually made a PR for this as well
2017-07-06 13:44:25 <pqatsi> (And with -fPIC if it does not work)
2017-07-06 13:44:35 <Shiz> i gave some feedback and they never got back to me :(
2017-07-06 13:44:42 <pqatsi> Uh, i did not found it :(
2017-07-06 13:44:46 <Shiz> https://github.com/alpinelinux/aports/pull/1379
2017-07-06 13:44:48 <pqatsi> Shiz: well, Im doing it here too
2017-07-06 13:45:35 <pqatsi> uh
2017-07-06 13:45:47 <pqatsi> Shiz: Im only facing issues with textrels until now
2017-07-06 13:45:53 <Shiz> hmm
2017-07-06 13:45:58 <Shiz> i don't think we had textrel issues with zerotier before
2017-07-06 13:46:08 <pqatsi> >>> ERROR: zerotier-one*: Found textrels:
2017-07-06 13:46:11 <pqatsi> TEXTREL  /home/leonardo/apk-build/zerotier-one/pkg/zerotier-one/usr/sbin/zerotier-one
2017-07-06 13:46:12 <Shiz> and our gcc already implicitly does -fpic/-pie, unless explicitly disabled
2017-07-06 13:46:13 <pqatsi> >>> ERROR: zerotier-one*: prepare_subpackages failed
2017-07-06 13:46:28 <pqatsi> Shiz: well, zerotier makefile overrides a lot of things
2017-07-06 13:46:28 <Shiz> odd...
2017-07-06 13:46:40 <pqatsi> https://github.com/zerotier/ZeroTierOne/blob/master/make-linux.mk
2017-07-06 13:46:41 <Shiz> pqatsi: it's hardcoded in our compiler specs, not in any CFLAGS or the like
2017-07-06 13:46:43 <Shiz> :P
2017-07-06 13:46:55 <pqatsi> Shiz: well, indeed odd... :/
2017-07-06 13:47:07 <pqatsi> But trying -fpic anyways
2017-07-06 13:47:19 <Shiz> can't take a look at it right now since i've got some errands to run, but ping me later about it if you can't get it to work out
2017-07-06 13:47:44 <pqatsi> Shiz: nice, ill try things here
2017-07-06 13:47:53 <pqatsi> Just for reference
2017-07-06 13:47:54 <pqatsi> g++ -fpic -Wall -Wno-unused-result -Wreorder -fPIE -std=c++11 -pthread  -DNDEBUG -D_FORTIFY_SOURCE=2 -DZT_USE_MINIUPNPC -DMINIUPNP_STATICLIB -DMINIUPNPC_SET_SOCKET_TIMEOUT -DMINIUPNPC_GET_SRC_ADDR -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DOS_STRING=\"Linux\" -DMINIUPNPC_VERSION_STRING=\"2.0\" -DUPNP_VERSION_STRING=\"UPnP/1.1\" -DENABLE_STRNATPMPERR -DZT_NO_TYPE_PUNNING -DZT_BUILD_PLATFORM=1
2017-07-06 13:47:57 <pqatsi> -DZT_BUILD_ARCHITECTURE=3 -DZT_SOFTWARE_UPDATE_DEFAULT="\"disable\"" -DZT_USE_ARM32_NEON_ASM_SALSA2012 -Os -fomit-frame-pointer  -c -o node/Membership.o node/Membership.cpp
2017-07-06 13:47:59 <pqatsi> A example of final line
2017-07-06 13:48:10 <pqatsi> (forcing fpic)
2017-07-06 13:48:33 <pqatsi> I think ill need to remove this fPIE someway
2017-07-06 14:10:22 <ncopa> pqatsi: might be there are assembly code?
2017-07-06 14:11:47 <pqatsi> dunno, im trying to see it
2017-07-06 14:12:13 <pqatsi> Anyways, im trying to do the right way: Fixing everything was requested in the PR Shiz pointed here
2017-07-06 14:12:24 <pqatsi> But i think Ill need to find a way to remove the fPIE
2017-07-06 14:12:35 <pqatsi> (And im fixing all issues in PR)
2017-07-06 15:01:51 <ncopa> here comes busybox 1.27
2017-07-06 16:45:07 <pqatsi> ncopa: I can only see g++ here
2017-07-06 16:45:20 <pqatsi> ncopa: Im a bit noob to handle textrels
2017-07-06 16:46:29 <pqatsi> g++ -Os -fomit-frame-pointer -Wall -Wno-unused-result -Wreorder -fpic -std=c++11 -pthread  -DNDEBUG -D_FORTIFY_SOURCE=2 -DZT_USE_MINIUPNPC -DMINIUPNP_STATICLIB -DMINIUPNPC_SET_SOCKET_TIMEOUT -DMINIUPNPC_GET_SRC_ADDR -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DOS_STRING=\"Linux\" -DMINIUPNPC_VERSION_STRING=\"2.0\" -DUPNP_VERSION_STRING=\"UPnP/1.1\" -DENABLE_STRNATPMPERR -DZT_NO_TYPE_PUNNING
2017-07-06 16:46:32 <pqatsi> -DZT_BUILD_PLATFORM=1 -DZT_BUILD_ARCHITECTURE=3 -DZT_SOFTWARE_UPDATE_DEFAULT="\"disable\"" -DZT_USE_ARM32_NEON_ASM_SALSA2012 -Wl,--as-needed -pie -Wl,-z,relro,-z,now
2017-07-06 16:46:42 <pqatsi> remove -pie is enough?
2017-07-06 17:04:29 <Shiz> ncopa: new bb version broke depmod on some user systems
2017-07-06 17:22:26 <pqatsi> Shiz: I still stuck in textrel issue. How can i debug what is wrong with the binary?
2017-07-06 17:22:42 <pqatsi> And this is a thing that can be overrided in alpine?
2017-07-06 17:22:48 <Shiz> no
2017-07-06 17:23:04 <Shiz> textrels are not only dangerous, but also unsupported depending on the architecture (afaik)
2017-07-06 17:23:33 <Shiz> textrels are usually the cause of a single thing: non-position-independent code being mixed with position-independent-code
2017-07-06 17:23:49 <Shiz> often caused by the package having custom assembly that isn't compiled for PIC
2017-07-06 17:26:40 <pqatsi> Shiz: Everything in makefile is a C++ source. I cant find any binary here until now
2017-07-06 17:27:03 <Shiz> try compiling it with abuild -K
2017-07-06 17:27:11 <Shiz> that will make sure the build dirs aren't cleaned up
2017-07-06 17:27:18 <Shiz> you can then scan the intermediate .o files for non-pic
2017-07-06 17:27:35 <pqatsi> nice!
2017-07-06 17:27:40 <pqatsi> doing here
2017-07-06 17:29:22 <Shiz> once it's done compiling, do this:
2017-07-06 17:29:59 <Shiz> scanelf -qT pkg/zerotier-one/usr/bin/<whatever binary it says is off>
2017-07-06 17:30:11 <Shiz> it will tell you the symbols that cause the textrels
2017-07-06 18:28:03 <pqatsi> Shiz:   zerotier-one: (memory/data?) [0x76DBC] in (optimized out: previous IGDdata) [0x6F574]
2017-07-06 18:28:07 <pqatsi> just this
2017-07-06 18:31:45 <pqatsi> since IGDdata appear to be a miniupnp issue, Ill try to use miniupnpc-dev as makedep
2017-07-06 18:32:52 <pqatsi> MINIUPNPC_IS_NEW_ENOUGH=$(shell grep -sqr '.*define.*MINIUPNPC_VERSION.*"2.."' /usr/include/miniupnpc/miniupnpc.h && echo 1) <--- If its satisfied, they just link and do not try to build miniupnpc again
2017-07-06 18:35:56 <Shiz> ... right
2017-07-06 18:36:16 <Shiz> we do have miniupnpc 2.x though
2017-07-06 18:36:41 <Shiz> so adding that as makedep may fix it
2017-07-06 18:41:49 <pqatsi> Shiz: https://pastebin.com/3Cf2Rk6X :/
2017-07-06 18:42:07 <Shiz> yeah their grep is wrong
2017-07-06 18:42:17 <pqatsi> its missing a -v - right?
2017-07-06 18:42:19 <Shiz> no
2017-07-06 18:42:25 <Shiz> it's using non-posix regexps
2017-07-06 18:42:32 <pqatsi> uh :/
2017-07-06 18:42:33 <Shiz> try adding -E
2017-07-06 18:42:53 <pqatsi> no effect
2017-07-06 18:43:16 <pqatsi> pivpn:~# grep -Esqr '.*define.*MINIUPNPC_VERSION.*"2.."' /usr/include/miniupnpc/miniupnpc.h && echo 1 ; echo $?
2017-07-06 18:43:19 <pqatsi> 1
2017-07-06 18:43:57 <Shiz> # grep -Esqr '.*define.*MINIUPNPC_VERSION.*"2.."' /usr/include/miniupnpc/miniupnpc.h && echo 42 ; echo $?
2017-07-06 18:43:59 <Shiz> 42
2017-07-06 18:44:01 <Shiz> 0
2017-07-06 18:44:03 <Shiz> seems to work for me?
2017-07-06 18:44:28 <Shiz> oh right
2017-07-06 18:44:35 <pqatsi> i think its missing a *
2017-07-06 18:44:38 <pqatsi> 2..*
2017-07-06 18:44:43 <Shiz> yes
2017-07-06 18:44:47 <pqatsi> pivpn:~# grep -Esqr '.*define.*MINIUPNPC_VERSION.*"2..*"' /usr/include/miniupnpc/miniupnpc.h && echo 1
2017-07-06 18:44:47 <Shiz> was gonna suggest that, try that
2017-07-06 18:44:50 <pqatsi> 1
2017-07-06 19:04:06 <pqatsi> Shiz: sed -i.bak -e '25s,2..,2..*,g' ./make-linux.mk
2017-07-06 19:04:14 <pqatsi> Its good enough?
2017-07-06 19:04:20 <Shiz> pqatsi: i'd just do a .patch
2017-07-06 19:04:28 <Shiz> i'm generally not fond of search-replace in APKBUILDs
2017-07-06 19:05:01 <pqatsi> Ummm.. Ill keep this way just for now. There is some special function in APKBUILDs to apply patches?
2017-07-06 19:05:46 <Shiz> yes
2017-07-06 19:05:53 <Shiz> just add your patches to sources=
2017-07-06 19:05:56 <Shiz> and it will auto-apply them
2017-07-06 19:06:25 <pqatsi> hohoho, sweet. p0 from original source dir?
2017-07-06 19:06:41 <Shiz> p1
2017-07-06 19:06:56 <pqatsi> ok, ill try to do this if this build works :)
2017-07-06 19:07:01 <Shiz> :)
2017-07-06 19:40:07 <pqatsi> Shiz: miniupnp was done, but now: zerotier-one: (memory/data?) [0x6FAD0] in (optimized out: previous _ZN8ZeroTier5MutexD1Ev) [0x635FC
2017-07-06 20:22:42 <Shiz> pqatsi: hey, it's progress :P
2017-07-06 20:30:50 <pqatsi> Shiz: yup!
2017-07-06 20:31:05 <pqatsi> Shiz: https://twitter.com/pqatsi/status/883048845206310913
2017-07-06 20:31:09 <pqatsi> Meanwhile... :D
2017-07-06 20:31:23 <Shiz> >we have an Alpine PR in for the latest version
2017-07-06 20:31:27 <Shiz> that you didn't respond to feedback to
2017-07-06 20:31:29 <Shiz> *grumble grumble*
2017-07-06 20:32:31 <pqatsi> Shiz: hahhahahahaha, meanwhile, im fixing things... Im at work now, in a +- 2h ill try to submit it to a git
2017-07-06 20:32:46 <Shiz> np
2017-07-06 20:32:54 <Shiz> there's no rush :) i'm going to pick someone up now too
2017-07-06 20:52:20 <pqatsi> Shiz: :)
2017-07-06 20:53:00 <pqatsi> Shiz: Im a bit hurry because I need ZT to run in this Rpi - but i dont like workarrounds and hand-installed things and i liked a lot the premisses of alpine to be diskless/commitable distro
2017-07-06 20:53:01 <pqatsi> :)
2017-07-06 20:53:05 <pqatsi> BRB!
2017-07-06 20:54:29 <ncopa> Shiz: i think i saw something segfault on my laptop when i upgraded
2017-07-06 20:54:41 <ncopa> so it was depmod
2017-07-06 20:57:05 <ncopa> ok i can reproduce
2017-07-07 08:24:46 <xsteadfastx> i dont want to make any pressure... but could some review https://github.com/alpinelinux/aports/pull/1847 for me? this version fixes a problem with the facebook api
2017-07-07 08:47:32 <_ikke_> xsteadfastx: apparently someone did
2017-07-07 08:47:42 <_ikke_> xsteadfastx: (fabled)
2017-07-07 08:55:31 <xsteadfastx> wonderfull :)
2017-07-07 10:15:11 <Shiz> https://github.com/i-rinat/apulse
2017-07-07 10:15:18 <Shiz> this may be useful for us in the wake of fx dropping alsa support
2017-07-07 10:58:02 <fabled> seems patchworks.a.o no longer is auto-closing items when they are pushed to git.a.o
2017-07-07 10:58:08 <fabled> clandmeter, any ideas on ^
2017-07-07 10:58:35 <jirutka> fabled: I have an idea! shutdown patchwork! :)
2017-07-07 10:58:45 <fabled> jirutka, not all like github
2017-07-07 11:01:21 <jirutka> speaking about GH, this is very cool (for maintainers): https://gist.github.com/piscisaureus/3342247
2017-07-07 11:06:01 <fabled> niice, though i'd rather not clutter my branch space with that. i've been using the 'hub' tool so far
2017-07-07 11:06:53 <jirutka> not branch space…
2017-07-07 11:07:19 <jirutka> they do not appear as your local branches
2017-07-07 11:14:03 <jirutka> kaniini: how does it look with that Alpine CF tool? I need it :)
2017-07-07 11:23:07 <clandmeter> the prid.patch seems just as easy?
2017-07-07 11:23:37 <jirutka> it depends…
2017-07-07 11:24:20 <jirutka> I haven’t tried yet if you can also push to these references
2017-07-07 11:24:33 <clandmeter> ah ok
2017-07-07 11:25:30 <jirutka> moreover, you don’t even need to open GH with this approach
2017-07-07 11:25:42 <jirutka> just git fetch <remote> and you see all new PRs
2017-07-07 11:25:51 <jirutka> you can list them, see commits etc.
2017-07-07 11:26:04 <clandmeter> what if a project has 10k pr's?
2017-07-07 11:26:06 <jirutka> but not PR message, only commit messages :/
2017-07-07 11:26:19 <jirutka> does it matter?
2017-07-07 11:26:28 <clandmeter> im asking,
2017-07-07 11:27:05 <jirutka> I’ve started using it on aports and it doesn’t seem that git care about number of references, no slow down or something like that ;)
2017-07-07 11:27:21 <clandmeter> ok, thats a good thing
2017-07-07 11:28:40 <clandmeter> if fabled comes back, i dunno what the issue is with patchwork. its not patchwork but some remote part that doesn't pull git and  close it. i just need to remember where it is.
2017-07-07 11:29:15 <clandmeter> ncopa, do you recall where we put that part? i was under the impression it was redmine.
2017-07-07 11:29:21 <jirutka> :)
2017-07-07 11:29:46 <clandmeter> i need to create a new container with latest redmine...
2017-07-07 11:30:04 <clandmeter> but i am swamped
2017-07-07 11:30:20 <jirutka> good that I took over bot that sync GH repos, so it actually works without any outages :) :P
2017-07-07 11:32:17 <clandmeter> im going home and try to forget about computers for a day...
2017-07-07 11:33:32 <jirutka> actually we have kinda HA now, cause both bots still work, just mine is faster, so it’s always first who syncs; but when it stop working, then ncopa’s bot gets a word
2017-07-07 15:50:27 <thafreak> Anyone know of a package with an init script where the thing it launches is a shell script that doesn't exit?
2017-07-07 15:51:11 <thafreak> start-stop-daemon "daemonizes" it, but doesn't clean up properly when stopped (all the children are left running)
2017-07-07 15:51:43 <thafreak> I'm wondering if there is a package with an init script that already handles something similar that I can look at...
2017-07-07 16:06:15 <jirutka> thafreak: “where the thing it launches is a shell script that doesn't exit” … eh, what?
2017-07-07 16:06:45 <thafreak> start-stop-daemon --exec /some/shell/script.sh
2017-07-07 16:06:57 <thafreak> and that shell script does something like
2017-07-07 16:07:13 <jirutka> this is wrong
2017-07-07 16:07:14 <thafreak> eval /bin/thing|/bin/otherthing|/bin/something
2017-07-07 16:07:22 <thafreak> yeah, tell me about it
2017-07-07 16:07:28 <jirutka> don’t start this crappy shell script, but the actual program
2017-07-07 16:07:55 <thafreak> So, this isn't my thing, I'm trying to fix a package :/
2017-07-07 16:08:03 <jirutka> which pkg?
2017-07-07 16:08:11 <thafreak> sshguard 2.0 is a drasticly different thing than it was in 1.7
2017-07-07 16:08:19 <jirutka> aha
2017-07-07 16:08:45 <jirutka> anyway, as I said, remove this shell script
2017-07-07 16:08:55 <jirutka> examine what it does and do it in the runscript
2017-07-07 16:09:01 <thafreak> So I'm trying to fix it, but now I find that the init script doesn't really work right anymore
2017-07-07 16:09:41 <thafreak> Well, /usr/sbin/sshguard is now a script that does a bunch of stuff, and then at the end, runs an "eval"
2017-07-07 16:10:00 <thafreak> Which launches some pipeline based on configuration it reads in
2017-07-07 16:10:14 <jirutka> and it doesn’t offer any option like --foreground, --do-not-daemonize-goddman etc?
2017-07-07 16:10:41 <thafreak> Oh, no, the /usr/sbin/sshguard doesn't daemonize, it stays in the foreground
2017-07-07 16:10:54 <jirutka> then where’s the problem?
2017-07-07 16:11:00 <thafreak> but start-stop-daemon if it starts it, it doesn't stop it
2017-07-07 16:11:10 <thafreak> it kills something, but not everything
2017-07-07 16:11:21 <jirutka> aha, i see now
2017-07-07 16:11:29 <thafreak> I'm about to try --name to see if I can use that
2017-07-07 16:11:41 <jirutka> give me a sec
2017-07-07 16:11:43 <thafreak> do you know how it matches --name?
2017-07-07 16:16:24 <jirutka> thafreak: try this https://dpaste.de/6qQh
2017-07-07 16:23:43 <kaniini> jirutka: probably mid next week have been quite busy
2017-07-07 16:25:17 <thafreak> jirutka: thanks, that works better, still not perfect
2017-07-07 16:25:25 <jirutka> thafreak: why?
2017-07-07 16:25:28 <thafreak> status at least reports running now
2017-07-07 16:25:31 <thafreak> and stop mostly works
2017-07-07 16:25:40 <thafreak> some of the child processes are left running
2017-07-07 16:25:46 <thafreak> but it kils most of them
2017-07-07 16:26:04 <jirutka> hm, that’s bad
2017-07-07 16:26:18 <thafreak> /usr/sbin/sshguard responds to <ctrl>-c to exit
2017-07-07 16:26:29 <thafreak> is there a way to adjust which sig gets sent?
2017-07-07 16:26:56 <jirutka> thafreak: it’s actually not a good idea to define "wait" variable, there’s a fix https://dpaste.de/CAa8
2017-07-07 16:27:59 <jirutka> thafreak: yes, define variable stopsig
2017-07-07 16:28:05 <jirutka> Signal to send when stopping the daemon.
2017-07-07 16:32:33 <skarnet> just start the thing in its own process group and send a signal to the whole pgroup
2017-07-07 16:33:52 <jirutka> skarnet: how?
2017-07-07 16:34:11 <skarnet> do I look like I want to read the man of start-stop-daemon?
2017-07-07 16:34:16 <thafreak> haha
2017-07-07 16:34:32 <thafreak> is there a man for it? I was trying to look through the source to figure it out...
2017-07-07 16:35:04 <skarnet> half-assed pieces of shit always have a man
2017-07-07 16:35:05 <jirutka> https://encrypted.google.com/search?hl=en&q=man%20start%2Dstop%2Ddaemon
2017-07-07 16:35:33 <jirutka> and start-stop-daemon does not have such feature, I’d probably know about it otherwise…
2017-07-07 16:35:59 <skarnet> heh. useless through and through.
2017-07-07 16:36:02 <jirutka> anyway, if it does not kill all its own children, then I’d call it a bug in upstream
2017-07-07 16:36:15 <jirutka> skarnet: it’s not useless, just not so powerful
2017-07-07 16:36:15 <skarnet> sure it's a bug and should be reported
2017-07-07 16:36:23 <skarnet> useless
2017-07-07 16:36:30 <jirutka> …
2017-07-07 16:36:45 <skarnet> there's nothing you can do with it that you can't with shell and a few utilities
2017-07-07 16:37:41 <jirutka> yes, and?
2017-07-07 16:38:01 <skarnet> offering no value is the definition of useless
2017-07-07 16:38:16 <jirutka> it avoids copy&pasting of dozens of helpers…
2017-07-07 16:38:17 <thafreak> It does kill everything if I run /usr/sbin/sshgaurd and then ctrl-c
2017-07-07 16:38:21 <thafreak> which is odd
2017-07-07 16:38:21 <jirutka> like in crappy SysV init
2017-07-07 16:38:35 <skarnet> thafreak: that's the terminal sending a SIGINT to the whole pgroup
2017-07-07 16:38:38 <jirutka> so it’s not useless
2017-07-07 16:38:44 <thafreak> hmm
2017-07-07 16:38:45 <skarnet> that won't happen in an init script
2017-07-07 16:38:52 <jirutka> that’s nonsense
2017-07-07 16:39:03 <jirutka> there should not be any difference
2017-07-07 16:39:12 <jirutka> he does not manually start these processes from his shell
2017-07-07 16:39:24 <skarnet> oh?
2017-07-07 16:39:36 <jirutka> that shell script starts them and it’s not sourced into the current shell, but run as a separate shell process
2017-07-07 16:39:44 <skarnet> how would ^C work then?
2017-07-07 16:39:55 <jirutka> ’cause it starts in foreground?
2017-07-07 16:39:59 <jirutka> aha…
2017-07-07 16:40:05 <jirutka> hm…
2017-07-07 16:40:16 <skarnet> if ^C works it means you got a ctty. If you got a ctty, then signals are sent to the pgroup. End of story.
2017-07-07 16:40:27 <jirutka> but ^C just sends some signal (don’t remember which one), so when you send this signal using start-stop-daemon instead, it should behave the same
2017-07-07 16:40:41 <jirutka> right?
2017-07-07 16:41:02 <skarnet> ssd sends it to the process.  ^C -> SIGINT sent to the pgroup. I won't explain a third time.
2017-07-07 16:41:18 <jirutka> okay okay
2017-07-07 16:52:06 <thafreak> Ok, so this is nuts, but one of the subprocesses it starts is a tail -F
2017-07-07 16:52:30 <thafreak> If I send a sigpipe to THAT process, all the other processes end cleanly
2017-07-07 16:52:41 <thafreak> but killing the first parent does nothing
2017-07-07 16:53:31 <thafreak> I think it's back to fail2ban for now until upstream gets their act together I guess :/
2017-07-07 16:55:44 <jirutka> thafreak: please don’t forget to report it to upstream
2017-07-07 16:55:55 <thafreak> Will do
2017-07-07 16:56:00 <thafreak> Thanks for your help
2017-07-07 16:56:37 <thafreak> Also, are there docs about applying patches during the abuild proces?
2017-07-07 16:56:45 <thafreak> Or is everything 100% upstream only?
2017-07-07 16:57:23 <thafreak> In case I want to fix it myself and make my own apk
2017-07-07 16:58:16 <jirutka> just add patch files to the same directory as APKBUILD and name them in sources=
2017-07-07 17:02:30 <thafreak> Oh ok, sounds like I can figure it out. Thanks for all the help
2017-07-07 22:24:49 <jirutka> This script creates a bootable Alpine Linux disk image for virtual machines, it can be used to create custom image: https://gist.github.com/jirutka/09a8401f69a2b70b2918f3e280740fc9
2017-07-08 01:23:06 <kaniini> nice
2017-07-08 11:24:16 <vkrishn> interesting, for writing "more secure and reliable C programs" from ms, https://www.microsoft.com/en-us/research/project/checked-c/
2017-07-08 11:56:32 <scadu> https://github.com/alpinelinux/aports/pull/1880 can we merge this one? sec update of irssi
2017-07-08 11:57:07 <scadu> kaniini: jirutka ^
2017-07-08 12:23:01 <jirutka> scadu: gaaa, you’ve forgot to remove \ after removing return 1 and also trailing spaces…
2017-07-08 12:23:19 <jirutka> and I should not merge things right after nap
2017-07-08 12:24:31 <scadu> jirutka: gimme sec
2017-07-08 12:24:39 <jirutka> I’ve already merged it
2017-07-08 12:24:43 <jirutka> and fixing now
2017-07-08 12:26:31 <scadu> jirutka: thanks. I should take a nap then :s
2017-07-08 18:58:06 <vkrishn> oui! https://github.com/Microsoft/checkedc/blob/master/include/string_checked.h#L62
2017-07-08 18:58:07 <vkrishn> seems they are analysing linux code also
2017-07-08 18:58:36 <vkrishn> this is a good sign ! right ?
2017-07-08 18:58:39 <TBB> they've been investing in Linux quite a bit in the recent years
2017-07-08 19:00:00 <vkrishn> in a oracle/mysql way or something better ?
2017-07-08 19:00:35 <pqatsi> Shiz: May this https://github.com/zerotier/ZeroTierOne/blob/master/ext/arm32-neon-salsa2012-asm/salsa2012.s is generating the textrels in ZeroTier?
2017-07-08 19:00:38 <vkrishn> corps need money to run, remember
2017-07-08 19:01:04 <Shiz> https://github.com/zerotier/ZeroTierOne/tree/master/ext/x64-salsa2012-asm
2017-07-08 19:01:06 <Shiz> possible, yes
2017-07-08 19:01:25 <TBB> I think Microsoft has solved that specific problem a long time ago, vkrishn :)
2017-07-08 19:01:39 <pqatsi> Shiz: in the case, the makefile  appear to do not play with x64.
2017-07-08 19:01:57 <pqatsi> Shiz: So, if its necessary, how can be fixed? Or may really needed the textrels
2017-07-08 19:01:59 <pqatsi> ?
2017-07-08 19:02:15 <Shiz> it does
2017-07-08 19:02:22 <Shiz> https://github.com/zerotier/ZeroTierOne/blob/fe5257df81c4ec4b5d48f707eb794de0748b7ac0/make-linux.mk#L84
2017-07-08 19:02:24 <Shiz> and
2017-07-08 19:02:31 <Shiz> https://github.com/zerotier/ZeroTierOne/blob/fe5257df81c4ec4b5d48f707eb794de0748b7ac0/make-linux.mk#L169
2017-07-08 19:02:56 <Shiz> pqatsi: easiest try would be make ZT_USE_X64_ASM_SALSA2012=0
2017-07-08 19:03:20 <pqatsi> Shiz: but in Raspberrypi, may heavly penalize the performance, dont?
2017-07-08 19:03:28 <Shiz> and same for arm
2017-07-08 19:03:35 <Shiz> well, it's just to see if it fixes the textrels
2017-07-08 19:03:45 <Shiz> also ZT_USE_ARM32_NEON_ASM_SALSA2012=0
2017-07-08 19:04:59 <pqatsi> Shiz: Trying here
2017-07-08 19:07:00 <vkrishn> well, if they make XP a "freeware", I might support their cause, or atleast show a smile
2017-07-08 19:11:09 <pqatsi> Shiz: final gcc line: g++ -Os -fomit-frame-pointer -Wall -Wno-unused-result -Wreorder -fPIC -std=c++11 -pthread  -DNDEBUG -D_FORTIFY_SOURCE=2 -DZT_USE_MINIUPNPC -DZT_USE_SYSTEM_MINIUPNPC -DZT_NO_TYPE_PUNNING -DZT_BUILD_PLATFORM=1 -DZT_BUILD_ARCHITECTURE=3 -DZT_SOFTWARE_UPDATE_DEFAULT="\"disable\"" -Os -fomit-frame-pointer  -c
2017-07-08 19:11:45 <pqatsi> Shiz: im wondering about this asm: May it be distributable in alpine with this textrels issue?
2017-07-08 19:12:02 <pqatsi> 
ACTION dont understand very well the effects of textrels in the binary

2017-07-08 19:24:06 <Shiz> pqatsi: no
2017-07-08 19:24:35 <pqatsi> Shiz: :(
2017-07-08 19:25:34 <pqatsi> Shiz: its a bad if this is not fixable. I'll try to report, but since this asm was copied from cry.pt.to, I dont see a way the zt upstream may fix it (Or even if its fixable)
2017-07-08 19:27:32 <Shiz> let's first find if it's an asm issue at all
2017-07-08 19:27:41 <Shiz> it may also just be a matter of passing correct pic flags to the assembler
2017-07-08 19:28:53 <pqatsi> Shiz: hmmmmmmm indeed. Can you find where in the make-linux the ASM flags was set?
2017-07-08 19:29:13 <Shiz> not until you figure out if it works properly with the asm disabled
2017-07-08 19:30:15 <pqatsi> ok doke!
2017-07-08 19:52:27 <pqatsi> Shiz: ok, compiled :)
2017-07-08 19:53:08 <pqatsi> Shiz: https://pastebin.com/VY27mf3D
2017-07-08 19:53:40 <pqatsi> (Set variable before make command does not work, so i changed the make file)
2017-07-08 20:19:16 <jirutka> pqatsi: set it *after* make command…
2017-07-08 20:21:50 <pqatsi> jirutka: Will not be overwritten by https://github.com/zerotier/ZeroTierOne/blob/master/make-linux.mk#L108 ?
2017-07-08 20:22:08 <jirutka> aha, sry, it’ll be
2017-07-08 20:22:51 <skarnet> nope
2017-07-08 20:22:58 <skarnet> that should be a make FAQ
2017-07-08 20:23:02 <jirutka> ?
2017-07-08 20:23:30 <skarnet> environment variables are overridden by make variable assignments in a Makefile, but make variables given on the cmdline *are not*
2017-07-08 20:23:41 <skarnet> unless the "override" keyword is used
2017-07-08 20:24:10 <skarnet> and if a Makefile uses override, send hate mail to the author
2017-07-08 20:24:18 <jirutka> aha, my fault, I haven’t read the patch, I thought that he’s talking about DEFS
2017-07-08 20:24:44 <skarnet> yeah, DEFS wouldn't work, but it makes sense here since it's an accumulator
2017-07-08 20:25:17 <skarnet> still they shouldn't use override, and simply fail if someone tries to declare DEFS on the cmdline
2017-07-08 20:25:31 <pqatsi> skarnet: Uh, i did not know this. Thanks!
2017-07-08 20:25:58 <skarnet> pqatsi: it's probably the most counterintuitive part of make, so don't worry about it - but it's useful to remember :)
2017-07-08 20:26:08 <pqatsi> skarnet: :)
2017-07-08 20:26:19 <pqatsi> -e also changes precedence of variables, right?
2017-07-08 20:26:56 <skarnet> IIRC make -e also makes environment variables override variable definitions in a makefile
2017-07-08 20:27:10 <skarnet> as if env vars were make vars
2017-07-08 20:27:40 <pqatsi> Uh, right.
2017-07-08 20:28:13 <pqatsi> As the fPIE/fpie tags are set within a override, patching still needed here if fpic is required
2017-07-08 20:28:34 <pqatsi> but since the relocations are from the asm code, ill try to do a vanilla compilation w/o the asm
2017-07-08 20:29:04 <skarnet> people who use override should be taken out and shot. With paintballs. Because it hurts a lot.
2017-07-08 20:35:30 <pqatsi> skarnet: :P
2017-07-08 21:04:18 <pqatsi> Shiz: Well, is the ASM thing. Iff i use  make one ZT_USE_ARM32_NEON_ASM_SALSA2012=0 - everything compiles ok. Im also using the patch for miniupnpc (sed -i.bak -e '25s,2..,2..*,g' ./make-linux.mk)
2017-07-08 21:05:06 <pqatsi> Shiz: so, its a good idea to do a initial commit with ZT_USE_ARM32_NEON_ASM_SALSA2012=0 ? Also, since only one sed is needed, should I create the patch anyways?
2017-07-08 21:05:11 <pqatsi> (As a best pratice)
2017-07-08 21:06:29 <Shiz> yes, don't do seds in APKBUILD
2017-07-08 21:06:38 <Shiz> and also use the one to disable asm for x86-64
2017-07-08 21:06:48 <pqatsi> Shiz: ok!
2017-07-08 21:07:02 <pqatsi> Shiz: About the asm part, what is the best to do? Report to upstream?
2017-07-08 21:07:41 <pqatsi> Because for x86, its ok, but for raspberry pi it maybe a missing thing (Because pi is slow as a rock for somethings)
2017-07-08 21:07:58 <pqatsi> Im afraid - as example - I cant get full 100mbps in ZT w/o the patc
2017-07-08 21:08:00 <pqatsi> patch
2017-07-08 21:14:42 <pqatsi> Shiz: last, since ZT mantainer have a PR, how should I submit it to you? Another PR?
2017-07-08 21:15:50 <pqatsi> And generic packaging: I see some comments in the PR to avoid | return 1, but https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Patches recomends to use  default_prepare || return 1
2017-07-08 21:15:56 <pqatsi> How is the correct way to do it now?
2017-07-08 21:19:13 <Shiz> shouldn't be needed
2017-07-08 21:19:56 <pqatsi> ok! Im doing a last compilation with cleaned APKBUILD.
2017-07-08 21:20:57 <pqatsi> Shiz: a generic question. the /var/lib/zerotier contains data about the tunnels - and its variable data. How alpine works with it?
2017-07-08 21:21:10 <pqatsi> in diskless mode, it will be commited to lbu_commit ?
2017-07-08 21:22:17 <Shiz> if you add it with # lbu inc, sure
2017-07-08 21:22:49 <pqatsi> Shiz: this must be done at packaging time?
2017-07-08 21:22:53 <Shiz> no?
2017-07-08 21:22:56 <Shiz> it's up to the end-user
2017-07-08 21:23:24 <pqatsi> right
2017-07-08 22:22:14 <pqatsi> Shiz: Zerotier user needs to be in netdev group to use tun/tap. Should I do it in post-script? And if yes, how?
2017-07-08 22:41:16 <jirutka> pqatsi: no, pre-install script: addgroup -S -g 28 netdev 2>/dev/null; addgroup zerotier netdev 2>/dev/null; exit 0
2017-07-08 22:42:12 <jirutka> pqatsi: pardon, without first addgroup
2017-07-08 22:42:21 <jirutka> pqatsi: netdev is in baselayout, so just add zerotier to netdev
2017-07-09 00:05:41 <pqatsi> jirutka: things of life: The proposed post-script sets gecos as 'http://www.zerotier.com/'
2017-07-09 00:05:50 <pqatsi> And things just dont work as user
2017-07-09 00:06:10 <pqatsi> su did not liked the gecos, so i've removed the gecos and voilá
2017-07-09 00:06:31 <pqatsi> Question: I think this gecos is not required but can be some sort of propaganda from the upstream
2017-07-09 00:06:44 <pqatsi> Should I mantain it or fix it or just dont use and leave it as it?
2017-07-09 01:24:22 <pqatsi> for diskless packages, there is some depend to add in initd to unit wait for lbu restore?
2017-07-09 01:42:31 <Shiz> ?
2017-07-09 02:06:58 <pqatsi> Shiz: i think its maybe a noob moment from me. If i reboot the raspi, the zerotier version backs to the 1.1 (from edge) :/
2017-07-09 02:07:16 <pqatsi> apk update ; apk upgrade fixes it :/
2017-07-09 17:44:09 <mitchty> i'll look at https://bugs.alpinelinux.org/issues/7340 a bit tonight but the top behavior if something mmaps 1TiB with MAP_RESERVE smells of a divide by zero to me or maybe busybox top not having a good size for vsz, the ls behavior really sounds interesting, but its been a while since I spelunked in the vm part of the kernel, have to go do some other stuff for the day
2017-07-10 04:26:06 <mitchty> so is there a quick way of getting a busybox binary with debug symbols or do I have to rebuild busybox with a -dbg subpackage, debugging with gdb without symbols makes me want to drink
2017-07-10 07:43:01 <kaniini> mitchty: SIGILL is likely a fortify violation, so actually buffer overrun most likely.
2017-07-10 09:08:53 <ncopa> morning
2017-07-10 09:09:12 <ncopa> is it just me who finds github so slow that it is close to useless?
2017-07-10 09:43:04 <scadu> yes
2017-07-10 09:51:48 <_ikke_> github is not slow for me
2017-07-10 09:51:56 <armin> also not for me
2017-07-10 10:30:41 <ncopa> takes like 3-4 seconds to generate the pull requests list for me
2017-07-10 10:31:33 <_ikke_> on aports?
2017-07-10 10:32:23 <_ikke_> 800ms for me
2017-07-10 11:25:42 <clandmeter> also 880 for me.
2017-07-10 11:54:07 <Shiz> https://twitter.com/sung_music/status/884357010501795840
2017-07-10 11:54:10 <Shiz> wrong channel
2017-07-10 12:51:55 <ncopa> i have problem with cmocka
2017-07-10 12:52:04 <ncopa> the testsuite fails on aarch64
2017-07-10 14:24:30 <mitchty> kaniini: makes sense i normally think of SIGILL for other reasons, but when I see a bt of just addresses my heart drops through the floor a bit, i hate debugging without symbols
2017-07-10 14:44:26 <nancy> Hello, i have few questions related iscsi tuning may i?
2017-07-10 15:06:56 <ng0> I like learning new things and systems. And some of the software I use isn't in alpine. The process itself is easy, having experience with Guix,Gentoo,and other systems. Have I missed the guidelines for how it is decided where packages go to? I seem to remember they stay a while in testing before they are considered stable and they are moved to community if no one maintains them that well and finally to
2017-07-10 15:06:57 <ng0> unmaintained if no one maintains them?
2017-07-10 15:07:57 <ng0> or should I simply read the git log and it will become clear?
2017-07-10 15:10:50 <pqatsi> Shiz: PR done: https://github.com/alpinelinux/aports/pull/1892 :)
2017-07-10 15:21:10 <ng0> great, something hates my current hardware.. I guess it's okay to direct my question to the alpine-devel list if a search in its archive doesn't answer the question I had
2017-07-10 19:08:04 <jirutka> ncopa: you don’t mind that https://github.com/alpinelinux/aports/pull/1849 downloads libraries during build and does not even set --locked to force it adhere to lock file?
2017-07-10 19:08:19 <jirutka> ncopa: more info https://github.com/alpinelinux/aports/blob/master/community/cargo/APKBUILD#L19-L28
2017-07-10 19:09:35 <ncopa> hum
2017-07-10 19:10:35 <ncopa> yes you are right
2017-07-10 19:12:27 <ncopa> jirutka: as i understand to fix that i need to: export CARGOFLAGS="--locked"
2017-07-10 19:12:33 <ncopa> that should be enough?
2017-07-10 19:12:42 <ncopa> i havent really looked into the rust things
2017-07-10 19:12:43 <jirutka> have you read the comment in cargo abuild?
2017-07-10 19:13:34 <jirutka> we still haven’t decided how to correctly deal with rust packages
2017-07-10 19:13:50 <ncopa> for now it's exception only for cargo
2017-07-10 19:13:50 <ncopa> #   package and should not be applied to other rust packages!
2017-07-10 19:13:51 <ncopa> ok
2017-07-10 19:14:09 <ncopa> i'll revert it then
2017-07-10 19:14:20 <ncopa> how are cargo package supposed to be handled?
2017-07-10 19:14:34 <pqatsi> jirutka: I didnt got you point in https://github.com/alpinelinux/aports/pull/1892#discussion_r126510559
2017-07-10 19:14:52 <pqatsi> jirutka: What is the correct way to do this post-deinstall?
2017-07-10 19:15:19 <jirutka> ncopa: I don’t know… I have some ideas, but we need to discuss it
2017-07-10 19:15:19 <ncopa> we dont delete users
2017-07-10 19:15:23 <ncopa> ok
2017-07-10 19:15:57 <ncopa> jirutka: i was not aware of the cargo ugliness. sorry
2017-07-10 19:15:59 <pqatsi> ncopa: even when the install script creates it?
2017-07-10 19:16:01 <pqatsi> ?
2017-07-10 19:16:06 <jirutka> pqatsi: do you really ask…? have you thought about what does it do?
2017-07-10 19:16:24 <ncopa> pqatsi: correct, even if we create it from pre-install
2017-07-10 19:16:40 <pqatsi> I just want to understand why, since usually in other distros, the user is removed if package is removed
2017-07-10 19:16:50 <jirutka> pqatsi: how the heck can you know if install script created it or user created it herself/himself before? or if (s)he really don’t need the data in this directory…?
2017-07-10 19:17:05 <skarnet> there is also a real technical argument not to remove users
2017-07-10 19:17:17 <jirutka> pqatsi: do you really think that’s it’s okay for packages to just delete user’s data?
2017-07-10 19:17:17 <ncopa> pqatsi: i think jirutkas biggest issue is that home dir is removed
2017-07-10 19:17:36 <pqatsi> sorry guys, its not a questioning, i really dont know well about alpine.
2017-07-10 19:17:46 <skarnet> suppose there are files still belonging to the old user - for instance, backup or data files created by the package, and that are not part of the installed files so that are not removed when the package is removed (and that's on purpose)
2017-07-10 19:17:52 <jirutka> pqatsi: I know that Debian do such thinks, but it’s utterly stupid and harmful
2017-07-10 19:17:53 <pqatsi> jirutka: some distros separates the remove from purge
2017-07-10 19:17:54 <skarnet> if the user is kept, there's no problem
2017-07-10 19:18:04 <pqatsi> jirutka: sure, i minded as debian does
2017-07-10 19:18:17 <skarnet> if the user is removed, it may be reassigned later, when installing a different package, under another user name
2017-07-10 19:18:24 <jirutka> pqatsi: Alpine is not Debian, we never delete user’s data
2017-07-10 19:18:36 <skarnet> and tada! you have another user owning files it has nothing to do with
2017-07-10 19:18:52 <ncopa> pqatsi: its ok. there is no way you could have known that
2017-07-10 19:19:05 <jirutka> packages should never remove users and never EVER remove any data not installed by the package itself
2017-07-10 19:19:12 <pqatsi> skarnet: hmmm, right
2017-07-10 19:19:22 <ncopa> i mean, there is no way you could have known the alpine policies. i dont think we have it written even
2017-07-10 19:19:35 <jirutka> this is not Alpine policy, but common sense IMO…
2017-07-10 19:19:38 <pqatsi> jirutka: well, the adduser entry, its ok in pre-install?
2017-07-10 19:19:40 <pqatsi> Ill remove it
2017-07-10 19:19:45 <jirutka> I’m quite shocked how many ppl thinks that this is okay to do…
2017-07-10 19:19:46 <pqatsi> (remove the deinstall)
2017-07-10 19:19:57 <jirutka> yes, adduser should be in pre-install
2017-07-10 19:20:54 <skarnet> jirutka: it's cohesive and defensible to say that packages that create a user at install should remove it at deinstall. It's a choice and there are arguments for it (and admins should not mess with what the package manager does)
2017-07-10 19:21:17 <skarnet> I just happen to think the argument *not* to remove users is stronger, and that Alpine made the right choice.
2017-07-10 19:21:59 <pqatsi> I understood skarnet arguing
2017-07-10 19:22:38 <pqatsi> The point i think is debian can do this kind of thing (can does not mean its good to do) because exist a trigger to purge that removes user data - and explicitly does this
2017-07-10 19:22:45 <ncopa> pqatsi: could you please also change the commit message to something like: testing/zerotier-one: Support for ZeroTier 1.2.4
2017-07-10 19:23:02 <ncopa> and add the reference to the PR as full url instead of #<number>
2017-07-10 19:23:20 <ncopa> since we have other bugtracker with different id
2017-07-10 19:23:21 <pqatsi> ncopa: sure. I need to stash the last commit or just do a new commit message?
2017-07-10 19:23:40 <ncopa> git commit --amend && git push --force ...
2017-07-10 19:24:22 <pqatsi> A question about the delete/nodelete user data:
2017-07-10 19:24:44 <pqatsi> In the zerotier upstream packaging, the post-deinstall removes the network.d files
2017-07-10 19:25:15 <pqatsi> The "upstream" pratice bypass the do not delete user data or do not delete user data is mandatory?
2017-07-10 19:26:13 <jirutka> upstream practices of Zerotier are very bad
2017-07-10 19:26:24 <ncopa> where is the upstream packaging?
2017-07-10 19:26:39 <ncopa> is it upstream debian packaging?
2017-07-10 19:26:43 <pqatsi> ncopa: they sent a PR very critized. So Ive based in it
2017-07-10 19:26:45 <pqatsi> No, Alpine PR
2017-07-10 19:26:52 <jirutka> this is like 2nd attempt to update this package, I remember that there were a lot of issues in the previous one and some of them repeats even here, like putting pidfile into /var/lib/…
2017-07-10 19:26:54 <pqatsi> jirutka: I saw the comments in the original pr
2017-07-10 19:27:30 <pqatsi> jirutka: I dont know well alpine packaging. Im fixing everything was told in the PR, but im still learning (Like the user data thing)
2017-07-10 19:27:41 <pqatsi> jirutka: Where the PID file must point?
2017-07-10 19:27:55 <jirutka> inside /run, as I wrote
2017-07-10 19:28:08 <pqatsi> ncopa: https://github.com/alpinelinux/aports/pull/1379 - the first one
2017-07-10 19:28:14 <pqatsi> jirutka: Uh, so ive missed it
2017-07-10 19:28:14 <jirutka> this is the same for every Linux distribution that use init system which needs pidfiles…
2017-07-10 19:28:21 <jirutka> . /run or (legacy) /var/run
2017-07-10 19:28:24 <pqatsi> Ill patch this issue too.
2017-07-10 19:29:55 <ncopa> oh, that pr is long. thats why i havent read it before :)
2017-07-10 19:33:24 <ncopa> its late
2017-07-10 19:33:29 <ncopa> have a good night
2017-07-10 19:33:38 <jirutka> yeah, i should leave work
2017-07-10 19:38:01 <pqatsi> jirutka: So, ill do the amend ncopa said and try to fix the /var/lib/*.pid. I hope no patching in source code got required
2017-07-10 19:39:06 <jirutka> pqatsi: also init system should create pidfile, not the program
2017-07-10 19:40:45 <pqatsi> jirutka: OpenRC do this? I dont remember from my Gentoo era
2017-07-10 19:41:43 <jirutka> pqatsi: yes, when you set command_background="yes" (it implies start-stop-daemon --background and --make-pidfile)
2017-07-10 19:41:45 <pqatsi> jirutka: but if its impossible to do w/o patch the source-code, its tolerable to leave zt create the *.pid - in the right folder?
2017-07-10 19:41:58 <pqatsi> Ah, ok
2017-07-10 19:42:10 <pqatsi> Ill try this
2017-07-10 19:42:21 <jirutka> pqatsi: then you should fix zt… you’re the zt’s developer, right?
2017-07-10 19:43:18 <jirutka> pqatsi: if it’s not possible to start ZT without detaching and dumping pidfile, then it’s very bad design
2017-07-10 19:44:32 <jirutka> pqatsi: it’s init/rc system’s responsibility to daemonize programs and keep track of their processes and not all init/rc system needs pidfiles
2017-07-10 19:45:25 <pqatsi> jirutka: Im not
2017-07-10 19:45:39 <pqatsi> Im a enthusiast that uses it - also to work
2017-07-10 19:45:58 <jirutka> pqatsi: then why have you put @zerotier into Maintainer and Contributor…?
2017-07-10 19:46:40 <pqatsi> jirutka: My PR is based on https://github.com/alpinelinux/aports/pull/1379 - from the original mantainer of ZT
2017-07-10 19:47:07 <pqatsi> So I tried to fix every note made into this PR and send another PR
2017-07-10 19:47:24 <pqatsi> jirutka: Ive also asked for the original PR to the mantainer and i got no awnser
2017-07-10 19:47:38 <jirutka> how do you know that the person from zerotier still wants to maintain it?
2017-07-10 19:48:09 <pqatsi> jirutka: Ive asked for help in https://twitter.com/pqatsi/status/882960540875796480
2017-07-10 19:48:29 <jirutka> aha
2017-07-10 19:48:33 <pqatsi> jirutka: I dont mind mantaining it, but I just want to make all corrections you wanted
2017-07-10 19:48:47 <pqatsi> Because I want ZT in Alpine (Better if in the right way)
2017-07-10 19:49:47 <jirutka> afk
2017-07-10 23:44:21 <kolbyjack> Is it okay to create a PR for a busybox feature that's in their git (crond named time support), or is the policy just to wait until busybox cuts the next release?
2017-07-10 23:49:23 <Shiz> latter, the PR won't help much if it's not in the release
2017-07-10 23:57:35 <jirutka> kolbyjack: well, you can backport it to the current stable version
2017-07-10 23:58:26 <Shiz> depends how relevant/vital it is
2017-07-10 23:59:54 <jirutka> yeah
2017-07-11 00:15:04 <kolbyjack>  It's not vital, it's just support for named times in cron
2017-07-11 00:15:58 <kolbyjack> I like to use @reboot for startup jobs as a non privileged user
2017-07-11 02:55:34 <mitchty> kaniini: i think you're right that its a buffer overrun, is definitely a BUG() or similar getting hit (i'm more used to the kernel than userspace) https://gist.github.com/mitchty/893559a2906a2767f0ff235f4bf715db i'm going to compile busybox and leave debug symbols in so I dont have to reverse engineer that binary
2017-07-11 02:57:24 <mitchty> least i know of BUG() in the kernel basically being ud2 on x86_64, so not a huge shock to see that there
2017-07-11 06:50:55 <fabled> kaniini, the musl guard page size change makes pthread_create fail randomly, perhaps kernel bug?
2017-07-11 07:00:38 <fabled> kaniini, clone() will fail with -1 EPERM semi-randomly. perhaps related to stack alignment
2017-07-11 08:59:14 <clandmeter> fabled, seems that rpi fix also made my zerow boot. thx for that.
2017-07-11 09:16:33 <clandmeter> fabled, seems as the rpi3 family need additional firmware to make wifi working. are you ok with http://tpaste.us/QDQ4 ?
2017-07-11 09:55:07 <clandmeter> jirutka, seems the lxc alpine template has 2 issues.
2017-07-11 09:57:28 <clandmeter> if the download of the key fails and csums are false, it should delete the faulty (empty) key
2017-07-11 09:58:11 <clandmeter> and alpinelinux.org forwards to https now. so it should depend on libressl for the ssl helper.
2017-07-11 09:58:26 <ncopa> it should not try download keys if they are there
2017-07-11 09:58:46 <ncopa> http://tpaste.us/K6Ng
2017-07-11 09:58:58 <ncopa> was needed for ppc64le
2017-07-11 10:03:05 <fabled> clandmeter, the firmware is non-free? is there any license restrictions?
2017-07-11 10:03:46 <clandmeter> I have no idea
2017-07-11 10:03:54 <fabled> kaniini, nevermind the guard page size thing. i wonder why in my testing it seemed to fix the issue; it was instead seccomp() thing in firefox sandbox
2017-07-11 10:04:03 <clandmeter> i think it was handed over in some tarball and somebody put it online
2017-07-11 10:04:26 <ncopa> fabled: i disabled use of wordexp in alsa-lib
2017-07-11 10:04:26 <clandmeter> it also works with just the txt file.
2017-07-11 10:04:49 <fabled> clandmeter, the license text seems to be: https://github.com/RPi-Distro/firmware-nonfree/blob/master/brcm80211/LICENSE
2017-07-11 10:08:27 <clandmeter> fabled, not a license specialist here. the bins are not identical from kernel repo vs that other repo.
2017-07-11 10:11:13 <ncopa> the above url has "firmware-nonfree"
2017-07-11 10:11:26 <ncopa> so i'd expect it to not be free
2017-07-11 10:13:56 <clandmeter> are all firmware's "free" in linux-firmware.git?
2017-07-11 10:14:21 <ncopa> dunno
2017-07-11 10:19:04 <fabled> normally firmwares are non-free one way or the other
2017-07-11 10:19:10 <fabled> just need to check we can ship it
2017-07-11 10:19:37 <fabled> i think we need to ship the license terms as minimum
2017-07-11 10:23:05 <fabled> ncopa, clandmeter : we should probably change the license=GPL to license="custom:multiple"  or something similar for linux-firmware
2017-07-11 10:23:16 <fabled> clandmeter, i think adding the license + the above change together would be ok
2017-07-11 10:23:33 <fabled> oh, add it only for arm* architectures
2017-07-11 10:23:58 <clandmeter> ok
2017-07-11 10:24:55 <clandmeter> so i include the license in the brcm dir?
2017-07-11 10:26:39 <fabled> yeah, as LICENSE.brcm80211 or something similar like the other license files
2017-07-11 10:26:50 <fabled> oh
2017-07-11 10:26:56 <fabled> we don't ship the other licenses?
2017-07-11 10:27:25 <fabled> ncopa, ^
2017-07-11 10:27:41 <clandmeter> doesnt look like it.
2017-07-11 10:27:58 <clandmeter> we should provide it per doc pkg?
2017-07-11 10:35:02 <fabled> dunno how it should be done. ncopa, any thoughts?
2017-07-11 10:57:29 <ncopa> hm
2017-07-11 10:57:56 <ncopa> i dunno if its sufficient to provide the license in -doc package
2017-07-11 10:58:19 <ncopa> if its not then we'll have to ship it in /usr/share/licenses or similar
2017-07-11 11:16:43 <^7heo> moin
2017-07-11 12:50:44 <ncopa> jirutka: ok if i tag new lua-aports release?
2017-07-11 13:47:42 <jirutka> if?
2017-07-11 14:27:20 <ncopa> jirutka: i saw you have various commits in lua-aports, i wonder if it is ok to tag new release or if something needs be completed first
2017-07-11 17:31:10 <jirutka> ncopa: I never commit incomplete code into master
2017-07-11 17:31:59 <jirutka> ncopa: it can be released, there are some non-breaking additions, so increment minor version
2017-07-11 17:32:15 <jirutka> ncopa: huh, the last stabler elease is 2 years old o.O
2017-07-11 17:36:42 <jirutka> CfP for LinuxDays 2017 (https://www.linuxdays.cz/2017/en/) is open (since June), we should start preparing presentations :) /cc ncopa, skarnet, Shiz, kaniini, …
2017-07-11 18:30:50 <ncopa> jirutka: i occatinoally commit incomplete code to testing
2017-07-11 18:31:03 <ncopa> so people can test it early
2017-07-11 18:34:32 <ncopa> jirutka: since you're a lua hacker...
2017-07-11 18:34:52 <ncopa> im thinking of use this: https://github.com/hoelzro/lua-linenoise
2017-07-11 18:35:47 <ncopa> but im not happy how the callback calls the addcompletion (see example at the bottom)
2017-07-11 18:36:15 <ncopa> i'd like to do: c:addcompletion('help')
2017-07-11 18:37:21 <ncopa> eg: http://tpaste.us/Bezk
2017-07-11 18:43:01 <ncopa> as i understand, i need to luaL_setfuncs on the userdata type
2017-07-11 18:43:07 <ncopa> my lua is a a bit rusty...
2017-07-11 18:51:59 <jirutka> I’ve prepared wiki page about LinuxDays / Alpine Miniconf https://wiki.alpinelinux.org/wiki/LinuxDays2017
2017-07-11 18:52:28 <jirutka> ncopa: well, then you should create a feature branch… for incomplete code
2017-07-11 18:53:10 <ncopa> defeats the purpose since builders does not build those
2017-07-11 18:56:57 <jirutka> ncopa: hm, what you want should be possible to do, but I don’t know Lua C API so well
2017-07-11 18:57:19 <ncopa> its possible, and i think its trivial
2017-07-11 18:57:23 <ncopa> ok
2017-07-11 18:57:31 <ncopa> im reading up on the C api
2017-07-11 18:57:35 <jirutka> yeah, should be trivial, it’s more-or-less just a syntactic sugar
2017-07-11 18:58:43 <ncopa> i think i need create a luaL_Reg table and luaL_setfuncs on __index or similar
2017-07-11 18:59:26 <jirutka> ncopa: please add yourself to the Attendees list on https://wiki.alpinelinux.org/wiki/LinuxDays2017 :)
2017-07-11 19:01:07 <ncopa> would be nice
2017-07-11 19:02:11 <ncopa> not sure i will be able to attend
2017-07-11 19:02:15 <ncopa> i'll check it up
2017-07-11 19:02:41 <jirutka> are there enough information on this wiki page (and conference web)? something missing?
2017-07-11 19:02:51 <jirutka> I’ll send it to ML later
2017-07-11 19:02:55 <ncopa> which language is linuxdays in?
2017-07-11 19:03:15 <ncopa> the talk you did last year was not english :)
2017-07-11 19:06:40 <jirutka> aha, i forgot to note it
2017-07-11 19:06:45 <jirutka> it’s in Czech and English
2017-07-11 19:07:23 <jirutka> the goal for this year is to have at least 1/3 talks in English; I assume that all talks included in “Alpine Miniconf” will be in English :)
2017-07-11 19:09:04 <clandmeter> little late...
2017-07-11 19:10:54 <jirutka> late?
2017-07-11 19:11:51 <clandmeter> the topic...
2017-07-11 19:12:32 <jirutka> aha
2017-07-11 22:12:56 <BitL0G1c> travis needs an apk update - py-elasticsearch (missing)
2017-07-11 22:16:48 <jirutka> BitL0G1c: nope, build is always started in fresh new environment
2017-07-11 22:17:26 <jirutka> BitL0G1c: what PR is failing due to this?
2017-07-11 22:18:47 <BitL0G1c> https://github.com/alpinelinux/aports/pull/1907 - I've set it off again using py2-elasticsearch
2017-07-11 22:19:31 <jirutka> it’s in community, but py-elasticsearch is in testing…
2017-07-11 22:20:02 <BitL0G1c> aha - ok so move py-elasticsearch to community
2017-07-11 22:20:29 <jirutka> if it really works…
2017-07-11 22:21:35 <BitL0G1c> nxtool -x works - I'll do a bit more testing just in case
2017-07-11 22:22:03 <jirutka> I mean py-e…s…
2017-07-11 22:22:39 <BitL0G1c> nxtool queries the elasticsearch container ok
2017-07-11 22:23:14 <BitL0G1c> will test a bit more
2017-07-11 23:26:02 <jirutka> fyi, binaryen is going to use our alpine-chroot-install for testing build on various architectures and producing statically linked binaries :) https://github.com/WebAssembly/binaryen/pull/1064
2017-07-12 07:20:56 <fcolista> hi
2017-07-12 07:21:23 <clandmeter> howdy
2017-07-12 07:21:29 <clandmeter> how can we help you
2017-07-12 07:25:52 <ncopa> hi
2017-07-12 07:26:08 <ncopa> a coffe would help...
2017-07-12 07:27:23 <clandmeter> apk fetch coffee
2017-07-12 07:27:55 <clandmeter> its the best i can do.
2017-07-12 07:28:01 <ncopa> lol
2017-07-12 07:30:53 <fabled> kaniini, someone is looking at buildbot already, if there's others willing to work on it, it'd be good to join forces
2017-07-12 07:32:18 <kaniini> fabled: buildbot + homu seems like it can do even more than what our current workflow supports, it seems like we could enable a fedora-like workflow where things are automatically accepted by trusted maintainers after enough +1's and testing to prove it wont break
2017-07-12 07:32:29 <kaniini> the more i read about it, the more i like :)
2017-07-12 07:33:00 <fabled> yes, my vision was for buildbot to do the merging and automatic test-builds on all supported platforms
2017-07-12 07:33:07 <fabled> looking at homu
2017-07-12 07:36:59 <kaniini> i think homu would have to be modified, but it is fairly close to what i think we actually want
2017-07-12 07:39:37 <fabled> kaniini, eventually i would like buildbot plugin that can parse aports and schedule individual aport builds based on the dependencies
2017-07-12 07:39:59 <fabled> but just to start is to build-all, manage that from central node and then collect all .apks from the builders
2017-07-12 07:45:27 <kaniini> ah like debian wanna-build ?
2017-07-12 07:46:44 <fabled> something like that
2017-07-12 07:47:06 <fabled> and use the new 'abuild rootbld' thingy so one buildbot slave can build any branch's packages
2017-07-12 07:47:17 <fabled> so we don't need to create LXCs on branching
2017-07-12 07:47:28 <kaniini> how does rootbld work
2017-07-12 07:48:38 <fabled> in aports.git you configure the binary repo, and it'll create new chroot from those binary repos, and then execute further abuild steps inside the chroot
2017-07-12 07:49:06 <fabled> basically you get clean environment based on given repository url for each build
2017-07-12 07:49:20 <fabled> helps also to test that dependencies are correct on developer machines
2017-07-12 07:49:44 <kaniini> configure how
2017-07-12 07:50:51 <fabled> https://git.alpinelinux.org/cgit/abuild/commit/?id=ee52fee11ce09abf3b070cbfb3697646c24f51e5
2017-07-12 07:50:54 <fabled> needs doc
2017-07-12 07:51:14 <fabled> kunkku, could you add an example how to configure the rootbld thingy? and include it in aports.git too
2017-07-12 07:52:01 <fabled> but basically you need main/.rootbld-repositories and community/.rootbld-repositories
2017-07-12 07:52:03 <kaniini> ah, i see how it works.
2017-07-12 10:33:39 <fabled> s390x builder seems hung..?
2017-07-12 14:15:14 <^7heo> Is Bruno Leiato here?
2017-07-12 14:15:24 <^7heo> sorry, Breno
2017-07-12 14:15:53 <^7heo> (I hope I didn't offend Breno by butchering his name =/)
2017-07-12 14:22:25 <skarnet> no problem, Teho
2017-07-12 15:00:00 <leitao> ^7heo: hello Sir!
2017-07-12 15:00:11 <leitao> that is Breno! :-)
2017-07-12 15:00:13 <^7heo> ah leitao is your nick ;)
2017-07-12 15:00:33 <^7heo> I tried b<tab>, bl<tab>, bre<tab> but not le<tab> ;)
2017-07-12 15:00:57 <^7heo> So first off, thanks a lot for your mail :)
2017-07-12 15:01:17 <leitao> ^7heo: sure. I just want to make sure that we had the problem well stated.
2017-07-12 15:01:34 <^7heo> I find it very useful when people focus on problems rather than "why not solution X"
2017-07-12 15:01:49 <^7heo> yeah it's a very good move.
2017-07-12 15:02:43 <rdutra> ^7heo: yeah, sorry, I think I was not very happy with my email
2017-07-12 15:02:49 <rdutra> but was not the intention
2017-07-12 15:03:21 <^7heo> the whole issue, and the main reason why I first answered like I did; was the paternizing tone of the email from Yves
2017-07-12 15:03:33 <^7heo> essentially saying "Jenkins über alles!"
2017-07-12 15:03:47 <^7heo> which made me react a bit strongly.
2017-07-12 15:04:10 <^7heo> I do have, like many other alpine contributors, a strong aversion vis a vis Jenkins
2017-07-12 15:04:57 <^7heo> and I do not wish, under any circumstances, to have to put in the considerable effort to do the legwork to mathematically prove why it sucks.
2017-07-12 15:06:03 <^7heo> ultimately, as ncopa pointed out; it falls on the person caring for it to chose what will be their poison.
2017-07-12 15:06:10 <^7heo> Salut user.
2017-07-12 15:06:48 <rdutra> ^7heo: I understand, anyway, sorry if I was not very clear with what I wanted to suggested and made anyone uncomfortable
2017-07-12 15:07:07 <^7heo> But to get back on topic with the CI solution; I unfortunately sincerely believe there is no existing good solution.
2017-07-12 15:07:14 <^7heo> Every solution out there is terrible to some degree.
2017-07-12 15:07:18 <^7heo> Including Travis.
2017-07-12 15:07:52 <ncopa> so it will be a tradeoff regardless what we do
2017-07-12 15:08:00 <^7heo> yes.
2017-07-12 15:08:06 <^7heo> like anything ;)
2017-07-12 15:08:29 <^7heo> but in this particular case it is very important IMHO to be extremely careful in evaluating the costs vs gains
2017-07-12 15:08:35 <^7heo> unless we're chosing a temporary solution
2017-07-12 15:08:39 <^7heo> (like Travis)
2017-07-12 15:08:46 <^7heo> rdutra: No need to apologize; if anything, you were right to speak up to point your issues with the existing toolchain.
2017-07-12 15:09:42 <^7heo> I feel sorry too that I reacted so strongly about the problem; but I do not know how to react in a better way that still prevents more time wasting with Jenkins.
2017-07-12 15:11:29 <ncopa> ^7heo: i think your point was clearly made in the email, and im sure it will be taken in consideration
2017-07-12 15:12:06 <ncopa> but i still think that the opinion to whoever gets his/her hands dirty has more weight
2017-07-12 15:14:36 <^7heo> definitely.
2017-07-12 15:14:46 <^7heo> I agree with you there.
2017-07-12 15:15:15 <^7heo> but it's a little difficult for anyone to get their hand dirty since the bus factor regarding the alpine infra is ridiculously low.
2017-07-12 15:15:28 <^7heo> i.e. finding info on what to do and how to participate is next to impossible
2017-07-12 15:15:32 <^7heo> if anything it's highly improbable.
2017-07-12 15:38:01 <user> Bonjour
2017-07-12 15:43:05 <Shiz> hola
2017-07-12 15:58:32 <^7heo> Shiz: what exactly is the point with your email?
2017-07-12 15:59:26 <^7heo> Shiz: do you feel like stepping in without context and blaming the person who supports the interest of the distribution vs adopting a broadly supported piece of crap?
2017-07-12 15:59:43 <^7heo> Shiz: if you do so, please do not contribute to Alpine, it is not what it is about AFAIK.
2017-07-12 15:59:52 <Shiz> i'm not going to respond to someone who immediately jumps into a victim role
2017-07-12 16:00:12 <^7heo> Unless I'm not a white male, right?
2017-07-12 16:00:22 <^7heo> anyway.
2017-07-12 16:00:40 <^7heo> I think it was pretty much settled until you answered.
2017-07-13 05:37:27 <fabled> working on gcc 6.4.0
2017-07-13 06:22:17 <ncopa> we should rebuild all go packages with go 1.8.3
2017-07-13 06:22:36 <ncopa> due to CVE-2017-8932
2017-07-13 06:48:56 <fabled> ncopa, gcc 6.4.0 http://sprunge.us/fJYM -> tested on x86_64 and aarch64
2017-07-13 06:50:46 <fabled> also verified that aarch64's libgcc is not broken anymore with omit-frame-pointer
2017-07-13 06:51:13 <ncopa> nice!
2017-07-13 06:51:16 <ncopa> push it!
2017-07-13 06:51:48 <ncopa> i wonder if we should backport it to 3.6-stable
2017-07-13 06:52:51 <fabled> ok, let's see if it blows up on other arches ;)
2017-07-13 08:36:45 <fcolista> I've created a container with jenkins on Alpine
2017-07-13 08:37:16 <fcolista> I'm going to create the APKBUILD
2017-07-13 12:43:58 <ncopa> the make check thing caught another interesting bug
2017-07-13 12:44:35 <ncopa> rdutra found out why zstd fails on ppc64le
2017-07-13 12:44:41 <ncopa> or why the testsuite fails
2017-07-13 12:44:45 <ncopa> and its hilarious
2017-07-13 12:45:00 <ncopa> turns out that they have a maxthreads = 128
2017-07-13 12:45:16 <rdutra> ppc64le has 190 cores and zstd allow just 128 and breaks the execution lol
2017-07-13 12:45:17 <ncopa> and if you have more than 128 cores, it wil give up
2017-07-13 12:45:34 <ncopa> https://github.com/facebook/zstd/blob/132e6efd760b97403f1e84c6c4e4ee6569fad605/lib/compress/zstdmt_compress.c#L12
2017-07-13 12:45:46 <ncopa> https://github.com/facebook/zstd/blob/132e6efd760b97403f1e84c6c4e4ee6569fad605/lib/compress/zstdmt_compress.c#L410
2017-07-13 12:45:53 <ncopa> i find it hilarious! :D
2017-07-13 12:46:01 <fabled> so file a bug... "add proper multicore support"
2017-07-13 12:46:08 <fabled> :)
2017-07-13 12:46:16 <ncopa> looks like its facebooks code
2017-07-13 15:08:55 <_ikke_>                                                                                                                                                      │ hl
2017-07-13 15:08:56 <_ikke_> 14:44:45       ncopa │ and its hilarious                                                                                                                                                                                     │ hrmlgon-z
2017-07-13 15:09:05 <Shiz> same
2017-07-13 15:09:36 <ncopa> i think it also show what a good idea it was to enable the tests
2017-07-13 15:11:00 <_ikke_> sorry bout that
2017-07-13 16:14:59 <ncopa> i think we have a bug in setup-disk: #7524
2017-07-13 16:15:17 <ncopa> it does not set up fstab to fsck the filesystems
2017-07-13 18:28:03 <vkrishn> web-pannic!! cannot connect to kernel.org
2017-07-13 19:14:18 <scadu> https://www.twistlock.com/2017/07/13/alpine-linux-pt-2-twistlock-security-alert/ aw yis, here's 2nd part
2017-07-13 20:03:52 <ncopa> i just pushed 4.9.37-hardened
2017-07-13 20:04:04 <ncopa> watch out for it. it may kill your cat
2017-07-13 20:11:19 <skarnet> onoes
2017-07-13 20:11:21 <skarnet> not my cat
2017-07-13 20:13:50 <scadu> uff, I have no cat
2017-07-13 20:14:00 <scadu> (he died after the latest update)
2017-07-13 20:27:28 <vkrishn> ncopa, could you have a look at #7178 pls
2017-07-13 20:28:19 <vkrishn> was reading about it a month back or so,  seem nice to have it enabled
2017-07-13 23:02:58 <mitchty> i was kinda surprised not to see it included
2017-07-13 23:17:11 <mkbucc> greetings
2017-07-13 23:18:11 <mkbucc> how can i build top with debug symbols?
2017-07-13 23:18:41 <mkbucc> and then run that new binary?
2017-07-13 23:18:54 <mkbucc> it's been a while since i've done c and am new to alpine.
2017-07-13 23:18:58 <mkbucc> but am trying to fix a bug
2017-07-13 23:19:19 <mkbucc> i downloaded aports, and abuild works on main/procps
2017-07-13 23:21:18 <mkbucc> on 3.6.2 i can make top crash after starting ghc daemon
2017-07-13 23:21:47 <mkbucc> and ls of an empty directory takes 30 seconds
2017-07-13 23:24:34 <mkbucc> https://bugs.alpinelinux.org/issues/7340#change-19901
2017-07-13 23:24:37 <mkbucc> is bug report
2017-07-13 23:30:55 <mkbucc> i want to run top in gdb, get the line number where it crashes, then look at the actual, C source that was used to build the binary
2017-07-14 13:48:11 <andypost> Any idea why edge can't install openssh? >ERROR: openssh-client-7.5_p1-r2: BAD signature
2017-07-14 13:54:13 <Shiz> oh dear
2017-07-14 13:54:21 <Shiz> have you tried a different mirror?
2017-07-14 14:14:58 <^7heo> andypost: yeah what mirror is this on?
2017-07-14 14:15:26 <andypost> yep, other mirror works
2017-07-14 14:15:39 <^7heo> andypost: which one did you use?
2017-07-14 14:15:50 <andypost> only default fails dl-cdn.alpinelinux.org
2017-07-14 14:16:02 <andypost> nl.alpinelinux.org - works
2017-07-14 14:18:54 <^7heo> yeah but dl-cdn is failing is pret-ty bad.
2017-07-14 14:21:15 <ncopa> i know why
2017-07-14 14:21:26 <ncopa> openssh was likely rebuilt
2017-07-14 14:21:40 <ncopa> and dl-cdn has the old build in cache
2017-07-14 14:21:51 <ncopa> but checksum changed in APKINDEX
2017-07-14 14:22:02 <ncopa> we should bump pkgrel
2017-07-14 14:23:25 <ncopa> openssh should not have been rebuilt, but i think it was du to a bug in lua-aports
2017-07-14 14:23:37 <ncopa> i pushed a pkgrel bump
2017-07-14 14:37:29 <^7heo> :)
2017-07-14 15:39:27 <ncopa> TBB: i understand that you have some experience with LUKS
2017-07-14 15:39:57 <ncopa> TBB: do you have any opinion on boot args for encrypted root fs?
2017-07-14 15:40:02 <ncopa> http://lists.alpinelinux.org/alpine-devel/5710.html
2017-07-14 15:43:50 <^7heo> didn't I already do that?
2017-07-14 15:44:29 <^7heo> also, please do not concatenate identifiers, we might want to use GUIDs.
2017-07-14 15:45:03 <^7heo> (or other not-so-easy-to-parse data)
2017-07-14 15:45:17 <^7heo> s/parse/&-when-concatenated/
2017-07-14 15:45:22 <^7heo> ncopa: ^
2017-07-14 15:57:18 <ncopa> i think i remember someone had an opionion about it
2017-07-14 15:57:25 <ncopa> but i could not remember who or what it was
2017-07-14 15:57:43 <ncopa> ^7heo: do you mind responding to the alpine-devel list?
2017-07-14 15:58:43 <^7heo> my mail client does a lot of crap with mailing lists
2017-07-14 15:58:46 <^7heo> for some reason
2017-07-14 15:58:52 <^7heo> I could, but not from my phone.
2017-07-14 15:58:54 <^7heo> from home, later.
2017-07-14 19:29:57 <pie3> hi
2017-07-14 19:30:01 <pie3> anyone can help me?
2017-07-14 19:30:17 <Shiz> whats up
2017-07-14 19:30:43 <pie3> i am facing issue in apline set up in virtual box
2017-07-14 21:01:03 <jirutka> fabled: I think that every core dev should now that security upgrades/fixes should be backported to stable branches…
2017-07-14 21:01:08 <jirutka> fabled: https://github.com/alpinelinux/aports/pull/1909
2017-07-14 21:02:10 <scadu> jirutka: j-j-j-just run edge on production, right XD
2017-07-14 21:02:44 <jirutka> scadu: I never run edge on production, I always backport pkgs to stable branch in my repository when I need newer version of pkg
2017-07-14 21:03:11 <scadu> jirutka: I was just kidding. there is too many useful stuff in edge which somehow weren't backported to stable branch :(
2017-07-14 21:03:18 <vkrishn> jirutka, if you looking at new lua pkgs, could you pls look at, http://sophia.systems/ and its bindings/drivers, eg tarantool
2017-07-14 21:03:42 <vkrishn> seems nice for AL point
2017-07-14 21:03:43 <jirutka> scadu: only bugfixes and most importantly security fixes should be backported to stable branches, not new features
2017-07-14 21:04:54 <jirutka> vkrishn: hmm, Tarantool looks interesting!
2017-07-14 21:05:17 <jirutka> vkrishn: just don’t like the name, it reminds me tarantula…
2017-07-14 21:05:36 <vkrishn> :-)
2017-07-14 21:05:42 <vkrishn> its "A drop-in replacement for Lua 5.1, based on LuaJIT 2.1"
2017-07-14 21:06:33 <vkrishn> with built in nosql support
2017-07-14 21:10:14 <jirutka> I should probably officially take maintainership of nodejs, the current maintainer is not active for a long time
2017-07-14 21:24:31 <mitchty> kaniini: thanks for the help with the busybox top stuff, out of curiosity how did you rebuild busybox or determine it was a grsecurity mitigation? That way I can better debug these things in future
2017-07-14 21:27:04 <kaniini> tarantool lacks machine learning therefore who cares
2017-07-14 21:27:40 <kaniini> if it doesnt do machine learning, it's OBSOLETE
2017-07-14 21:29:26 <vkrishn> any example of nosql+m.l ?
2017-07-14 21:29:32 <vkrishn> written in c
2017-07-14 21:30:10 <jirutka> damn, Linux kernel do not use machine learning, we must write new kernel NOW!
2017-07-14 21:31:53 <vkrishn> tarantool and tool here, https://github.com/tarantool/ do [al]most of things I was thinking to do my first iot testing
2017-07-14 21:32:58 <vkrishn> even mqtt, http://highscalability.com/blog/2017/1/23/master-master-replication-and-scaling-of-an-application-betw.html
2017-07-14 21:36:32 <vkrishn> we can add to todo list for M.L+ AI for AL v4.0
2017-07-14 21:37:42 <jirutka> but coffee machine control should be first
2017-07-14 21:38:49 <vkrishn> imaging your were just thinking of coffee and apk serves it !
2017-07-14 21:39:01 <vkrishn> that would be AL4.0
2017-07-14 21:39:59 <jirutka> yeah, 1st apk add coffee; 2nd thinking about coffee automatically triggers `apk add coffee`
2017-07-14 21:41:08 <vkrishn> I wonder how to think and ask for 2nd cup/ refilling !! ;)
2017-07-14 21:43:54 <vkrishn> that could send apk to disastrous "cyclic cup[ling]"
2017-07-14 22:57:46 <mitchty> also q regarding perf, I really get nervous not having perf for debugging, I'm testing out adding perf as a subpkg of the kernel since its in that source tree, that sound ok or should it be a separate APKBUILD?
2017-07-14 22:59:03 <mitchty> also as far as I can tell, perf only works on x86 (32/64bit) arm (same) and s390 I think? i'm not well versed in what the power cpus do
2017-07-14 22:59:15 <mitchty> i mainly deal with x86_64 and arm
2017-07-14 23:02:48 <mitchty> can subpkgs restrict the arch they build on?
2017-07-14 23:08:19 <mitchty> anyway its beer o clock time while this compiles
2017-07-15 00:07:46 <jirutka> vkrishn: I have tarantool pkg almost ready
2017-07-15 00:18:12 <vkrishn> jirutka, how are third_party being processed, as separate pkgs
2017-07-15 02:19:58 <ollieparanoid[m]> I've written a post about the current progress of postmarketOS (which installs Alpine on smarthpones): https://ollieparanoid.github.io/post/50-days-of-postmarketOS/
2017-07-15 06:57:26 <_ikke_> ollieparanoid[m]: it even made it to HN
2017-07-15 11:26:03 <ollieparanoid[m]> ikke: yeah, I've posted it there. but it made the top 5 or so \o/
2017-07-15 11:28:03 <ollieparanoid[m]> and a very high position in /r/linux. someone wrote this comment there: "yay! alpine! the best linux distro. also a non-GNU distro. [...]" :)
2017-07-15 11:28:40 <ollieparanoid[m]> oh, I realize now that I posted this into #alpine-devel. sorry, I meant to post it in #alpine-offtopic
2017-07-15 11:28:48 <ollieparanoid[m]> the whole post thing
2017-07-15 13:33:17 <jirutka> clandmeter: how to use snapshot function, i.e. upload tarball to dev.a.o?
2017-07-15 13:33:51 <jirutka> kaniini: fabled: ^
2017-07-15 19:39:40 <vkrishn> nice list here, https://github.com/pmwkaa/engine.so (Embeddable data storage engines)
2017-07-15 19:40:24 <vkrishn> UnQLite/WhiteDB/Sophia seems interesting
2017-07-15 19:45:49 <_ikke_> !.
2017-07-15 20:28:54 <okeuday_bak> could there be some feedback on https://github.com/alpinelinux/aports/pull/1763 or a merge, it hasn't moved for awhile, would be nice to eventually be able to test it as a package on alpine
2017-07-16 13:30:52 <tdtrask> jirutka / kaniini: any thoughts on http://bugs.alpinelinux.org/issues/7531 - APK add --upgrade ignores --repository option
2017-07-16 13:31:14 <tdtrask> this is causing a problem in the ansible apk module
2017-07-16 13:31:31 <tdtrask> upgrades are available, but don't take place
2017-07-16 13:32:11 <jirutka> tdtrask: it looks like a reasonable feature, but i don’t know apk internals and how it may increase complexity, so cannot say; ask fabled and kaniini
2017-07-16 13:42:52 <tdtrask> fabled would be my go-to person, but he's not here now
2017-07-16 13:42:57 <tdtrask> probably have to wait til tomorrow
2017-07-16 15:31:19 <^7heo> damn, when your MUA does crap, it's really inconenient to follow a ML =/
2017-07-16 16:15:25 <^7heo> ncopa: what email is the previous email in this thread? http://lists.alpinelinux.org/alpine-devel/5710.html
2017-07-16 16:15:28 <^7heo> ?
2017-07-16 16:19:11 <_ikke_> ^7heo: do you mean Nathanaels e-mail?
2017-07-16 16:20:25 <_ikke_> ^7heo: http://tpaste.us/aQNm
2017-07-16 16:24:28 <^7heo> _ikke_: it's weird, I don't find it in the ML...
2017-07-16 16:27:59 <_ikke_> Cannot find it either, but I did receive it..
2017-07-16 16:28:27 <^7heo> I have no email from the alpine-devel list from 2017-06-13T10:38:00Z (A.Wilcox - Re: [alpine-devel] A few questions about Alpine) to 2017-06-15T20:01:32Z (Cág - [alpine-devel] Alpine features and the future)
2017-07-16 16:28:44 <^7heo> absolutely nothing.
2017-07-16 16:29:52 <_ikke_> that's devel, not aports
2017-07-16 16:30:01 <^7heo> oooh
2017-07-16 16:30:13 <^7heo> right.
2017-07-16 16:30:17 <^7heo> Thanks for pointing it out.
2017-07-16 16:30:23 <^7heo> I do not know if I have subscribed to aports
2017-07-16 16:57:25 <sh4rm4^bnc> ncopa: icu 59.1 is out
2017-07-16 16:57:51 <sh4rm4^bnc> maybe it fixes the thing you have that iterator patch for
2017-07-16 17:07:22 <^7heo> _ikke_: thanks a bunch for a the link; helps a lot
2017-07-16 17:08:12 <_ikke_> ^7heo: np
2017-07-17 12:16:57 <^7heo> Does anyone here know a good european VPS provider that has alpine available as a system?
2017-07-17 12:47:32 <scadu> ^7heo: Vultr, Scaleway
2017-07-17 13:13:30 <^7heo> scadu: vultr is where I'm at
2017-07-17 13:13:41 <^7heo> scadu: the network ist komplett scheiß
2017-07-17 13:13:49 <^7heo> scaleway... not interested.
2017-07-17 13:14:46 <scadu> ^7heo: why?
2017-07-17 13:15:22 <^7heo> Because Alpine had an issue with them
2017-07-17 13:16:07 <scadu> ^7heo: oh, and still Alpine infrra uses Scaleway
2017-07-17 13:16:44 <^7heo> Hey, free stuff is free ;)
2017-07-17 13:29:54 <ncopa> i think scaleway can be ok, depends a bit on the application
2017-07-17 13:36:12 <^7heo> possibly, but I know upcloud it okay
2017-07-17 13:36:44 <^7heo> so I'll just take the time to write a packer manifest for my own upcloud alpine image.
2017-07-17 13:36:52 <^7heo> and I'll send that to upcloud
2017-07-17 13:36:55 <^7heo> so they can make it official
2017-07-17 14:00:42 <_ikke_> https://www.twistlock.com/2017/07/13/alpine-linux-pt-2-twistlock-security-alert/
2017-07-17 14:02:28 <scadu> already posted here
2017-07-17 14:02:40 <_ikke_> ah ok, missed it then
2017-07-17 14:09:57 <^7heo> Those CVEs are not yet public.
2017-07-17 14:10:05 <^7heo> did we get emails for them?
2017-07-17 14:11:38 <^7heo> fabled: ^
2017-07-17 14:12:08 <^7heo> (not from Ariel Zelivansky himself, but from mitre)
2017-07-17 14:12:18 <scadu> ^7heo: iirc fabled and the guy from twistlock were discussing this on private email
2017-07-17 14:12:23 <scadu> oh
2017-07-17 14:12:26 <^7heo> yeah that's why I explicited.
2017-07-17 14:14:23 <^7heo> ncopa: Shiz ^
2017-07-17 14:18:40 <ncopa> its fixed
2017-07-17 14:19:34 <ncopa> was fixed in apk-tools-2.7.2,  Fri Jun 23
2017-07-17 14:19:53 <^7heo> that wasn't the question.
2017-07-17 14:20:27 <^7heo> the question was about the mitre feedback channel; if it works or not.
2017-07-17 14:21:10 <^7heo> because I remember that when Shiz and jirutka reported the CVE they found; mitre (AFAIR) did ask for an email contact.
2017-07-17 14:21:25 <^7heo> I have not followed more than that, but since this comes up now, I thought I'd ask.
2017-07-17 14:36:05 <ncopa> i dont think the gpg channel is up yet
2017-07-17 14:36:24 <ncopa> rnalrd: were you working on that gpg remailer?
2017-07-17 14:42:41 <rnalrd> nope
2017-07-17 14:43:00 <rnalrd> clandmeter was on it, iirc
2017-07-17 14:43:27 <clandmeter> yes, it is on my todo.
2017-07-17 14:46:42 <^7heo> ok, so short of infosec researchers contacting us...
2017-07-17 14:46:46 <^7heo> we're blind?
2017-07-17 15:32:23 <ncopa> they can contact us individually
2017-07-17 15:32:34 <ncopa> which is what happened in the apk case
2017-07-17 15:33:07 <ncopa> they can also file a bug on bugs.alpinelinux.org and mark it as private
2017-07-17 15:33:48 <ncopa> sigh
2017-07-17 15:33:55 <ncopa> we have a problem with the builders
2017-07-17 15:34:05 <ncopa> abuild is broke
2017-07-17 15:34:19 <ncopa> and builders fails to build the fixed abuild
2017-07-17 16:18:01 <jirutka> ncopa: IIRC Shiz prepared GPG remailer…
2017-07-17 16:18:16 <scadu> lel
2017-07-17 16:27:30 <ncopa> jirutka: i know, itsjust the final integration thats left
2017-07-17 16:27:33 <ncopa> and generating keys etc
2017-07-17 16:27:38 <jirutka> yeah
2017-07-17 16:54:30 <^7heo> Do we have a way to fit Alpine in 2MB?
2017-07-17 16:54:44 <^7heo> (with a trimmed kernel obv)
2017-07-17 16:57:16 <lxGzx53qO34r> that would be quite interesting for a coreboot payload, even if a bit bigger even...
2017-07-17 16:58:20 <^7heo> yeah I would also be interesed in that
2017-07-17 16:58:27 <^7heo> s/sed/sted/
2017-07-17 16:58:36 <^7heo> for fitting it in old routers.
2017-07-17 16:58:59 <^7heo> since _ikke_ (I think?) pointed out that I didn't use Alpine on ALL of my machines, I would like to try
2017-07-17 17:06:57 <lxGzx53qO34r> hehe
2017-07-17 17:12:54 <_ikke_> ^7heo: You can also run alpine on a mobile device
2017-07-17 17:12:56 <_ikke_> :P
2017-07-17 17:13:07 <_ikke_> PostMarket OS
2017-07-17 17:16:36 <^7heo> yeah no.
2017-07-17 17:16:41 <^7heo> first off
2017-07-17 17:16:51 <^7heo> it's definitely advertized as non-production
2017-07-17 17:16:55 <^7heo> and second off
2017-07-17 17:17:01 <^7heo> it's definitely not ready.
2017-07-17 17:17:44 <^7heo> eating your own dogfood isn't about being as stupid as possible or as brain-dead-following-the-scriptures as possible (that's for GNU people only anyway)
2017-07-17 17:18:18 <^7heo> it's about using your product for all the things YOU need that are supported by your product.
2017-07-17 17:18:28 <_ikke_> ^7heo: note the ":P"
2017-07-17 17:18:30 <^7heo> ok ok :D
2017-07-17 17:18:47 <^7heo> but yeah when Postmarket OS will be supported
2017-07-17 17:18:54 <^7heo> I guess I'll have to use a shitty phone then
2017-07-17 17:18:56 <^7heo> 
ACTION hides

2017-07-17 20:03:17 <ncopa> did we have a wiki page or something that explained the rules for version string?
2017-07-17 20:05:15 <_ikke_> I'm not aware of any
2017-07-17 20:05:27 <_ikke_> the reference page does not mention anything about the format
2017-07-17 20:13:55 <ncopa> im am sure i have seen one
2017-07-17 20:14:01 <ncopa> but it was probably for gentoo
2017-07-17 20:14:04 <ncopa> a decade ago
2017-07-17 21:52:52 <jirutka> _ikke_: ncopa: https://devmanual.gentoo.org/ebuild-writing/file-format/, you can find some examples even in specs of https://github.com/jirutka/gversion.lua
2017-07-18 12:26:24 <ncopa> does anybody know how to run a single test in php7 build? https://github.com/alpinelinux/aports/pull/1851
2017-07-18 12:55:38 <PureTryOut[m]> hey guys I was wondering, why is qt5-qtscript blocked for the armhf architecture? it's the only one left out, and just the one I need
2017-07-18 13:00:07 <Shiz> seems it's due a build failure
2017-07-18 13:00:20 <Shiz> as of 5.6.1
2017-07-18 13:00:30 <Shiz> may be fixed in the current version, however
2017-07-18 13:00:36 <Shiz> I sadly don't have an armhf builder right here to test
2017-07-18 13:00:52 <PureTryOut[m]> well I have and I was trying to update it, but sadly the Qt downloads page is down so it fails to retrieve the source
2017-07-18 13:01:13 <PureTryOut[m]> but I thought it would be good to know why it wasn't updated in the first place
2017-07-18 13:01:32 <PureTryOut[m]> can I see the build failure somewhere?
2017-07-18 13:02:02 <Shiz> it's in the git log
2017-07-18 13:02:04 <Shiz> https://git.alpinelinux.org/cgit/aports/commit/main/qt5-qtscript?id=3c24f0a29e351a57cf59e45077fae63aaabb5fae
2017-07-18 13:02:48 <PureTryOut[m]> interesting how that git message talks about failing on armhf, but the commit actually disables x86, not armhf
2017-07-18 13:04:00 <PureTryOut[m]> well, I'll try building it once the Qt download site is back up, and if it builds fine I'll look into submitting a patch
2017-07-18 13:04:32 <PureTryOut[m]> something might've fixed in the last 3 months
2017-07-18 13:04:47 <Shiz> yes, it comes with a follow-up commit that fixes that issue
2017-07-18 13:04:49 <Shiz> :P
2017-07-18 13:04:55 <Shiz> https://git.alpinelinux.org/cgit/aports/commit/main/qt5-qtscript?id=3c0d8ea5cbb2744c490b9ac8a83413e9734dcda6
2017-07-18 13:04:56 <PureTryOut[m]> huh
2017-07-18 13:05:02 <PureTryOut[m]> ooh
2017-07-18 14:29:23 <PureTryOut[m]> so, it did indeed compile fine now. interestingly enough though, a different package having `qt5-qtscript-dev` as dependency keeps complaining about the dependency still not being satisfied in the `cmake` fase
2017-07-18 14:30:16 <Shiz> do you have your own repo in /etc/apk/repos?
2017-07-18 14:30:19 <Shiz> repositories*
2017-07-18 14:30:22 <Shiz> and did an apk update?
2017-07-18 14:33:18 <PureTryOut[m]> well I have to admit 😉 I'm running it in the chroot provided by ollieparanoid's postmarketOS project, so I installed the package using `./pmbootstrap.py install --add qt5-qtscript-dev`, so no not a repo but installed from outside the system. inside the chroot `apk info qt5-qtscript-dev` does show it's installed fine though
2017-07-18 14:33:47 <PureTryOut[m]> (I'm assuming you guys know about the postmarketOS project)
2017-07-18 14:35:29 <PureTryOut[m]> running `apk update` inside the chroot and recompiling does not fix it
2017-07-18 14:36:10 <PureTryOut[m]> ooh actually the repo postmarketOS provides resides in `/home/user/packages/user` which *is* queried when running `apk update`
2017-07-18 14:47:11 <Shiz> :P
2017-07-18 14:47:26 <Shiz> i know pmOS exists, but i'm not familiar with any of its tooling
2017-07-18 14:48:01 <Shiz> but as long as your compiled packages, presuming you used abuild, are in a directory that's listed in /etc/apk/repositories and your key is in the right place too it should pick up your local pkg just fine
2017-07-18 14:51:20 <PureTryOut[m]> yeah it's in a repository that's listed in `/etc/apk/repositories`. to be fair, I'm not exactly sure where it installed it to on the system, I see no traces of it anywhere except for `apk` reporting it's installed
2017-07-18 14:54:17 <Shiz> if you used abuild, it will copy the .apk files to ~/packages by default
2017-07-18 14:54:31 <PureTryOut[m]> this apkbuild is a bit strange though. it has a line `makedepends="$depends_dev qt5-qtbase-dev` but when running `abuild` it reports it can't resolve `$depends_dev`. that variable is however defined above it
2017-07-18 14:54:51 <PureTryOut[m]> so to compile it I just removed that variable from that line for now, it's an empty variable anyway
2017-07-18 14:55:04 <PureTryOut[m]> it doesn't make sense but maybe that's it? not sure
2017-07-18 14:55:39 <PureTryOut[m]> Shiz: I meant once the package is installed, I'd expect it in `/usr/lib` somewhere
2017-07-18 14:55:59 <PureTryOut[m]> although there are Qt packages there, I see no qtscript anywhere. but I don't really know where to look
2017-07-18 14:56:11 <Shiz> apk info -L qt5-qtscript-dev
2017-07-18 14:56:37 <PureTryOut[m]> that reports nothing
2017-07-18 14:56:55 <PureTryOut[m]> so there is the problem then
2017-07-18 14:57:00 <PureTryOut[m]> it doesn't actually put the files anywhere lol
2017-07-18 14:57:57 <PureTryOut[m]> well I reran `apk add qt5-qtscript-dev` and now the files *are* installed, strange
2017-07-18 14:59:08 <PureTryOut[m]> still no luck running cmake though 😢
2017-07-18 15:00:02 <PureTryOut[m]> ooh never mind, that seems to be a tooling issue in pmOS
2017-07-18 15:00:46 <PureTryOut[m]> thanks for your help Shiz! `apk info -L` gave me the clue that I needed
2017-07-18 18:12:15 <ollieparanoid[m]> Shiz: Thanks for helping out! For some context, pmbootstrap uses abuild, but does its own dependency/APKBUILD parsing, before it calls abuild or apk. (dependency parsing is needed to resolve dependencies on its own aports folder and the APKINDEXes combined). The APKBUILD parsing is intentionally not emulating a complete shell, but only has some variables hardcoded, that's why it failed here. I hope, that we can
2017-07-18 18:12:16 <ollieparanoid[m]> make some decent upstreaming from the pmOS community to Alpine and don't bother you with unrelated stuff :)
2017-07-18 18:14:49 <PureTryOut[m]> well since qt5-qtscript does seem to compile fine again on armhf, I guess I'll look into upstreaming that, even if it's just removing the `!armhf` flag 😉
2017-07-18 20:44:34 <ncopa> im pushing icu-59 now
2017-07-18 20:44:41 <ncopa> it changes types in the public headers
2017-07-18 20:44:51 <ncopa> at least mapnik broke
2017-07-19 07:40:17 <Samvine> Hi all !
2017-07-19 07:41:45 <Samvine> I have an issue with Zabbix Agent for monitoring network interface. Zabbix use the /proc/net/dev, but with no-root user, all metrics are set to zero.
2017-07-19 07:42:48 <Samvine> Do you know how a normal user can access to this file with all metrics ?$
2017-07-19 07:56:48 <ncopa> Samvine: try add the user to the group "readproc"
2017-07-19 07:59:53 <ncopa> fcolista: i'd like to move the old webkitgtk to unmaintained
2017-07-19 08:00:02 <ncopa> there is a py-pywebkitgtk that uses it
2017-07-19 08:00:06 <ncopa> which you maintain
2017-07-19 08:00:16 <ncopa> do you mind if i move that to unmaintained as well?
2017-07-19 08:00:29 <fcolista> no problem ncopa
2017-07-19 08:00:33 <fcolista> go ahead
2017-07-19 08:00:39 <ncopa> thanks
2017-07-19 08:00:47 <ncopa> then we can get rid of the old webkit
2017-07-19 08:01:12 <fcolista> ok
2017-07-19 11:00:02 <fcolista> WARNING: CPU: 1 PID: 3681 at /home/buildozer/aports/main/linux-hardened/src/linux-4.9/drivers/gpu/drm/drm_irq.c:1254 drm_wait_one_vblank+0x1a9/0x222 [drm]
2017-07-19 11:00:27 <fcolista> got segfault with intel on a macbook with edge
2017-07-19 11:07:24 <^7heo> sounds sucky.
2017-07-19 11:44:35 <fcolista> seems a notorius bug
2017-07-19 11:44:36 <fcolista> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1384297
2017-07-19 11:44:45 <fcolista> https://bugzilla.redhat.com/show_bug.cgi?id=1365316
2017-07-19 11:54:24 <fcolista> options i915 enable_rc6=1 enable_fbc=1 semaphores=1
2017-07-19 13:23:15 <PureTryOut[m]> I have an apkbuild failing "ERROR: libdmtx*: Found uncompressed man pages"
2017-07-19 13:23:21 <PureTryOut[m]> how am
2017-07-19 13:23:33 <PureTryOut[m]> *how am I supposed to "uncompress" them?
2017-07-19 13:28:20 <Shiz> add a -doc subpackage
2017-07-19 13:28:26 <Shiz> that's where man pages should go
2017-07-19 13:28:36 <Shiz> the default implementation of doc should take care of it just fine
2017-07-19 13:49:10 <jirutka> I’ve added support for minification and compression (using BriefLZ algorithm) into Luapak https://github.com/jirutka/luapak :) I’m gonna do first release soon /cc ncopa
2017-07-19 13:50:11 <PureTryOut[m]> Shiz: aah thanks will look that up
2017-07-19 13:50:15 <jirutka> if someone needs very lightweight and fast compression library with decent compress ratio, BriefLZ is quite good https://github.com/jibsen/brieflz, I wrote Lua binding for it https://github.com/jirutka/brieflz.lua
2017-07-19 17:37:44 <^7heo> My discovery of the day: seq isn't actually POSIX
2017-07-19 17:51:56 <^7heo> and it's not THAT trivial to replace.
2017-07-19 18:49:20 <abbierwolf> Hi. I made a pullrequest for a novnc aport.
2017-07-19 18:49:49 <abbierwolf> And now there is a build error which i cannot understand
2017-07-19 18:50:51 <abbierwolf> it seems it gets a permission denied during a mkdir in the srcdir
2017-07-19 18:51:18 <abbierwolf> Is this a common thing or should i change something
2017-07-19 18:53:33 <jirutka> I don’t understand why you’re making pkg for noVNC, it’s purely client-side JS, isn’t it?
2017-07-19 18:54:38 <jirutka> this error is really weird
2017-07-19 19:04:04 <abbierwolf> The Kimchi project uses noVNC and on other distros like Ubuntu and Fedora they have a noVNC package containing the noVNC files
2017-07-19 19:05:00 <abbierwolf> So I thought of making a novnc aport and add this as an dependency for the kimchi aport
2017-07-19 19:06:38 <jirutka> aha
2017-07-19 19:06:41 <jirutka> ok
2017-07-19 19:07:44 <abbierwolf> But I could find an example of a aport just untar the source and copy files to the packagedir
2017-07-19 19:07:54 <abbierwolf> couldn't find
2017-07-19 19:10:38 <jirutka> it’s not only your PR that is failing
2017-07-19 19:10:43 <jirutka> there’s something wrong on Travis
2017-07-19 19:20:36 <abbierwolf> OK I see. I made the changes based on your review so if Travis is working again I hope it wil pass
2017-07-19 19:21:30 <jirutka> I’m gonna write to Travis support
2017-07-19 19:31:05 <jirutka> hm, maybe not, it doesn’t make sense
2017-07-19 19:31:15 <jirutka> maybe it’s related to some recent updates in aports
2017-07-19 19:31:34 <abbierwolf> what do you mean by updates
2017-07-19 19:31:36 <abbierwolf> ?
2017-07-19 19:32:27 <abbierwolf> do you mean the git part of aports or the Travis part?
2017-07-19 19:34:23 <jirutka> hm, no, this can’t be, it stopped working between 11.56 and 16.57 today
2017-07-19 19:39:55 <abbierwolf> I see the setup is done by a user alpine but the build is done in a directory /home/travis/.... is this correct?
2017-07-19 19:45:42 <jirutka> yes, I wrote these scripts, but yet it looks quite suspicious for me
2017-07-19 19:46:09 <jirutka> and I did it quite differently in alpine-chroot-install, it uses travis user
2017-07-19 19:46:22 <jirutka> I’m currently troubleshooting it
2017-07-19 19:47:16 <jirutka> it’s probably somehow related to travis updating to Trusty as default
2017-07-19 19:52:20 <abbierwolf> Do you have access rights on the /home/travis directory from within the alpine context?
2017-07-19 19:56:39 <jirutka> tbh i wonder how it worked before…
2017-07-19 19:57:01 <jirutka> i think that i understand why it doesn’t work, but i don’t understand how it worked until now
2017-07-19 19:59:19 <abbierwolf> Which distro did the use before?
2017-07-19 20:01:20 <jirutka> the same crap, ubuntu, but the previous release
2017-07-19 20:01:34 <jirutka> Precise or something like that
2017-07-19 20:04:40 <abbierwolf> I see a mount command for the CLONE_DIR in setup-alpine is this a container like environment?
2017-07-19 20:05:11 <abbierwolf> Maybe the mount is now a read-only mount or something
2017-07-19 20:05:48 <abbierwolf> maybe the -s parameter of abuild could be a solution here
2017-07-19 20:08:10 <jirutka> chroot
2017-07-19 20:09:15 <abbierwolf> May the chroot is secured with apparmor preventing changes on the directory outside the chroot
2017-07-19 20:09:52 <jirutka> the problem is as you said, alpine user doesn’t have write privileges to /home/travis
2017-07-19 20:10:37 <abbierwolf> But if you use -s on abuild to create the srcdir within the /home/alpine directory it should work right?
2017-07-19 20:12:18 <jirutka> fixed now, pls rebase your branch against master
2017-07-19 20:18:47 <abbierwolf> I use the github repo not the git.alpinlinux.... what delay is there ?
2017-07-19 20:19:43 <jirutka> like 1 second…?
2017-07-19 20:59:35 <abbierwolf> Thanks for the support. I hope the pullrequest is complete now.
2017-07-19 21:31:48 <kaniini> hi
2017-07-19 21:43:25 <jirutka> hi
2017-07-19 21:51:32 <Shiz> hi
2017-07-19 21:58:19 <xentec> hi
2017-07-19 21:58:36 <xentec> are there any plans to upgrade gcc to 7.x?
2017-07-19 22:13:16 <kaniini> eventually.
2017-07-19 22:18:41 <jirutka> I… I AM DYING! … Should I call an ambulance? … NOT NOW, EVENTUALLY…
2017-07-19 22:18:59 <jirutka> https://youtu.be/J08eUKfzpqM?t=7s
2017-07-19 22:22:31 <leo-unglaub> good evening
2017-07-19 22:23:53 <jirutka> hi leo! long time no see you…
2017-07-19 22:24:11 <jirutka> too many hours spent in helicopter? :)
2017-07-19 22:24:18 <leo-unglaub> hehe, i wish ;)
2017-07-19 22:24:27 <leo-unglaub> i was very busy in openbsd land
2017-07-19 22:24:33 <jirutka> aha
2017-07-19 22:24:40 <leo-unglaub> but now i am installing an alpine server again :)
2017-07-19 22:24:46 <jirutka> porting Alpine to OpenBSD? :)
2017-07-19 22:24:55 <PureTryOut[m]> can abuild not download using a git helper?
2017-07-19 22:25:02 <leo-unglaub> nah, only ported apk to openbsd :)
2017-07-19 22:25:15 <jirutka> PureTryOut[m]: what git helper?
2017-07-19 22:25:30 <PureTryOut[m]> well... a? can I not put a git link into "source"?
2017-07-19 22:25:41 <PureTryOut[m]> "git://urlhere/package.git"
2017-07-19 22:26:00 <jirutka> PureTryOut[m]: no, you can’t
2017-07-19 22:26:04 <PureTryOut[m]> darn
2017-07-19 22:26:12 <jirutka> PureTryOut[m]: upstream does not provide tarballs?
2017-07-19 22:26:19 <jirutka> PureTryOut[m]: what project?
2017-07-19 22:26:19 <PureTryOut[m]> does not seem like it
2017-07-19 22:26:32 <PureTryOut[m]> trying to package polkit-qt5 and I can only find a git repo
2017-07-19 22:26:41 <jirutka> url of that repo?
2017-07-19 22:27:31 <PureTryOut[m]> https://cgit.kde.org/polkit-qt-1.git/
2017-07-19 22:27:59 <jirutka> last release 3 years ago, looks quite dead
2017-07-19 22:28:10 <PureTryOut[m]> yeah, but required by some KDE packages I'm trying to build... :/
2017-07-19 22:29:56 <PureTryOut[m]> the Arch PKGBUILD just has a broken source url, and other distros seem to host their own source or something
2017-07-19 22:30:12 <jirutka> hm, then the only way is to use snapshot
2017-07-19 22:30:21 <PureTryOut[m]> yeah but how to get it?
2017-07-19 22:30:35 <jirutka> something like https://github.com/alpinelinux/aports/blob/master/testing/libcoro/APKBUILD#L19
2017-07-19 22:30:52 <PureTryOut[m]> I don't think cgit supports that stuff, only Github
2017-07-19 22:30:52 <jirutka> and then ask someone of us to upload this to dev.alpinelinux.org
2017-07-19 22:31:42 <jirutka> try to use `git archive --format=tar <TAG>` to generate the tarball
2017-07-19 22:32:08 <PureTryOut[m]> ooh you mean clone the source myself, and get the tarbell on dev.alpinelinux.org?
2017-07-19 22:32:59 <PureTryOut[m]> *tarball
2017-07-19 22:33:08 <jirutka> git archive --prefix=$pkgname/ -o "$SRCDEST"/$pkgname-$pkgver.tar.gz $_gittag
2017-07-19 22:33:17 <jirutka> yeah
2017-07-19 22:35:28 <PureTryOut[m]> ok I got it, where can I submit it?
2017-07-19 22:36:28 <jirutka> open a pull request
2017-07-19 22:36:42 <PureTryOut[m]> ooh on Github, ok sure
2017-07-19 22:37:24 <PureTryOut[m]> but don't I still need to have the tarball somewhere abuild can access it? an url to put in the source?
2017-07-19 22:37:50 <PureTryOut[m]> (so upload it to dev.alpinelinux.org somehow)
2017-07-19 22:37:55 <jirutka> yes, look into https://github.com/alpinelinux/aports/blob/master/testing/libcoro/APKBUILD#L12
2017-07-19 22:38:03 <PureTryOut[m]> oops missed that, sory
2017-07-19 22:38:05 <PureTryOut[m]> *sorry
2017-07-19 22:38:13 <jirutka> travis build will fail, I’ll upload the snapshot then
2017-07-19 22:38:23 <PureTryOut[m]> aah like that, ok
2017-07-19 22:39:42 <PureTryOut[m]> I'm not sure if I got the APKBUILD correct though, how would I test it for now without the tarball on dev.alpinelinux.org?
2017-07-19 22:39:57 <PureTryOut[m]> nvm I'm dumb
2017-07-19 22:40:55 <jirutka> well, you can copy the tarball into your /var/cache/distfiles
2017-07-19 22:41:09 <PureTryOut[m]> neh I got it already
2017-07-19 22:42:10 <leo-unglaub> jirutka: what letsencrypt client are you using on alpine?
2017-07-19 22:42:32 <jirutka> leo-unglaub: acme-client https://pkgs.alpinelinux.org/package/v3.6/community/x86_64/acme-client
2017-07-19 22:42:37 <jirutka> leo-unglaub: with few custom scripts
2017-07-19 22:43:25 <jirutka> leo-unglaub: request-cert https://dpaste.de/S4iC
2017-07-19 22:44:24 <jirutka> leo-unglaub: and update-certs https://dpaste.de/Smfe (this is called by cron once a week)
2017-07-19 22:45:08 <jirutka> leo-unglaub: actually, I’ve already put them to gist and documented XD https://gist.github.com/jirutka/5f891cce11ad6fec772f673859d4b82d
2017-07-19 22:45:51 <leo-unglaub> hehe, thanks!
2017-07-19 22:46:03 <jirutka> you’re welcome
2017-07-19 22:46:28 <PureTryOut[m]> jirutkawell I'm not going to finish this today, but thanks for your help! I'll probably contact one of you later for uploading the source
2017-07-19 22:48:03 <jirutka> okay
2017-07-20 09:13:31 <fcolista> ncopa, why do we hove some udev rules in /usr/lib/udev/rules.d, why others in /lib/udev/rules.d ?
2017-07-20 09:13:36 <fcolista> *have
2017-07-20 09:14:10 <Shiz> probably result of --prefix=
2017-07-20 09:14:21 <fcolista> Shiz, but which is correct?
2017-07-20 09:14:23 <ncopa>                 --with-rootlibexecdir=/lib/udev \
2017-07-20 09:14:23 <ncopa>                 --libdir=/usr/lib \
2017-07-20 09:14:49 <ncopa> for udev I'd say /lib/udev
2017-07-20 09:15:07 <ncopa> what packages owns the /usr/lib/udev/rules.d/* files?
2017-07-20 09:15:15 <fcolista> so this: http://pkgs.alpinelinux.org/contents?file=80-libinput-device-groups.rules&path=&name=&branch=&repo=&arch= should be moved in /lib/udev/
2017-07-20 09:15:25 <fcolista> jsut noticed now with libgpod
2017-07-20 09:15:30 <fcolista> *just
2017-07-20 09:15:37 <fcolista> ipod is not recognized as MTP
2017-07-20 09:15:42 <Shiz> I'd be more of a fan of /usr/lib/udev but meh
2017-07-20 09:15:44 <fcolista> while there's udev rules that should make it
2017-07-20 09:15:54 <fcolista> that's why I noticed
2017-07-20 09:15:59 <Shiz> im not even sure if udev interprets stuff in /usr/lib/udev
2017-07-20 09:16:09 <fcolista> Shiz, i think no
2017-07-20 09:16:27 <ncopa> Shiz: /usr/lib/ will require that /usr is on rootfs partition
2017-07-20 09:16:42 <ncopa> but it might be that udev requires that anyways
2017-07-20 09:16:42 <Shiz> as it should
2017-07-20 09:16:49 <Shiz> it does i think
2017-07-20 09:16:50 <TBB> fwiw, it doesn't matter which path the base rules are in, your overrides are still in /etc/udev/rules.d/
2017-07-20 09:17:27 <ncopa> i know they does not support /usr on separate partition in upstram systemd, but eudev might support separate /usr
2017-07-20 09:17:41 <TBB> (with the exception that ncopa just said while I was staring at my keyboard instead of the screen)
2017-07-20 09:18:47 <ncopa> fcolista: interesting observation you had re MTP
2017-07-20 09:19:07 <ncopa> i noticed my moto z phone is not detected as mtp either
2017-07-20 09:19:30 <Shiz> /usr on different partition is broken anyway
2017-07-20 09:19:32 <Shiz> 
ACTION grandstanding

2017-07-20 09:20:07 <ncopa> very possible it is
2017-07-20 09:20:10 <fcolista> ncopa, i've updated libgpod with correct udev path rules
2017-07-20 09:20:21 <fcolista> but still having: ": bus: 2, device: 8 was not an MTP device"
2017-07-20 09:20:37 <ncopa> Shiz: do you think we want support /usr on separate partition?
2017-07-20 09:20:44 <ncopa> i think it may work
2017-07-20 09:20:53 <Shiz> i'm not sure what the use case for it is
2017-07-20 09:21:06 <Shiz> the traditional reason to do separate /usr is that / can be on a boot disk/medium to load the rest of the system
2017-07-20 09:21:16 <Shiz> but that's what the initramfs is used for these days in Linux
2017-07-20 09:22:20 <ncopa> theoretical usecase: mount /usr on readonly nfs
2017-07-20 09:22:59 <ncopa> then you have all the software installed for you users on the nfs server only
2017-07-20 09:23:19 <ncopa> but i suppose nobody in their right mind would do something like that nowdays
2017-07-20 09:23:24 <Shiz> :P
2017-07-20 09:23:33 <ncopa> even if the idea is neat
2017-07-20 09:24:01 <Shiz> yeah but that just begs the question
2017-07-20 09:24:13 <Shiz> what about the software installed to /
2017-07-20 09:24:15 <Shiz> :P
2017-07-20 09:24:30 <ncopa> well
2017-07-20 09:24:34 <Shiz> it seems if you want something like that you should just mount /bin /sbin /lib and /share
2017-07-20 09:24:46 <Shiz> or a complete sep directory and add it to path
2017-07-20 09:25:19 <ncopa> the / would only have the base tools, to get the system up
2017-07-20 09:25:53 <ncopa> the bigger software, like web browser, libreoffice etc would be shared
2017-07-20 09:26:04 <ncopa> and user does not need to install those
2017-07-20 09:26:16 <Shiz> actually
2017-07-20 09:26:21 <Shiz> even that you could support with a union mount on /
2017-07-20 09:26:26 <Shiz> no need for separate dirs
2017-07-20 09:27:32 <TBB> it's just one of those things that are still awake and it's way past their bedtime (which pretty much applies to the whole linux filesystem hierarchy)
2017-07-20 09:30:37 <fcolista> bah
2017-07-20 09:30:46 <fcolista> mtp issue still present
2017-07-20 09:31:19 <fcolista> ncopa, it's the kernel that does not recognize the MTP part
2017-07-20 09:33:26 <clandmeter> isnt mpt fuse based?
2017-07-20 09:34:15 <Shiz> no
2017-07-20 09:34:34 <Shiz> "it's complicated"
2017-07-20 09:37:44 <TBB> to say the least
2017-07-20 09:48:19 <fcolista> umh
2017-07-20 09:48:20 <fcolista> so
2017-07-20 09:48:45 <fcolista> mtp-probe is part of libmtp, and is used by udev to recognize if the device is/has mtp or not
2017-07-20 09:49:01 <fcolista> libmtp is built without --with-udev
2017-07-20 09:49:15 <fcolista> and this points to /usr/lib/udev (again)
2017-07-20 09:51:36 <fcolista> ncopa: it's zune your device right?
2017-07-20 09:51:58 <fcolista> oh, no..it's moto z
2017-07-20 09:52:06 <fcolista> zune is M$
2017-07-20 11:02:42 <PureTryOut[m]> I've got an error of which I'm not sure what it means...
2017-07-20 11:02:50 <PureTryOut[m]> 
ACTION sent a long message: PureTryOut[m]_2017-07-20_11:02:49.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/fuLNZwfWJtyKWHdWvcVMivUr>

2017-07-20 11:04:14 <Shiz> https://en.wikipedia.org/wiki/Setuid
2017-07-20 11:04:32 <Shiz> by policy we disallow suid binaries by default since they're a security risk
2017-07-20 11:05:15 <PureTryOut[m]> hmm ok. how would I remoe that bit then?
2017-07-20 11:05:16 <PureTryOut[m]> *remove
2017-07-20 11:06:18 <PureTryOut[m]> ooh, `chmod 0644`?
2017-07-20 11:06:29 <PureTryOut[m]> although, it seems required to have that bit set
2017-07-20 11:07:25 <Shiz> yes, it's a bit more complex than removing the bit
2017-07-20 11:07:37 <Shiz> if the script actually has a useful purpose that can't be done otherwise, it may be whitelisted
2017-07-20 11:07:42 <Shiz> however, i think that's unlikely for this one
2017-07-20 11:08:42 <PureTryOut[m]> how so? it's sort of an init manager, but for KDE related tasks
2017-07-20 11:08:49 <PureTryOut[m]> it makes sense to me tbh
2017-07-20 11:09:10 <Shiz> doesn't make sense for me that it'd need root from any user for that
2017-07-20 11:10:10 <PureTryOut[m]> well I guess I can work with disabling it for now. would chmod 0644 do?
2017-07-20 11:19:16 <PureTryOut[m]> that worked. I'm interested to see if KDE will still work with that bit gone
2017-07-20 14:29:12 <mosez> if i'm building a new testing package and it depends on other testing packages, how can i use these? abuild -r seems to be not able to do that :(
2017-07-20 14:29:26 <mosez> got masked in: @testing for multiple deps
2017-07-20 14:32:21 <PureTryOut[m]> I guess you need to install the testing package first before you build the others
2017-07-20 14:32:41 <jirutka> mosez: locally? add your ~/packages/<repo>/<branch> to /etc/apk/repositories
2017-07-20 14:48:15 <mosez> jirutka: the deps are already part of the testing repo. so i have to install the deps to being able to build it?
2017-07-20 14:48:31 <jirutka> no
2017-07-20 14:48:51 <jirutka> aha, you’ve pinned testing repo as @testing…
2017-07-20 14:48:56 <jirutka> that’s the problem
2017-07-20 14:49:05 <mosez> ok, i need to unpin it?
2017-07-20 14:49:07 <jirutka> then you must to unpin it
2017-07-20 14:49:13 <mosez> ok
2017-07-20 14:49:43 <mosez> just working through my flagged packages
2017-07-20 14:50:00 <mosez> http://pkgs.alpinelinux.org/flagged?origin=&branch=&repo=&maintainer=Thomas+Boerger hugo and sassc already got pull requests on github :)
2017-07-20 15:13:09 <mosez> ok, i really don't like python crap -.-
2017-07-20 15:13:20 <jirutka> me neither
2017-07-20 15:27:59 <mosez> added py-cli_helpers, updated py-pgspecial py-prompt_toolkit pgcli and mycli, but if i try to execute the installed mycli or pgcli packages it results in an error like ImportError: No module named pkg_resources
2017-07-20 15:28:21 <mosez> i found out so far that this module should be related to setuptools
2017-07-20 15:28:30 <jirutka> yes
2017-07-20 15:28:40 <jirutka> why do you use Legacy Python?
2017-07-20 15:28:47 <jirutka> setuptools is included in Python 3
2017-07-20 15:28:52 <jirutka> so it means that you use Python 2
2017-07-20 15:29:09 <mosez> because this package is already added with python2
2017-07-20 15:29:22 <jirutka> what pkg?
2017-07-20 15:29:40 <mosez> https://github.com/alpinelinux/aports/blob/master/testing/mycli/APKBUILD https://github.com/alpinelinux/aports/blob/master/testing/pgcli/APKBUILD
2017-07-20 15:30:21 <mosez> and the deps are mostly also packaged already for py-
2017-07-20 15:30:23 <jirutka> mycli supports python3, so it should be updated
2017-07-20 15:30:32 <mosez> (beside the new dep cli_helpers)
2017-07-20 15:31:25 <mosez> oh god, looks like it got a runtime dep on setuptools -.-
2017-07-20 15:31:53 <jirutka> that’s also suspicious, setuptools should not be needed in runtime
2017-07-20 15:31:58 <jirutka> but… it’s python… so…
2017-07-20 15:32:18 <mosez> i have installed py-setuptools and it mostly works. just missing another dep now
2017-07-20 15:33:34 <mosez> how should this package be named? https://pypi.python.org/pypi/backports.csv maybe py-backports.csv? or py-backports-csv?
2017-07-20 15:33:49 <jirutka> the second one
2017-07-20 15:34:00 <mosez> python is strange stuff, but these 2 tools are pretty nice
2017-07-20 15:51:07 <Shiz>    @jirutka : that’s also suspicious, setuptools should not be needed in runtime
2017-07-20 15:51:09 <Shiz> actually it is
2017-07-20 15:51:12 <Shiz> for packages that have binaries
2017-07-20 15:51:21 <jirutka> huh?
2017-07-20 15:52:20 <Shiz> by binaries i mean files that get installed in /{usr,}/{bin,sbin}
2017-07-20 15:52:44 <Shiz> setuptools install tiny wrapper scripts that import pkg_resources, part of setuptools, to locate and load the python entry point
2017-07-20 15:53:53 <jirutka> aha, yes
2017-07-20 15:53:55 <jirutka> you’re right
2017-07-20 16:16:21 <jirutka> Shiz: could you please take care of upstreaming our patches to Rust? you have currently largest knowledge about it and wrote most of these patches
2017-07-20 17:35:23 <mitchty> ok, i was setting up perf as a subpkg of the kernel, and well, its dependencies are... unique, aka elfutils in alpine linux are not the one expected
2017-07-20 17:36:34 <mitchty> but given its a part of the kernel, curious how to proceed? not having perf is making me nervous, so used to using it now
2017-07-21 08:38:06 <mosez> ok, i have created various pull requests on github now... all packages i'm maintaining should be up2date again after merging them :)
2017-07-21 11:30:39 <mosez> so if somebody is bored and wants to merge some github pull requests: 1957 1958 1962 1963 1964 1965 1966 1967 1968
2017-07-21 12:33:44 <nigdav007> Hi could i pick your brains on something i am trying to create an alpine package, that installs an few things (what i done) and copy an script to an folder. The script it self needs to be packaged up with the package also.
2017-07-21 12:34:08 <Shiz> why?
2017-07-21 12:34:21 <Shiz> mosez: i can take a look at them when i'm home if you ping me in say, 4 hours
2017-07-21 12:34:28 <Shiz> mosez: do they concern any packages in main/?
2017-07-21 12:36:33 <nigdav007> the programs is docker and diglog, the script is an interface that is ran when a user logsin
2017-07-21 12:39:37 <jirutka> nigdav007: mine brain is not for rent :P
2017-07-21 12:40:02 <jirutka> nigdav007: we already have package for docker
2017-07-21 12:40:43 <jirutka> nigdav007: diglog – Design and simulate circuits ?
2017-07-21 12:42:33 <nigdav007> hi jirutka sorry i ment dialog not diglog
2017-07-21 12:43:18 <jirutka> nigdav007: dialog is also here, so i kinda don’t understand what you’re trying to do?
2017-07-21 12:43:43 <PureTryOut[m]> hey guys, my apkbuild is unpacking a source package which has a "+" in the folder name when extracted. however, $pkgver may not contain a "+" according to abuild, what can I do about this?
2017-07-21 12:44:19 <Shiz> PureTryOut[m]: is the + part of the package name?
2017-07-21 12:44:20 <Shiz> err
2017-07-21 12:44:23 <Shiz> actual package version?
2017-07-21 12:44:27 <PureTryOut[m]> yes
2017-07-21 12:44:27 <nigdav007> i am trying to package it all up with an script of my own so on running it installs docker dialog, places an script in to an folder
2017-07-21 12:44:33 <PureTryOut[m]> http://archive.ubuntu.com/ubuntu/pool/main/libd/libdbusmenu-qt/, bottom file
2017-07-21 12:45:05 <Shiz> uhm
2017-07-21 12:45:09 <Shiz> so it's not?
2017-07-21 12:45:17 <Shiz> because the upstream version seems to be http://archive.ubuntu.com/ubuntu/pool/main/libd/libdbusmenu-qt/libdbusmenu-qt_0.9.2.orig.tar.bz2
2017-07-21 12:45:19 <PureTryOut[m]> it's not?
2017-07-21 12:45:20 <Shiz> the rest is ubuntu patches
2017-07-21 12:45:24 <Shiz> ubuntu patched-versions*
2017-07-21 12:45:46 <PureTryOut[m]> yeah but I need the patched version, due to qt5 support
2017-07-21 12:46:16 <Shiz> i'd take the upstream version and apply the patcthes in the apkbuild anyway then
2017-07-21 12:46:18 <Shiz> it's cleaner
2017-07-21 12:46:38 <jirutka> nigdav007: this doesn’t look like something that should go into official aports… are you creating it for your personal aports repository?
2017-07-21 12:47:04 <PureTryOut[m]> hmm that could work, but idk where to find the patches
2017-07-21 12:47:30 <PureTryOut[m]> ooh nvm
2017-07-21 12:47:37 <PureTryOut[m]> the .diff.gz package right?
2017-07-21 12:47:56 <Shiz> i think so yes
2017-07-21 12:48:40 <nigdav007> jirutka: yes its for my repo not anything official
2017-07-21 12:48:41 <PureTryOut[m]> Canonical should upstream more...
2017-07-21 12:49:17 <jirutka> nigdav007: ok, so what’s the problem? how to create package in general?
2017-07-21 12:49:37 <PureTryOut[m]> [Shiz](https://matrix.to/#/@freenode_Shiz:matrix.org): thanks, I'll just use those, is cleaner indeed
2017-07-21 12:49:54 <Shiz> whats this highlight lol
2017-07-21 12:50:03 <jirutka> omg, matrix should really improve its IRC integration!
2017-07-21 12:50:14 <nigdav007> jirutka: yes thats my problem
2017-07-21 12:50:23 <jirutka> this is so stupid… what about just not adding any crap into messages…?
2017-07-21 12:50:41 <Shiz> relax yo
2017-07-21 12:50:43 <Shiz> ;p
2017-07-21 12:50:47 <jirutka> nigdav007: start with https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Setup_your_system_and_account
2017-07-21 12:51:51 <jirutka> nigdav007: then use abuild command to generate scaffold of your aport inside your repository
2017-07-21 12:52:07 <jirutka> nigdav007: and then adjust it
2017-07-21 12:52:18 <Shiz> you mean newapkbuild
2017-07-21 12:52:22 <jirutka> eh, yes
2017-07-21 12:52:32 <jirutka> nigdav007: s/abuild/newapkbuild/
2017-07-21 12:53:56 <nigdav007> jirutka: thanks i got that so fair, my problem is now adding my custom .sh script to the package and on install adds the file to an folder
2017-07-21 12:54:27 <PureTryOut[m]> I'll stop the highlighting... didn't know it looked weird. tbf, it's a develop version still
2017-07-21 12:54:54 <PureTryOut[m]> anyways, I can't actually use libdbusmenu-qt_0.9.2, as that requires Qt4 which conflicts with my Qt5 installation...
2017-07-21 12:55:46 <Shiz> isn't the point of those patches to make it not require qt4
2017-07-21 12:55:48 <Shiz> :P
2017-07-21 12:56:08 <PureTryOut[m]> you would think so haha
2017-07-21 12:56:17 <PureTryOut[m]> it patches fine, but CMake still complains
2017-07-21 12:56:33 <PureTryOut[m]> I've even added "-DUSE_QT4=Off", still complaining
2017-07-21 12:56:55 <jirutka> nigdav007: just add your .sh script into the same directory as APKBUILD and in package phase copy it "$srcdir"/your.sh "$pkgdir"/whatever/you/want/your.sh
2017-07-21 12:57:22 <jirutka> nigdav007: maybe this may help https://github.com/jirutka/user-aports/tree/v3.6/user/jj-baselayout
2017-07-21 12:57:27 <Shiz> hmm
2017-07-21 13:09:00 <nigdav007> jirutka: thank you i think that will help me out :D
2017-07-21 18:47:25 <foxkit> stuff and nonsense
2017-07-21 18:48:04 <foxkit> has there ever been consideration to shipping musl patches as a single .tgz file off alpinelinux.org?  that way, there only needs to be two checksums instead of dozens
2017-07-21 18:57:12 <fabled> foxkit, it's musl upstream commits mostly. we get rid of them when they tag new release. and it's somewhat simpler to just add individual patches than start hosting a .tgz
2017-07-21 19:17:14 <foxkit> fabled: yeah I understand
2017-07-21 19:17:22 <foxkit> it is just very annoying when I am trying to add my own patches in
2017-07-21 19:17:31 <foxkit> musl needs to stop having so many patches, or else release more often
2017-07-21 21:49:07 <leo-unglaub> good evening
2017-07-21 21:59:12 <jirutka> good evening!
2017-07-22 11:30:12 <c4milo> is there a way of compiling getent with initgroups support?
2017-07-22 12:33:55 <vkrishn> weee!! http://www.infoworld.com/article/3206644/linux/review-alpine-linux-is-small-fast-and-different.html
2017-07-22 12:36:42 <Shiz> too bad its loginwalled
2017-07-22 12:39:14 <vkrishn> we can train algibot to fetch it ;)
2017-07-22 12:47:54 <vkrishn> gtg, enjoy your weekend as ms / .net gets in linux, tizen4.0 and more.... I wonder what would they call it, ms powered phone, linux or MILUX ;)
2017-07-22 12:49:57 <vkrishn> no wait ! you cannot use word "linux" and ms together... it dilutes the corp identity
2017-07-22 13:47:31 <jirutka> wut? .net is already in linux, it’s called mono
2017-07-22 13:50:41 <vkrishn> I thought ms open-sourced the .NET platform, a yr back iirc
2017-07-22 13:50:53 <jirutka> yes
2017-07-22 13:51:01 <jirutka> and officially supports mono
2017-07-22 13:51:05 <PureTryOut[m]> that's .NET Core
2017-07-22 13:51:23 <jirutka> and MS SQL will run on Linux soon
2017-07-22 13:51:44 <vkrishn> what I still struggling to understand, is, why they need linux to push open-source schemes/aggendas
2017-07-22 13:52:09 <jirutka> ’cause most servers run on Linux?
2017-07-22 13:52:18 <jirutka> correction: *nix
2017-07-22 13:52:40 <vkrishn> they could just strive to make things portable/posix.... etch
2017-07-22 13:52:57 <jirutka> that’s what they’re doing
2017-07-22 13:53:01 <vkrishn> make a os that is freeware (NOT opensource)
2017-07-22 13:53:37 <jirutka> but it means porting large part of their stack, like .NET
2017-07-22 13:53:42 <arch3y> but apparently ppl are still loving to stick to their mssql ways
2017-07-22 13:53:48 <arch3y> and not learn a different db lol
2017-07-22 13:53:53 <vkrishn> a corp needs money to run, if the whole model does not pay back, thats confusing
2017-07-22 13:54:07 <jirutka> i don’t understand it too, but I’ve never worked with MS SQL
2017-07-22 13:54:25 <jirutka> PostgreSQL FTW
2017-07-22 13:55:16 <vkrishn> the analysing part is, how would they advertise the products like eg.tizen4.0
2017-07-22 13:55:30 <jirutka> MS is trying hard to stay relevant and make friends in FOSS communities
2017-07-22 13:55:48 <vkrishn> will the put their brand name on heading in 24pts and linux name in footer in 2pts
2017-07-22 13:56:33 <jirutka> most likely
2017-07-22 13:57:00 <arch3y> pgsql is the programmers db
2017-07-22 13:57:12 <arch3y> but alot of ppl still go with mysql
2017-07-22 13:57:14 <arch3y> or maria
2017-07-22 13:57:27 <jirutka> don’t expect good will from big corps, they do everything just for money, it’s their nature
2017-07-22 13:57:48 <Shiz> guys please
2017-07-22 13:57:51 <Shiz> -offtopic
2017-07-22 13:57:53 <Shiz> :P
2017-07-22 13:57:56 <jirutka> yeah, cause there’s A LOT of incompetent and uneducated devs…
2017-07-22 13:58:09 <jirutka> Shiz right, please move to #alpine-offtopic
2017-07-22 14:00:24 <jirutka> this is not like “go away”, it’s name of real channel we use for OT discussions ;)
2017-07-22 14:00:38 <arch3y> thanks for the minidiscussion guys
2017-07-22 14:00:40 <arch3y> carry on
2017-07-22 14:04:48 <vkrishn> gtg, I cannot stay long on an unlogged channel due to flaky-internet, leads to miscommunication, but thanks
2017-07-22 14:05:18 <Shiz> all alpine channels are logged
2017-07-22 14:05:25 <jirutka> vkrishn: use ZNC…
2017-07-22 14:05:38 <jirutka> Shiz: not all, offtopic is not logged
2017-07-22 14:06:03 <vkrishn> yes, I really want to, but still need a reliable connection
2017-07-22 14:06:44 <vkrishn> I mean, the server running it
2017-07-22 17:30:59 <deed02392> hi all, i’m investigating a segfault that occurs for a python program using the lxml library and so far this looks like it could be an Alpine issue of using muslc instead of glibc
2017-07-22 17:31:01 <deed02392> https://github.com/clouder-community/clouder/issues/221
2017-07-22 18:05:37 <jirutka> deed02392: hi, there’s not enough information in this issue to say anything…
2017-07-22 18:33:48 <Janp> Hi, I somewhere read that there is a smartphone distro based on Alpine Linux. Unfortunately, I can't remember where I read it. Can anybody give please me a link?
2017-07-22 18:35:13 <scadu> Janp: second link from google on phrase "alpine linux smartphone": https://ollieparanoid.github.io/post/postmarketOS/
2017-07-22 18:36:35 <PureTryOut[m]> #postmarketos on Freenode, or [#postmarketos:disroot.org](https://matrix.to/#/#postmarketos:disroot.org)  on Matrix
2017-07-22 18:37:16 <Janp> Thanks
2017-07-22 18:39:45 <scadu> XD
2017-07-22 18:42:39 <PureTryOut[m]> in regards to postmarketOS, soon Alpine Linux will have KDE available! well, Plasma Mobile for now, but that includes a large part of Plasma for the desktop
2017-07-22 19:36:35 <deed02392> jirutka: i’ve got more detail if you’re open to it
2017-07-22 19:36:45 <deed02392> jirutka: https://github.com/python-pillow/Pillow/issues/1935
2017-07-22 19:37:46 <deed02392> it’s a lot of detail but it’s basically a long discovery process of going from some app not working, to figuring out that it’s lxml using musl on Alpine that is probably the issue… i guess then maybe it’s an lxml project issue where it needs to be fixed for when it’s using musl?
2017-07-22 19:45:31 <jirutka> deed02392: could you please provide me minimal example how to reproduce this issue? i’m not very wise from this thread
2017-07-22 19:46:09 <deed02392> sure one second
2017-07-22 19:46:38 <deed02392> docker pull ressu/sickgear
2017-07-22 19:46:38 <deed02392> run -it --rm --entrypoint=/bin/sh -p 8081:8081 ressu/sickgear
2017-07-22 19:46:57 <deed02392> navigate to http://localhost:8081/config/notifications and the application will SIGSEGV
2017-07-22 19:47:31 <jirutka> without docker…
2017-07-22 19:48:16 <deed02392> sorry, this is the only reproduction example I have
2017-07-22 19:50:31 <jirutka> huh https://github.com/SickGear/SickGear
2017-07-22 19:50:35 <jirutka> Repository unavailable due to DMCA takedown.
2017-07-22 20:17:07 <deed02392> jirutka: i’ve managed to confirm that a fix is to manually set the stack_size that python uses, i.e. override the platform default
2017-07-22 20:17:16 <deed02392> are you aware of what the default thread stack size is in alpine linux?
2017-07-22 20:19:04 <jirutka> IIRC 80k
2017-07-22 20:19:46 <deed02392> https://github.com/voidlinux/void-packages/issues/4147
2017-07-22 20:19:51 <jirutka> what python module needs bigger stack size?
2017-07-22 20:19:55 <deed02392> looks correct jirutka, great recall!
2017-07-22 20:19:58 <deed02392> py-lxml
2017-07-22 20:22:10 <deed02392> jirutka: that github i mention lists several other softwares that tend to fail under the default stack size of 8k
2017-07-22 20:22:17 <deed02392> 80, sorry
2017-07-22 20:27:09 <deed02392> jirutka: https://github.com/docker-library/python/issues/211#issuecomment-314919717 looks like someone at alpine has already agreed to patch Python to use a larger stack size?
2017-07-23 18:10:03 <foxkit> configure: error: GNAT is required to build ada
2017-07-23 18:10:06 <foxkit> >>> ERROR: gcc: all failed
2017-07-23 18:10:17 <foxkit> gcc-gnat needs to be in gcc's makedepends
2017-07-23 18:31:09 <foxkit> even with gcc-gnat and libgnat installed, it still fails with the same error
2017-07-23 19:13:44 <foxkit> I have found the reason it was crashing after installing gcc-gnat
2017-07-23 19:13:55 <foxkit> and yes, definitely, if LANG_ADA=true, gcc-gnat needs to be added to makedepends
2017-07-23 21:42:38 <foxkit> gcc needs help, just going to say it :s
2017-07-23 21:42:53 <foxkit> https://bpaste.net/raw/03e6ebeb7a7e
2017-07-23 21:43:07 <foxkit> and that's only after managing to get ada to work at all
2017-07-24 02:07:32 <m4chm4n> are there any mods on the forums?
2017-07-24 03:11:17 <ninthstone> is this the right venue for an abuild question and how it patches?
2017-07-24 03:53:47 <ninthstone> nevermind, just realized that all of the patches for the openssl package in aports are still in the repo, but unused
2017-07-24 14:31:58 <mitchty> question on version bumps for things
2017-07-24 14:32:12 <mitchty> ghc 8.2.1 got released finally, i have it building fine so no big deal there
2017-07-24 14:33:42 <mitchty> but for things that version bumps can impact the ability to build things (mostly in haskell land it means people just need to say it works fine with the base package included), how do version bumps get handled generally? I can update the version in community but some might want to use ghc 8.0.2 later etc...
2017-07-24 14:52:56 <foxkit> https://github.com/alpinelinux/aports/pull/1983 managed to get some stuff ready for merge.  unfortunately using github.
2017-07-24 14:54:46 <Shiz> you can use the aports ML for patches too if you want
2017-07-24 14:54:47 <Shiz> :P
2017-07-24 14:55:00 <Shiz> mitchty: i'm not sure, is there a big issue in ghc land with xversion compat
2017-07-24 14:55:08 <Shiz> generally I don't like maintaining separate versions of packages
2017-07-24 14:55:19 <mitchty> not really, its more stuff you build with it
2017-07-24 14:55:32 <mitchty> aka the "base" library bumps a rev
2017-07-24 14:55:54 <mitchty> but most stuff depends on base - 1 as that is what it was tested with
2017-07-24 14:56:02 <mitchty> junk like that
2017-07-24 14:56:04 <Shiz> foxkit: btw, I just sent a reply to your ML post
2017-07-24 14:56:08 <Shiz> thanks for the insights
2017-07-24 14:59:49 <foxkit> Shiz: great, thank you!  I know about aports ML, but I am already trying to pick MLs to unsubscribe from; I get slammed every day with somewhere around ~100 messages from Fedora, ~80 from FreeBSD, ~60 from Gentoo.  probably going to unsub gentoo anyway
2017-07-24 15:00:05 <foxkit> I mainly stay on fedora because they do the mass rebuilds when gcc bumps version.  and it is interesting to see what packages break with new gcc.
2017-07-24 15:00:14 <foxkit> sometimes I help out upstreams
2017-07-24 15:00:23 <Shiz> aaand i noticed my mail had a typo, fml
2017-07-24 15:00:26 <Shiz> s/multiline/multilib/
2017-07-24 15:03:57 <^7heo> yeah it's what happens
2017-07-24 15:04:05 <^7heo> you *never* notice it before hitting 'send'
2017-07-24 15:04:43 <^7heo> and then you just re-read to confirm you didn't leave a typo behind and that's when it hits you.
2017-07-24 15:07:22 <mitchty> you could always get around it by having cabal adjust constraints globally, but sometimes things do break, 8.0 changed some ways certain things were defined so it did break some things (not a lot, and they were broken already)
2017-07-24 15:17:40 <jirutka> mitchty: just bump it, we don’t maintain multiple versions simultaneously if not really necessary
2017-07-24 15:23:54 <mitchty> jirutka: ok I had copied it from community and then added things but pretty easy to change it to update community https://github.com/alpinelinux/aports/compare/master...mitchty:ghc-8.2?expand=1
2017-07-24 15:38:21 <jirutka> mitchty: and bump depending packages if there are some ABI incompatibilities, but this is probahly not the case with ghc
2017-07-24 15:42:42 <foxkit> >>> gcc-x86_64*: Stripping binaries
2017-07-24 15:42:44 <foxkit> strip: Unable to recognise the format of the input file `./usr/x86_64-foxkit-linux-musl/lib/libcilkrts.so.5.0.0'
2017-07-24 15:42:47 <foxkit> joy :(
2017-07-24 16:07:35 <Shiz> foxkit: hmm
2017-07-24 16:34:57 <mitchty> jirutka: the only thing I think it might impact is cabal-install right now, and thats only for rebuilds, i'll have to test it tonight
2017-07-24 19:46:09 <ncopa> i think this guy has a good point: http://bugs.alpinelinux.org/issues/7524#note-5
2017-07-24 19:46:29 <ncopa> im open for ideas for QA
2017-07-24 19:47:36 <ncopa> Shiz: do you think you could review the busybox patch "[alpine-aports] [PATCH] main/busybox: fix timezone adjustment in syslogd"
2017-07-24 19:47:46 <Shiz> isn't that my patch
2017-07-24 19:48:36 <ncopa> its a fix for your patch if i understand it correctly
2017-07-24 19:49:00 <Shiz> ah
2017-07-24 19:49:24 <ncopa> http://lists.alpinelinux.org/alpine-aports/4758.html
2017-07-24 19:53:43 <Shiz> hmm
2017-07-24 20:03:11 <jirutka> hm, what exactly is wrong about ext4 or whatever in this bug report?
2017-07-24 20:04:22 <jirutka> I was thinking about openQA from SUSE, for testing things like that, but not sure about it… I’ve talked with one of its devs and it’s made with GUI distro in mind
2017-07-24 20:05:19 <jirutka> “The two ext4 file-systems are set up without journals.” … srsly?!! why the heck he installed system on non-journaled ext4?
2017-07-24 20:07:13 <jirutka> lol, he has 0 0 in fastb
2017-07-24 20:07:16 <jirutka> fstab
2017-07-24 20:07:26 <jirutka> clearly error between chair and screen…
2017-07-24 20:08:18 <_ikke_> jirutka: is it when setup-disk sets it to that?
2017-07-24 20:08:32 <jirutka> hm, looks like so…
2017-07-24 20:09:00 <jirutka> “Insuring the integrity of file-systems is about as fundamental a function of a distribution as it gets” … and yet user explicitly created ext4 without journal…
2017-07-24 20:11:24 <jirutka> it probably happens here https://github.com/alpinelinux/alpine-conf/blob/master/setup-disk.in#L62
2017-07-24 20:12:00 <ncopa> jirutka: it is a bug in setup-disk
2017-07-24 20:12:14 <ncopa> yup
2017-07-24 20:12:15 <jirutka> what it creates non-journaled ext4?!
2017-07-24 20:12:29 <ncopa> that sounds weird
2017-07-24 20:12:33 <ncopa> it shouldnt
2017-07-24 20:12:37 <ncopa> mkfs.ext4
2017-07-24 20:12:41 <ncopa> with default args
2017-07-24 20:13:09 <jirutka> I’m not sure what exactly setup-disk do, ’cause i don’t use it
2017-07-24 20:13:37 <ncopa> i'd be surprised if it creates it without journal
2017-07-24 20:13:43 <jirutka> but i’d say that mkfs.ext4 do not create non-journaled fs if you don’t explicitly ask for it and no one sane would add such option into setup-disk
2017-07-24 20:13:57 <ncopa> so i dont think that is the problem
2017-07-24 20:14:05 <ncopa> but we should verify it
2017-07-24 20:14:07 <jirutka> imo he created it purposely like that
2017-07-24 20:14:21 <ncopa> and we shoudl fix the fstab issue
2017-07-24 20:14:48 <ncopa> what is embarassing is that it went unnoticed for so long
2017-07-24 20:15:09 <ncopa> ok. need to sleep now
2017-07-24 20:15:51 <Shiz> night
2017-07-24 20:21:13 <kaniini_> .
2017-07-24 20:26:43 <Shiz> uh
2017-07-24 20:28:03 <kaniini> what
2017-07-24 20:28:07 <kaniini> i was debugging my shit
2017-07-24 20:28:21 <kaniini> the things i do for push notifications man
2017-07-24 20:34:33 <Shiz> does that mean i can highlight you for shitposting at 4am now
2017-07-24 20:40:42 <kaniini> only if you do it from an alpine-based phone
2017-07-24 21:41:43 <jirutka> https://cdn.meme.am/cache/instances/folder407/500x/80005407/say-what-again-say-sending-patches-via-email-is-simplicity-again-i-dare-you.jpg
2017-07-24 21:43:02 <kaniini> seems to work for the musl guys
2017-07-24 21:43:33 <jirutka> ofc, everything works until you experience something significantly better…
2017-07-24 21:43:48 <jirutka> and until some level of load
2017-07-24 21:44:29 <errm> I am thinking about packaging https://github.com/projectatomic/skopeo but it depends on ostree, is it ok to add a new package that depends on another that is still in testing?
2017-07-24 21:44:42 <kaniini> i don't deny that there is definitely
2017-07-24 21:44:54 <kaniini> more complexity in accepting alpine packages
2017-07-24 21:45:00 <kaniini> i am just saying it does work for some workflows
2017-07-24 21:45:45 <jirutka> errm: yes
2017-07-24 21:50:38 <errm> ok thanks
2017-07-24 22:11:59 <leo-unglaub> hey :)
2017-07-24 22:31:20 <jirutka> hi leo!
2017-07-24 22:32:10 <leo-unglaub> i fixed my routing problem, now my new alpine server is online
2017-07-24 22:32:18 <leo-unglaub> running on a openbsd vmd :)
2017-07-24 22:32:19 <jirutka> \o/
2017-07-24 22:32:24 <leo-unglaub> works very well
2017-07-24 22:32:34 <jirutka> vmd? great, how it works?
2017-07-24 22:32:48 <jirutka> how it performs in comparison with QEMU/KVM?
2017-07-24 22:33:00 <jirutka> how fast it boots?
2017-07-24 22:33:24 <leo-unglaub> its in very early development. alpine linux is basically the only linux running in it :)
2017-07-24 22:33:35 <leo-unglaub> boot time is around 2 seconds for the vmd and the vm itself
2017-07-24 22:33:56 <jirutka> I’ve tried xhyve (clone of FreeBSD’s bhyve for macOS) some time ago and I was quite impressed how fast it boots
2017-07-24 22:34:38 <leo-unglaub> alpine boot 2 seconds, and the daemon itself is also 2 seconds
2017-07-24 22:34:57 <leo-unglaub> so thats very good, but you have to use the alpine "virtual" image. standard or extended to not boot at all
2017-07-24 22:35:57 <leo-unglaub> i really see a great future for alpine in vmd
2017-07-24 22:37:03 <jirutka> how it handles memory? i mean is it possible to somehow truly dynamically (de)allocate memory for VM?
2017-07-24 22:37:14 <leo-unglaub> not yet
2017-07-24 22:37:16 <jirutka> to get similar experience like with containers
2017-07-24 22:37:56 <leo-unglaub> currently the only benefit of vmd is, that is is developed into the os itself. using security stuff like pledge and very priv-drop design pattern
2017-07-24 22:38:11 <leo-unglaub> also the cli tools are the only ones where you dont want to throw up while using it
2017-07-24 22:38:34 <leo-unglaub> that basically is it: https://man.openbsd.org/vmctl.8
2017-07-25 11:15:10 <clandmeter> im having a python error: UnicodeDecodeError: 'utf-8' codec can't decode byte 0x84 in position 155: invalid start byte
2017-07-25 11:15:15 <clandmeter> is this related to musl?
2017-07-25 11:16:49 <ashb> I doubt it. That sounds like actual invalid utf8. What's the next byte at posn 156?
2017-07-25 11:18:57 <clandmeter> i dont know, its part of some python app.
2017-07-25 11:19:03 <clandmeter> not sure how to debug that.
2017-07-25 11:19:49 <ashb> Py2 vs Py3?
2017-07-25 11:21:07 <clandmeter> py3
2017-07-25 11:21:15 <clandmeter> https://github.com/openpaperwork/pyocr/blob/master/src/pyocr/tesseract.py#L199
2017-07-25 11:21:29 <clandmeter> seems as it needs strict utf-8
2017-07-25 11:26:10 <_ikke_> clandmeter: what is the source of this data?
2017-07-25 11:26:47 <clandmeter> ocr data from tesseract
2017-07-25 11:30:00 <clandmeter> i tried to use .decode("utf-8", "ignore") but then it seems all data is ignored.
2017-07-25 11:33:22 <_ikke_> clandmeter: are you sure the input data is utf-8?
2017-07-25 11:35:21 <_ikke_> 0x84 happens to be a lower quotation mark in windows-1252
2017-07-25 11:35:29 <clandmeter> no, its an app so i dont manage the input myself
2017-07-25 11:36:12 <_ikke_> .decode('utf-8') assumes that the input data is utf-8
2017-07-25 11:36:36 <_ikke_> but if the system is providing a different encoding, at assumption breaks
2017-07-25 11:37:05 <clandmeter> yes, so most possibly its tesseract not providing utf8
2017-07-25 11:37:21 <_ikke_> It's doing a subprocess call
2017-07-25 11:37:40 <_ikke_> but through stdin/stdout
2017-07-25 11:37:50 <_ikke_> I would not expect anything to happen in between, right?
2017-07-25 11:38:09 <_ikke_> (Issue I had with this came from argv)
2017-07-25 11:39:07 <clandmeter> i need to dig deeper
2017-07-25 11:39:42 <clandmeter> i just wanted to make sure its not a musl issue, as musl acts different then glibc with encodings iirc.
2017-07-25 11:40:49 <_ikke_> right
2017-07-25 17:51:46 <jirutka> so, we have a problem…
2017-07-25 17:52:41 <^7heo> only one?! YAY! FINALLY! Almost done!
2017-07-25 17:52:45 <^7heo> 
ACTION hides

2017-07-25 17:52:57 <_ikke_> haha
2017-07-25 17:53:44 <jirutka> lua-aports is broken
2017-07-25 17:53:54 <jirutka> and the worst is that it’s my fault
2017-07-25 17:53:56 <jirutka> I have bad week :/
2017-07-25 17:54:08 <^7heo> happens to the best of us.
2017-07-25 17:54:23 <jirutka> the problem is that I’ve pushed it to aports… so builders are probably broken now
2017-07-25 17:54:34 <jirutka> cause there’s no single damn test in lua-aports! >_<
2017-07-25 17:54:35 <^7heo> can't you just push a fix and have it work?
2017-07-25 17:54:51 <^7heo> (naively asking)
2017-07-25 18:03:10 <jirutka> no chance, builders are broken
2017-07-25 18:03:26 <jirutka> clandmeter: are you here?
2017-07-25 18:06:23 <jirutka> I’m gonna force CI to this damn lua-aports repo; this can be detected by luacheck that I use in every single Lua project, but it’s not configured here and there are so many CQ violations that it’s easy to overlook the breaking ones
2017-07-25 19:46:52 <scadu> BREAKING BAD
2017-07-26 11:00:22 <jirutka> clandmeter: are you here?
2017-07-26 11:00:43 <clandmeter> kind of
2017-07-26 11:00:53 <jirutka> clandmeter: could you please fix builders?
2017-07-26 11:01:07 <clandmeter> better ask ncopa
2017-07-26 11:01:15 <clandmeter> i dont have access to all of them.
2017-07-26 11:01:16 <jirutka> clandmeter: he’s not responding
2017-07-26 11:01:31 <jirutka> clandmeter: it’s needed to manually update lua-aports to 0.6.1
2017-07-26 11:01:31 <clandmeter> try fabled
2017-07-26 11:01:43 <clandmeter> they are the only ones with full access
2017-07-26 11:02:11 <jirutka> two ppl who are not here very often and not in #alpine-infra, great :/
2017-07-26 11:02:30 <clandmeter> its because of signing keys access
2017-07-26 11:02:56 <clandmeter> the only alternative is a dedicated signing server
2017-07-26 11:03:14 <jirutka> yes, or more trust
2017-07-26 11:03:32 <jirutka> but dedicated signing server is the right approach
2017-07-26 11:05:16 <clandmeter> you could try to mail both ncopa and fabled and see if they can fix it.
2017-07-26 11:05:29 <clandmeter> and mention what needs to be done.
2017-07-26 11:05:30 <fabled> clandmeter, jirutka : what's broke?
2017-07-26 11:06:17 <jirutka> fabled: i’ve messed lua-aports 0.6.0, it must be upgraded to 0.6.1
2017-07-26 11:06:31 <jirutka> fabled: ppc64le is fixed, other edge are still broken
2017-07-26 11:07:09 <fabled> 0.6.1 is not available, it needs to be built first?
2017-07-26 11:07:45 <jirutka> fabled: yes
2017-07-26 11:07:48 <jirutka> it’s in aports
2017-07-26 11:07:55 <fabled> x86 fixed
2017-07-26 11:08:19 <fabled> x86_64 too
2017-07-26 11:11:31 <jirutka> also s390x is broken for several days due to some problem with unzip
2017-07-26 11:13:16 <ipin> !help
2017-07-26 11:31:12 <^7heo> ipin: doesn't work like that.
2017-07-26 11:31:34 <^7heo> algitbot: help me, this machine has no brain and so do I!
2017-07-26 11:31:44 <^7heo> \o/
2017-07-26 11:31:53 <^7heo> (yay it's still alive!)
2017-07-26 12:10:52 <fabled> jirutka, yes, ncopa just posted bb fix for unzip
2017-07-26 12:11:06 <Shiz> ipin: hi whats up
2017-07-26 14:07:30 <ncopa> hi
2017-07-26 14:07:32 <ncopa> im back
2017-07-26 16:14:48 <jirutka> ncopa: do you agree with splitting OpenRC runscripts into separate -openrc subpackage starting the next release of abuild?
2017-07-26 16:15:02 <kaniini> jirutka: it is opt-in
2017-07-26 16:15:19 <jirutka> kaniini: no, it doesn’t look like opt-in according to the patch
2017-07-26 16:15:37 <kaniini> jirutka: subpackages require $foo-openrc
2017-07-26 16:15:44 <jirutka> kaniini: that’s my concern, I would except some global switch like for implicit -dbg subpackage
2017-07-26 16:15:44 <kaniini> jirutka: it is opt-in
2017-07-26 16:15:48 <jirutka> aha, yes
2017-07-26 16:15:51 <jirutka> sry, you’re right
2017-07-26 16:16:31 <kaniini> there is an on/off switch too, but that one isn't being upstreamed yet.
2017-07-26 16:16:42 <jirutka> okay, so the state is that abuild will support it, so e.g. Adélia can use it, but we will not use it in aports yet, right?
2017-07-26 16:17:17 <kaniini> correct, for now.
2017-07-26 16:17:26 <jirutka> okay, so no problem on my side
2017-07-26 16:17:41 <kaniini> we wish to experiment with using s6 optionally for some services and therefore would not like to waste ramfs space on openrc scripts
2017-07-26 16:17:54 <jirutka> understand
2017-07-26 16:18:40 <^7heo> jirutka: it's Adélie btw ;)
2017-07-26 16:18:51 <skarnet> do openrc scripts live in tmpf
2017-07-26 16:18:53 <skarnet> s?
2017-07-26 16:19:12 <kaniini> skarnet: they do in a run-from-ram configuration
2017-07-26 16:19:14 <kaniini> :)
2017-07-26 16:19:32 <skarnet> ah, yes, modloop and all that.
2017-07-26 16:19:50 <jirutka> ^7heo: thanks for correction, i still don’t remember that name
2017-07-26 16:25:34 <^7heo> jirutka: think French, they put an "e" at the end of all the things.
2017-07-26 16:25:42 <^7heo> jirutka: even "euuuuuh" most of the times.
2017-07-26 16:25:47 <jirutka> fcolista: check phase runs after build and before package, so could you please put the check function between these two to make apkbuilds more clear?
2017-07-26 16:25:52 <^7heo> jirutka: as in "Adélieuuuuh"
2017-07-26 16:26:26 <^7heo> (eu is not the English e-u but the German ö)
2017-07-26 16:26:47 <jirutka> i don’t speak German or French, so i don’t understand what the heck do you mean XD
2017-07-26 16:27:55 <^7heo> phonetically it's ø, œ
2017-07-26 16:28:02 <^7heo> if it means anything to you
2017-07-26 16:28:49 <jirutka> i think that i will continue pronouncing it like in Czech
2017-07-26 16:29:09 <jirutka> so [adélie], it’s like Adéla (name)
2017-07-26 16:29:11 <kaniini> ad-elle-ie
2017-07-26 16:29:16 <kaniini> is how it is pronounced
2017-07-26 16:29:30 <jirutka> should there be long é?
2017-07-26 16:29:30 <^7heo> actually, it's just 'i' at the end.
2017-07-26 16:29:34 <_ikke_> jirutka: yes
2017-07-26 16:29:36 <^7heo> a long one, but just 'i'
2017-07-26 16:29:47 <jirutka> so just [adéli]?
2017-07-26 16:29:51 <^7heo> yeah.
2017-07-26 16:30:02 <jirutka> what does it actually mean?
2017-07-26 16:30:08 <_ikke_> Isn't it a name?
2017-07-26 16:30:10 <^7heo> if your language has a concept of long and short voyels, then [adélii]
2017-07-26 16:30:21 <^7heo> (to denote the long i)
2017-07-26 16:30:22 <Shiz>   @kaniini : jirutka: subpackages require $foo-openrc
2017-07-26 16:30:25 <Shiz> i'm slightly confused now
2017-07-26 16:30:36 <_ikke_> A name like Adelle
2017-07-26 16:30:39 <^7heo> jirutka: it doesn't mean anything, it is a proper name, as _ikke_ said.
2017-07-26 16:30:49 <jirutka> okay
2017-07-26 16:31:08 <^7heo> _ikke_: ethymologically speaking, "Adélie" would me "the small Adèle"
2017-07-26 16:31:17 <jirutka> interesting
2017-07-26 16:31:28 <jirutka> so it’s Adélka :P
2017-07-26 16:31:35 <^7heo> Very probably, yes.
2017-07-26 16:31:38 <_ikke_> Adelletje :P
2017-07-26 16:31:50 <^7heo> and yes Adelltje in Hollandisch
2017-07-26 16:31:57 <kaniini> Shiz: i added an abuild patch that is carried in adelie to allow us to have a default $foo-openrc split
2017-07-26 16:32:09 <kaniini> Shiz: but it is opt-in, e.g. you have to have $foo-openrc like $foo-doc
2017-07-26 16:32:22 <Shiz> oh right
2017-07-26 16:32:24 <Shiz> yeah
2017-07-26 16:32:32 <Shiz> i'd like to move all of our existing openrc subpackages to use that though
2017-07-26 16:32:34 <Shiz> :P
2017-07-26 16:32:37 <Shiz> openrc-enabled
2017-07-26 16:32:38 <Shiz> packages*
2017-07-26 16:32:45 <jirutka> nope pls
2017-07-26 16:33:08 <Xe> how will migration work?
2017-07-26 16:33:13 <^7heo> not
2017-07-26 16:33:15 <^7heo> 
ACTION hides

2017-07-26 16:33:39 <kaniini> Xe: it is an install_if rule, so on upgrade it will just be pulled in.
2017-07-26 16:33:45 <jirutka> it would work w/o problems, but it doesn’t make sense to do it now since we don’t really support any other init system yet
2017-07-26 16:33:49 <kaniini> but this isn't relevant to alpine (or even adelie) yet
2017-07-26 16:33:51 <Shiz> what kaniini said
2017-07-26 16:34:17 <Shiz> well i think it's a semantically cleaner separation regardless of if we directly use it yet or not
2017-07-26 16:34:32 <kaniini> i agree, but i don't want to propose it be a release goal for 3.7
2017-07-26 16:35:01 <jirutka> also i still quite hope that we will be able to use declarative OpenRC runscripts even for s6… with declarative i mean runscripts without overridden start/stop/status functions
2017-07-26 16:35:48 <Shiz> declarative was one of my major conditions for #alpine-s6
2017-07-26 16:35:49 <Shiz> :P
2017-07-26 16:36:44 <jirutka> but not declarative-only… that’s the beauty of using shell for runscripts, you can still script if you need, typically start_pre functions
2017-07-26 16:37:20 <kaniini> should be possible
2017-07-26 16:37:21 <jirutka> without need to reinvent hyper-complex syntax and support for every case…
2017-07-26 16:37:30 <^7heo> on the other hand, procedural processing makes it exponentially harder not to break things on upgrade when upstream changes significantly.
2017-07-26 16:37:38 <^7heo> Especially if they do that multiple times.
2017-07-26 16:38:18 <jirutka> i don’t understand what you mean…?
2017-07-26 16:38:26 <^7heo> if it is done declaratively, the fix on the procedural part (processing the declarations) will be applied globally to all the packages.
2017-07-26 16:39:07 <^7heo> what I mean is that if you have a start_pre function that is enforcing some stuff that could be described instead (a user existing, a umask, you name it)
2017-07-26 16:39:12 <^7heo> and upstream changes
2017-07-26 16:39:57 <jirutka> i’d say it’s quite opposite, with shell you can easily deal with such cases
2017-07-26 16:40:04 <jirutka> you can conditionally apply this or that
2017-07-26 16:40:10 <^7heo> managing the migrations is gonna be painful, since you never know what version it's upgraded from; and even if you do, it'd force you to explicitely code all the possibilities in.
2017-07-26 16:40:19 <jirutka> with declarative only you’re basically screwed
2017-07-26 16:40:34 <^7heo> well, declarative is never only declarative.
2017-07-26 16:40:40 <^7heo> it's only the part WE modify that is.
2017-07-26 16:40:56 <^7heo> in the end, it's read, parsed, processed, and then procedural code is executed conditionally.
2017-07-26 16:41:08 <^7heo> so it's like using a library vs copy pasting
2017-07-26 16:41:24 <^7heo> at least when you use a library, a fix is fixing all the uses.
2017-07-26 16:41:34 <^7heo> when you copy/paste code, you have to copy/paste the fixes.
2017-07-26 16:41:34 <jirutka> i’m quite lost know, but never mind, i need to do some work
2017-07-26 16:41:39 <jirutka> yes
2017-07-26 16:41:40 <^7heo> yeah same.
2017-07-26 16:41:46 <jirutka> that’s the current problem with apkbuild bts
2017-07-26 16:41:47 <jirutka> btw
2017-07-26 16:41:58 <jirutka> a lot of copy-pasting; but that’s different topic
2017-07-26 16:42:22 <^7heo> true
2017-07-26 17:56:40 <ncopa> im back again
2017-07-26 17:56:53 <ncopa> i think the -openrc subpackages makes sense
2017-07-26 18:06:49 <skarnet> they're the first step towards separation of mechanism and policy \o/
2017-07-26 18:07:34 <ncopa> and use install_if="openrc ..." makes sense too
2017-07-26 18:07:45 <ncopa> so if you have openrc installed you get it automatically
2017-07-26 18:07:54 <ncopa> if you remove openrc it goes away
2017-07-26 18:11:00 <ncopa> before we go there, i'd just like to verify with fabled that we dont make memory use explode when resolving the deps in apk
2017-07-26 18:11:54 <ncopa> it would make docker images smaller too
2017-07-26 18:19:29 <tmh1999> ncopa : hi, sorry I haven't kept track of the current aports work. been working on musl + s390-tools + bootloader stuff lately
2017-07-26 18:19:41 <tmh1999> looks like you have made the patch for busybox
2017-07-26 18:20:17 <ncopa> hi tmh1999! i've missed you :)
2017-07-26 18:20:54 <tmh1999> ncopa : yeah miss you and everyone too ! is there anything I could help ?
2017-07-26 18:21:14 <tmh1999> I am reading the backlog on github
2017-07-26 18:21:36 <ncopa> i think the most urgen thing was that busybox regression but i fixed it yesterday
2017-07-26 18:21:54 <ncopa> i havent checked if the s390x builder completes main and community
2017-07-26 18:21:55 <ncopa> oh
2017-07-26 18:22:02 <ncopa> i htink it fails on libreoffice for some reason
2017-07-26 18:22:24 <tmh1999> I see
2017-07-26 18:23:03 <ncopa> what is the status with the s390x boot loader?
2017-07-26 18:23:08 <ncopa> where is it blocking?
2017-07-26 18:23:52 <tmh1999> as in the last email, I have an instance in KVM but I still cannot make #alpine-setup working yet
2017-07-26 18:24:01 <tmh1999> I am reading the zipl stuff
2017-07-26 18:24:32 <tmh1999> all other distros compile zipl with -no-pie
2017-07-26 18:24:49 <tmh1999> this was also discussed on #musl before
2017-07-26 18:24:51 <ncopa> i think -no-pie makes sense
2017-07-26 18:24:56 <ncopa> may make sense
2017-07-26 18:24:59 <ncopa> its a bootloader
2017-07-26 18:25:03 <tmh1999> yes
2017-07-26 18:25:07 <tmh1999> perfect
2017-07-26 18:25:35 <tmh1999> tbh I am reading zipl + other distro's integration of zipl + grub
2017-07-26 18:25:41 <tmh1999> to learn how it works
2017-07-26 18:34:23 <ncopa> good
2017-07-26 18:34:28 <ncopa> let me know if you get stuck
2017-07-26 18:49:05 <foxkit> jirutka: https://en.wikipedia.org/wiki/Ad%C3%A9lie_penguin
2017-07-26 18:49:31 <jirutka> ahá!
2017-07-26 18:49:38 <foxkit> it is a smaller, more nimble, faster-swimming cousin of the Gentoo penguin
2017-07-26 18:49:41 <foxkit> pun intended
2017-07-26 18:50:03 <foxkit> though the pun doesn't work so well, since we are no longer downstream of gentoo
2017-07-26 18:50:22 <foxkit> so now it's just a cuddly penguin that looks cute
2017-07-26 18:59:31 <jirutka> :P
2017-07-26 19:54:32 <kaniini> foxkit: i merged the openrc stuff to abuild
2017-07-26 19:57:53 <foxkit> kaniini: yep, saw that.  much obliged
2017-07-26 19:58:47 <PureTryOut[m]> `WARNING: Total of 22 unsatisfiable package names. Your repository maybe broken.`
2017-07-26 19:58:52 <PureTryOut[m]> s/maybe/may be
2017-07-26 19:59:01 <PureTryOut[m]> is that worth PR'ing? 😛
2017-07-26 19:59:17 <jirutka> probably not…? o.O
2017-07-26 19:59:22 <jirutka> or what do you mean?
2017-07-26 19:59:38 <PureTryOut[m]> "Your repository maybe broken" <-- typo
2017-07-26 19:59:41 <PureTryOut[m]> should be "may be"
2017-07-26 19:59:56 <foxkit> PureTryOut[m]: https://git.alpinelinux.org/cgit/apk-tools/commit/?id=9325eb721d123bbcb51f0cd838fbe7dc54bc77bb
2017-07-26 20:00:08 <jirutka> aaha
2017-07-26 20:00:13 <PureTryOut[m]> ooh haha
2017-07-26 20:00:14 <PureTryOut[m]> nice
2017-07-26 20:00:17 <jirutka> yes, that’s worth PR’ing :)
2017-07-26 20:48:02 <kaniini> foxkit: i followed up on the adelie merge PR
2017-07-26 20:48:47 <jirutka> do not add coreutils to checkdepends!
2017-07-26 20:49:16 <kaniini> hmm, true that creates a loop
2017-07-26 20:49:18 <kaniini> now that i think about it
2017-07-26 20:49:25 <kaniini> because coreutils requires attr, doesn't it?
2017-07-26 20:49:44 <jirutka> yes
2017-07-26 20:49:57 <jirutka> and also they are installed before building pkgs, so it may have negative consequences, you may not notice some breakages
2017-07-26 20:50:05 <jirutka> the proper solution is to patch these damn tests
2017-07-26 20:51:49 <kaniini> i think we just disable the 2 broken tests for now
2017-07-26 20:51:56 <jirutka> foxkit: please build/test pkgs for Alpine on actual Alpine system, you can run it in LXC or just inside plain old chroot
2017-07-26 20:52:15 <jirutka> yeah, that’s also a solution, if these tests are not somehow critical
2017-07-26 20:52:25 <kaniini> they dont appear to be
2017-07-26 20:52:28 <kaniini> they seem redundant
2017-07-26 21:00:12 <jirutka> I’m still not sure about ca-certificates…
2017-07-26 21:00:33 <jirutka> who is the upstream? Debian?
2017-07-26 21:09:26 <kaniini> yes, Debian
2017-07-26 21:09:55 <jirutka> so why they just don’t release new version, with new dsate?
2017-07-26 21:10:01 <jirutka> why this weird suffix?
2017-07-26 21:10:14 <kaniini> non-maintainer upload
2017-07-26 21:10:17 <jirutka> and why we use ca certs from debian instead of Mozilla or curl?
2017-07-26 21:10:30 <jirutka> and what *exactly* does this mean?
2017-07-26 21:10:43 <jirutka> when they are the upstream
2017-07-26 21:11:17 <kaniini> in this case it means the security team uploaded it and the actual maintainer of that package did not sign off on it
2017-07-26 21:11:36 <jirutka> uh, that’s really weird…
2017-07-26 21:11:54 <kaniini> such is life
2017-07-26 21:12:01 <jirutka> i don’t think it’s correct to bump just pkgrel
2017-07-26 21:12:11 <jirutka> this should affect the actual version
2017-07-26 21:12:13 <kaniini> it technically is
2017-07-26 21:12:31 <jirutka> so something like YYYYMMDD_p1…?
2017-07-26 21:12:32 <kaniini> it is the same version, with an imaginary patch
2017-07-26 21:12:53 <jirutka> hm, yes…
2017-07-26 21:13:09 <jirutka> okay, and why not use ca certs from Mozilla?
2017-07-26 21:17:43 <kaniini> because if you do that, you are just reinventing the other parts debian added to the package
2017-07-26 21:19:17 <kaniini> and they do not really have a CA cert bundle you can just download anyway
2017-07-26 21:19:24 <kaniini> it has to be extracted from mozilla sources
2017-07-26 21:22:54 <kaniini> the debian ca-certificates package contains a mozilla CA cert bundle that it processes in various ways
2017-07-26 21:23:34 <jirutka> in which ways?
2017-07-26 21:26:14 <jirutka> https://curl.haxx.se/docs/caextract.html
2017-07-26 21:26:33 <jirutka> these are also more up-to-date
2017-07-26 21:32:23 <kaniini> if we are to change it from debian, i rather use mozilla directly as a source
2017-07-26 21:33:23 <kaniini> which is https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt
2017-07-26 21:34:04 <jirutka> that’s quite odd format o.O
2017-07-26 21:51:15 <kaniini> (1/1) Upgrading ca-certificates (20161130-r3 -> 20170726-r0)
2017-07-26 21:51:31 <kaniini> i modified the APKBUILD to pull directly from a local copy of certdata.txt
2017-07-26 21:52:35 <kaniini> so we just upgrade it from time to time
2017-07-26 21:55:10 <jirutka> i really don’t like adding such huge file directly to aports repository… it’d be better to upload it to dev.a.o
2017-07-26 21:55:35 <kaniini> i want to maintain git log of certdata.txt
2017-07-26 21:55:51 <kaniini> it is important for the sake of transparency
2017-07-26 21:56:17 <jirutka> so then create a separate repository for it?
2017-07-26 21:56:34 <kaniini> sure
2017-07-26 21:56:47 <kaniini> that option isn't available to me though, i think an infra person has to do it?
2017-07-26 21:57:51 <jirutka> you can create repo on GH… we can mirror it to git.a.o later ;)
2017-07-26 21:58:22 <kaniini> uh huh
2017-07-26 21:58:36 <kaniini> something something non-free cloud services
2017-07-26 21:59:25 <jirutka> still better than polluting main repository with too huge files…
2017-07-26 21:59:55 <kaniini> jirutka: irrespective of certdata.txt presently being in aports - is that solution acceptable to you?
2017-07-26 22:00:10 <foxkit> trusting github with certdata.txt sounds like great idea *eyeroll*
2017-07-26 22:00:31 <foxkit> noted about the checkdepends... not sure how to disable tests in that test suite, I will look in to that
2017-07-26 22:00:57 <kaniini> yes, i rather wait for a certdata repo to be made by infra team.  i already asked for it.
2017-07-26 22:07:14 <jirutka> kaniini: yes
2017-07-27 06:30:08 <fcolista> morning all
2017-07-27 11:34:25 <mosez> how do you guys run the mirrors? some rsync scripting?
2017-07-27 11:34:53 <mosez> currently i'm searching for a good new mirror setup for ownCloud which is scaleable on download peaks
2017-07-27 12:02:18 <Shiz> yeah, rsync
2017-07-27 12:02:24 <Shiz> and an mqtt message queue for when updates are available
2017-07-27 12:31:04 <xentec> ncopa: APKINDEX on nl.a.o seems broken. ncurses-libs has multiple versions https://dpaste.de/TEut#L1,9,19
2017-07-27 12:32:10 <ncopa> xentec: what does apk policy ncurses-libs say?
2017-07-27 12:32:35 <xentec> ncurses-libs policy:  6.0-r7:
2017-07-27 12:35:12 <xentec> ncopa: https://dpaste.de/7Smh (complete output)
2017-07-27 12:35:45 <ncopa> its the installed version of ncurses-libs
2017-07-27 12:35:47 <ncopa> apk version
2017-07-27 12:37:05 <xentec> I'm confused right now: https://dpaste.de/Ju0D#L1,4
2017-07-27 12:39:19 <xentec> ncopa: nevermind. had a custom version of ncurses-terminfo-base which somehow prevented ncurses-libs from updating
2017-07-27 12:44:27 <xentec> ncopa: you can also close #7608.
2017-07-27 13:06:09 <mosez> shiz: is this setup published somehow somewhere? :)
2017-07-27 13:12:23 <xentec> mosez: https://wiki.alpinelinux.org/wiki/How_to_setup_a_Alpine_Linux_mirror
2017-07-27 13:17:40 <jirutka> xentec: another way for mirror https://gist.github.com/jirutka/288c6fff7c0b8a835d143686207316be
2017-07-27 13:19:22 <mosez> xentec: thx
2017-07-27 20:59:47 <foxkit> are fixes to cross-compiling packages wanted?
2017-07-27 21:00:00 <foxkit> readline has wrong makedepends_host (well, none actually) as does bash
2017-07-27 21:00:34 <jirutka> foxkit: yes
2017-07-27 21:01:26 <Shiz> yes
2017-07-27 21:03:30 <Shiz> foxkit: most packages right now aren't xcompile compatible, i had to change some for my llvm-based bootstrap as well
2017-07-27 21:03:34 <Shiz> would not mind at all fixes to that
2017-07-27 21:07:59 <foxkit> can someone fix the unzip thing?
2017-07-27 21:08:09 <foxkit> the APKBUILD uses distfiles.alpinelinux.org to avoid FTP
2017-07-27 21:08:15 <foxkit> but the file is no longer there
2017-07-27 21:08:19 <jirutka> aha, i’ll look at it
2017-07-27 21:08:33 <jirutka> it’s in your PR, right?
2017-07-27 21:08:53 <foxkit> yes
2017-07-27 21:08:57 <foxkit> it's the only failure
2017-07-27 21:09:30 <foxkit> also, for anyone interested: the gcc failure is only on x86_64 and it is because of 'cilkrts', some silly C++ language extension that I didn't even know existed; disabling it in configure allows me to fake-cross the entire x86_64 toolchain
2017-07-27 21:09:37 <foxkit> so this does seem like actual gcc bug, not apk
2017-07-27 21:09:59 <jirutka> foxkit: btw if you like to make community/rust cross-compilable, I’d be very happy :)
2017-07-27 21:10:05 <Shiz> oh dear
2017-07-27 21:10:10 <Shiz> jirutka: it already is though
2017-07-27 21:10:11 <Shiz> :P
2017-07-27 21:10:17 <jirutka> Shiz: really?
2017-07-27 21:10:25 <jirutka> Shiz: so why we don’t compile it for other arches?
2017-07-27 21:10:29 <foxkit> jirutka: since my ppc builder is dual 1.8GHz, that will almost /require/ cross-compile
2017-07-27 21:10:35 <foxkit> jirutka: so I definitely will fix it up if it needs it
2017-07-27 21:10:38 <Shiz> dunno, nobody did it yet
2017-07-27 21:10:47 <jirutka> Shiz: what is needed to be done?
2017-07-27 21:10:50 <Shiz> but the build steps are already a cross-compile
2017-07-27 21:11:04 <Shiz> because it cross-compiles from x86_64-unknown-linux-musl to x86_64-alpine-linux-musl
2017-07-27 21:11:10 <Shiz> for the build system thats an xcompile
2017-07-27 21:11:11 <foxkit> oh
2017-07-27 21:11:22 <foxkit> also, for openrc split thing: there is very important reason to not make it "automatic" for all packages
2017-07-27 21:11:23 <Shiz> so all it would need is proper makedepends_{host,build}
2017-07-27 21:11:24 <foxkit> openrc itself
2017-07-27 21:11:25 <Shiz> and it should work
2017-07-27 21:11:33 <foxkit> when I did gentoo-based alpine... that happened... openrc-openrc
2017-07-27 21:11:42 <foxkit> er gentoo-based adelie*
2017-07-27 21:12:06 <Shiz> lol
2017-07-27 21:12:09 <Shiz> well
2017-07-27 21:12:10 <foxkit> and the worst part was install_if wasn't working with the dumb tools that I had available on gentoo.. so... I had to tell people to manually install openrc-openrc
2017-07-27 21:12:37 <Shiz> imo the default scripts should be part of baselayout-openrc
2017-07-27 21:12:38 <Shiz> 
ACTION hides

2017-07-27 21:13:43 <foxkit> that's not a terrible idea but still openrc-openrc is silly :P
2017-07-27 21:15:05 <foxkit> [censored] I switched branches out from under abuild and broke everything ;.;
2017-07-27 21:15:19 <jirutka> foxkit: unzip is now available at https://dev.alpinelinux.org/archive/unzip/unzip60.tgz, please source url in unzip pkg (note that it’s tgz instead of zip, so builddir must be probably adjusted)
2017-07-27 21:15:25 <Shiz> ;_;
2017-07-27 21:16:24 <foxkit> jirutka: ah, good... now there won't be circular dep.. bootstrapping that on ppc required me to boot debian and use musl-gcc
2017-07-27 21:16:34 <foxkit> because unzip.zip needs unzip to unzip
2017-07-27 21:16:37 <Shiz> lol
2017-07-27 21:16:50 <jirutka> yep, I don’t understand why someone used .zip before…
2017-07-27 21:17:11 <jirutka> it’s like famous WinRAR packed in .rar… XD
2017-07-27 21:17:25 <jirutka> heh, .rar, i haven’t seen this extension for more than 10 years
2017-07-27 21:17:26 <foxkit> exactly haha
2017-07-27 21:17:41 <Shiz> what about
2017-07-27 21:17:43 <Shiz> .arc
2017-07-27 21:18:04 <foxkit> ugh.. I had to fix arj build in gentoo..
2017-07-27 21:18:12 <foxkit> which yes.. arj somehow still exists
2017-07-27 21:19:17 <jirutka> uh, actually i was wrong, I still see .rar… movies from scene
2017-07-27 21:19:31 <jirutka> i somehow forced my brain to ignore that
2017-07-27 21:19:35 <foxkit> jirutka: builddir doesn't seem to change
2017-07-27 21:19:44 <foxkit> jirutka: it is building on my ppc builder right now with the new URL
2017-07-27 21:19:52 <jirutka> okay
2017-07-27 21:20:00 <Shiz> :]
2017-07-27 21:20:13 <foxkit> if all goes well I will throw it at the alpine x86_64 box then push to the branch.
2017-07-27 21:25:06 <foxkit> https://bpaste.net/raw/ea8be6090f51
2017-07-27 21:25:46 <foxkit> four packages kicking around that use .rar it seems
2017-07-27 21:26:04 <foxkit> don't have my debian repo accessible right now or I'd check there too.  it looks like Fedora's already cleaned them all out.
2017-07-27 22:56:07 <foxkit> nice green tickmark ^^
2017-07-27 23:01:29 <jirutka> foxkit: so finished?
2017-07-27 23:01:46 <foxkit> yes please review again, it should be ready
2017-07-27 23:35:35 <foxkit> jirutka: thank you very much :3
2017-07-27 23:36:35 <jirutka> foxkit: you’re welcome!
2017-07-27 23:36:47 <foxkit> hoping to have more frequent merges with tighter feedback loops as time progresses.  this was all bootstrap stuff
2017-07-27 23:37:01 <foxkit> just saw bootstrap.sh x86_64 finish up, so now I can use my mighty 8-core box
2017-07-27 23:37:11 <foxkit> instead of the little powerpc that could
2017-07-27 23:37:13 <foxkit> :P
2017-07-27 23:37:31 <foxkit> the poor thing is 12 years old..
2017-07-27 23:40:44 <jirutka> just curious, why do you wanna support such old powerpc?
2017-07-27 23:47:54 <foxkit> jirutka: there are lots of users and debian is abandoning them.  I already have 7 people from /r/powerpc on reddit following along with development.
2017-07-27 23:48:04 <foxkit> jirutka: we just love our old powerpcs :)
2017-07-27 23:48:54 <foxkit> they aren't great for build boxes, but they still work quite well for desktop usage... most have 2-4 GB RAM, SATA disks, and CPU speeds in the 1.4-2.4ghz range... that's a bog standard laptop these days.
2017-07-27 23:57:00 <foxkit> jirutka: another is that they don't have anything like Intel ME or AMD PSP or anything running in the firmware that can't be trusted... OpenFirmware is all readable and dumpable and written in forth so the binary is the source and so on.
2017-07-28 00:06:38 <Shiz> foxkit: alpine pc98 port when
2017-07-28 00:06:40 <Shiz> :p
2017-07-28 00:47:27 <jirutka> OpenFirmware is written in Forth? wow!
2017-07-28 00:52:37 <trn> Ofw inplements forth :)
2017-07-28 00:52:55 <trn> I'm not sure what it itself is written in :)
2017-07-28 01:27:37 <jirutka> I’ve alpinised another project’s CI :P https://github.com/xianyi/OpenBLAS/pull/1255
2017-07-28 06:14:39 <kaniini> justincormack_: have you guys considered using gcompat for linuxkit instead of all of these library hacks? :P
2017-07-28 06:46:28 <ncopa> lua-compas tests are broken on aarch64 and s390x apparently
2017-07-28 06:49:57 <kaniini> apparently talos2 is supposed to be only 1800-2400 USD
2017-07-28 06:50:13 <kaniini> meaning it is possible to actually have a non-x86 alpine desktop with actual power
2017-07-28 06:54:12 <ncopa> talos2 is a ssd over sas?
2017-07-28 06:54:35 <ncopa> what would the rest of the machine be for non-x86?
2017-07-28 06:56:15 <kaniini> ncopa: https://www.raptorcs.com/TALOSII/prerelease.php
2017-07-28 06:56:25 <kaniini> it's a commercial ppc64le machine
2017-07-28 06:58:24 <ncopa> desktop machine with power9?
2017-07-28 06:58:25 <ncopa> wow
2017-07-28 07:01:33 <kaniini> such a machine with alpine + musl would be quite fast
2017-07-28 07:01:51 <ncopa> yes
2017-07-28 07:13:16 <clandmeter> jirutka, why did you remove -DCMAKE_INSTALL_SYSCONFDIR=/etc from tarantool?
2017-07-28 10:02:07 <ncopa> i think i know why lua-copas fails
2017-07-28 10:02:12 <ncopa> on aarhc64 and s390x
2017-07-28 10:02:22 <ncopa> and i know how to reproduce it on any machine i think
2017-07-28 10:02:26 <ncopa> its ipv6
2017-07-28 10:02:50 <ncopa> echo "::1  localhost" >> /etc/hosts
2017-07-28 10:02:58 <ncopa> and run the lua-copas tests
2017-07-28 10:38:34 <jirutka> clandmeter: ’cause this is the default value
2017-07-28 10:38:57 <clandmeter> its putting etc in /usr
2017-07-28 10:39:18 <jirutka> clandmeter: uh, really? i must overlooked it :(
2017-07-28 10:40:22 <jirutka> clandmeter: I’m gonna fix it
2017-07-28 10:40:34 <jirutka> clandmeter: there’s also one fix i forgot to merge, just realized it now
2017-07-28 11:15:00 <jirutka> clandmeter: pushed; sorry about this, i didn’t noticed it before, ’cause i didn’t installed their configs
2017-07-28 12:02:07 <ncopa> looks like tarantool does not run on aarch64?
2017-07-28 12:05:03 <jirutka> ncopa: it does not, as stated in apkbuild, comment behind arch= ;)
2017-07-28 12:06:15 <jirutka> ncopa: maybe we can copy aarch64 patch from luajit pkg
2017-07-28 12:07:01 <ncopa> ncopa-edge-x86_64:~/aports/testing/tarantool$ grep aarch64 APKBUILD
2017-07-28 12:07:01 <ncopa> ncopa-edge-x86_64:~/aports/testing/tarantool$
2017-07-28 12:07:22 <jirutka> ncopa: eh, pardon, aarch64
2017-07-28 12:07:39 <jirutka> ncopa: i misplaced it with ppc64le
2017-07-28 12:07:43 <ncopa> i just noticed the builder choked
2017-07-28 12:07:56 <jirutka> ncopa: sry, i need a coffee :)
2017-07-28 12:08:27 <jirutka> ncopa: i don’t know about aarch64 support; tbh tarantool is quite messy project :/
2017-07-28 12:08:41 <ncopa> seems like that
2017-07-28 12:09:35 <ncopa> arch support seems to be "all arches except (all except x86_64)" :)
2017-07-28 12:10:05 <jirutka> i’d disagree about their claim about 100% drop-in compatibility with Lua/LuaJIT… LuaJIT does support aarch64 and x86, but they apparently don’t…
2017-07-28 12:10:17 <ncopa> maybe better to use whitelist of arches it supports
2017-07-28 12:10:45 <jirutka> in this case, yes
2017-07-28 12:11:00 <jirutka> does it work on armhf?
2017-07-28 12:11:06 <ncopa> dunno
2017-07-28 12:11:43 <ncopa> luajit as dropin compatible with lua is overrated yes
2017-07-28 14:13:15 <foxkit> Shiz: I can't tell if the pc9800 patches were ever merged in to the kernel; looks like there was effort around 2.5.31
2017-07-28 14:13:20 <foxkit> Shiz: debian98 exists, but the docs are in japanese
2017-07-28 14:14:06 <foxkit> Shiz: anyway, the PC9821 C/I series should be easily supportable as long as grub98 is packaged.  they are typical Pentium systems with PCI buses.  I don't think the C bus was ever supported by Linux, even with the patches.  the biggest difference is the BIOS
2017-07-28 14:14:29 <foxkit> Shiz: if you use a PCI video card, X11 should even work; I don't think the XFree86 PC-98 servers were ever ported to X.org
2017-07-28 14:15:27 <foxkit> Shiz: and if you didn't care about all of this, you shouldn't have asked XD
2017-07-28 14:22:23 <Shiz> i was kidding :P
2017-07-28 14:22:34 <Shiz> pc98 support was mainline in late 2.4 and early 2.6
2017-07-28 14:22:36 <Shiz> and then it got nuked
2017-07-28 14:22:47 <Shiz> the bsds have C-bus support
2017-07-28 20:59:36 <foxkit> is there a way to make abuild -R not build things I already built
2017-07-28 20:59:54 <foxkit> like, abuild -R in perl builds everything perl requires, but then abuild -R in git builds all of perl's deps and perl itself again
2017-07-28 21:01:06 <skarnet> abuild -r ?
2017-07-28 21:01:26 <foxkit> abuild -r requires everything to be built already
2017-07-28 21:01:43 <foxkit> 'xmlto' and 'tk' haven't been built yet
2017-07-28 21:02:04 <skarnet> it will build them if they haven't been built before
2017-07-28 21:02:37 <skarnet> AIUI that's the point of -r
2017-07-28 21:07:53 <jirutka> I’ve just merged pull request no. 2000!
2017-07-28 21:09:45 <jirutka> \o/
2017-07-28 22:53:25 <foxkit> I just managed to segfault apk...
2017-07-28 22:54:23 <Shiz> nice
2017-07-28 23:03:38 <foxkit> wow
2017-07-28 23:03:41 <foxkit> found the bug