2019-09-01 00:04:16 <maxice8> 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 <nmeum> maxice8: any particular reason why you started replacing $pkgname in $source?
2019-09-01 09:17:21 <nmeum> saw this in a few PR's
2019-09-01 09:28:24 <Cogitri> 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 <mps> nmeum: iirc, this was ncopa advice
2019-09-01 09:28:48 <Cogitri> 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 <nmeum> sure, but would be nice to document it somewhere (e.g. in CODINGSTYLE.md) then
2019-09-01 09:29:46 <nmeum> otherwise the next PR will just change it again
2019-09-01 09:29:49 <mps> personally I would like to keep $pkgname, and replace it with literal string only where it needed
2019-09-01 09:30:15 <nmeum> I don't really care as long as it is consistent
2019-09-01 09:32:14 <maxice8> 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 <maxice8> There is an entry on alint from atools-doc, AL29 pkgname_used_in_source
2019-09-01 09:35:03 <mps> maybe is best to left to maintainer to decide, IDK
2019-09-01 09:36:49 <Cogitri> nmeum: pretty sure we already noted it down in the currently WIP docbook thingie
2019-09-01 09:53:57 <maxice8> nmeum: reviewed your hy thingy
2019-09-01 10:00:32 <mps> 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 <mps> 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 <Cogitri> Ah, add `--disable-rust-simd` to configure's cmdline
2019-09-01 10:02:18 <Cogitri> (or smth like that)
2019-09-01 10:03:28 <mps> aha, ok
2019-09-01 10:03:59 <Cogitri> I guess they don't have simd for all arches yet
2019-09-01 10:04:27 <mps> obviously ;-)
2019-09-01 10:36:53 <nmeum> 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 <nmeum> Cogitri: oh great, do you have a link?
2019-09-01 10:48:46 <maxice8> nmeum: oh
2019-09-01 10:50:00 <nmeum> the feedback is useful though :)
2019-09-01 10:51:57 <maxice8> yes
2019-09-01 11:02:02 <Cogitri> 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 <maxice8> PureTryOut:  [ foo || bar ] doesn't exist in shell
2019-09-01 13:11:15 <maxice8> you're looking for [ foo ] || [ bar ] (discover patch)
2019-09-01 13:14:26 <PureTryOut[m]> Oh, interesting. It didn't complain about it, I'll change it
2019-09-01 13:14:34 <maxice8> It did
2019-09-01 13:14:40 <maxice8> it just went along with the failure
2019-09-01 13:14:58 <PureTryOut[m]> That's... A weird behaviour
2019-09-01 13:15:30 <PureTryOut[m]> Oh you've already merged it
2019-09-01 13:15:37 <PureTryOut[m]> Well, my v2 patch can be ignored then lol
2019-09-01 13:15:44 <PureTryOut[m]> Thanks for the quick response!
2019-09-01 13:15:54 <maxice8> ash: missing ]
2019-09-01 13:15:57 <maxice8> the error ^
2019-09-01 14:29:44 <maxice8> What's the plan for updating gcc ?
2019-09-01 14:43:27 <mps> iirc, ncopa is working on that
2019-09-01 16:21:40 <maxice8> pr10671
2019-09-01 16:23:24 <mps> we reached to fifty MR's on gitlab.a.o ;-) !50
2019-09-01 16:24:07 <maxice8> mps: nice :D can't wait to switch to it fulltime
2019-09-01 16:24:41 <mps> we have to wait for ikke to finish CI
2019-09-01 16:24:56 <maxice8> I am waiting
2019-09-01 16:25:11 <mps> also I :)
2019-09-01 16:25:29 <maxice8> you're already using gitlab MRs
2019-09-01 16:26:09 <mps> yes, have temptation to merge one from SpaceToast but not sure is ok
2019-09-01 16:26:18 <maxice8> which one ?
2019-09-01 16:26:33 <mps> moment
2019-09-01 16:27:03 <mps> !44
2019-09-01 16:27:34 <maxice8> already merged
2019-09-01 16:27:53 <mps> and not closed?
2019-09-01 16:28:00 <maxice8> i don't have permission to close
2019-09-01 16:28:36 <mps> oh, I will check later to see if I can
2019-09-01 16:30:17 <mps> 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 <mps> (mine or my?)
2019-09-01 16:43:49 <mps> maxice8: looks like I only can close those I created, not from other people
2019-09-01 16:55:43 <j8r> 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 <Cogitri> Nice
2019-09-01 17:54:38 <mps> j8r: you are using some cross build environment?
2019-09-01 18:13:58 <j8r> 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 <mps> that wouldn't be possible. You need linker for target arch
2019-09-01 18:16:46 <mps> and compiler
2019-09-01 18:17:38 <j8r> ho, ok, I'am a noob for this
2019-09-01 18:17:45 <mps> I'm trying to make cross compiler for alpine, but that will take time
2019-09-01 18:18:46 <mps> and will depend on my free time from $day_job
2019-09-01 18:19:45 <mps> but I think it is time for alpine to get at least basic cross build tools
2019-09-01 18:20:54 <Cogitri> Crossbuilding isn't as easy as making the base tooling available
2019-09-01 18:21:10 <Cogitri> On Void we had to spend lots of time fixing crossbuilding
2019-09-01 18:21:16 <Cogitri> 
ACTION looks at gobject-introspection

2019-09-01 18:23:00 <Cogitri> And lots of stuff just assumes that it's compiled natively
2019-09-01 18:24:33 <mps> Cogitri: I don't mean full cross build system. Just something to make some simple to build software
2019-09-01 18:25:02 <mps> and yes, 'real' cross build is not so simple
2019-09-01 19:19:53 <mps> 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 <j8r> 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 <mps> not sure, TBH. thought it would be possible to tell crystal to cross build itself
2019-09-01 21:31:56 <j8r> *then cross compiling I meant
2019-09-01 21:45:06 <mps> aha, ok. will see if can make cross build environment first
2019-09-01 21:55:45 <j8r> don't know how jirutka did for aarch64
2019-09-01 21:57:27 <mps> looks like crystal is ported to aarch64 only on alpine?
2019-09-01 22:07:12 <j8r> there is also src/lib_c/aarch64-linux-gnu
2019-09-01 22:07:30 <j8r> don't know if it works
2019-09-02 00:04:30 <maxice8> Can someone merge https://lists.alpinelinux.org/~alpine/aports/patches/2955 ?
2019-09-02 00:04:33 <maxice8> needs to fix py-ans1-modules
2019-09-02 09:13:50 <MY-R> ^ 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 <mps> 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 <mps> anyone have idea what can be cause of this error
2019-09-02 11:08:50 <TBB> ... glitch in the matrix :P
2019-09-02 11:09:30 <MY-R> mps, when you got that error? :D
2019-09-02 11:12:07 <mps> MY-R: at the end, when abuild tries to make apk
2019-09-02 11:12:28 <mps> but running 'abuild rootpkg' succeed
2019-09-02 11:20:06 <MY-R> mps, :\
2019-09-02 11:20:19 <MY-R> maybe not enough space?
2019-09-02 11:21:57 <MY-R> using 'ash' as shell or something different?
2019-09-02 11:24:12 <mps> I thought it could be space, but 'df' shows 95GB available
2019-09-02 12:26:51 <PureTryOut[m]> maxice8: I see you packaged appstream, does it actually work with apk?
2019-09-02 18:41:14 <mps> anyone building programs with rust on armv7 have memory issues during build
2019-09-02 18:44:01 <Cogitri> Yes, it SIGSEVs occasionally
2019-09-02 18:46:19 <mps> for me it SIGABRT constantly building firefox-esr http://tpaste.us/Q1VE
2019-09-02 18:47:10 <Cogitri> `LLVM ERROR: out of memory` seems like a likely cause
2019-09-02 18:48:20 <mps> 'free' => Mem:      131760984     1359064    84097336        1824    46304584   129112948
2019-09-02 18:48:50 <mps> how it can be out of memory on this machine
2019-09-02 18:49:05 <Cogitri> Well, maybe it needs to allocate more than 4 gigs of RAM per process
2019-09-02 18:49:17 <Cogitri> Which it can't do on 32-bit arches
2019-09-02 18:49:52 <mps> right, didn't thought about that
2019-09-02 18:51:36 <mps> so, no firefox on arm for now
2019-09-02 18:52:43 <Cogitri> Maybe you can turn down the opt level or disable LTO to make it work?
2019-09-02 18:55:27 <mps> disable or thin?
2019-09-02 18:56:02 <mps> '--enable-lto={full,thin,cross}'
2019-09-02 18:56:23 <Cogitri> Dunno what's enabled by default by ff
2019-09-02 18:56:35 <Cogitri> But I guess you could try with thin before disabling it
2019-09-02 18:56:51 <mps> makes sense, thanks for hint
2019-09-02 18:57:03 <mps> lets try with thin
2019-09-02 20:17:51 <mps> Cogitri: no luck with '--enable-lto=thin' nor '--disable-lto' :( => 'out of memory'
2019-09-03 05:45:52 <ncopa> morning
2019-09-03 05:45:59 <maxice8> morning
2019-09-03 05:46:15 <ncopa> been moving to new apartment, thats why i have been much away lately
2019-09-03 05:46:21 <maxice8> oh
2019-09-03 05:46:49 <ncopa> more work with that than anticipated
2019-09-03 05:47:39 <ncopa> anything i should prioritize?
2019-09-03 05:48:46 <ncopa> except get coffe and breakfast...
2019-09-03 05:51:12 <maxice8> There are some PRs with t-security and s-ready :D
2019-09-03 07:08:35 <afkpaul> 
ACTION good morning everyone

2019-09-03 07:34:05 <mps> ncopa: did you looked at MR's for XFRM and cpu NR for kernel for x86
2019-09-03 07:41:59 <ncopa> not if they are new
2019-09-03 07:46:09 <mps> they are related to two issue/feature requests
2019-09-03 07:47:48 <mps> !50
2019-09-03 07:48:09 <mps> !32
2019-09-03 07:58:05 <ncopa> mps: i'm increasing NR_CPUS to 128 for 32bit x86 and to 256 for x86_64
2019-09-03 07:59:14 <mps> to much, imo. :D
2019-09-03 08:00:05 <ncopa> we already have 256 on vanilla x86_64
2019-09-03 08:00:42 <ncopa> i think it makes sense to have the same for virt
2019-09-03 08:00:51 <ncopa> and for 32 bit i guess half is ok
2019-09-03 08:00:58 <ncopa> that was my thinking
2019-09-03 08:01:06 <mps> no, I'm kidding, I had same temptation but didn't wanted in 'first step'
2019-09-03 08:01:47 <ncopa> aarch64 has 4096
2019-09-03 08:02:24 <mps> notice ':D' in previous msg
2019-09-03 08:02:48 <ncopa> difficult to read sarcasm on irc :)
2019-09-03 08:03:34 <mps> ah, we have to be deadly serious
2019-09-03 08:05:53 <mps> anyway, we will have to examine and maybe test these kernel parameters more deeply in next few months
2019-09-03 08:17:53 <ncopa> tmhoang: there is something nasty going on with git and s390x
2019-09-03 08:19:07 <ncopa> my bad
2019-09-03 08:19:12 <ncopa> looks normal now
2019-09-03 08:21:54 <ncopa> except that apr testsuite hanged
2019-09-03 08:51:15 <mps> trying to build firefox-esr on aarch64 with 'abuild -r' I got this error http://tpaste.us/W1XN
2019-09-03 08:51:36 <mps> using 'abuild rootpkg' it works
2019-09-03 08:52:05 <mps> anyone have idea what could be problem?
2019-09-03 09:36:00 <ncopa> huh
2019-09-03 09:36:59 <ncopa> sounds like a bug in abuild
2019-09-03 09:38:45 <mps> build of other packages works normally
2019-09-03 09:39:22 <_ikke_> Something in the apkbuild?
2019-09-03 09:39:41 <mps> although smaller ones, didn't tried any bigger in last week or so
2019-09-03 09:41:15 <mps> _ikke_: \o
2019-09-03 09:42:45 <mps> abuild is 3.4.0-r1
2019-09-03 09:45:51 <ncopa> i had some similar issue the other week
2019-09-03 09:46:05 <ncopa> abuild rootpkg worked but not `abuild -r`
2019-09-03 09:46:09 <ncopa> i dont remember which package it was
2019-09-03 09:46:20 <ncopa> or which arch
2019-09-03 09:47:16 <ncopa> tmhoang: looks like apr testsuite hangs on s390x
2019-09-03 09:47:23 <ncopa> testproc            : SUCCESS
2019-09-03 09:47:23 <ncopa> testprocmutex       : |
2019-09-03 09:48:04 <mps> 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 <ncopa> strace: Process 8449 attached
2019-09-03 09:49:46 <ncopa> semtimedop(163840, [{0, -1, SEM_UNDO}], 1, NULL
2019-09-03 09:52:20 <PureTryOut[m]> maxice8: I see you packaged appstream, does it actually work with apk?
2019-09-03 10:56:10 <ncopa> tmhoang: teh testprocmutex hangs on s390x on sysv semaphore locking mechanism
2019-09-03 10:56:38 <tmhoang> wow what is testprocmutex
2019-09-03 10:56:55 <tmhoang> ah apr
2019-09-03 10:56:56 <ncopa> its a test in testsuite for apr
2019-09-03 10:57:08 <tmhoang> it seems it has been recently introduced, was fine with 3.10
2019-09-03 10:57:12 <tmhoang> looking
2019-09-03 10:57:24 <ncopa> yes, i happens afteer the aprl upgrade to 1.7.0
2019-09-03 10:57:51 <ncopa> i dont know if it is due to musl upgrade, or if they changed/broke anything in apr
2019-09-03 10:58:03 <ncopa> or if test is broken
2019-09-03 10:58:08 <tmhoang> ok I will have a look, it was on my todo list ...
2019-09-03 10:58:19 <ncopa> test has not changed last two years
2019-09-03 10:58:31 <ncopa> but it may have been broken all the time
2019-09-03 10:58:45 <ncopa> im not that deep into sys v semaphores
2019-09-03 10:59:02 <ncopa> but is seems there are some implementation details when you fork
2019-09-03 10:59:53 <tmhoang> me neither, can't do now sorry. will try this week L*
2019-09-03 10:59:54 <tmhoang> :(
2019-09-03 11:17:30 <ncopa> ok. im adding a patch that works around the problem
2019-09-03 13:23:29 <maxice8> Need pr10671 merged
2019-09-03 14:02:48 <PureTryOut[m]> maxice8: I see you packaged appstream, does it actually work with apk?
2019-09-03 15:45:02 <PureTryOut[m]> maxice8 ?
2019-09-03 17:48:39 <PureTryOut[m]> 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 <maxice8> PR for poppler-080 pr10593
2019-09-03 21:12:04 <Cogitri> 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 <PureTryOut[m]> Oh damn, that is quite big. Why is it needed?
2019-09-04 06:48:36 <Cogitri> 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 <PureTryOut[m]> Ah clear answer, thanks
2019-09-04 11:33:09 <maxice8> :D ruby has been updated
2019-09-04 11:34:02 <ncopa> i didnt verify that everythign needed was rebuilt
2019-09-04 11:35:21 <maxice8> isn't it just a matter of rebuilding ruby-* ?
2019-09-04 11:35:47 <ncopa> could be some package that builds ruby module
2019-09-04 11:35:59 <ncopa> could be some package linking to libruby.so or similar
2019-09-04 11:36:02 <ncopa> i havent checkec those
2019-09-04 11:36:11 <maxice8> :D better rebuild everything that has ruby-dev ?
2019-09-04 11:36:21 <ncopa> possibly yes
2019-09-04 11:36:39 <ncopa> but i havent checked if something indirectly pulls in ruby-dev
2019-09-04 11:37:35 <ncopa> im updating perl to 5.30
2019-09-04 11:37:47 <maxice8> good luck
2019-09-04 13:05:51 <ncopa> fcolista: i dont think b2b52a99c79da5dd37fc82e9a01f3473b15eb029 was intentional?
2019-09-04 13:08:28 <fcolista> ncopa, not at all
2019-09-04 13:08:30 <fcolista> :-/
2019-09-04 13:08:36 <fcolista> sorry /0\
2019-09-04 13:09:38 <ncopa> np
2019-09-04 13:09:46 <ncopa> i'm bumping it with the perl 5.30 upgrade
2019-09-04 13:14:54 <fcolista> k thx
2019-09-04 17:10:40 <mps> ncopa: are you here? I have no one except you to annoy. !47
2019-09-04 17:11:01 <mps> I need it pushed to upgrade iwd
2019-09-04 21:11:30 <repu1sion> is there any guide how to install arm image of alpine linux in qemu?
2019-09-04 21:16:44 <mps> afaik, only that I already posted link to you
2019-09-04 21:56:04 <artok> 5th hit on google
2019-09-04 21:56:40 <artok> "qemu aarch64 alpine" gives some info
2019-09-04 22:12:32 <mps> artok: oh, I can go to 1st RSN :D
2019-09-05 08:41:56 <maxice8> 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 <mps> !43 !42
2019-09-05 08:46:52 <ncopa> morning
2019-09-05 10:12:51 <PureTryOut[m]> 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 <ncopa> im working on perl 5.30, and will likely push it today
2019-09-05 10:14:50 <mps> PureTryOut[m]: I already had temptation to move it
2019-09-05 10:15:06 <maxice8> ncopa: nice
2019-09-05 10:15:25 <PureTryOut[m]> Ah good
2019-09-05 10:16:03 <mps> but, yes, I prefer to ask maintainer first
2019-09-05 10:16:12 <mps> fcolista: ^
2019-09-05 10:18:47 <PureTryOut[m]> Definitely 😉
2019-09-05 10:18:52 <PureTryOut[m]> I might send him an email
2019-09-05 10:19:34 <mps> I think he will answer here when he see our msgs
2019-09-05 10:19:59 <mps> no need to hurry
2019-09-05 10:20:33 <PureTryOut[m]> Yeah I'll wait for a bit
2019-09-05 10:20:48 <mps> he is very responsive, and kind person
2019-09-05 10:21:13 <PureTryOut[m]> Most people here are quite responsive and kind ime
2019-09-05 10:23:35 <mps> PureTryOut[m]: how long you are on this channel
2019-09-05 10:24:17 <mps> (rhetorical question, no need to answer ;-) )
2019-09-05 10:24:26 <PureTryOut[m]> Year and a half or so? I'm not certain
2019-09-05 10:28:08 <mps> why don't we build libtinfo from ncurses, any reasons for it or against
2019-09-05 11:03:22 <maxice8> mps: it is built as part of libncurses
2019-09-05 11:05:25 <mps> yes, I know. my question is why we don't build it as separate lib
2019-09-05 11:19:56 <maxice8> Problably how it was always done
2019-09-05 11:27:11 <maxice8> pr10860 important ncopa
2019-09-05 11:27:53 <mps> maxice8: inertia
2019-09-05 12:33:39 <ncopa> im almost done with perl 5.30
2019-09-05 12:33:49 <ncopa> apache2 mod_perl is broken though
2019-09-05 12:34:02 <ncopa> apparently it crashes in libperl.so
2019-09-05 12:34:47 <ncopa> 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 <mps> who should close applied MR's, commiter or author, or any of them or even anyone?
2019-09-05 14:47:32 <maxice8> Whoever can close it when it is applicable imo
2019-09-05 14:48:19 <mps> should we add note or just simply close
2019-09-05 14:48:59 <maxice8> ideally the algitbot does it like it does for GitHub
2019-09-05 14:49:19 <mps> yes, but it still doesn't
2019-09-05 15:41:29 <SpaceToast> ping fcolista - there's some serious regression in lxd 3.16
2019-09-05 15:41:39 <SpaceToast> I'm guessing it's their "new NIC logic" being horribly broken
2019-09-05 15:42:16 <SpaceToast> 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 <maxice8> 5 pages of commits rebuilding perl stuff :D
2019-09-05 15:49:34 <MY-R> perlfect!
2019-09-05 15:49:58 <mps> wait, wait ... there will be more pages :)
2019-09-05 15:51:05 <MY-R> builders gonna burn!
2019-09-05 15:52:02 <mps> hehe, and people says that perl is dying ;-)
2019-09-05 16:03:53 <maxice8> 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 <mps> looking at build.a.o looks like 32bit machines are faster than their 64bit cousins
2019-09-05 18:30:06 <clandmeter> mps: same machine :)
2019-09-05 18:30:46 <mps> no, I'm looking at build.a.o aports built column
2019-09-05 18:31:11 <clandmeter> you mean x86 or arm?
2019-09-05 18:31:30 <mps> both
2019-09-05 18:31:45 <clandmeter> x86 does 32 and 64bit
2019-09-05 18:31:54 <clandmeter> afaik
2019-09-05 18:31:58 <mps> aha, x86 and x86_64 builders are on same machine
2019-09-05 18:32:04 <clandmeter> arm is different
2019-09-05 18:32:09 <mps> that explains
2019-09-05 18:32:24 <clandmeter> the thunderx is slower but has more cores
2019-09-05 18:32:45 <mps> I see, thanks
2019-09-05 18:32:49 <clandmeter> and i think for perl it does a lot of single thread processing
2019-09-05 18:33:04 <clandmeter> like with some autotools projects
2019-09-05 18:33:17 <clandmeter> it runs configure for 10 minutes and make for 1
2019-09-05 18:33:22 <mps> 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 <mps> anyone looked at abuild issue I posted here few days ago?
2019-09-05 20:23:08 <MY-R> 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 <MY-R> cus you talking about that error with firefox, right?
2019-09-05 20:27:57 <mps> 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 <MY-R> mps, still, would be cool to "document it" ps what board?
2019-09-05 20:34:02 <mps> it is some of alpine infrastructure machines, and I run build in lxc
2019-09-05 20:35:01 <mps> APKBUILD is tweaked to enable firefox-esr build on aarch64
2019-09-05 20:35:32 <mps> non-standard to reproduce easily
2019-09-05 20:36:29 <MY-R> oh :\
2019-09-05 20:38:25 <MY-R> or something going on with builders, last time they didnt work, right? :D
2019-09-05 20:39:32 <mps> something really strange to me, but have no idea what could be
2019-09-05 20:40:03 <mps> abuild is not much from previous version when build worked
2019-09-06 06:28:42 <clandmeter> _ikke_: but are they not identical?
2019-09-06 06:31:54 <_ikke_> Yes, they should be indeed
2019-09-06 06:53:33 <mps> clandmeter: should clamav 0.101.4 be backported to 3.10, what you (maintainer) think? !48
2019-09-06 06:54:29 <mps> I made it and it run for one of my customers about week ago
2019-09-06 07:24:11 <clandmeter> mps: not sure, what does it fix?
2019-09-06 07:24:18 <clandmeter> test unit?
2019-09-06 07:25:13 <mps> yes, it is fixed
2019-09-06 07:25:49 <clandmeter> mps: elaborate?
2019-09-06 07:26:08 <mps> 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 <clandmeter> what is a test unit?
2019-09-06 07:26:36 <mps> it is outdated
2019-09-06 07:26:53 <clandmeter> its when pkg is build or when its run?
2019-09-06 07:27:31 <mps> it was bug in --debug option for librar
2019-09-06 07:27:53 <mps> single line fix
2019-09-06 07:29:01 <clandmeter> i dont understand the problem, so i cannot give you an answer.
2019-09-06 07:29:19 <mps> 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 <mps> it was not upgraded for latest stable because of this bug which is now fixed
2019-09-06 07:32:05 <mps> and upgraded version is already in edge
2019-09-06 07:32:28 <clandmeter> so the current version in stable has an issue?
2019-09-06 07:32:49 <mps> no, it works but it is outdated
2019-09-06 07:33:34 <mps> and for software intended to secure something is not good to be outdated too much, imo
2019-09-06 07:34:10 <clandmeter> thats why we have new alpine releases
2019-09-06 07:34:19 <clandmeter> and we backport fixes
2019-09-06 07:34:42 <clandmeter> and in some special cases we do different things.
2019-09-06 07:34:55 <mps> yes, I know
2019-09-06 07:35:35 <mps> 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 <clandmeter> 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 <clandmeter> yes some software does that.
2019-09-06 07:35:56 <clandmeter> clamav is not the only one
2019-09-06 07:36:52 <clandmeter> 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 <mps> I presume users will ask or fill issues about that
2019-09-06 07:37:32 <mps> we always risks new bugs with upgrades
2019-09-06 07:40:57 <mps> 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 <clandmeter> ok sounds fair
2019-09-06 07:41:27 <clandmeter> lets do it :)
2019-09-06 07:43:42 <mps> I don't want to force it, because that I asked for your opinion
2019-09-06 08:18:03 <clandmeter> mps: your update is broken
2019-09-06 08:20:00 <mps> oh, ok. then forget it
2019-09-06 08:21:08 <mps> and sorry for taking your time
2019-09-06 08:22:57 <clandmeter> hmm its not  your update
2019-09-06 08:23:57 <mps> ?
2019-09-06 08:24:34 <clandmeter> ncopa did it
2019-09-06 08:25:25 <ncopa> morning
2019-09-06 08:25:29 <ncopa> what did i do now?
2019-09-06 08:25:48 <clandmeter> heh, i knew you would say that same sentence :)
2019-09-06 08:26:56 <clandmeter> nah its non of you, im sure if i look far back enough ill end up with myself.
2019-09-06 08:27:35 <mps> I don't see anything wrong in git log for last year, so I'm blind ;)
2019-09-06 08:27:55 <clandmeter> build is ok, packaging is broken
2019-09-06 08:28:56 <mps> ehm, will be happy is this pkg only one which packaging is broken in alpine :D
2019-09-06 08:29:31 <clandmeter> libs is executed before clamav-libunrar
2019-09-06 08:29:42 <clandmeter> so it moves the unrar lib to libs
2019-09-06 08:29:46 <clandmeter> making libunrar empty
2019-09-06 08:30:42 <clandmeter> ncopa removed the libs function, but its similar to what abuild does.
2019-09-06 08:30:48 <clandmeter> i guess it has been like this for ages
2019-09-06 08:30:48 <mps> ah, right
2019-09-06 08:35:53 <clandmeter> pushed including the libunrar fix
2019-09-06 08:36:38 <clandmeter> i wonder if this fix will break some ppl setup
2019-09-06 08:37:32 <mps> I will test it later to see
2019-09-06 08:37:52 <clandmeter> now you need to explicitly install libunrar subpgk
2019-09-06 08:38:04 <clandmeter> before it would be pulled in with libs pkg
2019-09-06 08:39:26 <mps> no, clamav-libunrar is not pulled
2019-09-06 08:39:45 <mps> ah, you mean now
2019-09-06 08:40:37 <mps> 
ACTION better to first test and then speak

