2020-05-01 02:48:52 <maxice8> huh, gitlab-ci on alpine/aports is completely useless to check if a package will be built correctly
2020-05-01 05:02:47 <ikke> maxice8: ?
2020-05-01 05:03:39 <maxice8> Tried to fix aconf, CI passed but build failed
2020-05-01 05:05:01 <ikke> yeah, but this is in general something flaky
2020-05-01 05:05:17 <ikke> even ncopa / kunkky had issues finding what is going on
2020-05-01 05:05:40 <ikke> kunkku*
2020-05-01 05:23:01 <ikke> same with slang, succeeded everywhere except on the builders, no clue why
2020-05-01 05:23:05 <ikke> (test failure)
2020-05-01 05:23:21 <ikke> So yeah, CI is not perfect, but does not mean it's useless
2020-05-01 05:23:50 <maxice8> yeah i expressed myself poorly
2020-05-01 05:23:51 <maxice8> let me rephrase
2020-05-01 05:24:25 <maxice8> It is very annoying that on 3-12 i can't get a one-to-one mapping between the CI and what will happen on 3-12
2020-05-01 05:24:43 <ikke> yes, agreed, but that's not possible in general
2020-05-01 05:24:58 <ikke> 3-12 is bootstrapping, while edge is fully bootstrapped
2020-05-01 05:25:01 <ikke> fully built
2020-05-01 05:25:03 <ikke> I mean
2020-05-01 05:25:51 <ikke> so packages that build fine on edge, have issues on 3.12 for example due to cyclic dependencies
2020-05-01 05:45:34 <ncopa> morning
2020-05-01 05:46:04 <ncopa> they are also different environments, one is lxc and the other docker. it should not make any difference in theory, but it may
2020-05-01 06:05:56 <ncopa> maxice8: i have not been able to reproduce the aconf issue. apparently it happens on random, so I suspect there is a race
2020-05-01 06:08:00 <maxice8> Größe oof
2020-05-01 06:12:01 <ikke> but on the builder it seems to happen consistently
2020-05-01 06:12:28 <maxice8> !7406 can you take a look at ?
2020-05-01 06:13:17 <maxice8> nvm :D
2020-05-01 06:37:53 <kunkku> seems aconf build fails consistently on 3.12 builder but never on edge
2020-05-01 06:38:44 <kunkku> https://build.alpinelinux.org/buildlogs/build-3-12-armhf/main/dmvpn/dmvpn-1.3.0-r1.log
2020-05-01 06:39:25 <kunkku> weird errors on other pkgs too
2020-05-01 06:48:21 <kunkku> ncopa: have you seen the aconf issue elsewhere than 3.12 builders?
2020-05-01 07:35:52 <Cogitri> Are revert commits fine like in !7408 ?
2020-05-01 07:39:09 <maxice8> @PureTryOut: ping, can you PM me ?
2020-05-01 07:45:34 <ikke> Cogitri: should be fine, I would just move the revert part after the repo designation
2020-05-01 07:45:49 <ikke> community/telepathy-logger: revert ...
2020-05-01 07:46:03 <ikke> and perhaps add details about why it was reverted
2020-05-01 07:53:59 <Cogitri> That's in the commit description
2020-05-01 07:55:27 <ikke> ah, I looked over the last line :)
2020-05-01 07:58:47 <maxwell-k> could I ask someone to please take a look at !7219?
2020-05-01 07:59:04 <maxwell-k> it fixes a mess of python and library dependencies, but for some reason the GitLab UI doesn't like rebasing it and I've done that a few times now after Cogitri prompted me to
2020-05-01 07:59:38 <ikke> maxwell-k: could you at least rebase it? THere appear to be conflicts with master
2020-05-01 08:02:46 <maxwell-k> I just did rebase it, just a few minutes ago, let me take another look
2020-05-01 08:04:49 <maxwell-k> @ikke: what conflicts do you see? I can't see any; if I could see them I'd happily address them
2020-05-01 08:13:24 <ikke> maxwell-k: I don't see the specific conflicts, just gitlab saying it cannot rebase
2020-05-01 08:13:39 <ikke> "Merge failed: Rebase failed. Please rebase locally. Please try again. "
2020-05-01 08:13:44 <ikke> usually indicates merge conflcits
2020-05-01 08:14:00 <ikke> just rebase it, then you'll notice
2020-05-01 08:19:44 <maxwell-k> @ikke: I think we have our wires crossed, I have rebased five times now over the last 5 days and never seen a conflict
2020-05-01 08:20:14 <maxwell-k> I'm asking for help because that's pretty tedious, and I don't understand why its required
2020-05-01 08:20:49 <ikke> https://imgur.com/a/YaNHiSw
2020-05-01 08:21:07 <maxwell-k> I have seen the message you can see in the GitLab UI
2020-05-01 08:21:39 <maxwell-k> but I do not understand what is causing it
2020-05-01 08:24:37 <maxwell-k> I'm really open to suggestions on how to move forward, should I close the MR and open another one?
2020-05-01 08:25:30 <ikke> no
2020-05-01 08:25:32 <ikke> hold on
2020-05-01 08:26:20 <ikke> OK, the branch seems to be already up-to-date, so can just be merged
2020-05-01 08:48:11 <maxwell-k> thanks @ikke, that's what I thought, I still don't get what has confused the UI, but hopefully it'll be reviewed/merged
2020-05-01 10:29:57 <PureTryOut[m]> What is this about? `ERROR: py3-humanhash3-0.0.6-r0: failed to rename usr/lib/python3.8/site-packages/.apk.139e13a93e434202f39e2a2634d2355ec1b6aafa84fb77b5 to usr/lib/python3.8/site-packages/humanhash3-0.0.6-py3.8.egg-info.`. I just packaged it, and it's a standard setup.py thing
2020-05-01 10:30:48 <ikke> I'm not sure, but there are some strange things going on with egg-info files lately
2020-05-01 10:30:56 <ikke> files being read-only for example
2020-05-01 10:31:05 <ikke> I mean, non-readable for non-root
2020-05-01 10:31:29 <ikke> PureTryOut[m]: can you check permissions?
2020-05-01 10:32:31 <Cogitri> I think that error happens when you try to overwrite a file with a dir or the other way around
2020-05-01 10:32:48 <ikke> ah, that would make sense as well
2020-05-01 10:32:51 <ikke> d/f conflcit
2020-05-01 10:35:01 <PureTryOut[m]> Still, how could that happen? I just installed, uninstalled, and installed it again and now it happens
2020-05-01 10:36:07 <ikke> did you check the permissions?
2020-05-01 10:40:56 <PureTryOut[m]> I did but Cogitri was right. I removed the package, force removed the file/directory that was left-over, and now it installs fine again
2020-05-01 10:40:58 <PureTryOut[m]> 🦐
2020-05-01 10:41:01 <PureTryOut[m]> 🤷‍♂️
2020-05-01 10:54:43 <Cogitri> apk should really have some measure for that or at least a better error message
2020-05-01 11:48:34 <clandmeter> we have a problem with lua5.3
2020-05-01 12:12:42 <PureTryOut[m]> Yeah it just made my CI linter check fail while I didn't even touch it
2020-05-01 12:25:51 <clandmeter> http://tpaste.us/Jx1g these packages need a bump to fix lua modules with wrong path
2020-05-01 12:26:32 <clandmeter>  lua-ldap seems to use its own version as lib versioned dir
2020-05-01 12:27:14 <clandmeter> kunkku: i need to run soon, can you or maybe maxice8 bump those pkgs?
2020-05-01 12:27:48 <clandmeter> maybe check if im right about ldap pkg
2020-05-01 12:30:27 <kunkku> might be due to the same issue
2020-05-01 12:31:33 <kunkku> the other packages behave differently too: some of them end up directly to /usr/lib/lua while others to /usr/lib/lua/$V
2020-05-01 12:32:35 <kunkku> so I would bump lua-ldap too and see if the module path gets corrected
2020-05-01 12:36:17 <clandmeter> do others use pkg-config?
2020-05-01 12:37:05 <clandmeter> maybe others just use /usr/lib/lua$_lver
2020-05-01 12:37:22 <Cogitri> apk-tools' luaapk uses it, but I think it hasn't been rebuilt in the meantime (it's where I noticed the breakage)
2020-05-01 13:28:05 <prez> should adding a service file and moving a package from testing be done separately?
2020-05-01 13:28:57 <Cogitri> Would be best to do that in two commits, yes
2020-05-01 13:29:12 <prez> but one PR is alright?
2020-05-01 13:29:31 <ikke> yes
2020-05-01 13:29:33 <prez> thanks
2020-05-01 14:36:09 <prez> any reason alpine doesnt use _ for package users? it seems a lot cleaner
2020-05-01 14:38:54 <ikke> ?
2020-05-01 14:39:15 <ikke> prefix users created from packages with _?
2020-05-01 14:39:18 <prez> yeah
2020-05-01 14:41:13 <ikke> would seem very cluttery to me
2020-05-01 14:42:21 <prez> au contraire, the status quo seems very cluttery to me
2020-05-01 14:42:24 <prez> but whatever
2020-05-01 14:42:35 <artok> creating users from packages is not great thing anyway
2020-05-01 14:42:56 <mps> I agree with ikke
2020-05-01 14:43:19 <artok> having _ is like permission to pollute passwd
2020-05-01 14:43:38 <mps> yes
2020-05-01 14:43:52 <prez> grep -r pkgusers= | wc -l : 77
2020-05-01 14:44:31 <mps> so?
2020-05-01 14:44:46 <prez> artok said it was not a great thing
2020-05-01 14:44:49 <prez> I dont see how
2020-05-01 14:45:22 <mps> I don't see any problem with this how it is now
2020-05-01 14:47:48 <artok> they're created uid 100->, right?
2020-05-01 14:48:29 <mps> usually
2020-05-01 14:49:15 <Cogitri> Void Linux tried to make the switch from no prefix to _
2020-05-01 14:49:17 <Cogitri> It wasn't pretty and has been reverted since
2020-05-01 14:49:54 <Cogitri> I mean if you do it from the beginning it might be fun, but it's asking for trouble if you change things now
2020-05-01 14:50:59 <mps> besides that, it looks ugly to me
2020-05-01 14:51:27 <artok> tha'
2020-05-01 14:52:07 <prez> interesting, wasnt aware they reverted
2020-05-01 14:52:25 <prez> thanks for elaborating
2020-05-01 14:52:49 <mps> I'm pleased that someone 'removed' _ in his nick :)
2020-05-01 14:53:02 <Cogitri> It kind of is, but sometimes it's nice being able to differentiate between system created users and user created users
2020-05-01 14:53:36 <Cogitri> prez: At least the one they changed it for (I think polkit) was reverted when I was on void because it broke people's setup
2020-05-01 14:53:47 <mps> system users have id < 1000
2020-05-01 14:58:16 <Cogitri> I should've said distro created users :)
2020-05-01 14:58:40 <mps> ah
2020-05-01 14:58:44 <Cogitri> I mean you can create a system user yourself with adduser -S, but you don't know if it's from your distro or yourself
2020-05-01 14:59:14 <mps> ah, you mean for people with bad memory :P
2020-05-01 15:02:26 <prez> I see there are 3 conventions for configuration files - /etc/conf.d, /etc and /etc/pkgname; which one should I use?
2020-05-01 15:03:44 <ikke> /etc/conf.d is mostly configuration for the service (ie, used in /etc/init.d)
2020-05-01 15:03:54 <mps> prez: /etc/conf.d is for init scripts
2020-05-01 15:04:01 <mps> heh
2020-05-01 15:04:15 <prez> Im planning to add a service
2020-05-01 15:04:18 <prez> the package in question is hitch
2020-05-01 15:04:34 <mps> and /etc/pkgname for 'normal' config of package
2020-05-01 15:04:36 <prez> stunnel, which is similar, uses /etc/stunnel
2020-05-01 15:05:12 <prez> got it. thanks
2020-05-01 17:52:00 <ikke> Hmm, we need to bootstrap rust
2020-05-01 17:54:54 <ikke> ncopa: apparently some ubilders already started working on community
2020-05-01 17:56:47 <ncopa> wow
2020-05-01 17:56:47 <ncopa> nice
2020-05-01 17:57:12 <ncopa> but, hum
2020-05-01 17:57:26 <ncopa> i wanted to leave computer
2020-05-01 17:57:39 <ikke> I can arrange bootstrapping
2020-05-01 17:57:45 <ncopa> great
2020-05-01 17:57:47 <ncopa> thanks!
2020-05-01 17:57:59 <ikke> enjoy your weekend
2020-05-01 17:59:18 <ncopa> you too!
2020-05-01 17:59:24 <ikke> thanks!
2020-05-01 17:59:52 <ikke> is go already installed on some builders? It seems to just continue with go
2020-05-01 18:00:22 <mps> what is (or better, was) 'weekend' :)
2020-05-01 18:08:17 <artok> weekend is normally "working days" but since government has forbidden me to work, I'll just drink alcohol
2020-05-01 18:10:03 <Cogitri> Hum, did someone else's XWayland break with the latest upgrade?
2020-05-01 18:12:00 <mps> artok: hehe :)
2020-05-01 19:21:01 <kunkku> re: system users
2020-05-01 19:21:19 <kunkku> I know an Indian guy whose name is Man
2020-05-01 19:21:39 <kunkku> also Postmaster would be a feasible surname/username
2020-05-01 19:58:17 <artok> oh those 80's prank calls to people with funny names
2020-05-01 20:22:21 <ikke> Apparently quite some tests segfault in fail2ban
2020-05-01 20:23:04 <ikke> sounds like it would be better to disable it on s390x for now
2020-05-01 20:49:06 <clandmeter> ikke: if you want you can upgrade gitlab :)
2020-05-01 20:49:26 <clandmeter> .10 seems to not build correctly
2020-05-01 20:50:35 <ikke> 12.10?
2020-05-01 20:51:14 <ikke> did you saw the test failures from gittea btw?
2020-05-01 20:51:50 <clandmeter> gittea?
2020-05-01 20:52:03 <ikke> gitea
2020-05-01 20:52:03 <clandmeter> yes 12.10.x
2020-05-01 20:52:13 <clandmeter> i did not
2020-05-01 20:52:15 <ikke> apparently only on armv7
2020-05-01 20:52:26 <clandmeter> am i still the maintainer?
2020-05-01 20:52:29 <ikke> yes
2020-05-01 21:18:54 <clandmeter> ikke: where can i see the gitea test failure?
2020-05-02 06:00:17 <ikke> clandmeter: hmm, apparently it succeeded now
2020-05-02 06:03:18 <ikke> restarting gitlab to upgrade to latest patch release
2020-05-02 06:24:22 <TheSlackOne> Hello, I've flagged a package a couple of days ago and no news about it. Does anybody know what is the overall time it to get updated?
2020-05-02 06:24:37 <maxice8> What package would that be ?
2020-05-02 06:24:42 <ikke> TheSlackOne: most focus now is on getting 3.12 out
2020-05-02 06:24:44 <TheSlackOne> gvmd
2020-05-02 06:25:07 <TheSlackOne> ikke: oh, ok, makes sense.
2020-05-02 07:16:17 <ikke> filezilla fails due to assert not being declared
2020-05-02 07:16:33 <maxice8> i guess it is because of the opt level ?
2020-05-02 07:16:48 <ikke> opt level?
2020-05-02 07:17:02 <maxice8> -Os
2020-05-02 07:17:32 <ikke> but shouldn't it be a noop in that case?
2020-05-02 07:17:59 <ikke> brb
2020-05-02 07:29:33 <Cogitri> I think assert is not on the optlevel
2020-05-02 07:30:09 <Cogitri> I think it's only on if you have DEBUG defined
2020-05-02 07:30:24 <Cogitri> Even so, it should probably have assert.h included
2020-05-02 07:31:16 <mps> Cogitri: right, usually. but without looking source never can be sure
2020-05-02 07:32:38 <ikke> assert.h is provided by musl-dev
2020-05-02 07:32:54 <ikke> this is in the log as well: "note: 'assert' is defined in header '<cassert>'; did you forget to '#include <cassert>'?"
2020-05-02 07:43:24 <mps> cassert.h must be C++
2020-05-02 07:44:06 <mps> for C it is usually assert.h, afaik
2020-05-02 07:44:48 <ikke> yeah
2020-05-02 07:45:06 <ikke> but I wondor why this would be broken in such an obvious manner
2020-05-02 07:45:45 <mps> filezilla?
2020-05-02 07:45:52 <ikke> yes
2020-05-02 07:47:36 <mps> lets try in lxc
2020-05-02 07:47:58 <mps> huh, 224 pkgs in makedeps
2020-05-02 07:48:24 <ikke> gtk
2020-05-02 07:48:28 <ikke> pulls in a lot I guess
2020-05-02 07:49:57 <mps> lets see will boost-dev will help
2020-05-02 07:51:43 <mps> no, it uses only assert.h
2020-05-02 07:52:19 <ikke> does it need musl-dev then?
2020-05-02 07:55:34 <mps> musl-dev is always installed, isn't it
2020-05-02 07:57:04 <ikke> Through what?
2020-05-02 07:57:08 <mps> I think '#include <asseert.h>' is missing in some files
2020-05-02 07:57:19 <ikke> ah, libc-dev
2020-05-02 07:57:23 <mps> alpine-sdk
2020-05-02 07:57:40 <ikke> yeah, gcc depends on libc-dev
2020-05-02 07:57:40 <mps> yes, libc-dev
2020-05-02 07:57:49 <ikke> ok
2020-05-02 08:01:11 <mps> is there a cli switch for g++ to explicitly include header file
2020-05-02 08:01:45 <mps> to not go through some number of them and do it manually and create big patch
2020-05-02 08:12:54 <mps> probably adding '#include <asseert.h>' in files where it needs is fix
2020-05-02 08:26:42 <mps> find -name "*.cpp" | xargs sed -i 's/\#include <filezilla.h>/\#include <filezilla.h>\n#include <assert.h>/'
2020-05-02 08:27:30 <mps> looks like that works though it is ugly
2020-05-02 08:28:12 <mps> http://tpaste.us/V46v
2020-05-02 08:31:52 <mps> it works. 'ls -l packages/community/x86_64/' => -rw-r--r--    1 mps      mps        2816316 May  2 10:30 filezilla-3.47.1-r0.apk
2020-05-02 08:40:03 <ikke> next one: gpgme
2020-05-02 08:40:08 <ikke> test failures
2020-05-02 08:43:05 <mps> 'Please report to https://bugs.gnupg.org'
2020-05-02 08:43:39 <mps> I wouldn't 'play' with such critical pkg as gpgme is
2020-05-02 08:43:55 <ikke> heh
2020-05-02 08:44:21 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11473
2020-05-02 08:44:33 <mps> fear to introduce subtle bug which will be sec fiasco for alpine
2020-05-02 08:48:02 <ikke> there was an upstream commit mentioned there, but that one didn't fix it
2020-05-02 08:48:35 <mps> still, I wouldn't play with it
2020-05-02 08:48:51 <ikke> well, *someone* has to
2020-05-02 08:49:00 <ikke> or disable it
2020-05-02 08:50:01 <mps> I think *someone* (maintainer) should contact upstream and ask
2020-05-02 08:51:42 <ikke> now it's blocking the 3-12 builders
2020-05-02 08:52:27 <mps> I see
2020-05-02 08:57:13 <ikke> quite a few things depend on gpgme, so I guess it's not trivial to disable it
2020-05-02 09:33:08 <nmeum> the gpgme failure is caused by https://dev.gnupg.org/T4820
2020-05-02 09:33:26 <nmeum> we could just disable the t-json test
2020-05-02 09:33:38 <nmeum> though that seems to require patching the makefiles
2020-05-02 09:37:24 <PureTryOut[m]> Cogitri: we will need https://github.com/void-linux/void-packages/pull/21531/files
2020-05-02 09:41:19 <nmeum> I think we should just disable the gpgme test suite
2020-05-02 09:56:32 <ikke> nmeum: can't we just disable this test, or is that too complicated?
2020-05-02 09:57:18 <Cogitri> PureTryOut[m]: Huh, I didn't have a crash yet :o
2020-05-02 09:57:48 <Cogitri> Anyway, debugging GNOME Shell dying with telepathy-logger installed, so it'll take me a bit to apply that patch
2020-05-02 10:10:00 <ikke> nmeum: I think it's just a one line change in Makefile.am
2020-05-02 10:10:23 <nmeum> though that will require regenerating the makefiles then
2020-05-02 10:10:30 <nmeum> I will try that
2020-05-02 10:11:07 <ikke> Testing it now
2020-05-02 10:12:00 <ikke> nmeum: this seems to work:
2020-05-02 10:12:02 <ikke> http://tpaste.us/mEkg
2020-05-02 10:12:21 <nmeum> but this will disable all json tests
2020-05-02 10:12:24 <ikke> right
2020-05-02 10:12:29 <nmeum> not just t-json
2020-05-02 10:12:32 <ikke> ok
2020-05-02 10:12:38 <nmeum> I am currently trying to only disable t-json
2020-05-02 10:12:41 <nmeum> building it now
2020-05-02 10:12:44 <nmeum> let's see how that goes
2020-05-02 10:13:02 <ikke> ok
2020-05-02 10:13:04 <ikke> thanks
2020-05-02 10:13:53 <nmeum> https://tpaste.us/9NV7
2020-05-02 10:13:55 <nmeum> this seems to work
2020-05-02 10:14:21 <ikke> ok
2020-05-02 10:19:41 <nmeum> fails during package now though :/
2020-05-02 10:20:34 <nmeum> > gpgme-dev*: usr/lib/pkgconfig/gpgme-glib.pc: pkgconf version 1.13.1-unknown is invalid
2020-05-02 10:21:21 <ikke> hmm, ok
2020-05-02 10:21:44 <ikke> due to the added validation on pkgconf versions
2020-05-02 10:24:14 <nmeum> not sure why it appends the -unknown postfix though
2020-05-02 10:24:31 <nmeum> probably a side effect of generating the makefiles instead of using the supplied ones?
2020-05-02 10:25:33 <ikke> You could try to patch Makefile.in instead of Makefile.am
2020-05-02 10:25:45 <ikke> if that's the issue
2020-05-02 10:28:24 <nmeum> gnu autotools is such a mess
2020-05-02 10:30:44 <nmeum> yeah, that seems to work
2020-05-02 10:32:27 <nmeum> https://tpaste.us/naOr that's what it looks like a bit ugly but seems to work
2020-05-02 10:32:30 <nmeum> should I push it?
2020-05-02 10:33:24 <ikke> Fine with me. The bug is confirmed upstream, so I feel comfortable disabling it for now
2020-05-02 10:34:13 <nmeum> I feel semi comfortable patching a generated makefile but it's only a test makefile and probably better then disabling the entire test suite…
2020-05-02 10:34:25 <ikke> yes, indeed
2020-05-02 10:34:41 <ikke> the impact is fairly limited
2020-05-02 10:35:11 <ikke> and even a makefile for a subset of tests
2020-05-02 10:35:25 <nmeum> ok, pushed
2020-05-02 10:35:29 <ikke> (y)
2020-05-02 10:37:26 <PureTryOut[m]> Cogitri: it crashes for me if I access a local file. It seems to be comparable to the crash with the password field, doesn't happen for everyone
2020-05-02 10:43:56 <Cogitri> Ah, huh
2020-05-02 10:44:19 <Cogitri> Can you make a MR for it?
2020-05-02 10:54:37 <ikke> Just to confirm I'm not mentioning non-sense: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11474#note_85234 " am guessing that LXC containers slow down execution while the clocksource continues normally (kvm-clock isn't being used)," doesn't make sense, right?
2020-05-02 11:30:56 <mps> ikke: looks right. first time hear for that
2020-05-02 11:32:15 <PureTryOut[m]> Cogitri: yeah sure bit later
2020-05-02 11:37:03 <mps> we have some number of outdated packages in aports, some time ago Ariadne proposed to discuss remove them. maybe we can look now, before 3.12 release
2020-05-02 15:48:19 <justin_> o/
2020-05-02 15:49:37 <Bridouz> o/
2020-05-02 15:49:46 <Bridouz> Do you accept printer drivers here ?
2020-05-02 15:49:52 <Bridouz> I mean in aports
2020-05-02 15:50:14 <Bridouz> Musl does not seem to manage ipp with cups and so I had to package my epson printer driver
2020-05-02 16:15:05 <Cogitri> If it's OSS, sure
2020-05-02 16:17:39 <mps> libc (musl) manage ipp?
2020-05-02 16:48:26 <PureTryOut[m]> So for a GPS app that depends on `gpsd` to work (for example), it would need `/etc/init.d/gpsd` to enabled. Would this be a case where it's allowed to enable the service after package installation in a `.post-install` script?
2020-05-02 16:48:45 <PureTryOut[m]> (like we modprobe kernel modules for some packages)
2020-05-02 16:48:52 <mps> no
2020-05-02 16:49:57 <mps> do we want to be debian/ubuntu/fedora ?
2020-05-02 16:50:31 <tehcloud> (fuck no)
2020-05-02 16:51:28 <PureTryOut[m]> What kind of an argument is that? I'm just wondering if we should do that when the application to be installed needs the service to be enabled
2020-05-02 16:52:09 <PureTryOut[m]> The application in question is an end-user one, not just any library that gets installed by other stuff
2020-05-02 16:52:55 <tehcloud> perhaps a post-installation message is all that is necessary for the situation in question
2020-05-02 16:53:09 <ikke> PureTryOut[m]: policy is to not enable/start services on install
2020-05-02 16:53:37 <PureTryOut[m]> I know but I wonder if there can be exceptions. I guess not
2020-05-02 16:53:55 <PureTryOut[m]> But just to be clear, "we are not <insert some other distro>" is not a good reason for anything imo
2020-05-02 16:55:00 <ikke> You could provide some setup script that makes everything in order
2020-05-02 16:55:05 <ikke> but it's the user that needs to initiate that
2020-05-02 16:55:12 <mps> yes
2020-05-02 16:55:20 <PureTryOut[m]> Ok
2020-05-02 16:55:24 <mps> like setup-xorg
2020-05-02 16:55:24 <PureTryOut[m]> Thanks
2020-05-02 16:55:56 <mps> setup-xorg-base*
2020-05-02 16:56:28 <mps> PureTryOut[m]: don't take my opinion as personal attack
2020-05-02 16:56:42 <PureTryOut[m]> Don't worry, I don't 😉
2020-05-02 16:57:33 <mps> it is my strong opionion that user/admin should enable services/daemons or other things, and we don't have to force anything except base things
2020-05-02 17:14:54 <Cogitri> PureTryOut[m]: gpsd doesn't provide a dbus service that is autostarted?
2020-05-02 17:36:43 <Bridouz> mps: regarding ipp, It's working now. Don't know why it failed before.
2020-05-02 17:38:04 <mps> Bridouz: cups with ipp printers works for long time on alpine on my boxes
2020-05-02 17:38:34 <Bridouz> Ok, that's stranged. With my epson drivers packed and installed ipp everywhere is working.
2020-05-02 17:39:04 <Bridouz> without it, it detects my printer but does not seem to manage it like it should. (no printer configuration etc...)
2020-05-02 17:39:31 <Bridouz> Don't remember if it used to be like that on previous Alpine installs. (Guess it was, Void too)
2020-05-02 17:40:27 <mps> I don't have much experience with cups and last time I looked at it was about two years, when switched to alpine
2020-05-02 17:40:41 <mps> and it was simple copy configs from debian
2020-05-02 17:41:45 <Bridouz> Yes, IPP works ootb, configuring rightfully ootb is not supported for my printer I guess.
2020-05-02 18:41:46 <maxice8> Hey, gitlab is kinda weird with super old MR
2020-05-02 18:42:04 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/1051/diffs
2020-05-02 18:42:08 <maxice8> it looks like they are binary files ?
2020-05-02 18:43:18 <ikke> not sure if it has to do with the age, but I've noticed it more often
2020-05-02 18:43:27 <ikke> not sure what is causing it
2020-05-02 18:43:50 <ikke> you can fetch the branch just fine
2020-05-02 18:44:03 <ikke> maybe some heuristic that's messing up
2020-05-02 19:26:44 <dne> 08:01:11 <mps> is there a cli switch for g++ to explicitly include header file
2020-05-02 19:26:53 <dne> mps: there's "-include file"
2020-05-02 19:27:02 <dne> https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#Preprocessor-Options
2020-05-02 19:31:18 <mps> dne: thanks. I thought there must be option but couldn't find, tried -iassert.h from the head which didn't worked
2020-05-02 19:31:50 <mps> long time didn't used C seriously
2020-05-02 19:32:33 <mps> and forgot some things, probably not some but much too
2020-05-02 19:41:09 <ikke> I wonder what we should do with livemedia. They only provide the latest version, so each time it's rebuilt, we need to update it
2020-05-02 19:48:40 <Cogitri> Well, best case they stop doing that
2020-05-02 19:49:04 <Cogitri> Otherwise I'd say we mirror it, although that's some effort too
2020-05-02 19:49:11 <ikke> if you read it, they're addement about it
2020-05-02 19:49:59 <ikke> http://live555.com/liveMedia/faq.html#old-versions
2020-05-02 19:50:05 <ikke> "No"
2020-05-02 19:52:49 <maxice8> mirroring it is
2020-05-02 19:53:57 <Cogitri> Yup
2020-05-02 19:54:13 <Cogitri> The latest version contains bugfixes, why wouldn't you use that lol
2020-05-02 19:54:27 <ikke> because they also contain new bugs :D
2020-05-02 20:08:14 <mps> anyone (except ncopa) know how the kernel for rpi armhf is built, in armhf lxc ?
2020-05-02 20:09:20 <ikke> I would suppose so
2020-05-02 20:09:50 <ikke> linux-rpi is built for arch armhf, so that builder is building it
2020-05-02 20:09:57 <mps> huh, so have to setup armhf lxc
2020-05-02 20:11:04 <Cogitri> <ikke "because they also contain new bu"> Yup, I just had to think of the "How to make package maintainers cry" talk where the speaker mentioned that reasoning from upstreams :D
2020-05-02 20:11:07 <mps> managed to build rpi zero w u-boot but can't boot kernel, missing loglevel=7
2020-05-02 20:11:18 <ikke> Cogitri: yes, indeed, me too
2020-05-02 20:12:06 <mps> Cogitri: hehe, I posted link few times here
2020-05-02 20:12:48 <Cogitri> One of my favourite talks ^^
2020-05-02 20:13:39 <Ganwell> I am working on program that boots qemu-system-* archs. It boots aarch64, armv7 atm. I build it from a minirootfs, how do I get some default runlevels? A login for example?
2020-05-02 20:15:01 <mps> Ganwell: I have scripts to boot armv7 and aarch64 on x86_64
2020-05-02 20:16:39 <Ganwell> mps: Its a fully automated thing. At least it builds all archs, booting is another story.
2020-05-02 20:17:25 <mps> ok
2020-05-02 20:17:36 <ikke> Cogitri: any idea what we should do with the unicode emoji conflict (ibus)?
2020-05-02 20:22:47 <Ganwell> mps https://gitlab.alpinelinux.org/jeanlf/alpine-now/-/blob/master/alpine_now/init.py
2020-05-02 20:24:13 <Cogitri> ikke: Hm, not sure right now, I don't really know that unicode stuff. But I guess it'd be best to move one of them to another dir
2020-05-02 20:53:33 <Ganwell> $> rc-update add hwclock boot
2020-05-02 20:53:34 <Ganwell>  * rc-update: failed to add service `hwclock' to runlevel `boot': No such file or directory
2020-05-02 20:53:34 <Ganwell> I can add to other runlevels. I can even create runlevels. I can't add anything to boot.
2020-05-02 20:54:10 <ikke> strange, for some reason a lot of packages suddenly require pbr in my container, but apparently not on the builders
2020-05-02 20:54:13 <ikke> python packages
2020-05-02 21:02:01 <mps> Ganwell: miniroots are intended to run in containers, docker mostly
2020-05-02 21:02:41 <mps> they don't have all needed tools and they are not tailored to 'boot' as normal boxes
2020-05-02 21:02:45 <Ganwell> mps: I just use it to bootstrap
2020-05-02 21:02:56 <Ganwell> mps: I install the tools
2020-05-02 21:03:12 <mps> you have to add all needed things and set configs in etc
2020-05-02 21:03:32 <mps> I did that once or two/three times
2020-05-02 21:04:18 <mps> you have to create runlevels dirs
2020-05-02 21:04:41 <Ganwell> mps: The directories are there
2020-05-02 21:05:15 <Ganwell> mps I create symlinks now directly instead of using rc-update.
2020-05-02 21:05:57 <mps> sorry, I forgot details, I did this about two years ago for armhf and aarch64 and I remember that I had some manual work
2020-05-02 21:06:04 <Ganwell> mps: It now starts the services. Only the ram fs is mssing, the root is read-only
2020-05-02 21:07:08 <mps> yes, this is trial and error job
2020-05-02 21:07:10 <Ganwell> mps: I am really happy how nicely this works. I hope I get the boot-params for more arch correclty. Currently I am working on mips64.
2020-05-02 21:07:32 <Cogitri> https://github.com/OpenRC/openrc/issues/243
2020-05-02 21:07:41 <Cogitri> I think you can't add to the boot level in chroots due to that
2020-05-02 21:07:47 <Cogitri> Should work on the actual system tho
2020-05-02 21:08:12 <Ganwell> mps try and error... with a bit of cheating here and there
2020-05-02 21:09:09 <Ganwell> Cogitri: Great thanks, so I did the right thing... create the symlinks directly
2020-05-02 21:24:45 <Cogitri> Yup, that should work too, I suppose
2020-05-02 21:25:14 <Cogitri> I mean fixing it would be the best thing realistically speaking, but C is ew so no thanks :P
2020-05-02 21:55:48 <Ganwell> thanks mps and cogitri, append overlaytmpfs=yes was the last piece of the puzzle. It boots into a login screen. Add ssh and more archs and hopefully I can help with the multi-arch.
2020-05-03 07:28:48 <ikke> ncopa: rust and cargo have been bootstrapped and removed from the builders again
2020-05-03 07:28:52 <ikke> and go
2020-05-03 07:42:01 <Cogitri> Have you looked at the unicode stuff already, ikke? Didn't get to it yesterday but I can take a look after breakfast
2020-05-03 07:42:18 <ikke> Cogitri: no, not yet
2020-05-03 07:47:42 <Cogitri> Okie
2020-05-03 07:57:40 <ikke> hmm, libevhtp is missing onigposix.h, but nothing seems to have that file
2020-05-03 07:58:00 <maxice8> oniguruma lost it recently, let me check
2020-05-03 07:58:40 <maxice8> ok
2020-05-03 07:58:41 <maxice8> found the problem i think
2020-05-03 07:58:59 <ikke> ok
2020-05-03 07:59:00 <maxice8> missing --enable-posix-api, i'll merge a fix
2020-05-03 07:59:05 <ikke> (y)
2020-05-03 07:59:08 <maxice8> was deafult=on now it is default=off
2020-05-03 08:01:59 <maxice8> merged, should be fixed
2020-05-03 08:02:18 <ikke> thanks
2020-05-03 08:34:32 <Cogitri> PureTryOut: Since you're the maintainer of unicode-emoji: Seems like it provides some of the same files as unicode-character-database
2020-05-03 08:35:15 <PureTryOut[m]> Could you make an issue for it and tag me in it?
2020-05-03 08:35:20 <Cogitri> Sure
2020-05-03 08:44:45 <ikke> hmm, libphonenumber fails with what looks like syntax errors on s390x
2020-05-03 08:45:12 <Cogitri> I think libphonenumber has always been a bit special to build
2020-05-03 09:09:38 <ikke> hmm, somehow py3-pytest-forked is built before py3-setuptools_scm, while the former depends on the latter
2020-05-03 09:11:11 <ikke> circular dependency
2020-05-03 09:16:38 <ikke> hmm, no
2020-05-03 09:29:37 <ikke> ok, so ap recursdeps does list py3-pytest-forked as a makedepend for py3-setuptools_scm
2020-05-03 09:34:50 <clandmeter> anyone care to move jo to community?
2020-05-03 09:37:47 <ikke> ok, py3-setuptools_scm -> py3-pip -> py3-distro -> py3-pytest-cov -> py3-pytest-xdist (checkdepends) -> py3-pytest-forked -> py3-pytest_scm
2020-05-03 09:37:53 <mps> clandmeter: your wish is my command :)
2020-05-03 09:40:51 <ikke> Should I just disable tests on py3-pytest-cov?
2020-05-03 09:55:53 <mps> clandmeter: done
2020-05-03 09:56:10 <ikke> oooh
2020-05-03 09:56:15 <ikke> looks interesting
2020-05-03 09:57:55 <mps> ikke: I would like to help but I don't know much python
2020-05-03 10:07:09 <ikke> strange, somehow abuild deps is not installing py3-virtuelenv, which is a checkdepends
2020-05-03 10:11:10 <clandmeter> mps: grazie
2020-05-03 10:12:05 <mps> non ce niente
2020-05-03 10:12:19 <mps> :)
2020-05-03 10:12:20 <clandmeter> i cant go to italy this year, so ill just pretend
2020-05-03 10:12:46 <mps> also I, and I think not only we two
2020-05-03 10:13:17 <clandmeter> yep, should become truck driver :)
2020-05-03 10:13:59 <mps> believe me or not, I tried and worked about 6 months
2020-05-03 10:14:36 <mps> long time ago, now I'm not sure if I can open the door on truck
2020-05-03 10:15:09 <mps> not easy job, ime
2020-05-03 10:15:19 <artok> optimal world would be that python packages would be installed using pip from wheels
2020-05-03 10:17:04 <ikke> artok: you still need to deal with conflicting dependencies
2020-05-03 10:18:00 <ikke> What would be the difference between installing them as a package with apk or installing them with pip as a wheel?
2020-05-03 10:19:15 <artok> pip wheel into virtual env
2020-05-03 10:20:37 <ikke> Finally found the issue why suddenly packages were complaing about pbr missing. Apparently there was an old pbr python package left behind which was not managed by apk
2020-05-03 10:22:23 <ikke> so apparently py3-pytest-cov doesn't even need py3-pytest-xdist
2020-05-03 10:24:32 <ikke> oh lol, checks are disabled, but the checkdepends are still
2020-05-03 10:25:08 <ikke> Then the solution is simple
2020-05-03 11:59:18 <Cogitri> Can someone with bits for abuild take a look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/43 ?
2020-05-03 11:59:26 <Cogitri> It's pretty late for 3.12, but it's a pretty minor change
2020-05-03 11:59:45 <Cogitri> Otherwise I'd have to add DFLAGS="$DFLAGS -g" to all D packages with -dbg subpackages
2020-05-03 12:26:56 <Cogitri> And can someone with main bits take a look at !6260 ?
2020-05-03 12:31:04 <ikke> I can look later
2020-05-03 12:32:39 <Cogitri> Thank you :)
2020-05-03 13:25:56 <ikke> FD: install: target '/home/buildozer/aports/community/fd/pkg/fd-bash-completion/usr/share/bash-completion/completions/fd' is not a directory
2020-05-03 14:31:08 <PureTryOut[m]> Cogitri: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7484
2020-05-03 14:42:48 <mps> 3.12 builder aarch64 => tar: mesa-20.0.6/src/gallium/drivers/nouveau/nv50/nv50_winsys.h: Cannot write: No space left on device
2020-05-03 14:54:46 <Cogitri> PureTryOut[m]: Thanks for fixing it :)
2020-05-03 14:55:17 <PureTryOut[m]> Np
2020-05-03 14:55:36 <PureTryOut[m]> After it's merged, it's one less package for me to care about lol
2020-05-03 15:12:32 <PureTryOut[m]> `ERROR: slang-doc-2.3.2-r0: BAD signature` <- is that going to be fixed at some point?
2020-05-03 15:12:36 <PureTryOut[m]> I have had it for the past 2 days now
2020-05-03 15:12:56 <Cogitri> Huh, that has been fixed itself yesterday on my machine
2020-05-03 15:13:05 <Cogitri> s/been//
2020-05-03 15:13:05 <alpine-meetbot> Cogitri meant to say: Huh, that has  fixed itself yesterday on my machine
2020-05-03 15:13:34 <PureTryOut[m]> I got it just now when upgrading again
2020-05-03 15:14:09 <Cogitri> Hm, can you try deleting the apk file from /var/cache/apk and try again?
2020-05-03 15:14:54 <PureTryOut[m]> Did so, no luck
2020-05-03 15:15:43 <Cogitri> Hm, I guess ikke should take a look then ^
2020-05-03 16:17:50 <clandmeter> PureTryOut[m]: which pkg exactly?
2020-05-03 16:26:41 <clandmeter> ficxed
2020-05-03 16:26:48 <clandmeter> fixed even
2020-05-03 16:42:48 <PureTryOut[m]> Cool, thanks!
2020-05-03 18:59:06 <PureTryOut[m]> Ok wtf, the ppc64le CI keeps timing out while downloading package sources, constantly for different packages. While the other arches all already succeeded, I had to restart the ppc64le CI job 6 or so times already
2020-05-03 19:08:54 <ikke> Cogitri: py3-ufo2ft is a dependency of psautohint, which is maintained by you, but py3-ufo2ft is unmaintained and failing on the builders
2020-05-03 19:10:18 <Cogitri> Huh, weird that the tests are failing now
2020-05-03 19:11:02 <Cogitri> Looking into it
2020-05-03 19:15:16 <Cogitri> I've submitted an upstream issue, but since it looks like all of the failing tests are because the tests don't expect some comment, how about we disable the tests for now to make the builders happy?
2020-05-03 19:15:27 <Cogitri> Since upstream knows about it now I hope that we'll have a proper fix soon-ish
2020-05-03 19:16:22 <Cogitri> !7490
2020-05-03 19:17:24 <Cogitri> Should I make old sec issues that only apply to unsupported branches visible?
2020-05-03 19:17:45 <ikke> good question
2020-05-03 19:18:01 <ikke> I would say no
2020-05-03 19:18:12 <ikke> due to the purpose we make them confidential in the first place
2020-05-03 19:19:31 <Cogitri> Well yes, but old, unsupported releases are insecure anyway, so I guess it's better to know about the dangers they bear
2020-05-03 19:20:27 <Cogitri> Also, I think we really need to do a better job communicating what release is supported and what release isn't, it's scary how many people still recommend Alpine 3.9 when it'll be unsupported in a few weeks and already a sieve for things from community
2020-05-03 19:21:08 <ikke> euhm, 3.9 will be supported for a bit, it's 3.8 that will become unsupported
2020-05-03 19:21:20 <ikke> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-05-03 19:22:22 <Cogitri> Derp, right
2020-05-03 19:22:45 <Cogitri> But I don't think many people are aware community is only supported for 6 months
2020-05-03 19:31:00 <Cogitri> ikke: About #11482 - I'm pretty sure abuild wont like marking packages which have arch dependant binaries in them noarch, right?
2020-05-03 19:32:38 <ikke> It will warn about it, and you could disable that check if it makes sense
2020-05-03 19:33:06 <Cogitri> Ah, okay
2020-05-03 19:33:07 <Cogitri> I guess `apk add --arch` is the way to do this though
2020-05-03 19:33:09 <ikke> https://git.alpinelinux.org/abuild/tree/abuild.in#n1233
2020-05-03 19:39:54 <ikke> I thought --arch only works when initializing a new chroot?
2020-05-03 19:40:23 <ikke> "--arch ARCH             Use architecture with --root:
2020-05-03 19:41:35 <ikke> seems monkey-project.com is down
2020-05-03 19:42:41 <Cogitri> ikke: Quite possibly, I haven't used it yet since crosscompiling on Alpine isn't fun
2020-05-03 19:43:32 <Cogitri> But then there should be an issue against apk-tools to add support for installing packages for foreign arches/proper multiarch support
2020-05-03 19:43:40 <Cogitri> Since we can't really supprot that from the aports side
2020-05-03 19:47:31 <ikke> ScrumpyJack: ping
2020-05-03 19:49:09 <ikke> apparently the monkey-project.com site is down
2020-05-03 19:52:58 <ikke> I switched it to a mirror
2020-05-03 20:01:14 <ikke> funtoo apparently switched to github
2020-05-03 20:01:32 <ikke> (for keychain)
2020-05-03 20:12:18 <ikke> hmm, should I have updated the pkgrel for keychain to force a rebuild on edge, since the source changed?
2020-05-03 20:12:28 <ikke> Technically it should be the same source
2020-05-03 20:37:56 <ikke> Hmm, that's a new one. A server responding with 501 https requried
2020-05-03 20:38:08 <ikke> Y U NO REDIRECT?
2020-05-03 20:40:31 <Cogitri> lol
2020-05-03 20:41:40 <ikke> oh, funny, there is already a patch for that line
2020-05-03 20:45:14 <ikke> hmm
2020-05-03 20:45:58 <ikke> it's not working :*
2020-05-03 20:50:48 <ikke> meh
2020-05-03 21:27:03 <corysanin> Hi all. I'm experimenting with creating an apk package for duktape (c library). Doesn't look like the install routine in its makefile installs a duktape.pc file. Doesn't appear to have such a file in the release anywhere, either. Any advice?
2020-05-03 21:31:31 <Cogitri> Well, it'd be best to ask upstream to add a pkgconfig file then, I suppose
2020-05-03 21:35:44 <corysanin> This is probably a stupid question, but is this file not necessary for publishing a package on debian-based distros? It's already available in the debian/ubuntu apt repos.
2020-05-03 21:40:33 <ikke> you could check this: https://salsa.debian.org/debian-iot-team/duktape
2020-05-03 21:42:41 <ikke> I couhttps://salsa.debian.org/debian-iot-team/duktape/-/blob/master/debian/duktape.pc.in
2020-05-03 21:42:52 <ikke> They provide their own apparently
2020-05-03 21:45:17 <corysanin> Strange. Do any packages in apk do anything like that?
2020-05-03 21:46:23 <ikke> There are some apparently
2020-05-03 21:46:31 <ikke> http://tpaste.us/XgmZ
2020-05-03 21:48:23 <corysanin> I'm fine going that route, then. At least until it's provided in future releases, if and when that happens.
2020-05-03 21:48:56 <ikke> corysanin: you could raise an issue upstream
2020-05-03 21:49:58 <corysanin> I'll give that a shot too. Thanks for the advice 🙂
2020-05-03 22:18:36 <Hello71> the duktape build system sucks
2020-05-03 22:22:28 <corysanin> At first I was surprised that it wasn't in apk, but now I'm surprised that it's in Debian's apt repo
2020-05-03 22:23:07 <corysanin> Doesn't seem to have any tests in the release either, from what I can tell 😕
2020-05-03 23:24:44 <wsinatra> Cogitri: added that s390x comment to toAPK's aport
2020-05-03 23:25:36 <wsinatra> networking in the blue ridge leaves something to be desired..
2020-05-04 00:05:49 <Danct12[m]> can anyone look into merging !7459?
2020-05-04 06:42:08 <PureTryOut[m]> The next version of OpenRCT2 will need Duktape...
2020-05-04 06:42:53 <Cogitri> Well, at least there's a MR for it, I suppose
2020-05-04 06:43:01 <PureTryOut[m]> Yup
2020-05-04 06:47:49 <maxice8> @Cogitri ping
2020-05-04 07:27:33 <ikke> libmateweather is failing, because of (I assume) that our tzdb does not have America/Godthab as timezone (yet). I tried to remove it from data/Locations.xml.in, but that didn't seem to work. Anyone has time to look at it?
2020-05-04 07:31:38 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11486
2020-05-04 07:34:04 <ikke> ncopa: did you by chance bootstrap go on most arches already? It seems to have been built, but I only installed it on one or two builders
2020-05-04 07:46:49 <ikke> Great, tcllib has no maintainer and has 5 failing tests
2020-05-04 07:52:04 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11487
2020-05-04 08:05:03 <ncopa> morning
2020-05-04 08:05:09 <Cogitri> Morning
2020-05-04 08:05:22 <maxwell-k> ikke: !7505 should fix the libmateweather issue you linked, I think you were just missing one line from your patch
2020-05-04 08:06:00 <ikke> maxwell-k: thanks, Leo already merged it
2020-05-04 08:06:09 <ikke> I didn't have a lot of time to look into it :)
2020-05-04 08:07:21 <maxwell-k> I was just checking I linked the right MR, thought oh no all the CI fails, I'm sure it was passing, then I realised he merged it :-)
2020-05-04 08:09:46 <Cogitri> ncopa: Sorry to ping you when you're probably busy with other stuff, but can you maybe take a look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/43? It's just a small change and should allow us to have proper debug info with D packages
2020-05-04 08:11:18 <ikke> Cogitri: note that this has to be manually set at the builders
2020-05-04 08:11:39 <ikke> oh, sorry, n/m
2020-05-04 08:11:40 <Cogitri> I don't think so?
2020-05-04 08:11:57 <Cogitri> :)
2020-05-04 08:50:57 <Danct12[m]> why is libgrilio and libglibutil not in aarch64 apkindex?
2020-05-04 08:51:05 <Danct12[m]> it was merged just this morning
2020-05-04 08:52:20 <ikke> Did you enable the testing repo? (and I assume you are using edge)
2020-05-04 08:52:49 <Danct12[m]> yes, it's also not on pkgs.alpinelinux.org
2020-05-04 08:52:56 <ikke> https://pkgs.alpinelinux.org/packages?name=libgrilio&branch=edge
2020-05-04 08:53:07 <Danct12[m]> however builds for other arches are pushed
2020-05-04 08:53:13 <ikke> https://pkgs.alpinelinux.org/packages?name=libglibutil&branch=edge
2020-05-04 08:53:23 <ikke> hmm, I see
2020-05-04 08:55:22 <ikke> because the aarch64 builder is stuck on another package
2020-05-04 09:13:15 <PureTryOut[m]> I have an package that supports plugins written in Python. Those plugins aren't installed by means of a setup.py like a PyPi package but by extracting the release tarball directly from e.g. Github. Where should I install those plugins too? Right now I have it to `$pkgdir/usr/share/<packagename>/plugin`
2020-05-04 09:13:21 <PureTryOut[m]> Since it's Python, should it maybe be to `/usr/lib` instead?
2020-05-04 09:14:03 <ikke> are they supposed to be imported (ie, in PYTHONPATH)?
2020-05-04 09:15:16 <PureTryOut[m]> Nope
2020-05-04 09:15:27 <ikke> ok
2020-05-04 09:15:31 <PureTryOut[m]> There is a config file for the main package that tells the program where to find them
2020-05-04 09:16:05 <PureTryOut[m]> So I can edit that to anything
2020-05-04 09:16:36 <ikke> I think /usr/lib makes a little bit more sense
2020-05-04 09:17:31 <PureTryOut[m]> So `/usr/lib/<packagename>/plugins` then?
2020-05-04 09:18:01 <ikke> I think that would make sense
2020-05-04 09:18:13 <Cogitri> Hm, aren't the python files noarch?
2020-05-04 09:18:23 <PureTryOut[m]> Ok thanks, will do that
2020-05-04 09:18:26 <PureTryOut[m]> They are
2020-05-04 09:18:30 <ikke> hmm
2020-05-04 09:18:35 <Cogitri> We have a patch on Rust to move python packages to /usr/share because they're noarch 😅
2020-05-04 09:18:40 <Cogitri> s/packages/files/
2020-05-04 09:18:41 <alpine-meetbot> Cogitri meant to say: We have a patch on Rust to move python files to /usr/share because they're noarch 😅
2020-05-04 09:18:45 <PureTryOut[m]> But most Python packages atm, even if noarch, install themselves to `/usr/lib/python3.8/site-packages` too
2020-05-04 09:19:04 <PureTryOut[m]> I currently have it in `/usr/share` so if that is good too, I'll just keep them there
2020-05-04 09:19:11 <mps> so is with perl
2020-05-04 09:19:54 <mps> i.e.  /usr/lib/perl5/core_perl and /usr/lib/perl5/vendor_perl/
2020-05-04 09:20:07 <mps> but that is for module
2020-05-04 09:20:43 <mps> I don't know how this should be set for python
2020-05-04 09:20:54 <Cogitri> I personally don't mind whether we put it in /usr/lib or /usr/share, it's just that we patch Rust to move py things to /usr/share so I though that's the standard for python packages that don't use setup.py
2020-05-04 09:21:33 <mps> yes, I forgot to add there is same for perl in /usr/share
2020-05-04 09:22:07 <mps> i.e. /usr/share/perl5/core_perl/ /usr/share/perl5/
2020-05-04 09:22:21 <mps> iirc, similar is on debian
2020-05-04 09:23:44 <PureTryOut[m]> I'll keep it in `/usr/share` then!
2020-05-04 09:23:46 <PureTryOut[m]> 👍️
2020-05-04 09:25:20 <mps> looks sane, I think /usr/lib is for system modules and /usr/share is for (well) not system things, just guessing
2020-05-04 09:26:55 <ikke>         /usr/share
2020-05-04 09:26:56 <ikke> Architecture-independent (shared) data.
2020-05-04 09:27:07 <ikke> /usr/lib Libraries for the binaries in /usr/bin and /usr/sbin.
2020-05-04 09:27:17 <ikke> That
2020-05-04 09:27:30 <ikke> That's what FHS has to say about it
2020-05-04 09:28:26 <PureTryOut[m]> So `/usr/share` it is
2020-05-04 09:29:46 <mps> (this is not modern, put everything in / :D )
2020-05-04 10:54:19 <clandmeter> ikke: did we look into the salt cve?
2020-05-04 10:54:26 <clandmeter> i have some email in my mailbox
2020-05-04 11:00:45 <Cogitri> The one that caused Lineage OS to get hacked?
2020-05-04 11:01:09 <ikke> I haven't
2020-05-04 11:05:12 <clandmeter> Cogitri: yes and more
2020-05-04 11:06:20 <Cogitri> Oof
2020-05-04 11:18:39 <ncopa> kunkku: i think you are right that pulling in right lua$version module based on install_if=lua$version is wrong. thats why i did  59e37c7f6d3da19f5a14aa07e02f06e23f29f40e
2020-05-04 11:19:30 <ncopa> kunkku: are there other packages that has same problem?
2020-05-04 11:19:52 <kunkku> the problem with aconf was not the dependencies but lua5.3 itself was broken by commit dd508687ca234b47651455c15b64b4e6263f20d5
2020-05-04 11:21:34 <ncopa> right, the "\$V" vs "\${V}"
2020-05-04 11:22:50 <kunkku> but now if you install aconf, you get lua5.3 cmd line interpreter pulled in with the modules
2020-05-04 11:23:30 <kunkku> even though only lua5.3-libs would be needed
2020-05-04 11:24:31 <ncopa> what pulls in lua5.3?
2020-05-04 11:24:41 <kunkku> lua5.3-*
2020-05-04 11:25:24 <kunkku> hm, not all of them but some
2020-05-04 11:25:29 <ncopa> not lua5.3-penlight
2020-05-04 11:25:30 <ncopa> yeah
2020-05-04 11:25:39 <ncopa> that is wrong
2020-05-04 11:26:29 <ncopa> lua-filesystem
2020-05-04 11:26:41 <ncopa> :q
2020-05-04 11:27:26 <kunkku> seems the majority of lua module pkgs have such a dep
2020-05-04 11:28:13 <ncopa> that is wrong, technically
2020-05-04 11:29:07 <kunkku> also py pkgs seem to follow this pattern
2020-05-04 11:29:49 <ncopa> question is how bad it is. it pull in lua5.3 when technically not needed
2020-05-04 11:30:07 <ncopa> but i think there are still various packages that has install_if=lua$ver
2020-05-04 11:30:38 <ncopa> so we may break stuff if we clean up the depends=lua$ver without also cleaning up install_if=lua$ver
2020-05-04 11:31:00 <kunkku> in your opinion, when is it acceptable to use install_if?
2020-05-04 11:31:20 <ikke> installing *-openrc subpackages when openrc is installed
2020-05-04 11:31:26 <ikke> or *-doc for docs
2020-05-04 11:31:35 <ncopa> those are good examples
2020-05-04 11:31:37 <ncopa> also kernel modules
2020-05-04 11:31:48 <maxice8> shell completion
2020-05-04 11:32:04 <Cogitri> lang packages also, very handy to have that
2020-05-04 11:32:12 <ikke> Maybe better: What are improper usecases?
2020-05-04 11:32:31 <kunkku> or what makes the lua use case fundamentally different from the above?
2020-05-04 11:33:06 <mps> huh
2020-05-04 11:33:11 <ncopa> because as you say, there is no direct dependency between the lua module and interpreter
2020-05-04 11:33:47 <ncopa> but you do have a point, we could use it with lya$ver-libs
2020-05-04 11:33:54 <mps> install_if only when it is really needed, not for convenience
2020-05-04 11:34:11 <kunkku> yes, that's what I meant
2020-05-04 11:35:02 <kunkku> if we change to install_if="lua$ver-libs", I don't think there is much difference to openrc
2020-05-04 11:35:28 <ncopa> why do you think we should use install_if=lua5.3-libs to pull in the right lua module instead of adding direct dependencies of lua$version-module-dep?
2020-05-04 11:35:43 <ncopa> oh
2020-05-04 11:35:45 <ncopa> right
2020-05-04 11:35:59 <ncopa> the stuff that we currently have install_if=lua$ver
2020-05-04 11:36:11 <ncopa> chagne that to install_if=lua$ver-libs
2020-05-04 11:36:19 <ncopa> i thikn that may make sense
2020-05-04 11:38:12 <ncopa> i thikn it was jirutka who pushed for using install_if for lua. I assume because it was considered a clever/elegant solution
2020-05-04 11:38:39 <kunkku> I think the install_if approach has some merit
2020-05-04 11:39:10 <ncopa> kunkku: you think its right usecase for lua?
2020-05-04 11:39:45 <kunkku> if your lua program is version-agnostic, the install_if mechanism allows you to write a version-agnostic APKBUILD
2020-05-04 11:40:06 <kunkku> even if it depends on version-dependent modules
2020-05-04 11:40:15 <ncopa> right, like lua-penlight
2020-05-04 11:40:26 <ncopa> which depends on lua-filesystem
2020-05-04 11:41:31 <ncopa> lua-penlight is lua version agnostic, while lua-filesystem is not
2020-05-04 11:41:47 <kunkku> yes
2020-05-04 11:42:43 <kunkku> so the lua-penlight APKBUILD was kind of right
2020-05-04 11:43:14 <kunkku> but worked only if you had the cmd line interpreter installed
2020-05-04 11:43:17 <ncopa> we can in that case use install_if=lua$ver-libs in lua-filesystem or have dummy lua$ver-penlight packages with the direct dependencies of lua$ver-filesystem
2020-05-04 11:43:28 <ncopa> yes
2020-05-04 11:43:31 <ncopa> both works
2020-05-04 11:43:38 <ncopa> just different solutions
2020-05-04 11:44:38 <ncopa> i went for the dummy packages with direct dependencies over install_if in commit 59e37c7f6d3da19f5a14aa07e02f06e23f29f40e
2020-05-04 11:44:51 <ncopa> kunkku: do you prefer the install_if way for this?
2020-05-04 11:45:17 <ncopa> apparently that is what jirutka prefers (or preferred)
2020-05-04 11:46:04 <ncopa> using install_if is not wrong
2020-05-04 11:46:12 <kunkku> at least that makes APKBUILD simpler
2020-05-04 11:46:29 <ncopa> there is one potential downside
2020-05-04 11:47:22 <ncopa> if you install aconf, and pull in lua-penlight + lua5.3-filesystem
2020-05-04 11:47:54 <ncopa> and then install something that uses lua5.2 but does not need lua5.2-filesystem
2020-05-04 11:48:07 <ncopa> then you'd get lua5.2-filesystem installed, even if you don't need it
2020-05-04 11:48:24 <ncopa> its not a huge cost
2020-05-04 11:48:29 <kunkku> that is true
2020-05-04 11:48:50 <ncopa> similar as getting lua5.3 installed with aconf is not a huge cost
2020-05-04 11:50:00 <ncopa> we may be willing to pay that price for simpler APKBUILDs
2020-05-04 11:50:52 <kunkku> in my opinion, we should have default functions for lua etc.
2020-05-04 11:51:08 <ncopa> i think install_if is clever, very clever. I think its too clever in the lua case. but thats my humble opinion. but its not a strong opinion
2020-05-04 11:51:26 <ncopa> default functions for lua in abuild?
2020-05-04 11:52:41 <ncopa> kunkku: what do you think about using direct dependencies for lua modules vs use install_if?
2020-05-04 11:52:55 <ncopa> i guess its somethign we should discuss on the mailing list
2020-05-04 11:53:30 <kunkku> I think it doesn't hurt to fix install_if to lua-libs
2020-05-04 11:53:37 <Cogitri> PureTryOut[m]:https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/libsailfishkeyprovider/libsailfishkeyprovider-1.0.4-r0.log
2020-05-04 11:53:44 <ncopa> kunkku: +1 on that one
2020-05-04 11:54:05 <ncopa> and for the long term strategy?
2020-05-04 11:54:18 <ncopa> i assume that jirutka prefers use install_if
2020-05-04 11:54:25 <PureTryOut[m]> Cogitri: yeah that happened a few times on CI as well, think retriggering the build helps
2020-05-04 11:54:34 <PureTryOut[m]> Maybe it needs `-j1`, not sure
2020-05-04 11:55:07 <ncopa> and i suspect he has strong opinion on this (he almost always has strong opinions)
2020-05-04 11:57:26 <ncopa> kunkku: i can also revert 59e37c7f6d3da19f5a14aa07e02f06e23f29f40e and use lua$ver-libs if you prefer that
2020-05-04 11:58:08 <kunkku> should we ask jirutka's opinion?
2020-05-04 12:00:13 <ncopa> $ grep Maintainer.*Jirutka */lua*/APKBUILD | wc -l
2020-05-04 12:00:13 <ncopa> 44
2020-05-04 12:00:33 <ncopa> $ grep Maintainer.*Copa */lua*/APKBUILD | wc -l
2020-05-04 12:00:34 <ncopa> 52
2020-05-04 12:00:47 <ncopa> yeah. we shoudl ask
2020-05-04 12:01:08 <ncopa> he maintains a significant number of lua packages
2020-05-04 12:02:04 <kunkku> there are basically two issues:
2020-05-04 12:02:35 <kunkku> 1) cmd line interpreter being pulled in as a dep
2020-05-04 12:02:54 <kunkku> 2) cmd line interpreter being used as the proxy for indirect deps
2020-05-04 12:06:10 <ncopa> we can solve the 2 by using -libs as proxy for indirect deps
2020-05-04 12:06:22 <ncopa> i think that is something we should do regardless
2020-05-04 12:07:13 <ncopa> but the question is what we want the general policy to be. do we use direct dependencies (and have more complicated APKBUILDs) or do we use -libs as proxy for indirect deps using install_if
2020-05-04 12:10:38 <kunkku> I think APKBUILD compliction could be adderessed by a default split function
2020-05-04 12:11:46 <ncopa> it could be solved by that yes, but i have tried to avoid add to much blackbox magic to abuild, to keep things transparent, even if it means duplication of code in APKBUILDs
2020-05-04 12:13:26 <ncopa> that said, i do understand that simplifying maintenance is of increasingly importance, while the importance of having beginnerfriendly APKBUILDs is decreasing
2020-05-04 12:13:53 <kunkku> we are using default functions to some extent already
2020-05-04 12:15:32 <kunkku> I don't think direct deps and install_if are mutually exclusive
2020-05-04 12:16:38 <kunkku> we could use lua-penlight as you made it and add install_if to -libs there
2020-05-04 12:17:07 <ncopa> true
2020-05-04 12:29:06 <maxice8> I'll take a look at fd
2020-05-04 12:29:10 <maxice8> it seems i caused it
2020-05-04 12:29:34 <ikke> thanks, already started looking at it, but didn't have time anymore
2020-05-04 12:30:32 <ikke> sounds like mobpass needs to be disabled on armhf/v7
2020-05-04 13:21:10 <ikke> https://github.com/fail2ban/fail2ban/issues/2708
2020-05-04 13:21:31 <ikke> They suggest some issue with python or pysqlite
2020-05-04 13:24:31 <ncopa> maybe assign to tmhoang or disable fail2ban on s390x
2020-05-04 13:24:50 <ikke> ok
2020-05-04 13:44:18 <PureTryOut[m]> Ok wtf. CI complains in one of my MR's that a package that is in the MR doesn't exist and then fails to build something that depends on it because of it
2020-05-04 13:45:02 <ikke> link?
2020-05-04 13:46:00 <ikke> Note that checkapk can complain that a package does not exist, but that's not a fatal error
2020-05-04 13:47:24 <PureTryOut[m]> No I mean that it tries to build a package that depends on a package it refuses to build, even though it got added in the same MR
2020-05-04 13:47:28 <Ariadne> morning
2020-05-04 13:47:37 <PureTryOut[m]> https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/108157
2020-05-04 13:47:50 <PureTryOut[m]> `testing/mycroft-skills-kit` complains that `mycroft-skills-manager` doesn't exist, but it's added in the same MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7412#c15aadde38f5a57c57ac66f5222ba6fcbd5016ef
2020-05-04 13:47:53 <PureTryOut[m]> morning
2020-05-04 13:48:28 <ikke> aha
2020-05-04 13:48:33 <ikke> 52 commits
2020-05-04 13:50:09 <ikke> PureTryOut[m]: We do a shallow clone of aports to make pipelines run quicker
2020-05-04 13:50:17 <ikke> but the depth is 52 commits
2020-05-04 13:50:21 <ikke> 50*
2020-05-04 13:50:30 <ikke> So it misses 2 commits
2020-05-04 13:50:36 <PureTryOut[m]> Ah, so it misses 2 packages...
2020-05-04 13:50:40 <ikke> yes
2020-05-04 13:50:47 <PureTryOut[m]> I guess I'll remove those from the MR then lol
2020-05-04 13:50:59 <ikke> I think we can raise the limit a bit
2020-05-04 13:51:11 <PureTryOut[m]> Well I'm fine with splitting it up more
2020-05-04 13:51:16 <ikke> ok
2020-05-04 13:51:18 <ikke> fine with me
2020-05-04 14:11:09 <PureTryOut[m]> ikke: same thing happens 😕
2020-05-04 14:11:11 <PureTryOut[m]> The MR has 38 commits now
2020-05-04 14:11:15 <ikke> hmm
2020-05-04 14:11:42 <PureTryOut[m]> Oh I see the problem, renaming package gone wrong
2020-05-04 14:12:42 <PureTryOut[m]> (renamed thefolder, not the pkgname)
2020-05-04 14:12:51 <ikke> heh
2020-05-04 16:13:30 <nmeum> why does util-linux-dev depend on util-linux nowadays?
2020-05-04 16:18:45 <ikke> Why did it used to depend on util-linux?
2020-05-04 16:19:07 <ikke> It depends even on a specific version of util-linux
2020-05-04 16:19:52 <ncopa> seems like it was introduced by dcc5965f6f4fabd096b4df6cdd01e4f206341f64
2020-05-04 16:20:00 <ncopa> commit message does not explain why
2020-05-04 16:20:06 <ikke> yaay
2020-05-04 16:20:25 <ikke> maxice8:
2020-05-04 16:20:29 <ikke> Why did you add it?
2020-05-04 16:39:14 <kpcyrd> did something change in lua-aports? `ap dump-json` doesn't seem to work anymore
2020-05-04 16:39:46 <kpcyrd> https://paste.debian.net/plainh/4cfd0da7
2020-05-04 16:40:08 <ikke> Do you execute it in the correct directory?
2020-05-04 16:40:22 <ikke> I know ap is very sensitive to that
2020-05-04 16:40:27 <kpcyrd> ikke: I'm not sure, what's the correct directory?
2020-05-04 16:40:53 <kpcyrd> ah, inside core/community/etc
2020-05-04 16:40:54 <ikke> one of the repo dirs
2020-05-04 16:41:06 <kpcyrd> *main/community/...
2020-05-04 16:41:08 <ikke> yes
2020-05-04 16:41:09 <kpcyrd> got it, thanks!
2020-05-04 17:08:35 <clandmeter> ikke: ok if i push salt secfix?
2020-05-04 17:08:51 <ikke> yes
2020-05-04 17:18:06 <z3ntu> Can I get apk to not automatically uninstall all dependencies of a package that I'm uninstalling?
2020-05-04 17:18:40 <ikke> I don't think so
2020-05-04 17:19:28 <ikke> apk is basically always trying to resolve world
2020-05-04 17:19:47 <ikke> Anything not part of world or require by world gets unintalled
2020-05-04 17:19:54 <ikke> clandmeter: thanks
2020-05-04 17:20:01 <clandmeter> np
2020-05-04 17:20:15 <clandmeter> it has been requested on github
2020-05-04 17:20:21 <z3ntu> hm thanks
2020-05-04 17:20:28 <z3ntu> guess I'll uninstall 151 packages then...
2020-05-04 17:20:49 <ikke> uninstall?
2020-05-04 17:20:54 <Cogitri> z3ntu: It should cache the .apk archives anyway, no?
2020-05-04 17:21:07 <clandmeter> only if you enable caching
2020-05-04 17:21:10 <ikke> nod
2020-05-04 17:21:13 <z3ntu> sd cards are slow still ;)
2020-05-04 17:21:28 <ikke> you need to create /etc/apk/cache
2020-05-04 17:21:58 <z3ntu> I don't really care about the bandwidth, just the time it takes to write the stuff to the sd card
2020-05-04 17:22:17 <clandmeter> tmpfs install ftw :)
2020-05-04 17:22:33 <Cogitri> Ah right, I usually enable the cache on all of my machines
2020-05-04 17:23:20 <Cogitri> libapk has a `APK_SOLVERF_IGNORE_UPGRADE` flag, maybe it could get `APK_SOLVERF_IGNORE_DELETE` flag too
2020-05-04 17:56:54 <ikke> mps: did you manage to find a solution for filezilla?
2020-05-04 18:02:03 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11491
2020-05-04 18:11:16 <mps> ikke: didn't I posted it to tpaste
2020-05-04 18:12:09 <mps> or, maybe try to add to CXXFLAGS '-include assert.h'
2020-05-04 18:12:25 <mps> ok, will look in 20 minutes again
2020-05-04 18:12:45 <ikke> If you did, I cannot find it
2020-05-04 18:12:56 <ikke> I'll try that
2020-05-04 18:13:27 <mps> ok, don't worry, I think I saved APKNUILD with fix
2020-05-04 18:13:41 <mps> but will be on my main box in 20 mins
2020-05-04 18:13:49 <mps> will repost it
2020-05-04 18:14:01 <mps> it was ugly 'sed'
2020-05-04 18:15:02 <ikke> trying the CXXFLAGS now
2020-05-04 18:17:05 <mps> oh, I connected from remote to my box
2020-05-04 18:17:19 <ikke> it is compiling
2020-05-04 18:17:23 <ikke> trying without the flag to be sure
2020-05-04 18:18:05 <ikke> yes, fails without, good
2020-05-04 18:18:09 <mps> here is APKBUILD http://tpaste.us/Z0NZ
2020-05-04 18:18:23 <mps> find ... above make
2020-05-04 18:18:23 <ikke> http://tpaste.us/lYe5
2020-05-04 18:18:46 <ikke> that indentation is.. confusing :)
2020-05-04 18:19:03 <mps> uh, yes
2020-05-04 18:19:29 <mps> ugly :)
2020-05-04 18:19:35 <ikke> but CXXFLAGS works
2020-05-04 18:19:41 <ikke> Do you want to push that?
2020-05-04 18:19:44 <mps> nice, this is better
2020-05-04 18:20:10 <mps> please do, if you don't mind, I'm not at home
2020-05-04 18:20:14 <ikke> ok, no problem
2020-05-04 18:20:29 <ikke> just don't wanted to preempt you
2020-05-04 18:20:39 <mps> I don't care
2020-05-04 18:21:04 <mps> rewrite complete git log and delete me, I don't care
2020-05-04 18:21:34 <ikke> ugh, so anoying. I can do a lot without a mouse, but there are some things that I can only do with a mouse, which I don't have 'close' right now
2020-05-04 18:21:44 <mps> less things to be blamed for :)
2020-05-04 18:21:48 <ikke> :D
2020-05-04 18:22:18 <mps> tmux have select and paste
2020-05-04 18:22:29 <mps> with keyboard
2020-05-04 18:22:32 <ikke> yes
2020-05-04 18:22:46 <ikke> but there are popups I cannot dismiss without a mouse :|
2020-05-04 18:23:01 <mps> ah
2020-05-04 18:23:11 <ikke> With not close I mean taking 3 steps to grab my mouse :P
2020-05-04 18:24:33 <ikke> sigh, I caved :P
2020-05-04 18:25:33 <ikke> I cannot find any references to assert.h missing. Is that something that is available by default on other platforms?
2020-05-04 18:26:05 <mps> don't know really
2020-05-04 18:26:18 <mps> it is strange this happens
2020-05-04 18:26:31 <ikke> asking #musl
2020-05-04 18:46:23 <mps> ikke: I would go with 'CXXFLAGS="$CXXFLAGS -include assert.h"
2020-05-04 18:46:30 <mps> just in case
2020-05-04 18:46:43 <mps> '*
2020-05-04 18:46:53 <ikke> I did
2020-05-04 18:46:59 <mps> nice :)
2020-05-04 18:47:04 <ikke> +export CXXFLAGS="$CXXFLAGS -include assert.h"
2020-05-04 19:33:41 <ikke> Anoying packages that keep hanging on the builders
2020-05-04 19:33:52 <ikke> And I kill one process and it just continues
2020-05-04 19:46:58 <ikke> Cogitri: any idea what to do with aom? Keeps aarch64 blocked
2020-05-04 19:55:46 <Cogitri> Ah, I hoped !7460 would fix that soon
2020-05-04 19:56:59 <Cogitri> I'll take a look at it tomorrow, sorry
2020-05-04 19:59:44 <ikke> np
2020-05-04 20:03:28 <ikke> talking about neon, cadaver is failing due to incompattible neon version
2020-05-04 20:05:53 <ikke> ScrumpyJack: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11492
2020-05-04 20:08:01 <ikke> Apparently we just patch that
2020-05-04 20:11:39 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7526
2020-05-04 20:11:45 <ikke> No clue if that causes issues or not
2020-05-04 20:12:26 <ikke> most builders are chugging along
2020-05-05 06:17:04 <ncopa> morning!
2020-05-05 06:17:28 <ncopa> Ariadne: what was the issue with go 1.14 and mips64?
2020-05-05 06:17:42 <Ariadne> it deadlocks while building
2020-05-05 06:17:55 <Ariadne> i haven't gotten around to getting latest stack trace yet.
2020-05-05 07:04:52 <ikke> morning
2020-05-05 07:05:47 <ikke> ~2700 packages left to build for community on x86_64
2020-05-05 07:06:49 <ikke> hmm, that's not right
2020-05-05 07:07:03 <ikke> ignore that
2020-05-05 07:16:27 <Cogitri> Morning
2020-05-05 08:04:36 <Cogitri> Are the signing keys used by CI always the same?
2020-05-05 08:04:47 <ikke> no
2020-05-05 08:04:49 <Cogitri> Or should I just keep using --allow-untrusted when installing packages from CI?
2020-05-05 08:04:57 <ikke> They are generated on each job
2020-05-05 08:05:26 <ikke> the artifacts to include the key, but not sure if it's woth the hassle to install them
2020-05-05 08:06:04 <Cogitri> Ah, okie, I'll just use --allow-untrusted then, thanks
2020-05-05 08:11:35 <ikke> Maybe we could create a script that downloads the archive and automatically sets it up
2020-05-05 08:13:09 <Cogitri> That'd be pretty fancy
2020-05-05 08:13:12 <Cogitri> install-mr $mrNum
2020-05-05 08:14:11 <Cogitri> mps: !7540 might be of interest to you
2020-05-05 08:21:56 <ikke> Am I the only one who is bothered by the colon in front of the output from algitbot? :)
2020-05-05 08:22:59 <Cogitri> No, it annoys me a bit too, but I think previously algitbot mentioned more than just the link, didn't it?
2020-05-05 08:23:03 <Cogitri> I think it mentioned the title
2020-05-05 08:23:19 <ncopa> yes, it used to get the title
2020-05-05 08:24:03 <ncopa> ikke: did the algitbot code move to gitlab?
2020-05-05 08:24:29 <ikke> https://gitlab.alpinelinux.org/alpine/infra/compose/algitbot
2020-05-05 08:27:18 <ikke> https://gitlab.alpinelinux.org/alpine/infra/compose/algitbot/-/blob/master/sircbot/scripts/sircbot.lua#L38
2020-05-05 08:27:31 <oneinsect> i am here ladies
2020-05-05 08:27:42 <oneinsect> :D
2020-05-05 08:37:28 <ikke> Open issues blocking the builders: https://gitlab.alpinelinux.org/alpine/aports/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=type%3Abuild-failure&milestone_title=3.12.0
2020-05-05 09:44:27 <mps> Cogitri: I see. I'm not interested much in graphic tools, just noted inkscape because with that upgrade one less pkg will depend on python2
2020-05-05 09:44:46 <mps> and this MR looks like not carefully prepared
2020-05-05 09:45:08 <mps> anyway, if I found time later I will look at it
2020-05-05 09:47:44 <mps> and, this pkg is example for which we need to have source in 'our' mirror
2020-05-05 10:02:19 <clandmeter> ncopa: the title is fixed
2020-05-05 10:02:23 <clandmeter> in the new code
2020-05-05 10:02:31 <clandmeter> it just need to move into production
2020-05-05 10:22:58 <ikke> clandmeter: well, what are you waiting for? :P
2020-05-05 10:23:25 <clandmeter> for you to do it :p
2020-05-05 11:06:51 <mps> ncopa: where do you build kernel for rpi armhf, in armhf or armv7 container
2020-05-05 11:22:38 <saramango> Are the sources of all packages available in aports repository (git://git.alpinelinux.org/aports)? In aports/main/ there are 1619 folders (each folder = 1 package, right?) but the mirror offers in total 5348 (https://nl.alpinelinux.org/alpine/v3.11/main/x86_64/). Do you have any idea where are the sources of other packages?
2020-05-05 11:23:08 <Cogitri> 5348 contains subpackages as well
2020-05-05 11:23:20 <PureTryOut[m]> I'm not sure how to reproduce a build failure I'm supposed to fix for 3.12... Is there anyway I can build it locally using 3.12 repos or something?
2020-05-05 11:23:42 <Cogitri> The 1619 folders in the aports git repo are all main packages which may have 0 or more subpackages
2020-05-05 11:25:39 <saramango> Great, Thank you!
2020-05-05 11:26:24 <Cogitri> PureTryOut[m]: What's the build failure? Sadly there isn't really a way to test it other than trying it on the builders I think
2020-05-05 11:26:27 <ikke> PureTryOut[m]: 3.12 is mostly edge
2020-05-05 11:26:42 <ikke> but built from scratch
2020-05-05 11:27:00 <PureTryOut[m]> Btw `main/bind` doesn't have a maintainer
2020-05-05 11:27:05 <PureTryOut[m]> ikke: but I can't reproduce it on edge
2020-05-05 11:27:20 <PureTryOut[m]> Cogitri: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11496
2020-05-05 11:28:36 <ikke> PureTryOut[m]: any idea where those symbols are supposed to come from?
2020-05-05 11:30:44 <PureTryOut[m]> Not sure but I'd think `wayland-dev`
2020-05-05 11:46:36 <ikke> interesting, repology started tracking 3.11 as well, not just edge
2020-05-05 11:51:50 <mps> src/inkscape-1.0_2020-05-01_4035a4fb49/src/libnrtype/font-lister.cpp:1223:64: error: missing sentinel in function call [-Werror=format=]
2020-05-05 11:51:50 <hicham> Hello everyone
2020-05-05 11:52:13 <mps> 1223 |     g_object_set(G_OBJECT(cell), "markup", markup.c_str(), NULL);
2020-05-05 11:52:34 <hicham> How to contribute with some APKBUILDS ?
2020-05-05 11:52:34 <mps> Cogitri: ^ maybe you know how to fix this in inkscape
2020-05-05 11:52:44 <Cogitri> I can take a loom
2020-05-05 12:58:09 <PureTryOut[m]> Cogitri: how do you think PYTHONPATH can be used to make packages see themselves for tests?
2020-05-05 13:05:18 <PureTryOut[m]> Actually, I should look into how other packages do it more, got tons of examples 😃
2020-05-05 13:09:04 <Cogitri> 👍
2020-05-05 13:10:47 <PureTryOut[m]> (it works btw, thanks!)
2020-05-05 17:58:35 <clandmeter> ping
2020-05-05 17:59:16 <ikke> Who are you pinging? :P
2020-05-05 17:59:26 <clandmeter> the irc logs
2020-05-05 17:59:34 <ikke> heh
2020-05-05 17:59:35 <clandmeter> oik we lost few hours
2020-05-05 17:59:39 <clandmeter> but its ok i guess
2020-05-05 18:00:14 <clandmeter> i broken the dns record..
2020-05-05 18:00:25 <clandmeter> so will be updated when it times out
2020-05-05 18:01:54 <clandmeter> algitbot: retry foobar
2020-05-05 18:02:01 <clandmeter> he you are stupid
2020-05-05 18:02:56 <ikke> The bot has feelings to, you know
2020-05-05 18:03:34 <clandmeter> algitbot: you are stupid
2020-05-05 18:03:45 <clandmeter> yes very limited :p
2020-05-05 18:04:16 <ikke> hehe :D
2020-05-05 18:41:12 <clandmeter> algitbot: ping
2020-05-05 18:41:30 <clandmeter> algitbot: ping
2020-05-05 19:07:16 <clandmeter> algitbot: ping
2020-05-05 19:07:22 <clandmeter> thats more like it
2020-05-05 19:07:29 <clandmeter> algitbot: retry master
2020-05-05 19:07:56 <clandmeter> algitbot: retry foobar
2020-05-05 19:13:05 <afontain_> Hello71: thanks for the article
2020-05-05 19:35:40 <ikke> Trying to find out why dockviz is built after containerd
2020-05-05 19:35:43 <ikke> euhm
2020-05-05 19:35:45 <ikke> before
2020-05-05 19:38:09 <ikke> (dockviz needs containerd)
2020-05-05 20:05:22 <PureTryOut[m]> Why is the internet connection of the ppc64le CI runner so flaky?
2020-05-05 20:05:48 <PureTryOut[m]> 99% of the time when a ppc64le CI job fails it's because it timed out while downloading package sources
2020-05-05 20:06:00 <ikke> PureTryOut[m]: very good question, to which I have no answer to
2020-05-05 20:06:40 <ikke> I'm running against this myself as well
2020-05-05 20:07:03 <ikke> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10687
2020-05-05 20:07:52 <PureTryOut[m]> Thanks I'll subscribe to that issue
2020-05-05 20:08:48 <ikke> Anyone got a clue why dockviz depends on containerd? I cannot find the dependency
2020-05-05 20:09:39 <ikke> but the 3.12 builder says it is
2020-05-05 20:15:28 <artok> dockviz depends on docker ?
2020-05-05 20:15:56 <ikke> yes, I found it
2020-05-05 20:16:08 <ikke> docker -> docker-engine -> containerd
2020-05-05 20:16:37 <artok> btw I just love "apk dot" command =)
2020-05-05 20:16:58 <ikke> yes, but it shows too much
2020-05-05 20:17:03 <ikke> hard to follow
2020-05-05 20:17:37 <ikke> hmm
2020-05-05 20:17:55 <ikke> you can limit it
2020-05-05 20:18:28 <ikke> but it only shows run-time deps
2020-05-05 20:25:17 <PureTryOut[m]> How would you use `apk dot`?
2020-05-05 20:25:48 <Cogitri> You can draw it with `dot` from graphviz
2020-05-05 20:26:54 <PureTryOut[m]> `apk dot | dot`?
2020-05-05 20:28:36 <Cogitri> Not sure if you can pipe
2020-05-05 20:28:59 <Cogitri> But `apk dot > deps.dot && dot -Tpng deps.dot -o graph1.png` works
2020-05-05 20:29:17 <PureTryOut[m]> well how else? `apk dot > test.dot && dot test.dot` doesn't seem to do much. I never used dot before so no clue how to use it
2020-05-05 20:29:24 <PureTryOut[m]> Oh, more arguments needed
2020-05-05 20:30:12 <ikke> -T
2020-05-05 20:31:04 <ikke> dot -Tpng input.dot -o output.png
2020-05-05 20:32:11 <ikke> There is also -Tx11
2020-05-05 20:32:35 <ikke> dot -Tx11 input.dot
2020-05-05 20:32:43 <ikke> shows a window with the rendered output
2020-05-05 20:33:17 <ikke> ok, I think that dockviz was just a glitch, it seems now to be built near the end
2020-05-05 20:33:58 <PureTryOut[m]> Well it either takes a long time for dot to generate an image, or it just never finishes
2020-05-05 20:34:28 <ikke> well, if you use apk dot, then yes, that would take a *long* time
2020-05-05 20:34:34 <ikke> maybe more usefull is apk dot --error
2020-05-06 01:44:45 <wsinatra> probably a silly question, but how do you reuse an aports fork once you've had an MR pushed? I've been deleting my forks and remaking them, which seems a bit overkill
2020-05-06 01:49:32 <danieli> were you working on a separate branch? if so, you could kill the branch and pull upstream back in
2020-05-06 01:50:11 <wsinatra> unfortunately no, I was working in the head of the fork. I probably should branch it
2020-05-06 05:01:12 <kaey> yes. dont touch master, except to pull and make a new branch from it
2020-05-06 05:01:30 <ikke> wsinatra already left
2020-05-06 05:03:20 <kaey> gitlab has no docs for MR workflow for some reason, guess youre supposed to know all this from your parents when born
2020-05-06 05:15:43 <clandmeter> you can kind of copy github workflow, it should be similar.
2020-05-06 05:17:32 <Cogitri> kaey: https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-from-you-local-environment ?
2020-05-06 05:21:51 <kaey> i was looking for it when alpine switched to gitlab and couldnt find anything useful
2020-05-06 05:24:38 <clandmeter> gitlab is known for documentation a lot of processes.
2020-05-06 06:46:15 <mps> nmeum: ping
2020-05-06 07:07:20 <PureTryOut[m]> Cogitri: fixed all your comments, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7412 should now be ready for merging
2020-05-06 07:10:21 <mps> !7412
2020-05-06 07:13:37 <Cogitri> Okie, will take a look after work
2020-05-06 08:41:23 <nmeum> mps: pong
2020-05-06 08:49:37 <PureTryOut[m]> Does anyone know why this fails to impor the Python module 'tests'? That is provided by Python 3 itself no? https://paste.sr.ht/%7Epuretryout/76d70900157fd7206a3ca51da7f6cc48cc69f4c0
2020-05-06 08:49:43 <PureTryOut[m]> *import
2020-05-06 08:50:30 <ikke> I don't think that's a standard module
2020-05-06 08:50:45 <ikke> unittest does exist
2020-05-06 08:50:50 <PureTryOut[m]> It isn't? 🤔
2020-05-06 08:51:02 <PureTryOut[m]> https://docs.python.org/3/library/unittest.html
2020-05-06 08:51:09 <PureTryOut[m]> Afaik that is standard Python
2020-05-06 08:51:12 <ikke> yes, untittest, not tests
2020-05-06 08:51:28 <ikke> import unittest works; import tests not
2020-05-06 08:51:46 <PureTryOut[m]> Oh woops I misread your comment
2020-05-06 08:52:00 <ikke> :)
2020-05-06 08:52:01 <PureTryOut[m]> But according to the error, it does use unittest
2020-05-06 08:53:05 <PureTryOut[m]> Also looking through the tests, they definitely use unittest
2020-05-06 08:53:28 <PureTryOut[m]> 
ACTION investigates further

2020-05-06 08:53:32 <ikke> the question is why it's trying to import tests
2020-05-06 08:58:52 <nmeum> you need to install python3-tests if you you want to import tests iirc
2020-05-06 08:59:03 <mps> nmeum: firefox-esr MR pass on aarch64 in lxc
2020-05-06 08:59:09 <nmeum> tests is the internal testing library used by python
2020-05-06 08:59:45 <nmeum> my firefox-esr build ran out of disk spaces on my builder ':)
2020-05-06 08:59:59 <PureTryOut[m]> Ok got it lol. The release package from PyPi doesn't include the tests 😒
2020-05-06 09:00:03 <PureTryOut[m]> 
ACTION switches sources to Github

2020-05-06 09:00:19 <mps> I wanted to ask will you create MR for 3.11 but in meantime I did it, thought you are busy
2020-05-06 09:00:55 <nmeum> thanks, actually kind of busy atm but I also don't wake up that early :)
2020-05-06 09:01:20 <mps> heh, also on my 3.11 builder it failed because of disk space
2020-05-06 09:01:27 <nmeum> hehe
2020-05-06 09:01:57 <nmeum> not sure if I get around to fixing my builder today. If the firefox-esr MR works for you on edge just go ahead and merge it
2020-05-06 09:02:51 <mps> I think it is safe to merge
2020-05-06 09:04:39 <mps> actually, I already running 68.8.0 on aarch64 edge
2020-05-06 09:10:01 <mps> ikke: could you allow/change !7549 to enable rebase and merge for other devs not only author
2020-05-06 09:11:22 <ikke> done
2020-05-06 09:11:45 <mps> thanks
2020-05-06 09:12:57 <mps> merged, and fingers crossed :)
2020-05-06 10:24:04 <PureTryOut[m]> > ERROR: py3-grpc: 0.3_19 is not a valid version
2020-05-06 10:24:09 <PureTryOut[m]> Then what would a valid version be? It doesn't like - either
2020-05-06 10:26:01 <ikke> 0.3_p19
2020-05-06 10:27:10 <PureTryOut[m]> Ah yes that works, thanks
2020-05-06 11:54:54 <rozamunda> What is the purpose of "passwd -u" command? In manual it says it unlocks the account. I see that after executing it, the /etc/shadow changes, i.e., the user password changes from "!" into "". Can I remotely access the computer using such a user?
2020-05-06 11:58:28 <clandmeter> yes
2020-05-06 11:58:33 <clandmeter> ! will not work
2020-05-06 11:58:56 <clandmeter> you can also set it to *
2020-05-06 11:59:03 <clandmeter> which also ulocks the acc
2020-05-06 11:59:14 <clandmeter> and is impossible to login by password
2020-05-06 12:00:02 <clandmeter> but these kind of questions should technically go to #alpine-linux
2020-05-06 12:01:49 <rozamunda> ok, I found out that two packages in community repository (gogs, gitea) create users with empty password (using passwd -u). The users have defined shell and home directory. Should I contact the package maintainer to change it?
2020-05-06 12:04:34 <rozamunda> https://git.alpinelinux.org/aports/tree/community/gogs/gogs.pre-install
2020-05-06 12:10:56 <clandmeter> why?
2020-05-06 12:15:59 <clandmeter> ah i read that wrong.
2020-05-06 12:16:11 <clandmeter> not sure why its set like that.
2020-05-06 12:17:07 <rozamunda> maybe a misconfiguration, or some left over from the development
2020-05-06 12:17:36 <clandmeter> git tells a different story
2020-05-06 12:19:57 <clandmeter> i guess this account needs ssh access
2020-05-06 12:20:17 <clandmeter> both gogs and gitea need it for git access
2020-05-06 12:26:53 <clandmeter> when using pam a locked account is still usable via ssh, but we dont use pam.
2020-05-06 12:27:50 <ncopa> i think we may have an openssh server build with pam support
2020-05-06 12:27:57 <clandmeter> but simply unlocking it is concidered a security issue
2020-05-06 12:28:48 <clandmeter> wont that try use path to authenticate?
2020-05-06 12:29:15 <clandmeter> err PAM
2020-05-06 12:29:58 <clandmeter> UsePAM yes
2020-05-06 12:52:32 <rozamunda> The default SSH setting does not allow PAM (`/etc/ssh/sshd_config line 82: Unsupported option UsePAM`). Therefore, one must set `PermitEmptyPasswords Yes` in order to ssh with a user that has empty password
2020-05-06 12:53:33 <rozamunda> or, one must use `openssh-server-pam`
2020-05-06 12:54:52 <mps> ncopa: would you review and decide what to do with !7221
2020-05-06 12:55:13 <mps> also !7409
2020-05-06 13:22:39 <Hello71> even with pam I think permitemptypasswords still functions
2020-05-06 13:22:49 <Hello71> it takes the more restrictive of permitemptypasswords and nullok
2020-05-06 13:29:18 <Hello71> huh, that's confusing. sshd only checks for locked passwords if usepam is no
2020-05-06 13:29:26 <Hello71> even if you are using keys
2020-05-06 13:31:55 <Hello71> oh, clandmeter already said that
2020-05-06 13:33:28 <Hello71> why does base-auth.pamd have nullok_secure if we do not carry the debian patch?
2020-05-06 13:38:17 <Hello71> is William Pitcock <nenolod@dereferenced.org> still here?
2020-05-06 13:39:58 <rozamunda> ok, let me catch up. I create a user and I unlock it (passwd -u). Now, I can login only if sshd configuration matches (`permitemptypasswords Yes`) or (`UsePAM YES` and `nullok`). Is that right?
2020-05-06 13:45:38 <ikke> Hello71: Ariadne
2020-05-06 13:48:29 <Hello71> rozamunda: or if UsePAM yes and you use not-passwords
2020-05-06 13:49:33 <Hello71> usually people use pam, so there is no need to unlock the user. but, sshd does not allow key authentication with a locked account if pam is off, which is common on alpine
2020-05-06 13:57:12 <walbon> PureTryOut[m]: do you still have problem into ppc64le CI?
2020-05-06 13:57:46 <PureTryOut[m]> Not atm but I'm sure the problem is still there if no one has actively done anything about it
2020-05-06 13:58:30 <ikke> This job keeps failing for me when trying to upload the artifacts: https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/jobs/109636
2020-05-06 13:58:58 <rozamunda> Hello71 got it. thank you
2020-05-06 14:01:11 <walbon> PureTryOut[m]: I'm tracking messages here to know issue on ppc and I saw your message, I can talk to maintainer of laboratory to know what's happening there.
2020-05-06 14:01:43 <rozamunda> then, I understand that the gogs and gitea packages simply use `passwd -u` to unlock the user they created. this permits a key-based login. a side effect is that the user has null password, which in some special configuration might allow connecting to the machine without providing password. but, such configuration is unlike to happen
2020-05-06 14:02:25 <ikke> walbon: that job now succeeded apparently
2020-05-06 14:02:47 <ikke> walbon: here are some diagnostics I did: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10687
2020-05-06 14:08:02 <Cogitri> Is someone with main bits in the mood to check out !6260 ?
2020-05-06 14:08:09 <Cogitri> Has been rotting for some time now
2020-05-06 14:08:30 <Cogitri> And the package has been broken for some time now
2020-05-06 14:08:54 <Cogitri> And it's one of the last py2 packages
2020-05-06 14:10:07 <ncopa> mps: im getting weird error when trying to build ncurses locally
2020-05-06 14:10:40 <ncopa> mv: can't rename '/home/ncopa/aports/main/ncurses/pkg/ncurses/usr/share/terminfo/t/terminology-1.0.0
2020-05-06 14:10:40 <ncopa>  /home/ncopa/aports/main/ncurses/pkg/ncurses/usr/share/terminfo/t/terminology
2020-05-06 14:10:40 <ncopa>  /home/ncopa/aports/main/ncurses/pkg/ncurses/usr/share/terminfo/t/terminology-0.6.1': No such file or directory
2020-05-06 14:10:54 <ncopa> why is it 1.0.0 and 0.6.1?
2020-05-06 14:15:13 <ncopa> ok, i know why
2020-05-06 14:15:23 <ncopa> terminology*
2020-05-06 14:15:51 <ncopa> there are multiple terminology*
2020-05-06 14:16:15 <ncopa> so `local termfile=$(find "$pkgdir"/usr/share/terminfo/ -name "$i" 2>/dev/null) || true` ends up with a list of mutiple paths
2020-05-06 14:16:21 <ncopa> but code assumes its a single file
2020-05-06 14:23:35 <ikke> Hmm, a single github project, but with numerous separate archives, yaay
2020-05-06 14:34:22 <markand> ow, pipelines do not run over several commits when opening a merge request that contains several commits?
2020-05-06 14:35:53 <ikke> It should, yes?
2020-05-06 14:36:01 <markand> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7586/pipelines
2020-05-06 14:36:05 <markand> here it stopped at the first one
2020-05-06 14:37:01 <ikke> >>> Changed aports:
2020-05-06 14:37:03 <ikke> libretro-core-info libretro-database retroarch
2020-05-06 14:37:11 <ikke> it detects all 3 packages as changed
2020-05-06 14:37:45 <ikke>  >>> community/libretro-core-info: build succesfully
2020-05-06 14:37:47 <ikke> >>> community/libretro-database: build succesfully
2020-05-06 14:37:49 <ikke> >>> community/retroarch: build succesfully
2020-05-06 14:37:54 <markand> aah
2020-05-06 14:38:48 <markand> I was confused by the fact that the pipeline title reference only the first commit
2020-05-06 14:39:21 <PureTryOut[m]> Cogitri: if you have time please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7412, it would help me with the rest of the packaging 😃
2020-05-06 14:52:50 <ikke> I need some advise. https://github.com/SELinuxProject/selinux/ hosts basicaly 15 different projects, each with their own release archive. We currently already have policycoreutils in testing, I need 2 other 'modules'. Should I add them all under their original name, or should I prefix them with selinux- or se-?
2020-05-06 14:54:08 <ikke> I don't think we can build everything from the main project and just use subpackages
2020-05-06 14:54:15 <ikke> https://github.com/SELinuxProject/selinux is missing a lot of modules
2020-05-06 14:54:54 <ikke> Or maybe it isn't
2020-05-06 14:55:59 <Cogitri> Is SELinux even useful on Alpine?
2020-05-06 14:56:22 <ikke> I just need tools to build the profiles
2020-05-06 15:01:07 <prez> is there any chance of a PR to move lxd and distrobuilder from testing so those can make it into the 3.12 release being accepted?
2020-05-06 15:01:46 <ikke> There is still time
2020-05-06 15:02:13 <prez> alright, I'll do that then
2020-05-06 15:05:00 <prez> oh, distrobuilder is broken
2020-05-06 15:13:54 <Cogitri> ikke: I don't think they need to be prefixed
2020-05-06 15:14:59 <ikke> yeah, checkpolicy and policycoreutils already exist in testing
2020-05-06 15:15:09 <ikke> I'll just add semodule-utils
2020-05-06 19:53:20 <z3ntu> Cogitri: fyi regarding the openrc-settingsd package: I've resolved basically all compile warnings with a few patches at https://git.sr.ht/~z3ntu/openrc-settingsd/log
2020-05-06 19:54:15 <z3ntu> Just so you're aware of these patches. I've tried to contact the Gentoo upstream but my email to the gentoo list was rejected for some reason and I wasn't terribly successful in the gentoo IRC channel either with it
2020-05-06 19:55:36 <Cogitri> Oh, fancy!
2020-05-06 19:56:06 <Cogitri> I was actually looking into working on openrc-settingsd too, but somehow always found another thing to work on so I don't have to work on a C codebase :D
2020-05-06 19:56:32 <Cogitri> I think the timezone stuff is broken as of now too, or at least setting the timezone in the GNOME Control Center doesn't do anything
2020-05-06 19:56:46 <z3ntu> This also removes the need for bash in the build script ^^
2020-05-06 19:57:04 <z3ntu> I know of this bug regarding locale: https://bugs.gentoo.org/699530
2020-05-06 19:58:17 <z3ntu> I was mostly interested in the project because of bluez using org.freedesktop.hostname1 for the display name, and not really because of the localed/timedated part
2020-05-06 19:58:46 <Cogitri> Ah, I only use it for GNOME's control center
2020-05-06 19:59:08 <Cogitri> Speaking of GNOME, I should fix Phosh, oops
2020-05-06 20:02:02 <PureTryOut[m]> Cogitri: sorry for bothering you with it, but could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7412 again? 😉 I'm kinda excited for this whole thing if you hadn't guessed so yet haha
2020-05-06 20:12:07 <Cogitri> PureTryOut[m]: Ah yes, I'll take a look in a minute, I'm deep inside some dark template vodoo right now
2020-05-06 20:13:00 <PureTryOut[m]> Sure that gives me time to update one of the packages in that MR
2020-05-06 20:14:01 <ikke> Now you are both here. It seems both vulkan-tools (maintained by PureTryOut[m]) as metacity (maintained by cogitri) have the same issue
2020-05-06 20:14:28 <Hello71> s/as/and/?
2020-05-06 20:14:28 <alpine-meetbot> Hello71 meant to say: rozamunda: or if UsePAM yes and you use not-pandswords
2020-05-06 20:14:34 <Hello71> ...
2020-05-06 20:14:39 <Hello71> alpine-meetbot: bad bot
2020-05-06 20:15:07 <ikke> Hello71: heh, some dutch getting through :)(
2020-05-06 20:16:01 <PureTryOut[m]> I'm unsure how to fix that sadly
2020-05-06 20:16:11 <PureTryOut[m]> ppc64le only as well strangely enough
2020-05-06 20:16:23 <ikke> metacity is x86
2020-05-06 20:16:32 <ikke> Note that not all arches are at the same level yet
2020-05-06 20:17:08 <Cogitri> Ah, what issue?
2020-05-06 20:17:32 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11503
2020-05-06 20:19:24 <ikke> The macros differ, but start with VK_
2020-05-06 20:19:39 <ikke> metacity uses vulkan
2020-05-06 20:19:54 <ikke> error: 'VK_PHYSICAL_DEVICE_TYPE_RANGE_SIZE' undeclared (first use in this function); did you mean 'VK_PHYSICAL_DEVICE_TYPE_MAX_ENUM'?
2020-05-06 20:23:20 <ikke> 413 packages left for x86_64 :)
2020-05-06 20:31:16 <PureTryOut[m]> I'm off to bed, done for today. Good night guys!
2020-05-06 20:31:22 <ikke> o/
2020-05-06 20:46:50 <Cogitri> Looking into the vulkan stuff now while I hope the builders don't choke on mycroft
2020-05-06 20:47:15 <ikke> heh
2020-05-06 21:07:40 <mps> ncopa: sorry, I was on party and I'm probably drunk, but I think terminologi terminfo doesnt't belong to ncurses-terminfo-base (if I read it correctly now)
2020-05-06 21:08:14 <mps> will look tomorrow at that
2020-05-06 21:09:52 <Cogitri> ikke: Can you remember Rust crashing on the builders ever since we upgraded to LLVM10 ?
2020-05-06 21:10:02 <Cogitri> Upstream thinks it's fixed with LLVM10
2020-05-06 21:10:53 <Cogitri> Also, the vulkan stuff should be fixed for now
2020-05-06 21:13:00 <ikke> I've not noticed it crashing lately, but I have no idea when the last time it was it crashed
2020-05-06 21:14:01 <ikke> oh, you found the vulkan issue?
2020-05-06 21:14:44 <ikke> nice
2020-05-06 21:14:52 <Cogitri> Yes, the vulkan-headers 1.2.140 upgrade broke stuff
2020-05-06 21:15:11 <Cogitri> And wow GitHub search really isn't that great
2020-05-06 21:15:25 <ikke> it's infamous
2020-05-06 21:15:42 <Cogitri> Rust usually crashed on things using gtk-rs, so fractal, tau, gnome-shortwave etc.
2020-05-06 21:16:04 <Cogitri> Those didn't have too many upgrades since we've upgraded to LLVM10 though
2020-05-06 21:16:09 <ikke> right
2020-05-06 21:17:54 <Cogitri> Anyway, time to sleep for me as well
2020-05-06 21:17:59 <ikke> o/
2020-05-06 21:18:01 <ikke> nite
2020-05-06 21:28:40 <Cogitri> Night :)
2020-05-07 06:48:21 <markand> heya
2020-05-07 06:49:11 <ikke> markand: o/
2020-05-07 07:14:33 <maxwell-k> what's the right way to handle a checkdepends that is only available on some archs?
2020-05-07 07:14:57 <maxwell-k> disable the whole package? or is there a way to disable check only?
2020-05-07 07:16:17 <maxice8> case "$CARCH" in arch) options="$options !check" esac
2020-05-07 07:17:00 <maxice8> sorry for the poor formatting but i think it is enough to get the idea
2020-05-07 07:17:45 <maxwell-k> I get the idea! ty
2020-05-07 07:18:19 <maxwell-k> looking closer, a smaller set of tests runs where that checkdepends isn't available
2020-05-07 07:19:14 <maxwell-k> is it possible/recommended to change checkdepends, depending on CARCH?
2020-05-07 07:19:52 <maxice8> never saw it being done but if it results in more tests then i'd guess it is acceptable
2020-05-07 07:24:36 <ikke> Just make sure to add a comment on why it's done
2020-05-07 07:36:15 <maxwell-k> ty, seems to work !17197
2020-05-07 07:36:36 <ikke> hmm, algitbot?
2020-05-07 07:36:37 <maxwell-k> whoops, !7630
2020-05-07 07:36:42 <ikke> heh
2020-05-07 07:36:55 <ikke> I guess that was the job #?
2020-05-07 07:37:06 <ikke> pipeline
2020-05-07 07:50:24 <maxwell-k> yep that was the pipeline number, my mistake
2020-05-07 07:51:43 <maxwell-k> ty for your review, I quickly opened !7631 to better document your style advice
2020-05-07 09:47:28 <mps> ah, nice, ncurses fixed finally (I hope) and merged. thanks ncopa
2020-05-07 09:48:20 <ncopa> np
2020-05-07 09:48:45 <mps> I think we should move testing/double-conversion to community, needed for new inkscape. any objection?
2020-05-07 09:49:30 <ncopa> no objection. APKBUILD looks good
2020-05-07 09:50:16 <mps> ok, will do
2020-05-07 09:53:28 <mps> btw, when you are online, what you decided about external kernel drbd module, to keep it for 3.12 or remove from repo?
2020-05-07 09:56:14 <ncopa> um
2020-05-07 09:56:29 <ncopa> the thirdparty module was requested by upstream developer some time ago
2020-05-07 09:56:46 <ncopa> not sure what the difference is nowdays
2020-05-07 09:56:58 <mps> I remember, you explained earlier
2020-05-07 09:57:49 <mps> this external module have one or two more options, one debug and other to work with TCP
2020-05-07 09:58:32 <mps> though in my experience in-kernel module also works with TCP
2020-05-07 09:58:48 <mps> but not sure if in different method
2020-05-07 10:00:46 <ncopa> can we investigate what the difference is between the module in mainline kernel and upstream 3rdparty? is there a some way to find out what version of drbd is in mainline kernel?
2020-05-07 10:00:55 <ncopa> woudl be good to get rid of the third-party module
2020-05-07 10:01:59 <mps> modinfo drbd => version:        8.4.11
2020-05-07 10:02:17 <mps> though kernel 5.6.9
2020-05-07 10:02:48 <mps> and same is for 5.4.25-lts
2020-05-07 10:04:18 <maxice8> mps: thanks for fixing checksum on timew
2020-05-07 10:05:59 <ncopa> i think we can keep the drbd 3rd party module for now. it does not add much work for us
2020-05-07 10:06:37 <mps> maxice8: np, but it still fails
2020-05-07 10:06:48 <mps> ncopa: ok
2020-05-07 10:20:44 <ncopa> clandmeter: do you still use lua-turboredis?
2020-05-07 10:23:07 <clandmeter> never used it
2020-05-07 10:23:15 <clandmeter> its not maintained afaik
2020-05-07 10:31:43 <ncopa> lets move it to unmaintained then
2020-05-07 10:32:24 <ncopa> actually, lets just purge it
2020-05-07 10:40:16 <maxice8> nice
2020-05-07 10:40:45 <ikke> Cogitri: shouldn't metacity be fixed now?
2020-05-07 10:41:40 <Cogitri> Should be, yes, but maybe vulkan-headers wasn't downgraded properly on those builders?
2020-05-07 10:42:02 <Cogitri> Anyway, I think metacity should be fixable even with vulkan-headers 1.2.140
2020-05-07 10:42:11 <Cogitri> The problematic thing is that gtk4 fails to build too with the new vulkan-headers
2020-05-07 10:42:18 <ikke> "(16/208) Purging vulkan-headers (1.2.140-r0)"
2020-05-07 10:42:49 <Cogitri> Huh, why did it not do the downgrade 🤔
2020-05-07 10:44:16 <ncopa> the repository was never successfully built, so it never reached the point where old packages got deleted
2020-05-07 10:44:30 <ncopa> it halts and exits on error
2020-05-07 10:44:52 <ncopa> so the local repository has both new and old in index and it will prefer the new
2020-05-07 10:44:53 <ikke> metacity seems to be the only package left to build (according to ap build-list)
2020-05-07 10:45:23 <ncopa> can we fix metacity to build with new vulcan headers?
2020-05-07 10:45:36 <ikke> vulkan-utils would need to be fixed as well
2020-05-07 10:47:47 <ikke> 170 packages left for x86_64
2020-05-07 10:48:42 <ikke> 877 for aarch64
2020-05-07 10:50:47 <Cogitri> Yes, fixing metacity is easy
2020-05-07 10:50:53 <Cogitri> Fixing gtk4, not so much
2020-05-07 10:51:38 <Cogitri> I can push a fix for metacity but for gtk4 we'll have to wait for upstream (or someone who knows the vulkan API)
2020-05-07 11:24:39 <Cogitri> Can we just add a dep on vulkan-headers<1.2.139 ?
2020-05-07 11:24:43 <Cogitri> Err..<1.2.140
2020-05-07 11:25:21 <ikke> The repo itself will just contain 1 version
2020-05-07 11:25:42 <ikke> but it should fix it in the interrim I gues
2020-05-07 11:29:05 <Cogitri> !7653
2020-05-07 14:09:34 <mps> !7540 is in bad shape, maybe I should create alternative one?
2020-05-07 14:10:44 <mps> don't want to discourage contributor but progress is so slow despite I attached complete APKBUILD in comment there
2020-05-07 15:24:26 <Bridouz> o/
2020-05-07 15:25:39 <ikke> GCC 10.1 released: https://gcc.gnu.org/pipermail/gcc-announce/2020/000163.html
2020-05-07 15:25:48 <Bridouz> I don't understand a thing in CI
2020-05-07 15:26:20 <Bridouz> I'm (poorly and badly) working on inkscape 1.0 and I need `double-conversion` to build.
2020-05-07 15:27:12 <ikke> Bridouz: hi
2020-05-07 15:27:20 <Bridouz> mps moved it from testing to community but CI does not seem to get the change
2020-05-07 15:27:34 <Bridouz> And still complains about missing `double-conversion`
2020-05-07 15:28:45 <ikke> checking
2020-05-07 15:30:22 <ikke> hmm, it appears that dl-cdn.alpinelinux.org does not have it yet
2020-05-07 15:31:12 <Bridouz> Mmmh Just pushed a new CI job and it seems to build (except on X86_64)
2020-05-07 15:31:36 <ikke> It might be because 3.12 is just being uploaded
2020-05-07 15:39:10 <ncopa> build-edge-mips64:~# apk dot --errors | tpaste
2020-05-07 15:39:10 <ncopa> http://tpaste.us/5E8B
2020-05-07 15:39:49 <ikke> samba is always an issue
2020-05-07 15:41:31 <ikke> those red dotted packages, does that mean the package needs to be rebuilt?
2020-05-07 15:43:58 <ikke> https://imgur.com/a/MvDOfYv
2020-05-07 15:44:04 <ikke> excludes the samba packages
2020-05-07 15:45:16 <ncopa> i think its missing dependencies
2020-05-07 15:45:23 <ncopa> they shoudl either be disabled or rebuilt yes
2020-05-07 15:45:37 <ikke> But how were they built in the first place
2020-05-07 15:46:26 <ncopa> my guess is that at some point qt5-qtwebengine built on mips and later an update broke it and it got disabled
2020-05-07 15:46:33 <mps> Bridouz: ah, you are here, nice
2020-05-07 15:46:41 <ncopa> restuling various other build failures
2020-05-07 15:46:45 <ikke> right
2020-05-07 15:46:51 <ncopa> which led to varioius other packages disabled
2020-05-07 15:46:56 <ncopa> i think we just need to clean that up
2020-05-07 15:47:13 <ncopa>   "weechat-ruby-2.8-r0" -> "so:libruby.so.2.6" [color=red];
2020-05-07 15:47:14 <mps> Bridouz: double-conversion is in community
2020-05-07 15:47:17 <ncopa> looks like a rebuild is needed
2020-05-07 15:47:37 <mps> but you need to 'pick' other changes from APKBUILD I posted
2020-05-07 15:48:10 <mps> Bridouz: remove some patches (all?)
2020-05-07 15:48:17 <ikke> mps: not all mirrors have it yet
2020-05-07 15:48:37 <ikke> ncopa: should I add 3.12 to pkgs.a.o already btw?
2020-05-07 15:49:15 <mps> ikke: I triggered on x86_64 and it passed till applying patches, which can't apply and don't needed now
2020-05-07 15:49:38 <ikke> ?
2020-05-07 15:49:56 <mps> inkscape MR
2020-05-07 15:50:13 <mps> sorry, was not clear
2020-05-07 15:50:32 <mps> or your '?' is for ncopa
2020-05-07 15:50:41 <ikke> No, was for you
2020-05-07 15:51:04 <Bridouz> mps Yep I did that
2020-05-07 15:51:24 <mps> if I know how to push changes to Bridouz's MR I will :)
2020-05-07 15:51:48 <ikke> add their fork as a remote, fetch from it, create branch based on their branch
2020-05-07 15:51:57 <Bridouz> However ncopa said that he thinks "--disable-werror is a valid g++ flag"
2020-05-07 15:52:24 <Bridouz> And Inkscape is built ;)
2020-05-07 15:52:34 <Bridouz> Thank you all for the kind help.
2020-05-07 15:52:56 <mps> Bridouz: yes, or -Wno-error, maybe should work
2020-05-07 15:53:47 <Cogitri> I think -Wno-error is the standard way to do it
2020-05-07 15:54:35 <ncopa> may be CFLAGS and CXXFLAGS are ignored
2020-05-07 15:55:28 <mps> Bridouz: https://gitlab.alpinelinux.org/Bridouz/aports/-/jobs/111171#L378
2020-05-07 15:56:42 <ikke> cc1: error: unknown pass werror specified in '-fdisable'
2020-05-07 15:57:23 <ncopa> are those needed at all? normally -Werror not enabled by upstream
2020-05-07 15:57:39 <ncopa> upstream should not have it enabled for releases
2020-05-07 15:57:56 <mps> in this case looks like it is upstream enabled
2020-05-07 15:58:41 <ncopa> i think the proper way is to see if there is a cmake option for it and if not, make a patch that removes it
2020-05-07 15:58:53 <ncopa> grep for Werror
2020-05-07 15:59:30 <ikke> ncopa: patchwork-mysql is missing py-mysqldb, but it's not disabled for mips
2020-05-07 16:00:03 <ncopa> is some of the py-mysqldb dependencies disabled for mips?
2020-05-07 16:01:09 <ikke> ah, it's in unmaintained, that explains
2020-05-07 16:01:48 <ikke> Leo moved it because it depends on python2 I assume
2020-05-07 16:02:04 <ncopa> move patchwork-mysql too then
2020-05-07 16:02:04 <ikke> so that's not only an issue on mips
2020-05-07 16:02:07 <ikke> yeah
2020-05-07 16:02:08 <ncopa> yeah
2020-05-07 16:02:21 <ncopa> ok, i gotta go
2020-05-07 16:02:23 <ncopa> have a nice evening
2020-05-07 16:02:34 <ikke> o/
2020-05-07 16:03:05 <mps> yes, I thought to ask how to pass flags to cmake
2020-05-07 16:06:48 <mps> 'grep -r Werror' for inkscape => http://tpaste.us/vJmB
2020-05-07 16:07:49 <Bridouz> Just looked again at Gottox pattch for Void and he added
2020-05-07 16:08:04 <Bridouz> sed -e "/-Werror=format/d" \			-i CMakeScripts/DefineDependsandFlags.cmake
2020-05-07 16:08:25 <mps> heh
2020-05-07 16:08:54 <Bridouz> So patching it is ?
2020-05-07 16:09:49 <mps> we prefer patches, ofc, but sometimes for 'big' number of files 'sed' is acceptable
2020-05-07 16:21:55 <Bridouz> I think I will abandon the upgrade, I clearly do not have enough skills and knowledge to make this.
2020-05-07 16:28:51 <Bridouz> revert changes to last known working (I think)
2020-05-07 16:29:20 <Bridouz> Still `double-conversion` issue. Feel free to close my MR if you manage to build it ;)
2020-05-07 16:31:01 <mps> Bridouz: change/fix is one patch ahead
2020-05-07 16:36:56 <mps> got it built on aarch64 http://tpaste.us/QnwO
2020-05-07 16:37:18 <mps> though not sure if it works, didn't tested
2020-05-07 17:59:24 <kpcyrd> any idea what could cause `/usr/bin/lua5.2: /usr/share/lua/5.2/aports/db.lua:44: bad argument #1 to 'pairs' (table expected, got nil)`
2020-05-07 17:59:28 <kpcyrd> https://jenkins.debian.net/view/reproducible/view/Alpine/job/reproducible_alpine_scheduler/1963/console
2020-05-07 17:59:39 <kpcyrd> not sure how approach this
2020-05-07 18:02:39 <Gottox> Bridouz: quick and dirty :D
2020-05-07 18:25:07 <mps> building inkscape I got: >>> inkscape-view*: Tracing dependencies...\n>>> ERROR: inkscape-view*: libinkscape_base.so: path not found
2020-05-07 18:26:28 <mps> checking built apk with 'tar tvf packages/community/aarch64/inkscape-1.0-r0.apk | grep libinkscape_base.so' => rwxr-xr-x root/root  22670344 2020-05-07 18:03 usr/lib/inkscape/libinkscape_base.so
2020-05-07 18:27:17 <mps> is that ERROR message above serious. (first time see it and build worked)
2020-05-07 18:35:17 <Cogitri> It's probably that there's no RPATH/RUNPATH in that library
2020-05-07 18:35:59 <Cogitri> Or rather in whatever uses that library
2020-05-07 18:36:19 <Cogitri> Or actually, I guess it's because it links against the .so and not the versioned lib?
2020-05-07 18:44:13 <mps> tbh, don't understand why that happens
2020-05-07 18:44:50 <mps> I think to create MR and ask someone who understand that to look at the problem
2020-05-07 18:45:47 <Cogitri> I can take a look tomorrow
2020-05-07 18:46:21 <mps> np
2020-05-07 18:58:43 <walbon> ncopa: I cant see I can't see the latest community/stellarium build(0.20.1) on builder ppc64 on 3-12, just on edge. Did the builder stop?
2020-05-07 19:15:31 <ikke> http://dl-cdn.alpinelinux.org/alpine/edge/community/ppc64le/stellarium-0.20.1-r0.apk
2020-05-07 19:15:36 <ikke> ah
2020-05-07 19:15:56 <ikke> http://dl-cdn.alpinelinux.org/alpine/v3.12/community/ppc64le/stellarium-0.20.1-r0.apk
2020-05-07 19:17:48 <mksully22> hmm, that's odd. The 0.20.1 apk is available at the 3.12 level but the log at https://build.alpinelinux.org/buildlogs/build-3-12-ppc64le/community/stellarium/stellarium-0.19.2-r2.log is downlevel. Looks like maybe the log got lost somewhere along the way
2020-05-07 19:24:13 <ikke> mksully22: nice to see you again
2020-05-07 19:26:01 <mksully22> Thanks! good to be seen :)
2020-05-07 20:05:11 <ikke> mksully22: did you hear about the network issues we appear to have with our ci box?
2020-05-07 20:07:51 <mksully22> ikke: walbon has mentioned it to me. I know he is working with the people that should be able to help. Is it working better now?
2020-05-07 20:14:02 <ikke> I haven't heard any new occurances the last couple of days
2020-05-07 20:17:59 <mps> ikke: artifacts upload for inkscape-1.0 is staled on ppc64le
2020-05-07 20:18:18 <mps> don't know is this related
2020-05-07 20:18:44 <ikke> Most likely related, yes
2020-05-07 20:19:00 <ikke> https://gitlab.alpinelinux.org/mps/aports/-/jobs/111365
2020-05-07 20:20:21 <mps> yes, this one
2020-05-07 21:54:41 <dalias> anyone know apk well? it seems to be doing some fun schlemiel-the-painter reallocs
2020-05-07 22:01:55 <dalias> incrementing n by 24 each time
2020-05-07 22:02:15 <dalias> leading to 15% of cpu time being spent in memcpy with mallocng
2020-05-08 05:07:57 <ikke> dalias: fabled would know :)
2020-05-08 06:09:24 <ncopa> dalias: fabled knows. he is also working on apk3, with new, binary, index format, which to my understanding should reduce the needs of reallocs
2020-05-08 06:11:27 <Cogitri> dalias: I guess it might call *_array_add in a loop? That would resize the array one element each time
2020-05-08 06:12:39 <Cogitri> E.g. in apk_db_dir (although it shouldn't matter much in that case)
2020-05-08 06:44:27 <mps> inkscape is 'Heissenbuild' software (as are more and more other software also)
2020-05-08 07:05:06 <mps> ncopa: fd0923377c5694059a39a9459696451d3a1fa4ed
2020-05-08 07:05:17 <mps> but the package is in main
2020-05-08 07:09:38 <ikke> clandmeter: ^ this one needs to be fixed as well
2020-05-08 07:10:05 <clandmeter> ah :)
2020-05-08 07:10:15 <mps> ncopa: why didn't you applied !7409
2020-05-08 07:18:02 <fcolista2> uff..i fixed the patch on gns3-server...should I bump the pkgrel?
2020-05-08 07:19:02 <ikke> no, but if the builders were still busy, they missed the new commit
2020-05-08 07:19:35 <fcolista2> thx ikke for retry master
2020-05-08 07:20:35 <PureTryOut[m]> ikke: please merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7662 to fix 2 packages blocking the builders
2020-05-08 07:21:58 <ikke> Will be merged once the pipeline succeeds
2020-05-08 07:22:32 <ikke> Do you have any clue why the abort happens on armhf?
2020-05-08 07:22:38 <PureTryOut[m]> Nope 🤷‍♂️
2020-05-08 07:22:57 <PureTryOut[m]> https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/py3-scikit-optimize/py3-scikit-optimize-0.7.4-r0.log
2020-05-08 07:23:03 <PureTryOut[m]> It's a weird one
2020-05-08 07:23:23 <PureTryOut[m]> I see no errors whatsoever
2020-05-08 07:23:30 <PureTryOut[m]> But like mentioned in the MR, I have no interest in fixing it tbh
2020-05-08 07:23:31 <ikke> Yes, I've seen it
2020-05-08 08:19:30 <ncopa> mps: i thikn it was an old commit that i had in my tree that never got pushed in 29 april. my guess is that librtlsdr moved to main after my commit but before my push and i didnt notice
2020-05-08 08:20:36 <ncopa> mps: i must have forgotten !7409 or wasnt aware of it
2020-05-08 08:36:13 <mps> ncopa: np, I will rebase and made new one
2020-05-08 08:36:45 <mps> just thought you have objections or something is wring with it
2020-05-08 09:16:24 <mps> ncopa: I rebased (by hand :) ) !7409 when you find time please review and (optionally) merge
2020-05-08 09:48:35 <maxwell-k> good morning, for a new version of a package in main, if a new makedepends is in community is it
2020-05-08 09:48:38 <maxwell-k> better to move both packages to main or community?
2020-05-08 09:49:12 <maxice8> depends on the package but i prefer to always move to community unless absolutely necessary
2020-05-08 09:49:17 <maxwell-k> my guess is community, but I'm not sure, examples are duplicity and py3-setuptools
2020-05-08 09:49:33 <maxwell-k> maxice8: ty, will try community
2020-05-08 11:07:41 <mps> was it good idea to move duplicity from main to community?
2020-05-08 11:07:56 <mps> maxice8: maybe candidate for your release notes
2020-05-08 11:08:13 <maxice8> i'm playing rs3, can you edit the wiki page for it ?
2020-05-08 11:08:40 <mps> if I understand wiki syntax I would, sorry
2020-05-08 11:08:58 <mps> maybe someone else?
2020-05-08 11:08:59 <maxice8> it is pretty simple and should be self-explained once you click edit
2020-05-08 11:09:31 <mps> huh, will try, but don't blame me if I made something wrong
2020-05-08 11:16:27 <ikke> there is even a preview option
2020-05-08 11:24:49 <mps> except I can't find it :(
2020-05-08 11:25:16 <mps> no TOC on wiki
2020-05-08 11:25:29 <maxwell-k> I can't find it either, anyone got a link please?
2020-05-08 11:30:03 <ikke> There was one for 3.11, but I don't see a new one for 3.12
2020-05-08 11:30:17 <ikke> ah
2020-05-08 11:30:18 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0
2020-05-08 11:32:43 <mps> ikke: thanks
2020-05-08 12:02:53 <Cogitri> z3untu: openrc-settingsd upstream is dead, right?
2020-05-08 12:03:19 <Cogitri> If so, how about we patch things into shape for timedatectl to work on Alpine and we make a new release then?
2020-05-08 12:03:44 <Cogitri> Also, since I don't know SourceHut: Can I make issues/send patches without email?...
2020-05-08 13:10:28 <maxwell-k> I noticed that the logs at https://dev.alpinelinux.org/irclogs/ stopped on Tuesday, they were handy when I'd an unreliably internet connection
2020-05-08 13:11:08 <ikke> clandmeter: ^
2020-05-08 13:11:35 <ikke> We switched the bot that did those logs to new infra, but it should still be logging
2020-05-08 13:11:37 <clandmeter> ikke: can you redirect it to new location?
2020-05-08 13:11:48 <ikke> irclogs, right?
2020-05-08 13:11:55 <clandmeter> yes sir
2020-05-08 13:12:13 <clandmeter> maxwell-k: irclogs.a.o
2020-05-08 13:12:19 <clandmeter> same thing new name
2020-05-08 13:12:38 <oneinsect> please backup the old logs are also
2020-05-08 13:12:41 <oneinsect> dont delete them
2020-05-08 13:13:08 <clandmeter> oneinsect: did you check before you asked? :p
2020-05-08 13:13:10 <ikke> they are still there
2020-05-08 13:13:22 <ikke> The url just changed
2020-05-08 13:13:55 <oneinsect> lol no
2020-05-08 13:17:06 <ikke> done
2020-05-08 13:20:15 <ikke> Hmm, the # in the filenames cause issues though
2020-05-08 13:20:24 <ikke> the redirect seems to unencode them
2020-05-08 13:20:33 <ikke> curl -I https://dev.alpinelinux.org/irclogs/%23alpine-commits-2015-06.log
2020-05-08 13:20:40 <ikke> location: https://irclogs.alpinelinux.org/#alpine-commits-2015-06.log
2020-05-08 13:45:45 <Hello71> heh
2020-05-08 13:57:14 <maxwell-k> clandmeter, ikke: I like the new location and the redirect works well for me, thank you
2020-05-08 13:57:46 <clandmeter> ikke: i think we only need redir base path
2020-05-08 14:05:41 <maxwell-k> anyone any ideas of a guideline for how long is too long for a package's test suite to run?
2020-05-08 14:06:13 <mps> irclogs.a.o
2020-05-08 14:06:24 <mps> algitbot: ^
2020-05-08 14:06:40 <ikke> it just expends some predefined shortcuts
2020-05-08 16:05:02 <mcrute> hi all, I've got some free time on my hands and would like to help work through the backlog of merge request reviews and tickets, what's the most effective way to do that? I've contributed off and on for a few years but am not a dev team member (yet)
2020-05-08 16:06:37 <Cogitri> Hm, well, you can comment on MRs too, but I think we're currently not short on review force, but on people with access to the main repos that merge stuff because those are busy with 3.12
2020-05-08 16:06:51 <Cogitri> You can go through old issues and ping me to close ones which don't apply anymore
2020-05-08 16:07:26 <Cogitri> I've gone through pages 28-18 already, so if you want to you can start going through each issue starting at https://gitlab.alpinelinux.org/alpine/aports/-/issues?page=18&state=opened
2020-05-08 16:07:52 <mcrute> Is there a process to become a developer with commit access?
2020-05-08 16:08:40 <Cogitri> I think right now the process is do consistently good work and eventually you'll get approached
2020-05-08 16:09:33 <Cogitri> But it takes some time to get to that :)
2020-05-08 16:09:48 <mcrute> I don't mind putting in the work and I've got the time :-)
2020-05-08 16:10:07 <mcrute> I'll start digging through issues and see about retiring some new aport requests
2020-05-08 16:10:54 <Cogitri> Hm, I think most of the aport requests still apply
2020-05-08 16:11:23 <Cogitri> I mostly just close issues that don't apply anymore (e.g. fixed in the meantime by a package upgrade but the issue wasn't closed)
2020-05-08 16:12:04 <mcrute> oh by "retire" I meant actually package the software
2020-05-08 16:12:11 <Cogitri> Ah, good
2020-05-08 16:12:31 <mcrute> the best way to close them is to complete them, eh?
2020-05-08 16:12:59 <Cogitri> Yup
2020-05-08 16:40:54 <maxwell-k> mcrute: are you behind the AMIs? if so I go to use one the first time a week or so back, very much appreciate your work!
2020-05-08 16:49:37 <mcrute> maxwell-k: yeah I've been working on them with another contributor, thanks!
2020-05-08 16:49:57 <mcrute> I'd like to get them in the hands of alpine and on the official release schedule, actually
2020-05-08 16:50:39 <mcrute> Cogitri: this can be closed... it's an issue with the 1.x bird series that we no longer ship... https://gitlab.alpinelinux.org/alpine/aports/-/issues/8600
2020-05-08 16:51:26 <Cogitri> Done, thanks
2020-05-08 17:31:45 <Danct12[m]> is there any thing i can do with FP_INT_*?
2020-05-08 17:32:19 <Cogitri> What?
2020-05-08 17:32:23 <Danct12[m]> the problem is that this only exists as a macros for glibc, and we don't have that on musl
2020-05-08 17:32:58 <Cogitri> Ah
2020-05-08 17:33:10 <dalias> what is FP_INT_* ?
2020-05-08 17:34:21 <Danct12[m]> macros for rounding functions on glibc
2020-05-08 19:12:13 <mps> how it is supposed 'apk version -t' to work? with pkgname-version or just versions
2020-05-08 19:12:37 <mps> 'apk version -t vboot-utils-6310032 vboot-utils-R81-12871.B' gives '='
2020-05-08 19:13:27 <ikke> just the versions
2020-05-08 19:13:33 <ikke> no package nmaes
2020-05-08 19:13:35 <ikke> names
2020-05-08 19:14:20 <ikke> apk version -t 6310032 R81-12871.B
2020-05-08 19:14:21 <mps> 'apk version -t 6310032-r2 R81-12871.B-r0' gives '>', which is newer?
2020-05-08 19:14:23 <ikke> >
2020-05-08 19:14:28 <ikke> the former
2020-05-08 19:14:35 <ikke> arg1 > arg2
2020-05-08 19:15:16 <mps> uhm, so I introduced mess when created aport
2020-05-08 19:16:35 <mps> will put it on todo list after 3.12 release
2020-05-08 19:41:35 <mps> what pkg is needed to fix this 'ake[2]: *** No rule to make target 'po/ko.gmo', needed by 'share/templates/default_templates.timestamp'.  Stop.'
2020-05-08 19:41:50 <mps> 'make*
2020-05-08 19:41:58 <mps> wrong cut-n-paste
2020-05-08 19:42:05 <Cogitri> I suppose gettext
2020-05-08 19:42:12 <Cogitri> But I guess it's just yet another instance of broken autotools
2020-05-08 19:42:47 <mps> hmm, could be, it failed on x86_64 but works on aarch64, and cmake not autotools
2020-05-08 19:43:34 <Cogitri> Ah, broken CMake then I guess
2020-05-08 19:43:46 <Cogitri> Try with -j1, maybe it can't deal with too many concurrent build jobs
2020-05-08 19:44:25 <mps> ah, didn't know, will try. thanks
2020-05-08 19:45:00 <mps> it is inkscape 1.0
2020-05-09 10:31:20 <mps> latest mupdf upgrade broke zathura-pdf-mupdf, /libmupdfthird.so.0 renamed libmupdf-third.so.0 without notice. anyone know why
2020-05-09 10:38:52 <mps> !7659 failed on aarch64 CI, timeout
2020-05-09 10:39:49 <mps> I changed make to -j1, that way it builds on all arches
2020-05-09 11:20:32 <mps> actually mupdf-dev is broken, usr/lib/libmupdfthird.so -> libmupdfthird.so.0 and libmupdfthird.so.0 should be libmupdf-third.so.0
2020-05-09 11:38:10 <mps> https://www.freetype.org/ release 2.10.2 with woff fonts support
2020-05-09 11:41:04 <mps> WOFF 2
2020-05-09 11:57:57 <maxice8> @mps sorry, didn't realize the soname changed, when i look at the diff i saw it was to match the static library.
2020-05-09 11:58:33 <mps> maxice8: np, errors happens, I'm working on fix
2020-05-09 12:21:34 <mps> maxice8: !7712 it is simple change, but to ask you, does it looks ok?
2020-05-09 12:22:09 <maxice8> also need to rebuild stuff that depend on the old name
2020-05-09 12:22:23 <maxice8> apk list --exact --depends so:libmupdfthird.so.0
2020-05-09 12:24:12 <mps> I think only zathura-pdf-mupdf
2020-05-09 12:29:35 <mps> hmm, mupdf 1.17.0 changed some APIs, so zathura-pdf-mupdf will need some more source patches
2020-05-09 12:35:47 <Ganwell> mps: there is zathura poppler....
2020-05-09 12:38:02 <mps> Ganwell: I think it doesn't use libmupdf-third
2020-05-09 12:39:09 <Ganwell> mps: yes, so it is not broken and you can use zathura to view pdfs with it
2020-05-09 12:40:07 <mps> yes, I know. but prefer zathura with mupdf
2020-05-09 12:40:56 <mps> I rebuilt already all pkgs which depends on mupdf, all is ok except zathura-pdf-mupdf
2020-05-09 12:41:23 <mps> will look later on API change and try to fix also it
2020-05-09 12:41:25 <Ganwell> mps: is there any difference?
2020-05-09 12:42:38 <mps> need to fix fz_resolve_link func in zathura-pdf-mupdf
2020-05-09 12:42:49 <Ganwell> I stopped when I had pdf view working, I am lazy 😃
2020-05-09 12:43:00 <mps> but I'm out of home right now, will look later
2020-05-09 17:46:48 <oneinsect> guys why is the isl package so old?
2020-05-09 17:46:57 <oneinsect> why wasnt it updated?
2020-05-09 17:47:14 <oneinsect> https://git.alpinelinux.org/aports/tree/main/isl/APKBUILD
2020-05-09 17:47:21 <oneinsect> pkgver=0.18
2020-05-09 17:47:34 <oneinsect> current isl is 	isl-0.22
2020-05-09 17:47:41 <oneinsect> this is for gcc
2020-05-09 17:49:02 <ikke> 1) newer package might introduce breakage. 2) the maintainer was not aware of a newer version.
2020-05-09 17:49:10 <oneinsect> hmmm
2020-05-09 17:49:32 <oneinsect> just tested newer package and it works very well
2020-05-09 17:49:37 <oneinsect> better than 0.18
2020-05-09 17:51:01 <mps> nice, inkscape 1.0 actually works, tested on armv7 edge
2020-05-09 17:51:48 <mps> is it ok to merge it with 'make -j1 ...'
2020-05-09 17:57:48 <ikke> d'ph
2020-05-09 17:57:50 <ikke> 'dohg
2020-05-09 17:57:57 <Cogitri> Sure, doesn't take that long anyway from what I can see, mps
2020-05-09 17:58:08 <Cogitri> But does it still throw that error about the lib it can't find?
2020-05-09 17:58:32 <dalias> oneinsect, in what way did you measure better?
2020-05-09 17:59:03 <oneinsect> hmm 0.18 was throwing in some error during bootstrapping
2020-05-09 17:59:07 <oneinsect> 0.22 went through
2020-05-09 17:59:16 <oneinsect> may be i could be doing something wrong
2020-05-09 17:59:30 <oneinsect> i honestly did not have enough information
2020-05-09 17:59:36 <dalias> well "builds better" and "works better at runtime" are very different things
2020-05-09 17:59:48 <dalias> i suspect the latter is true but the reason you have maintainers is to verify that
2020-05-09 17:59:51 <oneinsect> oooh my bad
2020-05-09 18:00:02 <oneinsect> it builds better
2020-05-09 18:00:04 <oneinsect> :D
2020-05-09 18:00:06 <oneinsect> sorry
2020-05-09 18:00:45 <mps> Cogitri: it takes more than 2 hours on aarch64 CI and fail because of timeout
2020-05-09 18:00:55 <oneinsect> i did not mean to offend the work of maintainers
2020-05-09 18:01:05 <oneinsect> i was just putting in an observation
2020-05-09 18:01:09 <mps> and, yes, still have error but builds fine and works fine
2020-05-09 18:02:11 <Cogitri> mps: Huh, I think it built within 5 or 10 minutes on my 3950X, but that was with -j28
2020-05-09 18:02:13 <mps> Cogitri: you can look at build jobs log
2020-05-09 18:02:28 <Cogitri> Didn't expect it to take that long on aarch64, sorry
2020-05-09 18:02:45 <ikke> nmeum: your last commit to rippled accidentaly enabled the tests again
2020-05-09 18:02:50 <Cogitri> Hum, I can take a look at the issue tomorrow, if that's OK for you
2020-05-09 18:02:53 <ikke> ad8c569f6d988607a7d488fe516a96de2866f3aa
2020-05-09 18:03:49 <mps> Cogitri: it could be 'fixed' by: case aarch64) make -jX, but not sure is that ok
2020-05-09 18:05:09 <Cogitri> I don't see what's not OK about that
2020-05-09 18:05:14 <Cogitri> I mean it's not optimal, sure
2020-05-09 18:05:37 <Cogitri> But if you push that at a not so busy time it should be fine
2020-05-09 20:03:35 <mps> we don't curlpp (http://www.curlpp.org/) or I can't find it
2020-05-09 20:03:37 <mps> ?
2020-05-09 20:04:31 <ikke> I don't think so
2020-05-09 20:04:46 <ikke> https://repology.org/project/curlpp/versions
2020-05-09 20:05:02 <mps> is worth to add it?
2020-05-09 20:06:43 <ikke> Not sure if there is nothing using it
2020-05-09 20:08:08 <mps> I'm building local pkg which need it, https://github.com/djt3/tuitube/ TUI for youtube
2020-05-09 20:09:08 <ikke> then sure
2020-05-09 20:09:18 <ikke> If you need it, it's necessary :)
2020-05-09 20:09:25 <ikke> Welcome to tautoly club :)
2020-05-09 20:10:05 <mps> :)
2020-05-09 20:15:25 <ikke> Which obviously is not a spelling club ::D
2020-05-09 20:15:46 <mps> ;)
2020-05-09 20:17:51 <mps> good, got it both working. now have TUI youtube browser with mpv as player
2020-05-09 20:20:15 <ikke> nice
2020-05-09 20:22:01 <mps> thanks, and thanks for advises
2020-05-09 20:22:50 <mps> if anyone need it I can push/merge these
2020-05-09 20:23:14 <ikke> I would say just do it :)
2020-05-09 20:24:11 <mps> heh, we have saying 'it is not hard to force frog to jump to water' :)
2020-05-09 20:24:27 <ikke> haha, nice one
2020-05-09 20:24:58 <mps> but, before push have to check licenses
2020-05-09 20:27:24 <ikke> yes, that's not a bad idea
2020-05-09 20:51:38 <mps> hmm, MP:[AL32]:APKBUILD:26:unnecesary usage of braces: ${CMAKE_CROSSOPTS}
2020-05-10 00:14:16 <hicham> Hello all
2020-05-10 00:14:28 <hicham> is there any online build system for alpine ?
2020-05-10 00:14:33 <hicham> like opensuse obs ?
2020-05-10 05:49:34 <oneinsect> friends
2020-05-10 05:49:44 <oneinsect> does compiling expat throw any error?
2020-05-10 05:49:47 <oneinsect> checking build system type... Invalid configuration `x86_64-alpine-linux-gcc': machine `x86_64-alpine-linux' not recognized
2020-05-10 05:51:20 <oneinsect> and the irc logs are missing i mean i cannot find alpine-devel-2015-05.log
2020-05-10 05:51:27 <oneinsect> https://irclogs.alpinelinux.org/#alpine-devel-2015-05.log
2020-05-10 05:51:41 <oneinsect> google cache has it
2020-05-10 05:51:42 <oneinsect> https://webcache.googleusercontent.com/search?q=cache:iSFRrRRjE68J:https://dev.alpinelinux.org/irclogs/%2523alpine-devel-2015-05.log+&cd=3&hl=en&ct=clnk&gl=in
2020-05-10 06:25:24 <Cogitri> oneinsect: run `update_config_guess` in prepare, then it should work
2020-05-10 06:25:39 <oneinsect> let me try Cogitri:
2020-05-10 06:26:33 <oneinsect> there is no prepare overide
2020-05-10 06:26:42 <oneinsect> let me overide prepare then
2020-05-10 06:28:58 <ikke> oneinsect: https://irclogs.alpinelinux.org/%23alpine-devel-2015-05.log
2020-05-10 06:29:04 <ikke> The issue is the #
2020-05-10 06:29:05 <oneinsect> the build fails when i overide the prepare () { update_config_guess }
2020-05-10 06:29:21 <ikke> oneinsect: don't forget to add default_prepare
2020-05-10 06:29:30 <ikke> otherwise patches are not being applied
2020-05-10 06:29:31 <oneinsect> wait let me add default_prepare
2020-05-10 06:29:39 <oneinsect> there are no patches for expat
2020-05-10 06:29:42 <ikke> ok
2020-05-10 06:29:45 <oneinsect> its supposed to be a simple make
2020-05-10 06:30:30 <oneinsect> ERROR: expat: prepare failed
2020-05-10 06:31:22 <oneinsect> before the error it says expat: No update needed for ./conftools/config.guess
2020-05-10 06:31:29 <oneinsect> any more ideas?
2020-05-10 06:32:49 <Cogitri> Huh, was it update_config_sub then?
2020-05-10 06:32:54 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/expat/APKBUILD
2020-05-10 06:34:52 <oneinsect> if i remove the CBUILD and CHOST options from configure it works (ofcourse without the update_config_guess)
2020-05-10 06:35:20 <oneinsect> it still fails if i just overide the prepare without actually removing CBUILD and CHOST options
2020-05-10 06:36:18 <oneinsect> and yes update_config_sub also fails
2020-05-10 06:38:49 <oneinsect> why arent configuration `x86_64-alpine-linux-gcc': machine `x86_64-alpine-linux' recognized by the configure of expat
2020-05-10 06:40:16 <Cogitri> I think autotools has a hardcoded list of triplets it accepts for some reason
2020-05-10 06:40:25 <oneinsect> may be the https://fossies.org/linux/expat/conftools/config.sub throws the error?
2020-05-10 06:40:37 <oneinsect> oooh the autotools
2020-05-10 06:40:40 <Cogitri> Maybe just try autoreconf -fi to just force regenerate all autotools scripts
2020-05-10 06:42:53 <oneinsect> holy moly
2020-05-10 06:42:54 <oneinsect> autoreconf -f -i
2020-05-10 06:42:58 <oneinsect> made it to work
2020-05-10 06:43:07 <Cogitri> 👍
2020-05-10 06:43:07 <oneinsect> thanks Cogitri:
2020-05-10 07:17:49 <artok> quick fix for config guess replacement: shell script that does: echo "$(gcc -dumpmachine)"
2020-05-10 07:17:54 <artok> =)
2020-05-10 07:24:01 <ikke> lol
2020-05-10 07:24:17 <Cogitri> The proper fix is to port to meson :P
2020-05-10 08:07:24 <artok> oh god.. meson again
2020-05-10 08:07:25 <artok> =D
2020-05-10 08:08:55 <artok> if meson has simple, as good as CMAKE_TOOLCHAIN_FILE setting for cross compiling, I could change my project to work with meson..
2020-05-10 08:10:23 <oneinsect> but isnt meson dead?
2020-05-10 08:11:38 <Cogitri> It's as alive as ever
2020-05-10 08:11:39 <Cogitri> artok:  https://github.com/mesonbuild/meson/blob/master/docs/markdown/Cross-compilation.md there you go
2020-05-10 08:14:00 <artok> ok
2020-05-10 08:14:01 <artok> =D
2020-05-10 08:14:48 <artok> my project needs to be built on x86_64, run on aarch64 and avr
2020-05-10 08:16:10 <mps> artok: for my personal 'thing' Makefile is all I need
2020-05-10 08:16:16 <Cogitri> See https://github.com/void-linux/void-packages/blob/master/common/build-style/meson.sh#L43 for Void's cross file
2020-05-10 08:16:44 <AinNero> artok: mps: im also using AVR with Makefile
2020-05-10 08:17:48 <Cogitri> Hm, Makefiles tend to get too complex for decently sized codebases
2020-05-10 08:18:00 <Cogitri> And it's so easy to mess things up with it, it's not nice how many packages need -j1
2020-05-10 08:18:11 <Cogitri> But at least it's better to use bare make than autotools
2020-05-10 08:18:27 <Cogitri> (If you still find a way to offer configurability)
2020-05-10 08:20:45 <mps> I don't know for meson/cmake and other tools, but with Makefile I can have a lot of automation, not only build software
2020-05-10 08:21:15 <AinNero> 
ACTION built their bachelor thesis with a makefile

2020-05-10 08:21:39 <mps> nice :)
2020-05-10 08:27:03 <SerkanDevel[m]1> I can't find any documentation or config for darkhttpd-openrc . Should there be a file of darkhttpd in /etc/conf.d/ after installed
2020-05-10 08:27:08 <SerkanDevel[m]1> ?
2020-05-10 08:27:37 <ikke> https://pkgs.alpinelinux.org/contents?branch=edge&name=darkhttpd-openrc&arch=x86_64&repo=main
2020-05-10 08:28:57 <ikke> there is no conf.d file as you can see
2020-05-10 08:29:40 <SerkanDevel[m]1> Thanks for the hint
2020-05-10 08:30:46 <ikke> But I think you can create one yourself to override defaults
2020-05-10 08:31:06 <ikke> document_root and darkhttpd_args
2020-05-10 08:31:18 <SerkanDevel[m]1> Do I just write the port number in the config where it says, $port?
2020-05-10 08:32:12 <ikke> add port=<port> in /etc/conf.d/darkhttpd
2020-05-10 08:33:23 <mps> I thought to add darkhttpd.confd but forgot :/
2020-05-10 09:41:17 <Bridouz> o/
2020-05-10 11:00:24 <mps> SerkanDevel[m]1: ikke: !7757
2020-05-10 11:20:25 <nmeum> should I push !7719 to fix the vkd3d build on the armv7 builder? don't actually use vkd3d and don't have an armv7 alpine device but seems to pass on the CI
2020-05-10 11:21:19 <nmeum> strange that it only fails on armv7 though
2020-05-10 11:22:01 <ikke> mps: merged
2020-05-10 11:22:51 <ikke> maxice8: ^
2020-05-10 11:23:01 <maxice8> yes ?
2020-05-10 11:24:03 <ikke> You are the maintainer of vkd3d
2020-05-10 11:24:26 <maxice8> ah
2020-05-10 11:24:47 <maxice8> i should drop myself from it, i did it for vulkan on Wine but i don't even use wine anymore
2020-05-10 11:30:08 <mps> ikke: thanks
2020-05-10 11:31:52 <ikke> mps: do you happen to have the time / opportunity to test vk3d?
2020-05-10 11:33:20 <mps> in a three hours from now I will look
2020-05-10 11:33:37 <mps> now I'm again out of home
2020-05-10 11:33:43 <ikke> no worry
2020-05-10 11:34:12 <mps> oh, it fail on 3.12
2020-05-10 14:04:44 <mps> ikke: I tested vk3d build on armv7, edge. it works
2020-05-10 14:05:11 <ikke> thanks
2020-05-10 14:05:14 <mps> problem is something is different on 3.12, probably
2020-05-10 14:07:11 <mps> I could try !7719 patch?
2020-05-10 14:07:35 <mps> but not sure will that help to solve problem on 3.12
2020-05-10 16:35:36 <nmeum> mps: why should it not help with the build problem on 3.12?
2020-05-10 16:39:54 <mps> nmeum: yes, you are right. I should say 'maybe' instead of
2020-05-10 16:40:45 <mps> lets try
2020-05-10 16:41:34 <mps> it build again with your patch 7719
2020-05-10 16:41:46 <mps> on edge
2020-05-10 16:42:28 <nmeum> but there shouldn't be any difference between 3.12 and edge at this point as we don't have a 3.12 branch yet
2020-05-10 16:42:37 <ikke> correct
2020-05-10 16:42:58 <mps> maybe some setup on 3.12 builder is different
2020-05-10 16:43:44 <nmeum> does vk3d build for you without the patch?
2020-05-10 16:44:32 <mps> nmeum: yes
2020-05-10 16:44:44 <nmeum> ah!
2020-05-10 16:44:46 <nmeum> that is strange indeed then
2020-05-10 16:44:50 <mps> without patch and with patch, both case
2020-05-10 16:45:55 <nmeum> also strange that it build succesfully on all other arches as the errornous code shouldn't be architecture-specific
2020-05-10 16:49:33 <mps> builders are not busy, maybe I should merge inkscape 1.0 now?
2020-05-10 16:50:56 <ikke> fine with me
2020-05-10 16:51:16 <nmeum> we actually have two inkscape 1.0 prs :)
2020-05-10 16:51:35 <nmeum> but I don't mind upgrading it
2020-05-10 17:08:18 <mps> nmeum: author of !7540 gave up after few unsuccessful try on CI
2020-05-10 17:19:10 <mps> ok, merged. lets pray
2020-05-10 21:17:51 <nmeum> hm
2020-05-10 21:18:08 <nmeum> is it possible that the 3.12 armhf builder is still using vulkan-headers 1.2.140?
2020-05-10 21:18:43 <Cogitri> Possibly, maybe a <1.2.139 dep there too
2020-05-10 21:21:04 <nmeum> I am just currently trying to debug the vkd3d build failure, fails due to an undefined macro. that macro was removed with vulkan-headers 1.2.140 but should be present in vulkan-headers 1.2.139
2020-05-10 21:21:30 <nmeum> since the downgrade didn't bump the pkgrel it might be possible that the old version is still installed on the armhf builder? at least that would explain the build failure
2020-05-10 21:22:01 <nmeum> https://build.alpinelinux.org/buildlogs/build-3-12-armv7/community/vkd3d/vkd3d-1.1-r0.log
2020-05-10 21:22:07 <nmeum> > (1/21) Installing vulkan-headers (1.2.140-r0)
2020-05-10 21:22:19 <nmeum> I guess that's really the issue then
2020-05-10 21:23:05 <Cogitri> Yup
2020-05-10 21:23:15 <Cogitri> I don't think bumping pkgrel is relevant?
2020-05-10 21:23:16 <nmeum> will bump the pkgrel
2020-05-10 21:23:40 <nmeum> why?
2020-05-10 21:24:11 <nmeum> if the pkgrel is not bumped the downgrade should only be installed when one runs apk upgrade -a
2020-05-10 21:24:56 <nmeum> I will just bump the pkgrel the package compiles in seconds and if it doesn't work we can still figure out why the old version is still being installed afterwards ':)
2020-05-10 21:25:02 <ix> because 1.2.139 will still be less than 1.2.140, no matter the pkgrel
2020-05-10 21:25:35 <ix> the new version needs to be purged
2020-05-10 21:26:15 <nmeum> hm
2020-05-10 21:27:51 <nmeum> ikke: you around?
2020-05-10 21:29:05 <Cogitri> nmeum: But vulkan-headers is always removed
2020-05-10 21:29:16 <nmeum> hm?
2020-05-10 21:29:56 <Cogitri> I mean the builders purge build deps, so it shouldn't matter
2020-05-10 21:30:33 <Cogitri> And 2.1.140 should be removed from the repos once 2.1.149 has been built
2020-05-10 21:30:50 <nmeum> yeah
2020-05-10 21:30:52 <Cogitri> So a <2.1.140 on one of the deps its currently trying to build should cause the old vulkan-headers to be built
2020-05-10 21:30:59 <nmeum> I also don't see 2.1.39 on the mirrors anymore
2020-05-10 21:32:19 <Cogitri> At least on x86_64 the revert seems to worked with a <2.1.140 dep on metacity
2020-05-10 21:32:37 <nmeum> we can add an explicit version dependency to vkd3d for now
2020-05-10 21:32:40 <nmeum> that should also work
2020-05-10 21:32:54 <Cogitri> Yup
2020-05-10 21:33:02 <Cogitri> That's what I meant to suggest :)
2020-05-10 21:33:09 <nmeum> would you mind if I try the pkgrel bump first anyhow?
2020-05-10 21:34:09 <Cogitri> Go ahead, but I don't see how it'd change anything
2020-05-10 21:34:29 <Cogitri> But bumping pkgrel won't hurt and vulkan-headers is quick to build, I suppose
2020-05-10 21:34:49 <nmeum> c283fabf17fd7dc65dacdf3a1b3c4faadb6ac5d8
2020-05-10 21:34:54 <nmeum> let's try that first ':)
2020-05-10 21:35:10 <Cogitri> 👍
2020-05-10 21:35:22 <Cogitri> Unfortunate that they removed such a widely used definition in a point release
2020-05-10 21:35:35 <Cogitri> Broke gtk4, metacity, vkd3d and probably more Vulkan stuff
2020-05-10 21:35:55 <nmeum> strange indeed
2020-05-10 21:36:06 <nmeum> meh, the armhf builder is still busy building z3
2020-05-10 21:37:05 <Cogitri> But looking at how many ifdef's GTK4 has for Vulkan it really doesn't look that much fun to build against vulkan things
2020-05-10 21:38:27 <tehcloud> Vulkan is a little crazy, and a really fast moving target
2020-05-10 21:38:33 <tehcloud> my stuff breaks every revision in subtle ways
2020-05-10 21:39:02 <tehcloud> maybe in a few more years it will be more predictable
2020-05-10 21:39:23 <Cogitri> Let's hope so
2020-05-10 21:39:44 <Cogitri> Anyway, we'll have to be careful on vulkan-headers upgrades in the future, I've added a note to the APKBUILD
2020-05-10 22:17:16 <gjabell> Can someone trigger a rebuild for racket? Looks like it still wants libffi.so.6
2020-05-11 01:39:57 <hicham> Hello
2020-05-11 01:40:24 <hicham> can apk query locally downloaded packages ( not from a repo ) ?
2020-05-11 01:43:46 <Hello71> you already asked this in #alpine-linux and I didn't answer because your question is vague
2020-05-11 01:43:58 <Hello71> but in general the answer is yes
2020-05-11 06:29:08 <maxwell-k> Cogitri: just on the offchance, are you around for a question about your nit on !7699 ?
2020-05-11 06:29:21 <Cogitri> Sure
2020-05-11 06:33:49 <maxwell-k> thanks, I just commmented explaining the makedepends, was worried I was missing something
2020-05-11 06:34:26 <maxwell-k> the package will build with "", "py3-pip" or "py3-pip py3-wheel"
2020-05-11 06:35:11 <maxwell-k> I like "py3-pip py3-wheel" because it gives the least warnings, but maybe you / the project more widely have different preferences?
2020-05-11 06:37:06 <maxwell-k> thank you, that's a version with py3-pip only pushed :)
2020-05-11 06:43:32 <Cogitri> Thanks :)
2020-05-11 08:48:18 <nmeum> mps: can you reproduce the armhf gitea build failure on your hardware? I might have a fix (it passes on the armhf CI) not sure though if it failed on the CI previously !7791
2020-05-11 09:42:29 <nmeum> gjabell: just merged the 7.7 upgrade for racket, that should fix your libffi issue
2020-05-11 10:21:50 <nmeum> Cogitri: shouldn't gcr depend on dbus-x11? currently trying to setup pinentry-gnome3 and without dbus-x11 I get: gnome3.gcr_system_prompt_open 83886195 8: Failed to execute child process “dbus-launch”
2020-05-11 10:22:05 <nmeum> currently trying to figure out whether I should add dbus-x11 as a dependency to pinentry-gnome3 or gcr
2020-05-11 10:22:50 <Cogitri> Hum, pinentry things worked for me on GNOME Wayland even before I added the dbus-x11 dep on the gnome metapackage
2020-05-11 10:23:17 <nmeum> maybe because you had it installed beforehand anyhow?
2020-05-11 10:24:28 <nmeum> also: pinentry-gnome3 is definitly missing a dependency on gcr for the org.gnome.keyring.SystemPrompter service, will add that but currently trying to sort this dbus thing out first
2020-05-11 10:25:17 <Cogitri> Hm, I think dbus-launch isn't required by gcr, I don't see it mentioned anywhere
2020-05-11 10:26:09 <Cogitri> And not in pinentry either, I think that's dbus trying to start it for you
2020-05-11 10:26:28 <nmeum> trying to start what for me?
2020-05-11 10:26:40 <Cogitri> The gcr service
2020-05-11 10:27:14 <nmeum> can I start it without dbus?
2020-05-11 10:27:32 <Cogitri> You could manually start the gcr service, it should recognise that it already runs then
2020-05-11 10:27:58 <nmeum> how do I do that?
2020-05-11 10:28:43 <Cogitri> `/usr/libexec/gcr-prompter`
2020-05-11 10:28:49 <Cogitri> But this should be fixed properly
2020-05-11 10:29:12 <Cogitri> I'll look into it in a bit
2020-05-11 10:29:24 <nmeum> > (gcr-prompter:22336): Gcr-WARNING **: 12:29:18.132: couldn't connect to session bus
2020-05-11 10:29:47 <nmeum> ok, I will only add the gcr dependency to pinentry-gnome3 in the meantime then
2020-05-11 10:29:52 <Cogitri> About the missing gcr dep for pinentry-gnome: Somehow I thought apk detects that already
2020-05-11 10:30:11 <Cogitri> Hum, no session bus?
2020-05-11 10:30:12 <Cogitri> I guess that's why it uses dbus-launch
2020-05-11 10:30:37 <PureTryOut[m]> I currently have a package somewhere in the package tree pulling in some specific version of a dep, but I need a newer version of that dep (and it is available). How can I find out which package is pulling that specific version in?
2020-05-11 10:31:37 <nmeum> it Cogitri: apk only detects the gcr-base dependency as that package ships libgcr-base-3.so which pinentry needs, but it also needs gcr itself for the service file
2020-05-11 10:31:53 <Cogitri> Ah, right
2020-05-11 10:31:57 <nmeum> since the service file and libgcr-base-3.so are not shipped by the same package it's not autodetected
2020-05-11 10:34:06 <nmeum> regarding the session bus: I don't know how this gnome3 stuff works, can I get a session bus without using dbus because I would prefer using pinentry-gnome3 without dbus
2020-05-11 10:34:54 <Cogitri> No, session bus == dbus bus that's running for your user
2020-05-11 10:35:01 <Cogitri> So no, you can't use it without DBus
2020-05-11 10:35:09 <nmeum> /
2020-05-11 10:35:20 <nmeum> I guess I will just stick to the gtk2 version then ':)
2020-05-11 10:35:58 <nmeum> added the gcr dependency to pinentry-gnome
2020-05-11 10:40:08 <Cogitri> Okie
2020-05-11 10:40:55 <Cogitri> I think dbus-x11 isn't a right dep on gcr though, it's just required if you don't have a session that starts dbus for you
2020-05-11 10:42:00 <nmeum> ok, as I said: I don't really know anything about this gnome stuff
2020-05-11 10:42:44 <Cogitri> Well, DBus isn't gnome, but fair :P
2020-05-11 10:43:35 <Cogitri> Thanks for fixing the gcr thing on pinentry-gnome3 though
2020-05-11 10:50:55 <nmeum> no problem
2020-05-11 11:00:26 <ikke> PureTryOut[m]: maybe a crude way, but try apk del <pkg>
2020-05-11 11:00:37 <ikke> apk should report what depends on it
2020-05-11 11:00:50 <PureTryOut[m]> ikke: this is using rootbld, so no can do
2020-05-11 11:02:30 <ikke> ap revdep perhaps, but I don't think that one works recursively
2020-05-11 11:02:42 <ikke> and doesn't show version dependencies either
2020-05-11 11:04:31 <ikke> PureTryOut[m]: any way to repro?
2020-05-11 11:05:22 <PureTryOut[m]> Bump py3-mock to 4.0.2 and set a package that depends on it to depend on py3-mock=4.0.2 (in my case py3-graphviz).
2020-05-11 11:18:17 <mps> nmeum: I don't have any armhf builder where I could test gitea
2020-05-11 11:50:56 <mps> we can use dot '.' in pkgver but not minus sign '-'?
2020-05-11 11:51:50 <Cogitri> You can use a `_` instead
2020-05-11 11:51:54 <ikke> nod
2020-05-11 11:52:06 <Cogitri> But `$pkgver-$morepkgver-$pkgrel` would look pretty weird
2020-05-11 11:52:08 <ikke> - is basically a delimiter reserved for alpine
2020-05-11 11:52:39 <mps> aha, ok. but dot looks better, imo
2020-05-11 11:52:52 <ikke> depends a bit on upstream
2020-05-11 11:53:35 <ikke> if they make a distinction between 0.1.2.3 and 0.1.2-3
2020-05-11 11:53:46 <mps> upstream use hashes only with some (looks like random) prefixes
2020-05-11 11:53:49 <Cogitri> Yup
2020-05-11 11:53:52 <Cogitri> Ah, fun
2020-05-11 11:54:01 <mps> vboot-utils
2020-05-11 11:54:20 <ikke> https://repology.org/project/vboot-utils/versions
2020-05-11 11:55:17 <ikke> They do seem to have branches which containe what look like proper versions
2020-05-11 11:55:18 <mps> yes you see, I looked arch and debian versions,
2020-05-11 11:55:25 <ikke> https://github.com/coreboot/vboot/branches
2020-05-11 11:55:35 <ikke> but apparently very old
2020-05-11 11:56:02 <mps> yes
2020-05-11 11:56:18 <mps> new versions are full of bugs
2020-05-11 11:57:28 <mps> I'm trying to fix latest from debian archive, looks like it could work, if I find some fixes
2020-05-11 11:59:05 <mps> interesting thing is if it is built in lxc for arms it doesn't work properly, but built on 'bare metal' builders it works
2020-05-11 13:05:22 <jmaselbas> Hi there
2020-05-11 13:06:07 <ikke> o/
2020-05-11 13:06:29 <jmaselbas> I am trying to build an alpine iso but I don't know where to start :/
2020-05-11 13:06:47 <hicham> Hello
2020-05-11 13:07:25 <ikke> jmaselbas: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts these are the scripts that are used to generate the iso's
2020-05-11 13:07:36 <ikke> jmaselbas: sadly there is no documentation for them
2020-05-11 13:07:51 <jmaselbas> hum I see...
2020-05-11 13:08:30 <hicham> Can apk query local packages ? Ie, read their metadata without searching in repos indexes ...
2020-05-11 13:09:03 <jmaselbas> ikke: what's the difference between aports and abuild ?
2020-05-11 13:09:22 <ikke> aports is the repository containing all APKBUILD files for alpine linux
2020-05-11 13:09:36 <ikke> abuild is a script to create apk packaages from these
2020-05-11 13:11:38 <jmaselbas> ikke: does abuild only create packages ? Or does it also build them, (does it depend on the target arch) ?
2020-05-11 13:12:01 <ikke> it's a complete recipe to fetch the source, build it and then package it
2020-05-11 13:14:43 <jmaselbas> aport uses abuild to create packages, am i right ?
2020-05-11 13:14:48 <ikke> yes
2020-05-11 13:15:13 <jmaselbas> okay, so first I need to install abuild
2020-05-11 13:15:33 <ikke> you can install alpine-sdk, which will install everything necessary
2020-05-11 13:15:51 <ikke> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2020-05-11 13:17:28 <jmaselbas> sadly i am not using apline
2020-05-11 13:17:53 <ikke> What are you trying to achieve?
2020-05-11 13:18:06 <ikke> https://gitlab.alpinelinux.org/alpine/docker-abuild
2020-05-11 13:18:32 <jmaselbas> I want to try to port alpine to another arch and see how it goes
2020-05-11 13:19:40 <ikke> Do you have experience with bootstrapping / cross-compiling?
2020-05-11 13:20:28 <jmaselbas> nop
2020-05-11 13:20:48 <ikke> Not an easy endeavour then
2020-05-11 13:21:01 <ikke> Out of curiousity, what arch are you interested in
2020-05-11 13:21:11 <jmaselbas> kvx
2020-05-11 13:21:23 <ikke> doesn't ring a bell
2020-05-11 13:21:24 <jmaselbas> aka mppa coolidge
2020-05-11 13:22:45 <jmaselbas> it is not really known
2020-05-11 13:23:10 <ikke> you would need to start with the build toolchain (gcc / musl)
2020-05-11 13:23:52 <ikke> But I have no experience with it either, so much more details I cannot give
2020-05-11 13:24:12 <ikke> There is https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/bootstrap.sh as well
2020-05-11 13:24:22 <ikke> but you would need to know how to use it
2020-05-11 13:25:20 <ikke> There are some instructions inside
2020-05-11 13:25:51 <jmaselbas> Ok 'llI take a look, thanks for your help
2020-05-11 14:12:41 <nmeum> mps: should I just push the gitea MR then?
2020-05-11 14:12:55 <nmeum> worst-case: it doesn't fix the tests and we need to come up with an alternative solution
2020-05-11 14:13:05 <ikke> nmeum: I would say, do it :)
2020-05-11 14:14:40 <nmeum> ok, let's see how it goes
2020-05-11 14:19:26 <artok> hmm.. did we have dkms somewhere?
2020-05-11 14:19:39 <ikke> no
2020-05-11 14:20:03 <artok> should we ? =)
2020-05-11 14:20:24 <artok> at least I'd say +1
2020-05-11 14:20:57 <ikke> I have no idea what it would entail to have dkms
2020-05-11 14:21:26 <ikke> Probably a package for dkms, + dkms enabled modules?
2020-05-11 14:21:34 <artok> might be ok on rpi land
2020-05-11 14:22:11 <artok> something like that.. time to spy archlinux
2020-05-11 14:22:42 <artok> actually I'll do that later this evening.
2020-05-11 14:23:39 <mps> nmeum: I really don't know, didn't looked at build problem on armhf
2020-05-11 14:24:06 <nmeum> already pushed it :)
2020-05-11 14:25:43 <ikke> urgh, rstcheck is blocking the builders apparently
2020-05-11 14:26:35 <mps> I answered more on wrong channel :)
2020-05-11 14:29:13 <mps> will someone with main 'bits' look at !7409 (and merge if it is ok, to not miss 3.12)
2020-05-11 14:29:42 <mps> and !7685 also
2020-05-11 14:49:43 <PureTryOut[m]> I'd like to get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7813 in 3.12 if someone has the time to review it, it's patches suggested by upstream to fix a performance regression with Plasma
2020-05-11 14:58:07 <nmeum> gitea fails with a different error now
2020-05-11 14:58:14 <nmeum> > The change was rejected by the server with the following message:env: can't execute 'bash': No such file or directory Please check githooks.
2020-05-11 14:59:25 <nmeum> strange that this didn't happen on the ci
2020-05-11 14:59:47 <ikke> yes
2020-05-11 14:59:57 <nmeum> bash is also installed actually
2020-05-11 14:59:59 <ncopa> looks like it git clones something during test
2020-05-11 15:00:10 <ncopa> maybe someone pushed bash dependency to that repo
2020-05-11 15:02:06 <ikke> can someone look at rstcheck? it keeps getting stuck on the builders during testing
2020-05-11 15:02:35 <ikke> I kill one process and it continue
2020-05-11 15:02:37 <ikke> s
2020-05-11 15:09:32 <nmeum> regarding gitea: unless someone else wants to debug this further I would just disable the testsuite on armhf
2020-05-11 15:10:28 <ncopa> does it help to add bash to checkdepends?
2020-05-11 15:11:52 <nmeum> it's already in checkdepends
2020-05-11 15:14:21 <nmeum> ooooohhh
2020-05-11 15:14:54 <nmeum> hmm nope, nevermind
2020-05-11 15:15:01 <mps> x86_64|s390x|x86) options="$options !check" ;;
2020-05-11 15:15:11 <mps> gitea
2020-05-11 15:16:07 <nmeum> and !mips !mips64 in $arch :D
2020-05-11 15:16:13 <mps> so, adding armhf is not big regresion
2020-05-11 15:16:19 <nmeum> let's do that then
2020-05-11 15:17:25 <nmeum> done
2020-05-11 15:18:50 <mps> 
ACTION wonder if anyone will run gitea on armhf

2020-05-11 15:19:17 <ikke> 
ACTION still has an rpi2 ;P

2020-05-11 15:19:20 <ikke> don't tempt me
2020-05-11 15:21:16 <mps> ok, I can run armhf on exynos peach 5800 with 4GB ram and 8 cpus :)
2020-05-11 15:21:45 <mps> and usb ssd, not bad. but armv7 is better there
2020-05-11 15:22:29 <mps> ikke: rpi2 can run armv7, I think?
2020-05-11 15:24:36 <ikke> It can? I thought it was hf only
2020-05-11 15:25:15 <mps> I'm not sure, but thought it can
2020-05-11 15:26:41 <ikke> sorry, it's a 1b+
2020-05-11 15:26:55 <ikke> I do have a 2 as well
2020-05-11 15:28:13 <mps> ah, that's something else
2020-05-11 15:58:31 <Thermi> ncopa: Hi, I opened an issue in aports about the gsoap package. The problem is that it has static symbols although it is dynamically linked. That prevents using some libs from the package to be linked against: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11511
2020-05-11 16:20:15 <hicham> Cogitri: Hello
2020-05-11 16:21:03 <hicham> Cogitri: can apk query locally downloded packages ?
2020-05-11 16:22:39 <Hello71> ... can we ban this guy yet, or is four times not enough
2020-05-11 16:31:58 <Cogitri> artok: dkms basically means building kernel modules on your machine
2020-05-11 16:32:44 <Cogitri> So pro: We wouldn't have to bump the kernel module anymore ourselves (for kernel upgrades) unless upstream releases a new release
2020-05-11 16:33:19 <Cogitri> Con: Probably more fragile and pulls in a full C toolchain and linux-headers in for the user to build the thing
2020-05-11 16:36:56 <Cogitri> hicham: wdym?
2020-05-11 16:55:49 <hicham_> @Cogitri: a feature like the rpm one to query downloaded packages 'rpm -qp <package_name>.rpm'
2020-05-11 16:57:28 <Cogitri> Dunno what rpm commands do, but you could always just look at the .PKGINFO file in the .apk archive
2020-05-11 16:58:45 <hicham_> Cogitri: so there is no way to do that actually via apk ?
2020-05-11 17:00:27 <hicham_> Cogitri: and yeah, rpm and dpkg basically read the metadata from the package
2020-05-11 17:00:44 <mps> tar -Oxf packages/mps/armv7/wiringbp-2.0-r1.apk .PKGINFO | l
2020-05-11 17:00:54 <mps> hicham_: ^
2020-05-11 17:01:13 <mps> just example
2020-05-11 17:01:17 <hicham_> mps: thank you
2020-05-11 17:01:23 <mps> l is less
2020-05-11 17:01:42 <hicham_> mps: but do you think that this can be implemented in apk easily ?
2020-05-11 17:01:45 <mps> but you can go without it
2020-05-11 17:03:31 <hicham_> Cogitri: 'apk info' reads metadata from APKINDEX.tar.gz right ?
2020-05-11 17:19:58 <Cogitri> Yup
2020-05-11 17:26:32 <hicham_> Cogitri: and 'apk add' can install local packages, so I assume it can read metadata from within the package, no ?
2020-05-11 17:26:54 <Cogitri> Yup
2020-05-11 17:27:09 <Cogitri> If you think it's worthwhile to add it you can work on it and make a MR
2020-05-11 17:27:25 <hicham_> ok, I will try, thanks for the help
2020-05-11 17:28:10 <hicham_> apk is the fastest package manager that I have used so far
2020-05-11 17:29:13 <artok> Cogitri: well that...
2020-05-11 17:33:55 <Cogitri> artok: Hm?
2020-05-11 17:35:04 <artok> after cloning repo, I see that there is helluva lot to do, it doesn't work with busybox tools
2020-05-11 17:38:01 <artok> oh no, it is just stupid makefile
2020-05-11 17:39:17 <Cogitri> Ah yes, Makefiles are great fun :^)
2020-05-11 17:46:53 <artok> aaand scripts are so debian/rhel stuff
2020-05-11 17:54:10 <Cogitri> Hm, I'm pretty sure they can be adapted though
2020-05-11 17:54:16 <Cogitri> dkms seems to work fine for Exherbo and Void
2020-05-11 17:56:53 <artok> indeed, with void having comment:
2020-05-11 17:57:03 <artok> # We are only interested in the bare minimum.
2020-05-11 17:57:13 <artok> which seems reasonable thing
2020-05-11 18:10:48 <maxwell-k> ikke: not sure if you got a volunteer to look at rstcheck, I'm trying to take a look
2020-05-11 18:11:49 <ikke> no one responded yet, so feel free :)
2020-05-11 18:12:25 <ikke> They passed on the builders now, but I had to kill processed for that tha happen
2020-05-11 18:16:33 <maxwell-k> its definitely intermittent, it stalled the first time I built it locally, finished three times and just stalled again :)
2020-05-11 18:17:29 <ikke> so annoying
2020-05-11 18:17:53 <ikke> maybe strace to see what it's doing
2020-05-11 18:18:10 <ikke> looks like some kind of dead-lock
2020-05-11 18:24:06 <nmeum> fun fun fun
2020-05-11 18:36:38 <ikke> for some definitions of fun :P
2020-05-11 18:37:11 <Cogitri> gdb bt all probably is easier to read than strace
2020-05-11 18:37:40 <ikke> probably, given that you have debug symbols
2020-05-11 18:38:57 <maxwell-k> I'm open to suggestions! first time I managed to catch it when stalled there were a lot of similar processes
2020-05-11 18:39:27 <ikke> Yes, same here
2020-05-11 18:39:32 <ikke> not sure if it's normal or not
2020-05-11 18:39:40 <ikke> but I only have seen the abnormal cases :)
2020-05-11 18:49:17 <maxwell-k> so I can quite consistently produce https://tpaste.us/napE by getting it to stall and interrupting
2020-05-11 18:49:39 <maxwell-k> by consistently I mean give me five or ten minute and I'll try repeatedly :)
2020-05-11 19:06:11 <clandmeter> going to upgrade gitlab to latest patch
2020-05-11 19:29:57 <ikke> ack
2020-05-11 19:32:26 <maxwell-k> do we have an open rstcheck issue anywhere?
2020-05-11 19:32:33 <maxwell-k> are there logs somewhere showing the failure?
2020-05-11 19:32:47 <ikke> No issue yet
2020-05-11 19:32:52 <maxwell-k> I have a fix which I'll submit upstream but was hoping for something to link to
2020-05-11 19:32:56 <ikke> the 'failure' is that it never finished building
2020-05-11 19:33:20 <ikke> I can create an issue, but it would be pretty generic
2020-05-11 19:33:39 <ikke> I did not record the process output
2020-05-11 19:33:47 <ikke> maxwell-k: nice btw that you have a fix
2020-05-11 19:35:41 <gjabell> can someone rebuild python2, looks like it still wants libffi.so.6
2020-05-11 19:36:00 <maxice8> wfm
2020-05-11 19:37:25 <gjabell> hmm
2020-05-11 19:38:11 <maxice8> 3.11 ?
2020-05-11 19:38:15 <gjabell> maybe it's py3-gobject3 then, not sure why it would have an issue with python2 though
2020-05-11 19:38:58 <gjabell> helping out a friend, think he's on edge but let me check
2020-05-11 19:39:23 <maxice8> make sure he is not mixing repos because everything but racket should be with new libffi
2020-05-11 19:39:54 <gjabell> racket's fixed, thanks for the rebuild ;)
2020-05-11 19:40:00 <gjabell> this is for something else haha
2020-05-11 19:41:10 <gjabell> he's trying to install py3-gobject3 for virt-manager (not sure why it's not installed already...), but getting this: https://0x0.st/i_I3.txt
2020-05-11 19:41:22 <gjabell> no mixed repos
2020-05-11 19:42:27 <maxice8> python2 should be 2.17.8
2020-05-11 19:45:50 <ikke> wow, I think I missed a few python2 releases
2020-05-11 19:46:26 <gjabell> might be fixed with a reboot, let's see
2020-05-11 19:47:31 <maxwell-k> ikke: I am pleasantly surprised, hopefully I can get it published and merged :)
2020-05-11 19:51:30 <ikke> Me too
2020-05-11 19:52:51 <gjabell> so...python2 can't be upgraded to 2.17.18 because it breaks a dep with python2-dev, which shows as being deleted but still breaks the dep :P
2020-05-11 19:53:36 <ikke> s/2.17.18/2.7.18
2020-05-11 19:54:01 <gjabell> oops yeah
2020-05-11 19:54:15 <ikke> maxice8 started :)
2020-05-11 19:54:37 <maxice8> ?
2020-05-11 19:54:39 <artok> =D
2020-05-11 19:55:03 <ikke> read ^^
2020-05-11 19:58:26 <PureTryOut[m]> maxice8: any chance you could merge this one? 😃 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7731
2020-05-11 19:59:53 <maxice8> needs rebase
2020-05-11 20:01:18 <ikke> Anyone can see what the actual error is here? https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/racket/racket-7.7-r0.log
2020-05-11 20:01:34 <ikke> I only see warnings and Error 2
2020-05-11 20:02:57 <PureTryOut[m]> maxice8: done
2020-05-11 20:19:47 <ikke> racket: "No rule to make target 'gmp_arm_gcc.o', needed by 'mzobjects'.  Stop."
2020-05-11 20:25:28 <artok> does gitlab mirroring work ?
2020-05-11 20:25:52 <artok> just to get aports fork master live in sync of upstream...
2020-05-11 20:29:53 <clandmeter> what do you mean?
2020-05-11 20:30:21 <clandmeter> ah you want to auto update your own fork
2020-05-11 20:30:57 <clandmeter> yes gitlab can mirror
2020-05-11 20:31:10 <clandmeter> but only push not pull
2020-05-11 20:31:22 <clandmeter> in the free version
2020-05-11 20:33:42 <artok> so git fetch upstream && git merge upstream/master is totally valid way
2020-05-11 20:35:51 <Cogitri> git pull upstream master --rebase is probably easier and can't create a merge commit you don't want
2020-05-11 20:36:05 <Cogitri> Although you don't really have to keep the master of your fork up to date
2020-05-11 20:37:02 <artok> it's not that I _have_ to
2020-05-11 20:37:15 <artok> it's if I want ;)
2020-05-11 20:46:48 <maxwell-k> `git pull --rebase upstream master` is good advice, I only realised how useful it is here this weekend after reading the source to mkmr
2020-05-11 20:49:21 <Cogitri> I use it all the time (both pull&rebase and mkmr)
2020-05-11 20:52:07 <maxwell-k> anyone interested in the rstcheck intermittent failure, the MR is !7824 and upstream PR is https://github.com/myint/rstcheck/pull/67
2020-05-11 20:53:31 <maxwell-k> upstream came back with a review very quickly, I think they like the change, just want to finesse it
2020-05-12 02:56:54 <Danct12[m]> can someone check !7827?
2020-05-12 06:28:11 <Cogitri> Does someone know why linux-lts lags behind on aarch64&s390x edge? https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=edge
2020-05-12 06:28:36 <Cogitri> Oh, it's stuck on openjdk :/
2020-05-12 06:29:02 <Cogitri> Can someone kill that please and disable the openjdk11 tests on those two arches? Apparently they like to get stuck at times...
2020-05-12 06:41:14 <ikke> killed the openjdk jobs
2020-05-12 06:46:00 <Cogitri> Thank you
2020-05-12 06:51:59 <Cogitri> Pushed commit to disable the tests on those arches
2020-05-12 06:54:33 <PureTryOut[m]> Could we get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7424 in 3.12 still?
2020-05-12 06:55:50 <Cogitri> I'll test in a bit
2020-05-12 08:49:52 <nmeum> hm racket is failing on armhf
2020-05-12 08:50:07 <nmeum> passed on the ci though, maybe a parallel build issue?
2020-05-12 08:50:30 <nmeum> > make[7]: *** No rule to make target 'gmp_arm_gcc.o', needed by 'mzobjects'.  Stop.
2020-05-12 08:51:03 <Cogitri> Probably, broken internal deps
2020-05-12 08:51:06 <nmeum> created a short upstream bug report
2020-05-12 08:51:12 <nmeum> yeah, that's what I am thinkign
2020-05-12 08:51:42 <nmeum> and the file is **only** build on armhf so probably not a well tested branch in their make system
2020-05-12 08:52:49 <Cogitri> ikke: Can you make https://gitlab.alpinelinux.org/durrendal/aports public again? I asked them to not deleted their aports fork anymore in the future, so hopefully that's the last time
2020-05-12 08:56:26 <ikke> done
2020-05-12 08:56:37 <ikke> (I just ran the script)
2020-05-12 08:56:58 <ikke> I need to schedule that some time, but keep forgetting
2020-05-12 08:58:10 <Cogitri> Ah, thanks :)
2020-05-12 09:17:29 <ncopa> im trying to fix the circular deps in repo
2020-05-12 09:18:00 <Cogitri> Good luck, feel free to ping me if there's something I can help with
2020-05-12 09:19:36 <ncopa>  * [new branch]            uacme-upgrade -> origin/uacme-upgrade
2020-05-12 09:19:36 <ncopa>  * [new branch]            z3-upgrade    -> origin/z3-upgrade
2020-05-12 09:19:39 <ncopa> what are those?
2020-05-12 09:20:26 <ncopa> From git://git.alpinelinux.org/aports
2020-05-12 09:20:34 <Cogitri> Huh?
2020-05-12 09:20:45 <ikke> ncopa: experiments from clandmeter
2020-05-12 09:20:53 <ikke> was testing sending patches via e-mail
2020-05-12 09:21:02 <Cogitri> Ah
2020-05-12 09:21:03 <ikke> and gitlab created those on alpine/aports
2020-05-12 09:21:34 <nmeum> the z3 branch was accidentally created by myself (pushed to the wrong remote)
2020-05-12 09:21:48 <nmeum> but iirc it was deleted (at least on gitlabr
2020-05-12 09:22:01 <clandmeter> I also deleted mine on gitlab
2020-05-12 09:22:12 <ikke> seems like something is recreating them
2020-05-12 09:22:22 <ikke> Same with the branches / tags that fabled pushed
2020-05-12 09:22:27 <clandmeter> I think it's on git.a.o
2020-05-12 09:22:37 <clandmeter> Or is it back on gitlab?
2020-05-12 09:22:37 <ncopa> https://git.alpinelinux.org/aports/
2020-05-12 09:22:38 <ikke> but what is syncing git.a.o -> gitlab.a.o?
2020-05-12 09:22:45 <nmeum> maybe we can also install some kind of server hook to prevent branches other than [0-9]+.[0-9]+-stable from being created in the first place?
2020-05-12 09:22:59 <ikke> nmeum: protected branches should work
2020-05-12 09:23:01 <ncopa> nmeum: sunds like a good idea
2020-05-12 09:23:22 <ncopa> ikke: users may pull from git.a.o and push to gitlab.a.o
2020-05-12 09:24:13 <ikke> I can set '*' to deny push again
2020-05-12 09:24:20 <ncopa> or may pull from https://github.com/alpinelinux/aports
2020-05-12 09:25:11 <ncopa> how do we delete those branches from git.a.o and github?
2020-05-12 09:26:35 <clandmeter> we need to disable the other repo mirror setup
2020-05-12 09:27:35 <clandmeter> do we have some permission setting for tags?
2020-05-12 09:27:44 <ikke> on gitlab?
2020-05-12 09:27:52 <clandmeter> yes
2020-05-12 09:28:07 <ikke> Only maintainers are allowed to create tags
2020-05-12 09:28:08 <clandmeter> ah samething as branches
2020-05-12 09:28:56 <clandmeter> its not that flexible
2020-05-12 09:29:07 <clandmeter> i dont think we need to allow anything except ncopa to create tags
2020-05-12 09:29:13 <clandmeter> anyone*
2020-05-12 09:29:33 <ikke> Sure, but I cannnot select 'ncopa' :)
2020-05-12 09:29:44 <ikke> unless we use hooks
2020-05-12 09:29:48 <clandmeter> yes, thats what i mean its not that flexible :)
2020-05-12 09:30:09 <ikke> clandmeter: and because we are admins anyway, we can do anything
2020-05-12 09:30:34 <Cogitri> (Why do I have to imagine that with an evil laugh :D)
2020-05-12 09:30:40 <ikke> although, I think it will still applies this ACL I think
2020-05-12 09:31:24 <clandmeter> and maybe ppl that have push access should not pull from git.a.o
2020-05-12 09:31:46 <ikke> I updated my remote to point to gitlab.a.o only
2020-05-12 09:34:35 <ncopa> i dont want be the only one who can create tags
2020-05-12 09:34:45 <ncopa> at least not in the long run
2020-05-12 09:35:05 <clandmeter> its not a fixed system
2020-05-12 09:35:21 <clandmeter> its just being protective about it i guess.
2020-05-12 10:01:16 <Cogitri> How do we usually handle /run/$pkgname dirs a package needs for docker containers? Usually we manage those via openrc services and checkpath, but that wont work for docker containers, right?
2020-05-12 10:01:20 <Cogitri> I'm asking for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7789#note_87854
2020-05-12 10:02:06 <ikke> Shouldn't that be part of the Dockerfile?
2020-05-12 10:02:15 <ikke> or entrypoint
2020-05-12 10:02:58 <Cogitri> Probably, but I wasn't sure if we usually also handle that from our side as well
2020-05-12 10:03:12 <Cogitri> But I don't see us creating that file in postinstall or the APKBUILD itself in other packages
2020-05-12 10:03:23 <ikke> Correct, because it doesn't work like you said
2020-05-12 10:03:31 <ikke> one reboot later and the dir is gone
2020-05-12 10:19:39 <ncopa> im trying to fix the vlc -> vlc-xorg -> vlc circular deps
2020-05-12 10:19:59 <ncopa> and bumped into commit 3a59623e3bbc176e9e159ad1c7397148baaeadc2 which splits out lots of plugins
2020-05-12 10:20:13 <ncopa> and then make vlc depend on those
2020-05-12 10:20:32 <ikke> hmm, that doesn't make a lot of sense
2020-05-12 10:20:41 <ikke> split it up, but then force them to be installed anyway
2020-05-12 10:21:02 <ncopa> clandmeter: do you remember what the intention was to split out the plugins as separate packages?
2020-05-12 10:56:15 <clandmeter> nope
2020-05-12 10:58:09 <clandmeter> i guess it pulls in a lot of deps?
2020-05-12 11:03:13 <ncopa> it pulls in all of them
2020-05-12 11:03:22 <ncopa> and kind of undermines the purpose of vlc-xorg
2020-05-12 11:05:36 <ncopa> at some point it was possible to install vlc-daemon without the xorg stuff
2020-05-12 11:08:39 <clandmeter> i dont recall this change at all.
2020-05-12 11:08:49 <clandmeter> do whatever you think its ok.
2020-05-12 11:47:07 <minus> DNS for git.alpinelinux.org seems gone; all recursors i tried give me a NXDOMAIN
2020-05-12 11:47:23 <ikke> minus: We just switched it, but it should not be gone
2020-05-12 11:47:33 <ikke> I can confirm
2020-05-12 12:07:15 <andypost[m]> It's back and works again
2020-05-12 12:07:43 <ikke> ok, thanks
2020-05-12 12:17:08 <Cogitri> Can I get the logs of vulkan-loader failing on s390x/armhf? 404s for me
2020-05-12 12:17:36 <ikke> In a moment
2020-05-12 12:21:31 <Cogitri> Thanks
2020-05-12 12:36:27 <ncopa> danieli: do you think you can help with the circular dependencies for erlang?
2020-05-12 12:36:53 <danieli> ncopa: sure, just been terribly busy with work lately
2020-05-12 12:36:57 <danieli> need to get up to speed on that
2020-05-12 12:38:21 <ncopa> oh apparently I have already reported it. #11040
2020-05-12 12:39:00 <ncopa> i think erlang and samba are the final ones for alpine 3.12
2020-05-12 12:39:07 <ncopa> atleast on x86_64
2020-05-12 12:39:27 <ncopa> samba is horribly complicated
2020-05-12 12:41:34 <ikke> Cogitri: https://tpaste.us/Z069
2020-05-12 12:41:38 <ikke> this is on s390x
2020-05-12 12:44:53 <Cogitri> Thanks, that should do for now
2020-05-12 12:45:30 <Cogitri> That vulkan stuff sure is "interesting"
2020-05-12 12:52:39 <Cogitri> !7840
2020-05-12 12:59:06 <ikke> always fun, these hard dependecies
2020-05-12 13:15:20 <ikke> nmeum: nice
2020-05-12 15:40:35 <kaey> git.a.o broke?
2020-05-12 15:40:44 <kaey> "No repositories found"
2020-05-12 15:41:54 <kaey> Git repository link on pkgs.a.o is wrong, see for ex https://pkgs.alpinelinux.org/package/edge/community/armv7/php7-pecl-event
2020-05-12 15:54:28 <ikke> kaey: We switched it over to new infra
2020-05-12 15:55:03 <ikke> /cgit should be removed
2020-05-12 15:55:12 <ikke> Or a redirect added perhaps
2020-05-12 15:56:01 <dalias> please add redirect or make both work
2020-05-12 15:56:12 <dalias> bitrot of git links *really* sucks
2020-05-12 15:56:44 <ikke> yeah, redirect makes sense
2020-05-12 15:56:51 <dalias> because ppl use and intend them as permanent references to exact historic versions
2020-05-12 15:56:53 <ikke> the cgit part was not there already for a long time
2020-05-12 15:57:40 <ikke> We tend to do our best to keep links working
2020-05-12 15:57:56 <kaey> link on pkgs.a.o worked yesterday
2020-05-12 15:59:05 <ikke> yes, we switched today
2020-05-12 16:25:17 <ikke> dalias: kaey https://gitlab.alpinelinux.org/alpine/infra/compose/cgit/-/merge_requests/1
2020-05-12 16:28:32 <kaey> lgtm
2020-05-12 16:29:02 <ikke> First want to make sure I'm not breaking anything else
2020-05-12 16:29:52 <ikke> it should not, but clandmeter knows this part better then I do
2020-05-12 17:08:26 <clandmeter> ikke: https://gitlab.alpinelinux.org/alpine/infra/aports-turbo/-/blob/master/config.sample.lua#L96
2020-05-12 17:08:49 <clandmeter> you can update the config on pkgs.a.o compose config and restart it
2020-05-12 17:09:02 <clandmeter> two entries needs update
2020-05-12 17:09:14 <ikke> Yes, but I think, like dalias said, also not to keep existing links working
2020-05-12 17:09:37 <ikke> so adjusting that in aports-turbo should be done anyway
2020-05-12 17:09:46 <clandmeter> cgit has bee depricated long time
2020-05-12 17:10:10 <clandmeter> since we moved it to uwsgi
2020-05-12 17:10:13 <ikke> but apparently pkgs.a.o still linked to it for a long time
2020-05-12 17:10:31 <clandmeter> yes, because it was even older
2020-05-12 17:10:45 <ikke> so at least redirecting is a minimal service we can do :)
2020-05-12 17:10:46 <clandmeter> you can add that if you want, but we should fix pkgs
2020-05-12 17:10:52 <ikke> yes, totally agree
2020-05-12 17:11:00 <ikke> Makes no sense to keep linking to the wrong url
2020-05-12 17:12:10 <clandmeter> if you restaret pkgs, dont forget to scale it to 4
2020-05-12 17:12:29 <ikke> 76 links in aports to git.alpinelinux.org/cgit
2020-05-12 17:12:40 <ikke> ok, do you need to manually specify that?
2020-05-12 17:14:17 <clandmeter> yes
2020-05-12 17:14:27 <clandmeter> compose up -d --scale=4
2020-05-12 17:14:49 <ikke> ok
2020-05-12 17:15:13 <ikke> no way to set that in the compose file?
2020-05-12 17:15:14 <clandmeter> good catch, so yes please add it to nginx
2020-05-12 17:15:21 <clandmeter> nope not yet afaik
2020-05-12 17:16:06 <ikke> docker-compose up -d --scale=http=4
2020-05-12 17:16:10 <ikke> that's the syntax apparently
2020-05-12 17:16:24 <clandmeter> oh yes sorry
2020-05-12 17:16:31 <clandmeter> you need to specify service
2020-05-12 17:16:52 <ikke> but I need to do a restart anyway, because the compose config didn't change
2020-05-12 17:17:43 <clandmeter> you can do --force-recreate
2020-05-12 17:17:48 <clandmeter> or similar
2020-05-12 17:18:01 <ikke> right, but restart should suffice
2020-05-12 17:18:10 <ikke> docker-compose restart http
2020-05-12 17:18:12 <clandmeter> that depends
2020-05-12 17:18:24 <ikke> on what?
2020-05-12 17:18:32 <clandmeter> if you mount a specific file, it does not update in the container
2020-05-12 17:18:47 <ikke> ah ok
2020-05-12 17:18:52 <clandmeter> if you mount a dir files in it do.
2020-05-12 17:19:03 <ikke> but it has been fixed anyway
2020-05-12 17:19:14 <ikke> links are working again
2020-05-12 17:19:14 <clandmeter> thats most important :)
2020-05-12 17:21:10 <ikke> hmm, you have uncommitted changes in cgit ... :)
2020-05-12 17:22:34 <clandmeter> its like that all over the place
2020-05-12 17:22:44 <clandmeter> i need to put that stuff in ansible
2020-05-12 17:23:19 <clandmeter> im running around in circles between too many things recently
2020-05-12 17:23:29 <ikke> heh, I know that feeling
2020-05-12 17:25:13 <ikke> redirect is working as well
2020-05-12 17:25:37 <clandmeter> cool thx
2020-05-12 17:27:16 <ikke> We should move this to #-infra I guess :P
2020-05-12 17:34:20 <clandmeter> interesting, im getting an email from uacme dev
2020-05-12 19:18:19 <ikke> kaey: fyi, the links should work again, including redirect for the old address
2020-05-12 19:43:45 <mps> uacme fail because checksum is not correct
2020-05-12 19:46:59 <mps> very strange changes in checksum
2020-05-12 19:48:11 <kaey> ikke: i saw. thank you
2020-05-12 19:48:42 <ikke> mps: yup
2020-05-12 19:51:06 <mps> not sure will the 'abuild checksum' 'git push' solve it
2020-05-12 19:51:13 <ikke> most likely
2020-05-12 19:51:24 <mps> I have it ready to push
2020-05-12 19:51:24 <ikke> The 'hard' part is figuring out why they changed in the first place
2020-05-12 19:52:17 <mps> pushed, lets see what will happen
2020-05-12 19:52:21 <ikke> k'
2020-05-12 20:01:02 <mps> hm, looks like source for uacme plays 'flip-flop' with file
2020-05-12 20:26:22 <clandmeter> mps: can you retry?
2020-05-12 20:27:39 <clandmeter> i updated src url but it has same name
2020-05-12 20:27:52 <clandmeter> abuild should rename old tarball
2020-05-12 20:33:10 <mps> I think it should be reverted to old tarball url
2020-05-12 22:11:58 <c705> ncopa: vlc-qt has vlc-xorg marked as a dep, but it's not availiable. I'll file a bug for this after work
2020-05-13 06:27:55 <ncopa> oh, sorry. I missed that one. Will fix asap
2020-05-13 06:53:34 <maxwell-k> good morning, I know alint discourages $pkgname in $source, does the same apply to other variables like $_pkgname?
2020-05-13 07:13:46 <Cogitri> maxwell-k: Yes, I think the purpose of that is to only have $pkgver as variable in the url
2020-05-13 07:13:56 <Cogitri> So that it's still somewhat easy to paste the thing
2020-05-13 08:42:21 <ncopa> heh, im trying to clean up the samba dependencies
2020-05-13 08:42:29 <ncopa> its a mess
2020-05-13 08:42:37 <ncopa> and now i hit this:
2020-05-13 08:42:43 <ncopa> >>> samba-libs*: Running split function libs...
2020-05-13 08:42:43 <ncopa> Segmentation fault
2020-05-13 08:49:01 <Cogitri> Oof
2020-05-13 08:49:12 <Cogitri> What SEGFAULTs?
2020-05-13 08:49:42 <ncopa>  i forgot a trailing \
2020-05-13 08:50:00 <ncopa> so it ended up running a dynamic lib
2020-05-13 08:50:15 <Cogitri> Oh ^^
2020-05-13 09:54:07 <danieli> we don't have a S-WIP issue label in gitlab, do we?
2020-05-13 09:59:08 <ncopa> seems like we dont
2020-05-13 10:02:59 <maxwell-k> Cogitri: ty, I understand now
2020-05-13 10:05:10 <Cogitri> danieli: What's the advantage of doing that over putting WIP: in the title (which also prevents if from accidentally getting merged)
2020-05-13 10:06:18 <Cogitri> maxwell-k: One thing to note: It's not really restricted to pkgver, other things which change often can also be a variable in the url, e.g. when you have a package which pulls from git it's easier to make a _commit variable and use that
2020-05-13 10:06:19 <Cogitri> Since the commit probably also is in the builddir etc.
2020-05-13 10:19:34 <danieli> just more consistency really but the title works
2020-05-13 11:00:45 <ncopa> ok, i think i finally managed to fix the samba circular deps
2020-05-13 11:04:47 <Cogitri> Nice
2020-05-13 11:30:38 <ncopa> whats wrong with uacme?
2020-05-13 11:32:28 <Cogitri> Seems like the shasum is wrong but since we host that ourselves apparently that's probably just a change to the tarball that was done afterwards
2020-05-13 11:32:38 <Cogitri> Not sure who did that though
2020-05-13 11:34:00 <ncopa> there are different tags
2020-05-13 11:34:11 <ncopa> https://github.com/ndilieto/uacme/releases
2020-05-13 11:34:21 <mps> on some builders it is pulled from distfiles not upstream
2020-05-13 11:34:29 <ncopa> there are upstream/1.3 and v1.3
2020-05-13 11:34:36 <mps> I fixed it last night
2020-05-13 11:34:51 <ncopa> not completely
2020-05-13 11:35:02 <mps> look at 'git log -p'
2020-05-13 11:35:45 <mps> it builds on edge after latest commits, except mips64 which pulls from local cache I think
2020-05-13 11:35:56 <ncopa> a7f0ffea0e7df9de9cb1dd701e66ed904f082b97
2020-05-13 11:36:14 <ncopa> clandmeter: why did you consider that the proper upstream source?
2020-05-13 11:36:19 <ncopa> and not the v1.3 tag?
2020-05-13 11:36:44 <mps> yes, but we talked after that and concluded to revert this
2020-05-13 11:36:48 <clandmeter> Cause he emailed me
2020-05-13 11:37:23 <ncopa> and why was the conclusion to revert it?
2020-05-13 11:38:40 <mps> because on prevoius url cheksums changes nearly on every fetch
2020-05-13 11:39:57 <Cogitri> Huh, they re-tag it?
2020-05-13 11:40:07 <ncopa> looks like there are two different branches
2020-05-13 11:40:11 <ncopa> master and upstream
2020-05-13 11:40:17 <ncopa> not sure what the difference is
2020-05-13 11:40:29 <mps> look backlog on this channel around 21:43 UTC last night
2020-05-13 11:42:50 <clandmeter> Yes developer mailed me to say we use wrong source
2020-05-13 11:42:59 <ncopa> did he say why?
2020-05-13 11:43:05 <clandmeter> It's also in the readme
2020-05-13 11:44:38 <clandmeter> somebody reverted my commit?
2020-05-13 11:45:00 <ncopa> yes
2020-05-13 11:45:03 <mps> clandmeter: I
2020-05-13 11:45:08 <clandmeter> why?
2020-05-13 11:45:25 <mps> because on prevoius url cheksums changes nearly on every fetch
2020-05-13 11:45:33 <ncopa> thats why im asking. none of the commits says why it should be the one or the other way
2020-05-13 11:46:32 <clandmeter> i thought its obvious as its stated in the readme.
2020-05-13 11:46:47 <ncopa> who reads the readmes? :)
2020-05-13 11:47:10 <mps> :)
2020-05-13 11:47:15 <clandmeter> Note: pristine releases are in the upstream/latest branch, tagged as upstream/x.x.x
2020-05-13 11:47:47 <ncopa> what is the git master v1.3 tag about then?
2020-05-13 11:48:04 <ncopa> what is the difference?
2020-05-13 11:48:12 <clandmeter> i have no time to find out the difference. i trust the author.
2020-05-13 11:48:32 <ncopa> ok. i thought he may have mentioned it in the email. the readme does not say either
2020-05-13 11:48:42 <ncopa> but i think we should respect that
2020-05-13 11:48:55 <clandmeter> i also mentioned it here
2020-05-13 11:48:59 <clandmeter> the autor contacted me
2020-05-13 11:49:09 <clandmeter> and i ask mps to retry cause the checksums will fail
2020-05-13 11:49:19 <clandmeter> cause it needs to redownload the tarball
2020-05-13 11:49:49 <clandmeter> i think some builders are fetching the same all the time
2020-05-13 11:49:54 <clandmeter> from distfiles or something
2020-05-13 11:50:05 <ncopa> i understand now. thanks. was not ovious from only reading git log what has happened and why
2020-05-13 11:50:11 <mps> (in God we trust, everything else check with pgp - old crypto saying)
2020-05-13 11:50:29 <clandmeter> https://tpaste.us/YpPZ
2020-05-13 11:50:33 <clandmeter> email from author
2020-05-13 11:51:00 <mps> clandmeter: true, I think mips64 fetch it from local cache
2020-05-13 11:51:38 <ncopa> thanks clandmeter. the answer to my question is in the link from author
2020-05-13 11:53:06 <clandmeter> ncopa: i think the logic to refetch is broken
2020-05-13 11:53:35 <clandmeter> abuild has an option to first try distfiles and fall back to real source
2020-05-13 11:53:52 <clandmeter> i didnt look into it, but this sounds it.
2020-05-13 11:54:46 <clandmeter> the only fix is probably to include $pkgrel in filename
2020-05-13 11:58:03 <ncopa> i have another workaround
2020-05-13 12:00:25 <ncopa> $ git format-patch -1 --stdout | tpaste
2020-05-13 12:00:25 <ncopa> http://tpaste.us/5EqB
2020-05-13 12:00:38 <ncopa> mps, clandmeter: does that look ok? ^^^
2020-05-13 12:01:01 <clandmeter> yes its fine
2020-05-13 12:01:03 <ncopa> if the checksum fails again, we'll need to find another solution
2020-05-13 12:01:10 <clandmeter> lots of details for a small case like this :)
2020-05-13 12:01:54 <clandmeter> btw, what is .tarball-version?
2020-05-13 12:01:59 <ncopa> no idea :)
2020-05-13 12:02:14 <clandmeter> so you have an aswer on your question which doesnt ring any bell :p
2020-05-13 12:02:14 <ncopa> i guess it is something uacme --version returns
2020-05-13 12:02:34 <clandmeter> i dont think so
2020-05-13 12:02:41 <clandmeter> i checked the version before
2020-05-13 12:02:58 <clandmeter> i was confused what he said in the beginning
2020-05-13 12:05:21 <mps> hmm, will that work
2020-05-13 12:07:08 <ncopa> there is something using it in build-aux/git-version-gen, so something uses the tarball version
2020-05-13 12:07:13 <ncopa> not sure why or what
2020-05-13 12:07:18 <ncopa> it may be broken too
2020-05-13 12:08:23 <mps> looks like it is ok now, after three tests
2020-05-13 12:08:37 <ncopa> ok, let me push it
2020-05-13 12:09:15 <mps> ok, I'm here if need revert again :)
2020-05-13 12:10:03 <ncopa> mps: thanks!
2020-05-13 12:10:14 <ncopa> :)
2020-05-13 12:10:32 <mps> np
2020-05-13 12:12:24 <Cogitri> I don't really get why upstream doesn't just make seperate release tarballs that have those files include, but oh well
2020-05-13 12:14:40 <mps> Cogitri: you remember talk about how to complicate maintainer life/work :)
2020-05-13 12:16:40 <ncopa> hum, we have an interesting segfault on s390x
2020-05-13 12:16:44 <ncopa> when building sox
2020-05-13 12:17:09 <ncopa> Core was generated by `make installcheck'.
2020-05-13 12:17:19 <ncopa> which means that it is gnu make that segfaults
2020-05-13 12:17:24 <Cogitri> mps: heh, right :D
2020-05-13 12:17:37 <Cogitri> Oof, can we get a coredump from the builders?
2020-05-13 12:17:55 <ncopa> i can reptoduce it on my dev machine
2020-05-13 12:18:54 <Cogitri> Ah, good
2020-05-13 12:19:02 <Cogitri> Or well, not good :D
2020-05-13 12:24:22 <ncopa> beign able to reproduce is always good
2020-05-13 12:24:32 <ncopa> but ugh...
2020-05-13 12:24:48 <ncopa> when i build make with debugging symbols i get errors in testsuite
2020-05-13 12:25:34 <ncopa> heh
2020-05-13 12:25:56 <danieli> at least erlang builds by only rebasing the existing patches
2020-05-13 12:26:01 <danieli> now to fix circular deps and test it
2020-05-13 12:26:16 <danieli> new major release a few hours ago by the way, 23.0
2020-05-13 12:26:27 <ncopa> awesome! thanks for looking into it
2020-05-13 12:28:01 <ncopa> hum
2020-05-13 12:28:20 <ncopa> i think it may be somethign in recent musl fixes/updates that breaks make
2020-05-13 12:43:46 <ncopa> gnu make testsuite fails with busybox diff
2020-05-13 12:43:52 <ncopa> not sure what introduced that
2020-05-13 12:44:22 <ncopa> must been introduced after I bootstrapped the builders
2020-05-13 14:53:18 <ncopa> looks lke adapta-gtk-theme is orphaned upstream and in aports
2020-05-13 15:26:17 <Cogitri> Yup
2020-05-13 15:26:21 <Cogitri> But it's still pretty useful
2020-05-13 15:26:32 <ncopa> i moved it to unmaintained. sorry
2020-05-13 15:26:37 <Cogitri> I had hoped that someone else would pick it up upstream
2020-05-13 15:26:53 <ncopa> feel free to move it back and maintain the alpine package if you want
2020-05-13 15:26:54 <Cogitri> Ah, no worries, I just Adwaita anyway
2020-05-13 17:19:10 <ikke> Hmm, related issue for borgbackup failing on armhf: https://github.com/borgbackup/borg/issues/4891
2020-05-13 21:03:44 <artok> note to self: alpine upgrade on rpi4 doesn't go well
2020-05-13 21:04:13 <artok> at least headless somehow stopped working
2020-05-13 21:09:53 <artok> oh noes
2020-05-13 21:10:07 <artok> firmware doesn't work
2020-05-13 21:23:56 <artok> aaahhaha!
2020-05-13 21:24:07 <artok> sorry, my bad
2020-05-13 21:29:04 <artok> had l
2020-05-13 21:29:18 <artok> symbolink link to /boot with typo...
2020-05-13 21:30:38 <c705> oops!
2020-05-13 21:59:37 <artok> at least it booted with old kernel so that usb keyboard worked to do the cp
2020-05-14 04:03:16 <yunfan> hi guys, were those allwinner a20 boards stil lack of ehternet modules?
2020-05-14 05:36:39 <Cogitri> Dunno, have you made a tracking issue for that?
2020-05-14 06:00:23 <mps> yunfan: some of boards have it working, but you have to test yourself if your boards work
2020-05-14 06:57:48 <yunfan> mps: i remember you had told me i need to add some sunxi relevent params for boot
2020-05-14 06:57:59 <yunfan> mps: and mine is cubieboard2
2020-05-14 06:58:31 <yunfan> dunno why it dont load the module for ethernet
2020-05-14 07:01:40 <mps> do you use latest stable release
2020-05-14 07:03:13 <yunfan> mps: yes
2020-05-14 07:03:20 <yunfan> looks like you dont remember me
2020-05-14 07:08:05 <mps> yunfan: I remember you but don't remember which release version you use :)
2020-05-14 07:09:49 <yunfan> mps: i am using alpine-uboot-3.11.6-armv7.tar.gz
2020-05-14 07:10:00 <yunfan> since it has the dtb files for my cubieboard2
2020-05-14 07:10:28 <yunfan> i had to wait for my daughter's birth and then play these boards, that's why i missed so much days
2020-05-14 07:11:06 <mps> I think I tested 3.11.4 with bananapi (A20) and iirc it worked
2020-05-14 07:11:52 <yunfan> i found ethernet has been recognized from `dmesg`
2020-05-14 07:11:56 <mps> yunfan: my congratulation for daughter birth :)
2020-05-14 07:12:12 <yunfan> but the eth0 device is down by default
2020-05-14 07:12:24 <yunfan> mps: thanks, i hope she could follow my stesp :D
2020-05-14 07:12:26 <yunfan> steps
2020-05-14 07:13:18 <mps> yes, dreams of all parents :)
2020-05-14 07:14:37 <yunfan> anyway, i will find a way to let you check my tty
2020-05-14 07:17:11 <yunfan> aha, its my fault
2020-05-14 07:17:26 <yunfan> turn out, its just some auto linkup scripts failed
2020-05-14 07:17:31 <mps> I have a script which install alpine-uboot-3.11.5-armv7.tar.gz for bananapi on sdcard, set boot loader (u-boot) and parameters to it
2020-05-14 07:17:45 <yunfan> so i just need to link up by manual and call udhcpc
2020-05-14 07:18:15 <yunfan> mps: after talk with you last time, i had learnt all these steps
2020-05-14 07:18:19 <yunfan> thanks again
2020-05-14 07:18:38 <yunfan> and i wonder if i could wrote a simple wiki pages for people who need this?
2020-05-14 07:18:53 <mps> if you want I can post it, but you will need some changes for your board and of course you device on computer where you do installation
2020-05-14 07:18:53 <yunfan> should i register a account and wait for gaining the write permision?
2020-05-14 07:20:00 <mps> yes, you can register at wiki and wait few hours before you can write there
2020-05-14 07:20:25 <yunfan> since i had ddns setup, i guess its possible to let you guys login it for playing
2020-05-14 07:22:41 <mps> yunfan: I have issue with A20 board when connect some equipment on ethernet port, for example my dsl routers don't appear as connected, i.e. link is down
2020-05-14 07:23:17 <mps> that is not because of kernel/alpine but probably about bad electronic design
2020-05-14 07:25:58 <yunfan> mps: yes, i found this issue reported also on armbian's forum
2020-05-14 07:31:55 <mps> I'm contemplating to create web page for alpine alpine on arm where I can write my experiences, tips, hacks, scripts and possibly guides, but still not decided because I'm not proficient in English writing
2020-05-14 07:32:22 <yunfan> mps: me too, i am chinese :D
2020-05-14 07:32:39 <yunfan> but i think you could host your site to github
2020-05-14 07:32:59 <yunfan> so people could fix your typo and other stuff by sending pr or just fork it
2020-05-14 07:33:06 <mps> I don't like github
2020-05-14 07:34:25 <mps> whole idea of forking and keep it separate is something I dislike
2020-05-14 07:35:19 <mps> better is to send patches back to origin, imo
2020-05-14 07:36:31 <ikke> forking is just mechanism github introduced to be able to send 'patches' back to origin as commits rather than emails
2020-05-14 07:36:39 <ikke> without having access to the actual project
2020-05-14 07:37:44 <mps> ikke: yes, but there are a lot of people who simply forks and keep their forks which is true jungle now
2020-05-14 07:38:06 <ikke> lots of people also keep local clones of projects, but that's not nearly as visible
2020-05-14 07:38:20 <ikke> A fork is just a clone of a repository that github hosts
2020-05-14 07:38:52 <ncopa> im working on borgbackup
2020-05-14 07:39:22 <ncopa> ikke: thanks for the tip on the memory alignment issue
2020-05-14 07:39:43 <mps> yunfan: here is my script to install alpine on bananapi https://tpaste.us/jxZe
2020-05-14 07:40:10 <mps> btw, looks like tpaste need to be fixed to use https only
2020-05-14 07:40:21 <ncopa> yes
2020-05-14 07:40:49 <ikke> mps: it's updated in the repos
2020-05-14 07:40:53 <mps> and backported after fixed
2020-05-14 07:41:20 <mps> ikke: just updated it but it still gives me http://tpaste.us/jxZe
2020-05-14 07:41:26 <mps> not https
2020-05-14 07:41:46 <mps> tpaste-0.7-r1
2020-05-14 07:43:28 <ncopa> $ docker run --rm -it alpine:edge sh -c 'apk update --quiet  && apk dot --errors' | tpaste
2020-05-14 07:43:28 <ncopa> http://tpaste.us/DDpe
2020-05-14 07:43:40 <ncopa> shows http instead of https ^^^
2020-05-14 07:44:00 <ncopa> also, it is only erlang that has circular dependencies now
2020-05-14 07:45:35 <yunfan> mps: thanks
2020-05-14 07:46:49 <ncopa> on mips there are more uresolved deps:
2020-05-14 07:46:51 <ncopa> $ apk dot --errors | tpaste
2020-05-14 07:46:51 <ncopa> http://tpaste.us/Bj7o
2020-05-14 07:48:19 <yunfan> ncopa: you can have a mips inside recently device?
2020-05-14 07:48:39 <yunfan> mps: i had enable ssh login for my cb2, if you need device for testing, ask me
2020-05-14 07:49:29 <ncopa> i have access to a mips64 machine yes, but im no sure it is inside a recently device (not sure what you mean)
2020-05-14 07:50:26 <yunfan> ncopa: which model?
2020-05-14 07:50:41 <yunfan> becuase i heard that its company will be sold again
2020-05-14 07:51:12 <yunfan> too sad, but now i am turn to riscv :D
2020-05-14 07:51:29 <mps> yunfan: if I can ssh login then the all issue are solved already, so I think I don't need access to your device/box
2020-05-14 07:51:39 <yunfan> ok
2020-05-14 07:52:10 <yunfan> will continue to test sata supporting
2020-05-14 08:00:20 <ncopa> yunfan: not sure. Ariadne know what model it is
2020-05-14 08:01:00 <Ariadne> the mips64 builder is a cavium octeon3
2020-05-14 08:01:14 <Ariadne> ubiquiti networks edgerouter infinity
2020-05-14 08:23:12 <yunfan> Ariadne: got it, this is the high end machine
2020-05-14 08:23:48 <Ariadne> actually we are trying to get an interface masters tahoe machine with the 48-core octeon3 :)
2020-05-14 08:28:43 <yunfan> mps: i think i met the old problem again
2020-05-14 08:29:31 <yunfan> mps: when i invoke reboot, i found all the scripts works, and then the system stuk at requesting system restarting
2020-05-14 08:32:11 <mps> yes, this is not yet fixed
2020-05-14 08:32:29 <mps> reboot/poweroff still doesn't work
2020-05-14 08:33:12 <mps> I have kernel 5.6.9 for armv7 where I fixed this but didn't yet pushed to aports
2020-05-14 08:50:12 <yunfan> ok, will just wait  :D
2020-05-14 08:53:15 <mps> I can put apk somewere on the net, but it have to be installed with 'apk add --allow-untrusted linux-edge-5.6.9-r0.apk'
2020-05-14 08:56:02 <mps> or maybe create merge request on gitlab.a.o with WIP status so everyone can build it yourself or download artefacts from CI
2020-05-14 08:56:47 <mps> ncopa: what you think about this idea?
2020-05-14 09:01:22 <fcolista2> I don' t know if this topic was already discussed...but I'm seeing some py packages started to be shipped to be build with poetry
2020-05-14 09:01:46 <fcolista2> ...anyone has a vague idea on how to package these py softwares?
2020-05-14 09:01:49 <maxice8> It has been very annoying have to deal with those
2020-05-14 09:02:00 <maxice8> you need poetry in testing/
2020-05-14 09:02:13 <fcolista2> yes I saw it
2020-05-14 09:02:18 <maxice8> it has lots of dependencies to boot
2020-05-14 09:02:26 <maxice8> fortunately in most cases the project's pypi tarball includes a setup.py that can use setuptools
2020-05-14 09:02:40 <fcolista2> I do have a couple of packages moved to poetry
2020-05-14 09:02:45 <fcolista2> without setup.py anymore...
2020-05-14 09:02:54 <fcolista2> and I feel that this will be the future..
2020-05-14 09:03:11 <maxice8> what an unfortunate future, i use flit myself in mkmr
2020-05-14 09:35:02 <ncopa> mps: no opinion there
2020-05-14 09:39:44 <Ariadne> it would be nice to have some sort of PPA system based on the gitlab CI
2020-05-14 09:40:18 <ncopa> danieli: I'm looking at the erlang circualr deps problem
2020-05-14 09:40:59 <ncopa> i wonder if it would make sense to drop almost all subpackages
2020-05-14 09:41:13 <Ariadne> yes, it would
2020-05-14 09:41:31 <Ariadne> the erlang developers *hate* that distros split it up
2020-05-14 09:41:32 <ncopa> and only have a few, like erlang-wx, erlang-megaco and erlang-odbc
2020-05-14 09:42:01 <Cogitri> Ariadne: You mean that you could use CI as a repo?
2020-05-14 09:42:36 <ncopa> wx pulls in wxwidgets and gtk and stuff, odbc pulls in external deps and megaco is just huge
2020-05-14 09:42:38 <ncopa> 20M
2020-05-14 09:43:31 <ncopa> the erlang modules themeslves are circular internally
2020-05-14 09:44:19 <ncopa> stdlib depends on erts which depends on stdlib for example
2020-05-14 10:07:23 <mps> yunfan: you can download kernel which fixed reboot/poweroff for A20 here http://arvanta.net/2x3d1kfg/linux-edge-5.6.9-r0.apk
2020-05-14 10:08:09 <mps> and please report to us (or to me by email) does it works on your board
2020-05-14 10:11:28 <yunfan> mps: just download and install it?
2020-05-14 10:11:33 <yunfan> no further actions?
2020-05-14 10:11:52 <yunfan> the problem is the current setup-alpine script will failed when saving to boot partitions
2020-05-14 10:12:16 <yunfan> so i guess the installing apk files will not affects when next boot
2020-05-14 10:14:47 <mps> you have to set it in extlinux.conf
2020-05-14 10:15:42 <yunfan> you mean i should download it and decompress the files
2020-05-14 10:15:54 <yunfan> and overwrite them in boot partitions?
2020-05-14 10:15:58 <mps> did you mount boot partition under /boot
2020-05-14 10:52:06 <danieli> ncopa: I've been terribly busy with work, but that could be the easy way
2020-05-14 10:52:26 <danieli> Erlang Solutions has various packages (debian among others), one of which is a monolithic erlang package and the rest is split up
2020-05-14 10:52:37 <danieli> I was thinking of looking at the dependency relations between thm
2020-05-14 10:52:40 <danieli> them*
2020-05-14 10:53:14 <danieli> also erlang 23 is out so we should get that in the next release
2020-05-14 10:53:17 <danieli> or is the next release 3.11.7?
2020-05-14 10:56:21 <ncopa> danieli: im looking into it
2020-05-14 10:56:37 <ncopa> there are a handful erlang packages that pulls in wx and odbc
2020-05-14 10:56:44 <ncopa> im splitting out those and only those
2020-05-14 10:56:54 <ncopa> rest will be a monolithic erlang package
2020-05-14 10:57:40 <ncopa> im also upgrading to 23.0 while at it
2020-05-14 10:57:49 <ncopa> and rebuild elixir and cloudi
2020-05-14 13:02:27 <Cogitri> ikke: Can you run the make-aports-public script again? :)
2020-05-14 13:05:25 <ikke> done
2020-05-14 13:06:10 <Cogitri> Thanks
2020-05-14 13:23:10 <yunfan> mps: yes
2020-05-14 13:25:38 <danieli> ncopa: not sure if we have tsung but if we do that needs to be rebuilt too
2020-05-14 13:26:52 <Cogitri> PureTryOut[m]: kmymoney fails on 3.12 aarch64: https://build.alpinelinux.org/buildlogs/build-3-12-aarch64/community/kmymoney/kmymoney-5.0.8-r0.log
2020-05-14 13:26:59 <ikke> hey, did borgbackup just succeed on armhf?
2020-05-14 13:27:17 <ikke> oh no, that was edge/community
2020-05-14 13:28:35 <PureTryOut[m]> Cogitri: yeah I noticed, no clue why the tests fail while it succeeded on different arches and same arch on edge
2020-05-14 13:28:43 <Cogitri> Hum
2020-05-14 14:00:46 <ncopa> $ git format-patch -1 --stdout | tpaste
2020-05-14 14:00:46 <ncopa> http://tpaste.us/b4L4
2020-05-14 14:02:46 <ikke> lgtm :)
2020-05-14 14:03:00 <ikke> right on point :P
2020-05-14 14:11:45 <ncopa> dependency errors on mips64: they need to be disabled, or we need to build ibus without librsvg on mips64. http://tpaste.us/1OmE
2020-05-14 14:56:30 <ikke> ncopa: did erlang-asn1 end up being bundled ?
2020-05-14 14:56:34 <ikke> tsung is missing it
2020-05-14 15:02:11 <ikke> apparently, yes
2020-05-14 15:03:18 <ikke> hmm
2020-05-14 15:03:29 <ikke> it should still be created
2020-05-14 17:07:49 <ikke> danieli: ping
2020-05-14 17:07:57 <danieli> ikke: pong
2020-05-14 17:08:23 <danieli> right, ncopa made some changes to it
2020-05-14 17:08:39 <ikke> Yes, what should they depend on now?
2020-05-14 17:08:46 <ikke> tsung is missing erlang-asn1
2020-05-14 17:08:56 <ikke> just erlang?
2020-05-14 17:09:39 <ikke> tsung already depends on erlang
2020-05-14 17:09:52 <danieli> I haven't had the time to look at his changes yet, and I don't remember how tsung is built
2020-05-14 17:10:19 <ikke> testing if it works just to remove the erlang-asn1 builddep
2020-05-14 17:10:29 <ikke> it does build, so I assume yes
2020-05-14 17:10:33 <danieli> it should if it is now included in erlang
2020-05-14 17:11:03 <ikke> It's no longer split out, so I would assume so
2020-05-14 17:14:36 <ikke> pushed a fix
2020-05-14 17:25:21 <Cogitri> I think someone has mentioned that they got an APKBUILD for ghc on aarch64 in here or in #alpine-linux , but I can't remember who that was. Does one of you happen to remember that?
2020-05-14 17:25:49 <Cogitri> Still didn't get around to looking at the GHC stuff
2020-05-14 17:42:55 <mps> Cogitri: I think cheese worked even without gsettings-desktop-schemas
2020-05-14 17:44:08 <mps> oh, it worked earlier but not now. sorry
2020-05-14 17:44:49 <Cogitri> Thanks for checking though :)
2020-05-14 17:45:14 <mps> np ;)
2020-05-14 17:54:06 <mps> (looking all this starting to think to switch to glibc based distro for desktop)
2020-05-14 18:37:39 <Cogitri> Hm, glibc is useful at times, but I want to use the same OS on all of my machines, so I'll keep using Alpine for the time being
2020-05-14 18:43:09 <dalias> there are things it would be convenient to have a glibc-based desktop distro for, but it's mostly (1) huge binary package repository from distro or (2) third-party binaries that only run easily on such a distro
2020-05-14 18:43:49 <dalias> and (1) you only get if your chosen distro is one of the big mainstream ones (mainly debian and derivatives) that's painful to use because of systemd and fdo dep-creep all over everything
2020-05-14 18:46:46 <mps> before switch to alpine (more than 2 years ago) I used debian with openrc
2020-05-14 18:47:26 <dalias> i like debian except for systemd/fdo having their fingers all in everything
2020-05-14 18:48:11 <mps> but I didn't used 'desktop environments' except xfce few years, awesome WM is quite enough for me
2020-05-14 18:48:31 <dalias> i really really dislike desktop environments
2020-05-14 18:48:37 <dalias> all the functionality is anti-functionality to me
2020-05-14 18:49:04 <mps> fully agree with you
2020-05-14 18:49:49 <artok> dwm !
2020-05-14 18:50:39 <mps> when I started to use linux (25 years ago) I mostly used fvwm
2020-05-14 18:50:43 <dalias> i don't want notification spam distracting me, don't want programs integrating with taskbar/tray/whatever, don't want inflexible gui configurators commandeering my mouse settings and messing them up, don't want drag-and-drop anywhere especially not between apps, etc.
2020-05-14 18:51:58 <dalias> drag-and-drop has got to be the single worst case of widespread bad ux with catastrophic failure modes
2020-05-14 18:52:04 <mps> but I'm in camp with people who never used windows
2020-05-14 18:52:12 <artok> actually I like to do coding with alpine + dwm and stuff, for my work, macOS does the job
2020-05-14 18:52:15 <dalias> like actually gripping your phone and trashing an app
2020-05-14 18:52:54 <dalias> well, swipe-to-delete is a comparably bad one too
2020-05-14 18:53:23 <mps> and I don't understand why linux/unix wants to emulate windows UI
2020-05-14 18:53:38 <AinNero> its worse for me, im a RTS gamer, i tend to slur clicks quite alot, i do accidental drag&drop quite often
2020-05-14 18:53:50 <maxice8> mps: is that another of your rethorical question you don't want people to answer ?
2020-05-14 18:53:56 <dalias> ainnero, and firefox *still* has no way to fully disable it
2020-05-14 18:54:06 <AinNero> i just given up
2020-05-14 18:54:10 <mps> maxice8: probably :)
2020-05-14 18:54:15 <AinNero> most of the important stuff happens in the terminal anyways
2020-05-14 18:54:15 <dalias> mps, i understand the dynamics of how it happens pretty well, i think
2020-05-14 18:54:56 <dalias> most of the newcomers are folks who used and liked windows up to version N, then they decided they hated something new in windows version N+1
2020-05-14 18:55:06 <mps> dalias: I remember your quote about that :)
2020-05-14 18:55:15 <dalias> so they're frustrated that everything isn't like version N and set out to recreate version N on linux
2020-05-14 18:55:21 <c705> vista is what flipped me over to Linux 15 years or so ago
2020-05-14 18:55:39 <dalias> now, the existing linux users are mostly happy with host stuff already is, or at least not sufficiently unhappy to dump lots of effort into change/improvement
2020-05-14 18:55:44 <c705> as much as i hate microshaft, i have to credit them to introducting me to linux
2020-05-14 18:55:51 <dalias> so the majority of effort comes from these "windows N abandoners"
2020-05-14 18:56:58 <mps> 'we are not windows but we like to pretend we are same'
2020-05-14 18:57:09 <dalias> then it turns out the old linux users actually *did* leave lots of gaps in important functionality
2020-05-14 18:57:13 <dalias> like m17n support
2020-05-14 18:57:45 <dalias> so the old software they like bitrots and is uninteresting to new users who need that functionality
2020-05-14 18:58:28 <dalias> and the new software made by the "windows N abandoners", regardless of how bad it is, thrives because it has now-essential functionality that the old users didn't deem important enough to add
2020-05-14 18:58:29 <mps> yes, this is in line with my thinking
2020-05-14 18:59:03 <dalias> and this happens in wave after wave
2020-05-14 19:02:29 <mps> in my POV most of these added functionalities are bloat
2020-05-14 19:03:30 <mps> have impression that developers are supported/payed by memory and cpu manufacturers
2020-05-14 19:03:47 <maxice8> i need a fortune for what you just said
2020-05-14 19:06:51 <Cogitri> Heh
2020-05-14 19:10:00 <Cogitri> Well, it is unfortunate that devs prioritize features over performance that much, but these days we have some really nice features I wouldn't want to miss
2020-05-14 19:10:52 <mps> hm, performance is also feature
2020-05-14 19:11:51 <AinNero> tfw i have yet to find a pdf reader that doesnt choke on my 600 page datasheets
2020-05-14 19:11:58 <AinNero> im seriously considering paying for a printout
2020-05-14 19:15:00 <mps> and I'm thinking to rebuild vim with minimum dependencies for me
2020-05-14 19:15:19 <dalias> mps, they're gamers who are paid in currency of "gpu vendors and gpu driver/software stack devs having to make the graphics stack on linux work for them because they're held hostage with core desktop software depending on it"
2020-05-14 19:15:36 <dalias> :)
2020-05-14 19:16:57 <mps> :D
2020-05-14 19:18:31 <Cogitri> Fair, performance is a feature too
2020-05-14 19:18:39 <dalias> but it's not performance
2020-05-14 19:18:41 <dalias> it's eyecandy
2020-05-14 19:18:53 <dalias> no-gpu-at-all X performs faster than gpu-accelerated-compositing-crap
2020-05-14 19:18:57 <Cogitri> And it does make me sad when GNOME Builder chokes on a 20k LOC log
2020-05-14 19:19:03 <Cogitri> But other software that's new and featureful gets it right, like VSCode
2020-05-14 19:19:16 <dalias> assuming you're not using stuff that requires faking a gpu in software
2020-05-14 19:19:44 <dalias> really all i want from the graphics stack is never to need a gpu and never to have to think about a gpu
2020-05-14 19:21:16 <ikke> hmm, interesting. kmymoney builds fine in my lxc container
2020-05-14 19:21:34 <dalias> it failed outside? or..?
2020-05-14 19:22:27 <ikke> on the builders
2020-05-14 19:22:34 <ikke> https://build.alpinelinux.org/buildlogs/build-3-12-aarch64/community/kmymoney/kmymoney-5.0.8-r0.log
2020-05-14 19:22:50 <ikke> test failures
2020-05-14 19:24:05 <ikke> the lxc container is on the same host as the builder
2020-05-14 19:27:32 <Cogitri> It works on edge too for some reason
2020-05-14 19:33:14 <ikke> yes, my lxc container is on edge
2020-05-14 19:34:04 <[[sroracle]]> maybe calm it down then :p
2020-05-14 19:34:38 <ikke> lol
2020-05-14 19:36:20 <ikke> huh
2020-05-14 19:36:41 <ikke> http://tpaste.us/pKdn
2020-05-14 19:37:16 <ikke> ohw, edge -_-
2020-05-14 19:40:13 <ikke> Cogitri: hmm, on 3-12 it fails much quicker, the build seems different
2020-05-14 19:40:45 <ikke> maybe should clean first
2020-05-14 21:54:21 <okeuday> danieli: testing/tsung does exist but needs more testing, may need changes upstream
2020-05-14 21:56:44 <okeuday> danieli: tsung isn't included with Erlang, though the Erlang Solutions packages have wrapped things into their erlang packages sometimes, they aren't official and there have been problems with the versions they pick (along with including external things into the erlang package)
2020-05-14 21:57:25 <danieli> I think there might be a misunderstanding, the tsung thing was a separate issue, I am aware it's not part of erlang :)
2020-05-14 21:58:01 <danieli> and yes, it hasn't been without trouble, but I was thinking to look at the dependency graph between their split-up packages to see how they did it
2020-05-14 22:02:42 <okeuday> just trying to avoid build problems because I have ran into the problem of external things in the erlang release, in the past (https://github.com/CloudI/CloudI/issues/174)
2020-05-14 22:07:44 <okeuday> stdlib and kernel are still circular dependencies in erlang too, in the past they have stressed how Erlang applications are separate, which is why the Erlang/OTP team at Ericsson and Erlang Solutions likely prefer having separate packages
2020-05-14 22:09:01 <okeuday> that is also how the autoconf macros exist, so that Erlang applications can be checked separately https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Erlang-Libraries.html
2020-05-14 22:10:01 <okeuday> but the circular dependencies generally make everyone use a single Erlang/OTP release, unless someone is creating a custom release of Erlang/OTP
2020-05-14 22:11:11 <okeuday> the circular dependencies would also make live upgrades problematic too, so it should be something they would want to fix gradually
2020-05-15 02:34:01 <Hello71> AinNero: zathura-pdf-mupdf usually works fine for me. it's a bit heavy on RAM, I think it never unloads rendered pages
2020-05-15 02:36:04 <Hello71> on this random 700 page textbook it uses 460 MB RSS
2020-05-15 02:36:29 <Hello71> on glibc
2020-05-15 07:36:55 <Cogitri> fabled: Are there any members on apk_package are never NULL? I've seen almost everything other than name and version being NULL already, but those two can't be NULL, or can they?
2020-05-15 07:41:58 <ikke> kmymoney tests fail on aarch64  (segfaults), but only the 3-12 builder. Not on edge or personal dev container
2020-05-15 07:43:32 <Cogitri> Huh
2020-05-15 07:45:15 <PureTryOut[m]> (I can confirm that)
2020-05-15 07:57:39 <macmpi> lbu update? Would be nice to have an option to update only a specific path/file (must be consistent with includes). In some situation one may not want to commit the whole thing. Any idea?
2020-05-15 08:26:28 <fabled> Cogitri, yes, the name and version are required to be set and included in the hash, so are always present
2020-05-15 08:28:14 <Cogitri> fabled: Okay, thanks for confirming :)
2020-05-15 08:31:49 <fabled> Cogitri, actually, it seems technically 'version' could be null. but currently the way everything is generated and parsed, rules out the possibility
2020-05-15 08:32:02 <fabled> i think also other places might not function properly if it's not there
2020-05-15 08:32:06 <fabled> so it's hard assumption
2020-05-15 08:40:33 <Cogitri> Ah okie
2020-05-15 08:41:16 <[[sroracle]]> a bit ago i showed off the script the output of the script that looks for broken dependencies (similar to apk dot --errors but across all arches and not looking for cyclic deps)
2020-05-15 08:41:47 <[[sroracle]]> i've set it up on a cronjob every 6 hours here in case anyone finds it useful https://dev.sick.bike/apkindex/alpine-deps.html
2020-05-15 08:43:35 <[[sroracle]]> the version spread examiner is less useful since i haven't made it look at $arch from the APKBUILDs so it may spuriously complain about missing packages, but it's also available https://dev.sick.bike/apkindex/alpine-versions.html
2020-05-15 08:45:19 <Cogitri> Oh, great! :)
2020-05-15 08:46:53 <[[sroracle]]> if it goes blank after i while i probably just botched the cron entry so lmk
2020-05-15 09:10:13 <clandmeter> [[sroracle]]: very nice
2020-05-15 09:13:13 <[[sroracle]]> thanks
2020-05-15 09:13:15 <clandmeter> [[sroracle]]: where are the scripts?
2020-05-15 09:13:23 <clandmeter> shell?
2020-05-15 09:13:41 <[[sroracle]]> python
2020-05-15 09:13:43 <[[sroracle]]> https://code.foxkit.us/adelie/arch-tester/tree/overhaul
2020-05-15 09:13:59 <[[sroracle]]> requires libapk and apkkit (python, available on pypi)
2020-05-15 09:14:56 <clandmeter> i think this should be part of pkgs
2020-05-15 09:15:05 <clandmeter> kind of :)
2020-05-15 09:15:17 <[[sroracle]]> hehe
2020-05-15 09:15:26 <[[sroracle]]> if i have time to learn lua i will take it on :p
2020-05-15 09:15:35 <clandmeter> haha
2020-05-15 09:15:47 <clandmeter> you can rewrite it in py ;-)
2020-05-15 09:15:54 <clandmeter> its very stupid anyways :)
2020-05-15 09:16:32 <[[sroracle]]> add it to my ever growing todo list i suppose :D
2020-05-15 09:16:50 <clandmeter> yes, i have that one too
2020-05-15 09:17:05 <clandmeter> and i dont write it down, so it never gets too long :)
2020-05-15 09:17:23 <clandmeter> one of the advantages of getting old
2020-05-15 09:18:30 <[[sroracle]]> very smart
2020-05-15 09:20:47 <clandmeter> [[sroracle]]: what is the red part?
2020-05-15 09:20:56 <clandmeter> its behind?
2020-05-15 09:26:48 <ikke> [[sroracle]]: so these are packages that would fail to rebuild?
2020-05-15 09:30:51 <[[sroracle]]> clandmeter: which red part?
2020-05-15 09:31:11 <Cogitri> What I don't get is why it complains about rust-lldb missing lldb and py3-lldb
2020-05-15 09:31:23 <[[sroracle]]> ikke: possibly. it's mostly useful as a tool for looking for things that need rebuilding or fixing
2020-05-15 09:31:38 <Cogitri> Or is it currently targeting 3.12=
2020-05-15 09:32:22 <[[sroracle]]> Cogitri: thats saying lldb is missing on armhf edge for example
2020-05-15 09:33:22 <Cogitri> Derp right, didn't look at the arch field in lldb
2020-05-15 09:33:35 <Cogitri> 
ACTION is wondering how that ever worked

2020-05-15 09:37:57 <clandmeter> [[sroracle]]: https://dev.sick.bike/apkindex/alpine-versions.html red items
2020-05-15 09:38:16 <clandmeter> i guess you compare with with the highest available version
2020-05-15 09:41:55 <[[sroracle]]> yes, exaxtly
2020-05-15 09:42:17 <[[sroracle]]> anything that is not highest version across all arches is marked in red
2020-05-15 09:42:45 <clandmeter> and these are based solely on origin i guess?
2020-05-15 09:42:49 <[[sroracle]]> (Or X mark for color blind)
2020-05-15 09:42:53 <[[sroracle]]> yes
2020-05-15 09:43:25 <clandmeter> i have been thinking of adding that to pkgs, a new index page based on origin
2020-05-15 09:43:45 <clandmeter> its a bit messy like this
2020-05-15 09:44:04 <clandmeter> list pkgs based on origin and show which arches has which version
2020-05-15 09:44:18 <[[sroracle]]> would be very cool :)
2020-05-15 09:44:53 <clandmeter> and when you search it would use the current index style to find also subpkgs
2020-05-15 09:45:25 <clandmeter> its on that not written down todo list of mine.
2020-05-15 09:45:55 <[[sroracle]]> i might take a look this weekend if i get tired of other projects
2020-05-15 09:46:01 <[[sroracle]]> will let you know
2020-05-15 09:48:15 <ncopa> anybody knows why elixir hangs on the builders?
2020-05-15 09:48:21 <ncopa> does not happen in my dev env
2020-05-15 09:48:55 <ikke> random guess: lack of tty?
2020-05-15 09:49:27 <ikke> number of jobs?
2020-05-15 09:49:38 <clandmeter> ncopa: did you check your emails?
2020-05-15 09:49:44 <clandmeter> reg uacme
2020-05-15 09:50:14 <clandmeter> your question is finally aswered  :)
2020-05-15 10:00:39 <ncopa> thanks! makes sense
2020-05-15 15:01:25 <danieli> is elixir hanging?
2020-05-15 15:04:42 <Cogitri> Yup, ncopa mentioned it a few hours ago
2020-05-15 15:11:53 <ikke> He said it only happened on the builders apparently
2020-05-15 17:40:45 <Thermi> ncopa: Any idea regarding the issue with gsoap? I haven't gotten any reply or any help with that yet. https://gitlab.alpinelinux.org/alpine/aports/-/issues/11511
2020-05-15 17:42:33 <oneinsect> btw ca-certificates is now compiling
2020-05-15 17:42:37 <oneinsect> i dont know if you guys noticed
2020-05-15 17:42:50 <oneinsect> the git url for download link goes 404
2020-05-15 17:42:59 <oneinsect> is NOT*
2020-05-15 17:43:20 <ikke> I guess we haven't noticed :)
2020-05-15 17:43:29 <oneinsect> lol
2020-05-15 17:44:13 <oneinsect> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/ca-certificates/APKBUILD
2020-05-15 17:44:15 <oneinsect> source="https://git.alpinelinux.org/ca-certificates/snapshot/ca-certificates-$pkgver.tar.xz
2020-05-15 17:44:24 <ikke> aha, right
2020-05-15 17:44:25 <oneinsect> the source is link throws 404
2020-05-15 17:44:40 <oneinsect> why arent you noticing it during releasing new builds?
2020-05-15 17:44:50 <ikke> because that only broke this week
2020-05-15 17:44:55 <oneinsect> lol
2020-05-15 17:45:00 <ikke> and that package was built last week
2020-05-15 17:45:05 <oneinsect> it was wreaking my porting work
2020-05-15 17:45:21 <oneinsect> btw when is the shift to gcc 10.1
2020-05-15 17:45:33 <ikke> after the release of 3.12 I assume
2020-05-15 17:45:42 <oneinsect> its working very well
2020-05-15 17:45:44 <oneinsect> 10.1
2020-05-15 17:46:04 <ikke> yes, but we are not going to chang ethe toolchain for 3.12
2020-05-15 17:46:12 <oneinsect> hmmm
2020-05-15 19:03:22 <andypost[m]> Something wrong with 3.11 builders (armv7, armhf) it does not pick build jobs
2020-05-15 19:05:06 <ikke> algitbot: retry 3.11-stable
2020-05-15 19:05:23 <ikke> they are running now
2020-05-15 19:06:15 <andypost[m]> ikke: thank you) I missed about it
2020-05-15 20:18:45 <wsinatra> Is there a good way to have a package depend on any lua version?
2020-05-15 20:19:18 <wsinatra> ie: Fennel runs with Lua 5.1, 5.2, 5.3, 5.4, & jit. Is there a way to have a package depend on any one if they're installed?
2020-05-15 20:19:45 <wsinatra> or would I rather need to have something like fennel-jit for a jit backed version, and fennel-lua53 for a lua5.3 version
2020-05-15 20:19:47 <mps> lua=>5.1
2020-05-15 20:20:11 <wsinatra> seriously? that's dead simple, I love it
2020-05-15 20:20:57 <mps> '>='
2020-05-15 20:21:27 <mps> main/dejagnu/APKBUILD:makedepends="tcl>=8.5"
2020-05-15 20:29:56 <dalias> :)
2020-05-15 21:59:45 <hbug___> talked about a problem with chwon overflowing on #openwrt a few days ago. i now reproduced it with an official image.
2020-05-15 22:02:12 <dalias> ?
2020-05-15 22:02:57 <hbug___> OpenWrt 19.07.2 - ARMv7 - AVM FRITZ!Box 4040 - chown overflows on 65536 / 16bit . can someone reproduce on an armv7 device?
2020-05-15 22:03:26 <dalias> what do you mean by "chown overflows" ?
2020-05-15 22:03:38 <hbug___> chwon 65540 $file results in uid 4 on $file.
2020-05-15 22:03:39 <dalias> uids >= 65536 aren't working?
2020-05-15 22:03:52 <dalias> can you strace it?
2020-05-15 22:05:44 <hbug___> or maybe it gets misrepresented by 'ls' ?
2020-05-15 22:06:56 <dalias> run it under strace to see
2020-05-15 22:07:52 <hbug___> dalias: hm.. strace seems fine > https://paste.debian.net/1146979/
2020-05-15 22:09:52 <AinNero> hbug___: i would assume its perfectly valid to block out changes to the bits above the first 16
2020-05-15 22:09:55 <hbug___> dalias: i'm impressed. this is totally the wrong channel. it's to late. wanted to ask in #openwrt-devel .. thatnks fo the help anyways.
2020-05-15 22:10:02 <dalias> :)
2020-05-15 22:10:13 <AinNero> hbug___: do you want to change the type of a file?
2020-05-15 22:10:34 <AinNero> its probably the S_IFMT mask taking effect
2020-05-15 22:10:43 <dalias> ?
2020-05-15 22:11:00 <AinNero> oh
2020-05-15 22:11:05 <AinNero> misread as chmod, fuck
2020-05-15 22:11:09 <dalias> :)
2020-05-15 22:11:18 <hbug___> sorry for being an idiot.
2020-05-15 22:11:27 <dalias> maybe ls is broken. maybe stat is broken
2020-05-15 22:14:23 <wsinatra> If anyone is still looking at MRs, could they take a look at !7932, trying to get something into community and just want to make sure I did it right
2020-05-15 22:14:35 <wsinatra> hopefully the first of many, since I'm sitting on about a dozen in testing..
2020-05-15 22:17:07 <Hello71> hbug___: maybe your ls is broken
2020-05-15 22:18:14 <Hello71> in particular, if you need chown32, then you probably also need stat64
2020-05-15 22:18:32 <Hello71> and if you compile without LFS then you may use original stat
2020-05-15 22:19:03 <dalias> hello71, that's legacy glibc/uclibc stuff, not relevant to musl (and never has been)
2020-05-15 22:19:22 <Hello71> oh, that's a good point
2020-05-15 22:19:29 <Hello71> I thought they were using uclibc
2020-05-15 22:19:43 <dalias> no, openwrt switched a few years back
2020-05-15 22:19:51 <Hello71> yeah, I remember now
2020-05-15 22:20:02 <Hello71> I think it was only released in 19.07 though?
2020-05-15 22:20:09 <Hello71> and per-target?
2020-05-15 22:20:48 <Hello71> I guess it could still theoretically be an ancient ls, but probably not
2020-05-15 22:23:12 <hbug___> i can't quite follow you i think. should i move this question to #openwrt or is it okey to continue here? don't want to spam.
2020-05-15 22:25:36 <hbug___> both the coreutils ls v8.30  and ls from BusyBox v1.30.1 show the wrong value.
2020-05-15 22:29:55 <dalias> hbug___, ok
2020-05-15 22:30:26 <dalias> i dont mind continuing here but if you're not seeing it on alpine then #openwrt is probably a better venue
2020-05-16 00:09:40 <AinNero> requesting moderation in #alpine-linux
2020-05-16 02:20:04 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/5870 is it possible to land this in 3.12? I know it's a bit late, but basically all other distros have this functionality
2020-05-16 02:20:18 <Hello71> Ariadne: ^
2020-05-16 02:27:13 <Ariadne> no objections if fabled is ok with it
2020-05-16 08:21:28 <ncopa> Thermi: no idea. please ping me on monday
2020-05-16 10:02:21 <clandmeter> 
ACTION grabs popcorn while reading backlog of #alpine-linux 

2020-05-16 10:38:05 <ScrumpyJack> o/
2020-05-16 10:45:41 <mps> clandmeter: you can participate even, not only passively watch :)
2020-05-16 10:46:21 <clandmeter> I can't go back in time. Not yet...
2020-05-16 10:48:59 <mps> just write few msgs with 'f**k' and 'time' will come ;)
2020-05-16 10:53:01 <clandmeter> Ariadne: thx for taking care of it.
2020-05-16 10:53:38 <Ariadne> it would be nice to expand the moderation team to cover timezones other than europe
2020-05-16 11:25:58 <clandmeter> Agree
2020-05-16 11:26:13 <clandmeter> I will see if I can support that
2020-05-16 12:22:16 <yunfan> mps: i had just downloaded the linux apk you mentioned, should i extract it and re-create the iniramfs or just put it into alpine's apk directory?
2020-05-16 12:23:52 <mps> yunfan: if you installed alpine in sys mode you can simply 'apk add --allow-untrusted filename.apk' and edit your u-boot config
2020-05-16 12:24:10 <mps> extlinux.conf, probably
2020-05-16 12:24:49 <yunfan> mps: otherwise, i should re-create initramfs?
2020-05-16 12:25:15 <yunfan> i wonder the setup script wont recognize my secondary partition in the sdcard
2020-05-16 12:25:50 <mps> no, linux-edge will create initramfs-edge
2020-05-16 12:26:32 <mps> apk add will trigger creation of proper initramfs
2020-05-16 12:27:06 <yunfan> ok trying now
2020-05-16 12:29:30 <mps> (I think I should create disk image (ok. mmc card) ready to be untared and put somewhere if someone give me free space on not slow link)
2020-05-16 12:31:15 <mps> yunfan: when you install linux-edge you should have vmlinuz-edge, initramfs-edge files and dtbs-edge dir in /boot
2020-05-16 12:32:27 <yunfan> mps: but the current situation is all my writing havnt be saved to the mmc
2020-05-16 12:32:45 <yunfan> so in the next boot, i still need enter a full brand new alpine
2020-05-16 12:33:08 <mps> ah, then you have first to install on mmc or usb in sys mode
2020-05-16 12:33:54 <mps> I could try to create u-boot-tarball for alpine but this will take time
2020-05-16 12:34:22 <yunfan> dont worry, will try to install in sys mode first, i have a spare time now, the baby just stoped crying
2020-05-16 12:39:44 <mps> hm, install by setup-alpine doesn't work because syslinux apk is not available on arms
2020-05-16 12:39:57 <mps> in sys mode, I mean
2020-05-16 12:41:10 <yunfan> why? the extlinux is the same , right?
2020-05-16 12:41:18 <mps> right
2020-05-16 12:41:50 <mps> but setup-disk script exit because can't find syslinux apk
2020-05-16 12:42:18 <yunfan> so i could do that by manmal ?
2020-05-16 12:43:18 <mps> yes, manual will work (talking from experience :) ) but require some time and 'trial and error' method
2020-05-16 12:46:57 <yunfan> aha, i got to know why all my setting lost, i havnt do lbu_commit
2020-05-16 12:47:07 <yunfan> this is important for mmc user
2020-05-16 12:49:02 <mps> sure :)
2020-05-16 12:56:54 <yunfan> the armbian used to destroy the sdcard filesystem on my rpi zero in just a week
2020-05-16 13:12:10 <wsinatra> does anyone know why lua5.1 is the only package to provide /usr/bin/lua?
2020-05-16 13:12:16 <yunfan> failed,
2020-05-16 13:12:22 <yunfan> will wait for the next release mps
2020-05-16 13:12:35 <yunfan> and currently , i just use lbu :D
2020-05-16 13:52:31 <yunfan> just installed k3s on my cubieboard , and run a alpine inside it :D
2020-05-16 13:52:37 <yunfan> mps: this is great
2020-05-16 15:20:53 <nmeum> what is our current policy on package upgrades when we are close to a new release? can I just push upgrades for main/ and community/ packages as I see fit?
2020-05-16 15:21:21 <ikke> the toolchain is frozen
2020-05-16 15:21:39 <ikke> The rest is under descretion, as long as it does not require major rebuilds
2020-05-16 15:22:47 <nmeum> what exactly falls under the definition of "toolchain"? just the C toolchain?
2020-05-16 15:23:48 <ikke> https://lists.alpinelinux.org/~alpine/devel/%3C20200429103645.19e83fe8%40ncopa-desktop.copa.dup.pw%3E
2020-05-16 15:24:29 <nmeum> yeah saw that mail
2020-05-16 17:40:25 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11528
2020-05-16 17:40:40 <nmeum> don't have permissions to move issues but maybe someone could move that to the infastructure group?
2020-05-16 18:05:34 <timlegge> mps: I changed  !7944 to testing as suggested.
2020-05-16 18:22:05 <mps> timlegge: merged
2020-05-16 18:22:20 <timlegge> thanks
2020-05-16 18:22:39 <mps> when it finish on builders you can create MR to move it to community
2020-05-16 18:23:10 <mps> timlegge: you're welcome :)
2020-05-17 07:49:02 <oneinsect> are you guys still mirring on github?
2020-05-17 07:49:40 <ikke> I think clandmeter set that up again yesterday
2020-05-17 07:50:02 <oneinsect> okie
2020-05-17 07:50:04 <clandmeter> today :)
2020-05-17 07:50:10 <ikke> yes, was about to correct that
2020-05-17 07:51:06 <oneinsect> good its important we keep them at multiple places
2020-05-17 07:53:29 <oneinsect> the newer versions of apk-tools use lua to generate help?
2020-05-17 07:53:47 <oneinsect> genhelp.lua
2020-05-17 07:54:50 <ikke> Apparently
2020-05-17 07:56:06 <oneinsect> hmmm
2020-05-17 07:56:15 <Cogitri> Yup
2020-05-17 07:56:19 <Cogitri> So we don't have to keep the manpages and help text in sync
2020-05-17 07:56:25 <oneinsect> its causing errors while bootstrapping
2020-05-17 07:56:34 <oneinsect> the older ones work just fine
2020-05-17 07:58:17 <Cogitri> What errors?
2020-05-17 07:58:41 <ikke> I guess lua not being available
2020-05-17 08:02:50 <oneinsect> https://github.com/alpinelinux/apk-tools/blob/master/src/genhelp.lua
2020-05-17 08:02:55 <oneinsect> for example on the top #!/usr/bin/lua5.3
2020-05-17 08:03:03 <oneinsect> sometimes we have only #!/usr/bin/lua
2020-05-17 08:03:14 <oneinsect> we are hardcoding version numbers
2020-05-17 08:03:50 <Ariadne> add lua5.3 to makedepends_host
2020-05-17 08:03:58 <Ariadne> but
2020-05-17 08:04:03 <Ariadne> we haven't released any new apk-tools
2020-05-17 08:04:12 <Ariadne> genhelp.lua is part of 2.11
2020-05-17 08:04:24 <oneinsect> i know but just saying
2020-05-17 08:04:35 <oneinsect> lua5.3-lzlib, it is not able to find lzlib even though i install using luarocks
2020-05-17 08:05:03 <Ariadne> apk add lua5.3-zlib
2020-05-17 08:06:06 <oneinsect> yes but for bootstrapping, it would help if we remove dependencies on lua, i mean just a suggestion
2020-05-17 08:06:24 <oneinsect> make it easier to build like 2.10, the make command just works
2020-05-17 08:07:11 <ikke> They need something to generate the help structures from the manpages, and sh is not going to cut it
2020-05-17 08:07:30 <oneinsect> i mean apk-tools and abuild are the heart of porting work, if they can compile easily with minimal dependencies it would help
2020-05-17 08:07:42 <oneinsect> just a suggestion though
2020-05-17 08:07:52 <ikke> It would be nice if there was an option to disable it though
2020-05-17 08:07:57 <ikke> at least for bootstrapping
2020-05-17 08:08:01 <oneinsect> yes atleast an option to disable
2020-05-17 08:08:12 <oneinsect> please that save us the mere mortals
2020-05-17 08:08:14 <ikke> I guess open an issue
2020-05-17 08:13:47 <oneinsect> opened issue here
2020-05-17 08:13:48 <oneinsect> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10696
2020-05-17 08:14:06 <Ariadne> why?
2020-05-17 08:14:11 <Ariadne> we can just add lua to the bootstrap
2020-05-17 08:14:15 <Ariadne> it is not a problem
2020-05-17 08:16:15 <oneinsect> sometimes we dont need lua, and we have unnecessarily add it just for building apk-tools
2020-05-17 08:16:20 <oneinsect> have to*
2020-05-17 08:17:22 <Ariadne> you are aware that making it optional eliminates the entire help system right
2020-05-17 08:17:28 <oneinsect> on smaller machines with smaller ram, it would help Ariadne: where every ounch of space counts
2020-05-17 08:17:35 <oneinsect> only for the first time bootstrap
2020-05-17 08:17:49 <Ariadne> oneinsect: i literally work for a company that builds alpine-derived firmware, please don't use that argument :)
2020-05-17 08:17:57 <oneinsect> alright
2020-05-17 08:18:13 <oneinsect> :D
2020-05-17 08:18:25 <oneinsect> i have to find ways to convince you
2020-05-17 08:18:55 <oneinsect> to be honest and truthful it doesnt matter for musl
2020-05-17 08:19:19 <oneinsect> it matters for glibc port which is not a concern for you guys
2020-05-17 08:19:46 <oneinsect> but it would help
2020-05-17 08:19:55 <Ariadne> why does it matter for glibc port?
2020-05-17 08:20:07 <Ariadne> note that alpine is unlikely to ever ship a "glibc port"
2020-05-17 08:20:12 <oneinsect> i know
2020-05-17 08:20:50 <oneinsect> because i know existing fedora or debian to build a minimal bootstrap image and using that i rebuild the images
2020-05-17 08:20:52 <Ariadne> and the new help system uses less space than the current one anyway
2020-05-17 08:21:23 <oneinsect> the master apk-tools throws errors
2020-05-17 08:27:06 <ikke> apparently it builds just fine without lua, just gives some warnings
2020-05-17 08:32:08 <oneinsect> on alpine it builds
2020-05-17 08:32:26 <oneinsect> my bad
2020-05-17 08:32:27 <Ariadne> humm is it known issue that qemu is not sdl-enabled anymore
2020-05-17 08:32:35 <oneinsect> it builds even without lua?
2020-05-17 08:34:25 <ikke> it does need lua-dev
2020-05-17 08:35:25 <Cogitri> Ariadne: I think we build with gtk instead?
2020-05-17 08:35:30 <Ariadne> i figured it out
2020-05-17 08:36:36 <oneinsect> okie
2020-05-17 08:38:41 <oneinsect> it doesnt build on fedora even with lua, but its okie please consider that whenever you have if you its worth spending on thanks Ariadne:
2020-05-17 08:38:51 <oneinsect> you have time*
2020-05-17 08:38:58 <oneinsect> if you think*
2020-05-17 08:39:13 <oneinsect> spending time*
2020-05-17 08:44:20 <Ariadne> build log ?
2020-05-17 08:45:30 <oneinsect> https://ctxt.io/2/AADADBoGFA
2020-05-17 08:46:06 <oneinsect> Ariadne: sorry did you ask me?
2020-05-17 08:46:16 <oneinsect> or Cogitri ?
2020-05-17 08:46:30 <Ariadne> you
2020-05-17 08:46:51 <oneinsect> so yes i do a chmod +x to that lua file and then this happens
2020-05-17 08:46:53 <Ariadne> i have managed to boot a linux system in qemu riscv64
2020-05-17 08:46:55 <Ariadne> this is painful
2020-05-17 08:47:28 <oneinsect> https://ctxt.io/2/AADAKGxcFA
2020-05-17 08:48:24 <Ariadne> yes, you pasted that already
2020-05-17 08:48:25 <oneinsect> and so i replace the top line of genhelp.lua from /usr/bin/lua5.3 to /usr/bin/lua and then this happens
2020-05-17 08:48:29 <Ariadne> please attach it to your bug
2020-05-17 08:48:36 <oneinsect> i mean the errors are different
2020-05-17 08:48:43 <oneinsect> i will attach them now
2020-05-17 08:51:52 <Ariadne> lollllllllll
2020-05-17 08:51:56 <Ariadne> i cannot even ssh into this
2020-05-17 08:51:59 <Ariadne> great stuff
2020-05-17 08:52:55 <Cogitri> oneinsect: For the package lua 5.3 not found:. Do `make LUAAPK=""`
2020-05-17 08:53:24 <oneinsect> let me try
2020-05-17 08:54:56 <Ariadne> right
2020-05-17 08:55:02 <Ariadne> 
ACTION gives up on riscv again

2020-05-17 08:57:23 <oneinsect> complete errors of different runs
2020-05-17 08:57:24 <oneinsect> https://ctxt.io/2/AADADLpCFA
2020-05-17 08:57:31 <oneinsect> attaching that file to that issue
2020-05-17 08:59:18 <oneinsect> done attached log file
2020-05-17 09:01:37 <nmeum> Ariadne: what issue are you having with risc-v?
2020-05-17 09:02:36 <Ariadne> nmeum: well, i would like to start getting the bits together to enable a proper bootstrap (such as porting libucontext), but qemu-system-riscv64 is hopeless
2020-05-17 09:04:11 <nmeum> what exactly is your issue with qemu?
2020-05-17 09:04:35 <nmeum> I used qemu-system-riscv64 successfully with riscv64 in the past
2020-05-17 09:04:46 <nmeum> s/with riscv64/with linux/
2020-05-17 09:04:46 <alpine-meetbot> nmeum meant to say: I used qemu-system-riscv64 successfully with linux in the past
2020-05-17 09:05:16 <Ariadne> nmeum: sshd crashes on the debian images
2020-05-17 09:07:29 <Ariadne> and well, no sshd means no workable dev environment to make libucontext work :p
2020-05-17 09:08:17 <nmeum> I think you should blame debian instead of risc-v then :p
2020-05-17 09:11:03 <Ariadne> well if there is an alpine environment for qemu riscv64 already :)
2020-05-17 09:11:15 <Ariadne> i guess there is the stuff devault did
2020-05-17 09:15:51 <nmeum> or just use busybox telnetd instead of ssh in your qemu guest :D
2020-05-17 09:16:44 <nmeum> my day job is riscv related so I also always wanted to port alpine to it but haven't really gotten around to it yet
2020-05-17 09:16:56 <mps> or dropbear ssh
2020-05-17 09:20:09 <Ariadne> nmeum: my day job is interested in risc-v custom silicon
2020-05-17 09:20:40 <Ariadne> mostly because mips is dead lolz
2020-05-17 09:20:56 <Ariadne> well, loongson might give it some life
2020-05-17 09:25:30 <nmeum> ah, but if you need help with porting alpine to risc-v at some point let me know
2020-05-17 09:27:15 <Ariadne> hardwareeeeee
2020-05-17 09:28:37 <nmeum> I still waiting for my hifive unleashed
2020-05-17 09:28:40 <nmeum> *am
2020-05-17 09:29:26 <Ariadne> :D
2020-05-17 09:29:31 <Ariadne> welcome to my world
2020-05-17 09:31:40 <oneinsect> give me a pass for your world
2020-05-17 09:49:04 <Ariadne> haha need to be able to adapt improvise and overcome first
2020-05-17 10:33:16 <Cogitri> Does `gpg_signature_extensions` and `gpgfingerprints` do something in APKBUILDs?
2020-05-17 10:35:56 <ikke> That's something that tcely tried to introduce iirc
2020-05-17 10:37:23 <Cogitri> Ah, just curious since the linter warns about it and I don't find references about it anywhere
2020-05-17 10:39:01 <ikke> it can be savely removed
2020-05-17 10:39:45 <Cogitri> Alright, thanks for confirming
2020-05-17 10:40:38 <ikke> If we want GPG key verification, it needs to first built into abuild
2020-05-17 10:46:28 <Cogitri> Probably not worth it with the tiny amount of upstreams offering it
2020-05-17 10:46:47 <ikke> nod
2020-05-17 12:23:12 <hjaekel> Are there any known issues with the build servers? Cogitri merged my MR !7817, where some libraries were moved to community, but they are not available in community on all platforms, e.g. https://pkgs.alpinelinux.org/packages?name=cfitsio-dev
2020-05-17 12:24:42 <hjaekel> can we just restart the build process? I cannot even find the logs to see what went wrong
2020-05-17 12:28:19 <Cogitri> hjaekel: The mips64 builder is down right now, s390x is choking on py3-pygit2 and apparently python3 is stuck again on aarch64
2020-05-17 12:28:51 <Cogitri> Seems like armhf is down for edge too? (cc ikke)
2020-05-17 12:29:34 <Cogitri> So nothing much that can be done from your side unfortunately, hjaekel
2020-05-17 12:29:50 <Cogitri> I guess aarch64 might fix itself on a 2nd test run of py3?
2020-05-17 12:37:04 <hjaekel> OK thank you for the information Cogitri
2020-05-17 12:38:26 <hjaekel> I created MR for a version upgrade on gdal, but the CI pipeline fails because of missing libraries on aarch64
2020-05-17 12:48:12 <ikke> Cogitri: I think it's stuck on python
2020-05-17 12:49:27 <ikke> It's at least continuing now
2020-05-17 13:10:35 <kaey> somebody press merge button please !7481
2020-05-17 13:11:05 <kaey> i think everyone should be able to remove S-changes-requested label, using bot or something
2020-05-17 13:15:43 <ikke> It will be merged as soon as the pipeline succeeds
2020-05-17 13:16:50 <ikke> merged
2020-05-17 13:17:20 <mps> kaey: looks like it is merged
2020-05-17 13:17:27 <mps> ahm
2020-05-17 13:17:31 <ikke> :()
2020-05-17 13:17:50 <mps> :)
2020-05-17 13:34:17 <kaey> Thanks. Also filed "label" issue in alpine/infra
2020-05-17 14:17:40 <ikke> fyi, restarting gitlab to upgrade to latest patch release
2020-05-17 14:19:17 <Cogitri> Okie, can you run the make-forks-public script afterwards? :)
2020-05-17 14:19:24 <ikke> nod
2020-05-17 14:20:51 <Cogitri> Thanks!
2020-05-17 14:22:47 <ikke> gitlab is running again
2020-05-17 14:23:02 <ikke> script has run
2020-05-17 14:23:33 <Cogitri> Phew, that was quick! :)
2020-05-17 14:24:55 <artok> that's what ladies say to me
2020-05-17 14:25:15 <ikke> *sad trombone*
2020-05-17 14:25:35 <oneinsect> lol
2020-05-17 14:25:41 <oneinsect> the ladies
2020-05-17 14:28:12 <Cogitri> lol
2020-05-17 15:33:47 <mps> tpaste.us should return https instead of http. who can fix it?
2020-05-17 15:35:18 <ikke> You: https://gitlab.alpinelinux.org/alpine/infra/turbo-paste :P
2020-05-17 15:42:44 <mps> ah, didn't know :) thanks for info
2020-05-17 16:09:48 <mps> ikke: https://gitlab.alpinelinux.org/alpine/infra/turbo-paste/-/blob/master/turbo-paste.lua#L18
2020-05-17 16:10:11 <mps> does that means it is configured by start script?
2020-05-17 16:12:08 <ikke> yes
2020-05-17 16:13:08 <mps> so, someone with access to server have to change it
2020-05-17 16:28:21 <nmeum> I always used tpaste with `sed 's|^http://|https://|'` for this reason :D
2020-05-17 16:31:12 <clandmeter> nmeum: try now
2020-05-17 16:31:19 <clandmeter> mps: ^
2020-05-17 16:31:50 <ikke> clandmeter: ah, you were ahead of me, I was just looking :)
2020-05-17 16:31:59 <ikke> where did you change it?
2020-05-17 16:32:08 <mps> echo 'try now' | tpaste => https://tpaste.us/8XYK
2020-05-17 16:32:27 <mps> now works fine :)
2020-05-17 16:32:30 <clandmeter> ssh tpaste.us and change .env file
2020-05-17 16:32:41 <ikke> ah
2020-05-17 16:32:45 <nmeum> thanks for changing that :)
2020-05-17 16:32:49 <mps> I don't have ssh access there
2020-05-17 16:32:51 <ikke> I was already looking at the compose project
2020-05-17 16:33:31 <clandmeter> i guess if we move it to ansible we can include those vars in the compose
2020-05-17 16:35:13 <hicham> clandmeter, Hello, are you the maintainer of lxqt ?
2020-05-17 16:51:29 <clandmeter> no
2020-05-17 16:51:37 <clandmeter> i dont think so
2020-05-17 18:06:16 <Cogitri> I think aarch64-edge is still stuck on py3
2020-05-17 18:06:50 <nmeum> that would explain why py3-pygit2 hasn't failed on it yet
2020-05-17 18:41:04 <oneinsect> guys
2020-05-17 18:41:06 <oneinsect> https://irclogs.alpinelinux.org/
2020-05-17 18:41:13 <oneinsect> is that correct url for irc logs?
2020-05-17 18:41:36 <oneinsect> thanks got it
2020-05-17 19:00:37 <Cogitri> fabled: Available for a question or two about apk?
2020-05-17 19:42:19 <mps> strace from rngd https://tpaste.us/V4L0
2020-05-17 19:42:54 <mps> is that musl issue or the program bug
2020-05-17 19:43:56 <mps> this look suspicious 'rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0'
2020-05-17 19:44:45 <mps> in dmesg I see 'traps: rngd[6475] general protection fault ip:7fed096772df sp:7ffe1f223078 error:0 in ld-musl-x86_64.so.1[7fed09670000+47000]'
2020-05-17 19:52:52 <Cogitri> Does it dump core?
2020-05-17 19:54:59 <mps> no
2020-05-17 19:55:26 <mps> maybe I should build it with debug symbols
2020-05-17 19:56:59 <dalias> mps, what is the problem?
2020-05-17 19:57:34 <mps> dalias: rngd segfault
2020-05-17 19:58:39 <dalias> the tpaste has no segfault
2020-05-17 19:58:51 <dalias> was it a child process that faulted and no -f in the strace?
2020-05-17 19:59:43 <mps> I get 'Segmentation fault' on console
2020-05-17 20:00:48 <mps> here is strace output with '-f' https://tpaste.us/mELR
2020-05-17 20:09:24 <mps> I don't have experience in debuging threads
2020-05-17 20:20:52 <mps> hm, I see in dmesg 'DVB: Unable to find symbol r820t_attach()' when inserting this Realtek RTL2832 (DVB-T) device to usb port, but anyway rngd shouldn't segfault because that
2020-05-17 20:35:04 <artok> what are ns1.alza.is, stz-bg.com, adelaidewebsites.com.au that alpine rpi installation is connecting to?
2020-05-17 20:36:50 <dalias> it's a child process not a thread that's crashing
2020-05-17 20:37:44 <mps> ah, forked child?
2020-05-17 20:38:26 <dalias> yeah
2020-05-17 20:39:14 <mps> but it is not musl bug? I think it is not
2020-05-17 20:39:26 <dalias> i doubt it is. there's no way to tell from the strace
2020-05-17 20:39:39 <dalias> most likely is they passed a null pointer somewhere
2020-05-17 20:39:45 <dalias> since the crash is a null pointer deref
2020-05-17 20:39:47 <mps> ok, I will report this upstream
2020-05-17 20:42:02 <mps> thanks for help
2020-05-17 21:23:50 <Cogitri> ikke: Can we kill python3 on aarch64-edge?
2020-05-17 21:24:37 <ikke> yes
2020-05-17 21:24:57 <Cogitri> Thanks :)
2020-05-17 21:25:14 <Cogitri> Hopefully it works on 2nd try
2020-05-17 21:27:15 <ikke> I think it will just continue
2020-05-17 21:28:08 <ikke> I killed a subprocess
2020-05-17 21:29:36 <ikke> finished
2020-05-17 21:29:54 <Cogitri> Nice
2020-05-17 21:31:30 <ikke> seems to happen more often, a subprocess that is stuck (I guess dead-lock). Killing it will let the rest continue
2020-05-18 00:38:15 <Ariadne> is it just me or is gitlab slow right now
2020-05-18 00:50:20 <maxice8> Seems to be fine to me when a navigating the webUI
2020-05-18 01:19:48 <Ariadne> well
2020-05-18 01:20:00 <Ariadne> that was a huge pain in the ass but i managed to flash riscv64 CPU core to an FPGA
2020-05-18 01:20:22 <Ariadne> and boot to the port devault made
2020-05-18 01:20:34 <maxice8> sounds fancy
2020-05-18 01:21:43 <dalias> uhg, nginx package is shipping an index.html file and overwrites your site when you upgrade...
2020-05-18 01:21:54 <dalias> WHY
2020-05-18 01:22:44 <Ariadne> :D :D :D :D :D :D :D :D :D :D
2020-05-18 01:23:30 <Ariadne> he did not build nano
2020-05-18 01:23:32 <Ariadne> that dick
2020-05-18 01:24:11 <Ariadne> dalias: while i have you here, ucontext.h definition of makecontext disagrees with other archs on riscv
2020-05-18 01:24:17 <Ariadne> dalias: should i send you a patch for that :p
2020-05-18 01:25:47 <dalias> makecontext? or ucontext_t ?
2020-05-18 01:26:31 <dalias> makecontext signature is not something that can vary by arch
2020-05-18 01:27:23 <Ariadne> dalias: on riscv64, /usr/include/ucontext.h defines as makecontext(void)
2020-05-18 01:27:29 <Ariadne> when should be makecontext()
2020-05-18 01:27:46 <Ariadne> erf
2020-05-18 01:27:49 <Ariadne> void (*)()
2020-05-18 01:27:54 <Ariadne> vs void (*)(int)
2020-05-18 01:28:01 <Ariadne> look i'll just make a patch lol
2020-05-18 01:28:10 <dalias> there is no arch-specific file here
2020-05-18 01:28:22 <dalias> so i'm confused
2020-05-18 01:28:43 <Ariadne> humm
2020-05-18 01:28:54 <Ariadne> maybe it is because this riscv64 build uses an old musl
2020-05-18 01:29:01 <dalias> this has never changed
2020-05-18 01:29:12 <dalias> oh no sorry it did
2020-05-18 01:29:18 <dalias> a year ago
2020-05-18 01:29:26 <Ariadne> yeah
2020-05-18 01:29:28 <Ariadne> that explaisn it
2020-05-18 01:29:30 <Ariadne> nevermind :)
2020-05-18 01:29:33 <dalias> commit e8e780af9865edbc0495aed326a736d013ef7168
2020-05-18 01:34:57 <Ariadne> god this FPGA is slow
2020-05-18 01:35:09 <Ariadne> an amazing 400mhz
2020-05-18 01:37:24 <dalias> lol
2020-05-18 01:37:43 <dalias> bogomips  30.51
2020-05-18 07:38:50 <PureTryOut[m]> Could someone review/merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7080?
2020-05-18 07:41:46 <ikke> apaprently alreadyde
2020-05-18 07:41:50 <ikke> already done*
2020-05-18 07:44:47 <PureTryOut[m]> Thanks
2020-05-18 08:15:20 <maxwell-k> Cogitri: thanks for looking at !7979
2020-05-18 08:15:44 <maxwell-k> to broaden out the conversation there - what is the right way to handle parts of a failing test suite?
2020-05-18 08:16:15 <Cogitri> I'd say:
2020-05-18 08:16:34 <Cogitri> 1) Check if it's on us (e.g. because we packaged it wrong)
2020-05-18 08:17:18 <Cogitri> 2) If unsure or it's not on us, then contact upstream
2020-05-18 08:18:03 <maxwell-k> its something I struggle with, there are so many test suites disabled with options="!check"
2020-05-18 08:19:02 <maxwell-k> do we track conversations with upstream anywhere? maybe link to the issue somewhere or..?
2020-05-18 08:19:57 <Cogitri> I guess we link to it in the MR were we discuss it
2020-05-18 08:20:08 <Cogitri> If the tests stay disabled, I'd link the discussion in the APKBUILD
2020-05-18 08:40:59 <ncopa> i dont think we should simply disable tests
2020-05-18 08:41:05 <ncopa> morning btw..
2020-05-18 08:41:18 <Cogitri> Morning
2020-05-18 08:41:22 <ncopa> i mean, we can disable tests as an emergency response
2020-05-18 08:41:34 <maxwell-k> ncopa: do you prefer `options="!check"`
2020-05-18 08:41:35 <Cogitri> Yes, disabling the tests defeats the purpose of the tests
2020-05-18 08:41:35 <maxwell-k> ?
2020-05-18 08:42:00 <ncopa> i prefer disable the package for the architecture that fails
2020-05-18 08:42:40 <ncopa> if tests fails, then the package likely does not work
2020-05-18 08:43:10 <ncopa> so, i think we should try fix the issue rather than ship a broken package
2020-05-18 08:43:33 <maxwell-k> there were already failing on the git snapshot we ship
2020-05-18 08:43:46 <maxwell-k> I have just highlighted the issue
2020-05-18 08:44:55 <ncopa> hum
2020-05-18 08:45:04 <ncopa> im looking at the issue
2020-05-18 08:45:36 <ncopa> maxwell-k: i think what you do is okish, and better than options="!check"
2020-05-18 08:46:35 <maxwell-k> I opened https://gitlab.alpinelinux.org/alpine/aports/-/issues/11552 would someone like to assign it to me?
2020-05-18 08:46:41 <ncopa> if there are a significant number of other tests that passes, it indicates that the package is not completely broken and useless
2020-05-18 08:48:13 <Cogitri> Heh, seems like we clashed on the assigning :D
2020-05-18 08:48:45 <ikke> regarding py3-libgit2, there was a single test that failed just on s390x, which I didn't think was significant enough to disable it entirely for the arch
2020-05-18 08:49:06 <ncopa> ikke: makes sense
2020-05-18 08:49:08 <ikke> But I do agree just disabling tests should not be done easily
2020-05-18 08:49:13 <maxwell-k> all the failures I have seen on this are locally on x86_64
2020-05-18 08:49:51 <maxwell-k> do we agree that enabling some tests and disabling others is better than disabling all?
2020-05-18 08:51:16 <Cogitri> If a significant portion can be run yes. If not, no, because then it can mask the tests being broken
2020-05-18 08:51:33 <ikke> of course, just selectively disabling tests let you at least see other regressions
2020-05-18 08:51:36 <Cogitri> An `options="!check" # test are broken` is a lot more clear
2020-05-18 08:53:18 <maxwell-k> I really appreciate the input here, thank's everyone
2020-05-18 08:53:47 <ikke> And we should create issues in the issue tracker imho
2020-05-18 08:53:51 <maxwell-k> (its not important but the assignment of https://gitlab.alpinelinux.org/alpine/aports/-/issues/11552 didn't work maybe someone could try again)
2020-05-18 08:54:22 <Cogitri> Yes, I think ncopa accidentally un-assigned you again
2020-05-18 09:02:59 <ncopa> sorry
2020-05-18 09:03:38 <ncopa> also, if some tests ar flakey, passes sometiems and soemtimes not, they can be disabled
2020-05-18 09:03:53 <ncopa> or if the pass in some environments and fails in others
2020-05-18 09:04:24 <ncopa> should preferable also be reported upstream
2020-05-18 09:05:11 <maxwell-k> ty, on a related note my rstcheck fix was merged upstream so that's one less flaky test in the world :-)
2020-05-18 09:05:43 <mps> yes, working with upstream developers is most important for good packaging
2020-05-18 09:06:58 <Cogitri> BTW, now that the builders are done, what's the ETA for 3.12? :)
2020-05-18 09:08:00 <mps> and testing is really important, not only test in pkg but also 'battlefield' tests, especially for pkgs in main
2020-05-18 09:08:42 <Cogitri> And can we maybe land a tiny patch for the D frontend of GCC still?
2020-05-18 09:08:47 <maxwell-k> I have been working on some very simple tests like that for python pkgs in main, hopefully will manage to share something soon
2020-05-18 09:10:05 <Cogitri> !7980 would be amazing to have that in 3.12 so we can enable D packages on more arches
2020-05-18 09:26:01 <ncopa> !7980 looks like a bugfix which is acknowledged upstream so i see no reason to not merge it
2020-05-18 09:26:41 <Cogitri> Great :)
2020-05-18 09:26:56 <Cogitri> Well, I don't have the bits for main, so could you do that? :)
2020-05-18 09:27:50 <ncopa> sure
2020-05-18 10:01:57 <ncopa> seems like builders are all idle
2020-05-18 10:01:59 <ikke> ncopa: kmymoney is a tricky one. It only fails on the 3-12 builder, I cannot reprodue it
2020-05-18 10:02:46 <ncopa> $ docker run --rm -it alpine:edge sh -c 'apk update --quiet  && apk dot --errors' | tpaste
2020-05-18 10:02:46 <ncopa> https://tpaste.us/9N50
2020-05-18 10:03:01 <ncopa> libreoffice needs to be rebuilt due to poppler upgrade. i will take care of that
2020-05-18 10:03:09 <ikke> (y)
2020-05-18 10:03:21 <ncopa> what up with the kmymoney?
2020-05-18 10:03:43 <Cogitri> Seems like we have some problems with poppler in general
2020-05-18 10:03:44 <Cogitri> See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7923#note_88807
2020-05-18 10:04:37 <mps> ncopa: they shouldn't idling, !7409
2020-05-18 10:05:35 <Cogitri> Seems like CI wasn't quick enough for the automatic merge in !7980
2020-05-18 10:05:55 <mps> please, push this, I plan to create subpackage rtl-sdr-tools from librtlsdr pkg
2020-05-18 10:06:11 <mps> but need this pushed first
2020-05-18 10:07:00 <mps> also, !7978 postfix fixes for 3.11
2020-05-18 10:14:06 <ikke> ncopa: I disabled the check on aarch64, but some tests fail with child aborted, I could not find anything related to that, and could not reproduce it outside of the 3.12 builder
2020-05-18 10:24:45 <dne> Ariadne: thanks for merging !7368 :) any chance this could get backported to 3.11 too?
2020-05-18 10:25:11 <Ariadne> yes, if you open an MR about it
2020-05-18 10:26:02 <dne> cool
2020-05-18 10:47:57 <dne> done in !7982
2020-05-18 10:48:50 <Ariadne> done
2020-05-18 10:49:22 <dne> great, thanks!
2020-05-18 13:37:56 <mps> subpackages="$pkgname-dev rtl-sdr:tools" of librtlsdr, should be rtl-sdr renamed to rtl-sdr-tools?
2020-05-18 13:38:16 <mps> subpkg, I mean
2020-05-18 16:40:50 <u0jQx9gPyrYg> mps: if you do, you could also use my package which is newer and has better support for remote rtls (via the patch): https://github.com/aports-ugly/aports/tree/master/ugly/rtl-sdr
2020-05-18 17:02:20 <mps> u0jQx9gPyrYg: didn't decided yet, but I will note your url in case I decide to change that. thanks
2020-05-18 17:03:17 <mps> first have to find why rngd daemon segfaults when rtlsdr device is plugged
2020-05-18 17:03:37 <mps> and time is short these days
2020-05-19 05:05:54 <rahmanshaber[m]> hello guys.
2020-05-19 05:05:54 <rahmanshaber[m]> is there any example APKBUILD file that uses git submodules?
2020-05-19 05:06:31 <maxice8> I recently removed it from telegram-desktop
2020-05-19 05:06:39 <maxice8> but you should put them into source= and move them into their proper locations
2020-05-19 05:07:28 <rahmanshaber[m]> that app i am trying to package it has a git submodule and have to use   'git submodule update --init --recursive'  then build but in APKBUILD file how to do it?
2020-05-19 05:07:38 <rahmanshaber[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/XvvxGAcwIuUdExPSIdXPJTqB >

2020-05-19 05:08:12 <maxice8> put it in source= then in prepare() mv it to the correct location
2020-05-19 05:08:13 <rahmanshaber[m]> i added the 'git submodule update --init --recursive" in build function. but i did not solved
2020-05-19 05:08:26 <maxice8> Please use a paste service
2020-05-19 05:09:16 <maxice8> do not use that
2020-05-19 05:09:36 <rahmanshaber[m]> https://pastebin.com/Ga2B1Jbb
2020-05-19 05:10:27 <rahmanshaber[m]> <maxice8 "put it in source= then in prepar"> is there any other way ?
2020-05-19 05:10:57 <maxice8> Yes, you can ask upstream to make a tarball that includes every submodule checked out like telegram has telegram-full.tar.xz
2020-05-19 05:11:07 <maxice8> That is the most correct thing
2020-05-19 05:35:40 <maxice8> @ncopa ping
2020-05-19 05:40:14 <ikke> rahmanshaber[m]: https://git.alpinelinux.org/aports/tree/testing/py3-maxminddb/APKBUILD
2020-05-19 05:43:31 <maxice8> hey ikke
2020-05-19 05:43:42 <maxice8> can you take a look at !8012 !8013 and !8014 ?
2020-05-19 05:45:01 <ikke> Later
2020-05-19 05:59:12 <maxice8> Okay
2020-05-19 06:35:12 <rahmanshaber[m]> why this picking up commits i didn't
2020-05-19 06:35:12 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/-/merge_requests/1/commits
2020-05-19 06:36:44 <maxice8> You need to rebase against the upstream branch
2020-05-19 06:37:04 <ncopa> morning
2020-05-19 06:37:08 <maxice8> also the merge request must be against alpine/aports
2020-05-19 06:37:16 <maxice8> morning
2020-05-19 06:37:20 <ncopa> hi maxice8, whats up?
2020-05-19 06:37:42 <maxice8> nothing much, looking at the possibility of upgrading libexif in 3.8, 3.9 and 3.10
2020-05-19 06:38:12 <maxice8> there are 2 version with 10+ CVE fixes
2020-05-19 06:39:55 <Cogitri> Morning
2020-05-19 06:42:54 <oneinsect> morning
2020-05-19 06:47:57 <mps> oneinsect: namaste
2020-05-19 06:48:08 <mps> :)
2020-05-19 06:55:30 <oneinsect> lol
2020-05-19 06:55:37 <oneinsect> :D
2020-05-19 06:57:31 <FrapeX> hi all, regarding arch x86. Based on what the kernel is compiled for I think alpine x86 should run on i586 / pentium and above. Yet, I found out there are bins/libs that contain the sse2 cpu instruction. For example: librsvg, gegl.
2020-05-19 06:58:12 <FrapeX> Those binaries/libs cause segfaults / invalid opcode exceptions and wont work on a true i586 / pentium.
2020-05-19 07:01:22 <FrapeX> So, is alpine x86 supposed to run on pentium and above, or pentium4 and above? If it is supposed to run on pentium and above then there is some fixing to do...
2020-05-19 07:07:35 <fabled> FrapeX, currently the x86 maps to i586-alpine-linux-musl and configures gcc to produce generic i586 code by default. unfortunately, some projects ignore that and make their own options, or even hardcode certain SSE etc. code in the app. so there might be application specific issues.
2020-05-19 07:08:58 <FrapeX> Good to hear its a known issue.
2020-05-19 07:13:07 <FrapeX> What would be required to fix such issues? Would it be given priority?
2020-05-19 07:14:58 <FrapeX> There is probably more packages, the few packages that I found is just the tip of the iceberg. And some would be hard to fix (rustc for example...)
2020-05-19 07:18:07 <oneinsect> https://code.foxkit.us/adelie/abuild/blob/master/functions.sh.in
2020-05-19 07:18:20 <oneinsect> i486-foxkit-linux-musl
2020-05-19 07:18:31 <oneinsect> dont know what maps to
2020-05-19 07:18:46 <oneinsect> ofcourse there is pentium4-foxkit-linux-musl
2020-05-19 07:18:51 <oneinsect> you may want to try it
2020-05-19 07:18:56 <oneinsect> Adelie
2020-05-19 07:21:11 <fabled> FrapeX, if it's simple to configure/patch the package, I think it'd be ok. but it's sad fact that increasing amount of large upstream projects do not care anymore about "legacy" pentium systems (even if there's new embedded CPUs supporting only that instruction set)
2020-05-19 07:26:55 <FrapeX> fabled, yeah true, I tried to rebuild several packages. For example, pks "babl" can be configured to disable SSE/SSE2 instructions and the build bins/libs won't contain SSE instructions. But for example pkg "libsrvg" can be build without SSE/SSE2 but the bins/libs will contain SSE2 instructions.
2020-05-19 07:27:53 <fabled> FrapeX, some "bigger" project detect on runtime the CPU and use SSE only when proper CPU is detected. However, seems to be increasing assumption that you run on modern CPU and that SSE is there.
2020-05-19 07:30:17 <FrapeX> fabled, It kinda hard to test also, because qemu configured with a limited set of supported instructions (using the -cpu option), will still execute SSE/SSE2 instructions without complaining. One would really need the hardware to get the segfaults / invalid opcode exceptions.
2020-05-19 07:30:46 <[[sroracle]]> adelie only ships pmmx right now; x86 and i528 arches are something that may be done in the future
2020-05-19 07:31:20 <Cogitri> I think it'll be loads of work to get non sse on x86 working for all packages for only a few people who actually still want to use it... :/
2020-05-19 07:31:31 <FrapeX> [[sroracle]]: thanks
2020-05-19 07:33:10 <Cogitri> fabled: BTW, what's the lifetime of apk_package* I get from libapk? It seems to me like they're never free'ed unless the package is uninstalled or the db is closed, is that right?
2020-05-19 07:33:25 <Cogitri> Then I wouldn't have to copy the contents of apk_package around in apk-polkit
2020-05-19 07:33:41 <FrapeX> Cogitri: Yes it will be loads of work, even even musl (main lib) contains SSE2 instructions...
2020-05-19 07:33:46 <fabled> Cogitri, lifetime is apk_database lifetime
2020-05-19 07:34:42 <FrapeX> It would be good to scan bins/libs during the build. I used (an older version) of https://github.com/Homer-Conferencing/Homer-Conferencing/blob/master/Homer/bin/analyse-x86.pl to analyse the bins/libs.
2020-05-19 07:34:52 <Cogitri> Ah, great, thanks for confirming, fabled
2020-05-19 07:36:51 <Cogitri> FrapeX: First we'd have to decide if that's actually worth the effort for us
2020-05-19 07:37:54 <Cogitri> Because to be completely honest, we're already having enough of work keeping packages up to date, so I personally don't think it's worth it to invest the effort to get packages working on a the few CPUs that don't have SSE on an already dying arch
2020-05-19 07:40:06 <FrapeX> Cogitri: yes, you are probably right. But in that case, alpine x86 wont run on i586, although it is supposed.
2020-05-19 07:40:20 <FrapeX> + to.
2020-05-19 07:41:11 <rahmanshaber[m]> any idea why it's failing?
2020-05-19 07:41:12 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/pipelines/18605
2020-05-19 07:42:05 <Cogitri> FrapeX: Yeah, but switching the triplet to i686 now would be a lot of work just to be technically correct. I guess we should document this better though
2020-05-19 07:44:20 <FrapeX> I found out that SSE/SSE2 instructions wont be added to bins/libs using the gcc options CFLAGS="-march=pentium" option. Wont work for rustc apps though, there you'll need something like RUSTFLAGS="-C target-feature=-sse,-sse2,-sse3,-sse4.1,-sse4.2,-ssse3"
2020-05-19 07:45:22 <FrapeX> Cogitri: well, i686 is pentium2 and up, does have mmx, wont do sse
2020-05-19 07:46:54 <FrapeX> pentium4 (MMX, SSE, SSE2) is more like i786
2020-05-19 07:47:41 <Cogitri> Ah, fair
2020-05-19 07:47:53 <FrapeX> Cogitri: GCC doc is pretty clear about the archs: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
2020-05-19 07:48:34 <Cogitri> But still, we'd downgrade the performance of other i686 professors which do have these options for the tiny user base of old i686 CPUs and invest a lot of effort into it while we're at it
2020-05-19 07:48:44 <Cogitri> s/prof/proc/
2020-05-19 07:48:44 <alpine-meetbot> Cogitri meant to say: But still, we'd downgrade the performance of other i686 processors which do have these options for the tiny user base of old i686 CPUs and invest a lot of effort into it while we're at it
2020-05-19 07:50:01 <FrapeX> alpine-meetbot: yes you will get performance regressions. But if Alpine x86 is supposed to run on i586/pentium and up, then there are a lot of packages broken.
2020-05-19 07:50:44 <Cogitri> So it's time to declare that Alpine won't run on these processors then
2020-05-19 07:51:17 <FrapeX> Yeah. Guess so.
2020-05-19 07:52:33 <FrapeX> In that case one would change the kernel arch to i686 also, for performance benefits.
2020-05-19 07:54:30 <PureTryOut[m]> Cogitri: new Phosh release 0.3.0 is out
2020-05-19 07:55:51 <Cogitri> Ah neat, I'll get to it in a bit
2020-05-19 07:56:28 <Cogitri> FrapeX: That'd probably be a good idea - but maybe you can make a post to the devel mailing list?
2020-05-19 07:57:42 <FrapeX> Cogitri: I think it would be sad though, Alpine is a lightweight distro which makes it perfectly suited to run on old boxes.
2020-05-19 07:58:26 <oneinsect> fabled closed my issue? that was fast
2020-05-19 07:58:27 <oneinsect> https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10696
2020-05-19 07:58:46 <Cogitri> FrapeX: Well yes, but there are other distros to use then
2020-05-19 07:59:02 <oneinsect> darn thank you fabled:
2020-05-19 07:59:03 <oneinsect> LUA=no to build without help
2020-05-19 07:59:09 <oneinsect> i will check it in sometime now
2020-05-19 07:59:10 <fabled> oneinsect, yes, today's an apk-tools day. trying to fix the easy things
2020-05-19 07:59:16 <oneinsect> lol
2020-05-19 08:00:05 <Cogitri> FrapeX: And I don't see us investing the time and effort to get Alpine to run on the CPU of like <5% of x86 users only to get a performance downgrade on an already slow arch for the other 95% of x86 users
2020-05-19 08:00:31 <FrapeX> Cogitri: yeah, I agree.
2020-05-19 08:00:53 <Cogitri> fabled: Ah, I'll make the lua help generation optional in meson for apk then too
2020-05-19 08:01:34 <fabled> ah, the meson thing. should try to get it merged in before there's too much stuff happening. i'm just not sure how to go ahead with the cross-compiling thing
2020-05-19 08:02:00 <fabled> and wondering if the python/meson build-dependency is an issue to oneinsect or others. i guess that's "more available" than lua though.
2020-05-19 08:02:47 <Cogitri> If you want to I can add the script to generate the crossfiles, that should be easy enough considering how nice and easy the crossfiles are
2020-05-19 08:03:00 <[[sroracle]]> fabled: one thing awilfox suggested was building help in release tarballs
2020-05-19 08:03:10 <Cogitri> Luckily meson only needs py3 and nothing else
2020-05-19 08:03:10 <[[sroracle]]> then lua is not needed downstream at all
2020-05-19 08:03:15 <oneinsect> oooh my god! just compiled using make LUAAPK="" LUA="no" and it works
2020-05-19 08:03:37 <oneinsect> with the latest commit! thank you thank you thank you
2020-05-19 08:03:48 <fabled> [[sroracle]], i was thinking that too, but oneinsect is already doing git builds so not sure if it would solve it
2020-05-19 08:04:30 <[[sroracle]]> fabled: rhis is speaking more generally to the introduction of lua as a dep not necessarily oneinsect's problem in particular
2020-05-19 08:04:46 <fabled> yes
2020-05-19 08:04:56 <fabled> and it might be useful also for reproducible builds etc
2020-05-19 08:05:33 <fabled> but then someone needs to do "make dist" or similar that starts including generated fiels. perhaps after meson support is merged in...
2020-05-19 08:05:34 <oneinsect> one make clean throws an error Lua interpreter not found. Please specify LUA interpreter, or use LUA=no to build without help so i have to do make clean LUA=no
2020-05-19 08:05:39 <FrapeX> Cogitri: but please state somewhere that alpine x86 wont run on anything below pentium4 without issues due to SSE/SSE2 instructions.
2020-05-19 08:05:40 <oneinsect> okie*
2020-05-19 08:06:07 <fabled> oneinsect, "make LUA=no" should also disable the lua module build and be sufficient without the LUAAPK...
2020-05-19 08:06:19 <oneinsect> correct
2020-05-19 08:06:42 <FrapeX> Cogitri: thanks for your time, I'll rest my case :-)
2020-05-19 08:06:51 <oneinsect> just tested the same make LUA="no" and it works!
2020-05-19 08:06:55 <[[sroracle]]> fabled: is meson replacing existing build system or just an alt impl?
2020-05-19 08:07:25 <fabled> i'd like to replace. mostly because the current makefile is rather cryptic for most, and slightly cumbersome to maintain.
2020-05-19 08:07:46 <[[sroracle]]> i see
2020-05-19 08:08:09 <oneinsect> please also make sure "make clean" works as right now it throws error and i have to do "make clean LUA=no"
2020-05-19 08:11:59 <rahmanshaber[m]> anyidea why this failing'
2020-05-19 08:11:59 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/119230
2020-05-19 08:12:47 <Cogitri> Yeah, the current makefile has a looot of magic :/
2020-05-19 08:13:18 <Cogitri> rahmanshaber[m]: You made a merge request against your private fork, not upstream aports
2020-05-19 08:13:35 <Cogitri> Please make a MR against https://gitlab.alpinelinux.org/alpine/aports, then it should work
2020-05-19 08:15:04 <rahmanshaber[m]> ohh, okey. thanks
2020-05-19 08:45:25 <markand> o/
2020-05-19 08:47:00 <FrapeX>  /?
2020-05-19 08:47:07 <rahmanshaber[m]> https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/119348
2020-05-19 08:47:21 <rahmanshaber[m]> stuck, can i do anything here?
2020-05-19 08:47:38 <mps> ncopa: http://ix.io/2mFi
2020-05-19 08:47:52 <mps> musl + postfix
2020-05-19 08:48:20 <mps> this is one option proposed
2020-05-19 08:50:34 <Cogitri> rahmanshaber[m]: s390x CI is busy again apparently, you can't do anything about that
2020-05-19 09:15:22 <rahmanshaber[m]> <ikke "rahmanshaber: https://git.alpine"> ikke: in line 15 i have to add the git submodule path ? but there it is a tar file but the package i am making is uses master branch
2020-05-19 09:19:07 <rahmanshaber[m]> My MR is ready to merge
2020-05-19 09:19:07 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8039
2020-05-19 09:21:48 <PureTryOut[m]> rahmanshaber: please try to refrain from using Matrix features like replies here. This is a majority IRC channel and they won't see your replies and such
2020-05-19 10:44:51 <Thermi> ncopa: Any idea about that gsoap issue I pinged you repeatedly about? https://gitlab.alpinelinux.org/alpine/aports/-/issues/11511
2020-05-19 10:45:22 <ikke> Thermi: 3.12 has priority right now
2020-05-19 10:48:27 <Thermi> ikke: so you're gonna drag the gsoap package with that unsolved issue into 3.12?
2020-05-19 12:24:06 <mps> timlegge: I wanted today to ask you about moving perl-crypt-openssl-verify to community, but I see it is done. thanks
2020-05-19 12:24:55 <timlegge> yes.  thanks for thinking of it though
2020-05-19 12:25:42 <mps> np, it is good to have this pkg in 3.12-stable community
2020-05-19 12:34:45 <Cogitri> markand: Did you notice the comments on your MRs?
2020-05-19 12:49:29 <Ariadne> damn, this cython test suite is brutal
2020-05-19 12:55:52 <markand> Cogitri, yes
2020-05-19 12:56:09 <markand> will update when I have some time to spare
2020-05-19 13:01:34 <Cogitri> Okie, thanks :)
2020-05-19 14:33:43 <rahmanshaber[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/kqbvIIZIAEqwwqOiyLSndaPR >

2020-05-19 14:33:56 <rahmanshaber[m]> ```
2020-05-19 14:33:56 <rahmanshaber[m]> usr/bin/abuild: /home/pmos/build/APKBUILD: line 14: libdesq-f64f6b049874926bbec18f9adb78576b8081fed7.tar.gz::https://gitlab.com/DesQ/libdesq/-/archive/f64f6b049874926bbec18f9adb78576b8081fed7/libdesq-f64f6b049874926bbec18f9adb78576b8081fed7.tar.gz: not found
2020-05-19 14:36:03 <Cogitri> source is one string
2020-05-19 14:36:21 <Cogitri> No two like you did
2020-05-19 14:40:15 <rahmanshaber[m]> Cogitri:  is there any other issues in the APKBUILD file?
2020-05-19 14:45:07 <rahmanshaber[m]> that apkbuild is unusual, that's why i asked.
2020-05-19 14:52:16 <Cogitri> You should leave a comment next to the options="!check" explaining why it doesn't run tests
2020-05-19 14:53:12 <Cogitri> And you're the upstream of that package, right? It'd be nice if you included that submodule in a release tarball
2020-05-19 15:01:41 <rahmanshaber[m]> <Cogitri "And you're the upstream of that "> we don't know if we use this git submodule thing in next release, this was a test run.
2020-05-19 15:02:22 <rahmanshaber[m]> <Cogitri "You should leave a comment next "> i don't know why, i just copy/ pasted from another one. i am not good at this script things
2020-05-19 15:02:53 <rahmanshaber[m]> as i remmember there is no script in the app it self to check the files or somthing like that, so that key is not uses
2020-05-19 15:02:59 <rahmanshaber[m]>  * as i remmember there is no script in the app it self to check the files or somthing like that, so that key is not used
2020-05-19 15:11:10 <ncopa> Thermi: can you please report the gsoap issue here: https://sourceforge.net/p/gsoap2/bugs/
2020-05-19 15:13:53 <Thermi> ncopa: ty! I tried the libtool patch but that didn't help with the issue. The symbol is still static. I'll try again later tonight.
2020-05-19 15:27:12 <ncopa> The idea is to use the shared lib instead of the static
2020-05-19 15:27:44 <ncopa> i bumped into the parallel build issue
2020-05-19 15:27:52 <ncopa> i hate those `make -j1`
2020-05-19 15:29:35 <maxice8> ncopa: thanks for merging libexif
2020-05-19 15:31:43 <ikke> Cogitri: rspamd checksum mismatch
2020-05-19 15:32:19 <ikke> (and it warns about chown in post-upgrade)
2020-05-19 15:33:29 <Cogitri> Oof
2020-05-19 15:33:52 <ncopa> maxice8: i modified the commit message
2020-05-19 15:34:00 <ncopa> but thanks for taking care of it
2020-05-19 15:34:02 <maxice8> fine by me
2020-05-19 15:34:11 <ncopa> i saw that it was also fixed in 3.11 and master. thanks!
2020-05-19 15:34:56 <Cogitri> ikke: Fixed the checksum, the chown thingie was there before
2020-05-19 15:34:56 <maxice8> as long as it gets through and the secfixes get to users i don't mind what happens
2020-05-19 15:35:07 <ikke> Cogitri: yeah, I figured as mutch
2020-05-19 15:35:36 <ncopa> maxice8: yes, thats the most important
2020-05-19 15:40:36 <ncopa> Thermi: can you please test gsoap-dev-2.8.102-r1 from edge? It should fix it.
2020-05-19 15:57:04 <dalias> ncopa, mps, see updates on https://gitlab.alpinelinux.org/alpine/aports/-/issues/11455
2020-05-19 16:16:45 <mps> dalias: I've seen but didn't had time to reply
2020-05-19 16:18:08 <mps> and looked at latest musl commit, but I think it is to late to pick it for alpine 3.12
2020-05-19 17:10:02 <dalias> well something should be done about the postfix issue for release
2020-05-19 17:10:31 <dalias> even if just disabling dnssec/dane at build
2020-05-19 17:10:51 <dalias> this is totally a bug (silently not honoring dane config) that should be considered cve-worthy
2020-05-19 17:11:37 <Hello71> I think DNSSEC/DANE is dumb, but if the admin explicitly enables it then it should not be silently ignored
2020-05-19 17:15:19 <mps> looks like we don't ship main.cf with dane enabled, at least something is ok
2020-05-19 17:16:19 <mps> and I never enabled dane on my servers
2020-05-19 17:17:38 <mps> not that I think dane is not good but because never had enough incentives
2020-05-19 18:47:27 <mps> dalias: (and all interested) I created !8089 MR for review
2020-05-19 18:50:25 <mps> tested with https://havedane.net/
2020-05-19 19:10:56 <ncopa> dalias: thanks for following up the postfix issue
2020-05-19 19:12:25 <dalias> mps, it works? :)
2020-05-19 19:13:39 <ncopa> i thinkj I'll backport the https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633
2020-05-19 19:14:17 <mps> dalias: yes, it works for tests I done
2020-05-19 19:15:14 <mps> ncopa: this is ok if it is not to late for 3.12
2020-05-19 19:15:36 <mps> I thought (and wrote on issue) about that
2020-05-19 19:15:41 <dalias> i'm ok with either. the postfix patch is 'safer' imo
2020-05-19 19:16:07 <dalias> even tho the musl patch is intentionally made as safe as possible, it's inherently safer to patch one leaf package than a core dep
2020-05-19 19:17:20 <ncopa> i think its ok to include it. in worst ase we can revert it
2020-05-19 19:17:37 <ncopa> its not like we need to rebuild the world in case of a revert
2020-05-19 19:17:49 <dalias> indeed
2020-05-19 19:18:11 <mps> I'm ok with whatever you do
2020-05-19 19:18:41 <ncopa> mps: and you did some basic testing, right?
2020-05-19 19:19:01 <mps> yes, send me mail and I will reply
2020-05-19 19:19:19 <mps> it works about two hours
2020-05-19 19:19:39 <mps> and we should backport to 3.11-stable at least
2020-05-19 19:21:25 <mps> just received your comment on issue
2020-05-19 19:22:55 <mps> dalias: is it still ok to post mail to address you gave me last night?
2020-05-19 19:26:46 <dalias> my badmx one? yes if so
2020-05-19 19:27:21 <mps> yes, this one
2020-05-19 19:29:35 <mps> dalias: response from server 'Subject: Undelivered Mail Returned to Sender'
2020-05-19 19:30:02 <mps> that's ok I think, I don't have dane
2020-05-19 19:31:13 <dalias> which server did you get response from? yours or mine?
2020-05-19 19:31:24 <mps> your
2020-05-19 19:31:30 <dalias> then it didn't honor dane
2020-05-19 19:31:36 <dalias> it will not contact my server if it honors dane
2020-05-19 19:31:53 <dalias> well it'll contact but abort as soon as it sees non-matching key
2020-05-19 19:31:56 <mps> 'badmx.aerifal.cx[216.12.86.13] said: 550 Message could not be delivered'
2020-05-19 19:32:12 <dalias> yeah that's rejection by my end
2020-05-19 19:32:18 <dalias> not dane validation failure
2020-05-19 19:32:27 <mps> aha
2020-05-19 19:32:28 <dalias> i forgot i left it that way so you can see which happens
2020-05-19 19:32:34 <dalias> rather than letting it deliver on my side
2020-05-19 20:57:52 <ikke> hmm, cython build failure appearing again
2020-05-19 21:55:21 <maxice8> Is there the possbility of caddy 2.0.0 hitting 3.12 ? it has a few breaking changes in the configuration files
2020-05-19 21:55:33 <maxice8> https://github.com/caddyserver/dist/issues/32
2020-05-19 21:59:03 <maxice8> also needs go 1.14
2020-05-19 22:20:37 <maxice8> !8099
2020-05-19 22:20:51 <maxice8> I need go >=1.14.0 for caddy 2.0.0
2020-05-19 22:34:29 <kaey> maxice8: ariadne had problems with go1.14 on mips
2020-05-19 22:34:41 <maxice8> well that is a big oof
2020-05-19 22:42:57 <Ariadne> we are working on it
2020-05-19 23:03:12 <kaey> i can do some printf debugging if you give me ssh access to that mips host
2020-05-19 23:06:36 <timlegge> when someone has time to review !8067 and am wondering about my approach in the testing/iwatch comit e632199f19b223d006a110c8cbbbf44e0be8b90e in particular
2020-05-19 23:27:05 <maxice8> @Ariadne thanks for your work on it, do you think it will be done by 3.12 ?
2020-05-19 23:27:31 <Ariadne> probably
2020-05-19 23:27:55 <maxice8> thanks, the caddy people want 2.0.0 in 3.12 but we need go 1.14.0 to have caddy 2.0.0
2020-05-20 01:31:01 <rahmanshaber[m]> ready to mrege
2020-05-20 01:31:02 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8103
2020-05-20 05:38:41 <mps> timlegge: I would remove this part from pkgdesc 'iWatch is a '
2020-05-20 05:40:00 <mps> and, pkgdesc="Event loop processing" to pkgdesc="event loop processing" (lowercase all)
2020-05-20 05:41:05 <mps> and, pkgdesc="Unknown" obviously
2020-05-20 05:41:52 <mps> this one is not nice: pkgdesc="XML::SimpleObject::LibXML - Perl extension allowing a simple(r) object representation of an XML::LibXML DOM object."
2020-05-20 05:43:15 <mps> and, could you split it to separate MRs, it is easier for review and safer to commit than one 'big'
2020-05-20 05:43:51 <mps> and thanks for preparing these perl things
2020-05-20 06:00:46 <Cogitri> I don't see the point of splitting things when one APKBUILD depends on the other
2020-05-20 06:01:00 <Cogitri> Because CI won't be able to run over all of them if you split the MR up
2020-05-20 06:02:31 <mps> push/merge one-by-one and in proper order
2020-05-20 06:03:02 <mps> when dependencies pushed and built on builder
2020-05-20 06:03:11 <mps> I think this is more safe
2020-05-20 06:04:39 <mps> small steps and one by one is safer then one big jump :)
2020-05-20 06:08:49 <Cogitri> Well, I wouldn't call 4 simple APKBUILDs a big jump, but oh well
2020-05-20 06:09:05 <Cogitri> And the builders will figure out the buildorder themselves
2020-05-20 06:09:32 <Cogitri> I mean I don't want to discourage you from doing reviews your way, it's just annoying for contributors when one reviewer tells them to group their changes together
2020-05-20 06:09:40 <Cogitri> And another one says to split everything up
2020-05-20 06:15:44 <mps> then those who tell to group changes are wrong :p
2020-05-20 06:27:01 <hrio[m]> Anybody else affected by a SSH host key change of git.alpinelinux.org? ( could have happended a week ago or so, not sure as I av not been working on alpine )
2020-05-20 06:29:16 <Cogitri> I think that has been swapped from Gitolite to cgit
2020-05-20 06:29:23 <Cogitri> One should use Gitlab now
2020-05-20 06:29:57 <hrio[m]> Any reason why the SSH host key was not preserved in the swap?
2020-05-20 06:30:39 <mps> iirc, git.alpinelinux.org is now only a mirror
2020-05-20 06:31:43 <hrio[m]> Sure but there could be setups that still mirrors that, that breaks due to SSH host key changes
2020-05-20 06:33:31 <hrio[m]> But OK, I will only use gitlab.alpinelinux.org
2020-05-20 06:34:11 <mps> infra team can give answer
2020-05-20 06:34:57 <mps> and I think this is announced on -devel ML
2020-05-20 06:42:54 <hrio[m]> Yes fount it, but nothing on the host key change, in that announcement.
2020-05-20 06:43:20 <ikke> THe host changed
2020-05-20 06:43:26 <ikke> so the host key change is implicit
2020-05-20 06:57:11 <Bridouz> o/
2020-05-20 06:59:16 <Bridouz> Does someone know (I'm sure you know) how to use secfixes-check
2020-05-20 07:04:01 <maxice8> secfixes-check /path/to/apkbuild
2020-05-20 07:04:37 <Bridouz> And it takes the $pkgver and check cvs ?
2020-05-20 07:04:46 <maxice8> what ?
2020-05-20 07:05:14 <ikke> It's just a linting tool
2020-05-20 07:05:25 <Bridouz> Yeah OK, just linting
2020-05-20 07:17:05 <maxwell-1> good morning, could someone take another look at !7633 please? maxice8 reviewed before
2020-05-20 07:17:09 <maxwell-1> lots of discussion but I don't think anything controversial, the GitLab UI won't rebase so I keep doing it manually
2020-05-20 07:18:06 <hrio[m]> I have been bitten by an issue three different times ( both VMs and bare metal) this year, now when upgrading edge, sudo and other packages are removed during upgrade and several directories including /etc looses permissions for others. Anybody else affected?
2020-05-20 07:20:19 <Cogitri> maxwell-1: Ah, no need to do that since it's rather improbable that a reviewer will look at it right after you rebased it
2020-05-20 07:20:40 <Cogitri> When it doesn't work via the UI reviewers can just add a remote to your aports to their aports tree and push from there
2020-05-20 07:21:09 <maxwell-1> so ignore the UI warning that it can't rebase? I'm sure people have asked me to rebase in the past
2020-05-20 07:21:16 <Cogitri> hrio[m]: Well, if you need those packages you should add them to your world
2020-05-20 07:21:44 <Cogitri> abuild stopped depending on sudo, so apk went ahead and removed it because it thought it was unnecessary now
2020-05-20 07:22:03 <hrio[m]> Sure, but want about perms? /var dir affected as well
2020-05-20 07:22:57 <Cogitri> Changed perms aren't good, but at least for me that didn't happen
2020-05-20 07:23:08 <Cogitri> Maybe you can track down what package did that?
2020-05-20 07:23:30 <Cogitri> maxwell-1: Well, we've only somewhat recently started using gitlab with rebasing
2020-05-20 07:23:40 <Cogitri> Ah, left
2020-05-20 07:30:46 <maxwell-k> Cogitri: sorry I accidentally was in this channel twice, the other "me" left :)
2020-05-20 07:30:59 <Cogitri> Ah, okie
2020-05-20 07:31:31 <Cogitri> Anyway, if a reviewer tells you to rebase all the time please tell them to add your aports repo as remote, checkout your branch, rebase and force push
2020-05-20 07:32:02 <Cogitri> We can't expect contributors to rebase all the time, especially since the reviewer would need to review the thing almost immediately before anything else is pushed
2020-05-20 07:32:13 <Cogitri> review and merge*
2020-05-20 07:32:26 <maxwell-k> I can be more patient, I appreciate that GitLab is new (I really like it!), and thank you for the advice
2020-05-20 07:35:36 <ikke> We appreciate the feedback as well, we want to make this work for both contributors as reviewers
2020-05-20 07:40:15 <hrio[m]> <Cogitri "Changed perms aren't good, but a"> Seems to be caused by the commit updating apt-dater to 1.0.4. Test building the commit locally creates a apk file with messed up perms for the affected directories
2020-05-20 07:41:17 <dne> if "Allow commits from members who can merge to the target branch" is enabled, I assume the reviewer can also rebase in the UI?
2020-05-20 07:42:33 <Cogitri> Yes, but sadly Gitlab sometimes doesn't like rebasing things for *some* reason
2020-05-20 07:42:50 <Cogitri> But with that setting enabled reviewers can also checkout your branch and push to your fork directly to rebase from the CLI fortunately
2020-05-20 07:43:06 <dne> ah I see
2020-05-20 07:47:28 <Cogitri> hrio[m]: Time to file a bug report then, thanks for checking
2020-05-20 07:47:40 <hrio[m]> Done
2020-05-20 07:47:57 <hrio[m]> Issue #11563
2020-05-20 07:56:49 <Cogitri> Thanks
2020-05-20 07:57:21 <Cogitri> Is the new version only broken due to the permission thing, or is it broken in general?
2020-05-20 07:58:05 <ikke> Cogitri: was wondering exactly the same myself :D
2020-05-20 07:58:37 <hrio[m]> When I tried to upgrade a year ago or so ( local testing ) it crashed a lot. Reverting stable again
2020-05-20 08:03:15 <hrio[m]> Will see if I have saved my branch
2020-05-20 08:05:55 <hrio[m]> No, will try to fix perms in the current version in edge. To see the status right now with never depends
2020-05-20 08:10:28 <hrio[m]> But have a few meetings to attend first, so will be this afternoon CET
2020-05-20 08:38:50 <ncopa> morning
2020-05-20 08:39:20 <ncopa> my computer hangs after bootup. not sure why
2020-05-20 08:39:29 <Cogitri> Morning
2020-05-20 08:39:43 <AinNero> ncopa: where?
2020-05-20 08:39:55 <ncopa> my work desktop computer
2020-05-20 08:40:12 <ncopa> lightdm starts up, but keyboard does not work
2020-05-20 08:40:16 <ncopa> so i cannot login
2020-05-20 08:40:29 <ncopa> nor do ctrl-alt-1 to switch to tty1
2020-05-20 08:40:47 <ncopa> there are a few error messages during boot but i dont reach to see them
2020-05-20 08:41:44 <clandmeter> ssh from macbook
2020-05-20 08:42:20 <Cogitri> Ah yes, probably no udev or Xorg input driver, that happened a few times to me as well
2020-05-20 08:42:49 <ncopa> possible. i cleanded up my /etc/apk/world
2020-05-20 08:43:01 <ikke> you should still be able to switch tty's right?
2020-05-20 08:43:11 <ncopa> i´d think so yes
2020-05-20 08:43:16 <ncopa> i booted my usb now
2020-05-20 08:43:28 <ncopa> so im removing the lightdm
2020-05-20 08:43:34 <ncopa> would be good to have a boot option to disable it
2020-05-20 08:44:03 <ikke> is it started as a service?
2020-05-20 08:44:08 <ncopa> yes
2020-05-20 08:44:14 <ncopa> rc-update add lightdm
2020-05-20 08:44:18 <ncopa> thats how i start it
2020-05-20 08:44:20 <ncopa> at boot
2020-05-20 08:44:22 <ikke> right
2020-05-20 08:44:23 <Cogitri> Booting into single user mode and disabling the service should work too, no?
2020-05-20 08:44:26 <ikke> maybe different runlevels?
2020-05-20 08:44:39 <ncopa> except that busybox init does not really support multiple runlevels
2020-05-20 08:44:44 <ikke> ok
2020-05-20 08:44:53 <ncopa> which is the problem at hand :)
2020-05-20 08:45:16 <ncopa> doesnt openrc has an init nowdays?
2020-05-20 08:45:24 <clandmeter> it does
2020-05-20 08:45:38 <Cogitri> Yup, there's openrc-init
2020-05-20 08:45:54 <Cogitri> Not sure if that'd provide an actual benefit though?
2020-05-20 08:46:14 <Cogitri> But when I tested it a few months ago it didn't break anything at least
2020-05-20 08:46:44 <ncopa> does it support different runlevels?
2020-05-20 08:47:52 <ncopa> looks like i removed eudev or similar
2020-05-20 08:48:26 <ncopa> service bluetooth needs non-existing service dev-settle
2020-05-20 08:48:32 <clandmeter> https://github.com/OpenRC/openrc/blob/master/init-guide.md
2020-05-20 08:49:26 <clandmeter> typo?
2020-05-20 08:49:34 <clandmeter> i guess its  udev-settle?
2020-05-20 08:49:43 <ncopa> i think i removed udev by mistake
2020-05-20 08:49:48 <ncopa> no keyboard or anything
2020-05-20 08:49:50 <ncopa> no network
2020-05-20 08:50:27 <clandmeter> ah dev-settle is a provides
2020-05-20 08:50:31 <Cogitri> clandmeter: No, I think udev provides those dev-* thingies in case you want to use mdev so we don't force udev usage
2020-05-20 08:50:32 <ncopa> yup
2020-05-20 08:50:33 <Cogitri> Right
2020-05-20 08:51:41 <mps> hmm, developers shouldn't have X/GUI autostarted
2020-05-20 08:52:02 <clandmeter> heh
2020-05-20 08:52:21 <clandmeter> thats what i normally do on alpine xorg installs
2020-05-20 08:53:24 <mps> when used (loooong time ago) other distros first thing is to disable XDM start on boot
2020-05-20 08:53:46 <clandmeter> a good dev would hack in a way to disable it via cmdline ;-)
2020-05-20 08:54:03 <AinNero> i never got warm with DM in the first place and still use startx
2020-05-20 08:54:15 <mps> which was annoyance on debian because they want on every uprage to re-enable it
2020-05-20 08:55:23 <ncopa> my problem was that i unintentionally had removed eudev
2020-05-20 08:55:38 <clandmeter> mps: dont change your food, change your diet (but you already did)
2020-05-20 08:55:59 <ncopa> `apk add --root /mnt eudev` to the rescue
2020-05-20 08:56:04 <Cogitri> 👍
2020-05-20 08:56:08 <ncopa> apk --root is pretty neat
2020-05-20 08:57:24 <ncopa> Cogitri: thanks for pointing me in right direction
2020-05-20 08:58:06 <Cogitri> Glad to be of help :)
2020-05-20 08:59:18 <ncopa> another annoyance is that every time i reboot to windows and back to linux, the bluetooth keyboard no longer works
2020-05-20 08:59:29 <clandmeter> isnt --root the same as chroot /mnt /sbin/apk ..?
2020-05-20 08:59:55 <ncopa> yup
2020-05-20 09:00:54 <ncopa> well, it gives you the opporunity to specify --keys-dir  and --repositories-file outside of the chroot if you want
2020-05-20 10:07:08 <Thermi> ncopa: The new package works (gsoap)!
2020-05-20 10:20:20 <ncopa> Thermi: awesome! thanks!
2020-05-20 10:20:55 <Thermi> ncopa: Thank you!
2020-05-20 10:24:00 <ncopa> i think i have a fix for cython x86. its a bug in the testsuite
2020-05-20 10:24:08 <ncopa> im testing it now
2020-05-20 10:27:02 <Cogitri> Nice
2020-05-20 10:27:33 <ikke> yes, nice
2020-05-20 10:30:18 <ncopa> its a patch from upstream. they responded quick
2020-05-20 10:30:29 <ncopa> lesson is to report upstream early
2020-05-20 10:36:55 <ikke> heh
2020-05-20 10:43:21 <mps> nice, pppoe bug about PADT is backported to LTS and latest stable kernel, kernel commit d315cf6cf0d2e4ddea61257acead37f7fddead95
2020-05-20 10:44:26 <mps> all who use pppoe should upgrade because of potential problems, or even (sec) risk
2020-05-20 10:55:18 <timlegge> mps: Thanks - I have split them and sorted the ppgdesc.  About to push the final iwatch (depends on the otheres)
2020-05-20 10:55:42 <mps> timlegge: nice and thanks
2020-05-20 10:56:03 <timlegge> btw is pkgdesc supposed to be a loower case?  If so I will adjust apkbuild-cpan.in
2020-05-20 10:56:22 <mps> I will look in a hour if someone don't merge them in meantime
2020-05-20 10:56:59 <mps> I think pkgdesc should be in lower case whenever is possible
2020-05-20 10:57:20 <ikke> timlegge: I don't think that's a rule, if you look for other packages, you see a lot of them with capitalized descriptions
2020-05-20 10:57:47 <mps> ikke: true, but that doesn't mean they are good
2020-05-20 10:58:40 <ikke> doesn't mean it's bad either
2020-05-20 10:58:49 <mps> acronyms and some thing is ok, but normal wording not
2020-05-20 10:59:35 <ikke> just 92 packages in main only have lower case descriptions
2020-05-20 10:59:54 <timlegge> I've done it both was and my latest push to apkbuild-cpan made the first character uppercase by default but I am good either way
2020-05-20 11:00:06 <timlegge> Some end in a period too :-)
2020-05-20 11:00:27 <mps> also this doesn't looks fine
2020-05-20 11:01:24 <mps> can anyone give any reasonable reason for First Character To Be Uper Case
2020-05-20 11:01:34 <ikke> It's too inconsisent right now to be pedantic about it honestly
2020-05-20 11:02:26 <ikke> 1481 packages in main start with a capital letter
2020-05-20 11:02:42 <ikke> That would be a good reason
2020-05-20 11:03:09 <mps> ikke: you are right again, but that doesn't mean we should start to make it better
2020-05-20 11:03:33 <mps> s/should/shouldn't/
2020-05-20 11:03:33 <alpine-meetbot> mps meant to say: ikke: you are right again, but that doesn't mean we shouldn't start to make it better
2020-05-20 11:04:08 <mps> (journey of 1000 miles start by first step)
2020-05-20 11:06:12 <timlegge> So I have pushed  !8119 !8118 !8117 - iwatch is 8120 and will fail till the other three get merged so I marked it WIP
2020-05-20 11:08:45 <ikke> mps: it's kind of subjective, and I'm not sure if it's worth the noise
2020-05-20 11:10:27 <mps> timlegge: merged three first, will wait till they build and look at last one
2020-05-20 11:11:11 <timlegge> thanks
2020-05-20 11:12:13 <mps> ikke: well, at the end everything is subjective (when you pulled my philosopher mind) for subjects but that doesn't mean that objectivity doesn't exist
2020-05-20 11:13:01 <ikke> yes, but that's where the 2nd part comes in :)
2020-05-20 11:14:13 <mps> :)
2020-05-20 11:18:22 <mps> (btw, I would advice everyone to look at old Latin subject/object terms origin and their meaning)
2020-05-20 11:21:25 <ncopa> sudo is becoming pretty bloated. new in sudo 1.9 is pyhon module support and a log server
2020-05-20 11:21:42 <ncopa> anyone knows why sudo needs a log server?
2020-05-20 11:21:58 <ikke> hmm, a log *server*. No idea
2020-05-20 11:24:39 <Cogitri> Python support is kinda neat to add your own custom hooks for sudo, they showcased that at FOSDEM
2020-05-20 11:24:54 <Cogitri> I think they added integration to syslog-ng or something IIRC
2020-05-20 11:25:01 <Cogitri> They showcased that at FOSDEM too I think
2020-05-20 11:25:22 <Cogitri> https://fosdem.org/2020/schedule/event/python2020_sudo/
2020-05-20 11:25:36 <ikke> https://www.sudo.ws/man/1.9.0/sudo_logsrvd.man.html
2020-05-20 11:26:32 <Cogitri> Wat
2020-05-20 11:26:41 <ncopa> python i understand, but a log server?
2020-05-20 11:26:51 <Cogitri> Same here
2020-05-20 11:26:52 <ncopa> i read the man page, but did not understand why
2020-05-20 11:26:56 <Cogitri> Same
2020-05-20 11:27:09 <ncopa> maybe its related to sudoreplay
2020-05-20 11:27:15 <mps> huh, why python
2020-05-20 11:27:17 <Cogitri> Like when do you have so many sudo request that you need another server just to handle sudo logging
2020-05-20 11:27:23 <Cogitri> mps: Makes it super easy to extend sudo
2020-05-20 11:27:33 <Cogitri> See the FOSDEM talk I linked if you're curious about it
2020-05-20 11:27:54 <mps> huh, again, what's wrong now (again rhetorical question)
2020-05-20 11:28:16 <mps> hope 'doas' will not follow this
2020-05-20 11:28:25 <ikke> I would not expect so
2020-05-20 11:29:00 <ncopa> i'd like that doas is the default in alpine
2020-05-20 11:29:07 <ncopa> the preferred
2020-05-20 11:29:09 <mps> ncopa: +1
2020-05-20 11:29:22 <Cogitri> Yup, doas is nice
2020-05-20 11:29:34 <Cogitri> I use it on all of my machines
2020-05-20 11:29:41 <Cogitri> Although with an alias from doas to sudo because of muscle memory :)
2020-05-20 11:29:56 <mps> also I use it but still not on all
2020-05-20 11:30:17 <ncopa> i have replaced sudo with doas in my muscle memory too by now :)
2020-05-20 11:30:35 <mps> I should also
2020-05-20 11:30:44 <ikke> I use _ as an alias
2020-05-20 11:30:51 <ikke> so it does not matter what I alias that to :)
2020-05-20 11:30:58 <mps> nice idea
2020-05-20 11:31:49 <ncopa> i killed the cython tests on build-3-12-x86 it will fail anyway
2020-05-20 11:32:08 <ncopa> still waiting for the local build to finish
2020-05-20 11:32:16 <ncopa> takes an hour or two
2020-05-20 11:32:32 <ikke> wow
2020-05-20 11:32:49 <ncopa> local build is on a heavy build server
2020-05-20 11:32:54 <ncopa> the tests are not parallelized
2020-05-20 11:33:39 <Cogitri> Oof
2020-05-20 11:33:40 <Cogitri> Remembers me of Pypy
2020-05-20 11:34:16 <ncopa> i really want the builders to complete so we can tag 3.12 rc1
2020-05-20 11:36:16 <Cogitri> Fortunately everything other than cython seems to work now, right?
2020-05-20 11:37:15 <Cogitri> There are some things for main which would be nice to have for 3.12 like the security upgrade for dovecot, but we can backport that
2020-05-20 11:39:45 <ncopa> mips64 needs to finish too
2020-05-20 11:40:24 <ncopa> i think we can push dovecot. and postfix. they are not big or problematic
2020-05-20 11:41:10 <ncopa> i'd love to have go 1.14 too
2020-05-20 11:41:18 <ncopa> but mips is holding it back
2020-05-20 11:41:28 <Cogitri> Yup :/
2020-05-20 11:41:33 <mps> oh, postfix works on my server from yesterday
2020-05-20 11:41:45 <Cogitri> We kind of have a MR jam for main/ in general since I don't have bits for that
2020-05-20 11:41:45 <ncopa> good
2020-05-20 11:41:48 <mps> didn't noticed any issue
2020-05-20 11:42:01 <ncopa> Cogitri: im working on that
2020-05-20 11:42:28 <ncopa> Cogitri: meanwhile, please ping me if there are blockers in main
2020-05-20 11:42:35 <ncopa> that needs to be prioritized
2020-05-20 11:42:57 <ncopa> btw, i noticed that polkit does not use elogind
2020-05-20 11:43:23 <ncopa> so i needed to add back consolekit2 for my desktop due to virt-manager
2020-05-20 11:44:06 <ncopa> i think its a compile option, but we'd need to move elogind to main
2020-05-20 11:44:26 <ncopa> or lots other stuff, like libvirtd, to community
2020-05-20 11:45:43 <Cogitri> Install polkit-elogind and it should work
2020-05-20 11:46:46 <Cogitri> I think the current situation is fine with polkit in main/ and polkit-elogind in community/, isn't it?
2020-05-20 11:47:15 <Cogitri> I personally wouldn't mind making elogind the default though
2020-05-20 12:27:12 <markand> hi
2020-05-20 12:31:45 <markand> not sure what I've done with my git repository but wanted to update my MRs and now they include lots of changes not related
2020-05-20 12:32:41 <markand> e.g. !6912
2020-05-20 12:33:37 <AinNero> markand: you only want one commit in there?
2020-05-20 12:34:39 <AinNero> unsure how you got into that situation, but i would re-create the branch from master, and then cherry-pick my commit onto it
2020-05-20 12:34:48 <AinNero> and then force push over the messed up branch on gitlab
2020-05-20 12:36:37 <markand> let me check
2020-05-20 12:39:22 <markand> hmmm, deleting the remote branch closed the issue, so let's start with a fresh one instead
2020-05-20 12:42:11 <markand> AinNero, it worked for my other MR, thanks :)
2020-05-20 12:54:22 <mps> cython is 'sleeping' on x86 builder
2020-05-20 12:54:54 <hrio[m]> Cogitri can you check !8121 for me?
2020-05-20 13:04:43 <Cogitri> Ah, it sets the weird permissions with install -m and not with chmod?
2020-05-20 13:05:06 <Cogitri> If so, then lgtm I suppose, would be nice if the CI checked for such things though
2020-05-20 13:19:51 <hrio[m]> It wants these perms on its own directories that are created with mkinstalldirs -m 02770
2020-05-20 13:21:01 <Cogitri> Should be OK then
2020-05-20 13:21:31 <hrio[m]> These directories where not included in the old version of the package
2020-05-20 14:26:02 <ncopa> Cogitri: oh, good. polkit-elogind should work
2020-05-20 14:26:54 <Cogitri> Yup, some stuff like GNOME already pulls it in by default
2020-05-20 14:29:36 <clandmeter> anyone can move aerc to community?
2020-05-20 14:29:53 <clandmeter> or is there a reason to keep it in testing?
2020-05-20 14:30:54 <mps> anyone can ublock x86 builders, cython is keeping it to work
2020-05-20 14:34:41 <ncopa> mps: i think i just did with 93d811c8bcd30b8df4b7f8676e4f58c3eb405f30
2020-05-20 14:34:54 <ncopa> it takes a couple of hours to build it though
2020-05-20 14:35:25 <mps> build.a.o shows it is idle
2020-05-20 14:36:57 <mps> hmm, not idle, activity column is empty
2020-05-20 14:38:35 <ncopa> it is running the tests for cython
2020-05-20 15:55:34 <Ariadne> clandmeter: done
2020-05-20 16:40:37 <clandmeter> Ariadne: grazie
2020-05-20 18:54:11 <Cogitri> Someone with main bits has time to look at !7350 ?
2020-05-20 18:58:29 <ikke> Will be merged after pipeline succeeds (again)
2020-05-20 22:55:08 <minimal> trying to git clone from gitlab.alpinelinux.org (172.105.69.85) but SSH connection is failing, connection refused. Gitlab does show the "Clone with SSH" url as "git@gitlab.alpinelinux.org:whatever/aports.git".
2020-05-20 23:22:27 <minimal> Nevermind - PEBKAC, forgot the firewall rules for the particular network subnet here block outgoing SSH
2020-05-20 23:33:03 <dalias> :)
2020-05-21 01:17:08 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8103
2020-05-21 01:17:40 <rahmanshaber[m]> guys is that line break i did is correct?
2020-05-21 01:23:08 <rahmanshaber[m]>  * guys is that line break i did correct?
2020-05-21 02:35:52 <[[sroracle]]> rahmanshaber[m]: i think you indent just one tab character. that looks like 15 spaces or something
2020-05-21 02:36:38 <rahmanshaber[m]> so i have add 1 tab instead of 15 sspacing?
2020-05-21 02:37:12 <[[sroracle]]> the second line should start with a tab instead of "		                   " yeah
2020-05-21 02:44:40 <rahmanshaber[m]> [[sroracle]]:  can you please check now.
2020-05-21 04:54:55 <rahmanshaber[m]> [[sroracle]]: please
2020-05-21 04:56:41 <ikke> rahmanshaber[m]: https://gitlab.alpinelinux.org/rahmanshaber/aports/-/jobs/122022
2020-05-21 04:57:36 <rahmanshaber[m]> i saw that but there is nothing pointing the error
2020-05-21 04:59:10 <ikke> it gives you the lines that causes the issue
2020-05-21 05:04:36 <rahmanshaber[m]> i added the tab but it gives me the warning again
2020-05-21 05:05:15 <rahmanshaber[m]> and what does this means?
2020-05-21 05:05:15 <rahmanshaber[m]> SC:[AL54]:APKBUILD:19:prepare() is missing call to 'default_prepare'
2020-05-21 05:05:15 <rahmanshaber[m]> ```
2020-05-21 05:06:03 <ikke> it means you have to call default_prepare in your prepare function
2020-05-21 05:06:47 <ikke> Just add "default_prepare" above line 20
2020-05-21 05:08:15 <rahmanshaber[m]> and that tab warning?
2020-05-21 05:08:34 <ikke> it means that you've used spaces instead of tabs for indentation
2020-05-21 05:09:11 <ikke> I guess your editor inserts spaces when you press tab
2020-05-21 05:09:46 <ikke> What editor do you use?
2020-05-21 05:14:06 <rahmanshaber[m]> qtcreator
2020-05-21 05:14:19 <rahmanshaber[m]> <ikke "I guess your editor inserts spac"> it does
2020-05-21 05:14:41 <rahmanshaber[m]> so you guys are against space?
2020-05-21 05:15:15 <ikke> The codestyle for aports is to use tabs
2020-05-21 05:15:15 <rahmanshaber[m]> can you help me in to make all the commit to one?
2020-05-21 05:15:53 <rahmanshaber[m]> i tried the reset head but it does not change the actual file.
2020-05-21 05:16:24 <rahmanshaber[m]> or should i open a new MR?
2020-05-21 05:16:25 <ikke> git reset master. git commit
2020-05-21 05:16:27 <ikke> no
2020-05-21 05:16:57 <rahmanshaber[m]> so first git reset master
2020-05-21 05:17:00 <ikke> yes
2020-05-21 05:17:05 <rahmanshaber[m]> then git add
2020-05-21 05:17:11 <ikke> yes
2020-05-21 05:17:14 <rahmanshaber[m]> then git push
2020-05-21 05:17:16 <ikke> no
2020-05-21 05:17:21 <ikke> git commit
2020-05-21 05:18:06 <rahmanshaber[m]> ohh.
2020-05-21 05:18:25 <rahmanshaber[m]> and i want to move a package to comunity
2020-05-21 05:18:42 <rahmanshaber[m]> should i update first then move or oposite?
2020-05-21 05:19:08 <ikke> the pipeline is green btw :)
2020-05-21 05:19:49 <ikke> I don't think the order matters
2020-05-21 05:19:52 <rahmanshaber[m]> <ikke "the pipeline is green btw :)"> yes. thanks.
2020-05-21 05:20:41 <rahmanshaber[m]> git mv testing/coretoppings comunity/coretopping will move it right?
2020-05-21 05:20:48 <rahmanshaber[m]> ii don't want to screw up
2020-05-21 05:21:02 <ikke> yes, should
2020-05-21 05:25:15 <rahmanshaber[m]> git reset master did not change the files .
2020-05-21 05:27:19 <ikke> No, would you exit it to?
2020-05-21 05:27:34 <ikke> You just want to create a single commit, right?
2020-05-21 05:27:46 <rahmanshaber[m]> yes
2020-05-21 05:28:05 <ikke> then you don't want to change your files
2020-05-21 05:28:33 <rahmanshaber[m]> so now git add and commit and push
2020-05-21 05:28:36 <rahmanshaber[m]> right?
2020-05-21 05:28:37 <ikke> push -f
2020-05-21 05:28:39 <ikke> yes
2020-05-21 05:31:36 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8103/commits?commit_id=a339cf1daaec6a949453487d1ae0b1eef1903a53
2020-05-21 05:31:37 <rahmanshaber[m]> it is a deserter
2020-05-21 05:32:03 <rahmanshaber[m]> i am open a new MR
2020-05-21 05:33:10 <ikke> :(
2020-05-21 05:33:25 <rahmanshaber[m]> new MR?
2020-05-21 05:35:25 <rahmanshaber[m]> ikke:
2020-05-21 05:35:45 <ikke> I understand what you mean now, that was my bad
2020-05-21 05:37:24 <rahmanshaber[m]> no. it happend many times , that's why i hate to work on git things
2020-05-21 05:37:33 <rahmanshaber[m]> new MR then?
2020-05-21 05:37:49 <ikke> not necessary, and won't fix this
2020-05-21 05:38:30 <rahmanshaber[m]> i will use a new branch
2020-05-21 05:42:41 <ikke> git reset 624180d6ca79ba7581c248e723a2c4c466a57f88
2020-05-21 05:42:55 <ikke> That would return your branch to the state it was before
2020-05-21 05:44:53 <rahmanshaber[m]> alredy done new MR. sorry. i know that's not the way to do it.
2020-05-21 05:48:16 <rahmanshaber[m]> please don't hate me, the new MR is done.
2020-05-21 05:48:16 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8177
2020-05-21 06:49:34 <mps> timlegge: someone already merged iwatch and saved me of work :)
2020-05-21 06:49:44 <maxice8> yes
2020-05-21 07:11:06 <maxwell-k> how do we handle CWEs? is there anything special to do? I can't find anything in the wiki
2020-05-21 07:11:32 <maxwell-k> I am also just learning the difference CVE vs CWE https://danielmiessler.com/blog/difference-cve-cwe/
2020-05-21 07:30:34 <ncopa> we dont really have any system for handling CWEs
2020-05-21 07:41:18 <mps> ncopa: should we backport DANE fix for musl and postfix to 3.11-stable
2020-05-21 07:41:41 <mps> I think we should
2020-05-21 07:42:38 <mps> if you agree to push I can prepare MRs, I already have postfix fix nearly ready
2020-05-21 07:46:37 <maxwell-k> ncopa: ty, just wanted to check I didn't miss anything
2020-05-21 07:49:11 <maxwell-k> by the way, https://cwe.mitre.org/data/definitions/93.html was the example I was looking at for mr !8181
2020-05-21 07:49:57 <maxwell-k> if a backport is appropriate I could have a go
2020-05-21 07:53:01 <ikke> Yeah, it can be backported to 3.11
2020-05-21 07:56:03 <ikke> maxwell-k: I see it's released as a new minor version rather than a patch
2020-05-21 07:56:16 <ikke> So I guess you would have to backport it yourself
2020-05-21 08:00:55 <ncopa> mps: i think we can backport postfix DANE patch, but I'd like to wait a bit to see if the musl fix causes any issues first
2020-05-21 08:01:52 <mps> ok, I created !8183 and assigned to you but put WIP on it
2020-05-21 08:02:42 <mps> if someone can test this who uses DANE will be nice
2020-05-21 08:03:07 <mps> I only tested with https://havedane.net/
2020-05-21 08:15:25 <maxwell-k> ikke: thanks I hadn't really thought that through, what would a backport look like?
2020-05-21 08:15:36 <maxwell-k> the relevant patch from 0.18.0 added to 0.14.0-r1 to give 0.14.0-r2 in the 3.11 branch?
2020-05-21 08:16:25 <maxwell-k> I think the patch would be a version of https://github.com/httplib2/httplib2/commit/a1457cc31f3206cf691d11d2bf34e98865873e9e
2020-05-21 08:16:26 <ikke> 3.11 has 0.17.4-r0 right now
2020-05-21 08:16:34 <ikke> no
2020-05-21 08:16:36 <ikke> nod*
2020-05-21 08:16:48 <maxwell-k> https://pkgs.alpinelinux.org/package/v3.11/main/x86_64/py3-httplib2
2020-05-21 08:17:17 <maxwell-k> is what I'm seeing, so 0.14.0-r1, or have I got something wrong?
2020-05-21 08:17:35 <ikke> oh, sorry, was looking at edge
2020-05-21 08:17:46 <ikke> then yes
2020-05-21 08:22:08 <maxwell-k> ikke: ty, will try that later on
2020-05-21 08:22:18 <ikke> basically adding https://github.com/httplib2/httplib2/commit/a1457cc31f3206cf691d11d2bf34e98865873e9e.patch
2020-05-21 08:35:18 <maxice8> Shouldn't those be put in secfixes ?
2020-05-21 08:35:49 <ikke> The project should request CVE's first
2020-05-21 08:36:05 <maxice8> carry on then
2020-05-21 08:36:10 <ikke> A CWE is more like a discription of common vulnerability
2020-05-21 08:37:06 <maxice8> @ikke updated atools
2020-05-21 08:37:27 <maxice8> new lint will complain when one sets -DCMAKE_BUILD_TYPE= in a cmake APKBUILD but does not set it to None
2020-05-21 08:37:50 <ikke> ok
2020-05-21 08:38:30 <Cogitri> Does it also complain about meson buildtype?
2020-05-21 08:39:39 <maxice8> no
2020-05-21 08:39:47 <maxice8> we can add a separate one for it
2020-05-21 08:40:15 <Cogitri> That'd be great
2020-05-21 08:58:18 <ncopa> im cloning build-edge-mips64 to build-3-12-mips64 now
2020-05-21 08:59:24 <ncopa> those needs to be fixed before the 3.12 release: https://tpaste.us/Mbr7
2020-05-21 08:59:48 <ikke> croc is still failing as well
2020-05-21 08:59:56 <ikke> most likely due to endianess
2020-05-21 08:59:58 <ncopa> thats in testing
2020-05-21 09:00:01 <ikke> ok
2020-05-21 09:00:04 <Cogitri> That link is only for mips?
2020-05-21 09:00:04 <ncopa> which we dont care about for 3.12
2020-05-21 09:00:12 <ikke> yeah, makes sense
2020-05-21 09:00:14 <ncopa> yes, thats for mips64
2020-05-21 09:00:15 <ikke> didn't noticed that
2020-05-21 09:00:28 <ncopa> i think armv7 has a few missing deps as well
2020-05-21 11:22:07 <ncopa> ugh.. new cython release....
2020-05-21 11:37:47 <ncopa> i have set up build-3-12-mips64
2020-05-21 11:37:58 <ncopa> created hardlinks for much of the stuff
2020-05-21 11:38:57 <ncopa> but v3.12/*/mips64 will use space on the mirrors, unless rsync is set up to transfer hardlinks as hardlinks
2020-05-21 12:35:41 <maxwell-k> I'm getting `ERROR: py3-docutils-0.15.2-r0: BAD signature
2020-05-21 12:36:03 <maxwell-k> has that been reported somewhere, sorry?
2020-05-21 12:37:27 <ikke> Havent heard of it
2020-05-21 12:37:32 <ikke> it has been downgraded in january
2020-05-21 12:37:53 <ikke> clandmeter: do you know how long dl-cdn caches packages?
2020-05-21 12:38:57 <maxwell-k> I'm only getting it intermittently, and on a remote host
2020-05-21 12:39:11 <ikke> what mirror?
2020-05-21 12:39:23 <maxwell-k> let me check
2020-05-21 12:39:59 <maxwell-k> http://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
2020-05-21 12:40:12 <maxwell-k> will try a different one
2020-05-21 12:40:22 <maxwell-k> thank you!
2020-05-21 12:40:52 <ikke> We see this issue most of the time after a package has been downgraded to an earlier version, where fastly still has the old version in cache
2020-05-21 12:41:01 <ikke> so the package does not match the index
2020-05-21 12:41:12 <ikke> But I would not expect it to be an issue after 4 months
2020-05-21 12:46:01 <ncopa> ikke: IIRC it is curl -X PURGE $URL
2020-05-21 12:46:14 <ikke> yes, I'm aware
2020-05-21 12:46:22 <ikke> Just wondering why it's still an issue
2020-05-21 13:06:51 <maxwell-k> thanks for the explanation too, switching to the uk mirror was a workaround, I will investigate a bit further in a few hours time
2020-05-21 13:07:28 <ikke> I can just purge it, and it will most likely work
2020-05-21 13:49:06 <mps> this is for kernel 5.8 https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=next&id=66ff14e59e8a30690755b08bc3042359703fb07a
2020-05-21 13:49:23 <mps> but maybe it is worth of backporting
2020-05-21 13:50:00 <mps> saves some power in PCIe
2020-05-21 13:51:45 <ncopa> i have a crazy idea
2020-05-21 13:52:03 <ncopa> what if we had an online developer conference?
2020-05-21 13:52:21 <mps> yes, idea is crazy
2020-05-21 13:52:29 <ncopa> now that all conferences are online anyway
2020-05-21 13:53:11 <ncopa> and its relatively cheap and simple. no need to organize a physical space, food etc
2020-05-21 13:53:37 <mps> audio, you mean
2020-05-21 13:53:44 <Cogitri> Sounds cool, but what would we discuss?
2020-05-21 13:53:55 <ncopa> we send out a call for papers
2020-05-21 13:54:00 <mps> I still prefer IRC
2020-05-21 13:54:11 <ncopa> invite people to talk about something they want to talk about
2020-05-21 13:54:25 <ncopa> then open for questions/answers
2020-05-21 13:54:36 <ncopa> could be a half day or a full day
2020-05-21 13:54:42 <Cogitri> mps: I don't think that patch needs to be backported, the change only improves energy efficiency for a limited amount of systems
2020-05-21 13:55:04 <ncopa> i have a couple of things that could be discussed
2020-05-21 13:55:07 <Cogitri> Hm, do you want the conference to only be Alpine specific?
2020-05-21 13:55:20 <mps> Cogitri: yes, but hot summer is coming, some will be grateful :)
2020-05-21 13:55:23 <Cogitri> I can't really come up with a topic I could talk about for more than a few minutes
2020-05-21 13:55:32 <ncopa> yes, alpine developer specific
2020-05-21 13:55:48 <ncopa> we could include things like general musl etc
2020-05-21 13:56:05 <mps> I have one already, get rid of -static libs :)
2020-05-21 13:56:06 <Cogitri> mps: Heh, right now I'm still happy about my 3950X being my trusty room heater :P
2020-05-21 13:56:09 <ncopa> but all sessions needs to have some sort of relation with alpine
2020-05-21 13:56:17 <ncopa> :D
2020-05-21 13:56:52 <mps> Cogitri: summer is nearing, I will wait you to pledge for patch :)
2020-05-21 13:57:16 <ncopa> things i could talk about: build infra. how it currently works (and how it got there) and what my thougts/ideas are for how i think it should work
2020-05-21 13:57:30 <ncopa> alpine governance
2020-05-21 13:57:54 <mps> huh, hot summer is really coming :D
2020-05-21 13:58:29 <ncopa> i'd love to hear a session about the alpine infra, or how the gitlab migration went
2020-05-21 13:58:49 <ncopa> or what the plans are for apk3
2020-05-21 13:58:53 <ncopa> plans and status
2020-05-21 13:59:12 <Cogitri> Oh yes, alpine infra and apk3 would be very interesting
2020-05-21 13:59:15 <Cogitri> Maybe we could invite the pmOS folks over too
2020-05-21 13:59:20 <ncopa> ofc
2020-05-21 13:59:27 <mps> and adelie
2020-05-21 13:59:36 <ncopa> i think gentoo ppl, void linux ppl, adelie ppl could be interested
2020-05-21 13:59:41 <mps> they still use apk
2020-05-21 13:59:51 <ncopa> docker people
2020-05-21 14:00:38 <ncopa> we already have 4 sessions. enough for a half day
2020-05-21 14:01:22 <mps> but conference without barbecue and wine :\
2020-05-21 14:01:38 <ncopa> well, not necessarily. that depens on you :)
2020-05-21 14:01:55 <Cogitri> Heh
2020-05-21 14:02:10 <Cogitri> Sounds like a great idea overall :)
2020-05-21 14:02:29 <ikke> Any idea what we want to use to 'host' this conference?
2020-05-21 14:02:39 <ncopa> could be anything
2020-05-21 14:02:56 <ncopa> but i guess it depends on who volunteers to manage it
2020-05-21 14:03:29 <ikke> The only open-source thing I'm aware of is jitsi, but it's very bare-bones
2020-05-21 14:03:38 <ncopa> i wouldnt mind zoom
2020-05-21 14:03:45 <Cogitri> We could take a look at what other conferences that switched to online conferences used
2020-05-21 14:03:52 <mps> I'm for jitsi
2020-05-21 14:04:10 <ncopa> let me send the email to the mailing list
2020-05-21 14:04:19 <Cogitri> I haven't used Jitsi much but I have to admit Zoom worked better for me
2020-05-21 14:04:25 <mps> debian made it in last two months as their communication platform
2020-05-21 14:04:26 <ikke> I
2020-05-21 14:05:01 <ncopa> thats a secondary problem
2020-05-21 14:05:12 <mps> I used jitsi some time long time ago, don't know how it is now
2020-05-21 14:06:45 <mps> there is mummble also
2020-05-21 14:06:57 <ncopa> i think we need one or two people who can run this project
2020-05-21 14:07:33 <hjaekel> We should use a software that can be installed on Alpine
2020-05-21 14:07:42 <ncopa> of all the things i have used, zoom has been the most reliable
2020-05-21 14:07:55 <ncopa> and has had the best quality
2020-05-21 14:08:03 <mps> hjaekel: agree
2020-05-21 14:08:35 <ncopa> hjaekel: and if there are nothing that is good enough, we drop the conference?
2020-05-21 14:09:26 <mps> yes, drop if we have to use non free platform
2020-05-21 14:10:14 <mps> personally I will feel ashamed to use non free for free software project
2020-05-21 14:10:31 <hjaekel> ncopa, I did not say that
2020-05-21 14:10:39 <mps> call me idealist or whatever, but that how I feel
2020-05-21 14:10:40 <Cogitri> You can run Zoom in your browser too
2020-05-21 14:12:13 <mps> I can run windows or macos also
2020-05-21 14:13:03 <mps> and make MRs or other things for alpine, but I prefer 'eat your food' principle
2020-05-21 14:14:01 <ncopa> I agree that it would be preferable that it could be run on alpine, but I doubt there are anything that can handle 100+ attendees.
2020-05-21 14:14:16 <mps> ofc, all of you are free to do however you like
2020-05-21 14:15:11 <ncopa> there are not too many good videoconferencing tools, and even fewer that are OSS
2020-05-21 14:15:33 <mps> yes, true, I know
2020-05-21 14:50:57 <wsinatra> Jitsi meet might be a solution for video conferencing. There's a recurring Lisp conference that uses it, should be free/OSS I believe
2020-05-21 16:10:57 <maxwell-k> I love the idea of an online Alpine conference
2020-05-21 16:23:24 <mps> can someone explain why CI says '>>> ERROR: exfatprogs-dev*: prepare_package failed' in !8155
2020-05-21 16:24:09 <mps> it worked for pkgver=1.0.2 but not for pkgver=1.0.3
2020-05-21 16:25:57 <Cogitri> I guess it doesn't install development files (headers, .so files) anymore?
2020-05-21 16:26:39 <mps> it builds them and headers are there, but not install them
2020-05-21 16:27:00 <mps> could be upstream bug?
2020-05-21 16:27:17 <Cogitri> Probably, yes
2020-05-21 16:27:37 <Cogitri> Or maybe they moved it to a separate install target
2020-05-21 16:28:08 <mps> I looked at generated Makefile but didn't found this
2020-05-21 16:28:27 <mps> also, this was my first mind
2020-05-21 16:29:16 <mps> Cogitri: thanks, for now I will disable -dev subpackage
2020-05-21 16:30:13 <mps> just wanted to be sure that I didn't made error in APKBUILD
2020-05-21 16:31:07 <Cogitri> I don't see one :)
2020-05-21 16:31:39 <mps> thanks :)
2020-05-21 19:01:21 <Cogitri> Can we tell shellcheck that $pkgdir is always set?
2020-05-21 19:01:25 <Cogitri> So we can avoid warnings like this: https://gitlab.alpinelinux.org/Bridouz/aports/-/jobs/122289#L38
2020-05-21 19:02:34 <hjaekel> I support that Cogitri
2020-05-21 19:02:53 <ikke> let's see
2020-05-21 19:07:35 <ikke> I don't think you can trick it
2020-05-21 19:07:44 <Cogitri> That's unfortunate
2020-05-21 19:07:50 <ikke> setting it explicitly before the rm will still cause this warning
2020-05-21 19:13:49 <ikke> It always warns when you have an rm which includes important paths
2020-05-21 19:16:10 <Cogitri> Well, I guess it does make sense that it doesn't want us to accidentally nuke our rootfs
2020-05-21 19:17:05 <ikke> yup
2020-05-21 19:17:45 <ikke> The explenation of the lint refers to STEAMROOT :)
2020-05-21 19:32:46 <Hello71> well abuild is basically pre-defining the variables
2020-05-21 19:33:26 <Hello71> so I think it should start the apkbuild for shellcheck like "source apkvars" and then that has the pkgdir and other variables predefined
2020-05-21 19:33:53 <ikke> Hello71: we already do that
2020-05-21 19:34:00 <ikke> but that does not matter for this check
2020-05-21 19:34:03 <Hello71> does it still do that?
2020-05-21 19:34:56 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/overlay/usr/share/abuild/APKBUILD_SHIM
2020-05-21 19:44:57 <Hello71> I think one argument for this is like Cogitri said, what if abuild stops exporting pkgdir
2020-05-21 19:45:16 <Hello71> I guess it might be good if shellcheck could have a whitelist of variables
2020-05-21 19:45:48 <ikke> I don't see the issue changing this to a safer variant
2020-05-21 19:47:58 <Cogitri> It's not a huge problem, but it's the linter complaining for no actual reason
2020-05-21 19:48:30 <Cogitri> And contributors have changed this because of the linter yelling at them only to then have a reviewer tell them that it's not necessary and that they can remove it, which is a bit annoying
2020-05-21 20:04:02 <Hello71> imo it would be good to have it whitelisted for a few specific variables
2020-05-21 20:04:12 <[[sroracle]]> i'd be very interested in a conference. might even have something to present :)
2020-05-21 20:04:38 <Hello71> I think it would actually be bad to have it be for all variables, even only global variables, on the basis that "what if you refactor and miss one instance"
2020-05-21 20:04:56 <Hello71> but nobody will change the name of pkgdir (hopefully?)
2020-05-22 03:15:20 <ikke> maxice8: py3-boto3 is broken
2020-05-22 03:15:26 <ikke> dependency issue
2020-05-22 03:15:36 <maxice8> i'll take a look
2020-05-22 04:08:29 <rahmanshaber[m]> Cogitri:  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8177
2020-05-22 05:18:54 <ncopa> morning! lets try get rc1 out today
2020-05-22 05:19:03 <maxice8> Morning :D
2020-05-22 06:19:20 <ncopa> can we try fix those now? https://gitlab.alpinelinux.org/alpine/aports/-/issues?milestone_title=3.12.0
2020-05-22 06:21:10 <Cogitri> ncopa: Could you please take a look at !8217 ?
2020-05-22 06:21:27 <Cogitri> CLang is broken on x86 on edge right now
2020-05-22 07:01:38 <ikke> Cogitri: apparently it fails (killed signal) on x86_64 in CI?
2020-05-22 07:03:00 <Ariadne> should alpine-base depend on GNU patch?
2020-05-22 07:03:14 <Cogitri> I think that's the runner OOMing
2020-05-22 07:04:04 <Cogitri> Ariadne: It's just the name of the file where we add our triplets, if you mean the Clang change
2020-05-22 07:04:14 <Ariadne> no
2020-05-22 07:04:18 <Ariadne> i mean #11001
2020-05-22 07:04:20 <mps> Ariadne: now when you dropped bb patch, what is the question :)
2020-05-22 07:05:05 <ikke> Ariadne: do we expect patch to be always available?
2020-05-22 07:05:20 <Ariadne> ikke: personally, i don't, but i don't want to break any pre-existing installs
2020-05-22 07:05:48 <maxice8> I don't
2020-05-22 07:06:14 <Ariadne> i think it's ok to just mention it in release notes.
2020-05-22 07:06:16 <mps> some users (especially admins) expect
2020-05-22 07:06:49 <Cogitri> I think at that point it's fine to install GNU patch though, isn't it?
2020-05-22 07:06:49 <mps> I remember from #alpine-linux
2020-05-22 07:06:54 <Ariadne> yes, but sysadmins likely use stuff like quilt which depends on GNU patch anyway
2020-05-22 07:07:07 <Cogitri> We're even pulling it in with alpine-sdk
2020-05-22 07:07:18 <ikke> it's a dependency of abuild
2020-05-22 07:07:30 <Cogitri> Because Busybox patch isn't really usable
2020-05-22 07:07:40 <maxice8> Can't we put it in build-base ?
2020-05-22 07:07:44 <mps> it is not issue for devs
2020-05-22 07:07:51 <maxice8> or should people just install alpine-sdk
2020-05-22 07:08:24 <ikke> alpine-sdk should only be necessary if you plan to build alpine-packages
2020-05-22 07:08:44 <maxice8> so if someone in, say docker, wants to compile some stuff then they need to apk add build-base patch
2020-05-22 07:09:06 <Ariadne> yes, build-base should pick it up
2020-05-22 07:09:32 <mps> abuild deps on patch
2020-05-22 07:09:57 <ikke> yes, because it actually depends on it
2020-05-22 07:10:12 <ikke> but that's separate from whether it should be present in build-base as well
2020-05-22 07:11:02 <mps> actually I dislike much deps but this one is ok
2020-05-22 07:11:05 <Ariadne> i think it is reasonable for build-base to have it
2020-05-22 07:11:43 <ikke> me too
2020-05-22 07:11:52 <Ariadne> and i think if any sysadmin is playing with patch, they probably have build-base already installed so they have a compiler too
2020-05-22 07:23:06 <maxice8> I think i should also document the abuild-meson helper
2020-05-22 08:01:08 <ikke> Ariadne: thanks for fixing krita :)
2020-05-22 08:20:11 <PureTryOut[m]> Are there examples of packaging Java applications?
2020-05-22 08:22:20 <detha> elasticsearch
2020-05-22 08:27:36 <PureTryOut[m]> `depends="openjdk8-jre"`. Should we force the user to openjdk8 specifically? Can we not make it depend on e.g. java-common?
2020-05-22 08:30:16 <ikke> java-common only contains a few binaries, I don't think it works just to depend on that
2020-05-22 08:37:14 <detha> it will have depend on a jre. Most things only work well with a particular version jre anyway, so probably it wouldn't be a bad thing
2020-05-22 08:38:29 <PureTryOut[m]> Hmm ok
2020-05-22 08:49:29 <PureTryOut[m]> I'm guessing Java packages either use pre-compiled binaries or do compile from source, but let the build system download all the dependencies? elasticsearch doesn't even have a build function
2020-05-22 08:52:26 <ikke> seems like elasticsearch is pre-compiled binariers....
2020-05-22 08:52:30 <ikke> binaries
2020-05-22 08:53:19 <ikke> ncopa: don't we require everything to be built from source?
2020-05-22 08:59:11 <ncopa> um... not sure if that is a hard requirement
2020-05-22 08:59:21 <ikke> hmm, ok
2020-05-22 09:00:05 <ncopa> but build from source is definitively preferred when possible
2020-05-22 09:06:18 <PureTryOut[m]> Well you need to build from source for reproducible packages no?
2020-05-22 09:08:15 <Ariadne> welp, i ported krita to run on opengles only
2020-05-22 09:08:22 <Ariadne> but everything looks like an LSD trip
2020-05-22 09:08:27 <Ariadne> so i drop arm for now :)
2020-05-22 09:08:39 <ikke> heh
2020-05-22 09:08:51 <Ariadne> will figure it out next week
2020-05-22 09:09:39 <ncopa> maybe we shoudl disable aarch64 too
2020-05-22 09:09:52 <Ariadne> i did
2020-05-22 09:09:59 <ncopa> ok
2020-05-22 09:10:18 <ncopa> good. thanks
2020-05-22 09:10:24 <ncopa> let me kill the build on edge then
2020-05-22 09:10:35 <Ariadne> well the curren tbuilds are to remove the crap
2020-05-22 09:10:39 <Ariadne> or do you mean aarch64
2020-05-22 09:12:12 <ncopa> i meant kill the krita build on build-edge-aarch64
2020-05-22 09:12:21 <ncopa> it would end up with failure anyway
2020-05-22 09:13:22 <ncopa> i want tag 3.12.0_rc1 now
2020-05-22 09:13:35 <ncopa> i have 45 mins then i need to go
2020-05-22 09:14:05 <Ariadne> no objections
2020-05-22 09:14:51 <ncopa> i have problems with the mips64 release media, so currently it only produces a minirootfs and thats it
2020-05-22 09:15:27 <Ariadne> well there is not really any point in an iso anyway
2020-05-22 09:15:31 <Ariadne> or do you mean netboot
2020-05-22 09:15:39 <ncopa> yes that too
2020-05-22 09:16:15 <ncopa> Cogitri: re !8217 it seems to fail on x86_64. I dont have time to look at it today. want get rc1 out *now*
2020-05-22 09:16:23 <Cogitri> Ah sure
2020-05-22 09:16:35 <Cogitri> I think it fails on x86_64 because the runner runs out of RAM
2020-05-22 09:17:04 <ncopa> Ariadne: problem is that release scripts (update-kernel to be specific) assmues/requires an initramfs, but there are none for the mips kernel
2020-05-22 09:17:24 <Ariadne> oh for linux-octeon ?
2020-05-22 09:17:28 <ncopa> yes
2020-05-22 09:17:42 <Ariadne> we can generate one
2020-05-22 09:17:44 <ncopa> no initramfs for linux-octeon as I understand
2020-05-22 09:17:53 <ncopa> there are no modules
2020-05-22 09:17:55 <Ariadne> but only some boards can use it
2020-05-22 09:18:10 <ncopa> i mean, we could generate a dummy initramfs
2020-05-22 09:18:19 <ncopa> or fix the scripts to work without initramfs
2020-05-22 09:18:26 <Ariadne> i can look into it monday
2020-05-22 09:18:35 <ncopa> good. thanks!
2020-05-22 09:18:38 <Ariadne> please open a bug and assign to me so i don't forget
2020-05-22 09:22:56 <clandmeter> +1 for no initramfs feature
2020-05-22 09:23:32 <Cogitri> Can I still merge things while you're working on rc1, ncopa?
2020-05-22 09:24:59 <ncopa> well, i have 35 mins...
2020-05-22 09:25:10 <ncopa> if krita does not finish before that there will be no rc1
2020-05-22 09:25:28 <ncopa> if you merge, it may or may not prevent me from doing rc1
2020-05-22 09:25:47 <ncopa> tiny builds (2 mins) are ok if you do it noew
2020-05-22 09:26:05 <ncopa> if it takes 15 mins to build it will postpone the rc1 til monday
2020-05-22 09:26:19 <ncopa> so if you can wait 30 mins...
2020-05-22 09:28:43 <Cogitri> Sure, I'll wait
2020-05-22 09:31:42 <ikke> Cogitri: The machine has more then enough ram, it's probably that there are just too much jobs at the same time
2020-05-22 09:32:14 <Cogitri> Probably
2020-05-22 09:39:20 <ncopa> hum, its only edge x86 that builds krita now
2020-05-22 09:39:50 <ncopa> i think I'll just push the 3.12.0_rc1 tag and hope it does not fail. it passed on v3.12 builder
2020-05-22 09:50:11 <ncopa> whee!!! 3.12.0_rc1 is out!
2020-05-22 09:50:47 <PureTryOut[m]> 🎉
2020-05-22 09:54:34 <ikke> 🎊
2020-05-22 09:57:09 <mps> clandmeter: I'm also for not using initramfs but then more drivers will need to be in kernel and not as modules
2020-05-22 10:04:28 <clandmeter> for board specific kernels there is no need for modules. so i think its a nice option to have.
2020-05-22 10:20:22 <mps> yes, but we don't have much board specific kernels, though I would like if we can have them
2020-05-22 10:20:50 <PureTryOut[m]> Preferably all boards would just use the mainline kernel 😿
2020-05-22 10:21:22 <ncopa> thank you everyone for the 3.12 rc1! and have a nice weekend
2020-05-22 10:21:45 <PureTryOut[m]> You too!
2020-05-22 10:21:47 <mps> PureTryOut[m]: currently this only option we can do
2020-05-22 10:22:12 <PureTryOut[m]> I agree though for devices that don't run mainline yet, like the RPi
2020-05-22 10:22:28 <PureTryOut[m]> For one I'd want a RockPro64/rockchip kernel
2020-05-22 10:22:46 <ikke> Is there are reason rpi's don't use mainline yet?
2020-05-22 10:23:13 <mps> it is time for people who have these boards to try linux-edge and report issues
2020-05-22 10:23:40 <mps> or send me all these boards :D
2020-05-22 10:25:44 <clandmeter> ikke: is there a reason we should?
2020-05-22 10:26:09 <ikke> no, just curious
2020-05-22 10:26:10 <clandmeter> i mean all important functionality is in mainline now?
2020-05-22 10:26:35 <mps> clandmeter: afaik 5.6 could boot on RPi4, but I don't have it so can't confirm
2020-05-22 10:26:40 <clandmeter> from what i remember its possible to boot
2020-05-22 10:27:02 <clandmeter> but i guess some features will not be available
2020-05-22 10:27:52 <clandmeter> https://github.com/lategoodbye/rpi-zero/issues/43
2020-05-22 10:30:57 <mps> iirc, on debian-arm ML some people boot mainline kernel on RPi4 and use it
2020-05-22 10:31:36 <mps> don't know if they add some patches
2020-05-22 10:37:07 <artok> just asking on raspberrypi
2020-05-22 10:37:28 <artok> most of the irc active guys use 5.4
2020-05-22 10:39:27 <artok> for what they say, works "not well enough"
2020-05-22 10:40:19 <artok> and meantime they are releasing pi4 bootloaders that allow usb boot
2020-05-22 10:40:24 <mps> I saw not small number of commits in latest few kernel
2020-05-22 10:48:02 <artok> gottago..
2020-05-22 13:28:44 <rahmanshaber[m]> Cogitri: it worked. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8177
2020-05-22 13:28:51 <Cogitri> Yup, waiting for CI right now
2020-05-22 13:29:57 <Ariadne> so, about this proposed online alpine conference
2020-05-22 13:30:11 <Ariadne> when do people want to do it
2020-05-22 13:30:37 <ikke> I haven't heard any concrete dates yet
2020-05-22 13:32:01 <Cogitri> Same here, but after July would be best for me, exam time is at the end of June
2020-05-22 13:36:02 <rahmanshaber[m]> this passed at last.
2020-05-22 13:36:02 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8177
2020-05-22 13:36:06 <afontain_> Ideas on the form? Different talks at different times? Meetup groups?
2020-05-22 13:50:29 <Ariadne> I was thinking first or second week of august.
2020-05-22 13:52:07 <Cogitri> Sounds good to me
2020-05-22 13:56:17 <mps> oh, on my birthday :)
2020-05-22 13:56:35 <Ariadne> that would lead to a call for proposals ending mid July
2020-05-22 13:58:59 <Ariadne> we need to allow for some time for people to submit proposals, otherwise there won't be enough content.  that's why I suggest this timeframe.
2020-05-22 14:00:20 <Ariadne> this also gives us time to assemble a production crew (necessary to make the live stream work in a quality way), and figure out all the logistics
2020-05-22 14:04:12 <Ariadne> mps: when is your birthday
2020-05-22 14:16:41 <mps> beginning of august, usually second week
2020-05-22 14:17:21 <mps> 10
2020-05-22 14:25:18 <Ariadne> I was thinking august 8 and 9, possibly august 10 if there is runover
2020-05-22 14:32:49 <ikke> Ariadne: yes, I agree we should not do it too soon
2020-05-22 14:36:16 <mps> heh, managed to make alpine running on DSA taged ethernet bridge arm SOC
2020-05-22 14:37:13 <mps> broadcom BCM53125
2020-05-22 14:37:40 <mps> nice thing for writing guide
2020-05-22 14:48:33 <Ariadne> 8-9th sounds good tbh
2020-05-22 14:48:56 <Ariadne> next we need some mechanism to accept CFPs (this could be a gitlab repo tbh)
2020-05-22 14:51:27 <Cogitri> I think a gitlab repo where you submit a markdown file would work fine, that is if you want to make the process public
2020-05-22 14:52:03 <Ariadne> seems fine to me.  other conferences have done it that way
2020-05-22 14:53:15 <ikke> Haven't used it, but this could be an options as well: https://github.com/opencfp/opencfp (but most likely overcomplicated for what we need)
2020-05-22 14:54:53 <Ariadne> yeah whichever :)
2020-05-22 16:22:49 <PureTryOut[m]> How would you guys transform `v0.5.0-beta.16` into a valid pkgver? The `-` can easily be replaced by `_`, but I'm not sure how to do 2 string replacements in one variable usage
2020-05-22 16:22:52 <PureTryOut[m]> Or should I just make a _pkgver?
2020-05-22 16:25:56 <Cogitri> _pkgver probably is the way to go
2020-05-22 19:32:28 <ikke> Alp(onl)ine conference :D (suggestion by Shiz)
2020-05-22 19:32:43 <maxice8> aconf
2020-05-22 19:56:18 <c705> alpine conference would be awesome!
2020-05-22 20:22:12 <ikke> github is down
2020-05-22 20:22:26 <Cogitri> Huh, it's down pretty often these days
2020-05-22 20:22:45 <ikke> https://www.githubstatus.com/incidents/6tcfpztf6j9m
2020-05-22 20:28:24 <Ariadne> its been something in discussion for a while
2020-05-22 20:28:46 <Ariadne> previous ideas were to have something that ran in parallel to some other conference like dockercon
2020-05-22 20:28:54 <Ariadne> but covid has caused us to have to come up with new ideas
2020-05-23 00:47:29 <Shiz> cd /w 25
2020-05-23 09:36:32 <maxice8> hey
2020-05-23 09:36:40 <maxice8> community/simplemtpfs has a nice prepare() :D
2020-05-23 09:45:04 <mps> maxice8: :)
2020-05-23 09:55:16 <TBB> an interesting one for sure
2020-05-23 10:06:17 <mps> maybe I had reason for this, but forgot
2020-05-23 10:12:59 <maxice8> lots of beer possibly
2020-05-23 10:20:14 <ikke> no such file or directory: community/simplemtpfs
2020-05-23 10:20:28 <mps> no, it is one of the my first pkg which I used locally before I even contacted alpine in any way
2020-05-23 10:20:29 <ikke> community/simple-mtpfs exists
2020-05-23 10:20:47 <ikke> What is wrong with it?
2020-05-23 10:20:55 <ikke> default_prepare; ./autogen.sh
2020-05-23 10:21:09 <mps> and I don't like beer, I prefer wine or brandy :)
2020-05-23 10:21:29 <mps> ikke: duplicate ./autogen.sh
2020-05-23 10:21:57 <ikke> ah, was already fixed
2020-05-23 10:22:10 <ikke> 73a47947ebc03fbbaafa1ee80ee2493346e18cb8
2020-05-23 10:24:31 <mps> and I have probably more such old things in my local repo ;)
2020-05-23 10:25:22 <afontain_> Hi. I've made this MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8309
2020-05-23 10:25:37 <afontain_> I was wondering if I needed to do something to get the change in 3.12 as well
2020-05-23 10:26:09 <ikke> No, 3.12 is currently still master
2020-05-23 10:26:33 <ikke> only when 3.12 is released, it is branched off
2020-05-23 10:27:17 <afontain_> ok, thanks
2020-05-23 10:27:38 <afontain_> I saw there was 3.12.0_rc1 tag, already
2020-05-23 14:41:08 <ikke> sqlite 3.32.0 has been released yesterday
2020-05-23 14:41:21 <maxice8> have an MR for it
2020-05-23 14:41:24 <ikke> aha
2020-05-23 14:41:37 <maxice8> heh
2020-05-23 17:20:27 <nmeum> is it just me or is the gitlab down?
2020-05-23 17:20:33 <ikke> sorry, that was me
2020-05-23 17:20:37 <ikke> should be back up in a second
2020-05-23 17:20:45 <nmeum> alright, no worries :)
2020-05-23 17:21:27 <ikke> back
2020-05-23 17:21:32 <nmeum> \*/
2020-05-24 07:23:05 <Cogitri> Can I get some testers on !8332 ?
2020-05-24 07:24:20 <mps> Cogitri: sure, but this afternoon or night
2020-05-24 07:25:17 <mps> and do you have anything in particular that you know that need a more attention
2020-05-24 07:27:51 <Cogitri> Well, just some basic testing on an arch that's not x86_64 would be nice, e.g. getting the backtrace of a program that crashed
2020-05-24 07:33:17 <mps> ok, will test on armv7 or/and aarc64
2020-05-24 07:33:54 <Cogitri> Thanks
2020-05-24 07:34:56 <mps> np
2020-05-24 08:12:07 <ikke> iwatch in community depends on perl-mail-sendmail in testing..
2020-05-24 08:12:31 <Cogitri> Huh
2020-05-24 08:12:34 <Cogitri> How did that work in CI
2020-05-24 08:12:44 <maxice8> huh
2020-05-24 08:12:48 <maxice8> how didn't aports catch that ?
2020-05-24 08:13:40 <Cogitri> https://gitlab.alpinelinux.org/timlegge/aports/-/jobs/125434 Huh, it didn't build the packages..
2020-05-24 08:14:26 <ikke> hmmm
2020-05-24 08:14:56 <maxice8> also url= is wack
2020-05-24 08:15:12 <maxice8> url= is what we tell people not to do with source=
2020-05-24 08:16:40 <Cogitri> I guess we clashed a bit there with the commits
2020-05-24 08:16:58 <maxice8> i guess
2020-05-24 08:17:19 <Cogitri> Well, we can just re-enable iwatch once perl-mail-sendmail is done building
2020-05-24 08:19:47 <ikke> I wonder why CI thought there were no commits to build
2020-05-24 08:20:01 <maxice8> 3.10 builder is screwing with me
2020-05-24 08:20:53 <maxice8> took 2 retries to get to use my commit that fixes the tests for fail2ban
2020-05-24 08:28:30 <maxice8> objections to !8292
2020-05-24 08:28:35 <maxice8> !8293 i mean
2020-05-24 08:28:39 <maxice8> sqlite 3.32.0
2020-05-24 08:35:01 <ikke> "No soname differences for sqlite."
2020-05-24 08:51:47 <rahmanshaber[m]> guys i can't this package in repo but it shows in the gitlab/aport
2020-05-24 08:51:47 <rahmanshaber[m]> https://pkgs.alpinelinux.org/packages?name=coretime&branch=edge
2020-05-24 08:51:47 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/find_file/master
2020-05-24 08:52:26 <maxice8> are you in Alpine Linux edge ?
2020-05-24 08:53:02 <rahmanshaber[m]> yes
2020-05-24 08:53:07 <rahmanshaber[m]> pmos
2020-05-24 08:53:13 <maxice8> ok found the problem
2020-05-24 08:53:16 <maxice8> arch="alli"
2020-05-24 08:53:18 <maxice8> should be arch="all"
2020-05-24 08:53:44 <maxice8> try again after a few minutes
2020-05-24 08:53:54 <rahmanshaber[m]> my bad. why ci did not catch it?
2020-05-24 08:54:03 <maxice8> because it did not build the package
2020-05-24 08:58:38 <rahmanshaber[m]> i once saw lxqt DE packages in alpine but can't find them now or i am wrong?
2020-05-24 09:02:25 <rahmanshaber[m]> is this commit mssage is good enough
2020-05-24 09:02:25 <rahmanshaber[m]> ```
2020-05-24 09:02:25 <rahmanshaber[m]> move testing/coretoppings to community/coretoppings
2020-05-24 09:02:38 <ikke> maxice8: maybe we should add a lint check for arch=
2020-05-24 09:02:50 <maxice8> are you a f*cking wizard ?
2020-05-24 09:02:58 <maxice8> i am doing that right now invalid-arch [AL57]
2020-05-24 09:03:31 <ikke> :D
2020-05-24 09:03:54 <mps> rahmanshaber[m]:  community/coretoppings: move from testing
2020-05-24 09:05:11 <mps> look 'git log' in aports for examples of commit messages
2020-05-24 09:08:42 <rahmanshaber[m]> <mps "look 'git log' in aports for exa"> yeah i saw that after i asked, getting hang of this. thnaks for the help always.
2020-05-24 09:09:14 <rahmanshaber[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8353
2020-05-24 09:09:51 <mps> and, please don't quote messages here, it is not needed for IRC
2020-05-24 09:10:51 <rahmanshaber[m]> i used to that as riot supports it. will be careful in next time.
2020-05-24 09:11:16 <mps> rahmanshaber[m]: commit msg now looks fine
2020-05-24 09:12:28 <rahmanshaber[m]> thanks. i did mistake 3 times, i did not pushed them.
2020-05-24 09:12:41 <rahmanshaber[m]> git is very complicated.
2020-05-24 09:14:15 <mps> yes, but it is worth to learn its fine points
2020-05-24 09:19:31 <rahmanshaber[m]> yup
2020-05-24 12:38:18 <mps> Cogitri: do you have any executable or simple C source which I can test with gdb 9.2
2020-05-24 12:39:09 <mps> I tested with some my small programs but they are not fault
2020-05-24 12:43:25 <Cogitri> I guess something as simple as this should work: http://dpaste.com/30JV446
2020-05-24 12:45:45 <mps> sure :)
2020-05-24 12:46:22 <mps> I thought you have example where gdb doesn't work
2020-05-24 12:46:43 <Cogitri> Ah no, it works for me :)
2020-05-24 12:46:53 <mps> also for me
2020-05-24 12:47:08 <ikke> is gdb known to break?
2020-05-24 12:47:42 <mps> ikke: I don't know, Cogitri asked to check on some other arches
2020-05-24 12:47:57 <Cogitri> It's a bit broken around TLS on musl, but that has always been the case
2020-05-24 12:48:24 <Cogitri> Just wanted to make sure we have a simple runtime test before I go ahead and merge the upgrade :)
2020-05-24 12:49:06 <mps> Cogitri: I think you can merge it
2020-05-24 12:51:41 <mps> someone want to introduce jemalloc again !8352
2020-05-24 12:52:00 <ikke> Is that problematic?
2020-05-24 12:52:20 <mps> we have it in unmaintained/jemalloc
2020-05-24 12:52:51 <mps> if someone wants it it should move it back and not create new aport
2020-05-24 12:53:17 <Cogitri> Weren't there problems with jemalloc on musl?
2020-05-24 12:53:19 <mps> but, personally I don't see reason to have it
2020-05-24 12:53:22 <Cogitri> Or was that tcmalloc?
2020-05-24 12:53:43 <mps> jemalloc is problematic
2020-05-24 12:53:56 <mps> not sure about tcmalloc
2020-05-24 12:56:34 <Cogitri> I think musl's current allocator can be pretty slow in some cases
2020-05-24 12:57:43 <mps> I think you know that the new allocator is 'on the road'
2020-05-24 12:58:33 <mps> anyway, ime current musl allocator is better than glibc one
2020-05-24 12:59:37 <Cogitri> Yup, the new musl malloc looks pretty nice
2020-05-24 14:12:46 <Hello71> mps: I have some local patches
2020-05-24 14:13:18 <Hello71> strange that this works. I got pkgconfig version error
2020-05-24 15:10:10 <mps> Hello71: patches about?
2020-05-24 16:11:52 <mps> could we 'split' vim to vim and gvim to separate packages and move gvim to community?
2020-05-24 16:12:30 <ikke> Means we would have two vim packages to maint, correct?
2020-05-24 16:12:49 <mps> yes
2020-05-24 16:13:24 <mps> but gvim depends on gtk, so we can continue in moving gtk to community
2020-05-24 16:13:40 <mps> some works already started in that path
2020-05-24 16:14:37 <mps> 'price' for hierarchical repos
2020-05-24 16:14:42 <ikke> yes
2020-05-24 16:16:19 <mps> actually, my question is RFC
2020-05-24 16:16:38 <Cogitri> I don't think moving gtk+3.0 out of main will work
2020-05-24 16:16:44 <Cogitri> Since py3-gobject3 needs it
2020-05-24 16:16:44 <ikke> how so?
2020-05-24 16:16:50 <Cogitri> Which is in turn required by libsecret
2020-05-24 16:17:12 <Cogitri> So we'd have to move pinentry and gnupg to community too
2020-05-24 16:17:38 <mps> is that related to gtk or glib
2020-05-24 16:17:38 <Cogitri> dconf will probably be annoying to move too
2020-05-24 16:17:58 <Cogitri> That's all gtk+3.0
2020-05-24 16:18:17 <Cogitri> We won't ever be able to move glib I think (and it belongs to main/)
2020-05-24 16:18:23 <mps> and gnupg depends on gtk? (:
2020-05-24 16:18:46 <Cogitri> gnupg -> pinentry -> libsecret -> py3-gobject3 -> gtk+3.0
2020-05-24 16:19:09 <maxice8> horrifying
2020-05-24 16:19:14 <mps> uhmm
2020-05-24 16:20:05 <mps> but could pinentry be split to have two, one which is TUI and second GUI
2020-05-24 16:20:56 <Cogitri> Sure, we could turn it into two separate packages, but then we'd have to make sure again that people are installing the right thing automatically
2020-05-24 16:21:16 <Cogitri> I personally don't see the harm of keeping gtk+3.0 in main, at least until gtk4 is officially out
2020-05-24 16:21:18 <mps> oh, no
2020-05-24 16:21:21 <Cogitri> And gtk4 is in community already
2020-05-24 16:21:39 <ikke> won't things in main start to depend on gtk4 at some point?
2020-05-24 16:21:40 <mps> why do we have to care about automatic installation
2020-05-24 16:22:44 <Cogitri> mps: Because how would users know that there's that one magic package they have to install for their things to work?
2020-05-24 16:23:27 <Cogitri> ikke: Possibly, but it's easier to react with one package depending on gtk4 and moving it to community than moving all the things now
2020-05-24 16:23:38 <Cogitri> And I suspect it'll take applications some time to port
2020-05-24 16:24:47 <mps> users should read the docs about packages and see what they need to install
2020-05-24 16:25:16 <mps> except if we want to move alpine in desktop oriented distro
2020-05-24 16:25:45 <ikke> Cogitri: certainly
2020-05-24 16:26:01 <Cogitri> I don't want to sound negative, but if I'm looking at the state of the wiki I doubt that'll work out, mps :)
2020-05-24 16:26:11 <Cogitri> And it's easy to miss those remarks in the docs
2020-05-24 16:26:24 <ikke> Yes, we would need to have a well-maintained wiki for that (like how Archlinux has that)
2020-05-24 16:26:49 <mps> Cogitri: nothing personal, just trying to provoke corner cases
2020-05-24 16:27:51 <Cogitri> I working by the principle of least possible surprises is pretty neat, because surely such unexpected things will blow up for someone
2020-05-24 16:28:01 <Cogitri> I like*
2020-05-24 16:28:07 <mps> yes, right
2020-05-24 16:28:11 <Cogitri> Wow that sentence didn't work out at all :D
2020-05-24 16:28:29 <Cogitri> Anyway, I hope it's understandable anyway :)
2020-05-24 16:28:36 <ikke> We get the gist of it
2020-05-24 16:29:04 <mps> on one hand I would like to have 'simple user experience' and on the other 'minimum deps', and those two is hard to accomplish
2020-05-24 16:29:32 <Cogitri> Yup
2020-05-24 16:30:02 <ikke> probably more install_if direcitves might help
2020-05-24 16:30:03 <mps> 'hard to accomplish at same time' I mean
2020-05-24 16:31:29 <mps> pinentry have this '--disable-pinentry-gtk' in ./configure
2020-05-24 16:32:46 <mps> and 'apk info -R libsecret' doesn't show gtk
2020-05-24 16:33:38 <Cogitri> Ah, gtk3.0 is only checkdepends
2020-05-24 16:33:44 <Cogitri> of py3-gobject3
2020-05-24 16:34:01 <Cogitri> Yes, it only needs gtk via py3-gobject3
2020-05-24 16:34:09 <Cogitri> And the tests of py3-gobject3 are currently disabled
2020-05-24 16:34:17 <mps> and I have gnupg, libsecret and pinentry installed but not gtk
2020-05-24 16:34:25 <mps> on one server
2020-05-24 16:34:30 <ikke> apparently only checkdepends
2020-05-24 16:34:42 <mps> ikke: yes
2020-05-24 16:35:07 <mps> checkdepends="py3-dbus py3-gobject3 xvfb-run dbus-x11
2020-05-24 16:35:14 <mps> libsecret pkg
2020-05-24 16:35:57 <Cogitri> Yup, didn't look carefully enough at grep output :)
2020-05-24 16:36:12 <mps> np :)
2020-05-24 16:38:12 <mps> heh, going to install 'dependency hell' distro to test it for some things, devuan
2020-05-24 18:01:16 <Hello71> strange, I get ">>> ERROR: jemalloc-dev*: usr/lib/pkgconfig/jemalloc.pc: pkgconf version 5.2.1_0 is invalid"
2020-05-24 18:01:23 <Hello71> did abuild change recently
2020-05-24 18:15:36 <ikke> maybe a year ago?
2020-05-24 18:18:50 <Hello71> ... odd, theirs gives 5.2.1_
2020-05-24 18:21:16 <Hello71> which is apparently a valid version
2020-05-24 18:22:45 <Hello71> ah, it's because they download the git archive instead of the release archive
2020-05-24 18:24:34 <Hello71> very odd apkbuild this is
2020-05-24 18:24:40 <Hello71> why cd $pkgdir
2020-05-24 20:03:55 <ikke> Cogitri: maxice8 https://gitlab.alpinelinux.org/kdaudt/gotail
2020-05-24 20:04:20 <ikke> This is a very early version, without any special features
2020-05-24 20:04:49 <Cogitri> Oh neat!
2020-05-24 20:09:20 <Cogitri> Oh, disregard the request for review or whatever I just clicked on that repo
2020-05-24 20:09:27 <Cogitri> I wanted to see what that button does ^^
2020-05-24 20:09:48 <ikke> request to join
2020-05-24 20:09:55 <Cogitri> Ah, right
2020-05-24 20:10:05 <Cogitri> Somehow I had expected it'd show me a dialogue with more info if I click the link
2020-05-24 20:10:23 <Cogitri> Was that link always there? I don't think I've seen it on other repos yet
2020-05-24 20:11:08 <ikke> probably only for internal projects you do not have access to
2020-05-24 20:12:49 <Cogitri> Ah, makes sense in a company setting
2020-05-24 22:16:43 <mps> interesting, https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=readfile&id=ba5cf68691014003a8647400003c8ec51f24dd00
2020-05-24 22:17:36 <mps> implement readfile syscall, one syscall to open, read and close file
2020-05-24 22:17:54 <mps> after so much years :)
2020-05-24 22:47:38 <c705> mps: which version? the mainline?
2020-05-24 22:48:00 <mps> c705: not yet, probably 5.7
2020-05-24 22:48:41 <mps> or 5.8 if not 5.7
2020-05-24 22:50:09 <c705> neat-o
2020-05-25 00:13:39 <jms> i'm trying to build ffmpeg from the APKBUILD in aports, but with jack enabled. i think i'm in over my head. I'm reading the wiki page on creating an alpine package, and im lost when it comes to actually building the package. anyone want to try to point me in the right direction?
2020-05-25 01:59:38 <timlegge> I I noticed that perl-clone is out of date.  I would propose moving it at to community from main as it has only one other package in main that depends on it and that package has no dependencies in main  https://pastebin.com/RyPH6223.  perl-clone now has a new dependency and will need B::COW packaged
2020-05-25 02:00:19 <timlegge> I don't mind doing it, didnt figure adding another packange in main made sense for 2 packages
2020-05-25 05:14:56 <rahmanshaber[m]> ready to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8353
2020-05-25 05:22:33 <ikke> merged
2020-05-25 05:29:46 <rahmanshaber[m]> thanks
2020-05-25 07:23:25 <fcolista2> @ikke, @clandmeter I've a MR that fails (that's the first time for me using gitlab with forked repo): the CI complains by sauing: "fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address
2020-05-25 07:24:15 <clandmeter> Link to log
2020-05-25 07:24:17 <clandmeter> Aub
2020-05-25 07:24:59 <fcolista2> gitlab.alpinelinux.org/fcolista/aports/-jobs/126690
2020-05-25 07:25:11 <ikke> 404
2020-05-25 07:25:52 <fcolista2> maybe because is private?
2020-05-25 07:26:07 <ikke> I'm admin, so I have full access
2020-05-25 07:26:56 <ikke> You did a merge request against your fork, not against alpine/aports
2020-05-25 07:27:05 <fcolista2> https://gitlab.alpinelinux.org/fcolista/aports/pipelines/19946
2020-05-25 07:28:14 <fcolista2> what can I do now?
2020-05-25 07:28:24 <ikke> recreate the merge request against alpine/aports
2020-05-25 07:29:08 <fcolista2> so the $branchname indicated on the wiki about "Creating a merge request" is alpine/aports
2020-05-25 07:29:09 <ikke> https://imgur.com/a/jxFhswB
2020-05-25 07:29:44 <ikke> If you push a branch, the url that appears contains the correct information
2020-05-25 07:30:01 <fcolista2> I copy/pasted that
2020-05-25 07:30:03 <ikke> unless you want to make an MR against a stable branch
2020-05-25 07:30:56 <fcolista2> git push -u origin $branchname <- this branchname then is alpine/aports
2020-05-25 07:31:16 <ikke> no, that's the branch you want to push
2020-05-25 07:31:21 <ikke> in your case, kubernetes-split
2020-05-25 07:31:59 <fcolista2> ok. So this is what I've done
2020-05-25 07:32:15 <fcolista2> and then copy/pasted the output
2020-05-25 07:41:26 <ikke> For me I can just create a MR based on that URL and it does the right thing
2020-05-25 07:46:42 <fcolista2> i try again with a new branch
2020-05-25 07:59:10 <fcolista2> Ok, so I just run git push -u origin kubernetes
2020-05-25 07:59:17 <fcolista2> kubernetes is the name of the new branch
2020-05-25 08:00:02 <ikke> Ok, what is the url that you got?
2020-05-25 08:01:39 <fcolista2> now i have this link: to create a merge requesto for kubernetes, visit: https://gitlab.alpinelinux.org/fcolsita/aports/~/merge_request/new?merge?requests%5Bsource_branch%5D=kubernetes
2020-05-25 08:01:47 <fcolista2> *fcolista
2020-05-25 08:02:30 <fcolista2> Im on another pc so I'm not copy/paste :D
2020-05-25 08:03:23 <fcolista2> when I paste, if I go ahead the target branch is fcolista/aports master
2020-05-25 08:03:43 <fcolista2> i clicked on " Change branches" on the web if
2020-05-25 08:04:09 <fcolista2> and I need to change the Target branch to alpine/aports master
2020-05-25 08:04:50 <fcolista2> dunno if this is normal.
2020-05-25 08:07:57 <ikke> no, it's not
2020-05-25 09:20:27 <ikke> fcolista2: is it working now?
2020-05-25 09:21:12 <fcolista2> yes, but not as you mentioned. I had to change the target branch manually. Dunno why, since I've followed what is written in the wiki
2020-05-25 09:21:54 <fcolista2> Anyway, the build went fine
2020-05-25 09:22:12 <fcolista2> I'm going to merge it
2020-05-25 09:22:47 <kaey> i had the same problem, but it fixed by itself somehow
2020-05-25 09:27:14 <fcolista2> another question: since abuild complains that there are initd and I should add -openrc subpkg, if the initd already belong to a subpkg, what do you suggest to do?
2020-05-25 09:27:36 <fcolista2> Just create $subpkg-openrc for each?
2020-05-25 09:27:47 <fcolista2> I mean, I cannot create a subpkg of a subpkg, right?
2020-05-25 09:28:35 <ikke> You can
2020-05-25 09:28:54 <ikke> https://pkgs.alpinelinux.org/package/edge/community/x86_64/zabbix-agent2-openrc
2020-05-25 09:28:55 <fcolista2> cool.
2020-05-25 09:30:48 <fcolista2> ah ok. I had to do with a specific function, ok...I meant if abuild would handle this automatically by adding $subpackage0openrc
2020-05-25 09:30:55 <fcolista2> *subpackage-openrc
2020-05-25 09:31:01 <fcolista2> as it does for $pkgname-openrc
2020-05-25 09:31:12 <ikke> ah, no, you have to do it manually then
2020-05-25 10:52:45 <fcolista2> Seems that after the first time you change the target branch, then it remains as default option
2020-05-25 10:53:15 <fcolista2> Now I did the same, but the target is correctly set to alpine master
2020-05-25 10:54:01 <ikke> hmm, ok, strange
2020-05-25 10:54:12 <ikke> but good to know at least
2020-05-25 11:48:23 <kaey> maybe making repo public affects this
2020-05-25 11:50:53 <ikke> I would not expect that
2020-05-25 11:58:24 <ikke> Ariadne: gocryptfs fails on mips64 because it does not support buildmode=pie. Is it a matter of disabling buildmode=pie (which the script does if cgo is disabled), or do we need to disable it for mips(64)??
2020-05-25 15:11:31 <nmeum> is community/kodi really our only remaining python2 package or am I missing something?
2020-05-25 15:12:11 <nmeum> because if my observation is correct it might be worthwhile to get kodi fixed as well before 3.12 is released to ship 3.12 without python2
2020-05-25 15:13:46 <nmeum> https://kodi.tv/article/attention-addon-developers-migration-python-3
2020-05-25 15:13:55 <maxice8> Needs new release of lodi
2020-05-25 15:14:03 <maxice8> Kodi 19
2020-05-25 15:14:29 <nmeum> https://kodi.tv/article/kodi-19-python-3-goes-live
2020-05-25 15:14:31 <nmeum> indeed
2020-05-25 15:15:16 <nmeum> really looks like an annoyingly complex APKBUILD though ':)
2020-05-25 15:20:44 <nmeum> there is also testing/getmail, testing/lizardfs and testing/flare-engine all of which I would remove if they don't support python3 by now tbh. not worth keeping python2 around just for some packages in testing/
2020-05-25 15:21:19 <maxice8> Fine by me
2020-05-25 15:21:24 <nmeum> but kodi seems to be the only main/community package
2020-05-25 15:21:56 <nmeum> create an issue to keep track of this
2020-05-25 15:22:07 <nmeum> will look into those testing packages
2020-05-25 15:26:56 <nmeum> getmail doesn't seem to support python3 at all, lizardfs has a python3-support-commit in their repo but hasn't tagged a release since, the flare-engine tarballd doesn't seem to contain any python files?
2020-05-25 15:27:37 <maxice8> I think Firefox also needs it for makedepends
2020-05-25 15:27:42 <nmeum> oh, right
2020-05-25 15:27:46 <nmeum> I didn't check makedepends
2020-05-25 15:29:03 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11577#note_91145
2020-05-25 15:33:17 <nmeum> maxice8: do you still recall your reasoning behind f13b1fd945b746cf7abdbd5ec81877674edb8b76? ctags test suite seems to pass find here with just python3
2020-05-25 15:33:25 <nmeum> s/find/fine/
2020-05-25 15:33:25 <alpine-meetbot> nmeum meant to say: maxice8: do you still recall your reasoning behind f13b1fd945b746cf7abdbd5ec81877674edb8b76? ctags test suite seems to pass fine here with just python3
2020-05-25 15:39:36 <maxice8> No
2020-05-25 15:40:20 <ikke> If only there was some please to record this kind of information ;)
2020-05-25 15:40:28 <ikke> s/please/place
2020-05-25 15:40:28 <alpine-meetbot> ikke meant to say: If only there was some place to record this kind of information ;)
2020-05-25 15:40:52 <Cogitri> I think patching ff shouldn't be too hard for py3
2020-05-25 15:42:04 <nmeum> https://wiki.mozilla.org/Firefox/Python_3_Migration
2020-05-25 15:42:15 <nmeum> maxice8: would you mind if I revert it then? :D
2020-05-25 15:42:42 <maxice8> I don't mind as long as python2 is purged
2020-05-25 15:42:48 <nmeum> haha
2020-05-25 15:47:06 <u0jQx9gPyrYg> why do you hate all those who have py2 legacy to work with?
2020-05-25 15:47:26 <Cogitri> They can maintain their own py2 package if they want to
2020-05-25 15:47:30 <u0jQx9gPyrYg> /hate/want to harm/
2020-05-25 15:47:42 <Cogitri> Because if we keep it in main we'll have to support it for 2 years
2020-05-25 15:47:46 <nmeum> I think we are incapable of maintaining python2 on our own for the next 2 years
2020-05-25 15:47:58 <Cogitri> Which is unrealistic considering that support will be dropped by upstream
2020-05-25 15:48:05 <u0jQx9gPyrYg> i reacted to the purging
2020-05-25 15:48:13 <u0jQx9gPyrYg> nothing else
2020-05-25 15:48:23 <Cogitri> You had more than enough time to either switch to python2 or persuade upstream to keep maintaining py2 for longer
2020-05-25 15:48:40 <Cogitri> So Alpine isn't the right actor to complain about removing py2 here
2020-05-25 15:49:20 <Hello71> https://bugzilla.mozilla.org/show_bug.cgi?id=1388447
2020-05-25 15:49:50 <u0jQx9gPyrYg> i repeat: i reacted to the purging of python2 - you seem to interprete more than i intended into this...
2020-05-25 15:50:08 <Hello71> 15:47 <u0jQx9gPyrYg> why do you hate all those who have py2 legacy to work with?
2020-05-25 15:50:51 <u0jQx9gPyrYg> i reacted to this: > I don't mind as long as python2 is purged
2020-05-25 15:51:05 <u0jQx9gPyrYg> sorry if that was not clear
2020-05-25 15:51:47 <PureTryOut[m]> Well they answered why then want it purged no?
2020-05-25 15:51:48 <PureTryOut[m]> *why they
2020-05-25 15:52:29 <nmeum> chromium and webkit also have a makdependency on python2 it seems
2020-05-25 15:52:46 <u0jQx9gPyrYg> the "if we keep it in main we'll have to support it for 2 years" does not imply purging. only moving it from main...
2020-05-25 15:54:22 <u0jQx9gPyrYg> which i would not object to.
2020-05-25 15:55:17 <u0jQx9gPyrYg> but chromium and webkit had > more than enough time to either switch to python2 or persuade upstream to keep maintaining py2 for longer  doesn't sound like a good argument if even those did not have the power to persuade upstream....
2020-05-25 15:55:44 <nmeum> removed python2 from ctags, looking into community/gringo now
2020-05-25 15:56:45 <u0jQx9gPyrYg> anyway, i just question this indirect hostility towards python2 users. its' not their choice, and they are victims.
2020-05-25 16:03:49 <maxice8> You're making a connection that doesn't exist
2020-05-25 16:04:41 <maxice8> Saying I want python2 purged is in no way saying I hate all those who have py2 legacy to work with
2020-05-25 16:05:06 <u0jQx9gPyrYg> that's why i > /hate/want to harm/
2020-05-25 16:05:47 <maxice8> I have no desire to harm them
2020-05-25 16:21:07 <nmeum> have a change which removes python2 from the community/gringo aport !8430
2020-05-25 16:22:03 <nmeum> the old gringo code from sourceforge seems to be obsolete
2020-05-25 16:22:56 <Hello71> >they are victims.
2020-05-25 16:23:03 <Hello71> 6/10 troll
2020-05-25 16:24:04 <nmeum> Cogitri: some telepathy packages seem to also use python2 in makedepends, do you happen to know if that's still strictly required?
2020-05-25 16:24:16 <nmeum> telepathy-idle, telepathy-logger and telepathy-mission-control
2020-05-25 16:30:45 <Cogitri> Unfortunately yes
2020-05-25 16:31:18 <Cogitri> Upstream became alive a bit ago though, so I hope that I can switch it over soon
2020-05-25 16:49:04 <nmeum> if we somehow get rid of the python2 dependency on mozjs60 and nodejs we should at least be able to move python2 from main/ to community/
2020-05-25 16:52:48 <PureTryOut[m]> Telepathy is (slowly) moving away from Python 3 actually
2020-05-25 16:58:12 <nmeum> what were they doing the last few years? :D
2020-05-25 17:06:12 <Cogitri> Being dead upstream
2020-05-25 17:07:13 <Cogitri> I think getting rid of py2 on mozjs will be pretty difficult
2020-05-25 17:07:27 <Cogitri> Would be nicer to have polkit depend on mozjs68
2020-05-25 17:08:21 <Cogitri> Also, did someone else's poweroff break? I have to REISU(B) to shutdown/restart my computer right now :c
2020-05-25 17:58:55 <hjaekel> @maxice8, do you think that all tasks from !7990 are resolved and it can be merged?
2020-05-25 18:13:54 <maxwell-k> nmeum: I'm going to have a go at some of the packages you mention in #11577
2020-05-25 18:14:20 <maxwell-k> just mention in case we end up working on the same thing
2020-05-25 18:14:41 <nmeum> please do
2020-05-25 18:14:46 <nmeum> I mostly did community/ stuff so for
2020-05-25 18:14:48 <nmeum> *far
2020-05-25 18:14:53 <nmeum> will try out if nodejs just builds with python3 now
2020-05-25 18:15:32 <maxwell-k> I just got started on that!
2020-05-25 18:15:58 <maxwell-k> well as far as an error in configure, happy to switch to another one or keep going on nodejs?
2020-05-25 18:16:00 <nmeum> ok, in that case I won't :p
2020-05-25 18:16:19 <nmeum> no, just keep doing nodejs I was reluctant to do nodejs stuff anyhow
2020-05-25 18:16:29 <maxwell-k> let me see how I get on :-)
2020-05-25 18:16:53 <maxwell-k> !8432 was the first two packages I tried
2020-05-25 18:17:21 <nmeum> btw: just FYI community/nodejs-current already uses python3
2020-05-25 18:17:37 <nmeum> yeah, already saw the py2-setuptools change
2020-05-25 18:18:52 <maxwell-k> great, thanks, will take a look at how community/nodejs-current does it
2020-05-25 18:28:14 <maxwell-k> have I picked this up right: the s390x CI runner isn't working great?
2020-05-25 18:58:11 <nmeum> maxwell-k: yes, has issues currently
2020-05-25 19:08:22 <maxwell-k> nmeum: ty, that's reassuring, apart from checking it builds on s390x that's nodejs python2 free :)
2020-05-25 19:08:44 <maxwell-k> I'm taking a look at polkit / mozjs60 next
2020-05-25 19:16:23 <Cogitri> 👍
2020-05-25 19:16:44 <Cogitri> Maybe take a look at how simple it is to get polkit to mozjs68
2020-05-25 19:16:59 <Cogitri> Would be best if we could just drop the unsupported mosjz60
2020-05-25 19:18:23 <maxwell-k> Cogitri: that's exactly what I'm looking at :) I got a bit side tracked...
2020-05-25 19:19:05 <maxwell-k> mozjs68 has both python2 and python3-dev in makedepends
2020-05-25 19:19:33 <maxwell-k> which struck me as strange, how does it strike you?
2020-05-25 19:20:20 <Cogitri> Its buildsystem isn't fully transitioned to py3 yet
2020-05-25 19:21:21 <Cogitri> nmeum sent a link in here explaining it a few hours ago but I can't seem to find that anymore
2020-05-25 19:21:48 <Cogitri> I *think* I saw some distro patching it to all on python3 and that patch wasn't too big, but I can't recall which distro that was
2020-05-25 19:22:05 <nmeum> https://wiki.mozilla.org/Firefox/Python_3_Migration
2020-05-25 19:22:21 <nmeum> they use both currently and seem to be still working on the transitions
2020-05-25 19:22:38 <maxwell-k> great, thanks, that is exactly what I was reading :)
2020-05-25 19:23:10 <maxwell-k> let me put that little detour aside and get back to seeing if polkit can use mozjs68
2020-05-25 19:23:27 <nmeum> Cogitri: but mozjs68 also uses python2 and is in community/
2020-05-25 19:24:33 <Cogitri> Yes, but even then, it'd be nice to drop mozjs60
2020-05-25 19:25:02 <Cogitri> And if we manage to transition firefox-esr to py3 we get mozjs68 on py3 for free, while we'd have to rework patches for mozjs60
2020-05-25 19:27:48 <nmeum> sounds good
2020-05-25 19:33:03 <maxwell-k> I had a quick look at mozjs68 on Fedora, Arch, Debian and Gentoo; all seemed to still use Python 2 at build time
2020-05-25 19:33:31 <maxwell-k> I guess its a multi-step process, I like this first step - move python2 to community
2020-05-25 19:34:17 <Cogitri> Yup, at least 18 months of support less for it
2020-05-25 19:34:24 <Cogitri> And a sign that people should really stop using py2
2020-05-25 19:42:07 <maxwell-k> Cogitri: hang on I forgot, maybe its what nmeum was saying, I'm too tired
2020-05-25 19:42:07 <maxwell-k> one route would be to move polkit to community/ but that sounds huge
2020-05-25 19:42:07 <maxwell-k> mozjs68 and mozjs60 both need python2, polkit is in main, we want python2 out of main so it doesn't matter if polkit uses mozjs68 or mozjs60, we're no better off
2020-05-25 19:42:12 <maxwell-k> or if you can remember which distro you saw with the python3 patch?
2020-05-25 19:44:30 <Cogitri> Not really, but apparently I was wrong when Fedora and Arch still use py2
2020-05-25 19:44:38 <Cogitri> I can't really think of what other distro would patch to py3
2020-05-25 19:44:57 <Cogitri> Moving polkit to community probably wont fly
2020-05-25 19:48:00 <maxwell-k> I didn't think so, guess we need a more creative solution
2020-05-25 19:56:06 <dalias> heh can we move polkit to /dev/null ? :)
2020-05-25 20:00:35 <Cogitri> Polkit is comfy
2020-05-25 20:00:59 <Cogitri> Although I'm inclined to say that maybe JS wasn't the best choice ever for the rules
2020-05-25 20:05:47 <dalias> having a turing-complete rules system almost nobody understands for bypassing unix permissions (for no good reason to begin with) wasn't the best choice, regardless of particular language choice
2020-05-25 20:07:12 <Cogitri> There are good reasons for that, e.g. to elevate the permissions of GUI programs
2020-05-25 20:07:34 <Cogitri> Where you need some kind of UAC
2020-05-25 20:08:13 <dalias> gui programs should not be elevating permissions
2020-05-25 20:08:44 <Cogitri> Well, if you like installing packages via the CLI on a phone or partition it via fdisk, then I agree with you
2020-05-25 20:09:13 <Cogitri> But a GUI sure is comfier on smaller screens and I'd argue most users prefer a GUI overall
2020-05-25 20:09:25 <dalias> that doesn't require the gui program having any permissions
2020-05-25 20:09:42 <dalias> as a really dumb example, see cups
2020-05-25 20:09:55 <Cogitri> You need some kind of root daemon though and somehow authenticate against that
2020-05-25 20:10:08 <dalias> yes. and then you only run the ones you want to have
2020-05-25 20:10:21 <dalias> rather than polkit making all sorts of unexpected stuff available to applications
2020-05-25 20:10:45 <dalias> with arcane and opaque rules that nobody understands and knows how to turn off
2020-05-25 20:10:49 <Cogitri> Well, usually that'd be DBus starting the service for you and not Polkit doing something
2020-05-25 20:11:03 <dalias> right, dbus activation is a huge part of the same problem
2020-05-25 20:11:08 <dalias> it's all the same fdo hell-ecosystem
2020-05-25 20:11:15 <Cogitri> And at least from an application perspective Polkit is very nice to use
2020-05-25 20:11:44 <dalias> for the most part applications shouldn't be doing anything they need polkit to do
2020-05-25 20:11:49 <dalias> only system components should
2020-05-25 20:11:55 <Cogitri> I had to make one API call to check if a user is authenticated and write a few lines of rule code (which I wouldn't have had to do if I hadn't wanted users in a certain group to always be authenticated)
2020-05-25 20:12:14 <Cogitri> Things like package manager frontends, GParted and friends need it though
2020-05-25 20:12:19 <Cogitri> And it's a nice fit for that IMO
2020-05-25 20:12:46 <Cogitri> And yes, DBus activation can be viewed as hostile since it doesn't manage things, but it sure is plenty useful
2020-05-25 20:12:49 <dalias> partition editing on system media is not something an application should be doing. it shouldn't be happening at all after install except from a rescue environment
2020-05-25 20:12:58 <dalias> on removable media, the user should be given ownership of the device node
2020-05-25 20:13:04 <dalias> and then parted needs no root
2020-05-25 20:13:23 <dalias> just a udev rule to chown node to proper user
2020-05-25 20:13:54 <dalias> i've never once had a dbus activation that i actually wanted to have happen, happen
2020-05-25 20:14:04 <dalias> it's always been activating crap i didn't even intend to have installed
2020-05-25 20:14:14 <dalias> and gobbling up hundreds of MB of memory doing so
2020-05-25 20:14:21 <dalias> in addition to making root backdoors
2020-05-25 20:14:47 <Cogitri> I don't want to be rude, but for the other >=90% of desktop users it's granted functionality they expect to be available
2020-05-25 20:14:48 <dalias> thankfully i found a path to purge all the packages that want that stuff and still have a functional system...
2020-05-25 20:15:02 <dalias> which functionality?
2020-05-25 20:15:10 <Cogitri> And I doubt those users are able to spin a udev rule for every usb device they plug in
2020-05-25 20:15:27 <Cogitri> Having services start automatically, partitioning their partitions
2020-05-25 20:15:38 <dalias> which is why distros should be providing nice general udev rules
2020-05-25 20:15:49 <dalias> partitioning their partitions?
2020-05-25 20:15:55 <dalias> partitioning is not a normal operation you do
2020-05-25 20:16:09 <Cogitri> I think I prefer my GParted asking for the admin password the one time I need it over my device being r/w for my user all the time
2020-05-25 20:16:41 <dalias> until gparted has a vuln in it reading malformed partion tables, and now the exploit code on the usb stick you plugged in is running as root...
2020-05-25 20:27:33 <mps> we want windows experience :D
2020-05-25 20:29:07 <mps> do we have anything which simulate BSOD to install by default
2020-05-25 20:29:12 <mps> (sorry)
2020-05-25 20:31:00 <mps> and there were old quote somewhere on the net "make system which even idiot can use and then only idiot will use it"
2020-05-25 20:31:10 <mps> really sorry again
2020-05-25 20:34:00 <dalias> mps, lol
2020-05-25 20:35:33 <TBB> or "when you create something that's foolproof, somewhere a new improved fool is born"
2020-05-25 20:35:53 <mps> :)
2020-05-25 20:36:13 <mps> yes, I remember also this one
2020-05-25 20:36:55 <dalias> i don't even get it
2020-05-25 20:37:38 <dalias> it's designing a workflow for a task that a non-technical user isn't even going to know is a thing you can do (partitioning) to make it easy for them to do it without having to know how to chown or login as root on a terminal (why?)
2020-05-25 20:38:12 <mps> but from 'theory of systems' less part in any system make it more stable and secure
2020-05-25 20:39:13 <mps> less code is more stable and more secure
2020-05-25 20:45:17 <Hello71> https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35/ is still open
2020-05-25 20:45:28 <Hello71> duktape packaging is terrible but at least it's smaller than mozjs
2020-05-25 20:46:13 <Hello71> dalias: kernel already reads lots of kinds of partition tables, you're already SOL on that front
2020-05-25 20:46:34 <Hello71> qubes people complained about not being able to suppress this behavior in stock kernel
2020-05-25 20:46:35 <dalias> yes but not with the same code. yes it's bad that the kernel does
2020-05-25 20:46:43 <Hello71> not sure if it was fixed yet
2020-05-25 20:47:04 <dalias> i guess you can fix it by removing support for all the types of partition tables :)
2020-05-25 20:47:13 <dalias> dos, efi, etc.
2020-05-25 20:47:33 <dalias> then instead have a userspace daemon do it and expose them as loop devices
2020-05-25 20:47:45 <dalias> :-)
2020-05-25 20:47:48 <Hello71> loop is very slow, you need dm-linear for performance
2020-05-25 20:47:54 <Hello71> fortunately there is already kpartx utility for this task
2020-05-25 20:48:18 <dalias> ah yeah loop is block-on-char not block-on-block
2020-05-25 20:48:19 <Hello71> it makes /dev/mapper entries, so you can kpartx /dev/sda; mount /dev/mapper/sda1
2020-05-25 20:48:59 <Hello71> and presumably you could ln -s mapper/sda1 /dev/sda1
2020-05-25 21:05:25 <nmeum> meh, this python2 → mozjs60 → polkitd dependency really is annoying
2020-05-26 06:02:17 <jms> I'm trying to build ffmpeg from aports, and after following the wiki page on creating a package (adding user, setting up keys) running abuild checksum passes, but abuild -r is returning "ERROR: unsatisfiable constraints" missing a handful of packages (v4l-utils-dev, x264-dev, xvidcore-dev, dav1d-dev, aom-dev) I dont see these packages in aports, and 'apk add' doesn't return anything. am i missing something obvious?
2020-05-26 06:14:30 <Cogitri> Maybe you forgot to enable the community repo in /etc/apk/repositories
2020-05-26 06:18:48 <jms> thank you! that fixed most of them. dav1d-dev and aom-dev are still missing. i'll keep poking around unles you have any more helpful tips.
2020-05-26 06:20:56 <Cogitri> Are you on <=3.11?
2020-05-26 06:21:07 <jms> yes, 3.11
2020-05-26 06:21:15 <Cogitri> dav1d and aom are only available on edge right now
2020-05-26 06:21:25 <Cogitri> You can checkout the 3.11-stable branch and build ffmpeg from there, that should work
2020-05-26 06:21:37 <jms> got it. thank you very much!
2020-05-26 06:22:48 <Cogitri> 👍️
2020-05-26 08:57:12 <ncopa> morning
2020-05-26 08:57:17 <ncopa> did anyone test the rc1?
2020-05-26 08:57:21 <maxice8> morning
2020-05-26 08:57:21 <ncopa> can we do rc2 today?
2020-05-26 08:58:05 <artok> 
ACTION is waiting for bob the builder answer

2020-05-26 08:59:58 <Cogitri> Morning
2020-05-26 09:06:35 <Cogitri> Well, I've been running updated edge on all of my systems, so I guess that might count as testing the rc
2020-05-26 09:27:58 <mps> I run edge aarch64 which I use mostly, and armv7 which I don't use daily but few times on week
2020-05-26 09:30:05 <ikke> I'll try to run the x86_64 iso in qemu
2020-05-26 09:31:30 <artok> edge on this laptop, working nicely
2020-05-26 10:35:03 <mps> what about building mutt with kyotocabinet (or tokypcabinet) instead of bdb?
2020-05-26 10:36:47 <mps> we will have one pkg less which depends on outdated bdb
2020-05-26 10:38:04 <mps> fine, no objections :)
2020-05-26 10:43:32 <ikke> hmm, is 2GB not enough for a base installation?
2020-05-26 10:43:38 <ikke> 2GB disk I mean
2020-05-26 10:44:40 <mps> hmm, my mail, web, dsl router is less than 1GB
2020-05-26 10:45:14 <ikke> I have a 2GB disk image, but I got a no space left ont device error during setup disk
2020-05-26 10:49:54 <mps> my rootfs on aarch64 is 3GB with complete apline-sdk, Xorg and some useful programs
2020-05-26 10:50:11 <ikke> think the issue was not enough ram for tmpfs
2020-05-26 11:03:30 <mps> hmm, I was wrong, mutt already doesn't depend on bdb
2020-05-26 11:14:38 <ikke> I think someone brought it up before here, but any reason why nomodeset is enabled by default?
2020-05-26 11:17:18 <Cogitri> Definitely shouldn't be enabled for anything but safe graphics mode
2020-05-26 11:19:07 <ikke> I keep running into that when trying to run a desktop on qemu
2020-05-26 11:20:35 <Cogitri> Time to remove it
2020-05-26 11:24:06 <ikke> .0
2020-05-26 11:25:09 <ncopa> so, what i need test with is test boot the release isos
2020-05-26 11:25:21 <ncopa> see if they boot and if the isntaller works
2020-05-26 11:25:41 <ncopa> so we dont ship releases that does not boot or does not install
2020-05-26 11:27:12 <ikke> I tested the most obvious one
2020-05-26 11:27:27 <ikke> standard x86_64 on qemu
2020-05-26 11:27:55 <ncopa> what is blocking testing/py3-padatious?
2020-05-26 11:28:02 <ncopa> it is getting in the way
2020-05-26 11:28:10 <ncopa> i think i'll just disable it for now
2020-05-26 11:28:48 <ikke> seems it's hanging?
2020-05-26 11:28:56 <ncopa> tests are hanging yes
2020-05-26 11:29:07 <ncopa> i had a quick look at it and it has some tests that does timeout on 3 mins
2020-05-26 11:29:09 <ncopa> or similar
2020-05-26 11:29:24 <ncopa> but apparently it fails on most arches
2020-05-26 11:57:23 <Cogitri> ncopa: Sorry to ping you when you're busy with RCs, but have you looked at the clang MR already?
2020-05-26 11:57:51 <ncopa> oh
2020-05-26 11:57:55 <ncopa> that too
2020-05-26 11:59:21 <Cogitri> The patch is pretty small though :)
2020-05-26 11:59:32 <Cogitri> I should ask upstream how we can get that upstream soon
2020-05-26 12:22:20 <Cogitri> ikke: !8125
2020-05-26 12:22:29 <ikke> hmm, right
2020-05-26 12:22:45 <ikke> last upgrade we had issues with different runner-helper versions and runners when the docker images were rebuilt
2020-05-26 13:05:57 <ncopa> i have fixed the golang buildmode=pie on build-3-12-mips64
2020-05-26 13:06:29 <ikke> ncopa: oh, nice
2020-05-26 13:07:53 <Ariadne> nice
2020-05-26 13:08:33 <Ariadne> how did you fix it
2020-05-26 13:17:10 <ncopa> we nowdays set the GOFLAGS="buildmode=pie " in /etc/abuild.conf on our builders
2020-05-26 13:17:15 <ncopa> i removed it on mips64
2020-05-26 13:18:17 <ikke> But for gocryptfs, I saw that it set it in the build.bash script (as long as cgo was enabled)
2020-05-26 16:18:37 <nmeum> ncopa: does that also fix the deadlock with go 1.14 on mips64?
2020-05-26 16:36:13 <Ariadne> no
2020-05-26 16:39:14 <Cogitri> ikke: Not sure what CI tries to tell me with that: https://gitlab.alpinelinux.org/uuser/aports/-/jobs/127501#L3635
2020-05-26 16:46:53 <ikke> I get what it tried to tell, but not why
2020-05-26 16:57:44 <oneinsect> folks one small clarity regarding apk, the apk database shows already installed and when i try to add a new repo and try installing, it says (1/1) [APK unavailable, skipped] Reinstalling perl
2020-05-26 16:58:44 <oneinsect> how do i make apk reinstall a package even if its from a different repo or a local repo for that matter
2020-05-26 16:58:48 <oneinsect> it doesnt do that
2020-05-26 16:59:06 <oneinsect> and i cant delete since apk complains about dependencies
2020-05-26 17:49:15 <oneinsect> abuild-tar: unrecognized option '--hbash'
2020-05-26 17:49:25 <oneinsect> is this warning right?
2020-05-26 17:49:39 <oneinsect> abuild outputs it while building a packing
2020-05-26 17:50:40 <oneinsect> package*
2020-05-26 19:05:40 <Ariadne> oneinsect: sounds like a bug in your setup
2020-05-26 19:20:12 <oneinsect> hmmm
2020-05-26 19:20:21 <oneinsect> i was trying abuild in debian and fedora
2020-05-26 19:21:40 <Hello71> looks like upgrading from 3.11 to edge breaks ssh until sshd is restarted. will this affect 3.12?
2020-05-26 19:21:48 <oneinsect> i dont get same in alpine
2020-05-26 19:21:55 <Hello71> if so then probably should remember to mention in release notes
2020-05-26 19:24:04 <mps> Hello71: yes, this was because of change in newer version of ssh
2020-05-26 19:24:27 <Hello71> I know. arch and gentoo released belated news items
2020-05-26 19:24:32 <Hello71> but alpine appears to have no such news item posted
2020-05-26 19:24:49 <ikke> true
2020-05-26 19:24:55 <mps> I think maxice8 keep wiki about changes
2020-05-26 19:25:08 <Hello71> ah, I remember. https://www.archlinux.org/news/sshd-needs-restarting-after-upgrading-to-openssh-82p1/: If you are upgrading to openssh-8.2p1-3 or higher, this restart will happen automatically.
2020-05-26 19:25:14 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0
2020-05-26 19:25:33 <Hello71> but I had this issue upgrading from 3.11 to edge just a few days ago
2020-05-26 19:26:03 <Hello71> maybe it would be good to add such a hook, in case people do not read release notes?
2020-05-26 19:27:07 <mps> yes, also I had this when upgrade, but I knew in advance because I read openssh announce about this
2020-05-26 19:29:00 <Cogitri> This should definitely be handled so we don't break SSH login for most people, I guess restarting the service should do the trick
2020-05-26 19:29:32 <mps> if the sshd already run
2020-05-26 19:30:02 <Hello71> I skimmed the openssh 8.2 release notes and didn't find any relevant notes
2020-05-26 19:30:22 <Hello71> and besides the whole point of a linux distro is that you don't have to meticulously follow each upstream
2020-05-26 19:30:44 <mps> hmm, there were something about 'retired' option, iirc
2020-05-26 19:33:02 <Hello71> at https://bugs.archlinux.org/task/65517 some people said it was mentioned in release notes, but I think it was concluded that those were unrelated
2020-05-26 19:34:03 <clandmeter> heh
2020-05-26 19:34:11 <clandmeter> i read that as bugs.alpinelinux.org
2020-05-26 19:35:10 <mps> can't remember now exactly what is changed and don't have reference 'at hand' but I remember there were 'something'
2020-05-26 19:36:22 <oneinsect> strange when i do git clone https://gitlab.alpinelinux.org/alpine/abuild.git and look at abuild.in file
2020-05-26 19:36:24 <oneinsect> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in
2020-05-26 19:36:49 <oneinsect> line 1639 abuild-tar --hash is becoming abuild-tar --bash
2020-05-26 19:37:04 <oneinsect> abuild-tar --bhash
2020-05-26 19:37:33 <oneinsect> sorry rather it is becoming abuild-tar --hbash
2020-05-26 19:37:42 <oneinsect> why is a b getting added automatically
2020-05-26 19:37:46 <oneinsect> phew!!!
2020-05-26 19:39:30 <Hello71> clandmeter: alpine has no bugs
2020-05-26 19:40:59 <[[sroracle]]> only issues now :p
2020-05-26 19:42:15 <mps> yes, no bug anymore :)
2020-05-26 23:00:05 <AinNero> mh, maybe firefox on edge could need some closer look
2020-05-26 23:00:25 <AinNero> i get into situations quite often where most parts of the firefox stops rendering
2020-05-26 23:00:41 <AinNero> without high cpu load
2020-05-26 23:02:17 <AinNero> dont know whether its specific to my setup or not
2020-05-26 23:02:39 <AinNero> and too tired to debug anything useful
2020-05-27 01:38:33 <Eighth_Doctor> 👋
2020-05-27 05:33:09 <Cogitri> AinNero: wfm
2020-05-27 05:33:24 <Cogitri> I didn't have a single hiccup with Firefox in the last months
2020-05-27 06:29:30 <ncopa> whats up with h2o?
2020-05-27 06:29:43 <ncopa> morning
2020-05-27 06:30:05 <ncopa> can we wait with pushing broken stuff til after 3.12 release, please?
2020-05-27 06:31:15 <dalias> :)
2020-05-27 06:31:20 <dalias> whats broken?
2020-05-27 06:32:57 <ncopa> h2o fails to buil everywhere
2020-05-27 06:33:04 <ncopa> https://build.alpinelinux.org/
2020-05-27 06:33:36 <ncopa> it is one of the tests that fails
2020-05-27 06:34:17 <Cogitri> Huh, worked on edge
2020-05-27 06:34:24 <Cogitri> It's a bit annoying how things work on edge and then explode on 3.12 right now
2020-05-27 06:34:26 <Cogitri> Sorry about that
2020-05-27 06:34:32 <ncopa> agree
2020-05-27 06:34:45 <ncopa> i guess its a flaky test
2020-05-27 06:35:05 <ncopa> which only passes if the stars are aligned properly or somthing....
2020-05-27 06:35:19 <dalias> ah i had no idea what h2o was
2020-05-27 06:35:55 <[[sroracle]]> if water is broken we're all doomed... :p
2020-05-27 06:36:06 <mps> :)
2020-05-27 06:38:56 <dalias> lol what it depends on node?!
2020-05-27 06:39:58 <mps> I need advice about vboot-utils. it build fine on builders but resulting binary doesn't work properly on aarch64 and armv7, works fine x86_64
2020-05-27 06:40:36 <mps> built native on aarch64 and armv7 it works fine
2020-05-27 06:40:56 <mps> something in lxc screws it
2020-05-27 06:42:01 <mps> so, disable build on aarch64 and armv7 is one option, or move to unmaintained is second so users can build it if they need it
2020-05-27 06:43:02 <mps> have it in current state is not option imo
2020-05-27 06:43:10 <mps> ideas?
2020-05-27 06:43:23 <dalias> sorry
2020-05-27 06:44:24 <Cogitri> ncopa: Could you disable the test on 3.12 for now? I don't have time to look at it right mow
2020-05-27 06:45:14 <mps> ok, I expect that users of vboot-utils know how to build alpine packages anyway, so adding comment in 'arch' line in APKBUILD maybe is the option
2020-05-27 06:50:28 <ncopa> mps: i dont think its related lxc, but may be related CFLAGS or other things in environment
2020-05-27 06:50:54 <ncopa> mps: also, what do you mean with "doesn't work properly"?
2020-05-27 06:51:45 <mps> yes, probably something about CFLAGS
2020-05-27 06:52:20 <mps> but don't have time to check on Makefiles and find what is the problem
2020-05-27 06:53:55 <mps> "doesn't work properly" means it don't work same as when built native, i.e. vbutil_kernel doesn't have proper options to sign kernel
2020-05-27 06:55:22 <mps> I don't have time now to investigate and fix it for 3.12 release
2020-05-27 08:08:48 <ikke> kubernetes is currently failing on armhf
2020-05-27 09:26:36 <ncopa> i gess we can disable it on armhf
2020-05-27 09:33:07 <markand> hello
2020-05-27 09:33:41 <markand> is it possible to add a git repository clone to source variable in an APKBUILD? I'm trying to package Ardour and their distributions files are broken
2020-05-27 09:34:18 <Cogitri> No, you could clone in prepare()
2020-05-27 09:34:28 <Cogitri> But you can't even download a tarball of the git snapshot?
2020-05-27 09:34:37 <Cogitri> It'd be best to just ask upstream to fix their stuff
2020-05-27 09:34:57 <markand> it's by design
2020-05-27 09:35:06 <_ikke_> broken by design? :)
2020-05-27 09:35:39 <markand> no, https://pastebin.com/95KeAwDQ
2020-05-27 09:35:39 <Cogitri> Huh, got your old nick again, ikke? :o
2020-05-27 09:36:01 <_ikke_> uhh, I guess because I reconnected
2020-05-27 09:36:22 <Cogitri> markand: Sounds to me like you can just create the mentioned file in the GitHub tarball?
2020-05-27 09:36:38 <Cogitri> Or tell upstream that they totally can make custom tarballs on GitHub, they could even automate that with CI
2020-05-27 10:47:51 <artok> oh that was ardour.. somehow sounded familiar
2020-05-27 11:06:25 <_ikke_> ncopa: maybe related to kubernetes on armhf: https://github.com/golang/go/issues/30949
2020-05-27 11:55:05 <ncopa> im tagging rc2 now
2020-05-27 11:58:28 <Cogitri> 👍
2020-05-27 12:00:29 <ncopa> Cogitri: sorry for being grumpy this morning
2020-05-27 12:09:17 <Cogitri> No worries, sorry for breaking the builders
2020-05-27 12:10:09 <Cogitri> Maybe I can persuade you to look at the clang MR to fix it on x86 though? :D
2020-05-27 12:20:41 <Ariadne> lets not
2020-05-27 12:22:54 <AinNero> Cogitri: re: firefox
2020-05-27 12:22:55 <AinNero> bummer
2020-05-27 12:23:19 <AinNero> if it works for others means that its not an alpine problem, which is good
2020-05-27 12:25:49 <mps> except I have to be grumpy again, having firefox which changes often in stable is bad idea (sorry Cogitri)
2020-05-27 12:27:28 <Cogitri> We'll need leaf packages for some things
2020-05-27 12:27:41 <Cogitri> The same thing applies for packages like webkit2gtk
2020-05-27 12:28:03 <Ariadne> anything like that should be updated in stable yes
2020-05-27 12:28:54 <mps> Cogitri: however, it is in your hand and I think you will care about it
2020-05-27 12:36:52 <ncopa> Cogitri: your clang patch seems to fail on x86_64
2020-05-27 12:37:11 <ncopa> is that what you wanted help with?
2020-05-27 12:41:17 <Cogitri> Ah, I think it only fails due to CI being overloaded
2020-05-27 12:41:56 <Cogitri> I just wanted someone else to have a look at the change before clang breaks even more on x86 (although it works on my x86 runner now, so AFAICS it should be good to go)
2020-05-27 12:54:34 <ncopa> it looks good indeed
2020-05-27 12:56:23 <Cogitri> I'm not really sure why our musl ld triplet doesn't match up with what we use at other places though
2020-05-27 12:56:39 <Cogitri> I guess that's a left over from the past?
2020-05-27 12:58:56 <Cogitri> Thanks for looking at it :)
2020-05-27 13:37:46 <Ariadne> Cogitri: because x86 was not always i686 (that's recent)
2020-05-27 13:39:01 <AinNero> i586 user here
2020-05-27 14:01:48 <Cogitri> Ariadne: Okie, so it's historical, got it. Thanks :)
2020-05-27 14:37:51 <markand> is there a way with abuild to avoid rebuilding? when for example only the package() function was wrong, I want to avoid taking 1h to rebuild a package :)
2020-05-27 14:38:27 <ncopa> yes
2020-05-27 14:39:14 <ncopa> there are some config option in /etc/abuild.conf that can set clean srcdir on error. make sure that is not set (so srcdir is not cleaned)
2020-05-27 14:39:45 <ncopa> then to only re-run the package() you run:  rm -r pkg && abuild rootpkg index
2020-05-27 14:39:55 <_ikke_> if a build failure happens, src remains in tact
2020-05-27 14:39:56 <markand> you mean ERROR_CLEANUP="bldroot deps" ?
2020-05-27 14:40:10 <markand> _ikke_, yes but abuild -r still re-run the build completely
2020-05-27 14:40:16 <_ikke_> yes,
2020-05-27 14:40:25 <_ikke_> you can run the specific functions
2020-05-27 14:40:34 <markand> ncopa, thanks I try
2020-05-27 14:40:35 <ncopa> markand: your config looks ok
2020-05-27 14:40:41 <_ikke_> abuild package for example
2020-05-27 14:40:51 <markand> okay perfect
2020-05-27 14:40:56 <_ikke_> or abuild rootpkg to get the splitfunction as well
2020-05-27 14:41:15 <ncopa> `abuild rootpkg` is waht you want. it will run package() in fakeroot, the split functions and create the final .apks
2020-05-27 14:41:29 <markand> yes exactly
2020-05-27 14:41:39 <ncopa> `abuild index` will update your local index
2020-05-27 14:41:44 <markand> will help saving some time and wear on my ssd ;p
2020-05-27 14:41:45 <ncopa> you need to do that as well
2020-05-27 14:41:46 <_ikke_> Note that package() needs to be written to only copy things, not move thing
2020-05-27 14:42:10 <ncopa> not if you do `rm -r pkg`
2020-05-27 14:42:26 <_ikke_> if you move things from srcdir to pkgdir
2020-05-27 14:42:31 <_ikke_> then you cannot run package again
2020-05-27 14:42:48 <markand> obviously
2020-05-27 14:42:49 <ncopa> true
2020-05-27 14:42:59 <_ikke_> There are packages that I needed to fix that in
2020-05-27 14:43:03 <markand> ardour 6 coming o/
2020-05-27 14:43:23 <ncopa> oh, wow...
2020-05-27 14:43:47 <ncopa> i dont think i have used ardour since pre-alpine
2020-05-27 14:44:28 <markand> I wanted to give a try to opensource mao, but I can tell that it's the area where Linux sucks ball terribly unfortunately
2020-05-27 14:44:55 <markand> alsa, pulse, jack, ...
2020-05-27 14:44:59 <ncopa> +1
2020-05-27 14:45:19 <ncopa> you probably want jack+alsa
2020-05-27 14:45:49 <ncopa> the problem pulse solves (or tries to solve) is save battery time
2020-05-27 14:45:49 <markand> yes, ardour can't use pulseaudio anyway
2020-05-27 14:46:18 <markand> but then ardour takes exclusive access to the sound card so any other non-jack application are just stuck and can't play audio anymore
2020-05-27 14:47:28 <mps> 'abuild deps unpack prepare build' is what I do for big packages when testing build
2020-05-27 14:47:45 <_ikke_> yeah me too
2020-05-27 14:48:07 <mps> if build pass, then 'abuild package' and if it is ok, 'abuild rootpkg index'
2020-05-27 14:49:12 <mps> in between some times 'rm -rf pkg' fix things and 'abuild package' again till I give up or success :)
2020-05-27 14:49:52 <mps> at the end 'abuild clean undeps'
2020-05-27 15:01:23 <mps> why we use libcap from http://www.friedhoff.org/posixfilecaps.html and not from https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/
2020-05-27 15:01:44 <mps> are they different 'sort of things'
2020-05-27 15:04:05 <_ikke_> are they or the are?
2020-05-27 15:04:51 <mps> what, my wording is bad? sorry if it is
2020-05-27 15:05:12 <_ikke_> Is it a question or a statement
2020-05-27 15:05:24 <mps> question, ofc
2020-05-27 15:05:54 <mps> to me it looks like we should use from https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/
2020-05-27 15:06:30 <mps> but not sure if there is a reason we don't, so before preparing MR for upgrade wanted to ask
2020-05-27 15:07:40 <mps> 'apk version libcap' => 2.27-r0
2020-05-27 15:08:22 <mps> https://git.kernel.org/pub/scm/libs/libcap/libcap.git/snapshot/libcap-2.34.tar.gz
2020-05-27 15:08:23 <ncopa> protip in case someone want help test boot/install alpine in vms: run setup-alpine -q && setup-disk
2020-05-27 15:08:31 <ncopa> asks less questions
2020-05-27 15:08:41 <_ikke_> ncopa: thanks
2020-05-27 15:09:30 <mps> ncopa: ^ you are libcap maintainer
2020-05-27 15:09:48 <mps> what is your opinion
2020-05-27 15:10:26 <mps> (except I think it is to late for 3.12 to upgrade libcap)
2020-05-27 15:11:28 <mps> also, what keeps you to upgrade qemu to 5.0
2020-05-27 15:11:36 <ncopa> i have tested rc2: -virt (lvmsys disk install), -extended (sys install), -standard with efi.
2020-05-27 15:11:51 <ncopa> oh, i guess we should upgraded qemu
2020-05-27 15:12:06 <ncopa> does libcap update break abi?
2020-05-27 15:12:14 <ncopa> if not, lets do it
2020-05-27 15:12:44 <mps> I'm not sure yet, didn't tested much, just working to change some things in APKBUILD
2020-05-27 15:13:28 <Hello71> markand: tmpfs
2020-05-27 15:13:40 <mps> hope will have something in few hours
2020-05-27 15:20:55 <ncopa> seems like efi install ins broken
2020-05-27 15:27:09 <ncopa> efi install works. just not with lvm root
2020-05-27 15:37:05 <ncopa> mps: can you help me test the arm image(s)?
2020-05-27 15:37:13 <ncopa> i can test rpi tomorrow i think
2020-05-27 15:37:14 <mps> yes
2020-05-27 15:37:21 <ncopa> hopefully we can do release tomorrow
2020-05-27 15:37:35 <mps> just post url when you have it ready
2020-05-27 15:37:58 <andypost[m]> ncopa: libcap has ABI changes (
2020-05-27 15:38:16 <mps> andypost[m]: yes, I see
2020-05-27 15:38:25 <mps> to late for 3.12
2020-05-27 15:38:26 <ncopa> mps: dl-cdn.alpinelinux.org/alpine/v3.12/releases/
2020-05-27 15:38:42 <mps> aha, ok, will test
2020-05-27 15:56:04 <mps> ncopa: this works fine on 'rpi zero w' http://dl-cdn.alpinelinux.org/alpine/v3.12/releases/armhf/alpine-rpi-3.12.0_rc2-armhf.tar.gz
2020-05-27 15:56:35 <mps> installed in run-from-ram-mode and tested basic things, all looks fine
2020-05-27 16:11:23 <mps> ncopa: alpine-uboot-3.12.0_rc2-armv7.tar.gz failed to boot with 'mkdir: can't create directory '/sysroot//proc': Read-only file system'
2020-05-27 16:12:18 <mps> not sure is it because tarball is not good or maybe my u-boot params is not good
2020-05-27 16:13:14 <mps> I have 'APPEND modules=sd-mod,usb-storage,ext4,f2fs,sunxi-mmc root=/dev/mmcblk0p2 rw rootwait console=${console}'
2020-05-27 16:13:35 <mps> maybe I don't need 'root=/dev/mmcblk0p2 rw rootwait'
2020-05-27 16:13:55 <mps> lets see
2020-05-27 16:15:46 <mps> yes, that is! removed 'root=/dev/mmcblk0p2 rw rootwait' from append line and it boots fine
2020-05-27 16:15:51 <mps> ncopa: ^
2020-05-27 16:16:24 <mps> all is ready for release except new openssh :)
2020-05-27 16:18:43 <dalias> ready? as of 12 hours ago weren't there like multiple new breakages in packages :-p
2020-05-27 16:19:14 <mps> dalias: I put ':)' at the end
2020-05-27 16:19:22 <dalias> :)
2020-05-27 16:19:28 <Cogitri> Well, one failing test in h2o and a known breakage in CLang that got fixed
2020-05-27 16:19:54 <mps> maxice8: I think sqlite have some last minute fixes in latest release
2020-05-27 16:20:02 <maxice8> 3.32.1 ?
2020-05-27 16:20:11 <mps> I think so
2020-05-27 16:21:25 <Cogitri> Security fix, yes
2020-05-27 16:22:29 <mps> https://www.sqlite.org/changes.html
2020-05-27 16:22:56 <mps> Fix two long-standing bugs that allow malicious SQL statements to crash the process that is running SQLite.
2020-05-27 16:23:09 <maxice8> there is an open issue on gitlab for that mps
2020-05-27 16:23:23 <mps> ah, didn't looked
2020-05-27 16:23:26 <mps> sorry
2020-05-27 20:07:56 <HRio> can we merge !8470 in before tagging v3.12?
2020-05-27 20:10:25 <ikke> sounds important :)
2020-05-27 20:13:35 <ikke> Hmm, starting firefox on a fresh system says that the profile could not be loaded or is missing
2020-05-27 20:13:39 <ikke> (3.12)
2020-05-27 20:29:19 <artok> å
2020-05-27 20:29:22 <artok> oops
2020-05-27 20:34:00 <ikke> disk was full
2020-05-27 20:34:04 <ikke> so it could not create a profile
2020-05-27 20:36:48 <Cogitri> Oh heh
2020-05-27 20:36:59 <Cogitri> I know that, things start becoming weird quickly when the disk gets full
2020-05-27 20:40:39 <ikke> Connected on my alpine VM now to irc :)
2020-05-27 20:41:15 <ikke> So, hello world from Alpine 3.12
2020-05-27 20:42:40 <Cogitri> Nice :)
2020-05-27 20:42:43 <Cogitri> > ERROR: hyperfine-1.10.0-r0: BAD signature
2020-05-27 20:42:43 <Cogitri> :c
2020-05-27 20:43:31 <ikke> was it downgraded?
2020-05-27 20:44:07 <Cogitri> Nop
2020-05-27 20:44:25 <Cogitri> Was upgraded in 12916081b0e1bce89a918239f91710c3228a1d3d
2020-05-27 20:44:38 <Cogitri> Uhhh
2020-05-27 20:44:45 <Cogitri> The rebasing messed with the commit :)
2020-05-27 20:45:05 <Cogitri> Let me fix that
2020-05-27 20:47:04 <ikke> the commit message said upgrade to 1.10.0, but no pkgver was changed
2020-05-27 20:47:16 <ikke> (the first one)
2020-05-27 20:47:32 <ikke> I guess it was already upgraded at that point?
2020-05-27 20:48:23 <Cogitri> Yes, the upgrade was done i nf4dd8cb1f2d386e22b0151f888c45e1010187c9d
2020-05-27 20:48:27 <Cogitri> in f4dd8cb1f2d386e22b0151f888c45e1010187c9d *
2020-05-27 20:48:37 <Cogitri> So when I rebased it that got removed from the other commit
2020-05-27 20:49:01 <Cogitri> Anyway, bumped pkgrel now, thanks for being my rubber ducky :)
2020-05-27 20:49:43 <ikke> np
2020-05-27 22:24:16 <c705> can we bump linux-lts to 5.4.43?
2020-05-27 22:31:54 <c705> i guess this was put out 30 mins ago..no rush!
2020-05-27 23:01:25 <c705> ikke: https://git.alpinelinux.org/ seems down
2020-05-28 04:43:44 <ikke> c705: let me check
2020-05-28 04:51:57 <ikke> c705: thanks for reporting, it's fixed now
2020-05-28 05:07:35 <c705> ikke: is there a better way i can make folks aware?
2020-05-28 05:09:56 <ikke> Not really (#alpine-infra is a bit more appropriate), but we already had it monitored, so we already got a notification about it
2020-05-28 05:10:57 <ikke> But we can still only look at it in CE(s)T timezone
2020-05-28 05:19:35 <c705> i understand
2020-05-28 08:19:32 <ncopa> doh
2020-05-28 08:19:43 <ncopa> i tested armv7 rpi boot yesterady
2020-05-28 08:19:51 <ncopa> armhf and armv7 on an rpi4
2020-05-28 08:20:00 <ncopa> didnt work. screen was black
2020-05-28 08:20:04 <ikke> :(
2020-05-28 08:20:10 <ncopa> i tried aarch64 today
2020-05-28 08:20:11 <ncopa> same
2020-05-28 08:20:50 <ncopa> so it turns out that i didnt plug the hdmi cable to the screen.... /o\
2020-05-28 08:20:58 <ikke> oof
2020-05-28 08:22:16 <ikke> I still have an rpi1b and 2, do you think it's worth testing on there?
2020-05-28 08:23:55 <ncopa> i think so yes
2020-05-28 08:23:59 <ncopa> at least the rpi2
2020-05-28 08:24:04 <ikke> ok
2020-05-28 08:24:12 <ncopa> i have an old rpi1 somewhere
2020-05-28 08:24:17 <mps> armhf worked on rpi zero with serial console
2020-05-28 08:24:25 <ncopa> great!
2020-05-28 08:24:42 <ncopa> rpi zero is armv6? the armv7 will not work?
2020-05-28 08:24:54 <mps> I don't have that micro hdmi cable to test hdmi
2020-05-28 08:25:36 <ncopa> i'd like to drop armhf support after 3.12 release
2020-05-28 08:25:46 <maxice8> +1
2020-05-28 08:25:56 <ikke> so rpi1 rp2 and rpi zero?
2020-05-28 08:26:10 <ncopa> rpi2 is armv7 iirc
2020-05-28 08:26:18 <mps> also, tested u-boot-armv7 on allwinner a20, it boots but no usb, and no ethernet drivers
2020-05-28 08:26:19 <ncopa> i think its only rpi1 that is armv6
2020-05-28 08:26:38 <ikke> ok, yes
2020-05-28 08:26:49 <ncopa> mps: do you know what drivers it needs to enable?
2020-05-28 08:26:50 <ikke> I thought it was 3 that switched to v7
2020-05-28 08:27:11 <ncopa> ikke: i dont remember, but its probably good to know before we drop armhf
2020-05-28 08:27:45 <mps> not sure, diff with testing/linux-edge/config-edge.armv7 could help
2020-05-28 08:27:59 <ikke> according to the archlinux arm wiki, it's a armv7 cortex a7 chip
2020-05-28 08:28:34 <mps> but I don't have time to do all this now, build and test does it work
2020-05-28 08:29:01 <mps> anyone who need armv7 kernel can install testing/linux-edge
2020-05-28 08:29:45 <ncopa> "The earlier V1.1 model of the Raspberry Pi 2 used a Broadcom BCM2836 SoC with a 900 MHz 32-bit, quad-core ARM Cortex-A7 processor, with 256 KiB shared L2 cache."
2020-05-28 08:29:51 <ncopa> yeah
2020-05-28 08:29:56 <ncopa> rpi2 is armv7
2020-05-28 08:30:00 <ikke> ok, good
2020-05-28 08:30:03 <Cogitri> ikke: 3 switched to aarch64, no?
2020-05-28 08:30:10 <ncopa> yes
2020-05-28 08:30:16 <ncopa> rpi3 is 64bit
2020-05-28 08:30:17 <ikke> Cortex A54
2020-05-28 08:30:20 <ikke> A53
2020-05-28 08:30:27 <ncopa> what about rpi zero?
2020-05-28 08:30:46 <Cogitri> +1 for dropping armhf from me :)
2020-05-28 08:30:52 <Cogitri> I think that's v7 or aarch64 too?
2020-05-28 08:31:52 <Cogitri> I can set up a x86_64 native install for testing with 3.12 later today if that still needs testing
2020-05-28 08:31:57 <ncopa> "The Raspberry Pi Zero and Zero W use the same Broadcom BCM2835 SoC as the first generation Raspberry Pi, although now running at 1 GHz CPU clock speed."
2020-05-28 08:32:16 <ncopa> the more testing the better
2020-05-28 08:32:29 <ncopa> if we drop support for armhf we drop support for rpi zero
2020-05-28 08:35:06 <ikke> Should we announce that on alpine-devel mailing list?
2020-05-28 08:35:47 <ncopa> yes
2020-05-28 08:36:07 <ncopa> i guess its not decided yet, but we need to ask the question on alpine-devel
2020-05-28 08:37:18 <mps> pmOS people will 'heat' ML
2020-05-28 08:37:40 <afontain_> lol
2020-05-28 08:39:26 <mps> ncopa: I'll try to fix linux-lts for some armv7 boards but for 3.12.1 or 3.12.2, simply don't have much free time these days
2020-05-28 08:39:45 <mps> ofc, if someone don't fix it in meantime
2020-05-28 09:30:19 <clandmeter> ncopa: its not that simple i think
2020-05-28 09:30:32 <clandmeter> even some rpi2 are aarch64
2020-05-28 09:30:36 <clandmeter> iirc
2020-05-28 09:30:46 <clandmeter> they switched soc after some time
2020-05-28 09:36:53 <mps> hmm, I think I know why linux-edge 5.6.14 doesn't boot on rpi zero, I built it in thumb mode :/
2020-05-28 09:37:15 <mps> and rpi zero doesn't have thumb
2020-05-28 09:37:29 <ikke> thumb?
2020-05-28 09:37:59 <mps> thumb2, sorry
2020-05-28 09:38:43 <ikke> Variable length instruction set apparently
2020-05-28 09:39:24 <mps> yes, 16bit instead of 32bit
2020-05-28 09:39:49 <ikke> "Thumb-2 extends the limited 16-bit instruction set of Thumb with additional 32-bit instructions to give the instruction set more breadth,"
2020-05-28 09:39:50 <mps> so you have two asm instructions in 32bit
2020-05-28 09:40:11 <mps> dense packed exe
2020-05-28 09:40:58 <mps> and somewhat faster, in one program memory fetch two instructions
2020-05-28 09:41:46 <mps> works nice in armv7 linux-edge kernel
2020-05-28 09:42:48 <mps> gcc have thumb2 as default on our armv7
2020-05-28 09:45:08 <mps> ncopa: what about last minute upgrade of openssh for 3.12 !8496
2020-05-28 09:53:51 <ncopa> mps: sounds good to me
2020-05-28 09:54:35 <Cogitri> Was that the one that needs a restart after upgrading?
2020-05-28 09:55:10 <ikke> that was 8.2_p1
2020-05-28 09:56:11 <Cogitri> Ah okie
2020-05-28 09:57:09 <mps> Cogitri: I tested it and didn't have to restart it
2020-05-28 09:57:41 <mps> but not sure if it will work everywhere
2020-05-28 09:58:15 <mps> at least some of us should test it after upgrade
2020-05-28 09:58:23 <Ariadne> saw some pretty impressive thumb-2 demos on risc-os last weekend
2020-05-28 09:59:01 <Ariadne> flying through a full 3D fractal in only 256 bytes of program text
2020-05-28 10:00:38 <Ariadne> regarding armhf, I am working out a proposal for a second tier of alpine ports.  armhf could become one of those.
2020-05-28 10:01:20 <mps> what means 'second tier'?
2020-05-28 10:01:37 <mps> not 'first class'?
2020-05-28 10:02:18 <Ariadne> as in not officially supported
2020-05-28 10:02:32 <mps> aha
2020-05-28 10:02:53 <Ariadne> the idea is to incubate new archs, like riscv64 or mips32 or mipsel/mips64el
2020-05-28 10:03:09 <Ariadne> but the infrastructure could be extended to deprecated archs too
2020-05-28 10:03:23 <Ariadne> look I just want to run alpine on my Amiga ok
2020-05-28 10:03:45 <Ariadne> also I have a microvax in my storage unit I want to set up eventually
2020-05-28 10:03:52 <mps> well, I thought about something called 'trimmed armhf', i.e. no GUI/X
2020-05-28 10:04:44 <Ariadne> well I have an idea on fixing rust bootstrap to make it bootstrapable from the APKBUILD
2020-05-28 10:06:18 <artok> I've got A500 hanging there, no AmigaOS anywhere to be found
2020-05-28 11:15:10 <andypost[m]> IIRC amiga 500(a) used only ROM and unsupported since early 90'
2020-05-28 12:11:48 <mps> ncopa: linux-lts 5.4.43 fixes bugs I mention few hours ago on armv7 allwinner a20
2020-05-28 12:12:18 <mps> ethernet is up, usb works, reboot and poweroff also
2020-05-28 12:12:46 <mps> fixed with a single config option added
2020-05-28 12:14:41 <ncopa> which config option change?
2020-05-28 12:15:17 <ncopa> mps: it means that the linux-lts kernel working with a single config change?
2020-05-28 12:15:20 <mps> usb_gadget
2020-05-28 12:15:49 <ncopa> then i dont think it was the config option that fixed it
2020-05-28 12:15:56 <mps> last change you did for config-lts.armv7
2020-05-28 12:16:10 <ncopa> that was due to an old request
2020-05-28 12:16:35 <ncopa> but it means that the linux-lts-5.4.43 works for you, right?
2020-05-28 12:16:36 <mps> these boards have etherent on usb shared
2020-05-28 12:17:36 <mps> yesterday I tested tarball prerelease, it booted but not usb nor ethernet
2020-05-28 12:18:22 <mps> now I just apk add -u linux-lts, rebooted and usb and ethernet works
2020-05-28 12:19:24 <mps> if you make new prerelease tarball (or release) I will test it again
2020-05-28 12:20:30 <ncopa> ok, let me push rc3
2020-05-28 12:23:27 <ncopa> rc3 pushed
2020-05-28 12:23:38 <mps> I see
2020-05-28 12:36:34 <mps> ncopa: inform me when you make new tarball, i.e. alpine-uboot-3.12.0_rc3-armv7.tar.g
2020-05-28 12:37:39 <ikke> Those should be generated automatically afaik
2020-05-28 12:39:03 <mps> aha, then have to monitor it 'by hand' :)
2020-05-28 12:40:13 <mps> heh, not much time to wait, it is there
2020-05-28 12:40:15 <mps> :)
2020-05-28 12:50:03 <mps> hm, no. this didn't fixed it. But we now know that the issue is not kernel but modules missing in u-boot-tarball initramfs (or modloop?)
2020-05-28 12:50:42 <mps> anyway, some progress
2020-05-28 13:32:37 <ncopa> modloop should have them all
2020-05-28 13:32:41 <ncopa> could be firmware?
2020-05-28 13:32:51 <ncopa> what happens if you install it to disk and reboot?
2020-05-28 13:34:30 <ncopa> did anyone test the alpine-xen image?
2020-05-28 13:47:24 <mps> ncopa: when install it on disk everything works fine
2020-05-28 13:47:42 <mps> and yes, modloop should have it all
2020-05-28 13:48:16 <mps> probably need to be added in kernel cli 'append modules=' list
2020-05-28 13:56:05 <ncopa> i wonder if it is a kernel module that is included in initramfs on the boot media, but lacks firmware
2020-05-28 14:00:45 <mps> firmware is not needed, afaik. but can look later
2020-05-28 14:02:04 <mps> after boot tarball (unpacked on mmc, ofc) there is no /lib/modules dir
2020-05-28 14:04:54 <mps> but, anyway I'm thinking to make 'ready-made' FS for such devices, something like Arch linux alarm have
2020-05-28 14:34:40 <ikke> "his change was discussed on IRC with _ikke_ and mps." heh :D
2020-05-28 14:35:29 <mps> ikke: where and what?
2020-05-28 14:35:59 <ikke> https://git.alpinelinux.org/aports/commit/?id=ec584ac1
2020-05-28 14:36:27 <ncopa> i sneaked in that :)
2020-05-28 14:37:20 <mps> ah, not "his change" but "This change" :)
2020-05-28 14:37:40 <ikke> yeah, miscopy, sorry
2020-05-28 14:38:40 <mps> np. I just thought someone will change self at our advice :D
2020-05-28 14:39:03 <ikke> hehe
2020-05-28 15:12:38 <ncopa> I'm pushing rc4. if nothing breaks i'll do 3.12.0 tomorrow
2020-05-28 15:15:14 <mps> I'm building qemu 5.0, if it pass will create MR
2020-05-28 15:22:08 <ncopa> drats... i forgot alpine-conf...
2020-05-28 15:28:49 <ikke> what drives the version of alpine-baselayout?
2020-05-28 15:30:17 <Cogitri> Can we get !8268 in 3.12 too?
2020-05-28 15:31:35 <mps> Cogitri: +1 for it
2020-05-28 15:33:07 <ncopa> I didnt have a chance to look at it
2020-05-28 15:33:23 <ncopa> it seems to change the current default, to always set those local vars?
2020-05-28 15:35:17 <ikke> yes, it was based on an issue a user had
2020-05-28 15:36:02 <ncopa> what was the issue?
2020-05-28 15:36:11 <mps> issue is raised few times on irc
2020-05-28 15:36:14 <Cogitri> I think musl defaults to C-UTF.8 anyway (or doesn't it, dalias?), but some programs don't recognise that without that env variable set
2020-05-28 15:36:37 <ikke> I noticed mosh complained that it was not set
2020-05-28 15:36:37 <Cogitri> E.g. DBus will start in non UTF-8 mode without that variable set, which breaks applications which expect UTF-8 to be available over DBus
2020-05-28 15:36:40 <ikke> but I had to set LC_ALL
2020-05-28 15:37:07 <ncopa> i wonder what the consequence is for docker images
2020-05-28 15:37:23 <ncopa> there is a testsuite for docker images that test if those things are set or not
2020-05-28 15:37:46 <ncopa> setting TZ=UTC or similar broke stuff
2020-05-28 15:37:54 <Cogitri> Hum
2020-05-28 15:38:02 <ncopa> but i guess that may be acceptable for new stable release
2020-05-28 15:38:18 <Cogitri> I don't really know that much about that language stuff, so I'd be fine with keeping things the way they are until 3.13 too
2020-05-28 15:38:51 <ncopa> you know what
2020-05-28 15:38:53 <ncopa> let merge it
2020-05-28 15:39:40 <ncopa> the only thing i think is wrong is the commti message
2020-05-28 15:40:07 <Cogitri> Oh, what would you prefer?
2020-05-28 15:40:08 <ncopa> it should be explained that we need to alwayse set those environment vars and why
2020-05-28 15:40:35 <Cogitri> Ah fair, I should've explained it more in the commit description
2020-05-28 15:40:47 <Cogitri> I can do that after lunch
2020-05-28 15:41:12 <ncopa> feel free to merge it after that
2020-05-28 15:41:22 <ncopa> im busy for the rest of the evening i think
2020-05-28 15:41:27 <ncopa> should do rc5 though
2020-05-28 15:41:31 <Cogitri> Okie, thanks for taking a look :)
2020-05-28 15:41:40 <ncopa> need to rerun the installer tests
2020-05-28 15:43:17 <Cogitri> BTW, not related to the 3.12 release, but what's the status of our docbook/other wiki replacment?
2020-05-28 15:43:34 <Cogitri> I think there was some work in that area some time ago but I'm not sure
2020-05-28 15:43:39 <ncopa> SpaceToast: ^^
2020-05-28 15:43:59 <ncopa> i suspect SpaceToast got demotivated for some reason
2020-05-28 15:44:02 <Cogitri> And I wanted to rewrite large parts of the contributing things in the wiki but figured it'd be best to do that in docbook directly if we're going to adopt that soon (tm)
2020-05-28 15:44:06 <ncopa> we need a driving force for that
2020-05-28 15:44:19 <Cogitri> And I got a bit jealous seeing Void Linux' super fancy new doc site :D
2020-05-28 15:44:24 <ncopa> we need a volunteer with a driving force
2020-05-28 15:44:48 <Cogitri> Yup, of course
2020-05-28 15:45:04 <Cogitri> Well, if someone knows a repo or smth where the current state is documented I'd love to take a look at it
2020-05-28 15:45:25 <ncopa> ask in #alpine-docs
2020-05-28 15:45:47 <Cogitri> Oh, we have a channel dedicated for that, right
2020-05-28 15:46:55 <ncopa> i guess we shoudl have a wiki page explaining how to contribute to documentation
2020-05-28 15:47:09 <SpaceToast> Cogitri: https://docs.alpinelinux.org is what we've got, sources are at https://gitlab.alpinelinux.org/alpine/docs
2020-05-28 15:47:31 <SpaceToast> it's not really a replacement for the wiki either - there's place for both
2020-05-28 15:48:07 <ncopa> its a replacement for the official documentation stuff
2020-05-28 15:48:08 <SpaceToast> it should be for official alpine docs, so nothing on, say, X (because it's not an alpine project, or anything related to basic alpine installation/particularities/etc)
2020-05-28 15:48:15 <SpaceToast> yes, just not the wiki as  a whole :)
2020-05-28 15:49:09 <Cogitri> Ah, thanks for explaining
2020-05-28 15:49:13 <SpaceToast> re: progress on it, I consider the user handbook quintessentially finished
2020-05-28 15:49:24 <SpaceToast> governance handbook is still waiting for anything to come out of that subproject
2020-05-28 15:49:39 <Cogitri> Oh neat. I don't think it's really well known among contributors though
2020-05-28 15:49:46 <SpaceToast> and re: the development handbook, my attempt to investigate had erm, issues, so I'm mostly going to let more active contributors work on that
2020-05-28 15:50:07 <SpaceToast> I'm still here (alpine is just a lot lower on my list of priorities nowadays), but I'm definitely available to review PRs, suggest improvements and merge stuff
2020-05-28 15:50:35 <SpaceToast> sounds complete / fair? ^^
2020-05-28 16:08:19 <Cogitri> Reviewing things is plenty already, thanks :)
2020-05-28 16:10:43 <mps> hmm, got qemu-system-rx when building upgrade to qemu 5.0.0 and I don't know what is it
2020-05-28 16:11:33 <Cogitri> I'll try to get adding more docs once exam time is over, but I should try to not get too many OSS things on my plate again :)
2020-05-28 16:25:03 <mps> nice, qemu 5.0.0 is working, system-{x86_64,aarch64,arm} at least (tested them on x86_64 host)
2020-05-28 17:36:25 <mps> huh, https://gitlab.alpinelinux.org/mps/aports/-/jobs/128869 : Duration: 5 minutes 0 seconds
2020-05-28 17:36:57 <mps> on my i7 with 8GB RAM it took more than a hour
2020-05-28 17:47:01 <ikke> that machine has 128 threads :P
2020-05-28 17:48:35 <mps> will someone send me one :)
2020-05-28 17:49:09 <ikke> heh
2020-05-28 17:50:01 <mps> I don't need it for my work, just for alpine development ;)
2020-05-28 18:12:10 <Ariadne> i have POWER9 192 threads for that
2020-05-28 18:12:22 <Ariadne> and POWER8 with even more threads, but SMT8 is less performant
2020-05-28 18:12:38 <Cogitri> I'm all set with my 3950X currently :)
2020-05-28 18:12:55 <Cogitri> And I doubt I can fit that many cores into mini itx :D
2020-05-28 18:13:30 <Cogitri> BTW, Ariadne: Who would build the packages of those community supported arches you suggested?
2020-05-28 18:13:49 <Cogitri> Would it be AUR style-build-it-yourself or would Alpine still build it?
2020-05-28 18:14:20 <Ariadne> Alpine would still maintain the builders, but the output wouldn't be "supported"
2020-05-28 18:21:51 <mps> anyone brave^Wwilling to review !8531 and download artifacts from CI and check if it works
2020-05-28 18:22:21 <ikke> I dont have a host to test it on
2020-05-28 18:23:16 <mps> I tested qemu-system-{x86_64,aarch64,armv7} on x86_64 host, works fine and I'm tempted to merge it, to have it in 3.12
2020-05-28 18:24:04 <maxice8> from the setuptools 47.0.0 changelog
2020-05-28 18:24:07 <maxice8> * #2094: Setuptools now actively crashes under Python 2. Python 3.5 or later is required. Users of Python 2 should use ``setuptools<45``.
2020-05-28 18:24:50 <ikke> that link is irrelevant :)
2020-05-28 18:25:44 <Ariadne> i think we should wait on qemu 5 for 3.13
2020-05-28 18:25:52 <Ariadne> i am planning to push musl 1.2.0 immediately on branch
2020-05-28 18:26:14 <Cogitri> Uhh
2020-05-28 18:26:25 <Ariadne> it is backwards compatible ABI-wise
2020-05-28 18:26:26 <Cogitri> Do we still need loads of patches for 32-bit arches?
2020-05-28 18:26:28 <Ariadne> for 32-bit
2020-05-28 18:26:48 <Ariadne> no, most of it is upstreamed now :)
2020-05-28 18:26:48 <Cogitri> ABI wise it's compatible, but the wiki page of musl sounded like a lot of breakage
2020-05-28 18:27:08 <Ariadne> i have already done a test rebuild, it is not too bad
2020-05-28 18:28:09 <Ariadne> and 3.13 will most likely become 4.0, because apk3 will likely be done by then
2020-05-28 18:29:37 <Cogitri> Ah okay, the wiki page sounded rather grim to me
2020-05-28 18:29:38 <mps> Ariadne: could you elaborate a little why wait for 3.13 with qemu 5.0
2020-05-28 18:30:16 <ikke> probably a big upgrade right before release
2020-05-28 18:30:21 <Ariadne> basically this
2020-05-28 18:30:48 <mps> hmm, not much big, no breaking changes
2020-05-28 18:31:05 <Ariadne> go ahead and push it i guess
2020-05-28 18:31:33 <mps> and BDFL expressed interest to have it on 3.12, but I think he didn't had time so I made it
2020-05-28 18:31:42 <Ariadne> i am working on $CENDIAN support in abuild right now
2020-05-28 18:31:53 <Ariadne> and !big-endian and !little-endian arch modifiers
2020-05-28 18:32:02 <Ariadne> so we can block packages we know won't work based on endianness
2020-05-28 18:32:15 <ikke> maybe 64-bit / 32-bit as well?
2020-05-28 18:32:20 <Ariadne> yes, good idea
2020-05-28 18:32:46 <mps> aha, good idea
2020-05-28 18:32:52 <mps> :)
2020-05-28 18:34:21 <hjaekel> Hi Cogitri, did you look at !8218 again; can it be merged?
2020-05-28 18:41:42 <Ariadne> mps: the artifacts work for me (qemu-system-x86_64), so i am just going to push it
2020-05-28 18:42:03 <mps> merge, you mean :)
2020-05-28 18:42:08 <Ariadne> whatever
2020-05-28 18:42:09 <ikke> same difference
2020-05-28 18:42:11 <Ariadne> you know what i mean
2020-05-28 18:42:33 <ikke> starts good
2020-05-28 18:42:48 <ikke> checksum failure :/
2020-05-28 18:43:00 <mps> Ariadne: please, didn't wanted to be offensive, because that put ':)' at the end
2020-05-28 18:43:12 <Ariadne> bummer
2020-05-28 18:43:43 <Ariadne> i'm not feeling this AWS merge request for linux-edge incidentally
2020-05-28 18:43:55 <mps> hm, how it passed on CI
2020-05-28 18:43:56 <Ariadne> i don't think AWS should be shipping alpine AMIs with linux-edge kernel
2020-05-28 18:44:22 <ikke> Ariadne: context?
2020-05-28 18:44:28 <Ariadne> its the newest MR on gitlab
2020-05-28 18:44:31 <Ariadne> !8532
2020-05-28 18:45:09 <Ariadne> enabling the driver, sure, but amazon shipping AMIs with it seems like madness to me
2020-05-28 18:45:21 <ikke> right
2020-05-28 18:46:15 <ikke> it only fails on armhf/v7 strange
2020-05-28 18:46:24 <ikke> at least, it seems
2020-05-28 18:47:07 <mps> and on 3.12 builders
2020-05-28 18:47:22 <Ariadne> download race
2020-05-28 18:47:56 <ikke> because they share the same distfiles path I guess
2020-05-28 18:48:00 <Ariadne> yep
2020-05-28 18:49:12 <mps> Ariadne: thanks for comment on !8532
2020-05-28 18:49:29 <Ariadne> i also commented upstream
2020-05-28 18:50:34 <Ariadne> i'm not opposed to shipping the driver, but i find shipping actual images with that kernel to be dubious
2020-05-28 18:50:42 <mps> this one is even better, thanks again
2020-05-28 18:50:43 <Ariadne> sounds like it will be a pain in the ass for us
2020-05-28 18:51:36 <mps> they didn't read note in APKBUILD for linux-edge, obviously
2020-05-28 18:51:58 <mps> # NOTE: this kernel is intended for testing
2020-05-28 18:51:59 <mps> # please resist urge to upgrade it blindly
2020-05-28 18:51:59 <ikke> mps: like I predicted :P
2020-05-28 18:52:14 <Ariadne> we should clarify that note i think
2020-05-28 18:52:24 <mps> ikke: yes, as usual you are always right
2020-05-28 18:52:30 <Ariadne> but there is no formal "kernel team" yet
2020-05-28 18:52:34 <Ariadne> just a defacto one
2020-05-28 18:52:36 <Cogitri> Let's rename it to linux-kernel-panic :D
2020-05-28 18:52:40 <Ariadne> i should work on that too
2020-05-28 18:52:47 <ikke> Cogitri: in favor
2020-05-28 18:53:01 <Ariadne> i should invent human cloning so i can clone myself and ncopa and fabled and
2020-05-28 18:53:26 <mps> Ariadne: I expected that you will add some 'config-edge.xxx'
2020-05-28 18:53:51 <Ariadne> yes, eventually, but i am not sure if edge should target octeon or malta
2020-05-28 18:54:01 <Ariadne> i think octeon is more practical
2020-05-28 18:54:02 <mps> Cogitri: where I'm using linux-edge it is quite stable, didn't had any problem
2020-05-28 18:54:29 <Cogitri> It kernel panic'ed for me on boot when I couldn't resist the urge to upgrade ^^
2020-05-28 18:54:32 <Ariadne> but octeon kernel is weird :)
2020-05-28 18:54:41 <Ariadne> so... dunno
2020-05-28 18:54:45 <mps> and I'm using it (in some variations) for more than 3 months
2020-05-28 18:55:09 <Ariadne> only some octeon boards can boot an initramfs
2020-05-28 18:55:27 <Ariadne> so things that are normally in initramfs are staticly linked instead on octeon
2020-05-28 18:56:15 <mps> Ariadne: because of this I made ext4, f2fs and some other drivers 'in-kernel' and not as modules
2020-05-28 18:56:40 <Ariadne> so much work to do
2020-05-28 18:56:42 <Ariadne> :(
2020-05-28 18:57:49 <mcrute> Ariadne: they AMIs are a community project... I commented on the issue but we don't have any intention of actually shpping linux-edge in anything we support
2020-05-28 18:57:58 <Ariadne> mcrute: yeah no worry
2020-05-28 18:58:04 <Ariadne> it was just a little eyebrow raising
2020-05-28 18:58:41 <Ariadne> the point of linux-edge is to allow us (kernel maintainers) to evaluate new features in current mainline stable kernel
2020-05-28 18:58:57 <mcrute> haha, yeah I could see that... probably should have been more explicit about what I was doing :-)
2020-05-28 18:58:59 <Ariadne> e.g. they inform what changes will be made in next linux-lts kernel branch
2020-05-28 18:59:21 <Ariadne> problem is
2020-05-28 18:59:23 <mcrute> do you migrate those changes forward to the main kernels?
2020-05-28 18:59:23 <mps> but if someone want to run linux-edge on this kind of 'what-is-it' (I don't know) then we could enable this driver
2020-05-28 18:59:34 <Ariadne> yeah, its no problem to enable the driver
2020-05-28 19:00:00 <Ariadne> its just that people may wind up using linux-edge because it enables some feature (because we are evaluating it), and then we stop evaluating it, and the feature goes away
2020-05-28 19:00:15 <mps> yes
2020-05-28 19:00:34 <krichy> Hi here
2020-05-28 19:00:40 <mps> but it's testing, so no guaranties
2020-05-28 19:00:41 <Ariadne> thats basically the situation we wish to avoid
2020-05-28 19:01:16 <mps> and intended to stay in testing
2020-05-28 19:01:18 <krichy> In alpine:3.11 log4cplus fails on armhf.
2020-05-28 19:01:23 <mcrute> Ariadne: makes sense, we definitely don't want to support the edge package and will certainly not encourage that behaviour, but still don't want to prevent it if somebody has a really specific use-case
2020-05-28 19:01:36 <ikke> krichy: fails how
2020-05-28 19:01:40 <Ariadne> mcrute: sure i am just saying for documentation's sake :)
2020-05-28 19:01:46 <krichy> howewer, I've built it on alpine:edge, and now it succeeds
2020-05-28 19:01:58 <krichy> so, what is the procedure to enable it again in ports tree?
2020-05-28 19:01:59 <ikke> mcrute: managing expectations :)
2020-05-28 19:02:03 <mcrute> we need to document our support of the edge images better anyhow so I'll make a note of that as well
2020-05-28 19:02:16 <mcrute> ikke: for sure!
2020-05-28 19:02:33 <krichy> fails some tests in 3.11, that is mentioned in APKBUILD
2020-05-28 19:02:37 <mcrute> once the aarch64 stuff is stable I'd really like to make the case to bring these into Alpine as officially supported
2020-05-28 19:03:02 <mcrute> but small steps first I think
2020-05-28 19:04:24 <mps> mcrute: actually I would like to enable more drivers in linux-edge so people can test before they 'migrated' to linux-lts
2020-05-28 19:05:17 <krichy> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/log4cplus/APKBUILD
2020-05-28 19:05:21 <mcrute> mps: gotcha, so this should be in-line with that goal :-)
2020-05-28 19:05:39 <krichy> also, this is a blocker for kea dhcp being built
2020-05-28 19:05:57 <mcrute> mps: I'm happy to build a private AMI with the edge kernel specifically for validation of upcoming changes... I've been pondring some way to do automated tests on the AMI
2020-05-28 19:06:00 <ikke> krichy: you can create a merge request to enable it again
2020-05-28 19:06:44 <mcrute> but I'm not sure what you're doing for testing and haven't (yet) had time to research it... would definitely appreciate a push in the right direction
2020-05-28 19:06:53 <mps> mcrute: good, then I think we can enable this driver (maybe at next upgrade)
2020-05-28 19:07:28 <mcrute> mps: can we land the lts/virt changes a lot sooner than that?
2020-05-28 19:07:48 <krichy> ikke: thanks. I only have access to armhf architectures, so I dont know if the same is true for s390 or not.
2020-05-28 19:07:49 <mps> that depends on linux-lts maintainer, not me
2020-05-28 19:07:59 <mps> mcrute: ^
2020-05-28 19:08:03 <ikke> krichy: we have CI in place
2020-05-28 19:08:13 <ikke> so it would try to build it on all arches
2020-05-28 19:08:20 <ikke> though, armhf sadly is not supported
2020-05-28 19:08:29 <krichy> then, armv7
2020-05-28 19:08:30 <ikke> (armv7 is though)
2020-05-28 19:08:32 <ikke> yea
2020-05-28 19:08:33 <mcrute> mps: who is that?
2020-05-28 19:08:40 <ikke> ncopa
2020-05-28 19:08:49 <mps> mcrute: but we are now busy with 3.12 release
2020-05-28 19:08:54 <krichy> ok, and will a merge req trigger a build?
2020-05-28 19:09:09 <ikke> once it's merged to master, it will
2020-05-28 19:09:19 <krichy> ok, thanks.
2020-05-28 19:09:54 <krichy> but, if armhf is not supported, why is that mentioned in the APKBUILD at all?
2020-05-28 19:09:55 <krichy> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/log4cplus/APKBUILD#L10
2020-05-28 19:10:02 <mcrute> well this is a release blocker for us but I can at least get everything in order and test out a custom build to validate it then poke ncopa and hope for the best :-)
2020-05-28 19:10:13 <ikke> krichy: we do build for armhf, we don't have CI for it
2020-05-28 19:11:04 <mps> BTW, anyone know why our curl is not upgraded to https://curl.haxx.se/download/curl-7.70.0.tar.gz for 3.12
2020-05-28 19:11:31 <Cogitri> Probably because no one got to it yet
2020-05-28 19:11:44 <ikke> I can prepare an MR
2020-05-28 19:13:01 <mps> good
2020-05-28 19:20:44 <Cogitri> hjaekel: I'll give it a look, thanks for the ping
2020-05-28 19:21:39 <mps> ikke: curl 7.70.0 on armv7, => make: *** [Makefile:804: nonflaky-test] Error 1
2020-05-28 19:22:37 <mps> lets see on aarch64
2020-05-28 19:24:28 <krichy> ikke I've created one: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8535
2020-05-28 19:24:29 <ncopa> mcrute: thanks for the ena driver MR. i thinkwe want it for 3.12 release
2020-05-28 19:24:48 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8536
2020-05-28 19:25:09 <Ariadne> mcrute: can you fix the commit message, and i'll merge it
2020-05-28 19:25:28 <ncopa> Ariadne: please hold your horses. we need rebuild the thirdparty modules too
2020-05-28 19:25:33 <Ariadne> oh
2020-05-28 19:25:34 <Ariadne> yes
2020-05-28 19:25:35 <Ariadne> we do
2020-05-28 19:25:50 <ikke> :)
2020-05-28 19:26:10 <ncopa> commit message looks good to me
2020-05-28 19:28:44 <mcrute> ncopa: was able to validate that this does work to bring-up networking on a1 and m6g so should be good to ship from my perspective
2020-05-28 19:29:04 <mcrute> ncopa: anything I can do to help with the 3p module rebuild? I assume it's just a bunch of version bumps?
2020-05-28 19:29:05 <Cogitri> Can we merge !8218 still or should be wait for 3.13 with that? It's not a massive upgrade, but does need a few rebuilds due to ABI breakage
2020-05-28 19:29:14 <mcrute> happy to do the work on that if it will help get this released faster :-)
2020-05-28 19:30:01 <ikke> Ariadne: why does verification of kea on s390x require a separate MR?
2020-05-28 19:30:08 <Cogitri> Wondering that too
2020-05-28 19:30:14 <Ariadne> i mean, it doesn't, but it is cleaner
2020-05-28 19:30:23 <Cogitri> If they're in one MR s390x CI can just run over both packages
2020-05-28 19:30:26 <Cogitri> How is that cleaner?
2020-05-28 19:30:33 <Ariadne> logical separation of concerns
2020-05-28 19:30:39 <Cogitri> If it's in one MR we can validate it actually works thanks to CI
2020-05-28 19:31:03 <Cogitri> And I really don't see the advantage of splitting such MRs up when one change hard requires another one
2020-05-28 19:31:17 <Ariadne> what i am actually saying is that the submitter has no way of validating it works on s390x other than our CI.  so he should not make changes he cannot validate himself in an MR.
2020-05-28 19:31:55 <Ariadne> enablement of armhf is one concern, s390x is another.
2020-05-28 19:32:02 <mps> ikke: hm, curl 7.70.0 pass on aarch64
2020-05-28 19:32:20 <Ariadne> that the CI can validate both changes at once is not relevant to my point
2020-05-28 19:32:36 <ikke> it fails on armv7
2020-05-28 19:32:39 <Ariadne> the focus of this MR is to enable kea on armhf.  it should leave s390x out of the mix
2020-05-28 19:32:43 <mps> ikke: yes
2020-05-28 19:32:48 <Cogitri> So you want everyone who enables packages on s390x to have a s390x machine?
2020-05-28 19:32:57 <Cogitri> I'm confused, just enable all the things and see if CI likes it
2020-05-28 19:33:10 <Cogitri> I don't see the advantage of enabling it one arch at a time
2020-05-28 19:33:33 <Ariadne> enabling it one arch at a time means we can git revert broken arch enablements
2020-05-28 19:34:00 <Ariadne> but, whatever
2020-05-28 19:34:02 <ikke> they are still separate commits
2020-05-28 19:34:05 <Cogitri> If one arch works on CI but doesn't on the builders (which rarely happens) changing that is trivial without git revert too
2020-05-28 19:35:13 <Ariadne> one is a more disciplined approach, the other is not
2020-05-28 19:35:13 <ncopa> Cogitri: wait with ABI rebuilds (higher risk for delay the release)
2020-05-28 19:35:31 <ncopa> mcrute: im on it. will push in a few mins
2020-05-28 19:35:41 <ikke> ncopa: do you want curl 7.70.0 in 3.12?
2020-05-28 19:36:01 <Cogitri> ncopa: Okie, will do
2020-05-28 19:36:04 <Ariadne> throwing tons of stuff in a single MR also causes ABI rebuids to go south.  the rebuild should be pushed *after* the parent, which requires two MRs.
2020-05-28 19:36:33 <ikke> Ariadne: what if it breaks the build of some package?
2020-05-28 19:36:35 <Ariadne> that is so parent is always bumped *before* any part of the rebuild
2020-05-28 19:36:40 <ncopa> ikke: yes
2020-05-28 19:36:50 <ikke> ncopa: ok
2020-05-28 19:37:07 <ncopa> unless it breaks stuff and requires time to fix
2020-05-28 19:37:10 <mcrute> ncopa: okay, thanks! in general though is this something I can/should do in tandem with kernel patches? I'm certainly happy to do it to save you the effort
2020-05-28 19:37:34 <Ariadne> ikke: sure, but the CI is incapable of evaluating a full rebuild because of the same problem.  buildrepo does not always get the order right.  i've seen it happen many times.
2020-05-28 19:37:49 <ncopa> mcrute: i have scripts for it. i think its easier for me to deal with it myself
2020-05-28 19:37:57 <mcrute> okie dokie
2020-05-28 19:38:09 <ncopa> thanks for asking
2020-05-28 19:38:26 <ncopa> buildrepo should build in correct order
2020-05-28 19:38:58 <Ariadne> it should, but i have seen it build dependents first.  this happened a couple of times with mips64 bringup
2020-05-28 19:39:19 <ncopa> it may happen if there are something fishyin the dependencies
2020-05-28 19:39:23 <ncopa> like circular dependencies
2020-05-28 19:39:40 <Ariadne> right, that is probably what causes it
2020-05-28 19:40:45 <ncopa> other special situation is when some base install lib gets abi breakage. then it will not be updated due to old version is needed by something in the base install
2020-05-28 19:41:03 <ncopa> and you may end up do rebuild against the old version
2020-05-28 19:41:15 <ikke> Ariadne: to me, at least theoretically, it would make sense to see the upgrade of a package and all it's dependencies as an attomic operation
2020-05-28 19:41:20 <Ariadne> anyway, my point is that dumping everything in a single MR is not good practice
2020-05-28 19:41:36 <ncopa> i think for ABI breakages its the way to go
2020-05-28 19:41:52 <ncopa> so we can push them all in one go
2020-05-28 19:42:29 <ncopa> that said, having an MR with 100 commits is not a good idea
2020-05-28 19:43:06 <Cogitri> Sure, everything should be done in moderation :)
2020-05-28 19:43:12 <ncopa> so i think doing it without an MR may be a better way to do it
2020-05-28 19:43:35 <ncopa> so we dont need rebuild *everything* for every tiny change
2020-05-28 19:44:34 <ncopa> there was one thing more i wanted to fix before 3.12 relase. the setup-interfaces with wifi is non-optimal
2020-05-28 19:44:56 <ncopa> it failed for me earlier with some weird messages
2020-05-28 19:45:14 <ncopa> i think the wpa_supplicant config for "open" networks is invalid
2020-05-28 19:45:18 <ncopa> and things went south
2020-05-28 19:45:20 <mps> ncopa: it worked for me today on rpi zero
2020-05-28 19:45:33 <ncopa> it worked for me when i tried to reproduce
2020-05-28 19:45:55 <mps> ah, 'open network', didn't tried that
2020-05-28 19:46:05 <ncopa> i believe it will fail with an open network, non PSK
2020-05-28 19:46:30 <ncopa> but i guess those are rare
2020-05-28 19:46:43 <ncopa> and even with captive portals it wont work
2020-05-28 19:47:04 <ncopa> (common usecase for open networks nowdays)
2020-05-28 19:47:38 <ncopa> what I dont know is how it ended up pick the "open" network path
2020-05-28 19:47:43 <mps> yes, but to late for 3.12 to dig deeply at that, imo
2020-05-28 19:47:49 <Ariadne> anyways
2020-05-28 19:47:52 <ncopa> but i guess its not a showstopper for 3.12
2020-05-28 19:48:00 <Ariadne> i have some post-3.12 things for abuild
2020-05-28 19:48:14 <ncopa> cool
2020-05-28 19:48:22 <Ariadne> we are hoping to have the apk-tools side done for 3.12
2020-05-28 19:49:01 <ncopa> i have various ideas for abuild improvements
2020-05-28 19:49:10 <ncopa> but never had time to implement any :-/
2020-05-28 19:49:24 <Ariadne> basically, apk-tools gets new --print-endian and --print-bitwidth arguments in 2.11.  abuild picks up on these values, and you can do arch="all !big-endian" or arch="all !32-bit"
2020-05-28 19:49:56 <ncopa> ah! nice!
2020-05-28 19:50:31 <mps> ikke: also !7346
2020-05-28 19:50:46 <ikke> mps: oh, thanks!
2020-05-28 19:50:58 <mps> we missed it somehow
2020-05-28 19:51:01 <Ariadne> i think once the --print-endian and --print-bitwidth go in, apk-tools 2.11 is basically ready
2020-05-28 19:51:06 <Ariadne> but that's a fabled thing
2020-05-28 19:51:28 <Ariadne> we would like apk-tools 2.11 to ship with 3.12, obviously.  but we could upgrade it after the point i suppose
2020-05-28 19:52:08 <ncopa> yes, i think thats a good idea to hold it til post 3.12
2020-05-28 19:54:23 <Cogitri> Quite a few things were changed in 2.11, yes
2020-05-28 19:58:46 <ikke> mps: I'll close mine then
2020-05-28 20:00:51 <mps> ikke: looks like is it to late to try to fix these tests on armv7
2020-05-28 20:01:58 <mps> anyway maybe we shouldn't upgrade it now, because ncopa wants to make 3.12 release tomorrow
2020-05-28 20:02:34 <Ariadne> ncopa: i am looking at update-kernel, but i don't understand the issue with mkinitfs on octeon
2020-05-28 20:07:51 <Ariadne> oh, i see.  the modloop is empty
2020-05-28 20:10:51 <ikke> Unsupported proxy syntax in '127.0.0.1:0'
2020-05-29 07:38:57 <Cogitri> I think the mariadb pkgconfig file or smth is bad since the 10.4.13 upgrade, lots of stuff suddenly fails to find mariadb's headers without explicit -I directives for the compiler via C*FLAGS
2020-05-29 07:42:49 <ncopa> sounds like pkgconfig is broken yes
2020-05-29 07:47:26 <ncopa> Cogitri do you have a reproducer?
2020-05-29 07:48:43 <Cogitri> kea and gdal fail to build now
2020-05-29 07:49:07 <Cogitri> I've added a "-I/usr/include/..." to gdal to fix the builders
2020-05-29 07:49:21 <Cogitri> So if you remove that gdal should fail again to test
2020-05-29 07:51:35 <ncopa> it doesnt fail during configure
2020-05-29 07:52:13 <Cogitri> gdal fails during compile, kea during configure
2020-05-29 07:58:52 <ncopa> hum
2020-05-29 07:59:16 <ncopa> we dont have the old mariadb somewhere?
2020-05-29 07:59:32 <ncopa> $ pkg-config --cflags mariadb
2020-05-29 07:59:32 <ncopa> -I/usr/include/mysql
2020-05-29 08:00:05 <ncopa> but those projects seems to need /usr/include/mysql/server as well
2020-05-29 08:00:14 <ncopa> so its an upstream issue
2020-05-29 08:03:39 <Cogitri> Upstream being gdal/kea ?
2020-05-29 08:03:55 <Cogitri> Or mariadb upstream?
2020-05-29 08:04:26 <ncopa> upstream mariadb
2020-05-29 08:04:33 <ncopa> this may be related https://github.com/MariaDB/server/commit/f21592c675e198ba6298748b40e5d695a17f4e5f
2020-05-29 08:05:02 <ncopa> my guess from that commit is that they used to set include dir to /usr/include/mariadb/server
2020-05-29 08:05:20 <ncopa> and had $includedir/.. added to cflags
2020-05-29 08:05:35 <ncopa> then they changed includedir to /usr/include/mariadb
2020-05-29 08:05:39 <ncopa> and that commit makes sense
2020-05-29 08:05:49 <ncopa> that a wild guess though
2020-05-29 08:07:29 <Cogitri> Possibly. I guess I'll go ahead and compile the old mariadb in a bit to check that, but currently busy studying
2020-05-29 08:11:09 <ikke> currently looking at curl on armv7 btw, seeing if I can find why the tests fail
2020-05-29 08:15:39 <ikke> ncopa: curl seems to build fine on my armv7 lxc container
2020-05-29 08:32:50 <mps> ikke: it will need bisecting between previous and current release to find problem, probably
2020-05-29 08:45:32 <ikke> mps: the question is if it's actual an issue with curl
2020-05-29 08:46:53 <mps> ikke: i tested in lxc and on native (armv7), same result
2020-05-29 08:47:00 <ikke> success you mean?
2020-05-29 08:47:07 <mps> no, fail
2020-05-29 08:47:10 <ikke> hmm
2020-05-29 08:47:14 <ikke> strange, why do I get a success
2020-05-29 08:47:21 <mps> previous version works fine
2020-05-29 08:47:28 <ikke> ah, yes
2020-05-29 08:47:39 <ikke> I thought it was up-to-date, but only with master, not with the MR :)
2020-05-29 08:47:42 <ikke> ok, good
2020-05-29 08:47:43 <mps> you got success in lxc? then it is good
2020-05-29 08:47:47 <ikke> no
2020-05-29 08:47:52 <ikke> previous version
2020-05-29 08:48:02 <ikke> forgot to checkout the MR branch
2020-05-29 08:48:05 <mps> ah, yes, previous version is ok
2020-05-29 08:49:07 <mps> if BDFL don't release 3.12 today I will try to bisect it over weekend
2020-05-29 08:49:23 <ikke> I have time today to look at it
2020-05-29 08:50:03 <mps> but not sure if we need to rebuild some (most dependants) packages with upgraded version for release
2020-05-29 08:50:16 <ikke> is there a soname change?
2020-05-29 08:50:52 <mps> as I see no, but tests for such important thing would be good
2020-05-29 08:51:24 <ikke> "Use of uninitialized value $HTTPPORT in substitution iterator at ./runtests.pl line 3220" might be the issue
2020-05-29 08:51:33 <mps> yes
2020-05-29 08:51:44 <mps> that is the cause of problem
2020-05-29 08:51:47 <ikke> so might be just an issue in the test suite
2020-05-29 08:52:06 <mps> actually manifestattion of problem
2020-05-29 08:52:18 <ikke> where is $HTTPPORT coming from
2020-05-29 08:53:01 <mps> it is set in tests/quicktest.pl (sorry writting from head)
2020-05-29 08:53:24 <mps> but tests subdir for sure
2020-05-29 08:53:55 <mps> and I tried to fix it manually but without luck
2020-05-29 08:54:20 <ikke> ok, let's see what I can find
2020-05-29 08:54:55 <ikke> runtests.pl
2020-05-29 08:54:57 <ikke> 131:my $HTTPPORT=$noport;    # HTTP server port
2020-05-29 08:57:47 <mps> yes, this one
2020-05-29 08:58:06 <mps> look 2 lines above
2020-05-29 08:58:54 <ikke> noport="[not running]" you mean
2020-05-29 09:00:49 <mps> yes
2020-05-29 09:00:55 <mps> this is strange
2020-05-29 09:01:16 <ikke> But the error says the variable is undefined, right?
2020-05-29 09:01:24 <mps> (I'm out on breakfast now so can't do anything helpful)
2020-05-29 09:01:54 <mps> yes, that part is strange
2020-05-29 09:02:32 <mps> why $HTTPORT, SMTPPORT etc are undefined
2020-05-29 09:06:50 <mps> I'm thinking to ask upstream on ML, if you don't fix it in meantime :)
2020-05-29 09:46:36 <ncopa> ikke: if its a problem with testsuite, then i think you can disable the test and report it upstream
2020-05-29 09:50:00 <ncopa> Cogitri: think the mariadb issue may be a problem in kea and gdal
2020-05-29 09:50:10 <ncopa> it looks like mariadb is doing the right thing
2020-05-29 09:50:42 <ncopa> they moved the pkgconfig from /usr/share to /usr/lib so i suspect that they didnt use the pkg-config in previous release
2020-05-29 09:58:53 <Cogitri> Hm, I'm pretty sure they used the pkgconfig previously, pkgconfig searches in /usr/share too
2020-05-29 09:59:03 <Cogitri> We just prefer to put it in /usr/lib I think
2020-05-29 09:59:22 <Cogitri> It's just weird that two unrelated projects suddenly break in the same way after the upgrade
2020-05-29 09:59:51 <ikke> ncopa: I'm not certain yet, still figuring out what is causing it
2020-05-29 10:28:46 <ncopa> bah.. its not healthy to stress like i do now...
2020-05-29 10:29:09 <ncopa> i guess im stupid for trying include more than i should in the release
2020-05-29 10:29:30 <ikke> Anything I can help with?
2020-05-29 10:29:55 <ncopa> u
2020-05-29 10:30:03 <ncopa> maybe start write release notes?
2020-05-29 10:30:08 <ikke> Certainly
2020-05-29 10:30:13 <ncopa> i think i'll do rc5 too
2020-05-29 10:30:25 <maxice8> don't forget to take a look at the wiki
2020-05-29 10:30:29 <ncopa> once rc5 is out, help me test the installer
2020-05-29 10:30:36 <ikke> maxice8: yes, that was exactly my plan
2020-05-29 10:30:38 <ncopa> i think we should have a link to the wiki too
2020-05-29 10:31:21 <ikke> I have a day off :)
2020-05-29 10:35:21 <ikke> zfs-lts checksums were not updated
2020-05-29 10:39:55 <ncopa> i messed up big time
2020-05-29 10:40:03 <ncopa> well... i messed up
2020-05-29 10:40:09 <ncopa> i merged a broken commit
2020-05-29 10:40:29 <ncopa> but fortunately i forgot to update the checkum in subsequent update
2020-05-29 10:40:48 <ncopa> or people would bet broken (unbootable) systems now if they updated
2020-05-29 10:41:15 <ncopa> i really should not trust that people doing MRs know what they are doing
2020-05-29 10:42:21 <ikke> yeah, reviewing is one of the harder tasks in my experience
2020-05-29 10:43:46 <mps> ikke: yes
2020-05-29 10:44:20 <mps> I mean, also I have this feeling
2020-05-29 10:44:55 <mps> it's a lot easier to just 'throw' something in gitlab
2020-05-29 11:19:58 <ncopa> if build servers complete i'll tag rc5
2020-05-29 11:20:08 <ncopa> which will need some testing
2020-05-29 11:21:58 <mps> that means you will not make 3.12 release today?
2020-05-29 11:27:23 <nmeum> I sometimes have the feeling that reviewing a PR is more work than doing the same thing on your own
2020-05-29 11:27:38 <ncopa> mps: depends if we manage to verify that rc5 works
2020-05-29 11:28:00 <ncopa> nmeum: yes. agree. its often faster to just do it yourself
2020-05-29 11:28:27 <ncopa> but it is also good to teach others how to do it
2020-05-29 11:28:32 <Cogitri> nmeum: Yes, it often is more work the first time
2020-05-29 11:28:33 <nmeum> yes, indeed
2020-05-29 11:28:41 <Cogitri> But new contributors need to be taught somehow :)
2020-05-29 11:29:03 <ncopa> and teach people requires lots of patience...
2020-05-29 11:32:15 <mps> people who are willing to learn is pleasure to work with
2020-05-29 11:33:01 <ncopa> usually yes
2020-05-29 11:33:49 <mps> actually we have more those who are quite ready to learn, but some are 'stubborn' :)
2020-05-29 11:35:24 <gompa> is pipewire-dev supposed to live in /usr/include/pipewire-3.0/pipewire/, having it in a subdir like this makes the chromium build proccess unable to find it
2020-05-29 11:36:11 <maxice8> I think yes
2020-05-29 11:36:23 <maxice8> It is meant to allow people to have multiple pipewires
2020-05-29 11:36:39 <maxice8> The pkgconfig should point to the right path
2020-05-29 11:37:07 <ncopa> rc5 is tagged
2020-05-29 11:37:32 <ncopa> now i want to test that the installer still works
2020-05-29 11:37:50 <ikke> installed = alpine-setup, right?
2020-05-29 11:37:55 <ikke> installer
2020-05-29 11:38:01 <ncopa> yes
2020-05-29 11:38:22 <mps> ikke: setup-alpine
2020-05-29 11:38:24 <ncopa> also have a look at the firstboot service during boot
2020-05-29 11:39:02 <ncopa> want to test boot and install EFI as well. sys install
2020-05-29 11:39:10 <ikke> mps: uhh, yes :)
2020-05-29 11:39:11 <ncopa> lvm sys does not work with EFI
2020-05-29 11:40:15 <gompa> would add a cpath env to the chromium abuild prepare ? or what would be the proper way to do this ?
2020-05-29 11:40:34 <ikke> ncopa: testing rc5 now
2020-05-29 11:40:43 <ncopa> awesome. thanks!
2020-05-29 11:40:55 <ncopa> i'll test the -xen image
2020-05-29 11:41:10 <mps> no, ikke use awesomeWM for testing :)
2020-05-29 11:41:29 <ikke> haha :D
2020-05-29 11:42:33 <ikke> ncopa: is it possible to remove nomodeset from kernel parameters for sys installs?
2020-05-29 11:42:38 <ikke> by default
2020-05-29 11:43:02 <Ariadne> better to ask
2020-05-29 11:43:09 <ikke> right
2020-05-29 11:43:13 <Ariadne> framebuffer is shit on ipmi
2020-05-29 11:49:30 <ikke> ncopa: I don't see anything about firstboot being mentioned
2020-05-29 11:55:05 <ncopa> only look that the service does not fail to start during first boot.
2020-05-29 11:55:09 <ncopa> it didnt
2020-05-29 11:55:17 <ncopa> so i guess its fine
2020-05-29 11:55:26 <ikke> But accoding to the initd file it should have shown something
2020-05-29 11:56:02 <ncopa> Starting firstboot ... [OK]
2020-05-29 11:56:14 <ncopa> thats shown when you boot the iso
2020-05-29 11:56:26 <ikke> ah, only when you boot the iso
2020-05-29 11:56:30 <ncopa> yeah
2020-05-29 11:56:31 <ikke> not after installation?
2020-05-29 11:56:33 <ikke> ok
2020-05-29 11:57:11 <ikke> should I test the virtual image as well?
2020-05-29 11:57:18 <ncopa> yes please
2020-05-29 11:57:34 <ncopa> can you also test EFI boot?
2020-05-29 11:58:10 <ikke> Can I test that with qemu?
2020-05-29 12:03:00 <jenneron> hi, i can't make merge request, https://gitlab.alpinelinux.org/jenneron/aports, that's what i got when i tried:
2020-05-29 12:03:00 <jenneron> Unfortunately, your email message to GitLab could not be processed.
2020-05-29 12:03:00 <jenneron> You are not allowed to perform this action. If you believe this is in error, contact a staff member.
2020-05-29 12:03:35 <jenneron> i sent emty email with subject "testing/xf86-input-multitouch" (name of branch)
2020-05-29 12:13:32 <ncopa> ikke: yes
2020-05-29 12:13:40 <ncopa> whee.. xen work
2020-05-29 12:14:42 <ncopa> i tested: boot alpine-xen in qemu, with 2 disks 8G, run setup-alpine and install on both vda vdb. setup-disk will create md0, md1 and md2 raid1 devs
2020-05-29 12:15:09 <ncopa> xen dom0 boots from disk. then i followed https://wiki.alpinelinux.org/wiki/Create_Alpine_Linux_PV_DomU
2020-05-29 12:15:16 <ncopa> and managed to create a pv
2020-05-29 12:15:30 <ncopa> works like a charm
2020-05-29 12:15:52 <ncopa> the only issue i found along the way was that the keymap was not restored after the sys install
2020-05-29 12:16:40 <ncopa> i think the problem is that loadkmap is not configured to start
2020-05-29 12:35:19 <ncopa> efi boot works in virtualbox
2020-05-29 12:35:36 <ncopa> they i guess its only rpi3 testing left
2020-05-29 12:36:28 <ikke> ok
2020-05-29 12:37:23 <ncopa> then its just to do 3.12.0 i think
2020-05-29 12:37:52 <ikke> I'll be working on the release notes
2020-05-29 12:39:09 <ikke> tested virt as well
2020-05-29 12:41:14 <ncopa> great! thanks!
2020-05-29 12:45:01 <ikke> What are the noteworthy changes for this release?
2020-05-29 12:45:27 <ikke> Further deprecation of python2 I guess
2020-05-29 12:49:58 <ncopa> jenneron: sorry but we are a bit busy with making release now
2020-05-29 12:51:10 <jenneron> i realized what i was doing wrong
2020-05-29 12:51:19 <jenneron> thanks for reply
2020-05-29 12:53:26 <ncopa> ikke: not sure
2020-05-29 12:54:08 <ncopa> i guess initial support for mips64 is worth mentioning
2020-05-29 12:54:28 <ncopa> i was thinking of add a note sayin it will be the last release for armhf
2020-05-29 12:54:52 <ncopa> but given the response on the mailing list i think we should wait
2020-05-29 12:55:08 <ikke> jenneron: maybe care to share what you did wrong for our reference?
2020-05-29 12:59:10 <ikke> hmm, strange, git log --oneline v3.11.0.. --grep upgrade --format="%s" | sort -k1 -u hangs my container for quite a few minutes
2020-05-29 12:59:24 <ikke> ssh times out
2020-05-29 13:01:24 <Hello71> Cogitri: well it can be that according to upstream, you were supposed to use #include <server/whatever> the whole time
2020-05-29 13:01:31 <Hello71> or it could be a bug
2020-05-29 13:02:46 <Hello71> ikke: oom?
2020-05-29 13:03:49 <Hello71> what's wrong with armhf? not worth keeping along armv7? or is there some other reason
2020-05-29 13:04:02 <ikke> Hello71: less and less upstream support
2020-05-29 13:04:16 <ikke> so the maintenance burdon gets higher
2020-05-29 13:04:55 <Hello71> I guess that makes sense. doesn't debian still support armhf though?
2020-05-29 13:05:02 <Hello71> although they don't tend to upstream their patches :/
2020-05-29 13:05:12 <Hello71> they tend to not upstream their patches
2020-05-29 13:14:29 <mps> did I told that installing aarch64 in qemu installs efi boot fine and VM boot using grub
2020-05-29 13:14:35 <jenneron> ikke: it was my stupid mistace. i have never made merge requests before. i didn't fork repository, i just set remote to my own repository and i pushed it. sorry to bother
2020-05-29 13:16:47 <Hello71> I get the impression that these qemu tests could be automated...
2020-05-29 13:17:03 <Hello71> does alpine have any tests outside of gitlab ci?
2020-05-29 13:17:12 <Hello71> s/tests/automated &/
2020-05-29 13:17:12 <alpine-meetbot> Hello71 meant to say: does alpine have any automated & outside of gitlab ci?
2020-05-29 13:17:28 <Hello71> bad bot
2020-05-29 13:32:53 <ikke> Hello71: what kind of automated tests?
2020-05-29 13:33:14 <Hello71> I mean integration tests
2020-05-29 13:33:34 <Hello71> there is gitlab ci which basically runs make check
2020-05-29 13:33:40 <Hello71> but it doesn't test if the system boots
2020-05-29 13:33:44 <Hello71> afaik
2020-05-29 13:33:48 <ikke> Nothing automated
2020-05-29 13:33:51 <ikke> manual testing
2020-05-29 13:39:58 <ncopa> Hello71: i think debian dropped armv6 long time ago
2020-05-29 13:40:07 <ncopa> mps: good to know! thanks for testing that
2020-05-29 13:40:28 <Hello71> aren't we talking about armhf?
2020-05-29 13:40:34 <ncopa> we are
2020-05-29 13:40:48 <ncopa> our (alpine's) armhf = armv6
2020-05-29 13:41:11 <ncopa> we have armv7 which corresponds with debians armhf (i think)
2020-05-29 13:41:50 <ncopa> would be great to have automatted tests with qemu
2020-05-29 13:42:00 <ikke> yup
2020-05-29 13:42:03 <ncopa> not sure how though
2020-05-29 13:42:13 <ikke> maybe through serial?
2020-05-29 13:42:21 <ncopa> we could probably do it with expect and alpine-virt which has serial enabled
2020-05-29 13:42:55 <ncopa> or we'd need separate release image for testing with serial enabled
2020-05-29 13:44:10 <ncopa> ok. lets make this release. ikke: http://wiki.alpin.pw/releng/release-checklist.html
2020-05-29 13:44:44 <ikke> I can create an issue for this checklist?
2020-05-29 13:45:06 <ikke> still working on release notes
2020-05-29 13:45:36 <ikke> I'm strugling to find noteworthy updates
2020-05-29 13:45:52 <ncopa> typically language updates
2020-05-29 13:45:57 <ncopa> or databases
2020-05-29 13:46:00 <ncopa> like postgresql
2020-05-29 13:46:05 <ikke> Yes, I have that under significant updates
2020-05-29 13:46:09 <ncopa> which needs dump/restore for upgrades
2020-05-29 13:46:42 <ncopa> Cogitri, Leo: anything else that is noteworthy to mention in 3.12 release notes?
2020-05-29 13:47:01 <ncopa> ikke: i guess its ok its short
2020-05-29 13:49:20 <ikke> https://tpaste.us/EOl6
2020-05-29 13:50:30 <ncopa> Ariadne, Cogitri, Leo, mps: anything you think should be mentioned in release notes?
2020-05-29 13:51:16 <mps> ikke: nice, I'm mentioned in two lines :)
2020-05-29 13:51:39 <mps> ncopa: I think maxice8 have wiki with notes
2020-05-29 13:52:06 <mps> maybe note about ssh restart
2020-05-29 13:52:10 <ncopa> with details yes
2020-05-29 13:52:48 <mps> uh, let me look
2020-05-29 13:52:53 <maxice8> i have written what is important to me and i think others in the wiki notes
2020-05-29 13:52:58 <maxice8> i might have missed some stuff but the big stuff is there
2020-05-29 13:53:11 <ncopa> if sshd needs special treatment then we can mention it as noteworthy update
2020-05-29 13:53:54 <ncopa> ikke: can you help create 3.12.1 , move open issue to that (or 3.13.0)
2020-05-29 13:54:07 <ncopa> open issues*
2020-05-29 13:54:59 <mps> problem is I upgraded ssh on 3.11 already and can't now test will it need restart with latest version in 3.12
2020-05-29 13:55:15 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11591
2020-05-29 13:55:39 <Hello71> ncopa: ah, that's confusing.
2020-05-29 13:55:58 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/milestones/153
2020-05-29 13:56:03 <Hello71> I guess you already cannot run softfloat binaries as is on musl
2020-05-29 13:56:49 <Hello71> mps: I upgraded openssh from 3.11 to edge just a few days ago and couldn't log in
2020-05-29 13:57:06 <mps> ah, duplicity is moved t community, maybe this deserves note
2020-05-29 13:57:16 <Hello71> so unless for some reason there was some fix made in 3.12 and not edge, then this is almost certainly a problem in 3.12 too
2020-05-29 13:58:08 <mps> Hello71: yes, this is expected with openssh  8.2_p1
2020-05-29 13:58:28 <Hello71> right, I'm saying that I tested and it does affect alpine
2020-05-29 13:58:40 <mps> and we upgraded it to 8.3_p1 for 3.12, Wed May 27 18:39:06 2020 +0200
2020-05-29 13:58:50 <mps> 38a7d6eaa8cf893b162b57499774356c3df9cec6
2020-05-29 13:59:19 <mps> well, not a bad idea to add a note about this just in case
2020-05-29 14:00:36 <ikke> yes, will add it
2020-05-29 14:01:37 <ikke> https://tpaste.us/0PnN
2020-05-29 14:02:35 <Hello71> miscapitalized OpenSSH and also missing the 1 on p1
2020-05-29 14:03:00 <ikke> fixed
2020-05-29 14:03:36 <ncopa> zabbix misspelled
2020-05-29 14:04:03 <ikke> fixed
2020-05-29 14:04:32 <ikke> You said we should link to the release notes wiki/
2020-05-29 14:04:34 <ikke> ?
2020-05-29 14:04:39 <mps> add in uppercase 'for detailed chages READ GIT LOG' :)
2020-05-29 14:05:21 <mps> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.12.0
2020-05-29 14:05:42 <mps> cherry pick what you think is important
2020-05-29 14:06:24 <ikke> yes, I've been reading that already
2020-05-29 14:09:03 <ncopa> we could have a link to that page
2020-05-29 14:09:10 <Hello71> if we're nitpicking then Qemu should be QEMU, and Postgresql should be PostgreSQL
2020-05-29 14:09:39 <Hello71> also there are line breaks after some section headers and some not, but I think this will not be visible on the rendered page
2020-05-29 14:10:59 <ikke> fixed
2020-05-29 14:11:56 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues?milestone_title=3.12.0&scope=all&state=opened
2020-05-29 14:12:35 <ikke> Most I moved to 3.12.1, some I moved to 3.13
2020-05-29 14:14:21 <ncopa> great!
2020-05-29 14:15:11 <ncopa> please hold you commit for 3.12.0 now
2020-05-29 14:15:15 <ncopa> commits*
2020-05-29 14:15:39 <ikke> So, for master :)
2020-05-29 14:17:06 <PureTryOut[m]>  ncopa got a build log for https://git.alpinelinux.org/aports/commit/testing/py3-padatious?id=a44f73dca90322b87dd854aefe65e537e3801d1b?
2020-05-29 14:17:45 <ncopa> PureTryOut[m]: look in https://build.alpinelinux.org/buildlogs/
2020-05-29 14:18:08 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/py3-padatious/py3-padatious-0.4.8-r0.log
2020-05-29 14:18:16 <ncopa> ok, here 3.12.0 comes...
2020-05-29 14:18:55 <ikke> ncopa: I've pushed the post to master
2020-05-29 14:18:58 <PureTryOut[m]> Oh that is useful
2020-05-29 14:19:04 <PureTryOut[m]> Though that build log is completely useless...
2020-05-29 14:19:05 <PureTryOut[m]> Terminated by what?
2020-05-29 14:20:51 <ncopa> i guess i killed it
2020-05-29 14:20:55 <ncopa> i think it hanged
2020-05-29 14:22:39 <ikke> hmm, wwwtest is not updated
2020-05-29 14:24:47 <ikke> after the release is finished, I'm going to restart gitlab for the security upgrade
2020-05-29 14:28:40 <ncopa> um
2020-05-29 14:28:45 <ncopa> i think we have a problem
2020-05-29 14:28:53 <ikke> ok?
2020-05-29 14:28:55 <ncopa> s390x
2020-05-29 14:29:07 <ikke> What about it?
2020-05-29 14:29:31 <ncopa> build-3-12-s390x has been gone for 22 days
2020-05-29 14:29:36 <ncopa> 22620 buildoze 22d21 ./testrunner
2020-05-29 14:29:46 <ikke> oof
2020-05-29 14:29:59 <ikke> and we somehow did not notice
2020-05-29 14:30:17 <ncopa> yeah
2020-05-29 14:30:35 <ncopa> i just looked for 'idle' in the build list. i didnt verify each arch
2020-05-29 14:30:51 <mps> things which disappears tend to be unnoticeable
2020-05-29 14:31:26 <ikke> pdns failed
2020-05-29 14:31:43 <ncopa> i killed the test
2020-05-29 14:31:52 <ikke> ok
2020-05-29 14:34:24 <ncopa> the edge builder is ok though
2020-05-29 14:34:28 <ikke> oops, over 160 packages left to build
2020-05-29 14:34:38 <ncopa> so hopefully it will just work
2020-05-29 14:34:44 <ncopa> 22 days...
2020-05-29 14:34:53 <ncopa> 160 packages is only main
2020-05-29 14:34:58 <ikke> main and community
2020-05-29 14:35:03 <ncopa> ok. good
2020-05-29 14:35:09 <ncopa> thats not too bad
2020-05-29 14:35:16 <ncopa> and the builder is pretty fast too
2020-05-29 14:35:36 <ncopa> but it means that i cannot create docker image til its done
2020-05-29 14:35:49 <ncopa> nor sign the release
2020-05-29 14:46:03 <ncopa> ok, lets publish the release notes
2020-05-29 14:46:24 <ikke> ncopa: can I restart gitlab now?
2020-05-29 14:46:30 <ncopa> sure
2020-05-29 14:48:23 <ncopa> builder is moving along
2020-05-29 14:48:37 <ikke> yes, I'm tracking it
2020-05-29 14:48:40 <ikke> 30%
2020-05-29 14:50:37 <ikke> gitlab is up again
2020-05-29 14:53:03 <ncopa> good job!
2020-05-29 14:53:30 <ncopa> wwwtest does not pick up changes. i guess www wont do it either
2020-05-29 14:53:37 <ikke> yeah
2020-05-29 14:53:38 <ncopa> i guess the mqtt subject changed
2020-05-29 14:53:42 <ikke> heh
2020-05-29 14:54:06 <ncopa> where is wwwtest hosted howdays?
2020-05-29 14:54:36 <ikke> it's a cname for gitold apparently
2020-05-29 14:54:45 <ikke> git-old
2020-05-29 14:54:59 <ncopa> looks like its bld1
2020-05-29 14:55:01 <ncopa> im on it
2020-05-29 14:55:23 <ikke> ok
2020-05-29 14:59:59 <ncopa> https://wwwtest.alpinelinux.org/posts/Alpine-3.12.0-reloased.html
2020-05-29 15:00:09 <ncopa> still need to update the mqtt listener
2020-05-29 15:00:18 <ikke> ok
2020-05-29 15:00:22 <ncopa> do you know what it should subcribe to?
2020-05-29 15:03:34 <ikke> I think gitlab/alpine/infra/alpine-mksite
2020-05-29 15:08:50 <Cogitri> Should we link the wiki on that page too?
2020-05-29 15:08:55 <Cogitri> Since the wiki contains way more indo
2020-05-29 15:09:01 <Cogitri> s/indo/info/
2020-05-29 15:09:01 <alpine-meetbot> Cogitri meant to say: Since the wiki contains way more info
2020-05-29 15:10:25 <Cogitri> And maybe initial D support is worth a mention on the main page too
2020-05-29 15:16:13 <ncopa> Cogitri: thats good point
2020-05-29 15:19:19 <ikke> Cogitri: Could you go over that wiki? It has some unfinished sections
2020-05-29 15:24:53 <ncopa> im taking a walk
2020-05-29 15:24:55 <ncopa> i need a break
2020-05-29 15:25:11 <ncopa> i updated release notes on wwwtest.alpinelinux.org
2020-05-29 15:25:51 <ikke> You deserve a break :)
2020-05-29 15:25:54 <ikke> enjoy your walk
2020-05-29 15:35:28 <Cogitri> ikke: I can do that tomorrow, busy today
2020-05-29 15:35:41 <Cogitri> Maybe maxice8 can take a look before that?
2020-05-29 15:36:14 <maxice8> the bpf section ?
2020-05-29 15:49:52 <ikke> Yeah, that's the one I noticed
2020-05-29 15:50:15 <ikke> kamailio faield
2020-05-29 15:50:22 <ikke> on s390x
2020-05-29 15:50:34 <ikke> hmm, no mysql.h
2020-05-29 15:51:07 <ikke> hmm, but mariadb-dev is included
2020-05-29 15:52:06 <ikke> does it need to be #include <mysql/mysql.h>?
2020-05-29 15:52:19 <ikke> or even <mysql/server/mysql.h>
2020-05-29 15:55:12 <ikke> also fails to build in my dev container, so no s390x specific issue
2020-05-29 16:04:02 <ikke> Anyone knows why that is suddenly necessary?
2020-05-29 16:04:09 <ikke> I don't see that it has changes since 3.11 in mariadb
2020-05-29 16:28:19 <ikke> !8562
2020-05-29 16:31:14 <Ariadne> hi
2020-05-29 16:31:26 <ikke> hi
2020-05-29 16:31:29 <Ariadne> congrats to everyone on 3.12
2020-05-29 16:31:36 <ikke> It's not done yet :(
2020-05-29 16:31:46 <ikke> s390x builder was mia
2020-05-29 16:35:08 <oneinsect> rpi 8gb is out and so you have many builders now for aarch64
2020-05-29 16:35:35 <ikke> The hardware we use is a bit more specier than a 8gb rpi
2020-05-29 16:35:41 <ikke> spicier*
2020-05-29 16:35:51 <ikke> Ariadne: could you review that MR?
2020-05-29 16:35:57 <oneinsect> :-)
2020-05-29 16:36:02 <Ariadne> which MR
2020-05-29 16:36:08 <Ariadne> 8562 ?
2020-05-29 16:36:21 <ikke> yes
2020-05-29 16:36:39 <ikke> I basically have no clue why that is necessary
2020-05-29 16:37:07 <Ariadne> that's actually the way you're supposed to include mysql
2020-05-29 16:37:15 <Ariadne> kamailio was doing it wrong
2020-05-29 16:37:41 <ikke> yes. but why now?
2020-05-29 16:38:00 <ikke> It only failed on s390x which was behind
2020-05-29 16:38:06 <Ariadne> idk, maybe new mariadb dropped compatibility headers
2020-05-29 16:38:16 <ikke> I checked pkgs.a.o
2020-05-29 16:38:24 <ikke> doesn't seem to be any headers gone
2020-05-29 16:38:29 <Ariadne> weird
2020-05-29 16:41:42 <ikke> But you see no issue merging this?
2020-05-29 16:41:55 <ikke> I'm doubting whether I should bump pkgrel
2020-05-29 16:42:06 <ikke> ah, already done
2020-05-29 16:43:45 <ncopa> problem with mariadb is latest release did some changes in pkg-config that breaks various packages
2020-05-29 16:43:52 <ikke> ah ok
2020-05-29 16:44:05 <ncopa> need to work around it for now
2020-05-29 16:45:21 <Ariadne> ok
2020-05-29 16:45:32 <Ariadne> ncopa: are the builders already branched?
2020-05-29 16:45:38 <ncopa> yes
2020-05-29 16:45:42 <Ariadne> ok
2020-05-29 16:45:46 <ikke> ok, then we need to cherry-pick that commit
2020-05-29 16:45:48 <Ariadne> i'll backport it
2020-05-29 16:45:51 <ikke> thanks
2020-05-29 16:46:03 <ncopa> hang on a sec
2020-05-29 16:46:28 <Ariadne> hanging on
2020-05-29 16:47:13 <Ariadne> 
ACTION elevator music

2020-05-29 16:47:44 <ncopa> i think its better to append -I/usr/include/mysql to  CPPFLAGS
2020-05-29 16:47:55 <ikke> ah ok
2020-05-29 16:47:58 <ncopa> but its weird, why isnt it properly exposed in pkg-config
2020-05-29 16:48:09 <ncopa> or mysql_config --cflags
2020-05-29 16:48:23 <ncopa> i think the proper fix is to fix mariadb somehow
2020-05-29 16:48:37 <ncopa> but im not sure how
2020-05-29 16:48:48 <Ariadne> sure but right now this is blocking release so i think we should unblock release and then figure out mariadb
2020-05-29 16:49:00 <ncopa> need to it manually this case i think
2020-05-29 16:49:08 <ncopa> builder will checkout the git tag
2020-05-29 16:49:12 <ncopa> abuild build from there
2020-05-29 16:49:24 <ncopa> we shouldnt have tagged something that is not buildable
2020-05-29 16:51:48 <ncopa> i injected CPPFLAGS="$CPPFLAGS -I/usr/include/mysql"  and build asterisk
2020-05-29 16:53:13 <ikke> gdb, # include <sys/cdefs.h>
2020-05-29 16:53:16 <ikke> not found
2020-05-29 16:53:23 <ncopa> whatta
2020-05-29 16:54:08 <ncopa> where is the not found?
2020-05-29 16:54:14 <ikke> https://build.alpinelinux.org/buildlogs/build-3-12-s390x/main/gdb/gdb-9.2-r0.log
2020-05-29 16:54:21 <ikke> ./glob.h:25:11: fatal error: sys/cdefs.h: No such file or directory
2020-05-29 16:54:56 <ncopa> how is that possible
2020-05-29 16:55:04 <ncopa> it built on the other builders and it built on edge
2020-05-29 16:55:15 <ncopa> something else that was updated has triggered that
2020-05-29 16:59:12 <ikke> also pkg-config related?
2020-05-29 17:01:37 <Ariadne> not for sys/cdefs.h
2020-05-29 17:01:41 <ikke> ok
2020-05-29 17:02:08 <Ariadne> sys/cdefs.h is part of musl
2020-05-29 17:02:18 <ikke> right
2020-05-29 17:02:28 <Ariadne> or rather, its a POSIX header
2020-05-29 17:02:32 <Ariadne> musl does not provide it
2020-05-29 17:03:06 <Ariadne> whats weird is
2020-05-29 17:03:07 <Ariadne> checking for sys/cdefs.h... no
2020-05-29 17:03:31 <Ariadne> oh but gdb built this time
2020-05-29 17:04:05 <Ariadne> huh ?
2020-05-29 17:05:04 <Ariadne> i guess ncopa or somebody is intervening manually on s390x
2020-05-29 17:12:21 <ncopa> i am
2020-05-29 17:12:38 <ncopa> sys/cdefs.h is not posix iirc
2020-05-29 17:12:44 <ncopa> i think its in bsd-compat-headers
2020-05-29 17:12:55 <ncopa> not sure why gdb passed
2020-05-29 17:12:57 <Ariadne> i'm confused though
2020-05-29 17:13:11 <Ariadne> why is all of this stuff missing from 3-12-s390x
2020-05-29 17:13:20 <Ariadne> when we released RCs already
2020-05-29 17:13:50 <ncopa> the build-3-12-s390x had a package with a test that hanged
2020-05-29 17:13:59 <ncopa> was gone for 22 days
2020-05-29 17:14:08 <Ariadne> o
2020-05-29 17:14:12 <ncopa> nobody noticed that there was no _rc for s390x
2020-05-29 17:14:26 <ncopa> which makes me wonder why we even bother about s390x
2020-05-29 17:14:49 <ncopa> nobody seems to care about it anymore
2020-05-29 17:15:11 <Ariadne> apparently not even IBM
2020-05-29 17:15:21 <Ariadne> i think that should change for it to remain a supported port moving forward
2020-05-29 17:15:35 <ncopa> may be related to redhat thing
2020-05-29 17:15:51 <ncopa> they probably want their s390x users to buy redhat licenses
2020-05-29 17:16:28 <Ariadne> i'm considering buying an s390x machine at a surplus auction that keeps being pushed back due to covid
2020-05-29 17:17:12 <ncopa> i wonder if there are anyone using alpine on s390x for production
2020-05-29 17:17:52 <Ariadne> i doubt it, alpine kind of goes against the whole concept of s390x
2020-05-29 17:18:34 <ncopa> ok. i think im gonna make a trip to the store while its building
2020-05-29 17:18:37 <Ariadne> i've also noticed that IBM has kind of stepped back from maintaining POWER
2020-05-29 17:18:40 <Ariadne> but
2020-05-29 17:19:04 <Ariadne> i think we can keep power going steady
2020-05-29 17:19:10 <c705> s390x is an architecture?
2020-05-29 17:19:12 <Ariadne> i have some plans for expanding the power port, in fact
2020-05-29 17:19:14 <ncopa> yes
2020-05-29 17:19:18 <Ariadne> c705: yes, big mainframe
2020-05-29 17:19:24 <ncopa> s390x IBM Z
2020-05-29 17:19:29 <Ariadne> the kind you have to go pick up in a pickup truck
2020-05-29 17:19:36 <c705> ah, okay
2020-05-29 17:19:51 <ncopa> bbl
2020-05-29 17:28:53 <ncopa> ugh. pdns and mysql include
2020-05-29 17:34:58 <ikke> sigh
2020-05-29 17:39:49 <Ariadne> Usage: mariadb_config [OPTIONS]
2020-05-29 17:39:49 <Ariadne>   --cflags        [-I/usr//usr/include/mysql -I/usr//usr/include/mysql/mysql]
2020-05-29 17:39:49 <Ariadne>   --include       [-I/usr//usr/include/mysql -I/usr//usr/include/mysql/mysql]
2020-05-29 17:39:58 <Ariadne> i suspect this is wrong :)
2020-05-29 17:40:14 <Ariadne>  pkgconf --cflags mariadb
2020-05-29 17:40:14 <Ariadne> -I/usr/include/mysql
2020-05-29 17:42:10 <Ariadne> ok
2020-05-29 17:42:11 <Ariadne> figured it out
2020-05-29 17:42:18 <Ariadne> its mariadb-connector-c
2020-05-29 17:42:25 <Ariadne> -DCMAKE_INSTALL_PREFIX=/usr \
2020-05-29 17:42:32 <Ariadne> -DINSTALL_INCLUDEDIR=/usr/include/mysql \
2020-05-29 17:42:53 <Ariadne> these are relative to CMAKE_INSTALL_PREFIX
2020-05-29 17:43:06 <ikke> aha
2020-05-29 17:43:13 <ikke> so the latter should be just mysql
2020-05-29 17:43:21 <ikke> or include/mysql
2020-05-29 17:43:58 <Ariadne> yeah, i'm checking it now
2020-05-29 17:44:02 <Ariadne> but i am pretty sure this will fix it
2020-05-29 17:53:14 <Ariadne> Usage: mysql_config [OPTIONS]
2020-05-29 17:53:14 <Ariadne>   --include       [-I/usr/include/mysql -I/usr/include/mysql/mysql]
2020-05-29 17:53:14 <Ariadne>   --cflags        [-I/usr/include/mysql -I/usr/include/mysql/mysql]
2020-05-29 17:53:19 <ikke> looks better
2020-05-29 17:53:26 <Ariadne> petrie:~/aports/main/mariadb-connector-c$ ls /usr/include/mysql/mysql.h
2020-05-29 17:53:26 <Ariadne> /usr/include/mysql/mysql.h
2020-05-29 17:53:55 <Ariadne> petrie:~/aports/main/mariadb-connector-c$ ls /usr/lib/libmariadb.so
2020-05-29 17:53:55 <Ariadne> /usr/lib/libmariadb.so
2020-05-29 17:56:15 <Ariadne> need to backport this to 3.12-stable
2020-05-29 17:58:00 <Ariadne> ncopa: build-3-12-s390x is MIA again
2020-05-29 18:00:46 <ikke> hmm, mqtt-exec is not listed
2020-05-29 18:00:56 <ikke> it stopped
2020-05-29 18:00:57 <Ariadne> i guess fire it up
2020-05-29 18:01:04 <Ariadne> thats the mariadb fix
2020-05-29 18:01:25 <ikke> done
2020-05-29 18:09:32 <Ariadne> something something fuck cmake
2020-05-29 18:14:44 <ncopa> im on it
2020-05-29 18:15:18 <ncopa> i stopped mqtt-exec.aports-build while manually building pdns
2020-05-29 18:15:51 <ncopa> ugh. 2 packages = 2%
2020-05-29 18:16:00 <ncopa> means there are 100 packages to go
2020-05-29 18:17:33 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.12.0-released.html
2020-05-29 18:18:08 <Ariadne> yes
2020-05-29 18:18:27 <ncopa> good. thanks
2020-05-29 18:18:31 <c705> well, the text looks a bit funny
2020-05-29 18:18:52 <c705> the headers pecifically, but i'm not sure if that's just an artifact of the test page
2020-05-29 18:19:09 <c705> and i mean the formatting, the content looks OK
2020-05-29 18:19:10 <Ariadne> wow
2020-05-29 18:19:18 <Ariadne> i committed more than ncopa
2020-05-29 18:19:27 <maxice8> nice
2020-05-29 18:19:44 <ncopa> Leo is the major committer nowdays :)
2020-05-29 18:19:52 <Ariadne> Leo committed the most, but i suspect most of his are just abump
2020-05-29 18:19:55 <Ariadne> :P
2020-05-29 18:19:59 <ncopa> I mean maxice8
2020-05-29 18:20:12 <ncopa> yeah, thats how I used to be on top before
2020-05-29 18:20:12 <maxice8> yes but the major idea of aports is abump :P
2020-05-29 18:20:29 <Ariadne> anywho
2020-05-29 18:20:36 <ncopa> now i have to take care of all the tricky packages
2020-05-29 18:20:37 <Ariadne> that mariadb issue was stupid
2020-05-29 18:20:45 <ncopa> did you find the problem?
2020-05-29 18:20:50 <Ariadne> yeah
2020-05-29 18:20:58 <Ariadne> fixed and backported already :)
2020-05-29 18:21:05 <ncopa> thank you!
2020-05-29 18:21:31 <Ariadne> https://git.alpinelinux.org/aports/commit/?id=a1a915c3327e78203a76f05cd1c88a93e7ab0ee1
2020-05-29 18:22:04 <Ariadne> basically cmake sucks
2020-05-29 18:22:05 <Ariadne> :)
2020-05-29 18:22:09 <hjaekel> doesn't this mariadb issue show that it would be safer to rebuild all depending packages even if there are no ABI changes?
2020-05-29 18:22:56 <Ariadne> not really
2020-05-29 18:23:06 <hjaekel> the issue that Ariadne fixed was already fixed in the previous versions, but the patch was removed
2020-05-29 18:23:08 <ncopa> looks like we had a patch for it that got removed in 5173f8ea2ef97d88f898267b38ea59cd02ea0354
2020-05-29 18:23:33 <Ariadne> oh look
2020-05-29 18:23:35 <Ariadne> its maxice8
2020-05-29 18:23:43 <Ariadne> :p
2020-05-29 18:24:03 <Ariadne> anyway the patch was unnecessary
2020-05-29 18:24:04 <ncopa> i generally dont care much who did it
2020-05-29 18:24:15 <Ariadne> we were providing the wrong input to cmake to begin with
2020-05-29 18:24:19 <Ariadne> the patch was actually bad
2020-05-29 18:24:31 <ncopa> im glad it got fixed properly
2020-05-29 18:24:45 <ncopa> that is what i care about
2020-05-29 18:24:54 <hjaekel> Ariadne, why do you think "not really"?
2020-05-29 18:24:58 <Ariadne> hjaekel: i don't think it is realistic to bump packages every time a dependency is changed.  this will result in a lot of update churn
2020-05-29 18:25:19 <Ariadne> instead, a better approach, which i am working on automating already, is to rebuild the entire archive every so often as a test run
2020-05-29 18:25:26 <hjaekel> right, but we would avoid such issues that are also painful
2020-05-29 18:25:42 <ncopa> hjaekel: its safer to rebuild it all, but not realistic
2020-05-29 18:26:07 <ncopa> rebuilding it all always is more painful
2020-05-29 18:26:11 <Ariadne> we would, but the cost-benefit analysis is unrealistic.  weekly rebuild of the entire archive in a sandbox gets the same results without the update churn
2020-05-29 18:26:17 <hjaekel> it would be very helpful if you know from which change the issue comes
2020-05-29 18:26:36 <hjaekel> if you rebuild every week, there are hundreds of changes
2020-05-29 18:26:49 <Ariadne> it can be deduced if necessary
2020-05-29 18:27:00 <Ariadne> it took me 5 minutes to figure out the mariadb issue once i started digging
2020-05-29 18:27:16 <ncopa> i agree with Ariadne, re cost-benefit
2020-05-29 18:27:54 <ncopa> i looked at it earlier but was stupid to look at mariadb-dev rather than the separate client lib package
2020-05-29 18:28:16 <Ariadne> in my case, i did
2020-05-29 18:28:22 <Ariadne> apk add cmd:mysql_config
2020-05-29 18:29:33 <Ariadne> then i did mysql_config --cflags
2020-05-29 18:29:38 <Ariadne> and saw they were completely screwed
2020-05-29 18:29:49 <Ariadne> thats how i knew it came from mariadb-connector-c-dev
2020-05-29 18:29:50 <Ariadne> :)
2020-05-29 18:30:58 <ncopa> this: /usr/include/postgresql/server/utils/pg_locale.h:19:10: fatal error: unicode/ucol.h: No such file or directory
2020-05-29 18:31:14 <ncopa> means postgresql-dev is missing a depends=icu-dev
2020-05-29 18:31:48 <hjaekel> If a rebuild is not realistic, then maybe a proper review process of the merge requests should be established, so that one person is creating the MR and another person has to approve
2020-05-29 18:33:30 <ncopa> i manually fixed postgresl-orafce
2020-05-29 18:34:19 <ncopa> ideally the maintainer should give an ACK before merge
2020-05-29 18:37:36 <Ariadne> hjaekel: not realistic
2020-05-29 18:37:51 <hjaekel> that MR was open for 15 minutes, so no chance for anyone to ACK
2020-05-29 18:38:02 <Ariadne> which MR?
2020-05-29 18:38:14 <hjaekel> !8421
2020-05-29 18:38:42 <Ariadne> hmm, self-merge, naughty :p
2020-05-29 18:38:57 <Ariadne> hjaekel: in this case, this is what check() is for
2020-05-29 18:39:17 <Ariadne> there should be a test added to ensure that mysql_config --cflags returns the right data
2020-05-29 18:39:42 <Ariadne> instead of nitpicking,maybe you can work on adding a check() to the APKBUILD
2020-05-29 18:40:10 <Ariadne> if that does not interest you, please stop beating a dead horse, thanks
2020-05-29 18:40:18 <hjaekel> do we have tests that check pkg_config?
2020-05-29 18:40:33 <Ariadne> we don't, but they would be welcome
2020-05-29 18:40:48 <Ariadne> pkgconf --validate will catch some things that don't make sense
2020-05-29 18:40:54 <Ariadne> i intend to add additional validations
2020-05-29 18:41:08 <Ariadne> perhaps check to make sure -I flags point to paths that actually exist
2020-05-29 18:41:14 <Ariadne> but the .pc file in this case was fine
2020-05-29 18:41:20 <Ariadne> the problem was mysql_config.
2020-05-29 18:41:44 <hjaekel> I am not nitpicking, what I want to say is that we are not under time pressure, we are creating open source
2020-05-29 18:42:01 <hjaekel> so it's not necessary that every MR is merged within minutes
2020-05-29 18:42:13 <Ariadne> while alpine is open source, there are many people who are paid to work on it
2020-05-29 18:42:32 <Ariadne> and alpine flowing at a reasonable pace is critical to those people continuing to be employed
2020-05-29 18:42:39 <hjaekel> we can wait until we find someone to reveiw a MR
2020-05-29 18:43:02 <Ariadne> anyway, you can be part of the solution instead of complain
2020-05-29 18:43:08 <Ariadne> that is my suggestion
2020-05-29 18:44:04 <Ariadne> i agree that a 15 minute delay on a self-merge is not a good look, but then again, i don't open MRs when making tactical engineering operations
2020-05-29 18:44:30 <Ariadne> however, i do my best to make sure what i push does not break the package, and i ask maintainers if i am unsure
2020-05-29 18:44:54 <hjaekel> I definitively want to be part of the solution, and I'm not complaining, I'm also making suggestions
2020-05-29 18:45:18 <hjaekel> the difference is that your suggestions are more on the technical level, where i am suggesting process changes
2020-05-29 18:45:32 <Ariadne> the process needs to stay basically as it is
2020-05-29 18:45:55 <Ariadne> we do not live in a perfect world, unfortunately
2020-05-29 18:46:56 <hjaekel> That's true, but that does not mean that everything has to stay as it is... everything can be changed
2020-05-29 18:47:16 <Ariadne> ok, let me put it more bluntly
2020-05-29 18:48:03 <Ariadne> the companies which sponsor alpine development cannot afford for the developers they sponsor to be delayed by red tape
2020-05-29 18:48:24 <Ariadne> therefore, any process change that exists solely to introduce red tape, is unlikely to be adopted
2020-05-29 18:49:13 <Ariadne> maxice8 made a mistake, but we have fixed that mistake.  there are processes in development to improve QA to catch these mistakes earlier.
2020-05-29 18:49:33 <Ariadne> i'm not going to continue arguing with you, at this point its just concern trolling
2020-05-29 18:51:58 <ikke> Anybody looking at postgres?
2020-05-29 18:53:58 <Ariadne> yes
2020-05-29 18:54:12 <ikke> ok
2020-05-29 18:55:06 <Ariadne> this is because postgresql now depends on icu-dev, but postgresql-dev does not reflect it
2020-05-29 19:26:24 <ikke> Hmm, mu is missing emacs, but it should have been built
2020-05-29 19:26:40 <oneinsect> Ariadne was a Cretan princess in Greek mythology
2020-05-29 19:27:05 <Ariadne> emacs is blocked by librsvg
2020-05-29 19:27:29 <ikke> ah, I see
2020-05-29 19:27:51 <Ariadne> almost done with this intervention i hope
2020-05-29 19:28:01 <ikke> I hope too
2020-05-29 19:28:51 <ikke> building postgres now
2020-05-29 19:29:33 <Ariadne> yeah it had not blown up on orafce yet
2020-05-29 19:29:44 <Ariadne> oneinsect: yes, that is true
2020-05-29 19:30:45 <oneinsect> :P i know you all busy but just some rant in-between as i wait to buy a new builder for alpine
2020-05-29 19:30:58 <Ariadne> i'm not sure that is a rant
2020-05-29 19:31:00 <Ariadne> but ok
2020-05-29 19:31:58 <Ariadne> ok looks like we're all green except for s390x
2020-05-29 19:33:45 <oneinsect> but then i heard AMD 3990x compiles linux kernel in 20 seconds, just a suggestion, we get those stuff alpine builders, i dont know the current infra though
2020-05-29 19:34:02 <oneinsect> should get*
2020-05-29 19:34:11 <oneinsect> for alpine*
2020-05-29 19:34:14 <ikke> We get sponsored hardware that is quite beefy
2020-05-29 19:34:17 <Ariadne> for x86, we have a threadripper already
2020-05-29 19:34:22 <Ariadne> i think it is even 3990x
2020-05-29 19:34:29 <oneinsect> oooh nice!!! i didnt know that
2020-05-29 19:35:09 <ikke> oneinsect: Getting hardware is only one part of the picture, it needs to be hosted somewhere as well
2020-05-29 19:39:05 <oneinsect> yeaa
2020-05-29 19:39:13 <oneinsect> agreed
2020-05-29 19:39:26 <ikke> Ariadne: everything is idle now
2020-05-29 19:39:29 <ikke> ncopa: ^
2020-05-29 19:40:25 <Ariadne> i'm not sure how to proceed
2020-05-29 19:40:33 <Ariadne> maybe we should retag v3.12
2020-05-29 19:40:50 <Ariadne> that would be my suggestion
2020-05-29 19:40:55 <Ariadne> we haven't actually "released" yet
2020-05-29 19:41:19 <ikke> Hard to retag though if people already fetched the tag
2020-05-29 19:41:45 <Ariadne> humm no
2020-05-29 19:41:52 <Ariadne> git will pick it up as a forced update
2020-05-29 19:41:59 <ikke> not for tags
2020-05-29 19:42:05 <Ariadne> oh that's annoying
2020-05-29 19:42:28 <Ariadne> maybe trigger a build manually on the s390x host
2020-05-29 19:42:35 <Ariadne> to generate the release
2020-05-29 19:44:22 <ncopa> im triggering the release yes
2020-05-29 19:44:34 <ikke> ssh is corrupt
2020-05-29 19:44:38 <ikke> need to fix it
2020-05-29 19:45:11 <ikke> fixed
2020-05-29 19:45:17 <ncopa> i fixed it
2020-05-29 19:45:22 <ikke> we both did :)
2020-05-29 19:45:24 <ncopa> mu will be a problem
2020-05-29 19:46:54 <ncopa> i manually edited community/mu to it passes the build
2020-05-29 19:47:12 <Ariadne> oh i fixed it
2020-05-29 19:47:15 <Ariadne> in git :p
2020-05-29 19:47:46 <ncopa> yes but it will checkout the tag when it builds the release
2020-05-29 19:48:12 <ncopa> maybe i should have commented that out in the script instead
2020-05-29 19:48:38 <ncopa> and build it from 3.12-stable HEAD
2020-05-29 19:48:46 <ikke> What part of building the release would that cause issues for?
2020-05-29 19:49:10 <ncopa> it will retry build community/mu
2020-05-29 19:49:18 <ncopa> which wont work due to missing emacs
2020-05-29 19:49:18 <ikke> ah ok
2020-05-29 19:49:28 <ncopa> but for some reason we had emacs earlier
2020-05-29 19:49:45 <ikke> edge still has emacs
2020-05-29 19:49:56 <ncopa> during 3.12 build. not sure why its gone from 3.12?
2020-05-29 19:50:30 <Ariadne> emacs is blocked by librsvg
2020-05-29 19:50:33 <Ariadne> on s390x
2020-05-29 19:50:40 <Ariadne> or is librsvg now on s390x
2020-05-29 19:50:42 <ncopa> but at some point it built
2020-05-29 19:50:55 <ikke> it was disabled in october
2020-05-29 19:51:15 <ncopa> maybe the emacs dependency was added recently?
2020-05-29 19:51:33 <ikke> but strange that I still see emacs on the mirrors
2020-05-29 19:51:41 <ikke> https://pkgs.alpinelinux.org/package/edge/community/s390x/emacs
2020-05-29 19:52:00 <ikke> probably because disabling it does not remove it
2020-05-29 19:52:18 <ncopa> something pulled in librsvg dependency after it was built
2020-05-29 19:52:45 <ikke> mu was moved from testing
2020-05-29 19:52:50 <ikke> 4 days ago
2020-05-29 19:55:14 <ncopa> \o/ 3.12.0 release was uploaded
2020-05-29 19:55:27 <ikke> yaay
2020-05-29 19:57:43 <[[sroracle]]> congrats
2020-05-29 19:59:48 <Ariadne> right
2020-05-29 20:15:43 <c705> congratulations
2020-05-29 20:20:38 <Ariadne> we're not done yet
2020-05-29 20:52:19 <ncopa> and finally we got the web page updated and the annouce email sent
2020-05-29 20:52:28 <ncopa> never do release on fridays they said
2020-05-29 20:52:51 <c705> and _now_ congratulations!
2020-05-29 20:53:27 <c705> yeah, it's late for you folks in cet?
2020-05-29 20:53:36 <mps> ncopa: and, repeat this sentence on every release :)
2020-05-29 20:54:35 <mps> I missed party because I was on real party, so even don't need to open bottle of wine now :)
2020-05-29 20:56:26 <ncopa> its late
2020-05-29 21:26:21 <omni> congratulations!
2020-05-29 21:27:46 <omni> good job everyone!
2020-05-30 06:56:39 <clandmeter> hah, ncopa still didnt learn not to release on fridays :)
2020-05-30 06:58:40 <mps> hehe, yes. but he learned to say 'never do release on fridays they said' everytime when he make release :)
2020-05-30 07:00:50 <ikke> Updated https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases as well
2020-05-30 07:02:25 <Cogitri> 👍
2020-05-30 07:58:29 <ikke> Ariadne: the fix for mysql fixed an issue I had with zabbix as well :)
2020-05-30 08:11:00 <mps> https://www.reddit.com/r/linux/comments/gt16a2/alpine_linux_3120_released/
2020-05-30 08:11:01 <alpine-meetbot> [REDDIT] Alpine Linux 3.12.0 released (https://alpinelinux.org/posts/Alpine-3.12.0-released.html) to r/linux | 64 points (87.0%) | 34 comments | Posted by LeoFromAlpineLinux | Created at 2020-05-29 - 20:58:15UTC
2020-05-30 08:12:52 <mps> it says 34 comments but I see just 4
2020-05-30 08:13:39 <mps> hmm, now i see all
2020-05-30 08:17:43 <ikke> Cogitri: You were just on commit off 1000 commits :)
2020-05-30 08:17:47 <ikke> just one*
2020-05-30 08:21:56 <mps> rotate screen 180 degrees and read that number :)
2020-05-30 08:23:44 <mps> though I dislike these number of commits in release notes, they means nothing
2020-05-30 08:24:20 <ikke> Ncopa already moved away from listing them in order of commits
2020-05-30 08:25:54 <mps> anyway, this gives false perception
2020-05-30 08:28:31 <mps> nothing personal (I'm somewhere in the middle) but some people which deserves a big credits are 'low' in these numbers
2020-05-30 08:35:47 <maxice8> I have been thinking about bots to give info about merge requests
2020-05-30 08:36:42 <maxice8> on the top of my head, one bot that shows abi-laboratory information
2020-05-30 09:18:28 <nmeum> a gitlab bot which assigns MRs to the maintainer(s) of affected aports would also be neat
2020-05-30 09:18:43 <maxice8> ncopa is gonna get flooded
2020-05-30 09:19:32 <nmeum> indeed but maybe that would open up an oppertunity to move maintainership of some aports to other people
2020-05-30 09:19:55 <maxice8> big maybe
2020-05-30 09:22:26 <hjaekel> maybe assigning the maintainer is too much, but informing the maintainer would be nice
2020-05-30 09:22:49 <maxice8> That has barely any change, both will ping maintainer
2020-05-30 09:23:04 <mps> yes, good ideas
2020-05-30 09:23:32 <maxice8> If we're gonna do that then do a maintainer purge before
2020-05-30 09:25:03 <mps> also this
2020-05-30 09:25:31 <mps> better to not have maintainer than inactive/retired
2020-05-30 09:25:47 <Cogitri> ikke: OOOF
2020-05-30 09:25:54 <Cogitri> So close yet so far :D
2020-05-30 09:26:06 <ikke> hehe
2020-05-30 09:27:35 <PureTryOut[m]> You should've done empty one just for the hell of it lol
2020-05-30 09:36:28 <maxice8> hey everyone
2020-05-30 09:36:33 <maxice8> i'm gonna update poppler to 0.89.0
2020-05-30 09:36:38 <maxice8> that includes a libreoffice rebuild
2020-05-30 09:37:00 <maxice8> when can i merge it for least disruption ?
2020-05-30 09:50:54 <mps> maxice8: builders don't look busy
2020-05-30 09:51:08 <maxice8> They are building stuff atm
2020-05-30 09:51:18 <maxice8> specifically my x265 update
2020-05-30 09:51:27 <mps> some, and not big ones
2020-05-30 09:51:38 <mps> except maybe ffmpeg
2020-05-30 09:52:26 <mps> but I don't see reason that you have to wait too much
2020-05-30 09:53:08 <Cogitri> PureTryOut[m]: Yeah, didn't notice I got that many commits ^°
2020-05-30 10:26:34 <dne> 
ACTION notes that the most recent commit on 3.11-stable (merged on the 28th) hasn't turned up in the apk repos yet

2020-05-30 10:35:01 <maxice8> !6609 can someone that uses look at ?
2020-05-30 10:35:07 <maxice8> that uses mariadb*
2020-05-30 10:48:27 <afontain_> I've got a question about licensing. I've got a piece of software with a visibly permissive license, but it's not in the spdx licenses list https://github.com/poljar/matrix-nio/blob/master/LICENSE.md
2020-05-30 10:49:37 <afontain_> I guess it is suitable for inclusion if I make sure the license is included in the -doc subpackage, but I'm not sure
2020-05-30 10:51:27 <maxice8> Isn't that the ISC license ?
2020-05-30 10:52:19 <maxice8> almost sure that is the ISC license
2020-05-30 10:52:27 <maxice8> https://spdx.org/licenses/ISC.html
2020-05-30 11:01:03 <maxice8> here comes poppler
2020-05-30 11:15:03 <afontain_> Ah, yes
2020-05-30 11:16:17 <ikke> dne: which package is that?
2020-05-30 11:16:26 <dne> xen*
2020-05-30 12:52:33 <maxice8> @ikke what is with pkgs.a.o not showing stuff ?
2020-05-30 12:53:17 <ikke> You mean for 3.12?
2020-05-30 12:53:33 <ikke> It's still syncing
2020-05-30 12:55:33 <maxice8> yes
2020-05-30 12:55:33 <maxice8> ty
2020-05-30 13:06:24 <maxice8> !8587
2020-05-30 13:06:27 <maxice8> first 3.12 MR :D
2020-05-30 13:35:08 <nmeum> I am currently trying to get rid of the last few aports which use python2 as a run-time dependency
2020-05-30 13:35:22 <nmeum> currently working on lizardfs, will probably also remove testing/getmail and upgrade kodi
2020-05-30 13:35:46 <mps> hah, haproxy finally got linux-musl target
2020-05-30 13:37:32 <nmeum> maxice8: re mariadb I would just go aheand and merge that later, or is there a reason for a more in-depth review?
2020-05-30 14:05:10 <maxice8> i have no clue
2020-05-30 14:05:30 <ikke> mps: out of curiosity, does targetting linux-musl for haproxy improve anything?
2020-05-30 14:05:57 <Ariadne> probably means we dont have ot patch it
2020-05-30 14:06:05 <ikke> No patches were removed
2020-05-30 14:06:15 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8589/diffs
2020-05-30 14:06:28 <Ariadne> probably cosmetic then
2020-05-30 14:06:28 <ikke> but perhaps for the future
2020-05-30 14:06:31 <ikke> yeah
2020-05-30 14:08:47 <mps> we didn't had patches for haproxy
2020-05-30 14:11:21 <mps> last time when I made it to build on alpine (da59b854cdbdcb8d64bbb1a5115a3817de90d84e)  I made TARGET=linux-glibc instead of TARGET=linux2628 to be able to build
2020-05-30 14:11:36 <ikke> aha ok
2020-05-30 14:11:40 <mps> but no patches are added/removed
2020-05-30 14:21:23 <ikke> I wonder what actionable thing we need to do for #6933. Just enabling it by default does not seem like a good solution to me
2020-05-30 14:24:17 <Cogitri> Hm, but I'd argue almost no one wants to disable that
2020-05-30 14:24:23 <Cogitri> And other distros do the same thing
2020-05-30 14:24:37 <Cogitri> So personally I'd opt for enabling it if the terminal supports the colours
2020-05-30 14:24:51 <maxice8> always enabled
2020-05-30 14:32:11 <mps> +1
2020-05-30 14:39:25 <ikke> yay, lots of read again
2020-05-30 14:47:35 <nmeum> urgs
2020-05-30 14:52:00 <ikke> its fixed already
2020-05-30 14:59:08 <nmeum> puh, this lizardfs aport really is a mess
2020-05-30 15:08:53 <ikke> what requires it?
2020-05-30 15:09:04 <nmeum> nothing I think
2020-05-30 15:09:20 <nmeum> it builds fine now without python3 but it doesn't have a maintainer
2020-05-30 15:09:28 <nmeum> I upgraded it to git head which includes python3 support
2020-05-30 15:10:07 <nmeum> !8591
2020-05-30 15:10:18 <ikke> Yes, I saw it
2020-05-30 15:11:02 <nmeum> I do not use it and it doesn't have any tests so not sure how well it works
2020-05-30 15:11:31 <ikke> Maybe we should move it to unmaintained?
2020-05-30 15:11:36 <nmeum> I would be all for that
2020-05-30 15:12:39 <nmeum> should I just do that instead?
2020-05-30 15:12:47 <ikke> You have my support :)
2020-05-30 15:12:52 <nmeum> I will just do it then
2020-05-30 15:23:43 <nmeum> done
2020-05-30 15:23:58 <nmeum> ikke: while you are here, do you have any opinion on removing testing/getmail as well?
2020-05-30 15:24:18 <ikke> I commented on your MR
2020-05-30 15:24:18 <nmeum> ah, you already suggested moving it to unmaintained
2020-05-30 15:24:33 <nmeum> that would work as well
2020-05-30 15:24:37 <ikke> Then it's easier to move back once py3 support is there
2020-05-30 15:24:43 <nmeum> ok
2020-05-30 15:26:56 <nmeum> done
2020-05-30 15:26:57 <nmeum> ok
2020-05-30 15:27:10 <nmeum> if I am not mistaken the only package left with a python2 run-time dependency is community/kodi
2020-05-30 15:27:15 <artok> hehe
2020-05-30 15:27:36 <nmeum> latest kodi release has support for python3 so upgrading it should solve that
2020-05-30 15:34:59 <nmeum> there are only nightly builds of kodi 19 but it hasn't been offically released yet so I guess we will have to wait for that to happen
2020-05-30 16:13:05 <detha> <Cogitri> Hm, but I'd argue almost no one wants to disable that
2020-05-30 16:13:17 <detha> _almost_ no one indeed
2020-05-30 16:49:07 <nmeum> is it just me or is ldd behaving a bit strange?
2020-05-30 16:49:08 <nmeum> > cc -o hello-world hello-world.c -static && ldd ./hello-world
2020-05-30 16:49:14 <nmeum> > Adran/lib/ld-musl-x86_64.so.1 (0x7f4725d88000)
2020-05-30 16:49:38 <nmeum> the tab character caused a tab completation ':)
2020-05-30 16:49:45 <dalias> ?
2020-05-30 16:50:30 <nmeum> with a static binary I would assume that it doesn't link against ld-musl-*.so is that assumption incorrect?
2020-05-30 16:51:20 <dalias> it's correct. the incorrect assumption is that ldd is giving you meaningful information there
2020-05-30 16:53:20 <nmeum> well…I assumed that ldd doesn't output anything for static binaries. iirc that's what it did previously
2020-05-30 16:53:26 <dalias> run file (if it's sufficiently new) or readelf
2020-05-30 16:53:34 <dalias> ldd will error out for non-pie static binaries
2020-05-30 16:53:46 <dalias> for static pie i don't think it knows how to tell that they're not something it can operate on
2020-05-30 16:53:55 <nmeum> file has the same problem iirc
2020-05-30 16:54:03 <dalias> modern file is fixed
2020-05-30 16:54:16 <dalias> but not sure if alpine has upgraded yet
2020-05-30 16:54:32 <dalias> readelf is your most reliable answer
2020-05-30 16:55:38 <nmeum> alright
2020-05-30 18:08:31 <nmeum> Ariadne: how would you like to proceed with the go mips64 problem? given that 3.12 is released I would like to upgrade go to 1.14 at some point
2020-05-30 18:21:45 <Ariadne> we are still investigating it.  should have a solution soon
2020-05-30 18:22:56 <Ariadne> we have observed on mips64 that go binaries are unstable
2020-05-30 18:30:30 <maxice8> Good luck
2020-05-30 20:46:06 <ikke> maxice8: fyi, v3.12 is fully synced now
2020-05-30 21:06:35 <artok> so it's time to refresh my sysroots
2020-05-30 21:07:55 <artok> oh
2020-05-30 21:08:01 <artok> do we have docker image up
2020-05-30 21:08:47 <artok> yes we do
2020-05-30 21:39:24 <Cogitri> Can we maybe disable the s390x CI runner for now when it fails all the time anyway?
2020-05-30 21:39:45 <Cogitri> It's a bit annoying when all pipelines are red and I'm getting an email for every MR I open how CI is failing
2020-05-30 21:44:56 <mps> this !8594 MR doesn't have build() function. is that ok?
2020-05-30 21:50:23 <Cogitri> No build () is fine when nothing is built (and the makefile only installs things)
2020-05-30 21:51:51 <mps> in this MR it actually build from C source
2020-05-30 21:52:07 <mps> and README says 'make' 'make install'
2020-05-30 21:52:49 <Cogitri> Then make should be called in build
2020-05-30 21:54:11 <mps> I commented that in MR, thanks
2020-05-30 21:55:40 <Cogitri> 👍
2020-05-31 03:41:13 <Adran> nmeum: glad to know i'm part of musl now
2020-05-31 03:41:15 <Adran> :P
2020-05-31 06:36:02 <ikke> heh
2020-05-31 08:53:25 <mps> how to name 'quota' pkg, simply quota or quota-tools or linux-quota, disk-quota ...
2020-05-31 08:53:42 <ikke> how does upstream call it?
2020-05-31 08:54:36 <mps> https://sourceforge.net/projects/linuxquota/files/quota-tools/4.05/
2020-05-31 08:55:23 <mps> tarball is simply 'quota-$ver.tar.gz'
2020-05-31 08:55:40 <ikke> I guess if it does not clash, I would just call it quota then
2020-05-31 08:55:57 <ikke> preference is upstream name
2020-05-31 08:56:42 <mps> Arch linux call it quota-tools, while void just quota
2020-05-31 08:57:24 <ikke> https://repology.org/project/quota/versions
2020-05-31 08:57:47 <mps> debian quotatool and quota
2020-05-31 08:57:57 <mps> ah, thanks
2020-05-31 08:58:23 <ikke> Most call it quota, just a few outliers
2020-05-31 08:58:50 <ikke> 18 times quota, 3 times quota-tools
2020-05-31 08:58:52 <ikke> https://repology.org/project/quota/information
2020-05-31 08:59:22 <ikke> repology is a nice site for this kind of info
2020-05-31 09:00:09 <mps> yes, except it can be sometimes misleading :)
2020-05-31 09:00:34 <ikke> sure
2020-05-31 09:01:39 <ikke> I do send updates / fixes from time to time
2020-05-31 09:03:02 <mps> hmm, reading unpacked files to me quota-tools looks best name
2020-05-31 09:03:41 <ikke> hmm
2020-05-31 09:04:05 <mps> and announces for example 'Quota tools 4.04 released'
2020-05-31 09:04:41 <ikke> the project is called linuxquota on sourceforge
2020-05-31 09:04:56 <ikke> https://sourceforge.net/projects/linuxquota/
2020-05-31 09:04:58 <mps> and this 'quota-tools-4.05-README.txt'
2020-05-31 09:06:02 <mps> and Changelog 'Changes in quota-tools from 4.04 to 4.05'
2020-05-31 09:07:09 <mps> ok, will go with 'quota-tools'
2020-05-31 10:26:27 <nmeum> Cogitri: what's your opinion on moving polkit to community? seems to me only main/consolekit2 and main/libvirt require it. the former could also be moved to community (no main packages require it) the latter can be build without polkit support (not sure what this would imply though)
2020-05-31 10:26:55 <nmeum> if we move polkit to community we could also move mozjs60 and thereby python2 to community
2020-05-31 10:41:37 <mps> ikke: (and all interested) !8634 - review and comments are welcome
2020-05-31 10:42:31 <ikke> looks pretty straight-forward
2020-05-31 10:42:45 <ikke> I would say, just add it :)
2020-05-31 10:43:09 <Cogitri> nmeum: I don't mind moving consolekit2 but I'm not sure about libvirt
2020-05-31 10:44:34 <nmeum> I wouldn't move libvirt, I wolud keep it in main and build it with --without-polkit
2020-05-31 10:44:59 <nmeum> but probably need to investigate first what that entails
2020-05-31 10:45:31 <nmeum> polkit support for libvirt was enabled in
2020-05-31 10:45:32 <nmeum> 7ca62936d297e385c94c629838644bbc7c992cdc
2020-05-31 10:45:33 <mps> nmeum: though I don't use libvirt, I agree with you
2020-05-31 10:45:55 <Cogitri> nmeum: That entails that you won't be able to use virt-manager with system instances I think
2020-05-31 10:46:10 <Cogitri> It uses polkit to make it possible to run Qemu system instances
2020-05-31 10:46:42 <Cogitri> Actually I'm not sure if that won't brick virt-manager entirely
2020-05-31 10:46:56 <Cogitri> Since it asks for my password via polkit when starting virt-manager
2020-05-31 10:47:31 <nmeum> ah
2020-05-31 10:47:48 <mps> ( would like to see 'git rm polkit' one day)
2020-05-31 10:48:01 <nmeum> hm, breaking virt-manager is probably undesirable
2020-05-31 10:51:05 <Cogitri> I'm not entirely sure about that though, I haven't used virt-manager for some time
2020-05-31 10:54:25 <nmeum> I could open an MR moving polkit to community (with the changes described above to libvirt and consolekit) and we can discuss is further on gitlab then, would that make sense?
2020-05-31 11:17:02 <opal> ugh someone committed one of my patches a while back under their name and not mine so its difficult to find in git-shortlog
2020-05-31 11:18:35 <ikke> opal: you should still be the author
2020-05-31 11:18:46 <ikke> hmm, but shortlog should show authors
2020-05-31 11:19:01 <ikke> opal: do you know what package that patch was for?
2020-05-31 11:19:19 <opal> https://gitlab.alpinelinux.org/alpine/aports/-/commit/8225d5fd09
2020-05-31 11:19:41 <ikke> "authored 3 months ago by Francesco Colista's avatar Francesco Colista "
2020-05-31 11:19:43 <ikke> hmm
2020-05-31 11:20:20 <ikke> Not sure why fcolista did it like that
2020-05-31 11:20:25 <ikke> "
2020-05-31 11:20:27 <ikke> "Creds to : opal hart"
2020-05-31 11:20:39 <opal> yeah lol
2020-05-31 11:21:17 <opal> someone else did that fairly recently in another repo and im like, git can read emailed patches directly, just use that
2020-05-31 11:26:27 <opal> anyway submitted to aports a commit for prosody that fixes the default config
2020-05-31 11:26:54 <opal> guess someone added a line and then did not test it
2020-05-31 11:26:58 <opal> a long time ago
2020-05-31 11:27:55 <opal> what other package was i supposed to work on, let me check my mail
2020-05-31 11:31:53 <Cogitri> nmeum: Sure
2020-05-31 11:32:11 <Cogitri> And I guess it makes sense to move things that need polkit to community anyway
2020-05-31 11:32:23 <Cogitri> Since most people want polkit-elogind anyway
2020-05-31 11:33:37 <nmeum> yeah and polkit-gnome and other polkit related packages are also in community/ already
2020-05-31 11:36:59 <mps> any opinion about !8352
2020-05-31 11:37:54 <nmeum> Cogitri: !8637
2020-05-31 12:05:32 <ikke> opal: checksum failure
2020-05-31 12:05:40 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/8636
2020-05-31 12:08:25 <opal> my bad i'll send a v2
2020-05-31 12:12:40 <opal> done ikke, thanks
2020-05-31 12:14:19 <nmeum> https://gitlab.alpinelinux.org/nmeum/aports/-/jobs/130955
2020-05-31 12:14:24 <nmeum> can we make the CI ignore checkapk failures?
2020-05-31 12:14:50 <nmeum> >  >>> ERROR: the built package (consolekit2) is already in the repo
2020-05-31 12:15:00 <nmeum> that's an error message emitted by checkapk because I didn't bump the pkgrel
2020-05-31 12:37:17 <mps> huh, finally managed to boot mainline 5.6 kernel on raspberry pi zero w
2020-05-31 12:49:31 <ikke> pro-ftpd is failing on some arches
2020-05-31 12:49:49 <ikke> looks like a build dependency order issue
2020-05-31 12:51:24 <mps> yes, (someone told few days ago how is reviewers and commiters life is hard)
2020-05-31 12:52:11 <mps> trying to reproduce it locally
2020-05-31 12:52:49 <ikke> probably depends on the amount of concurrent jobs
2020-05-31 12:54:38 <mps> could be, locally it passed fine
2020-05-31 12:54:41 <mps> in lxc
2020-05-31 12:55:18 <mps> and I have export JOBS=8 in abuild.conf
2020-05-31 12:57:41 <opal> oh i thought pro-ftpd was the issue :^)
2020-05-31 12:57:56 <opal> i wish ftp was worth saving but we have rsync
2020-05-31 13:00:18 <ikke> We have better alternatives for faxing, but they refuse to die as well
2020-05-31 13:00:43 <opal> fair
2020-05-31 15:16:00 <nmeum> can we do a purge of testing/ at some point again? i.e. move all inactive packages to testing/ like we did in b6af1e02efe594039707cd882517663d5370f375
2020-05-31 15:16:20 <maxice8> sure, i use testing/*
2020-05-31 15:17:16 <nmeum> I also use testing/* packages but I move them to community/ or main/ if they work at some point
2020-05-31 15:17:38 <ikke> yeah, sounds like a good idea
2020-05-31 15:17:41 <nmeum> while going through packages which still use python2 I found a bunch of poorly maintained packages in testing/
2020-05-31 15:17:47 <maxice8> i mean, in the commit title i use testing/* instead of [multiple]
2020-05-31 15:17:48 <ikke> I have some packages in testing which should be moved to community
2020-05-31 15:18:06 <mps> hmm, I keep some pkgs in testing and move them only on users requests
2020-05-31 15:18:59 <ikke> foxtrotgps fails to build
2020-05-31 15:19:29 <ikke> "incompatible types when assigning to type 'double' from type 'timespec_t' {aka 'struct timespec'}"
2020-05-31 15:21:39 <maxice8> oof
2020-05-31 15:21:43 <maxice8> passed on CI ><
2020-05-31 15:27:05 <ikke> I wonder how that happens
2020-05-31 15:30:50 <mps> in computing most used thing is so called 'monte carlo method'
2020-05-31 15:30:58 <ikke> :)
2020-05-31 15:31:48 <maxice8> whever i head monte carlo i remember of Monaco for some reason
2020-05-31 15:36:00 <mps> probably because they relates
2020-05-31 15:38:23 <maxice8> from Wikipedia: "Monte Carlo is officially an administrative area of the Principality of Monaco"
2020-05-31 15:38:24 <maxice8> huh
2020-05-31 15:40:14 <mps> mostly known as 'Casino' from which computing 'monte carlo method' got name :)
2020-05-31 17:06:19 <nmeum> only 15 python2 packages left \o/
2020-05-31 17:08:13 <clandmeter> Somebody call my name?
2020-05-31 17:09:28 <Ariadne> nmeum: regarding go 1.14, we are considering rebootstrapping 1.14 with a cross-compile and see if 1.14 can rebuild itself on the host
2020-05-31 17:11:18 <nmeum> ok, keep me posted ;)
2020-05-31 17:14:15 <artok> lemmesee... I did go 1.14 by 1.4 bootstrap -> 1.14
2020-05-31 17:20:40 <artok> ah, there is go-bootstrap package to do that
2020-05-31 17:33:33 <ikke> Monte Carlo :D
2020-05-31 17:55:25 <artok> I think I'll send https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/clang/10-add-musl-triples.patch to llvm upstream
2020-05-31 17:57:16 <mps> Monte Carlo Casino :)
2020-05-31 18:01:10 <Ariadne> artok: we are talking about mips64
2020-05-31 18:01:24 <Ariadne> nmeum: go ahead and bump to 1.14, i'll rebootstrap it.  i think it will work
2020-05-31 18:01:26 <artok> oh that then
2020-05-31 18:14:10 <clandmeter> :)
2020-05-31 19:05:54 <nmeum> Ariadne: alright, good to hear
2020-05-31 19:08:38 <nmeum> currently making sure that the go 1.14 testsuite still passes on all arches supported by the gitlab ci
2020-05-31 19:23:47 <mps> uhm, we don't have linux-lts for armhf anymore
2020-05-31 19:25:05 <nmeum> ikke: didn't you say that you had a fix for the getrlimit go test suite problem? do you still recall what that fix was?
2020-05-31 19:25:47 <nmeum> I am asking because the aarch64 CI builder seems to run into this (again?) https://gitlab.alpinelinux.org/nmeum/aports/-/jobs/131397
2020-05-31 19:27:01 <PureTryOut[m]> For CMAKE to pick up the Java installation, I now do `PATH="$PATH:/usr/lib/jvm/java-1.8-openjdk/bin" cmake`. Is there a better way of doing this? Is there maybe an easy way to get the binaries symlinked to `/usr/bin/`?
2020-05-31 19:33:40 <Cogitri> 
ACTION really wished we had a proper alternatives system for that

2020-05-31 19:35:34 <nmeum> never really seen a good alternatives system so far, find the one used on debian-based distros very annoying personally but I agree that the way we handle jdk versions is a bit suboptimal atm
2020-05-31 19:36:22 <Cogitri> eclectic from Exherbo is kinda neat
2020-05-31 19:37:00 <Cogitri> But really, anything that just manages slots (as in notes the available slots) and symlinks things into place would be neato
2020-05-31 20:07:40 <ikke> nmeum: that was fixed upstream
2020-05-31 20:08:10 <ikke> They changed the syscsll they did to one that was allowed in Docker on arm
2020-05-31 20:08:18 <ikke> Are you running into that again?
2020-05-31 20:24:57 <ikke> ugh, forgot to check commits :-/
2020-05-31 20:25:03 <ikke> had to squash
2020-05-31 20:25:20 <maxice8> that is a
2020-05-31 20:25:26 <maxice8> groß oof
2020-05-31 20:25:58 <ikke> ganz groß
2020-05-31 20:26:02 <Cogitri> Yeah, I sometimes have that happen to me as well :/
2020-05-31 20:26:19 <ikke> That's what I dislike about gitlab / github
2020-05-31 20:26:22 <maxice8> I need to add a confirmation prompt for mgmr
2020-05-31 20:26:23 <ikke> it's all about the MR
2020-05-31 20:26:31 <ikke> commits don't matter
2020-05-31 20:29:41 <Hello71> arch just uses a custom script
2020-05-31 20:29:43 <Hello71> https://git.archlinux.org/svntogit/packages.git/tree/trunk/bin_archlinux-java?h=packages/java-common
2020-05-31 20:42:15 <nmeum> ikke: ah, probably not included in the latest release then
2020-05-31 20:42:24 <ikke> hmm
2020-05-31 20:43:09 <nmeum> I will push the go upgrade now
2020-05-31 20:43:31 <nmeum> it fails on aarch64 ci due to the getrlimit thing and the armv7 ci runs into a timeout but unsure whether this happens on the builders
2020-05-31 20:44:31 <ikke> nmeum: https://github.com/golang/go/issues/38604
2020-05-31 20:45:23 <nmeum> looks like that will be included in 1.15.X
2020-05-31 20:45:28 <ikke> ok
2020-05-31 20:45:29 <nmeum> we could backport it though
2020-05-31 20:45:38 <nmeum> but I think it's not that important? idk
2020-05-31 20:46:06 <ikke> Depends on how quick we will go to 1.15
2020-05-31 20:46:58 <ikke> I think I patched it for 3.11-stable
2020-05-31 20:47:15 <ikke> yeah, I did
2020-05-31 20:47:28 <ikke> So we can do the same for edge
2020-05-31 20:48:03 <ikke> nmeum: https://tpaste.us/on6k
2020-05-31 20:48:12 <ikke> it's a relatively simple patch
2020-05-31 20:48:22 <ikke> not sure if it applies cleanly on 1.14 though
2020-05-31 20:48:50 <nmeum> okk
2020-05-31 20:49:07 <nmeum> can backport it after the current upgrade passed successfully
2020-05-31 20:49:11 <ikke> nod
2020-05-31 20:49:26 <nmeum> just wanna make sure that works before I do anything else with go
2020-05-31 21:00:09 <nmeum> the build-edge-armv7 builder shows as idle on build.alpinelinux.org but doesn't seem to have build go yet is that intended?
2020-05-31 21:08:45 <ikke> it's still busy apparnetly
2020-05-31 21:09:17 <ikke> build.a.o shows it as well
2020-05-31 21:13:49 <nmeum> hm strange
2020-05-31 21:13:51 <nmeum> it failed now
2020-05-31 21:14:04 <nmeum> this time with a different error message on a test which passed on the ci
2020-05-31 21:14:13 <nmeum> > using too much memory: 81305600 bytes
2020-05-31 21:17:53 <nmeum> I will call it a day for now
2020-05-31 21:17:58 <ikke> heh
2020-05-31 21:18:07 <nmeum> maybe it's some kind of race condition and it will magically fix itself over night ':R
2020-05-31 21:18:15 <ikke> what's up with things taking too much mem on a box with 128G
2020-05-31 21:18:41 <ikke> probably some other limit
2020-05-31 21:38:35 <Ariadne> PureTryOut[m]: yo, since upgrading to latest kde packages, my akonadi keeps dying every time my computer goes to sleep
2020-05-31 21:38:49 <Ariadne> and i have to rm the entire .local/share/akonadi to make it work again
2020-05-31 21:40:45 <PureTryOut[m]> Yeah I noticed that swell, it's hella annoying
2020-05-31 21:40:49 <PureTryOut[m]> Not sure what's happening
2020-05-31 22:26:44 <Ariadne> PureTryOut[m]: any objection to adding a -dbg package to akonadi?
2020-05-31 22:33:00 <nmeum> on armv7 go seems to be running into https://github.com/golang/go/issues/37331
2020-05-31 22:33:04 <nmeum> not sure what the armhf thing is about
2020-05-31 22:37:04 <PureTryOut[m]> Ariadne: nope
2020-05-31 23:13:24 <nmeum> !8672 seems to fix the go test flakyness (at least on the CI)
2020-05-31 23:13:28 <nmeum> will push it tomorrow