2018-10-01 08:37:36 <Bodenhaltung> Has anyone running mariadb with galera cluster on alpine and can help me to setup?
2018-10-01 08:44:56 <Bodenhaltung> And something like logcheck?
2018-10-02 11:49:11 <vkrishn> bit of testing cleanup, project drizzle seems have stalled, kiyoshi around ?
2018-10-02 11:58:06 <vkrishn> cpupower could be merged in testing/linux-tools
2018-10-02 11:58:35 <vkrishn> and since don't have grsec, the kernel updated to
2018-10-02 11:59:42 <vkrishn> anyone having plans to donate hardware, let me know
2018-10-02 12:43:10 <leo-unglaub> hey, i just updated mariadb from the 3.7 version (10.2) to the 3.8 version (10.3) and now my PHP cannot connect to it anymore. is that a know problem? or am i the first one with that issue?
2018-10-02 13:17:38 <TBB> Question: am I right in my assumption that the sudden appearance of -openrc packages imply possible other init systems in the future?
2018-10-02 13:18:03 <TBB> *implies, sorry, Ubuntu robbed most of my sleep last night :P
2018-10-02 13:18:10 <_ikke_> TBB: The preperations are being made yes, but afaik no decissions has been made yet
2018-10-02 13:23:57 <Shiz> leo-unglaub: not that i know of
2018-10-02 13:24:00 <Shiz> any mariadb logs?
2018-10-02 13:25:36 <mps> _ikke_: do you which one is planned and will be openrc stay default
2018-10-02 13:25:55 <_ikke_> no
2018-10-02 13:26:34 <mps> s/do you/do you know/
2018-10-02 13:26:58 <mps> s6, maybe?
2018-10-02 13:34:04 <TBB> s6 is already there in some limited capacity... I'm honestly not even aware of any serious alternatives right now
2018-10-02 13:35:29 <leo-unglaub> Shiz: mariadb disabled all networking in a post upgrade script breaking existing configs
2018-10-02 13:35:36 <leo-unglaub> i have undone it and now it works again
2018-10-02 13:35:45 <Shiz> oof
2018-10-02 13:36:04 <mps> TBB: yes, s6 is in AL, but which one will be default in future, the question is
2018-10-02 13:36:31 <Shiz> there are no concrete plans for alternative init systems as of right now
2018-10-02 13:36:41 <Shiz> this is just the infrastructure to make it possible
2018-10-02 13:38:11 <mps> Shiz: tnx for explanation. So, I don't need to learn another init system, for now at least
2018-10-02 13:38:20 <Shiz> right :)
2018-10-02 13:38:36 <Shiz> and if it were to happen you could always still just use openrc
2018-10-02 13:38:52 <TBB> mps, correction, "which one the default in future will be" ;)
2018-10-02 13:39:17 <TBB> (you went quite Yoda at the end)
2018-10-02 13:40:03 <TBB> yeh, I have no problems with openrc, I was just wondering whether I guessed correctly the -openrc thing. It's a good move, creates some room in the future
2018-10-02 13:40:32 <mps> TBB: I'm self taught in English, so sorry because I translate word by word from my language to English
2018-10-02 13:41:43 <TBB> mps, no problem at all and I wasn't seriously trying to mock you, that "the question is" just instantly triggered a Star Wars association
2018-10-02 13:42:44 <TBB> languages work differently and I can't avoid sometimes using English with the structure of Finnish :)
2018-10-02 13:43:27 <mps> TBB: don't worry, I'm not resentful (offended)
2018-10-02 13:44:22 <TBB> okay :) back to the topic, how does s6 look like to you who have had a look at it?
2018-10-02 13:46:58 <mps> long time ago I made read only root system with runit (which is similar to s6 in some ideas) and I don't think that the s6 bad, but for common system I prefer sysvinit/openrc
2018-10-02 13:47:17 <mps> I mean, runit as init 1
2018-10-02 13:47:36 <mps> without any other init system
2018-10-02 13:47:44 <AinNero> like void linux does?
2018-10-02 13:48:03 <mps> AinNero: didn't looked at void linux yet
2018-10-02 13:49:05 <mps> IMHO, runit, s6 are for customized systems and not for general use
2018-10-02 13:50:24 <TBB> I've looked at skarnet's documentation for s6, barely scratched the surface only, and it seems ... slightly confusing at first
2018-10-02 13:50:47 <mps> I'm using runit in (most, practically all) my servers for some processes but the init 1 are sysvinit or openrc
2018-10-02 13:51:05 <TBB> but then, I've mostly been subjected to sysv and openrc (and inits of commercial Unices) in the last 20+ years
2018-10-02 13:51:15 <AinNero> like, these kind of people make extensive use of already existing I/O interfaces
2018-10-02 13:51:54 <AinNero> so runit and s6 are pretty simple like, when you look at them via strace
2018-10-02 13:52:52 <mps> well, I was one of the early adopters of systemd, even advocated it in Debian devel list, but when it became to bloated I ditched it
2018-10-02 13:53:49 <mps> AinNero: yes, small programs for chaining tasks, you know 'unix philosophy'
2018-10-02 13:53:51 <TBB> you just hit the nerve there, my question was partly triggered by that systemd related problem I may have mentioned on the main channel
2018-10-02 13:54:11 <TBB> well, perhaps "hit the nerve" is a bit too strong an expression
2018-10-02 13:56:33 <mps> TBB: uh, I had also 'hit the nerve' with systemd about year and a half ago, and then replaced my working machines with AL
2018-10-02 13:57:12 <TBB> it seems to do that to a lot of people
2018-10-02 13:57:32 <mps> some servers are still Debian but with sysvinit, till I prepare to move them to something else (Alpine probably)
2018-10-02 13:58:45 <AinNero> mps: 'unix philosophy' is dogmatic stuff to me
2018-10-02 13:58:55 <AinNero> i argue with composability as useful feature
2018-10-02 13:59:45 <mps> AinNero: also I'm not dogmatic (maybe sometimes) and because that I put term in quotes
2018-10-02 14:00:38 <AinNero> alright
2018-10-02 14:33:36 <mps> TBB: I forgot to mention that skarnet (s6 author) is sometimes on alpine channels so you could ask him about details
2018-10-03 10:03:17 <fcolista> Freeswitch 1.6.x is EoL. We need to upgrade to 1.8.x, but there are issues with libressl: https://dpaste.de/amYc
2018-10-03 10:05:33 <fcolista> looking at other distribution, seems that not many has moved as yet to 1.8 besides FreeBSD
2018-10-03 10:07:18 <fcolista> (distro with libressl)
2018-10-03 10:23:14 <fcolista> ncopa ^
2018-10-03 10:38:39 <ncopa> i think we will switch back to openssl soonish
2018-10-03 10:39:58 <ncopa> my plan is now: 1) update abuild, 2) fix gcc6, 3) update ffmpeg4, 4) switch to openssl
2018-10-03 10:40:13 <ncopa> might be i do the ffmpeg4 and openssl switch in same go
2018-10-03 10:42:19 <ncopa> would like to reduce the patch/pr queue a bit too before i do the openssl switch
2018-10-03 11:11:22 <brebs> fcolista: Presumably that is with a libressl version less than 2.7.4-r1, since the "/usr/include/openssl/ssl.h:1237:10: note: expected 'const SSL_METHOD *' {aka 'const struct ssl_method_st *'} but argument is of type 'int'" error looks wrong otherwise.
2018-10-03 11:24:05 <fcolista> ncopa, yeah, makes sense
2018-10-03 11:24:11 <fcolista> brebs, thx for the input
2018-10-03 12:21:43 <ncopa> I am going to reverse the options="!checkroot"
2018-10-03 12:22:09 <ncopa> meaning that make check will not run in fakeroot unless options="checkroot" is set
2018-10-03 12:22:38 <ncopa> i expect most tests run fine as non-root, and those who needs root permissions will likely fail in fakeroot too
2018-10-03 13:05:15 <ncopa> im pushing new abuild...
2018-10-03 13:18:30 <TBB> I feel dump for even asking... so when I've got an APKBUILD for a new package, I should make a github repo for it, commit the stuff to it and let someone know it's there?
2018-10-03 13:36:27 <clandmeter> TBB, you fork aports on github and create a feature branch. in that branch you put your new apkbuild.
2018-10-03 15:41:39 <andypost> ncopa, please commit https://github.com/alpinelinux/aports/pull/5173
2018-10-03 19:45:11 <TBB> clandmeter: too much trouble without proper documentation
2018-10-04 09:23:52 <_ikke_> Anyone able to check why the py*-pycryptodome subpackages haven't been rebuilt since the last update/
2018-10-04 09:35:04 <clandmeter> _ikke_, your apkbuild is broken
2018-10-04 09:35:14 <clandmeter> you cannot use :all in subpkg
2018-10-04 09:35:21 <_ikke_> ah, ok
2018-10-04 09:35:57 <clandmeter> we should probably add a check in abuild and error
2018-10-04 09:37:36 <clandmeter> _ikke_, you want me to fix it?
2018-10-04 09:38:12 <_ikke_> Do we need to disable the arch check then?
2018-10-04 09:38:28 <_ikke_> because the main package does not contain any arch specific files, while the subpackages do
2018-10-04 09:39:09 <clandmeter> abuild will just warn, its no problem.
2018-10-04 09:39:25 <_ikke_> ok
2018-10-04 09:39:44 <clandmeter> you have commit access?
2018-10-04 09:39:46 <_ikke_> No
2018-10-04 09:39:59 <clandmeter> i have to go soon, so if you want i can fix it now
2018-10-04 09:40:21 <_ikke_> Would be nice if you could do it
2018-10-04 09:42:23 <clandmeter> done. bye :)
2018-10-04 09:43:22 <_ikke_> thanks, bye
2018-10-05 12:02:42 <AinNero> ^ IMHO usr/share/udhcpc/default.script should be in the main busbox pkg together with udhcpc
2018-10-05 12:13:57 <ncopa> or maybe in its own package
2018-10-05 12:14:52 <ncopa> there are usecases where you want busybox but not the script(s)
2018-10-05 12:15:04 <ncopa> which is why it is in busybox-initscripts
2018-10-05 17:34:20 <vkrishn> do we have something like http://rasdaman.org/ in al, mongodb ?
2018-10-05 17:34:49 <_ikke_> https://pkgs.alpinelinux.org/packages
2018-10-05 17:35:14 <vkrishn> I mean in features
2018-10-05 18:46:43 <dandy> any chance someone has gotten wifi working on a pi 3b+?
2018-10-06 17:01:55 <AinNero> ncopa: your lddtree has some weird conceptions about the libs on my system...  http://0x0.st/sg8n.txt
2018-10-06 17:02:36 <AinNero> see the /mnt/debian references, which are in ld.so.cache, but not honoured by actual musl dynloader
2018-10-06 17:02:44 <AinNero> im investigating
2018-10-06 17:27:35 <AinNero> i think what i did with registering debian libraries does not work correctly at all
2018-10-06 17:38:18 <AinNero> hm, its that lddtree incorrectly reads ld.so.cache (which is glibc-specific) on a musl system
2018-10-06 17:41:38 <AinNero> * ld.so.conf
2018-10-08 09:28:27 <ncopa> morning
2018-10-08 09:32:03 <mps> 'apkbuild-cpan create Module::Name' fails with '404 Not Found at /usr/bin/apkbuild-cpan line 346.'
2018-10-08 09:32:20 <mps> is that fixed in edge abuild package
2018-10-08 09:36:41 <ncopa> dunno
2018-10-08 09:38:21 <mps> no, it is not fixed
2018-10-08 09:38:53 <mps> just tried apkbuild-cpan@edge ver. 3.3.0_pre1-r0
2018-10-08 09:39:44 <ncopa> i dont have time to look at it now
2018-10-08 09:39:49 <ncopa> patches are welcome ;)
2018-10-08 09:40:22 <mps> I will try to debug it and if I find bug/error will post it to bugs.a.o
2018-10-08 09:41:51 <ncopa> would be great! thanks!
2018-10-08 09:43:01 <AinNero> ncopa: did you read my complaints about lddtree?
2018-10-08 09:43:18 <AinNero> would it make sense to patch the glibc parts out via patch in aports?
2018-10-08 09:43:33 <ncopa> i saw something about it, but i havent had time to look at the details
2018-10-08 09:43:54 <AinNero> lddtree honours config files that musl ignores
2018-10-08 09:43:58 <ncopa> the lddtree is supposed to be multiplatform
2018-10-08 09:44:08 <AinNero> resulted in glibc libraries being put into the initramfs
2018-10-08 09:44:25 <AinNero> on a multi-libc system
2018-10-08 09:44:45 <ncopa> I guess they are not supposed to be there?
2018-10-08 09:45:18 <ncopa> i mean, if its multi-libc, maybe mkinits pulls in glibc binaries?
2018-10-08 09:45:47 <AinNero> but mkinitfs pulls in glibc libraries as dependencies of musl binaries
2018-10-08 09:45:58 <AinNero> which blows up at runtime
2018-10-08 09:46:02 <ncopa> i suppose thats wrong :)
2018-10-08 09:46:34 <AinNero> fix: lddtree shouldn't read /etc/ld.so.conf for musl binaries
2018-10-08 09:46:41 <AinNero> that config file is glibc specfici
2018-10-08 09:46:53 <ncopa> it would be nice if lddtree does its thing, and works on glibc system, musl libc system and multi-libc
2018-10-08 09:47:39 <ncopa> not sure how to detect if ld.so.conf should be read or not. maybe add a flag for it? --honor-ld-so-conf or similar?
2018-10-08 09:48:12 <AinNero> its dependent on the binary lddtree is being run on
2018-10-08 10:46:44 <ncopa> and dropping support for ld.so.conf breaks glibc?
2018-10-08 10:47:58 <AinNero> it breaks glibc for mkinitfs or everything else that uses lddtree
2018-10-08 12:10:16 <mps> ncopa: looks like apkbuild-cpan problem is in that the search.cpan.org is now redirected to metacpan.org which have different api
2018-10-08 12:11:06 <mps> If I understand it correctly it need a rewrite to new api, not a bug fix
2018-10-08 12:18:28 <ncopa> sounds correct
2018-10-08 12:23:08 <mps> found new url, for example 'https://fastapi.metacpan.org/v1/module/Crypt::OpenSSL::X509' returns big json with correct download url as 'download_url' and other fields
2018-10-08 12:25:21 <mps> so, question is, should I start to rewrite apkbuild-cpan or that is job for someone more skillful in abuild
2018-10-08 12:53:37 <andypost> ncopa, please backport it https://github.com/alpinelinux/aports/pull/5173
2018-10-08 13:07:03 <fabled__> mps, i wrote the orignial apkbuild-cpan; i would not mind if you can improve/fix it to work with the new api
2018-10-08 13:08:45 <mps> fabled__: however you want, I could try to update it if you don't have time, or for any other reason
2018-10-08 13:09:20 <mps> I have some experience with perl and wrote some api/json clients
2018-10-08 16:40:02 <Mo0O> hi there
2018-10-08 16:40:23 <Mo0O> do you know if `no include path in which to search for stdint.h` is fixable?
2018-10-08 16:42:49 <Mo0O> well, forget, I just did not install musl-dev on this machine
2018-10-08 16:42:50 <Mo0O> sorry
2018-10-08 17:59:20 <Lochnair> Mo0O: if you need to lookup more headers in the future, you can use pkgs.a.o like this
2018-10-08 17:59:20 <Lochnair> https://pkgs.alpinelinux.org/contents?file=stdint.h&path=%2Fusr%2Finclude*&name=&branch=edge&arch=x86_64
2018-10-08 18:00:41 <Mo0O> thanks Lochnair, that could really be useful
2018-10-08 18:01:21 <johnnyfive> Yo yo, i'm looking for any information (roadmap, tickets, anything) that indicates that Alpine is going to have a package management rewrite?
2018-10-08 18:07:51 <TBB> damn, I could've told you that the specific dev that's working on it is not here right now, but I'm sure someone else here knows about it
2018-10-08 18:13:11 <johnnyfive> TBB, it's good, i'm in no rush. I'll try again later/tomorrow/somet
2018-10-08 18:33:36 <Gottox> is there any process with rust on other architectures than x86?
2018-10-08 18:33:59 <Gottox> or any work? :)
2018-10-08 18:34:18 <Gottox> we managed to x-compile glibc, but currently x-musl is failing.
2018-10-08 18:37:27 <awilfox> we've managed to get it working on ppc64
2018-10-08 18:37:29 <awilfox> musl
2018-10-08 18:38:05 <awilfox> ppc32 is broken upstream; one of our contributors spent all freaking weekend trying to fight all the brokenness, and got to the point where stage1 builds, but stage2 still doesn't
2018-10-08 18:38:45 <awilfox> one of the crates pulls in an old version of rust-random which has the wrong syscall number for getrandom(2) on ... hmm, I think it was ppc32 sparc64 and ia64? ... so it fails
2018-10-08 18:39:13 <awilfox> arm64 has a syntax error in the target-specific code...
2018-10-08 18:49:27 <Gottox> funny.
2018-10-08 18:49:59 <Gottox> our cargo fails, I'm not exactly sure why:
2018-10-08 18:50:13 <Gottox> https://gist.github.com/Gottox/ab75b3796a9383423deecc0828494ac5#file-rust_aarch64-musl_do_build-log-L937
2018-10-09 02:25:11 <kaniini> i mean that has to violate something right
2018-10-09 08:54:32 <TBB> johnnyfive, now would be a good time
2018-10-09 10:39:53 <filoozom> Hey guys, I'm trying to update a package on the testing repo but always get an "untrusted signature" error message on "abuild index". What did I do wrong?
2018-10-09 11:23:33 <ncopa> kaniini: agree, initscripts should not invoke package manager
2018-10-09 17:17:59 <johnnyfive> TBB, I sleep around that time ;) who is i'm looking for?
2018-10-09 17:41:11 <TBB> someone who left about 4 hours ago :(
2018-10-09 17:41:56 <johnnyfive> haha, ok
2018-10-09 17:42:06 <johnnyfive> TBB, thanks. I'll keep looking :)
2018-10-11 10:23:09 <Gottox> read
2018-10-11 10:23:14 <Gottox> whoops
2018-10-11 14:38:29 <ncopa> the gnome thing in alpine is a huge mess now...
2018-10-11 14:50:29 <TBB> let me optimize that for you: gnome is a huge mess
2018-10-11 15:37:15 <ncopa> would be nice with some help to fix the build issues to unblock the builders again
2018-10-11 23:41:19 <andypost> ncopa, PRs 5372 & 5373 will fix 2 packages for builders
2018-10-12 20:57:27 <AinNero> Shiz: i understood the syslog -Z bug
2018-10-12 20:59:15 <AinNero> actually, #8028 explains it pretty well
2018-10-12 20:59:55 <AinNero> im proposing adding the workaround with .tm_year=100, so the calculations arent done with 1900, but 2000
2018-10-12 21:00:33 <AinNero> this improves the situation as 2000 is within 1970 +- 2^31 seconds, as opposed to 1900
2018-10-12 22:09:37 <Shiz> AinNero: i'm gonna properly check this this weekend, so sorry for the delay
2018-10-12 22:11:06 <AinNero> i would do it myself, im gonna need an PR for hacktoberfest anyways
2018-10-13 09:09:43 <HRio> /usr/share/dnssec-root/trusted-key.key seems to now work since the key rollover on October 11. We must update the dnssec-root package... managed to get unbound to resolv again after changing trusted-key.key to a more upto data version from Debian
2018-10-13 09:09:58 <HRio> s/data/date/
2018-10-13 09:14:22 <HRio> s/now/not/
2018-10-13 10:35:07 <HRio> https://www.redhat.com/en/blog/what-you-need-know-about-first-ever-dnssec-root-key-rollover-october-11-2018
2018-10-13 10:55:47 <Michcioperz> ah so that's why my home server started to fail dns
2018-10-13 13:28:09 <AinNero> nmeum: im dissatisfied with the current version of the patch...
2018-10-13 13:28:22 <nmeum> how come?
2018-10-13 13:28:35 <AinNero> i would prefer nowtm = time() and then running strptime on it
2018-10-13 13:29:26 <nmeum> you mean you would prefer entirely ignoring the date supplied in the message?
2018-10-13 13:30:05 <nmeum> if that's the case we might as well apply https://git.busybox.net/busybox/commit/sysklogd/syslogd.c?id=9d539f9fbd0dc4ea70ed8ba66e3c78150fa8a8b2
2018-10-13 13:30:35 <AinNero> strptime does't set the year
2018-10-13 13:30:41 <nmeum> but that's something we can only do in edge as the option has both: a different name and a different behviour
2018-10-13 13:30:42 <AinNero> so the year would be inherited from now()
2018-10-13 13:30:59 <nmeum> have you seen https://github.com/alpinelinux/aports/pull/5375#issuecomment-429538885 ?
2018-10-13 13:31:21 <nmeum> because that's fixed now
2018-10-13 13:31:33 <AinNero> i mean that patch right now
2018-10-13 13:31:48 <AinNero> because it creates an second nowtm, except its named tmp
2018-10-13 13:31:58 <AinNero> both carry the semantics of 'now'
2018-10-13 13:33:05 <nmeum> right, but it copies the date from the temporary tm struct. you would prefer to copy everything from now() and replace it later own with the information from strptime?
2018-10-13 13:33:13 <nmeum> *later on
2018-10-13 13:33:23 <nmeum> s/the date/the year/
2018-10-13 13:37:14 <AinNero> also your else branch did went missing somehow
2018-10-13 13:38:08 <nmeum> no, it's still there https://github.com/nmeum/aports-upstream/tree/busybox-syslogd-z-opt
2018-10-13 13:38:13 <AinNero> yeah, pre-initializing nowtm with time(NULL) and then running strptime() over it
2018-10-13 13:38:56 <AinNero> i mean now = 0; timestamp = msg;
2018-10-13 13:39:08 <AinNero> this was non-buggy code that the patch had previously
2018-10-13 13:39:12 <AinNero> is it not needed anymore?
2018-10-13 13:40:35 <nmeum> it is, it's still there https://github.com/nmeum/aports-upstream/blob/busybox-syslogd-z-opt/main/busybox/0011-sysklogd-add-Z-option-to-adjust-message-timezones.patch#L81-L82
2018-10-13 13:42:14 <nmeum> AinNero: is this what you had in mind? https://tpaste.us/ykV0
2018-10-13 13:42:25 <nmeum> (untested, obviously)
2018-10-13 13:44:11 <AinNero> hm, let me look at this fully first
2018-10-13 13:44:16 <AinNero> i think i missed something
2018-10-13 13:50:32 <AinNero> nmeum: the busybox patch is only adding an option to strip the timestamp alltogether
2018-10-13 13:50:38 <nmeum> I know
2018-10-13 13:50:56 <AinNero> which is another feature, so im not sure why it should be pulled in
2018-10-13 13:51:32 <nmeum> well…it strips the timestamp provided in the messages and creates a new one. from the description: „ignore the message timestamps and always locally timestamp”
2018-10-13 13:52:29 <nmeum> so it solves the same problem: fixing inconsistent time stamps but it entirely ignores the timestamp provided in the message. thus the behaviour is different
2018-10-13 13:52:32 <AinNero> ... when explicitly specified so, right?
2018-10-13 13:53:00 <nmeum> huh?
2018-10-13 13:53:03 <AinNero> not sure if ignoring the original time is the right thing to do
2018-10-13 13:53:17 <nmeum> well…that's the solution upstream has picked
2018-10-13 13:53:40 <nmeum> I am not saying we should apply that right away, but I would probably switch to that with the next major busybox upgrade
2018-10-13 13:53:53 <nmeum> but for now: we sholud fix this using 5375
2018-10-13 13:56:15 <AinNero> to me it looks like -t is allowing to strip the timestamp is explicitly specified so
2018-10-13 13:56:30 <AinNero> this does not help with the incorrect timestamps when its not enabled and timezone conversion is wanted..
2018-10-13 13:58:05 <AinNero> especially since -t is optional
2018-10-13 13:58:20 <AinNero> so it wouldn't change our situation with the default options
2018-10-13 13:59:17 <AinNero> https://bugs.alpinelinux.org/issues/8028 had an simple fix with .tm_year=100 that did not otherwise change the behavior of the program
2018-10-13 13:59:29 <nmeum> ok, there are two cases here: 1. the syslog producer doesn't specify a message → syslog generates a timestamp using time(3) and ctime(3) (resulting in a correct local timestamp) 2. the syslog producers supplies a timestamp → musl's syslog(3) uses UTC for this resulting in an uncorrect timestamp. There are two solutions for fixing 2.: (a) changing the timestamp from UTC to localtime (which is what
2018-10-13 13:59:35 <nmeum> -Z) does (b) stripping the timestamp, generating a new one using time(3) and ctime(3) which is what -t does
2018-10-13 14:01:11 <nmeum> the patch I pruposed for -Z doesn't (or at least shouldn't) change the behaviour of -Z either
2018-10-13 14:02:23 <AinNero> still, i dont know what you are doing with tmp, either
2018-10-13 14:02:33 <AinNero> and if ((tmp = timegm(&nowtm))) is like, always true
2018-10-13 14:02:56 <nmeum> I am using tmp to get the current year since it is not set by strptime
2018-10-13 14:03:26 <nmeum> > and if ((tmp = timegm(&nowtm))) is like, always true
2018-10-13 14:03:45 <nmeum> that's indeed an error that should be if ((tmp = timegm(&nowtm)) == (time_t)-1))
2018-10-13 14:05:07 <AinNero> afterwards its also used for assigning now
2018-10-13 14:06:17 <nmeum> yeah but before that it's assigned to the return value of timegm
2018-10-13 14:07:41 <AinNero> doesnt make sense to me..
2018-10-13 14:08:16 <nmeum> that's because I removed the branch for `now = 0` and set `now = 0` before performing the other checks
2018-10-13 14:08:36 <nmeum> and if the other checks fail now is not modified again
2018-10-13 14:21:46 <AinNero> 
ACTION is dissatisfied