2019-09-06 08:40:53 <clandmeter> if you have libunrar in world you should be fine
2019-09-06 08:41:37 <mps> yes, but I don't have it installed explicitly
2019-09-06 08:41:55 <clandmeter> then libunrar will not be available
2019-09-06 08:42:28 <mps> will wait for in on mirror and check
2019-09-06 08:43:25 <mps> and, why separate clamav-libunrar pkg? licence issue?
2019-09-06 08:43:49 <clandmeter> thats our policy
2019-09-06 08:43:55 <clandmeter> keep main pkg small as possible
2019-09-06 08:44:03 <clandmeter> let user choose what to install
2019-09-06 08:47:14 <mps> nice, I like this, especially if it will be written in some official document
2019-09-06 08:47:38 <mps> always disliked debian 'dependency hell'
2019-09-06 08:47:44 <clandmeter> its something for the official docs
2019-09-06 08:55:04 <mps> added this to notes if we ever start to discuss policy docs
2019-09-06 08:56:17 <clandmeter> mps: you can find this policy in almost every pkg.
2019-09-06 08:56:45 <clandmeter> if applicable ofc.
2019-09-06 08:58:10 <mps> in vim, too?
2019-09-06 09:04:20 <mps> back to work, clamav upgrade doesn't pull clamav-libunrar
2019-09-06 09:04:57 <mps> need to remember if someone fill issue or ask on irc/ML
2019-09-06 09:08:06 <clandmeter> mps: https://pkgs.alpinelinux.org/package/edge/main/x86_64/vim
2019-09-06 09:08:19 <clandmeter> check subpkgs (right colomn)
2019-09-06 09:11:08 <mps> I remember, I made last fixes about vimdiff and gvim there
2019-09-06 09:12:27 <mps> 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 <artok> heyyy
2019-09-06 14:26:54 <artok> ncopa: here?
2019-09-06 14:27:13 <ncopa> hi
2019-09-06 14:27:16 <ncopa> im here
2019-09-06 14:27:19 <ncopa> 3 mins more
2019-09-06 14:28:00 <artok> ncurses worked on builders? I'm getting some error on downloading that...
2019-09-06 14:29:32 <artok> something like _ver=${pkgver/_p/-} is not working properly.. I'll launch builder again...
2019-09-06 14:29:53 <artok> but if you're in hurry, just go and I'll check it and report
2019-09-06 14:33:18 <ncopa> note that that is a bash extension, which is supported in busybox ash
2019-09-06 14:54:28 <artok> filoozom: happy rpi4 aarch64 user?
2019-09-06 14:55:18 <mps> artok: what kernel you use
2019-09-06 14:55:48 <artok> nothing at the moment, just going to build kernel for rpi
2019-09-06 14:58:00 <mps> 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 <artok> hmm
2019-09-06 15:08:22 <artok> links?
2019-09-06 15:11:56 <mps> arch linux alarm git repo, don't have url right now
2019-09-06 15:14:51 <mps> https://github.com/archlinuxarm/PKGBUILDs.git
2019-09-06 15:15:50 <mps> i've seen in aarch64 config rpi4 enabled
2019-09-06 15:19:30 <artok> just found that.
2019-09-06 15:46:48 <mps> no way to build firefox-esr on armv7, 4GB address space is limit :/
2019-09-06 15:50:49 <PureTryOut[m]> You can cross-compile
2019-09-06 15:51:22 <mps> on alpine?
2019-09-06 16:19:16 <artok> scripts/bootstrap.sh does thingies
2019-09-06 16:21:33 <mps> and that will work on alpine builders?
2019-09-06 16:30:49 <artok> mps haven't really tested now, but afaik =)
2019-09-06 16:31:22 <artok> oh damn that ncurses was updated 2 days ago.. my repo was lagging behind
2019-09-06 16:32:21 <mps> you don't miss too much with this update, I'm on ncurses ML, just small fixes
2019-09-06 16:33:00 <artok> I finally just hit abuild -R on linux-rpi with filoozom edits
2019-09-06 17:34:20 <artok> did we have "skip tests" flag on abuild?
2019-09-06 17:34:43 <maxice8> no
2019-09-06 17:35:48 <artok> once in a while that would be ok, even that is not good practice
2019-09-06 17:35:48 <mps> artok: yes => options="!check"
2019-09-06 17:40:54 <artok> yeah on APKBUILD that is, but globally ignoring check
2019-09-06 17:45:16 <mps> ah, then as maxice8 told
2019-09-06 17:46:37 <mps> but you can 'abuild deps unpack prepare build rootpkg' to skip check
2019-09-06 17:46:57 <mps> and clean and undeps at the end
2019-09-06 17:47:27 <artok> oh true,
2019-09-06 17:48:14 <mps> I do right this sometimes, and repeating some steps 'abuild stepxx'
2019-09-06 17:53:21 <artok> oh well, amazon is just taking my money on the instance, nothing more =D
2019-09-07 08:06:52 <maxice8> Getting 'ERROR: Metadata for package keepassxc-doc-2.4.3-r1 is too long.' when building keepassxc
2019-09-07 09:11:40 <maxice8> oh well
2019-09-07 09:11:45 <maxice8> license was too long
2019-09-07 09:16:55 <artok> libaio gives 404 on source fetch, https://hastebin.com/simuzaxate.bash ought to do it
2019-09-07 14:31:53 <mps> maxice8: sorry for nitpicking again, but isn't proper word 'remove' instead of 'drop'
2019-09-07 14:32:17 <maxice8> i wanted to put execute but i felt it was too charged
2019-09-07 14:32:26 <mps> :D
2019-09-07 14:32:30 <maxice8> also has other meanings
2019-09-07 14:33:07 <mps> ok, I understand all of them
2019-09-07 14:33:13 <maxice8> well i was using limit and some wanted me to use disable instead
2019-09-07 14:33:30 <maxice8> 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 <mps> I was that 'some'
2019-09-07 14:34:00 <maxice8> i have no memory of who asked me just that some people asked me
2019-09-07 14:34:14 <mps> we should follow established rules, although most of them are not written in policy
2019-09-07 14:35:04 <mps> not only I asked, some other people also told that the 'limit' is not correct
2019-09-07 14:35:28 <maxice8> 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 <mps> ok, however you want, I just wasn't sure
2019-09-07 14:36:34 <mps> btw, I see you work a lot to make python in better shape
2019-09-07 14:37:25 <maxice8> Today is holiday :D
2019-09-07 14:37:48 <mps> happy holiday to you :)
2019-09-07 14:42:42 <maxice8> thank you :)
2019-09-07 19:31:05 <z3ntu> maxice8: `/usr/include/lttng/tracepoint.h:39:10: fatal error: 'sys/sdt.h' file not found` :(
2019-09-07 20:07:26 <z3ntu> 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 <maxice8> PureTryOut: congrats on 3000th patch on ~patches
2019-09-07 20:14:13 <PureTryOut[m]> Thanks! I worked very hard for it and am very proud of the achievement 😄
2019-09-07 20:30:07 <maxice8> PureTryOut: libpostal is failing on everything not x86_64 and x86
2019-09-07 20:30:10 <maxice8> because of usage of -msse2
2019-09-07 20:30:29 <PureTryOut[m]> Yeah I noticed
2019-09-07 20:30:37 <PureTryOut[m]> Already send a patch out to fix that on marisa-trie
2019-09-07 20:30:50 <PureTryOut[m]> Seeing if I can fix it on libpostal as well
2019-09-07 20:30:56 <maxice8> i'll merge that then and disable libpostal for now, i'm going to a birthday party
2019-09-07 20:31:02 <PureTryOut[m]> Oh sure
2019-09-07 20:31:48 <maxice8> 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 <maxice8> regardless, i'll push now, disable libpostal and go
2019-09-07 20:32:15 <PureTryOut[m]> I guess that's fine too, doesn't really matter much imo
2019-09-07 20:32:26 <maxice8> it does deduplicate the ./configure script
2019-09-07 20:34:41 <PureTryOut[m]> 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 <PureTryOut[m]> Oh wait nvm
2019-09-07 20:35:26 <PureTryOut[m]> I misunderstood
2019-09-08 09:38:36 <artok> seems that new raspberry pi start.elf doesn't support kernel/initramfs being in subfolder
2019-09-08 12:40:57 <PureTryOut[m]> Has the s390x architecture been dropped? I don't see any builder for it anymore
2019-09-08 12:43:11 <mps> no, iirc tmhoang told that builder will be down some time for maintenance
2019-09-08 12:43:38 <PureTryOut[m]> Ah ok
2019-09-08 14:08:13 <PureTryOut[m]> 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 <maxice8> No, doesn't  apply  against master
2019-09-08 14:11:16 <PureTryOut[m]> Ah didn't know that. I'll update it then
2019-09-08 14:15:54 <PureTryOut[m]> I've send a new version for it
2019-09-08 14:18:00 <maxice8> current font-noto-emoji doesn't depend on python2
2019-09-08 14:18:40 <PureTryOut[m]> font-noto-emoji itself doesn't, but one of it's depends does
2019-09-08 14:18:53 <maxice8> font-noto-emoji has no depends
2019-09-08 14:18:53 <PureTryOut[m]> Wait...
2019-09-08 14:19:36 <PureTryOut[m]> Oooh you changed it
2019-09-08 14:19:45 <PureTryOut[m]> It doesn't build the fonts anymore, now it just uses a pre-compiled one
2019-09-08 14:19:51 <PureTryOut[m]> In that case, only merge the nototools patch
2019-09-08 14:19:59 <maxice8> aight
2019-09-08 14:21:16 <PureTryOut[m]> 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 <PureTryOut[m]> *version
2019-09-08 14:21:37 <PureTryOut[m]> It should use the `0_gityearmonthdate` notation
2019-09-08 14:22:10 <PureTryOut[m]>  * It should use the `0_git<year><month><date>` notation
2019-09-08 14:22:12 <PureTryOut[m]> Or `<latestrelease>_git<year><month><date>`
2019-09-08 17:46:37 <maxice8> PureTryOut: kgpg is failing D:
2019-09-09 07:23:00 <_ikke_> https://pythonclock.org
2019-09-09 07:25:04 <mps> Python 2.7 will retire in...
2019-09-09 07:25:55 <mps> Python 2.7^W will retire in.. (rofl)
2019-09-09 07:26:23 <mps> _ikke_: \o
2019-09-09 07:26:39 <_ikke_> Hi
2019-09-09 07:27:43 <mps> 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 <mps> 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 <mps> don't hurry back ;-) especially if you enjoy to visit nice places there
2019-09-09 07:47:53 <PureTryOut[m]> Ugh I today noticed my commit message to upgrade KDE Applications uses the wrong version number...
2019-09-09 07:48:08 <PureTryOut[m]> I guess rewriting history isn't an option? 🙈
2019-09-09 07:53:58 <Cogitri> Not really :P
2019-09-09 08:00:32 <PureTryOut[m]> 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 <fcolista> ping SpaceToast
2019-09-09 10:20:33 <z3ntu> Is installing LICENSE/COPYING files in /usr/share/licenses/$pkgname wanted?
2019-09-09 10:20:58 <maxice8> z3ntu: imo as long as it isn't available as an SPDX identifier. yes
2019-09-09 10:21:02 <fcolista> SpaceToast: aports:master |Francesco Colista| testing/lxd: upgrade to 3.17: | http://dup.pw/aports/b4f25fe2
2019-09-09 10:23:28 <mps> fcolista: you are maintainer of i2c-tools, what about move to community
2019-09-09 10:27:30 <fcolista> mps, if it works fine, yes
2019-09-09 10:28:04 <mps> it works fine on some of my arm boards
2019-09-09 10:28:46 <mps> I tested it only on arm's
2019-09-09 10:28:51 <fcolista> ok
2019-09-09 10:29:14 <fcolista> i2c has py2 bindings
2019-09-09 10:29:22 <fcolista> that needs to be removed or udpated to py3
2019-09-09 10:29:30 <mps> yes
2019-09-09 10:30:01 <mps> I didn't wanted to touch it before asking you for opinion
2019-09-09 10:30:57 <fcolista> ok it needs some extra work
2019-09-09 10:31:02 <fcolista> I'm looking at this
2019-09-09 10:31:10 <fcolista> do you have something ready?
2019-09-09 10:31:55 <mps> 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 <fcolista> lol
2019-09-09 10:32:15 <fcolista> :D
2019-09-09 10:32:26 <mps> now, when you respond I will forget it ;-)
2019-09-09 10:33:04 <fcolista> :P :)
2019-09-09 10:40:16 <fcolista> mps: wanna take a look before i push?
2019-09-09 10:40:44 <mps> ok, url
2019-09-09 10:40:56 <mps> I even can test build on some arches
2019-09-09 10:41:34 <fcolista> http://dpaste.com/2QPJTBY.txt
2019-09-09 10:42:10 <fcolista> wondering if I should add provides=py-smbus
2019-09-09 10:42:21 <fcolista> since now I renamed py-smbus to py3-smbus
2019-09-09 10:43:05 <mps> ah, look like it should
2019-09-09 10:43:20 <Cogitri> Yes, add provides and replaces
2019-09-09 10:43:29 <fcolista> Cogitri, yeah..replaces
2019-09-09 10:43:30 <maxice8> yes, that is how it goes
2019-09-09 10:43:41 <maxice8> provides="py-smbus=$pkgver-r$pkgrel" and replaces="py-smbus"
2019-09-09 10:44:00 <maxice8> caveat, do that in the py() function not in the root of the APKBUILD
2019-09-09 10:44:22 <fcolista> ?
2019-09-09 10:44:32 <fcolista> ah
2019-09-09 10:44:33 <fcolista> ok
2019-09-09 10:44:34 <fcolista> yes
2019-09-09 10:44:47 <fcolista> sure, in py() function
2019-09-09 10:45:04 <maxice8> yes, otherwise i2c-tools will replace it no py3-smbus
2019-09-09 10:45:11 <fcolista> exactly
2019-09-09 10:45:12 <maxice8> s/ no / not /
2019-09-09 10:47:19 <fcolista> ok...lunchtime here
2019-09-09 10:47:54 <mps> buon apetito :)
2019-09-09 10:48:12 <fcolista> http://dpaste.com/3ERC0KB.txt
2019-09-09 10:48:20 <fcolista> mps :) grazie!
2019-09-09 10:48:37 <mps> (forgot exact Italian syntax)
2019-09-09 10:48:55 <fcolista> "buon appetito"
2019-09-09 10:49:51 <mps> I know I missed something
2019-09-09 10:50:51 <mps> (long time didn't used nice Italian language :( )
2019-09-09 10:51:36 <mps> when you speak is like you sing
2019-09-09 11:09:15 <tmhoang> wait till you speak/hear German
2019-09-09 11:10:06 <mps> tmhoang: I did when I was in school ;)
2019-09-09 11:11:40 <tmhoang> German school? ;)
2019-09-09 11:12:54 <mps> no, local but German was foreign lang to learn
2019-09-09 11:14:37 <mps> actually, German and Russian, and as option French
2019-09-09 11:31:59 <SpaceToast> fcolista: thanks, I'll check back once I checked to see if it's better
2019-09-09 13:02:53 <fcolista> Thanks SpaceToast
2019-09-09 13:03:06 <fcolista> I'm interested in knowing if/when we can move lxd to community
2019-09-09 13:03:21 <fcolista> for each version they mess up the things
2019-09-09 13:04:07 <fcolista> 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 <fcolista> *qlite
2019-09-09 15:02:17 <SpaceToast> fcolista: I still encounter the same bug on 3.17
2019-09-09 15:02:35 <SpaceToast> 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 <SpaceToast> 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 <SpaceToast> the real device is veth932fea0f@veth0
2019-09-09 15:02:56 <fcolista> do you think that is an alpine issue, or an upstream issue?
2019-09-09 15:03:04 <fcolista> can you give a static name to the iface?
2019-09-09 15:03:24 <SpaceToast> it's a bridged autogenerated iface, not sure how I'd do that
2019-09-09 15:03:33 <SpaceToast> iirc it needs extra logic for actually doing the pairing bit
2019-09-09 15:04:09 <SpaceToast> upstream is clearly using their stuff to some degree, but it's clearly related to upstream
2019-09-09 15:04:26 <SpaceToast> they changed their internal NIC logic in the 3.16 release, which is when this started happening
2019-09-09 15:04:33 <SpaceToast> so something in their new logic isn't playing well with alpine
2019-09-09 15:05:03 <fcolista> ok
2019-09-09 15:05:17 <fcolista> yes makes sense what you say
2019-09-09 15:06:04 <fcolista> i think this is related to some systemd compatibility stuff
2019-09-09 15:08:42 <SpaceToast> possibly :)
2019-09-09 16:22:16 <mps> maxice8: should the testing/quickjs be disabled again till it tested on CI or some local build
2019-09-09 16:33:35 <maxice8> Anyone feel free to disable it
2019-09-09 16:34:40 <maxice8> 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 <maxice8> But I'm driving atm so can't do anything
2019-09-09 16:35:11 <mps> aha, ok. understand
2019-09-09 16:35:19 <mps> I will disable it for now
2019-09-09 16:44:36 <SpaceToast> mps: it passes on every local build attempted (at least 3 machines)
2019-09-09 16:44:49 <SpaceToast> it looks like yet another issue caused by our weird lxc configuration
2019-09-09 16:45:03 <SpaceToast> 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 <mps> yes, I see it fails on test and message is strange
2019-09-09 16:46:14 <mps> I suspect the problem is with builders
2019-09-09 16:46:46 <SpaceToast> We've seen this stuff before, yeah
2019-09-09 16:47:18 <SpaceToast> 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 <mps> right, also I had issues sometimes with builders
2019-09-09 16:52:56 <mps> 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 <SpaceToast> mps: I think just disabling tests is fine
2019-09-09 16:53:28 <SpaceToast> Via options=!check
2019-09-09 16:55:41 <mps> and add note after '# enable check again when builders are fixed' or '# disabled because bug/issue in builders'
2019-09-09 16:57:12 <SpaceToast> That last one, thank you :)
2019-09-09 16:57:25 <mps> ah, ok
2019-09-09 16:58:03 <SpaceToast> 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 <mps> I'll fix source by moving url to be on same line
2019-09-09 17:11:30 <mps> SpaceToast: it fails on s390x and ppc64le
2019-09-09 17:12:27 <SpaceToast> mps: ok, you can disable those
2019-09-09 17:12:38 <SpaceToast> I only tested on amd64 since I have no other hardware
2019-09-09 17:12:50 <SpaceToast> I think it might use some asm so that would make sense
2019-09-09 17:13:33 <SpaceToast> And sorry for the trouble, I did mention that in the MR :)
2019-09-09 17:15:36 <mps> 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 <mps> I would give it yet another chance on those two to see will it segfault again
2019-09-09 17:17:05 <SpaceToast> Would be nice if we had ci on gitlab
2019-09-09 17:17:22 <mps> can't wait also
2019-09-09 17:17:59 <SpaceToast> 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 <mps> hope when _ikk_e_ comes back that he will continue his work
2019-09-09 19:17:54 <TML> 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 <TML> can anyone tel me what's required to move that into the main branch?
2019-09-09 19:18:12 <TML> s/tel/tell/
2019-09-09 19:24:05 <mps> TML: isn't enough to move it to community
2019-09-09 19:25:46 <mps> and package doesn't have maintainer field so I'm not sure it should go in main
2019-09-09 19:27:45 <TML> 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 <mps> pkgname is wrong "SON ..." instead of "JSON ..." I think
2019-09-09 19:28:56 <TML> yes, I noticed that as well
2019-09-09 19:29:02 <mps> and do you know why test is disabled
2019-09-09 19:30:46 <mps> oh, doesn't have tests, I think
2019-09-09 19:32:22 <mps> license looks non-standard and not MIT as is in APKBUILD
2019-09-09 19:33:44 <TML> it's MIT
2019-09-09 19:33:51 <TML> https://github.com/keenerd/jshon/blob/master/LICENSE
2019-09-09 19:35:43 <mps> aha, I see
2019-09-09 19:36:13 <clandmeter> TML: Fix the issues and claim it
2019-09-09 19:36:30 <clandmeter> Does it work ok?
2019-09-09 19:36:49 <TML> Yes
2019-09-09 19:36:54 <clandmeter> Looks like the tests are disabled
2019-09-09 19:37:00 <clandmeter> Not sure why
2019-09-09 19:37:07 <mps> clandmeter: doesn't have tests
2019-09-09 19:37:37 <mps> check() function can be removed
2019-09-09 19:37:40 <clandmeter> Ok then please remove it
2019-09-09 19:39:24 <mps> and source field, jshon-$pkgver.tar.gz::ht...... => $pkgname-$pkgver.tar.gz::ht.....
2019-09-09 19:40:10 <clandmeter> Not so important..
2019-09-09 19:40:39 <clandmeter> It's still done by newapkbuild
2019-09-09 19:40:40 <mps> well, not important but nice to be like other pkgs
2019-09-09 19:41:03 <clandmeter> So will happen to more new ones
2019-09-09 19:41:24 <mps> really, didn't noticed
2019-09-09 19:41:33 <clandmeter> I think it still is
2019-09-09 19:42:27 <clandmeter> I will be out
2019-09-09 19:42:57 <clandmeter> Maybe mps can apply it to community
2019-09-09 19:43:12 <clandmeter> Ones a patch of provided
2019-09-09 19:43:45 <mps> np, I will
2019-09-09 19:45:08 <mps> TML: just send msg here mentioning my nick when you finish
2019-09-09 19:45:52 <mps> and you can remove 'cd "$builddir"' from functions
2019-09-09 19:46:03 <mps> it is now default
2019-09-09 19:46:31 <TML> would it be better to just do a newapkbuild for it so everything is using the new structure?
2019-09-09 19:49:03 <mps> no, it would be good to have history of package in alpine
2019-09-09 19:50:07 <mps> it is not hard to change current APKBUILD
2019-09-09 19:57:44 <PureTryOut[m]> 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 <PureTryOut[m]> Actually I can probably just send the rest in a new patch set
2019-09-09 20:01:05 <PureTryOut[m]> Actually no it just blocked me, I can't send any new patches...
2019-09-09 20:01:24 <PureTryOut[m]> I guess I'll use Github instead then... ddevault could you unblock me I guess?
2019-09-09 20:13:18 <mps> just noticed that firefox APKBUILD doesn't have check() and doesn't options="!check"
2019-09-09 21:28:58 <maxice8> Need a merge for pr10930
2019-09-09 21:42:26 <ddevault> PureTryOut[m]: blocked?
2019-09-09 22:17:08 <maxice8> Need  a  merge for  pr10930
2019-09-09 23:35:04 <maxice8> Need  a  merge for  pr10930
2019-09-10 05:34:52 <PureTryOut[m]> 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 <Cogitri> 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 <mps> 
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 <wsinatra> 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 <wsinatra> 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 <wsinatra> 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 <clandmeter> It's the only way
2019-09-10 15:23:01 <clandmeter> Or setup your own ci
2019-09-10 15:23:20 <wsinatra> That's what I figured. I should probably look long term at setting up my own
2019-09-10 15:24:20 <wsinatra> 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 <wsinatra> 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 <mps> probably problem on 32bit arch's
2019-09-10 17:05:30 <wsinatra> Something that makes it unbuildable?
2019-09-10 17:05:44 <wsinatra> 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 <mps> not sure, do you have any info about that
2019-09-10 17:06:25 <nmeum> 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 <mps> I can try to build it on armv7 to see if it works
2019-09-10 17:07:17 <wsinatra> nmeum good point on the chroot, also if you don't mind mps I would appreciate that!
2019-09-10 17:07:55 <wsinatra> 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 <mps> building :)
2019-09-10 17:08:59 <mps> passed :)
2019-09-10 17:09:03 <mps> on armv7
2019-09-10 17:09:25 <wsinatra> That's a wonderful sign! Thank you mps!
2019-09-10 17:09:34 <mps> I can try later on my x86 lxc
2019-09-10 17:10:39 <mps> now I'm building 5.2.14 kernel, and don't want to stop it
2019-09-10 17:12:03 <wsinatra> I'm impatient and pushed a PR, looks like it builds across everything
2019-09-10 17:12:41 <wsinatra> It didn't have a maintainer, so that's probably all that it was.
2019-09-10 17:13:17 <mps> if you can wait 20-30 minutes I'll check x86 build
2019-09-10 17:14:10 <mps> if it builds on armv7 I presume it will also on armhf
2019-09-10 17:14:40 <wsinatra> Yeah I believe so, they're not all that different
2019-09-10 17:16:15 <mps> let me finish with kernel first
2019-09-10 17:16:44 <wsinatra> No worries, I'd say working on the kernel is probably more important
2019-09-10 17:21:40 <mps> wsinatra: pass on x86
2019-09-10 17:21:55 <wsinatra> Perfect :D
2019-09-10 17:22:04 <wsinatra> Thank you so much for the help mps!
2019-09-10 17:22:28 <nmeum> ,
2019-09-10 17:22:30 <nmeum> oops
2019-09-10 17:22:45 <nmeum> 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 <mps> nmeum: what is PR number
2019-09-10 17:23:26 <wsinatra> Pull Request on git
2019-09-10 17:23:38 <wsinatra> nmeum yeah I think it's good to merge as is
2019-09-10 17:23:42 <mps> yes, number
2019-09-10 17:23:50 <wsinatra> #11267
2019-09-10 17:23:59 <mps> give me minute
2019-09-10 17:24:09 <nmeum> ok
2019-09-10 17:24:47 <mps> algitbot: what's with you
2019-09-10 17:24:58 <wsinatra> It doesn't like my PRs
2019-09-10 17:26:19 <mps> nmeum: looks ok
2019-09-10 17:26:23 <nmeum> ok great
2019-09-10 17:26:29 <nmeum> let's see if passes on the builders as well …
2019-09-10 17:26:51 <mps> yes
2019-09-10 17:27:19 <nmeum> pushed
2019-09-10 17:27:44 <wsinatra> Wonderful! One step closer to SBCL everywhere
2019-09-10 17:28:08 <nmeum> \o/
2019-09-10 17:28:28 <mps> looks like it passed armhf
2019-09-10 17:28:53 <mps> what is SBCL?
2019-09-10 17:29:07 <wsinatra> Steel Bank Common Lisp
2019-09-10 17:30:09 <mps> 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 <mps> s/new to/new to me/
2019-09-10 17:30:46 <wsinatra> It's an implementation really. But it's probably the most popular one currently
2019-09-10 17:30:59 <wsinatra> In active development, 20 years old as well as of this year
2019-09-10 17:31:14 <mps> thanks for info
2019-09-10 17:32:10 <wsinatra> Don't mention it
2019-09-10 17:32:29 <nmeum> wsinatra: just out of curiousity: have you considered bootstraping sbcl with an implementation other than clisp?
2019-09-10 17:33:07 <wsinatra> I would be lying if I said yes haha. I know it's possible to do though
2019-09-10 17:33:40 <nmeum> 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 <wsinatra> 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 <wsinatra> last update was 2010 I think for clisp
2019-09-10 17:34:03 <nmeum> yeah
2019-09-10 17:34:10 <nmeum> but I guess we can stick to clisp for now
2019-09-10 17:34:24 <nmeum> at least as long as it is good enough for bootstraping sbcl :)
2019-09-10 17:34:24 <wsinatra> I honestly don't know anyone that uses clisp, so I really only have it there for SBCL
2019-09-10 17:34:31 <nmeum> right
2019-09-10 17:35:07 <wsinatra> I'll look into it though, because it's kind of just bloat. It exists to make SBCL
2019-09-10 17:42:51 <SpaceToast> 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 <maxice8> All builders are failing to upload packages
2019-09-11 06:58:12 <fcolista> SpaceToast, great, thanks!
2019-09-11 07:35:15 <nmeum> 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 <ahmedbilal> 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 <ahmedbilal> 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 <mps> 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 <mps> s/build/build fail/
2019-09-11 10:02:01 <Cogitri> nmeum: Ah, thought SpaceToast had sent you that already
2019-09-11 10:02:58 <Cogitri> ahmedbilal: Just use apk, that does what you want
2019-09-11 10:04:09 <Cogitri> 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 <Cogitri> No need to patch pip
2019-09-11 10:04:42 <ahmedbilal> Cogitri: Then, we have to figure out dependencies and their subdependencies
2019-09-11 10:06:06 <ahmedbilal> 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 <mps> ncopa: did you looked at #10783
2019-09-11 10:12:40 <mps> firefox on aarch64 waits for fixing that ;)
2019-09-11 10:24:41 <ncopa> mps: im not sure whats wrong with #10783
2019-09-11 10:27:10 <mps> 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 <mps> maybe something is messed on my builder
2019-09-11 10:30:14 <mps> I can, ofc, but may I :)
2019-09-11 10:42:59 <ncopa> can you please tpaste the patch here?
2019-09-11 10:47:22 <mps> here it is http://tpaste.us/nMmV please ignore some comments there for now
2019-09-11 10:55:27 <artok> 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 <mps> 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 <artok> indeed that is problem with upstream sources
2019-09-11 11:01:18 <mps> we still don't have $arch-alpine-linux-musl{eabixx} target in rust
2019-09-11 11:02:59 <mps> (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 <MY-R> 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 <mps> 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 <MY-R> mps, but tpaste is alpine project
2019-09-11 11:41:39 <mps> really? I will call it apaste then ;)
2019-09-11 11:42:04 <MY-R> mps, https://github.com/alpinelinux/turbo-paste
2019-09-11 11:42:38 <mps> yes, I know, but kidding a little
2019-09-11 11:42:42 <MY-R> :<
2019-09-11 11:43:34 <Cogitri> 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 <Cogitri> And way better than us making a package registry for musl python packages
2019-09-11 11:57:33 <artok> and pythonic way is to have virtual environments anyway
2019-09-11 12:45:34 <maxice8> @ncopa ping: i got security upgrades for a package in main/ pr11299 up to pr11302
2019-09-11 14:41:27 <SpaceToast> 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 <fcolista> SpaceToast, doing right now
2019-09-11 14:43:09 <SpaceToast> I already checked, installing iproute2 in my test environment resolves the issue
2019-09-11 14:43:23 <fcolista> Yes I saw that on https://github.com/lxc/lxd/issues/6185
2019-09-11 14:47:43 <fcolista> SpaceToast :  https://git.alpinelinux.org/aports/commit/?id=97edbbad
2019-09-11 14:47:54 <SpaceToast> thanks :)
2019-09-11 14:47:59 <fcolista> np
2019-09-11 15:38:15 <Cogitri> Could someone test something for me on s390x?
2019-09-11 18:16:10 <maxice8> PureTryOut: it is in community now
2019-09-11 18:51:20 <iggy> 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 <Cogitri> Well, depends on what is smaller chunks for you
2019-09-11 18:52:58 <Cogitri> 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 <mps> also depends of importance of patches
2019-09-11 18:53:07 <Cogitri> Where have you posted your patch?
2019-09-11 18:53:31 <Cogitri> mps: At least I won't prioritze patches unless it's about security stuff
2019-09-11 18:53:38 <mps> does they fix bugs, security issue or something else
2019-09-11 18:53:54 <Cogitri> I don't want to scare of new contributors with long waiting times
2019-09-11 18:54:04 <mps> Cogitri: just didn't wrote in time :)
2019-09-11 18:54:14 <Cogitri> iggy: Where have you sent your patch?
2019-09-11 18:54:15 <Cogitri> s/sent/posted/
2019-09-11 18:54:26 <iggy> It's a github PR that's been open for 4 months
2019-09-11 18:54:32 <Cogitri> Oh my
2019-09-11 18:54:52 <mps> also I don't want, but wanted to add to your msg
2019-09-11 18:55:19 <Cogitri> iggy: Mind spinning me a link?
2019-09-11 18:55:22 <mps> iggy: can you post url
2019-09-11 18:55:29 <mps> ehm
2019-09-11 18:55:32 <iggy> https://github.com/alpinelinux/aports/pull/7894/
2019-09-11 18:56:14 <mps> isn't this already merged?
2019-09-11 18:56:45 <Cogitri> Seems like only the ceph to $pkgname change is left
2019-09-11 18:58:30 <iggy> oh, it got merged yesterday (I cleaned up the s/ceph/$pkgname/ today)
2019-09-11 18:59:23 <iggy> but the github PR didn't get updated, so I will just close that I guess
2019-09-11 19:00:01 <mps> looks such
2019-09-11 19:00:57 <iggy> 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 <mps> well, somewhat messy for now, we have ML patches, github PR's and gitlab MR's
2019-09-11 19:02:18 <iggy> 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 <mps> I hope this will be consolidated 'real soon now' to gitlab only
2019-09-11 19:02:31 <iggy> mps: which is preferred?
2019-09-11 19:03:07 <mps> for now looks like github is fastest and have more attention
2019-09-11 19:03:46 <mps> but plan is to move to gitlab
2019-09-11 19:04:53 <mps> on gitlab is already moved bug/issue report so will be easier to 'connect' with patches
2019-09-12 04:18:13 <dimon222[m]> hello guys, i got notification of one of my packages outdated, but wanted to confirm quickly
2019-09-12 04:18:14 <dimon222[m]> 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 <dimon222[m]> 2. python2 is obsolete? i maintain metapackage, should i remove it and maintain py3 package instead?
2019-09-12 04:18:53 <maxice8> 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 <maxice8> 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 <dimon222[m]> 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 <dimon222[m]> dont know if anyone is relying on python2 version still, but alpine repository shows couple of depended packages
2019-09-12 04:21:31 <maxice8> yes, py-requests and py-tornado depend on py2-certifi
2019-09-12 04:22:46 <maxice8> that is unfortunate, better wait until work is done on making py3-requests and py3-tornado
2019-09-12 04:23:23 <dimon222[m]> is it possible to have on alpine both metapackage and the py3 package or its a conflict?
2019-09-12 04:23:41 <maxice8> metapackage you mean py-foo ?
2019-09-12 04:23:47 <dimon222[m]> yep
2019-09-12 04:24:03 <dimon222[m]> i'm just curious what could be "smooth" migration plan in this case
2019-09-12 04:24:57 <maxice8> 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 <dimon222[m]> i see, but long-term basically removing "py-" altogether and enforce usage of "py3-" notation, right?
2019-09-12 04:26:25 <dimon222[m]> i guess i could contribute some of these migrations, might be worthy
2019-09-12 05:50:06 <ncopa> im pushing gcc9 now
2019-09-12 05:50:22 <maxice8> oh nice
2019-09-12 05:50:23 <maxice8> :D
2019-09-12 05:52:26 <ncopa> i am slightly worried about arm* though
2019-09-12 05:52:50 <ncopa> https://gcc.gnu.org/gcc-9/changes.html
2019-09-12 05:52:57 <ncopa> it says it breaks ABI for arm*
2019-09-12 06:17:07 <mps> so, how software works today should anyone notice breakage ;)
2019-09-12 06:19:13 <mps> anyway, not first time that upgrades breaks something
2019-09-12 07:04:25 <iggy> ncopa: Thank you for merging my Ceph PR yesterday
2019-09-12 07:08:06 <ncopa> iggy: np. thanks for working on it
2019-09-12 09:24:08 <ahmedbilal> Can we install older version of Python 3.5? without compiling from source in Alpine 3.10?
2019-09-12 11:03:04 <ncopa> ahmedbilal: no
2019-09-12 11:03:30 <ncopa> well, i gues you could attach some older repo and hope for the best
2019-09-12 11:14:14 <tmhoang> 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 <tmhoang> *from me
2019-09-12 11:15:03 <tmhoang> and great thing we drop python2 in ceph
2019-09-12 11:37:40 <mps> 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 <mps> upgrade/fix quietly?
2019-09-12 11:40:19 <Cogitri> 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 <mps> 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 <mps> 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 <Cogitri> I don't think orphaning them is useful
2019-09-12 11:46:14 <mps> 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 <mps> 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 <Cogitri> Ah, on GitHub/Gitlab I'd just ping them and see if they respond
2019-09-12 11:53:56 <Cogitri> 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 <Cogitri> And minor/patch upgrades should be fine without maintainer approval if you just bump the pkgver
2019-09-12 11:55:51 <mps> I'm always feel shaky even for upgrades or small fixes if I don't ask maintainer first
2019-09-12 12:03:02 <Cogitri> Well, Alpine would grind to a halt if we had to ask the maintainer for every little change
2019-09-12 12:05:34 <MY-R> ye! contributing!
2019-09-12 12:06:22 <mps> 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 <mps> for example not about maintainer, active, last active, angry if touch pkg etc...
2019-09-12 12:07:13 <mps> s/not /note /
2019-09-12 12:09:02 <mps> ( and I'll out myself on 'angry list' in advance :D )
2019-09-12 12:09:18 <mps> s/out /put /
2019-09-12 12:10:07 <MY-R> somebody is angry because other person wanted help by contribution to project, no logic! :D
2019-09-12 12:10:09 <mps> 
ACTION need another patch for st term

2019-09-12 12:11:26 <mps> MY-R: no, if someone add bad changes then yes
2019-09-12 12:12:13 <mps> or break something
2019-09-12 12:12:26 <MY-R> but it is mostly about bump up version
2019-09-12 12:12:58 <MY-R> for that "edge" exist
2019-09-12 12:13:18 <mps> I'm not angry if someone do right things, even if not asking me. that's ok
2019-09-12 12:15:48 <mps> for example, I hesitated more than 3 months to start working on fixing clamav
2019-09-12 12:16:34 <mps> although current maintainer is really kind person (although with strange sense of humor :p)
2019-09-12 12:18:45 <mps> to finish my grumbling, some kind of inactive maintainers would be good to have, imo
2019-09-12 12:19:05 <MY-R> just keep away emotions/feelings from programming/fixing/contributing and all will be fine :D
2019-09-12 12:21:15 <mps> MY-R: you want me to like a marble :D
2019-09-12 12:21:29 <mps> to be*
2019-09-12 12:21:40 <MY-R> so what :D
2019-09-12 12:22:09 <mps> no, I prefer to live with feelings
2019-09-12 12:23:15 <MY-R> well, nothing wrong with feeling but with over-interpretation of them :P
2019-09-12 12:23:40 <MY-R> s/feeling/feelings
2019-09-12 12:25:03 <MY-R> ps I was afraid of today upgrade, gcc and firefox but looks like all working fine, thanks! :)
2019-09-12 12:25:40 <mps> I'm testing build firefox on aarch64 again with new gcc
2019-09-12 12:25:47 <mps> right now
2019-09-12 12:26:57 <mps> already upgraded fakeroot locally, seems good for now
2019-09-12 12:27:19 <MY-R> :)
2019-09-12 12:44:17 <mps> firefox-esr builds fine with gcc 9.2 on aarch64
2019-09-12 18:39:28 <xerireu> 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 <maxice8> library packages ?
2019-09-12 18:41:32 <xerireu> package containing a .so library
2019-09-12 18:42:06 <maxice8> libraries are also ELF binaries and have the same dependency tracing done to them
2019-09-12 18:43:27 <xerireu> when I build they don't, but my APKBUILD might be wrong
2019-09-12 18:43:36 <xerireu> I should mention it's a bunch of subpackages
2019-09-12 18:44:05 <maxice8> .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 <maxice8> 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 <xerireu> 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 <Cogitri> Be mindful that ldd also lists recursive deps
2019-09-12 18:55:47 <Cogitri> Use `readelf -a | grep NEEEDED` or lddtree
2019-09-12 18:56:49 <xerireu> I tried it the hard way (removing the dependency), but I'll check with readelf as well
2019-09-12 18:57:23 <xerireu> yup, the other libraries are there
2019-09-13 00:19:34 <iggy> 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 <ncopa> mps: i think updating packages is ok.
2019-09-13 06:44:46 <ncopa> if you are unsure, send a message to maintainer and ask "is this ok with you?"
2019-09-13 06:44:56 <ncopa> and give him a couple of days to respond
2019-09-13 06:45:32 <ncopa> 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 <ncopa> Cogitri: i think 1d68058f057b940aa3d695794abb1473542464c3 breaks atleast avahi-ui and py-dbus
2019-09-13 07:26:24 <Cogitri> Oh, sonehow I had thought py-dbus had been switched over to py3 already, my bad
2019-09-13 08:15:13 <Cogitri> Leo takes care of py-dbus, so I'll ask him about that
2019-09-13 08:22:13 <ncopa> ok
2019-09-13 09:26:10 <_ikke_> hiya everyone, I'm back
2019-09-13 09:26:31 <TBB> eek!
2019-09-13 09:26:33 <TBB> er, I mean
2019-09-13 09:26:37 <TBB> welcome back!
2019-09-13 09:26:43 <_ikke_> thanks
2019-09-13 09:26:43 <mps> _ikke_: welcome back :)
2019-09-13 09:53:40 <Cogitri> Welcome back ikke :)
2019-09-13 10:52:41 <_ikke_> Cogitri: thanks
2019-09-13 11:34:25 <Cogitri> (if so, could you please test the PR I pinged you in?)
2019-09-13 11:44:32 <Cogitri> Does Alpine Gitlab CI use the Gitlab-runner-helper Docker image?
2019-09-13 11:44:35 <Cogitri> 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 <maxice8> fcolista: moved py3-distro from testing to community to satisfy certbot
2019-09-13 12:37:27 <maxice8> 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 <Cogitri> Ah, alright
2019-09-13 19:20:45 <mps> 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 <mps> s/sure/not sure/
2019-09-13 19:37:46 <mps> 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 <mps> I think it should be added because support is added upstream, and wouldn't hurt to have it
2019-09-13 19:39:24 <maxice8> no objections from me but i don't use squashfs atm
2019-09-13 19:39:57 <mps> modloop uses it
2019-09-13 19:40:44 <maxice8> i'm not modloop
2019-09-13 19:41:20 <mps> :D
2019-09-13 20:02:25 <_ikke_> what is zstd? :)
2019-09-13 20:03:48 <maxice8> _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 <maxice8> 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 <TML> 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 <tcely> iggy: I saw an actual build error so did not add that label
2019-09-14 05:18:36 <clandmeter> [[sroracle]]: next week we hope to fix it
2019-09-14 05:19:29 <[[sroracle]]> good to hear :)
2019-09-14 08:43:28 <mps> TML: did you prepared patch for jshon?
2019-09-14 08:45:09 <mps> TML: and, I created MR for squashfs-tools with zstd support, !54
2019-09-14 13:19:44 <nicolaus> hello people
2019-09-14 13:20:02 <nicolaus> could someone add stagit to the alpine repos?
2019-09-14 13:20:08 <nicolaus> stagit - static git page generator (HTML).
2019-09-14 13:20:12 <nicolaus> https://git.codemadness.org/stagit/log.html
2019-09-14 13:20:18 <nicolaus> it's very similar to cgit
2019-09-14 13:20:30 <nicolaus> which I already made a guide for it
2019-09-14 13:20:34 <nicolaus> 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 <nicolaus> 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 <nicolaus> ok
2019-09-14 13:23:05 <nicolaus> thanks
2019-09-14 13:23:29 <nicolaus> i understand now, just found the url
2019-09-14 13:23:34 <_ikke_> ok, nice
2019-09-14 13:24:34 <nicolaus> i'll see if i can make it work in a few hours
2019-09-14 16:30:21 <pltrz[m]> 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 <pltrz[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/v1/download/matrix.org/QbegQqsWkZwmKSjjqSILrNkh >

2019-09-14 16:37:52 <Cogitri> I'd use docker-abuild for that
2019-09-14 16:38:44 <Cogitri> Or build in a chroot
2019-09-14 16:40:16 <pltrz[m]> 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 <pltrz[m]> <_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 <mps> 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 <mps> 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 <pltrz[m]> 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 <mps> also I did till today
2019-09-14 17:49:19 <iggy> 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 <maxice8> @fcolista can you take a look at https://lists.alpinelinux.org/~alpine/aports/patches/3020 ?
2019-09-14 21:25:28 <maxice8> qt5 + shiboken update from 5.12.4 to 5.12.5
2019-09-14 21:25:53 <mps> maxice8: git commit 6ff98ded2034f0d3003f264a102529e3d80b8e64
2019-09-14 21:26:17 <maxice8> mps: yes ?
2019-09-14 21:26:27 <mps> looks like you forgot bump pkgrel to mosh be rebuilt
2019-09-14 21:26:40 <maxice8> oh
2019-09-14 21:26:48 <maxice8> did you make a PR/MR/patch to have it pkgrel bumped ?
2019-09-14 21:26:52 <mps> or something else is issue
2019-09-14 21:27:27 <mps> no, I will left it for you, and will make it only if you don't care ;)
2019-09-14 21:27:38 <maxice8> just did it
2019-09-14 21:27:47 <maxice8> please don't shy away from doing it in the future
2019-09-14 21:27:53 <maxice8> the sooner the problem is fixed the better
2019-09-14 21:27:54 <mps> good :)
2019-09-14 21:28:25 <mps> np, noticed it about hour ago when tried to upgrade mosh
2019-09-14 21:29:37 <mps> 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 <maxice8> _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 <mps> could anyone with main push right push https://github.com/alpinelinux/aports/pull/11409
2019-09-15 11:49:33 <mps> it is needed for smooth upgrade to edge
2019-09-15 11:50:09 <mps> mosh rebuild with new protobuf by maxice8
2019-09-15 11:53:35 <PureTryOut[m]> 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 <Cogitri> PureTryOut: Maybe some of its deps isn't rebuilt (and that needs private qt symbols)?
2019-09-15 12:09:22 <mps> _ikke_: thanks
2019-09-15 13:00:18 <Cogitri> ncopa: It seems like our current musl-libintl thingie doesn't really work out
2019-09-15 13:01:42 <Cogitri> 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 <Cogitri> (or link libintl)
2019-09-15 13:36:04 <Cogitri> 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 <mps> (drop whatever you can to make alpine again small :) )
2019-09-15 14:03:43 <PureTryOut[m]> Cogitri: maybe, but I 'm not sure which dep
2019-09-15 14:04:30 <Cogitri> 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 <PureTryOut[m]> 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 <Cogitri> I don't think it can do that with Qt
2019-09-15 14:07:17 <Cogitri> Since it can't track the private symbols (unless we used something like an ABI scanner?)
2019-09-15 14:08:26 <PureTryOut[m]> 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 <Cogitri> I think qt5-qtbase provides that
2019-09-15 14:10:00 <PureTryOut[m]> 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 <mps> how to rename pkg to new upstream name, lm_sensors to lm-sensors
2019-09-15 16:35:35 <mps> git mv ?
2019-09-15 16:36:53 <maxice8> i have that in my ax personal tool
2019-09-15 16:37:43 <maxice8> 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 <maxice8> see almost any py3- package for example on how to replaces/provides
2019-09-15 16:40:33 <mps> maxice8: this tool is key of your productivity? ;)
2019-09-15 16:40:56 <maxice8> a piece, yes
2019-09-15 16:42:05 <mps> 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 <mps> 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 <mps> :o
2019-09-15 16:45:39 <mps> s/:o/:\/
2019-09-15 16:46:35 <_ikke_> Hmm, alpine-meetbot is missing
2019-09-15 16:47:11 <mps> 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 <alpine-meetbot> 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 <maxice8> _ikke_: re: versioning scheme change. maybe they saw that video on how to piss FOSS packagers off :D
2019-09-15 16:52:07 <mps> good, life will be less boring with 'it'
2019-09-15 16:52:32 <maxice8> 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 <maxice8> 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 <maxice8> 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 <maxice8> oh
2019-09-15 16:57:37 <maxice8> 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 <maxice8> 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 <mps> 60th MR on gitlab.a.o
2019-09-15 18:26:33 <mps> 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 <mps> linux 5.3 is released
2019-09-16 07:34:17 <mps> some new and interesting 'features' are included
2019-09-16 07:34:56 <mps> pidfd is nice thing
2019-09-16 07:37:08 <_ikke_> What does that do?
2019-09-16 07:37:09 <mps> and support for compressed firmware, alpine can be smaller
2019-09-16 07:38:48 <mps> 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 <mps> 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 <mps> and 16 million of new possible IP addresses
2019-09-16 07:41:43 <kr0k0> Hy guys
2019-09-16 07:42:33 <kr0k0> I have updated pr10951 with latest wireguard "release" today
2019-09-16 07:54:51 <mps> kr0k0: what are new features with this new WG release
2019-09-16 07:55:53 <mps> 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 <kr0k0> mps: I didn't find new features in the commits, only fixes
2019-09-16 07:58:28 <mps> fixes are important, so I will try this new release, thanks
2019-09-16 07:58:32 <kr0k0> mps: We should wait for kernel version 5.4, because this is the next lts release
2019-09-16 07:58:48 <mps> yes, I know
2019-09-16 07:59:30 <mps> 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 <kr0k0> I also don't understand, why the kernel updates in edge are not backported to 3.10...
2019-09-16 08:00:12 <mps> with 5.3 we can test a lot of changes introduced in a few latest major upgrades
2019-09-16 08:00:27 <kr0k0> mps: Yes, you are right.
2019-09-16 08:01:30 <mps> 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 <kr0k0> mps: This is a pity! Because we should be able to support the kernel for 2 years....
2019-09-16 08:26:06 <mps> anyway, I hope we will manage to add 5.4 to alpine 3.11 release
2019-09-16 08:28:38 <mps> 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 <mps> but not much reports from users is received
2019-09-16 08:29:49 <mps> so I hope it means: no new is good news :)
2019-09-16 08:45:19 <mps> heh, nice new thing in kernel 5.3 is automatic bigger fonts on console for high resolution screens
2019-09-16 09:18:33 <mps> 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 <PureTryOut[m]> 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 <fcolista> PureTryOut[m], sure!
2019-09-16 09:45:01 <fcolista> Go ahead
2019-09-16 09:45:48 <PureTryOut[m]> Awesome thanks!
2019-09-16 10:01:26 <PureTryOut[m]> 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 <mps> PureTryOut[m]: passwd.1 and passwd.5 should be in shadow and not openssl, imo
2019-09-16 10:08:23 <PureTryOut[m]> Of course
2019-09-16 10:08:37 <PureTryOut[m]> So would you guys be fine with just removing passwd.1 from openssl?
2019-09-16 10:08:57 <mps> not reemove, but rename
2019-09-16 10:09:14 <PureTryOut[m]> openssl-passwd.1 describes the same thing and is also installed by openssl
2019-09-16 10:09:39 <mps> (hm, need to fix xset rate)
2019-09-16 10:10:37 <mps> yes, i agree with openssl-passwd.1, and maybe other man's in openssl
2019-09-16 10:11:53 <PureTryOut[m]> No need to rename, openssl.passwd.1 literally describes the same thing and is already installed too
2019-09-16 10:12:54 <mps> i like how iproute named it's man pages
2019-09-16 10:15:10 <PureTryOut[m]> 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 <PureTryOut[m]> 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 <PureTryOut[m]> Oh nvm, renaming schemes 😒
2019-09-16 11:33:33 <PureTryOut[m]> 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 <PureTryOut[m]> I guess `source /etc/os-release` would be the easiest way to do it?
2019-09-16 11:35:37 <PureTryOut[m]> Although on edge repos `VERSION_ID` is  "3.11_alpha20190809" there rather than just "edge"
2019-09-16 14:40:11 <maxice8> PureTryOut: pushed that plymouth-kcm thing
2019-09-16 14:40:18 <maxice8> just removed a trailing space on the pkgdesc
2019-09-16 14:41:04 <PureTryOut[m]> Thanks!
2019-09-16 14:41:35 <PureTryOut[m]> 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 <maxice8> your series didn't get into patches
2019-09-16 14:43:34 <maxice8> it was stuck and broken down on archives
2019-09-16 14:43:43 <maxice8> i hate when it breaks like that
2019-09-16 14:45:56 <PureTryOut[m]> Ugh
2019-09-16 14:46:49 <PureTryOut[m]> Thanks for merging it though, I'll send the Kwin bump in a sec
2019-09-16 14:48:53 <PureTryOut[m]> https://lists.alpinelinux.org/~alpine/aports/patches/3023
2019-09-16 14:50:01 <maxice8> done
2019-09-16 14:50:14 <maxice8> and i'm going to play some Europa Universalis 4 now so no more merging
2019-09-16 14:50:19 <PureTryOut[m]> Thanks!
2019-09-16 16:15:14 <PureTryOut[m]> 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 <mps> any known reason why cpp (cxx) is not enabled in portaudio pkg
2019-09-16 21:22:09 <iggy> someone sent a github PR for that the other day
2019-09-16 21:23:47 <mps> oh, didn't know, already built it locally and thought to post patch
2019-09-16 21:24:00 <mps> heh, someone was faster
2019-09-16 21:25:35 <mps> ah, that was Cogitri
2019-09-17 06:17:52 <Cogitri> Oh right, thanks for the reminder, mps :)
2019-09-17 06:43:35 <mps> Cogitri: good morning :) your patch is better than my 'hack'
2019-09-17 06:51:36 <Cogitri> Morning :)
2019-09-17 06:51:47 <Cogitri> Will fix it up after math lesson (ugh :P)
2019-09-17 10:33:26 <PureTryOut[m]> This wiki page should probably be archived https://wiki.alpinelinux.org/wiki/Upgrade_to_repository_main
2019-09-17 14:24:16 <maxice8> So i got a lot of python3 conversions for main/
2019-09-17 14:44:58 <tcely> Please review pr9921
2019-09-17 14:46:57 <maxice8> 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 <tcely> abuild should one day have support for pc: versions and GPG verification too
2019-09-17 14:50:20 <maxice8> Ok i'll take a closer look as that day draws closer
2019-09-17 14:52:47 <tcely> https://github.com/alpinelinux/abuild/commit/9c284d4c33a421b14bf1ccf6d1b95324875f6937
2019-09-17 14:53:01 <tcely> https://github.com/alpinelinux/abuild/commit/7edafd8c75a5804867c342da75efbfae6432ca41
2019-09-17 14:53:18 <tcely> https://github.com/alpinelinux/abuild/pull/57
2019-09-17 14:53:58 <tcely> Hopefully at least the first two will be in the next abuild version
2019-09-17 14:56:51 <mps> tcely: and 3rd will be nice
2019-09-17 14:57:56 <tcely> It would! I have up waiting and just use my own abuild now.
2019-09-17 14:59:11 <tcely> s/have/gave/
2019-09-17 14:59:11 <alpine-meetbot> tcely meant to say: It would! I gave up waiting and just use my own abuild now.
2019-09-17 18:24:34 <mps> _ikke_: if you have time could you push MR !67
2019-09-17 18:38:49 <_ikke_> done
2019-09-17 18:41:45 <mps> _ikke_: thanks
2019-09-17 19:18:49 <mps> 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 <mps> _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 <mps> yes, retry
2019-09-18 08:33:01 <mps> 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 <Cogitri> mps: got merged
2019-09-18 09:21:06 <mps> I've seen it
2019-09-18 09:22:50 <mps> 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 <mps> Cogitri: I need this patch to push xournalpp, hope you will like it
2019-09-18 09:24:49 <Cogitri> Ah, you've packaged xournalpp too?
2019-09-18 09:25:04 <mps> yes, and using it
2019-09-18 09:25:15 <Cogitri> Or are you referring to pr11324
2019-09-18 09:25:43 <mps> just waiting for portaudio cpp fix
2019-09-18 09:26:35 <mps> ohm, we should have something like debian ITP (Intent To Package)
2019-09-18 09:27:32 <Cogitri> Yup
2019-09-18 09:27:53 <mps> and even WNPP (Work-Needing and Prospective Packages)
2019-09-18 09:28:43 <Cogitri> Sounds like a lot of organisational effort
2019-09-18 09:28:49 <Cogitri> Also, so you happen to use a Pen with Xournalpp?
2019-09-18 09:30:38 <mps> yes, pen. mouse is cumbersome (to say it politically correct) to me for such things
2019-09-18 09:31:26 <mps> did you tried 'abuild -r' on builder for your xournalpp?
2019-09-18 09:31:41 <Cogitri> s/so/do/
2019-09-18 09:31:41 <alpine-meetbot> Cogitri meant to say: Aldo, so you happen to use a Pen with Xournalpp?
2019-09-18 09:31:58 <Cogitri> Dang :P
2019-09-18 09:32:03 <mps> hehe
2019-09-18 09:32:21 <Cogitri> mps: Huh, it crashes for my with my pen unless increase the stack size
2019-09-18 09:32:50 <Cogitri> 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 <mps> I didn't used it much, just 2-3 days
2019-09-18 09:33:03 <Cogitri> Ah, I use it all the time for uni
2019-09-18 09:33:12 <Cogitri> Currently working with upstream to fix a few things
2019-09-18 09:33:25 <mps> looks like missing is LDFLAGS=-lexecinfo
2019-09-18 09:34:09 <mps> 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 <mps> s/if /if I /
2019-09-18 09:34:54 <alpine-meetbot> 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 <mps> and, I would prefer if you stay as maintainer
2019-09-18 09:36:30 <mps> I even thought to push my patch wiht empty maintainer field
2019-09-18 09:40:40 <Cogitri> Patch for execinfo is upstream already :)
2019-09-18 09:41:02 <Cogitri> Will restart CI once portaudiocpp is built on builders and will push if it works then, okay?
2019-09-18 09:42:36 <mps> ok, I'm not in hurry
2019-09-18 09:45:56 <TBB_> 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 <Cogitri> Xournalpp is pretty neat :)
2019-09-18 10:45:04 <Sodomon> very good to all
2019-09-18 11:15:34 <Sodomon> 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 <Sodomon1> :)
2019-09-18 11:18:57 <Cogitri> It's hard to review a massive PR with unrelated packages
2019-09-18 11:19:39 <Sodomon1> I don't understand
2019-09-18 11:20:03 <Sodomon1> Here's the pull. https://github.com/alpinelinux/aports/pull/10515
2019-09-18 11:20:20 <Cogitri> 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 <Cogitri> But if they're not related to each other it's better to split them
2019-09-18 11:21:32 <Cogitri> Yeaaah, I won't review a PR with over 60 commits, sorry
2019-09-18 11:21:37 <Cogitri> Please split that up a bit
2019-09-18 11:21:46 <Cogitri> With 60 commits CI doesn't really have a chance to run over it
2019-09-18 11:22:12 <Sodomon1> So if the packages are not related I can't pull with unrelated packages?
2019-09-18 11:23:14 <Cogitri> Well, you can do it, but it certainly won't make reviewers more motivated to review it :)
2019-09-18 11:23:27 <Cogitri> So please split it, so it's easier (or even possible) to review the thing
2019-09-18 11:23:58 <Sodomon1> Okay. Thank you.
2019-09-18 11:24:41 <Cogitri> Feel free to ping me once you've splitted it up, I can take a look then
2019-09-18 11:25:11 <Sodomon1> ok
2019-09-18 11:59:19 <Cogitri> mps: pushed xournalpp :)
2019-09-18 11:59:47 <mps> I see, good. didn't know you have push accces
2019-09-18 12:03:16 <Cogitri> Recently got them (hurray)
2019-09-18 12:05:20 <mps> good, I will not look to your patches anymore ;)
2019-09-18 12:06:45 <Cogitri> Well, I do welcome a review from time to time :P
2019-09-18 12:08:14 <mps> 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 <maxice8> ncopa: thanks for taking a look at main/
2019-09-18 14:10:28 <PureTryOut[m]> 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 <nmeum> yeah, I also noticed that
2019-09-18 14:11:02 <nmeum> would be nice to have some easy way to unflag them
2019-09-18 14:13:04 <mps> where they are flagged?
2019-09-18 14:13:48 <nmeum> pkgs.alpinelinux.org allows flagging packages as outdated
2019-09-18 14:13:59 <nmeum> and automatically sends an email to the package maintainer
2019-09-18 14:14:59 <mps> ah, didn't know that feature although receive mail sometimes and wonder how it is sent. thanks
2019-09-18 14:16:18 <nmeum> np
2019-09-18 14:19:40 <tcely> 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 <Cogitri> 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 <mps> just found this script https://github.com/arzzen/git-quick-stats
2019-09-18 17:05:35 <mps> interesting to see statistic about our activities
2019-09-18 17:07:31 <mps> we are most productive on Wednesday's ;)
2019-09-18 17:16:34 <artok> or monday-tuesday hangovers, wednesday just get's all the commits!
2019-09-18 17:20:51 <artok> all kinds of things you can do with big data
2019-09-18 17:22:44 <mps> 'statistic allows you to be drown in a glass of water' (or even half of glass) :D
2019-09-18 17:25:04 <artok> but still, based on those kind of statistics, most of the marketing money is transferred
2019-09-18 17:25:17 <artok> totally drowning people
2019-09-18 17:27:50 <mps> we are OT but, what else could be expected from civilization in which money is supreme $deity
2019-09-18 17:28:19 <artok> nothing more expected
2019-09-18 20:17:44 <Cogitri> Hm, could we maybe have the email mentioned by the bot in #alpine-commits too?
2019-09-18 20:17:53 <Cogitri> Then it'd get pinged if something goes wrong
2019-09-18 20:18:54 <_ikke_> what bot?
2019-09-18 20:24:11 <Cogitri> algitbot I guess
2019-09-18 20:27:00 <_ikke_> Then I don't understand your question
2019-09-18 20:29:50 <Cogitri> 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 <Cogitri> So I don't have to manually watch #alpine-commits or b.a.o
2019-09-18 22:23:26 <iggy> 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 <maxice8> 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 <iggy> 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 <maxice8> 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 <iggy> the only thing I could come up with was something like `main/<first letter>/<first 2 letters/pkg name` (i.e. `main/o/op/openssl` )
2019-09-18 22:28:06 <iggy> I'm sure there are smarter people than me that could think of something better
2019-09-18 22:34:38 <PureTryOut[m]> Should unmaintained packages in `community/` without other stuff depending on it be moved to `unmaintained/`?
2019-09-18 22:35:01 <maxice8> problably make a PR / Patch and see if there are interested parties
2019-09-18 22:35:25 <PureTryOut[m]> A patch to move it to `unmaintained/` then?
2019-09-18 22:35:35 <maxice8> yes
2019-09-18 22:38:02 <PureTryOut[m]> Ok thanks did so
2019-09-18 23:59:24 <maxice8> 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 <PureTryOut[m]> Hmm
2019-09-19 00:00:39 <maxice8> Plus you get free CI :D
2019-09-19 00:02:37 <PureTryOut[m]> I mean, I don't really want to
2019-09-19 00:02:52 <PureTryOut[m]> The PR bit, not the CI bit 😉
2019-09-19 00:03:19 <maxice8> idk why, it is functionally the same for me except using git send-email or hub pr
2019-09-19 02:56:34 <maxice8> 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 <clandmeter> Cogitri: cant you config your irc client to trigger on your name?
2019-09-19 07:25:27 <Cogitri> I don't think so :c
2019-09-19 07:25:51 <clandmeter> switch to a better client
2019-09-19 07:26:03 <clandmeter> 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 <clandmeter> oh ok
2019-09-19 07:27:04 <clandmeter> you want it for failures only?
2019-09-19 07:27:15 <Cogitri> Yes
2019-09-19 07:27:21 <Cogitri> That'd be very nice
2019-09-19 07:27:37 <clandmeter> 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 <clandmeter> yes and no
2019-09-19 07:28:24 <clandmeter> not directly
2019-09-19 07:28:41 <clandmeter> 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 <clandmeter> it also mentions the package is pushed
2019-09-19 07:29:21 <clandmeter> so there is a relation
2019-09-19 07:33:20 <clandmeter> Cogitri: you know you can subscribe to mqtt msg's?
2019-09-19 07:34:26 <Cogitri> I know mqtt but where do we publish the stream?
2019-09-19 07:34:33 <clandmeter> msg.a.o
2019-09-19 07:34:55 <clandmeter> we have a tool you can use called mqtt-exec
2019-09-19 07:35:47 <Cogitri> Ah, nice, thanks
2019-09-19 07:35:51 <clandmeter> it will listen on topic(s) and exec something when found.
2019-09-19 07:36:07 <clandmeter> this is how we trigger things via mqtt
2019-09-19 09:29:44 <PureTryOut[m]> <Cogitri "I don't think so :c"> Yeah you can
2019-09-19 09:31:08 <PureTryOut[m]> 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 <Cogitri> Oh my, how? :o
2019-09-19 09:42:56 <PureTryOut[m]> 
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 <PureTryOut[m]> 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 <Cogitri> Oh nice, thanks for the info!
2019-09-19 10:20:02 <Cogitri> Now it'd still be nice if some author information was included for failed builds
2019-09-19 13:37:28 <maxice8> PureTryOut: pushed retroarch, pkgrel wasn't resetted
2019-09-19 13:38:07 <PureTryOut[m]> Woops sorry
2019-09-19 13:41:57 <maxice8> no worries, ammended and pushed
2019-09-19 13:43:25 <mps> not much time left to freeze and main needs more upgrades and fixes
2019-09-19 13:51:13 <PureTryOut[m]> Cogitri: you should probably get GNOME into community before that
2019-09-19 13:51:59 <maxice8> mps: When is the freeze ?
2019-09-19 13:53:24 <mps> 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 <maxice8> that will make it very tight to remove python2
2019-09-19 13:54:38 <Cogitri> PureTryOut: Yup, will do it at the weekend
2019-09-19 13:55:18 <mps> maxice8: yes, and afaik python2 will 'die' in few months
2019-09-19 13:55:37 <maxice8> It will be EOL by january 2020 iirc
2019-09-19 13:56:25 <mps> ah, yes Jan
2019-09-19 13:56:31 <artok> eeeeh
2019-09-19 13:56:40 <artok> https://www.python.org/dev/peps/pep-0373/
2019-09-19 13:56:52 <artok> aaaand 2020 april you'll get yet another 2.7
2019-09-19 13:57:16 <mps> artok: 2020-04-01 you mean :D
2019-09-19 13:57:43 <artok> mps: that was my first reaction to the news, but then that url..
2019-09-19 14:00:19 <mps> back to subject, we need more care for main especially from people with push access right there
2019-09-19 14:43:34 <artok> hitting mkimage.sh --arch aarch64 just gives gzip: invalid magic
2019-09-19 14:44:54 <artok> ah well
2019-09-19 14:45:04 <artok> another things than the mkimage script
2019-09-19 15:20:14 <maxice8> 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 <ddevault> maxice8: that would be nice
2019-09-19 15:25:50 <maxice8> 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 <ddevault> thanks!
2019-09-19 15:39:49 <_ikke_> yeah, would make sense to me as well
2019-09-19 15:40:39 <ddevault> aye
2019-09-19 15:40:45 <ddevault> 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 <maxice8> 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 <maxice8> 
ACTION back to HOI4

