2019-09-01 00:04:16 Got lots of PRs for main ready to go https://github.com/alpinelinux/aports/pulls?q=is%3Apr+is%3Aopen+label%3AS-ready 2019-09-01 09:17:01 maxice8: any particular reason why you started replacing $pkgname in $source? 2019-09-01 09:17:21 saw this in a few PR's 2019-09-01 09:28:24 nmeum: can't find the docs for that just now, but pkgname doesn't change often (or at all) during a package's lifetime so just using the pkgname directly is clearer and easier to paste 2019-09-01 09:28:26 nmeum: iirc, this was ncopa advice 2019-09-01 09:28:48 And we have lots of places where we need to write it out anyway (e.g. when doing py3-pkgname) 2019-09-01 09:29:36 sure, but would be nice to document it somewhere (e.g. in CODINGSTYLE.md) then 2019-09-01 09:29:46 otherwise the next PR will just change it again 2019-09-01 09:29:49 personally I would like to keep $pkgname, and replace it with literal string only where it needed 2019-09-01 09:30:15 I don't really care as long as it is consistent 2019-09-01 09:32:14 Using $pkgname in source ties the alpine name for the package to the upstream name, making it more work for people creating custom packages. 2019-09-01 09:32:40 There is an entry on alint from atools-doc, AL29 pkgname_used_in_source 2019-09-01 09:35:03 maybe is best to left to maintainer to decide, IDK 2019-09-01 09:36:49 nmeum: pretty sure we already noted it down in the currently WIP docbook thingie 2019-09-01 09:53:57 nmeum: reviewed your hy thingy 2019-09-01 10:00:32 in last 6 months I see increasing mess in aports (will not elaborate) and we need some rules about changes in APKBUILD, imo 2019-09-01 10:01:33 Cogitri: as you are here, trying to build firefox-esr on armv7 I got this ' ^^^^^^^^^^ maybe a missing `extern crate simd_funcs;`?; 2019-09-01 10:02:13 Ah, add `--disable-rust-simd` to configure's cmdline 2019-09-01 10:02:18 (or smth like that) 2019-09-01 10:03:28 aha, ok 2019-09-01 10:03:59 I guess they don't have simd for all arches yet 2019-09-01 10:04:27 obviously ;-) 2019-09-01 10:36:53 maxice8: thanks, just quickly hacked it to together not sure if I actually want to maintain hy in the long run 2019-09-01 10:37:08 Cogitri: oh great, do you have a link? 2019-09-01 10:48:46 nmeum: oh 2019-09-01 10:50:00 the feedback is useful though :) 2019-09-01 10:51:57 yes 2019-09-01 11:02:02 nmeum: Can't find it right now and currently am on the go. I'll look for it later, but maybe SpaceToast knows where it is? 2019-09-01 13:11:04 PureTryOut: [ foo || bar ] doesn't exist in shell 2019-09-01 13:11:15 you're looking for [ foo ] || [ bar ] (discover patch) 2019-09-01 13:14:26 Oh, interesting. It didn't complain about it, I'll change it 2019-09-01 13:14:34 It did 2019-09-01 13:14:40 it just went along with the failure 2019-09-01 13:14:58 That's... A weird behaviour 2019-09-01 13:15:30 Oh you've already merged it 2019-09-01 13:15:37 Well, my v2 patch can be ignored then lol 2019-09-01 13:15:44 Thanks for the quick response! 2019-09-01 13:15:54 ash: missing ] 2019-09-01 13:15:57 the error ^ 2019-09-01 14:29:44 What's the plan for updating gcc ? 2019-09-01 14:43:27 iirc, ncopa is working on that 2019-09-01 16:21:40 pr10671 2019-09-01 16:23:24 we reached to fifty MR's on gitlab.a.o ;-) !50 2019-09-01 16:24:07 mps: nice :D can't wait to switch to it fulltime 2019-09-01 16:24:41 we have to wait for ikke to finish CI 2019-09-01 16:24:56 I am waiting 2019-09-01 16:25:11 also I :) 2019-09-01 16:25:29 you're already using gitlab MRs 2019-09-01 16:26:09 yes, have temptation to merge one from SpaceToast but not sure is ok 2019-09-01 16:26:18 which one ? 2019-09-01 16:26:33 moment 2019-09-01 16:27:03 !44 2019-09-01 16:27:34 already merged 2019-09-01 16:27:53 and not closed? 2019-09-01 16:28:00 i don't have permission to close 2019-09-01 16:28:36 oh, I will check later to see if I can 2019-09-01 16:30:17 I noticed that some of mine are merged but not sure who have to close them, one who post it or who merged it 2019-09-01 16:30:49 (mine or my?) 2019-09-01 16:43:49 maxice8: looks like I only can close those I created, not from other people 2019-09-01 16:55:43 mps: If I got `relocations in generic ELF (EM: 40)` errors, that means the bindings are likely wrong? 2019-09-01 17:14:56 <_ikke_> Once I'm back, I'll try to get gitlab ci in tip-top shape 2019-09-01 17:19:17 Nice 2019-09-01 17:54:38 j8r: you are using some cross build environment? 2019-09-01 18:13:58 mps: not really. I am build on x86-64, with a newly compiled compiler, with the same vars as in your Makefile 2019-09-01 18:16:32 that wouldn't be possible. You need linker for target arch 2019-09-01 18:16:46 and compiler 2019-09-01 18:17:38 ho, ok, I'am a noob for this 2019-09-01 18:17:45 I'm trying to make cross compiler for alpine, but that will take time 2019-09-01 18:18:46 and will depend on my free time from $day_job 2019-09-01 18:19:45 but I think it is time for alpine to get at least basic cross build tools 2019-09-01 18:20:54 Crossbuilding isn't as easy as making the base tooling available 2019-09-01 18:21:10 On Void we had to spend lots of time fixing crossbuilding 2019-09-01 18:21:16 ACTION looks at gobject-introspection 2019-09-01 18:23:00 And lots of stuff just assumes that it's compiled natively 2019-09-01 18:24:33 Cogitri: I don't mean full cross build system. Just something to make some simple to build software 2019-09-01 18:25:02 and yes, 'real' cross build is not so simple 2019-09-01 19:19:53 j8r: can we instruct crystal static on aarch64 to build next version and set target to arm-linux-musleabihf 2019-09-01 21:10:58 mps: not sure what you mean. You can build the new compiler with the old one, the cross compiling, That's what I've done 2019-09-01 21:17:20 not sure, TBH. thought it would be possible to tell crystal to cross build itself 2019-09-01 21:31:56 *then cross compiling I meant 2019-09-01 21:45:06 aha, ok. will see if can make cross build environment first 2019-09-01 21:55:45 don't know how jirutka did for aarch64 2019-09-01 21:57:27 looks like crystal is ported to aarch64 only on alpine? 2019-09-01 22:07:12 there is also src/lib_c/aarch64-linux-gnu 2019-09-01 22:07:30 don't know if it works 2019-09-02 00:04:30 Can someone merge https://lists.alpinelinux.org/~alpine/aports/patches/2955 ? 2019-09-02 00:04:33 needs to fix py-ans1-modules 2019-09-02 09:13:50 ^ yep, can confirm, current py-asn1-modules need py-asn1 version higher than 0.4.5 or application like "deluge" wont even start 2019-09-02 10:29:09 first time I see this 'ERROR: Unable to open root: No such file or directory' 'abuild -r' community/firefox-esr 2019-09-02 10:29:50 anyone have idea what can be cause of this error 2019-09-02 11:08:50 ... glitch in the matrix :P 2019-09-02 11:09:30 mps, when you got that error? :D 2019-09-02 11:12:07 MY-R: at the end, when abuild tries to make apk 2019-09-02 11:12:28 but running 'abuild rootpkg' succeed 2019-09-02 11:20:06 mps, :\ 2019-09-02 11:20:19 maybe not enough space? 2019-09-02 11:21:57 using 'ash' as shell or something different? 2019-09-02 11:24:12 I thought it could be space, but 'df' shows 95GB available 2019-09-02 12:26:51 maxice8: I see you packaged appstream, does it actually work with apk? 2019-09-02 18:41:14 anyone building programs with rust on armv7 have memory issues during build 2019-09-02 18:44:01 Yes, it SIGSEVs occasionally 2019-09-02 18:46:19 for me it SIGABRT constantly building firefox-esr http://tpaste.us/Q1VE 2019-09-02 18:47:10 `LLVM ERROR: out of memory` seems like a likely cause 2019-09-02 18:48:20 'free' => Mem: 131760984 1359064 84097336 1824 46304584 129112948 2019-09-02 18:48:50 how it can be out of memory on this machine 2019-09-02 18:49:05 Well, maybe it needs to allocate more than 4 gigs of RAM per process 2019-09-02 18:49:17 Which it can't do on 32-bit arches 2019-09-02 18:49:52 right, didn't thought about that 2019-09-02 18:51:36 so, no firefox on arm for now 2019-09-02 18:52:43 Maybe you can turn down the opt level or disable LTO to make it work? 2019-09-02 18:55:27 disable or thin? 2019-09-02 18:56:02 '--enable-lto={full,thin,cross}' 2019-09-02 18:56:23 Dunno what's enabled by default by ff 2019-09-02 18:56:35 But I guess you could try with thin before disabling it 2019-09-02 18:56:51 makes sense, thanks for hint 2019-09-02 18:57:03 lets try with thin 2019-09-02 20:17:51 Cogitri: no luck with '--enable-lto=thin' nor '--disable-lto' :( => 'out of memory' 2019-09-03 05:45:52 morning 2019-09-03 05:45:59 morning 2019-09-03 05:46:15 been moving to new apartment, thats why i have been much away lately 2019-09-03 05:46:21 oh 2019-09-03 05:46:49 more work with that than anticipated 2019-09-03 05:47:39 anything i should prioritize? 2019-09-03 05:48:46 except get coffe and breakfast... 2019-09-03 05:51:12 There are some PRs with t-security and s-ready :D 2019-09-03 07:08:35 ACTION good morning everyone 2019-09-03 07:34:05 ncopa: did you looked at MR's for XFRM and cpu NR for kernel for x86 2019-09-03 07:41:59 not if they are new 2019-09-03 07:46:09 they are related to two issue/feature requests 2019-09-03 07:47:48 !50 2019-09-03 07:48:09 !32 2019-09-03 07:58:05 mps: i'm increasing NR_CPUS to 128 for 32bit x86 and to 256 for x86_64 2019-09-03 07:59:14 to much, imo. :D 2019-09-03 08:00:05 we already have 256 on vanilla x86_64 2019-09-03 08:00:42 i think it makes sense to have the same for virt 2019-09-03 08:00:51 and for 32 bit i guess half is ok 2019-09-03 08:00:58 that was my thinking 2019-09-03 08:01:06 no, I'm kidding, I had same temptation but didn't wanted in 'first step' 2019-09-03 08:01:47 aarch64 has 4096 2019-09-03 08:02:24 notice ':D' in previous msg 2019-09-03 08:02:48 difficult to read sarcasm on irc :) 2019-09-03 08:03:34 ah, we have to be deadly serious 2019-09-03 08:05:53 anyway, we will have to examine and maybe test these kernel parameters more deeply in next few months 2019-09-03 08:17:53 tmhoang: there is something nasty going on with git and s390x 2019-09-03 08:19:07 my bad 2019-09-03 08:19:12 looks normal now 2019-09-03 08:21:54 except that apr testsuite hanged 2019-09-03 08:51:15 trying to build firefox-esr on aarch64 with 'abuild -r' I got this error http://tpaste.us/W1XN 2019-09-03 08:51:36 using 'abuild rootpkg' it works 2019-09-03 08:52:05 anyone have idea what could be problem? 2019-09-03 09:36:00 huh 2019-09-03 09:36:59 sounds like a bug in abuild 2019-09-03 09:38:45 build of other packages works normally 2019-09-03 09:39:22 <_ikke_> Something in the apkbuild? 2019-09-03 09:39:41 although smaller ones, didn't tried any bigger in last week or so 2019-09-03 09:41:15 _ikke_: \o 2019-09-03 09:42:45 abuild is 3.4.0-r1 2019-09-03 09:45:51 i had some similar issue the other week 2019-09-03 09:46:05 abuild rootpkg worked but not `abuild -r` 2019-09-03 09:46:09 i dont remember which package it was 2019-09-03 09:46:20 or which arch 2019-09-03 09:47:16 tmhoang: looks like apr testsuite hangs on s390x 2019-09-03 09:47:23 testproc : SUCCESS 2019-09-03 09:47:23 testprocmutex : | 2019-09-03 09:48:04 I already looked to abuild script in hope to spot something but didn't noticed anything, although i'm not good at shell scripting 2019-09-03 09:49:46 strace: Process 8449 attached 2019-09-03 09:49:46 semtimedop(163840, [{0, -1, SEM_UNDO}], 1, NULL 2019-09-03 09:52:20 maxice8: I see you packaged appstream, does it actually work with apk? 2019-09-03 10:56:10 tmhoang: teh testprocmutex hangs on s390x on sysv semaphore locking mechanism 2019-09-03 10:56:38 wow what is testprocmutex 2019-09-03 10:56:55 ah apr 2019-09-03 10:56:56 its a test in testsuite for apr 2019-09-03 10:57:08 it seems it has been recently introduced, was fine with 3.10 2019-09-03 10:57:12 looking 2019-09-03 10:57:24 yes, i happens afteer the aprl upgrade to 1.7.0 2019-09-03 10:57:51 i dont know if it is due to musl upgrade, or if they changed/broke anything in apr 2019-09-03 10:58:03 or if test is broken 2019-09-03 10:58:08 ok I will have a look, it was on my todo list ... 2019-09-03 10:58:19 test has not changed last two years 2019-09-03 10:58:31 but it may have been broken all the time 2019-09-03 10:58:45 im not that deep into sys v semaphores 2019-09-03 10:59:02 but is seems there are some implementation details when you fork 2019-09-03 10:59:53 me neither, can't do now sorry. will try this week L* 2019-09-03 10:59:54 :( 2019-09-03 11:17:30 ok. im adding a patch that works around the problem 2019-09-03 13:23:29 Need pr10671 merged 2019-09-03 14:02:48 maxice8: I see you packaged appstream, does it actually work with apk? 2019-09-03 15:45:02 maxice8 ? 2019-09-03 17:48:39 maxice8: you've made https://git.alpinelinux.org/aports/tree/main/mesa/add-glx-use-tls.patch. Is it being upstreamed? 2019-09-03 21:02:38 PR for poppler-080 pr10593 2019-09-03 21:12:04 PureTryOut: I doubt that mesa patch will make it upstream, IIRC comes along with a performance penalty of about 30% 2019-09-03 21:13:16 Oh damn, that is quite big. Why is it needed? 2019-09-04 06:48:36 PureTryOut: Well because it doesn't build with that option enabled on musl, so I guess it'd be best to properly fix it instead of just disabling that part if we want to upstream that 2019-09-04 08:16:09 Ah clear answer, thanks 2019-09-04 11:33:09 :D ruby has been updated 2019-09-04 11:34:02 i didnt verify that everythign needed was rebuilt 2019-09-04 11:35:21 isn't it just a matter of rebuilding ruby-* ? 2019-09-04 11:35:47 could be some package that builds ruby module 2019-09-04 11:35:59 could be some package linking to libruby.so or similar 2019-09-04 11:36:02 i havent checkec those 2019-09-04 11:36:11 :D better rebuild everything that has ruby-dev ? 2019-09-04 11:36:21 possibly yes 2019-09-04 11:36:39 but i havent checked if something indirectly pulls in ruby-dev 2019-09-04 11:37:35 im updating perl to 5.30 2019-09-04 11:37:47 good luck 2019-09-04 13:05:51 fcolista: i dont think b2b52a99c79da5dd37fc82e9a01f3473b15eb029 was intentional? 2019-09-04 13:08:28 ncopa, not at all 2019-09-04 13:08:30 :-/ 2019-09-04 13:08:36 sorry /0\ 2019-09-04 13:09:38 np 2019-09-04 13:09:46 i'm bumping it with the perl 5.30 upgrade 2019-09-04 13:14:54 k thx 2019-09-04 17:10:40 ncopa: are you here? I have no one except you to annoy. !47 2019-09-04 17:11:01 I need it pushed to upgrade iwd 2019-09-04 21:11:30 is there any guide how to install arm image of alpine linux in qemu? 2019-09-04 21:16:44 afaik, only that I already posted link to you 2019-09-04 21:56:04 5th hit on google 2019-09-04 21:56:40 "qemu aarch64 alpine" gives some info 2019-09-04 22:12:32 artok: oh, I can go to 1st RSN :D 2019-09-05 08:41:56 ncopa: morning 2019-09-05 08:44:19 <_ikke_> Apparently CVE's in the upcoming curl release (7.66.0) 2019-09-05 08:46:04 !43 !42 2019-09-05 08:46:52 morning 2019-09-05 10:12:51 fcolista: you maintain i2c-tools, is there a chance you could move it to community before Alpine 3.11? 2019-09-05 10:14:10 im working on perl 5.30, and will likely push it today 2019-09-05 10:14:50 PureTryOut[m]: I already had temptation to move it 2019-09-05 10:15:06 ncopa: nice 2019-09-05 10:15:25 Ah good 2019-09-05 10:16:03 but, yes, I prefer to ask maintainer first 2019-09-05 10:16:12 fcolista: ^ 2019-09-05 10:18:47 Definitely 😉 2019-09-05 10:18:52 I might send him an email 2019-09-05 10:19:34 I think he will answer here when he see our msgs 2019-09-05 10:19:59 no need to hurry 2019-09-05 10:20:33 Yeah I'll wait for a bit 2019-09-05 10:20:48 he is very responsive, and kind person 2019-09-05 10:21:13 Most people here are quite responsive and kind ime 2019-09-05 10:23:35 PureTryOut[m]: how long you are on this channel 2019-09-05 10:24:17 (rhetorical question, no need to answer ;-) ) 2019-09-05 10:24:26 Year and a half or so? I'm not certain 2019-09-05 10:28:08 why don't we build libtinfo from ncurses, any reasons for it or against 2019-09-05 11:03:22 mps: it is built as part of libncurses 2019-09-05 11:05:25 yes, I know. my question is why we don't build it as separate lib 2019-09-05 11:19:56 Problably how it was always done 2019-09-05 11:27:11 pr10860 important ncopa 2019-09-05 11:27:53 maxice8: inertia 2019-09-05 12:33:39 im almost done with perl 5.30 2019-09-05 12:33:49 apache2 mod_perl is broken though 2019-09-05 12:34:02 apparently it crashes in libperl.so 2019-09-05 12:34:47 i dont know if i should disable apach2-mod-perl for now, or spend more time trying to fix it 2019-09-05 14:47:00 who should close applied MR's, commiter or author, or any of them or even anyone? 2019-09-05 14:47:32 Whoever can close it when it is applicable imo 2019-09-05 14:48:19 should we add note or just simply close 2019-09-05 14:48:59 ideally the algitbot does it like it does for GitHub 2019-09-05 14:49:19 yes, but it still doesn't 2019-09-05 15:41:29 ping fcolista - there's some serious regression in lxd 3.16 2019-09-05 15:41:39 I'm guessing it's their "new NIC logic" being horribly broken 2019-09-05 15:42:16 tl;dr it'll create vethN, which will get assigned a pair veth$BLOB_A, but it'll try to manipulate veth$BLOB_B for some reason, and fail with "no such device" 2019-09-05 15:48:24 5 pages of commits rebuilding perl stuff :D 2019-09-05 15:49:34 perlfect! 2019-09-05 15:49:58 wait, wait ... there will be more pages :) 2019-09-05 15:51:05 builders gonna burn! 2019-09-05 15:52:02 hehe, and people says that perl is dying ;-) 2019-09-05 16:03:53 How does Alpine handle perl modules in perl itself ? Arch and Void has a script to generate a provides="" for each module inside perl itself 2019-09-05 16:57:32 looking at build.a.o looks like 32bit machines are faster than their 64bit cousins 2019-09-05 18:30:06 mps: same machine :) 2019-09-05 18:30:46 no, I'm looking at build.a.o aports built column 2019-09-05 18:31:11 you mean x86 or arm? 2019-09-05 18:31:30 both 2019-09-05 18:31:45 x86 does 32 and 64bit 2019-09-05 18:31:54 afaik 2019-09-05 18:31:58 aha, x86 and x86_64 builders are on same machine 2019-09-05 18:32:04 arm is different 2019-09-05 18:32:09 that explains 2019-09-05 18:32:24 the thunderx is slower but has more cores 2019-09-05 18:32:45 I see, thanks 2019-09-05 18:32:49 and i think for perl it does a lot of single thread processing 2019-09-05 18:33:04 like with some autotools projects 2019-09-05 18:33:17 it runs configure for 10 minutes and make for 1 2019-09-05 18:33:22 yes, yes, now I understand 2019-09-05 18:53:16 <_ikke_> X86 and x86_64 are different machines 2019-09-05 18:53:25 <_ikke_> bld1 and bld2 2019-09-05 19:59:26 anyone looked at abuild issue I posted here few days ago? 2019-09-05 20:23:08 mps, maybe you could open a issue and describe it little more, machine/arch etc stuff so would be easier to try reproduce it? :\ 2019-09-05 20:24:31 cus you talking about that error with firefox, right? 2019-09-05 20:27:57 MY-R: yes, only have this issue with firefox-esr on aarch64, and I doubt someone can reproduce it 2019-09-05 20:32:13 mps, still, would be cool to "document it" ps what board? 2019-09-05 20:34:02 it is some of alpine infrastructure machines, and I run build in lxc 2019-09-05 20:35:01 APKBUILD is tweaked to enable firefox-esr build on aarch64 2019-09-05 20:35:32 non-standard to reproduce easily 2019-09-05 20:36:29 oh :\ 2019-09-05 20:38:25 or something going on with builders, last time they didnt work, right? :D 2019-09-05 20:39:32 something really strange to me, but have no idea what could be 2019-09-05 20:40:03 abuild is not much from previous version when build worked 2019-09-06 06:28:42 _ikke_: but are they not identical? 2019-09-06 06:31:54 <_ikke_> Yes, they should be indeed 2019-09-06 06:53:33 clandmeter: should clamav 0.101.4 be backported to 3.10, what you (maintainer) think? !48 2019-09-06 06:54:29 I made it and it run for one of my customers about week ago 2019-09-06 07:24:11 mps: not sure, what does it fix? 2019-09-06 07:24:18 test unit? 2019-09-06 07:25:13 yes, it is fixed 2019-09-06 07:25:49 mps: elaborate? 2019-09-06 07:26:08 but we have 0.100.3 (so 0.100.x) which is released more than a year ago in stable 2019-09-06 07:26:34 what is a test unit? 2019-09-06 07:26:36 it is outdated 2019-09-06 07:26:53 its when pkg is build or when its run? 2019-09-06 07:27:31 it was bug in --debug option for librar 2019-09-06 07:27:53 single line fix 2019-09-06 07:29:01 i dont understand the problem, so i cannot give you an answer. 2019-09-06 07:29:19 we will have to care about it for a two years in future, and I think it would be easier to care of the upgraded version than to old 2019-09-06 07:30:19 it was not upgraded for latest stable because of this bug which is now fixed 2019-09-06 07:32:05 and upgraded version is already in edge 2019-09-06 07:32:28 so the current version in stable has an issue? 2019-09-06 07:32:49 no, it works but it is outdated 2019-09-06 07:33:34 and for software intended to secure something is not good to be outdated too much, imo 2019-09-06 07:34:10 thats why we have new alpine releases 2019-09-06 07:34:19 and we backport fixes 2019-09-06 07:34:42 and in some special cases we do different things. 2019-09-06 07:34:55 yes, I know 2019-09-06 07:35:35 but for this case, whenever clamav runs it tells users that it is outdated and they should be upgraded 2019-09-06 07:35:43 if you think this is special you need to explain why so somebody with access to main can understand and apply if needed. 2019-09-06 07:35:51 yes some software does that. 2019-09-06 07:35:56 clamav is not the only one 2019-09-06 07:36:52 so you think the benefit outweighs the risk of bringing a new version to stable with possible new bugs? 2019-09-06 07:36:53 I presume users will ask or fill issues about that 2019-09-06 07:37:32 we always risks new bugs with upgrades 2019-09-06 07:40:57 at the end maybe I can't explain it very well, but my opinion we should upgrade it because we didn't upgrade it for latest stable because of mentioned bug for test units 2019-09-06 07:41:23 ok sounds fair 2019-09-06 07:41:27 lets do it :) 2019-09-06 07:43:42 I don't want to force it, because that I asked for your opinion 2019-09-06 08:18:03 mps: your update is broken 2019-09-06 08:20:00 oh, ok. then forget it 2019-09-06 08:21:08 and sorry for taking your time 2019-09-06 08:22:57 hmm its not your update 2019-09-06 08:23:57 ? 2019-09-06 08:24:34 ncopa did it 2019-09-06 08:25:25 morning 2019-09-06 08:25:29 what did i do now? 2019-09-06 08:25:48 heh, i knew you would say that same sentence :) 2019-09-06 08:26:56 nah its non of you, im sure if i look far back enough ill end up with myself. 2019-09-06 08:27:35 I don't see anything wrong in git log for last year, so I'm blind ;) 2019-09-06 08:27:55 build is ok, packaging is broken 2019-09-06 08:28:56 ehm, will be happy is this pkg only one which packaging is broken in alpine :D 2019-09-06 08:29:31 libs is executed before clamav-libunrar 2019-09-06 08:29:42 so it moves the unrar lib to libs 2019-09-06 08:29:46 making libunrar empty 2019-09-06 08:30:42 ncopa removed the libs function, but its similar to what abuild does. 2019-09-06 08:30:48 i guess it has been like this for ages 2019-09-06 08:30:48 ah, right 2019-09-06 08:35:53 pushed including the libunrar fix 2019-09-06 08:36:38 i wonder if this fix will break some ppl setup 2019-09-06 08:37:32 I will test it later to see 2019-09-06 08:37:52 now you need to explicitly install libunrar subpgk 2019-09-06 08:38:04 before it would be pulled in with libs pkg 2019-09-06 08:39:26 no, clamav-libunrar is not pulled 2019-09-06 08:39:45 ah, you mean now 2019-09-06 08:40:37 ACTION better to first test and then speak 2019-09-06 08:40:53 if you have libunrar in world you should be fine 2019-09-06 08:41:37 yes, but I don't have it installed explicitly 2019-09-06 08:41:55 then libunrar will not be available 2019-09-06 08:42:28 will wait for in on mirror and check 2019-09-06 08:43:25 and, why separate clamav-libunrar pkg? licence issue? 2019-09-06 08:43:49 thats our policy 2019-09-06 08:43:55 keep main pkg small as possible 2019-09-06 08:44:03 let user choose what to install 2019-09-06 08:47:14 nice, I like this, especially if it will be written in some official document 2019-09-06 08:47:38 always disliked debian 'dependency hell' 2019-09-06 08:47:44 its something for the official docs 2019-09-06 08:55:04 added this to notes if we ever start to discuss policy docs 2019-09-06 08:56:17 mps: you can find this policy in almost every pkg. 2019-09-06 08:56:45 if applicable ofc. 2019-09-06 08:58:10 in vim, too? 2019-09-06 09:04:20 back to work, clamav upgrade doesn't pull clamav-libunrar 2019-09-06 09:04:57 need to remember if someone fill issue or ask on irc/ML 2019-09-06 09:08:06 mps: https://pkgs.alpinelinux.org/package/edge/main/x86_64/vim 2019-09-06 09:08:19 check subpkgs (right colomn) 2019-09-06 09:11:08 I remember, I made last fixes about vimdiff and gvim there 2019-09-06 09:12:27 and proposed split it further on alpine-devel ML few months (maybe 6) ago but didn't got any response 2019-09-06 14:26:44 heyyy 2019-09-06 14:26:54 ncopa: here? 2019-09-06 14:27:13 hi 2019-09-06 14:27:16 im here 2019-09-06 14:27:19 3 mins more 2019-09-06 14:28:00 ncurses worked on builders? I'm getting some error on downloading that... 2019-09-06 14:29:32 something like _ver=${pkgver/_p/-} is not working properly.. I'll launch builder again... 2019-09-06 14:29:53 but if you're in hurry, just go and I'll check it and report 2019-09-06 14:33:18 note that that is a bash extension, which is supported in busybox ash 2019-09-06 14:54:28 filoozom: happy rpi4 aarch64 user? 2019-09-06 14:55:18 artok: what kernel you use 2019-09-06 14:55:48 nothing at the moment, just going to build kernel for rpi 2019-09-06 14:58:00 yesterday I looked on some arm64 kernels and looks like it could be possible to use some of multi platform kernels 2019-09-06 15:08:05 hmm 2019-09-06 15:08:22 links? 2019-09-06 15:11:56 arch linux alarm git repo, don't have url right now 2019-09-06 15:14:51 https://github.com/archlinuxarm/PKGBUILDs.git 2019-09-06 15:15:50 i've seen in aarch64 config rpi4 enabled 2019-09-06 15:19:30 just found that. 2019-09-06 15:46:48 no way to build firefox-esr on armv7, 4GB address space is limit :/ 2019-09-06 15:50:49 You can cross-compile 2019-09-06 15:51:22 on alpine? 2019-09-06 16:19:16 scripts/bootstrap.sh does thingies 2019-09-06 16:21:33 and that will work on alpine builders? 2019-09-06 16:30:49 mps haven't really tested now, but afaik =) 2019-09-06 16:31:22 oh damn that ncurses was updated 2 days ago.. my repo was lagging behind 2019-09-06 16:32:21 you don't miss too much with this update, I'm on ncurses ML, just small fixes 2019-09-06 16:33:00 I finally just hit abuild -R on linux-rpi with filoozom edits 2019-09-06 17:34:20 did we have "skip tests" flag on abuild? 2019-09-06 17:34:43 no 2019-09-06 17:35:48 once in a while that would be ok, even that is not good practice 2019-09-06 17:35:48 artok: yes => options="!check" 2019-09-06 17:40:54 yeah on APKBUILD that is, but globally ignoring check 2019-09-06 17:45:16 ah, then as maxice8 told 2019-09-06 17:46:37 but you can 'abuild deps unpack prepare build rootpkg' to skip check 2019-09-06 17:46:57 and clean and undeps at the end 2019-09-06 17:47:27 oh true, 2019-09-06 17:48:14 I do right this sometimes, and repeating some steps 'abuild stepxx' 2019-09-06 17:53:21 oh well, amazon is just taking my money on the instance, nothing more =D 2019-09-07 08:06:52 Getting 'ERROR: Metadata for package keepassxc-doc-2.4.3-r1 is too long.' when building keepassxc 2019-09-07 09:11:40 oh well 2019-09-07 09:11:45 license was too long 2019-09-07 09:16:55 libaio gives 404 on source fetch, https://hastebin.com/simuzaxate.bash ought to do it 2019-09-07 14:31:53 maxice8: sorry for nitpicking again, but isn't proper word 'remove' instead of 'drop' 2019-09-07 14:32:17 i wanted to put execute but i felt it was too charged 2019-09-07 14:32:26 :D 2019-09-07 14:32:30 also has other meanings 2019-09-07 14:33:07 ok, I understand all of them 2019-09-07 14:33:13 well i was using limit and some wanted me to use disable instead 2019-09-07 14:33:30 if some feel like i should use remove or delete instead of drop then they can just ask, happy to comply 2019-09-07 14:33:35 I was that 'some' 2019-09-07 14:34:00 i have no memory of who asked me just that some people asked me 2019-09-07 14:34:14 we should follow established rules, although most of them are not written in policy 2019-09-07 14:35:04 not only I asked, some other people also told that the 'limit' is not correct 2019-09-07 14:35:28 PS: i'll continue to use drop py2 instead of remove py2, drop -> remove only applies to when i execute a package 2019-09-07 14:36:03 ok, however you want, I just wasn't sure 2019-09-07 14:36:34 btw, I see you work a lot to make python in better shape 2019-09-07 14:37:25 Today is holiday :D 2019-09-07 14:37:48 happy holiday to you :) 2019-09-07 14:42:42 thank you :) 2019-09-07 19:31:05 maxice8: `/usr/include/lttng/tracepoint.h:39:10: fatal error: 'sys/sdt.h' file not found` :( 2019-09-07 20:07:26 Weirdly, /usr/include/lttng/ust-config.h has the "#undef LTTNG_UST_HAVE_SDT_INTEGRATION" commented out even though according to the build log, autotools correctly identified that sdt.h was missing: "sdt.h integration: no (use --with-sdt)" 2019-09-07 20:13:33 PureTryOut: congrats on 3000th patch on ~patches 2019-09-07 20:14:13 Thanks! I worked very hard for it and am very proud of the achievement 😄 2019-09-07 20:30:07 PureTryOut: libpostal is failing on everything not x86_64 and x86 2019-09-07 20:30:10 because of usage of -msse2 2019-09-07 20:30:29 Yeah I noticed 2019-09-07 20:30:37 Already send a patch out to fix that on marisa-trie 2019-09-07 20:30:50 Seeing if I can fix it on libpostal as well 2019-09-07 20:30:56 i'll merge that then and disable libpostal for now, i'm going to a birthday party 2019-09-07 20:31:02 Oh sure 2019-09-07 20:31:48 why not create a has_sse2 variable and set it to --enable-ss2 or --disable-ss2 depending on the arch ? 2019-09-07 20:31:55 regardless, i'll push now, disable libpostal and go 2019-09-07 20:32:15 I guess that's fine too, doesn't really matter much imo 2019-09-07 20:32:26 it does deduplicate the ./configure script 2019-09-07 20:34:41 Does it? I still have to switch the whole thing if it has to be enabled or disabled. It's not like I can do `--enable-sse2=$has_sse2` 2019-09-07 20:35:23 Oh wait nvm 2019-09-07 20:35:26 I misunderstood 2019-09-08 09:38:36 seems that new raspberry pi start.elf doesn't support kernel/initramfs being in subfolder 2019-09-08 12:40:57 Has the s390x architecture been dropped? I don't see any builder for it anymore 2019-09-08 12:43:11 no, iirc tmhoang told that builder will be down some time for maintenance 2019-09-08 12:43:38 Ah ok 2019-09-08 14:08:13 maxice8: could you merge https://lists.alpinelinux.org/~alpine/aports/patches/2838? It seems to have been forgotten about 2019-09-08 14:08:58 No, doesn't apply against master 2019-09-08 14:11:16 Ah didn't know that. I'll update it then 2019-09-08 14:15:54 I've send a new version for it 2019-09-08 14:18:00 current font-noto-emoji doesn't depend on python2 2019-09-08 14:18:40 font-noto-emoji itself doesn't, but one of it's depends does 2019-09-08 14:18:53 font-noto-emoji has no depends 2019-09-08 14:18:53 Wait... 2019-09-08 14:19:36 Oooh you changed it 2019-09-08 14:19:45 It doesn't build the fonts anymore, now it just uses a pre-compiled one 2019-09-08 14:19:51 In that case, only merge the nototools patch 2019-09-08 14:19:59 aight 2019-09-08 14:21:16 Also, the pkgver for font-noto-emoji is cumbersome. If there is a proper release of the package at any point, it'll never replace previously installed versions as it'll never be a higher versino 2019-09-08 14:21:19 *version 2019-09-08 14:21:37 It should use the `0_gityearmonthdate` notation 2019-09-08 14:22:10 * It should use the `0_git` notation 2019-09-08 14:22:12 Or `_git` 2019-09-08 17:46:37 PureTryOut: kgpg is failing D: 2019-09-09 07:23:00 <_ikke_> https://pythonclock.org 2019-09-09 07:25:04 Python 2.7 will retire in... 2019-09-09 07:25:55 Python 2.7^W will retire in.. (rofl) 2019-09-09 07:26:23 _ikke_: \o 2019-09-09 07:26:39 <_ikke_> Hi 2019-09-09 07:27:43 are you enjoying you work/travel 2019-09-09 07:28:29 <_ikke_> Yes, we've seen some beautiful falls this weekend 2019-09-09 07:29:28 <_ikke_> The work is progressing, will travel back Thursday/Friday 2019-09-09 07:30:14 oh, very nice, would be nice if I can travel there. 2019-09-09 07:31:14 <_ikke_> t's a very poor country. Not a lot of people will travel there without a good reason. 2019-09-09 07:31:27 don't hurry back ;-) especially if you enjoy to visit nice places there 2019-09-09 07:47:53 Ugh I today noticed my commit message to upgrade KDE Applications uses the wrong version number... 2019-09-09 07:48:08 I guess rewriting history isn't an option? 🙈 2019-09-09 07:53:58 Not really :P 2019-09-09 08:00:32 Well at least the actual effect of the commit is correct. And it's clear it's wrong if you compare it to the previous commit for those packages, so I guess it's not that much of an issue lol 2019-09-09 10:19:49 ping SpaceToast 2019-09-09 10:20:33 Is installing LICENSE/COPYING files in /usr/share/licenses/$pkgname wanted? 2019-09-09 10:20:58 z3ntu: imo as long as it isn't available as an SPDX identifier. yes 2019-09-09 10:21:02 SpaceToast: aports:master |Francesco Colista| testing/lxd: upgrade to 3.17: | http://dup.pw/aports/b4f25fe2 2019-09-09 10:23:28 fcolista: you are maintainer of i2c-tools, what about move to community 2019-09-09 10:27:30 mps, if it works fine, yes 2019-09-09 10:28:04 it works fine on some of my arm boards 2019-09-09 10:28:46 I tested it only on arm's 2019-09-09 10:28:51 ok 2019-09-09 10:29:14 i2c has py2 bindings 2019-09-09 10:29:22 that needs to be removed or udpated to py3 2019-09-09 10:29:30 yes 2019-09-09 10:30:01 I didn't wanted to touch it before asking you for opinion 2019-09-09 10:30:57 ok it needs some extra work 2019-09-09 10:31:02 I'm looking at this 2019-09-09 10:31:10 do you have something ready? 2019-09-09 10:31:55 no, didn't started anything, but have it in minds in case you not respond in a week or two :) 2019-09-09 10:32:15 lol 2019-09-09 10:32:15 :D 2019-09-09 10:32:26 now, when you respond I will forget it ;-) 2019-09-09 10:33:04 :P :) 2019-09-09 10:40:16 mps: wanna take a look before i push? 2019-09-09 10:40:44 ok, url 2019-09-09 10:40:56 I even can test build on some arches 2019-09-09 10:41:34 http://dpaste.com/2QPJTBY.txt 2019-09-09 10:42:10 wondering if I should add provides=py-smbus 2019-09-09 10:42:21 since now I renamed py-smbus to py3-smbus 2019-09-09 10:43:05 ah, look like it should 2019-09-09 10:43:20 Yes, add provides and replaces 2019-09-09 10:43:29 Cogitri, yeah..replaces 2019-09-09 10:43:30 yes, that is how it goes 2019-09-09 10:43:41 provides="py-smbus=$pkgver-r$pkgrel" and replaces="py-smbus" 2019-09-09 10:44:00 caveat, do that in the py() function not in the root of the APKBUILD 2019-09-09 10:44:22 ? 2019-09-09 10:44:32 ah 2019-09-09 10:44:33 ok 2019-09-09 10:44:34 yes 2019-09-09 10:44:47 sure, in py() function 2019-09-09 10:45:04 yes, otherwise i2c-tools will replace it no py3-smbus 2019-09-09 10:45:11 exactly 2019-09-09 10:45:12 s/ no / not / 2019-09-09 10:47:19 ok...lunchtime here 2019-09-09 10:47:54 buon apetito :) 2019-09-09 10:48:12 http://dpaste.com/3ERC0KB.txt 2019-09-09 10:48:20 mps :) grazie! 2019-09-09 10:48:37 (forgot exact Italian syntax) 2019-09-09 10:48:55 "buon appetito" 2019-09-09 10:49:51 I know I missed something 2019-09-09 10:50:51 (long time didn't used nice Italian language :( ) 2019-09-09 10:51:36 when you speak is like you sing 2019-09-09 11:09:15 wait till you speak/hear German 2019-09-09 11:10:06 tmhoang: I did when I was in school ;) 2019-09-09 11:11:40 German school? ;) 2019-09-09 11:12:54 no, local but German was foreign lang to learn 2019-09-09 11:14:37 actually, German and Russian, and as option French 2019-09-09 11:31:59 fcolista: thanks, I'll check back once I checked to see if it's better 2019-09-09 13:02:53 Thanks SpaceToast 2019-09-09 13:03:06 I'm interested in knowing if/when we can move lxd to community 2019-09-09 13:03:21 for each version they mess up the things 2019-09-09 13:04:07 so we should wait for them to not ship a custom sqlite/dqlite, rather waiting that their patch for *qlite will be merget upstream and lxd could use the system *sqlite 2019-09-09 13:04:13 *qlite 2019-09-09 15:02:17 fcolista: I still encounter the same bug on 3.17 2019-09-09 15:02:35 when trying to start a container that uses a bridge type NIC, it fails to figure out what veth it actually created 2019-09-09 15:02:43 Error: Common start logic: Failed to start device 'eth0': Failed to set the MAC address: Failed to run: ip link set dev veth853fa594 address 00:16:3e:67:1d:11: ip: ioctl 0x8933 failed: No such device 2019-09-09 15:02:52 the real device is veth932fea0f@veth0 2019-09-09 15:02:56 do you think that is an alpine issue, or an upstream issue? 2019-09-09 15:03:04 can you give a static name to the iface? 2019-09-09 15:03:24 it's a bridged autogenerated iface, not sure how I'd do that 2019-09-09 15:03:33 iirc it needs extra logic for actually doing the pairing bit 2019-09-09 15:04:09 upstream is clearly using their stuff to some degree, but it's clearly related to upstream 2019-09-09 15:04:26 they changed their internal NIC logic in the 3.16 release, which is when this started happening 2019-09-09 15:04:33 so something in their new logic isn't playing well with alpine 2019-09-09 15:05:03 ok 2019-09-09 15:05:17 yes makes sense what you say 2019-09-09 15:06:04 i think this is related to some systemd compatibility stuff 2019-09-09 15:08:42 possibly :) 2019-09-09 16:22:16 maxice8: should the testing/quickjs be disabled again till it tested on CI or some local build 2019-09-09 16:33:35 Anyone feel free to disable it 2019-09-09 16:34:40 I just released it so SpaceToast can get logs since the failure that happens in the builders doesn't happen locally 2019-09-09 16:35:00 But I'm driving atm so can't do anything 2019-09-09 16:35:11 aha, ok. understand 2019-09-09 16:35:19 I will disable it for now 2019-09-09 16:44:36 mps: it passes on every local build attempted (at least 3 machines) 2019-09-09 16:44:49 it looks like yet another issue caused by our weird lxc configuration 2019-09-09 16:45:03 if you could just disable the tests with that as a comment it'd help :) (I'm at $dayjob right now) 2019-09-09 16:45:47 yes, I see it fails on test and message is strange 2019-09-09 16:46:14 I suspect the problem is with builders 2019-09-09 16:46:46 We've seen this stuff before, yeah 2019-09-09 16:47:18 Builders have two main issues - lack of lxcfs (CPU functions) and weird filesystem properties (what we're hitting here) 2019-09-09 16:47:34 right, also I had issues sometimes with builders 2019-09-09 16:52:56 SpaceToast: till the builders are fixed I think it should be disabled. but I don't insist on 'disable', whatever you prefer 2019-09-09 16:53:18 mps: I think just disabling tests is fine 2019-09-09 16:53:28 Via options=!check 2019-09-09 16:55:41 and add note after '# enable check again when builders are fixed' or '# disabled because bug/issue in builders' 2019-09-09 16:57:12 That last one, thank you :) 2019-09-09 16:57:25 ah, ok 2019-09-09 16:58:03 It seems like the fixes aren't really high priority, and the tests aren't really that extensive anyway 2019-09-09 16:58:41 I'll fix source by moving url to be on same line 2019-09-09 17:11:30 SpaceToast: it fails on s390x and ppc64le 2019-09-09 17:12:27 mps: ok, you can disable those 2019-09-09 17:12:38 I only tested on amd64 since I have no other hardware 2019-09-09 17:12:50 I think it might use some asm so that would make sense 2019-09-09 17:13:33 And sorry for the trouble, I did mention that in the MR :) 2019-09-09 17:15:36 I read it when you posted, and wanted to push but was not sure if it builds on all arches 2019-09-09 17:16:45 I would give it yet another chance on those two to see will it segfault again 2019-09-09 17:17:05 Would be nice if we had ci on gitlab 2019-09-09 17:17:22 can't wait also 2019-09-09 17:17:59 And for gitlab to be the canonical source, so merging via the Web UI (and Auto closing the MR) worked :) 2019-09-09 17:18:06 hope when _ikk_e_ comes back that he will continue his work 2019-09-09 19:17:54 I'd like to see jshon make its way to the main repo, there's a commit that's been out there since December of 2018 to add it, but it's still only in edge: https://git.alpinelinux.org/aports/commit/testing/jshon?id=57818935b7a5a1bec426721e935238ff89b54684 2019-09-09 19:18:08 can anyone tel me what's required to move that into the main branch? 2019-09-09 19:18:12 s/tel/tell/ 2019-09-09 19:24:05 TML: isn't enough to move it to community 2019-09-09 19:25:46 and package doesn't have maintainer field so I'm not sure it should go in main 2019-09-09 19:27:45 sure, community would be fine - but I'd be happy to be the maintainer as well, if that's needed 2019-09-09 19:28:46 pkgname is wrong "SON ..." instead of "JSON ..." I think 2019-09-09 19:28:56 yes, I noticed that as well 2019-09-09 19:29:02 and do you know why test is disabled 2019-09-09 19:30:46 oh, doesn't have tests, I think 2019-09-09 19:32:22 license looks non-standard and not MIT as is in APKBUILD 2019-09-09 19:33:44 it's MIT 2019-09-09 19:33:51 https://github.com/keenerd/jshon/blob/master/LICENSE 2019-09-09 19:35:43 aha, I see 2019-09-09 19:36:13 TML: Fix the issues and claim it 2019-09-09 19:36:30 Does it work ok? 2019-09-09 19:36:49 Yes 2019-09-09 19:36:54 Looks like the tests are disabled 2019-09-09 19:37:00 Not sure why 2019-09-09 19:37:07 clandmeter: doesn't have tests 2019-09-09 19:37:37 check() function can be removed 2019-09-09 19:37:40 Ok then please remove it 2019-09-09 19:39:24 and source field, jshon-$pkgver.tar.gz::ht...... => $pkgname-$pkgver.tar.gz::ht..... 2019-09-09 19:40:10 Not so important.. 2019-09-09 19:40:39 It's still done by newapkbuild 2019-09-09 19:40:40 well, not important but nice to be like other pkgs 2019-09-09 19:41:03 So will happen to more new ones 2019-09-09 19:41:24 really, didn't noticed 2019-09-09 19:41:33 I think it still is 2019-09-09 19:42:27 I will be out 2019-09-09 19:42:57 Maybe mps can apply it to community 2019-09-09 19:43:12 Ones a patch of provided 2019-09-09 19:43:45 np, I will 2019-09-09 19:45:08 TML: just send msg here mentioning my nick when you finish 2019-09-09 19:45:52 and you can remove 'cd "$builddir"' from functions 2019-09-09 19:46:03 it is now default 2019-09-09 19:46:31 would it be better to just do a newapkbuild for it so everything is using the new structure? 2019-09-09 19:49:03 no, it would be good to have history of package in alpine 2019-09-09 19:50:07 it is not hard to change current APKBUILD 2019-09-09 19:57:44 I send 44 patchces in one go, but git clearly didn't like it. It stopped sending after 20 commits... How do I continue sending the patches so they'll be included with the rest? 2019-09-09 19:59:43 Actually I can probably just send the rest in a new patch set 2019-09-09 20:01:05 Actually no it just blocked me, I can't send any new patches... 2019-09-09 20:01:24 I guess I'll use Github instead then... ddevault could you unblock me I guess? 2019-09-09 20:13:18 just noticed that firefox APKBUILD doesn't have check() and doesn't options="!check" 2019-09-09 21:28:58 Need a merge for pr10930 2019-09-09 21:42:26 PureTryOut[m]: blocked? 2019-09-09 22:17:08 Need a merge for pr10930 2019-09-09 23:35:04 Need a merge for pr10930 2019-09-10 05:34:52 ddevault: yeah the system didn't like me sending 44 patches at once. It seemed like I was blocked/throttled server-side 2019-09-10 06:01:24 Thanks for merging pr10930 ncopa, could you restart the mutter & gnome-shell build now? Those need the new glib 2019-09-10 12:29:22 ACTION starting to dislike perl's lots of modules on metacpan, a lot of work to package them for distro 2019-09-10 15:20:54 Quick question, I want to try and see if CLISP can be built against x86 and the arm platforms so I can get SBCL built for those platforms as well 2019-09-10 15:21:28 I don't have access to anything other than x86_64 to test on however, anyone have any suggestions on how I could test APKBUILDS on those platforms? 2019-09-10 15:21:52 I don't want to spam a PR to do testing unless that's an acceptable route to take 2019-09-10 15:22:41 It's the only way 2019-09-10 15:23:01 Or setup your own ci 2019-09-10 15:23:20 That's what I figured. I should probably look long term at setting up my own 2019-09-10 15:24:20 Well, as long as it's not frowned upon, I'll use it as a short term solution to get a sense on where I need to go and then make a plan 2019-09-10 17:03:06 Hey Carlo, quick question if you're in the IRC. Clisp requires ffcall to be available, and it looks like the package you built for it explicitly doesn't build x86, armhf, or armv7. Any particular reason behind that? 2019-09-10 17:04:30 probably problem on 32bit arch's 2019-09-10 17:05:30 Something that makes it unbuildable? 2019-09-10 17:05:44 It probably doesn't hurt for me to send a PR just to see what the CI does with it 2019-09-10 17:05:58 not sure, do you have any info about that 2019-09-10 17:06:25 on x86_64 you should probably also be able to reproduce the build failure (if any) in an x86 alpine chroot 2019-09-10 17:06:28 I can try to build it on armv7 to see if it works 2019-09-10 17:07:17 nmeum good point on the chroot, also if you don't mind mps I would appreciate that! 2019-09-10 17:07:55 I'm hoping I can get SBCL available everywhere, especially since 1.5.7 is likely to include a big endian release 2019-09-10 17:08:20 building :) 2019-09-10 17:08:59 passed :) 2019-09-10 17:09:03 on armv7 2019-09-10 17:09:25 That's a wonderful sign! Thank you mps! 2019-09-10 17:09:34 I can try later on my x86 lxc 2019-09-10 17:10:39 now I'm building 5.2.14 kernel, and don't want to stop it 2019-09-10 17:12:03 I'm impatient and pushed a PR, looks like it builds across everything 2019-09-10 17:12:41 It didn't have a maintainer, so that's probably all that it was. 2019-09-10 17:13:17 if you can wait 20-30 minutes I'll check x86 build 2019-09-10 17:14:10 if it builds on armv7 I presume it will also on armhf 2019-09-10 17:14:40 Yeah I believe so, they're not all that different 2019-09-10 17:16:15 let me finish with kernel first 2019-09-10 17:16:44 No worries, I'd say working on the kernel is probably more important 2019-09-10 17:21:40 wsinatra: pass on x86 2019-09-10 17:21:55 Perfect :D 2019-09-10 17:22:04 Thank you so much for the help mps! 2019-09-10 17:22:28 , 2019-09-10 17:22:30 oops 2019-09-10 17:22:45 the ffcall PR looks good, do you still want to make some tests or can I merge it as is? 2019-09-10 17:23:11 nmeum: what is PR number 2019-09-10 17:23:26 Pull Request on git 2019-09-10 17:23:38 nmeum yeah I think it's good to merge as is 2019-09-10 17:23:42 yes, number 2019-09-10 17:23:50 #11267 2019-09-10 17:23:59 give me minute 2019-09-10 17:24:09 ok 2019-09-10 17:24:47 algitbot: what's with you 2019-09-10 17:24:58 It doesn't like my PRs 2019-09-10 17:26:19 nmeum: looks ok 2019-09-10 17:26:23 ok great 2019-09-10 17:26:29 let's see if passes on the builders as well … 2019-09-10 17:26:51 yes 2019-09-10 17:27:19 pushed 2019-09-10 17:27:44 Wonderful! One step closer to SBCL everywhere 2019-09-10 17:28:08 \o/ 2019-09-10 17:28:28 looks like it passed armhf 2019-09-10 17:28:53 what is SBCL? 2019-09-10 17:29:07 Steel Bank Common Lisp 2019-09-10 17:30:09 aha, I know what is 'Common Lisp' but 'Steel Bank' is new to although I've seen this acronym and never looked for it's meaning 2019-09-10 17:30:30 s/new to/new to me/ 2019-09-10 17:30:46 It's an implementation really. But it's probably the most popular one currently 2019-09-10 17:30:59 In active development, 20 years old as well as of this year 2019-09-10 17:31:14 thanks for info 2019-09-10 17:32:10 Don't mention it 2019-09-10 17:32:29 wsinatra: just out of curiousity: have you considered bootstraping sbcl with an implementation other than clisp? 2019-09-10 17:33:07 I would be lying if I said yes haha. I know it's possible to do though 2019-09-10 17:33:40 yeah, just asking because when I added sbcl to the tree clisp upstream was pretty dead and I guess it still is 2019-09-10 17:33:43 In my case I took over SBCL's maintenance when it became unmaintained a few months ago, so I mostly used what was available to me. ECL, and a broken CLISP package which I took over too 2019-09-10 17:33:58 last update was 2010 I think for clisp 2019-09-10 17:34:03 yeah 2019-09-10 17:34:10 but I guess we can stick to clisp for now 2019-09-10 17:34:24 at least as long as it is good enough for bootstraping sbcl :) 2019-09-10 17:34:24 I honestly don't know anyone that uses clisp, so I really only have it there for SBCL 2019-09-10 17:34:31 right 2019-09-10 17:35:07 I'll look into it though, because it's kind of just bloat. It exists to make SBCL 2019-09-10 17:42:51 fcolista: ping - got around to filing a bug for the lxd thing; https://github.com/lxc/lxd/issues/6185 in case you're interested in following 2019-09-10 21:38:05 All builders are failing to upload packages 2019-09-11 06:58:12 SpaceToast, great, thanks! 2019-09-11 07:35:15 Cogitri: did you manage to find the developer handbooks recommendation on $pkgname in $source? (talked about this a few days ago) 2019-09-11 08:51:58 Python wheels are not supported on Alpine Linux probably because of using muslc. This causes very prolong build/compilation of Python packages which badly effect the overall experience of using Python on Alpine. Is it possible to patch pip in a way that whenever it builds/compiles python package it also submit it to a specific server. So, whenever 2019-09-11 08:51:58 another user want to install a package; pip first looks onto that server for availability of a precompiled wheel for user specified package/version. If package wheel exists download it and install it; otherwise build/compile it and submit the resulting wheel to that server. 2019-09-11 09:18:30 I don't know much about python, but if the build this on musl wouldn't be better to ask upstream to fix it so it can be built on musl, or patch it 2019-09-11 09:19:17 s/build/build fail/ 2019-09-11 10:02:01 nmeum: Ah, thought SpaceToast had sent you that already 2019-09-11 10:02:58 ahmedbilal: Just use apk, that does what you want 2019-09-11 10:04:09 Or the dev of the package needs to build a wheel for both glibc and muslc and upload both of those to pypi 2019-09-11 10:04:11 No need to patch pip 2019-09-11 10:04:42 Cogitri: Then, we have to figure out dependencies and their subdependencies 2019-09-11 10:06:06 Cogitri: Yes, it can be possible to ask developers to build for both glibc and muslc. But, I think pypi doesn't support it currently. 2019-09-11 10:11:40 ncopa: did you looked at #10783 2019-09-11 10:12:40 firefox on aarch64 waits for fixing that ;) 2019-09-11 10:24:41 mps: im not sure whats wrong with #10783 2019-09-11 10:27:10 can I post you patch for firefox to try it and see will this issue will be reproduced on on your build box 2019-09-11 10:28:35 maybe something is messed on my builder 2019-09-11 10:30:14 I can, ofc, but may I :) 2019-09-11 10:42:59 can you please tpaste the patch here? 2019-09-11 10:47:22 here it is http://tpaste.us/nMmV please ignore some comments there for now 2019-09-11 10:55:27 having stuff like CARCH=native always makes sure you are not able do cross compiling. personally I don't like it, but I don't know what politics are used 2019-09-11 10:57:57 artok: for now there are no other ways to build firefox (and some other pkgs which depends on rust) except that, or I don't know better 2019-09-11 11:00:04 indeed that is problem with upstream sources 2019-09-11 11:01:18 we still don't have $arch-alpine-linux-musl{eabixx} target in rust 2019-09-11 11:02:59 (and I don't expect from these hipsters to support something which is not famous, like musl or alpine) 2019-09-11 11:32:31 damn, why tpaste service isnt on alpinelinux.org!? :< could be added somewhere between: wiki git bugs packages mirrors links 2019-09-11 11:38:31 paste services are short lived, so doesn't make sense to link them to anything which will last longer 2019-09-11 11:39:58 mps, but tpaste is alpine project 2019-09-11 11:41:39 really? I will call it apaste then ;) 2019-09-11 11:42:04 mps, https://github.com/alpinelinux/turbo-paste 2019-09-11 11:42:38 yes, I know, but kidding a little 2019-09-11 11:42:42 :< 2019-09-11 11:43:34 ahmedbilal: Huh? Pypi supports uploading linux and windows binaries already so adding a glibc|musl category should be possible 2019-09-11 11:43:46 And way better than us making a package registry for musl python packages 2019-09-11 11:57:33 and pythonic way is to have virtual environments anyway 2019-09-11 12:45:34 @ncopa ping: i got security upgrades for a package in main/ pr11299 up to pr11302 2019-09-11 14:41:27 fcolista: turns out it depends on "full" ip(1) (as in iproute2), the busybox shim isn't sufficient. Can you please add iproute2 to the depends list? 2019-09-11 14:42:53 SpaceToast, doing right now 2019-09-11 14:43:09 I already checked, installing iproute2 in my test environment resolves the issue 2019-09-11 14:43:23 Yes I saw that on https://github.com/lxc/lxd/issues/6185 2019-09-11 14:47:43 SpaceToast : https://git.alpinelinux.org/aports/commit/?id=97edbbad 2019-09-11 14:47:54 thanks :) 2019-09-11 14:47:59 np 2019-09-11 15:38:15 Could someone test something for me on s390x? 2019-09-11 18:16:10 PureTryOut: it is in community now 2019-09-11 18:51:20 just out of curiosity, can anyone give any tips for getting patches merged quicker? Like, should I break things into smaller chunks? Should I do reviews and hope for a quid pro quo? Just be patient? Any tips are appreciated 2019-09-11 18:52:10 Well, depends on what is smaller chunks for you 2019-09-11 18:52:58 It foes make sense to group patches which belong together together (e.g. if you enable required feature X in a dep Y for package Z it makes sense to group those two commits together) 2019-09-11 18:53:02 also depends of importance of patches 2019-09-11 18:53:07 Where have you posted your patch? 2019-09-11 18:53:31 mps: At least I won't prioritze patches unless it's about security stuff 2019-09-11 18:53:38 does they fix bugs, security issue or something else 2019-09-11 18:53:54 I don't want to scare of new contributors with long waiting times 2019-09-11 18:54:04 Cogitri: just didn't wrote in time :) 2019-09-11 18:54:14 iggy: Where have you sent your patch? 2019-09-11 18:54:15 s/sent/posted/ 2019-09-11 18:54:26 It's a github PR that's been open for 4 months 2019-09-11 18:54:32 Oh my 2019-09-11 18:54:52 also I don't want, but wanted to add to your msg 2019-09-11 18:55:19 iggy: Mind spinning me a link? 2019-09-11 18:55:22 iggy: can you post url 2019-09-11 18:55:29 ehm 2019-09-11 18:55:32 https://github.com/alpinelinux/aports/pull/7894/ 2019-09-11 18:56:14 isn't this already merged? 2019-09-11 18:56:45 Seems like only the ceph to $pkgname change is left 2019-09-11 18:58:30 oh, it got merged yesterday (I cleaned up the s/ceph/$pkgname/ today) 2019-09-11 18:59:23 but the github PR didn't get updated, so I will just close that I guess 2019-09-11 19:00:01 looks such 2019-09-11 19:00:57 not sure how all this merging works, but I'll look closer next time to make sure I'm not saying something isn't merged when it is 2019-09-11 19:01:44 well, somewhat messy for now, we have ML patches, github PR's and gitlab MR's 2019-09-11 19:02:18 still, my request for any tips stands... I mean, I hopefully don't have any major changes like those any time soon, but baby sitting a PR for 4 months is tough 2019-09-11 19:02:27 I hope this will be consolidated 'real soon now' to gitlab only 2019-09-11 19:02:31 mps: which is preferred? 2019-09-11 19:03:07 for now looks like github is fastest and have more attention 2019-09-11 19:03:46 but plan is to move to gitlab 2019-09-11 19:04:53 on gitlab is already moved bug/issue report so will be easier to 'connect' with patches 2019-09-12 04:18:13 hello guys, i got notification of one of my packages outdated, but wanted to confirm quickly 2019-09-12 04:18:14 1. are we moving to gitlab now? should we contribute on github PR still or its now on gitlab MR? 2019-09-12 04:18:15 2. python2 is obsolete? i maintain metapackage, should i remove it and maintain py3 package instead? 2019-09-12 04:18:53 1. Yes we are moving to GitLab but most PRs still happens at GitHub and GitLab CI is still not complete 2019-09-12 04:19:26 2. Yes, python2 will be EOL soon so the sooner it is removed (hopefully before 3.11) the better 2019-09-12 04:20:29 my package is one of foundations for certain things, is it safe to do that? its basically py-certifi which is root cert bundle for SSL 2019-09-12 04:21:06 dont know if anyone is relying on python2 version still, but alpine repository shows couple of depended packages 2019-09-12 04:21:31 yes, py-requests and py-tornado depend on py2-certifi 2019-09-12 04:22:46 that is unfortunate, better wait until work is done on making py3-requests and py3-tornado 2019-09-12 04:23:23 is it possible to have on alpine both metapackage and the py3 package or its a conflict? 2019-09-12 04:23:41 metapackage you mean py-foo ? 2019-09-12 04:23:47 yep 2019-09-12 04:24:03 i'm just curious what could be "smooth" migration plan in this case 2019-09-12 04:24:57 current migration is making py3- the main package and do replaces="py-foo" and provides="py-foo=$pkgver-r$pkgrel" 2019-09-12 04:25:51 i see, but long-term basically removing "py-" altogether and enforce usage of "py3-" notation, right? 2019-09-12 04:26:25 i guess i could contribute some of these migrations, might be worthy 2019-09-12 05:50:06 im pushing gcc9 now 2019-09-12 05:50:22 oh nice 2019-09-12 05:50:23 :D 2019-09-12 05:52:26 i am slightly worried about arm* though 2019-09-12 05:52:50 https://gcc.gnu.org/gcc-9/changes.html 2019-09-12 05:52:57 it says it breaks ABI for arm* 2019-09-12 06:17:07 so, how software works today should anyone notice breakage ;) 2019-09-12 06:19:13 anyway, not first time that upgrades breaks something 2019-09-12 07:04:25 ncopa: Thank you for merging my Ceph PR yesterday 2019-09-12 07:08:06 iggy: np. thanks for working on it 2019-09-12 09:24:08 Can we install older version of Python 3.5? without compiling from source in Alpine 3.10? 2019-09-12 11:03:04 ahmedbilal: no 2019-09-12 11:03:30 well, i gues you could attach some older repo and hope for the best 2019-09-12 11:14:14 iggy: also a thank you from for working on Ceph. It's a big thing. I will test out on s390x too. There is a s390x bug in ceph master and being fixed fyi. will back port soon. 2019-09-12 11:14:31 *from me 2019-09-12 11:15:03 and great thing we drop python2 in ceph 2019-09-12 11:37:40 what to do with packages whose maintainers are not active for some time, for example more than 6 months 2019-09-12 11:39:17 upgrade/fix quietly? 2019-09-12 11:40:19 I guess I'd just keep them as maintainer and if someone wants to they can become the maintainer 2019-09-12 11:42:18 sounds ok, but I'm asking about upgrade or fix, not changing maintainer. because I dislike to send mail from my personal mail address and ask if they are still active 2019-09-12 11:44:02 it would be nice for alpine to send automated mails for maintainers who are not active in some time and make some report of the answer and results of dead addresses 2019-09-12 11:44:33 I don't think orphaning them is useful 2019-09-12 11:46:14 no, just to have report so we can look at it if we want/need to upgrade or fix 2019-09-12 11:48:02 I remember that some devs were very angry when someone upgrade their packages without asking first, and I don't wan't to make anyone angry/sad 2019-09-12 11:53:12 Ah, on GitHub/Gitlab I'd just ping them and see if they respond 2019-09-12 11:53:56 And if they don't respond in a reasonable time, let's say 2 weeks (if it's not security relevant) I'd just upgrade it IMHO 2019-09-12 11:54:18 And minor/patch upgrades should be fine without maintainer approval if you just bump the pkgver 2019-09-12 11:55:51 I'm always feel shaky even for upgrades or small fixes if I don't ask maintainer first 2019-09-12 12:03:02 Well, Alpine would grind to a halt if we had to ask the maintainer for every little change 2019-09-12 12:05:34 ye! contributing! 2019-09-12 12:06:22 true, because this I'm thinking about some web page or text file where we can look and be more certain 2019-09-12 12:07:03 for example not about maintainer, active, last active, angry if touch pkg etc... 2019-09-12 12:07:13 s/not /note / 2019-09-12 12:09:02 ( and I'll out myself on 'angry list' in advance :D ) 2019-09-12 12:09:18 s/out /put / 2019-09-12 12:10:07 somebody is angry because other person wanted help by contribution to project, no logic! :D 2019-09-12 12:10:09 ACTION need another patch for st term 2019-09-12 12:11:26 MY-R: no, if someone add bad changes then yes 2019-09-12 12:12:13 or break something 2019-09-12 12:12:26 but it is mostly about bump up version 2019-09-12 12:12:58 for that "edge" exist 2019-09-12 12:13:18 I'm not angry if someone do right things, even if not asking me. that's ok 2019-09-12 12:15:48 for example, I hesitated more than 3 months to start working on fixing clamav 2019-09-12 12:16:34 although current maintainer is really kind person (although with strange sense of humor :p) 2019-09-12 12:18:45 to finish my grumbling, some kind of inactive maintainers would be good to have, imo 2019-09-12 12:19:05 just keep away emotions/feelings from programming/fixing/contributing and all will be fine :D 2019-09-12 12:21:15 MY-R: you want me to like a marble :D 2019-09-12 12:21:29 to be* 2019-09-12 12:21:40 so what :D 2019-09-12 12:22:09 no, I prefer to live with feelings 2019-09-12 12:23:15 well, nothing wrong with feeling but with over-interpretation of them :P 2019-09-12 12:23:40 s/feeling/feelings 2019-09-12 12:25:03 ps I was afraid of today upgrade, gcc and firefox but looks like all working fine, thanks! :) 2019-09-12 12:25:40 I'm testing build firefox on aarch64 again with new gcc 2019-09-12 12:25:47 right now 2019-09-12 12:26:57 already upgraded fakeroot locally, seems good for now 2019-09-12 12:27:19 :) 2019-09-12 12:44:17 firefox-esr builds fine with gcc 9.2 on aarch64 2019-09-12 18:39:28 hi, is there any way to make library-packages depend on other libraries the same way ordinary ELF binaries are with APKBUILD? 2019-09-12 18:40:22 library packages ? 2019-09-12 18:41:32 package containing a .so library 2019-09-12 18:42:06 libraries are also ELF binaries and have the same dependency tracing done to them 2019-09-12 18:43:27 when I build they don't, but my APKBUILD might be wrong 2019-09-12 18:43:36 I should mention it's a bunch of subpackages 2019-09-12 18:44:05 .so files are symlinks to libfoo.so.x which is a symlink to libfoo.so.x.y.z (most of the time) 2019-09-12 18:44:43 abuild depends the package that has libfoo.so to the package that has libfoo.so.x.y.z (as far as i know, not sure if it is so.x.y.z or just so.x) 2019-09-12 18:47:36 yeah, but it doesn't seem to do that for, so for example I build the tpm2-tss libraries into several packages, libtss2-esys.so depends on libtss2-sys when checking with ldd, but the libtss2-esys package doesn't depend on the libtss2-sys package when I check with apk info -R libtss2-esys, and I can run apk del libtss2-sys without the usual dependency error/warning 2019-09-12 18:55:31 Be mindful that ldd also lists recursive deps 2019-09-12 18:55:47 Use `readelf -a | grep NEEEDED` or lddtree 2019-09-12 18:56:49 I tried it the hard way (removing the dependency), but I'll check with readelf as well 2019-09-12 18:57:23 yup, the other libraries are there 2019-09-13 00:19:34 tcely: when you have some time, can you mark https://github.com/alpinelinux/aports/pull/11367 as `T-ci-malfunction` please? 2019-09-13 06:44:33 mps: i think updating packages is ok. 2019-09-13 06:44:46 if you are unsure, send a message to maintainer and ask "is this ok with you?" 2019-09-13 06:44:56 and give him a couple of days to respond 2019-09-13 06:45:32 i think what happened with the person who got angry was that the coding style was changed or similar 2019-09-13 06:46:54 Cogitri: i think 1d68058f057b940aa3d695794abb1473542464c3 breaks atleast avahi-ui and py-dbus 2019-09-13 07:26:24 Oh, sonehow I had thought py-dbus had been switched over to py3 already, my bad 2019-09-13 08:15:13 Leo takes care of py-dbus, so I'll ask him about that 2019-09-13 08:22:13 ok 2019-09-13 09:26:10 <_ikke_> hiya everyone, I'm back 2019-09-13 09:26:31 eek! 2019-09-13 09:26:33 er, I mean 2019-09-13 09:26:37 welcome back! 2019-09-13 09:26:43 <_ikke_> thanks 2019-09-13 09:26:43 _ikke_: welcome back :) 2019-09-13 09:53:40 Welcome back ikke :) 2019-09-13 10:52:41 <_ikke_> Cogitri: thanks 2019-09-13 11:34:25 (if so, could you please test the PR I pinged you in?) 2019-09-13 11:44:32 Does Alpine Gitlab CI use the Gitlab-runner-helper Docker image? 2019-09-13 11:44:35 Err, _ikke_ ^ (and also, reverse the order of the messages, connection in uni isn't good enough for IRC apparently :P) 2019-09-13 12:37:14 fcolista: moved py3-distro from testing to community to satisfy certbot 2019-09-13 12:37:27 next time use aports-lint to find violations of packages depending on packages of upper repos 2019-09-13 14:12:58 <_ikke_> Cogitri: it uses the gitlab-runner-heoper images, but we have to build our own to support more arches 2019-09-13 14:14:29 Ah, alright 2019-09-13 19:20:45 do we want zstd support for next squashfs-tools? I'm working on it right now and sure about adding zstd 2019-09-13 19:25:26 s/sure/not sure/ 2019-09-13 19:37:46 no comments? ok, I'll rephrase question: any objections to add zstd to new squashfs-tools version (4.4)? 2019-09-13 19:38:36 I think it should be added because support is added upstream, and wouldn't hurt to have it 2019-09-13 19:39:24 no objections from me but i don't use squashfs atm 2019-09-13 19:39:57 modloop uses it 2019-09-13 19:40:44 i'm not modloop 2019-09-13 19:41:20 :D 2019-09-13 20:02:25 <_ikke_> what is zstd? :) 2019-09-13 20:03:48 _ikke_: new compression format 2019-09-13 20:04:06 <_ikke_> ah ok 2019-09-13 20:04:19 <_ikke_> akin to zlib? 2019-09-13 20:04:38 zlib, lzo, lz4 and all that stuff 2019-09-13 20:04:45 <_ikke_> right 2019-09-13 20:04:56 <_ikke_> thanks 2019-09-14 00:22:42 mps: I don't use squashfs-tools, but anything that drives adoption of zstd has my support :) 2019-09-14 00:26:16 <[[sroracle]]> the spam on the alpine MLs need to be taken care of 2019-09-14 04:58:27 iggy: I saw an actual build error so did not add that label 2019-09-14 05:18:36 [[sroracle]]: next week we hope to fix it 2019-09-14 05:19:29 <[[sroracle]]> good to hear :) 2019-09-14 08:43:28 TML: did you prepared patch for jshon? 2019-09-14 08:45:09 TML: and, I created MR for squashfs-tools with zstd support, !54 2019-09-14 13:19:44 hello people 2019-09-14 13:20:02 could someone add stagit to the alpine repos? 2019-09-14 13:20:08 stagit - static git page generator (HTML). 2019-09-14 13:20:12 https://git.codemadness.org/stagit/log.html 2019-09-14 13:20:18 it's very similar to cgit 2019-09-14 13:20:30 which I already made a guide for it 2019-09-14 13:20:34 in the wiki 2019-09-14 13:22:02 <_ikke_> nicolaus: You could create a patch to add it yourself if you are inclined 2019-09-14 13:22:17 a patch? sorry i dont understand 2019-09-14 13:22:27 <_ikke_> patch / pull request / merge request 2019-09-14 13:22:31 <_ikke_> to aports 2019-09-14 13:23:02 ok 2019-09-14 13:23:05 thanks 2019-09-14 13:23:29 i understand now, just found the url 2019-09-14 13:23:34 <_ikke_> ok, nice 2019-09-14 13:24:34 i'll see if i can make it work in a few hours 2019-09-14 16:30:21 I'm trying to build firefox from aports (@edge), but some of the dependencies are also in @edge and so are masked when I try to `abuild -r`, how can I allow dependencies from edge with `abuild`? 2019-09-14 16:30:37 ACTION sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/QbegQqsWkZwmKSjjqSILrNkh > 2019-09-14 16:37:52 I'd use docker-abuild for that 2019-09-14 16:38:44 Or build in a chroot 2019-09-14 16:40:16 even if I intend to install the package after? (for reference, I'm trying to build firefox with pulseaudio enabled; I know.. shame on me) 2019-09-14 17:06:09 <_ikke_> pltrz[m]: are you trying to build from a stable release version? 2019-09-14 17:43:21 <_ikke_ "pltrz: are you trying to build f"> firefox-68.0.2-r0 - right from testing 2019-09-14 17:44:37 <_ikke_> pltrz[m]: combining edge + stable is not really supported in alpine 2019-09-14 17:44:55 <_ikke_> you are going to run into dependency issues (just like you experience now) 2019-09-14 17:46:23 <_ikke_> So if you want to run firefox you built from edge, you'd best option is to switch to edge 2019-09-14 17:46:40 pltrz[m]: I rebuilt firefox-esr-68.1.0 from edge today, installed it on stable but it doesn't work because some files missing 2019-09-14 17:47:30 so, i will upgrade to edge and see if it works, not good idea to combine stable and edge 2019-09-14 17:48:17 oh, I've been running firefox from edge for a while now with no problems (except for some clash with flatpak) 2019-09-14 17:48:50 also I did till today 2019-09-14 17:49:19 tcely: Travis says `The job exceeded the maximum time limit for jobs, and has been terminated.` and Drone says `c++: fatal error: Killed signal terminated program cc1plus` (which in my experience has meant ran out of memory) 2019-09-14 21:25:17 @fcolista can you take a look at https://lists.alpinelinux.org/~alpine/aports/patches/3020 ? 2019-09-14 21:25:28 qt5 + shiboken update from 5.12.4 to 5.12.5 2019-09-14 21:25:53 maxice8: git commit 6ff98ded2034f0d3003f264a102529e3d80b8e64 2019-09-14 21:26:17 mps: yes ? 2019-09-14 21:26:27 looks like you forgot bump pkgrel to mosh be rebuilt 2019-09-14 21:26:40 oh 2019-09-14 21:26:48 did you make a PR/MR/patch to have it pkgrel bumped ? 2019-09-14 21:26:52 or something else is issue 2019-09-14 21:27:27 no, I will left it for you, and will make it only if you don't care ;) 2019-09-14 21:27:38 just did it 2019-09-14 21:27:47 please don't shy away from doing it in the future 2019-09-14 21:27:53 the sooner the problem is fixed the better 2019-09-14 21:27:54 good :) 2019-09-14 21:28:25 np, noticed it about hour ago when tried to upgrade mosh 2019-09-14 21:29:37 and, I'm working on my $day_job (well better say $night_job) so don't have much time 2019-09-14 23:39:00 _ikke_: There is a new atools, somask is now recognized as a valid variable for abuild 2019-09-15 06:13:55 <_ikke_> maxice8: alright 2019-09-15 11:49:12 could anyone with main push right push https://github.com/alpinelinux/aports/pull/11409 2019-09-15 11:49:33 it is needed for smooth upgrade to edge 2019-09-15 11:50:09 mosh rebuild with new protobuf by maxice8 2019-09-15 11:53:35 qt5-qtdeclarative is broken since the upgrade to qt 5.12.5 for some reason, not sure why. Complains about a symbol not found, but rebuilding it doesn't fix it... 2019-09-15 11:55:53 <_ikke_> mps: done 2019-09-15 11:59:51 PureTryOut: Maybe some of its deps isn't rebuilt (and that needs private qt symbols)? 2019-09-15 12:09:22 _ikke_: thanks 2019-09-15 13:00:18 ncopa: It seems like our current musl-libintl thingie doesn't really work out 2019-09-15 13:01:42 Just splitting out the header doesn't cut it, about every package just checks if a function like `ngettext` is available without linking any libs and if so enables NLS 2019-09-15 13:01:58 (or link libintl) 2019-09-15 13:36:04 About Avahi: I guess we either drop avahi-bookmarks since that's not ported to py3 yet or we re-introduce py2-gobject3 2019-09-15 13:40:22 (drop whatever you can to make alpine again small :) ) 2019-09-15 14:03:43 Cogitri: maybe, but I 'm not sure which dep 2019-09-15 14:04:30 Sorry, I don't know Qt too well, when I used source based distros I just sort of guessed which one it was an rebuilt them one by one 2019-09-15 14:06:04 It would be nice if abuild figured out itself which stuff needs rebuilding and then bumped the `$pkgrel` of those packages... 2019-09-15 14:06:51 I don't think it can do that with Qt 2019-09-15 14:07:17 Since it can't track the private symbols (unless we used something like an ABI scanner?) 2019-09-15 14:08:26 It 's complaining about FontEngine and GlyphCache stuff, but I do not see any font related deps for qt5-qtdeclarative 2019-09-15 14:09:39 I think qt5-qtbase provides that 2019-09-15 14:10:00 You'd think so. I'll try rebuilding that 2019-09-15 14:40:24 <_ikke_> PureTryOut[m]: maybe this can help? https://abi-laboratory.pro/index.php?view=navigator 2019-09-15 16:35:15 how to rename pkg to new upstream name, lm_sensors to lm-sensors 2019-09-15 16:35:35 git mv ? 2019-09-15 16:36:53 i have that in my ax personal tool 2019-09-15 16:37:43 http://ix.io/1Vgu :D rename_repo 2019-09-15 16:38:07 <_ikke_> git mv should work 2019-09-15 16:38:17 <_ikke_> and don't forget to add replaces / provides 2019-09-15 16:38:37 see almost any py3- package for example on how to replaces/provides 2019-09-15 16:40:33 maxice8: this tool is key of your productivity? ;) 2019-09-15 16:40:56 a piece, yes 2019-09-15 16:42:05 btw, upstream also changed release numbering from 3.4.0 to 3-5-0. what we should do in such cases 2019-09-15 16:42:52 <_ikke_> I guess s/-/. 2019-09-15 16:43:58 <_ikke_> 3-5-0 is not a valid package version 2019-09-15 16:44:09 that is what I think, but anyway asking here to hear other thinkings 2019-09-15 16:44:42 <_ikke_> I wonder what made them to decide to switch to such a strange versioning scheme 2019-09-15 16:44:56 :o 2019-09-15 16:45:39 s/:o/:\/ 2019-09-15 16:46:35 <_ikke_> Hmm, alpine-meetbot is missing 2019-09-15 16:47:11 on vacation? 2019-09-15 16:47:14 <_ikke_> heh 2019-09-15 16:48:15 <_ikke_> sopel is apparently broken 2019-09-15 16:48:57 <_ikke_> let's see if an upgrade fixes it 2019-09-15 16:49:06 <_ikke_> nope 2019-09-15 16:51:13 <_ikke_> .uptime 2019-09-15 16:51:13 I've been sitting here for 0:00:40 and I keep going! 2019-09-15 16:51:19 <_ikke_> it's back 2019-09-15 16:51:52 _ikke_: re: versioning scheme change. maybe they saw that video on how to piss FOSS packagers off :D 2019-09-15 16:52:07 good, life will be less boring with 'it' 2019-09-15 16:52:32 Yes, "just use master, it is always stable :D" 2019-09-15 16:54:21 <_ikke_> maxice8: too bad gitlab does not have release subscriptions 2019-09-15 16:54:53 i can get it into my RSS feed 2019-09-15 16:56:09 <_ikke_> gitlab only has 18.1 as latest? 2019-09-15 16:56:24 <_ikke_> for atools 2019-09-15 16:56:44 https://gitlab.alpinelinux.org/Leo/atools/-/tags 2019-09-15 16:57:00 <_ikke_> ah, I was looking at releases 2019-09-15 16:57:16 <_ikke_> https://gitlab.alpinelinux.org/Leo/atools/-/releases 2019-09-15 16:57:29 oh 2019-09-15 16:57:37 gitlab.a.o doesn't generate a RSS feed D: 2019-09-15 16:58:44 <_ikke_> upgrade is pushed 2019-09-15 16:59:41 <_ikke_> maxice8: did you only push lightweight tags by chance? 2019-09-15 17:00:32 i tag on git with this cmd: git tag -a 18.8.5 -e -m 'revolution' 2019-09-15 17:01:17 <_ikke_> alright, that's a proper tag 2019-09-15 17:01:28 <_ikke_> I wonder what causes gitlab to show a release 2019-09-15 17:02:23 <_ikke_> Ah ok, the tag description 2019-09-15 17:02:25 <_ikke_> on gitlab 2019-09-15 17:02:40 <_ikke_> https://gitlab.alpinelinux.org/Leo/atools/-/tags/18.8.5/release/edit 2019-09-15 17:24:38 <_ikke_> maxice8: hugo is failing to build on s390x, some tests are failing 2019-09-15 18:25:40 60th MR on gitlab.a.o 2019-09-15 18:26:33 I was productive in last 24 hours :) 2019-09-16 07:17:02 <_ikke_> I wonder how we should deal with install-time python dependencies. They're easy to miss during build 2019-09-16 07:33:00 linux 5.3 is released 2019-09-16 07:34:17 some new and interesting 'features' are included 2019-09-16 07:34:56 pidfd is nice thing 2019-09-16 07:37:08 <_ikke_> What does that do? 2019-09-16 07:37:09 and support for compressed firmware, alpine can be smaller 2019-09-16 07:38:48 pidfd remembers pid of started process so we will not kill when it is created with previously 'died' process pid 2019-09-16 07:39:33 better explanation (and short enough) is here https://kernelnewbies.org/Linux_5.3 2019-09-16 07:39:42 <_ikke_> thanks 2019-09-16 07:41:23 and 16 million of new possible IP addresses 2019-09-16 07:41:43 Hy guys 2019-09-16 07:42:33 I have updated pr10951 with latest wireguard "release" today 2019-09-16 07:54:51 kr0k0: what are new features with this new WG release 2019-09-16 07:55:53 I'm just preparing to build 5.3 kernel and would like to know should I add new WG or old one is 'good enough' 2019-09-16 07:57:21 mps: I didn't find new features in the commits, only fixes 2019-09-16 07:58:28 fixes are important, so I will try this new release, thanks 2019-09-16 07:58:32 mps: We should wait for kernel version 5.4, because this is the next lts release 2019-09-16 07:58:48 yes, I know 2019-09-16 07:59:30 although I would like to start right now with 5.3 for edge and when 5.4 is released just upgrade 2019-09-16 07:59:42 I also don't understand, why the kernel updates in edge are not backported to 3.10... 2019-09-16 08:00:12 with 5.3 we can test a lot of changes introduced in a few latest major upgrades 2019-09-16 08:00:27 mps: Yes, you are right. 2019-09-16 08:01:30 5.4 will be released in about two months and we will not have enough time to fix all issues for next alpine stable, I fear 2019-09-16 08:21:43 mps: This is a pity! Because we should be able to support the kernel for 2 years.... 2019-09-16 08:26:06 anyway, I hope we will manage to add 5.4 to alpine 3.11 release 2019-09-16 08:28:38 I'm testing 5.2 on some arm64 and arm32 boxes, it works well. and I posted to some people 5.2.x apk and they tested it 2019-09-16 08:29:13 but not much reports from users is received 2019-09-16 08:29:49 so I hope it means: no new is good news :) 2019-09-16 08:45:19 heh, nice new thing in kernel 5.3 is automatic bigger fonts on console for high resolution screens 2019-09-16 09:18:33 ncopa: I posted few MR's on gitlab.a.o for pkg's where you are maintainer. If you have some time please look at them 2019-09-16 09:41:48 fcolista: are you fine with me taking over maintainership of attica? It's part of KDE Frameworks which I'm maintaining already 2019-09-16 09:44:57 PureTryOut[m], sure! 2019-09-16 09:45:01 Go ahead 2019-09-16 09:45:48 Awesome thanks! 2019-09-16 10:01:26 So what to do to resolve the `shadow-doc` and `openssl-doc` packages conflicting with each other? Do you guys agree with this solution? https://gitlab.alpinelinux.org/alpine/aports/issues/10724#note_48773 2019-09-16 10:06:15 PureTryOut[m]: passwd.1 and passwd.5 should be in shadow and not openssl, imo 2019-09-16 10:08:23 Of course 2019-09-16 10:08:37 So would you guys be fine with just removing passwd.1 from openssl? 2019-09-16 10:08:57 not reemove, but rename 2019-09-16 10:09:14 openssl-passwd.1 describes the same thing and is also installed by openssl 2019-09-16 10:09:39 (hm, need to fix xset rate) 2019-09-16 10:10:37 yes, i agree with openssl-passwd.1, and maybe other man's in openssl 2019-09-16 10:11:53 No need to rename, openssl.passwd.1 literally describes the same thing and is already installed too 2019-09-16 10:12:54 i like how iproute named it's man pages 2019-09-16 10:15:10 I'll just send a patch, link to the issue in the description and it can be discusses further there 2019-09-16 10:44:35 Hmm not sure when openssl installs that man file. Trying to remove it just after `make install` just reports "No such file or directory"... 2019-09-16 10:47:48 Oh nvm, renaming schemes 😒 2019-09-16 11:33:33 Is there anyway to get the version of Alpine Linux being built on in an APKBUILD? Like "3.10" or "edge"? 2019-09-16 11:35:15 I guess `source /etc/os-release` would be the easiest way to do it? 2019-09-16 11:35:37 Although on edge repos `VERSION_ID` is "3.11_alpha20190809" there rather than just "edge" 2019-09-16 14:40:11 PureTryOut: pushed that plymouth-kcm thing 2019-09-16 14:40:18 just removed a trailing space on the pkgdesc 2019-09-16 14:41:04 Thanks! 2019-09-16 14:41:35 I need to push a `pkgrel` bump of `community/kwin`, but I rather do that after the KDE Frameworks upgrade is merged otherwise I have to do it again 2019-09-16 14:43:29 your series didn't get into patches 2019-09-16 14:43:34 it was stuck and broken down on archives 2019-09-16 14:43:43 i hate when it breaks like that 2019-09-16 14:45:56 Ugh 2019-09-16 14:46:49 Thanks for merging it though, I'll send the Kwin bump in a sec 2019-09-16 14:48:53 https://lists.alpinelinux.org/~alpine/aports/patches/3023 2019-09-16 14:50:01 done 2019-09-16 14:50:14 and i'm going to play some Europa Universalis 4 now so no more merging 2019-09-16 14:50:19 Thanks! 2019-09-16 16:15:14 https://lists.alpinelinux.org/~alpine/aports/patches/3024 to fix the current build issues (I did not have these locally, interesting) 2019-09-16 18:51:39 any known reason why cpp (cxx) is not enabled in portaudio pkg 2019-09-16 21:22:09 someone sent a github PR for that the other day 2019-09-16 21:23:47 oh, didn't know, already built it locally and thought to post patch 2019-09-16 21:24:00 heh, someone was faster 2019-09-16 21:25:35 ah, that was Cogitri 2019-09-17 06:17:52 Oh right, thanks for the reminder, mps :) 2019-09-17 06:43:35 Cogitri: good morning :) your patch is better than my 'hack' 2019-09-17 06:51:36 Morning :) 2019-09-17 06:51:47 Will fix it up after math lesson (ugh :P) 2019-09-17 10:33:26 This wiki page should probably be archived https://wiki.alpinelinux.org/wiki/Upgrade_to_repository_main 2019-09-17 14:24:16 So i got a lot of python3 conversions for main/ 2019-09-17 14:44:58 Please review pr9921 2019-09-17 14:46:57 ignoring the gpg stuff that i don't get and assuming the sed line is to fix a _beta3 or other case of failure to create a pc: provider, looks good. 2019-09-17 14:49:26 abuild should one day have support for pc: versions and GPG verification too 2019-09-17 14:50:20 Ok i'll take a closer look as that day draws closer 2019-09-17 14:52:47 https://github.com/alpinelinux/abuild/commit/9c284d4c33a421b14bf1ccf6d1b95324875f6937 2019-09-17 14:53:01 https://github.com/alpinelinux/abuild/commit/7edafd8c75a5804867c342da75efbfae6432ca41 2019-09-17 14:53:18 https://github.com/alpinelinux/abuild/pull/57 2019-09-17 14:53:58 Hopefully at least the first two will be in the next abuild version 2019-09-17 14:56:51 tcely: and 3rd will be nice 2019-09-17 14:57:56 It would! I have up waiting and just use my own abuild now. 2019-09-17 14:59:11 s/have/gave/ 2019-09-17 14:59:11 tcely meant to say: It would! I gave up waiting and just use my own abuild now. 2019-09-17 18:24:34 _ikke_: if you have time could you push MR !67 2019-09-17 18:38:49 <_ikke_> done 2019-09-17 18:41:45 _ikke_: thanks 2019-09-17 19:18:49 do the builders cache source tarballs 2019-09-17 19:38:34 <_ikke_> yes 2019-09-17 19:38:46 <_ikke_> just like abuild would on your own machine 2019-09-17 19:39:08 <_ikke_> /var/cache/distfiles 2019-09-17 19:46:42 _ikke_: I've seen, and algitbot helped me :) . thanks for info 2019-09-17 19:50:20 <_ikke_> how did algitbot help you? 2019-09-17 19:50:44 <_ikke_> You mean in #alpine-commits? 2019-09-17 19:52:53 yes, retry 2019-09-18 08:33:01 would someone with main push right look at https://github.com/alpinelinux/aports/pull/11323 main/portaudio: enable cpp binding 2019-09-18 09:15:33 mps: got merged 2019-09-18 09:21:06 I've seen it 2019-09-18 09:22:50 hope that the commiter (ncopa) will look at my MR's on gitlab.a.o for pkg's where he is maintainer ;) 2019-09-18 09:23:23 Cogitri: I need this patch to push xournalpp, hope you will like it 2019-09-18 09:24:49 Ah, you've packaged xournalpp too? 2019-09-18 09:25:04 yes, and using it 2019-09-18 09:25:15 Or are you referring to pr11324 2019-09-18 09:25:43 just waiting for portaudio cpp fix 2019-09-18 09:26:35 ohm, we should have something like debian ITP (Intent To Package) 2019-09-18 09:27:32 Yup 2019-09-18 09:27:53 and even WNPP (Work-Needing and Prospective Packages) 2019-09-18 09:28:43 Sounds like a lot of organisational effort 2019-09-18 09:28:49 Also, so you happen to use a Pen with Xournalpp? 2019-09-18 09:30:38 yes, pen. mouse is cumbersome (to say it politically correct) to me for such things 2019-09-18 09:31:26 did you tried 'abuild -r' on builder for your xournalpp? 2019-09-18 09:31:41 s/so/do/ 2019-09-18 09:31:41 Cogitri meant to say: Aldo, so you happen to use a Pen with Xournalpp? 2019-09-18 09:31:58 Dang :P 2019-09-18 09:32:03 hehe 2019-09-18 09:32:21 mps: Huh, it crashes for my with my pen unless increase the stack size 2019-09-18 09:32:50 Haven't tried it on builders yet because the new portaudiocpp apparently isn't built yet (at least CI tells me that) 2019-09-18 09:32:51 I didn't used it much, just 2-3 days 2019-09-18 09:33:03 Ah, I use it all the time for uni 2019-09-18 09:33:12 Currently working with upstream to fix a few things 2019-09-18 09:33:25 looks like missing is LDFLAGS=-lexecinfo 2019-09-18 09:34:09 would you mind if test and fix your PR and build it on few arch's, and if pass push it 2019-09-18 09:34:54 s/if /if I / 2019-09-18 09:34:54 mps meant to say: would you mind if I test and fix your PR and build it on few arch's, and if pass push it 2019-09-18 09:35:46 and, I would prefer if you stay as maintainer 2019-09-18 09:36:30 I even thought to push my patch wiht empty maintainer field 2019-09-18 09:40:40 Patch for execinfo is upstream already :) 2019-09-18 09:41:02 Will restart CI once portaudiocpp is built on builders and will push if it works then, okay? 2019-09-18 09:42:36 ok, I'm not in hurry 2019-09-18 09:45:56 oh xournal has a next-gen version of it! the original xournal was one of my most used apps on Nokia N810 and N900 2019-09-18 09:53:26 Xournalpp is pretty neat :) 2019-09-18 10:45:04 very good to all 2019-09-18 11:15:34 I have been told that here I can ask about the development of the packages, and I have a question since I have many packages and usually see that they send 1 package for each pull request and wanted to know how I do to send all my packages in a single pull request. 2019-09-18 11:18:39 :) 2019-09-18 11:18:57 It's hard to review a massive PR with unrelated packages 2019-09-18 11:19:39 I don't understand 2019-09-18 11:20:03 Here's the pull. https://github.com/alpinelinux/aports/pull/10515 2019-09-18 11:20:20 If they're tightly related to each other it's fine to pack them in one PR (e.g. bump package X that's required for package Y) 2019-09-18 11:20:30 But if they're not related to each other it's better to split them 2019-09-18 11:21:32 Yeaaah, I won't review a PR with over 60 commits, sorry 2019-09-18 11:21:37 Please split that up a bit 2019-09-18 11:21:46 With 60 commits CI doesn't really have a chance to run over it 2019-09-18 11:22:12 So if the packages are not related I can't pull with unrelated packages? 2019-09-18 11:23:14 Well, you can do it, but it certainly won't make reviewers more motivated to review it :) 2019-09-18 11:23:27 So please split it, so it's easier (or even possible) to review the thing 2019-09-18 11:23:58 Okay. Thank you. 2019-09-18 11:24:41 Feel free to ping me once you've splitted it up, I can take a look then 2019-09-18 11:25:11 ok 2019-09-18 11:59:19 mps: pushed xournalpp :) 2019-09-18 11:59:47 I see, good. didn't know you have push accces 2019-09-18 12:03:16 Recently got them (hurray) 2019-09-18 12:05:20 good, I will not look to your patches anymore ;) 2019-09-18 12:06:45 Well, I do welcome a review from time to time :P 2019-09-18 12:08:14 ofc, I'm just kidding. also I would like if at least one developer look at mine, but hesitate to ask because I know most of them are busy 2019-09-18 14:00:15 ncopa: thanks for taking a look at main/ 2019-09-18 14:10:28 Ugh sometimes people flag stuff out of date while they aren't, so annoying. I have a singular KDE Applications package flagged out of date, with just the message "yo" 2019-09-18 14:10:54 yeah, I also noticed that 2019-09-18 14:11:02 would be nice to have some easy way to unflag them 2019-09-18 14:13:04 where they are flagged? 2019-09-18 14:13:48 pkgs.alpinelinux.org allows flagging packages as outdated 2019-09-18 14:13:59 and automatically sends an email to the package maintainer 2019-09-18 14:14:59 ah, didn't know that feature although receive mail sometimes and wonder how it is sent. thanks 2019-09-18 14:16:18 np 2019-09-18 14:19:40 Worse is when automatic flagging is always a version ahead because they look at changelog instead of download page 2019-09-18 15:08:58 It's a bit annoying with GNOME packages where new versions are automatically tagged, but those are uneven version numbers (so they're unstable) 2019-09-18 17:05:01 just found this script https://github.com/arzzen/git-quick-stats 2019-09-18 17:05:35 interesting to see statistic about our activities 2019-09-18 17:07:31 we are most productive on Wednesday's ;) 2019-09-18 17:16:34 or monday-tuesday hangovers, wednesday just get's all the commits! 2019-09-18 17:20:51 all kinds of things you can do with big data 2019-09-18 17:22:44 'statistic allows you to be drown in a glass of water' (or even half of glass) :D 2019-09-18 17:25:04 but still, based on those kind of statistics, most of the marketing money is transferred 2019-09-18 17:25:17 totally drowning people 2019-09-18 17:27:50 we are OT but, what else could be expected from civilization in which money is supreme $deity 2019-09-18 17:28:19 nothing more expected 2019-09-18 20:17:44 Hm, could we maybe have the email mentioned by the bot in #alpine-commits too? 2019-09-18 20:17:53 Then it'd get pinged if something goes wrong 2019-09-18 20:18:54 <_ikke_> what bot? 2019-09-18 20:24:11 algitbot I guess 2019-09-18 20:27:00 <_ikke_> Then I don't understand your question 2019-09-18 20:29:50 Basically, it'd be nice if algitbot somehow pinged (or rather, mentioned) me if a commit of mine fails to build on the builders 2019-09-18 20:29:59 So I don't have to manually watch #alpine-commits or b.a.o 2019-09-18 22:23:26 I spent a little bit of time looking around (mailing list archives, general Google searches, etc), but didn't find anything... has their ever been any discussion about splitting the repo's into subdirectories somehow? main/community/testing are all approaching 2000 subdirs that could be organized differently to make things a little simpler to work with 2019-09-18 22:24:40 i find it very simple to work with as it is (plus my tooling is made with that hierarchy in mind), any ideas on how changing to subdirectories can help ? 2019-09-18 22:26:35 I first started thinking about it when github said it wouldn't show me everything in `main/`, which isn't the worst thing to work around 2019-09-18 22:27:21 i see, i had that problem when i was on Void Linux, it has only 1 directory (srcpkgs/) with all templates 2019-09-18 22:27:39 the only thing I could come up with was something like `main// I'm sure there are smarter people than me that could think of something better 2019-09-18 22:34:38 Should unmaintained packages in `community/` without other stuff depending on it be moved to `unmaintained/`? 2019-09-18 22:35:01 problably make a PR / Patch and see if there are interested parties 2019-09-18 22:35:25 A patch to move it to `unmaintained/` then? 2019-09-18 22:35:35 yes 2019-09-18 22:38:02 Ok thanks did so 2019-09-18 23:59:24 PureTryOut: pushed the 'fix url' for packages on testing/ i recommend doing PRs for packages on main/, personally i see more movement there for merging stuff to main/ 2019-09-19 00:00:24 Hmm 2019-09-19 00:00:39 Plus you get free CI :D 2019-09-19 00:02:37 I mean, I don't really want to 2019-09-19 00:02:52 The PR bit, not the CI bit 😉 2019-09-19 00:03:19 idk why, it is functionally the same for me except using git send-email or hub pr 2019-09-19 02:56:34 PureTryOut: Merged a few PRs, yakuake was missing checksum change and zxing-cpp had a soname bump, made a separate commit to rebuild kitinerary 2019-09-19 07:24:55 Cogitri: cant you config your irc client to trigger on your name? 2019-09-19 07:25:27 I don't think so :c 2019-09-19 07:25:51 switch to a better client 2019-09-19 07:26:03 if you want you can have an acc on our lounge instance 2019-09-19 07:26:23 <_ikke_> But that only highlights you for your commits, not actual build failures 2019-09-19 07:26:49 <_ikke_> which only mentions the package names 2019-09-19 07:26:58 oh ok 2019-09-19 07:27:04 you want it for failures only? 2019-09-19 07:27:15 Yes 2019-09-19 07:27:21 That'd be very nice 2019-09-19 07:27:37 you could kind of script it i think 2019-09-19 07:27:54 <_ikke_> Is that information even available somewhere? 2019-09-19 07:28:21 yes and no 2019-09-19 07:28:24 not directly 2019-09-19 07:28:41 it does mention which pkg 2019-09-19 07:28:44 <_ikke_> Yeah, that's what I mean. You'd have to tie back the package to the last commit that touched that package I guess 2019-09-19 07:29:05 it also mentions the package is pushed 2019-09-19 07:29:21 so there is a relation 2019-09-19 07:33:20 Cogitri: you know you can subscribe to mqtt msg's? 2019-09-19 07:34:26 I know mqtt but where do we publish the stream? 2019-09-19 07:34:33 msg.a.o 2019-09-19 07:34:55 we have a tool you can use called mqtt-exec 2019-09-19 07:35:47 Ah, nice, thanks 2019-09-19 07:35:51 it will listen on topic(s) and exec something when found. 2019-09-19 07:36:07 this is how we trigger things via mqtt 2019-09-19 09:29:44 Yeah you can 2019-09-19 09:31:08 You can tell in Riot to highlight you for custom keywords. Afaik it then applies that server-side so should work on any client 2019-09-19 09:33:46 Oh my, how? :o 2019-09-19 09:42:56 ACTION uploaded an image: Screenshot_20190919_114243.png (31KB) < https://matrix.org/_matrix/media/v1/download/fam-ribbers.com/SxJHRAtJVcSPLLdAubIESPnA > 2019-09-19 09:43:11 Bottom option in that screenshot, click on "keywords" and enter the keyword you'd like to be notified on 2019-09-19 10:19:04 Oh nice, thanks for the info! 2019-09-19 10:20:02 Now it'd still be nice if some author information was included for failed builds 2019-09-19 13:37:28 PureTryOut: pushed retroarch, pkgrel wasn't resetted 2019-09-19 13:38:07 Woops sorry 2019-09-19 13:41:57 no worries, ammended and pushed 2019-09-19 13:43:25 not much time left to freeze and main needs more upgrades and fixes 2019-09-19 13:51:13 Cogitri: you should probably get GNOME into community before that 2019-09-19 13:51:59 mps: When is the freeze ? 2019-09-19 13:53:24 I'd don't know for sure, but I think at the end of next month, approxx. BDFL know better :) 2019-09-19 13:53:54 that will make it very tight to remove python2 2019-09-19 13:54:38 PureTryOut: Yup, will do it at the weekend 2019-09-19 13:55:18 maxice8: yes, and afaik python2 will 'die' in few months 2019-09-19 13:55:37 It will be EOL by january 2020 iirc 2019-09-19 13:56:25 ah, yes Jan 2019-09-19 13:56:31 eeeeh 2019-09-19 13:56:40 https://www.python.org/dev/peps/pep-0373/ 2019-09-19 13:56:52 aaaand 2020 april you'll get yet another 2.7 2019-09-19 13:57:16 artok: 2020-04-01 you mean :D 2019-09-19 13:57:43 mps: that was my first reaction to the news, but then that url.. 2019-09-19 14:00:19 back to subject, we need more care for main especially from people with push access right there 2019-09-19 14:43:34 hitting mkimage.sh --arch aarch64 just gives gzip: invalid magic 2019-09-19 14:44:54 ah well 2019-09-19 14:45:04 another things than the mkimage script 2019-09-19 15:20:14 ddevault: if you want i can make a PR to move the py-flask* stuff from main/ to community/ 2019-09-19 15:20:27 maxice8: that would be nice 2019-09-19 15:25:50 updated py3-flask PR to have tests and be in community/ also moved the other flask* stuff to community 2019-09-19 15:26:14 thanks! 2019-09-19 15:39:49 <_ikke_> yeah, would make sense to me as well 2019-09-19 15:40:39 aye 2019-09-19 15:40:45 I think one of our long term goals should be shrinking main 2019-09-19 15:41:00 <_ikke_> yes, a lot of packages are still in main because community didn't exist yet 2019-09-19 15:47:06 Alright, did another roundtrip of py2 removal on main/ need someone to walk over it on GitHub and merge 2019-09-19 15:47:11 ACTION back to HOI4 2019-09-19 15:53:44 yes, just working on iputils and see that we should add new pkg docbook-xsl-ns (new iputils depends on it make doc) to main but not sure would it be better to move iputils to community and add docbook-xsl-ns there 2019-09-19 16:06:41 PureTryOut: Seems like the notification thing worked, thanks 2019-09-19 16:06:48 No problem! 2019-09-19 17:24:27 :D lots of PRs for main/ in GitHub 2019-09-19 19:12:25 <_ikke_> I still need to get a bit up to speed again 2019-09-19 19:39:49 <_ikke_> apparently llvm 9.0 has been released 2019-09-19 19:42:00 Neat 2019-09-20 14:08:37 ncopa: I think in iptables the file /usr/etc/ethertypes should be /etc/ethertypes 2019-09-20 14:09:27 <_ikke_> https://pkgs.alpinelinux.org/contents?file=&path=%2Fusr%2Fetc&name=iptables&branch=edge&repo=main&arch=x86_64 2019-09-20 14:09:39 <_ikke_> Yes, I would agree 2019-09-20 14:11:45 <_ikke_> This patch would probably fix it: http://tpaste.us/oaRR 2019-09-20 15:18:24 yes, that fixes it 2019-09-20 18:18:32 ddevault: merged tqdm with a few changes in a follow-up commit 2019-09-20 18:19:12 thanks maxice8 2019-09-21 13:14:55 Cogitri: checking the fwupd you did, you disabled a patch but didn't remove it from the directory 2019-09-21 13:15:11 Oh, oops 2019-09-21 13:15:20 Thanks for the heads-up 2019-09-21 13:15:27 Np 2019-09-21 14:30:43 Hey guys, hopefully I quick one, whenever I try to build any 'APKBUILD' with 'abuild -r' it is failing with an 'unsatisiable constraint' error, but the packages that it complains about exist in the repos. Does 'abuild -r' not pull down makedeps anymore? 2019-09-21 14:31:49 <_ikke_> it does 2019-09-21 14:33:28 <_ikke_> make sure that you added the repositories that the package comes from to /etc/apk/repositories 2019-09-21 14:37:06 doesn't seem to be that. I am building the 'xsel' APKBUILD and it is complaining about `libxt-dev` which is in the 'main' repo 2019-09-21 14:37:47 'http://dl-cdn.alpinelinux.org/alpine/edge/main' is in /etc/apk/repositories 2019-09-21 14:39:17 hmm it has just started working again, not sure what if anything I've just changed 2019-09-22 08:14:34 anyone with glm experience would look patch I made to upgrade it to 0.9.9.6 2019-09-22 08:15:47 upstream removed 'make install' so I use 'cp' in package() 2019-09-22 08:17:02 build works fine, and I rebuilt few packages which makedepends on glm-dev (libreoffice is big one), works ok 2019-09-22 08:18:01 or, just to push glm upgrate to aports and fix bugs later if they appears 2019-09-22 15:19:11 Hello, just quick question regarding the mailing lists. If I have a patch proposing new feature for mkinitfs, should that go into ~alpine/devel or ~alpine/aports ? 2019-09-22 15:29:15 The latter 2019-09-22 15:29:18 (Or a GitHub/Gitlab PR) 2019-09-22 16:55:45 Hi all 2019-09-22 16:56:39 Just a short reminder, please merge pr10951. 2019-09-22 16:57:23 We are two releases behind... 2019-09-22 16:57:50 I'll take a look once home 2019-09-22 16:58:09 Cogitri: Thanks! 2019-09-22 16:58:26 Does Wireguard actually work for you though? 2019-09-22 16:58:59 Yes 2019-09-22 16:59:01 I'm hit by https://gitlab.alpinelinux.org/alpine/aports/issues/10772 :c 2019-09-22 16:59:08 It works fine on my mobile but the same config doesn't work on Alpine for me 2019-09-22 16:59:14 Huh, weird 2019-09-22 17:03:34 Hm... 2019-09-22 17:04:31 I'm running on Alpine the "server side" and on Android, Windows and iOS the clients 2019-09-22 17:05:13 Ah, alright 2019-09-22 17:05:31 I'm running Alpine on the server side too and Alpine/Android on the client side 2019-09-22 17:20:05 Cogitri: Is this a wg-quick problem? Because I'm not using it. 2019-09-22 17:21:06 Dunno, I just know that wg-quick doesn't do the trick for me on the client side 2019-09-22 17:22:58 Anyway, your upgrade works for me with Alpine as server side and Android as client side, will merge when home 2019-09-22 17:36:06 Cogitri: Ah, nice 2019-09-22 18:33:19 Cogitri: how do I tell whether a package will work on any arch? 2019-09-22 18:38:37 or rather 'all' 2019-09-22 18:41:46 CI will tell you for anything but ppc64le and s390x as of now 2019-09-22 18:41:52 (Rust stuff generally works on everything but s390x tho) 2019-09-22 18:43:23 so it I change it to 'all' and the travis CI build on the PR passed it should be good in theory? 2019-09-22 18:43:28 *if 2019-09-22 18:44:24 <_ikke_> Yes, and if it fails on a certain arch in a way that's not easily fixable, we'll just disable it for that arch fow now 2019-09-22 18:44:46 thanks 2019-09-22 18:45:56 <_ikke_> maxice8: libqmi is failing on s390x 2019-09-22 18:59:20 so after changing to 'all' it appears to be failing the tests on x86 armhf and armv7 2019-09-22 18:59:55 should I just set arch to 'x86_64 aarch64'? 2019-09-22 19:00:12 https://cloud.drone.io/alpinelinux/aports/12236 2019-09-22 19:04:27 <_ikke_> yeah, looks to be failing on 32bit arches 2019-09-22 19:04:53 <_ikke_> 1 failed test 2019-09-22 19:05:08 <_ikke_> Maybe worth reporting upstream 2019-09-22 19:05:46 will do 2019-09-22 21:30:26 fcolista: icigna is failing on s390x (possible due to a broken boost build?) 2019-09-23 06:41:16 Cogitri, I saw that...I was wondering to disable the build. 2019-09-23 06:56:22 fcolista: got my pm? 2019-09-23 07:00:44 clandmeter, yes..going to ask him 2019-09-23 07:01:31 (sorry I back just today @work and read your pm) 2019-09-23 10:35:10 ncopa: do you have some time to look at MR's on gitlab.a.o I posted, all passed build tests on x86, x86_64, armv7 and aarch64. Some of them are working on my production systems 2019-09-23 12:45:48 ok 2019-09-23 12:46:04 <_ikke_> o/ 2019-09-23 13:23:51 <_ikke_> ncopa: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/74 2019-09-23 19:15:49 can anyone review and comment MR !75 2019-09-23 19:16:46 <_ikke_> It's still WIP? ;-) 2019-09-23 19:19:13 yes, I add WIP tag by intention in case someone wanted to push it before looking on it 2019-09-23 19:19:37 <_ikke_> THe convention is that WIP means, do not merge yet 2019-09-23 19:19:38 is that ok, i.e. add this tag? 2019-09-23 19:19:47 <_ikke_> It means you are still working on it 2019-09-23 19:20:02 <_ikke_> ie, it's not finished 2019-09-23 19:20:08 aha, ok. 2019-09-23 19:20:47 I could push it but wanted at least one developer to look at it 2019-09-23 19:21:11 <_ikke_> let me check 2019-09-23 19:21:31 and when you are looking at, it builds on x86, x86_64, armv7 and aarch64 2019-09-23 19:21:58 <_ikke_> gitlab CI is ready to be used btw (though no ARM builders yet) 2019-09-23 19:21:59 I tested build some pkg which depends on it 2019-09-23 19:22:33 libreoffice is big one, builds with this upgraded version worked 2019-09-23 19:23:22 what happened to fix-endian-test.patch it seems reverted? 2019-09-23 19:24:10 <_ikke_> looks like line-ending change 2019-09-23 19:24:17 <_ikke_> I was just looking at it 2019-09-23 19:24:44 yes, I noted in git commit msg 2019-09-23 19:26:42 <_ikke_> I always find it a shame that these hosted review interfaces place de-emphazise reviewing individiual commits 2019-09-23 19:27:33 biggest change is that the upstream removed 'make install' and I used 'cp' instead 2019-09-23 19:27:58 <_ikke_> mps: Any reason you don't use the install command? 2019-09-23 19:28:14 <_ikke_> probably because of cp -r 2019-09-23 19:28:41 https://github.com/g-truc/glm/commit/5f352ecce21bb1ab37fa56fac0f383c779b351a3 2019-09-23 19:28:51 > Removed CMake install and uninstall scripts 2019-09-23 19:29:11 <_ikke_> why.. 2019-09-23 19:29:23 <_ikke_> Not even a motivation in the commit message 2019-09-23 19:29:34 <_ikke_> just "removed" 2019-09-23 19:29:47 also I have no idea why 2019-09-23 19:29:52 <_ikke_> https://github.com/g-truc/glm/issues/947 2019-09-23 19:31:14 yes, I know 2019-09-23 19:31:18 <_ikke_> "You have to work on it" 2019-09-23 19:31:56 what, to revert this removal? 2019-09-23 19:32:11 <_ikke_> "Towards a solution that works for everyone" 2019-09-23 19:32:21 <_ikke_> Where some responded: "the revert is what will work for us" 2019-09-23 19:32:41 <_ikke_> This is just madness 2019-09-23 19:32:49 but how we know will upstream ever revert it 2019-09-23 19:33:36 <_ikke_> You might add the reverted commit as a patch 2019-09-23 19:33:54 maybe we can make 'revert' patch for this release (or another one) but at the end we are at the merci of upstream 2019-09-23 19:34:11 I thought about that 2019-09-23 19:34:18 but was not sure 2019-09-23 19:34:25 <_ikke_> Me neither 2019-09-23 19:34:52 because this I asked here for opinions of other devs/people 2019-09-23 19:34:52 ah, i have an openoffice dev friend, will ask him what they think about this... 2019-09-23 19:35:07 <_ikke_> It's kind of random 2019-09-23 19:35:16 <_ikke_> what the maintainer did 2019-09-23 19:35:44 Arch maintainer also use 'cp' 2019-09-23 19:36:29 hmm, you remembered me to look what debian maintainer do 2019-09-23 19:36:55 pinged the libreoffice dev, we'll see what they think of this. 2019-09-23 19:37:41 qa3Txu0iak0F: thanks 2019-09-23 19:40:12 Debian changelog '* Deal with upstream no longer providing an install option.' 2019-09-23 19:42:36 <_ikke_> How did they deal with it? 2019-09-23 19:43:05 ah, like this what I posted but they added also /usr/share/pkgconfig/glm.pc 2019-09-23 19:43:10 <_ikke_> ok 2019-09-23 19:44:38 so, this have to be added 2019-09-23 19:45:40 yeah. .pc files are quite important 2019-09-23 19:46:21 agree but wonder how the libreoffice is built without it 2019-09-23 19:48:46 I guess they're just probing for it manually 2019-09-23 19:49:36 libreoffice is smart ;-) 2019-09-23 19:53:25 More like Libreoffice is working around the oddness of its deps :P 2019-09-23 19:53:42 <_ikke_> so, smart? 2019-09-23 20:16:43 bumping my old patch adding full disk encryption to setup-alpine 2019-09-23 20:17:31 https://lists.alpinelinux.org/~alpine/devel/patches/769 2019-09-23 20:18:40 <_ikke_> hmm, this is against alpine-conf 2019-09-23 20:18:50 yes? 2019-09-23 20:19:04 https://pkgs.alpinelinux.org/contents?file=setup-disk&path=&name=&branch=edge 2019-09-23 20:19:18 <_ikke_> It's a separate repo, with separate maintainers 2019-09-23 20:19:36 separate from? 2019-09-23 20:20:51 <_ikke_> separate from aports 2019-09-23 20:21:05 I didn't post it to aports 2019-09-23 20:21:07 I posted it to devel 2019-09-23 20:21:57 <_ikke_> yes, I just mentioned that this is for alpine-conf, to make clear it's just not a regular aports patch 2019-09-23 20:25:01 I see 2019-09-23 20:25:26 maybe it'd be more likely to get reviewed if it were done in the form of a patch applied in the aport ;) 2019-09-23 20:26:16 <_ikke_> Then I would give as feedback that this should be applied upstream, not in the aport ;-) 2019-09-23 20:33:10 Hello 2019-09-23 20:33:38 I wanted to add a package to alpine linux (namely dmd, the reference D language compiler) 2019-09-23 20:34:08 is there any guidelines to follow? How does one do the process of submission? Thanks in advance 2019-09-23 20:34:13 o/ 2019-09-23 20:34:43 <_ikke_> Roxanne: Welcome 2019-09-23 20:34:47 there is some information on the wiki 2019-09-23 20:35:09 you can provide patches via github or ml 2019-09-23 20:35:15 and recently also via gitlab 2019-09-23 20:35:43 <_ikke_> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2019-09-23 20:37:07 thanks! I will try to work on it, if I have any issue I wont hesitate to ask here 2019-09-23 20:37:24 <_ikke_> Feel free 2019-09-23 20:40:40 _ikke_: is it ok to steal glm.pc from debian -_- 2019-09-23 20:41:11 for glm pkg, I mean 2019-09-23 20:41:49 <_ikke_> It's not included in the project? 2019-09-23 20:42:31 no 2019-09-23 20:42:51 debian have it as separate file 2019-09-23 20:43:10 or, can take it from previous version in alpine 2019-09-23 20:44:37 hmmm, this sound better option 2019-09-23 20:46:27 difference is in just one digit, minor version. their is 'Version: 0.9.9.6' our is 'Version: 0.9.9' 2019-09-23 20:50:01 in the url field of an APKBUILD, do I redirect to a github repo or the homepage of the project 2019-09-23 20:50:18 Roxanne: home page 2019-09-23 20:51:40 can the arch field be an array if I target both i386 and amd64 2019-09-23 20:52:07 an array? 2019-09-23 20:52:10 as in, arch="x86, x86_64" 2019-09-23 20:52:14 no, space-sparated list, arrays are a bash feature 2019-09-23 20:52:33 yes, without comma ',' 2019-09-23 20:52:38 thanks 2019-09-23 20:53:25 you can also exclude in a list with !value 2019-09-23 20:53:30 <_ikke_> Roxanne: note that alpine supports more arches then just x86* 2019-09-23 20:53:52 yeah but the thing im porting namely only supports that 2 2019-09-23 20:54:03 <_ikke_> right, suspected as much 2019-09-24 02:04:18 Trying to make a merge request on gitlab.a.o using curl and the gitlab v4 API but getting 403 forbidden even when using an access token with all permissions. 2019-09-24 02:55:59 Nevermind, got it to work, sadly because the gitlab API to create merge_requests feel very annoying compare to GitHub 2019-09-24 05:02:37 I've just asked in alpine-users, but I believe here's the correct place to ask. Sorry if you see this twice 2019-09-24 05:03:00 say that I update a library (L) with abuild, then there's two other packages that depends on L, package 1 (P1) and package 2 (P2). Now when I've built and installed L, how does apk/abuild help me to understand that I need to rebuild P1 and P2 as well, otherwise I'll end up with a broken system 2019-09-24 05:24:14 <_ikke_> iveqy: apk info -R L 2019-09-24 05:25:29 <_ikke_> There is also https://github.com/alpinelinux/lua-aports 2019-09-24 05:28:30 _ikke_: so let's say that upstream want to upgrade zlib in edge, they compile a new zlib package and push that to the mirrors, but then they also need to update openssh (since it has zlib as a dependecy). Do you mean it's a manual job to run apk info -R -L and then remember to rebuild all those package before releasing them to a mirror/repo? 2019-09-24 05:29:27 <_ikke_> Yes 2019-09-24 05:29:57 _ikke_: oh thanks, and atools-lua has build-list command that helps 2019-09-24 05:30:24 <_ikke_> Indeed, that's what most core devs use 2019-09-24 05:32:06 are you one of them? Do you happen to know the runtime of that command? 2019-09-24 05:32:50 _ikke_: I'm working with bitbake today, and this lookup is really really slow, so I'm looking around to see how other systems does it. 2019-09-24 05:37:14 iveqy: not all upgrades needs revdep rebuilds 2019-09-24 05:38:01 clandmeter: how do you determine which does? 2019-09-24 05:38:20 Soname mostly 2019-09-24 05:38:40 I imagine that a change that does not alter a header file don't need it 2019-09-24 05:38:44 It's mostly means abi has changed 2019-09-24 05:38:56 <_ikke_> abi laboratories can help as well 2019-09-24 05:39:20 We have tool called checkapk 2019-09-24 05:39:47 It will compare new and current package 2019-09-24 05:39:47 <_ikke_> https://abi-laboratory.pro/ 2019-09-24 05:41:42 And the changelog does miracles too 2019-09-24 05:42:28 _ikke_: thanks I'll look into it 2019-09-24 05:43:05 clandmeter: I see, neat. So cname is set by the library developers, so it's really up to them to make sure to update the version if the abi change 2019-09-24 05:43:14 have I understood it correctly? 2019-09-24 05:43:27 Some packages are notorious for breaking abi without a proper soname bump 2019-09-24 05:43:57 Correct 2019-09-24 05:45:20 We try to catch those charges with CI 2019-09-24 05:45:35 _ikke_ is working on it 2019-09-24 05:47:09 a cool, I guess there's where api-laboratories comes in? 2019-09-24 05:47:32 why don't you just always rebuild all packages with reverse dependencies? 2019-09-24 06:38:57 How does everyone open merge requests on gitlab ? @mps 2019-09-24 06:41:06 maxice8: 'git push mps' and then go to WEB interface and clickety-clickety 2019-09-24 06:41:28 tried with 'lab' but it sometimes make a mess 2019-09-24 06:41:56 yes, found out lab wouldn't make merge requests 2019-09-24 06:42:01 neither fetch them properly 2019-09-24 06:42:06 so i'm writing my own script :D 2019-09-24 06:42:22 it can, but sometimes make a big mess 2019-09-24 06:43:31 I would play with it but because can't delete (no rights) to delete messed MR I ceased, don't like to bother _ikke_ much too with deleting mess 2019-09-24 06:45:31 I have a hope when git.a.o closes and primary repo move to gitlab.a.o it will be easier to work from cli, because in test phase of GL.a.o it worked fine 2019-09-24 06:48:39 @mps: https://i.imgur.com/sdMvsCT.png 2019-09-24 06:52:03 'mkmr'? resolution is low so not see it clearly 2019-09-24 06:56:27 btw, !90 is secfix? 2019-09-24 06:58:17 mps: it is an upgrade with security implications 2019-09-24 06:59:37 I think it have CVE assigned, should be added in commit msg 2019-09-24 07:06:45 yes, https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint&id=8dbe7b475ec5e91ed767239f0e85880f416fc384 2019-09-24 07:07:02 CVE-2019-5094 2019-09-24 07:09:06 yes, i am aware of which cve it is 2019-09-24 07:11:55 aha, shouldn't it then be mentioned in git commit msg 2019-09-24 07:12:07 If you say so 2019-09-24 07:17:13 not because I say, but nowadays it is 'best practice' to add CVE's info where we can and know for them 2019-09-24 07:21:33 maxice8: looks good :) 2019-09-24 07:22:58 and other MR's you posted looks fine 2019-09-24 09:42:09 hello, I have a question about aports mailing list. I see a lot of proposed patches, but almost never a patch actually applied. At the same time there is a site patchwork.alpineline.org which also doesn't seem to be updated. What is currently the process after a patch is submitted to aports mailing list? 2019-09-24 09:42:12 gitlab doesn't 'understand' newline in commit messages? 2019-09-24 09:42:54 kvtb: patchwork.a.o is retired 2019-09-24 09:43:43 Most patches on the aports mailing list are applied, they just don't show up as such yet 2019-09-24 09:43:43 and, patches from ML applied for sure, not all though, but most yes 2019-09-24 09:44:18 another question, if I create a patch that solves an issue in gitlab, and submit it to the aports mailing list, can I simply use Closes: #xxx to close the issue, or is there no link between aports ml and Gitlab issues? 2019-09-24 09:44:34 ok, thanks 2019-09-24 09:44:54 kvtb: fixes #issue_number 2019-09-24 09:45:45 maybe 'closes' also, but I never tested it 2019-09-24 09:46:36 ok - good to know I can refer to a Gitlab issue in a commit msg when sending a patch 2019-09-24 09:47:29 yes, that is good practice :) 2019-09-24 09:48:08 but you can create merge request directly on GL.a.o 2019-09-24 09:49:10 or on github pull request 2019-09-24 09:50:17 is there a preferred way for Alpine devs (mailing list vs merge/pull request) to handle patches? 2019-09-24 09:52:37 Each dev has it's own preference for providing patches, but it shouldn't matter to you which way they prefer to handle them from others 2019-09-24 09:52:46 Just use the way you prefer, mailing list or MR/PR 2019-09-24 09:52:56 officially no, but GH now have some preference, ime. but GL will be official git repo soon so it will be 'first class', I hope :) 2019-09-24 09:53:32 idea with GL is to consolidate all at one place 2019-09-24 09:54:06 OK - good to know 2019-09-24 09:57:16 GitHub and Gitlab have CI, so they're better IMHO 2019-09-24 09:57:32 At least I won't merge mailing list patches because I don't want to blow up the builders 2019-09-24 09:57:56 Once we have CI on the MLs that could change I guess 2019-09-24 09:59:10 Cogitri: ddevault told earlier that he works on add CI to ML 2019-09-24 09:59:36 Neat 2019-09-24 10:00:12 but as a user of ML I would prefer if can switch to one place, i.e. gitlab 2019-09-24 10:00:31 and forget about GH and ML 2019-09-24 10:22:51 Yup, one central place would certainly be nice 2019-09-24 10:23:02 Otherwise checking for duplicates and so on can be a bit tedious 2019-09-24 10:25:31 from new (and casual) contributer point of view, I agree 2019-09-24 10:27:54 well, bug/issue tracker is already moved 2019-09-24 10:28:13 Yup, to Gitlab 2019-09-24 12:22:28 mps: CI is being worked on, I'm writing patches for libgit2 and pygit2 towards that end now 2019-09-24 12:26:40 ddevault: ah, good, so my memory works ;-) 2019-09-24 12:27:11 the basic idea is going to be to add a git.sr.ht backend to pygit2, so it can read objects from git.sr.ht's repos remotely 2019-09-24 12:27:28 then we can teach lists about git, and it'll grow features like seeing more context from the diff or testing if a patch applies 2019-09-24 12:27:40 then it can fetch the .build.yml as well and submit it when emails come in 2019-09-24 14:59:57 Can someone take a look at !94 ? 2019-09-24 15:04:12 maxice8: wansnt there some commit regarding ulogd today? 2019-09-24 15:04:28 There was 2019-09-24 15:04:45 rnalrd (sorry can't write out his name correctly most of the time) added json support that was asked 2019-09-24 15:04:59 i did that in the merge request as well at first but now i just rebase 2019-09-24 15:05:59 maxice8: rnalrd 2019-09-24 15:06:38 you don't have nick tab completion in your irc client? 2019-09-24 15:07:51 i do if i prefix with @ but i didn't even bother to care to see if he/she was in here 2019-09-24 15:08:13 matrix i guess 2019-09-24 15:08:37 im looking at it 2019-09-24 15:08:40 what should i see? 2019-09-24 15:08:51 '@' is for channel OP's in irc 2019-09-24 15:08:57 yes i use the web riot.im 2019-09-24 15:09:18 i mean im looking at !94 2019-09-24 15:09:44 aha, I see, interesting you don't have [m] after your nick, as most of matrix users have 2019-09-24 15:10:10 it has services to auth you and change your nick 2019-09-24 15:10:35 You have to set your IRC nick manually to not have the [m] 2019-09-24 15:10:37 OT, I thought you are using 'real' irc client 2019-09-24 15:14:37 wow thats some time since i touch my buildenv 2019-09-24 15:15:28 <_ikke_> FYI, ci in Gitlab is ready to be enabled. !74 2019-09-24 15:15:46 Just to make sure it doesn't burn your computer because of a missing output plugin 2019-09-24 15:15:52 what are you waiting for? 2019-09-24 15:15:59 wait 2019-09-24 15:16:01 it wasn't already ? 2019-09-24 15:16:21 <_ikke_> To actually build apoegs 2019-09-24 15:16:21 i did find it weird that there was just lint pipeline on my MR 2019-09-24 15:16:31 <_ikke_> Aports 2019-09-24 15:16:48 <_ikke_> Yes, building aports was not ready yet 2019-09-24 15:16:54 to actually build the packages changed in the MR 2019-09-24 15:17:01 <_ikke_> Correct 2019-09-24 15:17:49 maxice8: you want me review that MR? 2019-09-24 15:17:59 Neat 2019-09-24 15:18:20 The tags are automatically added to the builders? 2019-09-24 15:18:45 clandmeter: if possible i also need someone with rights to main/ to push it 2019-09-24 15:19:09 i think you missed pkgrel bump? 2019-09-24 15:19:27 yes 2019-09-24 15:19:42 i forgot that rnalrd also bumped pkgrel to enable json 2019-09-24 15:19:55 i think i have permission to push to main 2019-09-24 15:20:00 or rather i did the first time but i used git am --con which screwed up the git REBASE process 2019-09-24 15:20:01 or somebody removed it 2019-09-24 15:20:14 so i rebase --abort and did it again and forgot the second time 2019-09-24 15:20:25 i can add it if you like 2019-09-24 15:20:31 problably because i was wondering why my script to make merge requests was failing 2019-09-24 15:20:34 clandmeter: pushed already 2019-09-24 15:21:06 that looks better :) 2019-09-24 15:21:15 Also, a more general question: We don't allow merged on gitlab, devs still pull changes from the merge request and then manually push it, right? 2019-09-24 15:21:19 s/merged/merges/ 2019-09-24 15:21:20 Cogitri meant to say: Also, a more general question: We don't allow merges on gitlab, devs still pull changes from the merge request and then manually push it, right? 2019-09-24 15:21:36 Also, do we have a bot for closing the MR on gitlab or do I need to do that manually? 2019-09-24 15:22:07 i havent touched the workflow on gitlab much, more focused on the internals atm. 2019-09-24 15:22:20 i think _ikke_ knows more about MR workflow 2019-09-24 15:22:33 i remember there was something missing for auto closing 2019-09-24 15:22:40 <_ikke_> For now manually 2019-09-24 15:22:43 <_ikke_> Yes 2019-09-24 15:22:48 we need to change origin 2019-09-24 15:22:50 Alrighty 👍 2019-09-24 15:22:57 when thats done we can do it from gitlab 2019-09-24 15:23:02 <_ikke_> You can only autoclose issues, not MRs 2019-09-24 15:23:14 Okie, thanks for the info 2019-09-24 15:23:26 i think changing origin will be soon 2019-09-24 15:23:36 soon ™️ 2019-09-24 15:23:54 <_ikke_> 😉 2019-09-24 15:24:39 nice news 2019-09-24 15:25:08 im trying to polish gitlab docker image a bit. 2019-09-24 15:25:56 that (tm) means valve time ? 2019-09-24 15:26:00 Another question: Is something like https://github.com/alpinelinux/aports/blob/6fc26139463834a2db2157ab4d688b0bbc6a9b49/non-free/yed/yed.install fine for non-free software? 2019-09-24 15:26:53 (That's pr11636) 2019-09-24 15:27:25 maxice8: valve time? 2019-09-24 15:27:47 https://developer.valvesoftware.com/wiki/Valve_Time 2019-09-24 15:28:14 never heard of it before :) 2019-09-24 15:28:21 valve is that gaming? 2019-09-24 15:29:14 valve is the company that makes that platform for online games, steam 2019-09-24 15:29:19 Yes, the dev of steam 2019-09-24 15:29:21 they also made Half-Life and Counter-Strike and Dota 2019-09-24 15:29:23 soon as i dont see many show stoppers to not switch 2019-09-24 15:29:25 Cogitri: is it free or non-free 2019-09-24 15:30:05 we need some free time to actually do the swtich. 2019-09-24 15:31:19 mps: You mean yed or steam? 2019-09-24 15:31:34 yed? 2019-09-24 15:31:41 maxice8: ok, i think i heard about it before, but im not a gamer... 2019-09-24 15:31:44 as I see it is non-free 2019-09-24 15:32:49 Cogitri: i dont understand your question 2019-09-24 15:32:56 reg yed 2019-09-24 15:34:00 it shouldn't go to testing, imo 2019-09-24 15:34:11 It's just echoing in post_install that you have to accept the license terms to use the thing 2019-09-24 15:34:38 It doesn't, it's going to non-free 2019-09-24 15:34:40 Cogitri: but its in testing or in non-free? 2019-09-24 15:34:41 The title just wasn't edited 2019-09-24 15:34:44 <_ikke_> Wasn't one showstopper that we cannot limit pushes to main? 2019-09-24 15:34:45 whatever, it is non-free 2019-09-24 15:34:57 _ikke_: its not a showstopper 2019-09-24 15:35:01 <_ikke_> Ok 2019-09-24 15:35:19 Cogitri: we dont care about non-free, so i would leave the msg. 2019-09-24 15:35:22 its not build 2019-09-24 15:35:46 Alrighty then, thanks 2019-09-24 15:36:07 if you build non-free things local you should know what you are doing. 2019-09-24 15:36:23 but thats my personal opinion 2019-09-24 15:37:04 _ikke_: its still an issue, but i remember we discussed it and ncopa agreed its something we can live with. 2019-09-24 15:37:28 <_ikke_> Ah OK, missed / forgot that 2019-09-24 15:37:40 could be it was in pm 2019-09-24 15:37:50 it was a few months ago 2019-09-24 15:37:55 memory is fading... 2019-09-24 15:41:57 maxice8: will ulogd still work without additional plugins installed? 2019-09-24 15:42:43 worked for me but i'd like more testers since i don't use ulogd 2019-09-24 15:42:58 so you want me to push it or not? 2019-09-24 15:43:22 i think in my usecase it should work 2019-09-24 15:44:17 well, better wait 2019-09-24 15:44:36 i dont mind breaking edge users 2019-09-24 15:44:51 just need to make sure it doesnt happen when branching 2019-09-24 15:45:03 or at least make it less painful :) 2019-09-24 15:45:15 i think i use it with awall 2019-09-24 15:45:25 to redirect kernel msgs to some logfile 2019-09-24 15:48:08 yes, edge users will have to install ulogd-$plugin that they use and it will also be the case once a new release is made 2019-09-24 15:50:51 maxice8: why did you split logemu? 2019-09-24 15:51:54 I split almost all of them 2019-09-24 15:52:07 i might go and also split the ones that don't depend on any other libs 2019-09-24 15:52:25 well they dont depend on only lib 2019-09-24 15:52:29 like logemu 2019-09-24 15:52:43 s/only/any 2019-09-24 15:52:44 clandmeter meant to say: well they dont depend on any lib 2019-09-24 15:53:26 graphite logemu and nacct 2019-09-24 15:53:40 i tried to upgrade chromium but it crashes. i may need some help to get a usable backtrace or coredump 2019-09-24 15:54:20 clandmeter: should keep them in or just split for size reduction ? 2019-09-24 15:54:52 i wouldnt split them cause they are 32kb 2019-09-24 15:55:02 and it would probably break more things as to fix things 2019-09-24 15:55:43 i think i use logemu 2019-09-24 15:56:05 its a common use case if you want to log to sep log file. 2019-09-24 15:56:20 ok i removed them from the split list 2019-09-24 15:57:19 maxice8: what about graphite? 2019-09-24 15:57:46 missed it 2019-09-24 15:57:47 i'll rebuild and see the traced deps 2019-09-24 15:58:27 removed 'pcap' as well 2019-09-24 15:58:54 right 2019-09-24 15:59:10 i think we can merge it now 2019-09-24 15:59:54 sounds good 2019-09-24 16:01:29 Can someone restart the Fractal build? Rust SIGSEGV'ed on most arches :/ 2019-09-24 16:01:54 Cogitri: you can do th at yourself 2019-09-24 16:02:02 algitbot: retry master 2019-09-24 16:02:09 Oh :o 2019-09-24 16:02:21 except if it hangs 2019-09-24 16:02:39 you can specifiy any branch 2019-09-24 16:02:53 not sure it works here or you need to do it in commits 2019-09-24 16:05:30 maxice8: can you close MR's? 2019-09-24 16:05:47 no 2019-09-24 16:06:09 i think we should change that 2019-09-24 16:06:26 :D 2019-09-24 16:06:58 ACTION opens his gitlab manual 2019-09-24 16:09:10 I think poster can close it's MR's 2019-09-24 16:09:40 at least I can close 2019-09-24 16:12:38 mps: can you enable 2FA? 2019-09-24 16:13:24 what I need for this, some secret key? 2019-09-24 16:13:54 nice :D 2019-09-24 16:13:56 or account on some public (well known) services 2019-09-24 16:14:06 https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html 2019-09-24 16:15:20 I read it earlier 2019-09-24 16:15:36 but 'Your browser doesn't support U2F. Please use Google Chrome desktop (version 41 or newer).' 2019-09-24 16:16:53 hmm this gitlab interface is spooky 2019-09-24 16:17:19 it doest need confirmation to switch between roles... 2019-09-24 16:17:30 maxice8: do you have more options now? 2019-09-24 16:18:03 Sorry am out of keyboard 2019-09-24 16:18:05 ah, looks like I can install freeotp from f-droid 2019-09-24 16:18:09 I can answer in a few hours 2019-09-24 16:18:31 Cogitri: and you? 2019-09-24 16:19:07 keep in mind that you should not push to gitlab on aports 2019-09-24 16:19:16 Won't do 2019-09-24 16:19:28 What options should I see now? :o 2019-09-24 16:19:34 Cogitri: can you now close other MR's? 2019-09-24 16:20:01 Yup 👍 2019-09-24 16:23:28 ah, found how to enable 2FA in firefox 2019-09-24 16:24:20 <_ikke_> Yes should work with firefox 2019-09-24 16:25:20 but now I have to install freeotp on phone 2019-09-24 16:25:43 mps: you can also try Aegis 2019-09-24 16:25:45 for android 2019-09-24 16:26:18 heh, aegis is first on list when searched for freeotp 2019-09-24 16:26:27 Yup, aegis is pretty good 2019-09-24 16:28:16 Yubikeys are good if you prefer hardware, I've had one on my keyring for a few years 2019-09-24 16:28:22 https://www.yubico.com/products/yubikey-hardware/ 2019-09-24 16:31:12 <_ikke_> Yeah, me too 2019-09-24 16:43:19 huh, looks like I have to create account on firefox site to use 2FA. right? 2019-09-24 16:46:20 <_ikke_> Why would that be necessary? 2019-09-24 16:47:26 2FA is TOTP or U2F for you? 2019-09-24 16:52:00 all guides about firefox 2FA shows that firefox account should be set 2019-09-24 16:53:45 <_ikke_> Isn't that for your Firefox account itself? 2019-09-24 16:54:18 <_ikke_> https://support.yubico.com/support/solutions/articles/15000017511-enabling-u2f-support-in-mozilla-firefox 2019-09-24 16:54:24 I don't understand, I never used public accounts on mozzila site 2019-09-24 16:54:39 You don't need a Mozilla account 2019-09-24 16:54:48 Actually, there isn't anything browser specific for TOTP 2019-09-24 16:55:06 aha, you give me hope 2019-09-24 16:55:07 <_ikke_> "As of version 67 Mozilla Firefox now has U2F enabled by default." 2019-09-24 16:55:25 <_ikke_> Yeah, TOTP is just a code you provide 2019-09-24 16:55:42 ahm, have to upgrade to edge 2019-09-24 16:55:52 <_ikke_> U2F requires browser support as it needs to communicate with a hardware token 2019-09-24 16:56:32 will it recognize phone with Aegis installed, and over USB 2019-09-24 16:57:20 <_ikke_> I don't think aegis supports u2f 2019-09-24 16:57:34 <_ikke_> It just generates totp's afaik 2019-09-24 16:59:01 I see TOTP and HOTP 2019-09-24 17:00:16 <_ikke_> Yes, so TOTP generates a new code every 30 seconds based on a shared secret 2019-09-24 17:16:07 eh, managed to login with 2FA, but still cannot close other MR's (don't intend to do this but there is no option) 2019-09-24 17:16:25 thank you all for help, btw 2019-09-24 17:31:18 so the redmine bug tracker is gone? 2019-09-24 17:31:27 i was going to report an issue with unbound in 3.10: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227 2019-09-24 17:32:07 i had to switch to edge repos in order to get the latest (hopefully fixed) version of unbound (im not entirely sure when they introduced the fix) 2019-09-24 17:34:07 https://github.com/NLnetLabs/unbound/blob/release-1.9.3/doc/Changelog unless im reading this wrong, it should have been fixed in 1.9.1 2019-09-24 17:34:18 <_ikke_> mps: now you should be able 2019-09-24 17:34:31 <_ikke_> wowaname: we switched to gitlab 2019-09-24 17:36:26 _ikke_: yes, now there is a button 'close merge request'. nice 2019-09-24 17:36:35 guess i'll just continue to haunt here and the mailing list then 2019-09-24 17:37:18 <_ikke_> wowaname: all issues were migrated to gitlab 2019-09-24 17:37:20 <_ikke_> gitlab.a.o 2019-09-24 17:37:32 accounts werent 2019-09-24 17:38:05 <_ikke_> Every account that made a contribution should've been migrated 2019-09-24 17:38:10 <_ikke_> though you'd have to reset your password 2019-09-24 17:38:17 oh 2019-09-24 17:38:34 makes sense 2019-09-24 17:39:56 thanks 2019-09-24 17:40:22 <_ikke_> np 2019-09-24 17:41:28 im stubborn about making new accounts for bug trackers anymore, wish there was a good first-class email-based tracker 2019-09-24 17:41:30 im one of those people 2019-09-24 17:42:07 <_ikke_> If you have a github account, you could use that as well with gitlab 2019-09-24 17:42:36 wowaname: quite understand your feelings 2019-09-24 17:42:55 my github account's long gone 2019-09-24 17:43:20 thats perhaps the main reason im one of those people, because github has left a bad taste in my mouth 2019-09-24 17:43:36 but how the spam is everywhere I understand admins of bug report sites 2019-09-24 17:43:41 people who refuse to take patches via email and demand to use their github PR workflow 2019-09-24 17:43:57 yeah i saw some of the spam the AL bug tracker was getting 2019-09-24 17:44:13 this is why we cant have nice things 2019-09-24 17:45:51 even void linux is dead set on using github for its backbone; one of a few reasons im gonna try to migrate my laptop to another distro when i get time lol 2019-09-24 17:46:11 i gave void a fair shot, i'll say that, but i'm beginning to see what's wrong with it 2019-09-24 17:46:34 yes, I have patches locally for some really used software but didn't posted because upstream only accept them over github 2019-09-24 17:47:22 anyway yeah im not sure if unbound 1.9.3 fixes the issue im having, but i linked the original bug report above which has a patch if that's good enough to be backported 2019-09-24 17:47:40 i assume thats what the "stable" alpine releases do, they pick some software versions and just release bug fixes 2019-09-24 17:47:57 ive never paid much attention 2019-09-24 17:48:47 mps: i'd do that but i didnt start using void to learn their package management. i know alpine's, and if i wanted to learn another i'd probably go all in with gentoo's PMS 2019-09-24 17:48:54 void isnt worth my trouble lol 2019-09-24 17:48:57 bug fixes usually backported to latest stable 2019-09-24 17:49:23 i've actually cared about making alpine better so i decided it was a good thing to invest some time in 2019-09-24 17:49:35 gotcha, thats what i thought 2019-09-24 17:50:08 secfix are backported to LTS's 2019-09-24 17:50:14 i'd have to check out 3.10-stable in aports and apply to that? 2019-09-24 17:50:27 right 2019-09-24 17:50:33 good stuff 2019-09-24 17:52:21 but only in main and community repos 2019-09-24 17:52:47 testing is never 'stable' 2019-09-24 17:54:48 <_ikke_> clandmeter: You think I can just merge the MR for gitlab CI? 2019-09-24 17:55:58 Yes 2019-09-24 17:56:05 <_ikke_> ok 2019-09-24 17:57:58 <_ikke_> p00f 2019-09-24 18:11:11 mps: well testing doesnt exist in the stable releases anyway, so i knew that lol 2019-09-24 18:11:59 good, just wanted to remind you in case you don't know this 2019-09-24 18:14:02 unbound is in main 2019-09-24 18:32:00 <_ikke_> !100 :-) (now with CI build) 2019-09-24 18:35:20 aieee! time to open red wine bottle ;-) 2019-09-24 18:35:29 https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/911 2019-09-24 18:49:51 clandmeter: back 2019-09-24 18:52:58 Does the -dbg subpackage contain the debug info of the package's subpackages too? 2019-09-24 18:54:18 good question actually 2019-09-24 18:54:25 i think i was wondering this a while ago 2019-09-24 19:07:51 <[[sroracle]]> it depends on the ordering of the contents of $subpackages. i can't remember if it was fixed or not to always put -dbg first (and thus include all subpackages) 2019-09-24 19:08:09 <[[sroracle]]> with DEFAULT_DBG it is first anyway 2019-09-24 19:10:40 clandmeter: i was able to closed a few MRs that were already merged 2019-09-24 19:11:40 <_ikke_> maxice8: good 2019-09-24 19:26:13 <_ikke_> mps: was the glm MR ready yet? 2019-09-24 19:28:29 no, and yes 2019-09-24 19:28:34 <_ikke_> ok 2019-09-24 19:29:23 didn't had time today because of $day_job. maybe before going to sleep 2019-09-24 19:29:30 <_ikke_> sure, np 2019-09-24 19:29:34 <_ikke_> no hurry 2019-09-24 19:30:29 actually I have issue, created patch with 'git format-patch -1' and then 'git am patch' doesn't work 2019-09-24 19:30:41 <_ikke_> hmm, ncurses uses makedepends_build, but that seems to be an internal variable 2019-09-24 19:30:47 something about tabs and spaces 2019-09-24 19:31:19 Different line ending formats are annoying :/ 2019-09-24 19:31:25 about ncurses, there is newer release 2019-09-24 19:31:51 <_ikke_> I'm looking at the MR 2019-09-24 19:31:58 Cogitri: yes, I think this is because of CRLF to LF changes 2019-09-24 19:32:07 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/58/ 2019-09-24 19:32:22 I'm out right now 2019-09-24 19:32:35 will be back in about 45 minutes 2019-09-24 19:34:04 I can prepare new MR for ncurses later, but this one is good also, tested build on x86, x86_64, armv7 and aarch64 2019-09-24 19:34:26 so, _ikke_ , do what you think is ok with it 2019-09-24 19:34:51 <_ikke_> I merged it 2019-09-24 19:35:01 ah, ok 2019-09-24 19:35:41 I'm on their ML, and in last time they release often new versions 2019-09-24 19:36:08 usually small fixes, nothing serious or big changes 2019-09-24 19:41:18 why is mongodb not in the alpine repos? 2019-09-24 19:42:08 nicolaus: license chaned, iirc 2019-09-24 19:42:08 <_ikke_> It's in non-free 2019-09-24 19:42:16 ohhhh I didnt know that 2019-09-24 19:42:26 non-free/ 2019-09-24 19:42:57 guess I'll learn some other program now haha 2019-09-24 19:43:48 I have lots of Pull requests to drop python2 for stuff on main 2019-09-24 19:43:57 can someone take a look and merge some ? :D 2019-09-24 19:44:07 <_ikke_> I'll look at them later 2019-09-24 19:44:11 https://github.com/alpinelinux/aports/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+%22drop+py2%22 2019-09-24 19:44:13 <_ikke_> (tomorrow probably) 2019-09-24 19:45:26 Thanks 2019-09-24 19:49:19 nice that py2's being phased out 2019-09-24 19:50:30 Yup 2019-09-24 20:21:07 _ikke_: pushed glm. I did best what I can now. Will look if issues reported or something fail to build because of it and will try to fix 2019-09-24 20:21:55 <_ikke_> (y) 2019-09-24 23:54:35 PureTryOut: can you check out !117 2019-09-25 03:06:32 Hi team, I've been working on some PRs and something really interesting has popped up regarding Alpine and Java 2019-09-25 03:06:58 Seems Alpine OpenJDK is ~10% slower that glibc based OpenJDK on the same hardware and configuration 2019-09-25 03:07:07 Details in https://github.com/DependencyTrack/dependency-track/pull/420 2019-09-25 04:17:10 And Azul's zulu flavour of OpenJDK is significantly faster than Alpine's. Maybe we could use Azul as upstream? It is an open source distribution. 2019-09-25 05:38:14 would be nice to track down why openjdk is slower, fixing those would likely make other things faster as well 2019-09-25 10:04:14 hey guys, out of interest what is the process for deciding which PRs get merged and which don't. Is it random or is there reason to it? 2019-09-25 10:05:31 just wondering as I've got some PRs hanging around from about a week ago whilst other more recent ones get merged 2019-09-25 10:06:27 Well, stuff to main/ needs to be reviewed/merged by someone who has access to main, so some people (e.g. me) can't do that 2019-09-25 10:07:21 We don't have a standardized review process AFAIK, so I just pick interesting ones by chance 2019-09-25 10:07:58 I try to not let stuff sit around so much, but I only have so much time :c 2019-09-25 10:09:32 I look at bugs/issue first and then look for PR/MR which solves issue 2019-09-25 10:10:56 when I'm talking about issues, #10821 2019-09-25 10:11:37 anyone with deeper understanding lxc would look at it 2019-09-25 10:15:43 fair enough, not complaining, just trying to understand 2019-09-25 10:17:05 secfixes and bugfixes have priority usually 2019-09-25 10:17:30 then comes feature requests 2019-09-25 10:18:29 you know you were getting things set up yesterday on gitlab. Are you going to stop accepting PRs on github and moved to MRs on gitlab? 2019-09-25 10:19:00 I use gitlab for work so it doesn't really matter so much to me 2019-09-25 10:19:15 ACTION would preffer that ;-) 2019-09-25 10:20:49 my support for sending patches over ML was based on premise that the gitlab can accept 'git send-email' 2019-09-25 10:21:36 Wait, Gitlab supports sending patches via mail? 2019-09-25 10:22:04 yes, but not sure if CE or just EE 2019-09-25 10:22:56 TBH, never used it but read somewhere that it support it 2019-09-25 10:24:58 https://docs.gitlab.com/ce/user/project/merge_requests/#create-new-merge-requests-by-email suggests it is in CE 2019-09-25 10:26:08 ah, yes, I read this, thanks for reminder 2019-09-25 10:39:13 Awesome thanks for the link! 2019-09-25 10:43:01 for someone who's never bother with, git + email whats the appeal? just the fact you can do everything from the cli? 2019-09-25 10:45:43 For me mainly that yeah. Also, not having to fork repositories 2019-09-25 10:46:54 there is 'lab' package for interacting with gitlab from cli 2019-09-25 10:47:07 I also like sr.ht quite a lot, which is based on git + email. No javascript required which is awesome 2019-09-25 10:47:29 Uh git.sr.hit I mean 2019-09-25 10:47:34 *git.sr.ht 2019-09-25 10:47:50 and maxice8 working on better cli for gitlab, hope he will release something RSN 2019-09-25 10:48:54 I like how that lab project has the website hosted on GitHub while it's a wrapper for Git_Lab_ 2019-09-25 10:54:07 pr11547 should probably have a security label... 2019-09-25 10:56:14 Hmm I don't see the button to get the email address for the Gitlab instance? 2019-09-25 10:56:29 thanks for mentioning that lab tool. Looks like something that will be useful for work. 2019-09-25 10:56:36 Is https://docs.gitlab.com/ce/administration/incoming_email.html enabled? 2019-09-25 11:36:52 mps: I just use mkmr 2019-09-25 11:37:06 Uses the gitlab v4 API to make the merge request 2019-09-25 11:38:07 didn't you created this 'mkmr' tool? 2019-09-25 11:58:50 i managed to get chromium 77 working, more or less 2019-09-25 11:59:13 there was a couple of syscalls that needed to be allowed in the sandbox 2019-09-25 13:04:45 mps: yes 2019-09-25 13:05:46 https://raw.githubusercontent.com/maxice8/meltryllis/master/bin/mkmr 2019-09-25 14:22:31 Out of curiosity, could anyone suggest the best way to handle softlinks in APKBUILDs? Not sure if there's anything special that should be done or if I can just call ln in the package segment 2019-09-25 14:25:18 wsinatra: maybe "grep -r 'ln -s' main/" could give you idea 2019-09-25 14:25:31 softlinks? 2019-09-25 14:26:03 softlinks? I missread to symbolic links 2019-09-25 14:26:14 ln -s 2019-09-25 14:26:28 Oh symlinks 2019-09-25 14:26:41 yeah just softlinks, +1 to mps for the obvious answer though 2019-09-25 14:26:44 so, soft or symbolic :p 2019-09-25 14:34:28 quick grep shows exactly what I was looking for, thanks gents. I think my brain isn't firing all of its pistons correctly this morning 2019-09-25 14:34:57 mps: mkmr sadly depends on libsecret 2019-09-25 14:35:13 no idea where to safely store the gitlab access token needed to make the API call 2019-09-25 14:35:37 maxice8: yes, I noticed. but anyway writing anything useful today end in a lot of deps 2019-09-25 14:36:25 anyways it is easy to just hard-code your own token instead of setting up a org.freedesktop.secrets provider like gnome-keyring 2019-09-25 14:37:18 what I do for some of my tools ;-) 2019-09-25 14:39:15 i just pushed new edge snapshot release 2019-09-25 14:39:54 I see, you don't write notes for edge snapshots? 2019-09-25 14:47:41 speaking of taking notes 2019-09-25 14:47:55 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas) 2019-09-25 14:52:43 maxice8: could you merge https://lists.alpinelinux.org/~alpine/aports/patches/3063 and https://lists.alpinelinux.org/~alpine/aports/patches/3062 as well? Seems you've missed them 2019-09-25 14:56:25 Sure but later 2019-09-25 14:56:49 Am at subway 2019-09-25 14:58:48 The sandwich store not the place where train go but underground 2019-09-25 15:18:11 Anyone mind looking over PR #11636 for me? I'd like to get it merged and a few other packages submitted today 2019-09-25 15:20:03 wsinatra: this is non-free, why it have to go to testing and not to non-free 2019-09-25 15:23:22 I actually changed it over to non-free, or thought I had done so. Cogriti had pointed that out earlier 2019-09-25 15:23:55 The actual commit is in non-free/yed, but I started the PR as testing/yed mistakenly 2019-09-25 15:25:27 ah, so, I didn't looked last change 2019-09-25 15:26:13 It's all good, I feel like my commits can be a bit cluttered sometimes because I constantly have to squash and repush for silly errors 2019-09-25 15:34:51 Oh, hacktoberfest is approaching! 2019-09-25 15:34:57 time to work out some patches 2019-09-25 15:35:45 <_ikke_> https://github.com/gregkh/presentation-cve-is-dead/blob/master/abstract.txt apparently a talk where gregkh talks about CVE relevance in Linux Kernel development 2019-09-25 15:40:08 reading his commit messages for kernels I also started to think about CVE's as artifacts of 'security theater' 2019-09-25 15:40:35 mps: because thats what they are 2019-09-25 15:41:08 if you think about it, 'look! we are doing important work here!'-signalling isn't that rare with humans 2019-09-25 15:41:36 and, don't forget this is money for some 2019-09-25 15:41:49 thats worse actually 2019-09-25 15:41:53 <_ikke_> And putting to much focus on CVE's can distract you from important things 2019-09-25 15:42:24 agree fully 2019-09-25 15:42:39 <_ikke_> One argument from kernel developers is that bug fixes may turn out to fix security issues without being marked as such 2019-09-25 15:43:12 <_ikke_> So if you only backport fixes with CVE's, you might miss important security fixes 2019-09-25 15:43:57 true, yesterday I looked at postfix anounce, no CVE but one of fixes looks like it could be sec risk 2019-09-25 15:44:19 also, people are so obsessed with outside attackers as threat 2019-09-25 15:44:29 thought to make MR later today 2019-09-25 15:44:35 what about race conditions that result in data corruption? 2019-09-25 15:44:56 if they are silent, they might be a existential risk to a company if its in the wrong place 2019-09-25 15:45:51 yes, imagine this 3 months silence, 3 months we are at risk while some knows that and do not inform us 2019-09-25 15:46:05 meh 2019-09-25 15:46:56 <_ikke_> Another argument is that by be very picky in what you backport is that you deviate further and further from the mainline 2019-09-25 16:44:00 ah, there is postfix PR already, https://github.com/alpinelinux/aports/pull/11588 2019-09-25 16:44:08 saved me some time :) 2019-09-25 17:19:02 Ok back 2019-09-25 17:19:16 @PureTryOut https://lists.alpinelinux.org/~alpine/aports/patches/3063 already applied 2019-09-25 17:19:47 @PureTryOut https://lists.alpinelinux.org/~alpine/aports/patches/3062 is krita which was known to cause problems on Void Linux musl, i'd rather run it through CI first 2019-09-25 17:19:50 Oh huh, sorry 2019-09-25 17:19:57 Oh sure, I'll make a Gitlab MR then 2019-09-25 17:54:01 <_ikke_> Anyone knows of makedepends_build should be used by APKBUILDs? 2019-09-25 17:54:47 <_ikke_> It being referenced without ever being defined in abuild.in seems to imply so, but it's apparently not documented 2019-09-25 17:57:00 also I wonder about it's use 2019-09-25 17:57:32 <_ikke_> Seems to have to do with cross compiling 2019-09-25 17:58:47 <_ikke_> quite a few packages that use it 2019-09-25 18:02:44 I think we use it for packages needed for bootstrapping new arches 2019-09-25 18:03:48 <_ikke_> yes, I kind of figured 2019-09-25 18:39:39 gitlab CI is not activated for stable release? 2019-09-25 18:53:32 <_ikke_> No, I can backport it though 2019-09-25 18:55:24 well, it is not important (at least for now) to me, just noticed 2019-09-25 19:04:26 hey, does anyone care to weigh in on PR #11650 ? 2019-09-25 19:09:39 jjsearle_: I understand you're eager to get your work merged and do feel free to ask about PR which have been stale for a few days, but maybe don't ask about PRs which you only filed yesterday, I'm sure someone will look at it soon 2019-09-25 19:10:43 some of my MR's stays few weeks 2019-09-25 19:11:47 Yes, sadly PRs to main/ take frankly way too long until they're getting merged 2019-09-25 19:11:58 Cogitri there is a slight disagreement about the way to do things, I am trying to understand which is correct before I make the same changes in any future PRs and have to waste time correcting them 2019-09-25 19:12:06 But most stuff in main should be moved to community anyway, I suppose 2019-09-25 19:12:11 I am not asking for it to be merged now 2019-09-25 19:12:31 Ah, okie. Feel free to ask about that stuff then :) 2019-09-25 19:12:35 Cogitri: some, I think 2019-09-25 19:13:19 jjsearle_: Sorry, am kinda sleepy right now :P 2019-09-25 19:13:37 <_ikke_> Cogitri: Personally I'm usually a little more conservative regarding to main 2019-09-25 19:13:45 <_ikke_> s/little/little bit/ 2019-09-25 19:13:45 _ikke_ meant to say: Cogitri: Personally I'm usually a little bit more conservative regarding to main 2019-09-25 19:14:31 <_ikke_> But I agree that we don't want to keep things open for weeks 2019-09-25 19:14:39 Well, I don't have a problem with stuff being in main 2019-09-25 19:14:49 I have a problem with PRs rotting for months because no one with the necessary bit has time to look at it 2019-09-25 19:14:58 it is regarding the use of $pkgname in the source url. I have been removing it, as is suggested by maxice8's apkbuild-lint tool. 2019-09-25 19:14:59 <_ikke_> Cogitri: I agree that things can be moved out of main 2019-09-25 19:15:08 is there an offical stance on this? 2019-09-25 19:15:30 (Not meaning to sound accusatory here. But people who have access to main/ also only have so much time) 2019-09-25 19:15:38 <_ikke_> jjsearle_: It was added after discussing it here 2019-09-25 19:16:09 jjsearle_: We don't have an official standard right now since our docs for that are still WIP, but at least in this channel we mostly agreed that it's better to not use $pkgname in the URL 2019-09-25 19:16:29 Although in retrospective I'm unsure if this nitpicking really is useful :/ 2019-09-25 19:16:52 okay, I will continue removing it 2019-09-25 19:17:15 few weeks ago we disscused this and conclusion was to not use var ($pkgname) but name, as _ikke_ pointed 2019-09-25 19:17:33 Yup 2019-09-25 19:17:52 thanks 2019-09-25 19:17:53 personally I don't mind 2019-09-25 19:19:10 <_ikke_> In general I don't mind, but in this case there are a few reasons that make me think it's better to avoid it 2019-09-25 19:19:19 its not that I have any opinion on it either way. I just don't want to have to change a bunch of PRs just because of differing opinions 2019-09-25 19:20:43 <_ikke_> I think apkbuild-lint generally covers the consensus of coding style 2019-09-25 19:20:50 <_ikke_> (and what's documented) 2019-09-25 19:23:00 <_ikke_> Personally I feel we should aim for a unified code style across aports to make it easier for everyone to contribute 2019-09-25 20:07:25 alpine has s390x packages? wow 2019-09-25 20:07:36 <_ikke_> 0yes 2019-09-25 20:07:45 who's got one of those in their basement? ;) 2019-09-25 20:08:08 <_ikke_> They sponsor us hosted hardware 2019-09-25 20:08:14 cool! 2019-09-25 20:08:16 IBM does? 2019-09-25 20:08:52 <_ikke_> Yes, they do 2019-09-25 20:08:54 do you know of anyone using it? 2019-09-25 20:08:59 <_ikke_> no 2019-09-25 20:09:27 <_ikke_> Well, I guess tmhoang is using it 2019-09-25 20:09:53 I wonder if I could steal some space on a work machine to try it 2019-09-25 20:21:59 <_ikke_> ahills: apparently they have a program called Linux Test Drive where you can get a VM for 30 days 2019-09-25 20:22:44 nice, thank you for the info 2019-09-25 20:23:37 <_ikke_> I was reading the wiki page because I got curious about it 2019-09-25 20:24:04 <_ikke_> I've never worked with mainframes, so it's kind of alien to me 2019-09-25 20:25:26 they don't list alpine in the question about linux distributions, and there's no "other", so I'm not sure it'd be possible to swap it out 2019-09-25 20:25:35 (looks like it comes preinstalled, I mean) 2019-09-25 20:49:04 how to set/export empty variable in ash (busybox sh) in APKBUILD 2019-09-25 20:51:07 <_ikke_> export FOO= 2019-09-25 20:52:20 with '=' after? 2019-09-25 20:52:51 looked at perl APKBUILD, it 'export FOO' 2019-09-25 20:53:20 <_ikke_> That would export an existing variable 2019-09-25 20:53:39 ah, so, thanks 2019-09-25 20:53:50 <_ikke_> That's not specific to ash btw 2019-09-25 20:53:55 <_ikke_> that's common shell behaviour 2019-09-25 20:54:21 <_ikke_> You see in the perl the APKBUILD first sets variables, and then exports them 2019-09-25 20:55:01 yes, make sense. I'm not versed in shell programming 2019-09-25 20:55:20 perl is for my 'shell' scripts 2019-09-25 21:08:36 How do you decide if something from `testing` goes to `main` or `community`? 2019-09-25 21:09:40 <_ikke_> PureTryOut[m]: upstream support for one 2019-09-25 21:09:56 and active maintainer 2019-09-25 21:10:46 Both of those seem logical, and also good requirements to move it to `community` lol 2019-09-25 21:11:38 <_ikke_> packages in main are supported by alpine for 2 years, so upstream should have at least 2 years support of that specific major version 2019-09-25 21:12:29 and 'main' is for essential and base pkg's. some should be moved to community 2019-09-25 21:12:53 So if a package has continious releases (e.g. every 2-3 weeks) and doesn't support an older version when a new one is released, `community` is the only place it can go too? 2019-09-25 21:13:04 <_ikke_> PureTryOut[m]: yea 2019-09-25 21:13:13 Ok thanks for the info 2019-09-25 21:13:52 servers, compiler and similar also belongs to main 2019-09-25 21:14:09 but IRC clients ;-) 2019-09-25 21:14:25 <_ikke_> A lot is still there because community didn't exist yet and no one bothered to move it yet 2019-09-25 21:15:05 like void linux 2019-09-25 21:15:39 everything is in one repo 2019-09-25 22:20:09 that sounds a bit odd when the other thing I've heard is only security patches go into stable branches, so you require an upstream to support a release for 2 years, but only actually use security patches (which generally are pretty trivial to backport) 2019-09-25 23:28:07 @_ikke_ out of curiosity would CLISP be eligible for main/ then? It's on the last release that will likely ever happen? SBCL has releases every month, but I would say might fall into the "compiler" category, would something like that be eligible for main/ as well? 2019-09-26 03:07:56 _ikke_: any progress on those py3- PRs ? 2019-09-26 08:32:45 dbg or gcc is broken 2019-09-26 08:32:59 gdb does not show C sources 2019-09-26 08:33:02 i dont know why 2019-09-26 08:37:00 Hm, I think it works for me 2019-09-26 08:37:01 Does it show something along the lines of "loading debug info....done" when you start gdb? 2019-09-26 08:39:58 no 2019-09-26 08:40:08 For help, type "help". 2019-09-26 08:40:08 Type "apropos word" to search for commands related to "word"... 2019-09-26 08:40:08 Reading symbols from hello... 2019-09-26 08:40:08 (gdb) 2019-09-26 08:42:20 gdb 8.3.1 2019-09-26 08:42:24 Ah :c 2019-09-26 08:42:36 gcc (Alpine 9.2.0) 9.2.0 2019-09-26 08:42:51 At least with stuff I've compiled myself it definitely worked 2019-09-26 08:42:59 That was with clang though 2019-09-26 08:43:00 I'll try later 2019-09-26 08:43:46 youre right 2019-09-26 08:43:49 it works with clang 2019-09-26 08:43:52 but not gcc 2019-09-26 08:45:35 'GNU gdb (GDB) 8.3.1' on aarch64, edge works 2019-09-26 08:48:58 and gcc version? 2019-09-26 08:49:52 cc (Alpine 9.2.0) 9.2.0 2019-09-26 08:50:24 how can I check with wich version of gcc gdb is built 2019-09-26 08:50:42 i dont think gdb is broken 2019-09-26 08:50:52 i think its gcc that generates wrong -g 2019-09-26 08:51:10 Odd 2019-09-26 08:51:46 yup, aarch64 works 2019-09-26 08:52:55 32 bit x86 2019-09-26 08:53:27 right now I can check only on aarch64 2019-09-26 08:53:43 huh 2019-09-26 08:54:21 Temporary breakpoint 1, main () at hello.c:5 2019-09-26 08:54:21 5 printf("hello world\n"); 2019-09-26 08:54:21 (gdb) 2019-09-26 08:54:30 so it works on x86_64 too 2019-09-26 08:54:38 it must be something on my desktop 2019-09-26 08:55:26 Hello everyone, I'm writing here because I'm doing something wrong but I do not understand exactly what. I have read it the page https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package but still is not obvious to me how can I fix the error. 2019-09-26 08:55:45 zarch: whats the error message you get? 2019-09-26 08:56:57 I would like to add GRASS GIS package to alpine, here my attempt: https://github.com/zarch/aports/commit/6a79458773134d7369f600f0046966179efa4416 to define the APKGBUILD file. 2019-09-26 08:58:55 seems like reinstalling the packages on my machine solved my gcc issue. (apk info -q | sudo xargs apk fix) 2019-09-26 08:59:24 Uploaded file: https://uploads.kiwiirc.com/files/d81ba0cdb354d9e94243e729879887ff/pasted.txt 2019-09-26 08:59:36 ncopa, I can compile without errors with `abuild -r build` but I failed when I do: `abuild package` 2019-09-26 09:02:32 zarch: /bin/sh: can't create /usr/bin/grass78: Permission denied 2019-09-26 09:02:45 it tries to install in / rather than "$pkgdir" 2019-09-26 09:04:26 what happens if you do: abuild rootpkg? 2019-09-26 09:04:34 dhooo! ok, I see...@ncopa... thank you! 2019-09-26 09:04:52 i think you cannot run `abuild package` like that 2019-09-26 09:05:01 it needs to be done via `abuild rootpkg` 2019-09-26 09:05:15 which will run it in fakeroot, and do the package spelitting 2019-09-26 09:05:28 ok, I'm going to try it 2019-09-26 09:18:50 <_ikke_> ncopa: I run abuild package all the time 2019-09-26 09:19:08 also I do 2019-09-26 09:38:17 ok 2019-09-26 11:03:22 ahills, _ikke_: Alpine s390x images used wherever Alpine image is used on s390x machines (well, obviously ...) I don't have exact number but there are people using it intensively. Most of them just ignore the fact that they have Alpine containers running in their apps/infra, thanks to their ignorance. 2019-09-26 11:05:08 Efforts have been put to upstream s390x patches to Kubernetes. They were ready long ago in some products but mostly as internal patches. 2019-09-26 11:07:35 tmhoang: nice, I figured containers would be an easier entrypoint there; does the docker registry support multiple arches now, or is there some other place to find alpine-based s390x images? 2019-09-26 11:08:02 <_ikke_> ahills: it does support it by means of manifests 2019-09-26 11:08:07 ok 2019-09-26 11:08:16 <_ikke_> the alpinelinux images are available for s390x 2019-09-26 11:09:42 ahills: you can request for s390x VM/apps, etc. in here 2019-09-26 11:09:43 https://developer.ibm.com/linuxone/ 2019-09-26 11:09:59 from above link : for VM : https://developer.ibm.com/linuxone/request-vm/ 2019-09-26 11:10:12 kubernetes-based cluster : https://developer.ibm.com/linuxone/request-icp/ 2019-09-26 11:10:26 so on for blockchain - whatever it is 2019-09-26 11:11:33 I don't think they have Alpine VM, only RHEL + SLES. There were some Ubuntu but I don't quite remember. 2019-09-26 11:21:50 right, but hopefully I could run an Alpine container on RHEL easily 2019-09-26 11:22:02 ahills : yes 2019-09-26 11:22:26 you can actually run s390x emulation on qemu x86 2019-09-26 16:10:07 is it ok to add $CTARGET in source field of APKBUILD? example: https://dev.alpinelinux.org/archive/crystal/crystal-$_bootver-$CTARGET.tar.gz 2019-09-26 16:11:08 that way builders will download only one version of prebuilt tarball, not all 2019-09-26 16:25:59 <_ikke_> Should be an issue I guess 2019-09-26 16:27:14 why? already have $_bootver for long time 2019-09-26 16:27:32 <_ikke_> Sorry, should not 2019-09-26 16:27:46 ahhh, thanks 2019-09-26 16:27:56 :) 2019-09-26 16:29:49 I looked at community/rust, it have 3 such things for now, and it has to download all of them on every build 2019-09-26 16:31:05 <_ikke_> What was the reason again that crystal cannot use a previously built version to build itself? 2019-09-26 16:31:07 about 150MB on every build 2019-09-26 16:31:50 _ikke_: you remember that we (you and me) started to fix it about 6 months ago but we didn't finish 2019-09-26 16:32:08 time issue, I think 2019-09-26 16:32:08 mps: Was only required for bootstrapping, I'll remove them with the incoming version bump :) 2019-09-26 16:32:47 Cogitri: I'm not criticize you, just noted 2019-09-26 16:33:39 Yup, just wanted to point out that that's going to change too 2019-09-26 16:33:41 I understand your reason, but will try also to change rust APKBUILD with $CTARGET for these files 2019-09-26 16:34:04 if you don't mind or you will change, ofc 2019-09-26 16:36:06 Thode tarballs will be removed in a few days anyway, so I don't think we have to change that 2019-09-26 16:36:34 ok, understand. And thanks for good news :) 2019-09-26 16:37:50 anyway, this can't be done, i.e. using $CTARGET because of calcuting 'abuild checksum' 2019-09-26 17:00:20 xut 2019-09-26 17:19:05 <_ikke_> maxice8: apparently ncopa merged a bunch of PRs, but they weren't automatically closed 2019-09-26 17:26:20 ohm, upgraded lm-sensors (3.5.0) is a lot better 2019-09-26 18:19:37 _ikke_: oh ? 2019-09-26 18:19:43 also, which dependencies of py3-urwid are missing ? 2019-09-26 18:19:46 i saw nothing on requires 2019-09-26 18:23:01 <_ikke_> maxice8: Seem to be downstream deps that abuild cannot find 2019-09-26 18:23:26 well abuild doesn't track python dependencies 2019-09-26 18:23:27 <_ikke_> py3-pyhamcrest, py3-hyperlink, py3-automat 2019-09-26 18:23:47 <_ikke_> https://pkgs.alpinelinux.org/packages?name=*pyhamcrest&branch=edge 2019-09-26 18:24:20 <_ikke_> required by: py3-twisted-19.2.1-r2[py3-pyhamcrest] 2019-09-26 18:25:08 oh that is because they are in community and are for py3-twisted 2019-09-26 18:25:12 i have a PR for moving them to main 2019-09-26 18:25:51 pr11553 2019-09-26 18:27:56 <_ikke_> Would it make more sense to move py3-twisted to community? 2019-09-26 18:28:15 <_ikke_> A cursory glance didn't reveal an important package depending on twisted 2019-09-26 18:28:36 sure 2019-09-26 18:28:44 i can make an mr to move it to main/ 2019-09-26 18:28:58 there is openvswitch 2019-09-26 18:29:24 and py-urwid will have to be moved to community as well or lose its check 2019-09-26 18:30:03 <_ikke_> yup 2019-09-26 18:30:04 well we can move py3-twisted + openvswitch + py3-urwid + py3-configshell (depends on py3-urwid) 2019-09-26 18:30:28 <_ikke_> What is the openvswitch dependency? 2019-09-26 18:30:31 <_ikke_> I only see py-six 2019-09-26 18:30:46 i'll make an MR and assign to you on g.a.o 2019-09-26 18:31:11 <_ikke_> ah, openvswitch-test 2019-09-26 18:31:16 makedepends and in the depends of the _test() function 2019-09-26 18:31:22 so openvswitch-test (that uses _test()) should depend on twisted 2019-09-26 18:31:27 <_ikke_> yes, I saw 2019-09-26 18:33:22 !154 2019-09-26 18:35:02 <_ikke_> Hmm, the maintainer is not on gitlab 2019-09-26 18:36:36 <_ikke_> Oh, they are 2019-09-26 19:11:13 _ikke_: he approved 2019-09-26 19:14:45 <_ikke_> ok, good 2019-09-26 19:59:28 PureTryOut: can't find you on gitlab.a.o 2019-09-26 19:59:43 !166 2019-09-26 20:00:41 <_ikke_> maxice8: Apparently gitlab only autocompletes the names of users that have parcipated in the project before 2019-09-26 20:01:22 <_ikke_> maxice8: It's just @PureTryOut 2019-09-26 20:04:49 Yes, that weirded me out for a sec too 2019-09-26 20:05:29 oh 2019-09-26 20:29:50 I was about to say, it's what you expect my nickname to be :p 2019-09-26 22:43:22 So yeah i dropped more py2 stuff on GitLab 2019-09-26 22:45:27 Need testers for !177 2019-09-26 23:05:27 _ikke_: tagged you on a few py2 drop MRs and on redo-c 2019-09-27 05:12:42 Cogitri, are you there? 2019-09-27 05:41:43 Sodomon: Yes 2019-09-27 05:43:08 Well I wanted to tell you that I already did another PR, and you told me that when a PR came up I would give you a ping. 2019-09-27 05:45:10 Ah yes, I meant a ping on GitHub though :) 2019-09-27 06:41:24 _ikke_: is the redo-c MR ok ? 2019-09-27 06:41:56 <_ikke_> I have not checked it yet 2019-09-27 06:42:44 ok 2019-09-27 07:38:42 200th MR reached 2019-09-27 07:39:08 <_ikke_> \o/ 2019-09-27 07:45:29 just looked, good 2019-09-27 09:53:55 !213 ddevault 2019-09-27 10:13:41 PureTryOut: merged latte-dock 2019-09-27 10:13:46 Yeah I saw it thanks 2019-09-27 10:57:02 <_ikke_> restarting gitlab 2019-09-27 13:15:22 Got lots of MRs for main/ :D 2019-09-27 14:48:04 been out most of the day today 2019-09-27 18:15:48 if the package version from upstream is "1.6.4.post2", what would you use as pkgver? 2019-09-27 18:20:07 not sure, but I would try that 2019-09-27 18:20:44 <_ikke_> THat's invalid 2019-09-27 18:21:51 mind to explain 2019-09-27 18:22:08 <_ikke_> apk does not allow .post2 in the version 2019-09-27 18:22:16 yes, 1.6.4.post2 is invalid. That's why I am asking 2019-09-27 18:22:26 hmm, apk version -t 1.6.4.post2 1.6.4 2019-09-27 18:22:33 <_ikke_> mps: use -c 2019-09-27 18:22:41 <_ikke_> apk version -c 1.6.4.post2 2019-09-27 18:22:53 <_ikke_> If it outputs the version, it's invalid 2019-09-27 18:23:16 it's queiet 2019-09-27 18:23:33 <_ikke_> for me it's not 2019-09-27 18:23:49 sorry, right 2019-09-27 18:23:57 wrong params 2019-09-27 18:24:56 so, version must have only numbers and dots 2019-09-27 18:25:12 <_ikke_> _rc is allowed as well 2019-09-27 18:25:19 <_ikke_> or _git 2019-09-27 18:25:20 the pattern is {digit}{.digit}...{letter}{_suf{#}}...{-r#} 2019-09-27 18:26:02 <_ikke_> where suf only allows certain predefined values 2019-09-27 18:26:39 so do you have any suggestions what I should use as a version number? 2019-09-27 18:27:16 well, 'r' is reserved for pkgrel, afaik 2019-09-27 18:27:46 <_ikke_> s/.post/_p./? 2019-09-27 18:27:46 _ikke_ meant to say: apk version -c 1.6.4_p.2 2019-09-27 18:27:54 gentoo uses 1.6.4_p2 for that particular package 2019-09-27 18:27:57 <_ikke_> yea 2019-09-27 18:28:02 <_ikke_> that should be allowed 2019-09-27 18:28:29 upstream could stop using weird version names :D 2019-09-27 18:29:39 I have got same "problem" with package which got 1.5.1-stable5 ... 2019-09-27 18:29:42 <_ikke_> https://github.com/alpinelinux/apk-tools/blob/master/src/version.c#L76 2019-09-27 18:29:51 whatever that could mean "stable5" ... 2019-09-27 18:30:22 <_ikke_> and p happens to be a post suffix, which is what we want 2019-09-27 18:31:42 android-tools have such example 2019-09-27 18:32:28 <_ikke_> so they use _p in that case as well 2019-09-27 18:32:31 ahm, not anymore, it's changed. 2019-09-27 18:32:46 <_ikke_> yeah, it use to 2019-09-27 18:32:48 <_ikke_> used to 2019-09-27 18:32:51 <_ikke_> https://git.alpinelinux.org/aports/commit/?id=651b721dfaae6bbe72be23c24775417ba4acaab2 2019-09-27 18:33:01 last time I made upgrade it has 's/_r/_p/?' 2019-09-27 18:33:54 or something similar. there I learned about rewriting versions 2019-09-27 18:34:56 git log -p .... realver=${pkgver/_p/_r} 2019-09-27 18:35:22 mps, ye last time, only 6 days ago 2019-09-27 18:37:02 no, it was when I helped jwh to enable it on more arch's, 67283cdbf6ef0ce2912bd28297714d6bb3976a38 2019-09-27 18:37:33 <_ikke_> mps: they mean that up to 6 days ago, that was still the cawe 2019-09-27 18:37:35 <_ikke_> case 2019-09-27 18:37:50 yep 2019-09-27 18:38:49 yes, I know, but I mention when I learned about that I noticed android-tools upgrade few days ago because I worked on that but someone was faster 2019-09-27 18:39:41 hmm, it time to go afk, a lot of typing errors 2019-09-27 18:44:18 OK thank you. So what do you prefer now: 1.6.4_p2 or 1.6.4_p.2 ? 2019-09-27 18:44:38 <_ikke_> _p2 I guess 2019-09-27 18:47:35 +1 2019-09-27 19:05:01 OK here is version 1.6.4_p2: pr#11709 2019-09-27 19:06:05 <_ikke_> Will check in a sec 2019-09-27 19:07:05 no need to hurry _ikke_ 2019-09-27 19:17:51 <_ikke_> maxice8: one test seems to be failing for py3-urwid on s390x 2019-09-27 19:41:11 <_ikke_> Cogitri: fractal seems to be failign on x86 2019-09-27 19:41:44 <_ikke_> error: failed to fetch `https://github.com/rust-lang/crates.io-index` 2019-09-27 19:41:50 <_ikke_> invalid version 3 on git_proxy_options; class=Invalid (3) 2019-09-27 19:45:50 Ah, had hoped that was only a temporary failure 2019-09-27 19:46:07 Let's hope that's Fractal being weird and not Cargo 1.38.0 being bad... 2019-09-27 19:46:18 <_ikke_> heh, yea 2019-09-27 19:46:25 <_ikke_> and strange it only happens on x86 2019-09-27 19:46:56 Ah, Fractal was only built on x86 since the commit which fails enables it on x86 2019-09-27 19:47:01 <_ikke_> ah ok 2019-09-27 19:48:07 <_ikke_> Apparently cargo uses github to host their package index 2019-09-27 19:55:33 Yup, they cache their registry like that 2019-09-27 19:56:30 https://github.com/rust-lang/rust/issues/63476 there we go 2019-09-27 19:56:55 Well at least we should be able to rebuild Rust and cargo since that doesn't need network access 2019-09-27 19:57:06 <_ikke_> libgit2 issue? 2019-09-27 19:58:10 Upstream of the libgit2-sys crate not giving a damn about distros apparently if I may say so 2019-09-27 19:58:28 They just hard bind the API against libgit2's latest git and don't even warn you if you build against the stable release... 2019-09-27 19:59:18 <_ikke_> That seems to be kind of endemic of the rust ecosystem 2019-09-27 20:00:56 Fair enough 2019-09-27 20:01:17 Argh, I really like the lang but the ecosystem is slowly stearing towards becoming JS all over again 2019-09-27 20:01:23 npm² 2019-09-27 20:01:43 <_ikke_> lol 2019-09-27 20:03:30 well, it is born in browser company :D 2019-09-27 20:09:09 <_ikke_> hmm, a soname change from usr/lib/libprotobuf.so.20.0.1 to usr/lib/libprotobuf.so.20.0.2 should most likely be safe, right? 2019-09-27 20:10:12 <_ikke_> abi-laboratories does not list this one yet 2019-09-27 20:14:01 If libprotobuf.20.0.1 symlinks to libprotobuf.20 2019-09-27 20:14:02 Sure 2019-09-27 20:17:01 <_ikke_> usr/lib/libprotobuf.so.20 -> libprotobuf.so.20.0.2 2019-09-27 20:20:12 Should be A-OK then 2019-09-27 20:28:53 <_ikke_> Hmm, a conundrum 2019-09-27 20:29:24 <_ikke_> go-bindata uses a snapshot version in aports (20151023) 2019-09-27 20:29:47 <_ikke_> It uses a github repo which is archived and apparently the original author disappeared 2019-09-27 20:29:59 <_ikke_> There seems to be an actively maintained repo with proper versions 2019-09-27 20:30:14 <_ikke_> but those will always be considered older then the current version 2019-09-27 20:31:36 Ah, it's not 0_git? :/ 2019-09-27 20:31:41 <_ikke_> nope :( 2019-09-27 20:35:15 I guess you _could_ do `provides` for that version? 2019-09-27 20:35:55 <_ikke_> does that work? 2019-09-27 20:36:19 I was wondering if replaces takes a version 2019-09-27 20:36:32 from the wiki page, it doesn't look like it though 2019-09-27 20:36:50 <_ikke_> no 2019-09-27 20:36:59 <_ikke_> Only thing I can think of is to rename it 2019-09-27 20:37:04 rename it to go-bin-data? 2019-09-27 20:42:53 replaces doesn't take a version but provides does 2019-09-27 20:43:01 Sadly we don't habe epochs yet 2019-09-27 20:43:05 <_ikke_> yup 2019-09-27 20:47:31 Made a PR for Rust 2019-09-27 20:47:53 <_ikke_> ok 2019-09-27 20:47:53 ACTION prays it just works and I don't have to make a new cargo for all arches now 2019-09-27 20:50:08 <_ikke_> hmm 2019-09-27 20:50:34 Oh my god they broke building Rust with $bootver == $pkgver 2019-09-27 20:51:02 <_ikke_> building it with the same version? 2019-09-27 20:52:53 Yes 2019-09-27 20:53:53 <_ikke_> great 2019-09-27 20:54:05 <_ikke_> So it only builds with the previous version? 2019-09-27 20:57:23 Maybe it'll work if I allow warnings, let's see 2019-09-27 20:57:42 Otherwise I'll just patch it in shape, restoring the old tarballs and using those sound pretty painful 2019-09-27 20:58:34 <_ikke_> yup 2019-09-28 07:58:53 Nice, seems like That works now 2019-09-28 07:58:59 s/That/Rust/ 2019-09-28 07:58:59 Cogitri meant to say: Nice, seems like Rust works now 2019-09-28 07:59:02 <_ikke_> ah 2019-09-28 07:59:04 <_ikke_> cool 2019-09-28 08:01:23 <_ikke_> fractal now builds as well 2019-09-28 08:02:50 Yup, took a few tries to build due to rustc SIGSEGVing 2019-09-28 08:03:12 <_ikke_> anoying 2019-09-28 08:03:24 <_ikke_> any clue why that happens? 2019-09-28 08:13:00 Not really 2019-09-28 08:13:46 <_ikke_> hmm, ok 2019-09-28 08:13:53 I just know that it happens a lot on complex packages like gtk-rs and that the crash needs to be in one of Rustc's non-rust parts 2019-09-28 08:14:01 Maybe LLVM9 will improve that 2019-09-28 08:48:49 PureTryOut: Does kwallet-pam work for you? At least in my setup pam only searches for modules in /lib/security and kwallet-pam installs to /usr/lib/security 2019-09-28 09:23:32 <_ikke_> Cogitri: gnome weather fails on s390x due to missing gjs 2019-09-28 09:24:02 Ah, I'll disable it, thanks 2019-09-28 09:29:05 I'll check when I'm back home monday 2019-09-28 09:29:35 Okay, thanks 2019-09-28 10:06:33 Is there a manual somewhere for lua-aports? I can't seems to find that 2019-09-28 10:07:04 <_ikke_> No, it's not really well documented 2019-09-28 10:07:38 <_ikke_> anything in particular you are looking for? 2019-09-28 10:10:00 I want to check what needs to be rebuilt after a soname bump, can I do that with lua-aports? 2019-09-28 10:11:12 <_ikke_> ap revdep I believe 2019-09-28 10:11:25 <_ikke_> But it does not check if it actually is neeeded 2019-09-28 10:13:21 <_ikke_> while in a repo dir (ie main): ap revdep 2019-09-28 10:41:05 Ah, thanks 2019-09-28 16:11:11 maxice8: can you take a look at #10887 2019-09-28 16:11:43 err PR10887 2019-09-28 17:10:50 clandmeter: sorry, will be away until next week 2019-09-28 17:15:11 Currently at airport 2019-09-28 18:20:21 Ok np 2019-09-29 07:10:17 Could someone with access to main/ take a look at pr11721? Would be nice to have LLVM9 if that fixes the Rust SIGSEGVs 2019-09-29 07:27:30 do we have something like aports-ghpr for gitlab 2019-09-29 07:29:02 You can use maxice8's mkmr I suppose 2019-09-29 07:29:56 isn't that for making MR, and not to check if MR exist for particular pkg 2019-09-29 07:30:34 I downloaded it and looked in source (superficially, TBH) 2019-09-29 07:32:58 Ah, alright, wasn't quite sure what aports-ghpr does 2019-09-29 07:33:03 No, it doesn't do that 2019-09-29 07:33:54 aports-ghpr check if PR exist for pkg in github 2019-09-29 07:35:05 'lab mr list gitlab -n 100 | grep pkgname' could help somewhat but is far for good 2019-09-29 07:49:11 Yes :/ 2019-09-29 07:49:36 Hm, I can't set a different `arch` value for subpackages than the main package, can I? 2019-09-29 07:49:58 <_ikke_> no, afaik you can only set noarch 2019-09-29 07:50:37 Well that's unfortunate 2019-09-29 08:06:59 Also, does `apk search --rdepends --origin --quiet so: libclang` actually work for all deps? 2019-09-29 08:07:10 s/so: / so:/ 2019-09-29 08:07:11 Cogitri meant to say: Also, does `apk search --rdepends --origin --quiet so:libclang` actually work for all deps? 2019-09-29 08:07:31 I feel like it doesn't list all deps 2019-09-29 11:40:16 <_ikke_> Why is building inkscape producing more than 4M of logs 2019-09-29 11:40:18 <_ikke_> ? 2019-09-29 11:42:12 I guess because it's a bit project and we're building it in verbose mode 2019-09-29 11:42:13 s/bit/big/ :P 2019-09-29 11:42:13 Cogitri meant to say: I guess because it's a big project and we're building it in verbose mode 2019-09-29 12:32:47 <_ikke_> great, the job failed after an hour, but the logs are truncated.. 2019-09-29 12:33:48 We truncate logs on b.a.o? 2019-09-29 12:34:10 <_ikke_> gitlab.a.o, it's a default setting 2019-09-29 12:35:17 Ah, so you're talking about CI, got it 2019-09-29 12:35:58 <_ikke_> yes, CI indeed 2019-09-29 12:36:43 Yeah, it's super, super annoying that users have to setup the CI timeout for their own fork and we can't just set a global timeout 2019-09-29 12:36:52 <_ikke_> Yes, indeed 2019-09-29 12:37:04 Since setting CI timeout on the builder only sets the maximum timeout allowed by the builder :/ 2019-09-29 12:41:13 <_ikke_> It's kinda anoying that those jobs are running the forks in the first place 2019-09-29 12:43:57 Yes 2019-09-29 12:51:43 <_ikke_> Ok, found out that if you explicitly set a value for how much log it allows, it also shows more output in the web interface (which as less than the default value) 2019-09-29 12:53:01 Ah yes, log sizes are set per builder 2019-09-29 12:53:05 <_ikke_> indeed 2019-09-29 12:56:06 <_ikke_> Trying to find out what's going on with this pipeline: https://gitlab.alpinelinux.org/Leo/aports/pipelines/392 2019-09-29 13:05:21 Dunno, weird that it says cancelled when it actually failed 2019-09-29 13:07:05 <_ikke_> Well, one issue is that it wanted to build too much 2019-09-29 13:07:09 <_ikke_> so some of them I canceled 2019-09-29 13:23:07 Ah, right 2019-09-29 13:38:04 <_ikke_> ">>> community/libreoffice: build failed" 2019-09-29 13:38:06 <_ikke_> :( 2019-09-29 14:54:44 Hi, how do I cross compile packages? I am building with "abuild -r". Tried setting CTARGET, doesn't seem to affect anything. Tried setting CHOST, fails with: "ERROR: unsatisfiable constraints: build-base-x86 (missing)". What am I doing wrong? 2019-09-29 14:59:31 <_ikke_> You would need to have a cross-compile toolchain 2019-09-29 15:15:08 Ok, I obviously need to read more. Then what kind of toolchain does alpine use for cross compilation? 2019-09-29 15:16:59 alpine does not have it 2019-09-29 15:17:13 builds native 2019-09-29 15:18:58 I usually use Void Linux's xbps-src does o crosscompile things 2019-09-29 15:19:49 (At least I used that to generate the Rust tarballs) 2019-09-29 15:19:57 Cogitri: question was about alpine 2019-09-29 15:20:22 Yes, but it's not really possible on Alpine so I recommend an alternative 2019-09-29 15:20:26 can you use xbps-src to cross build on alpine 2019-09-29 15:20:31 aha, ok 2019-09-29 15:20:53 I misunderstood your answer 2019-09-29 15:21:31 thought that you somehow managed to cross build on alpine using void tools 2019-09-29 15:22:29 Does alpine use virtualization then? Or just hardware with different architectures? 2019-09-29 15:22:40 Ah no, but you can compile Void Linux packages on an Alpine host and unpack those to at least have the binaries 2019-09-29 15:22:53 The latter 2019-09-29 15:22:59 We have native builders 2019-09-29 15:24:11 Getting crosscompiling working isn't pretty sometimes and most upstreams don't test for it in their CI pipelines because of that (further worsening the situation) 2019-09-29 15:25:23 true, native build is safest, I'm started to avoid cross build in last time 2019-09-29 15:25:42 Ok, got it, thanks _ikke_, mps, Cogitri 2019-09-29 15:26:40 Dekedro: np, we like to help when we can 2019-09-29 15:27:52 👍 2019-09-29 15:28:45 Some ZFS users here? Would be nice if someone tested https://github.com/alpinelinux/aports/pull/11704 2019-09-29 21:26:11 i have to admit that i have some locally built arm and riscv crosscompilers, and there is mingw which is a packaged crosscompiler in alpine... 2019-09-29 21:26:49 but then i don't use my crosscompilers to build apks with them. 2019-09-29 21:36:42 qa3Txu0iak0F: also I've built musl-cross-make for arm32 and arm64 but don't use for alpine 2019-09-30 09:54:51 Thanks for taking a look, ncopa :) 2019-09-30 10:02:53 Cogitri: i built it and pushed it. will test it on my laptop afterwards 2019-09-30 10:03:27 im working from laptop for a few days, so if its broken i'll have a serious problem :) 2019-09-30 10:03:37 Cogitri: thanks for looking at llvm9 2019-09-30 10:03:43 Sure thing 2019-09-30 10:04:19 i think there was a problem with llvm8 and chromium on armv7/armhf 2019-09-30 10:04:19 zfs should work though. It works on my laptop at least (although I'm not sure if it consumes more CPU now though) 2019-09-30 10:05:04 it failed to find the c++ includes for some reason, so i suspected the triples for armv7 was wrong some place 2019-09-30 10:05:19 did you test if it is fixed in llvm9? 2019-09-30 10:06:49 i noticed that this commit removed triples hunk for arm: 54db62760803072c5308e62d769048d2f50b68be 2019-09-30 10:07:00 was that intentional? 2019-09-30 10:07:23 Oh my, I guess I messed up the rebasing 2019-09-30 10:08:16 i think i tried to put it back but i dont think it made any difference for chromium 2019-09-30 10:09:08 i will try do the llvm9 think this week 2019-09-30 10:09:21 we should get the 3.11 builders up soon too 2019-09-30 10:09:50 which means that we should have a compilers and toolchains freeze 2019-09-30 10:09:58 and abuild freeze 2019-09-30 10:10:10 reminds me, i need to tag release of abuild too 2019-09-30 10:16:17 I think there are some pending PRs for abuild too :P 2019-09-30 10:18:55 yeah i know 2019-09-30 10:33:27 ncopa: user on #alpine-linux asked about https://github.com/alpinelinux/aports/pull/10936 2019-09-30 10:34:11 it is kernel change, I looked at it and I think it could and should be applied 2019-09-30 10:35:36 Cogitri: is the llvm9 pushed, or you just have MR/PR 2019-09-30 10:36:12 I would try to build and test in a next few days 2019-09-30 11:16:04 I have a pr for it 2019-09-30 11:16:22 pr11721 2019-09-30 11:31:25 Cogitri: thanks, will look and try to build on armv7 later this night (too busy now) 2019-09-30 11:36:43 Okie :) 2019-09-30 11:55:50 mps: i already merged it 2019-09-30 11:56:24 the kernel config thing 2019-09-30 12:06:07 ah, ok, something about pinctrl iirc, nice 2019-09-30 15:54:37 Would anyone care to verify something for me right quick? I have a package I want to submit that requires libfixposix.so to exist. The current package I have for libfixposix creates a .so.3 and .so.3.2.0; should I create a symlink in the package section for libfixposix to provide that file, or should that be done with the package that requires libfixposix.so to exist? 2019-09-30 15:59:05 <_ikke_> https://pkgs.alpinelinux.org/contents?file=libfixposix.so&path=&name=&branch=edge&arch=x86_64 2019-09-30 16:00:08 'apk-file libfixposix.so' 2019-09-30 16:00:41 Wait, it's provided by the -dev not the main? I obviously missed something obvious then 2019-09-30 16:01:45 +1 mps, I wasn't aware of apk-file. That's going to come in handy 2019-09-30 16:01:53 Thanks gents, obviously a non-issue then 2019-09-30 16:03:12 I found apk-file more useful than go to web page 2019-09-30 16:10:53 I imagine a lot of us spend more time on a prompt than a browser, so that make sense 2019-09-30 20:42:03 Cogitri: llvm9 in your PR builds on aarch64 and armv7 without problem 2019-09-30 20:44:54 Nice 2019-09-30 20:44:58 Also, does someone happen to have FF 69 up and running already M 2019-09-30 20:49:09 what is needed to build it, rust and llvm versions I mean 2019-09-30 20:50:35 What's in the repos should work already 2019-09-30 20:50:56 And Void already has it in their repos, so they patches for musl should be up too 2019-09-30 20:51:22 I can try to build it on aarch64 2019-09-30 20:51:59 doubt it is possible on armv7 because of 4GB problem 2019-09-30 20:52:03 That'd be nice. It doesn't build with just a bump though, it also needs a few patches 2019-09-30 20:52:30 are these patches already in aports 2019-09-30 20:53:06 Nop, you'll have to pull them from Void Linux 2019-09-30 20:54:11 aha, then maybe tomorrow, I'm tired, all day worked to solve some service problem 2019-09-30 20:54:41 Same here, but tired from uni :) 2019-09-30 20:54:50 I have FF 69 working on arm64 here, built when we had rust-1.37 I think 2019-09-30 20:55:10 it's hacked together and I don't have a x86_64 abuild setup to build and test a clean PR though 2019-09-30 20:55:12 colona: on alpine 2019-09-30 20:55:17 yeah 2019-09-30 20:55:45 nice 2019-09-30 20:55:55 Do feel free to submit a PR then 2019-09-30 20:56:07 I can take a look tomorrow and test on x86_64 2019-09-30 20:57:10 alright, I'll also check if Void have the same changes I had to make 2019-09-30 20:59:24 colona: please post your PR number/id here when you post it to github 2019-09-30 21:00:37 sure