2018-10-13 14:22:24 <AinNero> like, the year value is discarded anyways, the simple fix just moved the sample date the calculation is done on into the 2^32 range
2018-10-13 14:22:57 <AinNero> but now it has additional variables and calls to retrieve information that is discarded later anyways
2018-10-13 14:24:15 <AinNero> naming that variable `tmp` and using it twice for different things doesn't help with readabiliy..
2018-10-13 14:25:44 <nmeum> I am not saying the patch is perfect, we could hardcode the year as well. Shiz: What are your thoughts on this?
2018-10-13 14:30:17 <nmeum> AinNero: I would suggest that you express your concerns in the PR. Some other developer can then decide whether or not this should be merged or if a different solution should be implemented
2018-10-13 14:30:49 <nmeum> none the less, it would be nice to know if the patch fixes both 9279 and 8028 on your hardware
2018-10-13 14:32:26 <AinNero> i did not test the syslogd code, i picked out the data calculations and compiled and run that on 32-bit
2018-10-13 14:33:09 <nmeum> ah, ok
2018-10-13 14:33:26 <nmeum> nonetheless, it would be nice if you could add comment to the PR expressing your concerns
2018-10-13 14:34:28 <nmeum> I also just pushed a fix for the always-true condition, thanks for pointing that out
2018-10-13 14:41:42 <AinNero> 'my hardware', just netboot some 32-bit alpine from boot.alpinelinux.org
2018-10-13 14:42:40 <nmeum> I just used a x86 chroot
2018-10-13 15:01:06 <AinNero> anyways, im out
2018-10-13 15:20:19 <AinNero> nmeum: using timegm makes subtracting timezone unnecessary?
2018-10-13 19:23:36 <mps> anyone tried to build fritzing on Alpine
2018-10-13 19:25:24 <_ikke_> Never heard of it
2018-10-13 19:26:23 <mps> fritzing.org, simple electronic schematic tool for beginners
2018-10-13 19:27:20 <mps> I made APKBUILD and 'patched' it by hand a little but it gives me a lot of errors when tried 'make'
2018-10-13 19:28:12 <mps> it is qt5 based, but I have little experience in building qt programs
2018-10-13 19:30:10 <_ikke_> What kind of error are you getting?
2018-10-13 19:31:23 <mps> compiler errors, but deleted them last night
2018-10-13 19:32:09 <mps> I will try to adapt Arch linux pkgbuild, but before that wanted to ask here if somebody already tried
2018-10-13 19:33:50 <mps> actually, asked the same question on #alpine-linux but no one answered
2018-10-13 19:34:12 <mps> asked last night, I mean
2018-10-13 19:34:58 <_ikke_> was after 12am CEST, so probably not a lot of people online
2018-10-13 19:36:59 <mps> about 00:52
2018-10-13 19:37:13 <mps> CEST, of course
2018-10-13 19:38:30 <mps> never mind, I will try again if no one have a apkbuild for it
2018-10-13 20:55:07 <terra> Guys, how can I make ALpine aware of compressed kernel modules eg: *.ko.xz
2018-10-13 21:05:05 <AinNero> terra: where did you get them from?
2018-10-13 21:05:28 <AinNero> because if they are not from alpine, they are not gonna work with alpine
2018-10-13 21:06:13 <AinNero> this is an limitation from the kernel itself
2018-10-13 21:06:40 <terra> AinNero: I tend to try other distro kernels
2018-10-13 21:06:51 <terra> most of them come with compressed modules
2018-10-13 21:07:40 <terra> probably alpine kernel doesn't compiled with compressed modules support
2018-10-13 21:07:42 <AinNero> the util-linux pkg might contain a modprobe that is able to deal with compressed modules
2018-10-13 21:08:17 <terra> AinNero: It is not that simple I think because initrd will contain same compressed modules
2018-10-13 21:08:55 <AinNero> then you will need to patch some mkinitfs things
2018-10-13 21:09:20 <terra> It is interesting to see that some distro like Alpine which compiles all packages with "-Os" but doesn't support copressed kernel modules
2018-10-13 21:10:29 <AinNero> because alpine does have the modloop, which is better than individually compressing the modules
2018-10-13 21:12:14 <opal> any reason xf86 video drivers dont have debugging symbol packages? that's probably where they're most needed to debug desktop issues
2018-10-13 21:13:56 <terra> what does make modloop so important that discards such a wide spread and useful feature?
2018-10-13 21:17:02 <terra> opal: you're right. for instance I can't launch X with root user, thus can't use display managers on Alpine. Couldn't figure out why.
2018-10-13 21:17:14 <opal> that isnt my issue
2018-10-13 21:17:30 <terra> yes. most probably.
2018-10-13 21:17:42 <terra> I'm just making an example.
2018-10-13 21:19:23 <opal> shit is crashing on both nouveau and intel drivers
2018-10-13 21:19:31 <opal> might be your issue, but i'd say programs randomly crashing is a more severe issue
2018-10-13 21:19:31 <opal> ive been running discord and some other relatively heavy web pages in firefox for a while without an issue, and now that i restarted my pc, i can't bring it up again without everything crashing
2018-10-13 21:20:29 <opal> on that note firefox itself has a shitload of issues crashing too
2018-10-13 21:21:46 <terra> did you check "dmesg" output?
2018-10-13 21:22:51 <AinNero> terra: what does make musl so important that discards such a wide spread and useful glibc?
2018-10-13 21:23:25 <AinNero> terra: what does make apk so important that discards such a wide spread and useful thing like dpkg?
2018-10-13 21:23:42 <terra> interesting.. my firefox started crashing on some web pages since yesterday
2018-10-13 21:24:54 <AinNero> alpine isn't just some smaller version of centos
2018-10-13 21:25:02 <AinNero> alpine is smaller because it does some things differently
2018-10-13 21:25:10 <opal> terra: no im checking coredumps
2018-10-13 21:25:28 <opal> AinNero: are you trolling
2018-10-13 21:25:46 <AinNero> im fed up with that attitude
2018-10-13 21:25:54 <terra> AinNero: musl and apk comes as default. what about modloop thing? Is it a compuşsory feature that I can't discard?
2018-10-13 21:25:57 <opal> people who develop for glibc (un)intentionally do things wrong because glibc treats some undefined properties of posix as defined
2018-10-13 21:26:00 <AinNero> 'alpine should support XZY because its widespread and stuff'
2018-10-13 21:26:12 <opal> and so people depend on the defined properties of glibc rather than knowing that those shouldnt be depended on
2018-10-13 21:26:26 <opal> and as for dpkg and apt, that isnt even fucking useful
2018-10-13 21:26:32 <opal> just dont even start in that direction
2018-10-13 21:26:36 <opal> its a big pain in the ass
2018-10-13 21:26:39 <AinNero> opal: see my postings in context of replying to terra
2018-10-13 21:26:41 <opal> that's all it ever will be
2018-10-13 21:26:47 <terra> AinNero: your statement is irrevelant
2018-10-13 21:26:49 <AinNero> it was intentionally imitating his sentences
2018-10-13 21:26:54 <opal> i don't care what the context is
2018-10-13 21:27:07 <AinNero> then shut up, both of you
2018-10-13 21:27:13 <opal> whatever context those statements were in, the statements you made still come across as trolling or uninformed
2018-10-13 21:27:19 <opal> dont tell me to shut up
2018-10-13 21:27:29 <opal> quit spreading misinformation
2018-10-13 21:27:42 <terra> AinNero: Who the hell are you?
2018-10-13 21:28:10 <AinNero> i sometimes fix crap on alpine
2018-10-13 21:28:49 <terra> AinNero: Then start first on your disgusting behavior
2018-10-13 21:28:53 <AinNero> and honestly, im considering just ignoring people who come with "XZY supports Foo, so Alpine also needs Foo now"
2018-10-13 21:29:02 <opal> so do i, but i also use alpine as my main distro, i also understand how fundamentally broken a lot of gnu software is, i also understand how fundamentally broken a package manager such as apt is
2018-10-13 21:29:32 <opal> AinNero: if that was your argument, pick a better example
2018-10-13 21:29:49 <opal> comparing musl with glibc is almost comparing posix conformancy to non-conformant behaviour
2018-10-13 21:29:53 <AinNero> mkinitfs has no support for xz-compressed modules
2018-10-13 21:30:03 <opal> so, that has nothing to do with a personal preference of compressed modules
2018-10-13 21:30:20 <opal> musl is more correct than glibc, objectively speaking from a posix perspective
2018-10-13 21:30:38 <opal> so yeah, pick your examples more carefully
2018-10-13 21:30:39 <AinNero> but i can tell you, adding parts of util-linux to the initramfs probably wont make it into edge
2018-10-13 21:32:31 <AinNero> and seriously, your "is XYZ so important that ..." statement was less than helpful to your intent
2018-10-13 21:40:54 <AinNero> hm, i was wrong with util-linux, the package is kmod
2018-10-13 21:41:08 <AinNero> afaik the initramfs uses the busybox modprobe per default
2018-10-14 16:56:07 <AinNero> im having trouble with the upstream fetching for main/zip
2018-10-14 16:56:14 <AinNero> is there a way to rehost it on alpine-side ?
2018-10-14 17:20:38 <_ikke_> AinNero: We have some place to redistribute files, but you'd have to probably ask one of the core devs
2018-10-14 17:22:00 <AinNero> alright
2018-10-14 17:22:17 <AinNero> _ikke_: could you add ftp://ftp.info-zip.org/pub/infozip/src/zip30.zip to the redistribution place?
2018-10-14 17:22:48 <_ikke_> Not sure I have access
2018-10-14 17:23:01 <AinNero> otherwise i'll ping clandmeter
2018-10-14 17:23:03 <AinNero> oops, i just did
2018-10-15 10:43:31 <nmeum> ncopa: any plans on upgrading firefox-esr soonish? firefox-esr 52.X seems to be EOL, we should upgrade to firefox-esr 60.X soonish.
2018-10-15 11:32:38 <vkrishn> hi, does busybox's hdparm work?
2018-10-15 11:32:39 <vkrishn> localhost:~# hdparm -h
2018-10-15 11:32:40 <vkrishn> hdparm: unrecognized option: h
2018-10-15 11:37:18 <TBB> hdparm, without switches
2018-10-15 11:37:21 <vkrishn> in testing/ these could be moved to unmaintained/ -> "boost-coroutine, shntool, sphinxcontrib-ansi"
2018-10-15 11:37:58 <TBB> and my busybox hdparm does show help with -h
2018-10-15 11:38:25 <vkrishn> TBB: I tried hdparm from hdparm pkg for command "hdparm -y" and got different results
2018-10-15 11:39:03 <vkrishn> busyboxy gave errors
2018-10-15 11:42:24 <TBB> seems to give me "Invalid argument" on a media that has support for standby
2018-10-15 11:42:30 <TBB> the busybox one that is
2018-10-15 12:08:33 <ncopa> nmeum: it depends on rust...
2018-10-15 12:11:54 <vkrishn> ncopa: ^^ busybox/hdparm issue
2018-10-15 12:24:37 <ncopa> vkrishn: i havent tested, but I expect it to work. file a bug if it is broken
2018-10-15 12:26:56 <ncopa> i suppose we could just disable hdparm from busybox and let people who need it use the full version
2018-10-15 12:27:51 <ncopa> vkrishn: why do think we can move shntool and sphinxcontrib-ansi to unmaintained?
2018-10-15 12:31:00 <vkrishn> http://www.etree.org/shnutils/shntool/ not found, and pkg also not in distfiles
2018-10-15 12:31:09 <vkrishn> same for sphinxcontrib-ansi
2018-10-15 12:31:41 <vkrishn> +1 for disabling hdparm in busybox
2018-10-15 12:43:00 <ncopa> vkrishn: do you think you could send an email to the package maintainers for those packages?
2018-10-15 12:44:36 <vkrishn> it should be logically, but its practically beyond their fix, unless they keep a copy of the pkg
2018-10-15 12:44:59 <vkrishn> and have permission to upload it in distfiles
2018-10-15 12:45:55 <vkrishn> has any more thought gone into having repos of pkgs on al servers?
2018-10-15 12:49:19 <vkrishn> correction sphinxcontrib-ansi refers to 'testing/py-sphinxcontrib-ansi'
2018-10-15 12:50:26 <_ikke_> vkrishn: I don't think we have the capacity to mirror all upstream data
2018-10-15 12:50:51 <vkrishn> we start with main/
2018-10-15 12:51:36 <vkrishn> logically git repo should use less space
2018-10-15 12:53:02 <vkrishn> except java pkgs, where they have tendency to keep gzip/zip..tar and binary in git repo
2018-10-15 13:04:02 <vkrishn> there is also a possible positive outcome, for fixes/patches eg. grsec that requires purchase, but once patched are covered in GPL,
2018-10-15 13:04:05 <vkrishn> meaning someone can purchase, patch it, the let the source in its entirity available, which I think is still valid download
2018-10-15 13:04:54 <vkrishn> and beyond the purchase/subscription clause of seller
2018-10-15 13:05:16 <nmeum> ncopa: why is firefox-esr 60.X depending on rust a problem? rust is already in community and we have firefox >= 60.X in testing
2018-10-15 13:05:16 <_ikke_> vkrishn: I think the problem is that once you do that, grsec stops giving you new versions
2018-10-15 13:05:37 <vkrishn> giving who, if the source of purchaser is not known
2018-10-15 13:05:48 <ncopa> nmeum: i think we only have rust for x86_64
2018-10-15 13:06:04 <ncopa> which means firefox-esr disappears from the other arches
2018-10-15 13:06:07 <nmeum> oh, that's true indeed
2018-10-15 13:06:13 <vkrishn> one cannot stop patched kernel to get re-distributed, it in GPL
2018-10-15 13:06:43 <vkrishn> if i make binary or a patched kernel, I need to make available the source too
2018-10-15 13:06:47 <nmeum> but continueing to ship an EOL firefox-esr is also not really a long-term option. Besides, we also need rust on other arches for the libsvg upgrade, right? So it's probably work while to add support for other arches to rust
2018-10-15 13:06:50 <vkrishn> binary of*
2018-10-15 13:07:12 <nmeum> *worth while
2018-10-15 13:07:32 <vkrishn> I am aware it takes away the earning of the original other, but it is the way it is
2018-10-15 13:08:18 <vkrishn> the monetary value is on the patch, not on the final code
2018-10-15 13:10:43 <vkrishn> the problem is re-distributing the patch itself
2018-10-15 13:18:02 <vkrishn> on second thought, even if the purchaser is known, he/she is not distributing the patch, but 'binary+patched code'
2018-10-15 13:19:23 <vkrishn> if resell/provision of newer version is stopped, it may be a cause of an action
2018-10-15 13:21:17 <vkrishn> but then currently that is not the main reason I want repos in al
2018-10-15 13:28:29 <vkrishn> _ikke_: have you worked on 'capacity to mirror' part ?
2018-10-15 13:28:55 <_ikke_> nope
2018-10-15 13:41:54 <ncopa> nmeum: yes. we need to do something
2018-10-15 13:42:08 <ncopa> i think we just upgrade firefox-esr and remove the unsupported arches
2018-10-15 13:59:09 <nmeum> that would be an acceptable temporary solution until we add support for more arches to firefox
2018-10-15 13:59:24 <nmeum> s/to firefox/to rust/
2018-10-15 14:00:43 <nmeum> jirutka[m]: how difficult do you think it will be add support for other arches to rust?
2018-10-15 14:02:12 <_ikke_> afaik jirutka is not actively involved with alpine anymore
2018-10-15 14:19:42 <nmeum> he still commits stuff occasionally
2018-10-15 14:19:47 <nmeum> and he still maintains the rust apport
2018-10-15 14:19:48 <nmeum> *aport
2018-10-15 14:56:00 <ncopa> nmeum: maybe send an email to him with cc alpine-devel
2018-10-15 15:33:54 <ncopa> about security scanners that scan alpine images: https://kubedex.com/follow-up-container-scanning-comparison/
2018-10-15 15:34:11 <ncopa> clandmeter: ^^^
2018-10-15 15:34:31 <ncopa> that seems to be the reason why they DoS our alpine-secdb
2018-10-15 15:35:37 <_ikke_> Yeah, I figured as much
2018-10-15 15:44:04 <ncopa> hum... looks like openssl's shape is worse than i thought
2018-10-15 15:45:09 <Gottox> Didn't alpine switch to libressl?
2018-10-15 15:45:23 <_ikke_> Gottox: yes, but there were plans to switch back
2018-10-15 15:45:47 <_ikke_> iirc because libressl is diverging more and more from openssl
2018-10-15 15:45:54 <Gottox> okay, due to nodejs or are there other issues too?
2018-10-15 15:46:03 <ncopa> Gottox: we are looking at switching back
2018-10-15 15:46:09 <ncopa> there are a few other issues
2018-10-15 15:46:44 <ncopa> im not happy how they handled the time_t issue on 32bit
2018-10-15 15:46:58 <ncopa> they basically said "fix your kernel"
2018-10-15 15:47:02 <ncopa> which is technically correct
2018-10-15 15:47:11 <ncopa> but non-trivial to do
2018-10-15 15:47:24 <ncopa> well, wtihout breaking kernel ABI
2018-10-15 15:47:55 <ncopa> there are a few packages that we never made work at all with libressl
2018-10-15 15:47:59 <ncopa> asterisk, nodejs
2018-10-15 15:48:34 <ncopa> and i think there are a few that explicitly says that libressl is not supported (iirc openvpn, stunnel)
2018-10-15 15:49:08 <ncopa> Gottox: http://lists.alpinelinux.org/alpine-devel/6308.html
2018-10-15 15:53:33 <Gottox> yea nodejs blows up fairly regulary with libressl.
2018-10-15 15:54:12 <Gottox> whenever s/o tries to link a system library to nodejs, which we build with the shipped openssl.
2018-10-15 15:54:31 <Gottox> anyway, we finally got rust-cross working with xbps-src :D
2018-10-15 16:16:48 <nmeum> ncopa: sure, I will send jirutka[m] an email
2018-10-15 16:18:55 <nmeum> I also wanted to write a reply to that switch-back-to-openssl thread as I would personally like to stick with libressl
2018-10-15 18:32:26 <kaniini> nmeum i would rather not
2018-10-15 18:32:44 <kaniini> there are things that are openssl-only (in python, for example)
2018-10-15 18:33:19 <kaniini> and if you mix with libressl
2018-10-15 18:33:22 <kaniini> it blows up amazingly
2018-10-15 18:33:52 <kaniini> also, admittedly, i have biases because we have to ship openssl in adelie and would like to keep the ABI compatible
2018-10-15 19:18:44 <vkrishn> hi, anyone having problem in dumping their secret-chipped supermicro hardware, pls let me know,
2018-10-15 19:19:03 <vkrishn> atleast it can still build al ;-)
2018-10-15 19:42:49 <ncopa> seems like openssl requires ucontext for its async features, which IIRC is required for nodejs
2018-10-15 20:18:00 <kaniini> ncopa we got this with libucontext
2018-10-15 20:18:16 <kaniini> kaniini, implementing all the things dalias hates
2018-10-16 17:25:17 <johnnyfive> Yo yo, i'm searching for information on the apk rewrite. Anyone here have deets on that upcoming endeavor?
2018-10-16 17:25:58 <AinNero> there is an apk rewrite?
2018-10-16 17:51:09 <johnnyfive> That's what I was told? I'm not sure if that's just the package format, but i've been creating a new way to sign packages using only code (not bash), and someone pointed out that this might be diminishing returns due to the fact it all might change in month(s)
2018-10-16 17:51:12 <johnnyfive> AinNero, ^
2018-10-16 18:36:36 <kaniini> there is no rewrite of apk, but a proposed new binary format
2018-10-16 18:36:56 <kaniini> whether or not that format becomes the default remains to be seen
2018-10-16 18:37:10 <AinNero> kaniini: is there documentation on that?
2018-10-16 18:38:19 <kaniini> not really yet, but the general concept is to replace tar streams with CDB-like structures that are more simple to parse
2018-10-16 18:39:11 <AinNero> in regards of the apkindex?
2018-10-16 18:39:18 <kaniini> johnnyfive you may be referring to the new build system being done in adelie which may eventually be used in alpine too, that is a rewrite of some abuild components in memory-safe languages
2018-10-16 18:39:52 <kaniini> AinNero the index is just a type of entity stored in an apk binary file
2018-10-16 18:39:59 <kaniini> but
2018-10-16 18:40:02 <kaniini> yes, sure
2018-10-16 18:40:27 <kaniini> at any rate, i wouldn't worry too much about it
2018-10-16 18:40:32 <johnnyfive> kaniini, I may be totally wrong on all accounts, if so that makes it easier on me, since I won't have to create a new workflow in the future.
2018-10-16 18:40:46 <kaniini> a new binary format is not likely to effect workflow
2018-10-16 18:41:33 <_ikke_> https://lists.alpinelinux.org/alpine-devel/6291.html
2018-10-16 18:41:45 <johnnyfive> understood. I'll have to look up adelie, as that might be relevant to what i'm doing
2018-10-16 18:42:43 <kaniini> https://code.foxkit.us/sroracle/py3-abuild/tree/master/
2018-10-16 18:43:09 <johnnyfive> Awesome, thanks!
2018-10-16 18:44:26 <johnnyfive> So this is a drop-in replacement for abuild. Is there another system on top of this alpine uses to build+sign+deploy packages as they get released?
2018-10-16 18:45:15 <johnnyfive> Furthermore, i'm writing a signing "service" in Go that replaces abuild-sign. Would that be beneficial to this community at all?
2018-10-16 18:45:25 <kaniini> alpine has some build scripts, but they arent so great
2018-10-16 18:45:52 <kaniini> adelie uses a fork of those build scripts, but we are making abuildd to use either abuild or pbuild
2018-10-16 18:45:54 <kaniini> in a safe, reproduceable way
2018-10-16 18:46:04 <_ikke_> johnnyfive: It would be beneficial I guess if it allows alpine to have remote signing servers
2018-10-16 18:46:21 <kaniini> abuildd already has a signing service
2018-10-16 18:47:31 <johnnyfive> Roger that, thank you all for the info.
2018-10-16 18:47:33 <kaniini> but, pbuild has adelie extensions, for example, you can do away with APKBUILD and use RPM spec files or python "recipes"
2018-10-16 18:48:36 <kaniini> pbuild also has an extensive testsuite, abuild does not ;)
2018-10-16 18:48:46 <_ikke_> nod
2018-10-16 18:50:21 <kaniini> anyway, it is my intention to introduce pbuild as an abuild alternative in alpine 3.9, we have been having good success with it on adelie side
2018-10-16 18:50:35 <kaniini> it can do a lot of things that abuild can't, especially with QA checks
2018-10-16 18:50:45 <kaniini> the downside is that it requires python
2018-10-16 18:51:47 <_ikke_> kaniini: readme says it's still WIP, what is missing?
2018-10-16 18:52:08 <kaniini> rootbld
2018-10-16 18:52:21 <kaniini> not frequently used commandline options
2018-10-16 18:52:34 <johnnyfive> To confirm, you're saying Adelie, as in Adelie linux (http://www.adelielinux.org/about.html) or something else?
2018-10-16 18:52:36 <kaniini> docs, API stabilization
2018-10-16 18:52:36 <_ikke_> can you remind me again what rootbld does exactly?
2018-10-16 18:52:51 <kaniini> rootbld builds a package from scratch in a new environment
2018-10-16 18:53:12 <_ikke_> ok, so it sets up a chroot I guess?
2018-10-16 18:53:17 <kaniini> right
2018-10-16 18:55:23 <kaniini> also, pbuild generates slightly different apks
2018-10-16 18:55:35 <kaniini> for example, the specfile or APKBUILD used to generate the package is embedded
2018-10-16 18:56:32 <johnnyfive> nvm i'm assuming yes due to adelie being hosted on foxkit as well.
2018-10-16 18:57:02 <_ikke_> johnnyfive: it is
2018-10-16 18:57:30 <kaniini> also, python3 needs some changes in order to run pbuild on alpine
2018-10-16 18:57:52 <kaniini> (it needs to be aware of xattr syscalls)
2018-10-16 18:59:20 <kaniini> but, overall, it is a good tool for developers once it enters alpine i think devs should use it
2018-10-16 18:59:52 <kaniini> among other things, it has a proper dependency solver
2018-10-16 19:00:27 <_ikke_> kaniini: when you need to build multiple packages?
2018-10-16 19:00:32 <_ikke_> which depend on eachother?
2018-10-16 19:00:34 <kaniini> yes
2018-10-16 19:00:38 <kaniini> it can solve that
2018-10-16 19:00:38 <_ikke_> ok, cool
2018-10-16 19:39:38 <afazio> looks like the acct, linux-vanilla (not sure why needed, but hey), and xen-hypervisor packages are not provided in the alpine-xen iso installer.  If the installer does not have internet access it will fail when attempting to install these (during setup-disk) and blow up the install.
2018-10-16 19:46:49 <afazio> looks like the acct, linux-vanilla (not sure why needed, but hey), and xen-hypervisor packages are not provided in the alpine-xen iso installer.  If the installer does not have internet access it will fail when attempting to install these (during setup-disk) and blow up the install.
2018-10-16 19:50:22 <kaniini> alpine-xen is not an installer
2018-10-16 19:50:28 <kaniini> it is for running xen hypervisor live
2018-10-16 19:51:00 <afazio> The iso installer for the alpine-xen flavor does not contain the offline packages to complete an offline install.
2018-10-16 19:51:30 <afazio> Namely the acct, linux-vanilla, and xen-hypervisor packages
2018-10-16 19:51:55 <afazio> https://git.alpinelinux.org/cgit/alpine-iso/tree/alpine-xen.packages
2018-10-16 19:53:24 <afazio> If an internet connection is present then /sbin/setup-disk can complete the install.  Otherwise it fails in the setup_root() method trying to install packages that aren't available and the install is left in a bad state.
2018-10-16 19:57:30 <kaniini> yes
2018-10-16 19:57:37 <kaniini> as i said a moment ago
2018-10-16 19:57:52 <kaniini> it is not an installer
2018-10-16 20:01:27 <afazio> Excuse me.  /sbin/setup-alpine is an installer.  And it comes shipped in several ISOs for different flavors of Alpine.  The Xen flavor is not installable offline because of missing three packages locally.  I'm talking about a bug, you are talking symantics.  Anyways, anyone else have any ideas?  New to Alpine and am happy to submit PRs to fix this.
2018-10-16 20:02:59 <duncan^> It also is to be found in Alpine systems that have been persistently installed onto a storage medium, so it's not necessarily accurate to suggest any image with that script is an installer image
2018-10-16 20:04:53 <afazio> Well since I have said ISOs, you know, the ones generated by the alpine-iso git repo, I assumed we all knew I was talking about ISOs and not a storage medium on an already installed system.
2018-10-16 20:10:50 <afazio> Sooooo, yeah.  The only input is a complete distortion of symantics for the sake of being dicks.  Great.  Looks like I stumbled across the internet's finest community.  I take it PRs will be blocked as well on the grounds that it's not an installer and thus does not need to complete it's job of installing Alpine.
2018-10-16 20:28:26 <afazio> How about this... I'll completely re-word it all to make the dicks happy.  When running the xen flavor ISO, the user is greeted with a MOTD that includes: "You can setup the system by running: setup-alpine".  So when a user goes to "setup" the system per the instructions, the "setup" completes fine with an internet connection, and does not complete and instead leaves the system in an unstable state.  The very quick fix to this is
2018-10-16 20:28:26 <afazio> added the necessary packages.  There.  I never said the word "install" once.  And if you don't want people ever "setting up" Alpine with the setup-alpine command, then take the freaking message out of the MOTD.  Either way, bugs.
2018-10-16 20:29:15 <afazio> Bugs which I'm happy to fix by submitting PRs like a good little newb.
2018-10-16 23:26:20 <Shiz> oof
2018-10-16 23:26:33 <Shiz> what happened here
2018-10-16 23:28:31 <duncan^> That did appear to take quite the turn for the worse.
2018-10-16 23:53:11 <mikedlr> hi; I'm trying to build two packages from one source tarball;  the build of the second package really depends on the first one (a library) being installed - is there a sensible way to do that?  Should I make two separate APKBUILD files?
2018-10-17 00:44:31 <Shiz> i agree that the nitpicking didn't quite help
2018-10-17 00:44:39 <Shiz> mikedlr: seems like it's logical to split them up
2018-10-17 00:44:44 <Shiz> are they logically separate pieces of software?
2018-10-17 00:46:28 <mikedlr> Shiz: sort of;  it's a c library and a python library that depends on  it.  I think I found another / better solution for now - make them both in one build so the dependencies are handled by the build process.
2018-10-17 00:46:41 <Shiz> well rather
2018-10-17 00:46:50 <Shiz> can the C library be feasibly used apart from the python library
2018-10-17 00:46:55 <Shiz> by some piece of software :)
2018-10-17 00:47:18 <Shiz> or well, I guess it matters not if it's two packages anyway
2018-10-17 00:47:32 <mikedlr> definitely;  it's currently packaged entirely without - it's gpgme - the python bindings are need the c though.
2018-10-17 05:51:51 <Adran> btw https://alpinelinux.org/about/ might need to be updated since theres no more hardened kernel by default
2018-10-17 07:53:47 <xsteadfastx> i just created a PR for the libssh security update https://github.com/alpinelinux/aports/pull/5386
2018-10-17 08:05:27 <AinNero> xsteadfastx: hah, just doing the same thing @work
2018-10-17 08:07:53 <xsteadfastx> :)
2018-10-17 08:21:41 <xsteadfastx> i hope it gets merged soon
2018-10-17 08:21:59 <xsteadfastx> but i wonder how this lands in the older versions of alpine. i mean its a rather large security risk
2018-10-17 08:27:10 <AinNero> add a comment requesting it to be backported, but i guess the person merging it will do it on their own
2018-10-17 08:35:04 <AinNero> xsteadfastx: is there some program that is using libssh? it seems like its rarely used as dependency
2018-10-17 08:35:39 <xsteadfastx> sure, but if... its a huge risk
2018-10-17 08:35:58 <AinNero> no, i mean, i just built it, but im not sure how i can confirm its working
2018-10-17 08:54:20 <TBB> unsurprisingly I just recently worked on porting something that uses libssh
2018-10-17 09:42:20 <TBB> libssh 0.7.6 at least goes through abuild -r just fine ... this would also be a good time to enable the tests
2018-10-17 09:43:07 <TBB> of course it could be considered to go to 0.8.4 straight away
2018-10-17 10:08:19 <TBB> ... for some reason my alpine dev box doesn't seem to be able to fetch source code from libssh.org, fun
2018-10-17 10:11:22 <mikedlr> hi;  just created a PR for gpgme - should I also create a feature request for it?  https://github.com/alpinelinux/aports/pull/5387
2018-10-17 10:14:30 <ncopa> mikedlr: hi! no need to create a feature request if you have a PR
2018-10-17 10:44:23 <AinNero> could someone run a quick test for me? compare `grep ZLIB_ /usr/lib/libpng*` with `apk policy zlib`, does anyone else see this discrepancy?
2018-10-17 10:45:25 <AinNero> libpng is somehow linking to 1.2.9
2018-10-17 10:48:33 <AinNero> previous problem is that libpng references inflateValidate@ZLIB_1.2.9, which is not found by the linker
2018-10-17 11:03:53 <ncopa> $ grep ZLIB_ /usr/lib/libpng* | tpaste
2018-10-17 11:03:53 <ncopa> http://tpaste.us/jXae
2018-10-17 11:05:47 <AinNero> hm. still investigating
2018-10-17 11:10:57 <AinNero> ah, i got it
2018-10-17 11:11:12 <AinNero> i have two fixes that each warrant a revbump
2018-10-17 11:11:24 <AinNero> should i do it in separate commits with two revbumps or merge it into one?
2018-10-17 11:11:52 <AinNero> the fixes are not directly related to each other, i just fond the second while fixing the first
2018-10-17 11:12:07 <ncopa> depends a bit how big the fixes are. I'd say merge them
2018-10-17 11:18:48 <AinNero> shit, the machine i worked on just ran out of power... i'll submit it later this day
2018-10-17 11:18:50 <xsteadfastx> TBB: the location of the archives changed
2018-10-17 11:19:10 <xsteadfastx> i can try to build a apkbuild file for 0.8.4
2018-10-17 11:19:37 <TBB> I did change the APKBUILD to point to the new repos, naturally
2018-10-17 11:20:03 <TBB> 0.8.4 doesn't compile
2018-10-17 11:20:37 <xsteadfastx> oh ok
2018-10-17 11:20:44 <TBB> "assuming signed overflow does not occur when simplifying conditional to constant", it says in two locations in connect.c
2018-10-17 16:09:51 <PureTryOut[m]> why are all qt5 binaries installed by qt5-qtbase linked to /usr/bin/*-qt5 rather than without -qt5 (e.g. `/usr/bin/qdbus-qt5` rather than `/usr/bin/qdbus`)? https://git.alpinelinux.org/cgit/aports/tree/community/qt5-qtbase/APKBUILD#n129
2018-10-18 11:30:42 <pksadiq> Hi. Is there any bug report that tracks python3 support? ie, moving packages to use python3 instead of python2 if possible? or is that yet not considered as a milestone?
2018-10-18 11:31:47 <_ikke_> I don't think there is an encompassing project to track that, it's just done on a package-by-package case. Many packages support both py2 and py3
2018-10-18 11:34:16 <pksadiq> hm.. Given that py2 EOLs ~2 years ahead, I assumed there would be a tracking bug.
2018-10-18 15:17:24 <AinNero> i found /lib/dasd-functions.sh on my system, but i cant find any references to it
2018-10-18 15:17:40 <AinNero> multiple systems have it
2018-10-18 15:17:54 <AinNero> since they are x86, im surprised to see it there. does it ring a bell for someone?
2018-10-18 15:18:15 <ncopa> AinNero: i think its fo s390x only
2018-10-18 15:18:30 <AinNero> im sure it is
2018-10-18 15:18:46 <ncopa> it is probably setup-disk that uses it
2018-10-18 15:19:36 <AinNero> ah, its in alpine-conf, thanks
2018-10-18 15:20:29 <AinNero> pkg search on it yields no results: https://pkgs.alpinelinux.org/contents?file=&path=lib%2Fdasd-functions.sh&name=&branch=edge
2018-10-18 15:20:34 <AinNero> i think the search might be broken
2018-10-18 15:32:06 <_ikke_> AinNero: the path only takes directories
2018-10-18 15:32:10 <_ikke_> not the filename
2018-10-18 15:32:26 <AinNero> ooh.
2018-10-18 15:33:03 <_ikke_> https://pkgs.alpinelinux.org/contents?file=dasd-functions.sh&path=%2Flib&name=&branch=edge
2018-10-18 18:05:22 <kaniini> is it just me or is kernel 4.14.76 really unstable
2018-10-19 10:17:34 <nmeum> clandmeter: any idea why testing/systemc doesn't appear on nl.alpinelinux.org for x86_64, build seems to have passed http://dev.alpinelinux.org/buildlogs/build-edge-x86_64/testing/systemc/systemc-2.3.2-r0.log ?
2018-10-19 10:21:49 <clandmeter> nmeum, checking
2018-10-19 10:23:32 <nmeum> thanks
2018-10-19 10:25:06 <clandmeter> nmeum, looks like testing didnt get updated since qtorrent
2018-10-19 10:25:47 <clandmeter> i think its stuck because of gnome-shell
2018-10-19 10:25:58 <clandmeter> it will only upload when its unstuck
2018-10-19 10:28:09 <ncopa> im working on that
2018-10-19 10:30:40 <clandmeter> looks like gnome is broken
2018-10-19 10:31:20 <nmeum> ah
2018-10-19 10:31:28 <nmeum> that makes sense, thanks for looking into it
2018-10-19 10:31:57 <TBB> 
ACTION bites his tongue for the second time within 14 minutes.

2018-10-19 10:35:43 <_ikke_> TBB: perhaps you should have that checked out :P
2018-10-19 10:36:22 <ncopa> the problem is that gjs for soem reason did not pick up pc:mozjs-38 dependency
2018-10-19 10:36:44 <ncopa> but i think i'll uprade it to mozjs60 and gjs 1.54 while at it
2018-10-19 10:37:06 <ncopa> linux-tools needs some fixing too on arm
2018-10-19 10:37:12 <ncopa> or we can disablee arm for now
2018-10-19 10:37:16 <ncopa> to unblock the builders
2018-10-19 10:58:48 <nmeum> ncopa: if you have a chance please take a look at https://github.com/alpinelinux/aports/pull/5400 currently all dns resolvers with DNSSEC which use the trust anchor shipped by this package are broken
2018-10-19 11:04:53 <ncopa> nmeum: i will not have time unfortunately. it would be great if you could have a look at it
2018-10-19 11:05:09 <ncopa> if you think its ok, then i'm ok that you merge it
2018-10-19 11:05:56 <nmeum> on first glance I am ok with the changes (seem to copied from arch tbh) but I wouldn't backport this as is to the stable branches
2018-10-19 11:06:20 <ncopa> we can backport it next week
2018-10-19 11:07:42 <nmeum> ok, I will take a closer look then. Possibly merge it into master, thereby fixing this on edge. If nothing breaks within the next few days we can backport it
2018-10-19 11:07:50 <ncopa> kaniini: i suspect that recent pkgconf update broke abuild
2018-10-19 11:08:04 <ncopa> seems that it fails to autodetect pc:* depends now
2018-10-19 11:08:17 <ncopa> nmeum: +1
2018-10-19 11:10:04 <ncopa> kaniini: gjs-dev package should have had a depend=pc:mozjs-38, but its missing
2018-10-19 11:15:30 <ncopa> ncopa-edge-x86_64:~/aports/testing/gjs$ PKG_CONFIG_PATH="$PWD"/pkg/gjs-dev/usr/lib/pkgconfig pkg-config --print-requires --print-requires-private gjs-1.0; echo $?
2018-10-19 11:15:30 <ncopa> gobject-2.0 >= 2.54.0
2018-10-19 11:15:30 <ncopa> 1
2018-10-19 11:15:38 <ncopa> pkg-config returns error
2018-10-19 11:15:49 <ncopa> and onlyl prints gobject-2.0
2018-10-19 11:15:55 <ncopa> thats why it breaks
2018-10-19 11:17:40 <ncopa> Requires.private:  gobject-introspection-1.0 libffi gthread-2.0 gio-2.0 >= 2.54.0 mozjs-60 cairo cairo-gobject gthread-2.0 gio-2.0 >= 2.54.0 mozjs-60 cairo-xlib gtk+-3.0 >= 3.20
2018-10-19 11:19:47 <ncopa> the gjs-1.0.pc is wrong i think
2018-10-19 11:20:25 <ncopa> ncopa-edge-x86_64:~/aports/testing/gjs$ PKG_CONFIG_PATH="$PWD"/pkg/gjs-dev/usr/lib/pkgconfig pkg-config --debug --print-requires --print-requires-private gjs-1.0 2>&1 | sprunge
2018-10-19 11:20:25 <ncopa> http://sprunge.us/BdLodw
2018-10-19 11:20:35 <ncopa> it complains about a missing gtk+3.0
2018-10-19 11:24:19 <ncopa> turns out problem was in gjs
2018-10-19 11:24:44 <ncopa> gjs was built without gtk, but the gjs-1.0.pc still included the gtk+3 depends
2018-10-19 11:24:50 <ncopa> which made pkgconf error
2018-10-19 11:24:54 <ncopa> because it was missing
2018-10-19 11:30:05 <nmeum> ncopa: while reviewing the dnsec-root PR I noticed that the iana published a tool for fetching and verifying the trust anchors https://github.com/iana-org/get-trust-anchor I will just use that instead unless you have objections
2018-10-19 11:30:24 <nmeum> diff looks as follows http://tpaste.us/O1ow
2018-10-19 11:30:26 <nmeum> currently testing it
2018-10-19 12:09:25 <nmeum> made a few minor changes and pushed the dnssec-root fix. let me know if anything breaks
2018-10-19 12:10:45 <mepholic> huh cool
2018-10-19 12:10:56 <mepholic> I ran into this issue the other day
2018-10-19 12:11:07 <mepholic> unbound started getting dnssec validation issues
2018-10-19 12:11:19 <mepholic> ad to fetch the new trust anchors myself
2018-10-19 12:20:01 <ncopa> I didn’t reach to unblock the builders. I think anything that fails can be disabled
2018-10-19 12:20:21 <ncopa> so disable gnome-shell
2018-10-19 15:25:29 <kaniini> ncopa yeah, makes sense that it's not pkgconf, the 1.5.4 didn't change anything functionally on linux anyway
2018-10-19 16:53:55 <mikedlr> ncopa: I think that the requests in gpgme have now been addressed, however the travis build is marked as failed - cancelled?  It shows that and a failure that doesn't seem related.
2018-10-19 16:54:21 <mikedlr> can you see if everything has been resolved please otherwise comment if there's something else.
2018-10-20 16:30:04 <nmeum> community/re2 and community/libre2 package the same software (I wonder how that keeps on happening). Which one do we want to remove?
2018-10-20 16:30:17 <nmeum> I would vouch for reoving community/re2 and renaming libre2 to re2
2018-10-20 18:02:52 <andypost> nmeum, looks great idea
2018-10-20 18:03:46 <andypost> interesting is that both packages maintained by @fcolista
2018-10-20 21:32:49 <andypost> any idea why aarch64 & travis can't make external requests?
2018-10-20 21:33:21 <andypost> and options=net does not help https://github.com/alpinelinux/aports/pull/5439/files
2018-10-20 22:07:53 <andypost> hm, now it passed
2018-10-21 00:50:02 <Thalheim> there are inconsistencies with packages like 'nginx' and 'nginx-mod-http-lua' where, apparently in between updates, files like '/var/lib/nginx/modules/ngx_http_lua_module.so' are moved to '/usr/lib/nginx/...', yet the nginx config (nginx binary?) isn't informed of this, so it fails to start?
2018-10-21 00:50:40 <Thalheim> this is not the first time something like this has happened, and it's exceedingly frustrating. are these changes published anywhere?
2018-10-21 03:18:32 <Shiz> hmm
2018-10-21 03:20:43 <Shiz> Thalheim: very odd since nginx-mod-http-lua is built together with nginx itself
2018-10-21 03:21:13 <Shiz> moreover, i don't think this has changed recently..
2018-10-21 03:24:01 <Thalheim> Shiz: I restarted nginx for the first time in several weeks (6-8?) after rebooting, and nginx complained about not being able to find the module. searching for the file itself revealed it was s/var/usr
2018-10-21 03:24:29 <Shiz> yeah it's strange because
2018-10-21 03:24:40 <Shiz> the location is set in the same apkbuild that builds  oth the modues and nginx itself
2018-10-21 03:25:12 <Shiz> is it possible tht you pdated one but not the other?
2018-10-21 03:25:19 <Shiz> just trying to eliminate some common issues
2018-10-21 03:25:29 <Thalheim> only if "apk update && apk upgrade" did not work correctly
2018-10-21 03:25:40 <pksadiq> Hi. I wish to contribute to alpine. I see that I can do A PR at github/send a patch to mailing list. Which is more preferred by reviewers?
2018-10-21 03:29:01 <Shiz> pksadiq: whatever works for you works for us, but github is generally easier to check
2018-10-21 03:29:02 <Shiz> :p
2018-10-21 03:29:56 <pksadiq> Shiz: well. I see a pile of yet to be reviewed PRs in github. that's why I asked. :)
2018-10-21 03:30:19 <Shiz> yes there's quite a backlog sadly
2018-10-21 03:31:21 <pksadiq> hm.. Let me begin with some small things and see how well it goes.
2018-10-21 10:13:35 <Myhro> How can I find out why the latest version of a package isn't in the mirrors? I'm trying to install wireguard-vanilla-4.14.76-r1 but this version is different than the latest kernel, which is linux-vanilla-4.14.77-r0
2018-10-21 10:14:25 <Myhro> And by this commit looks like wireguard-vanilla was properly bumped rebuilt two days ago: https://github.com/alpinelinux/aports/commit/40ab239
2018-10-21 10:15:58 <Myhro> I also tried another mirror other than dl-cdn.a.o but it didn't helped
2018-10-21 10:16:02 <AinNero> i can confirm the version discrepancy
2018-10-21 10:18:12 <Myhro> Great. How can we debug it further? Are the builder logs public?
2018-10-21 10:20:03 <brebs> Myhro: can see build log at https://pkgs.alpinelinux.org/package/edge/testing/x86_64/wireguard-vanilla
2018-10-21 10:21:11 <brebs> ... usually, when it's not a 404 Not Found :(
2018-10-21 10:21:28 <Myhro> Yeah, maybe it was cleaned up.
2018-10-21 10:21:49 <Myhro> Is the "Flag" button for situations like that?
2018-10-21 10:24:11 <_ikke_> Myhro: no, that's more to notify the maintainer that the package is out of date (eg, a newer version is upstream)
2018-10-21 10:27:45 <Myhro> _ikke_: I see. So what can I do then? Is it common for versions in Git to differ from what goes to the mirrors in edge/testing?
2018-10-21 10:28:45 <_ikke_> Usually that happens when something is going wrong with building the packages
2018-10-21 10:30:39 <Myhro> That was my suspicion as well. Is there another place where can I find the build logs other than pkgs.a.o ?
2018-10-21 10:31:16 <_ikke_> no, pkgs links to the place where they are stored
2018-10-21 10:33:17 <andypost> Myhro, that's because testing builders are broken and the package was not rebuild yet
2018-10-21 10:33:19 <_ikke_> I've checked on the build server
2018-10-21 10:33:30 <_ikke_> apparently it is build succesfully
2018-10-21 10:33:38 <_ikke_> but probably not uploaded yet
2018-10-21 10:33:56 <Myhro> Just found the most recent one at http://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/wireguard-vanilla/wireguard-vanilla-4.14.77-r1.log - but there's no timestamps.
2018-10-21 10:33:59 <_ikke_> wireguard-vanilla-4.14.77-r1.log exists and it says the build was successful
2018-10-21 10:34:14 <_ikke_> The file is from 2 days ago
2018-10-21 10:34:30 <Myhro> 2018-Oct-19 08:47:36 - got it.
2018-10-21 10:34:33 <_ikke_> > Oct 19 08:47 wireguard-vanilla-4.14.77-r1.log
2018-10-21 10:35:05 <Myhro> andypost: is the breakage related to uploads?
2018-10-21 10:35:35 <_ikke_> Myhro: If another package is broken, the packages aren't uploaded
2018-10-21 10:35:45 <andypost> Myhro, yes, gnome-shell blocks uploads
2018-10-21 10:35:59 <_ikke_> see https://build.alpinelinux.org
2018-10-21 10:36:07 <_ikke_> http://build.alpinelinux.org/
2018-10-21 10:36:27 <_ikke_> ncopa was working on getting it unstuck
2018-10-21 10:36:34 <Myhro> Now I understood.
2018-10-21 10:38:08 <Myhro> Thanks.
2018-10-21 12:04:32 <Mo0O> Hi there, I'm working on packaging https://github.com/s3fs-fuse/s3fs-fuse in order to make check function working I need to load fuse kernel module, is it correct to run `modprobe fuse` in check function?
2018-10-21 12:07:04 <AinNero> yes
2018-10-21 12:07:57 <AinNero> oh, in check.. mh..
2018-10-21 12:08:10 <AinNero> community/lxcfs does it in start_pre
2018-10-21 12:09:34 <AinNero> seems to be used inconsistently
2018-10-21 12:09:40 <AinNero> IMHO it belongs into start_pre
2018-10-21 15:55:08 <Mo0O> AinNero: thanks, but that's for initd file which manage lxcfs daemon, what I need is to have fuse module available during abuild check phase
2018-10-21 15:55:39 <Mo0O> in order to `make check` pass it require `fuse` kernel module
2018-10-21 15:56:17 <AinNero> mh..
2018-10-21 16:04:30 <mps> 'sudo modprobe fuse' in check, maybe
2018-10-21 16:07:34 <mps> Mo0O: ah, sorry, I see that you already mentioned modprobe
2018-10-21 16:08:40 <Mo0O> no problem, my question was more about knowing if it's clean and safe to do it, I never see that in other APKBUILD
2018-10-21 16:08:54 <andypost> ncopa this could fix armhf build https://github.com/alpinelinux/aports/pull/5455
2018-10-21 16:10:24 <_ikke_> Mo0O: Not sure if you can do modprobe on the builders
2018-10-21 16:11:18 <Mo0O> neither do I, that's why I'm asking, maybe better just test localy and add a comment in APKBUILD
2018-10-21 16:11:24 <Mo0O> let me know you through
2018-10-21 16:14:36 <Mo0O> s/you/your/
2018-10-21 17:37:38 <Shiz> definiely don't modprobe on the builders
2018-10-21 17:37:40 <Shiz> even if you could
2018-10-21 17:38:04 <Mo0O> modprobe: ERROR: could not insert 'fuse': Operation not permitted
2018-10-21 17:38:32 <Mo0O> it's not permitted during check phase
2018-10-21 18:28:56 <Shiz> it's not permitted ever
2018-10-21 18:28:58 <Shiz> :p
2018-10-21 18:58:01 <AinNero> hm
2018-10-21 18:58:43 <AinNero> the 'pass' password manager generates passwords from 7 different characters when busybox 'tr' is used
2018-10-21 18:59:01 <AinNero> which is like, awful to password safety
2018-10-21 18:59:24 <AinNero> no worry, its in testing, so no CVE :P
2018-10-22 00:38:02 <AlecTaylor> hi
2018-10-22 09:56:19 <_ikke_> linux 4.19 (lts) has been released
2018-10-22 10:02:09 <unmy> _ikke_, oh nice, hope it will be good kernel :>
2018-10-22 10:26:34 <_ikke_> https://lkml.org/lkml/2018/10/22/184
2018-10-22 10:27:39 <_ikke_> gkh said that waiting a few weeks longer proved to be beneficial
2018-10-22 10:52:55 <unmy> sounds promising
2018-10-22 11:36:07 <clandmeter> can somebody restart github.exe?
2018-10-22 12:11:43 <_ikke_> heh
2018-10-22 12:12:10 <_ikke_> "The majority of restore processes have completed. We anticipate all data stores will be fully consistent within the next hour."
2018-10-22 12:12:19 <_ikke_> ~30 minutes ago
2018-10-22 13:31:27 <andypost> can someone review & commit https://github.com/alpinelinux/aports/pull/5455 to unblock armhf builder
2018-10-22 13:44:16 <clandmeter> andypost, did you verify it builds?
2018-10-22 13:45:57 <andypost> clandmeter, I did test only prepare() where it fails in chroot
2018-10-22 13:46:26 <andypost> I mean it fails now but with this option prepare can pass
2018-10-22 13:46:55 <andypost> but build still running - as hell slow
2018-10-22 13:49:05 <andypost> probably I need to tune qemu cos it running 6hrs now but using only single core
2018-10-22 13:50:10 <clandmeter> hmm
2018-10-22 13:50:19 <clandmeter> i think we didnt need to bump pkgrel
2018-10-22 13:50:55 <andypost> clandmeter, that's why I asking someone more familar with kernel
2018-10-22 13:51:11 <clandmeter> now it rebuilds all arch kernels
2018-10-22 13:58:31 <andypost> clandmeter, while you're here) can you approve or comment on https://github.com/alpinelinux/aports/pull/5437
2018-10-22 16:44:17 <nmeum> ncopa: re: gnome-shell https://github.com/alpinelinux/aports/commit/b1f08894693a872b890ed1e9ca76ada3bb9f980f#commitcomment-30994566
2018-10-22 18:03:45 <_ikke_> Meeting in about 30 minutes in #alpine-meetings about naming things / DNS. Feel free to join.
2018-10-22 18:06:12 <_ikke_> Agenda: http://tpaste.us/J6W0
2018-10-22 20:52:12 <frebib> I guess I should ask if there are any plans to update openssl to 1.1.1 in the next major release? I understand it is a big task
2018-10-22 20:55:28 <_ikke_> I think there are plans to do something with openssl, not sure what though
2018-10-22 21:01:51 <frebib> Although thinking about it, nothing much will come of it because libressl is ABI compatible with the 1.0 series of OpenSSL releases, not 1.1
2018-10-22 21:02:04 <frebib> So it hardly makes a difference
2018-10-22 21:13:30 <TBB> is that the case?
2018-10-22 21:14:34 <TBB> I'm by no means knowledgeable about the topic, but I seem to remember seeing at least some 1.1 compatibility in, was it, 2.7 series already
2018-10-22 21:16:16 <TBB> I think I was porting some tools required for some linux auditing framework that had 1.0 and 1.1 compatible versions of them and being able to package the 1.1 ones with libressl 2.7
2018-10-22 21:17:21 <TBB> but I underline the fact I'm basically a packaging monkey without deep understanding of what I do
2018-10-22 21:17:23 <andypost> TBB, I guess you mean fresh release of 2.7.2 which provides better BC for openssl
2018-10-22 21:17:57 <TBB> could very well be, that'd make sense
2018-10-22 21:55:20 <frebib> If supported and compiled against, anything should work with 1.1 and 1.0 but things compiled against 1.1 don't necessarily work with libressl and vice-versa
2018-10-22 21:56:02 <frebib> So until libressl becomes 1.1 binary compatible I imagine openssl1.0 will stay the primary version
2018-10-23 06:39:27 <ncopa> there are plans to switch to openssl 1.1 for alpine v3.9
2018-10-23 09:00:34 <nmeum> is there any particular reason why we build boost with `--layout=tagged`? This adds prefixes to library names, e.g. our boost_thread library has an -mt prefix and you thus can't link against it with -lboost_thread
2018-10-23 09:00:38 <nmeum> see also: https://www.boost.org/doc/libs/1_68_0/more/getting_started/unix-variants.html#library-naming
2018-10-23 09:01:27 <nmeum> Arch Linux, for instance, builds boost with `--layout=system` thereby avoiding this problem entirely
2018-10-23 10:17:53 <sunmaster> Hi, I would like to understand (I) how Alpine's standard iso get its kernel - if it is not included by a package -, then (II) what _is_ the base system of Alpine - does it consist of the 18 packages showing up by apk info?- ?
2018-10-23 10:21:17 <sunmaster> I would like to (re)build the base system plus some other packages on top, but for this I need first to know what the base system of Alpine is.
2018-10-23 10:21:33 <sunmaster> I am thankful for every help I can get.
2018-10-23 10:25:27 <nmeum> https://pkgs.alpinelinux.org/package/edge/main/ppc64le/alpine-base this package depends on all other packages needed by a minimal base system (e.g. busybox)
2018-10-23 10:26:33 <nmeum> the kernel is shipped in a separate package https://pkgs.alpinelinux.org/package/edge/main/x86_64/linux-vanilla
2018-10-23 10:27:14 <nmeum> if you want to build your own image take a look at https://git.alpinelinux.org/cgit/aports/tree/scripts/mkimage.sh
2018-10-23 10:29:46 <sunmaster> nmeum: Thanks you very much for your answers, the one thing I do not understand is why linux-vanilla is not showing up in apk info for the booted (not installed) standard iso? Is it just extracted into the iso at its generation?
2018-10-23 10:31:14 <_ikke_> yes, it's part of the booadloader
2018-10-23 10:31:27 <_ikke_> Imagine that apk cannot run without running linux first
2018-10-23 10:32:05 <_ikke_> bootloader*
2018-10-23 10:35:46 <sunmaster> _ikke_: ?? Of course apk can not run without the kernel but after booting it should be able to list the package name with the kernel. I am confused now. After installing the standard iso linux-vanilla shows up.
2018-10-23 10:36:08 <_ikke_> It serves no real purpose
2018-10-23 10:36:16 <_ikke_> and it doesn't work anyway
2018-10-23 10:36:28 <_ikke_> the kernel lives on the boot media, not on the root file system
2018-10-23 10:36:41 <sunmaster> ahh
2018-10-23 10:36:59 <sunmaster> why do you not say so it in the beginning
2018-10-23 10:37:22 <sunmaster> Now it is clear, you have two distinct systems there
2018-10-23 10:37:40 <_ikke_> sunmaster: it's not always clear what kind of answer someone is expecting
2018-10-23 10:39:30 <sunmaster> I am just used to look up the package names of the base system of an linux distro - for example the debootstrap list of Debian - and also look at this way which kernel a given distro is using
2018-10-23 10:39:41 <sunmaster> But again thanks for your help.
2018-10-23 10:42:38 <AinNero> sunmaster: btw, its completely optional to have the kernel installed as package
2018-10-23 10:42:46 <AinNero> not specifically to alpine, but it general
2018-10-23 10:45:49 <sunmaster> at least the "big" distros are installing the kernel (even in the minimal or base systems) from the package so that you as a user (or admin) can manage it. Without package (entry in the package database) you have to find every file that belongs to the kernel
2018-10-23 10:46:16 <_ikke_> sunmaster: on an installed system, there is a kernel package
2018-10-23 10:46:22 <_ikke_> that's how the kernel is kept up-to-date
2018-10-23 10:46:40 <AinNero> sunmaster: alpine supports boot-to-ram, with only a little of ram usage
2018-10-23 10:46:49 <AinNero> keeping an offline copy of the kernel does not make sense there
2018-10-23 10:47:11 <sunmaster> _ikke_: Yes, I know and this discrepancy was confusing to me as a Alpine beginner.
2018-10-23 10:48:07 <AinNero> sunmaster: what were your previous distros? debian-like?
2018-10-23 10:48:13 <sunmaster> AinNero: Yes
2018-10-23 10:49:00 <sunmaster> But I also looked into Gentoo. And used it for some time.
2018-10-23 10:49:58 <sunmaster> Now I have to get into virtualization/containerization and want to use (and later contribute to) Alpine.
2018-10-23 10:50:55 <sunmaster> My questions were my first baby steps to becoming an Alpine dev.
2018-10-23 10:53:06 <AinNero> hah.
2018-10-23 10:53:50 <AinNero> personally, i dont like that 'i want to become an XYZ' dev approach
2018-10-23 10:54:14 <AinNero> my biggest sin is wrath, and im angry about software alot. so i moved away from systemd/Debian to alpine
2018-10-23 10:54:48 <AinNero> and i found that some things in alpine were also bad or undocumented
2018-10-23 10:54:59 <sunmaster> I just want to give back to that what I took from.
2018-10-23 10:55:05 <AinNero> ah, that sounds nice
2018-10-23 10:55:31 <sunmaster> YES, there are many things not really documented. Maybe that is where I can start ... I have to learn first.
2018-10-23 10:55:35 <AinNero> 
ACTION remembers that they are supposed to write contribution guidelines

2018-10-23 10:58:57 <AinNero> personal worries that there are too many pull requests being stacked up
2018-10-23 10:59:25 <AinNero> i can't review much exept for the things i personally use
2018-10-23 11:00:53 <_ikke_> yes, but there is a long-tail of PRs that are stuck somehow
2018-10-23 11:23:03 <AinNero> next script will be a thing that fetches the PR heads from github and checks against my /etc/apk/world
2018-10-23 11:23:28 <AinNero> so i can get a list of packages that i use that are awaiting changes
2018-10-23 11:30:32 <mps> AinNero: such script would be useful for me, also
2018-10-23 11:34:19 <AinNero> currently its just talking, i'll come back to you when i have an PoC
2018-10-23 11:37:10 <mps> of course, but don't forget to announce it when you make it
2018-10-23 12:24:45 <AinNero> mps: this is good enough to be of use it seems http://0x0.st/s6Zi.bin
2018-10-23 12:24:59 <AinNero> also somewhat works with subpkgs
2018-10-23 12:26:04 <AinNero> take care to exit your checkout location
2018-10-23 12:26:07 <AinNero> *enter
2018-10-23 12:39:19 <mps> AinNero: trying right now. btw, why name ends in bin for shell script
2018-10-23 12:39:29 <AinNero> no idea
2018-10-23 12:41:04 <mps> never mind, just nitpicking little
2018-10-23 12:46:15 <AinNero> you could ask the author of 0x0.st to fix it, but honestly... its not exactly my favourite kind of person to interact with
2018-10-23 14:59:19 <nmeum> ncopa: what's your opinion on backporting 01ae13d188cafc19691518a4814372729dec9877 soonish? Haven't heard any complaints so far
2018-10-23 14:59:29 <nmeum> (that's the dnssec-root fix)
2018-10-23 15:16:49 <ncopa> nmeum: have you tested that it works?
2018-10-23 15:19:34 <ncopa> nmeum: i am slightly in doubt about it. it does not look like build is reproduceable
2018-10-23 15:20:21 <nmeum> ncopa: yeah I've been using it since friday on edge it does work but the build isn't reproduceable in deed as the order of the keys in the trusted keys files is not deterministic
2018-10-23 15:20:27 <nmeum> *indeed
2018-10-23 15:26:07 <nmeum> http://tpaste.us/P0qb should make the build reproducible
2018-10-23 15:27:46 <nmeum> gotta go
2018-10-23 15:28:25 <_ikke_> o/
2018-10-23 16:31:06 <andypost> ncopa, any idea what's wrong with s390x builder for edge?
2018-10-23 16:33:39 <milliardo> Hello. I'm getting `Oct 23 02:11:22 lucy smtpd[17600]: e696084a4381c67b mta event=error reason=TLS required but not supported by remote host` when I try to send an email to the list. Does lists.alpinelinux.org support being relayed mail over tls?
2018-10-23 17:49:19 <ncopa> milliardo: sounds weird. smtp protocol in it self does not require encryption
2018-10-23 17:49:41 <ncopa> can you try get a tcpdump of the smtp session?
2018-10-23 17:49:54 <ncopa> andypost: i'll have a look
2018-10-23 17:51:07 <ncopa> andypost: looks lik eits stuck in a test
2018-10-23 17:58:32 <andypost> ncopa, is there a way to see that log at build.a.o
2018-10-23 18:00:57 <milliardo> ncopa: no, but my server is configured to only relay if remote hosts provides STARTTLS
2018-10-23 18:01:44 <mps> milliardo: you can check by: openssl s_client -connect lists.alpinelinux.org:25
2018-10-23 18:05:03 <milliardo> which says that there isn't a certificate. Any plans to add one soon? If not, is there any other way to submit a patch besides a github PR?
2018-10-23 18:06:03 <mps> sory, forgot to add '-starttls smtp'
2018-10-23 18:06:25 <milliardo> same
2018-10-23 18:06:46 <mps> yes, it is the same for alpine list server
2018-10-23 18:07:32 <mps> but, if want to test some smtp server to see if it supports tls that could be done by openssl s_client
2018-10-23 18:08:05 <mps> example: openssl s_client -connect muffat.debian.org:25 -starttls smtp
2018-10-23 18:08:35 <ncopa> milliardo: i suggest that you create a ticket on bugs.a.o with the above info
2018-10-23 18:08:48 <ncopa> https://bugs.alpinelinux.org
2018-10-23 18:09:08 <ncopa> my guess is that nobody thought of fix starttls for a public mailing list
2018-10-23 18:09:51 <ncopa> ok so this openssl 1.1 thing is great...
2018-10-23 18:10:04 <_ikke_> saracasm?
2018-10-23 18:10:04 <ncopa> apparently i have made a package for openssl 1.1 in july already
2018-10-23 18:10:24 <ncopa> and this week i have redone the same work
2018-10-23 18:10:42 <ncopa> completely forgot that i already did it
2018-10-23 18:10:50 <ncopa> i'm losing it...
2018-10-23 18:10:55 <_ikke_> 0:(
2018-10-23 18:11:01 <ncopa> doublework
2018-10-23 18:11:30 <ncopa> interestingly, i solve it fairly similar :)
2018-10-23 18:13:33 <ncopa> ok. i'll clean it up tomorrow
2018-10-23 18:28:52 <frebib> ncopa: what's the plan for openssl1.1?
2018-10-24 09:05:24 <andypost> please backport it to early releases https://github.com/alpinelinux/aports/pull/5480
2018-10-24 10:54:58 <brebs> Woo, my first Alpine bug report :)
2018-10-24 10:55:07 <_ikke_> \o/
2018-10-24 10:58:03 <milliardo> mhmm, just realized I messed it up and reported https://bugs.alpinelinux.org/issues/9573 in alpine and not in alpine-infra
2018-10-24 10:58:16 <milliardo> and I don't think I can change the project
2018-10-24 11:02:31 <_ikke_> Moved it
2018-10-24 11:09:20 <milliardo> _ikke_: <3
2018-10-24 13:12:49 <clandmeter> PureTryOut[m], matrix.a.o is now turned off.
2018-10-24 14:18:10 <ncopa> frebib: the plan for openssl1.1 is to merge testing/openssl1.1 with testing/openssl, move it to main/openssl, remove main/openssl1.0 and rebuild evertying linked to libressl and build it with openssl 1.1.
2018-10-24 14:35:42 <mps> ncopa: do local built package must be rebuilt once when we upgrade to new release with openssl as default libssl
2018-10-24 14:44:37 <ncopa> yes
2018-10-24 14:48:49 <mps> good to know, to be prepared.
2018-10-24 15:00:58 <yangxuan> ncopa: would you mind I ask why disable IP_PNP in linux-rpi? I'm wonder if need also disable it in new amlogic kernel package
2018-10-24 15:05:06 <ncopa> clandmeter: ^^^
2018-10-24 15:05:13 <clandmeter> he left
2018-10-24 15:05:29 <ncopa> oh...
2018-10-24 15:05:33 <clandmeter> but i think we disable it on all of our kernels?
2018-10-24 15:05:45 <clandmeter> doesnt it conflict with initramfs network setup?
2018-10-24 15:05:53 <ncopa> i dunno
2018-10-24 15:06:23 <clandmeter> i remember some commit messages are comments in code.
2018-10-24 15:06:36 <clandmeter>  /are/or
2018-10-24 15:07:07 <ncopa> ok
2018-10-24 15:07:54 <clandmeter> https://git.alpinelinux.org/cgit/aports/tree/main/linux-vanilla/config-vanilla.x86_64#n905
2018-10-24 15:08:34 <ncopa> maybe we want switch to use kernel's IP_PNP instead of add magic in our initramfs?
2018-10-24 15:08:56 <clandmeter> there was a catch why were doing that.
2018-10-24 15:09:53 <clandmeter> AinNero, any idea?
2018-10-24 15:10:32 <clandmeter> i need to check gitlog. time to go home.
2018-10-24 15:10:48 <AinNero> 
ACTION gets up from the crypt

2018-10-24 15:11:12 <clandmeter> btw, i wonder if we really need t o add an additional kernel if they support mainline.
2018-10-24 15:11:20 <clandmeter> ncopa, ^
2018-10-24 15:11:35 <AinNero> clandmeter: ah right, i never could get it to work
2018-10-24 15:12:08 <AinNero> the people trying it previously were like, 'use an proper dhcp client'
2018-10-24 15:12:15 <clandmeter> AinNero, how does debian do it?
2018-10-24 15:12:20 <AinNero> the procfs (afaik) interface had some shortcomings
2018-10-24 15:12:44 <AinNero> i can't easily check how debian does it
2018-10-24 15:13:57 <AinNero> IP_PNP was intended for stuff like NFS root, or remote block device stuff
2018-10-24 15:14:23 <AinNero> which some sort of got replaced by initramfs + userspace tools
2018-10-24 15:18:43 <AinNero> the nearest debian has # CONFIG_IP_PNP is not set
2018-10-24 15:20:32 <AinNero> ncopa: im fine with removing it alltogether, it was inconsistently across kernel flavours until now
2018-10-24 15:21:01 <ncopa> so we keep IP_PNP disabled?
2018-10-24 15:22:43 <AinNero> for vanilla, yes. virt currently has it enabled
2018-10-24 15:23:06 <ncopa> so we disable it everywhere?
2018-10-24 15:23:10 <ncopa> was my question
2018-10-24 15:23:10 <AinNero> my idea.
2018-10-24 15:23:12 <AinNero> yes.
2018-10-24 15:23:13 <ncopa> ok
2018-10-24 15:23:22 <ncopa> lets do that with next kernel update
2018-10-24 15:23:28 <AinNero> alright
2018-10-24 15:23:33 <ncopa> or together with 4.19
2018-10-24 15:23:46 <ncopa> oh!!!
2018-10-24 15:23:48 <ncopa> 4.19 is out
2018-10-24 15:23:52 <_ikke_> yes
2018-10-24 15:23:55 <_ikke_> I linked to it
2018-10-24 15:24:11 <_ikke_> Was released on monday
2018-10-24 15:24:22 <_ikke_> https://lkml.org/lkml/2018/10/22/184
2018-10-24 15:29:22 <ncopa> ha, and i was out monday
2018-10-24 17:28:58 <AinNero> ncopa: there are some PR's on mkinitfs still open
2018-10-24 17:36:41 <ncopa> i know, i havent had time to look at them
2018-10-24 17:36:59 <ncopa> the plan is to work on those and gcc6 when builder is busy with the openssl rebuild
2018-10-24 18:20:16 <_ikke_> fyi: we disabled tlsv1.0 and tlsv1.1 on git.alpinelinux.org. Please let us know if you are facing issues
2018-10-24 19:24:27 <Half-Shot> PureTryOut: is this working?
2018-10-24 19:24:40 <PureTryOut[m]> hey I can talk now, thanks! 😄
2018-10-24 19:31:05 <_ikke_> What was the issue?
2018-10-24 19:31:52 <PureTryOut[m]> Matrix users required a permission of 1 to talk in this room, which nobody had
2018-10-24 19:32:01 <Half-Shot> Bridge forgot to allow people to speak :|
2018-10-24 19:32:21 <Half-Shot> I told it off, it will behave now.
2018-10-24 19:32:37 <PureTryOut[m]> Well, and some people on IRC don't come through to Matrix, so we see basically only half of the conversation. not sure if that is gone
2018-10-24 19:41:16 <andypost[m]> yay! now #freenode_#alpine-devel:matrix.org works
2018-10-24 19:42:28 <HRio> is current zfs version known to be unstable on arm 32-bit? seeing that we only build it for "x86 x86_64 aarch64"
2018-10-24 19:56:07 <HRio> I was under the impression that 32-bit stability improved in zfs on linux 0.7.0 and in 0.7.3, but anybody here that have tested on arm 32-bit with alpine?
2018-10-24 19:56:12 <PureTryOut[m]> andypost: yeah we needed some help 😅
2018-10-24 20:06:05 <andypost[m]> PureTryOut: at least in this room I can see all messages but none in #alpine-devel:alpinelinux.org
2018-10-24 20:07:40 <andypost[m]> and the last one (official) still readonly
2018-10-24 20:11:38 <PureTryOut[m]> the latter one is old, the homeserver that hosted the alias has been taken down
2018-10-24 20:11:53 <PureTryOut[m]> so it should be ignored anyway
2018-10-24 20:12:19 <PureTryOut[m]> same with #alpine-linux:alpinelinux.org , should also not be used anymore. use #freenode_#alpine-linux:matrix.org instead. That one does still have the permission problem though
2018-10-24 20:50:52 <andypost[m]> PureTryOut: btw #alpine-commits:alpinelinux.org works fine
2018-10-24 20:51:50 <PureTryOut[m]> sure, just note that people can't join that room via that alias anymore. the Alpine Linux homeserver has been taken down
2018-10-25 04:15:30 <yangxuan> ncopa: sorry for quit just after ask question yesterday
2018-10-25 04:16:44 <yangxuan> after check the discussion in irclog, seems I also need to disable IP_PNP in new amlogic kernel
2018-10-25 04:21:47 <yangxuan> yes, this kernel actually mainline with some patches, the amlogic support was added to mainline at least from 4.14 or early, but the support wasn't so good on old kernel, when linux-vanilla move to 4.18 or later maybe it's possible to merge them into one package, but the package size I guess would be quite big, it's 75MB after compress
2018-10-25 07:17:05 <clandmeter> yangxuan, 4.19 is coming soon
2018-10-25 07:17:11 <clandmeter> its the new lts kernel
2018-10-25 07:18:17 <yangxuan> clandmeter, what's the alpine plan(date) to move to 4.19
2018-10-25 07:18:31 <_ikke_> yangxuan: soon(tm)
2018-10-25 07:18:57 <clandmeter> i think ncopa has a few important items on his todo list
2018-10-25 07:20:36 <clandmeter> switching to openssl will probably take some time.
2018-10-25 07:20:41 <yangxuan> so, you tend to add amlogic support when have 4.19 kernel?
2018-10-25 07:21:10 <clandmeter> yangxuan, i took a quick look at your kernel
2018-10-25 07:21:19 <clandmeter> there are many patches
2018-10-25 07:21:56 <clandmeter> how many of then will be left for 4.19?
2018-10-25 07:24:05 <yangxuan> it's said without most pathes it should still work, but maybe not so good, the mainline amlogic is still under development
2018-10-25 07:25:09 <clandmeter> i dont think ncopa wants to have so many patches to rebase all the time.
2018-10-25 07:26:18 <clandmeter> so if it can be limited it would maybe be possible, else you will to submit the kernel yourself and keep it up to date.
2018-10-25 07:27:55 <yangxuan> ok, then I guess better submit the new kernel package and update it myself
2018-10-25 07:30:13 <yangxuan> amlogic mainline developer said some device can boot with vanilla and arm64 defconfig, but most amlogic device I guess not, at least not for my android box
2018-10-25 07:31:25 <clandmeter> many of them are dts additions?
2018-10-25 07:31:50 <clandmeter> and meson updates?
2018-10-25 07:34:42 <yangxuan> clandmeter: yes, as I said, the mainline amlogic is still under development
2018-10-25 07:35:41 <yangxuan> the rest changes in linux-rpi config-changes-rpi.armhf, if they are also necessary for other device?
2018-10-25 07:36:22 <clandmeter> i think most of them i added to actually make it build.
2018-10-25 07:37:50 <clandmeter> i think you can keep most of them
2018-10-25 07:38:03 <clandmeter> only the ones you think are not needed for your env you can remove.
2018-10-25 07:38:48 <yangxuan> I see.
2018-10-25 07:40:43 <yangxuan> will compare it with current amlogic config later, after that the kernel package should ready to submit
2018-10-25 07:42:28 <clandmeter> a few of them (the first ones) were to make it build.
2018-10-25 07:42:52 <clandmeter> i think the rest is a diff from rpi to vanilla and we selected what we wanted.
2018-10-25 07:43:06 <clandmeter> wanted/needed.
2018-10-25 07:52:34 <yangxuan> clandmeter: I've compared them, seems need add those config: https://paste.ubuntu.com/p/Jc4r6XQtFW/
2018-10-25 07:55:46 <yangxuan> will test if it can build
2018-10-25 07:56:37 <clandmeter> i remember i had to add the frrst two to make rpi kernel build.
2018-10-25 07:56:59 <clandmeter> chances are you dont have it for amlogic defconfig
2018-10-25 07:57:19 <clandmeter> if those are enabled i think your build will fail.
2018-10-25 07:58:27 <yangxuan> actually the current config already able to build
2018-10-25 08:00:17 <yangxuan> the STACK_TRACER was not enable, and for FUNCTION_TRACER, the linux-vanilla enable it, so I didn't disable it
2018-10-25 08:05:20 <clandmeter> yangxuan, most of the other options were advised by ncopa
2018-10-25 08:05:28 <clandmeter> and the packet module is needed by alpine afaik
2018-10-25 08:05:45 <clandmeter> but we should probably fix that by just including it.
2018-10-25 08:05:59 <clandmeter> but it will need more work as only kernel.
2018-10-25 08:06:36 <clandmeter> yangxuan, do you use alpine initramfs?
2018-10-25 08:07:07 <clandmeter> SQUASHFS_LZ4 is probably needed for modloop
2018-10-25 08:07:39 <yangxuan> yes, it's enabled
2018-10-25 08:08:45 <yangxuan> clandmeter: I just test the changes in above links, it complain: Config: CONFIG_CC_STACKPROTECTOR not properly set!
2018-10-25 08:09:24 <yangxuan> can I skip CONFIG_CC_STACKPROTECTOR?
2018-10-25 08:11:45 <clandmeter> thats a security feature
2018-10-25 08:11:51 <clandmeter> i wouldnt disable it.
2018-10-25 08:17:29 <yangxuan> the current config have this config: CONFIG_CC_HAS_STACKPROTECTOR_NONE=y I'm not sure if it's affect CONFIG_CC_STACKPROTECTOR
2018-10-25 08:18:17 <clandmeter> try to remove it and see if it works.
2018-10-25 08:19:22 <clandmeter> i mean disable it.
2018-10-25 08:22:08 <yangxuan> disable CONFIG_CC_HAS_STACKPROTECTOR_NONE ?
2018-10-25 08:22:18 <clandmeter> yes
2018-10-25 08:31:59 <yangxuan> clandmeter: not work, according to cateee.net the CC_STACKPROTECTOR don't depends on other config, kind of weird
2018-10-25 08:35:26 <mps> yangxuan: I've built 4.19 for arm32 with CONFIG_STACKPROTECTOR_STRONG=y and it works,although not for rpi but for allwiner A20
2018-10-25 08:36:30 <mps> and CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
2018-10-25 08:38:20 <yangxuan> mps: I'm build for amlogic, not sure why this not work
2018-10-25 08:40:23 <mps> it should be work because that part isn't SoC specific, but who knows, could be some quirk somewhere
2018-10-25 08:40:59 <mps> s/should be/should/
2018-10-25 08:42:08 <clandmeter> yangxuan, what is your build env? just plain alpine?
2018-10-25 08:42:13 <mps> are you building it on stable or on edge
2018-10-25 08:43:00 <ncopa> looks liek there is a new CVE for openssl coming up soonish: https://github.com/openssl/openssl/commit/ece482ff3ad958872ab011dc3e9af49ecb238ec8
2018-10-25 08:43:05 <yangxuan> on edge
2018-10-25 08:43:50 <mps> I've built it on stable, just for info
2018-10-25 08:44:30 <yangxuan> thanks for the info, after skip CONFIG_CC_STACKPROTECTOR the rest changes seems ok
2018-10-25 08:45:44 <clandmeter> ncopa, i don think we want to disable CONFIG_CC_STACKPROTECTOR?
2018-10-25 08:46:32 <yangxuan> clandmeter: I'm native build in this docker: https://github.com/yangxuan8282/docker-apk-build , although I'm not quite understand what's plain alpine
2018-10-25 08:47:25 <clandmeter> plain means you use official alpine tools (ie alpine-sdk) to build kernel.
2018-10-25 08:47:57 <yangxuan> yes, it's standard one, by abuild
2018-10-25 08:48:33 <ncopa> i think we want have stackprotector enabled fi possible, yes
2018-10-25 08:53:21 <mps> of course
2018-10-25 08:55:06 <mps> I've built 4.19 but not with alpine config (I need it for something special on arm SBC) but next week I will try to build it with alpine config on armhf and aarch64
2018-10-25 09:02:03 <andypost> ncopa, https://github.com/alpinelinux/aports/pull/5253 please check about security update - it also removes libressl patch
2018-10-25 09:02:53 <andypost> btw something weird with github/travis sometimes status is not reported back
2018-10-25 09:03:28 <andypost> maybe caused by last guthub fail cos some PRs are not closed after merge by bot
2018-10-25 09:03:40 <clandmeter> correct
2018-10-25 09:03:44 <clandmeter> i saw that also
2018-10-25 09:04:59 <andypost> clandmeter, looks like merging not-own PRs is not reported back by bot
2018-10-25 09:05:51 <clandmeter> sounds weird
2018-10-25 09:06:08 <clandmeter> but github has been weird lately
2018-10-25 09:07:49 <andypost> clandmeter, is the bot's code accessible in any public repo to check?
2018-10-25 09:08:06 <clandmeter> the pr closer?
2018-10-25 09:08:10 <andypost> yep
2018-10-25 09:08:14 <clandmeter> yes
2018-10-25 09:08:21 <clandmeter> its done by jirutka
2018-10-25 09:08:31 <clandmeter> check his repo
2018-10-25 09:08:38 <clandmeter> i think its called github-pr-closer
2018-10-25 09:09:14 <clandmeter> maybe its in alpine github space idk
2018-10-25 09:09:32 <andypost> https://github.com/jirutka/github-pr-closer I'll dig today
2018-10-25 09:10:22 <clandmeter> andypost, so some do close and others dont?
2018-10-25 09:11:26 <andypost> clandmeter, exactly and IMO it is not random
2018-10-25 09:11:51 <clandmeter> ah its even in aports
2018-10-25 09:12:21 <clandmeter> oh its in jirutka personal ports
2018-10-25 09:13:08 <andypost> clandmeter, https://github.com/alpinelinux/aports/pull/5473#issuecomment-432803698
2018-10-25 09:14:40 <clandmeter> if you can find the issue that would be nice.
2018-10-25 09:14:55 <clandmeter> else you could create a ticket and see if jirutka will respond.
2018-10-25 09:19:01 <clandmeter> andypost, what about the latest pr 5484
2018-10-25 09:19:17 <clandmeter> seems to autoclose just right
2018-10-25 09:21:40 <andypost[m]> Yep, it  looks like random
2018-10-25 09:23:35 <clandmeter> no its not
2018-10-25 09:23:38 <clandmeter> its user based
2018-10-25 09:23:48 <clandmeter> we've seen this before
2018-10-25 09:24:01 <clandmeter> check all 	J0WI pr's
2018-10-25 09:24:05 <clandmeter> they dont auto close
2018-10-25 09:26:17 <clandmeter> its similar to awilfox pr's
2018-10-25 09:39:11 <clandmeter> andypost[m], i wonder if its something related to having pgp keys in your profile but not using them to sign.
2018-10-25 09:42:59 <andypost[m]> hm, looks like ... is there similar issues before guhub flux?
2018-10-25 09:47:09 <andypost[m]> clandmeter, I just accepted https://github.com/alpinelinux/aports/pull/5458 and it was not closed again
2018-10-25 09:47:19 <Myhro> Is there a way to see a list of issues/bugs that are more critical (e.g. blocking builders)? I'm seeing lots of mentions of packages being prepared for 3.9, but at the same time I don't know which ones have high priority (and looks like one can't trust the 'Priority' field on bugs.a.o).
2018-10-25 09:48:03 <clandmeter> andypost[m], i think it has nothing to do with github dowmtime.
2018-10-25 09:53:18 <andypost[m]> clandmeter, you are right - just commited 5477 and it was closed fine
2018-10-25 09:58:33 <yangxuan> need help, after make menuconfig with amlogic config, use / search CC_STACKPROTECTOR no found matches
2018-10-25 10:05:24 <ncopa> Myhro: there are no easy way
2018-10-25 10:05:48 <ncopa> Myhro: you can see whats blocking builders in #alpine-commits normally
2018-10-25 10:06:02 <ncopa> and on http://build.alpinelinux.org
2018-10-25 10:08:54 <ncopa> andypost: im updating the commit message for apache2 2.4.35
2018-10-25 10:10:43 <andypost> ncopa, got it - I was not sure cos apache2 package does not provides http/2
2018-10-25 10:11:23 <ncopa> maybe we should enable http/2 for alpine v3.9?
2018-10-25 10:11:38 <andypost> I bet we should
2018-10-25 10:13:59 <Myhro> ncopa: That's nice. I'll follow up on them. Thanks.
2018-10-25 10:14:59 <yangxuan> ncopa: can I skip CC_STACKPROTECTOR for amlogic config? because seems I can't enable it.
2018-10-25 10:24:49 <ncopa> yangxuan: ok
2018-10-25 10:40:48 <andypost> ncopa, does it makes sense to backport to 3.8 bugfixes like dependency of package https://bugs.alpinelinux.org/issues/9119
2018-10-25 10:42:39 <ncopa> yes, i think so
2018-10-25 10:43:07 <ncopa> let me know which commits we need to backport and I can try handle it
2018-10-25 10:44:00 <andypost> ncopa, I could make PR with security upgrade & backport, I see you also fixed ICU - it also makes sense to backport
2018-10-25 10:44:15 <ncopa> ok
2018-10-25 10:59:44 <andypost> Also https://github.com/alpinelinux/aports/pull/5480 needs backport cos really critical
2018-10-25 11:16:06 <sunmaster> Hi there
2018-10-25 11:18:43 <sunmaster> What does it mean if after "fakeroot make PROFILE=alpine-rescue iso" I get the ERROR: unsatisfiable constraints: linux-grsec (missing): required by: world[linux-grsec]
2018-10-25 11:20:52 <TBB> means whatever you're using is old
2018-10-25 11:21:07 <TBB> linux-grsec hasn't existed for a while
2018-10-25 11:22:52 <sunmaster> I just cloned alpine-iso and tried out the wiki documentation. How can that repo be old
2018-10-25 11:22:55 <sunmaster> ?
2018-10-25 11:24:31 <unmy> sunmaster, git clone git://git.alpinelinux.org/alpine-iso ?
2018-10-25 11:24:41 <sunmaster> unmy: yes
2018-10-25 11:24:58 <unmy> this how-to is outdated
2018-10-25 11:25:12 <unmy> look: https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image
2018-10-25 11:25:32 <sunmaster> That is what I read
2018-10-25 11:25:34 <AinNero> yeah, use mkimage from aports.git now
2018-10-25 11:25:39 <unmy> https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage
2018-10-25 11:25:43 <AinNero> read the notice at the top
2018-10-25 11:25:46 <unmy> ye
2018-10-25 11:29:16 <sunmaster> AinNero: I also tried mkimage.sh. It does not work :-(
2018-10-25 11:43:55 <sunmaster> Right now I tried it out just as it is written in the wiki with only the Profilename set to standard. I get grub-mkimage not found.
2018-10-25 11:54:10 <sunmaster> sh mkimage.sh --tag edge --outdir ~/output --workdir ~/workingdir --arch x86_64 --repository http://dl-cdn.alpinelinux.org/alpine/edge/main --profile standard
2018-10-25 11:54:31 <sunmaster> gave me first the grub-mkimage not found error.
2018-10-25 11:55:42 <sunmaster> Then I installed grub. Now it gives me the error cannot open /usr/lib/grub/...blah No such file or directory.
2018-10-25 11:56:46 <sunmaster> Please, why do these not work in the default so that a new user can try them out. What are you devs using for the variables.
2018-10-25 12:00:32 <sunmaster> "fakeroot make PROFILE=alpine-standard iso" worked. PROFILE=alpine-rescue did not work. the mkimage.sh does not work, the bootstrap.sh could not even set one of the first variables in the script, I had to set CBULDROOT in the script to some directory and then it gave me some error, too.
2018-10-25 12:01:03 <sunmaster> s/CBULDROOT/CBUILDROOT/
2018-10-25 12:01:57 <AinNero> dont know. last time i used it to generate an image it worked
2018-10-25 12:05:42 <AinNero> im also having these issues
2018-10-25 12:08:40 <sunmaster> okay then, I have to look for another lightweight distribution. I really thought that alpine would be easy to look into.
2018-10-25 12:08:52 <sunmaster> thanks all for your answers and help
2018-10-25 12:08:54 <sunmaster> bye
2018-10-25 12:09:52 <AinNero> ah right
2018-10-25 12:10:02 <AinNero> what a nice timing. just need to install grub-efi
2018-10-25 12:14:41 <Michcioperz> it's all in the first lines of mkimage.sh isn't it?
2018-10-25 12:22:01 <AinNero> .. yes
2018-10-25 12:22:04 <AinNero> and also in the wiki
2018-10-25 14:49:59 <yangxuan> clandmeter: if there are any document about how to pxe boot rpi or other arm alpine linux?
2018-10-25 14:50:28 <clandmeter> yangxuan, no
2018-10-25 14:50:46 <clandmeter> you need a bootloader that supports it.
2018-10-25 14:51:02 <yangxuan> you mean u-boot?
2018-10-25 14:51:05 <clandmeter> rpi bootloader does
2018-10-25 14:51:37 <clandmeter> I havent played much with uboot
2018-10-25 14:52:17 <clandmeter> if you have a bootloader that supports pxe you can load ipxe.
2018-10-25 14:52:43 <clandmeter> but afaik ipxe is not supported on arm32
2018-10-25 14:52:48 <yangxuan> with the rpi blobs (bootcode.bin, fixup.dat, and start.elf) ?
2018-10-25 14:53:23 <clandmeter> yes, you need to put them on a tftp server
2018-10-25 14:53:37 <clandmeter> the bootloader of rpi3 will fetch bootcode.bin
2018-10-25 14:53:57 <clandmeter> you should be able to find that info on the net.
2018-10-25 14:54:12 <clandmeter> i tried it before, its just a bit slow but works.
2018-10-25 14:55:04 <yangxuan> I tried it once, before disable IP_PNP, without initramfs it boot with tftp + nfs
2018-10-25 14:56:16 <clandmeter> http://dev.alpinelinux.org/~clandmeter/other/rpi-netboot.mp4
2018-10-25 14:57:24 <yangxuan> I remember the video, you post the links on postmarket github issues when I ask
2018-10-25 14:58:28 <yangxuan> but you didn't give details about how to make it boot when you post it
2018-10-25 14:59:07 <clandmeter> its just regular boot with initramfs
2018-10-25 14:59:20 <yangxuan> in this video you are boot it with ipxe?
2018-10-25 14:59:23 <clandmeter> and modloop fetched via http
2018-10-25 14:59:37 <clandmeter> no just rpi bootloader
2018-10-25 14:59:56 <clandmeter> you need to put the config.txt on tftp
2018-10-25 15:01:17 <yangxuan> the current rpi alpine official img still support pxe?
2018-10-25 15:01:21 <clandmeter> it will fetch it and you can specifiy kernel and initramfs and cmdline
2018-10-25 15:01:58 <clandmeter> yes, but the logic is mostly in bootloader
2018-10-25 15:02:16 <clandmeter> the only magic i added is fetrching of modloop via http
2018-10-25 15:02:41 <clandmeter> you need to specify modloop=http....
2018-10-25 15:02:44 <clandmeter> i need tro run now.
2018-10-25 15:02:46 <clandmeter> later
2018-10-25 15:02:55 <yangxuan> ok
2018-10-25 15:03:06 <AinNero> yangxuan: we have an netbooted RPi3 in the hackspace
2018-10-25 15:03:18 <AinNero> so im sure it works
2018-10-25 15:04:07 <yangxuan> AinNero: the recent alpine official rpi img still support pxe?
2018-10-25 15:06:18 <yangxuan> I remeber used to tried alpine pxe on rpi with blobs and amlogic with u-boot, the kernel boot, but the initramfs complain can't find /dev/nfs
2018-10-25 15:07:21 <yangxuan> test alpine with the amlogic kernel pxe boot just days ago
2018-10-25 15:08:14 <AinNero> split it up into two steps: 1) loading kernel, initramfs and command line and put it into ram
2018-10-25 15:08:26 <AinNero> 2) execute it, initramfs loads modloop and boots alpine diskless
2018-10-25 15:08:56 <AinNero> 1 works on the RPi in the hackspace, 2 is rather platform-independent and works with alpine
2018-10-25 15:09:23 <AinNero> so i dont see any reason why it should not work, i'll try it later
2018-10-25 15:10:15 <yangxuan> the alpine I use is classic install, no modloop, just initramfs
2018-10-25 15:10:54 <AinNero> where is the rootfs? on nfs?
2018-10-25 15:11:03 <yangxuan> yes
2018-10-25 15:12:04 <AinNero> i dont know if the initramfs still supports it
2018-10-25 15:12:37 <yangxuan> the step 2 you metion, initramfs load modloop, they all put in tftp?
2018-10-25 15:13:09 <AinNero> modloop cannot be fetched from tftp, but from ftp or http
2018-10-25 15:13:12 <AinNero> and maybe nfs
2018-10-25 15:14:23 <AinNero> i once wanted to add support to fetch modloop over tftp, but tftp has an 32 megabyte limit, so it might fail in many usecases
2018-10-25 15:14:38 <AinNero> so it would never be reliable enough for 'officially supported'
2018-10-25 15:17:45 <yangxuan> modloop is kind of mystery for me, work like magic
2018-10-25 15:18:11 <AinNero> its an quashfs blob
2018-10-25 15:18:16 <AinNero> *squashfs
2018-10-25 15:18:28 <AinNero> and you mount it at /lib/module/$(uname -r)
2018-10-25 15:18:35 <AinNero> and it contains the kernel modules
2018-10-25 15:19:00 <AinNero> actually, not you, but the diskless system fetches and mounts it
2018-10-25 15:19:19 <yangxuan> AinNero: how can we tell the device where to fetch(ftp/http) modloop, cmdline.txt or config.txt
2018-10-25 15:19:47 <AinNero> cmdline.txt
2018-10-25 15:20:24 <yangxuan> format like: modloop=http://some.where ?
2018-10-25 15:23:47 <AinNero> yeah
2018-10-25 15:24:03 <AinNero> the code is in /etc/init.d/modloop, in start()
2018-10-25 15:25:55 <AinNero> there is a manpage for some other options that is not released yet, curl http://0x0.st/s61W.txt
2018-10-25 15:27:28 <yangxuan> thanks, will test it on rpi
2018-10-25 15:32:49 <clandmeter> yangxuan, i never tested nfs boot
2018-10-25 15:33:01 <clandmeter> only tmpfs
2018-10-25 15:33:20 <clandmeter> modloop also has the firmware
2018-10-25 15:35:05 <yangxuan> I used to get nfs work with alpine, with older version kernel(in June), but the latest kernel seems not support it anymore
2018-10-25 15:36:48 <clandmeter> are you sure its kernel related?
2018-10-25 15:36:52 <yangxuan> this is the last rpi class install alpine I can get work with pxe (tftp + nfs), need comment out initramfs in config.txt: https://github.com/yangxuan8282/gen-rpi_os/releases/download/rpi/2018-06-24-alpine-rpi-aarch64.zip
2018-10-25 15:37:02 <clandmeter> or could be something broken in initramfs
2018-10-25 15:37:54 <yangxuan> I have to comment out initramfs, so kernel can mount nfs itself
2018-10-25 15:38:53 <yangxuan> not sure if it's related to IP_PNP
2018-10-25 15:40:56 <AinNero> IP_PNP is required if you want the kernel to do NFS on its own
2018-10-25 15:41:16 <AinNero> but im sure this is deprecated since there is initramfs now
2018-10-25 15:42:26 <clandmeter> yangxuan, did you build initramfs with nfs support?
2018-10-25 15:42:54 <clandmeter> the one you dl from mirrors will not support it.
2018-10-25 15:43:51 <yangxuan> the initramfs is auto generated by trigger, so I guess not with nfs support
2018-10-25 15:44:07 <clandmeter> you need to enable it in features
2018-10-25 15:44:11 <clandmeter> network and nfs
2018-10-25 15:44:16 <clandmeter> iirc
2018-10-25 15:47:07 <yangxuan> clandmeter: append nfs and network in /etc/mkinitfs/mkinitfs.conf ?
2018-10-25 15:49:29 <clandmeter> Check if they are valid features
2018-10-25 15:59:22 <yangxuan> AinNero: just tried on rpi, extract alpine rpi in a folder, run tftp and http(darkhttpd), edit cmdline.txt append modloop=http://some.where , the rpi recive kernel, but not ask for modloop
2018-10-25 16:00:28 <AinNero> modloop is fetched from the diskless system, do you also send the initramfs?
2018-10-25 16:00:54 <AinNero> if you are using an NFS root, then you dont need an extra modloop
2018-10-25 16:01:04 <AinNero> because the kernel modules will be in the NFS root then
2018-10-25 16:01:56 <AinNero> for reference, 'diskless' means the tmpfs-rootfs that the alpine iso does per default
2018-10-25 16:02:19 <AinNero> NFS is handled like some special sort of disk
2018-10-25 16:02:36 <yangxuan> this is the docker compose file I use: https://paste.ubuntu.com/p/btxmszQvmc/
2018-10-25 16:03:47 <yangxuan> the alpine was download from alpine mirror, alpine-rpi-3.8.1-aarch64.tar.gz, extract to os/boot folder, not use NFS, just tftp and http host modloop
2018-10-25 16:04:55 <yangxuan> here is the edited cmdline.txt: modules=loop,squashfs,sd-mod,usb-storage quiet dwc_otg.lpm_enable=0 console=tty1 modloop=http://192.168.2.105:8000/boot/modloop-rpi
2018-10-25 16:06:25 <yangxuan> from server output, both the kernel and initramfs was sent to rpi, but modloop not
2018-10-25 16:11:37 <yangxuan> clandmeter: just check the features, seems nfs was not available
2018-10-25 16:25:30 <clandmeter> So it looks like no NFS support in initramfs
2018-10-25 16:54:30 <yangxuan> just found someone boot a Yocto based Linux on a Beaglebone Black in one second, how fast alpine could be on arm?
2018-10-25 17:19:33 <TBB> seems his hasn't come back up in 25 minutes...
2018-10-25 18:00:31 <mbeierl> Is this the right channel to ask questions about building software on Alpine?  or should I ask in #alpine-linux?
2018-10-25 18:02:43 <unmy> mbeierl, extra 100~ people on #alpine :P
2018-10-25 18:02:53 <unmy> extra more
2018-10-25 18:03:05 <mbeierl> unmy: ok, thanks!
2018-10-25 18:03:28 <mbeierl> it's a question about libraries and deps while building FIO, so wasn't sure
2018-10-25 20:36:38 <AinNero> who is fixing the typo from the mailing list?
2018-10-25 23:45:26 <AinNero> andypost: #5502 should be marked for further review
2018-10-25 23:45:38 <AinNero> PR on gh, not issue
2018-10-25 23:46:05 <AinNero> was too quick with reviewing. at least it works.
2018-10-25 23:48:41 <AinNero> i was supposed to add that to the CONTRIBUTING anyways...
2018-10-26 09:13:31 <Myhro> clandmeter: I have a few (small and unrelated) changes to send for aports-turbo. Do you prefer to have them on a single PR (different commits) or separate PRs?
2018-10-26 09:15:46 <clandmeter> Myhro, hi
2018-10-26 09:15:54 <clandmeter> nice, do what you think makes sense.
2018-10-26 09:17:30 <Myhro> That's great. Thanks.
2018-10-27 09:01:31 <yangxuan> clandmeter: what's the proper way to disable auto negotiation with udev or mdev?
2018-10-27 09:09:19 <neofutur> hi I all,I have two questions about building a pacage for alpine
2018-10-27 09:10:03 <neofutur> at the end of the apkbiuild do I need the 3 checksum lines or having just sha512sums is ok ?
2018-10-27 09:11:11 <yangxuan> just sha512sums should be fine
2018-10-27 09:11:24 <neofutur> great ! and second question,I have an APKbuild I made for twine , a python utility , it seems ok and building. could someone check it / try it  ?
2018-10-27 09:14:06 <yangxuan> I treid disable negotiation with this udev rules, but seems not work: ACTION=="change", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -A %k autoneg off"
2018-10-27 09:25:28 <neofutur> [master 9b2abafadb] adding a package for the twine python utility
2018-10-27 09:25:28 <neofutur>  1 file changed, 59 insertions(+)
2018-10-27 09:25:28 <neofutur>  create mode 100644 testing/twine/APKBUILD
2018-10-27 09:25:56 <neofutur> ok I commited ! if anyone could check its ok :)
2018-10-27 09:33:38 <clandmeter> yangxuan, why not use network scripts?
2018-10-27 09:35:55 <yangxuan> which network?
2018-10-27 09:36:04 <yangxuan> which network scripts
2018-10-27 09:36:20 <clandmeter> The default ones
2018-10-27 09:36:42 <clandmeter> pre-up up....
2018-10-27 09:37:26 <clandmeter> https://wiki.debian.org/NetworkConfiguration#Setting_the_speed_and_duplex
2018-10-27 09:40:24 <clandmeter> Our Network scripts are similar to Debian but not the same.
2018-10-27 09:42:47 <yangxuan> finally disable it with create a scripts in /etc/local.d/ , and networkmanager dispatcher script also work
2018-10-27 09:47:50 <yangxuan> anyway, thanks for the link, clandmeter
2018-10-27 10:03:48 <yangxuan> ncopa: the amlogic devices with vendor u-boot need boot script like this: https://github.com/150balbes/Build-Armbian/blob/master/config/bootscripts/boot-aml-s9xxx_ENV.cmd
2018-10-27 10:04:33 <yangxuan> should I package them or put into u-boot package?
2018-10-27 10:09:13 <yangxuan> the vendor u-boot is old, they doesn't support extlinux.conf, although some SBC like odroid c2 support mainline uboot
2018-10-27 10:23:42 <neofutur> errr , since i m doing a twine package,I need the tqdm package,that is in testing
2018-10-27 10:24:03 <neofutur> so I added testing in my repositories,and tried apk add py-tqdm
2018-10-27 10:24:17 <neofutur> got ERROR: unsatisfiable constraints:
2018-10-27 10:24:17 <neofutur>   py3-tqdm-4.19.5-r1:
2018-10-27 10:24:18 <neofutur>     masked in: @testing
2018-10-27 10:24:26 <_ikke_> you added it as a pinned repo
2018-10-27 10:24:39 <_ikke_> so: apk add py3-tqdm@testing
2018-10-27 10:24:46 <neofutur> err yes,just uncommented the line
2018-10-27 10:24:55 <neofutur> ah ok ,@testing !
2018-10-27 10:24:56 <neofutur> thans
2018-10-27 10:40:44 <yangxuan> clandmeter: if the current alpine arm was build by mkimg.arm.sh ?
2018-10-27 10:42:15 <clandmeter> its build be one of those scripts
2018-10-27 10:42:23 <clandmeter> i think what you specify is a profile
2018-10-27 10:42:30 <clandmeter> i think its included
2018-10-27 10:42:45 <clandmeter> not sure, cause i dont use those scripts often.
2018-10-27 10:44:18 <clandmeter> if its not yet on the wiki, it would be nice if somebody added instructions on how to use them.
2018-10-27 10:44:25 <clandmeter> this quesiton has been asked many times.
2018-10-27 10:46:23 <yangxuan> yes, document it should helpful
2018-10-27 10:46:29 <yangxuan> how you build rpi alpine
2018-10-27 10:47:26 <yangxuan> I mean the diskless mode, for class install I have script
2018-10-27 11:07:59 <clandmeter> yangxuan, diskmode is automatic in alpine when you dont specify root=
2018-10-27 11:08:46 <clandmeter> yangxuan, if you want to know more you should take a look at alpine init. it will explain most of the boot process.
2018-10-27 11:10:11 <clandmeter> err i mean diskless mode when no root=
2018-10-27 12:16:15 <neofutur> https://bugs.alpinelinux.org/issues/9507
2018-10-27 12:16:31 <neofutur> I have pacages ready for twine and all deendencies !
2018-10-27 12:16:51 <neofutur> I d better do a pull request on github or a patch ?
2018-10-27 12:17:04 <neofutur> which shouldbe reviewed faster ?
2018-10-27 12:44:16 <neofutur> well Isubmitted a pullrequest ! https://github.com/alpinelinux/aports/pull/5510 ,for https://bugs.alpinelinux.org/issues/9507
2018-10-27 13:39:22 <Myhro> neofutur: Have you read https://github.com/alpinelinux/aports/blob/master/.github/CONTRIBUTING.md ?
2018-10-27 13:41:39 <neofutur> yes
2018-10-27 13:41:58 <neofutur> is there a problem with the pull request ? I missed something ?
2018-10-27 13:42:01 <Myhro> To all: what do you think about using pigz in the "Compressing data..." step of abuild? 'gzip -9' takes ages when dealing with huge packages like the Kubernetes one.
2018-10-27 13:43:35 <Myhro> neofutur: I guess the commits/commit messages can be improved, but I haven't throughly reviewed your PR.
2018-10-27 13:52:24 <TBB> (usual disclaimers here) compression changes is one of the things supposedly planned for the next version of the package format
2018-10-27 13:56:26 <Myhro> TBB: Nice to know. Thanks.
2018-10-27 14:08:24 <TBB> gotta warn you though, that means next major version, so it'll take a while
2018-10-27 14:12:48 <Myhro> Yes, I got it. My question isn't about changing the compression format per se, but adding multithreaded compression, like we have support for multithreaded decompression: https://github.com/alpinelinux/abuild/commit/6fc2f40
2018-10-27 15:25:58 <clandmeter> Myhro, i think a patch is acceptable.
2018-10-27 15:41:35 <Myhro> clandmeter: Great. I'll try it out and send a PR.
2018-10-27 15:42:07 <[[sroracle]]> Myhro: https://code.foxkit.us/adelie/packages/blob/master/system/abuild/use-pigz.patch
2018-10-27 15:47:53 <Myhro> [[sroracle]]: That's even better. Thanks for pointing it out.
2018-10-28 11:53:35 <entrusc> Hi! Is anyone of you guys responsible for building the kernel for the raspberry pi (armhf?)? I wanna build a custom kernel and have some questions.
2018-10-28 11:54:26 <_ikke_> entrusc: Yes, they should be around. You just have to be a bit patient (usually there is more activity during the week)
2018-10-28 11:54:42 <entrusc> I see - thanks ikke!
2018-10-28 12:17:54 <clandmeter> he didnt have much patients...
2018-10-28 12:18:07 <_ikke_> heh
2018-10-28 12:36:17 <brebs> Is github preferred, for sending APKBUILD patches? https://github.com/alpinelinux/aports/pulls  looks nicer than  https://lists.alpinelinux.org/alpine-aports/ , but https://wiki.alpinelinux.org/wiki/Creating_patches and https://wiki.alpinelinux.org/wiki/Patch_Workflow don't mention github.
2018-10-28 12:37:02 <brebs> https://it-offshore.co.uk/code mentions github
2018-10-28 12:37:50 <clandmeter> github is ok
2018-10-28 12:49:00 <Myhro> clandmeter: Hi. I just sent the pigz PR. Is there a test suite for abuild?
2018-10-28 16:03:13 <brebs> What's the criteria for adding the Contributor line to an APKBUILD? Required/recommended for small-ish changes?
2018-10-28 16:04:05 <_ikke_> It's never required
2018-10-28 16:04:21 <_ikke_> git tracks who changed what when
2018-10-29 09:02:30 <PureTryOut[m]> would it be an idea to use `-opengl es2` for `qt5-qtbase` on `arm*` architectures? seems to make more sense than like how it is right now
2018-10-29 10:50:48 <mps> regarding https://bugs.alpinelinux.org/issues/9595, it is not needed because one have to stop setup-linux to manually partition disk and make filesystems. in that case 'apk add whatever' could be used to add whatever is needed
2018-10-29 11:34:16 <rdutra> not related with Alpine, but a big change: https://www.bloomberg.com/news/articles/2018-10-28/ibm-is-said-to-near-deal-to-acquire-software-maker-red-hat?fbclid=IwAR1LA_JE-rgWWzZdnz06PTqxet5sMELQ2clnGLs0L7MsaLxoKiKSoFS9jEw
2018-10-29 11:35:39 <_ikke_> rdutra: I posted that in #alpine-offtopic
2018-10-29 11:36:22 <rdutra> _ikke_: oh did not see.
2018-10-29 11:44:27 <ncopa> its not completely unrelated alpine, considering we have ppc64le and s390x port
2018-10-29 11:45:41 <_ikke_> ncopa: Do you think IBM might no longer sponser these machines because alpine 'competes' with RHEL?
2018-10-29 11:45:55 <andypost_> ncopa, who can review _o flag to fix ppc64 builder? https://github.com/alpinelinux/aports/pull/5514
2018-10-29 11:52:02 <clandmeter> rnalrd, any reason unifi is behind?
2018-10-29 11:53:16 <clandmeter> rnalrd, seems it doesnt want to start on 3.8 due to newer mongodb. i added a hack.
2018-10-29 11:54:53 <ncopa> _ikke_: i have no clue. everything is possible
2018-10-29 11:57:41 <clandmeter> yes, it just takes more time ;-)
2018-10-29 12:03:57 <rnalrd> clandmeter, afaik mongo 3.8 isn't officially supported
2018-10-29 12:04:11 <clandmeter> i know, but it works
2018-10-29 12:04:32 <clandmeter> i didnt bump into anything yet
2018-10-29 12:04:51 <rnalrd> i'm still using 5.6.x LTS and mongo 3.6
2018-10-29 12:05:42 <clandmeter> rnalrd, any reason the current version is holding back?
2018-10-29 12:05:55 <clandmeter> or can i just bump it?
2018-10-29 12:06:01 <rnalrd> nothing, i just didn't care to bump it
2018-10-29 12:06:06 <rnalrd> pls go ahead
2018-10-29 12:06:07 <clandmeter> ok
2018-10-29 12:06:19 <clandmeter> thx
2018-10-29 12:06:25 <rnalrd> 2u
2018-10-29 15:34:55 <ncopa> did someone work on a freeswitch update?
2018-10-29 15:41:31 <clandmeter> ncopa, do we want to ship new lxc with 3.9?
2018-10-29 16:46:39 <ncopa> clandmeter: yes, i think so
2018-10-29 23:46:59 <plymorph> hi
2018-10-29 23:47:34 <polymorph> when will alpine have proper statically linked everything ? ;)
2018-10-29 23:47:52 <polymorph> i read that it now uses musl libc
2018-10-29 23:48:21 <polymorph> https://dl.suckless.org/htmlout/sta.li/
2018-10-29 23:57:38 <Shiz> never
2018-10-30 00:02:45 <polymorph> that is sad
2018-10-30 00:03:08 <polymorph> -i started to like alpine
2018-10-30 00:10:22 <polymorph> asd="ftp://mirror.datacenter.by/pub/DragonFlyBSD/iso-images/dfly-x86_64-5.2.2_REL.img.bz2"; curl -k -L -A "Firefox 69" "$asd" | bzcat | xz -z -9 -e > "`sed -E 's;(.*\.)(|t)bz(|2);\1\2xz;I' <<<"$(basename "$asd")"`";
2018-10-30 08:46:41 <AinNero> ncopa: there are xorg PR's that should be closed
2018-10-30 13:12:23 <Mo0O> hi there
2018-10-30 13:12:35 <Mo0O> do you know how can I clear the root history?
2018-10-30 13:13:36 <AinNero> for the root shell?
2018-10-30 13:13:42 <Mo0O> yes
2018-10-30 13:14:11 <Mo0O> even if I delete /root/.ash_history history still return entries
2018-10-30 13:14:37 <_ikke_> Sure, the history is still in the memory of current shell
2018-10-30 13:15:09 <Mo0O> I've just made a test, and if I relog history is no present
2018-10-30 13:15:15 <Mo0O> sorry for the noise
2018-10-30 13:15:21 <Mo0O> thanks _ikke_ :)
2018-10-30 15:35:22 <pksadiq> ncopa: Hi. Sorry, I accidently inserted space instead of tab for indentation in the commit that merged. I forgot to configure my editor. I shall take care for the next commits. Should I create a patch to fix the indentation?
2018-10-30 15:38:04 <ncopa> pksadiq: nah, dont bother, i can push a fix
2018-10-30 15:38:39 <ncopa> libressl -> openssl migration is somewhat tricky
2018-10-30 15:39:02 <ncopa> ERROR: openssl-1.1.1-r7: trying to overwrite etc/ssl/openssl.cnf owned by libressl2.7-libcrypto-2.7.4-r3.
2018-10-30 15:39:11 <ncopa> and abuild no longer works....
2018-10-30 15:39:39 <ncopa> abuild exits with error if installing the deps fails
2018-10-30 15:39:49 <ncopa> and apk add the deps will fail due to the above problem
2018-10-30 15:40:28 <ncopa> so we need do the correct replaces=... etc on first try
2018-10-30 16:04:55 <mps> anyone can explain why I got "Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)." with 'abuild rootpkg' and I don't use git repo but tarball as source package
2018-10-30 16:44:54 <ncopa> mps: what package are you trying to build?
2018-10-30 16:50:38 <mps> svxlink, http://www.svxlink.org/
2018-10-30 16:51:04 <mps> I made APKBUILD and it compiles
2018-10-30 16:51:36 <mps> I can post APKBUILD to tpaste if you have time to look at it
2018-10-30 16:53:49 <mps> removing -dev subpackage it builds and made apk which I installed
2018-10-30 16:54:39 <mps> but that apk have development files included, which are not needed for production system
2018-10-30 16:55:31 <mps> so, I would like to build -dev package to strip development file for 'base' apk
2018-10-30 16:57:23 <mps> tried to search net about git_discovery error but all I found is related to packages which have git repo
2018-10-30 16:59:41 <mps> anyway, here is my APKBUILD http://tpaste.us/Q1oO
2018-10-30 17:51:35 <mps> ncopa: I think I found the problem about git in svxlink
2018-10-30 17:52:17 <mps> it is in the src/svxlink-17.12.2/src/CMakeLists.txt, 'COMMAND git describe --tags'
2018-10-30 17:53:11 <mps> probably I have to make some workaround for that, yet don't know what but will search about that
2018-10-30 18:01:09 <_ikke_> Anoying when they assume you are in a git repository
2018-10-30 18:03:03 <mps> yes, and they distributed tar releases in the same time
2018-10-30 18:08:20 <ncopa> test if .git directory exists
2018-10-30 18:08:31 <ncopa> :q
2018-10-30 18:09:12 <mps> yes, I found it and now trying to edit CMakeFiles
2018-10-30 18:09:28 <mps> will see :/
2018-10-31 10:22:05 <andypost_> ncopa, https://github.com/alpinelinux/aports/pull/5522 should I try to rm previous ini file or apk will do it for me?
2018-10-31 10:46:39 <ncopa> apk will do it for you, unless the config file is modified by user
2018-10-31 10:46:57 <ncopa> so the PR shoudl be good as is
2018-10-31 10:47:40 <ncopa> clandmeter: ERROR: http://nl.alpinelinux.org/alpine/edge/main: operation timed out
2018-10-31 10:48:29 <clandmeter> works for me
2018-10-31 10:49:07 <ncopa> for me too, but apparently not for travis: https://travis-ci.org/alpinelinux/aports/builds/448775728?utm_source=github_status&utm_medium=notification
2018-10-31 10:49:24 <clandmeter> hmm
2018-10-31 10:49:50 <ncopa> i think i'm gonna replace it with dl-cdn
2018-10-31 10:50:06 <clandmeter> nl is cname of some dlx
2018-10-31 10:53:15 <pksadiq> ncopa: Hi. installing i386/alpine:edge installs version 3.7. See https://github.com/gliderlabs/docker-alpine/blob/master/versions/library-edge/x86/options
2018-10-31 10:55:09 <ncopa> pksadiq: looks wrong. can you please create a ticket on docker-alpine?
2018-10-31 10:55:32 <pksadiq> ncopa: sure. May I do a PR too?
2018-10-31 10:55:45 <ncopa> even better :)
2018-10-31 11:12:36 <pksadiq> ncopa: I made a PR: https://github.com/gliderlabs/docker-alpine/pull/454 I don't necessarily know what I'm doing. :). So if you find it bad, I shall close it and file a bug instead.
2018-10-31 11:15:22 <ncopa> hum...
2018-10-31 11:38:03 <ncopa> pksadiq: i dont think that will work
2018-10-31 11:39:31 <pksadiq> ncopa: hm.. I simply copied it from x86_64. But I see no simple way to test. I think I should better file a bug report.
2018-10-31 11:40:05 <ncopa> the problem is that circleci runs on x86, the other arches does not run on native machine
2018-10-31 11:40:19 <ncopa> so we use the pregenerated minirootfs tarball release
2018-10-31 11:40:37 <_ikke_> ncopa: awall, in a filter section, can "in" have an array of zones?
2018-10-31 11:41:02 <ncopa> i think the proper longterm solution is to make everything use minirootfs tarball and tag releases from git master (eg edge)
2018-10-31 11:41:07 <ncopa> _ikke_: i dont know
2018-10-31 11:41:25 <_ikke_> k
2018-10-31 11:42:44 <pksadiq> ncopa: http://dl-cdn.alpinelinux.org/alpine/edge/releases/x86/ doesn't have a minirootfs image for edge.
2018-10-31 11:43:00 <ncopa> that is the problem we need to solve
2018-10-31 11:43:52 <ncopa> currently, release tarballs are generated automatically when we push a git tag
2018-10-31 11:44:33 <ncopa> but we dont want generate all release images (iso images etc) from edge
2018-10-31 11:44:55 <ncopa> so we need figure out exactly what we generate release of for edge
2018-10-31 11:45:02 <ncopa> minirootfs is one
2018-10-31 11:45:10 <ncopa> but do we want generate alpine-standard.iso?
2018-10-31 11:45:14 <ncopa> or alpine-virt.iso?
2018-10-31 11:45:33 <ncopa> i think we probably dont want
2018-10-31 11:46:47 <pksadiq> I think we need only minirootfs, so far the docker is concerned
2018-10-31 11:53:51 <pksadiq> ncopa: I changed /etc/apk/repositories to point edge. That's enough for me. I shall be hanging around to fix gtk+ things, until I lose interest. :)
2018-10-31 13:33:42 <kunkku> question on packaging: lua-penlight does not have Lua version-dependent subpackages but should depend on lua-filesystem which has. How should this be handled?
2018-10-31 15:43:07 <ncopa> kunkku: it was handled before b106a06b4e1fbaf82a3def3cf620e81e9fe63292. i suggest that you write an email to jirutka with cc alpine-devel with that question
2018-10-31 15:54:54 <ncopa> did dl-cdn.alpinelinux.org just die?
2018-10-31 15:57:54 <_ikke_> seems to be working for me
2018-10-31 15:57:59 <_ikke_> http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/
2018-10-31 15:59:12 <clandmeter> works here, but could depend on which server you are locked in.
2018-10-31 16:06:23 <_ikke_> fastly does not report any 5xx errors
2018-10-31 16:08:49 <ncopa> it times out from my packet.net container
2018-10-31 16:09:56 <sadiq[m]> When I build gtk+3.0 (for example) with 'abuild -r' I see a lot of lines with ">>> WARNING: gtk+3.0-dev*: at-spi2-atk-dev should be removed from depends_dev". Are those just hints, or is safe to do so (ie, remove them from depends_dev)?
2018-10-31 16:10:34 <ncopa> its normally safe to remove them from depends_dev
2018-10-31 16:11:56 <ncopa> ncopa-edge-x86_64:~$ wget http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
2018-10-31 16:11:56 <ncopa> Connecting to dl-cdn.alpinelinux.org (151.101.36.249:80)
2018-10-31 16:11:59 <ncopa> times out
2018-10-31 17:00:38 <ncopa> hum, openntpd wants to use libtls but explicitly checks for -ltls
2018-10-31 17:05:29 <leo-unglaub1> ncopa, is the libtls usage of openntpd a problem?
2018-10-31 17:20:56 <ncopa> leo-unglaub1: not really, just need some time to patch it to accept libtls-standalone
2018-10-31 17:21:16 <ncopa> alternatively we can simply disable the libtls support
2018-10-31 17:21:21 <ncopa> it seems to build fine without libtls
2018-10-31 17:21:32 <ncopa> but i suppose we want it
2018-10-31 17:21:41 <leo-unglaub1> i would highly recommend against disabeling libtls
2018-10-31 17:21:52 <ncopa> thats what i thought :)
2018-10-31 17:22:11 <ncopa> worstcase, we link it against libressl
2018-10-31 17:22:43 <leo-unglaub1> openntpd uses a https connection to some https sites in order to verify if the time is actually correct and that no attack is currently running with that server
2018-10-31 17:22:48 <leo-unglaub1> so it is pretty usefull
2018-10-31 17:22:55 <ncopa> understand
2018-10-31 18:36:49 <ncopa> $ git rev-list origin/master.. | wc -l
2018-10-31 18:36:49 <ncopa> 163
2018-10-31 18:37:04 <ncopa> 163 commits in my queue for the openssl 1.1 stuff
2018-10-31 18:37:10 <ncopa> this is only main repo
2018-10-31 20:50:36 <PureTryOut[m]> has something changed in abuild's -dev split function? I have 2 packages now where their cmake files have moved from the -dev subpackage to the base package