2019-09-19 15:53:44 <mps> 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 <Cogitri> PureTryOut: Seems like the notification thing worked, thanks
2019-09-19 16:06:48 <PureTryOut[m]> No problem!
2019-09-19 17:24:27 <maxice8> :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 <Cogitri> Neat
2019-09-20 14:08:37 <z3ntu> 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 <ncopa> yes, that fixes it
2019-09-20 18:18:32 <maxice8> ddevault: merged tqdm with a few changes in a follow-up commit
2019-09-20 18:19:12 <ddevault> thanks maxice8
2019-09-21 13:14:55 <PureTryOut[m]> Cogitri: checking the fwupd you did, you disabled a patch but didn't remove it from the directory
2019-09-21 13:15:11 <Cogitri> Oh, oops
2019-09-21 13:15:20 <Cogitri> Thanks for the heads-up
2019-09-21 13:15:27 <PureTryOut[m]> Np
2019-09-21 14:30:43 <jjsearle> 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 <jjsearle> 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 <jjsearle> 'http://dl-cdn.alpinelinux.org/alpine/edge/main' is in /etc/apk/repositories
2019-09-21 14:39:17 <jjsearle> hmm it has just started working again, not sure what if anything I've just changed
2019-09-22 08:14:34 <mps> anyone with glm experience would look patch I made to upgrade it to 0.9.9.6
2019-09-22 08:15:47 <mps> upstream removed 'make install' so I use 'cp' in package()
2019-09-22 08:17:02 <mps> 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 <mps> or, just to push glm upgrate to aports and fix bugs later if they appears
2019-09-22 15:19:11 <gray_-_wolf> 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 <Cogitri> The latter
2019-09-22 15:29:18 <Cogitri> (Or a GitHub/Gitlab PR)
2019-09-22 16:55:45 <kr0k0> Hi all
2019-09-22 16:56:39 <kr0k0> Just a short reminder, please merge pr10951.
2019-09-22 16:57:23 <kr0k0> We are two releases behind...
2019-09-22 16:57:50 <Cogitri> I'll take a look once home
2019-09-22 16:58:09 <kr0k0> Cogitri: Thanks!
2019-09-22 16:58:26 <Cogitri> Does Wireguard actually work for you though?
2019-09-22 16:58:59 <kr0k0> Yes
2019-09-22 16:59:01 <Cogitri> I'm hit by https://gitlab.alpinelinux.org/alpine/aports/issues/10772 :c
2019-09-22 16:59:08 <Cogitri> It works fine on my mobile but the same config doesn't work on Alpine for me
2019-09-22 16:59:14 <Cogitri> Huh, weird
2019-09-22 17:03:34 <kr0k0> Hm...
2019-09-22 17:04:31 <kr0k0> I'm running on Alpine the "server side" and on Android, Windows and iOS the clients
2019-09-22 17:05:13 <Cogitri> Ah, alright
2019-09-22 17:05:31 <Cogitri> I'm running Alpine on the server side too and Alpine/Android on the client side
2019-09-22 17:20:05 <kr0k0> Cogitri: Is this a wg-quick problem? Because I'm not using it.
2019-09-22 17:21:06 <Cogitri> Dunno, I just know that wg-quick doesn't do the trick for me on the client side
2019-09-22 17:22:58 <Cogitri> 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 <kr0k0> Cogitri: Ah, nice
2019-09-22 18:33:19 <jjsearle> Cogitri: how do I tell whether a package will work on any arch?
2019-09-22 18:38:37 <jjsearle> or rather 'all'
2019-09-22 18:41:46 <Cogitri> CI will tell you for anything but ppc64le and s390x as of now
2019-09-22 18:41:52 <Cogitri> (Rust stuff generally works on everything but s390x tho)
2019-09-22 18:43:23 <jjsearle> 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 <jjsearle> *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 <jjsearle> thanks
2019-09-22 18:45:56 <_ikke_> maxice8: libqmi is failing on s390x
2019-09-22 18:59:20 <jjsearle> so after changing to 'all' it appears to be failing the tests on x86 armhf and armv7
2019-09-22 18:59:55 <jjsearle> should I just set arch to 'x86_64 aarch64'?
2019-09-22 19:00:12 <jjsearle> 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 <jjsearle> will do
2019-09-22 21:30:26 <Cogitri> fcolista: icigna is failing on s390x (possible due to a broken boost build?)
2019-09-23 06:41:16 <fcolista> Cogitri, I saw that...I was wondering to disable the build.
2019-09-23 06:56:22 <clandmeter> fcolista: got my pm?
2019-09-23 07:00:44 <fcolista> clandmeter, yes..going to ask him
2019-09-23 07:01:31 <fcolista> (sorry I back just today @work and read your pm)
2019-09-23 10:35:10 <mps> 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 <ncopa> 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 <mps> can anyone review and comment MR !75
2019-09-23 19:16:46 <_ikke_> It's still WIP? ;-)
2019-09-23 19:19:13 <mps> 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 <mps> 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 <mps> aha, ok.
2019-09-23 19:20:47 <mps> 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 <mps> 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 <mps> I tested build some pkg which depends on it
2019-09-23 19:22:33 <mps> libreoffice is big one, builds with this upgraded version worked
2019-09-23 19:23:22 <qa3Txu0iak0F> 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 <mps> 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 <mps> 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 <qa3Txu0iak0F> https://github.com/g-truc/glm/commit/5f352ecce21bb1ab37fa56fac0f383c779b351a3
2019-09-23 19:28:51 <qa3Txu0iak0F> >  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 <mps> 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 <mps> yes, I know
2019-09-23 19:31:18 <_ikke_> "You have to work on it"
2019-09-23 19:31:56 <mps> 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 <mps> 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 <mps> 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 <mps> I thought about that
2019-09-23 19:34:18 <mps> but was not sure
2019-09-23 19:34:25 <_ikke_> Me neither
2019-09-23 19:34:52 <mps> because this I asked here for opinions of other devs/people
2019-09-23 19:34:52 <qa3Txu0iak0F> 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 <mps> Arch maintainer also use 'cp'
2019-09-23 19:36:29 <mps> hmm, you remembered me to look what debian maintainer do
2019-09-23 19:36:55 <qa3Txu0iak0F> pinged the libreoffice dev, we'll see what they think of this.
2019-09-23 19:37:41 <mps> qa3Txu0iak0F: thanks
2019-09-23 19:40:12 <mps> 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 <mps> 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 <mps> so, this have to be added
2019-09-23 19:45:40 <qa3Txu0iak0F> yeah. .pc files are quite important
2019-09-23 19:46:21 <mps> agree but wonder how the libreoffice is built without it
2019-09-23 19:48:46 <Cogitri> I guess they're just probing for it manually
2019-09-23 19:49:36 <mps> libreoffice is smart ;-)
2019-09-23 19:53:25 <Cogitri> 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 <ddevault> bumping my old patch adding full disk encryption to setup-alpine
2019-09-23 20:17:31 <ddevault> 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 <ddevault> yes?
2019-09-23 20:19:04 <ddevault> 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 <ddevault> separate from?
2019-09-23 20:20:51 <_ikke_> separate from aports
2019-09-23 20:21:05 <ddevault> I didn't post it to aports
2019-09-23 20:21:07 <ddevault> 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 <ddevault> I see
2019-09-23 20:25:26 <ddevault> 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 <Roxanne> Hello
2019-09-23 20:33:38 <Roxanne> I wanted to add a package to alpine linux (namely dmd, the reference D language compiler)
2019-09-23 20:34:08 <Roxanne> is there any guidelines to follow? How does one do the process of submission? Thanks in advance
2019-09-23 20:34:13 <clandmeter> o/
2019-09-23 20:34:43 <_ikke_> Roxanne: Welcome
2019-09-23 20:34:47 <clandmeter> there is some information on the wiki
2019-09-23 20:35:09 <clandmeter> you can provide patches via github or ml
2019-09-23 20:35:15 <clandmeter> 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 <Roxanne> 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 <mps> _ikke_: is it ok to steal glm.pc from debian -_-
2019-09-23 20:41:11 <mps> 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 <mps> no
2019-09-23 20:42:51 <mps> debian have it as separate file
2019-09-23 20:43:10 <mps> or, can take it from previous version in alpine
2019-09-23 20:44:37 <mps> hmmm, this sound better option
2019-09-23 20:46:27 <mps> 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 <Roxanne> 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 <mps> Roxanne: home page
2019-09-23 20:51:40 <Roxanne> can the arch field be an array if I target both i386 and amd64
2019-09-23 20:52:07 <clandmeter> an array?
2019-09-23 20:52:10 <Roxanne> as in, arch="x86, x86_64"
2019-09-23 20:52:14 <maxice8> no, space-sparated list, arrays are a bash feature
2019-09-23 20:52:33 <mps> yes, without comma ','
2019-09-23 20:52:38 <Roxanne> thanks
2019-09-23 20:53:25 <clandmeter> 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 <Roxanne> 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 <maxice8> 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 <maxice8> 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 <iveqy> 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 <iveqy> 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 <iveqy> _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 <iveqy> _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 <iveqy> are you one of them? Do you happen to know the runtime of that command?
2019-09-24 05:32:50 <iveqy> _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 <clandmeter> iveqy: not all upgrades needs revdep rebuilds
2019-09-24 05:38:01 <iveqy> clandmeter: how do you determine which does?
2019-09-24 05:38:20 <clandmeter> Soname mostly
2019-09-24 05:38:40 <iveqy> I imagine that a change that does not alter a header file don't need it
2019-09-24 05:38:44 <clandmeter> 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 <clandmeter> We have tool called checkapk
2019-09-24 05:39:47 <clandmeter> It will compare new and current package
2019-09-24 05:39:47 <_ikke_> https://abi-laboratory.pro/
2019-09-24 05:41:42 <clandmeter> And the changelog does miracles too
2019-09-24 05:42:28 <iveqy> _ikke_: thanks I'll look into it
2019-09-24 05:43:05 <iveqy> 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 <iveqy> have I understood it correctly?
2019-09-24 05:43:27 <clandmeter> Some packages are notorious for breaking abi without a proper soname bump
2019-09-24 05:43:57 <clandmeter> Correct
2019-09-24 05:45:20 <clandmeter> We try to catch those charges with CI
2019-09-24 05:45:35 <clandmeter> _ikke_ is working on it
2019-09-24 05:47:09 <iveqy> a cool, I guess there's where api-laboratories comes in?
2019-09-24 05:47:32 <iveqy> why don't you just always rebuild all packages with reverse dependencies?
2019-09-24 06:38:57 <maxice8> How does everyone open merge requests on gitlab ? @mps
2019-09-24 06:41:06 <mps> maxice8: 'git push mps' and then go to WEB interface and clickety-clickety
2019-09-24 06:41:28 <mps> tried with 'lab' but it sometimes make a mess
2019-09-24 06:41:56 <maxice8> yes, found out lab wouldn't make merge requests
2019-09-24 06:42:01 <maxice8> neither fetch them properly
2019-09-24 06:42:06 <maxice8> so i'm writing my own script :D
2019-09-24 06:42:22 <mps> it can, but sometimes make a big mess
2019-09-24 06:43:31 <mps> 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 <mps> 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 <maxice8> @mps: https://i.imgur.com/sdMvsCT.png
2019-09-24 06:52:03 <mps> 'mkmr'? resolution is low so not see it clearly
2019-09-24 06:56:27 <mps> btw, !90 is secfix?
2019-09-24 06:58:17 <maxice8> mps: it is an upgrade with security implications
2019-09-24 06:59:37 <mps> I think it have CVE assigned, should be added in commit msg
2019-09-24 07:06:45 <mps> yes, https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint&id=8dbe7b475ec5e91ed767239f0e85880f416fc384
2019-09-24 07:07:02 <mps> CVE-2019-5094
2019-09-24 07:09:06 <maxice8> yes, i am aware of which cve it is
2019-09-24 07:11:55 <mps> aha, shouldn't it then be mentioned in git commit msg
2019-09-24 07:12:07 <maxice8> If you say so
2019-09-24 07:17:13 <mps> 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 <mps> maxice8: looks good :)
2019-09-24 07:22:58 <mps> and other MR's you posted looks fine
2019-09-24 09:42:09 <kvtb> 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 <mps> gitlab doesn't 'understand' newline in commit messages?
2019-09-24 09:42:54 <mps> kvtb: patchwork.a.o is retired
2019-09-24 09:43:43 <PureTryOut[m]> Most patches on the aports mailing list are applied, they just don't show up as such yet
2019-09-24 09:43:43 <mps> and, patches from ML applied for sure, not all though, but most yes
2019-09-24 09:44:18 <kvtb> 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 <kvtb> ok, thanks
2019-09-24 09:44:54 <mps> kvtb: fixes #issue_number
2019-09-24 09:45:45 <mps> maybe 'closes' also, but I never tested it
2019-09-24 09:46:36 <kvtb> 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 <mps> yes, that is good practice :)
2019-09-24 09:48:08 <mps> but you can create merge request directly on GL.a.o
2019-09-24 09:49:10 <mps> or on github pull request
2019-09-24 09:50:17 <kvtb> is there a preferred way for Alpine devs (mailing list vs merge/pull request) to handle patches?
2019-09-24 09:52:37 <PureTryOut[m]> 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 <PureTryOut[m]> Just use the way you prefer, mailing list or MR/PR
2019-09-24 09:52:56 <mps> 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 <mps> idea with GL is to consolidate all at one place
2019-09-24 09:54:06 <kvtb> OK - good to know
2019-09-24 09:57:16 <Cogitri> GitHub and Gitlab have CI, so they're better IMHO
2019-09-24 09:57:32 <Cogitri> 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 <Cogitri> Once we have CI on the MLs that could change I guess
2019-09-24 09:59:10 <mps> Cogitri: ddevault told earlier that he works on add CI to ML
2019-09-24 09:59:36 <Cogitri> Neat
2019-09-24 10:00:12 <mps> but as a user of ML I would prefer if can switch to one place, i.e. gitlab
2019-09-24 10:00:31 <mps> and forget about GH and ML
2019-09-24 10:22:51 <Cogitri> Yup, one central place would certainly be nice
2019-09-24 10:23:02 <Cogitri> Otherwise checking for duplicates and so on can be a bit tedious
2019-09-24 10:25:31 <kvtb> from new (and casual) contributer point of view, I agree
2019-09-24 10:27:54 <mps> well, bug/issue tracker is already moved
2019-09-24 10:28:13 <Cogitri> Yup, to Gitlab
2019-09-24 12:22:28 <ddevault> mps: CI is being worked on, I'm writing patches for libgit2 and pygit2 towards that end now
2019-09-24 12:26:40 <mps> ddevault: ah, good, so my memory works ;-)
2019-09-24 12:27:11 <ddevault> 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 <ddevault> 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 <ddevault> then it can fetch the .build.yml as well and submit it when emails come in
2019-09-24 14:59:57 <maxice8> Can someone take a look at !94 ?
2019-09-24 15:04:12 <clandmeter> maxice8: wansnt there some commit regarding ulogd today?
2019-09-24 15:04:28 <maxice8> There was
2019-09-24 15:04:45 <maxice8> 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 <maxice8> i did that in the merge request as well at first but now  i  just rebase
2019-09-24 15:05:59 <mps> maxice8: rnalrd
2019-09-24 15:06:38 <mps> you don't have nick tab completion in your irc client?
2019-09-24 15:07:51 <maxice8> 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 <clandmeter> matrix i guess
2019-09-24 15:08:37 <clandmeter> im looking at it
2019-09-24 15:08:40 <clandmeter> what should i see?
2019-09-24 15:08:51 <mps> '@' is for channel OP's in irc
2019-09-24 15:08:57 <maxice8> yes i use the web riot.im
2019-09-24 15:09:18 <clandmeter> i mean im looking at !94
2019-09-24 15:09:44 <mps> aha, I see, interesting you don't have [m] after your nick, as most of matrix users have
2019-09-24 15:10:10 <clandmeter> it has services to auth you and change your nick
2019-09-24 15:10:35 <Cogitri> You have to set your IRC nick manually to not have the [m]
2019-09-24 15:10:37 <mps> OT, I thought you are using 'real' irc client
2019-09-24 15:14:37 <clandmeter> 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 <maxice8> Just to make sure it doesn't burn your computer because of a missing output plugin
2019-09-24 15:15:52 <clandmeter> what are you waiting for?
2019-09-24 15:15:59 <maxice8> wait
2019-09-24 15:16:01 <maxice8> it wasn't already ?
2019-09-24 15:16:21 <_ikke_> To actually build apoegs
2019-09-24 15:16:21 <maxice8> 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 <maxice8> to actually build the packages changed in the MR
2019-09-24 15:17:01 <_ikke_> Correct
2019-09-24 15:17:49 <clandmeter> maxice8: you want  me review that MR?
2019-09-24 15:17:59 <Cogitri> Neat
2019-09-24 15:18:20 <Cogitri> The tags are automatically added to the builders?
2019-09-24 15:18:45 <maxice8> clandmeter: if possible i also need  someone with rights to main/ to push it
2019-09-24 15:19:09 <clandmeter> i think you missed pkgrel bump?
2019-09-24 15:19:27 <maxice8> yes
2019-09-24 15:19:42 <maxice8> i forgot that rnalrd  also bumped pkgrel to enable json
2019-09-24 15:19:55 <clandmeter> i think i have permission to push to main
2019-09-24 15:20:00 <maxice8> 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 <clandmeter> or somebody removed it
2019-09-24 15:20:14 <maxice8> so i rebase --abort  and  did it again and forgot the second time
2019-09-24 15:20:25 <clandmeter> i can add it if you like
2019-09-24 15:20:31 <maxice8> problably because i was wondering why my script to make merge requests was failing
2019-09-24 15:20:34 <maxice8> clandmeter: pushed already
2019-09-24 15:21:06 <clandmeter> that looks better :)
2019-09-24 15:21:15 <Cogitri> 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 <Cogitri> s/merged/merges/
2019-09-24 15:21:20 <alpine-meetbot> 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 <Cogitri> 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 <clandmeter> i havent touched the workflow on gitlab much, more focused on the internals atm.
2019-09-24 15:22:20 <clandmeter> i think _ikke_ knows more about MR workflow
2019-09-24 15:22:33 <clandmeter> 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 <clandmeter> we need to change origin
2019-09-24 15:22:50 <Cogitri> Alrighty 👍
2019-09-24 15:22:57 <clandmeter> 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 <Cogitri> Okie, thanks for the info
2019-09-24 15:23:26 <clandmeter> i think changing origin will be soon
2019-09-24 15:23:36 <clandmeter> soon ™️
2019-09-24 15:23:54 <_ikke_> 😉
2019-09-24 15:24:39 <mps> nice news
2019-09-24 15:25:08 <clandmeter> im trying to polish gitlab docker image a bit.
2019-09-24 15:25:56 <maxice8> that (tm) means valve time ?
2019-09-24 15:26:00 <Cogitri> 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 <Cogitri> (That's pr11636)
2019-09-24 15:27:25 <clandmeter> maxice8: valve time?
2019-09-24 15:27:47 <maxice8> https://developer.valvesoftware.com/wiki/Valve_Time
2019-09-24 15:28:14 <clandmeter> never heard of it before :)
2019-09-24 15:28:21 <clandmeter> valve is that gaming?
2019-09-24 15:29:14 <maxice8> valve is the company that makes that platform for online games, steam
2019-09-24 15:29:19 <Cogitri> Yes, the dev of steam
2019-09-24 15:29:21 <maxice8> they also made Half-Life and Counter-Strike and Dota
2019-09-24 15:29:23 <clandmeter> soon as i dont see many show stoppers to not switch
2019-09-24 15:29:25 <mps> Cogitri: is it free or non-free
2019-09-24 15:30:05 <clandmeter> we need some free time to actually do the swtich.
2019-09-24 15:31:19 <Cogitri> mps: You mean yed or steam?
2019-09-24 15:31:34 <mps> yed?
2019-09-24 15:31:41 <clandmeter> maxice8: ok, i think i heard about it before, but im not a gamer...
2019-09-24 15:31:44 <mps> as I see it is non-free
2019-09-24 15:32:49 <clandmeter> Cogitri: i dont understand your question
2019-09-24 15:32:56 <clandmeter> reg yed
2019-09-24 15:34:00 <mps> it shouldn't go to testing, imo
2019-09-24 15:34:11 <Cogitri> 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 <Cogitri> It doesn't, it's going to non-free
2019-09-24 15:34:40 <clandmeter> Cogitri: but its in testing or in non-free?
2019-09-24 15:34:41 <Cogitri> 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 <mps> whatever, it is non-free
2019-09-24 15:34:57 <clandmeter> _ikke_: its not a showstopper
2019-09-24 15:35:01 <_ikke_> Ok
2019-09-24 15:35:19 <clandmeter> Cogitri: we dont care about non-free, so i would leave the msg.
2019-09-24 15:35:22 <clandmeter> its not build
2019-09-24 15:35:46 <Cogitri> Alrighty then, thanks
2019-09-24 15:36:07 <clandmeter> if you build non-free things local you should know what you are doing.
2019-09-24 15:36:23 <clandmeter> but thats my personal opinion
2019-09-24 15:37:04 <clandmeter> _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 <clandmeter> could be it was in pm
2019-09-24 15:37:50 <clandmeter> it was a few months ago
2019-09-24 15:37:55 <clandmeter> memory is fading...
2019-09-24 15:41:57 <clandmeter> maxice8: will ulogd still work without additional plugins installed?
2019-09-24 15:42:43 <maxice8> worked for me but i'd like more testers since i don't use ulogd
2019-09-24 15:42:58 <clandmeter> so you want me to push it or not?
2019-09-24 15:43:22 <clandmeter> i think in my usecase it should work
2019-09-24 15:44:17 <maxice8> well, better wait
2019-09-24 15:44:36 <clandmeter> i dont mind breaking edge users
2019-09-24 15:44:51 <clandmeter> just need to make sure it doesnt happen when branching
2019-09-24 15:45:03 <clandmeter> or at least make it less painful :)
2019-09-24 15:45:15 <clandmeter> i think i use it with awall
2019-09-24 15:45:25 <clandmeter> to redirect kernel msgs to some logfile
2019-09-24 15:48:08 <maxice8> 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 <clandmeter> maxice8: why did you split logemu?
2019-09-24 15:51:54 <maxice8> I split almost all of them
2019-09-24 15:52:07 <maxice8> i might go and also split the ones that don't depend on any other libs
2019-09-24 15:52:25 <clandmeter> well they dont depend on only lib
2019-09-24 15:52:29 <clandmeter> like logemu
2019-09-24 15:52:43 <clandmeter> s/only/any
2019-09-24 15:52:44 <alpine-meetbot> clandmeter meant to say: well they dont depend on any lib
2019-09-24 15:53:26 <clandmeter> graphite logemu and nacct
2019-09-24 15:53:40 <ncopa> 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 <maxice8> clandmeter: should keep them in or just split for size reduction  ?
2019-09-24 15:54:52 <clandmeter> i wouldnt split them cause they are 32kb
2019-09-24 15:55:02 <clandmeter> and it would probably break more things as to fix things
2019-09-24 15:55:43 <clandmeter> i think i use logemu
2019-09-24 15:56:05 <clandmeter> its a common use case if you want to log to sep log file.
2019-09-24 15:56:20 <maxice8> ok i removed them from the split list
2019-09-24 15:57:19 <clandmeter> maxice8: what about graphite?
2019-09-24 15:57:46 <maxice8> missed it
2019-09-24 15:57:47 <maxice8> i'll rebuild and see the traced deps
2019-09-24 15:58:27 <maxice8> removed 'pcap' as well
2019-09-24 15:58:54 <clandmeter> right
2019-09-24 15:59:10 <clandmeter> i think we can merge it now
2019-09-24 15:59:54 <maxice8> sounds good
2019-09-24 16:01:29 <Cogitri> Can someone restart the Fractal build? Rust SIGSEGV'ed on most arches :/
2019-09-24 16:01:54 <clandmeter> Cogitri: you can do th at yourself
2019-09-24 16:02:02 <clandmeter> algitbot: retry master
2019-09-24 16:02:09 <Cogitri> Oh :o
2019-09-24 16:02:21 <clandmeter> except if it hangs
2019-09-24 16:02:39 <clandmeter> you can specifiy any branch
2019-09-24 16:02:53 <clandmeter> not sure it works here or you need to do it in commits
2019-09-24 16:05:30 <clandmeter> maxice8: can you close MR's?
2019-09-24 16:05:47 <maxice8> no
2019-09-24 16:06:09 <clandmeter> i think we should change that
2019-09-24 16:06:26 <maxice8> :D
2019-09-24 16:06:58 <clandmeter> 
ACTION opens his gitlab manual

2019-09-24 16:09:10 <mps> I think poster can close it's MR's
2019-09-24 16:09:40 <mps> at least I can close
2019-09-24 16:12:38 <clandmeter> mps: can you enable 2FA?
2019-09-24 16:13:24 <mps> what I need for this, some secret key?
2019-09-24 16:13:54 <maxice8> nice :D
2019-09-24 16:13:56 <mps> or account on some public (well known) services
2019-09-24 16:14:06 <clandmeter> https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html
2019-09-24 16:15:20 <mps> I read it earlier
2019-09-24 16:15:36 <mps> but 'Your browser doesn't support U2F. Please use Google Chrome desktop (version 41 or newer).'
2019-09-24 16:16:53 <clandmeter> hmm this gitlab interface is spooky
2019-09-24 16:17:19 <clandmeter> it doest need confirmation to switch between roles...
2019-09-24 16:17:30 <clandmeter> maxice8: do you have more options now?
2019-09-24 16:18:03 <maxice8> Sorry am out of keyboard
2019-09-24 16:18:05 <mps> ah, looks like I can install freeotp from f-droid
2019-09-24 16:18:09 <maxice8> I can answer in a few hours
2019-09-24 16:18:31 <clandmeter> Cogitri: and you?
2019-09-24 16:19:07 <clandmeter> keep in mind that you should not push to gitlab on aports
2019-09-24 16:19:16 <Cogitri> Won't do
2019-09-24 16:19:28 <Cogitri> <clandmeter "Cogitri: and you?"> What options should I see now? :o
2019-09-24 16:19:34 <clandmeter> Cogitri: can you now close other MR's?
2019-09-24 16:20:01 <Cogitri> Yup 👍
2019-09-24 16:23:28 <mps> 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 <mps> but now I have to install freeotp on phone
2019-09-24 16:25:43 <clandmeter> mps: you can also try Aegis
2019-09-24 16:25:45 <clandmeter> for android
2019-09-24 16:26:18 <mps> heh, aegis is first on list when searched for freeotp
2019-09-24 16:26:27 <Cogitri> Yup, aegis is pretty good
2019-09-24 16:28:16 <jjsearle> Yubikeys are good if you prefer hardware, I've had one on my keyring for a few years
2019-09-24 16:28:22 <jjsearle> https://www.yubico.com/products/yubikey-hardware/
2019-09-24 16:31:12 <_ikke_> Yeah, me too
2019-09-24 16:43:19 <mps> 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 <Cogitri> 2FA is TOTP or U2F for you?
2019-09-24 16:52:00 <mps> 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 <mps> I don't understand, I never used public accounts on mozzila site
2019-09-24 16:54:39 <Cogitri> You don't need a Mozilla account
2019-09-24 16:54:48 <Cogitri> Actually, there isn't anything browser specific for TOTP
2019-09-24 16:55:06 <mps> 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 <mps> 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 <mps> 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 <mps> 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 <mps> 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 <mps> thank you all for help, btw
2019-09-24 17:31:18 <wowaname> so the redmine bug tracker is gone?
2019-09-24 17:31:27 <wowaname> 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 <wowaname> 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 <wowaname> 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 <mps> _ikke_: yes, now there is a button 'close merge request'. nice
2019-09-24 17:36:35 <wowaname> 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 <wowaname> 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 <wowaname> oh
2019-09-24 17:38:34 <wowaname> makes sense
2019-09-24 17:39:56 <wowaname> thanks
2019-09-24 17:40:22 <_ikke_> np
2019-09-24 17:41:28 <wowaname> 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 <wowaname> 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 <mps> wowaname: quite understand your feelings
2019-09-24 17:42:55 <wowaname> my github account's long gone
2019-09-24 17:43:20 <wowaname> 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 <mps> but how the spam is everywhere I understand admins of bug report sites
2019-09-24 17:43:41 <wowaname> people who refuse to take patches via email and demand to use their github PR workflow
2019-09-24 17:43:57 <wowaname> yeah i saw some of the spam the AL bug tracker was getting
2019-09-24 17:44:13 <wowaname> this is why we cant have nice things
2019-09-24 17:45:51 <wowaname> 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 <wowaname> 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 <mps> 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 <wowaname> 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 <wowaname> 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 <wowaname> ive never paid much attention
2019-09-24 17:48:47 <wowaname> 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 <wowaname> void isnt worth my trouble lol
2019-09-24 17:48:57 <mps> bug fixes usually backported to latest stable
2019-09-24 17:49:23 <wowaname> 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 <wowaname> gotcha, thats what i thought
2019-09-24 17:50:08 <mps> secfix are backported to LTS's
2019-09-24 17:50:14 <wowaname> i'd have to check out 3.10-stable in aports and apply to that?
2019-09-24 17:50:27 <mps> right
2019-09-24 17:50:33 <wowaname> good stuff
2019-09-24 17:52:21 <mps> but only in main and community repos
2019-09-24 17:52:47 <mps> 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 <clandmeter> Yes
2019-09-24 17:56:05 <_ikke_> ok
2019-09-24 17:57:58 <_ikke_> p00f
2019-09-24 18:11:11 <wowaname> mps: well testing doesnt exist in the stable releases anyway, so i knew that lol
2019-09-24 18:11:59 <mps> good, just wanted to remind you in case you don't know this
2019-09-24 18:14:02 <wowaname> unbound is in main
2019-09-24 18:32:00 <_ikke_> !100 :-) (now with CI build)
2019-09-24 18:35:20 <mps> aieee! time to open red wine bottle ;-)
2019-09-24 18:35:29 <mps> https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/911
2019-09-24 18:49:51 <maxice8> clandmeter: back
2019-09-24 18:52:58 <Cogitri> Does the -dbg subpackage contain the debug info of the package's subpackages too?
2019-09-24 18:54:18 <wowaname> good question actually
2019-09-24 18:54:25 <wowaname> 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 <maxice8> 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 <mps> no, and yes
2019-09-24 19:28:34 <_ikke_> ok
2019-09-24 19:29:23 <mps> 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 <mps> 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 <mps> something about tabs and spaces
2019-09-24 19:31:19 <Cogitri> Different line ending formats are annoying :/
2019-09-24 19:31:25 <mps> 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 <mps> 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 <mps> I'm out right now
2019-09-24 19:32:35 <mps> will be back in about 45 minutes
2019-09-24 19:34:04 <mps> 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 <mps> 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 <mps> ah, ok
2019-09-24 19:35:41 <mps> I'm on their ML, and in last time they release often new versions
2019-09-24 19:36:08 <mps> usually small fixes, nothing serious or big changes
2019-09-24 19:41:18 <nicolaus> why is mongodb not in the alpine repos?
2019-09-24 19:42:08 <mps> nicolaus: license chaned, iirc
2019-09-24 19:42:08 <_ikke_> It's in non-free
2019-09-24 19:42:16 <nicolaus> ohhhh I didnt know that
2019-09-24 19:42:26 <maxice8> non-free/
2019-09-24 19:42:57 <nicolaus> guess I'll learn some other program now haha
2019-09-24 19:43:48 <maxice8> I have lots of Pull requests to drop python2 for stuff on main
2019-09-24 19:43:57 <maxice8> 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 <maxice8> 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 <maxice8> Thanks
2019-09-24 19:49:19 <wowaname> nice that py2's being phased out
2019-09-24 19:50:30 <Cogitri> Yup
2019-09-24 20:21:07 <mps> _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 <maxice8> PureTryOut: can you check out !117
2019-09-25 03:06:32 <terror> 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 <terror> Seems Alpine OpenJDK is ~10% slower that glibc based OpenJDK on the same hardware and configuration
2019-09-25 03:07:07 <terror> Details in https://github.com/DependencyTrack/dependency-track/pull/420
2019-09-25 04:17:10 <terror> 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 <iggy> 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 <jjsearle_work> 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 <jjsearle_work> 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 <Cogitri> 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 <Cogitri> We don't have a standardized review process AFAIK, so I just pick interesting ones by chance
2019-09-25 10:07:58 <Cogitri> I try to not let stuff sit around so much, but I only have so much time :c
2019-09-25 10:09:32 <mps> I look at bugs/issue first and then look for PR/MR which solves issue
2019-09-25 10:10:56 <mps> when I'm talking about issues, #10821
2019-09-25 10:11:37 <mps> anyone with deeper understanding lxc would look at it
2019-09-25 10:15:43 <jjsearle_work> fair enough, not complaining, just trying to understand
2019-09-25 10:17:05 <mps> secfixes and bugfixes have priority usually
2019-09-25 10:17:30 <mps> then comes feature requests
2019-09-25 10:18:29 <jjsearle_work> 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 <jjsearle_work> I use gitlab for work so it doesn't really matter so much to me
2019-09-25 10:19:15 <mps> 
ACTION would preffer that ;-)

2019-09-25 10:20:49 <mps> 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 <PureTryOut[m]> Wait, Gitlab supports sending patches via mail?
2019-09-25 10:22:04 <mps> yes, but not sure if CE or just EE
2019-09-25 10:22:56 <mps> TBH, never used it but read somewhere that it support it
2019-09-25 10:24:58 <jjsearle_work> 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 <mps> ah, yes, I read this, thanks for reminder
2019-09-25 10:39:13 <PureTryOut[m]> Awesome thanks for the link!
2019-09-25 10:43:01 <jjsearle_work> 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 <PureTryOut[m]> For me mainly that yeah. Also, not having to fork repositories
2019-09-25 10:46:54 <mps> there is 'lab' package for interacting with gitlab from cli
2019-09-25 10:47:07 <PureTryOut[m]> 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 <PureTryOut[m]> Uh git.sr.hit I mean
2019-09-25 10:47:34 <PureTryOut[m]> *git.sr.ht
2019-09-25 10:47:50 <mps> and maxice8 working on better cli for gitlab, hope he will release something RSN
2019-09-25 10:48:54 <PureTryOut[m]> 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 <hrio[m]> pr11547 should probably have a security label...
2019-09-25 10:56:14 <PureTryOut[m]> Hmm I don't see the button to get the email address for the Gitlab instance?
2019-09-25 10:56:29 <jjsearle_work> thanks for mentioning that lab tool. Looks like something that will be useful for work.
2019-09-25 10:56:36 <PureTryOut[m]> Is https://docs.gitlab.com/ce/administration/incoming_email.html enabled?
2019-09-25 11:36:52 <maxice8> mps: I just use mkmr
2019-09-25 11:37:06 <maxice8> Uses the gitlab v4 API to make the merge request
2019-09-25 11:38:07 <mps> didn't you created this 'mkmr' tool?
2019-09-25 11:58:50 <ncopa> i managed to get chromium 77 working, more or less
2019-09-25 11:59:13 <ncopa> there was a couple of syscalls that needed to be allowed in the sandbox
2019-09-25 13:04:45 <maxice8> mps: yes
2019-09-25 13:05:46 <maxice8> https://raw.githubusercontent.com/maxice8/meltryllis/master/bin/mkmr
2019-09-25 14:22:31 <wsinatra> 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 <mps> wsinatra: maybe "grep -r 'ln -s' main/" could give you idea
2019-09-25 14:25:31 <maxice8> softlinks?
2019-09-25 14:26:03 <mps> softlinks? I missread to symbolic links
2019-09-25 14:26:14 <Cogitri> ln -s
2019-09-25 14:26:28 <maxice8> Oh symlinks
2019-09-25 14:26:41 <wsinatra> yeah just softlinks, +1 to mps for the obvious answer though
2019-09-25 14:26:44 <mps> so, soft or symbolic :p
2019-09-25 14:34:28 <wsinatra> 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 <maxice8> mps: mkmr sadly depends on libsecret
2019-09-25 14:35:13 <maxice8> no idea where to safely store the gitlab access token needed to make the API call
2019-09-25 14:35:37 <mps> maxice8: yes, I noticed. but anyway writing anything useful today end in a lot of deps
2019-09-25 14:36:25 <maxice8> 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 <mps> what I do for some of my tools ;-)
2019-09-25 14:39:15 <ncopa> i just pushed new edge snapshot release
2019-09-25 14:39:54 <mps> I see, you don't write notes for edge snapshots?
2019-09-25 14:47:41 <maxice8> speaking of taking notes
2019-09-25 14:47:55 <maxice8> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.11.0_(ideas)
2019-09-25 14:52:43 <PureTryOut[m]> 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 <maxice8> Sure but later
2019-09-25 14:56:49 <maxice8> Am at subway
2019-09-25 14:58:48 <maxice8> The sandwich store not the place where train go but underground
2019-09-25 15:18:11 <wsinatra> 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 <mps> wsinatra: this is non-free, why it have to go to testing and not to non-free
2019-09-25 15:23:22 <wsinatra> 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 <wsinatra> The actual commit is in non-free/yed, but I started the PR as testing/yed mistakenly
2019-09-25 15:25:27 <mps> ah, so, I didn't looked last change
2019-09-25 15:26:13 <wsinatra> 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 <AinNero> Oh, hacktoberfest is approaching!
2019-09-25 15:34:57 <AinNero> 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 <mps> 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 <AinNero> mps: because thats what they are
2019-09-25 15:41:08 <AinNero> 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 <mps> and, don't forget this is money for some
2019-09-25 15:41:49 <AinNero> 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 <mps> 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 <mps> 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 <AinNero> also, people are so obsessed with outside attackers as threat
2019-09-25 15:44:29 <mps> thought to make MR later today
2019-09-25 15:44:35 <AinNero> what about race conditions that result in data corruption?
2019-09-25 15:44:56 <AinNero> 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 <mps> 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 <mps> 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 <mps> ah, there is postfix PR already, https://github.com/alpinelinux/aports/pull/11588
2019-09-25 16:44:08 <mps> saved me some time :)
2019-09-25 17:19:02 <maxice8> Ok back
2019-09-25 17:19:16 <maxice8> @PureTryOut https://lists.alpinelinux.org/~alpine/aports/patches/3063 already applied
2019-09-25 17:19:47 <maxice8> @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 <PureTryOut[m]> Oh huh, sorry
2019-09-25 17:19:57 <PureTryOut[m]> 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 <mps> 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 <Cogitri> 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 <mps> 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 <mps> well, it is not important (at least for now) to me, just noticed
2019-09-25 19:04:26 <jjsearle_> hey, does anyone care to weigh in on PR #11650 ?
2019-09-25 19:09:39 <Cogitri> 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 <mps> some of my MR's stays few weeks
2019-09-25 19:11:47 <Cogitri> Yes, sadly PRs to main/ take frankly way too long until they're getting merged
2019-09-25 19:11:58 <jjsearle_> 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 <Cogitri> But most stuff in main should be moved to community anyway, I suppose
2019-09-25 19:12:11 <jjsearle_> I am not asking for it to be merged now
2019-09-25 19:12:31 <Cogitri> Ah, okie. Feel free to ask about that stuff then :)
2019-09-25 19:12:35 <mps> Cogitri: some, I think
2019-09-25 19:13:19 <Cogitri> 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 <alpine-meetbot> _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 <Cogitri> Well, I don't have a problem with stuff being in main
2019-09-25 19:14:49 <Cogitri> 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 <jjsearle_> 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 <jjsearle_> is there an offical stance on this?
2019-09-25 19:15:30 <Cogitri> (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 <Cogitri> 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 <Cogitri> Although in retrospective I'm unsure if this nitpicking really is useful :/
2019-09-25 19:16:52 <jjsearle_> okay, I will continue removing it
2019-09-25 19:17:15 <mps> 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 <Cogitri> Yup
2019-09-25 19:17:52 <jjsearle_> thanks
2019-09-25 19:17:53 <mps> 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 <jjsearle_> 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 <ahills> alpine has s390x packages? wow
2019-09-25 20:07:36 <_ikke_> 0yes
2019-09-25 20:07:45 <ahills> 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 <ahills> cool!
2019-09-25 20:08:16 <ahills> IBM does?
2019-09-25 20:08:52 <_ikke_> Yes, they do
2019-09-25 20:08:54 <ahills> 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 <ahills> 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 <ahills> 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 <ahills> 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 <ahills> (looks like it comes preinstalled, I mean)
2019-09-25 20:49:04 <mps> 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 <mps> with '=' after?
2019-09-25 20:52:51 <mps> 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 <mps> 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 <mps> yes, make sense. I'm not versed in shell programming
2019-09-25 20:55:20 <mps> perl is for my 'shell' scripts
2019-09-25 21:08:36 <PureTryOut[m]> 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 <mps> and active maintainer
2019-09-25 21:10:46 <PureTryOut[m]> 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 <mps> and 'main' is for essential and base pkg's. some should be moved to community
2019-09-25 21:12:53 <PureTryOut[m]> 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 <PureTryOut[m]> Ok thanks for the info
2019-09-25 21:13:52 <mps> servers, compiler and similar also belongs to main
2019-09-25 21:14:09 <mps> 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 <mps> like void linux
2019-09-25 21:15:39 <mps> everything is in one repo
2019-09-25 22:20:09 <iggy> 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 <wsinatra> @_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 <maxice8> _ikke_: any progress on those py3- PRs ?
2019-09-26 08:32:45 <ncopa> dbg or gcc is broken
2019-09-26 08:32:59 <ncopa> gdb does not show C sources
2019-09-26 08:33:02 <ncopa> i dont know why
2019-09-26 08:37:00 <Cogitri> Hm, I think it works for me
2019-09-26 08:37:01 <Cogitri> Does it show something along the lines of "loading debug info....done" when you start gdb?
2019-09-26 08:39:58 <ncopa> no
2019-09-26 08:40:08 <ncopa> For help, type "help".
2019-09-26 08:40:08 <ncopa> Type "apropos word" to search for commands related to "word"...
2019-09-26 08:40:08 <ncopa> Reading symbols from hello...
2019-09-26 08:40:08 <ncopa> (gdb)
2019-09-26 08:42:20 <ncopa> gdb 8.3.1
2019-09-26 08:42:24 <Cogitri> Ah :c
2019-09-26 08:42:36 <ncopa> gcc (Alpine 9.2.0) 9.2.0
2019-09-26 08:42:51 <Cogitri> At least with stuff I've compiled myself it definitely worked
2019-09-26 08:42:59 <Cogitri> That was with clang though
2019-09-26 08:43:00 <Cogitri> I'll try later
2019-09-26 08:43:46 <ncopa> youre right
2019-09-26 08:43:49 <ncopa> it works with clang
2019-09-26 08:43:52 <ncopa> but not gcc
2019-09-26 08:45:35 <mps> 'GNU gdb (GDB) 8.3.1' on aarch64, edge works
2019-09-26 08:48:58 <ncopa> and gcc version?
2019-09-26 08:49:52 <mps> cc (Alpine 9.2.0) 9.2.0
2019-09-26 08:50:24 <mps> how can I check with wich version of gcc gdb is built
2019-09-26 08:50:42 <ncopa> i dont think gdb is broken
2019-09-26 08:50:52 <ncopa> i think its gcc that generates wrong -g
2019-09-26 08:51:10 <Cogitri> Odd
2019-09-26 08:51:46 <ncopa> yup, aarch64 works
2019-09-26 08:52:55 <ncopa> 32 bit x86
2019-09-26 08:53:27 <mps> right now I can check only on aarch64
2019-09-26 08:53:43 <ncopa> huh
2019-09-26 08:54:21 <ncopa> Temporary breakpoint 1, main () at hello.c:5
2019-09-26 08:54:21 <ncopa> 5               printf("hello world\n");
2019-09-26 08:54:21 <ncopa> (gdb)
2019-09-26 08:54:30 <ncopa> so it works on x86_64 too
2019-09-26 08:54:38 <ncopa> it must be something on my desktop
2019-09-26 08:55:26 <zarch> 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 <ncopa> zarch: whats the error message you get?
2019-09-26 08:56:57 <zarch> 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 <ncopa> 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 <zarch> Uploaded file: https://uploads.kiwiirc.com/files/d81ba0cdb354d9e94243e729879887ff/pasted.txt
2019-09-26 08:59:36 <zarch> ncopa, I can compile without errors with `abuild -r build` but I failed when I do: `abuild package`
2019-09-26 09:02:32 <ncopa> zarch: /bin/sh: can't create /usr/bin/grass78: Permission denied
2019-09-26 09:02:45 <ncopa> it tries to install in / rather than "$pkgdir"
2019-09-26 09:04:26 <ncopa> what happens if you do: abuild rootpkg?
2019-09-26 09:04:34 <zarch> dhooo! ok, I see...@ncopa... thank you!
2019-09-26 09:04:52 <ncopa> i think you cannot run `abuild package` like that
2019-09-26 09:05:01 <ncopa> it needs to be done via `abuild rootpkg`
2019-09-26 09:05:15 <ncopa> which will run it in fakeroot, and do the package spelitting
2019-09-26 09:05:28 <zarch> 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 <mps> also I do
2019-09-26 09:38:17 <ncopa> ok
2019-09-26 11:03:22 <tmhoang> 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 <tmhoang> 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 <ahills> 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 <ahills> ok
2019-09-26 11:08:16 <_ikke_> the alpinelinux images are available for s390x
2019-09-26 11:09:42 <tmhoang> ahills: you can request for s390x VM/apps, etc. in here
2019-09-26 11:09:43 <tmhoang> https://developer.ibm.com/linuxone/
2019-09-26 11:09:59 <tmhoang> from above link : for VM : https://developer.ibm.com/linuxone/request-vm/
2019-09-26 11:10:12 <tmhoang> kubernetes-based cluster : https://developer.ibm.com/linuxone/request-icp/
2019-09-26 11:10:26 <tmhoang> so on for blockchain - whatever it is
2019-09-26 11:11:33 <tmhoang> 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 <ahills> right, but hopefully I could run an Alpine container on RHEL easily
2019-09-26 11:22:02 <tmhoang> ahills : yes
2019-09-26 11:22:26 <tmhoang> you can actually run s390x emulation on qemu x86
2019-09-26 16:10:07 <mps> 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 <mps> 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 <mps> why? already have $_bootver for long time
2019-09-26 16:27:32 <_ikke_> Sorry, should not
2019-09-26 16:27:46 <mps> ahhh, thanks
2019-09-26 16:27:56 <mps> :)
2019-09-26 16:29:49 <mps> 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 <mps> about 150MB on every build
2019-09-26 16:31:50 <mps> _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 <mps> time issue, I think
2019-09-26 16:32:08 <Cogitri> mps: Was only required for bootstrapping, I'll remove them with the incoming version bump :)
2019-09-26 16:32:47 <mps> Cogitri: I'm not criticize you, just noted
2019-09-26 16:33:39 <Cogitri> Yup, just wanted to point out that that's going to change too
2019-09-26 16:33:41 <mps> I understand your reason, but will try also to change rust APKBUILD with $CTARGET for these files
2019-09-26 16:34:04 <mps> if you don't mind or you will change, ofc
2019-09-26 16:36:06 <Cogitri> 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 <mps> ok, understand. And thanks for good news :)
2019-09-26 16:37:50 <mps> anyway, this can't be done, i.e. using $CTARGET because of calcuting 'abuild checksum'
2019-09-26 17:00:20 <wsinatra> 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 <mps> ohm, upgraded lm-sensors (3.5.0) is a lot better
2019-09-26 18:19:37 <maxice8> _ikke_: oh ?
2019-09-26 18:19:43 <maxice8> also, which dependencies of py3-urwid are missing ?
2019-09-26 18:19:46 <maxice8> 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 <maxice8> 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 <maxice8> oh that is because they are in community and are for py3-twisted
2019-09-26 18:25:12 <maxice8> i have a PR for moving them to main
2019-09-26 18:25:51 <maxice8> 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 <maxice8> sure
2019-09-26 18:28:44 <maxice8> i can make an mr to move it to main/
2019-09-26 18:28:58 <maxice8> there is openvswitch
2019-09-26 18:29:24 <maxice8> 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 <maxice8> 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 <maxice8> 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 <maxice8> makedepends and in the depends of the _test() function
2019-09-26 18:31:22 <maxice8> 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 <maxice8> !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 <maxice8> _ikke_:  he approved
2019-09-26 19:14:45 <_ikke_> ok, good
2019-09-26 19:59:28 <maxice8> PureTryOut: can't find you on gitlab.a.o
2019-09-26 19:59:43 <maxice8> !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 <Cogitri> Yes, that weirded me out for a sec too
2019-09-26 20:05:29 <maxice8> oh
2019-09-26 20:29:50 <PureTryOut[m]> I was about to say, it's what you expect my nickname to be :p
2019-09-26 22:43:22 <maxice8> So yeah i dropped more py2 stuff on GitLab
2019-09-26 22:45:27 <maxice8> Need testers for !177
2019-09-26 23:05:27 <maxice8> _ikke_: tagged you on a few py2 drop MRs and on redo-c
2019-09-27 05:12:42 <Sodomon> Cogitri, are you there?
2019-09-27 05:41:43 <Cogitri> Sodomon: Yes
2019-09-27 05:43:08 <Sodomon> 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 <Cogitri> Ah yes, I meant a ping on GitHub though :)
2019-09-27 06:41:24 <maxice8> _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 <maxice8> ok
2019-09-27 07:38:42 <maxice8> 200th MR reached
2019-09-27 07:39:08 <_ikke_> \o/
2019-09-27 07:45:29 <mps> just looked, good
2019-09-27 09:53:55 <maxice8> !213 ddevault
2019-09-27 10:13:41 <maxice8> PureTryOut: merged latte-dock
2019-09-27 10:13:46 <PureTryOut[m]> Yeah I saw it thanks
2019-09-27 10:57:02 <_ikke_> restarting gitlab
2019-09-27 13:15:22 <maxice8> Got lots of MRs for main/ :D
2019-09-27 14:48:04 <ncopa> been out most of the day today
2019-09-27 18:15:48 <hjaekel> if the package version from upstream is "1.6.4.post2", what would you use as pkgver?
2019-09-27 18:20:07 <mps> not sure, but I would try that
2019-09-27 18:20:44 <_ikke_> THat's invalid
2019-09-27 18:21:51 <mps> mind to explain
2019-09-27 18:22:08 <_ikke_> apk does not allow .post2 in the version
2019-09-27 18:22:16 <hjaekel> yes, 1.6.4.post2 is invalid. That's why I am asking
2019-09-27 18:22:26 <mps> 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 <mps> it's queiet
2019-09-27 18:23:33 <_ikke_> for me it's not
2019-09-27 18:23:49 <mps> sorry, right
2019-09-27 18:23:57 <mps> wrong params
2019-09-27 18:24:56 <mps> so, version must have only numbers and dots
2019-09-27 18:25:12 <_ikke_> _rc<x> is allowed as well
2019-09-27 18:25:19 <_ikke_> or _git<x>
2019-09-27 18:25:20 <hjaekel> 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 <hjaekel> so do you have any suggestions what I should use as a version number?
2019-09-27 18:27:16 <mps> well, 'r' is reserved for pkgrel, afaik
2019-09-27 18:27:46 <_ikke_> s/.post/_p./?
2019-09-27 18:27:46 <alpine-meetbot> _ikke_ meant to say: apk version -c 1.6.4_p.2
2019-09-27 18:27:54 <hjaekel> 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 <MY-R> upstream could stop using weird version names :D
2019-09-27 18:29:39 <MY-R> 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 <MY-R> 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 <mps> 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 <mps> 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 <mps> last time I made upgrade it has 's/_r/_p/?'
2019-09-27 18:33:54 <mps> or something similar. there I learned about rewriting versions
2019-09-27 18:34:56 <mps> git log -p .... realver=${pkgver/_p/_r}
2019-09-27 18:35:22 <MY-R> mps, ye last time, only 6 days ago
2019-09-27 18:37:02 <mps> 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 <MY-R> yep
2019-09-27 18:38:49 <mps> 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 <mps> hmm, it time to go afk, a lot of typing errors
2019-09-27 18:44:18 <hjaekel> 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 <mps> +1
2019-09-27 19:05:01 <hjaekel> 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 <hjaekel> 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 <Cogitri> Ah, had hoped that was only a temporary failure
2019-09-27 19:46:07 <Cogitri> 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 <Cogitri> 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 <Cogitri> Yup, they cache their registry like that
2019-09-27 19:56:30 <Cogitri> https://github.com/rust-lang/rust/issues/63476 there we go
2019-09-27 19:56:55 <Cogitri> 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 <Cogitri> Upstream of the libgit2-sys crate not giving a damn about distros apparently if I may say so
2019-09-27 19:58:28 <Cogitri> 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 <Cogitri> Fair enough
2019-09-27 20:01:17 <Cogitri> Argh,  I really like the lang but the ecosystem is slowly stearing towards becoming JS all over again
2019-09-27 20:01:23 <Cogitri> npm²
2019-09-27 20:01:43 <_ikke_> lol
2019-09-27 20:03:30 <mps> 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 <Cogitri> If libprotobuf.20.0.1 symlinks to libprotobuf.20
2019-09-27 20:14:02 <Cogitri> Sure
2019-09-27 20:17:01 <_ikke_> usr/lib/libprotobuf.so.20 -> libprotobuf.so.20.0.2
2019-09-27 20:20:12 <Cogitri> 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 <Cogitri> Ah, it's not 0_git<date>? :/
2019-09-27 20:31:41 <_ikke_> nope :(
2019-09-27 20:35:15 <Cogitri> 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 <iggy> I was wondering if replaces takes a version
2019-09-27 20:36:32 <iggy> 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 <iggy> rename it to go-bin-data?
2019-09-27 20:42:53 <Cogitri> replaces doesn't take a version but provides does
2019-09-27 20:43:01 <Cogitri> Sadly we don't habe epochs yet
2019-09-27 20:43:05 <_ikke_> yup
2019-09-27 20:47:31 <Cogitri> Made a PR for Rust
2019-09-27 20:47:53 <_ikke_> ok
2019-09-27 20:47:53 <Cogitri> 
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 <Cogitri> 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 <Cogitri> 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 <Cogitri> Maybe it'll work if I allow warnings, let's see
2019-09-27 20:57:42 <Cogitri> 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 <Cogitri> Nice, seems like That works now
2019-09-28 07:58:59 <Cogitri> s/That/Rust/
2019-09-28 07:58:59 <alpine-meetbot> 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 <Cogitri> 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 <Cogitri> Not really
2019-09-28 08:13:46 <_ikke_> hmm, ok
2019-09-28 08:13:53 <Cogitri> 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 <Cogitri> Maybe LLVM9 will improve that
2019-09-28 08:48:49 <Cogitri> 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 <Cogitri> Ah, I'll disable it, thanks
2019-09-28 09:29:05 <PureTryOut[m]> <Cogitri "PureTryOut: Does kwallet-pam wor"> I'll check when I'm back home monday
2019-09-28 09:29:35 <Cogitri> Okay, thanks
2019-09-28 10:06:33 <Cogitri> 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 <Cogitri> 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 <package>
2019-09-28 10:41:05 <Cogitri> Ah, thanks
2019-09-28 16:11:11 <clandmeter> maxice8: can you take a look at #10887
2019-09-28 16:11:43 <clandmeter> err PR10887
2019-09-28 17:10:50 <maxice8> clandmeter: sorry, will be away until next week
2019-09-28 17:15:11 <maxice8> Currently at airport
2019-09-28 18:20:21 <clandmeter> Ok np
2019-09-29 07:10:17 <Cogitri> 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 <mps> do we have something like aports-ghpr for gitlab
2019-09-29 07:29:02 <Cogitri> You can use maxice8's mkmr I suppose
2019-09-29 07:29:56 <mps> isn't that for making MR, and not to check if MR exist for particular pkg
2019-09-29 07:30:34 <mps> I downloaded it and looked in source (superficially, TBH)
2019-09-29 07:32:58 <Cogitri> Ah, alright, wasn't quite sure what aports-ghpr does
2019-09-29 07:33:03 <Cogitri> No, it doesn't do that
2019-09-29 07:33:54 <mps> aports-ghpr check if PR exist for pkg in github
2019-09-29 07:35:05 <mps> 'lab mr list gitlab -n 100 | grep pkgname' could help somewhat but is far for good
2019-09-29 07:49:11 <Cogitri> Yes :/
2019-09-29 07:49:36 <Cogitri> 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 <Cogitri> Well that's unfortunate
2019-09-29 08:06:59 <Cogitri> Also, does `apk search --rdepends --origin --quiet so: libclang` actually work for all deps?
2019-09-29 08:07:10 <Cogitri> s/so: / so:/
2019-09-29 08:07:11 <alpine-meetbot> Cogitri meant to say: Also, does `apk search --rdepends --origin --quiet  so:libclang` actually work for all deps?
2019-09-29 08:07:31 <Cogitri> 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 <Cogitri> I guess because it's a bit project and we're building it in verbose mode
2019-09-29 11:42:13 <Cogitri> s/bit/big/ :P
2019-09-29 11:42:13 <alpine-meetbot> 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 <Cogitri> 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 <Cogitri> 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 <Cogitri> 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 <Cogitri> 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 <Cogitri> 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 <Cogitri> 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 <Cogitri> 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 <Cogitri> 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 <Dekedro> 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 <Dekedro> Ok, I obviously need to read more. Then what kind of toolchain does alpine use for cross compilation?
2019-09-29 15:16:59 <mps> alpine does not have it
2019-09-29 15:17:13 <mps> builds native
2019-09-29 15:18:58 <Cogitri> I usually use Void Linux's xbps-src does o crosscompile things
2019-09-29 15:19:49 <Cogitri> (At least I used that to generate the Rust tarballs)
2019-09-29 15:19:57 <mps> Cogitri: question was about alpine
2019-09-29 15:20:22 <Cogitri> Yes, but it's not really possible on Alpine so I recommend an alternative
2019-09-29 15:20:26 <mps> can you use xbps-src to cross build on alpine
2019-09-29 15:20:31 <mps> aha, ok
2019-09-29 15:20:53 <mps> I misunderstood your answer
2019-09-29 15:21:31 <mps> thought that you somehow managed to cross build on alpine using void tools
2019-09-29 15:22:29 <Dekedro> Does alpine use virtualization then? Or just hardware with different architectures?
2019-09-29 15:22:40 <Cogitri> 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 <Cogitri> The latter
2019-09-29 15:22:59 <Cogitri> We have native builders
2019-09-29 15:24:11 <Cogitri> 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 <mps> true, native build is safest, I'm started to avoid cross build in last time
2019-09-29 15:25:42 <Dekedro> Ok, got it, thanks _ikke_, mps, Cogitri
2019-09-29 15:26:40 <mps> Dekedro: np, we like to help when we can
2019-09-29 15:27:52 <Cogitri> 👍
2019-09-29 15:28:45 <Cogitri> Some ZFS users here? Would be nice if someone tested https://github.com/alpinelinux/aports/pull/11704
2019-09-29 21:26:11 <qa3Txu0iak0F> 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 <qa3Txu0iak0F> but then i don't use my crosscompilers to build apks with them.
2019-09-29 21:36:42 <mps> qa3Txu0iak0F: also I've built musl-cross-make for arm32 and arm64 but don't use for alpine
2019-09-30 09:54:51 <Cogitri> Thanks for taking a look, ncopa :)
2019-09-30 10:02:53 <ncopa> Cogitri: i built it and pushed it. will test it on my laptop afterwards
2019-09-30 10:03:27 <ncopa> im working from laptop for a few days, so if its broken i'll have a serious problem :)
2019-09-30 10:03:37 <ncopa> Cogitri: thanks for looking at llvm9
2019-09-30 10:03:43 <Cogitri> Sure thing
2019-09-30 10:04:19 <ncopa> i think there was a problem with llvm8 and chromium on armv7/armhf
2019-09-30 10:04:19 <Cogitri> 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 <ncopa> 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 <ncopa> did you test if it is fixed in llvm9?
2019-09-30 10:06:49 <ncopa> i noticed that this commit removed triples hunk for arm: 54db62760803072c5308e62d769048d2f50b68be
2019-09-30 10:07:00 <ncopa> was that intentional?
2019-09-30 10:07:23 <Cogitri> Oh my, I guess I messed up the rebasing
2019-09-30 10:08:16 <ncopa> i think i tried to put it back but i dont think it made any difference for chromium
2019-09-30 10:09:08 <ncopa> i will try do the llvm9 think this week
2019-09-30 10:09:21 <ncopa> we should get the 3.11 builders up soon too
2019-09-30 10:09:50 <ncopa> which means that we should have a compilers and toolchains freeze
2019-09-30 10:09:58 <ncopa> and abuild freeze
2019-09-30 10:10:10 <ncopa> reminds me, i need to tag release of abuild too
2019-09-30 10:16:17 <Cogitri> I think there are some pending PRs for abuild too :P
2019-09-30 10:18:55 <ncopa> yeah i know
2019-09-30 10:33:27 <mps> ncopa: user on #alpine-linux asked about https://github.com/alpinelinux/aports/pull/10936
2019-09-30 10:34:11 <mps> it is kernel change, I looked at it and I think it could and should be applied
2019-09-30 10:35:36 <mps> Cogitri: is the llvm9 pushed, or you just have MR/PR
2019-09-30 10:36:12 <mps> I would try to build and test in a next few days
2019-09-30 11:16:04 <Cogitri> I have a pr for it
2019-09-30 11:16:22 <Cogitri> pr11721
2019-09-30 11:31:25 <mps> Cogitri: thanks, will look and try to build on armv7 later this night (too busy now)
2019-09-30 11:36:43 <Cogitri> Okie :)
2019-09-30 11:55:50 <ncopa> mps: i already merged it
2019-09-30 11:56:24 <ncopa> the kernel config thing
2019-09-30 12:06:07 <mps> ah, ok, something about pinctrl iirc, nice
2019-09-30 15:54:37 <wsinatra> 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 <mps> 'apk-file libfixposix.so'
2019-09-30 16:00:41 <wsinatra> Wait, it's provided by the -dev not the main? I obviously missed something obvious then
2019-09-30 16:01:45 <wsinatra> +1 mps, I wasn't aware of apk-file. That's going to come in handy
2019-09-30 16:01:53 <wsinatra> Thanks gents, obviously a non-issue then
2019-09-30 16:03:12 <mps> I found apk-file more useful than go to web page
2019-09-30 16:10:53 <wsinatra> 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 <mps> Cogitri: llvm9 in your PR builds on aarch64 and armv7 without problem
2019-09-30 20:44:54 <Cogitri> Nice
2019-09-30 20:44:58 <Cogitri> Also, does someone happen to have FF 69 up and running already M
2019-09-30 20:49:09 <mps> what is needed to build it, rust and llvm versions I mean
2019-09-30 20:50:35 <Cogitri> What's in the repos should work already
2019-09-30 20:50:56 <Cogitri> And Void already has it in their repos, so they patches for musl should be up too
2019-09-30 20:51:22 <mps> I can try to build it on aarch64
2019-09-30 20:51:59 <mps> doubt it is possible on armv7 because of 4GB problem
2019-09-30 20:52:03 <Cogitri> 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 <mps> are these patches already in aports
2019-09-30 20:53:06 <Cogitri> Nop, you'll have to pull them from Void Linux
2019-09-30 20:54:11 <mps> aha, then maybe tomorrow, I'm tired, all day worked to solve some service problem
2019-09-30 20:54:41 <Cogitri> Same here, but tired from uni :)
2019-09-30 20:54:50 <colona> I have FF 69 working on arm64 here, built when we had rust-1.37 I think
2019-09-30 20:55:10 <colona> 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 <mps> colona: on alpine
2019-09-30 20:55:17 <colona> yeah
2019-09-30 20:55:45 <mps> nice
2019-09-30 20:55:55 <Cogitri> Do feel free to submit a PR then
2019-09-30 20:56:07 <Cogitri> I can take a look tomorrow and test on x86_64
2019-09-30 20:57:10 <colona> alright, I'll also check if Void have the same changes I had to make
2019-09-30 20:59:24 <mps> colona: please post your PR number/id here when you post it to github
2019-09-30 21:00:37 <colona> sure