2019-11-01 05:38:22 <_ikke_> tmhoang: I'm running a patch for go from the mailing list through or CI. The only thing it does is adding a musl-del makedepends. It fails a test on our s390x runner with "waitgroup_test.go:96: Unexpected panic: <nil>". Any idea why?
2019-11-01 05:38:26 <_ikke_> https://gitlab.alpinelinux.org/kdaudt/aports/-/jobs/10489
2019-11-01 05:38:49 <_ikke_> Interestingly enough, I found this while googling: https://build.golang.org/log/148e44a754540f89bba374981a1a8ac73747bc9f
2019-11-01 05:38:55 <_ikke_> solaris, same failure
2019-11-01 09:55:31 <kaey> _ikke_: https://github.com/golang/go/issues/22944
2019-11-01 10:03:09 <_ikke_> kaey: thanks !
2019-11-01 10:03:21 <_ikke_> I only searched for the error message, this didn't show up
2019-11-01 11:32:49 <tmhoang> _ikke_ i'm seeing thanks for catching
2019-11-01 11:33:39 <_ikke_> tmhoang: np
2019-11-01 11:37:59 <tmhoang> _ikke_: is there any way I can subscribe to gitlab with *all* issue/pr coming in ?
2019-11-01 11:38:27 <tmhoang> looking at : https://gitlab.alpinelinux.org/alpine/aports
2019-11-01 11:38:36 <tmhoang> finding subscribe button to hit
2019-11-01 11:39:03 <_ikke_> You can select "watch"
2019-11-01 11:40:07 <tmhoang> ah right
2019-11-01 11:40:47 <Cogitri> (Or setup custom notification rules)
2019-11-01 11:41:08 <Cogitri> Which is what I did, otherwise you'll be notified for every comment on every thread which makes your postbox blow up :P
2019-11-01 11:46:41 <tmhoang> it passes here at my dev machine, hmm
2019-11-01 11:47:01 <tmhoang> Cogitri: custom noti rule in gitlab or in your email client ?
2019-11-01 11:47:47 <Cogitri> Custom rule in gitlab
2019-11-01 11:48:15 <Cogitri> On the thingie you're pressing to set "Watch" there's a field under that saying "Custom Notification Rules" or something like that
2019-11-01 11:49:04 <tmhoang> ah ha fancy, thanks
2019-11-01 11:53:52 <tmhoang> _ikke_ could you trigger the build again ? I cannot reproduce
2019-11-01 11:54:26 <_ikke_> sure (I already did ran it twice)
2019-11-01 11:54:50 <_ikke_> It's running
2019-11-01 12:02:47 <tmhoang> I assume ci is latest edge
2019-11-01 12:02:55 <_ikke_> yes
2019-11-01 12:02:57 <tmhoang> 
ACTION upgrading machine 

2019-11-01 12:03:10 <_ikke_> Maybe it onle happens in docker?
2019-11-01 12:04:24 <tmhoang> gitlab runner runs stuff in docker ? maybe, i'm checking too.
2019-11-01 12:04:42 <_ikke_> it does
2019-11-01 12:14:27 <tmhoang> running in docker ... it seems this test is flaky, not just s390x : https://goissues.org/sync, https://github.com/golang/go/issues/20072
2019-11-01 12:15:09 <_ikke_> tmhoang: right, I suspected as much
2019-11-01 12:16:00 <tmhoang> doesn't fail on latest edge, doesn't failed in latest edge docker too. I think I would just disable this test or other flaky tests too
2019-11-01 12:16:58 <_ikke_> tmhoang: ok, makes sense
2019-11-01 12:23:08 <tmhoang> https://github.com/golang/go/issues/20072 : specific to s390x
2019-11-01 12:27:05 <_ikke_> including patch
2019-11-01 12:27:13 <tmhoang> _ikke: maybe ? http://tpaste.us/reqV
2019-11-01 12:27:13 <_ikke_> https://github.com/dragonfly-science/nixpkgs/commit/ef230346b0f0b05b85571945c9e2d1f13d7e53a7
2019-11-01 12:27:34 <tmhoang> eh sweet
2019-11-01 12:27:45 <_ikke_> :)
2019-11-01 12:28:02 <_ikke_> Thanks!
2019-11-01 12:28:23 <tmhoang> I'm thinking about package podman and builddah and brothers to Alpine
2019-11-01 12:28:30 <tmhoang> but need to to rust for s390x ...
2019-11-01 12:29:55 <_ikke_> tmhoang: I feel you
2019-11-01 12:30:37 <tmhoang> podman promises to do docker without root priv, sounds cool
2019-11-01 12:30:46 <tmhoang> s/docker/container/
2019-11-01 12:30:46 <alpine-meetbot> tmhoang meant to say: podman promises to do container without root priv, sounds cool
2019-11-01 12:30:53 <_ikke_> yeah, read about it before
2019-11-01 12:31:09 <_ikke_> And buildah is like docker build?
2019-11-01 12:31:10 <tmhoang> at work I use it a lot, like all the time.
2019-11-01 12:31:16 <tmhoang> kinda
2019-11-01 12:31:18 <_ikke_> ok
2019-11-01 12:31:36 <_ikke_> someone reported an issue related to that btw: https://gitlab.alpinelinux.org/alpine/aports/issues/10925
2019-11-01 12:32:09 <tmhoang> hah fun
2019-11-01 14:11:43 <mps> crosbymichael_: thanks for help with docker yesterday
2019-11-01 14:12:06 <crosbymichael_> no problem.  did you all get it working?
2019-11-01 14:12:31 <mps> I think _ikke_ fixed them
2019-11-01 14:13:28 <crosbymichael_> good.  i'll be around because i'm trying to run alpine on my desktop, to replace ubuntu, so if you all need anything container related i'm here to help
2019-11-01 14:13:38 <crosbymichael_> hopefully i'll start packaging some things too
2019-11-01 14:13:39 <mps> would you mind to open issue on gitlab.a.o and describe cause and solution because you understand this well
2019-11-01 14:14:31 <crosbymichael_> sure, let me get signed up.  An issue in the aports repo or somewhere else?
2019-11-01 14:14:47 <mps> _ikke_: ^
2019-11-01 14:15:26 <mps> I think aports or infra but not sure, when _ikke_ come online he will give proper answer
2019-11-01 14:15:36 <crosbymichael_> infra probably :)
2019-11-01 14:16:26 <mps> I think so, but again not sure
2019-11-01 14:17:37 <mps> re your switch from ubuntu, after more than 20 years on debian I switched to alpine, never looked back :)
2019-11-01 14:18:36 <crosbymichael_> i have cryptroot plus zfs root setup
2019-11-01 14:18:38 <crosbymichael_> soo good
2019-11-01 14:22:53 <mps> nice to hear
2019-11-01 14:26:33 <_ikke_> we just ignored CI for now, I pushed the packages
2019-11-01 14:26:44 <_ikke_> We'll wait for docker to fix this properly
2019-11-01 14:26:48 <ncopa> hey crosbymichael_: how is the alpine desktop project goin?
2019-11-01 14:27:55 <crosbymichael_> ncopa, good! cryptroot+zfs and everything working good for me
2019-11-01 14:28:02 <crosbymichael_> using chroot from things like zoom
2019-11-01 14:28:55 <ncopa> nice
2019-11-01 14:29:22 <ncopa> was it difficult to set up the cryptroot+zfs?
2019-11-01 14:29:33 <crosbymichael_> _ikke_, talked with some of the security team.  it is safe if containers have their own keyring, but i'm sure sure it would be safe for docker to whitelist them as you need to make sure on the runtime side(runc/etc) that containers are created with their own keyring
2019-11-01 14:29:55 <crosbymichael_> cryptroot+zfs is easy, it was getting syslinux + EFI to work on NVME drives which was harder
2019-11-01 14:30:11 <crosbymichael_> but we got it to work and didn't have to use grub
2019-11-01 14:31:21 <crosbymichael_> mostly because i'm an efi noob but now its fine.  right now `efibootmgr` is in the testing repo and was wondering if you all were going to move it to community/main anytime soon
2019-11-01 14:31:48 <crosbymichael_> it's kinda the only core setup piece that you need that is in the testing repo
2019-11-01 14:32:46 <_ikke_> crosbymichael_: ok, and how do you make sure that's the case?
2019-11-01 14:33:21 <crosbymichael_> _ikke_, the docker defaults with using runc creates containers with their own keyring
2019-11-01 14:33:36 <crosbymichael_> so it would be safe to whitelist this on the CI for building those packages
2019-11-01 14:33:42 <maxice8> crosbymichael_: re: efibootmgr in community/ : as soon as someone makes a MR to move it to community
2019-11-01 14:33:51 <ncopa> I can move efibootmgr to community if it works
2019-11-01 14:35:22 <_ikke_> crosbymichael_: ok, thanks for the information
2019-11-01 14:35:47 <_ikke_> crosbymichael_: is it btw possible to extend the existing secomp, or do you have to always define it completely?
2019-11-01 14:35:50 <ncopa> efibootmgr moved
2019-11-01 14:36:05 <crosbymichael_> ncopa, thanks!  i've tested it and it works ;)
2019-11-01 14:36:13 <crosbymichael_> _ikke_, i think you have to redefine
2019-11-01 14:36:20 <crosbymichael_> just because it's a whitelist
2019-11-01 14:37:58 <crosbymichael_> _ikke_, the docker daemon has a `--seccomp-profile` flag so you can replace the default on the daemon side
2019-11-01 14:39:09 <_ikke_> crosbymichael_: yes, that's what I've been doing
2019-11-01 14:39:19 <_ikke_> But we have to make sure it's kept up-to-date then
2019-11-01 14:45:07 <crosbymichael_> true.  i'll keep a lookout for any changes that are made
2019-11-01 16:05:37 <Cogitri> Just ad a PSA: Will be kind of AFK for the next two weeks, notebook will be at repair @ HP
2019-11-01 16:05:37 <Cogitri> s/ad/as/
2019-11-01 16:05:37 <alpine-meetbot> Cogitri meant to say: Just as a PSA: Will be kind of AFK for the next two weeks, notebook will be at repair @ HP
2019-11-01 16:07:11 <_ikke_> Cogitri: sadface
2019-11-01 17:32:17 <tboerger[m]> damn.... leo killed py3-boto3@testing with https://gitlab.alpinelinux.org/alpine/aports/commit/825b60cb9bb16b44d7b187549c13c8f31c1f79e6 :(
2019-11-01 17:32:36 <tboerger[m]> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/pWWjjDgTYNQgBlMbalZczTXw >

2019-11-01 17:33:28 <_ikke_> So it just needs to be rebuilt
2019-11-01 17:34:50 <tboerger[m]> and who can trigger a rebuild? :)
2019-11-01 17:35:03 <_ikke_> I can
2019-11-01 17:35:16 <tboerger[m]> or maybe it could be even moved into community instead of testing? :P
2019-11-01 17:35:25 <_ikke_> yes, that might make sense
2019-11-01 17:36:24 <_ikke_> First need to finish somehting
2019-11-01 17:37:18 <tboerger[m]> if somebody takes care about getting it working again: absolutely great! :)
2019-11-01 17:38:12 <tboerger[m]> even if it's still in testing, we are using this package within our Drone CI ansible plugin and some guy ran into that issue while he wanted to add another python dependency at https://github.com/drone-plugins/drone-ansible/pull/30
2019-11-01 17:42:05 <_ikke_> ok, finished
2019-11-01 17:42:08 <_ikke_> let's take al ook
2019-11-01 17:46:18 <_ikke_> tboerger[m]: strange
2019-11-01 17:46:24 <_ikke_> there is a py3-boto in main as well
2019-11-01 17:46:34 <_ikke_> do you know why there is a separate py3-boto in testing?
2019-11-01 17:46:42 <_ikke_> ah, boto3
2019-11-01 17:46:51 <tboerger[m]> py3-boto3 is in testing
2019-11-01 17:46:57 <tboerger[m]> py3-boto in main is another version
2019-11-01 17:46:58 <_ikke_> yea, noticed
2019-11-01 17:47:01 <_ikke_> thanks
2019-11-01 17:47:12 <_ikke_> I can reproduce the issue
2019-11-01 17:48:39 <_ikke_> ok, it's not *just* a matter of bumping it, it has hard requirements for those versions
2019-11-01 17:48:47 <_ikke_> at least, in the APKBUILD
2019-11-01 17:51:04 <_ikke_> 1.10.7 is available
2019-11-01 17:51:44 <_ikke_> maxice8: Any idea why these constraints have been added to testing/py3-boto3?
2019-11-01 17:52:51 <maxice8> They used to have a interlocked release versioning
2019-11-01 17:56:45 <maxice8> if you want i can take a look at it
2019-11-01 17:56:55 <_ikke_> I just pushed a commit to gitlab
2019-11-01 17:57:13 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/997
2019-11-01 17:57:19 <maxice8> a mr ?
2019-11-01 17:57:24 <_ikke_> yes
2019-11-01 17:58:01 <maxice8> lgtm
2019-11-01 17:58:35 <_ikke_> requirements.txt does not limit the version for botocore
2019-11-01 17:58:41 <_ikke_> https://github.com/boto/boto3/blob/develop/requirements.txt#L1
2019-11-01 17:59:18 <maxice8> but requres.txt does
2019-11-01 17:59:29 <_ikke_> where?
2019-11-01 17:59:32 <maxice8> in boto3.egg-info
2019-11-01 17:59:49 <_ikke_> ah, it's in setup.pu
2019-11-01 17:59:51 <_ikke_> py
2019-11-01 17:59:57 <_ikke_> https://github.com/boto/boto3/blob/master/setup.py#L17
2019-11-01 17:59:59 <maxice8> boto3.egg-info/requires.txt
2019-11-01 18:00:05 <_ikke_> yes, that comes from setup.py
2019-11-01 18:00:05 <maxice8> botocore<1.14.0,>=1.13.2
2019-11-01 18:00:23 <_ikke_> ok, so <1.14.0 makes sense then
2019-11-01 18:01:05 <_ikke_> The rest of the deps are still ok
2019-11-01 18:03:55 <_ikke_> maxice8: maybe it would make sense to add a note to py3-boto that py3-boto3 has a fixed requirement on it
2019-11-01 18:04:34 <_ikke_> py3-botocore*
2019-11-01 18:05:36 <maxice8> Sounds good
2019-11-01 18:05:39 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/997/diffs#811cf2c393443d64a251a126caab0a706600c3dc_5_5
2019-11-01 18:07:19 <_ikke_> # Verify required version from py3-boto3 on this package before upgrading
2019-11-01 18:09:26 <maxice8> :shipit:
2019-11-01 18:09:45 <_ikke_> done
2019-11-01 18:10:23 <_ikke_> tboerger[m]: can you confirm later that everything is fixed?
2019-11-01 18:18:30 <tmhoang> _ikke_: what is our policy to kill a hanging build process on the builder ? looks like openjdk11 consumes a lot of cpu but it was disabled already
2019-11-01 18:18:58 <_ikke_> Then just kill it :)
2019-11-01 18:53:05 <tboerger[m]> @ikke yeah I can check if it works
2019-11-01 18:53:13 <_ikke_> It should be available now
2019-11-01 20:46:31 <crosbymichael_> ok, how do I go about building a new kernel with all the various modules, wireguard zfs, etc
2019-11-01 20:46:56 <crosbymichael_> i'm trying to get a 5.3x kernel going but after the kernel and header compiles, i cannot compile wireguard or zfs because of breaking depenedencies
2019-11-01 20:47:00 <_ikke_> Have you looked at the linux-vanilla aport?
2019-11-01 20:47:27 <_ikke_> I don't have experience with this myself, so I'm of little help
2019-11-01 20:47:59 <crosbymichael_> yup, just built that fine but I cannot install it because of wireguard-vanilla
2019-11-01 20:49:19 <_ikke_> https://git.alpinelinux.org/aports/tree/community/wireguard-vanilla/APKBUILD
2019-11-01 20:49:20 <crosbymichael_> ok, if i remove the host package it will start the build
2019-11-01 20:49:46 <crosbymichael_> i think it's because i'm building on my dev box and wireguard was installed
2019-11-01 20:49:57 <_ikke_> yes, makes sense
2019-11-01 20:50:07 <_ikke_> otherwise it should not be an issue
2019-11-01 20:50:18 <crosbymichael_> i guess i need a little build box
2019-11-01 20:50:31 <crosbymichael_> or maybe the docker image for the builds
2019-11-01 20:50:39 <_ikke_> there is docker-abuild
2019-11-01 20:51:52 <_ikke_> softhsm test suite crypto test fails on CI, I wonder if it's the same issue again
2019-11-01 20:51:55 <mps> crosbymichael_: I build my own kernels for different arch's, but I patch wireguard to kernel tree before 'make'
2019-11-01 20:52:28 <crosbymichael_> mps, ya, I usually compile it in as well.  just getting used to the alpine build setup
2019-11-01 20:52:51 <crosbymichael_> do you have an aport fork with some examples for your kernels/
2019-11-01 20:53:26 <mps> I have one branch in aports with armv7 multiplatform kernel
2019-11-01 20:53:56 <mps> and started one branch with 5.4-rc5 but not finished it
2019-11-01 20:54:12 <crosbymichael_> nice, i'm getting 5.3 up because i've been doing cgroupv2 work and need that one
2019-11-01 20:55:01 <mps> I run 5.3 on arm boxes because I need newer drivers
2019-11-01 20:56:33 <mps> few days ago I built 5.4-rc5 for x86_64 (vanilla and virt) but they are not finished because a lot of changes from 4.19.x, although both boots and works
2019-11-01 20:57:50 <mps> if you want I can post patch somewhere
2019-11-01 21:00:00 <crosbymichael_> thanks but it just booted 5.3.  I think i'm good ;)
2019-11-01 21:00:17 <mps> ok, nice to hear
2019-11-01 21:03:42 <artok> they even have 5.3 branch
2019-11-01 21:03:50 <artok> on rpi
2019-11-01 21:08:09 <mps> artok: who are 'they'
2019-11-01 21:08:35 <artok> raspberry people
2019-11-01 21:08:46 <artok> github.com/raspberrypi/linux
2019-11-01 21:08:53 <artok> and seems to be active
2019-11-01 21:08:58 <mps> aha, ok, I hope we will have 5.4 soon
2019-11-01 21:10:03 <artok> well after rc roulette stops, I think they'll get it
2019-11-01 21:10:23 <mps> and I'm contemplating to make testing/linux-arv7-mp
2019-11-01 21:10:54 <mps> armv7
2019-11-01 21:14:40 <mps> but now I'm struggling with cmake splitting man pages for pkg in my private repo :(
2019-11-01 21:17:53 <artok> cmake, best thing after sliced bread
2019-11-01 21:27:58 <_ikke_> maxice8: oh, you justed deleted botan, I was looking at that one
2019-11-01 21:28:53 <maxice8> oh
2019-11-01 21:29:27 <_ikke_> I still have it locally though
2019-11-01 21:29:38 <maxice8> Feel free to push it with --reset-author :D
2019-11-01 21:29:45 <_ikke_> :)
2019-11-01 21:30:52 <_ikke_> We ran in an issue yesterday where seccomp as causing a test to fail
2019-11-01 21:31:01 <_ikke_> I was wondering if it was the same in this case
2019-11-01 21:31:06 <_ikke_> but apparently it was not
2019-11-01 21:42:04 <mps> how can I tell cmake to install/copy man pages from dir in source tree to $pkgdir
2019-11-01 21:42:26 <artok> you're doing the cmake script yourself?
2019-11-01 21:42:39 <mps> no
2019-11-01 21:43:20 <mps> I can post APKBUILD if you are willing to help me
2019-11-01 21:43:36 <artok> sure, source for the package also helps
2019-11-01 21:44:04 <mps> http://tpaste.us/mEMV
2019-11-01 21:44:40 <mps> source is https://github.com/sm0svx/svxlink/archive/19.09.1.tar.gz
2019-11-01 21:45:00 <mps> but you have seen it already in APKBUILD probably
2019-11-01 21:45:25 <artok> yeah
2019-11-01 21:45:40 <artok> that source seems to use DOC_INSTALL_DIR
2019-11-01 21:46:01 <mps> MAN_INSTALL_DIR
2019-11-01 21:46:11 <artok> oh yeah
2019-11-01 21:46:14 <mps> isn't this enough
2019-11-01 21:46:19 <artok> doc is for html
2019-11-01 21:46:24 <mps> yes
2019-11-01 21:46:54 <artok> -DMAN_INSTALL_DIR=$pkgdir
2019-11-01 21:47:11 <mps> in doc() function?
2019-11-01 21:47:41 <mps> or in build()
2019-11-01 21:47:45 <artok> build..
2019-11-01 21:47:53 <mps> let me try
2019-11-01 21:48:07 <artok> that seems to have usr/share now
2019-11-01 21:49:46 <mps> it have usr/share and copies other files there properly
2019-11-01 21:51:48 <mps> no luck, same error
2019-11-01 21:52:02 <mps> >> ERROR: svxlink-doc*: Missing /home/mps/mps-aports/svxlink/pkg/svxlink-doc
2019-11-01 21:53:40 <artok> you set the builddir to be where source is lying?
2019-11-01 21:54:05 <mps> yes, builddir="$srcdir"/$pkgname-$pkgver/src
2019-11-01 21:54:34 <artok> it is considered bad thing to do in-souce-tree building with cmake
2019-11-01 21:55:04 <artok> (hell, even binutils and gcc with autotools say it is bad thing)
2019-11-01 21:55:16 <mps> yes, I know, but it worked on previous version of the same pkg
2019-11-01 21:56:04 <mps> I usually do not that, but this pkg is make me nervous
2019-11-01 21:56:51 <artok> might be that there is now some cmake sripts that are using ${CMAKE_CURRENT_SOURCE_DIR}/file ${CMAKE_CURRENT_BINARY_DIR}/file and they need to be different.. in-source-build and you'll be writing over the first one on generation of the second one
2019-11-01 21:58:15 <mps> huh, nvm, I can live without man pages in pkg, and copy them manually
2019-11-01 22:02:43 <artok> actually how abuild does the stuff would be nice to know
2019-11-01 22:02:52 <artok> splitting, that is
2019-11-01 22:03:30 <artok> how to tell what goes into -dev
2019-11-01 22:03:49 <mps> heh, it's fine points isn't still clear to me
2019-11-01 22:04:32 <mps> -dev *.h files and *.so files
2019-11-01 22:04:40 <artok> *.a
2019-11-01 22:04:50 <mps> *.a in static
2019-11-01 22:05:03 <artok> *.so files should be in basic libs, as they're runtime
2019-11-01 22:05:54 <_ikke_> *.so is in -dev, *.so.* is in main package
2019-11-01 22:05:57 <mps> if the built binaries depends on them, yes
2019-11-01 22:06:56 <_ikke_> /usr/lib/eggdrop/server.so eggdrop
2019-11-01 22:08:06 <artok> isn't that usually symlink to some server.so.1.4
2019-11-01 22:08:14 <artok> (for example)
2019-11-01 22:10:45 <artok> (says guy who is just writing cmake scripts to library and telling it to make symlink for the version)
2019-11-01 22:23:11 <mps> got new svxlink version apk but this time with empty -doc
2019-11-01 22:24:02 <mps> strange thing that in previous version I've got man pages in -doc subpkg
2019-11-01 22:24:21 <artok> and with basically same commands ?
2019-11-01 22:24:39 <artok> abuild get's them from /usr/share/man ?
2019-11-01 22:26:11 <mps> yes, but with this version 'make install' in package() doesn't copy them to $pkg/....
2019-11-01 22:29:24 <artok> make install-man ?
2019-11-01 22:29:31 <mps> previous version works more than a year on one HAM repeater 365/24 and I thought to post it to aports
2019-11-01 22:29:56 <artok> cmake generates target man
2019-11-01 22:30:15 <mps> I searched something like that but didn't found
2019-11-01 22:30:34 <mps> maybe I misspelled it in grep -r
2019-11-01 22:30:35 <artok>  builddir src/doc/man/Makefile
2019-11-01 22:30:59 <artok> (if there is any)
2019-11-01 22:31:01 <mps> will try but tomorrow, it's late and I'm tired
2019-11-01 22:31:09 <artok> oh damn
2019-11-01 22:31:34 <artok> less than 5hrs of sleep and I need to be driving
2019-11-01 22:32:00 <artok> and then spend 6 days at sea again
2019-11-01 22:32:15 <mps> heh, not bad
2019-11-01 22:32:22 <mps> enjoy it
2019-11-01 22:32:27 <artok> yeah, working
2019-11-01 22:33:15 <mps> oh, that is different then, anyway enjoy your work :)
2019-11-01 22:33:29 <artok> but that is usually enjoyable, I work as AV technician and DJ =)
2019-11-01 22:34:49 <mps> ah, yes, I remember, you told me that earlier
2019-11-01 22:36:47 <artok> yah
2019-11-01 22:37:21 <artok> one nighty night beer and at least try to get some sleep
2019-11-01 22:37:25 <artok> cya!
2019-11-01 22:37:36 <mps> go to bed and rest few hours! good night
2019-11-01 22:42:11 <PureTryOut[m]> In the LibreOffice packaging, where does the "file-lists" folder come from? https://git.alpinelinux.org/aports/tree/community/libreoffice/APKBUILD#n352
2019-11-01 22:44:01 <[[sroracle]]> it's generated as part of the build process afaik
2019-11-01 22:49:31 <PureTryOut[m]> Hmm that's annoying, makes it hard to check...
2019-11-01 23:27:10 <maxice8> we reached 1000 MRs on gitlab.a.o
2019-11-01 23:40:53 <maxice8> Got MRs for security issues on tiff, libarchive (3.7) and libvncserver
2019-11-02 01:47:34 <russkel> does abuild actually support building from git repos?
2019-11-02 01:47:45 <russkel> I see the snapshot functionality but I don't understand how to use it
2019-11-02 03:18:11 <russkel> if I want to compile the clang-tools-extra repo, should I just modify the clang APKBUILD to include it (as it's an extra project as a part of the clang build) or should I make a separate package?
2019-11-02 06:44:27 <agris> Hello, is anybody here?
2019-11-02 07:10:19 <wowaname> only a few hundred people
2019-11-02 07:22:31 <agris> k
2019-11-02 09:58:57 <mps> _ikke_: you asked me few days ago about !288
2019-11-02 10:00:15 <mps> I think is should go to edge now, and we will have time to fix it before next stable alpine release, if problem arises ofc
2019-11-02 10:00:30 <mps> s/is/it/
2019-11-02 10:00:30 <alpine-meetbot> mps meant to say: I think it should go to edge now, and we will have time to fix it before next stable alpine release, if problem arises ofc
2019-11-02 12:55:27 <maxice8> :D got MRs for security fixes for tiff and libvncserver
2019-11-02 13:04:44 <_ikke_> maxice8: do you think this edit makes sense? http://tpaste.us/naZv
2019-11-02 13:06:17 <maxice8> looks like it but i have no clue how that works
2019-11-02 13:06:42 <_ikke_> My idea is to prevent running the command if the file alreayd exists
2019-11-02 13:06:54 <_ikke_> so that it doesn't (attempt) to generate a new key on every upgrade
2019-11-02 13:07:23 <maxice8> i see
2019-11-02 16:36:11 <_ikke_> maxice8: Why do you happen to close MRs just as I'm looking at them :P
2019-11-02 16:36:56 <maxice8> _ikke_: you  remind me i needed to close them because they had problems i had no will to fix :D
2019-11-02 16:37:06 <maxice8> can we get !777 ?
2019-11-02 16:37:23 <_ikke_> !640 builds just fine
2019-11-02 16:37:33 <_ikke_> https://gitlab.alpinelinux.org/Leo/aports/-/jobs/10942
2019-11-02 16:37:43 <_ikke_> I just had to increase the artifact size limit
2019-11-02 16:50:41 <maxice8> _ikke_: need an urgent merge to unstuck the builders
2019-11-02 16:50:48 <maxice8> !1031
2019-11-02 16:50:53 <_ikke_> k
2019-11-02 16:51:59 <_ikke_> What happened?
2019-11-02 16:52:32 <maxice8> previous update to nodejs removed the npm package
2019-11-02 16:52:41 <maxice8> so nodejs now holds /usr/bin/npm while before it was under its own npm package
2019-11-02 16:52:43 <maxice8> 83248509e435971957582bb985fac43e791abad5
2019-11-02 16:55:33 <_ikke_> You didn't add the ::noarch part back?
2019-11-02 16:56:15 <maxice8> yes, by mistake
2019-11-02 16:56:24 <_ikke_> ok, I can fix that
2019-11-02 16:56:53 <_ikke_> Oh, you pushed already
2019-11-02 16:58:36 <maxice8> yes
2019-11-02 17:11:26 <kr0k0> Hi @all
2019-11-02 17:12:20 <kr0k0> maxice8: I have forgotten to add wireguard-go first to testing. Thank you!
2019-11-02 17:28:16 <_ikke_> maxice8: https://gitlab.alpinelinux.org/Leo/aports/pipelines/1316 :-)
2019-11-02 17:28:41 <maxice8> :shipit:
2019-11-02 17:29:06 <_ikke_> first pushing node
2019-11-02 17:35:57 <maxice8> yes please, nomad keeps failing
2019-11-02 17:36:22 <maxice8> any package that calls npm will fail so basically the whole nodejs stuff in Alpine
2019-11-02 17:36:33 <_ikke_> It's pushed
2019-11-02 17:36:40 <maxice8> not a bad thing per se
2019-11-02 17:36:44 <_ikke_> :D
2019-11-02 17:39:30 <_ikke_> maxice8: nomad is still failing, apparently it needs to be pushed to distfiles?
2019-11-02 17:39:43 <_ikke_> Fetching http://distfiles.alpinelinux.org/distfiles//nomad-0.10.0.tar.gz
2019-11-02 17:41:02 <_ikke_> make: *** [GNUmakefile:340: ember-dist] Error 1
2019-11-02 17:41:30 <maxice8> hopefully just a failure to fetch from the npm repos
2019-11-02 17:42:32 <_ikke_> doesn't seem like it
2019-11-02 17:45:54 <_ikke_> warning " > @babel/plugin-proposal-object-rest-spread@7.4.3" has unmet peer dependency "@babel/core@^7.0.0-0".
2019-11-02 17:45:56 <_ikke_> warning "@babel/plugin-proposal-object-rest-spread > @babel/plugin-syntax-object-rest-spread@7.2.0" has unmet peer dependency "@babel/core@^7.0.0-0".
2019-11-02 17:46:11 <_ikke_> maxice8: I guess this is causing the build to fail?
2019-11-02 17:52:53 <maxice8> seems to be
2019-11-02 17:53:12 <_ikke_> Building it locally now. Those seem to be just warnings
2019-11-02 17:54:35 <_ikke_> http://tpaste.us/LY66
2019-11-02 17:54:40 <_ikke_> this is what it shows before it fails
2019-11-02 17:55:53 <_ikke_> yarn seems to fail for some reason
2019-11-02 17:56:27 <_ikke_> removing --silent from the yarn install command helps
2019-11-02 17:57:15 <_ikke_> ../src/create_string.cpp:17:37: error: no matching function for call to 'v8::String::Utf8Value::Utf8Value(v8::Local<v8::Value>&)'
2019-11-02 17:57:39 <_ikke_> trying to build node-gyp
2019-11-02 18:02:06 <_ikke_> maxice8: https://github.com/sass/libsass/issues/2883
2019-11-02 18:07:07 <_ikke_> Note sure how to fix it, but apparently node-sass 4.12.0 should fix it
2019-11-02 18:14:36 <_ikke_> yarn upgrade seemse to fix it
2019-11-02 18:55:44 <_ikke_> sigh
2019-11-02 18:55:59 <_ikke_> some node crap installed hooks in my aports repo
2019-11-02 19:00:56 <mps> heh, (node is crap)
2019-11-02 19:01:12 <_ikke_> husky in this case
2019-11-02 19:02:47 <mps> anyway 'Javascript, good parts' is/was big disservice for computing field
2019-11-02 19:03:54 <mps> builders are stuck?
2019-11-02 19:04:17 <_ikke_> yes
2019-11-02 19:04:45 <mps> anyone know why
2019-11-02 19:04:54 <_ikke_> yes
2019-11-02 19:05:00 <_ikke_> nomad is failing to build
2019-11-02 19:05:25 <mps> aha, ok, will wait then
2019-11-02 19:05:30 <_ikke_> first due to someone removing npm as subpackage from node, and now due to some depependency
2019-11-02 19:06:13 <mps> someone? doesn't have name or we got AI
2019-11-02 19:06:27 <_ikke_> I didn't care to remember who
2019-11-02 19:06:37 <_ikke_> the git history will tell you if you are curious
2019-11-02 19:06:50 <mps> ok, just kidding , np
2019-11-02 19:07:42 <mps> we all make breaking changes from time to time. and this is how improvement works
2019-11-02 19:08:42 <mps> and, also I have my parts of breaking things
2019-11-02 19:13:08 <_ikke_> cdp
2019-11-02 20:13:13 <_ikke_> Hunk #133 succeeded at 6597 with fuzz 2 (offset -16 lines).
2019-11-02 20:13:15 <_ikke_> arg
2019-11-02 20:13:23 <_ikke_> http://tpaste.us/Z0Pg
2019-11-02 20:13:29 <_ikke_> this patch took way too long to make
2019-11-02 20:13:46 <_ikke_> maxice8: you're welcome :)
2019-11-02 20:21:01 <_ikke_> builders are unstuck again
2019-11-02 20:23:13 <maxice8> Thank you
2019-11-02 20:23:22 <maxice8> +5k lines wew
2019-11-02 20:23:50 <_ikke_> I wanted to only update node-sass, but coult manage that
2019-11-02 20:24:00 <_ikke_> so I just did a yarn upgrade, which at least fixed it
2019-11-02 20:24:12 <_ikke_> s/coult/couldn't/
2019-11-02 20:24:12 <alpine-meetbot> _ikke_ meant to say: I wanted to only update node-sass, but couldn't manage that
2019-11-02 20:25:27 <_ikke_> ugh, now geos is failing on arm(hf|v7)
2019-11-02 20:26:11 <_ikke_> maxice8: that one is for you :P
2019-11-02 20:26:19 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/geos/geos-3.8.0-r0.log
2019-11-02 20:26:37 <maxice8> yes, passed on CI but is failing on the builders
2019-11-03 02:18:07 <russkel> if I want to compile the clang-tools-extra repo, should I just modify the clang APKBUILD to include it (as it's an extra project as a part of the clang build) or should I make a separate package?
2019-11-03 02:18:54 <maxice8> if it can be compiled without being in-tree for clang then at the moment separate
2019-11-03 02:19:17 <maxice8> avoids having to recompile clang every time you want to compile clang-tools-extra
2019-11-03 02:19:32 <russkel> it needs to be in tree
2019-11-03 02:19:46 <russkel> it relies on APIs provided by the clang project
2019-11-03 02:20:10 <maxice8> then i think in the APKBUILD itself
2019-11-03 02:21:09 <russkel> and when it comes to package()... is there a way to specify what targets go where?
2019-11-03 02:21:16 <russkel> I never found a nice way to do that..
2019-11-03 02:21:36 <russkel> presumably I'd pack the extra-tools into a subpackage
2019-11-03 07:34:02 <_ikke_> russkel: the common way to do it is to just let everything install in the default location in package(), and then in each subpackge function, you move the files from $pkgdir to $subpkgdir
2019-11-03 07:58:43 <russkel> ah by hand eh
2019-11-03 07:59:05 <russkel> not that I haven
2019-11-03 07:59:21 <russkel> haven't seen that, just surprised the tooling doesn't allow for something more elegant
2019-11-03 08:27:16 <russkel> there's a surprisingly lot of warnings while building clang with gcc haha
2019-11-03 10:54:31 <russkel> https://github.com/alpinelinux/aports/pull/12044
2019-11-03 14:36:17 <maxice8> oh wow i got apk to segfault after i compiled 2 different packages at the same time and both wrote to the APKINDEX
2019-11-03 14:36:22 <maxice8> :D had to delete the index otherwise apk would segfault
2019-11-03 14:38:58 <mps> could you reproduce it, would be good to fix it
2019-11-03 14:39:18 <maxice8> no, but i used docker-abuild to build 2 packages at the same time
2019-11-03 14:39:41 <maxice8> with enough RNGJesus and using very small packages that finish almost instantly like metapackages i think it can be reproduced
2019-11-03 14:40:56 <mps> and you deleted APKINDEX which triggered segfault?
2019-11-03 14:41:36 <maxice8> mindlessly yes
2019-11-03 14:41:56 <maxice8> was more concerned with reviewing @Cogitri 's cuetools package
2019-11-03 14:42:07 <maxice8> i triggered while building cuetools and ttaenc at the same time, both are new aports as Merge Requests
2019-11-03 14:42:19 <mps>  /o\ waiting for next
2019-11-03 14:49:04 <maxice8> :D keep building alpine-baselayout and alpine-mirrors in a loop
2019-11-03 14:49:08 <maxice8> you'll get it eventually
2019-11-03 14:49:19 <maxice8> also made an MR for helping detection of #!/bin/sh
2019-11-03 14:49:33 <maxice8> https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/7 :D also found by cuetools
2019-11-03 14:55:12 <mps> doesn't it works by default, spaces in shebang
2019-11-03 14:56:13 <maxice8> it does
2019-11-03 14:56:20 <maxice8> but on abuild we do grep '^#!/bin/sh'
2019-11-03 14:56:35 <maxice8> abuild will not detect scripts that install shebangs such as '#!  /bin/sh'
2019-11-03 14:56:40 <mps> aha, understand
2019-11-03 14:56:42 <maxice8> and will not automatically add /bin/sh to the dependencies
2019-11-03 16:27:22 <maxice8> Lots of MRs for main/ :D
2019-11-03 16:29:37 <tankf33der> is it good?
2019-11-03 20:16:13 <_ikke_> Most MRs are less than a week old, so not that bad
2019-11-03 21:17:23 <mps> interesting, tried few days (when had free time) to build svxlink on x86_64 and couldn't install man pages, moved same files to armv7 and all worked 'out of the box'
2019-11-03 21:17:45 <mps> cmake and abuild are same versions, and most build tools
2019-11-03 21:37:40 <_ikke_> ugh, due to this husky mess, I've accidentally deleted my applypatch-msg hook :(
2019-11-03 21:43:38 <maxice8> D:
2019-11-03 21:44:04 <maxice8> i keep my hooks in my dotfiles
2019-11-03 21:44:49 <maxice8> just in case i end up trashing the git repo
2019-11-03 21:46:31 <_ikke_> yeah, makes sense
2019-11-03 21:53:48 <_ikke_> luckily this hook is easily recreated
2019-11-03 22:08:21 <_ikke_> maxice8: cve MRs have been applied now
2019-11-03 22:11:09 <maxice8> yay
2019-11-03 22:11:09 <maxice8> ty
2019-11-04 07:54:04 <_ikke_> Would it make sense to automatically install bind-tools when installing bind https://gitlab.alpinelinux.org/alpine/aports/issues/10935?
2019-11-04 07:57:49 <mps> if we tend to be user friendly (less experienced admins) then yes, otherwise no, imo
2019-11-04 07:58:36 <_ikke_> Right now it's broken
2019-11-04 07:58:46 <_ikke_> but for reload support, it's kind of required
2019-11-04 07:59:06 <mps> yes, it should be fixed
2019-11-04 07:59:27 <mps> above, I spoke in general
2019-11-04 07:59:31 <_ikke_> nod
2019-11-04 08:00:51 <mps> _ikke_: I see you pushed libevent upgrade, we can expect now some pkgs breakage, need to work on upgrades
2019-11-04 08:01:29 <_ikke_> There were no sonamge changes?
2019-11-04 08:01:32 <_ikke_> soname
2019-11-04 08:02:00 <mps> I think something in ABI is changed
2019-11-04 08:02:11 <_ikke_> without soname bump?
2019-11-04 08:02:14 <_ikke_> :-/
2019-11-04 08:02:20 <mps> will look later when I finish with my $day_job
2019-11-04 08:12:06 <mps> if we bump pkgrel and push pkg will it be rebuilt wiht new libevent, for example tmux, firefox ....
2019-11-04 08:33:29 <clandmeter> morning
2019-11-04 08:33:41 <clandmeter> I have drafted a short terms page for gitlab.a.o
2019-11-04 08:33:46 <clandmeter> https://gitlab.alpinelinux.org/-/users/terms
2019-11-04 08:35:28 <clandmeter> would be cool if somebody who is native English could take a look at it and advise if needed.
2019-11-04 09:00:36 <Cogitri> clandmeter: Maybe make a MR or something, so that people can comment on it
2019-11-04 09:00:57 <_ikke_> An MR against what?
2019-11-04 09:01:47 <clandmeter> we can discus it here. we need something in place as we have to much spam and unwanted projects already.
2019-11-04 09:03:20 <Cogitri> ikke Good question, but commenting on it on IRC is a bit annoying
2019-11-04 09:03:44 <clandmeter> what is annoying about it?
2019-11-04 09:06:02 <TBB> not native, but 1. "Alpine Linux related projects", second mention, lacks a trailing s in the word projects, and 2. I'd personally replace "which do not follow" to just "not following".
2019-11-04 09:07:54 <clandmeter> TBB: thx, updated.
2019-11-04 09:08:44 <clandmeter> i guess we can also add a link to our coc
2019-11-04 09:10:09 <Cogitri> s/of which gitlab.com and github.com are possible examples./e.g. gitlab.com or github.com/
2019-11-04 09:11:16 <Cogitri> LGTM otherwise, but not a native speaker either
2019-11-04 09:14:43 <clandmeter> i think "or" makes them exclusive?
2019-11-04 09:18:03 <Cogitri> It's not xor :P
2019-11-04 09:21:28 <mps> I think 'of which gitlab.com and github.com are' is not needed
2019-11-04 09:22:05 <mps> 'other public services' is enough, imo
2019-11-04 09:30:54 <Cogitri> Hm, I think including examples is a good idea
2019-11-04 09:31:35 <mps> will be long list
2019-11-04 09:32:32 <Cogitri> Well, we don't have to include all of them, including the two major ones sounds good to me
2019-11-04 09:33:01 <mps> wrong, imo
2019-11-04 09:33:08 <Cogitri> (Although you could argue that we should include sr.ht or something too then, maybe just saying 'or other public git hosters' would be better after all)
2019-11-04 09:34:32 <mps> we shouldn't promote ones over others
2019-11-04 09:37:38 <mps> we can mention services which are our 'friends' (sr.ht, gitlab) but we download sources all over the net and all they are our 'friends' to some degree
2019-11-04 09:43:13 <PureTryOut[m]> For `flatpak-builder` to work, it requires the `fuse` kernel module to be loaded. Is it ok to auto load it in a `.post-install` file?
2019-11-04 09:48:04 <_ikke_> Wouldn't that break after the first reboot?
2019-11-04 09:49:26 <PureTryOut[m]> Sure, which is why I'm adding a conf file to `/etc/modules-load.d` as well
2019-11-04 09:50:48 <_ikke_> I'm not sure if this falls in the same category as enabling / starting services
2019-11-04 09:51:29 <clandmeter> we do not have an interface in place to do this afaik.
2019-11-04 09:53:03 <PureTryOut[m]> Uhm... `> GitLab: You (@PureTryOut) must accept the Terms of Service in order to perform this action. Please access GitLab from a web browser to accept these terms.`
2019-11-04 09:53:12 <PureTryOut[m]> Those terms of service changes have been rolled back, but the Alpine instance still asks me to accept them?
2019-11-04 09:53:24 <PureTryOut[m]> Oh wait
2019-11-04 09:53:26 <PureTryOut[m]> Nvm these are Alpine specific
2019-11-04 09:53:33 <clandmeter> :)
2019-11-04 09:56:49 <PureTryOut[m]> So I made this which enables the kernel module on default. Please let me know if there is a different way to do it or if it's frowned upon at all https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1064/diffs
2019-11-04 10:01:55 <clandmeter> PureTryOut[m]: post install should always exit properly
2019-11-04 10:02:08 <clandmeter> else the package will fail to install
2019-11-04 10:02:59 <PureTryOut[m]> So `exit 0`?
2019-11-04 10:04:24 <clandmeter> yes, not sure its mentioned on the wiki
2019-11-04 10:06:42 <clandmeter> similar to what we do when adding users
2019-11-04 10:06:52 <clandmeter> when a user already exist we need to exit 0
2019-11-04 10:15:40 <Cogitri> Yes, it's mentioned on the wili
2019-11-04 10:17:36 <_ikke_> lol
2019-11-04 10:28:46 <TBB> || true after adduser, standard practice when I did packaging
2019-11-04 10:29:27 <Cogitri> We don't do `set -e` in postinstall scripts so that shouldn't be required
2019-11-04 10:30:26 <TBB> yeah but if it's the last command in your post install script then it will return an error, and that's and elegant one-liner solution to that
2019-11-04 10:30:38 <TBB> *an
2019-11-04 10:31:20 <TBB> but admittedly since I started writing every shell script with all these checks, it's become a habit to do things like that
2019-11-04 11:06:05 <clandmeter> exit 0 is also a one liner :)
2019-11-04 11:21:47 <_ikke_> : is even shorter :)
2019-11-04 11:21:55 <_ikke_> But also more cryptic
2019-11-04 11:41:33 <_ikke_> Anything against letting bind depend on bind-tools? For rc-service bind reload to work, it needs to have a secret generated with rndc-confgen, which is in bind-tools (https://gitlab.alpinelinux.org/alpine/aports/issues/10935)
2019-11-04 12:09:58 <mps> _ikke_: iirc, this rndc-confgen should be started only on install or first start
2019-11-04 12:12:39 <_ikke_> mps: Isn't that what's happening? Whe installing bind, it checks if the key file exists. If not, it runs rnd-confgen
2019-11-04 12:12:53 <_ikke_> The problem is that rndc-confgen is part of bind-tools
2019-11-04 12:13:39 <mps> aha, yes
2019-11-04 12:14:06 <mps> I remember discussion with telmich
2019-11-04 12:15:09 <_ikke_> I found it in the log
2019-11-04 12:16:31 <_ikke_> So with this change, I guess we need to depend on bind-tools
2019-11-04 12:16:45 <_ikke_> But not sure if that's acceptable
2019-11-04 12:30:43 <mps> could this rndc-congen moved to bind-tools?
2019-11-04 12:31:06 <mps> and does it makes sense?
2019-11-04 12:32:59 <mps> I mean, script for rndc-confgen
2019-11-04 12:55:55 <_ikke_> It's already in bind-tools
2019-11-04 12:56:00 <_ikke_> it would need to be moved to bind
2019-11-04 13:54:16 <maxice8> lib3mf now ships an x86_64 binary in the build system to generate some "stuff"
2019-11-04 13:54:22 <maxice8> breaking all other arches :D
2019-11-04 13:55:02 <maxice8> https://github.com/3MFConsortium/lib3mf/tree/master/AutomaticComponentToolkit/bin
2019-11-04 14:27:16 <mps> hmm, '>>> ERROR: svxlink-sounds-en_us-heather-16k: builddeps failed' and pkg doesn't have any build deps
2019-11-04 14:27:47 <mps> arch="noarch"
2019-11-04 14:28:03 <mps> anyone know why it fails
2019-11-04 14:28:32 <_ikke_> mps: does apk fix return something?
2019-11-04 14:28:43 <mps> let's see
2019-11-04 14:29:16 <mps> OK: 532 MiB in 414 packages
2019-11-04 14:29:58 <mps> hmm, but looks like it works now
2019-11-04 14:30:09 <mps> (:
2019-11-04 16:04:36 <wsinatra> Looking back into package SBCL for arm, and it appears that version 1.4.11 is built for armhf, but the current iteration is 1.5.8 for x86_64. Is there any parameter to follow for packaging disparate versions of the same package?
2019-11-04 16:13:00 <_ikke_> wsinatra: abuild does not support it
2019-11-04 16:13:25 <wsinatra> I didn't think so, I couldn't find anything about it.
2019-11-04 16:13:27 <_ikke_> You could override the version based on arch
2019-11-04 16:13:45 <_ikke_> But not clue if that's deemed appropriate
2019-11-04 16:14:13 <wsinatra> Would an if elif fi work to substitute the variable? I feel like the lint tool might get angry
2019-11-04 16:14:23 <_ikke_> case $CARCH in arm*) pkgver=...;; esac
2019-11-04 16:14:49 <wsinatra> good point, case is a much better call for this if anything
2019-11-04 16:16:24 <wsinatra> I'll test it on my CI and see if the linter yells at me or not
2019-11-04 16:16:35 <_ikke_> alint should not
2019-11-04 16:16:45 <mps> is it enough to rebuild pkgs which depends on new libevent, i.e. bump pkgrel
2019-11-04 16:17:01 <_ikke_> mps: If it's purely an ABI issue, then yes
2019-11-04 16:19:37 <mps> _ikke_: is it worth creating MR's for all of them or you would just 'apkgrel' for pkgs in main
2019-11-04 16:19:56 <mps> fstrm is first one
2019-11-04 16:20:23 <_ikke_> I would just create a single MR for all of them
2019-11-04 16:20:27 <mps> I will do for those I tested in community and testing
2019-11-04 16:21:03 <mps> single MR will be 'big'
2019-11-04 16:21:13 <_ikke_> Maybe a couple then
2019-11-04 16:21:40 <mps> that looks better (to me at least)
2019-11-04 16:22:37 <mps> TBH, I'm too much accustomed to do such changes one by one
2019-11-04 16:23:18 <_ikke_> If it's just a pkgrel bump, it creates a lot more work if you create a MR for every single one of them
2019-11-04 16:24:56 <mps> well, understand, but I don't have much experience with 'bundled' commits
2019-11-04 16:25:50 <_ikke_> You just add more commits on top of a single branch
2019-11-04 16:25:57 <_ikke_> there is not much too it
2019-11-04 16:26:59 <mps> bump pkgrel, commit, repeat, repeat ... and single 'git push'?
2019-11-04 16:27:03 <_ikke_> yes
2019-11-04 16:27:32 <mps> ok, will try and see. it is time to learn it
2019-11-04 16:35:23 <mps> !1074
2019-11-04 16:35:38 <mps> it goes in reverse order to CI
2019-11-04 16:37:00 <_ikke_> fstrm has a test failure on s390x
2019-11-04 16:37:51 <mps> yes, see it now
2019-11-04 16:47:32 <agzotherma> I installed nginx using apk. I noticed that it automatically added a user nginx in my /etc/passwd. Where in the APK package can you define to add a user when installing the package?
2019-11-04 16:47:48 <_ikke_> agzotherma: it has to be done in the pre-install script
2019-11-04 16:48:42 <agzotherma> is the pre-install script part of the apk package? I do not see it when I untar the package
2019-11-04 16:49:30 <pedrolucasp> that's... kind of dangerous, right?
2019-11-04 16:49:38 <Cogitri> Look at the aports repo, it's in the same directory as nginx's APKBUILD
2019-11-04 16:49:51 <_ikke_> pedrolucasp: what is?
2019-11-04 16:49:54 <pedrolucasp> i mean, a install script making these modifications, like adding user, etc
2019-11-04 16:50:20 <pedrolucasp> dunno if other similar package installers (?) do the same stuff tho
2019-11-04 16:50:27 <_ikke_> yes
2019-11-04 16:50:39 <_ikke_> they do
2019-11-04 16:51:06 <_ikke_> although some offer a more declarative approach for common tasks as these as well
2019-11-04 16:51:25 <pedrolucasp> got it
2019-11-04 16:51:59 <agzotherma> ok, I found it in the aports repo. thanks!
2019-11-04 16:52:30 <maxice8> pedrolucasp: adding user for a package to use is something every package manager does in one form or another
2019-11-04 16:52:45 <maxice8> It is a basic thing
2019-11-04 16:52:56 <_ikke_> maxice8: I think they were commenting on the fact that it's a script that is run on installation
2019-11-04 16:53:15 <pedrolucasp> yeah, I just couldn't remember something like that on other package managers
2019-11-04 16:53:41 <pedrolucasp> is been a long time i've been away from linux tho
2019-11-04 16:53:43 <maxice8> ikke: that also is a basic of basic thing of package managers
2019-11-04 16:56:07 <mps> conservative unix admins are against install scripts, but nowadays who cares
2019-11-04 16:57:53 <maxice8> mps: people that want the package they install be mostly ready for usage / activated as a service
2019-11-04 16:58:42 <mps> yes, there are different peoples in this world :p
2019-11-04 16:59:26 <Cogitri> If you want something so minimal that it doesn't even create the users you can make a shellscript which just fetches the apk tarball and unpacks it on your /
2019-11-04 17:00:46 <mps> I just told that there are different people, not that I'm against install scripts
2019-11-04 17:01:19 <mps> I make pkgs with install scripts
2019-11-04 17:01:20 <maxice8> mps: fortunately there is --no-scripts
2019-11-04 17:01:26 <Cogitri> Yup, but we can't account for every edge case
2019-11-04 17:01:39 <mps> maxice8: good point
2019-11-04 18:05:01 <ncopa> this python 3.8 update was way bigger than expected
2019-11-04 18:05:12 <ncopa> i have 800 commits now after a weeks work
2019-11-04 18:10:32 <_ikke_> ncopa: what
2019-11-04 18:32:27 <mps> _ikke_: I'm thinking to close !1074
2019-11-04 18:32:54 <mps> and create MR's one by one, so that one failed CI not stop others
2019-11-04 18:33:38 <_ikke_> it doesn't
2019-11-04 18:33:57 <_ikke_> It's not like the official builders
2019-11-04 18:34:05 <_ikke_> each pipeline is independent
2019-11-04 18:34:32 <_ikke_> Or do you mean that fstrm does not stop the other packages?
2019-11-04 18:34:37 <mps> yes, but I suspect that anyone will push MR if it have at least one build error in CI
2019-11-04 18:35:00 <_ikke_> You don't *have* to close it
2019-11-04 18:35:16 <mps> fstrm is not relevant to tmux for example
2019-11-04 18:35:29 <_ikke_> With an interactive rebase you could drop that commit and force push the branch :)
2019-11-04 18:36:07 <mps> huh
2019-11-04 18:36:31 <_ikke_> git rebase -i master; remove the line with the fstrm commit. save + quit :)
2019-11-04 18:36:38 <mps> I prefer small steps
2019-11-04 18:37:08 <mps> I used to rebase for rewriting history ;)
2019-11-04 18:41:51 <mps> ok, done
2019-11-04 18:43:57 <mps> passed CI
2019-11-04 18:44:24 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1076
2019-11-04 18:45:54 <_ikke_> ncopa: any opinion on ^?
2019-11-04 18:46:26 <mps> why then split it to bind-tools
2019-11-04 18:46:42 <_ikke_> So that you can install bind-tools without install bind\
2019-11-04 18:47:02 <mps> makes sense
2019-11-04 18:48:15 <mps> and it makedepends on fstrm-dev
2019-11-04 18:49:09 <_ikke_> heh, didn't realize
2019-11-04 18:50:37 <mps> eh, I'm greping through aports searching libevent-dev
2019-11-04 18:51:42 <_ikke_> http://tpaste.us/5EY7
2019-11-04 18:51:44 <_ikke_> for main
2019-11-04 18:52:02 <_ikke_> for community: https://tpaste.us/vJ7W
2019-11-04 18:52:21 <_ikke_> for testing: https://tpaste.us/Qn48
2019-11-04 18:52:32 <mps> I see it locally as 'grep -r libevent-dev'
2019-11-04 18:52:39 <Danct12[m]> is it alright to upstream a ddos tool to alpine?
2019-11-04 18:53:31 <_ikke_> mps: I used ap (lua-aports)
2019-11-04 18:54:58 <mps> ehm, package which name I forgot, thanks for remind me
2019-11-04 19:03:19 <_ikke_> ncopa: thanks :)
2019-11-04 19:08:49 <_ikke_> mps: interesting: https://build.alpinelinux.org/buildlogs/build-edge-s390x/main/opensmtpd/opensmtpd-6.4.2p1-r2.log
2019-11-04 19:09:57 <_ikke_> mps: ugh, accidentally clicked on the close button for your MR
2019-11-04 19:11:29 <mps> yes, opensmtmd is also on list
2019-11-04 19:12:30 <mps> hmm, does this mean that libevent is not upgraded on s390x
2019-11-04 19:13:45 <mps> hmm, s390x CI segfault-ed on fstrm
2019-11-04 19:16:27 <mps> hm, builders have tmux installed?
2019-11-04 19:16:50 <_ikke_> Should not be the case
2019-11-04 19:17:03 <mps> https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/opensmtpd/opensmtpd-6.4.2p1-r2.log
2019-11-04 19:17:25 <_ikke_> Yeah, looking at it
2019-11-04 19:18:00 <_ikke_> removed it from armhf
2019-11-04 19:18:08 <_ikke_> I don't have access to s390x though
2019-11-04 19:18:42 <mps> lets see will it work on armhf now
2019-11-04 19:20:30 <_ikke_> armhf is happy now
2019-11-04 19:20:39 <mps> I see
2019-11-04 19:21:16 <mps> looks like remove tmux from s390x will solve issues
2019-11-04 20:00:51 <maxice8> mps: good work on libevent, i'll finally be able to run apk version without seeing it all the time :D
2019-11-04 20:11:26 <mps> maxice8: heh, but some pkgs need upgrade
2019-11-04 22:28:31 <mps> firefox doesn't build with python3
2019-11-04 22:32:16 <Cogitri> Yup, but upstream is currently in the process of porting their build system
2019-11-04 22:32:35 <Cogitri> (Or changing to Bazel, which I very much hope was just an out of season April's fools)
2019-11-04 22:33:24 <mps> hm, how then the current version of firefox in aports is built with python3
2019-11-04 22:33:44 <mps> (oh, no, no bazel)
2019-11-04 22:35:39 <maxice8> mps: I don't think it is, it problably uses python2 but not with it explicitly installed via makedepends= but rather via an implicit dependency that could have recently been changed to use python3 and is no longer bringing in python2?
2019-11-04 22:36:35 <mps> so, for now option is to revert to python2-dev
2019-11-04 22:38:02 <crosbymichael> how do i get around module deps when rebuilding new kernel versions
2019-11-04 22:38:03 <crosbymichael> ERROR: unsatisfiable constraints:
2019-11-04 22:38:03 <crosbymichael>   linux-vanilla-5.3.8-r0:
2019-11-04 22:38:03 <crosbymichael>     breaks: .makedepends-zfs-vanilla-20191104.173707[linux-vanilla=5.3.8-r1]
2019-11-04 22:38:03 <crosbymichael>     satisfies: world[linux-vanilla><Q1iyU06KUiCl67ujEL0a2QabilO0Q=] zfs-vanilla-5.3.8-r0[linux-vanilla=5.3.8-r0]
2019-11-04 22:38:04 <crosbymichael> >>> ERROR: zfs-vanilla: builddeps failed
2019-11-04 22:38:08 <crosbymichael> get errors like that
2019-11-04 22:38:32 <crosbymichael> i currently have 5.3.8 installed and rebuilding a rev=1 and recompile zfs-vanilla but I cant
2019-11-04 22:49:53 <mps> maxice8: with python2-dev it starts to work
2019-11-04 22:50:44 <mps> but on my newly degraded x86_64 I'll have to wait to long to see will it finish
2019-11-05 06:07:41 <Cogitri> crosbymichael: Build in a docker container with docker-abuild or use rootbld
2019-11-05 06:07:53 <Cogitri> Argh, he left again
2019-11-05 06:39:51 <mps> yes, I started last night to write answer but noticed he left short time after question
2019-11-05 06:43:00 <mps> Cogitri: is this known problem for rust 1.38 (latest in edge) '[14328.154208] traps: rustc[6704] general protection ip:7f59c5e36ea5 sp:7f598ad216b0 error:0 in libLLVM-9.so[7f59c5c50000+163d000]'
2019-11-05 06:45:24 <Cogitri> Yes, sadly we run into a SIGSEGV with rust at random points if LTO/optlevel=3 is enabled
2019-11-05 06:45:51 <Cogitri> I'll need to try if the same thing happens with Rust's bundled LLVM once I have a functional laptop again :)
2019-11-05 06:47:29 <mps> aha, ok. thanks for info
2019-11-05 07:40:11 <ncopa> mrning
2019-11-05 07:40:29 <ncopa> maxice8: why was geos downgraded? 3ed592696d66a7487666fb9b53cb6319ca62b953
2019-11-05 07:41:13 <_ikke_> Would be nice to have that kind of information in the commit message
2019-11-05 07:42:31 <Cogitri> fwiw he's sleeping right now
2019-11-05 07:43:40 <mps> anyone have idea what to do with firefox issue with python3-dev makedepends? revert back to python2-dev?
2019-11-05 07:44:06 <_ikke_> if it does not work with python3 and it's not easy fixable, then yes, reverting makes a lot of sense
2019-11-05 07:45:20 <mps> at least, build can commence while with python3-dev it fail on ./configire
2019-11-05 07:46:11 <mps> on my local machine didn't succeed because of GPF from rustc
2019-11-05 07:46:28 <ncopa> reverting back to python2 should be avoided if possible
2019-11-05 07:46:38 <mps> I think it is worth to try on builders
2019-11-05 07:47:07 <mps> firefox still requires python2
2019-11-05 07:48:17 <_ikke_> The build system that is
2019-11-05 07:48:53 <mps> _ikke_: yes
2019-11-05 07:50:14 <mps> and I don't understand how it passed earlier with python3 in makedepends, only if builders had python2 installed
2019-11-05 07:52:28 <_ikke_> transitive dependency?
2019-11-05 07:53:06 <mps> really have no idea about that
2019-11-05 07:53:48 <mps> I thought that builders for every pkg start from clean state
2019-11-05 07:54:28 <_ikke_> The builders have a minimal set of packages installed, the rest is all comming through dependencies and are removed again (like abuild -r does)
2019-11-05 07:54:30 <mps> tmux issue shows I  was wrong
2019-11-05 07:54:48 <_ikke_> Yea, like I said, tmux should not be installed on the builders, someone installed it manually
2019-11-05 07:55:28 <ncopa> probably me
2019-11-05 07:55:33 <ncopa> which builder is it?
2019-11-05 07:55:40 <_ikke_> s390x
2019-11-05 07:55:58 <mps> it was on armhf and _ikke_ removed it
2019-11-05 07:56:38 <mps> still on s390x, as _ikke_ says
2019-11-05 07:57:14 <ncopa> i'll fix it after breakfast
2019-11-05 10:32:37 <muhaha> is there alternative in alpine to https://packages.debian.org/stretch/libauthen-pam-perl ?
2019-11-05 13:29:07 <pltrz[m]> so i just installed edge. qtwebengine is broken because of a libevent rebuild. can i rebuild myself from aports so i don’t have to wait for it to get pushed to the repos?
2019-11-05 13:29:45 <pltrz[m]> by installed edge i mean i installed sys mode and using the edge branch
2019-11-05 13:31:35 <_ikke_> pltrz[m]: yes, you can
2019-11-05 13:48:02 <pltrz[m]> ok, i cloned aports, generates keys, `cd main/libevent` and `abuild -r`
2019-11-05 13:48:43 <_ikke_> You need to rebuild qtwebengine not libevent
2019-11-05 13:48:43 <pltrz[m]> it goes on but stops at the error: “libevent: Failed to create index”
2019-11-05 13:49:03 <pltrz[m]> derp
2019-11-05 13:49:04 <pltrz[m]> thx
2019-11-05 13:49:06 <pltrz[m]> will try
2019-11-05 13:50:26 <mps> will push qtwebengine in a few hours
2019-11-05 14:18:53 <pltrz[m]> so that build failed for some reason. the stdout and stderr for abuild are http://dpaste.com/34T2JWS.txt and http://dpaste.com/0R8SJ53.txt
2019-11-05 14:21:01 <pltrz[m]> at the end of the stderr it says “a suitable version of python2 could not be found. QtWebEngine will not be built.”
2019-11-05 14:22:58 <mps> pltrz[m]: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/qt5-qtwebengine/qt5-qtwebengine-5.12.5-r2.log
2019-11-05 14:23:09 <mps> same on builders
2019-11-05 14:23:15 <pltrz[m]> noticed there was just a push to aports for qtwebengine. will try rebasing the repo and trying again
2019-11-05 14:23:29 <pltrz[m]> oh i see
2019-11-05 14:24:17 <pltrz[m]> is it cause stuff is switching to python3 in aports?
2019-11-05 14:24:50 <mps> looks like that, but my lxc is in reparation right now
2019-11-05 14:26:03 <pltrz[m]> damn
2019-11-05 14:26:07 <pltrz[m]> let me know how i can help
2019-11-05 14:26:30 <pltrz[m]> i am just starting to get familiar with alpine packaging and apk in general
2019-11-05 14:26:44 <mps> problem line in build log: sed: /home/pltrz/aports/community/qt5-qtwebengine/pkg/qt5-qtwebengine/usr/lib/pkgconfig/*.pc: No such file or directory
2019-11-05 14:52:04 <clandmeter> mps: it shows it cannot find python
2019-11-05 15:06:22 <ncopa> seems like there are lots of packages broken due to libevent update?
2019-11-05 15:06:46 <clandmeter> it looks like it
2019-11-05 15:06:56 <clandmeter> somebody pushed it without rebuild
2019-11-05 15:07:46 <ncopa> looks liek libevent 2.0.10 -> 2.0.11 broke abi
2019-11-05 15:07:52 <ncopa> that was sort of unexpected
2019-11-05 15:08:38 <clandmeter> i dont know the details, its something between mps and _ikke_ afaik.
2019-11-05 15:10:57 <_ikke_> It was kind of unexpected for me as well
2019-11-05 15:11:29 <ncopa> i wonder if we could detect abi breakages in CI somehow
2019-11-05 15:13:39 <clandmeter> btw, do we still keep paxmark in apkbuilds?
2019-11-05 15:14:54 <ncopa> we dont need to anymore
2019-11-05 15:15:06 <ncopa> but i havent cared to remove either
2019-11-05 15:16:26 <clandmeter> that qt5-qtwebengine doesnt look pretty
2019-11-05 15:16:33 <clandmeter> lots of dup deps
2019-11-05 15:16:42 <clandmeter> and i think even some that are not needed.
2019-11-05 15:17:21 <clandmeter> i guess we should explicitly dep on python2 if needed
2019-11-05 15:17:35 <mps> clandmeter: aye, just added python2-dev in lxc and it builds
2019-11-05 15:17:46 <clandmeter> mps: i already pushed it
2019-11-05 15:17:55 <clandmeter> why dev?
2019-11-05 15:17:56 <mps> but I see you did it
2019-11-05 15:18:13 <mps> ah, right
2019-11-05 15:18:18 <mps> not dev
2019-11-05 15:19:32 <mps> ncopa: yes, there are pkgs which need to be rebuilt, but all one MR will too much
2019-11-05 15:21:12 <clandmeter> mps: do you have a list of pkgs that need a bump?
2019-11-05 15:21:43 <mps> I think _ikke_ have
2019-11-05 15:21:53 <_ikke_> http://tpaste.us/5EY7 https://tpaste.us/vJ7W https://tpaste.us/Qn48
2019-11-05 15:22:04 <_ikke_> main, community and testing
2019-11-05 15:22:11 <mps> I do it one by one one grepping through aports
2019-11-05 15:23:02 <mps> tmux is finished
2019-11-05 15:23:19 <mps> for links and fstrm I created MR
2019-11-05 15:23:50 <mps> !1080
2019-11-05 15:24:11 <mps> !1081
2019-11-05 15:24:25 <ncopa> can you please collecte them in a single MR?
2019-11-05 15:24:46 <clandmeter> that could cause issues with CI timeout
2019-11-05 15:25:02 <ncopa> collect them in 5 and five or similar then
2019-11-05 15:25:19 <mps> yes, I started that but it blocks on CI
2019-11-05 15:25:23 <clandmeter> or just small ones and bigger ones solo
2019-11-05 15:25:38 <clandmeter> i think only a few aports have timeout issues
2019-11-05 15:25:53 <mps> fstrm is small but it is stuck on s390x CI
2019-11-05 15:26:43 <mps> for community and testing I can do one by one
2019-11-05 15:27:16 <mps> I pushed some already
2019-11-05 15:29:53 <mps> btw, I think opensmtpd is already done by last night jirutka push
2019-11-05 15:35:17 <ncopa> good
2019-11-05 15:36:10 <mps> some shows issue despite just pkgrel bump
2019-11-05 16:15:20 <Cogitri> ncopa: Please take a look at pr12006
2019-11-05 16:15:24 <ncopa> i have 994 commits in queue now...
2019-11-05 16:15:31 <ncopa> for python 3.8 rebuilds
2019-11-05 16:16:39 <Cogitri> Oh, sorry, I had thought you got done with py3.8 yesterday
2019-11-05 16:16:47 <ncopa> Cogitri: i think we may need to wait til post 3.11 with D
2019-11-05 16:16:55 <Cogitri> Good luck with that then, hope it's not too boring
2019-11-05 16:16:57 <ncopa> im afraid it will slow down the release even more
2019-11-05 16:16:57 <_ikke_> ncopa: Really surprised it takes so much commits
2019-11-05 16:17:09 <Cogitri> (Or is boring good? :P)
2019-11-05 16:17:21 <ncopa> we have lots of py3-* packages
2019-11-05 16:17:31 <Cogitri> Well, I'd personally really like getting at least the GCC change into 3.11
2019-11-05 16:17:37 <ncopa> and lots of packages that provides python modules
2019-11-05 16:17:53 <ncopa> Cogitri: me too, but is it tested on all arches?
2019-11-05 16:17:56 <Cogitri> I can take care of the other stuff, just the GCC change would need to be in 3.11 since that's a requirement for the rest
2019-11-05 16:18:19 <ncopa> we should have builders up and running in october
2019-11-05 16:18:25 <ncopa> but python 3.8 took way too long
2019-11-05 16:18:29 <Cogitri> It's tested on all Drone CI arches
2019-11-05 16:18:40 <Cogitri> I can ask him to make a MR for better coverage
2019-11-05 16:18:54 <ncopa> i dont want spend another week on gcc to fix s390x and ppc64le
2019-11-05 16:19:36 <_ikke_> ncopa: lmk if I can help with something
2019-11-05 16:20:06 <ncopa> _ikke_: would be nice if you could merge som of the trivial MRs/PRs in main
2019-11-05 16:20:21 <_ikke_> sure, will be working on that
2019-11-05 16:20:30 <Cogitri> Well, would you be OK with it if he did a MR and as such had testing on all arches?
2019-11-05 16:20:51 <Cogitri> Or are we going to have to postpone it to GCC10 and as such Alpine 3.11?
2019-11-05 16:21:10 <Cogitri> Just unsure what to tell him, I hate letting contributor's stuff sit around without an explanation
2019-11-05 16:21:21 <ncopa> an MR would not hurt
2019-11-05 16:22:06 <Cogitri> Okie
2019-11-05 16:22:22 <ncopa> but gcc freeze for alpine 3.11 was in mid oct
2019-11-05 16:22:40 <ncopa> i think python 3.8 was a mistake
2019-11-05 16:23:07 <ncopa> \o/
2019-11-05 16:23:11 <ncopa> builds finished
2019-11-05 16:23:20 <Cogitri> Okie, so it'll be in 3.12 anyway
2019-11-05 16:23:34 <ncopa> i have 5-ish builds in testing that stil needs some work
2019-11-05 16:23:46 <ncopa> but i think im ready to merge python 3.8  now
2019-11-05 16:24:08 <ncopa> 10 packages
2019-11-05 16:24:50 <ncopa> but those shouldnt block setting up the 3.11 builders
2019-11-05 16:24:54 <ncopa> which i need to do now
2019-11-05 16:26:45 <ncopa> re PR 12006
2019-11-05 16:27:05 <ncopa> are we supposed to drop ADA support for D?
2019-11-05 16:28:08 <ncopa> ada requires full bootstrap
2019-11-05 16:28:30 <ncopa> so once its removed we cannot get it back unless we do a full bootstrap of gcc
2019-11-05 16:28:46 <ncopa> (or use gcc from some stable branch)
2019-11-05 16:28:47 <Cogitri> No, that was just temporary
2019-11-05 16:29:10 <ncopa> right, but if i merge as is, we cannot simply re'add it
2019-11-05 16:29:11 <Cogitri> I think our current gcc APKBUILD is broken on CI
2019-11-05 16:29:27 <ncopa> we'd need to bootstrap it from scratch
2019-11-05 16:30:04 <Cogitri> No, it's not required
2019-11-05 16:30:07 <Cogitri> We can keep ada and D at the same time :)
2019-11-05 16:30:33 <Cogitri> But building GCC on something that isn't the builders doesn't work, see e.g. https://github.com/alpinelinux/aports/pull/9517
2019-11-05 16:31:14 <Cogitri> Just strip the commit that removes ADA support, that's just to see that CI passes
2019-11-05 16:31:14 <ncopa> ah, yeah
2019-11-05 16:31:59 <Cogitri> We check for ada libs on GCC's configure but can't find them for some reason and I don't want to touch the GCC APKBUILD to figure out why it does that
2019-11-05 16:34:51 <ncopa> 1004 commits
2019-11-05 16:35:09 <ncopa> it will block the edge builders for a day or so
2019-11-05 16:36:50 <Cogitri> Phew
2019-11-05 16:36:59 <ncopa> pushed....
2019-11-05 16:37:23 <mps> taking popcorn :)
2019-11-05 16:37:28 <_ikke_> hgeh
2019-11-05 16:37:48 <mps> and watching #alpine-commits movie
2019-11-05 16:37:52 <_ikke_> me too
2019-11-05 16:41:50 <Cogitri> Quite the show, good work
2019-11-05 16:56:29 <ncopa> there are 9 packages in testing that needs to be fixed and rebuilt: apparmor, beancount, blender, hy, py3-whatever, py3-funcy, py3-jsonpickle, py3-junit-xml
2019-11-05 16:56:54 <ncopa> but it isnt a blocker for 3.11 release
2019-11-05 16:57:43 <ncopa> py3-shouldbe too
2019-11-05 17:08:07 <ncopa> i think i need to prioritize update chromium. there is a sec vulnerability
2019-11-05 17:08:28 <ncopa> https://www.pcmag.com/news/371701/use-chrome-update-your-browser-immediately
2019-11-05 17:08:49 <Cogitri> Yup
2019-11-05 17:09:07 <Cogitri> Sorry for not being a huge help right now, laptop is still absent :c
2019-11-05 17:09:59 <ncopa> Cogitri: no worries. you are a huge help
2019-11-05 17:13:55 <ncopa> there are a bunch of libevent rebuilds too
2019-11-05 17:15:57 <Cogitri> :)
2019-11-05 17:16:05 <Cogitri> I think mps wanted to take care of those?
2019-11-05 17:19:16 <_ikke_> I think mps can use some help
2019-11-05 17:20:38 <Cogitri> Ah, okie, it sounded to me like he only needed to test the thing and push it then
2019-11-05 17:22:23 <_ikke_> Is there some difference in musl that causes a test failure like this? ERROR   ] --- "1970-01-01T00:00:00" != "1969-12-31T16:00:00"
2019-11-05 17:22:30 <_ikke_> could cause8
2019-11-05 17:23:02 <mps> Cogitri: does it makes sense to push anything now and tomorrow :)
2019-11-05 17:23:28 <_ikke_> Not really
2019-11-05 17:23:50 <_ikke_> So I'm trying to figure out how to get the bind unittest suite fixed
2019-11-05 17:23:54 <_ikke_> just 2 tests are failing
2019-11-05 17:23:54 <mps> better to wait for python to finish
2019-11-05 17:25:04 <Cogitri> Right
2019-11-05 17:28:38 <Cogitri> Huh, #alpine-commits is still going :D
2019-11-05 17:28:52 <_ikke_> 1004 commits, 1 per second. Do the math
2019-11-05 17:29:48 <_ikke_> It just finished
2019-11-05 17:30:04 <Cogitri> Oh, it's limited to 1 per second, I thought it'd go as far as I can :)
2019-11-05 17:30:41 <_ikke_> it's even 1 per 3 seconds
2019-11-05 17:31:16 <Cogitri> Oh, okie
2019-11-05 17:31:50 <_ikke_> ncopa: Maybe we need something like this for Alpine Linux as well: https://gitlab.isc.org/isc-projects/bind9/issues/1306
2019-11-05 17:33:54 <Cogitri> I'd personally vote for using Milestones instead
2019-11-05 17:34:22 <Cogitri> I think with the amount of things we need to do before a release doing an issue which sums everything up is a bit too much work (and to read through)
2019-11-05 17:34:32 <Cogitri> And milestones allow nice filtering in the issue view
2019-11-05 17:36:48 <_ikke_> Yeah, that might be better indeed
2019-11-05 17:37:03 <_ikke_> But at least some kind of structured list of things to do
2019-11-05 17:37:18 <ncopa> yeah
2019-11-05 17:39:02 <_ikke_> I think a checklist is better for smaller steps
2019-11-05 17:42:39 <Cogitri> I think we can do smaller issues with smaller steps and add those to the milestone
2019-11-05 17:42:48 <Cogitri> E.g. make a `Convert to py 3.8` issue and add the 3.11 Milestone to that
2019-11-05 17:43:42 <_ikke_> Yeah, there is a difference between things specific for a certain release, and things to do for every release
2019-11-05 17:59:49 <ncopa> seems like async io test hangs on x86
2019-11-05 18:02:53 <_ikke_> ldb failed on s390x
2019-11-05 18:03:16 <_ikke_> _ldb.LdbError: (1, 'Failure during prepare_write): Corrupt database -> Operations error')
2019-11-05 18:03:56 <mps> ncopa: are you sure community/shards needs to be rebuilt with new libevent
2019-11-05 18:07:00 <mps> ah, you pushed nearly all, if not all of them
2019-11-05 18:10:55 <ncopa> mps: only chromium and firefox-esr are left
2019-11-05 18:11:03 <ncopa> and packages in testing
2019-11-05 18:11:48 <mps> chromium probably need some other fixes not only pkgrel bump
2019-11-05 18:11:57 <ncopa> it should be updated
2019-11-05 18:12:16 <mps> firefox-esr should have python2 in makedepends
2019-11-05 18:12:27 <ncopa> chromium patches needs to be rebased
2019-11-05 18:14:01 <mps> I would left chromium for Cogitri because he follows it's patches and fixes but he doesn't have working machine now
2019-11-05 18:15:52 <mps> well, with python3 update a lot is done
2019-11-05 18:16:22 <mps> we can now concentrate more on bug fixes
2019-11-05 18:17:11 <mps> only 'big thing' for next release left is kernel and kernel tools upgrade
2019-11-05 18:21:50 <_ikke_> TZ="America/Los_Angeles" date -d @0
2019-11-05 18:22:31 <_ikke_> Is there something I can do to make that work?
2019-11-05 18:22:42 <_ikke_> right now, it shows the time just in UTC
2019-11-05 18:23:09 <_ikke_> https://wiki.musl-libc.org/environment-variables.html
2019-11-05 18:24:14 <_ikke_> Ok, got it: apk add tzdata
2019-11-05 18:24:20 <_ikke_> now bind is happy
2019-11-05 18:32:32 <mps> hmm, ameba also doesn't need to be rebuilt with libevent
2019-11-05 18:34:09 <mps> did anyone considered 'pseudo' http://git.yoctoproject.org/cgit/cgit.cgi/pseudo as replacement for fakeroot
2019-11-05 18:41:46 <_ikke_> runtime error: file file:///usr/share/xml/docbook/xsl-stylesheets-1.79.2/lib/lib.xsl line 56 element variable
2019-11-05 18:41:59 <_ikke_> samba failing on armv7
2019-11-05 18:44:10 <mps> is the docbook-xsl upgraded on armv7
2019-11-05 18:45:09 <_ikke_> https://pkgs.alpinelinux.org/packages?name=docbook-xsl&branch=edge
2019-11-05 18:45:13 <_ikke_> they're all equal
2019-11-05 18:48:02 <mps> hmm, I tested samba build about week ago but can't remember on aarch64 or armv7, but went well
2019-11-05 20:11:13 <_ikke_> maxice8: I have this time a false negative for apkbuild-lint :)
2019-11-05 20:12:17 <maxice8> yes ? i have one for capital letters in variables
2019-11-05 20:12:34 <_ikke_> I have one for custom variables that have a valid variable name as prefix
2019-11-05 20:12:57 <_ikke_> depends_foo is accepted
2019-11-05 20:30:10 <_ikke_> maxice8: ok, I think I have a fix
2019-11-05 20:31:33 <_ikke_> https://regex101.com/r/qhVwsP/1
2019-11-05 20:46:29 <_ikke_> maxice8: https://gitlab.alpinelinux.org/Leo/atools/merge_requests/23
2019-11-05 20:51:24 <ncopa> git also fails with new docbook-xsl
2019-11-05 20:51:47 <ncopa> I'll see if i find a fix tomorrow
2019-11-05 20:52:09 <ncopa> iirc there was another package that broke with new docbook-xsl, but i managed to find a patch
2019-11-05 20:59:47 <jailbox> did a local patch on busybox, bump from -r3 -> -r3a, did upgrade ( from -2 -> -r3a) and got an error after exec busybox-1.30.1-r3a.trigger
2019-11-05 21:00:07 <_ikke_> What error?
2019-11-05 21:00:43 <jailbox> no text just "1 error; xx mib in xx pkgs"
2019-11-05 21:01:11 <jailbox> where to find what the error was ?
2019-11-05 21:01:35 <_ikke_> apk fix will try to run it again
2019-11-05 21:01:50 <jailbox> hmm, let me try
2019-11-05 21:02:34 <jailbox> ehh, error groff-doc trying to overwrite som man page
2019-11-05 21:03:23 <jailbox> upgrade did busybox, libmagic,file,tiff,file-doc,tiff-doc
2019-11-05 21:05:27 <jailbox> exact error : reinstalling groff-doc (1.22.4-r0)
2019-11-05 21:05:29 <jailbox> ERROR: groff-doc-1.22.4-r0: trying to overwrite usr/share/man/man1/soelim.1.gz owned by mdocml-doc-1.14.3-r3
2019-11-05 21:07:36 <_ikke_> A package conflict, but no idea where that comes from
2019-11-05 21:16:38 <jailbox> well both groff-doc.apk and mdocml-doc.apk contain's .../man7/roff.7.gz and .../man1/soelim.1.gz ( mutual exclusive pkg's ?)
2019-11-06 08:45:48 <_ikke_> py-scandir fails on (arm(hf|v7)|x86(
2019-11-06 08:49:05 <ncopa> _ikke_: i'll have a look at that later. im looking at docbook-xsl and samba right now
2019-11-06 08:50:10 <ncopa> mps: commit meesage for 218abcf559420f71eb7f8f96b0c066ffa7f62590 claims that the non-recursive_string_subst.patch is no longer needed, but samba fails
2019-11-06 08:50:43 <ncopa> does that mean that samba docs needs to be fixed or is the patch actually needed?
2019-11-06 08:53:25 <mps> ncopa: will look later this afternoon, but from head docbook-xsl with this patch breaks build some pkgs (po4 and some others)
2019-11-06 08:53:51 <mps> now I'm busy with some issues on $day_job
2019-11-06 08:54:35 <mps> po4a* and po4, sorry
2019-11-06 08:56:50 <mps> I will add it back and try to build samba with docbook-xsl with this patch
2019-11-06 09:04:07 <ncopa> i'm on it
2019-11-06 09:04:21 <ncopa> i have rebased the patch already
2019-11-06 09:04:30 <ncopa> and are trying to build samba now
2019-11-06 09:05:45 <mps> aha, ok, but don't forget to try po4a with it at least
2019-11-06 09:05:52 <ncopa> yeah, properly rebasing the patch makes it build samba again
2019-11-06 09:07:18 <ncopa> yup, po4a builds too
2019-11-06 09:07:27 <mps> _ikke_: do you remember which pkgs had issues with docbook-xsl with this patch
2019-11-06 09:07:47 <ncopa> i think the problem was that the first hunk in the patch was removed rather than rebased
2019-11-06 09:07:59 <mps> oh, or it was maxice8 , sorry
2019-11-06 09:08:05 <ncopa> in commit 163ac6aeef12affd8b0296e5c491fa944f313d63.
2019-11-06 09:08:59 <_ikke_> mps: Yeah, I don't know a lot about it
2019-11-06 09:09:29 <ncopa> i pushed docbook-xsl update
2019-11-06 09:09:32 <mps> could be, but I can't see it right now, I'm on some kind of 'business meeting'
2019-11-06 09:09:45 <ncopa> i'm following it up
2019-11-06 09:09:49 <ncopa> to unblock builders
2019-11-06 09:11:28 <mps> interesting that the po4a builds again (: but that's fine
2019-11-06 09:13:45 <mps> ah, I remember, I wanted to add -doc to iputils and because of that I played with docbook-xsl
2019-11-06 09:14:48 <mps> (can't understand why people write man pages in xml)
2019-11-06 10:17:40 <kunkku> question on Python package naming: are they now supposed to be prefixed with "py3-" rather than "py-"?
2019-11-06 11:09:08 <clandmeter> i think py3 is what is used most, and py- would have a install_if depended on the installed python version.
2019-11-06 11:09:52 <clandmeter> py2 is going to be removed afaik, but i dont think its wise to change all of the pkgnames.
2019-11-06 12:04:45 <_ikke_> That's already happening
2019-11-06 12:09:47 <igor-petruk> Hi team, would it be possible to comment on https://gitlab.alpinelinux.org/alpine/aports/issues/9074#note_53891, is there any work on this? It is pretty important to boost contributions to Alpine, and maybe easy to fix (I don't know)
2019-11-06 12:10:04 <igor-petruk> This is about adding LICENSE to aports repo
2019-11-06 12:10:12 <igor-petruk> Thanks
2019-11-06 12:11:00 <igor-petruk> Mabye the some license is implied, as it is documented elsewhere. Then it should be super easy to put the file there too
2019-11-06 12:20:08 <ncopa> kunkku: yes, we concluded with that we'd use py3- rather than py-
2019-11-06 12:20:23 <ncopa> there is a circular dep in py3-automat
2019-11-06 12:20:39 <ncopa> it has a checkdepends on py3-twisted
2019-11-06 12:20:50 <ncopa> and py3-twisted depends on py3-automat
2019-11-06 12:24:34 <ncopa> seems like py3-automat depends was added in fb7cae7994619fcfaeb63fcc805efa49a8a1dab5
2019-11-06 12:27:27 <maxice8> fixed, thanks for bringing to attention
2019-11-06 12:28:00 <ncopa> thanks!
2019-11-06 12:28:21 <maxice8> not completely fixed, py3-twisted is an optional dependency for a subsection of functionality
2019-11-06 12:28:33 <maxice8> i'll see if i can cut the tests so it runs only tests not related to that functionality
2019-11-06 12:28:40 <maxice8> so we can still run tests but not tests that require a dep that causes a circular dep
2019-11-06 12:28:51 <ncopa> yeah, that makes sense
2019-11-06 12:29:10 <ncopa> i also wonder why twisted uses automat
2019-11-06 12:29:15 <ncopa> where
2019-11-06 12:29:20 <ncopa> i see it in setup.py
2019-11-06 12:29:36 <ncopa> but I dont find anything importing it?
2019-11-06 12:29:58 <maxice8> but in the meantime tests are disabled and the builder shouldn't be spinning round
2019-11-06 12:30:08 <ncopa> ok
2019-11-06 12:30:12 <ncopa> i found it
2019-11-06 12:30:22 <ncopa> build/lib.linux-x86_64-3.8/twisted/application/internet.py
2019-11-06 12:30:22 <ncopa> 54:from automat import MethodicalMachine
2019-11-06 12:30:57 <ncopa> so, yeah, the correct fix is to disable the tests in py3-automat that uses py3-twisted
2019-11-06 12:31:24 <maxice8> i'll fix it soon, have to shower to do a band-aid changed
2019-11-06 12:33:22 <maxice8> done
2019-11-06 12:33:29 <maxice8> also added missing depend on py3-pluggy :D
2019-11-06 12:33:37 <ncopa> good
2019-11-06 12:33:58 <ncopa> is the py3-crypto correct? should it not be py3-cryptography?
2019-11-06 12:34:45 <ncopa> for py3-twisted
2019-11-06 12:35:00 <_ikke_> ncopa: is it expected that I get this error for python3 on edge now? "Error relocating /usr/lib/libpython3.8.so.1.0: copy_file_range: symbol not found"
2019-11-06 12:35:18 <ncopa> no
2019-11-06 12:36:00 <ncopa> maxice8: i think py3-twisted should depend on py3-cryptography instead of py3-crypto
2019-11-06 12:36:03 <_ikke_> docker run --rm -it alpine:edge /bin/sh -c 'apk add -U python3; python3'
2019-11-06 12:37:03 <ncopa> run apk upgrade
2019-11-06 12:37:29 <ncopa> i need to tag new edge snapshot
2019-11-06 12:37:34 <maxice8> http://ix.io/20Yd :D
2019-11-06 12:37:40 <ncopa> will do that as soon as the builders are done
2019-11-06 12:37:53 <_ikke_> ncopa: nod
2019-11-06 12:38:00 <maxice8> ncopa: seems fine to me py3-crypto is pycrypto and py3-cryptography is cryptography
2019-11-06 12:38:18 <ncopa> but where does it say that it uses py3-crypto?
2019-11-06 12:38:24 <ncopa> pycrypto
2019-11-06 12:38:40 <ncopa> the _setyp.py mention cryptography, but not pycrypto
2019-11-06 12:38:46 <ncopa> hum
2019-11-06 12:38:59 <ncopa> tests fails with py3-cryptography too
2019-11-06 12:39:06 <ncopa> i'll have a coffe break. brb
2019-11-06 12:43:35 <kunkku> I'm a bit confused about the py3 migration
2019-11-06 12:44:49 <kunkku> for example, main/py-country was moved to unmaintained and then testing/py3-pycountry was moved to main in the next commit
2019-11-06 12:45:05 <kunkku> so package name changed for no apparent reason
2019-11-06 12:46:09 <_ikke_> That doesn't make sense..
2019-11-06 13:15:59 <ddevault> https://builds.sr.ht/~sircmpwn/job/105234
2019-11-06 13:16:02 <ddevault> seems the meson package has some issues
2019-11-06 13:16:06 <ddevault> can someone rebuild it?
2019-11-06 13:17:41 <ncopa> kunkku: i guess someone is trying to standardize on py3-$upstreamname
2019-11-06 13:18:08 <ncopa> so pycountry -> py3-pycountry instead of pycountry -> py3-country
2019-11-06 13:18:25 <ncopa> which makes sense to me
2019-11-06 13:18:29 <ddevault> +1
2019-11-06 13:18:35 <ncopa> but we should probably doc that somewhere
2019-11-06 13:18:44 <ncopa> didnt we have a python policy doc?
2019-11-06 13:18:56 <ddevault> https://wiki.alpinelinux.org/wiki/Python_package_policies
2019-11-06 13:19:07 <ddevault> >Set _pyname to the name of the package on PyPI
2019-11-06 13:19:12 <ddevault> already in the guidelines
2019-11-06 13:19:14 <_ikke_> ddevault: python3 is being upgraded atm
2019-11-06 13:19:47 <ncopa> ddevault: what arch is having issues?
2019-11-06 13:19:52 <ddevault> x86_64
2019-11-06 13:19:58 <ddevault> but I'm guessing this would affect them all
2019-11-06 13:20:02 <ddevault> on edge
2019-11-06 13:20:08 <ddevault> but if python is being upgraded, that's the issue
2019-11-06 13:20:20 <clandmeter> arent the builders still processing the 1000+ commits from yesterday?
2019-11-06 13:20:23 <_ikke_> yes
2019-11-06 13:21:20 <ncopa> ddevault: I caonnt see that python is getting installed in https://builds.sr.ht/~sircmpwn/job/105234
2019-11-06 13:21:44 <ncopa> i think you may need upgrade the base image or whatever you are using
2019-11-06 13:21:46 <ddevault> the existence of a python traceback in the second step suggests that python is installed
2019-11-06 13:22:02 <_ikke_> So it's already installed
2019-11-06 13:22:05 <ddevault> aye
2019-11-06 13:22:08 <ncopa> yes, but it may get it from an oudated place
2019-11-06 13:22:12 <ncopa> and need to be upgraded
2019-11-06 13:22:25 <ddevault> aight
2019-11-06 13:22:26 <clandmeter> his env is mostly based on python iirc
2019-11-06 13:22:36 <ncopa> i think main repo should have python3.8 now
2019-11-06 13:22:40 <ncopa> community not yet
2019-11-06 13:22:41 <clandmeter> it does
2019-11-06 13:22:44 <clandmeter> just checked
2019-11-06 13:22:53 <ddevault> regenerating my alpine image, anyway
2019-11-06 13:22:57 <ddevault> we'll see if it helps
2019-11-06 13:23:17 <ncopa> deps in community will likely be broken til community repo builds are done
2019-11-06 13:23:30 <clandmeter> but i guess the modules that are not build are still linked against 3.7?
2019-11-06 13:23:45 <ddevault> aye, I would imagine that's the case
2019-11-06 13:23:57 <ncopa> python packagse in community is still python3.7
2019-11-06 13:24:14 <_ikke_> Isn't this the opposite case?
2019-11-06 13:24:26 <_ikke_> It looks for 3.7, but meson seems to be already 3.8?
2019-11-06 13:24:26 <ncopa> the builders needs to complete the community repo before its synced to dl-master
2019-11-06 13:24:55 <ncopa> yeah, so a refresh of the alpine image may solve it
2019-11-06 13:25:11 <ncopa> will likely solve the issue at hand
2019-11-06 13:25:14 <ddevault> I think the mercurial package may be broken as well
2019-11-06 13:25:22 <ddevault> which prevents the image verification tests from passing
2019-11-06 13:25:42 <ncopa> it needs to be updated i think
2019-11-06 13:26:07 <ncopa> mercurial should be rebuilt with python 3.8 already b79c7915dbd3bbc45b14c733ca35fd09ad8ab0b2
2019-11-06 13:26:28 <ncopa> make sure you get 5.1.2-r1
2019-11-06 13:26:35 <_ikke_> it's already rebuilt
2019-11-06 13:26:40 <_ikke_> https://pkgs.alpinelinux.org/contents?branch=edge&name=mercurial&arch=x86_64&repo=main
2019-11-06 13:26:50 <ddevault> 5.1.2-r1 is what we got
2019-11-06 13:26:54 <ddevault> but hg: not found
2019-11-06 13:27:25 <ddevault> bash: /usr/bin/hg: /usr/bin/python3: bad interpreter: No such file or directory
2019-11-06 13:27:28 <ddevault> o_O
2019-11-06 13:27:41 <ddevault> (3/4) Purging python3 (3.7.5-r1)
2019-11-06 13:27:48 <ddevault> does it... not depend on python anymore?
2019-11-06 13:28:06 <_ikke_> yeah, it appears so
2019-11-06 13:28:06 <ncopa> lol
2019-11-06 13:30:13 <ncopa> that seems to be an old bug
2019-11-06 13:30:16 <ncopa> very old
2019-11-06 13:30:26 <ncopa> i wonder how mercurial ever worked
2019-11-06 13:30:53 <ddevault> I got this error by spinning up an alpine/edge machine based on the latest image (yesterday's) and running apk upgrade -U
2019-11-06 13:30:58 <ddevault> so it worked as of yesterday
2019-11-06 13:31:09 <ncopa> the question is why it worked yesterday
2019-11-06 13:31:48 <ncopa> because it looks like it has been broken since 2012 1a64abeee622949cdd072c2fd8446d9f30fdc488
2019-11-06 13:32:14 <ncopa> i guess there may be some C module or similar that pulled in python indirectly?
2019-11-06 13:32:15 <ddevault> fwiw, hg 5.0 runs on python 3 now
2019-11-06 13:32:33 <ddevault> maybe during the overhaul they dropped native stuff?
2019-11-06 13:32:35 <_ikke_> Someone already changed python2-dev to pytho3-dev in makedepends
2019-11-06 13:33:05 <ncopa> ok
2019-11-06 13:33:12 <ncopa> i think i have an explanation on what happened
2019-11-06 13:34:25 <ncopa> there are some python modules implemented in C
2019-11-06 13:34:46 <ncopa> i guess that before python 3.8, those was (incorrectly) linked against libpython
2019-11-06 13:35:31 <ncopa> due to before python 3.8, python3-conflig --libs would include libpython
2019-11-06 13:35:55 <ncopa> from python 3.8, you need use python3-config --embed --libs
2019-11-06 13:36:10 <ncopa> if you intend to embed python in your app
2019-11-06 13:36:42 <ncopa> so yesterday, the merculrial python modules would pull in python as dependency due to so:libpython.so
2019-11-06 13:36:58 <ncopa> after python 3.8, that no longer happens
2019-11-06 13:37:05 <ncopa> so it no longer pulls in python as dep
2019-11-06 13:37:07 <ddevault> nice catch
2019-11-06 13:37:23 <ncopa> the proper fix is to add explicit depends
2019-11-06 13:37:52 <clandmeter> ah that makes sense
2019-11-06 13:37:59 <clandmeter> i think i had another case yesterday
2019-11-06 13:38:18 <ncopa> i bumped into various breakages that required --embed
2019-11-06 13:38:20 <clandmeter> but i think that was before your 1k commit push
2019-11-06 13:38:37 <ncopa> or pkg-config libpython3-embed
2019-11-06 13:46:57 <ncopa> hum, i wonder what the deal with pyt3-twisted was
2019-11-06 13:47:12 <ncopa> i remember battling twisted while doing the rebuild
2019-11-06 13:47:20 <ncopa> but apparently i messed soemthing while rebasing
2019-11-06 13:47:55 <ncopa> iirc i had a patch for python 3.8
2019-11-06 13:57:45 <AinNero> testing/mono ships xbuild, which itself tells its deprecated when used
2019-11-06 13:58:08 <AinNero> the new command is msbuild, its included in upstream afaik, but does not end up in the alpine package
2019-11-06 13:58:16 <AinNero> has prior work been done on this?
2019-11-06 13:59:29 <_ikke_> AinNero: the package just runs make install
2019-11-06 13:59:40 <AinNero> ill investigate..
2019-11-06 13:59:44 <_ikke_> https://git.alpinelinux.org/aports/tree/testing/mono/APKBUILD
2019-11-06 14:32:09 <ncopa> ok, i figured out whats wrong in twisted testsuite
2019-11-06 14:32:21 <ncopa> the CramMD5 tests are broken
2019-11-06 14:32:41 <ncopa> https://docs.python.org/3/library/hmac.html
2019-11-06 14:33:07 <ncopa> apparently prior to 3.8, hmac.new set digestmod to md5 by default
2019-11-06 14:33:19 <ncopa> from python 3.8 the digestmod arg is required
2019-11-06 14:34:59 <igor-petruk> Were there any previous discussions about aports repo LICENSE, just to get up to speed, e.g. blockers?
2019-11-06 14:39:42 <ncopa> igor-petruk: sorry for not yet follow up that
2019-11-06 14:39:52 <ncopa> i'm trying to unblock the builders....
2019-11-06 14:40:15 <igor-petruk> no problem :)
2019-11-06 14:40:17 <igor-petruk> Thanks
2019-11-06 14:40:18 <ncopa> igor-petruk: if i dont respond later today, can you please ping me tomorrow?
2019-11-06 14:40:27 <igor-petruk> yes, sure. In the bug?
2019-11-06 14:40:32 <ncopa> no, in IRC
2019-11-06 14:40:39 <igor-petruk> ack, thank you very much again
2019-11-06 14:40:43 <igor-petruk> will do
2019-11-06 14:40:47 <ncopa> i get too many pings in bugs and PRs
2019-11-06 14:40:58 <ncopa> thank you
2019-11-06 14:41:13 <ncopa> maxice8: im pretty sure that twisted is broken with python 3.8
2019-11-06 14:41:22 <ncopa> at least the CramMD5 stuff
2019-11-06 14:41:36 <ncopa> i dont know if we should report it upstream or just fix it
2019-11-06 14:42:35 <maxice8> You do whichever you feel is better, I'm at the bank to close my account so Im being dragged along burocratically
2019-11-06 14:42:58 <ncopa> :) ok. have fun! :D
2019-11-06 14:45:27 <ncopa> any python hackers that want to follow up the py3-twisted issues with python 3.8?
2019-11-06 14:45:30 <ncopa> report upstream
2019-11-06 14:45:33 <ncopa> etc
2019-11-06 14:45:37 <ncopa> and provide patches
2019-11-06 14:48:46 <_ikke_> ncopa: I can try to follow up on that one
2019-11-06 14:55:10 <ncopa> i disabled tests for now
2019-11-06 14:55:23 <ncopa> there are 15 tests that fails
2019-11-06 14:55:42 <ncopa> some of them are CramMD5, which i think only needs digestmod=md5 arg
2019-11-06 14:55:46 <ncopa> or 'MD5'
2019-11-06 14:55:59 <ncopa> i have no clue how to specify md5 digest
2019-11-06 14:56:16 <ncopa> https://docs.python.org/3/library/hmac.html
2019-11-06 14:56:29 <ncopa> for hmac.new:
2019-11-06 14:56:32 <ncopa> Deprecated since version 3.4, will be removed in version 3.8: MD5 as implicit default digest for digestmod is deprecated. The digestmod parameter is now required. Pass it as a keyword argument to avoid awkwardness when you do not have an initial msg.
2019-11-06 14:59:44 <_ikke_> ncopa: https://gitlab.alpinelinux.org/alpine/aports/issues/10939
2019-11-06 14:59:50 <_ikke_> otherwise I forget
2019-11-06 15:00:55 <ncopa> great! thanks!
2019-11-06 15:40:29 <tmhoang> Cogitri, mps: do you have a script or brief steps on how to cross compile rust ? I'm using glibc s390x rust btw
2019-11-06 15:40:54 <tmhoang> I believe you must have once using glibc x86_64 rust to compile must x86_64 rust , right ?
2019-11-06 15:50:37 <mps> tmhoang: no, I used rust from adelie linux
2019-11-06 15:54:28 <tmhoang> right
2019-11-06 15:57:46 <Cogitri> I used Void Linux's xbps-src. But you can either compile from s390x glibc to s390x musl or some arch musl to s390x musl, it doesn't really matter
2019-11-06 15:59:54 <tmhoang> Cogitri: agreed. Point here is I'm pretty unknown to rust and have no idea how to just cross compile from rust x86 glibc to rust x86 musl neither. Some initial scripts/steps would be really appreciated
2019-11-06 16:01:17 <AinNero> okay, i got a source for the dubious msbuild binary now
2019-11-06 16:01:36 <AinNero> is it acceptable to fetch a binary and store it as apk if its architecture independent?
2019-11-06 16:03:36 <_ikke_> Usually it's not
2019-11-06 16:16:06 <AinNero> ... it has itself as build dependency
2019-11-06 16:17:10 <_ikke_> so it needs to be bootstrapped somehow
2019-11-06 16:18:34 <AinNero> void linux re-packages the centOS rpm from upstream page
2019-11-06 16:18:38 <AinNero> gosh this stuff is so awful
2019-11-06 16:22:06 <Cogitri> tmhoang: I can recommend you to take a look at Void Linux's `template` for that
2019-11-06 16:22:33 <Cogitri> https://github.com/void-linux/void-packages/blob/master/srcpkgs/rust/template
2019-11-06 16:23:01 <Cogitri> They use the config.toml approach to configure rustc instead of using ./configure like we do, but most config.toml options map 1:1 to ./configure
2019-11-06 16:24:19 <Cogitri> Getting the crosscompiled rustc _should_ be as easy as setting `--build` to s390x glibc and both `--host` and `--target` to s390x musl
2019-11-06 16:25:08 <Cogitri> And the stuff under `[target.${RUST_BUILD}]`
2019-11-06 16:26:04 <Cogitri> This: https://github.com/void-linux/void-packages/blob/master/srcpkgs/rust/template#L215
2019-11-06 16:26:11 <Cogitri> (do note that CC, CXX etc. is the crosscompiler in Void, CC_host is the native one)
2019-11-06 16:27:37 <Cogitri> And you'll have to add the triplet for s390x, look at https://gitlab.alpinelinux.org/alpine/aports/blob/master/community/rust/alpine-target.patch to see how we do that
2019-11-06 16:28:02 <Cogitri> Feel free to ask me if you need help, but I can't help with code due to my laptop going to repair
2019-11-06 16:33:09 <_ikke_> Cogitri: I feel for you. I had an issue with my laptop as well and didn't have anything else to work on
2019-11-06 16:34:32 <Cogitri> :/
2019-11-06 16:38:56 <tmhoang> Cogitri: looks good, I'm trying your steps
2019-11-06 16:42:12 <Cogitri> 👍
2019-11-06 17:17:05 <mps> tmhoang: send one of your s390x boxes and the problem will be over :)
2019-11-06 17:17:17 <mps> to Cogitri
2019-11-06 17:58:43 <Cogitri> Heh, I'm sure those are very easy to ship :P
2019-11-06 17:58:53 <Cogitri> mps: FWIW NetworkManager 1.20.6 includes the patch for compat with iwd 1.0
2019-11-06 17:59:28 <mps> yes, I see it and wanted to tell you but wait till you appear here
2019-11-06 17:59:37 <mps> and you already saw
2019-11-06 18:00:22 <Cogitri> Yup, am on the GNOME release mailing list
2019-11-06 18:00:30 <mps> can you upgrade it (I'm asking because of missing notebook)
2019-11-06 18:00:49 <Cogitri> Sadly no :/
2019-11-06 18:01:01 <mps> ok, I will try
2019-11-06 18:03:47 <Cogitri> Good luck :)
2019-11-06 18:04:36 <mps> I did once with big version leap, 1.12 to 1.16 iirc
2019-11-06 18:47:27 <mps> Cogitri: NM passed on aarch64 (with warnings from compiler but this is usual)
2019-11-06 19:00:15 <mps> !1126
2019-11-06 19:00:31 <mps> lets see will it pass all CI's
2019-11-06 19:05:57 <mps> good, it passed all, only waiting for aarc64
2019-11-06 20:02:41 <mps> aarch64 CI doesn't work? or it is overloaded
2019-11-06 20:40:59 <maxice8> good lord py3-twisted keeps failing because of usage of rm -v
2019-11-06 20:41:10 <maxice8> 10 commits after that was fixed
2019-11-06 20:43:13 <_ikke_> Hmm, I don't see rm -v in the aports dir on the builder
2019-11-06 20:45:40 <mps> uhm, a lot of pkgs are in build queue on builders
2019-11-06 20:46:02 <_ikke_> Yes, but it should still pick up fixes
2019-11-06 20:46:04 <mps> I pushed NM to early
2019-11-06 20:52:10 <mps> is the aarrch64 builder stuck for some reason? it still shows firefox-esr
2019-11-06 20:53:55 <_ikke_> No, it doesn't seem stuck
2019-11-06 20:54:12 <_ikke_> It's still building, I see new processes
2019-11-06 20:54:34 <nmeum> regarding py3-twisted: I would just replace the grep -lr invocation, takes forever on my machine, and it only affects two files
2019-11-06 20:55:14 <mps> ah, ok
2019-11-06 20:56:13 <nmeum> alternative proposal: https://tpaste.us/evaB
2019-11-06 20:56:23 <nmeum> without the set -x of cause
2019-11-06 20:56:56 <mps> just tried py3-twisted in lxc aarch64, it passed grep but failed later in test
2019-11-06 20:57:20 <_ikke_> re tests: https://gitlab.alpinelinux.org/alpine/aports/issues/10939
2019-11-06 21:02:11 <nmeum> hm
2019-11-06 21:08:03 <_ikke_> So for the hmac failures, just adding 'md5' would fix them (without changing behavior)
2019-11-06 21:08:29 <nmeum> py3-twisted is still failing…
2019-11-06 21:09:54 <_ikke_> Really strange..
2019-11-06 21:10:58 <nmeum> could you check if the builder uses the current version of the APKBUILD?
2019-11-06 21:11:28 <nmeum> maybe it is just stuck on an old checkout for some reason
2019-11-06 21:12:18 <_ikke_> I checked the dir on the x86_64 builder, there it's no longer there
2019-11-06 21:13:43 <_ikke_> I'll look at it in a second
2019-11-06 21:21:38 <nmeum> _ikke_: thanks
2019-11-06 21:27:36 <_ikke_> hmm, on some arches it seems to have gotten past py3-twisted
2019-11-06 21:35:55 <nmeum> Channel main-local
2019-11-06 21:35:55 <nmeum> _0x5eb_Master :main:
2019-11-06 21:35:55 <nmeum> _0x5eb_Slave :local:
2019-11-06 21:35:55 <nmeum> _0x5eb_Patterns * !local !work
2019-11-06 21:35:55 <nmeum> _0x5eb_Sync All
2019-11-06 21:35:57 <nmeum> oops
2019-11-06 21:36:22 <nmeum> accidental middle mouse press ':)
2019-11-06 21:36:55 <_ikke_> hehe
2019-11-06 21:38:02 <_ikke_> sorry, I'm a bit to tired to investigate the builders now
2019-11-06 21:42:38 <nmeum> sure, no problem
2019-11-06 21:43:22 <_ikke_> I ran aports-build manually, and it seems to continue on main
2019-11-07 01:01:24 <maxice8> note to everyone in the future: busybox rm doesn't accept -v and busybox grep with the -r option needs the positional argument for path
2019-11-07 01:01:42 <maxice8> gnu grep assumes $PWD, busybox grep needs . or $PWD after the matching string/regex
2019-11-07 01:44:14 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/py3-twisted/py3-twisted-19.7.0-r2.log
2019-11-07 01:44:17 <maxice8> sweet
2019-11-07 05:37:13 <_ikke_> maxice8: plenty amounts of time where I ran grep -r foo and was wondering why nothing returned :P
2019-11-07 05:38:03 <maxice8> :P yes nothing returned because it kept waiting for input on stdin
2019-11-07 05:38:09 <_ikke_> indeed
2019-11-07 05:38:43 <_ikke_> so py3-twisted got unstuck I noticed?
2019-11-07 05:38:59 <maxice8> yes it was stuck
2019-11-07 05:39:11 <_ikke_> Yeah, I tried to look into it, but didn't figure out why yet
2019-11-07 05:39:16 <maxice8> somehow the builders don't update on stuck packages so all builds of py3-twisted kept failing on rm -v usage which i cleared long ago
2019-11-07 05:39:32 <maxice8> had to do arch="" then restore the previous arch="all"
2019-11-07 05:39:39 <maxice8> so the builders would pick up the changes
2019-11-07 05:39:41 <_ikke_> strange
2019-11-07 05:39:47 <_ikke_> normally that should not be needed
2019-11-07 05:40:24 <_ikke_> If your theory is correct, then that change would not be reflected either ;-)
2019-11-07 05:41:07 <maxice8> that assumes the builders are something normal
2019-11-07 05:42:15 <_ikke_> Even CI failed on the same issue..
2019-11-07 05:42:21 <_ikke_> but maybe it's an older commit
2019-11-07 06:04:05 <mps> maxice8: hah, thanks for hint about grep difference. sometimes I wondered why it 'does' nothing
2019-11-07 06:04:44 <maxice8> Most sensible solution is to make ripgrep provides=grep and be done with it :D
2019-11-07 06:05:55 <mps> and added to busybox :)
2019-11-07 06:06:13 <maxice8> rewrite busybox in rust
2019-11-07 06:06:44 <mps> and gcc, ofc
2019-11-07 06:24:10 <tmhoang> mps, Cogitri: I have tons of s390x box that I can setup for you, if you have some time to work on it. Please let me know. I'm pretty tight from now till Dec so really appreciate if you could work on it.
2019-11-07 06:24:35 <tmhoang> (in fact it's public cloud, anyone can register, I would love to help you with the processes)
2019-11-07 06:26:24 <mps> tmhoang: thanks for offer, I will note it to remember and maybe after new year (time constrained these days) remind you :)
2019-11-07 06:26:49 <tmhoang> mps: I mean I can setup today for you.
2019-11-07 06:26:59 <tmhoang> mps: morning early birds :)
2019-11-07 06:28:29 <Cogitri> tmhoang: That'd be great! :)
2019-11-07 06:28:53 <tmhoang> cool, I'm doing now
2019-11-07 06:30:08 <mps> tmhoang: thanks, but I'm preparing for travel and don't have time now, maybe I will ask you on weekend
2019-11-07 06:31:01 <tmhoang> mps: ok have a good time
2019-11-07 06:32:08 <mps> tmhoang: I will be here from time to time, my irc client is on the server and always connected
2019-11-07 06:32:19 <tmhoang> aw ignore it :P
2019-11-07 06:33:38 <mps> sitting in bus and chatting is better than reading news or watching bad movies
2019-11-07 07:29:46 <mps> anyone working on amavis-new upgrade. it is moved to gitlab.com and renamed to amavis. would be nice to have it in 3.11
2019-11-07 07:30:27 <mps> if no one have time or will to upgrade it, I could try
2019-11-07 07:53:23 <ncopa> morning
2019-11-07 07:53:35 <ncopa> sorry for the py3 twisted mess
2019-11-07 07:55:01 <mps> don't worry, don't sorry. this is development channel at end :)
2019-11-07 07:56:03 <mps> making mess is inevitable in development
2019-11-07 07:57:36 <Cogitri> You can't make an omelette without smashing eggs I guess :P
2019-11-07 08:00:20 <mps> Cogitri: thanks for reminder that I need omelet for breakfast :)
2019-11-07 08:16:15 <ncopa> eggs for breakfast sounds like a good idea indeed
2019-11-07 08:18:16 <_ikke_> ncopa: do you have a clue why it kept building the older version?
2019-11-07 08:22:41 <ncopa> not really
2019-11-07 08:24:03 <_ikke_> ok
2019-11-07 09:53:00 <_ikke_> ncopa: getting there: FAILED (skips=2725, failures=1, errors=3, successes=9793) :)
2019-11-07 09:54:54 <ncopa> nice!
2019-11-07 09:55:23 <ncopa> im cleaning up some of the missign packages
2019-11-07 09:55:26 <ncopa> and fixing blender
2019-11-07 09:56:08 <ncopa> apparmor also needs a fix
2019-11-07 09:56:15 <ncopa> testsuite failed there
2019-11-07 11:50:51 <mps> when we rename aports and files in dir (pkg.confd. pkg.initd ...) do we use 'git mv' for all this
2019-11-07 11:54:17 <maxice8> I use git mv
2019-11-07 12:00:26 <mps> maxice8: also I do, but I see now my question wasn't clear. I mean to ask do we first do 'git mv $files ...' and then git mv dir (dir is pkgname dir)
2019-11-07 12:01:06 <mps> although I think order doesn't matter (but ask anyway)
2019-11-07 12:06:57 <agzotherm> I found in the source code of initramfs_init and in the documentation that to activate the bootchart (to measure boot time) I must first add 'bootchart' option in mkinitfs.conf, rebuild it with mkinitfs, and then to set the kernel boot parameter 'chart'. But, the bootchart is not activated after following this procedure. It should according to this
2019-11-07 12:06:58 <agzotherm> line in initramfs_init: "if [ "$KOPT_chart" = yes ]; then", or? Did I miss something?
2019-11-07 12:07:10 <agzotherm> https://github.com/alpinelinux/mkinitfs/blob/master/initramfs-init.in
2019-11-07 12:07:20 <agzotherm> https://wiki.alpinelinux.org/wiki/Initramfs_init
2019-11-07 12:13:36 <_ikke_> mps: note that git mv is just a shortcut, it doesn't do anything special
2019-11-07 12:15:52 <mps> yes, I know, but asked for practice how do you usually do this things
2019-11-07 12:16:24 <mps> these*
2019-11-07 12:16:36 <_ikke_> As git doesn't track directories, it doesn't matter
2019-11-07 12:17:19 <mps> nor files? it is it as removed and new one
2019-11-07 12:17:57 <_ikke_> Right, it does not record the fact that you renamed them. It can however deduct after the fact that they were renamed.
2019-11-07 12:18:34 <mps> ok, thanks both
2019-11-07 12:22:42 <mps> uh, amavisd-new is renamed to amavis but 'binaries' and config files are still amavisd{*}, 'd' at the end
2019-11-07 12:24:23 <AinNero> agzotherm: yes, it needs to be enabled via kerne command lin eoption
2019-11-07 12:56:32 <ncopa> \o/
2019-11-07 12:56:46 <_ikke_> ncopa: Did you fix something?
2019-11-07 12:56:46 <ncopa> i just managed to make a fully reproducible .apk
2019-11-07 12:56:57 <_ikke_> cool
2019-11-07 12:57:42 <igor-petruk> Hi ncopa :)  as you asked, reminding you to take a look at the https://gitlab.alpinelinux.org/alpine/aports/issues/9074#note_53891 pls.
2019-11-07 12:58:46 <telmich> good morning
2019-11-07 12:59:27 <telmich> I am a bit confused - I think I saw one alpine machine with dkms existing, but I do not see a dkms package anywhere. If one was to install dkms based kernel modules, what would be the right way to do it in alpine?
2019-11-07 13:00:54 <ncopa> re licensing of the APKBUILDs
2019-11-07 13:02:06 <ncopa> i'd prefer that all APKBUILDs are MIT, ISC or BSD licensed, or similar
2019-11-07 13:02:19 <ncopa> but I dont think we can simply change it at this point
2019-11-07 13:02:37 <_ikke_> kind of infeasible
2019-11-07 13:03:37 <ncopa> so i guess the simplest solution is to say that the APKBUILD itself has the same license as the project, specified in the `licence` field in the APKBUILD (unless specified otherwise in a comment)
2019-11-07 13:03:41 <igor-petruk> Individual licensing can be an option too. Like if you said "We will accept files to our github, if they have a licenses X, Y, Z". And for companies that care, they can choose one of those and add a a header to the individual file
2019-11-07 13:04:04 <ncopa> yeah
2019-11-07 13:04:15 <ncopa> but it wont change the license of the current APKBUILDs
2019-11-07 13:04:38 <ncopa> since we dont have any contributor agreement in place already, we cannot take the copyright of the current changes
2019-11-07 13:05:02 <igor-petruk> True. But it would solve things for new packages. And also depending on contribution history, some APKBUILDs can be switched later
2019-11-07 13:05:04 <ncopa> so I think the contributors themselves has the copyright
2019-11-07 13:05:34 <_ikke_> One question is the copyrightability of many APKBUILDS
2019-11-07 13:05:48 <ncopa> or commits
2019-11-07 13:06:04 <ncopa> there is a limit on how small a change can be to be able to claim copyright of it
2019-11-07 13:06:07 <_ikke_> Most APKBUILDs follow a similar structure (based on a template)
2019-11-07 13:07:15 <ncopa> i dont want force contributors to sign a CLA
2019-11-07 13:07:20 <igor-petruk> Would it be possible to solve it at least for new packages? Like if you added a contributor guideline suggesting to add a licence header if people want it.
2019-11-07 13:07:39 <ncopa> yeah
2019-11-07 13:07:41 <igor-petruk> CLA gives freedom for you to re-license it, but if you don't care to re-license, CLA is not necessary
2019-11-07 13:07:56 <ncopa> at this point i dont think its possible to re-license it
2019-11-07 13:08:03 <ncopa> its 10years+ of history
2019-11-07 13:08:09 <igor-petruk> And you may choose to commit to never relicense as soon as the licenses are the ones you like
2019-11-07 13:08:32 <igor-petruk> As you said,  MIT, ISC or BSD
2019-11-07 13:08:47 <igor-petruk> If you never change your mind that those are good licenses, they can be used forever
2019-11-07 13:09:28 <ncopa> if we add a toplevel LICENSE file to aports tree, we'd also need to add a copyright statement i guess
2019-11-07 13:09:50 <ncopa> and i dont think I (or someone else) can simply claim the copyright of it all
2019-11-07 13:10:06 <ncopa> so the list of copyright holders will be insanely long
2019-11-07 13:10:29 <igor-petruk> Normally it is "Foo Authors"
2019-11-07 13:10:32 <igor-petruk> Like "Gentoo Authors"
2019-11-07 13:10:48 <igor-petruk> But without everyones permission you cannot choose a particular license at this point
2019-11-07 13:10:54 <ncopa> i think gentoo has a foudnation which you donate your contribution to
2019-11-07 13:11:04 <igor-petruk> I don't think it matters
2019-11-07 13:11:15 <igor-petruk> Any repo X can just use "X Authors"
2019-11-07 13:11:17 <ncopa> exactly, i cannot choose a particular license at this point
2019-11-07 13:11:30 <_ikke_> igor-petruk: is that legally sound?
2019-11-07 13:12:47 <igor-petruk> I don't know, but here is a data point
2019-11-07 13:12:48 <igor-petruk> https://opensource.google/docs/releasing/authors/
2019-11-07 13:13:21 <igor-petruk> I have to go
2019-11-07 13:13:29 <igor-petruk> but this is something to read
2019-11-07 13:14:28 <mps> uhmmm :(
2019-11-07 13:17:11 <PureTryOut[m]> Seems ther is no aarch64 Gitlab runner atm?
2019-11-07 13:19:16 <tmhoang> ncopa: I guess the date for 3.11 is around mid-end Dec,no ?
2019-11-07 13:19:17 <_ikke_> OOM killed it :(
2019-11-07 13:19:28 <_ikke_> PureTryOut[m]: booting it
2019-11-07 13:19:39 <PureTryOut[m]> Thanks!
2019-11-07 13:20:36 <PureTryOut[m]> Is there not some service monitoring the runners and restarting them when necessary?
2019-11-07 13:21:20 <_ikke_> We are currently starting them in a tmux session
2019-11-07 13:21:38 <_ikke_> We had some issues where we had no idea what the machine was doing (when it was running as a service)
2019-11-07 13:29:24 <ncopa> tmhoang: i hope for end of Nov
2019-11-07 13:34:24 <_ikke_> PureTryOut[m]: fyi, these are qemu VMs
2019-11-07 13:34:55 <PureTryOut[m]> I assume stuff can log to files which you can check right?
2019-11-07 14:02:14 <tmhoang> ncopa: ok thanks
2019-11-07 15:33:10 <Trafex> Hi! Not sure where I can post this, but i think something recently broke in the supervisor package. We run supervisor in a Docker image that extends from Alpine 3.10 and recent builds fail when we try to start supervisor with the following error: pkg_resources.DistributionNotFound: The 'meld3>=0.6.5' distribution was not found and is required by
2019-11-07 15:33:10 <Trafex> supervisor
2019-11-07 15:41:19 <_ikke_> Trafex: We are working on upgrading to python3.8
2019-11-07 15:41:42 <_ikke_> Due to build failures, not all packages have been upgraded yet
2019-11-07 15:41:49 <_ikke_> but that should only apply to edge though
2019-11-07 15:43:34 <_ikke_> tmhoang: I'm testing on 3.10, but supervisor seems to work there
2019-11-07 15:43:42 <_ikke_> oh, they left
2019-11-07 15:43:52 <_ikke_> that was meant for Trafex
2019-11-07 16:14:11 <_ikke_> ncopa: http://dup.pw/abuild/43fb2c01 nice :-)
2019-11-07 16:16:11 <_ikke_> this one also: https://git.alpinelinux.org/abuild/commit/?id=95cd15c0
2019-11-07 16:20:19 <ncopa> _ikke_: yeah :)
2019-11-07 16:20:32 <ncopa> now it should be easier to add tests
2019-11-07 16:22:00 <_ikke_> tests.storage.test__base.CacheDecoratorTestCase.test_double_get fails for synapse
2019-11-07 16:26:28 <ncopa> i've started bootstrap of build-3-11-s390x
2019-11-07 16:33:30 <Cogitri> 👍
2019-11-07 16:41:21 <_ikke_> hmm, py3-twisted is calling ckeygen in their test suite, which apparently is provided by py3-twisted itself, but I don't see it in the built files
2019-11-07 16:41:46 <_ikke_> build/lib.linux-x86_64-3.8/twisted/conch/scripts/ckeygen.py this apparently exists
2019-11-07 16:50:33 <maxice8> ERROR: py3-semantic-version-2.8.2-r1: BAD archive
2019-11-07 16:54:41 <_ikke_> wfm :)
2019-11-07 16:54:59 <_ikke_> though, I don't get r1
2019-11-07 16:55:23 <maxice8> 
ACTION makes ikke the new x86_64 builder

2019-11-07 16:55:36 <_ikke_> 
ACTION whistles

2019-11-07 16:56:29 <_ikke_> py3-inotify as well
2019-11-07 16:56:31 <_ikke_> ...
2019-11-07 16:56:57 <maxice8> yes
2019-11-07 17:32:45 <_ikke_> ncopa: PASSED (skips=2727, successes=9795) :-)
2019-11-07 17:42:50 <_ikke_> Someone care to review this? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1130
2019-11-07 18:11:53 <PureTryOut[m]> Hmm the latest abuild seems to produce bad archives...
2019-11-07 18:40:06 <mps> anyone have time to review !1137 and look did I made rename and provides correctly
2019-11-07 18:40:48 <mps> hm, now I see two spaces together :/
2019-11-07 19:25:41 <maxice8> Why BAD archive keeps happening ?
2019-11-07 19:30:26 <maxice8> py3-inotify and py3-logbook still have BAD archive even after rebuild
2019-11-07 19:42:50 <Cogitri> Seems to be the latest abuild according to PureTryOut
2019-11-07 19:52:16 <maxice8> well i hope it gets fixed soon if we want the python rebuild to finish before the weekend
2019-11-07 19:54:40 <_ikke_> Let's see if I can find something obvious that could cause this
2019-11-07 19:55:15 <_ikke_> One change is that it can use pigz if it's available
2019-11-07 19:57:37 <_ikke_> There have been changes to make apk files reproducable, so lots of sources of breakage
2019-11-07 20:02:37 <maxice8> Good luck I'm going to bbq
2019-11-07 20:03:23 <_ikke_> Enjoy
2019-11-07 20:05:02 <clandmeter> whats up with all the bad archives?
2019-11-07 20:05:15 <_ikke_> clandmeter: apparently some recent change to abuild broke something
2019-11-07 20:05:30 <ncopa> huh?
2019-11-07 20:05:42 <clandmeter> are you sure or is it fastly?
2019-11-07 20:06:20 <_ikke_> No, I have not confirmed it yet
2019-11-07 20:06:33 <ncopa> it is possible it is the recent abuild change i did for reproducible builtds
2019-11-07 20:06:43 <_ikke_> yes, and the builders don't use fastly, do they?
2019-11-07 20:06:59 <ncopa> no
2019-11-07 20:07:02 <clandmeter> heh right
2019-11-07 20:07:16 <ncopa> maxice8: what version of py3-inotify?
2019-11-07 20:08:16 <_ikke_> ERROR: py3-path.py-12.0.2-r1: BAD archive
2019-11-07 20:08:36 <_ikke_> ERROR: py3-hotqueue-0.2.8-r2: BAD archive
2019-11-07 20:08:44 <clandmeter> looks like lots of py packages have issues
2019-11-07 20:08:54 <ncopa> those are not available on builders?
2019-11-07 20:08:56 <_ikke_> Yes, because they are currently being ubilt
2019-11-07 20:08:57 <ncopa> i mean
2019-11-07 20:09:00 <ncopa> on mirrors
2019-11-07 20:09:02 <ncopa> ok
2019-11-07 20:09:06 <ncopa> let me revert the abuild thing
2019-11-07 20:09:31 <ncopa> yeah, i can reproduce
2019-11-07 20:09:38 <_ikke_> ok
2019-11-07 20:09:51 <_ikke_> Can you find the actual commit that introduced it?
2019-11-07 20:10:00 <ncopa> i'm on it
2019-11-07 20:10:02 <_ikke_> ok
2019-11-07 20:12:04 <ncopa> does it happen on the builders too?
2019-11-07 20:12:19 <_ikke_> ncopa: yes, check the error logs of failed packages
2019-11-07 20:12:25 <_ikke_> that's what maxice8 was talking about
2019-11-07 20:13:09 <_ikke_> the examples I gave came from buildlogs from the builders
2019-11-07 20:14:41 <clandmeter> there are around 3 gzip/tar related changes
2019-11-07 20:14:53 <ncopa> yeah
2019-11-07 20:15:13 <ncopa> i wonder if it is the change(s) in abuild-sign or in abuild itself
2019-11-07 20:15:31 <ncopa> i cannot reproduce it when building with abuild from git
2019-11-07 20:15:33 <clandmeter> did oyu install pigz already on the builders?
2019-11-07 20:15:51 <ncopa> i think so yes
2019-11-07 20:15:57 <_ikke_> Maybe try to uninstall
2019-11-07 20:16:00 <clandmeter> and local?
2019-11-07 20:16:14 <ncopa> oh, no
2019-11-07 20:16:19 <ncopa> i think pigz is not installed
2019-11-07 20:16:24 <ncopa> i mean
2019-11-07 20:16:31 <ncopa> its not an explicit dependency
2019-11-07 20:16:38 <ncopa> i have it locally yes
2019-11-07 20:16:44 <clandmeter> it isnt correct
2019-11-07 20:17:05 <_ikke_> pigz isn't correct?
2019-11-07 20:17:21 <clandmeter> it isnt install by deps
2019-11-07 20:17:27 <clandmeter> you need to manually do that
2019-11-07 20:17:29 <clandmeter> iirc
2019-11-07 20:17:38 <_ikke_> yeah, which I guess is the idea
2019-11-07 20:17:50 <clandmeter> or maybe ncopa added it to some other package which pulls it in
2019-11-07 20:17:52 <_ikke_> It only uses pigz when it's available, so it doesn't have to be a dependency
2019-11-07 20:18:20 <clandmeter> i would add another package t o boostrap
2019-11-07 20:18:22 <_ikke_> We should pigz being pulled in somehow, right?
2019-11-07 20:18:24 <ncopa> yeah, thats it
2019-11-07 20:18:27 <ncopa> its pigz
2019-11-07 20:18:30 <_ikke_> hmm, ok
2019-11-07 20:18:35 <ncopa> clandmeter: good catch!
2019-11-07 20:18:58 <clandmeter> s/i/it
2019-11-07 20:18:58 <alpine-meetbot> clandmeter meant to say: it would add another package t o boostrap
2019-11-07 20:19:09 <_ikke_> clandmeter: yeah, makes sense
2019-11-07 20:19:30 <clandmeter> pigz is kind of nice
2019-11-07 20:19:36 <clandmeter> it speeds things up a lot
2019-11-07 20:19:38 <_ikke_> I wonder why it breaks the apkbuilds
2019-11-07 20:19:53 <ncopa> but im stupid
2019-11-07 20:20:04 <ncopa> there is no point using it in abuild-sign
2019-11-07 20:20:15 <ncopa> it only compresses the signature
2019-11-07 20:20:18 <ncopa> which is tiny
2019-11-07 20:21:34 <ncopa> wait a sec...
2019-11-07 20:21:41 <ncopa> i think im tired
2019-11-07 20:22:13 <ncopa> so i had pigz in my dev env
2019-11-07 20:22:18 <ncopa> but not on the builders
2019-11-07 20:22:33 <ncopa> so installing pigz on the builders would fix it
2019-11-07 20:22:45 <_ikke_> Why would it fix it?
2019-11-07 20:23:08 <ncopa> because it works in my dev env with pigz
2019-11-07 20:23:21 <ncopa> but it fails when i uninstall pigz
2019-11-07 20:23:21 <_ikke_> why is it broken without pigz?
2019-11-07 20:23:25 <_ikke_> hmm, strange
2019-11-07 20:23:39 <_ikke_> some kind of discrepancy?
2019-11-07 20:23:49 <ncopa> i did two changes in abuild-sign
2019-11-07 20:23:56 <ncopa> one introduced the use oif pigz
2019-11-07 20:24:12 <ncopa> and one that added -n to avoid the timestamp
2019-11-07 20:24:23 <ncopa> it means that gzip -n breaks things
2019-11-07 20:24:35 <ncopa> while pigz -n works
2019-11-07 20:24:37 <_ikke_> but pigz -n doesn't?
2019-11-07 20:24:40 <clandmeter> heh
2019-11-07 20:24:40 <_ikke_> right
2019-11-07 20:24:46 <clandmeter> so its busybox -n
2019-11-07 20:24:55 <clandmeter> busybox gzip -n
2019-11-07 20:24:57 <ncopa> i bet its busybox gzip -n
2019-11-07 20:25:00 <_ikke_> ^^
2019-11-07 20:25:01 <ncopa> yeah
2019-11-07 20:25:02 <_ikke_> \
2019-11-07 20:25:19 <ncopa> which does nto make any sense
2019-11-07 20:25:35 <ncopa> i mean the -n option should be relatively simple
2019-11-07 20:25:41 <ncopa> just set timestamp to 0
2019-11-07 20:25:49 <ncopa> how can you mess that up...
2019-11-07 20:25:52 <_ikke_> Maybe do a binary diff to see what is different?
2019-11-07 20:26:05 <mps> bbox gzip don't have -n, iirc
2019-11-07 20:26:31 <clandmeter> heh it doesnt
2019-11-07 20:26:40 <ncopa> i thikn it has
2019-11-07 20:26:48 <clandmeter> not in the help
2019-11-07 20:26:56 <ncopa> correct
2019-11-07 20:26:57 <mps> it has
2019-11-07 20:27:02 <ncopa> but it does not complain
2019-11-07 20:27:03 <_ikke_> it does accept it
2019-11-07 20:27:05 <_ikke_> indeed
2019-11-07 20:27:10 <mps> and it works
2019-11-07 20:27:13 <ncopa> let me add pigz as explicit dep for now
2019-11-07 20:27:51 <_ikke_> ncopa: I managed to fix the test suite of twisted btw
2019-11-07 20:27:55 <clandmeter> i thought it had cause i had gzip installed
2019-11-07 20:27:57 <ncopa> wait, let met try with gnu gzip first
2019-11-07 20:28:00 <mps> interesting, it have -n but it ignores it
2019-11-07 20:28:00 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1130/diffs
2019-11-07 20:28:01 <ncopa> _ikke_i saw
2019-11-07 20:28:07 <ncopa> _ikke_: good job
2019-11-07 20:28:26 <_ikke_> I'm a bit unsure about this change: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1130/diffs#00ad1cd306ae31d8c813151992cc2690e23a8fbd_14_13
2019-11-07 20:29:55 <ncopa> whatta
2019-11-07 20:30:08 <clandmeter> https://github.com/mirror/busybox/blob/d327c6b190900dcb0cb7cda9008eb4f9893a92d8/archival/gzip.c#L2179
2019-11-07 20:30:16 <ncopa> gnu gzip seems to be broken too
2019-11-07 20:33:44 <clandmeter> should i wait with pushing aports?
2019-11-07 20:33:51 <ncopa> yes
2019-11-07 20:34:02 <ncopa> til we have fixed abuild
2019-11-07 20:34:11 <clandmeter> nod
2019-11-07 20:34:14 <ncopa> everything pushed after abuild push needs to be rebuilt
2019-11-07 20:34:25 <clandmeter> right
2019-11-07 20:34:34 <_ikke_> I'll try to get a list
2019-11-07 20:34:54 <ncopa> i think gzip -n breaks things but pigz -n works
2019-11-07 20:36:51 <ncopa> hum
2019-11-07 20:36:59 <ncopa> removing -n didnt solve it either
2019-11-07 20:37:10 <clandmeter> i would expect gnu gzip to actually work
2019-11-07 20:37:14 <ncopa> so then the problem is not in abuild-sign, but in abuild itself
2019-11-07 20:37:30 <ncopa> clandmeter: same
2019-11-07 20:37:42 <ncopa> but why did installing pigz solve it?
2019-11-07 20:38:00 <_ikke_> http://tpaste.us/6VD8
2019-11-07 20:38:17 <clandmeter> https://git.alpinelinux.org/abuild/commit/?id=f04a2ee34b28a38c4349ef1f94686a07afce730f is also a candidate?
2019-11-07 20:38:46 <ncopa> yes
2019-11-07 20:39:05 <ncopa> what is confusing is that apparently, installing/deinstalling pigz makes a difference
2019-11-07 20:40:07 <ncopa> no
2019-11-07 20:40:10 <ncopa> im holding it wrong
2019-11-07 20:40:22 <ncopa> it must be the https://git.alpinelinux.org/abuild/commit/?id=f04a2ee34b28a38c4349ef1f94686a07afce730f
2019-11-07 20:43:19 <ncopa> yeah
2019-11-07 20:43:20 <_ikke_> I wonder how we can get all the packages built after the abuild upgrade
2019-11-07 20:44:17 <clandmeter> apk verify?
2019-11-07 20:44:30 <_ikke_> on each package on the builders?
2019-11-07 20:44:42 <ncopa> were any packages uploaded to dl-master?
2019-11-07 20:44:43 <clandmeter> that would be an option
2019-11-07 20:45:54 <_ikke_> ncopa: I think not. After the abuild push, I see one sequence of upload messages
2019-11-07 20:46:01 <_ikke_> which I assume just built abuild
2019-11-07 20:46:06 <_ikke_> after that, only failures
2019-11-07 20:48:07 <ncopa> yeah
2019-11-07 20:48:16 <ncopa> lets delete those packages from the builders
2019-11-07 20:48:19 <_ikke_> ok
2019-11-07 20:48:29 <ncopa> except cmake
2019-11-07 20:48:37 <ncopa> which used the old abuild (i think)
2019-11-07 20:48:45 <ncopa> cmake got uploaded
2019-11-07 20:48:51 <_ikke_> ok
2019-11-07 20:49:04 <ncopa> (3/4) Installing cmake (3.15.5-r0)
2019-11-07 20:49:07 <ncopa> is ok
2019-11-07 20:49:25 <clandmeter> can you determine the exact packages by commit history?
2019-11-07 20:49:33 <_ikke_> I have those
2019-11-07 20:49:42 <_ikke_> But that's not the complete picture
2019-11-07 20:49:49 <clandmeter> thats what im asking :)
2019-11-07 20:49:54 <_ikke_> http://tpaste.us/6VD8
2019-11-07 20:50:08 <_ikke_> Those were committed after the abuild upgrade
2019-11-07 20:50:23 <clandmeter> yes but were some builders still doing other older commits?
2019-11-07 20:50:37 <_ikke_> yes
2019-11-07 20:50:47 <ncopa> hum
2019-11-07 20:52:19 <ncopa> apk verify  py3-path.py-12.0.2-r1.apk
2019-11-07 20:52:19 <ncopa> py3-path.py-12.0.2-r1.apk: -74 - FAILED
2019-11-07 20:52:29 <ncopa> we can use apk verify to find broken packages
2019-11-07 20:53:35 <clandmeter> xargs can run it multithreaded :)
2019-11-07 20:54:16 <ncopa> but we have another issue too
2019-11-07 20:54:40 <ncopa> if i push a fixed abuild, the broken abuild will build it
2019-11-07 20:55:01 <ncopa> and update to fixed version will fail
2019-11-07 20:56:35 <ncopa> sigh... what a mess
2019-11-07 20:56:48 <_ikke_> http://tpaste.us/V4Rz
2019-11-07 20:58:04 <_ikke_> can we install an abuild from stable on the builders?
2019-11-07 20:58:19 <ncopa> yeah
2019-11-07 20:58:31 <ncopa> or simply wget the one from git
2019-11-07 20:58:37 <ncopa> probably easier
2019-11-07 20:58:44 <clandmeter> git?
2019-11-07 20:58:47 <_ikke_> master I guess
2019-11-07 20:58:59 <ncopa> yeah
2019-11-07 20:59:10 <ncopa> https://dev.alpinelinux.org/~ncopa/abuild
2019-11-07 20:59:40 <ncopa> or live patch /usr/bin/abuild
2019-11-07 20:59:46 <_ikke_> lots of options
2019-11-07 21:00:54 <clandmeter> how does apk show a bad pkg?
2019-11-07 21:01:01 <clandmeter> OK vs ?
2019-11-07 21:01:06 <clandmeter> BAD?
2019-11-07 21:01:08 <ncopa> FAILED
2019-11-07 21:01:13 <_ikke_> py3-path.py-12.0.2-r1.apk: -74 - FAILED
2019-11-07 21:01:19 <ncopa> py3-flask-babel-0.12.2-r3.apk: -74 - FAILED
2019-11-07 21:01:19 <ncopa> py3-flask-dbconfig-0.3.12-r2.apk: -74 - FAILED
2019-11-07 21:01:19 <ncopa> py3-forbiddenfruit-0.1.3-r1.apk: -74 - FAILED
2019-11-07 21:01:19 <ncopa> py3-flask-headers-1.0-r2.apk: -74 - FAILED
2019-11-07 21:01:38 <clandmeter> ok grepping for FAILED
2019-11-07 21:06:58 <ncopa> ssh: connect to host build-edge-armhf port 22: Connection refused
2019-11-07 21:07:03 <_ikke_> It moved
2019-11-07 21:07:07 <_ikke_> I guess
2019-11-07 21:07:08 <clandmeter> :)
2019-11-07 21:07:12 <_ikke_> or is ssh corrupt again
2019-11-07 21:07:20 <ncopa> i think openssh-server needs to apk fixed
2019-11-07 21:07:24 <ncopa> apk fix openssh-server
2019-11-07 21:07:36 <ncopa> and possibly restrarted
2019-11-07 21:07:46 <_ikke_> on it
2019-11-07 21:07:56 <ncopa> do not reboot the machine
2019-11-07 21:08:00 <ncopa> just start the service
2019-11-07 21:08:07 <_ikke_> nod
2019-11-07 21:08:09 <clandmeter> is it only possible in testing?
2019-11-07 21:08:55 <clandmeter> wow thats a lot of pkgs
2019-11-07 21:09:08 <_ikke_> ncopa: fixed
2019-11-07 21:09:22 <ncopa> thanks
2019-11-07 21:09:24 <clandmeter> im chekcing aarch64
2019-11-07 21:09:38 <ncopa> how do i ssh a multicommand line
2019-11-07 21:09:54 <clandmeter> http://tpaste.us/mE5V
2019-11-07 21:09:57 <ncopa> ssh $host sh -c 'wget -P /usr/bin/ $url' gives wget error
2019-11-07 21:10:00 <clandmeter> but i tested testing only
2019-11-07 21:10:37 <ncopa> ssh root@build-edge-aarch64 sh -c 'wget -P /usr/bin https://dev.alpinelinux.org/~ncopa/abuild'
2019-11-07 21:11:02 <ncopa> gives error and wget help text
2019-11-07 21:12:27 <clandmeter> ls */*.apk | xargs -n1 -P16 apk verify |grep FAILED seems to speed up things a bit.
2019-11-07 21:14:00 <_ikke_> clandmeter: we need to fix dns for usa1/7
2019-11-07 21:14:06 <_ikke_> :)
2019-11-07 21:15:16 <clandmeter> We need to fix many things
2019-11-07 21:15:24 <_ikke_> ahuh
2019-11-07 21:15:46 <clandmeter> Like adding 3.10 builders to netbox
2019-11-07 21:16:00 <_ikke_> right
2019-11-07 21:23:19 <ncopa> im deleting the FAILED packages now
2019-11-07 21:23:41 <ncopa> after that i will push abuild update
2019-11-07 21:23:53 <ncopa> i have already wget the fixed version
2019-11-07 21:24:29 <_ikke_> ok, good
2019-11-07 21:37:28 <ncopa> ok, im pushing the fix now
2019-11-07 21:39:14 <ncopa> ugh
2019-11-07 21:39:49 <_ikke_> something seems off
2019-11-07 21:39:56 <ncopa> yeah
2019-11-07 21:40:00 <ncopa> i forgot aarch64
2019-11-07 21:40:01 <_ikke_> edge/main/: uploaded
2019-11-07 21:40:04 <_ikke_> pkgname?
2019-11-07 21:40:05 <ncopa> and i broke the reset
2019-11-07 21:48:10 <ncopa> something is off
2019-11-07 21:48:14 <ncopa> curl https://dev.alpinelinux.org/~ncopa/abuild
2019-11-07 21:48:28 <ncopa> works from my desktop, but from the builders it returns an empty file
2019-11-07 21:48:53 <ncopa> do we have some slpit dns or similar?
2019-11-07 21:49:07 <_ikke_> which builder?
2019-11-07 21:49:15 <ncopa> all of them
2019-11-07 21:49:24 <ncopa> build-edge-aarch64
2019-11-07 21:50:09 <_ikke_> even curl -v returns nothing
2019-11-07 21:50:12 <_ikke_> that's strange
2019-11-07 21:50:24 <ncopa> build-edge-armv7 seems to be ok
2019-11-07 21:50:25 <_ikke_> curl -v google.com
2019-11-07 21:50:36 <_ikke_> curl is broken
2019-11-07 21:51:01 <_ikke_> /usr/bin/curl empty
2019-11-07 21:51:57 <_ikke_> apk fix curl
2019-11-07 21:52:23 <ncopa> weird
2019-11-07 21:52:35 <ncopa> i wonder if we have corrupt fs
2019-11-07 21:53:47 <_ikke_> on all builders?
2019-11-07 21:53:53 <ncopa> no
2019-11-07 21:55:17 <ncopa> i thnk build-edge-aarch64 is ok now
2019-11-07 21:55:31 <_ikke_> yeah, that's the one I fixed
2019-11-07 21:56:59 <ncopa> build-edge-armv7 should be ok too now
2019-11-07 21:57:12 <_ikke_> k
2019-11-07 22:02:37 <ncopa> ssh: connect to host build-edge-armv7 port 22: Connection refused
2019-11-07 22:02:41 <ncopa> but something is still wrong
2019-11-07 22:02:51 <ncopa> now it seems they hange when uplodaing package to master
2019-11-07 22:03:19 <ncopa> rsync to dl-master hangs
2019-11-07 22:10:15 <ncopa> ppc64le should be ok now
2019-11-07 22:10:21 <ncopa> s390x too
2019-11-07 22:10:23 <ncopa> and x86
2019-11-07 22:13:47 <ncopa> and x86_64
2019-11-07 22:13:50 <ncopa> should all be ok now
2019-11-07 22:18:35 <_ikke_> \o/
2019-11-07 22:18:55 <ncopa> im going to bed
2019-11-07 22:19:07 <ncopa> i will check how things goes in the morning
2019-11-07 22:19:12 <ncopa> i intend to take the day off tomorrow
2019-11-07 22:20:32 <ncopa> seems like rsync to dl-master is insanely slow
2019-11-07 22:20:41 <ncopa> i'd guess its packetloss or something
2019-11-07 22:21:00 <ncopa> good night
2019-11-07 22:22:14 <_ikke_> nite
2019-11-07 22:23:53 <MartijnBraam> so... armhf is gone?
2019-11-07 22:27:13 <mps> MartijnBraam: what do you mean to say
2019-11-07 22:27:46 <MartijnBraam> armhf seems to be gone on the binary repo
2019-11-07 22:27:48 <MartijnBraam> in http://dl-cdn.alpinelinux.org/alpine/edge/main/
2019-11-07 22:28:06 <MartijnBraam> well seems to be more gone
2019-11-07 22:28:39 <mps> that looks like temporary issue
2019-11-07 22:30:51 <mps> https://nl.alpinelinux.org/alpine/edge/testing/
2019-11-08 00:16:46 <crosbymichael> my alpine mirror just got all the edge packages deleted.  something up with the rsync service?
2019-11-08 03:17:31 <Guest98> alpine/edge/community/x86_64 has been removed and it seems some packages are moved to x86 folder. anyone knows something it?
2019-11-08 03:24:57 <maxice8> Yes, it is a long story
2019-11-08 03:25:05 <maxice8> it will be fixed soon-ish
2019-11-08 05:07:29 <shun> hello alpine!
2019-11-08 05:08:02 <shun> i am running into an issue trying to apk install something from edge repo, and noticed that http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/ is currently empty?
2019-11-08 05:13:07 <maxice8> yes
2019-11-08 05:15:29 <shun> do you know why, and when will it be back up? its preventing me from doing a production deployment :(
2019-11-08 05:27:03 <maxice8> you're doing production deployment on edge ?
2019-11-08 05:27:18 <maxice8> anyways, as soon as it is fixed, can be a day or more
2019-11-08 05:34:10 <shun> its a long story, I have a dependency(kafka) that is broken when I tried to install it onto an Alpine image. And the version on Edge seems to have fixed this problem
2019-11-08 05:34:16 <shun> thanks for you reply
2019-11-08 05:35:16 <maxice8> if you open an issue with the version of kafka and alpine you tried, interested parties can try backporting a fix so you can use a stable image instead of edge
2019-11-08 05:43:08 <shun> thank you for your suggestion, i will look into it
2019-11-08 05:46:39 <maxice8> PureTryOut: i pushed adapta-gtk-theme and also adapta-kde, can you test the later ?
2019-11-08 06:31:47 <ncopa> morning
2019-11-08 06:31:52 <ncopa> what happened?
2019-11-08 06:32:34 <clandmeter> Morning
2019-11-08 06:32:51 <clandmeter> Looks like cdn misses some arches
2019-11-08 06:36:07 <ncopa> i think something/someone deleted the master mirror yesterday
2019-11-08 06:36:18 <ncopa> 23:20 <@ncopa> seems like rsync to dl-master is insanely slow
2019-11-08 06:36:36 <ncopa> that was likely due to it was copying all the files over again
2019-11-08 06:37:32 <ncopa> lets take this in #alpine-infra
2019-11-08 06:58:46 <Cogitri> Morning
2019-11-08 07:16:05 <ncopa> morning
2019-11-08 08:11:28 <ncopa> so something/someone managed to delete the master mirror yesterday
2019-11-08 08:11:40 <ncopa> im not 100% sure what or who
2019-11-08 08:12:05 <ncopa> we were working on a broken abuild which produced broken (uninstallable) packages
2019-11-08 08:12:31 <ncopa> i manualle deleted some corrupt packages from the *builders*
2019-11-08 08:12:43 <ncopa> and to my memory i didnt touch anything on the master mirror
2019-11-08 08:13:11 <ncopa> but something must have gone wrong which resulted in a deleted master mirror
2019-11-08 08:13:34 <ncopa> i did notice when abuild problem was fixed, that it to very long time to sync to master mirror
2019-11-08 08:14:25 <ncopa> so the problem must have happened while we were wowrking on abuild
2019-11-08 08:15:12 <ncopa> i also know that i was pretty tired, so i must have messed up somehow
2019-11-08 08:15:39 <ncopa> the packages should all be back again
2019-11-08 08:15:54 <ncopa> sorry for the inconvenience
2019-11-08 08:16:41 <mps> last night some people asked about issue on #alpine-linux
2019-11-08 08:17:13 <mps> I tried to give answer, guessing what's the issue
2019-11-08 08:18:07 <mps> would be good to have status on a.o for such cases
2019-11-08 08:18:53 <ncopa> yeah
2019-11-08 08:18:54 <Cogitri> Good that it works again :)
2019-11-08 08:19:21 <ncopa> mps: I was also thinkig that we should have a service statatus notifications some where
2019-11-08 08:19:23 <ncopa> not sure where
2019-11-08 08:19:37 <ncopa> i dont think a.o news section is proper place
2019-11-08 08:19:52 <ncopa> we should have something that is dynamic
2019-11-08 08:20:08 <ncopa> maybe plugged to zabbix or so
2019-11-08 08:20:11 <mps> maybe https://alpinelinux.org/status or something similar
2019-11-08 08:20:14 <ncopa> yeah
2019-11-08 08:20:36 <ncopa> whihch should always say "everything is ok" and a green icon and a time stamp
2019-11-08 08:20:57 <ncopa> and where we can log incidents
2019-11-08 08:21:40 <ncopa> im taking the rest of the day off
2019-11-08 08:21:51 <ncopa> i will check how things goes later
2019-11-08 08:21:57 <mps> ok, enjoy
2019-11-08 08:22:21 <ncopa> clandmeter and _ikke_ knows how to reach me if there is any emergency
2019-11-08 08:23:42 <_ikke_> ncopa: enjoy
2019-11-08 08:31:18 <clandmeter> _ikke_: can you check build-edge-x86_64 for lua-turbo in communtiy?
2019-11-08 08:31:34 <clandmeter> is it build but not synced yet?
2019-11-08 08:32:55 <_ikke_> sure
2019-11-08 08:33:32 <clandmeter> should be on r1
2019-11-08 08:33:46 <clandmeter> ah no
2019-11-08 08:33:51 <clandmeter> i didnt push it, due to the issues
2019-11-08 08:33:52 <_ikke_> community/lua-turbo-2.1.3-r0.apk
2019-11-08 08:35:04 <maxice8> Can i get !846 and !1028 merged ? :D
2019-11-08 08:41:43 <mps> do we have rss feed with some statuses of infra
2019-11-08 08:59:44 <fredrigu> ncopa: I see that https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/6 was closed but the commit still accepted in master. Did I do something wrong with the merge request that I should correct to next time?
2019-11-08 09:02:19 <_ikke_> fredrigu: it's just a consequence of how we intergrate commits currently
2019-11-08 09:02:26 <_ikke_> So nothing is wrong
2019-11-08 09:03:52 <_ikke_> fredrigu: the commits are effectively rebased and pushed
2019-11-08 09:11:07 <fredrigu> _ikke_: ah I see. Why not just configure gitlab to do fast forward merges?
2019-11-08 09:11:22 <maxice8> because things are not merged to gitlab
2019-11-08 09:11:26 <_ikke_> because gitlab is not the canonical source yet
2019-11-08 09:11:42 <_ikke_> We still push to git.alpinelinux.org, which gets synced to gitlab
2019-11-08 09:12:32 <fredrigu> ah, so when I do a MR in gitlab, those commits are instead merged to git.alpinelinux.org and then gitlab is synced?
2019-11-08 09:12:54 <maxice8> yes, merged == pushed in this case
2019-11-08 09:13:29 <fredrigu> ah, then I just continue doing MR to gitlab :)
2019-11-08 09:25:04 <_ikke_> yes, that's fine
2019-11-08 10:23:47 <oliv3r[m]> I just created a MR !1153 but the build fails (runs locally just fine) with unrelated code to my changes. Could it be that the infra is broken?
2019-11-08 10:32:07 <_ikke_> python got upgraded to 3.8
2019-11-08 10:32:21 <_ikke_> so might be something in the interaction between the vim python integration
2019-11-08 13:42:15 <AinNero> have you noticed that for many packages the "Maintainer" isnt the person that is doing the maintenance commits?
2019-11-08 13:54:17 <PureTryOut[m]> <maxice8 "PureTryOut: i pushed adapta-gtk-"> Sure I guess, will do it later
2019-11-08 13:58:12 <maxice8> i already tested it by running keepassxc with QT_STYLE_OVERRIDE=kvantum-
2019-11-08 13:58:46 <maxice8> but yeah it would be nice to have someone that actually uses KDE to test it i only did it because i want my qt5 applications like keepassxc to look like my other stuff
2019-11-08 15:42:17 <fredrigu> so when creating different repositories and using a multi-arch version of apk. A repo can be /var/repo/ and hence the APKINDEX will be /var/repo/x86_64/APKINDEX.tar.gz and /var/repo/all/APKINDEX.tar.gz as an example. Then there might be packages in x86_64 that depends on packages in all (and the reverse as well). Doing an apk index to create a APKINDEX will warn for this
2019-11-08 15:43:02 <fredrigu> My solution for this is to introduce a new argument to apk index --no-warn-if-no-providers to just ignore this warning. But it doesn't feel as a really great solution
2019-11-08 15:43:55 <fredrigu> becuase apk index shouldn't warn for a correct situation and different APKINDEX files don't know about eachother
2019-11-08 16:05:41 <ncopa> i am thinking of fosdem 2020 and wonder what people would be interested to hear about from me
2019-11-08 16:06:41 <ncopa> some topics i have been thinking about:
2019-11-08 16:07:20 <ncopa> alpine build infra. how it currently works, how we ended up here, and what my thoughts are it should work
2019-11-08 16:07:32 <ncopa> eg how i'd like to rebuild it
2019-11-08 16:08:50 <ncopa> DNS - how is musl libc's resolver different from others. why it is different
2019-11-08 16:09:40 <fredrigu> ncopa: I would be very interested in alpine build infra, that would be a reason for me to try to come to fosdem. But I don't work on alpine, I work on build systems. So maybe I'm not the target audience.
2019-11-08 16:09:50 <ncopa> or maybe something community related and how to deal with people.
2019-11-08 16:10:06 <Cogitri> Dunno if DNS resolvers are so interesting, build infra would be interesting for me and I'd most likely attend that
2019-11-08 16:10:16 <ncopa> how to contribute, make patches, and interact or similar
2019-11-08 16:10:44 <ncopa> basically, how to behave in an open source community
2019-11-08 16:10:56 <ncopa> or more, how i'd like people to behave
2019-11-08 16:11:01 <ncopa> or something like that
2019-11-08 16:11:32 <TBB> that topic is a minefield, it is
2019-11-08 16:13:29 <ncopa> yeah
2019-11-08 16:13:42 <mps> if I have to do something similar I would do about technical points
2019-11-08 16:14:20 <Cogitri> And IMHO there's nothing about how to contribute out there already
2019-11-08 16:14:42 <ncopa> there have been a number of talks on the subject
2019-11-08 16:16:07 <ncopa> i dont know what people would find interesting to hear from me
2019-11-08 16:16:07 <artok> I've seen many "I'll be offended if my patch doesn't make into release"-people
2019-11-08 16:16:40 <ncopa> artok: there is two sides of that kind of issues
2019-11-08 16:16:46 <ncopa> there *are*
2019-11-08 16:16:55 <ncopa> i have been on both sides numbers of times
2019-11-08 16:17:00 <ncopa> i have sent tons of patches upstream
2019-11-08 16:17:12 <ncopa> and i have dealth with tons of contributions
2019-11-08 16:17:47 <ncopa> but im not sure that is something people would be interestsed to hear about
2019-11-08 16:17:52 <ncopa> my perspective that is
2019-11-08 16:18:00 <artok> indeed, but keeping discussion constructive is the key point
2019-11-08 16:20:43 <Cogitri> Well, if you want to you can make a poll for it :P
2019-11-08 16:20:45 <mps> if I'm you (or Felker) I would complain about upstreams who ignores musl (rust devs at first)
2019-11-08 16:20:59 <Cogitri> I personally think the build system talk would be the nicest to listen to
2019-11-08 16:21:05 <mps> :)
2019-11-08 16:23:49 <artok> that would be indeed good topic, basic "how to contribute" is ok
2019-11-08 16:38:41 <crosbymichael> build system would be an interesting talk
2019-11-08 16:38:52 <crosbymichael> i always listen to all your talks!
2019-11-08 17:03:27 <fredrigu> who is Timo, is he on irc?
2019-11-08 17:04:57 <ncopa> ok, so i'll submit a build system talk
2019-11-08 17:05:10 <ncopa> Timo is kunkku
2019-11-08 17:05:23 <ncopa> no, sorry
2019-11-08 17:05:33 <ncopa> Timo is fabled
2019-11-08 17:05:57 <ncopa> fabled hangs around here sometimes
2019-11-08 17:06:13 <fredrigu> ncopa: thanks :)
2019-11-08 17:08:02 <artok> finnish drunkards...
2019-11-08 17:09:47 <artok> filoozom: have you been planning to do any modifications to your rpi update ? you still have the PR active on github
2019-11-08 17:11:58 <mps> artok: you are back? I looked through 5.4-rc6 and think it about possible to use same kernel for aarch64 and RPI4, but not sure
2019-11-08 17:12:08 <mps> did you looked at it
2019-11-08 17:12:46 <artok> not yet, I was still working last night so today has been mostly sleeping for now
2019-11-08 17:13:06 <mps> ah, ok. take time to rest
2019-11-08 17:13:22 <artok> well as we speak I'm downloading the rc6 package
2019-11-08 17:14:50 <mps> I built it on monday and it works fine on my RK3399 chromebook
2019-11-08 17:15:59 <mps> but I looked through config and think RPI4 could be added to same build, but don't have RPI4 to test
2019-11-08 17:16:31 <artok> what config did you use?
2019-11-08 17:16:57 <mps> 'home made' (in my home) :)
2019-11-08 17:17:28 <mps> I had to enable RK3399 and cros_ec stuff
2019-11-08 17:18:58 <mort___> ncopa: +1 for build infra talk (and i've been able to keep fosdem weekend free so far so should actually be able to make it :)
2019-11-08 18:43:36 <mps> looks like llvm6 can't build on 32bit arch'es
2019-11-08 18:44:45 <mps> and, does anything depend on it
2019-11-08 18:46:25 <artok> mps rpi3 a,b and c dtb&dts are built on 5.4 but not for rpi4
2019-11-08 18:48:41 <mps> what is dts file name for RPI4
2019-11-08 18:48:45 <artok> oh, while I've been sailing, there is rpi-5.4.y branch on github/raspberrypi
2019-11-08 18:50:26 <mps> rpi4 is broadcom, iirc
2019-11-08 18:50:31 <artok> bcm2711-rpi-4-b.dtb at least
2019-11-08 18:50:58 <artok> they're bcm2710, 2837 and 2711
2019-11-08 18:51:14 <mps> don't see it in -rc6 tree
2019-11-08 18:52:45 <mps> hmmm
2019-11-08 20:22:58 <artok> and raspberry people's rpi-5.4.y branch doesn't compile successfully
2019-11-08 20:24:37 <z3ntu> Hi, I'm getting a build failure for a package with the latest abuild: `pkgconf version 0.4.47+ubports is invalid` . Do I have to patch the sources to remove that prefix for the packaging to succeed?
2019-11-08 20:26:32 <z3ntu> This is also an issue with packaging the latest mesa from git: `pkgconf version 20.0.0-devel is invalid`
2019-11-08 20:32:18 <Cogitri> Ah yes, I think we only allow numerals in the pkgconfig version
2019-11-08 20:32:57 <maxice8> Yes, abuild strips some know version suffixes like alpha beta rc pre
2019-11-08 20:34:48 <z3ntu> at least two packages in postmarketOS are broken now because of that :/
2019-11-08 20:35:14 <maxice8> they were always apparently
2019-11-08 20:38:41 <z3ntu> Both mesa and 'click' have complicated ways to set the pkgconfig version number (mesa gets it from the `VERSION` file, sets it in meson for everything and uses that to generate the pkgconfig file; click parses the version from the debian/changelog file and puts it into the autoconf AC_INIT macro) - so in both cases it's not really trivial to strip the suffix out of just the pkgconfig file but the version number for the
2019-11-08 20:38:42 <z3ntu> whole application has to be modified
2019-11-08 20:40:05 <Cogitri> Well, you could fix abuild to properly recognise those I guess
2019-11-08 20:40:52 <z3ntu> strip all letters after a minus or a plus?
2019-11-08 20:45:37 <Cogitri> No, that abuild properly recognises those as versions
2019-11-08 20:46:19 <z3ntu> I mean patching abuild so that it doesn't just remove -alpha -beta, etc but all letters after a minus or a plus
2019-11-08 20:50:39 <Cogitri> Ah yes, but wouldn't that eventually lead to conflicts?
2019-11-08 20:52:49 <Cogitri> If you leave mesa-git in the tree and it provides mesa-20.0.0 and mesa makes a new stable 20.0.0 release abuild couldn't tell which one to choose
2019-11-08 21:02:19 <z3ntu> ¯\_(ツ)_/¯
2019-11-08 21:02:36 <z3ntu> so what should I do then?
2019-11-08 21:35:01 <mps> just built testing/firefox 70.0.1 (upgrade) on aarch64/edge. anyone with x86_64 fast enough builder to test, and push if it works
2019-11-08 21:35:38 <mps> my x86_64 is too slow for such task, and my net link is not fast
2019-11-08 22:47:01 <artok> all too deep going with 5.4 at this point to get rpi4 stuff to work. I'll wait for some patches
2019-11-08 23:11:25 <clandmeter> ncopa: build systems would be nice indeed
2019-11-08 23:11:41 <clandmeter> would also be nice to compare to what others have/do
2019-11-08 23:13:30 <clandmeter> it would also give you the opertunity to put this topic on paper for future reference.
2019-11-08 23:13:47 <clandmeter> we discussed this already a few times but most of it got lost in my head.
2019-11-09 11:34:42 <PureTryOut[m]> Python 3.8 seems to be broken, I get "Error relocating /usr/lib/libpython3.8.so.1.0: copy_file_range: symbol not found" whenever I run a Python script
2019-11-09 12:01:58 <maxice8> Wfm here, I'll need more info
2019-11-09 12:02:36 <PureTryOut[m]> Well, https://gitlab.com/postmarketOS/pmaports/-/jobs/346294584
2019-11-09 12:02:58 <PureTryOut[m]> That's the only info I can give you really lol. That and another CI job for us is failing, even though those scripts worked fine before
2019-11-09 12:03:28 <z3ntu__> I tested briefly in a fresh alpine:edge docker container before and it works fine there so no idea what's different in the CI
2019-11-09 12:07:17 <clandmeter> PureTryOut[m]: i think your image is not uptodate
2019-11-09 12:07:33 <clandmeter> i can reproduce it here
2019-11-09 12:07:41 <clandmeter> but apk -U upgrade -a fixes it
2019-11-09 12:07:49 <PureTryOut[m]> It's just the Gitlab Alpine image though...
2019-11-09 12:07:56 <PureTryOut[m]> That's annoying
2019-11-09 12:08:14 <clandmeter> its edge image, so that can happen
2019-11-09 12:09:06 <PureTryOut[m]> Yeah we set it to edge as we needed shellcheck. We will switch it back to stable once Alpine 3.11 hits but this will have to do
2019-11-09 12:09:36 <clandmeter> then make sure you upgrade the image before using it.
2019-11-09 12:11:23 <clandmeter> i think it gets updated when new edge snapshot arrives. not sure though how its managed.
2019-11-09 15:00:36 <maxice8> PureTryOut: re: about olm, updated patchver
2019-11-09 15:06:07 <maxice8> Forgot that gitlab has no email replies like githu and
2019-11-09 15:06:14 <maxice8> Github*
2019-11-09 15:25:41 <PureTryOut[m]> Hmm? I'm fine with commenting via the web UI
2019-11-09 15:31:05 <kmaxwell> anyone got advice about how to track down "Error relocating /usr/lib/python3.8.so.1.0: copy_file_range: symbol not found" please?
2019-11-09 15:32:51 <maxice8> PureTryOut: yeah but I'm on my phone in the middle of the street , no time to open the webui
2019-11-09 15:41:00 <PureTryOut[m]> kmaxwell: known issue, update your systenm
2019-11-09 15:41:40 <kmaxwell> PureTryOut: thanks! I think I just realised as much, by system I have alpine:edge docker image
2019-11-09 15:41:54 <kmaxwell> don't know how/when it gets update
2019-11-09 15:42:10 <z3ntu__> apk upgrade 😉
2019-11-09 15:42:31 <kmaxwell> z3ntu___: :-)
2019-11-09 15:44:06 <PureTryOut[m]> Yeah I encountered the same issue today, and the response I got here was "upgrade your image" 😉
2019-11-09 15:45:29 <kmaxwell> thanks again, I'm happy I know what I'm doing
2019-11-09 16:28:36 <PureTryOut[m]> maxice8: you'll like https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1189
2019-11-09 16:37:12 <PureTryOut[m]> maxice8: also, adapta-kde seems to work fine, although missing quite a few icons
2019-11-09 16:39:03 <maxice8> Nice mr
2019-11-09 17:00:58 <PureTryOut[m]> Once the full Mopidy 3.0 release is out, I'll package some extensions as well
2019-11-09 19:09:42 <mps> testing/llvm6 could/should be moved to unmaintained, nothing makedepends on it
2019-11-09 19:10:42 <mps> or removed form repo?
2019-11-09 19:10:54 <alpine-meetbot> mps meant to say: or removed from repo?
2019-11-09 19:10:54 <mps> s/form/from/
2019-11-09 19:12:12 <mps> clang6 is already in unmaintained
2019-11-09 19:12:37 <Cogitri> I'd move to unmaintained and then delete if no one complains
2019-11-09 19:15:43 <mps> hm, i forgot how _ik_ke_ use script to find revdeps of pk
2019-11-09 19:16:05 <mps> pkg*
2019-11-09 19:19:58 <Cogitri> I use `apk --search --rdepends --origin --quiet so:libfoo.so.1` to search for dependants of a lib
2019-11-09 19:24:36 <mps> yes
2019-11-09 19:26:17 <mps> ohm, ponyc depends on it
2019-11-09 19:27:17 <mps> so, no move or remove but try to fix
2019-11-09 19:31:57 <Cogitri> I think ponyc is working on LLVM8/9 compat or fixed it already
2019-11-09 19:33:04 <mps> also I think I saw work on this but not sure, never looked at ponyc
2019-11-09 19:33:58 <Cogitri> I only complained that they don't support llvm8 when I pushed that :P
2019-11-09 19:34:26 <mps> could be that I saw you complaint :)
2019-11-10 01:20:53 <kaniini> versions like 0.4.47+ubports and 20.0.0-devel are valid, however
2019-11-10 01:21:08 <kaniini> if pkgconf is generating an incorrect diagnostic, i would like to know :)
2019-11-10 01:21:16 <kaniini> the problem is spaces  in the version string
2019-11-10 11:16:17 <z3ntu__> kaniini: then it's just abuild who refuses to accept those versions I guess?
2019-11-10 11:16:40 <Cogitri> Yes
2019-11-10 11:17:14 <Cogitri> It uses the pkg-config versions to guess the dependencies
2019-11-10 11:17:46 <Cogitri> Since we don't support those symbols in `pkgver` it makes sense that abuild cries out about them when they're in the pkg-config file
2019-11-10 11:18:46 <z3ntu__> I'm still very unsure on what I should do with those two packages. For the 0.4.47+ubports version, I can definitely try to rip out the "+ubports", but I have no idea what to do about the mesa 20.0.0-devel package as I was told I shouldn't discard the "-devel" appendix
2019-11-10 11:29:24 <Cogitri> Either just discard the -devel appendix or implement support in abuild for arbitrary version numbers (although that'll be hard, how would you compare those values?)
2019-11-10 11:29:29 <Cogitri> E.g. is 20.0.0-devel >= 20.0.0 or not?
2019-11-10 11:32:26 <mps> or move devel to prefix, i.e. devel-mesa-20.0.0
2019-11-10 11:33:43 <mps> although, 20.0.0 is devel version
2019-11-10 11:35:03 <Cogitri> 20.0.0 will be stable eventually :)
2019-11-10 11:35:51 <mps> ofc, but will have 1 as minor ver
2019-11-10 11:35:54 <Cogitri> And doing the devel-mesa trick will lead to you having to rebuild everything against the mesa-git package because otherwise abuild will try to pull in mesa (non git)
2019-11-10 11:36:39 <mps> ofc, but z3ntu__ is free to play whatever he wants
2019-11-10 11:37:36 <Cogitri> Yes, but that sounds super uncomfortable compared to just stripping the -devel appendix :)
2019-11-10 11:38:33 <mps> agree with you, and don't understand what and why he is doing his way
2019-11-10 12:01:56 <kaey> Cogitri: semver specifies exactly how to compare such versions
2019-11-10 12:04:50 <Cogitri> I don't see it specifying that for arbitrary number/letter combinations
2019-11-10 12:06:17 <Cogitri> It does specify that you should discard metadata denoted by `+` though
2019-11-10 12:59:27 <z3ntu__> mps: We have mesa packaged from a recent commit to get features and bugfixes for drivers like lima quicker: https://gitlab.com/postmarketOS/pmaports/blob/master/temp%2Fmesa-git%2FAPKBUILD - I'm just saying that the abuild update broke the build process there where it worked fine before
2019-11-10 13:25:31 <mps> z3ntu__: doesn't lima work with 19.2.x
2019-11-10 13:28:50 <z3ntu__> lima is still in very active development and fixes and new features (which we need for some devices) are only in git master
2019-11-10 13:31:39 <mps> z3ntu__: I remember, I aslo advocated and worked with PureTryOut[m] on upgrades because of these new drivers
2019-11-10 13:33:04 <mps> and you can add git commit hash to current version, and when 20.0.0 is released just remove git hash
2019-11-10 13:34:06 <PureTryOut[m]> 
ACTION is still waiting for a newer linux-vanilla 😛

2019-11-10 13:35:47 <mps> and you run your own build when you wait :)
2019-11-10 13:36:02 <mps> as I do
2019-11-10 13:36:04 <Cogitri> PureTryOut: Same here
2019-11-10 13:37:04 <mps> I wanted to ask n_copa to start with -rc6 but seeing how he is busy I didn't
2019-11-10 13:38:30 <mps> and in a few hours I expect -rc7, impatient to run it on arm's
2019-11-10 13:49:03 <PureTryOut[m]> Yeah I can run my own indeed. I probably will eventually, but it'd be nice to not need to do that 😉
2019-11-10 14:47:30 <kaey> Cogitri: section 9 says what symbols are allowed, section 11 says how to compare them
2019-11-10 14:50:50 <Cogitri> Yes, but that section doesn't make sense at least in mesa's example
2019-11-10 14:50:57 <Cogitri> Devel would be above alpha/beta but below rc
2019-11-10 14:54:55 <z3ntu__> mesa doesn't make alpha/beta releases, just -rc and stable releases
2019-11-10 14:54:58 <z3ntu__> so it would work
2019-11-10 14:56:06 <Cogitri> In that one case, yes
2019-11-10 16:16:51 <artok> hmm.. getting bad signatures from edge mirror. is there still something happening on repos?
2019-11-10 16:19:54 <clandmeter> which mirror?
2019-11-10 16:19:56 <clandmeter> cdn?
2019-11-10 16:20:04 <artok> alpine.mirror.far.fi
2019-11-10 16:20:20 <clandmeter> which pkg?
2019-11-10 16:21:11 <artok> boost-program_options and linux-firmware-brcm
2019-11-10 16:22:02 <artok> now trying dl-4, and so far it seems to work
2019-11-10 16:23:13 <clandmeter> seems fine via cdn
2019-11-10 16:24:16 <artok> well changing mirror seemed to work
2019-11-10 19:26:31 <maxice8> PureTryOut: reviewed your discover MR
2019-11-10 19:42:10 <mps> llvm6 build fails on 32bit arch'es, should it be disabled on them till fix is found
2019-11-10 19:42:50 <Cogitri> How come it worked before?
2019-11-10 19:43:55 <mps> something in it's makedepends is changed which stops it to build, probably
2019-11-10 19:44:52 <mps> maybe python 3.8, 2695eaec6fd0169b07b4a5a5a531a0fb77918c72
2019-11-10 19:47:48 <mps> maybe to disable check, as it is for llvm5
2019-11-10 19:49:21 <mps> at least on arm32 check is disabled for llvm5
2019-11-11 09:04:34 <maxice8> Can i get !1191  merged ?
2019-11-11 09:33:10 <russkel> can anyone recommend what I do in this instance? https://github.com/assimp/assimp/issues/2733
2019-11-11 09:33:17 <russkel> upstream is being no help
2019-11-11 09:34:01 <russkel> can I just comment it out?
2019-11-11 09:34:28 <maxice8> if you're able just patch it out, if not then disable the arch it fails on
2019-11-11 09:34:29 <maxice8> @ncopa thanks for the merge
2019-11-11 09:34:31 <maxice8> PureTryOut: Want to take testing/falkon to community ?
2019-11-11 09:35:12 <maxice8> in the code ? no clue didn't look at it
2019-11-11 09:38:52 <russkel> maxice8, if I comment it out presumably that will fix the issue if nothing happens to be longer than long int?
2019-11-11 09:39:01 <russkel> wait what's the difference between a long and long int?
2019-11-11 09:40:12 <russkel> oh apparently it's the same
2019-11-11 09:52:52 <mps> rnalrd: sorry to annoy you, but you are maintainer of amavis. would you mind to look at !1137
2019-11-11 09:56:06 <mps> would be nice if gitlab send mail to maintainer when new MR created for pkg
2019-11-11 10:15:55 <maxice8> mps: I just tag the maintainer if i think he needs to look at it
2019-11-11 10:16:12 <maxice8> ncopa: made Merge Requests for fixing fribidi secissues
2019-11-11 10:17:38 <ncopa> russkel: (re)defining size_t sounds wrong
2019-11-11 10:18:16 <ncopa> i guess it should be correct to remove the redefinition, on all arches
2019-11-11 10:20:54 <mps> maxice8: yes, we can tag/assign or something else but I would prefer some automatic and set by policy action
2019-11-11 10:23:48 <ncopa> mps: I agree. would be nice with a bot that could assign to or notify maintainer
2019-11-11 10:32:24 <russkel> ncopa, indeed
2019-11-11 10:32:30 <russkel> I will patch it out entirely
2019-11-11 10:33:18 <mps> would be nice, for example I hesitate to assign MR's because don't like to annoy maintainer and have a hope that s/he will look and notice MR for his/her pkg
2019-11-11 10:34:48 <maxice8> mps: with your suggestion of automatically emailing that will be done every single time
2019-11-11 10:35:59 <mps> maxice8: I don't see a problem, as a maintainers we should be prepared to receive mails for our pkgs
2019-11-11 10:38:25 <mps> yesterday I talked with user on #alpine-linux who had issue with pptpd, i.e. error on starting
2019-11-11 10:39:11 <mps> solution was 'apk add ppp-daemon'. should be ppp-daemon added in depends for pptpd?
2019-11-11 10:40:16 <mps> I asked him/her to fill issue but s/he didn't
2019-11-11 10:40:40 <ncopa> mps: sounds correct to add it to depends, but i dont know pptpd enough
2019-11-11 10:41:13 <ncopa> maybe there are setups where it is useful without ppp-daemon?
2019-11-11 10:41:21 <ncopa> if not, it should be added to depends
2019-11-11 10:41:22 <mps> also I don't used pptpd for years, so not sure
2019-11-11 10:41:40 <mps> s/don't/didn't/
2019-11-11 10:41:40 <alpine-meetbot> mps meant to say: also I didn't used pptpd for years, so not sure
2019-11-11 10:41:54 <ncopa> i mean, that is what we need to check before we add it to depends
2019-11-11 10:42:22 <mps> because that I asked in hope that someone with experience can tell what should be done
2019-11-11 10:43:46 <mps> (and I think dependencies should be set only when it is really needed)
2019-11-11 10:44:34 <maxice8> @z3ntu can you check !1216 ?
2019-11-11 10:54:45 <mps> re pptpd, looked at debian pkg, and it looks like it used mostly as server and that the ppp-daemon deps should be added
2019-11-11 10:55:28 <mps> (if anyone still use this protocol in the wild)
2019-11-11 11:11:35 <z3ntu> maxice8: fine for me
2019-11-11 11:13:32 <maxice8> Sweet, thank you.
2019-11-11 11:13:46 <maxice8> Recently switched to sway and i'm using waybar instead of swaybar
2019-11-11 11:14:13 <mps> ncopa: I like this method of development, no ML, no MR no PR, when we know for issue/bug/problem just go and fix it :)
2019-11-11 11:14:29 <ncopa> :)
2019-11-11 11:24:11 <mps> kernel 5.4-rc7 works fine on aarch64 :)
2019-11-11 11:25:33 <ncopa> nice
2019-11-11 11:25:36 <mps> and Linus wrote maybe he will not release -rc8 next sunday but just 5.4
2019-11-11 11:25:48 <mps> we will see
2019-11-11 11:25:51 <ncopa> good
2019-11-11 11:26:01 <ncopa> i will try get the 3.11 builders up this week
2019-11-11 11:26:09 <mps> now I'm building -virt
2019-11-11 11:26:21 <mps> to test it in qemu first
2019-11-11 11:26:31 <ncopa> im trying to upgrade chromium now
2019-11-11 11:26:43 <ncopa> there is a security issue that needs fixing
2019-11-11 11:26:52 <mps> uhhh, I feel you pain
2019-11-11 11:27:25 <ncopa> its not that bad, thanks to the powerful build machines from packet
2019-11-11 11:28:26 <mps> fixing it on every release requires a lot of work. I stopped to look at it about 10 months ago
2019-11-11 11:29:38 <ncopa> yeah, there are some work needed indeed
2019-11-11 12:34:44 <PureTryOut[m]> <maxice8 "PureTryOut: Want to take testing"> Sure. You're the one maintaining it though
2019-11-11 12:35:20 <maxice8> See the MR I tagged you in
2019-11-11 13:55:22 <rnalrd> mps, thanks for the heads up. I've suggested a couple of changes.
2019-11-11 13:55:25 <rnalrd> thanks
2019-11-11 14:01:39 <mps> rnalrd: thanks for review and comments. I will fix it according your suggestions, and then remove WIP
2019-11-11 14:02:56 <mps> I noticed one thing though, on first install it will not start asking to first run 'sa-update' which is executable in spamassassin
2019-11-11 14:04:26 <mps> should be spamassassin added to depends because that, although spamassassin can be removed after initial run of 'sa-update' and amavis continues to work
2019-11-11 14:46:49 <maxice8> PureTryOut: i reviewed the discover MR and suggested a few changes
2019-11-11 14:50:20 <PureTryOut[m]> Yeah noticed it, will apply them soon
2019-11-11 15:02:09 <maxice8> please tag me once done so i can merge it quickly
2019-11-11 15:02:24 <maxice8> @ncopa i made MRs to fix fribidi secissues
2019-11-11 15:03:20 <ncopa> maxice8: thanks! will look at those now that i have pushed chromium
2019-11-11 15:13:13 <maxice8> Yay ty
2019-11-11 15:20:45 <ncopa> maxice8: can you help me close the issue?
2019-11-11 15:22:07 <maxice8> I can close it later currently waiting to get a band-aid change
2019-11-11 18:13:08 <fredrigu> _ikke_: I posted in the wrong channel, did you see my message in alpine-linux or do you want me to repost it here?
2019-11-11 18:15:36 <_ikke_> fredrigu: I saw them
2019-11-11 18:16:06 <_ikke_> fredrigu: Can you elaborate what you want to achieve?
2019-11-11 18:16:42 <_ikke_> Ah, I think I follow now
2019-11-11 18:16:52 <_ikke_> fredrigu: You want to expand on what ncopa started, right?
2019-11-11 21:09:11 <iveqy> _ikke_: I'm not sure I know what ncopa started
2019-11-11 21:09:25 <iveqy> _ikke_: do you know about CI and workers in gitlab?
2019-11-11 21:11:43 <iveqy> _ikke_: I want the tests for apk-tools to be run everytime you do a merge request, and probably also deny all merging before we pass the tests
2019-11-11 21:13:25 <PureTryOut[m]> maxice8: please wait for the CI to complete before merging my MR's
2019-11-11 21:22:57 <iveqy> PureTryOut[m]: are you running CI in gitlab?
2019-11-11 21:24:08 <PureTryOut[m]> yes
2019-11-11 21:24:23 <PureTryOut[m]> maxice8: please merge https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1234 once CI completes
2019-11-11 21:24:45 <maxice8> i'll merge the kwin change
2019-11-11 21:24:52 <maxice8> https://git.alpinelinux.org/aports/commit/?id=c682f98667b9e3cadb19773ac7f2b5ce6f766a70
2019-11-11 21:24:58 <_ikke_> iveqy: yes, I'm involved with the runners
2019-11-11 21:25:13 <_ikke_> iveqy: what do you mean with apk-tools?
2019-11-11 21:25:20 <PureTryOut[m]> Oh fixed the tests, even better
2019-11-11 21:25:29 <iveqy> _ikke_: So why aren't the runners running on my MR? What have I missed? https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/3
2019-11-11 21:26:32 <PureTryOut[m]> I think that image entry is wrong
2019-11-11 21:26:46 <iveqy> PureTryOut[m]: thanks, I can see that CI works on the aports repo, wonder why I can't get it to work on apk-tools.git
2019-11-11 21:27:01 <iveqy> PureTryOut[m]: maybe, I can try with the same as aports
2019-11-11 21:27:02 <PureTryOut[m]> Should be `alpinelinux/edge` or some other version
2019-11-11 21:27:23 <_ikke_> iveqy: You need to add proper tags
2019-11-11 21:27:27 <PureTryOut[m]> Just use `alpinelinux/edge` or `alpinelinux/latest`
2019-11-11 21:27:48 <_ikke_> alpine is correct
2019-11-11 21:27:53 <_ikke_> which defaults to alpine:latest
2019-11-11 21:28:08 <iveqy> _ikke_: oh I see, what tags would that be?
2019-11-11 21:28:37 <iveqy> docker-alpine?
2019-11-11 21:29:50 <_ikke_> yeah, docker-alpine
2019-11-11 21:30:21 <_ikke_> I don't think it matters on what arch it runs, correct?
2019-11-11 21:30:29 <iveqy> correct
2019-11-11 21:30:47 <maxice8> PureTryOut: Merged kwin
2019-11-11 21:30:47 <_ikke_> then docker-alpine should suffice
2019-11-11 21:31:01 <iveqy> unfortunately I need https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/2 to be merged before the CI MR can be merged, otherwise the tests will fail
2019-11-11 21:33:30 <_ikke_> someone maintaining apk-tools should do that
2019-11-11 21:34:13 <iveqy> _ikke_: yeah I know, I've tagged @fabled :)
2019-11-11 21:34:53 <_ikke_> iveqy: ncopa added support for testing just a couple of days ago to apk-tools :)
2019-11-11 21:35:29 <_ikke_> oh, no, that was abuild, not apk-tool
2019-11-11 21:35:31 <_ikke_> apk-tools
2019-11-11 21:37:00 <iveqy> _ikke_: phew, then I at least beat him to that on apk-tools :). I find this whole gitlab introductions to alpine being awesome, you're doing a great job
2019-11-11 21:37:53 <_ikke_> It still needs to be enabled in gitlab for abuild
2019-11-11 21:42:30 <iveqy> _ikke_: alright, I've a lot more work to do on apk before taking on abuild
2019-11-11 21:43:00 <_ikke_> np, I'll handle abuild
2019-11-11 22:40:22 <mps> do we still use 'cd $builddir' for pkgs in main on edge
2019-11-11 22:42:48 <mps> and what to do with build() function which have only 'return 0' in its body
2019-11-11 22:49:19 <maxice8> build functions with only return 0 can be removed
2019-11-11 22:49:40 <maxice8> i don't remember, but in a future version all supported abuild versions will have implicit cd $builddir
2019-11-11 22:49:46 <mps> maxice8: thanks, thought so and removed it
2019-11-11 22:49:46 <maxice8> and when that happens then we can start removing cd $builddir on edge
2019-11-11 22:50:07 <maxice8> i'll go do a commit digging
2019-11-11 22:50:43 <mps> community and testing on edge have already implicit 'cd $builddir', but don't know for main
2019-11-11 22:53:35 <maxice8> i think we can already
2019-11-11 22:53:45 <maxice8> v2.29.0 of abuild added the feature
2019-11-11 22:54:02 <maxice8> and the last supported version of alpine is 3.7 which has abuild 3.1.0
2019-11-11 22:54:58 <mps> thanks for digging :)
2019-11-11 22:56:43 <mps> PureTryOut[m]: looks like some builders doesn't listen ;)
2019-11-11 22:57:18 <PureTryOut[m]> Hmm? It was going after I did it
2019-11-11 23:00:10 <mps> armhf and armv7 are idle
2019-11-11 23:08:39 <maxice8> mps
2019-11-11 23:08:41 <maxice8> give me a name for a new release of atools
2019-11-11 23:16:10 <PureTryOut[m]> They're idle because they are done 😉
2019-11-11 23:16:31 <mps> maxice8: what's wrong with current name? I'm already accustomed to it
2019-11-11 23:16:55 <maxice8> release name
2019-11-11 23:16:58 <maxice8> not the name of the tool
2019-11-11 23:17:19 <maxice8> i went with pocky, the japanese sweet
2019-11-11 23:17:25 <maxice8> november 11 is national pocky (inb4 weeb)
2019-11-11 23:17:39 <mps> ah, I'm bad at giving names. 'jungle fixer' :D
2019-11-11 23:18:01 <mps> chaos calmer
2019-11-12 09:08:28 <ncopa> seems like i will not be able to go to fosdem after all :-(
2019-11-12 09:09:23 <maxice8> rip :(
2019-11-12 09:17:53 <clandmeter> ncopa: thats too bad
2019-11-12 09:23:34 <AinNero> mh, reading about it, im considering
2019-11-12 09:23:52 <AinNero> what are the nice feats of FOSDEM?
2019-11-12 09:52:54 <fredrigu> _ikke_: thanks for your help yester, I now have the tests working for apk-tools :)
2019-11-12 09:53:10 <_ikke_> cool :-)
2019-11-12 11:14:06 <rnalrd> maxice8, just to sync on the GL MRs for packages I maintain: how do you expect me to communicate if it's ok or if I feel that changes are needed?
2019-11-12 11:14:58 <rnalrd> I did "thumbs up" if it's okay and made local modification and pushed for changes... is it okay for you?
2019-11-12 11:15:43 <maxice8> Comment an OK or contact me here
2019-11-12 11:16:02 <maxice8> Sadly thumbs up and other reactions don't trigger an email notification the same way comments do
2019-11-12 11:16:25 <rnalrd> yeah, i thought so
2019-11-12 11:16:28 <rnalrd> k
2019-11-12 11:17:46 <maxice8> i'll generally take a few hours to a few days max to answer
2019-11-12 12:36:42 <maxice8> @ncopa thanks for the merges :D
2019-11-12 15:02:04 <pheoxy> where should I start on building my own raspberry pi aarch64 images? Is there some repo that already does this?
2019-11-12 15:02:50 <pheoxy> wiki is a little confusing
2019-11-12 15:14:45 <mps> pheoxy: aports/scripts and look on scripts there
2019-11-12 15:23:55 <maxice8> I'll be unavailable for the next 3 to 4 days, travelling to a new country and settling in with immigration authorities and municipality and all that stuff
2019-11-12 15:27:49 <fredrigu> maxice8: good luck!
2019-11-12 15:30:24 <mps> maxice8: see you, and good luck
2019-11-12 15:48:57 <maxice8> Supervisor keeps failing
2019-11-12 15:53:42 <mps> fail on some tests
2019-11-12 15:54:49 <mps> I looked but this is python issues and I don't know much python
2019-11-12 15:55:04 <ncopa> it fails because it tries to craete a file named /tmp/log
2019-11-12 15:55:23 <ncopa> but apparently some other package  craeted a directory named /tmp/log/*
2019-11-12 15:55:38 <ncopa> and did not clean up after itself
2019-11-12 15:56:17 <ncopa> rebooting the builder solves it because it clears /tmp on boot
2019-11-12 15:56:50 <mps> ah, maybe clean everything at each build start
2019-11-12 15:57:17 <ncopa> build-edge-aarch64 [~]$ find /tmp/log | tpaste
2019-11-12 15:57:17 <ncopa> http://tpaste.us/7Kv1
2019-11-12 15:57:30 <ncopa> we should clean ewverything on eaxch build yes
2019-11-12 15:57:40 <ncopa> but the only preper way to do so is to create a temp container
2019-11-12 15:58:08 <ncopa> would be better to fix whatever pacakges that creates that
2019-11-12 15:58:51 <mps> yes, agree that pkgs should clean after self
2019-11-12 16:00:11 <mps> but we will see pkgs from time to rime which don't
2019-11-12 16:22:33 <_ikke_> creating a container also provents projects from messing with ~/ or .git
2019-11-12 16:24:49 <fredrigu> when in apk-tools/tests I try to run make repo1 which, if I understand correctly, should give me an repo for testing. However this fails for me, can anyone else reproduce this? I want to know if I am doing something wrong or if the apk-tools tests just simply aren't working anymore
2019-11-12 16:39:55 <fredrigu> turns out I'd linked /bin/ash to /bin/dash which isn't supported by abuild
2019-11-12 16:52:21 <mps> Cogitri: looks like !747 should be closed
2019-11-12 16:58:37 <mps> maxice8: !1251 is superseded by 3680771336887cc5b2b0424fba4c1d4446ad592d
2019-11-12 17:00:06 <mps> and, btw, I see you removed 'cd $builddir'. should we do that for all pkgs in main? not now but when we upgrade i.e. one by one
2019-11-12 17:00:45 <_ikke_> Just like other style issues, just remove them opportunistically
2019-11-12 17:01:43 <mps> _ikke_: ofc, I wanted to say that but you better rephrased it
2019-11-12 17:02:15 <mps> my question is/was, should we do that for edge from now on
2019-11-12 17:09:23 <_ikke_> I guess so
2019-11-12 17:12:41 <mps> ok, thanks. would be nice if n_copa can confirm as top level authority
2019-11-12 17:46:02 <_ikke_> maxice8: ndctl failed: "ERROR: ndctl-dev*: usr/lib/pkgconfig/libdaxctl.pc: pkgconf version 67.git94fe5f8e is invalid"
2019-11-12 17:49:15 <_ikke_> Not sure why it only fails on the builders
2019-11-12 18:11:35 <makaveli_> \q
2019-11-12 18:11:40 <makaveli_> \quit
2019-11-12 18:51:00 <HRio> can PR12091 get a security label?
2019-11-12 18:51:41 <_ikke_> Done
2019-11-12 18:51:45 <HRio> thx
2019-11-12 20:10:19 <wenerme[m]> andypost: PR 12051 please help review
2019-11-12 20:11:07 <_ikke_> maxice8: ah, after system upgrade, I get the failure locally as well now
2019-11-12 20:17:55 <wenerme[m]> PR12092  please help review, tinc-pre was removed due to test failed
2019-11-12 20:28:02 <_ikke_> ugh, great. ndctl tries to grep the version from aports :-/
2019-11-12 20:35:38 <_ikke_> maxice8: fixed
2019-11-12 20:57:26 <andypost[m]> @wenerme:matrix.org: I bet it used, I'm afk to check
2019-11-12 21:00:46 <maxice8> ikke: thank you
2019-11-12 21:00:59 <maxice8> I'm in airport having problem with baggage check-in
2019-11-12 21:01:17 <_ikke_> maxice8: heh, success with that. Airports can be stressful
2019-11-12 22:33:04 <maxice8> All fixed now but what a mess
2019-11-13 09:17:00 <ahmedbilal> fcolista: Why don't etcd start with `service etcd start`?
2019-11-13 09:28:28 <fcolista> ahmedbilal, ?
2019-11-13 09:28:40 <fcolista> alpine uses openrc
2019-11-13 09:29:05 <fcolista> what problem do you have with etcd?
2019-11-13 09:30:46 <ahmedbilal> fcolista: If I start it with service it don't, but, if I start it with `etcd` it works. Probably, `service etcd start` isn't creating the data directory.
2019-11-13 09:32:24 <fcolista> care to check the logs and specify which version are you using?
2019-11-13 09:32:44 <ahmedbilal> fcolista: latest from edge repo
2019-11-13 09:32:58 <ahmedbilal> Where can I check logs
2019-11-13 09:48:50 <fcolista> /var/log/messages
2019-11-13 09:48:52 <fcolista> Nov 13 09:48:23 pig daemon.warn supervise-daemon[570]: /usr/bin/etcd, pid 571, exited with return code 1
2019-11-13 09:51:57 <fcolista> conf.yaml is not parsed correctly
2019-11-13 09:51:59 <fcolista> string into Go struct field configYAML
2019-11-13 09:52:25 <fcolista> let me check...it's using json to parse yaml file...
2019-11-13 09:57:06 <fcolista> https://github.com/charmed-kubernetes/bundle/issues/619
2019-11-13 10:02:15 <fcolista> figured
2019-11-13 10:02:26 <fcolista> upgrade is on the way, ahmedbilal
2019-11-13 10:02:43 <ahmedbilal> fcolista: Thank you very much. You are really helpful.
2019-11-13 10:06:26 <clandmeter> ncopa: can you create a new edge snapshot?
2019-11-13 10:06:36 <clandmeter> i guess it triggers a new edge docker image?
2019-11-13 10:23:53 <ncopa> clandmeter: yes
2019-11-13 10:24:11 <clandmeter> current edge image is broken
2019-11-13 10:24:28 <ncopa> its just outdated
2019-11-13 10:24:31 <ncopa> old musl
2019-11-13 10:24:38 <clandmeter> i know
2019-11-13 10:24:40 <ncopa> we need unblock the builders
2019-11-13 10:24:58 <clandmeter> but most ppl dont update their base image
2019-11-13 10:25:09 <ncopa> seems like build-edge-s390x has issues with rstcheck
2019-11-13 10:25:51 <ncopa> i´ll tag a snapshot release as soon as all the builders are on idle
2019-11-13 10:29:21 <ncopa> edge builders that is
2019-11-13 10:30:29 <fcolista> ahmedbilal: http://dup.pw/aports/0c44d7b3
2019-11-13 10:42:47 <ahmedbilal> fcolista: thanks
2019-11-13 10:53:34 <clandmeter> maxice8: any specific reason for a2d24547cf7eea626c9d9953dfd65e62752f5aa3?
2019-11-13 11:13:28 <clandmeter> packaging python is a waste of time
2019-11-13 11:18:27 <ahmedbilal> clandmeter: but they are really helpful for end users if they takes a lot of time to compile e.g grpcio
2019-11-13 11:20:22 <mps> (using python is a waste of resources)
2019-11-13 11:53:45 <ahmedbilal> mps: not really. It depends on what kind of resource efficiency you needed.
2019-11-13 12:20:40 <clandmeter> ahmedbilal: im refering to py applications that are packed in aports
2019-11-13 13:08:50 <ahmedbilal> clandmeter: I am also talking about the packages packed in aports. Try to install grpcio using pip. It would take 15-30 minutes. But, if we use apk it is instant as it is pre-compiled.
2019-11-13 13:10:24 <clandmeter> That's not what i mean
2019-11-13 13:16:50 <ahmedbilal> clandmeter:Ok.
2019-11-13 14:18:35 <mps> ppc64le builder doesn't work
2019-11-13 14:21:26 <_ikke_> mps: let's see
2019-11-13 14:22:06 <_ikke_> 15:05:58      algitbot │ edge/main/ppc64le: uploaded
2019-11-13 14:22:14 <_ikke_> that was 15 minutes ago
2019-11-13 14:22:15 <mps> _ikke_: sorry, no. looks like it failed on  /community/py3-google-auth
2019-11-13 14:33:25 <Cogitri> Does someone happen to be on Meetingcpp this week?
2019-11-13 14:34:44 <_ikke_> Does not ring a bell
2019-11-13 14:36:18 <Cogitri> It's a C++ centric developer conference, so I guess the chance that someone else attends isn't that high
2019-11-13 14:38:14 <mps> Cogitri: would you close !747 it is 'overwritten'
2019-11-13 14:39:59 <_ikke_> mps: superseeded?
2019-11-13 14:40:01 <mps> if you can't because notebook issue I offer my hands :)
2019-11-13 14:40:31 <mps> _ikke_: not sure what happened but newer version is already in aports
2019-11-13 14:41:14 <_ikke_> 4c11b21fb95fe5a73a4f231a025d4762bbe6e68d
2019-11-13 14:41:41 <Cogitri> Closed it
2019-11-13 14:42:14 <mps> I think is first upgraded with libevent rebuild
2019-11-13 14:43:15 <Cogitri> I got my borrowed laptop yesterday, so I guess I might be able to contribute again after the conference :)
2019-11-13 14:44:25 <mps> Cogitri: enjoy on conference :)
2019-11-13 15:48:34 <Cogitri> Thanks :)
2019-11-13 16:58:07 <nmeum> ncopa: https://git.alpinelinux.org/abuild/commit/?id=71d9d5233b9db3be91510addcb28721545d93185 broke abuild rootbld since SOURCE_DATE_EPOCH is unset when using abuild rootbld now, causes it to fail with `touch: invalid date '@'`
2019-11-13 17:07:16 <nmeum> https://gitlab.alpinelinux.org/alpine/abuild/issues/9978
2019-11-13 17:09:31 <_ikke_> Is there an alternative to reverting? afaik this was done to make reproducable builds possible.
2019-11-13 17:10:55 <nmeum> the particular change was probably done to achieve a speedup, SOURCE_DATE_EPOCH (and therefore reproducable builds) should still work when reverting the commit
2019-11-13 17:11:01 <nmeum> working on an alternative though
2019-11-13 17:11:03 <nmeum> gimme a sec :)
2019-11-13 17:11:43 <_ikke_> "getting the commit date can be timeconsuming so only do it once we need
2019-11-13 17:11:45 <_ikke_> it."
2019-11-13 17:11:47 <_ikke_> right
2019-11-13 17:13:00 <nmeum> why is SOURCE_DATE_EPOCH not just set from create_apks? seems to be the only function using that variable
2019-11-13 17:13:14 <nmeum> no, it isn't oops
2019-11-13 17:19:59 <nmeum> _ikke_: https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/8/diffs this is the alternative solution which doesn't have a performance impact (compared to reverting the change)
2019-11-13 17:21:28 <_ikke_> Sounds reasonable
2019-11-13 17:24:24 <nmeum> should I push it as is or wait if ncopa has any comments on it?
2019-11-13 17:25:21 <_ikke_> How easily is this testable?
2019-11-13 17:26:01 <_ikke_> https://gitlab.alpinelinux.org/alpine/abuild/blob/master/tests/abuild.bats
2019-11-13 17:27:28 <nmeum> well tests would be: (1) check that abuild -r still works (2) check that abuild rootbld works again (3) check that abuild -r with SOURCE_DATE_EPOCH set does the right thing
2019-11-13 17:27:45 <_ikke_> g2g
2019-11-13 17:28:04 <nmeum> so you are ok with pushing it?
2019-11-13 17:28:47 <nmeum> I guess I would just push it to the abuild repo for now and backport it later
2019-11-13 21:10:14 <_ikke_> regarding tmp2-tss build failure on s390x: https://github.com/tpm2-software/tpm2-tss/issues/1547
2019-11-14 02:58:21 <kaey> telegraf tests flake on armv7, every time i restart it different tests fail. should i just remove it from arch?
2019-11-14 05:41:11 <_ikke_> kaey: It's not built for armv7 tam?
2019-11-14 05:41:13 <_ikke_> atm*
2019-11-14 05:41:23 <_ikke_> arch="x86_64 aarch64 armhf"
2019-11-14 05:43:09 <kaey> _ikke_: !1262 builder is named armv7, I assume it's armhf
2019-11-14 05:44:17 <_ikke_> no, armhf is a separate arch
2019-11-14 05:44:45 <_ikke_> I wonder why abuild is building the package, normally it should not build it in that case
2019-11-14 05:45:09 <_ikke_> See for example: https://gitlab.alpinelinux.org/kaey/aports/-/jobs/13586
2019-11-14 05:50:00 <kaey> so there is no armhf CI at all?
2019-11-14 05:50:34 <_ikke_> kaey: no, there is not
2019-11-14 05:51:45 <kaey> ok i'll remove it then. don't want to support arches without ci
2019-11-14 06:16:38 <kaey> it still runs armv7
2019-11-14 06:17:15 <_ikke_> Yeah, something strange is going on
2019-11-14 06:17:36 <_ikke_> I'll have to investigate why that happens
2019-11-14 07:40:48 <ncopa> maxice8: seems like 3784181705be943196145acbfa8858783be34bdf breaks testing/py3-botocore dependency
2019-11-14 07:43:28 <ncopa> https://github.com/boto/botocore/commit/e87e7a745fd972815b235a9ee685232745aa94f9
2019-11-14 07:51:06 <mps> ncopa: he told few days ago that he will be 'offline' for some time
2019-11-14 07:51:13 <ncopa> ok
2019-11-14 07:51:41 <mps> if someone could step and fix this?
2019-11-14 07:51:47 <ncopa> seems like its Valery Kartel's packages
2019-11-14 07:52:18 <ncopa> apparently it is due to it requires newer setuptools, which we have
2019-11-14 07:52:27 <ncopa> at least i suppose we have
2019-11-14 07:53:49 <mps> not in the my field of knowledge
2019-11-14 08:05:30 <Cogitri> Ugh, python deps sure are kind of a pain to get right :/
2019-11-14 08:06:21 <Cogitri> I think maxice8 started to work on automatic dep recognition for python packages on abuild (like we do with sonames) some time ago though
2019-11-14 08:12:54 <mps> (eh, remember days when I started learn computing, assembly langs and cpu/comp architectures were first and obligatory to learn)
2019-11-14 09:12:49 <ncopa> tmhoang: we have an interesting floating point error in py3-srsly
2019-11-14 09:13:07 <ncopa> >       self.assertEqual(-1.7893, ujson.loads("-1.7893"))
2019-11-14 09:13:07 <ncopa> E       AssertionError: -1.7893 != -1.7893000000000001
2019-11-14 09:13:46 <ncopa> i guess we can simply drop that test
2019-11-14 09:13:48 <ncopa> ?
2019-11-14 09:20:32 <nmeum> ncopa: are you ok with https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/8/ ? (without it abuild rootbld doesn't work)
2019-11-14 09:20:41 <nmeum> if you are ok with it I can merge it and backport it to aports
2019-11-14 09:26:59 <ncopa> nmeum: looks good
2019-11-14 09:27:14 <ncopa> i was thinking of exactly this solution when you mentinoed abuild rootbld was broken
2019-11-14 09:27:22 <ncopa> i think we should also add a test for it
2019-11-14 09:27:39 <ncopa> but i guess we should first add a trivial test for building a package
2019-11-14 09:35:43 <nmeum> I will just merge it as is then and backport it, to make sure abuild rootbld works again on edge
2019-11-14 09:35:48 <nmeum> we can add tests afterwards
2019-11-14 09:36:06 <_ikke_> ncopa: :)
2019-11-14 10:08:06 <maxice8> ncopa: re: botocore, my bad then I just check the requires on the source
2019-11-14 12:37:29 <ncopa> its impossible to check all revers dependencies when updating python packates
2019-11-14 12:40:56 <_oxr463> Please see my latest package bump, https://gitlab.alpinelinux.org/alpine/aports/issues/10952; Thank you
2019-11-14 15:37:40 <ncopa> tmhoang: can you please have a look at libseccomp testsuite failure for s390x?
2019-11-14 16:05:31 <tmhoang> ncopa: I will try to find some cycles this week and next. Quite busted these months ...
2019-11-14 16:08:08 <ncopa> ok. thanks
2019-11-14 16:08:19 <ncopa> seems like openjdk11 was disabled on s390x too
2019-11-14 16:08:22 <ncopa> now sure why
2019-11-14 16:08:43 <ncopa> \o/ builders are finally all done!
2019-11-14 16:09:25 <tmhoang> ncopa: \o/
2019-11-14 16:09:31 <tmhoang> ncopa: `https://gitlab.alpinelinux.org/alpine/aports/merge_requests/998` for openjdk11
2019-11-14 16:09:48 <tmhoang> it was hang on builder and I cannot reproduce on my local machine and CI aslo passed
2019-11-14 16:10:14 <tmhoang> ncopa: so we merge aagain and see how the builder goes ?
2019-11-14 16:10:44 <tmhoang> ncopa: also it looks like Cogitri is working on rust for s390x, could we wait a bit for it for 3.11 ?
2019-11-14 16:10:52 <ncopa> no :)
2019-11-14 16:11:04 <tmhoang> but you said it would be end of Nov, no ?
2019-11-14 16:11:09 <ncopa> we are already past feature freeze
2019-11-14 16:11:17 <tmhoang> aw :(
2019-11-14 16:11:18 <tmhoang> my bad
2019-11-14 16:11:19 <ncopa> which is around mid oct
2019-11-14 16:12:02 <ncopa> if we try get rust for s390x in, it will not be end of nov
2019-11-14 16:12:34 <_ikke_> ncopa: maybe it's good to anounce these things a bit in advance so that everyone is on the same page (I know you're busy)
2019-11-14 16:12:36 <ncopa> end ov nov is if i drop everything aon only focus 100% on getting the release out asap
2019-11-14 16:12:43 <ncopa> yeah
2019-11-14 16:12:48 <ncopa> i guess we should document it
2019-11-14 16:12:58 <ncopa> march an oct is feature freeze
2019-11-14 16:13:09 <ncopa> May and Nov is release
2019-11-14 16:13:56 <ncopa> im tagging new snapshot release
2019-11-14 16:14:03 <tmhoang> ncopa: ok thanks for info. I was not aware (and didn't actually ask ) in the past 2 years :)
2019-11-14 16:14:20 <tmhoang> ncopa: lets move rust out then. But openjdk11 should be fine ?
2019-11-14 16:14:28 <tmhoang> aw I have a patch to enable ocaml but was so busy
2019-11-14 16:14:32 <tmhoang> ...
2019-11-14 16:14:33 <ncopa> i guess openjdk should be ok
2019-11-14 16:14:46 <ncopa> yeah, thats the problem, we are all too busy
2019-11-14 16:15:19 <tmhoang> ncopa: the situation of ocaml is like this : the patch in repo is wrong, and it failed s390x, so if we change the patch - meaning s390x working - is that ok to get it in ?>
2019-11-14 16:15:37 <ncopa> bugfixes are all ok
2019-11-14 16:15:38 <tmhoang> basically delete 10 lines
2019-11-14 16:15:40 <tmhoang> ok great
2019-11-14 16:15:49 <tmhoang> I'm hitting tonight, hang with me
2019-11-14 16:15:55 <tmhoang> (feel free to tag rc)
2019-11-14 17:59:50 <nmeum> hm
2019-11-14 18:00:19 <_ikke_> o/
2019-11-14 18:00:22 <_ikke_> What's on your mind
2019-11-14 18:01:07 <mps> imo, rc should wait to new kernel, 5.4
2019-11-14 18:01:35 <_ikke_> any idea when that's released?
2019-11-14 18:01:52 <nmeum> https://tpaste.us/PMMK anybody else getting this error when using gdb on edge?
2019-11-14 18:02:14 <mps> _ikke_: in a week or two
2019-11-14 18:02:33 <nmeum> maybe this is also an issue with python 3.8 from the changelog „The compiler now produces a SyntaxWarning when identity checks (is and is not) are used with certain types of literals (e.g. strings, numbers).”
2019-11-14 18:02:48 <nmeum> ah
2019-11-14 18:02:53 <nmeum> it is a python 3.8 issue
2019-11-14 18:02:59 <nmeum> upstream has a patch for it
2019-11-14 19:03:00 <telmich> good evening
2019-11-14 19:03:22 <telmich> what are the plans/policy for kernel upgrades in alpine? I assume it might be changed with a new minor version of alpine?
2019-11-14 19:03:51 <telmich> I'm wondering, because the current kernel has a routing bug that prevents IPv4 routes to be added via IPv6 next hops and it is certainly fixed in 5.3.x
2019-11-14 19:12:39 <mps> telmich: we hope that the 5.4 kernel will be default in next stable
2019-11-14 19:13:23 <mps> if your question is about that, or about 3.10 next then no 4.19 will stay there
2019-11-14 21:47:16 <mps> abuild now cannot work outside 'git dir'
2019-11-14 21:52:16 <_ikke_> Because it tries to get the commit date I guess?
2019-11-14 21:52:50 <mps> right
2019-11-14 21:53:20 <mps> 'touch: invalid date format ‘@’'
2019-11-14 21:54:51 <mps> hm, same in 'git dir'
2019-11-14 21:59:22 <_ikke_> are you using rootbld?
2019-11-14 22:02:54 <mps> no, from my workstation 'cd aports/testing/qtel' 'abuild deps unpack prepare build rootpkg'
2019-11-14 22:03:07 <mps> 'abuild -r' works
2019-11-14 22:03:41 <mps> uh, 'cd aports-old/testing/qtel'
2019-11-14 22:04:18 <_ikke_> hmm, I see.
2019-11-14 22:04:31 <_ikke_> build_abuildrepo is only called for `all`
2019-11-14 22:04:49 <_ikke_> build_abuildrepo calls set_source_date
2019-11-14 22:05:13 <_ikke_> try abuild set_source_date deps unpack prepare build rootpkg
2019-11-14 22:05:45 <mps> lets see
2019-11-14 22:09:30 <mps> works with 'set_source_date' without error
2019-11-14 22:09:34 <_ikke_> right
2019-11-14 22:14:45 <_ikke_> worth opening an issue at https://gitlab.alpinelinux.org/alpine/abuild/
2019-11-14 22:17:22 <mps> please open it because you better understand this and you will better explain than I
2019-11-14 22:21:09 <mps> could it be this already https://gitlab.alpinelinux.org/alpine/abuild/merge_requests/9
2019-11-14 22:21:35 <qa3Txu0iak0F> i had the same error yesterday ('touch: invalid date format ‘@’') but when i did a `abuild -r` it worked, only when i did `abuild fetch checksum unpack prepare build rootpkg` i had problems
2019-11-14 22:21:38 <mps> ah no, it is not
2019-11-14 22:21:41 <_ikke_> mps: no, that's a different error
2019-11-14 22:21:52 <_ikke_> qa3Txu0iak0F: right, that's the same issue
2019-11-14 22:22:28 <qa3Txu0iak0F> it seems that some shell var that should have the output of `date +%s` or so is empty and thus the touch fails
2019-11-14 22:23:35 <_ikke_> It has to do with this change: https://gitlab.alpinelinux.org/alpine/abuild/commit/71d9d5233b9db3be91510addcb28721545d93185
2019-11-14 22:24:11 <qa3Txu0iak0F> `touch -h -d "@$SOURCE_DATE_EPOCH"` is the problematic part in two place
2019-11-14 22:24:14 <qa3Txu0iak0F> s
2019-11-14 22:29:42 <_ikke_> https://gitlab.alpinelinux.org/alpine/abuild/issues/9979
2019-11-14 22:34:35 <mps> good explanation
2019-11-15 02:26:17 <kaey> gitlab.a.o cert expired
2019-11-15 09:52:45 <north1> got an invalid cert on gitlab.a.o
2019-11-15 09:53:10 <AinNero> seems fine to me\
2019-11-15 09:54:25 <mps> north1: try reload page
2019-11-15 09:55:55 <north1> The builders are getting fatal: unable to access 'https://gitlab.alpinelinux.org/Leo/aports.git/': SSL certificate problem: certificate has expired
2019-11-15 09:57:57 <mps> it works for me: expire date: Jan 22 11:32:43 2020 GMT
2019-11-15 10:08:35 <AinNero> north1: can happen if your date is set wrong
2019-11-15 10:08:52 <north1> It is working now, wasn't this morning
2019-11-15 10:09:02 <north1> problably because i moved from BRT to CET (+4 hours)
2019-11-15 11:14:51 <supersandro2000> Does anyone know why this happens when building rclone?
2019-11-15 11:14:51 <supersandro2000> ``
2019-11-15 11:14:51 <supersandro2000> $ abuild build
2019-11-15 11:14:51 <supersandro2000> # github.com/rclone/rclone
2019-11-15 11:14:51 <supersandro2000> loadinternal: cannot find runtime/cgo
2019-11-15 11:14:51 <supersandro2000> ``
2019-11-15 11:40:41 <clandmeter> you can ignore that error
2019-11-15 11:40:45 <clandmeter> or warning
2019-11-15 11:50:44 <telmich> mps: thanks a lot for clarification! That means that I can actually migrate some servers+notebooks to alpine with the next stable! Thanks a lot!
2019-11-15 11:58:49 <mps> telmich: well, if you mean 3.11 as next stable then yes
2019-11-15 11:59:24 <mps> current stable 3.10 only have sec fixes and important bug fixes
2019-11-15 12:07:40 <ncopa> i think the 3.11 repos will be available within a week or so
2019-11-15 12:07:51 <ncopa> im setting up the 3.11 builders as we speak
2019-11-15 12:09:10 <mps> isn't this too early, or you mean 3.11-rc
2019-11-15 12:13:51 <_ikke_> not even rc1, he will start building the repos for 3.11
2019-11-15 12:15:06 <mps> what does this mean? go straight to release?
2019-11-15 12:20:58 <_ikke_> The first step for a new release is setting up builders to build all the packages
2019-11-15 12:21:16 <_ikke_> All packages are going to be built from scratch
2019-11-15 12:21:34 <_ikke_> Effectively that means you will start seeing 3.11 here: http://dl-cdn.alpinelinux.org/alpine/
2019-11-15 12:23:18 <ncopa> once the builders are done building the repo it will upload it
2019-11-15 12:23:38 <ncopa> that needs to happen before we do rc1
2019-11-15 12:23:57 <ncopa> 3.11 s390x builder is up and running
2019-11-15 12:25:07 <mps> but it will not declared as stable right after it builds all packages?
2019-11-15 12:26:40 <supersandro2000> clandmeter good to hear that. I was kinda worried
2019-11-15 12:26:41 <_ikke_> no, then is when the rcs will be anounced
2019-11-15 12:27:50 <mps> _ikke_: so, will have some time to fix and clean pkgs before stable release
2019-11-15 12:27:50 <ncopa> that builders are up and running means that we have feature freeze
2019-11-15 12:28:08 <_ikke_> mps: yes, that's the idea
2019-11-15 12:28:13 <ncopa> we shoudl focus on fixes yes
2019-11-15 12:28:21 <ncopa> fix bugs
2019-11-15 12:28:25 <ncopa> fix builds
2019-11-15 12:28:33 <_ikke_> ncopa: should we announce that to everyone involved?
2019-11-15 12:28:35 <mps> aha, then I don't complain
2019-11-15 12:28:59 <ncopa> major version updates should be considered careful and avoided if possible
2019-11-15 12:29:04 <_ikke_> otherwise people will just hapily continue upgrading things
2019-11-15 12:29:24 <mps> I have some pkgs to fix and clean and test, and maybe move for next stable
2019-11-15 12:30:02 <telmich> do you generally speaking need help with testing new stable releases? I'm fine with breaking some of our systems in favor for fast feedback, if it helps
2019-11-15 12:30:32 <mps> one of them is iwd, does it make sense to move it to main or move ell from main to community, because they are tightly coupled
2019-11-15 12:30:34 <supersandro2000> dont think this is to important but does someone know why drone fails here https://github.com/alpinelinux/aports/pull/12040? It worked before and I kinda want the update live.
2019-11-15 12:32:32 <mps> and telmich reminded me that some features in pkgs depends on next LTS kernel and can't be enabled/switched before kernel upgrade
2019-11-15 12:34:09 <_ikke_> ncopa: does a feature freeze means the next kernel didn't make it in?
2019-11-15 13:07:50 <ncopa> _ikke_: no
2019-11-15 13:08:21 <ncopa> _ikke_: i can send an email once all builders are online
2019-11-15 13:53:32 <_ikke_> ncopa: no, it didn't make it, or no, it does not mean that? ;-)
2019-11-15 13:57:36 <ncopa> no, feature freeze does not mean next kernel didnt make it in
2019-11-15 13:57:43 <ncopa> i think we will try do that anyway
2019-11-15 13:57:58 <ncopa> updated kernel will not have big impact on the built packages
2019-11-15 13:58:17 <_ikke_> ok, thanks for clarifying :)
2019-11-15 13:58:26 <ncopa> it does makes a difference when we do boot testing
2019-11-15 13:58:51 <ncopa> so if we decide that we want new kernel, we should have it built before rc1
2019-11-15 13:59:07 <ncopa> same goes for rpi4 support
2019-11-15 13:59:31 <_ikke_> ok, makes sense
2019-11-15 14:04:40 <artok> is anyone really active on rpi4 hacking ?
2019-11-15 14:04:58 <artok> other than my https://github.com/alpinelinux/aports/compare/master...djazo:rpi4
2019-11-15 14:05:13 <_ikke_> afaik you were the only one actively working on it
2019-11-15 14:10:05 <artok> oh.. I have committed some bootstrap.sh edits into that repo
2019-11-15 14:10:31 <artok> but nevertheless, there is already some mkimg.arm.sh mods
2019-11-15 14:11:54 <mps> it is not just kernel, a lot of pkgs makedepends on linux-headers
2019-11-15 14:22:45 <artok> but as long as kernel ver > headers ver that packages are built with, system works
2019-11-15 14:26:00 <mps> yes but can be cause of some problems in build and in runtime. best is if headers and kernel are from same major version
2019-11-15 14:28:46 <artok> best ofcoz
2019-11-15 15:13:23 <mps> and to add, I'm already made linux-headers 5.3.x and linux-vanilla 5.4.0-rc7 for local use, and running on armv7, aarch64 and x86_64
2019-11-15 15:13:32 <mps> all works fine
2019-11-15 16:29:58 <artok> soon reports of rc7 on rpi coming in
2019-11-15 21:41:00 <ncopa> all the 3.11 builders are up now
2019-11-15 21:41:18 <_ikke_> \o/
2019-11-15 21:41:23 <ncopa> from now focus will be to fix all build issues
2019-11-15 21:41:35 <ncopa> and kernel and those
2019-11-15 21:41:47 <ncopa> the mkinitramfs issues, installer issues etc
2019-11-15 21:41:58 <_ikke_> libxcb / libraw1394 are failing now
2019-11-15 21:42:00 <ncopa> i'll try have a look at those next week
2019-11-15 21:42:02 <ncopa> yeah
2019-11-15 21:42:08 <ncopa> its late here
2019-11-15 21:42:12 <_ikke_> yeah
2019-11-15 21:42:22 <ncopa> they might have patches in fedora or similar
2019-11-15 21:42:24 <_ikke_> Enjoy your well-deserved weekend
2019-11-15 21:42:35 <ncopa> or maybe they have upstream release
2019-11-15 21:54:09 <telmich> Can I ask for some recommendation on how you would expect software to be "shipped" by upstream so that it would be easy to package it?
2019-11-15 21:55:27 <_ikke_> I think following established patterns would help
2019-11-15 21:56:13 <telmich> We are currently working on ucloud, an IPv6 first replacement for openstack/opennebula/cloudstack and we are discussing whether it makes sense to include the cli in the same repo and even same python script as the daemon; i.e. "ucloud api ..." and "ucloud cli ..." would exist, but clients would only need "ucloud cli ..." and not the dependencies that for instance the api has
2019-11-15 21:56:42 <_ikke_> telmich: your message got truncated
2019-11-15 21:56:52 <telmich> _ikke_: at which point?
2019-11-15 21:57:00 <_ikke_> the api has...
2019-11-15 21:57:18 <telmich> it actually ends there
2019-11-15 21:57:24 <_ikke_> ah ok :)
2019-11-15 21:57:42 <telmich> So - what I wanted to say is: I think it would be cool to ship "full" ucloud, even for the "user"
2019-11-15 21:57:58 <telmich> because then the user could potentially even run her/his own cloud by just spinning up some services
2019-11-15 21:58:21 <telmich> however to do so, the user would / will need etcd, python-etcd3, and some other things, which the cli does not need
2019-11-15 21:58:23 <_ikke_> telmich: I think it's common to create subpackages so users can choose what components they want
2019-11-15 21:58:41 <_ikke_> each subpackage can have it's own dependencies
2019-11-15 21:59:01 <_ikke_> So you could have ucloud and ucloud-cli for example
2019-11-15 21:59:41 <telmich> hehe, but that would not be so easily possible, if the ucloud python script (+lib), has already all python parts to run the full stack
2019-11-15 22:00:18 <telmich> ... which is what I think would be somewhat cool, because the actual size of ucloud is tiny (and there are no binaries)
2019-11-15 22:00:56 <telmich> But maybe the solution could be to have "fake" packages that only carry the dependencies
2019-11-15 22:01:12 <_ikke_> git is an example where some subcommands are moved to a subpackage which depend on perl
2019-11-15 22:01:45 <telmich> i.e. ucloud-server or similar would depend on etcd, python-etcd3, qemu, ... - would that be something that sounds like making sense
2019-11-15 22:01:52 <telmich> oh, git is a good example, thanks for the hint!
2019-11-15 22:03:45 <mps> telmich: most admins don't like monolithic software, and user also
2019-11-15 22:07:11 <mps> packagers also
2019-11-15 22:32:02 <telmich> mps: you have a point
2019-11-16 12:11:35 <nmeum> 052775
2019-11-16 12:11:38 <nmeum> oops
2019-11-16 12:13:53 <Cogitri> Heh, 2FA code?
2019-11-16 12:13:54 <_ikke_> TOTP code?
2019-11-16 12:13:56 <_ikke_> lol
2019-11-16 12:16:29 <nmeum> yes
2019-11-16 12:16:54 <_ikke_> Safed bu the TO part :)
2019-11-16 12:16:58 <nmeum> )
2019-11-16 12:42:49 <nmeum> looks like libxcb isn't compatible with the most recent check version?
2019-11-16 12:44:45 <mps> check_public.c:210:20: error: passing argument 2 of 'suite_add_test' from incompatible pointer type
2019-11-16 12:48:16 <nmeum> right, looks like the invocation of some check.h functions is incorrect
2019-11-16 12:48:53 <nmeum> and upstream recommends using
2019-11-16 12:48:53 <nmeum> check 0.9.4
2019-11-16 12:48:58 <nmeum> https://xcb.freedesktop.org/DevelopersGuide/
2019-11-16 12:49:07 <nmeum> we package check 0.13.0
2019-11-16 12:50:49 <_ikke_> That's quite an old version
2019-11-16 12:50:59 <_ikke_> 0.9.4 compared to 0.13.0
2019-11-16 12:53:31 <nmeum> indeed
2019-11-16 13:00:02 <nmeum> I guess we just disable the testsuite then?
2019-11-16 13:00:13 <nmeum> alternative solution would be packaging check 0.9.4 separatly I guess…
2019-11-16 13:07:32 <mps> also I think disable is fine for now
2019-11-16 13:26:23 <nmeum> agreed, disabled it
2019-11-16 13:28:06 <mps> I'm watching movie called #alpine-commits :)
2019-11-16 13:39:47 <maxice8> mps: old days of cinema but with 4 colors
2019-11-16 14:49:58 <mps> maxice8: hehe, I see 5 colors, fifth is nick of those who last commanded algitbot to retry :)
2019-11-16 14:50:37 <maxice8> Yes I forgot about that
2019-11-16 15:22:15 <maxice8> Can we push to 3.11-stable to fix builds
2019-11-16 15:22:32 <_ikke_> They still follow master
2019-11-16 15:22:54 <_ikke_> 3.11-stable does not exist yet
2019-11-16 15:23:17 <_ikke_> That will be created when 3.11 is released
2019-11-16 15:33:20 <maxice8> Oh
2019-11-16 15:33:35 <maxice8> Cool, didn't know that
2019-11-16 15:33:37 <maxice8> I'm walking home
2019-11-16 15:33:50 <maxice8> Will see what I can fix when I get home
2019-11-16 16:52:22 <maxice8> need !1322 to unblock 3.11-builders
2019-11-16 17:02:44 <_ikke_> pushed
2019-11-16 17:03:16 <maxice8> Thanks
2019-11-16 17:23:30 <_ikke_> maxice8: procps same issue?
2019-11-16 17:23:39 <_ikke_> ERROR: procps-dev*: usr/lib/pkgconfig/libprocps.pc: pkgconf version UNKNOWN is invalid
2019-11-16 19:01:09 <mps> need advice from more experienced alpine devs. I'm preparing iwd 1.1 upgrade and thinking to reintroduce /etc/iwd/main.conf file
2019-11-16 19:01:53 <mps> it is removed upstream in 1.0 release, but I think it will be good to have it in alpine because all previous version had it
2019-11-16 19:02:36 <mps> and, another reason is that resolver setup by default uses systemd
2019-11-16 19:03:21 <mps> so, we can have minimal /etc/iwd/main.conf file tailored to alpine
2019-11-16 19:03:46 <mps> any comment or suggestion
2019-11-16 19:12:39 <maxice8> ikke: yes
2019-11-16 19:51:53 <maxice8> ikke: alpine-mips-patches has a few fixes like Procps and argon2 on the mailing list
2019-11-16 20:00:15 <_ikke_> maxice8: is there some change in pkgconf that this has become an issue?
2019-11-16 20:00:24 <_ikke_> I noticed it more often that this suddenly pops up
2019-11-16 20:00:45 <maxice8> New abuild checks for it
2019-11-16 20:01:00 <_ikke_> ah, that explains
2019-11-16 20:01:20 <maxice8> Previously we would ship broken version fields on Pkg-config files
2019-11-16 20:02:08 <_ikke_> yes, indeed
2019-11-16 20:02:27 <_ikke_> projects that use git describe :)
2019-11-16 20:17:19 <maxice8> alpine-mips-patches posts a lot to the mailing list
2019-11-16 20:17:25 <maxice8> :D might want to take a look there
2019-11-16 20:18:01 <_ikke_> yes, I noticed
2019-11-16 20:18:20 <_ikke_> I was working on applying those
2019-11-16 20:18:26 <maxice8> after that you can look at gitlab too :D wink wink nudge nudge
2019-11-16 20:18:27 <mps> I noticed them also
2019-11-16 20:18:54 <_ikke_> I was focusing more on infra work, because we have a backlog there as well
2019-11-16 20:19:47 <mps> I don't look much in patches for main, I don't have access so it is not my priority
2019-11-16 20:20:40 <mps> i.e. have feeling I can't help much with them
2019-11-16 20:25:37 <maxice8> speaking of merging stuff can you merge the file MRs ?
2019-11-16 20:25:52 <maxice8> from !1282 to !1286
2019-11-16 20:26:12 <maxice8> :D i used the wrong number in secfixes so someone's system is hamemring them with a CVE they can't find a fix for
2019-11-16 20:26:13 <mps> maxice8: you are not asking me, I think?
2019-11-16 20:26:18 <maxice8> because it doesn't exist :DD
2019-11-16 20:26:43 <maxice8> mps: No, i know you can no main/
2019-11-16 20:26:55 <mps> aha, ok
2019-11-16 20:45:24 <_ikke_> hmm, strange. ldoc seems to depend on lua5.3-penlight, but I cannot find any reference to that package in aports
2019-11-16 20:51:14 <_ikke_> ok, it's a subpkg of lua-penlight
2019-11-16 20:53:33 <_ikke_> ah no, there is just a provides
2019-11-16 20:57:43 <_ikke_> somehow the dep build order resolution is not correct
2019-11-16 20:59:26 <mps> just noticed that asciidoc deps on python2
2019-11-16 21:20:09 <_ikke_> Is this page working for you? http://mama.indstate.edu/users/ice/tree
2019-11-16 21:20:52 <_ikke_> I can download it from my container
2019-11-16 21:23:58 <mps> _ikke_: it works for me
2019-11-16 21:24:20 <_ikke_> sounds like a routing issue
2019-11-17 09:46:58 <PureTryOut[m]> Could someone review and/or merge !1064?
2019-11-17 09:52:51 <mps> PureTryOut[m]: it build fine on CI, I see
2019-11-17 09:53:07 <mps> Will push it in a few minutes
2019-11-17 09:53:17 <PureTryOut[m]> Thanks!
2019-11-17 09:55:16 <mps> pushed
2019-11-17 09:56:42 <mps> wanted to tell you yesterday to use words enable and disable instead of limit for enabling or disabling build on specific arch
2019-11-17 10:06:16 <mps> hmm, main/tree source can't be fetched from builders
2019-11-17 10:35:57 <PureTryOut[m]> Oh sure
2019-11-17 12:44:07 <replikvlt> hello
2019-11-17 12:45:32 <replikvlt> i am not sure i have to direct it here, but package 'pulseaudio-equalizer' depends on pulseuadio which is a mistake
2019-11-17 12:46:33 <replikvlt> should be pulseaudio, the dependency is a typo
2019-11-17 12:46:51 <mps> typo, ofc
2019-11-17 12:48:15 <replikvlt> btw i'm using alpine edge on hw(laptop) if you need more info about it, so its in edge repo
2019-11-17 12:49:02 <mps> yes, I see it in local clone
2019-11-17 12:49:47 <mps> maxice8: would you fix this (you are maintainer) or if you are out I can?
2019-11-17 12:50:22 <maxice8> Can you fix? I'm doing house chores
2019-11-17 12:50:37 <mps> ok, np. I will push it now
2019-11-17 12:51:01 <replikvlt> thanks
2019-11-17 12:55:23 <mps> pushed
2019-11-17 12:55:49 <mps> replikvlt: in about 15-30 minutes it should be on mirrors
2019-11-17 12:57:03 <replikvlt> yay~, much appreciated, later...
2019-11-17 14:50:01 <PureTryOut[m]> Is there an example on how to package Haskell packages? Is there anything Haskell besides ghc package even?
2019-11-17 14:50:19 <maxice8> there is shellcheck
2019-11-17 14:50:36 <maxice8> <banter>only useful program in haskal</banter>
2019-11-17 14:51:58 <PureTryOut[m]> Neh, pandoc is useful as well 😛
2019-11-17 14:52:07 <PureTryOut[m]> Didn't realize shellcheck is a Haskell program though, will check it out
2019-11-17 15:21:55 <_ikke_> PureTryOut[m]: I started packaging haskell modules
2019-11-17 15:22:07 <_ikke_> but it's a lot of work (like with python packages)
2019-11-17 15:22:12 <_ikke_> but never got to finishing it
2019-11-17 15:22:22 <_ikke_> shellcheck just statically compiles everything
2019-11-17 15:23:08 <PureTryOut[m]> Yeah I noticed that
2019-11-17 15:23:12 <PureTryOut[m]> Would be nice to have Haskell modules available
2019-11-17 15:23:41 <PureTryOut[m]> I'm fine with static for now but can try to help out with module packaging
2019-11-17 15:24:09 <_ikke_> Apparently I threw my WIP for that away
2019-11-17 15:24:35 <_ikke_> ah, reflog ftw
2019-11-17 15:24:52 <PureTryOut[m]> Lol indeed
2019-11-17 15:25:23 <PureTryOut[m]> This Cabal stuff is a pain as well...
2019-11-17 15:25:26 <_ikke_> heh
2019-11-17 15:27:34 <_ikke_> PureTryOut[m]: https://gitlab.alpinelinux.org/kdaudt/aports/compare/master...haskell-packages
2019-11-17 15:27:35 <maxice8> Can we get more people on main/ ?
2019-11-17 15:28:56 <PureTryOut[m]> _ikke_: asesome! Maybe you can MR stuff you have already (after modernizing them, I see some older habits of doing stuff in there 😜)
2019-11-17 15:29:32 <_ikke_> yup, it's an older branch :)
2019-11-17 15:29:41 <mps> maxice8: I think there is enough people with main access write right, but they are inactive in last few months
2019-11-17 15:29:59 <_ikke_> Well, most people with main access are mostly maintaining their own stuff (with a few exceptions)
2019-11-17 15:30:11 <PureTryOut[m]> I wonder if eventually we can package NodeJS stuff like that as well, although it would be way more packages
2019-11-17 15:30:46 <maxice8> PureTryOut: We will pass NixOS (which automatically packages python stuff) on package number in repology
2019-11-17 15:31:38 <PureTryOut[m]> Lol definitely
2019-11-17 15:31:39 <maxice8> 5GB APKINDEX files
2019-11-17 15:32:48 <PureTryOut[m]> Well at least it seems Pandoc is finally compiling now
2019-11-17 15:34:03 <_ikke_> maxice8: My issue is that I'm also helping with infra, so I have to divide my time (and I have been working a lot on merging MRs lately
2019-11-17 15:34:05 <_ikke_> )
2019-11-17 15:35:40 <PureTryOut[m]> Well if you MR stuff you have already, other people like me can work on that
2019-11-17 15:35:58 <PureTryOut[m]> Or maybe I can continue working on your branch? Idk
2019-11-17 15:36:14 <_ikke_> PureTryOut[m]: It's more about merging MRs for main
2019-11-17 15:37:51 <PureTryOut[m]> I'm not sure what you mean?
2019-11-17 15:38:03 <PureTryOut[m]> I can modernize those APKBUILDs for you if you want, if that makes the mergeable
2019-11-17 15:38:31 <_ikke_> I was not talking about those haskell packages
2019-11-17 15:38:44 <_ikke_> but about maxice8' request for more people attending to open merge requests for main
2019-11-17 15:39:20 <PureTryOut[m]> Ah in regards to your lack of time, of course sorry
2019-11-17 15:43:29 <_ikke_> maxice8: not sure if you followed it, but ncopa has announced a feature freeze, so most focus is around keeping the 3.11 builders running
2019-11-17 15:44:23 <maxice8> They are currently failing on a lot of main/ pkgs
2019-11-17 15:44:38 <maxice8> but no i didn't it was problably done while i was settling in Germany
2019-11-17 15:45:02 <mps> looks like they started to skip deps order
2019-11-17 15:45:31 <mps> maybe restart could help
2019-11-17 15:45:48 <_ikke_> mps: yes, I noticed that as well
2019-11-17 15:49:22 <PureTryOut[m]> _ikke_: I have some time now, should I modernize your Haskell packages?
2019-11-17 15:51:14 <_ikke_> sure, feel free
2019-11-17 15:55:51 <PureTryOut[m]> 👍️
2019-11-17 17:15:51 <maxice8> Seems like our builders have difficulty (fail 100%) in fetching the source-code for main/tree
2019-11-17 17:16:00 <maxice8> what should we do ? archive it ?
2019-11-17 17:20:14 <mps> good idea, at least temporarily
2019-11-17 17:20:47 <mps> where are builders physically located
2019-11-17 17:21:46 <mps> it is strange, I can download tree from usa4.a.o and from my home net
2019-11-17 17:22:04 <maxice8> i can as well but what is important is that the builders can and they can't D:
2019-11-17 17:26:28 <mps> interesting, I can download from my net in Paris and Frankfurt also
2019-11-17 18:41:28 <ncopa> is it https or ftp?
2019-11-17 18:41:35 <ncopa> some of the builders may have problems with ftp
2019-11-17 18:41:57 <mps> it is http, iirc
2019-11-17 18:42:32 <mps> http://mama.indstate.edu/users/ice/tree/src/tree-1.8.0.tgz
2019-11-17 18:44:28 <ncopa> i suppose we have it on distfiles.a.o?
2019-11-17 18:46:00 <ncopa> i manually copied it to /var/cache/distfiles/v3.11/
2019-11-17 18:46:52 <mps> http://distfiles.alpinelinux.org/distfiles/v3.10/tree-1.8.0.tgz
2019-11-17 18:49:05 <_ikke_> I noticed yesterday that tee was reachable from some locations, but not others
2019-11-17 18:51:08 <mps> also I tested from 4 different geo locations and it worked always
2019-11-17 19:13:11 <ncopa> im looking at perl-mail-spamassassin
2019-11-17 19:13:23 <ncopa> we have 2 aports that creates that package
2019-11-17 19:13:51 <ncopa> main/spamassassin has a perl-mail-spamassassin subpackage
2019-11-17 19:35:24 <mps> what does this means 'local basedir=$(basename $(dirname "$termfile"))' \  ^--------------------^ SC2046: Quote this to prevent word splitting.
2019-11-17 19:35:35 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/12875
2019-11-17 19:35:54 <_ikke_> That you need to put quotes around $()
2019-11-17 19:36:08 <_ikke_> local basedir=$(basename "$(dirname "$termfile")")
2019-11-17 19:36:34 <mps> but then there are inner quotes
2019-11-17 19:36:43 <_ikke_> Otherwise, the result might get split
2019-11-17 19:36:48 <_ikke_> Those are in a different scope
2019-11-17 19:37:35 <mps> so, not remove quotes around $termfile
2019-11-17 19:37:42 <_ikke_> var="outer scope $(echo "inner scope")";
2019-11-17 19:37:44 <_ikke_> correct
2019-11-17 19:37:59 <mps> ok, thank you again
2019-11-17 19:38:20 <mps> lets try what will CI tell
2019-11-17 19:40:41 <mps> interesting is that locally aports-lint doesn't complain but do on CI
2019-11-17 19:40:51 <_ikke_> this is shellcheck
2019-11-17 19:41:04 <_ikke_> Which is a generic shell linter
2019-11-17 19:41:42 <mps> ah, is it useful to install it locally to check APKBUILDs
2019-11-17 19:41:53 <_ikke_> yes, but you need to tweak it a little
2019-11-17 19:42:17 <_ikke_> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/tree/master/overlay/usr/local/bin
2019-11-17 19:43:47 <_ikke_> ncopa: any idea why the builders seem to build certain packages while its dependencies are not built yet?
2019-11-17 19:44:50 <mps> _ikke_: I see, but TBH not understand much, and it is not important to me now. anyway thanks
2019-11-17 19:51:30 <artok> kernel 5.4 compiled for rpi4
2019-11-17 19:52:58 <mps> artok: \o/
2019-11-17 19:53:18 <mps> hm CI says now 'IC:[AL6]:APKBUILD:11:prefix custom variable with _: makedepends_build="ncurses"'
2019-11-17 19:53:44 <_ikke_> I guess that one needs to be added to valid names
2019-11-17 19:53:58 <mps> where is makedepends_build defined
2019-11-17 19:54:20 <_ikke_> https://gitlab.alpinelinux.org/alpine/abuild/blob/master/abuild.in#L2022 Here it's referenced
2019-11-17 19:55:37 <ncopa> _ikke_: which?
2019-11-17 19:56:05 <mps> I see, but it is not documented anywhere or I didn't searched hard enough
2019-11-17 19:56:32 <_ikke_> gtk+3.0 I believe
2019-11-17 19:56:36 <ncopa> sometimes a subpackage has a dependency that is not "visible" in global scope. In that case the build server cannot detect the build order
2019-11-17 19:56:47 <_ikke_> like subpackages?
2019-11-17 19:56:56 <ncopa> the fix is to add the subpackages dep to makedepends in global scope
2019-11-17 19:57:07 <_ikke_> ah, like that
2019-11-17 19:57:12 <ncopa> i have an example in spamassain
2019-11-17 19:57:21 <ncopa> spamassassin
2019-11-17 19:57:26 <_ikke_> gtk+3.0 depends on  gtk-update-icon-cache
2019-11-17 19:57:58 <ncopa> it has a perl-mail-spamassassin subpackage [splitfunction cpan()]
2019-11-17 19:58:08 <ncopa> which depends on gnupg
2019-11-17 19:58:32 <_ikke_> Hmm, gtk+2.0 is strange. It has subpkg=gtk-update-icon-cache
2019-11-17 19:59:05 <_ikke_> I don't think that's valid, is it?
2019-11-17 19:59:31 <_ikke_> ah, it's later reference, but it should start with an _ in that case
2019-11-17 20:00:58 <ncopa> yeah
2019-11-17 20:01:56 <_ikke_> But gtk+3.0 fails because it cannot find gtk-update-icon-cache
2019-11-17 20:02:29 <ncopa> i'd guess its a circular dep
2019-11-17 20:03:14 <_ikke_> I don't think gtk+2.0 depends on gtk+3.0, does it?
2019-11-17 20:03:37 <_ikke_> gtk+3.0 -> gtk-update-icon-cache (origin gtk+2.0)
2019-11-17 20:03:38 <ncopa> it does, indirectly
2019-11-17 20:03:44 <_ikke_> ah ok
2019-11-17 20:04:05 <ncopa> $ ap recursdeps gtk+2.0 | grep gtk+3
2019-11-17 20:04:05 <ncopa> gtk+3.0-dev
2019-11-17 20:04:11 <mps> artok: which kernel? -rc7?
2019-11-17 20:05:55 <artok> mps yes, I needed to do some fixes (add header and rename function name) to new naming on dma_coherence check, but that diff will be surely added on some rpi patch.. by someone =)
2019-11-17 20:07:44 <mps> aha, you had to patch it? setting config options didn't worked?
2019-11-17 20:08:14 <artok> rpi patches and then fixes to them
2019-11-17 20:08:53 <artok> actually I cloned github.com/raspberrypi/linux 5.4.y branch and fixed that
2019-11-17 20:09:14 <mps> so my expectation was wrong, that the kernel for rpi4 can built from plain upstream :\
2019-11-17 20:09:29 <artok> yeah that can't be done
2019-11-17 20:10:03 <mps> ok, thanks for info, you saved me some time
2019-11-17 20:15:22 <ncopa> _ikke_: circular deps: gtk+2.0 -> cups -> avahi -> py3-gobject -> gtk+3-dev -> gtk+2.0-dev
2019-11-17 20:15:54 <_ikke_> ncopa: ok, what did you use to find that?
2019-11-17 20:16:34 <ncopa> ap recursdeps, some guess/intuition and `vim APKBUILD`
2019-11-17 20:16:38 <_ikke_> ok
2019-11-17 20:16:46 <ncopa> we need a proper tool to detect circular deps
2019-11-17 20:16:50 <_ikke_> yeah
2019-11-17 20:17:08 <ncopa> should probably be added to atools
2019-11-17 20:17:09 <Cogitri> ncopa: about the mail on the mailing list: +1 for using a 5.4-rc kernel
2019-11-17 20:17:15 <Cogitri> Hopefully my laptop will be back before 3.11 so I can test it :P
2019-11-17 20:17:43 <ncopa> Cogitri: yeah, i hope that there are not many issues with the builders
2019-11-17 20:17:55 <ncopa> so i can work on kernel while builders are building the packages
2019-11-17 20:18:20 <ncopa> alternatively if someone helps me to fix the builds while i work on kernel
2019-11-17 20:18:39 <Cogitri> Yup, I hope so too. Also, about the GCC D stuff, can we work on merging that once 3.11 is branched off? :)
2019-11-17 20:18:55 <ncopa> that needs to be after 3.11 is released
2019-11-17 20:19:15 <Cogitri> Yup, that's what I meant :)
2019-11-17 20:19:17 <ncopa> unless there is strong reason to include it
2019-11-17 20:19:18 <ncopa> ok
2019-11-17 20:19:21 <ncopa> yeah
2019-11-17 20:19:25 <mps> and kernel 5.4-rc8 will be released tomorrow probably
2019-11-17 20:19:33 <Cogitri> Just wanted to give the contributor a timeframe for how long the contribution will sit around
2019-11-17 20:19:49 <ncopa> Cogitri: thank you for following that up
2019-11-17 20:20:07 <ncopa> i'd guess 1-4 weeks
2019-11-17 20:20:24 <Cogitri> mps: nice
2019-11-17 20:20:26 <ncopa> but i really want v3.11 out asap
2019-11-17 20:20:54 <Cogitri> Alright, great
2019-11-17 20:20:57 <ncopa> there was some PRs in initramfs script that I'd like to have a look at too
2019-11-17 20:21:24 <ncopa> i think it was support for raid on top of encrypted devices
2019-11-17 20:21:30 <ncopa> or similar
2019-11-17 20:21:45 <mps> I see in their git log that the rc8 is on the road
2019-11-17 20:22:01 <ncopa> nice. I will try have a look at that next week
2019-11-17 20:22:05 <mps> so, LTS will be released next monday I hope
2019-11-17 20:22:15 <ncopa> very nice
2019-11-17 20:22:52 <mps> as I wrote earlier, I building it from rc5 and it works fine and stable
2019-11-17 20:23:45 <mps> 'uname -a' => Linux arya 5.4.0-rc7-0-vanilla #1-Alpine SMP Mon Nov 11 13:18:36 CET 2019 x86_64 GNU/Linux
2019-11-17 20:23:59 <ncopa> nice!
2019-11-17 20:24:35 <_ikke_> strange, gcr fails due to gnupg dependency missing, but I don't see it depending on gnupg (and ap recursdeps does not return it either)
2019-11-17 20:24:45 <_ikke_> gnupg (missing):
2019-11-17 20:24:47 <_ikke_>     required by: .makedepends-gcr-20191117.201732[gnupg]
2019-11-17 20:25:10 <ncopa> its in checkdepends
2019-11-17 20:25:23 <mps> there are some new options in kernel which should be enabled, PSI, lockdown, pkcs8 and I forgot all
2019-11-17 20:25:29 <_ikke_> ncopa: where? I don't see any checkdepends
2019-11-17 20:25:57 <ncopa> $ grep checkdepends= main/gcr/APKBUILD
2019-11-17 20:25:57 <ncopa> checkdepends="xvfb-run gnupg dbus-x11"
2019-11-17 20:26:06 <ncopa> I'd guess thats also a circular dep
2019-11-17 20:26:20 <_ikke_> oh, sorry, I was still on an old branch
2019-11-17 20:26:35 <ncopa> mps: do you have a patch for the kernel? or MR
2019-11-17 20:26:49 <ncopa> re gtk2
2019-11-17 20:26:59 <mps> well, I have local branch in git repo
2019-11-17 20:27:02 <ncopa> i think we could maybe build gtk2 without cups/printingn support
2019-11-17 20:27:05 <artok> robob:~$ uname -a
2019-11-17 20:27:06 <artok> Linux robob 5.4.0-rc7-v8+ #1 SMP PREEMPT Sun Nov 17 20:50:40 EET 2019 aarch64 Linux
2019-11-17 20:27:10 <artok> wheeee
2019-11-17 20:27:30 <ncopa> we coudl say that if you want print, you'd need rebuild/port the app to gtk3
2019-11-17 20:27:39 <ncopa> artok: awesome!
2019-11-17 20:28:32 <mps> ncopa: but I made it only for x86_64, vanilla and virt
2019-11-17 20:28:33 <_ikke_> ncopa: I can try to disable the gnupg specific tests on gcr?
2019-11-17 20:28:49 <ncopa> _ikke_: yeah
2019-11-17 20:29:05 <ncopa> i think, in worst case, disable tests alltogether
2019-11-17 20:29:28 <ncopa> but better try disable a few problematic tests rather than disable everything
2019-11-17 20:29:32 <_ikke_> indeed
2019-11-17 20:29:44 <_ikke_> I think it would be just a matter to remove them from the Makefile.am file
2019-11-17 20:30:06 <ncopa> thanks for looking at it
2019-11-17 20:30:19 <ncopa> i'll think i'll continue tomorrow
2019-11-17 20:30:30 <_ikke_> nite
2019-11-17 20:30:31 <ncopa> i need to have the weekends off, or i'll lose my mind in the long run
2019-11-17 20:31:02 <ncopa> thank you eveyone!
2019-11-17 20:31:42 <_ikke_> yes, please do :)
2019-11-17 20:31:54 <_ikke_> I mean, not loose your mind, but have weekends off :)
2019-11-17 23:27:12 <mps> kernel 5.4-rc8 is released, I hope it is last 5.4 in rc series
2019-11-18 04:49:20 <maxice8> PureTryOut: can you take a look at !1356 ?
2019-11-18 04:49:48 <maxice8> oops, i meant !1353
2019-11-18 07:37:02 <ncopa> morning
2019-11-18 07:37:36 <Cogitri> Morning :)
2019-11-18 08:20:33 <maxice8> Morning
2019-11-18 08:36:10 <_ikke_> morning
2019-11-18 08:39:46 <tmhoang> ncopa: I think we need to upgrade ocaml/camlp4 to match ocaml version
2019-11-18 08:39:50 <tmhoang> morning guys
2019-11-18 08:41:10 <tmhoang> but there is no new/matching version upstream, hmm
2019-11-18 08:41:17 <tmhoang> https://github.com/ocaml/camlp4/releases
2019-11-18 08:41:25 <_ikke_> ncopa: didn't manage to fix gcr yet (due to another test failing regarding encoding errors)
2019-11-18 08:46:17 <ncopa> tmhoang: seems like ocaml-camlp4 is unmaintained upstream
2019-11-18 08:46:28 <ncopa> https://github.com/ocaml/camlp4/blob/trunk/README.md
2019-11-18 08:48:21 <tmhoang> oops
2019-11-18 08:52:11 <tmhoang> have anyone tried actually running ocaml on edge when ocaml and ocaml-camlp4 versions differ
2019-11-18 08:57:51 <fredrigu> ncopa: morning, seems as fabled is not able to look at my PR (it has been open for 6 days), would you be able to have a look? https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/2#content-body
2019-11-18 09:00:48 <tmhoang> I wonder if we want to ship ocaml-camlp4 - it's built with ocaml 4.08 while we ship ocaml 4.09 in edge/3.11
2019-11-18 09:02:17 <ncopa> tmhoang: maybe send an email to the maintainer, Anil, and ask what he suggests we do
2019-11-18 09:02:35 <ncopa> i think Anil is involved in upstream ocaml
2019-11-18 09:03:10 <tmhoang> ok
2019-11-18 09:03:13 <ncopa> fredrigu: you claim that testsuite fails?
2019-11-18 09:03:19 <ncopa> it works for me
2019-11-18 09:07:24 <tmhoang> personally I think we would ship 4.08 instead - but asking Anil
2019-11-18 09:07:57 <fredrigu> ncopa: I've added a CI build to apk-tools, you can see it here (no changes to the code) https://gitlab.alpinelinux.org/fredrigu/apk-tools/-/jobs/14573
2019-11-18 09:08:07 <fredrigu> it does work
2019-11-18 09:11:18 <fredrigu> running locally for me the test suite does not work. It might have to do with me running glibc? Anyway, the code is wrong from what I can see. We're referencing a stack-created string and pushing that to apk_blob_atomize
2019-11-18 09:11:23 <fredrigu> or do I miss something here?
2019-11-18 09:11:52 <ncopa> glibc may be the difference
2019-11-18 09:12:17 <ncopa> im not sayin you are wrong
2019-11-18 09:13:10 <fredrigu> since CI obviously work on alpine I'm removing WIP from this https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/3
2019-11-18 09:16:14 <fredrigu> ncopa: you can see the output from me running the tests (twice) here https://paste.ubuntu.com/p/6HFVB9Zzjx/ quite obvious invalid memory error
2019-11-18 09:22:10 <ncopa> yeah, it makes sense
2019-11-18 09:22:57 <ncopa> what i wonder is if 'version' is ever free'ed
2019-11-18 09:23:09 <ncopa> or how it is normally free'ed
2019-11-18 09:23:17 <ncopa> to avoid the leak
2019-11-18 09:23:58 <ncopa> it is possible that it is always leaking by design (clean up at process exit)
2019-11-18 09:24:30 <fredrigu> yeah, that had me wondering as well. Isn't the whole point of apk_blob_atomize that we shouldn't free memory ever? On the other hand, my "fix" will leak memory twice if the same string is inserted to apk_blob_atomize (even if only one actually is needed)
2019-11-18 09:25:14 <fredrigu> previously virtpkg->version = apk_blob_atomize(APK_BLOB_STR(ver));
2019-11-18 09:25:21 <fredrigu> was virtpkg->version = apk_blob_atomize(APK_BLOB_STR(ver));
2019-11-18 09:25:25 <fredrigu> was virtpkg->version = apk_blob_atomize(APK_BLOB_STR("0"));
2019-11-18 09:25:42 <fredrigu> I mean, so that was a string on the stack that never needed to be freed
2019-11-18 09:26:16 <ncopa> *nod*
2019-11-18 09:26:31 <ncopa> because it was a static string in DATA section
2019-11-18 09:27:31 <fredrigu> ncopa: oh, I got it
2019-11-18 09:27:47 <ncopa> so
2019-11-18 09:27:48 <fredrigu> running grep -r apk_blob_atomize *.c
2019-11-18 09:28:21 <ncopa> it is only possible to add a single virtual on each run
2019-11-18 09:28:25 <fredrigu> and looking at how other instances does it, tells me that there's a apk_blob_atomize_dup() as well. So that should be the correct solution
2019-11-18 09:28:52 <fredrigu> we will still leak memory (and I guess that's fine) but at least it will be a more consistant solution
2019-11-18 09:29:12 <ncopa> i wonder how the other version strings are created in database
2019-11-18 09:29:29 <ncopa> or more exact: i wonder if the other version strings are free'ed
2019-11-18 09:29:33 <ncopa> i dont think they are
2019-11-18 09:30:08 <ncopa> if they are never free'ed then i support apk_blob_atomize_dup()
2019-11-18 09:30:32 <ncopa> there is another possible solution, or workaround
2019-11-18 09:30:34 <ncopa> that simpler
2019-11-18 09:31:33 <fredrigu> ncopa: something like this https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/2/diffs
2019-11-18 09:31:54 <ncopa> yeah
2019-11-18 09:32:30 <ncopa> another possible workaround: https://tpaste.us/Nmmy
2019-11-18 09:33:13 <ncopa> which assumes there will always only be a single virtual package
2019-11-18 09:33:18 <ncopa> or version
2019-11-18 09:33:28 <fredrigu> yes, is that really a corret assumption?
2019-11-18 09:34:02 <ncopa> i guess there will never be a list of virtual packages
2019-11-18 09:34:31 <ncopa> and even it there ever would be, they would still only end up with the exact same version string
2019-11-18 09:34:32 <fredrigu> I'm not quite sure what apk considers to be a virtual package. Is that a package that don't have any data but only consist of a dependency list?
2019-11-18 09:34:39 <ncopa> yes
2019-11-18 09:34:56 <ncopa> the idea is that you can install/deinstall a group of packages
2019-11-18 09:35:03 <ncopa> used for build time dependencies
2019-11-18 09:35:12 <fredrigu> what if a virtual package point to another virtual package?
2019-11-18 09:35:24 <fredrigu> I can see that usecase
2019-11-18 09:35:24 <ncopa> so i do: apk add --virtual .mydeps pkg1 pkg2 pkg3
2019-11-18 09:35:37 <ncopa> <phone>
2019-11-18 09:36:38 <_ikke_> (abuild uses that as well)
2019-11-18 09:37:12 <fredrigu> oh, so virtual is only for grouping packages locally and never on the repo side. (that is, we never distribute virtual packages but only uses them locally on install)
2019-11-18 09:37:29 <_ikke_> correct                                                                                                       │ ephemer0l
2019-11-18 09:37:41 <fredrigu> btw. apk add -h doesn't have --virtual documented
2019-11-18 09:38:30 <ncopa> so if i install .mydeps, the packages are "locked" and if i try apk del pkg1, i'll get an error
2019-11-18 09:38:45 <ncopa> to make sure that nobody uninstall the packages by accident while package is built
2019-11-18 09:39:03 <_ikke_> fredrigu: it does
2019-11-18 09:39:06 <_ikke_> at the bottom
2019-11-18 09:39:14 <mps> fredrigu: it have, -t
2019-11-18 09:39:14 <_ikke_> -t, --virtual
2019-11-18 09:39:15 <fredrigu> _ikke_: oh thanks
2019-11-18 09:39:27 <ncopa> and on the other hand, if some other process install pkg1 with `apk add pkg1` while .mydeps are installed during build
2019-11-18 09:39:42 <ncopa> the pkg1 will not be purged when doing `apk del .mydeps`
2019-11-18 09:40:03 <fredrigu> ncopa: that's cool.
2019-11-18 09:40:04 <_ikke_> but it will be removed from world if it was there
2019-11-18 09:40:29 <ncopa> that makes it possible to install buildtime deps and run parallel builds, without anyone uninstall the other builds deps
2019-11-18 09:40:48 <fredrigu> ncopa: I've verified that the "static" solution also works for me. So I guess it's a matter of taste on which solution to go with. static or _dup()
2019-11-18 09:40:57 <ncopa> correcgt
2019-11-18 09:41:09 <ncopa> i'd like fabled decide that
2019-11-18 09:41:24 <ncopa> i'll post a comment with the static option too
2019-11-18 09:41:46 <fredrigu> thanks
2019-11-18 09:42:22 <fredrigu> I'll add a comment about glibc/musl
2019-11-18 09:44:47 <ncopa> we coudl also add a runtime safety net: http://tpaste.us/xkkl
2019-11-18 09:45:51 <ncopa> i know that fabled is busy these days, but I'll mention it when i talk with him next time
2019-11-18 09:46:26 <fredrigu> ncopa: yeah, the would be a good idea. Having the static solution without a safety net would be scary.
2019-11-18 09:46:29 <ncopa> also, it would be nice to add that runner to gitlab to we have a CI for MEs
2019-11-18 09:46:42 <fredrigu> thanks. I appreciate that
2019-11-18 09:46:44 <fredrigu> MEs?
2019-11-18 09:48:25 <tmhoang> ncopa: looks like upstream wanted to remove camlp4
2019-11-18 09:48:33 <tmhoang> just asked in #ocaml
2019-11-18 09:49:45 <tmhoang> copy paste : Fardale> Ok, then either you stay with 4.08.1 or you remove camlp4 with 4.09.0
2019-11-18 09:50:45 <tmhoang> Debian + Fedora current version of ocaml is 4.08.1
2019-11-18 09:54:37 <ncopa> s/MEs/MRs/ aka merge requests
2019-11-18 09:54:37 <alpine-meetbot> ncopa meant to say: also, it would be nice to add that runner to gitlab to we have a CI for MRs
2019-11-18 09:54:44 <PureTryOut[m]> _ikke_: lol I already have circular dependencies with Haskell modules. A circle of 4 packages...
2019-11-18 09:55:07 <PureTryOut[m]> Funny thing is, most of these deps aren't actually listed on https://hackage.haskell.org as a dependency
2019-11-18 09:55:35 <fredrigu> ncopa: I've a merge request that runs CI for apk-tools https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/3
2019-11-18 09:56:03 <fredrigu> ncopa: I'll be submitting one MR more with added support for running CI on debian as well
2019-11-18 09:57:24 <ncopa> fredrigu: great!
2019-11-18 09:59:16 <_ikke_> PureTryOut[m]: lol
2019-11-18 10:00:20 <PureTryOut[m]> I don't fully understand where these deps come from, they aren't listed in $pkgname.cabal either
2019-11-18 10:00:45 <mps> fredrigu: sorry, I don't understand, are you trying to make apk-tools to work on debian?
2019-11-18 10:01:44 <ncopa> mps: it already does. but we want avoid unintentional breakages on debian
2019-11-18 10:03:30 <mps> aha, apk-tools-static saved me a lot of time once on debian when I forgot to do full apk upgrade and reboot in between
2019-11-18 10:05:00 <mps> i.e. I fixed alpine from debian on one cloud provider
2019-11-18 10:06:02 <_ikke_> ncopa: there should be global runners available for every project
2019-11-18 10:06:31 <TBB> thank goodness for the static apk, it's what my entire custom installer depends on
2019-11-18 10:11:06 <fredrigu> mps: I'm trying to make apk work as a part of yocto
2019-11-18 10:19:14 <fredrigu> _ikke_: are we running CI tests on a powerpc?
2019-11-18 10:19:39 <_ikke_> fredrigu: for aports we are
2019-11-18 10:20:28 <fredrigu> _ikke_: for apk-tools as well it seems. I get a bunch of errors I wasn't expecting https://gitlab.alpinelinux.org/fredrigu/apk-tools/-/jobs/14584
2019-11-18 10:20:42 <fredrigu> I've a hard time reproducing them since it seems to work fine on x86
2019-11-18 10:20:46 <_ikke_> fredrigu: If you don't limit the arch, then it can be any arch
2019-11-18 10:21:00 <_ikke_> If you want to run it only on x86_64, add that as a tag
2019-11-18 10:21:25 <mps> fredrigu: thanks for info
2019-11-18 10:24:16 <fredrigu> _ikke_: thanks, it works fine (although, tests still doesn't work but at least I should be able to reproduce and fix it now)
2019-11-18 11:45:00 <PureTryOut[m]> _ikke_: do you know what exactly those register and unregister scripts are fore?
2019-11-18 11:45:45 <tmhoang> ncopa, _ikke_: are we ok with reverting ocaml to 4.08.1 ?
2019-11-18 11:46:38 <tmhoang> but it's quite ugly to revert, rebuild lots of stuffs ...
2019-11-18 11:56:12 <ncopa> tmhoang: i would prefer not revert if possible
2019-11-18 11:56:27 <ncopa> does camlp4 have many deps?
2019-11-18 11:56:32 <tmhoang> ncopa: some
2019-11-18 11:56:48 <ncopa> or i mean, are there many packages depending on camlp4
2019-11-18 11:56:56 <tmhoang> yes, some
2019-11-18 11:57:05 <tmhoang> < 10
2019-11-18 11:57:23 <maxice8> I think ocaml is really fussy and you need to recompile everything
2019-11-18 11:59:12 <tmhoang> community/ocaml-findlib,ocaml-lablgtk,haxe, testing/js_of_ocaml,ocaml-gettext
2019-11-18 11:59:24 <tmhoang> that's level 1 dep, maybe level 2 deps
2019-11-18 12:02:06 <ncopa> :-/
2019-11-18 12:02:09 <ncopa> sounds messy
2019-11-18 12:03:00 <maxice8> Back online, looking at pangox-compat
2019-11-18 12:03:51 <maxice8> Some builders for 3.11 are having weird errors like gnupg missing
2019-11-18 12:04:14 <maxice8> which seems like a package it shouldn't miss, i can install gnupg even though 3.11-x86_64 fails to find it for gcr
2019-11-18 12:05:04 <mps> maxice8: looks like 3.11 builders doesn't build deps orderly
2019-11-18 12:05:32 <_ikke_> PureTryOut[m]: I can't recall anymore
2019-11-18 12:05:32 <mps> i.e. go ahead even if deps are not built
2019-11-18 12:06:01 <PureTryOut[m]> Np I already found some docs for it https://downloads.haskell.org/~ghc/6.6/docs/html/Cabal/builders.html
2019-11-18 12:29:07 <Cogitri> Hooray, HP repaired my laptop, I'll be able to get it tomorrow
2019-11-18 12:29:26 <_ikke_> Cogitri: \o/
2019-11-18 12:34:38 <maxice8> \o/
2019-11-18 12:37:01 <PureTryOut[m]> 🎉
2019-11-18 12:42:32 <steveazz> Hello folks! I trying to build an armhf based Docker image `multiarch/alpine:armhf-v3.10` and trying to install bash on it, but it seems like it fails because `Ignoring https://uk.alpinelinux.org/alpine/v3.10/main/armhf/APKINDEX.tar.gz: No such file or directory`. Last Friday I had a similar failure where it was failing because of an expired
2019-11-18 12:42:33 <steveazz> certificate with the error `4286248308:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1915:` is this expected?
2019-11-18 12:58:09 <PureTryOut[m]> Seems there is something wrong with that repo, replace it for another one (e.g. https://dl-cdn.alpinelinux.org
2019-11-18 12:58:18 <PureTryOut[m]> uh *http://dl-cdn.alpinelinux.org
2019-11-18 12:58:27 <tmhoang> danieli: ^
2019-11-18 12:58:36 <PureTryOut[m]> Also, #alpine-linux is probably a better channel for this
2019-11-18 13:00:17 <steveazz> Ok got it thanks! Sorry about using the wrong channel
2019-11-18 13:01:34 <ncopa> no worries. i think maybe #alpine-infra is even better for this
2019-11-18 13:02:33 <clandmeter> uk was temp moved
2019-11-18 13:02:39 <clandmeter> but it seems https is not enabled
2019-11-18 13:03:47 <PureTryOut[m]> So I'm trying to upgrade `ghc` (the Haskell compiler). Compilation goes fine so far, but it needs a new tool "Alex", which is written in Haskell and needs to be compiled by that compiler. How is bootstrapping this supposed to work?
2019-11-18 13:05:43 <clandmeter> steveazz: i enabled https on uk.a.o
2019-11-18 13:18:56 <steveazz> clandmeter thank you! It seems to have worked, I appreciate it 🙇‍♂️
2019-11-18 13:19:02 <_ikke_> PureTryOut[m]: Usually manually by first installing the compiler from edge
2019-11-18 13:26:05 <PureTryOut[m]> So is this ok? It won't make Alpine 3.11 of course, but once 3.12 hits, it's fine to first download the compiler from edge, then compile Alex, and then compile the compiler?
2019-11-18 13:26:49 <_ikke_> It is already done to compile ghc itself
2019-11-18 13:27:05 <_ikke_> as long as it's managable, I don't think it's an isssue
2019-11-18 13:27:17 <PureTryOut[m]> Ok then 👍️
2019-11-18 13:27:35 <PureTryOut[m]> I'll put a comment for it in the APKBUILD
2019-11-18 13:31:03 <_ikke_> (y)
2019-11-18 13:31:18 <PureTryOut[m]> Ugh of course compilation fails like 1.5 hours in
2019-11-18 13:32:07 <PureTryOut[m]> Actually, compilation succeeded, just the unit tests didn't 😒
2019-11-18 13:32:19 <PureTryOut[m]> 
ACTION sent a long message:  <  >

2019-11-18 13:45:19 <artok> mps: my 5.4 rpi fix just got into rpi branch
2019-11-18 13:49:26 <mps> artok: nice to hear :)
2019-11-18 13:49:58 <mps> so, this can be a source for alpine linux-rpi4 kernel
2019-11-18 14:00:20 <artok> actually, same procedure will be here as before
2019-11-18 14:00:56 <artok> that rpi-patch is quite big
2019-11-18 14:06:12 <fredrigu> ncopa: https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/4 debian CI is done, but waiting for approval of other MR's first. Just FYI since we talked about this earlier
2019-11-18 14:12:31 <ncopa> very nice! thanks
2019-11-18 14:16:00 <artok> mps, afaik ncopa makes diff kernel upstream vs github.com/raspberrypi/linux which is then saved as patch. pros on that is that base kernel package needs to be downloaded once for each arch
2019-11-18 14:34:39 <mps> artok: ah, patch upstream then patch downstream, I see :)
2019-11-18 14:35:45 <mps> but that's how packaging works
2019-11-18 14:36:05 <maxice8> Can we get giblib source= archived ?
2019-11-18 14:36:09 <maxice8> it is unmaintained and just scrot uses it
2019-11-18 14:46:46 <_ikke_> And the source disappeared?
2019-11-18 14:49:00 <artok> ncopa: for rpi, 3 kernels for armhf (then all boards supported with that arch), 2 kernels for aarch64 (rpi3 + rpi4) and then 2 kernels for armv7 capable boards (rpi2 -> )
2019-11-18 14:51:57 <artok> ncopa OR Raspberry Pi 1, Pi Zero, Pi Zero W, and Compute Module for armhf, Raspberry Pi 2, Pi 3, Pi 3+, Compute Module 3 and Pi 4 armv7, and then Pi3 Pi4 with aarch64
2019-11-18 15:00:15 <artok> tbh, I havent tested armv7 on any rpi board
2019-11-18 15:02:36 <maxice8> _ikke_: Source is under an expired SSL cert
2019-11-18 15:07:30 <maxice8> PureTryOut: can you take a look at !1267 ?
2019-11-18 15:10:13 <PureTryOut[m]> <maxice8 "PureTryOut: can you take a look "> What about it? I haven't found a maintainer for it yet. I might do it myself till I find one who cares more about it than me tbh
2019-11-18 15:21:27 <PureTryOut[m]> Got a maintainer, I'll update the MR 👍️
2019-11-18 15:21:40 <ncopa> _ikke_: are you ok with this? https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/3
2019-11-18 15:23:13 <_ikke_> Yes, it can be optmized a bit in the future (create a docker image with the dependencies). The only thing is that the test stage is defined but not used
2019-11-18 15:23:51 <_ikke_> ncopa: Does it matter what arch this is run on? Right now it can be randomly any arch that we support
2019-11-18 15:24:39 <PureTryOut[m]> ncopa: do note that you have specified a "test" stage but run the tests in the "build" stage
2019-11-18 15:25:20 <_ikke_> PureTryOut[m]: This comes from oliv3r[m]
2019-11-18 15:25:43 <PureTryOut[m]> Oh, well, still applies 😉
2019-11-18 15:25:46 <ncopa> it come from fredrigu
2019-11-18 15:25:48 <ncopa> yeah
2019-11-18 15:25:58 <ncopa> probably better to run the make check in test stage
2019-11-18 15:26:17 <PureTryOut[m]> Definitely
2019-11-18 15:26:21 <fredrigu> yeah that was my first design
2019-11-18 15:26:34 <ncopa> i think its very nice to have it tested with debian/glibc too
2019-11-18 15:26:36 <fredrigu> however it turned out that the binary wasn't availiable then
2019-11-18 15:26:47 <_ikke_> Right, each job might be run on a different runner
2019-11-18 15:26:57 <_ikke_> you need to use artifacts to transfer them
2019-11-18 15:27:00 <fredrigu> ncopa: once !3 is merged, I can rebase !4 which will add support for debian
2019-11-18 15:27:05 <_ikke_> But not sure its worth it
2019-11-18 15:27:14 <ncopa> oh ok
2019-11-18 15:27:19 <fredrigu> I don't think so, tests are too small right now
2019-11-18 15:27:19 <PureTryOut[m]> Imo it is. Artifacts aren't hard to use
2019-11-18 15:27:21 <_ikke_> I think in this case a single job would suffice
2019-11-18 15:27:45 <ncopa> and remove the test stage i suppose
2019-11-18 15:27:46 <fredrigu> just the upstart time of another job will be longer than just running the tests
2019-11-18 15:27:51 <fredrigu> ncopa: sure
2019-11-18 15:27:52 <_ikke_> yes, indeed
2019-11-18 15:27:52 <PureTryOut[m]> And fases exist to have separation of concerns
2019-11-18 15:28:32 <_ikke_> The building in this case is just a requirement for testing
2019-11-18 15:28:46 <PureTryOut[m]> fredrigu: that amount of time is negligible
2019-11-18 15:29:41 <_ikke_> PureTryOut[m]: you need to install all the deps again in the separate phase as well
2019-11-18 15:30:18 <ncopa> i suggest that we remove the test stage for now, or rename "build" to "test" which is what we are really doing
2019-11-18 15:30:24 <PureTryOut[m]> Just the ones required for running the tests. Still, I don't see why that would be a problem
2019-11-18 15:30:34 <_ikke_> Just taking time
2019-11-18 15:30:37 <fredrigu> PureTryOut[m]: it's not, time is always critical. I get your concern with separation of concerns, it's a valid one. However when a project is small enough, sometimes the weight of adding abstractions doesn't justify the benefits. In my humble opinion this is such case
2019-11-18 15:30:39 <_ikke_> I agree with ncopa
2019-11-18 15:30:45 <_ikke_> It's enough to rename build to test, remove the build stage
2019-11-18 15:31:01 <_ikke_> This is just a very simple CI job
2019-11-18 15:31:07 <ncopa> and we can separate build and test when needed in future
2019-11-18 15:31:43 <ncopa> keep things simple until it makes sense to separate them
2019-11-18 15:31:50 <PureTryOut[m]> I mean, do whatever you want lol 🤷‍♂️ I personally just think separation of concerns is more important. But if we'd vote, I'd get outvoted here so I'm fine with whatever
2019-11-18 15:32:16 <ncopa> :)
2019-11-18 15:32:28 <fredrigu> I wonder if I should also remove the .travis.yml file, is it still used now when we're using gitlab?
2019-11-18 15:32:41 <_ikke_> PureTryOut[m]: I like to be pragmatic in these cases. If the goal is to just run the test suite, I don't see the need to split it up
2019-11-18 15:33:23 <ncopa> fredrigu: i think jirutka still uses it
2019-11-18 15:33:31 <ncopa> at least he updated it a few days back
2019-11-18 15:33:35 <PureTryOut[m]> Is there no need to test it with both Clang and GCC btw?
2019-11-18 15:33:38 <fredrigu> then I won't mess with it
2019-11-18 15:34:57 <fredrigu> !4 is done now, just merge !3 first
2019-11-18 15:37:56 <ncopa> we dont need run make and make check
2019-11-18 15:37:59 <PureTryOut[m]> maxice8: !1267 is done
2019-11-18 15:38:04 <PureTryOut[m]> I'd still like to get it in Alpine 3.11 if possible
2019-11-18 15:38:08 <ncopa> we only need run make check
2019-11-18 15:38:08 <maxice8> good
2019-11-18 15:38:27 <_ikke_> ncopa: because it will build it anyway?
2019-11-18 15:38:46 <maxice8> PureTryOut: It is
2019-11-18 15:39:32 <ncopa> _ikke_: yup
2019-11-18 15:40:00 <PureTryOut[m]> maxice8: awesome!
2019-11-18 15:40:03 <ncopa> I'd think `make -j $(nproc) check` would be what we want
2019-11-18 15:40:36 <ncopa> PureTryOut[m]: good point with both clang and gcc
2019-11-18 15:40:43 <ncopa> but lets start with gcc only for now
2019-11-18 15:40:52 <ncopa> and we add clang afterwards
2019-11-18 15:40:54 <ncopa> small steps
2019-11-18 15:41:02 <PureTryOut[m]> 👍️
2019-11-18 15:47:27 <fredrigu> ncopa: you're right. Fixed
2019-11-18 15:54:56 <ncopa> fredrigu: maybe we should also rename 'build' stage to 'test', which is more correct description?
2019-11-18 15:55:08 <ncopa> so we only have a single stage
2019-11-18 17:23:41 <fredrigu> ncopa: that's fixed in !4, maybe I should merge everything into one MR?
2019-11-18 18:33:56 <maxice8> is andypost here ?
2019-11-18 18:53:21 <andypost[m]> maxice8 hi
2019-11-18 18:53:40 <maxice8> can you test !1361 ?
2019-11-18 18:53:55 <maxice8> need to update recode to fix build failure but it changes library ABI which requires a rebuild of php7
2019-11-18 18:54:28 <andypost[m]> Hm, notvsure recode should cause php bump
2019-11-18 18:57:30 <maxice8> well php depends on so:librecode.so.0
2019-11-18 18:57:32 <maxice8> and the new recode has librecode.so.3
2019-11-18 18:57:51 <andypost[m]> It's about 7.4 https://github.com/php/php-src/commit/58b607c9ea6cdc631a61b18de0cf5c0b3c96c074
2019-11-18 18:58:24 <andypost[m]> So yes, needed
2019-11-18 19:00:48 <maxice8> we are on 7.3.11 so it is needed yet :D
2019-11-18 20:30:11 <mps> maxice8: what is the status of !693
2019-11-18 20:30:41 <mps> I see you created MR but it didn't go to CI, if I see it correctly
2019-11-18 21:03:48 <_ikke_> jkdsfj
2019-11-18 21:29:42 <PureTryOut[m]> _ikke_: I packaged more Haskell stuff, https://gitlab.alpinelinux.org/PureTryOut/aports/commits/haskell-packages
2019-11-18 21:30:33 <PureTryOut[m]> I'm trying to package haskell-test-framework and it's deps now to enable tests for some packages where it's disabled now. However, I'm currently having an issue compiling haskell-base and I don't know enough about Haskell to figure it out. Upgrading ghc did not help sadly
2019-11-18 21:30:51 <_ikke_> PureTryOut[m]: what issue?
2019-11-18 21:32:44 <PureTryOut[m]> my branch for ghc upgrade, just disabled tests for now to make it work https://gitlab.alpinelinux.org/PureTryOut/aports/commits/community_ghc
2019-11-18 21:33:23 <PureTryOut[m]> 
ACTION sent a long message:  <  >

2019-11-18 21:33:32 <PureTryOut[m]> _ikke_: the `haskell-base` error ^
2019-11-18 21:35:02 <_ikke_> PureTryOut[m]: Somethings brokeb. I get a long message line, but no link
2019-11-18 21:35:24 <_ikke_> "PureTryOut[m] sent a long message:  <  >"
2019-11-18 21:35:36 <PureTryOut[m]> Hmm? Normally if I send a multiline message the Matrix bridge gives IRC users a link
2019-11-18 21:35:38 <PureTryOut[m]> Strange
2019-11-18 21:35:48 <_ikke_> yes, that's what I expect
2019-11-18 21:36:01 <PureTryOut[m]> Well, here then https://paste.sr.ht/%7Epuretryout/2cb9d036a5c134f61913c4ef6ee1ad97d215b85d
2019-11-18 21:44:14 <PureTryOut[m]> Also interesting how ghc-8.8.1 seems to not be able to compile itself, while ghc-8.4.3 did it fine
2019-11-18 21:44:59 <_ikke_> prelude is the base module (the things that are available by default
2019-11-18 21:46:57 <PureTryOut[m]> Yeah I know that much. Not sure why it complains that it's not loaded though
2019-11-18 21:47:48 <_ikke_> me neither
2019-11-19 11:34:35 <_ikke_> ncopa: ah, I see you have a new version of lua-aports
2019-11-19 11:38:17 <_ikke_> ncopa: why doesn't ap recursdeps nagios-plugins return lm_sensors while it's a makedepends?
2019-11-19 11:40:07 <ncopa> it does for me?
2019-11-19 11:40:10 <ncopa> $ ap recursdeps nagios-plugins | grep lm_
2019-11-19 11:40:10 <ncopa> lm_sensors
2019-11-19 11:40:30 <ncopa> ah
2019-11-19 11:40:38 <ncopa> there are no lm_sensors
2019-11-19 11:40:46 <_ikke_> yeah
2019-11-19 11:40:47 <ncopa> it was renamed to lm-sensors
2019-11-19 11:40:51 <_ikke_> ah ok
2019-11-19 11:40:51 <ncopa> and has a provdes
2019-11-19 11:40:53 <ncopa> provides
2019-11-19 11:40:58 <ncopa> i just added support for provides
2019-11-19 11:41:19 <ncopa> i had same issue with linux-vanilla that depends on linux-firmware-any
2019-11-19 11:42:20 <_ikke_> So should we just rename lm_sensors to lm-sensors in nagios-plugins?
2019-11-19 11:42:25 <_ikke_> s/rename/change
2019-11-19 11:42:25 <alpine-meetbot> _ikke_ meant to say: So should we just change lm_sensors to lm-sensors in nagios-plugins?
2019-11-19 11:43:49 <ncopa> yes, i think thats a good idea
2019-11-19 11:43:56 <_ikke_> k\
2019-11-19 11:47:35 <_ikke_> ncopa: 54c4884f6bfa49ccf1b7e7396d0990926b8f6268
2019-11-19 11:47:39 <_ikke_> strange
2019-11-19 11:47:52 <_ikke_> ah, that's only for depends-sensors
2019-11-19 11:58:23 <mps> any reason we have more and more enabled supervise daemons?
2019-11-19 12:03:05 <ncopa> mps: i think maxice8 has been working on that
2019-11-19 12:04:02 <mps> not only he but prspkt also
2019-11-19 12:04:56 <mps> I'm interested to hear why and do we need supervising enabled by default
2019-11-19 12:07:40 <mps> (supervisors are good and useful tools, but not sure are they good to be enabled by default)
2019-11-19 12:11:16 <_ikke_> I guess most people don't mind it being enabled by default
2019-11-19 12:13:37 <mps> if daemon crashes for whatever reason I want to notice that early
2019-11-19 12:17:06 <_ikke_> But isn't that orthogonal to restarting it again?
2019-11-19 12:19:33 <mps> imagine having problem in web server, attacker is free to try different 'things' and server crashes, but unnoticeably restarted, and attacker again have a chance
2019-11-19 12:20:21 <_ikke_> Isn't that where monitoring is for?
2019-11-19 12:20:23 <mps> and admin/user is not aware it is under attak
2019-11-19 12:21:01 <artok> downtime is bad also
2019-11-19 12:21:25 <mps> artok: better down than breached
2019-11-19 12:21:36 <AinNero> i agree with mps here
2019-11-19 12:21:50 <AinNero> i really want to avoid that crashing daemons becomes a normal thing
2019-11-19 12:22:20 <AinNero> if it crashes more than once per year, its probably not suited for the job
2019-11-19 12:22:46 <artok> there is reason for docker...
2019-11-19 12:23:06 <AinNero> yes, to work around crappy software
2019-11-19 12:23:20 <AinNero> running docker in production @work
2019-11-19 12:23:22 <mps> AinNero: yes, that's my main point, if daemon crashes it should be fixed and not restarted
2019-11-19 12:23:33 <AinNero> and docker is easily worse than the buggy software its designed to work around
2019-11-19 12:23:39 <_ikke_> Depends on why it crashes
2019-11-19 12:23:48 <AinNero> _ikke_: OOM and such excluded
2019-11-19 12:24:08 <_ikke_> imho, restart + notification is best
2019-11-19 12:24:24 <_ikke_> Service is restored, but you are aware it crashed
2019-11-19 12:24:52 <mps> _ikke_: i still think that decision should be on admin
2019-11-19 12:24:52 <AinNero> ideally the notification has a coredump as mail attachment :P
2019-11-19 12:24:56 <_ikke_> And sane limit how often it does it
2019-11-19 12:26:22 <_ikke_> And I think there might be a distinction between being aware the daemon crashed and restarting it
2019-11-19 12:26:33 <_ikke_> (like we talked about earlier)
2019-11-19 12:27:07 <_ikke_> You should be able to rely on rc-status to see if it's running or not
2019-11-19 12:27:18 <mps> I think supervise option should go to /etc/conf.d/pgkname file and not in /etc/init.d/pkgname
2019-11-19 12:27:34 <_ikke_> mps: afaik, you are not against a supervisor
2019-11-19 12:27:36 <mps> and then admin can decide
2019-11-19 12:27:38 <_ikke_> just restart by default
2019-11-19 12:28:19 <mps> no, as I wrote earlier I use them and I'm not against them, but I think it shouldn't be default
2019-11-19 12:30:45 <mps> to again promote self, about 20 years ago I made debian routers with patching runit as init 1 on read-only fs
2019-11-19 12:31:11 <mps> so, supervisors are good tools for me
2019-11-19 12:34:34 <_ikke_> I'd like to be able to run rc-status and see whether a service is running or crashed. As openrc is limited what it can do for that, having a supervisor to at least be able to tell whether a service is running or not by default does not sound like a bad idea to me
2019-11-19 12:36:39 <maxice8> rc-status -S
2019-11-19 12:36:47 <maxice8> it even has (N) where N is number of times the service has been restarted
2019-11-19 12:37:26 <mps> _ikke_: yes, this limitation in openrc is quite annoying
2019-11-19 12:38:27 <mps> maxice8: this works only for supervised services?
2019-11-19 12:38:32 <_ikke_> yes
2019-11-19 12:38:37 <maxice8> Yes
2019-11-19 12:39:15 <maxice8> openRC doesn't know if a service crashed/stopped without supervision, technically it knows in some cases like failure right after starting
2019-11-19 12:40:07 <_ikke_> also if the pid from the pidfile has disappeared I guess?
2019-11-19 12:41:18 <mps> disappeared pids should be solved with new kernel, iiuc what are pidfd for
2019-11-19 12:42:58 <mps> i.e. that could be used for openrc if anyone add this feature to openrc
2019-11-19 12:43:47 <mps> but i didn't dived into this, TBH
2019-11-19 12:56:42 <maxice8> Better to just get rid of pidfiles altogether
2019-11-19 12:57:00 <_ikke_> nod
2019-11-19 12:57:20 <maxice8> daemontools did it a long time ago
2019-11-19 12:58:56 <AinNero> and it seems like we are coming back to a daemontools-style thing
2019-11-19 12:59:38 <AinNero> void linux has (had?) runit back when i was into it
2019-11-19 13:01:46 <maxice8> Void Linux always had an init system that did service-supervision
2019-11-19 13:01:47 <maxice8> first systemd then runit
2019-11-19 13:03:59 <mps> DJBs daemontools was first supervisor I used
2019-11-19 13:04:39 <AinNero> german hoster uberspace (where you get an unix account on a shared server) is using it for user services
2019-11-19 13:04:46 <AinNero> thats how i learned it
2019-11-19 13:04:49 <ncopa> i agree that if a daemon crashes, we should fix it rather than blindly restart it
2019-11-19 13:05:08 <ncopa> but i think a supervisor is better than pidfiles
2019-11-19 13:05:19 <clandmeter> +1
2019-11-19 13:05:59 <Cogitri> mps: But the new PID stuff for the kernel still doesn't notify you when something crashes, it just makes sure your PID doesn't get outdated and you kill the wrong process (oops)
2019-11-19 13:06:55 <AinNero> do we want supervisor functionality in openrc? or target support for djb/runit ?
2019-11-19 13:07:14 <AinNero> busybox already has runit incorporated as applets
2019-11-19 13:07:14 <mps> Cogitri: true, but who know will someone who is cleaver find different usage for it
2019-11-19 13:07:39 <ncopa> AinNero: there is already supervisor functionality in openrc
2019-11-19 13:07:43 <mps> AinNero: bb have it but it is not enabled in Alpine
2019-11-19 13:08:02 <ncopa> i am not too happy with the way runit works
2019-11-19 13:08:09 <AinNero> mps: i had it in mind as a separate package similar to busybox-extras
2019-11-19 13:08:18 <ncopa> which does poll
2019-11-19 13:08:34 <mps> I was tempted to make MR for that
2019-11-19 13:08:49 <ncopa> i'd rather use s6
2019-11-19 13:08:58 <mps> but I agree with ncopa, it doesn't use poll
2019-11-19 13:09:04 <clandmeter> then you never used s6 before :)
2019-11-19 13:09:11 <ncopa> but s6 is a bit "weird"
2019-11-19 13:10:07 <ncopa> i think that there are no perfect initsystems/supervisors
2019-11-19 13:10:22 <ncopa> and switching to something else now, is rather costly
2019-11-19 13:10:23 <clandmeter> from what ive seen i would just use openrc supervisor
2019-11-19 13:10:30 <mps> are there anything perfect?
2019-11-19 13:10:49 <ncopa> so i think sticking to openrc for now is ok
2019-11-19 13:10:57 <mps> (perfect is enemy of good)
2019-11-19 13:11:13 <ncopa> yes
2019-11-19 13:11:16 <clandmeter> there is nothing better without a shitload of sacrifices
2019-11-19 13:11:34 <ncopa> but my point is that the alternatives to openrc are not that much better, so its not worth it
2019-11-19 13:11:35 <mps> I agree, only not sure if it should be enabled by default for all daemons
2019-11-19 13:11:58 <ncopa> apparently someone thinks it should
2019-11-19 13:12:21 <ncopa> personally i think we should only enable supervisor when there is a proven need for it
2019-11-19 13:12:29 <mps> could that be moved to conf files instead of init
2019-11-19 13:13:02 <mps> init.d files*
2019-11-19 13:13:06 <clandmeter> i would argue that
2019-11-19 13:13:20 <clandmeter> if you dont like the supervisor to restart, just add that config.
2019-11-19 13:13:31 <clandmeter> pid files are just really stupid.
2019-11-19 13:14:20 <ncopa> mps: are there any good reasons to not enable supervisor?
2019-11-19 13:14:23 <mps> then I don't have any objections
2019-11-19 13:15:05 <mps> ncopa: I wrote above, that should be decided by admin or user of system
2019-11-19 13:15:14 <qa3Txu0iak0F> s6++
2019-11-19 13:15:21 <_ikke_> mps: supervsision in general or auto restart?
2019-11-19 13:15:44 <mps> _ikke_: {blind) restart
2019-11-19 13:15:45 <clandmeter> supervision without auto restart, can you call that still supervision?
2019-11-19 13:15:52 <_ikke_> yes, you can
2019-11-19 13:16:08 <_ikke_> just passive supervision
2019-11-19 13:16:14 <clandmeter> which is?
2019-11-19 13:16:27 <_ikke_> knowing the actual status of the service
2019-11-19 13:16:29 <clandmeter> notifications?
2019-11-19 13:16:43 <_ikke_> possibly
2019-11-19 13:16:47 <clandmeter> i can see that from rc-status too
2019-11-19 13:16:48 <mps> when it crashes notice admin (with coredump in mail :) )
2019-11-19 13:16:52 <clandmeter> so thats also supervision?
2019-11-19 13:17:45 <mps> clandmeter: well, most people accepts supervision as 'supervise + restart'
2019-11-19 13:19:15 <clandmeter> just define a basic rule within alpine how to setup/package supervise-daemon within rc scripts.
2019-11-19 13:21:26 <ncopa> so the thing with a supervisor is that it makes it possible get notification when a procecess dies for whatever reason
2019-11-19 13:21:35 <ncopa> with pid files, you cannot get notification when that happens
2019-11-19 13:21:39 <ncopa> so you need to poll
2019-11-19 13:22:13 <ncopa> once you have a system for getting notification, you can decide what you want to do with it
2019-11-19 13:22:20 <clandmeter> and not needing to manage a pid file is already a win.
2019-11-19 13:22:36 <ncopa> if you want auto-restart, then you can make that happen
2019-11-19 13:23:13 <clandmeter> question is, do we want it to try to restart X times or just let it die?
2019-11-19 13:23:19 <mps> ncopa: mostly agree
2019-11-19 13:23:26 <ncopa> if we dont have supervision, then we have no option
2019-11-19 13:24:01 <ncopa> but if we add supervision, but without the ability to configure the behavior
2019-11-19 13:24:10 <mps> clandmeter: again, I think die or restart should be left to admin
2019-11-19 13:24:13 <clandmeter> i would prefer it to restart, and if i dont trust or dont want it i can set retry=0 or whatever is called in conf.d
2019-11-19 13:24:17 <ncopa> then i think there is not much point
2019-11-19 13:24:29 <Cogitri> clandmeter: would be best if the user could configure that
2019-11-19 13:24:43 <clandmeter> of coure thats configable
2019-11-19 13:24:51 <ncopa> i think we all agree that user should be able to configure the autorestart policy
2019-11-19 13:25:06 <_ikke_> The question is what's the default behavior
2019-11-19 13:25:13 <ncopa> i think i disagree with the default though. i think want it to die by default
2019-11-19 13:25:28 <ncopa> so people report it
2019-11-19 13:25:32 <clandmeter> respawn_max=0
2019-11-19 13:25:40 <ncopa> and are interested in spending time to fix it
2019-11-19 13:25:54 <Cogitri> Sounds good
2019-11-19 13:27:55 <clandmeter> oh thats not correct what i pasted.
2019-11-19 13:28:12 <mps> nice
2019-11-19 13:28:37 <mps> can calmly go to lunch :(
2019-11-19 13:28:48 <mps> s/:(/:)/
2019-11-19 13:28:48 <alpine-meetbot> mps meant to say: can calmly go to lunch :)
2019-11-19 15:03:12 <mksully22> ncopa: looking at the failing log for https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/main/py3-pygments/py3-pygments-2.4.2-r2.log and noticed that the package build dependencies are not being installed on the Edge builder. Is it possible that this is because older packages are still present from earlier work and the build is failing because they are downlevel?
2019-11-19 15:08:07 <ncopa> possible
2019-11-19 15:08:12 <ncopa> i'll have a look at it
2019-11-19 15:09:14 <ncopa> there was a couple of old build deps installed
2019-11-19 15:09:24 <ncopa> i uninstalled those and reboot it
2019-11-19 15:10:19 <ncopa> mksully22: that solved it. good catch! thanks!
2019-11-19 15:14:17 <mksully22> Thank ncopa!
2019-11-19 15:15:29 <_ikke_> :)
2019-11-19 15:17:01 <ephemer0l> wut
2019-11-19 15:17:19 <ephemer0l> I got highlighted by you a bit ago _ikke_
2019-11-19 15:18:14 <_ikke_> in this channel?
2019-11-19 15:18:56 <_ikke_> Ah, that was an accidental terminal paste
2019-11-19 15:19:20 <ephemer0l> no worries :-) I'm not a bot FWIW
2019-11-19 15:19:54 <ephemer0l> Tost will vouch, rite SpaceToast
2019-11-19 15:20:17 <SpaceToast> Ah geez not you
2019-11-19 15:20:42 <ephemer0l> I stopped drinking for the moment, so..
2019-11-19 15:21:01 <SpaceToast> :p
2019-11-19 15:21:11 <ephemer0l> :-*
2019-11-19 18:01:37 <AinNero> switched to ubuntu because i wanted a system that "just works"
2019-11-19 18:01:44 <AinNero> ... but ships a NASM from 2017
2019-11-19 18:01:54 <AinNero> ... mtools from the same year
2019-11-19 18:02:28 <AinNero> maybe alpine is whacky as a desktop, but at least it had somewhat up-to-date software
2019-11-19 18:02:34 <AinNero> *has
2019-11-19 18:02:48 <TBB> that's the deal; you get one or the other
2019-11-19 18:18:01 <mps> hm, #10914
2019-11-19 18:18:49 <mps> works for me, looks like again people mixed stable and pkgs from testing
2019-11-19 18:19:57 <mps> we should add big note somewhere 'If you use pkgs from testing then upgrade to edge'
2019-11-19 18:31:44 <danieli> tmhoang: what?
2019-11-19 18:32:13 <artok> is there list of buildbots somewhere in public?
2019-11-19 20:40:21 <_ikke_> artok: You mean gitlab-runners?
2019-11-19 21:07:35 <artok> yah
2019-11-19 21:07:50 <_ikke_> Don't think so
2019-11-19 21:07:54 <artok> just what is detected arch on x86
2019-11-19 21:08:15 <artok> what is it build on, minimum processor pentium or what?
2019-11-19 21:08:53 <_ikke_> AMD EPYC 7401P 24-Core Processor
2019-11-19 21:09:19 <_ikke_> It's built on a 64bit machine in 32bit mode
2019-11-19 21:09:36 <artok> that's somewhat understandable
2019-11-19 21:10:05 <_ikke_> Same idea for the actual builders
2019-11-19 21:10:42 <artok> I just wondered with the clang targets
2019-11-19 21:15:15 <artok> https://hastebin.com/cabeqohayo.cpp
2019-11-19 21:15:36 <artok> diff should be there something like that
2019-11-19 21:16:51 <_ikke_> I, the tripplets, always fun
2019-11-19 21:16:53 <_ikke_> Ah*
2019-11-19 21:17:08 <artok> I'm fan of llvm+clang on my own projects, doing so much cross targeting
2019-11-19 21:22:48 <_ikke_> Hmm, bash-completion has test-failures :-/
2019-11-19 21:24:26 <maxice8> yes, got 7 of them
2019-11-19 21:24:44 <_ikke_> ah, you were looking at that as well
2019-11-19 21:25:13 <maxice8> yes the package required lots of changes, enough that i didn't want to just amend the commit from the original author
2019-11-19 21:25:21 <maxice8> usually i just amend small fixes and push it :D
2019-11-19 21:25:38 <_ikke_> yup, me too
2019-11-19 21:26:22 <maxice8> anyways, 22:26 so good night
2019-11-19 21:27:21 <mps> you moved to my TZ. good night :)
2019-11-19 21:27:59 <mps> ok, not only my, sorry
2019-11-19 21:28:01 <maxice8> Your TZ is CET?
2019-11-19 21:28:26 <mps> yes, same time is on my status line like you wrote
2019-11-19 21:29:47 <_ikke_> o?
2019-11-19 21:29:50 <_ikke_> o/
2019-11-19 21:30:08 <_ikke_> Lots of Alpine people are int CET :)
2019-11-19 21:30:45 <mps> Alps are in CET :)
2019-11-19 21:31:43 <_ikke_> Yeah, makes a lot of sense
2019-11-20 06:56:15 <kaey> _ikke_: armv7 erroneously runs again for !1433. have you looked at it?
2019-11-20 06:56:31 <kaey> maybe double maintainer line confuses parser or something?
2019-11-20 09:00:24 <clandmeter> kaey: we do not support double maintainer lines
2019-11-20 09:05:42 <clandmeter> _ikke_: does our ci check for this?
2019-11-20 09:06:06 <_ikke_> clandmeter: no
2019-11-20 09:06:13 <_ikke_> it could be added to apk-tools
2019-11-20 09:12:22 <_ikke_> I mean atools
2019-11-20 09:13:27 <clandmeter> :)
2019-11-20 09:51:20 <nmeum> maxice8: btw just a heads up: the -doc subpackage of testing/editline conflicts with the -doc subpackage of main/libedit not sure if there is any easy to solve this, maybe rename the man page of the former?
2019-11-20 09:55:24 <maxice8> I see
2019-11-20 09:56:43 <mps> isn't editline intended to replace libedit?
2019-11-20 09:56:58 <maxice8> no, editline is just a small library for nix
2019-11-20 09:57:04 <maxice8> nix being the package manager for nixOS
2019-11-20 09:57:41 <mps> aha
2019-11-20 10:06:23 <ncopa> im working on rebasing the dmvpn patches for strongswan
2019-11-20 10:06:41 <maxice8> good luck
2019-11-20 10:06:44 <ncopa> they got removed in b2957ab0565f02bfa82b4e943fada813e353541a
2019-11-20 10:06:47 <maxice8> :D working on python2 removal
2019-11-20 10:06:59 <ncopa> nice!
2019-11-20 10:07:04 <maxice8> also there are a few packages that have poor sources, can we get them archived here ?
2019-11-20 10:07:25 <ncopa> what i have done, is that i have uploaded them to dev.a.o/archive
2019-11-20 10:07:40 <ncopa> https://dev.alpinelinux.org/archive/
2019-11-20 10:07:48 <ncopa> which is the "permantent" source archives
2019-11-20 10:08:03 <maxice8> that is what i'm asking for but i don't know if there is a way to do it via the APKBUILD or i have to ask someone that can upload to it
2019-11-20 10:08:14 <nmeum> you could add a snapshot() function
2019-11-20 10:08:28 <ncopa> i think we should give you an account so you can upload yourself
2019-11-20 10:08:57 <ncopa> i dont know if there is any good upload to http service? so we dont need ssh/scp
2019-11-20 10:10:29 <ncopa> its a question for #alpine-infra
2019-11-20 10:53:35 <fredrigu> ncopa: where you happy with https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/3 or did you wanted me to do one MR for both !3 and !4?
2019-11-20 10:58:22 <ncopa> fredrigu: as _ikke_ pointed out, there is an unused stage "test". we should probably get rid of it.
2019-11-20 10:58:39 <ncopa> alternatively we rename the "build" stage to test
2019-11-20 10:59:18 <ncopa> but i dont have strong opinion tbh. what do youthink _ikke_? good to go as is?
2019-11-20 10:59:30 <ncopa> not sure how picky we want be
2019-11-20 10:59:58 <fredrigu> ncopa: yes, and as I pointed out that is fixed in !4
2019-11-20 11:00:12 <fredrigu> of course I can move that fix to !3
2019-11-20 11:03:04 <fredrigu> I've removed build and now only use one stage named test. https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/3/diffs
2019-11-20 11:04:00 <fredrigu> I've also opened two more bug fixes, and plan to push the multiarch later today, I'm just going to cleanup the code and write a proper commit message
2019-11-20 11:08:03 <ncopa> aha, i missed that it was fixed in !4
2019-11-20 11:10:57 <ncopa> merged !3
2019-11-20 11:11:40 <fredrigu> thanks
2019-11-20 11:13:22 <ncopa> can you please rebase !4 and drop the "WIP"?
2019-11-20 11:18:30 <fredrigu> ncopa: sure, just a moment
2019-11-20 11:23:19 <fredrigu> ncopa: https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/4 ready to be merged
2019-11-20 11:24:15 <fredrigu> so our test suite does not work with dash. Instead of replacing /bin/sh with /bin/ash or /bin/bash I changed the symbolic link in debian /bin/sh from /bin/dash to /bin/bash
2019-11-20 11:25:15 <fredrigu> I guess that's a matter of taste on how to do it. In a perfect world we should support dash as well in the test suite. But here I wanted the quickest solution just to get the tests up and running
2019-11-20 11:26:14 <ncopa> is it the apk-tools test suite that does not work with dash?
2019-11-20 11:27:37 <fredrigu> yes
2019-11-20 12:56:04 <ncopa> i think we should comment that in the .yaml file, or at least in commit message
2019-11-20 13:03:05 <kaniini> http://tpaste.us/ObQo
2019-11-20 13:03:10 <kaniini> here, have a patch
2019-11-20 13:19:25 <ncopa> thanks
2019-11-20 13:42:03 <maxice8> go is installed on the builders and can't rebuild llvm6 because of it
2019-11-20 13:42:46 <_ikke_> it's probably manually installed to bootstrap go
2019-11-20 13:49:04 <clandmeter> sudo apk add go; abuild -r; sudo apk del go :p
2019-11-20 13:52:55 <fredrigu> ncopa: it is mentioned in the commit message: Replace dash (default sh) with bash to make tests work.
2019-11-20 13:53:19 <fredrigu> perhaps I need to rephrase it?
2019-11-20 14:18:32 <PureTryOut[m]> Is Mitch Tishmack in this channel by any chance?
2019-11-20 15:21:54 <maxice8> _ikke_: it is blocking llvm6 D:
2019-11-20 15:22:29 <_ikke_> understood, just trying to guess the reason it has been installed
2019-11-20 15:26:47 <filoozom> Hi guys, anyone who can push the RPi things forward a bit in here? It's been 3 months now :(
2019-11-20 15:27:21 <maxice8> PureTryOut: can you check !1464 ?
2019-11-20 15:27:36 <artok> filoozom: personally I'm waiting for 5.4 kernel
2019-11-20 15:28:03 <PureTryOut[m]> Uh I don't do much with Avahi tbh, even less so the UI bits
2019-11-20 15:28:15 <PureTryOut[m]> And postmarketOS doesn't use Avahi at all
2019-11-20 15:28:26 <maxice8> oh
2019-11-20 15:28:53 <filoozom> artok: waiting for 5.4 and then what?
2019-11-20 15:29:18 <artok> doing merge request
2019-11-20 15:30:05 <filoozom> But why?
2019-11-20 15:30:47 <artok> but why?
2019-11-20 15:31:51 <artok> why to wait for 5.4?
2019-11-20 15:32:00 <filoozom> Why do you want to wait for 5.4? Wouldn't it be better to have it working now already and then do a "simple" bump later?
2019-11-20 15:32:15 <artok> well as I said, personally
2019-11-20 15:33:17 <artok> problem with foss is that we volunteered people do what is in our own interest =)
2019-11-20 15:33:50 <filoozom> Yes, I know! But I have two pull requests open already, just need them to be merged :)
2019-11-20 15:34:08 <filoozom> I wasn't asking for someone to do it for me, just someone to review if possible!
2019-11-20 15:34:42 <artok> one of those is already in the master
2019-11-20 15:35:31 <filoozom> Yes, still 2 left to get it to boot though :)
2019-11-20 15:36:31 <artok> are you able to boot with new start.elf using subdirectory on SD card for kernel/initramfs?
2019-11-20 15:38:22 <filoozom> I tried to boot while manually copying RPi's firmware a few months ago but it didn't work. Don't remember why exactly but I'm assuming I need the new kernel?
2019-11-20 15:40:23 <artok> I made some modifications into mkimg.arm.sh that it creates dummy boot symlink, so unpacking linux-kernel package (has boot dir) extracts kernel image into SD root and corrected config.txt accordingly
2019-11-20 15:41:20 <artok> also wireless firmware is copied from github.com/RPi-Distro/firmware-nonfree
2019-11-20 15:47:24 <artok> I think that was all needed to get it working
2019-11-20 15:50:10 <filoozom> Can you share those modifications?
2019-11-20 15:56:10 <artok> github.com/djazo/aports/tree/rpi4
2019-11-20 15:56:48 <artok> linux-firmware needs still checksums to update at least
2019-11-20 16:02:08 <filoozom> Thanks!
2019-11-20 16:03:28 <artok> I span up aws aarch64 and built packages there
2019-11-20 16:05:34 <artok> oh, might need to merge upstream aports into that
2019-11-20 16:05:40 <artok> some days old
2019-11-20 16:16:06 <maxice8> _ikke_: thanks for unclogging the builders
2019-11-20 16:16:33 <_ikke_> maxice8: If only I did do such a thing :)
2019-11-20 16:17:48 <maxice8> Oh
2019-11-20 16:18:56 <_ikke_> I just arrived home
2019-11-20 16:21:13 <maxice8> Thanks whoever did it then :D
2019-11-20 17:18:00 <PureTryOut[m]> maxice8: you changed a lot of service scripts a while ago to use something called supervisord or something? Why was that required? What does it do exactly?
2019-11-20 17:19:43 <maxice8> openrc supervisor, required not but it is objectively better than pidfile tracking which is done by default on openrc. It uses daemontools-style direct supervision, avoiding the pitfall of pidfiles and allowing implementation of healthchecks and restarting services
2019-11-20 17:20:55 <PureTryOut[m]> Ah ok, so it should be used in Alpine where possible then? Asking this as there is a new aport being MR'ed for postmarketOS with a service script, and was wondering if we should add the supervisor there as well
2019-11-20 17:21:38 <maxice8> it has a few kb/s of memory usage increase per service because of having a process to directly supervise the daemon
2019-11-20 17:21:39 <_ikke_> maxice8: apparently not all builders have been fixed yet
2019-11-20 17:21:52 <_ikke_> maxice8: I'm fixing it after I'm done shaving yaks
2019-11-20 17:21:57 <maxice8> it is preferable if you want reliable supervision of the process
2019-11-20 17:22:08 <maxice8> _ikke_: yes, x86_64 is failing and s390x ( i think )
2019-11-20 17:22:19 <_ikke_> armhf / v7
2019-11-20 17:22:27 <_ikke_> aarch64
2019-11-20 17:22:33 <_ikke_> So I don't think it's fixed yet
2019-11-20 17:22:33 <PureTryOut[m]> maxice8: thanks for the answer!
2019-11-20 17:23:23 <mps> maxice8: aren't we discussed supervisor yesterday, and concluded it shouldn't be enabled by default
2019-11-20 17:23:41 <_ikke_> mps: we concluded that the supervisor is usefull and can be enabled
2019-11-20 17:23:48 <_ikke_> mps: what might not be enabled is automatic restart
2019-11-20 17:24:01 <mps> ok, sorry
2019-11-20 17:24:41 <mps> what is use case for supervising then
2019-11-20 17:24:54 <_ikke_> mps: maxice8 mentioned it above
2019-11-20 17:24:59 <_ikke_> it's better then pidfile tracking
2019-11-20 17:25:40 <mps> and eating memory
2019-11-20 17:26:02 <_ikke_> should be negligable
2019-11-20 17:26:38 <ncopa> how much is it actually using
2019-11-20 17:26:52 <mps> OT, but that reminds me to some degree discussion on debian-devel ML when systemd is on the horizon :)
2019-11-20 17:27:10 <maxice8> I have 3 supervise-daemon using 301kb
2019-11-20 17:27:17 <maxice8> According to my (stolen) psmem script
2019-11-20 17:30:35 <ncopa> im fixing x264
2019-11-20 17:31:15 <mps> I'm ok with this but have to read/learn how to disable it by not touch init.d scripts
2019-11-20 17:32:30 <mps> and to explain my position, I'm not thinking that you are doing bad things. all good
2019-11-20 17:32:53 <maxice8> I don't think it is easy to disable because using supervisor=supervise-daemon also requires other changes to the initd file
2019-11-20 17:32:59 <maxice8> most importantly making sure it doesn't dameonize itself
2019-11-20 17:33:45 <mps> ok, no problem, I will try to see how can I add some 'alerting' service for it
2019-11-20 17:34:44 <mps> I'm too much accustomed to runit scripts :)
2019-11-20 17:36:43 <maxice8> supervise-daemon is basically runit
2019-11-20 17:36:49 <maxice8> which is basically daemontools
2019-11-20 17:37:31 <mps> so, will not be hard, thanks for info
2019-11-20 17:42:47 <_ikke_> ncopa: I can remove go from the builders, right?
2019-11-20 17:43:27 <maxice8> mps: it will be impossible without touching the initd files
2019-11-20 17:43:34 <maxice8> since supervisor=supervise-daemon is set on top
2019-11-20 17:44:40 <_ikke_> ah, go is installed as a dependency for gotop, which somehow was not removed
2019-11-20 17:45:11 <mps> maxice8: thanks for advices, but I first have to look how supervisor in openrc works
2019-11-20 17:46:57 <maxice8> mps: https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md
2019-11-20 17:49:17 <mps> good, will read after (too late) lunch :)
2019-11-20 17:50:01 <ncopa> _ikke_: yeah you shoudl apk del .make*
2019-11-20 17:50:19 <ncopa> i think there is a missing option to clean deps on failur
2019-11-20 17:50:21 <ncopa> in abuild.conf
2019-11-20 17:50:29 <ncopa> it should not keep the deps installed
2019-11-20 17:50:44 <ncopa> we have a problem with perl-mail-clamav
2019-11-20 17:50:51 <ncopa> which does not build with recent clamav
2019-11-20 17:51:03 <ncopa> and i cannot find any patch upstream
2019-11-20 17:53:44 <_ikke_> ERROR_CLEANUP="deps"
2019-11-20 17:53:46 <_ikke_> that looks right
2019-11-20 17:56:01 <ncopa> upstream report: https://rt.cpan.org/Public/Bug/Display.html?id=130891
2019-11-20 17:56:36 <ncopa> i'd like to remove it til we have this sorted out
2019-11-20 17:56:40 <ncopa> to unblock the builders
2019-11-20 17:56:50 <_ikke_> you can set arch= right?
2019-11-20 18:18:30 <mps> ncopa: it's a lot of work but did you considered upgrade perl to 5.30.1 before 3.11 stable release
2019-11-20 18:29:20 <_ikke_> maxice8: everything except ppc64le and s390x should be fixed now
2019-11-20 18:29:39 <maxice8> thank you
2019-11-20 18:30:12 <_ikke_> A bet you pulled a reverse psychology on me. Thanking me before I fixed it to guild me into doing it :P
2019-11-20 18:30:23 <_ikke_> s/guild/guilt/
2019-11-20 18:30:23 <alpine-meetbot> _ikke_ meant to say: A bet you pulled a reverse psychology on me. Thanking me before I fixed it to guilt me into doing it :P
2019-11-20 18:30:59 <_ikke_> I*
2019-11-20 18:37:35 <maxice8> _ikke_: https://www.youtube.com/watch?v=4JuK1Yr35Io
2019-11-20 18:42:41 <_ikke_> 0:D
2019-11-20 18:56:48 <_ikke_> does hylafax need to be updated? it complains about libtiff being too new
2019-11-20 19:00:08 <maxice8> i guess yes
2019-11-20 19:00:14 <maxice8> since libtiff was updated recently to fix a "few" CVEs :D
2019-11-20 19:00:21 <maxice8> hylafax and hylafax+
2019-11-20 19:00:47 <_ikke_> 6.0.7 is the latest version already
2019-11-20 19:02:29 <maxice8> then lets hope upstream made the work we can put as patch to use newer libtiff
2019-11-20 19:06:39 <_ikke_> Hmm, the configure file seems to match 4.[0]
2019-11-20 19:06:57 <_ikke_> What if I try to just add 1 as well
2019-11-20 19:07:12 <maxice8> yolo it to match 4.*
2019-11-20 19:07:14 <maxice8> :D
2019-11-20 19:07:27 <_ikke_> hehe
2019-11-20 19:08:28 <_ikke_> built seems to have worked
2019-11-20 19:08:58 <maxice8> nice
2019-11-20 19:09:28 <_ikke_> what is your typical workflow to create patch files?
2019-11-20 19:10:31 <maxice8> ax w ; do changes ; git diff > ../../changes.patch ; <C-d> ; ax e
2019-11-20 19:10:57 <maxice8> ax w -> create a git repository on $builddir
2019-11-20 19:11:10 <maxice8> also switch to it on a new shell so later i do <C-d> to go back to APORTSDIR
2019-11-20 19:11:16 <_ikke_> ah ok
2019-11-20 19:11:32 <maxice8> Works mostly fine
2019-11-20 19:11:42 <maxice8> falls apart when doing on big stuff like chromium
2019-11-20 19:11:50 <_ikke_> ok
2019-11-20 19:17:30 <_ikke_> I wonder why hylafax was not rebuilt when libtiff was updated
2019-11-20 19:17:49 <maxice8> libtiff didn't change soname ?
2019-11-20 19:17:58 <_ikke_> I guess
2019-11-20 19:18:29 <maxice8> libtiff-4.1.0 so:libtiff.so.5=5.5.0
2019-11-20 19:18:29 <maxice8> libtiff-4.0.10 so:libtiff.so.5=5.4.0
2019-11-20 19:20:00 <_ikke_> lol, someone got cute in the configure script
2019-11-20 19:20:24 <_ikke_> http://tpaste.us/8XjV
2019-11-20 19:20:36 <maxice8> oh ?
2019-11-20 19:21:14 <_ikke_> ^
2019-11-20 19:23:08 <maxice8> oh
2019-11-20 19:23:39 <maxice8> i got a Do they really still make x86_64-pc-linux-gnu systems?!
2019-11-20 19:28:58 <maxice8> anyways, should have used meson
2019-11-20 19:30:09 <_ikke_> I think this version of hylafax is from 2007
2019-11-20 19:30:19 <_ikke_> oh, no
2019-11-20 19:30:21 <_ikke_> 2018
2019-11-20 19:30:23 <_ikke_> n/m
2019-11-20 19:46:15 <ddevault> it looks like py3-gitlab in alpine 3.10 was incorrectly built against python3.8
2019-11-20 19:46:21 <ddevault> can someone address that?
2019-11-20 19:46:58 <_ikke_> incorrectly rebuilt?
2019-11-20 19:47:17 <ddevault> well, 3.10 is on python 3.7
2019-11-20 19:47:30 <ddevault> so there shouldn't be 3.8 packages in the 3.10 repo
2019-11-20 19:47:39 <ddevault> oh, wait, that package comes from edge
2019-11-20 19:47:41 <ddevault> bleh
2019-11-20 19:47:43 <ddevault> 
ACTION rebuilds it himself

2019-11-20 20:02:21 <artok> mixing edge and 3.10... brave people!
2019-11-20 20:41:30 <Cogitri> Uhh...so I just set up Alpine on my laptop but it doesn't boot due to the initramfs saying `trying to install packages on root...` (so I guess I somehow make mkinitfs think I did a ram install?). I only added zfs and nvme to my mkinitfs config so I'm not exactly sure what to do about this
2019-11-20 20:44:50 <maxice8> artok: alpine users are very brave
2019-11-20 20:58:14 <artok> indeed
2019-11-20 21:07:18 <_ikke_> Shouldn't "#if PIPE_ARCH_LITTLE_ENDIAN" be "#ifdef PIPE_ARCH_LITTLE_ENDIAN"
2019-11-20 21:07:24 <_ikke_> (re mesa)
2019-11-20 21:07:45 <artok> quickly without checking further, yes
2019-11-20 21:09:03 <_ikke_> These are just defined, not given a value
2019-11-20 21:09:24 <artok> yeah, if the value is 0 there, it will be evaluated as 0
2019-11-20 21:09:30 <artok> so it will be skipped
2019-11-20 21:10:05 <_ikke_> it's just #define PIPE_ARCH_LITTLE_ENDIAN in u_endian.h
2019-11-20 21:10:24 <_ikke_> So I guess #if PIPE_ARCH_LITTLE_ENDIAN would not make sense then
2019-11-20 21:11:46 <artok> would make if there is setting somewhere that PIPE_ARCH_LITTLE_ENDIAN would be something else than 0
2019-11-20 21:12:07 <_ikke_> artok: is the default 0?
2019-11-20 21:12:38 <_ikke_> This is what I'm trying to fix: http://tpaste.us/reae
2019-11-20 21:13:51 <artok> #define FOO
2019-11-20 21:13:56 <artok> FOO is ""
2019-11-20 21:14:01 <artok> aka nothing
2019-11-20 21:14:12 <_ikke_> right, so then that error makes sense
2019-11-20 21:14:18 <artok> totally makes
2019-11-20 21:14:21 <_ikke_> ok
2019-11-20 21:15:01 <_ikke_> the code combines #ifdef and #if defined()
2019-11-20 21:15:12 <artok> heh
2019-11-20 21:15:23 <artok> there it is, two different schools
2019-11-20 21:16:18 <_ikke_> ah, and it's in code that checks for ppc, so it makes complete sense now it only fails on that arch
2019-11-20 21:17:43 <_ikke_> apparently we're the only ones building mesa on ppc64le, because I don't see any issue raised yet
2019-11-20 21:19:05 <artok> not a surprise
2019-11-20 21:19:35 <_ikke_> ah, apparently it's already fixed upstream
2019-11-20 21:20:05 <_ikke_> I think..
2019-11-20 21:20:10 <_ikke_> Or this commit broke it
2019-11-20 21:20:12 <_ikke_> https://gitlab.freedesktop.org/mesa/mesa/commit/f9f60da813e69aacf541d25a24622c896f15ba98
2019-11-20 21:23:31 <artok> there is that the u_endian.h should have #define PIPE_ARCH_LITTLE_ENDIAN 1
2019-11-20 21:23:59 <_ikke_> Yes, but it does not have that
2019-11-20 21:24:15 <_ikke_> but the #ifdefs have been changed to #ifs
2019-11-20 21:24:37 <artok> that commit just sets them also
2019-11-20 21:24:52 <_ikke_> yes, so it's strange
2019-11-20 21:24:58 <_ikke_> unless somethings badly backported
2019-11-20 21:25:18 <artok> I would go with that rout
2019-11-20 21:25:19 <artok> e
2019-11-20 21:25:56 <artok> oh
2019-11-20 21:26:05 <artok> yeah it doesn't set that on linux platform?
2019-11-20 21:26:11 <_ikke_> what?
2019-11-20 21:26:29 <artok> gimme source tar.gz url and I'll check
2019-11-20 21:26:54 <_ikke_> I can fix it easily
2019-11-20 21:27:00 <_ikke_> I just wanne see what happened upstream
2019-11-20 21:27:46 <artok> my guess is that on apple and sun it works
2019-11-20 21:27:49 <_ikke_> https://gitlab.freedesktop.org/mesa/mesa/commit/ae071434e918586ab88a6533cd4a3b3f3dbd5a1f
2019-11-20 21:27:53 <_ikke_> This is fresh from the oven
2019-11-20 21:28:06 <_ikke_> seems indeed like a bad backport to me
2019-11-20 21:28:09 <_ikke_> that commit came from master
2019-11-20 21:28:18 <_ikke_> is backported to the 19.2 branch
2019-11-20 21:28:35 <artok> yah, have love for the header file and you'll be good to go =)
2019-11-20 21:29:03 <_ikke_> Yup, but I want to report it upstream as well
2019-11-20 21:29:17 <_ikke_> 19.2.5 was released 4 hours ago :D
2019-11-20 21:33:49 <artok> well you're handling hot hot version =)
2019-11-20 21:34:10 <artok> no wonder there is problem on platforms that are rare
2019-11-20 21:34:14 <_ikke_> heh
2019-11-20 21:34:34 <artok> wheeeee
2019-11-20 21:34:46 <artok> time for backup
2019-11-20 21:34:54 <artok> then I'm brave and update my macOS
2019-11-20 21:36:07 <artok> because they tell me that my dj software works on it, so I'll be okay doing money with it
2019-11-20 21:36:26 <_ikke_> :)
2019-11-20 21:50:35 <_ikke_> Builds now in our CI
2019-11-20 21:51:17 <mps> artok: macOS? you are using macbooks?
2019-11-20 21:51:35 <mps> (if they call it so?)
2019-11-20 21:54:44 <artok> i've been apple fanboy since 2002
2019-11-20 21:55:00 <artok> actually the day they released Logic Pro 6
2019-11-20 21:55:44 <artok> getting BSD based operating system that runs Logic and all major music software, that makes no turning back
2019-11-20 21:56:22 <mps> ah, I thought you are more ARM and Linux (fanboy)
2019-11-20 21:56:31 <artok> hobby =)
2019-11-20 21:57:49 <artok> aaand Linux robob 5.4.0-rc8-v8+ going strong
2019-11-20 21:58:15 <mps> robob?
2019-11-20 21:58:37 <artok> hostname for the rpi4
2019-11-20 21:59:11 <artok> merged from robot and Bob the Builder =)
2019-11-20 21:59:26 <mps> ah, here 'Linux zarya 5.4.0-rc8-1-gru #1 SMP PREEMPT Tue Nov 19 18:53:29 CET 2019 aarch64 GNU/Linux'
2019-11-20 21:59:40 <artok> if you see any dockerfiles I do, every build stage is named as bob =)
2019-11-20 22:00:16 <artok> my debian box, running on mac pro is just named sluga
2019-11-20 22:00:42 <mps> bob is code name for my chromebook board, and gru
2019-11-20 22:01:10 <mps> 'sluga'?
2019-11-20 22:02:08 <artok> russian, taken from Kraftwerk song Robots
2019-11-20 22:02:18 <artok> "Ja tvoi sluga, Ja tvoi rabotnik"
2019-11-20 22:02:27 <artok> "I'm your slave, I'm your robot"
2019-11-20 22:02:49 <mps> sluga in Serbian means lakey or butler
2019-11-20 22:03:20 <mps> yes, I was fanboy of Kraftwerk
2019-11-20 22:03:24 <artok> I still am
2019-11-20 22:03:36 <Cogitri> Hooray, got my laptop to boot
2019-11-20 22:03:43 <mps> I had all their 'plates'
2019-11-20 22:04:11 <artok> hmm or is sluga as "servant" and rabotnik is "slave"
2019-11-20 22:04:40 <mps> rabotnik is worker
2019-11-20 22:04:41 <artok> russian is not in my languages =D
2019-11-20 22:05:03 <_ikke_> robot means work, correct?
2019-11-20 22:05:27 <mps> robot, one who works without thinking
2019-11-20 22:05:41 <_ikke_> ah
2019-11-20 22:05:48 <_ikke_> like a drone
2019-11-20 22:06:13 <mps> it is not old term, I think Stanislav Lem invented it in book 'I robot'
2019-11-20 22:06:52 <mps> 'rabota' - work, usually hard
2019-11-20 22:07:16 <mps> and 'rob' means slave
2019-11-20 22:08:16 <mps> so, Lem combined that two to 'robot'
2019-11-20 22:09:30 <_ikke_> ah ok, thanks for that info
2019-11-20 22:09:35 <mps> back to macbook, anyone run alpine on some macbooks
2019-11-20 22:09:42 <_ikke_> ncopa does (did)
2019-11-20 22:10:39 <mps> I installed on one old (2013 year I think) but on usb drive and it is slow
2019-11-20 22:11:25 <mps> not sure if is so slow because of usb interface or something else
2019-11-20 22:13:31 <artok> might be the firmware
2019-11-20 22:13:44 <artok> not that easy to get firmware for apple stuff
2019-11-20 22:14:10 <mps> could be, because I have impression that I can make coffee on it when running alpine :)
2019-11-20 22:28:14 <artok> somewhat funny to have irssi on my pc laptop
2019-11-20 22:29:59 <hjaekel> "I, Robot" is by Isaac Asimov, not by Lem. But Lem has also written stories about robots
2019-11-20 22:30:05 <mps> I run irss
2019-11-20 22:30:24 <mps> hjaekel: right, I exchanged two
2019-11-20 22:31:31 <artok> but at least the robot word is from 1920 ish
2019-11-20 22:34:46 <hjaekel> I think Asimov invented the word "robotics", and of course the Three Laws of Robotics
2019-11-20 22:35:20 <AinNero> as soon as you know some minimum of IT you realize that asimov didnt know stuff about computers
2019-11-20 22:35:24 <AinNero> the laws are useless
2019-11-20 22:35:38 <AinNero> since a machine cannot intrinsically tell whats harm
2019-11-20 22:36:08 <AinNero> (to the contrary, we humans can)
2019-11-20 22:36:12 <AinNero> because, pain
2019-11-20 22:36:38 <_ikke_> and theory of mind
2019-11-20 22:36:58 <artok> that was like prime directive to be coded on the robots
2019-11-20 22:37:24 <artok> "the laws"
2019-11-20 22:37:51 <hjaekel> todays machines are stupid, so they cannot follow the Tree Laws. But Asimov's robots were intelligent, they could
2019-11-20 22:38:12 <artok> and AI is still programmed by people =)
2019-11-20 22:39:28 <AinNero> hjaekel: its fiction then
2019-11-20 22:39:45 <AinNero> im somewhat irated by systemic issues within common beliefs
2019-11-20 22:40:19 <mps> in every people dreamed about 'artificial' beings, Pygmalion and Galatea, Golem, Frankenstein, and now AI
2019-11-20 22:40:38 <mps> s/every/ wvery era/
2019-11-20 22:40:38 <alpine-meetbot> mps meant to say: in  wvery era people dreamed about 'artificial' beings, Pygmalion and Galatea, Golem, Frankenstein, and now AI
2019-11-20 22:40:43 <AinNero> you know what that is? the need to create a mirror of yourself?
2019-11-20 22:41:02 <AinNero> thats the instinct for getting kids, even when sometimes really misguided
2019-11-20 22:41:08 <mps> or dream for perfect
2019-11-20 22:41:27 <AinNero> what if thats actually the same thing?
2019-11-20 22:42:24 <mps> at the end could be
2019-11-20 22:44:54 <hjaekel> AinNero, soon an autonomous car has to decide which group of people have to die in an accident. So at Asimov's time it was fiction, but soon we have to define rules for those problems
2019-11-20 22:45:40 <AinNero> the problem is not generating the right decision from a situation
2019-11-20 22:45:51 <AinNero> the problem is perceiving the situation correctly
2019-11-20 22:45:59 <mps> monte-carlo method :D
2019-11-20 22:47:39 <AinNero> sometimes people really forget that the world isn't how we conceptualize/abstract it
2019-11-20 22:48:14 <mps> is it ever?
2019-11-20 22:48:46 <AinNero> never, thats a systematic problem
2019-11-20 22:49:12 <AinNero> you run really hard into it when you life a lifestyle other people have no word/concept for
2019-11-20 22:49:25 <AinNero> thats how i noticed that dilemma myself
2019-11-20 22:59:49 <mps> armhf CI box isn't up?
2019-11-20 23:45:15 <artok> oh this waiting for the backup
2019-11-20 23:45:41 <artok> it was time to do the backup, as it was almost 2monts old
2019-11-20 23:46:00 <artok> s/monts/months
2019-11-20 23:46:00 <alpine-meetbot> artok meant to say: it was time to do the backup, as it was almost 2months old
2019-11-20 23:46:26 <artok> hence 48G of backup to be done =D
2019-11-20 23:49:00 <artok> incremental that is
2019-11-21 01:21:15 <artok> dwm. slim and nasty
2019-11-21 01:22:51 <artok> truly the one to have on my linux installs
2019-11-21 01:23:20 <artok> filoozom: had success with rpi4 ?
2019-11-21 01:25:53 <artok> After I've upgraded my macOS, I'll start doing APKBUILD for the 5.4 kernel, from scratch. with arm6 for rpi < 3 arm7 for rpi > 2 and aarch64 for rpi3 and rpi4
2019-11-21 06:26:25 <_ikke_> I cannot reproduce the lua-penlight test failure on ppc64le
2019-11-21 07:30:56 <Cogitri> Could we enable APPARMOR in the -vanilla kernel?
2019-11-21 07:48:38 <mps> or have two kernels, one made with 'make allconfig' and one with 'make defconfig'
2019-11-21 07:49:12 <mps> although defconfig doesn't produce small kernel, also
2019-11-21 08:05:22 <ncopa> morning
2019-11-21 08:06:01 <ncopa> mps: i think perl 5.30.0 -> 5.30.1 is a bugfix only release, so it should be simple and safe
2019-11-21 08:07:12 <mps> yes, it is bugfix, but will need rebuild to rebuild 'some number' of pkgs
2019-11-21 08:07:22 <ncopa> huh?
2019-11-21 08:07:24 <ncopa> why?
2019-11-21 08:08:10 <ncopa> https://metacpan.org/pod/perldelta#Incompatible-Changes
2019-11-21 08:08:26 <mps> libperl?
2019-11-21 08:09:30 <mps> ahm,no. I need to finish morning coffee first :)
2019-11-21 08:09:48 <mps> you are right, not much
2019-11-21 08:09:52 <ncopa> yeah, i'll make some coffe here too
2019-11-21 08:36:49 <clandmeter> maxice8: why did you remove gd-dev in 40e0af22ae58a73fa9c5916034e6b050cc742a3b
2019-11-21 08:38:53 <maxice8> don't remember rn
2019-11-21 08:39:15 <clandmeter> i guess its a mistake?
2019-11-21 08:39:39 <clandmeter> also your commit msg tells no story
2019-11-21 08:41:47 <maxice8> yes should be a mistake
2019-11-21 08:42:16 <clandmeter> ok im adding it back
2019-11-21 11:07:48 <ncopa> Cogitri: any idea why dconf is failing?
2019-11-21 11:10:08 <Cogitri> I'll look into it after lunch
2019-11-21 11:17:35 <ncopa> found a patch upstream: https://gitlab.gnome.org/GNOME/dconf/commit/cc32667c5d7d9ff95e65cc21f59905d8f9218394
2019-11-21 11:17:37 <ncopa> i'll fix it
2019-11-21 11:20:34 <Cogitri> Okie 👍
2019-11-21 11:20:42 <Cogitri> Phew meson 0.52 sure has a lot of regressions
2019-11-21 11:20:51 <Cogitri> D shared linking broke in 0.52 too
2019-11-21 11:21:10 <Cogitri> 
ACTION makes note to backport 0.53 to 3.11 once that's releo

2019-11-21 11:21:14 <Cogitri> released*
2019-11-21 11:27:15 <_ikke_> ncopa: any idea why lua-penlight is only failing on ppc64le? the test failure does not look like something that depends on the arch
2019-11-21 11:28:21 <_ikke_> It does not fail in a ppc64le docker container
2019-11-21 11:32:26 <ncopa> isnt meson-0.53 unstalbe?
2019-11-21 11:33:02 <ncopa> _ikke_: yeah, i think mksully22 already has a fix: https://github.com/alpinelinux/aports/pull/12131
2019-11-21 11:33:06 <ncopa> which i merged
2019-11-21 11:33:08 <Cogitri> Meson doesn't follow the even==stable, uneven==unstable thingie of GNOME
2019-11-21 11:33:14 <ncopa> ok
2019-11-21 11:33:34 <_ikke_> ncopa: ok, thanks
2019-11-21 11:33:46 <_ikke_> ncopa: wonder why it only fails on the builders then
2019-11-21 11:45:13 <clandmeter> looks like wireguard will land in 5.6
2019-11-21 11:45:49 <clandmeter> should make ncopa happy, one less headache :)
2019-11-21 11:46:18 <mps> not only him
2019-11-21 11:47:03 <mps> especially if backported to 5.4 LTS
2019-11-21 12:05:48 <maxice8> the 3.11 builders reached community! :D
2019-11-21 12:06:02 <_ikke_> 8\o/
2019-11-21 12:16:15 <artok> algitbot should give hoorays for each builder when they've reached target
2019-11-21 12:24:17 <_ikke_> hmm, why is redo failing. it complains about variables being set that are explcitly unset
2019-11-21 12:29:36 <ncopa> \o/
2019-11-21 12:30:15 <ncopa> its only x86_64 thats not done with main
2019-11-21 12:30:19 <ncopa> im working on xen
2019-11-21 14:27:33 <mps> Cogitri: to not forget, I'm with you on apparmor enable
2019-11-21 14:29:39 <Cogitri> Yup, would be pretty nice and not really expensive
2019-11-21 14:44:20 <ncopa> i think the testing/apparmor may need some attention?
2019-11-21 14:44:54 <ncopa> duncaen: what is the status of doas port?
2019-11-21 14:48:05 <Cogitri> ncopa: Once apparmor is enabled in the kernel I'd love to maintain AppArmor
2019-11-21 14:48:29 <Cogitri> Before that not so much, having a custom kernel when using ZFS and Wireguard isn't fun
2019-11-21 14:49:20 <ncopa> we should try get the patches we have upstreamed
2019-11-21 14:52:49 <Cogitri> Yup, I've worked with upstream previously
2019-11-21 15:18:02 <ncopa> im working on rust now
2019-11-21 15:18:35 <ncopa> im manually "bootstrapping" it by temorparily add edge repo to install the build deps
2019-11-21 15:21:00 <Cogitri> Ah?
2019-11-21 15:49:03 <maxice8> AssertionError: content.xml not equal: expected len: 1961  actual len: 1961
2019-11-21 15:49:44 <artok> seems really far away from each other
2019-11-21 15:49:58 <ncopa> maxice8: which package?
2019-11-21 15:50:56 <maxice8> py3-docutils
2019-11-21 15:51:08 <maxice8> i'm upgrading it to 15.2, it drops usage of py-roman
2019-11-21 16:05:39 <maxice8> Some builders reached go and rust which i presume requires modifying the builders to have them built for 3.11
2019-11-21 16:17:27 <_ikke_> yes, they need to be bootstrapped
2019-11-21 16:17:37 <_ikke_> meaning, adding the package from edge and build it
2019-11-21 16:27:43 <ncopa> armhf, aarch64, ppc64le and x86 is done with rust
2019-11-21 16:28:13 <ncopa> armv7 and x86_64 still building
2019-11-21 17:09:17 <Cogitri> What values does musl's language implementation support? Everything UTF-8? (So things like `de_DE.UTF-8`?)
2019-11-21 17:09:40 <Cogitri> I'm trying to fix gnome-desktop's support for musl locales
2019-11-21 17:18:54 <mps> about year ago (maybe more) I rebuilt coreutils with this and it worked, except date of file in 'ls' was bad
2019-11-21 17:23:12 <artok> ncopa is there particular optimization flags used on builders? specially on each arm machine?
2019-11-21 18:04:00 <maxice8> oh cool, python3.8 has importlib.metadata
2019-11-21 18:04:12 <maxice8> once all packages switch to using it we can get rid of py3-importlib-metadata :D
2019-11-21 19:45:29 <maxice8> Fixing up failing packages while sleeping and i think i'm getting a signal from otherwordly forces, the 'rest' package is failing
2019-11-21 20:17:23 <mps> what's the conclusion about !1348
2019-11-21 20:18:06 <maxice8> Inconclusive
2019-11-21 20:18:08 <maxice8> well the s390x tests are disabled
2019-11-21 20:18:56 <mps> :)
2019-11-21 20:18:58 <hjaekel> mps, should I disable s390x completely?
2019-11-21 20:19:37 <mps> hjaekel: not sure, because that I ask in hope maxice8 will answer, and he did :)
2019-11-21 20:20:13 <hjaekel> he was the one who disabled s390x tests
2019-11-21 20:20:52 <mps> hjaekel: if I'm you I would disable it on arch where test fail in hope that someone with access to this arch can fix it
2019-11-21 20:21:39 <mps> but I'm not you and don't know what will be proper action
2019-11-21 20:23:19 <mps> maxice8: sorry to bother you again, do you think !1152 is ok to be pushed
2019-11-21 20:23:25 <hjaekel> I think a proper action would be to disable s390x, because the library is propably calculating wrong results on that platform
2019-11-21 20:23:46 <mps> if so, I agree with you
2019-11-21 20:24:00 <maxice8> eh, sure
2019-11-21 20:24:16 <maxice8> haha tox what you doin
2019-11-21 20:24:31 <maxice8> sometimes py3-tox decides not to find pytest for some reason and just fail all the tests
2019-11-21 20:24:39 <mps> 'tox'?
2019-11-21 20:25:04 <maxice8> test runner for python projects
2019-11-21 20:25:27 <mps> aha, every day I learn something new
2019-11-21 20:27:01 <maxice8> https://wiki.alpinelinux.org/wiki/Python_package_policies#You_need_to_use_the_.27tox.27_utility_to_run_tests
2019-11-21 20:27:55 <maxice8> mps: openv2g is failing hard :D
2019-11-21 20:27:59 <maxice8> oops
2019-11-21 20:28:12 <_ikke_> maxice8: ah, that one is good to know
2019-11-21 20:28:22 <mps> I see, it passed on CI
2019-11-21 20:30:06 <maxice8> _ikke_: 1519
2019-11-21 20:30:07 <maxice8>  * ikke: !1519
2019-11-21 20:30:11 <maxice8> !1519 can you check ?
2019-11-21 20:31:29 <mps> maxice8: this looks ok, imo
2019-11-21 20:32:23 <mps> how this bug slipt unnoticed
2019-11-21 20:54:23 <maxice8> well, almost 22:00 Here
2019-11-21 20:54:32 <maxice8> cya everyone
2019-11-21 20:55:24 <mps> o/
2019-11-21 20:57:41 <_ikke_> \\o
2019-11-21 21:12:01 <hjaekel> mps, maxice8, I disabled s390x for !2660.
2019-11-21 21:12:01 <hjaekel> I mean !1348, sorry
2019-11-21 21:12:01 <mps> hjaekel: will look later when come back home
2019-11-21 21:19:01 <_ikke_> hjaekel: what is the idea behind ${pkgdir:?}
2019-11-21 21:19:17 <_ikke_> ah, I follow
2019-11-21 21:19:37 <_ikke_> safeguard against accidentally deleting /usr/local if $pkgdir is not set for some reason
2019-11-21 21:20:10 <hjaekel> I was trying to make the linter green
2019-11-21 21:20:15 <_ikke_> heh :)
2019-11-21 21:20:17 <_ikke_> nice
2019-11-21 21:23:25 <_ikke_> hjaekel: pushed / merged
2019-11-21 21:23:53 <hjaekel> thanks _ikke_
2019-11-21 21:41:14 <_ikke_> hjaekel: seems to fail on arm(hf|v7(
2019-11-21 21:41:30 <_ikke_> geos
2019-11-21 21:42:39 <_ikke_> noding/.libs/libnoding.a(BasicSegmentString.o):(.rodata+0x0): multiple definition of `typeinfo name for geos::noding::BasicSegmentString';
2019-11-21 22:23:21 <hjaekel> sorry _ikke_, I can only look at that tomorrow after work. The pipeline in the MR ran through...
2019-11-21 22:47:08 <Cogitri> ncopa: Could you please take a look at !1529 ?
2019-11-22 07:00:49 <Cogitri> Morning
2019-11-22 07:01:07 <Cogitri> Do I need to do something special to get changes into 3.11 as of now?
2019-11-22 07:03:40 <ncopa> morning
2019-11-22 07:03:44 <ncopa> what kind of changes?
2019-11-22 07:04:01 <ncopa> just pushing to git master will make it a part of 3.11
2019-11-22 07:07:46 <Cogitri> Something like !1532
2019-11-22 07:08:07 <Cogitri> My server refused to update to py3.8 due to that
2019-11-22 07:08:36 <Cogitri> Ah okay, wasn't quite sure if we had some unofficial 3.11 branch already :)
2019-11-22 07:10:06 <ncopa> no
2019-11-22 07:10:10 <ncopa> we dont have branch yet
2019-11-22 07:10:21 <ncopa> we branch when we release 3.11.0
2019-11-22 07:10:48 <ncopa> that needs to be fixed yes
2019-11-22 07:11:00 <Cogitri> Okie, thanks for the info
2019-11-22 07:11:47 <ncopa> pushed it
2019-11-22 07:11:56 <ncopa> this is exactly the kind of things we should be fixing now
2019-11-22 07:12:52 <ncopa> we shoudl also have a look at `apk dot --errors`
2019-11-22 07:12:59 <ncopa> and solve those
2019-11-22 07:25:54 <Cogitri> Thanks :)
2019-11-22 08:17:44 <ncopa> I'll be afk most of today
2019-11-22 08:19:43 <mps> enjoy :)
2019-11-22 08:57:43 <_ikke_> morning
2019-11-22 08:57:55 <maxice8> morning
2019-11-22 09:20:14 <tmhoang> ncopa: I guess we have to roll back ocaml-camlp4. It was built using ocaml 4.08 on the builder. https://tpaste.us/Rz4o
2019-11-22 09:41:52 <_ikke_> mksully22: mind help bootstrapping go?
2019-11-22 09:41:55 <_ikke_> on ppc64le
2019-11-22 10:05:32 <clandmeter> _ikke_: you want me to do that?
2019-11-22 10:05:38 <_ikke_> clandmeter: sure :)
2019-11-22 10:06:01 <clandmeter> ppc64le.a.o?
2019-11-22 10:06:14 <clandmeter> build-3-11-ppc64le
2019-11-22 10:06:15 <_ikke_> I guess?
2019-11-22 10:08:12 <clandmeter> _ikke_: i have one for your todo
2019-11-22 10:08:17 <_ikke_> ok
2019-11-22 10:08:38 <clandmeter> check that arch all is set correctly
2019-11-22 10:09:12 <clandmeter> ie mtd
2019-11-22 10:09:18 <clandmeter> mtd-utils
2019-11-22 10:09:30 <clandmeter> and adwaita-gtk2-theme
2019-11-22 10:09:37 <clandmeter> atools could check it
2019-11-22 10:09:44 <clandmeter> or whatever is used for that
2019-11-22 10:09:46 <_ikke_> what is wrong with them?
2019-11-22 10:11:09 <clandmeter> hmm maybe it has already been corrected
2019-11-22 10:11:14 <clandmeter> but the buidlers still have all arch dir
2019-11-22 10:11:44 <clandmeter> if you set arch all explcitly for subpkg
2019-11-22 10:11:47 <clandmeter> this is not alled
2019-11-22 10:11:49 <clandmeter> allowed
2019-11-22 10:12:36 <clandmeter> https://git.alpinelinux.org/aports/commit/community/mtd-utils/APKBUILD?id=0c7d3793391202eff0009c1dac768d4f2449b356
2019-11-22 10:13:05 <_ikke_> noarch with arch subpkgs
2019-11-22 10:13:45 <clandmeter> maybe we  should do this from within abuild itself
2019-11-22 10:14:04 <clandmeter> i thjink ncopa mention it before
2019-11-22 10:17:06 <clandmeter> go is building
2019-11-22 10:17:22 <_ikke_> k
2019-11-22 10:26:54 <_ikke_> Hmm, darktable does not build with our version of gcc :(
2019-11-22 10:27:00 <_ikke_> it has been fixed, but requires gcc to be fixed
2019-11-22 10:28:46 <mps> _ikke_: iiuc, our gcc need to be fixed
2019-11-22 10:29:08 <mps> our, i.e. gcc in alpine
2019-11-22 10:29:09 <clandmeter> _ikke_: go is done
2019-11-22 10:29:15 <_ikke_> clandmeter: thanks
2019-11-22 10:29:19 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/issues/10909
2019-11-22 10:30:34 <mps> but 9.3 is not released yet
2019-11-22 10:32:12 <_ikke_> wonder if there's a patch for 9.2
2019-11-22 10:36:59 <mps> this? https://gcc.gnu.org/bugzilla/attachment.cgi?id=46962
2019-11-22 10:38:43 <mps> hard to follow their bug report, for me
2019-11-22 10:52:45 <mps> _ikke_: looks like void have this patch for gcc
2019-11-22 10:53:38 <mps> will try to build gcc with their patch in a few hours, need to finish some things of $day_job
2019-11-22 11:07:15 <maxice8> Where is makedepends_build and makedepends_host documented ?
2019-11-22 11:10:16 <maxice8> regardless atools=18.9.1 'black prince' now recognizes them @ikke
2019-11-22 11:10:23 <mps> not sure, but think these are for cross bootstrap
2019-11-22 11:11:01 <maxice8> That i am sure, we have those on Void Linux
2019-11-22 11:11:02 <maxice8> not the same name but same concept
2019-11-22 11:19:07 <_ikke_> maxice8: will update
2019-11-22 11:19:34 <maxice8> nice
2019-11-22 11:21:58 <_ikke_> done
2019-11-22 11:22:57 <_ikke_> ah, I already had them in the shellcheck shim
2019-11-22 11:42:17 <fredrigu> fabled: I've updated the MR https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/6
2019-11-22 11:48:52 <mps> we have !1526 and !1498 for #10220
2019-11-22 11:49:33 <mps> which of two MR's is better?
2019-11-22 11:53:56 <maxice8> both are missing the pkgrel= bump
2019-11-22 11:54:06 <fabled> fredrigu, looks better, thanks!
2019-11-22 11:54:09 <maxice8> the main/linux-vanilla: one has the correct title
2019-11-22 11:54:22 <maxice8> plus it doesn't misspell enable as Enalbe
2019-11-22 11:54:29 <fabled> fredrigu, btw. it seems i am getting sponsored for doing some apk-tools updates i've been long wanting to do
2019-11-22 11:54:48 <fabled> some of them probably a bit intrusive involving new binary file formats
2019-11-22 11:56:32 <mps> maxice8: they don't need pkgrel bump
2019-11-22 11:56:57 <mps> usually ncopa merges such things when upgrading kernels
2019-11-22 11:57:06 <clandmeter> fabled: nice
2019-11-22 11:57:17 <clandmeter> any schedule set already?
2019-11-22 11:57:50 <mps> _ikke_: trying to fix gcc, got 'configure: error: GNAT is required to build ada'
2019-11-22 11:58:28 <clandmeter> mps: apk add gcc-gnat
2019-11-22 11:58:43 <mps> clandmeter: not in makedepends?
2019-11-22 11:58:48 <clandmeter> no
2019-11-22 11:58:52 <mps> ok
2019-11-22 11:59:11 <clandmeter> boostrrap related
2019-11-22 12:00:11 <mps> thought something like this is issue. still don't know well how bootstrap gcc works
2019-11-22 12:01:07 <fabled> clandmeter, well, if it works out, i think we'd like to get next spring's alpine release already on the new apk-tools
2019-11-22 12:01:42 <clandmeter> how about compatibility?
2019-11-22 12:02:54 <fabled> we probably need to talk about. it's new binary format, so the new packages are not installable on old systems. but i think the new toolset should probably support old format at least for some time -- on some level. need to probably talk about that here.
2019-11-22 12:12:54 <fredrigu> fabled: that's nice! please let's have a disussion about it. I've a few things in the pipeline as well, I've tried to do issues on it
2019-11-22 12:13:34 <fredrigu> since abuild isn't suited for my usage yet, I build packages with a shell script that will probably break if you change the format
2019-11-22 12:14:11 <fredrigu> fabled: could you tell me more about the new binary format? I'm really curious
2019-11-22 12:14:21 <fabled> fredrigu, yes. the plan is to integrate the .apk generation to apk so it can be called from abuild, or by other scripts. there's probably interest enough on apk-tools to make it more independent from alpine
2019-11-22 12:14:45 <fabled> the new binary format is for two reasons: two offer speed ups and improve the security design
2019-11-22 12:15:17 <fabled> plan is to make the index file mmap:able; and the package to have signed file manifests so that "apk audit" will in future be based on signed data
2019-11-22 12:16:00 <fredrigu> the package creation is something I'm interested in as well. I was thinking about improving abuild but it would be much better to have everything in apk. It's really slow to create a new package today, my goal would be to have it as fast as installing one (that is, one read, one write)
2019-11-22 12:16:46 <fredrigu> oh, so you're talking about a new APKINDEX format and not a new format for the *.apk files?
2019-11-22 12:16:53 <fabled> yes, that's the plan. obviously the building part is separate. but when given a directory + some kind of description of dependencies and other meta-data, it'd produce a signed .apk
2019-11-22 12:16:57 <fabled> both
2019-11-22 12:17:01 <fabled> new APKINDEX, new .apk
2019-11-22 12:17:10 <fabled> unfortunately both are needed
2019-11-22 12:17:19 <fabled> .apk is needed for the signed manifest stuff
2019-11-22 12:18:07 <fredrigu> hmm, don't we already have signed manifests? isn't .PKGINFO the manifest?
2019-11-22 12:18:08 <fabled> APKINDEX is basically derived from .apk metadata, and it'd need to contain parts of the metadata there
2019-11-22 12:18:40 <fabled> yes we have, but the requirement comes from what is in the manifest
2019-11-22 12:18:57 <fabled> now it has only metadata; and the actual files and their checksums go into the data area of the package
2019-11-22 12:19:11 <fabled> the manifest will need to contain the full file structure + file checksums
2019-11-22 12:19:25 <fabled> so that apk audit can later verify that data
2019-11-22 12:19:28 <fredrigu> I see, yeah the APKINDEX should benifit greatly from a new format. There are of course downsides with a binary format, but perhaps the speed increase could justify it. It's not a very human friendly format right now anyway
2019-11-22 12:20:07 <fabled> i know the current is liked for it's simplicity and some have probably written alternate tooling on the file format directly
2019-11-22 12:20:13 <fredrigu> fabled: aha, yeah that sounds sane. Wouldn't it be enough to have checksum for the whole data.tar.gz?
2019-11-22 12:20:23 <fabled> but the only way to do future speed ups is to go binary.
2019-11-22 12:20:44 <fabled> obviously it's not big issue on servers or even modern laptops. the issues are in the embedded realm
2019-11-22 12:20:51 <fabled> and our pkg database increasingly with fast pace
2019-11-22 12:20:53 <fredrigu> since the APKINDEX is read for each invokation of apk it make sense to speed it up
2019-11-22 12:21:01 <fabled> most of apk startup time is just reading the text files in
2019-11-22 12:21:19 <tmhoang> ncopa, _ikke_ : if/when you have a minute https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1547
2019-11-22 12:21:29 <fabled> so just mmaping it would help a lot there. it get's rid of the parsing which is bulk of the time
2019-11-22 12:21:50 <fabled> re: data.tar.gz. yes, the checksum of that is in manifest. and it's good enough for install time.
2019-11-22 12:21:51 <fredrigu> for my specific case, this isn't a problem. I only run apk once. (but there are of course other use cases than mine)
2019-11-22 12:22:05 <fabled> the problem is that when that's done
2019-11-22 12:22:18 <fabled> you have system and no longer the original .apk's at hand (e.g. laptop without network)
2019-11-22 12:22:31 <fabled> and you run "apk audit" to see if someone modified anything in the system binaries
2019-11-22 12:22:43 <fabled> it needs to have somewhere signed file checksums
2019-11-22 12:22:47 <fabled> we don't have that currently
2019-11-22 12:23:02 <fabled> we have the file checksums in the apk db, but it's plain text and not signed
2019-11-22 12:23:09 <fredrigu> fabled: I love that idea. When building linux from scratch many years ago I started to create my own package manager and its main feature where just the auditing
2019-11-22 12:23:24 <fabled> the current use case is for generating modification list for "lbu commit"
2019-11-22 12:23:47 <fabled> but in future we want it to be valid for forensic type purpose and secure system integrity checking
2019-11-22 12:23:51 <fredrigu> it's a great feature to be able to see if someone has changed some binary file
2019-11-22 12:26:12 <Cogitri> Even if that someone was you :P
2019-11-22 12:31:21 <fabled> anyway, if you have feature requests or similar, it's good to put them in issue tracker, or email/irc me. even better if you can providing funding to implement them ;)
2019-11-22 12:34:02 <TBB> aren't there mechanisms like IMA that already take care of integrity checking?
2019-11-22 12:36:46 <TBB> (although, implementing IMA/EVM is ... let's say interesting)
2019-11-22 12:40:49 <fabled> it's little bit different use case. but if doing IMA, it'd be great if apk went at configured IMA properly :)
2019-11-22 12:45:12 <fabled> clandmeter, maybe i missed something. do i need to update my git repository paths for gitlab?
2019-11-22 12:47:19 <_ikke_> gitlab has it's own remote urls, yes
2019-11-22 12:47:32 <_ikke_> depending on the project
2019-11-22 12:47:42 <_ikke_> aports is /alpine/aports.git
2019-11-22 12:48:02 <_ikke_> apk-tools is /alpine/apk-tools.git
2019-11-22 12:48:14 <_ikke_> git@gitlab.alpinelinux.org:alpine/apk-tools.git or https://gitlab.alpinelinux.org/alpine/apk-tools.git
2019-11-22 12:48:44 <fabled> do i need to push there? though, gitlab did pick up my push to the old url...
2019-11-22 12:48:52 <fabled> but just not auto close the merge request
2019-11-22 12:49:12 <_ikke_> some repos are still synced from git.a.o to gitlab.a.o
2019-11-22 12:49:20 <_ikke_> but we do not have a bot to autoclose merge requests
2019-11-22 12:52:24 <_ikke_> for aports we have been just been manually closing merge requests
2019-11-22 12:53:28 <fabled> ok
2019-11-22 12:54:03 <fabled> on unrelated topic, has anyone ever setup or considered packaging apache-arrow ?
2019-11-22 12:55:29 <_ikke_> doesn't ring a bell
2019-11-22 12:55:57 <_ikke_> https://arrow.apache.org/
2019-11-22 13:07:11 <fabled> yes, that's the beast. seems to bundle tons of stuff, and not so co-operative with some of the OS shipped libs
2019-11-22 13:07:12 <fabled> :/
2019-11-22 13:15:20 <mps> _ikke_: no luck with https://gitlab.alpinelinux.org/alpine/aports/issues/10909
2019-11-22 13:16:19 <mps> added patch and rebuild gcc and used it to build darktable but still errors happen
2019-11-22 13:16:43 <_ikke_> (
2019-11-22 13:16:45 <_ikke_> :(
2019-11-22 13:23:24 <mps> hehe, there is good news, upgrade darktable to 2.6.3 and build works :=}
2019-11-22 13:24:01 <_ikke_> I have a branch with that upgrade
2019-11-22 13:24:12 <mps> probably without need of patched gcc
2019-11-22 13:24:14 <_ikke_> which is where I encountered the issue in the first place
2019-11-22 13:24:37 <mps> hmm, lets try with unpatched gcc
2019-11-22 13:25:00 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/771
2019-11-22 13:26:34 <mps> aha, I see
2019-11-22 13:27:07 <mps> hmm, I built 2.6.3 with patched gcc, but 2.6.2 failed
2019-11-22 13:27:31 <mps> how to downgrade gcc and tools, shortcut?
2019-11-22 14:03:11 <fabled> ncopa, flatbuffers 1.11.0 upgrade: http://sprunge.us/FtvNSn, does that look ok to you?
2019-11-22 14:11:54 <ncopa> fabled: lgtm. just check if it breaks abi
2019-11-22 14:12:32 <ncopa> checkapk can help you with that
2019-11-22 14:13:01 <fabled> -usr/lib/libflatbuffers.so.1.10.0
2019-11-22 14:13:01 <fabled> +usr/lib/libflatbuffers.so.1.11.0
2019-11-22 14:13:01 <fabled> usr/lib/libflatbuffers.so.1.11.0:    SONAME               libflatbuffers.so.1
2019-11-22 14:13:15 <fabled> should be good
2019-11-22 14:13:37 <ncopa> yeah
2019-11-22 14:13:39 <ncopa> push it
2019-11-22 14:16:54 <ncopa> tmhoang: lgtm. im fixing some whitespace damage and bump pkgrel: http://tpaste.us/9Nj7
2019-11-22 14:17:11 <ncopa> need to go
2019-11-22 14:23:00 <mps> hmm, looks like 'apk add -u gcc=9.2.0-r2' works to downgrade gcc
2019-11-22 14:24:38 <mps> _ikke_: ok, finished test builds darktable
2019-11-22 14:25:19 <mps> darktable 2.6.3 with unpatched gcc it fail and succeed with patched gcc
2019-11-22 14:25:42 <_ikke_> Ok, that's at least good news
2019-11-22 14:25:47 <mps> should I post gcc patch for review, what you think
2019-11-22 14:26:13 <_ikke_> Worth a try
2019-11-22 14:26:27 <_ikke_> otherwise we would need to disable darktable
2019-11-22 14:26:33 <mps> I'm not sure will that patched gcc pass CI, missing gcc-gnat?
2019-11-22 14:26:58 <mps> or maybe create WIP MR?
2019-11-22 14:30:41 <_ikke_> Not sure it needs to be WIP
2019-11-22 14:32:28 <mps> ok, preparing, will post in few minutes
2019-11-22 14:33:29 <_ikke_> WIP basically means: please don't merge yet, I'm still working on it
2019-11-22 14:33:40 <_ikke_> Which is not the case for this
2019-11-22 14:36:11 <mps> building gcc locally killed my box :)
2019-11-22 14:36:55 <_ikke_> heh
2019-11-22 14:37:00 <_ikke_> RIP
2019-11-22 14:39:12 <mps> rebooted, but have to setup working environment with a lot of terminals, tmux, mosh etc
2019-11-22 14:41:24 <mps> !1551
2019-11-22 14:42:56 <mps> tested build only on aarch64
2019-11-22 14:43:59 <mps> CI's doesn't have gcc-gnat. 'configure: error: GNAT is required to build ada'
2019-11-22 14:44:43 <_ikke_> Don't think that's easy to solve
2019-11-22 14:46:17 <mps> ok, it is there, look at it and if you think it is ok, you can even push it ;-}
2019-11-22 14:48:05 <_ikke_> Yes, but I'd like ncopa to review it, due to feature freeze
2019-11-22 14:49:12 <mps> np for me, I tested this only with darktable, nothing else
2019-11-22 14:50:05 <_ikke_> Can you add a fixes #10909 to the commit message?
2019-11-22 14:50:07 <mps> don't have much time these days, a lot of work and some social activities take much time
2019-11-22 14:50:25 <_ikke_> I appreciate you looking at this
2019-11-22 14:53:45 <mps> does it worked? I mean adding 'fixes #10909'
2019-11-22 14:55:16 <kaniini> does anybody know why qemu-user binaries are not available in their static variants
2019-11-22 14:56:53 <_ikke_> mps: I gues it works
2019-11-22 15:02:16 <mps> 'fixes' will be acted on when pushed to aports?
2019-11-22 15:02:32 <_ikke_> ye
2019-11-22 15:02:34 <_ikke_> s
2019-11-22 15:02:41 <mps> nice to remember
2019-11-22 15:03:15 <kaniini> ...
2019-11-22 15:03:19 <kaniini> are you fucking kidding me
2019-11-22 15:03:50 <kaniini> i think this is just
2019-11-22 15:04:01 <kaniini> dynamic binaries overwriting the static ones
2019-11-22 15:13:52 <kaniini> oh
2019-11-22 15:13:55 <kaniini> what the fucking fuck
2019-11-22 15:14:11 <kaniini> the files in build-static are not static
2019-11-22 15:14:44 <kaniini> well, lets see why
2019-11-22 15:15:36 <kaniini> ??????????
2019-11-22 15:15:40 <kaniini> CONFIG_STATIC=y
2019-11-22 15:15:52 <kaniini> this is quite frustrating
2019-11-22 15:19:00 <fredrigu> kaniini: could you provide a bit more context?
2019-11-22 15:19:36 <kaniini> qemu package is not building static binaries anymore
2019-11-22 15:39:32 <kaniini> oh
2019-11-22 15:39:36 <kaniini> they are static-pie
2019-11-22 15:58:22 <Cogitri> clandmeter: Can you take a look at pr12092?
2019-11-22 16:01:27 <Cogitri> Can someone who knows go take a look at pr12040
2019-11-22 16:25:59 <_ikke_> hjaekel: geos is still failing btw
2019-11-22 16:46:46 <hjaekel> I wonder why the builders were green but the build failed after merge to master
2019-11-22 16:47:07 <hjaekel> anyway, I created a new MR !1555, but the builders are still running...
2019-11-22 16:47:17 <_ikke_> hjaekel: probably due to some difference in environment between ci and the builders
2019-11-22 16:47:25 <_ikke_> hard to tell though
2019-11-22 16:48:14 <hjaekel> yes, and hard to investigate. I only know if my fix is successful is someone merges my MR
2019-11-22 16:54:49 <hjaekel> so the ci builders are green, but I don't know if my fix solves the issue on the production builders
2019-11-22 16:55:15 <_ikke_> Only one way to find out
2019-11-22 16:56:11 <_ikke_> I don't think the pkgrel bump is even necessary
2019-11-22 16:56:54 <_ikke_> It's not yet built on these arhches so it will try to build it anyway, and the change does not affect the other arches
2019-11-22 16:57:12 <_ikke_> (i'll fix it)
2019-11-22 16:57:17 <hjaekel> thanks
2019-11-22 16:58:11 <_ikke_> pushed, let's see
2019-11-22 16:59:17 <hjaekel> I keep my fingers crossed
2019-11-22 17:02:20 <_ikke_> :(
2019-11-22 17:02:36 <hjaekel> same error?
2019-11-22 17:02:43 <_ikke_> https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/geos/geos-3.8.0-r0.log
2019-11-22 17:02:45 <_ikke_> appears so
2019-11-22 17:05:59 <hjaekel> I expected to see the new flag -DDISABLE_GEOS_INLINE=ON. Is mycase statement correct?
2019-11-22 17:06:41 <_ikke_> It appears to be
2019-11-22 17:26:32 <kaniini> http://tpaste.us/LYw0
2019-11-22 17:26:38 <kaniini> somebody merge this patch
2019-11-22 17:26:43 <kaniini> thanks
2019-11-22 17:29:12 <Cogitri> Where's that from?
2019-11-22 17:29:20 <_ikke_> hjaekel: hmm, if I manually start the build on the builder, I do see the flags you passed
2019-11-22 17:31:49 <_ikke_> but it still fails to build
2019-11-22 17:32:17 <hjaekel> there is also the switch --disable-inline for the configure script, I am trying that one locally
2019-11-22 17:32:27 <_ikke_> ok
2019-11-22 17:33:01 <_ikke_> I have to go soon, but I can test it before pushing
2019-11-22 17:39:45 <hjaekel> I updated MR !1555 can you try that solution on the builder?
2019-11-22 17:50:48 <mps> hjaekel: testing in armv7 lxc
2019-11-22 17:56:40 <mps> hjaekel: _ikke_: geos with latest patch passed on armv7 lxc
2019-11-22 17:57:45 <hjaekel> great news!
2019-11-22 19:06:13 <mps> hjaekel: _ikke_: geos passed builders :)
2019-11-22 19:07:00 <mps> MR can be closed
2019-11-22 19:23:57 <_ikke_> hjaekel: mps: nice :)
2019-11-22 19:28:05 <hjaekel> great, thank you for your support :)
2019-11-22 19:28:12 <_ikke_> np
2019-11-22 19:33:00 <_ikke_> mps: moreutils fails due to a docbook-xls issue
2019-11-22 19:33:26 <mps> oh no, again
2019-11-22 19:33:35 <mps> isn't ncopa fixed it
2019-11-22 19:33:46 <_ikke_> I guess so
2019-11-22 19:34:35 <mps> it fail on 3.11 builders
2019-11-22 19:34:51 <mps> a lot of pkgs fail there
2019-11-22 19:36:03 <_ikke_> ncopa reverted docbook-xls
2019-11-22 19:36:09 <_ikke_> 8de3834ac8ce4411683cf6531921305961d9fcbe
2019-11-22 19:36:35 <mps> _ikke_: error is 'warning: failed to load external entity "/usr/share/xml/docbook/xsl-stylesheets-1.79.1/manpages/docbook.xsl"'
2019-11-22 19:36:40 <_ikke_> yes
2019-11-22 19:36:48 <mps> like it is not installed
2019-11-22 19:37:13 <mps> lets try build in aarch64 lxc
2019-11-22 19:37:44 <_ikke_> I build on x86_64
2019-11-22 19:37:53 <mps> it pass?
2019-11-22 19:38:14 <_ikke_> nope
2019-11-22 19:38:16 <_ikke_> fail
2019-11-22 19:38:18 <maxice8> fixed
2019-11-22 19:38:28 <mps> aha, not good
2019-11-22 19:38:40 <_ikke_> anoying that that's hardcoded
2019-11-22 19:38:45 <mps> maxice8: sorry, this is good :)
2019-11-22 19:38:57 <maxice8> turns out it was trying to load docbook-xsl-1.79.1 but we are on 1.79.2
2019-11-22 19:39:22 <_ikke_> so this is going to be an issue every time we update docbook-xsl
2019-11-22 19:39:32 <maxice8> yep
2019-11-22 19:39:54 <_ikke_> would a sed be more appropriate?
2019-11-22 19:40:01 <_ikke_> where you put the version in the apkbuild?
2019-11-22 19:40:03 <mps> this pkg is mess by design, and I sorry why I touched it at all
2019-11-22 19:41:08 <maxice8> maybe replace it with a sed that tries
2019-11-22 19:41:19 <maxice8> $(echo /usr/share/xml/docbook/xsl-stylesheets-*)
2019-11-22 19:41:43 <maxice8> like it is normal to do $(echo $PWD/build/lib.*) to get the proper PYTHONPATH for python packages that build C extensions
2019-11-22 19:42:40 <mps> uh
2019-11-22 20:01:44 <maxice8> pushed a simple version
2019-11-22 20:02:12 <_ikke_> are you sure?
2019-11-22 20:02:16 <_ikke_> I just pushed somehting
2019-11-22 20:02:34 <maxice8> https://git.alpinelinux.org/aports/commit/?id=eef2fb960ceeb31cf966ff89f5d585da993efffb yes
2019-11-22 20:02:43 <_ikke_> ok, then algitbot is slow
2019-11-22 20:02:58 <_ikke_> I don't see it announced in #alpine-commits
2019-11-22 20:14:13 <_ikke_> hmm, pytest-xdist might not have full py3.8 support yet
2019-11-22 20:14:15 <_ikke_> https://github.com/pytest-dev/pytest-xdist/pull/486
2019-11-22 20:22:46 <_ikke_> that one is hard because it's hard to distinguish what's part of the test and what's actual warning / error
2019-11-22 20:23:55 <_ikke_> yo dawg, I heard you liked testing, so I've added tests to your testing framework so you can fix tests while fixing tests
2019-11-22 20:25:10 <Cogitri> lol
2019-11-22 20:55:39 <_ikke_> making progress!
2019-11-22 20:55:52 <_ikke_> Was about to just disable those specific tests when I noticed what it was failing on
2019-11-22 20:59:10 <_ikke_> pluralization change :)
2019-11-22 21:47:32 <_ikke_> ah, apparently upstream already fixed it
2019-11-22 23:35:11 <Cogitri> Hm, can I not restart CI builds from other people's MRs?
2019-11-23 07:36:59 <_ikke_> Cogitri: no, it's because the job is run in their fork, where you don't have permissions
2019-11-23 09:15:02 <Cogitri> Oh, alrighty
2019-11-23 12:29:47 <_ikke_> I wish there was a better way of handling that
2019-11-23 13:52:47 <andypost[m]> commit aports/93d15aeb pr12155 needs backport
2019-11-23 14:43:55 <_ikke_> andypost[m]: done. You know you can do this yourself as well?
2019-11-23 15:34:21 <andypost[m]> ikke thank you, good to know
2019-11-23 18:48:17 <maxice8> Ok im back home
2019-11-23 18:48:32 <maxice8> Anything I shoujd attend to?
2019-11-23 19:07:27 <_ikke_> It's anoying, some htings are failing, but the logs are not available
2019-11-23 19:07:40 <maxice8> oh
2019-11-23 19:07:44 <maxice8> i think it is specific to 2 arches
2019-11-23 19:08:46 <_ikke_> hmm, armhf patchwork seems to just hang on signing the index
2019-11-23 19:14:35 <_ikke_> appears that it's just built
2019-11-23 19:19:10 <_ikke_> maxice8: do you happen to know what the pseudo-version error for git-lfs is about?
2019-11-23 19:19:56 <maxice8> seems to be related to go and its package management
2019-11-23 19:19:59 <maxice8> i have no clue about that
2019-11-23 19:20:15 <_ikke_> yes, indeed.
2019-11-23 19:20:38 <_ikke_> https://tip.golang.org/doc/go1.13#version-validation
2019-11-23 20:09:42 <_ikke_> Ok, got it
2019-11-23 20:10:05 <_ikke_> in go.mod, you need to remove the part before the hash in go.mod for the offending module
2019-11-23 20:10:09 <_ikke_> see https://tip.golang.org/doc/go1.13#version-validation
2019-11-23 20:32:09 <_ikke_> So upstream already fixed it in the next version
2019-11-23 23:20:07 <Cogitri> 
ACTION nervously watches the builders as they start building the new Rust version

2019-11-23 23:49:46 <mps> 
ACTION to

2019-11-23 23:51:11 <mps> hmm, too not to
2019-11-24 10:07:07 <z3ntu> How can I find out why apk is stuck at `fetch http://dl-cdn.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz` ? Running wget with that url works fine
2019-11-24 15:47:32 <_ikke_> regarding rust failing: https://github.com/rust-lang/rust/issues/65795
2019-11-24 18:01:57 <_ikke_> strange that rust is failing this way only on armv7
2019-11-24 18:43:27 <Cogitri> Huh? It worked on CI
2019-11-24 18:43:50 <_ikke_> I have a patch from upstream which I'm testing
2019-11-24 18:43:57 <_ikke_> but it takes ages ;)
2019-11-24 18:44:26 <Cogitri> I imagine :/
2019-11-24 18:44:29 <Cogitri> Thanks for looking into it
2019-11-24 18:44:33 <_ikke_> np
2019-11-24 18:44:59 <_ikke_> upstream isn't even sure themselves what is causing it :)
2019-11-24 18:45:07 <_ikke_> http://tpaste.us/adxN
2019-11-24 18:45:11 <_ikke_> look at the patch commit message
2019-11-24 19:18:14 <_ikke_> Cogitri: still building :)
2019-11-24 19:19:15 <Cogitri> Phew
2019-11-24 19:19:30 <Cogitri> Heh, good old "It makes more sense the less you think about it" :P
2019-11-24 19:19:49 <_ikke_> And that's without the patch (to verify I get the build error in the first place)
2019-11-24 19:21:16 <Cogitri> Oh
2019-11-24 19:36:29 <hjaekel> Hi maxice8, did you see that the changes for !1527 were not merged into master?
2019-11-24 19:39:34 <_ikke_> hjaekel: probably better to make a new MR for that
2019-11-24 19:40:21 <_ikke_> After a MR was merged and closed, it doesn't make sense to add new changes to it
2019-11-24 19:43:34 <hjaekel> OK from my point of view it was never merged, but you are right, I will create a new MR
2019-11-24 19:44:58 <_ikke_> hjaekel: that just has to do with our workflow atm, so gitlab will not show the MR as merged, but the commit(s) have been applied nontheless
2019-11-24 19:46:19 <hjaekel> that's the point. the MR was about moving geos from testing to community, but it is still in testing, so the commit has not been applied
2019-11-24 19:46:31 <hjaekel> I have created a new MR now
2019-11-24 19:46:54 <_ikke_> ah, ok
2019-11-24 19:47:02 <_ikke_> I thought the MR itself was about fixing it
2019-11-24 19:48:25 <hjaekel> the discussion about the fix somehow got into this MR, that may be the problem
2019-11-24 19:48:31 <_ikke_> yup
2019-11-24 19:54:20 <_ikke_> lol, Leo was ahead of me
2019-11-24 19:54:21 <hjaekel> thank you maxice8, that was fast :-)
2019-11-24 19:57:42 <hjaekel> can you also close issue #10528, I think it was fixed with !1528
2019-11-24 20:01:34 <_ikke_> hjaekel: I think 1528 caused that issue :)
2019-11-24 20:02:00 <maxice8> uhh
2019-11-24 20:02:26 <hjaekel> how?
2019-11-24 20:03:42 <_ikke_> it moved it from testing to community. If they were looking for it in testing, that MR caused it to be removed from testing
2019-11-24 20:04:39 <_ikke_> /ignore me
2019-11-24 20:05:05 <_ikke_> They are asking about a specific version of proj..
2019-11-24 20:12:55 <_ikke_> Cogitri: ugh, still building...
2019-11-24 20:13:41 <_ikke_> Cogitri: forgot to set the amount of jobs to run
2019-11-24 20:15:50 <Cogitri> Uff
2019-11-24 20:20:26 <_ikke_> Cogitri: do you have a armv7 builder?
2019-11-24 20:21:16 <Cogitri> Nop, I have aarch64 and x86_64
2019-11-24 20:21:20 <_ikke_> k
2019-11-24 20:21:35 <Cogitri> It passed on CI though, so there's that
2019-11-24 20:21:49 <_ikke_> Those are the most fun
2019-11-24 21:29:07 <mps> _ikke_: what should be done with rust on armv7, I can test it, now have some time
2019-11-24 21:29:48 <_ikke_> mps: I'm waiting for builds to finish
2019-11-24 21:29:52 <_ikke_> I have 2 running atm
2019-11-24 21:30:34 <mps> you are testing on builders
2019-11-24 21:30:43 <mps> ?
2019-11-24 21:30:45 <_ikke_> No
2019-11-24 21:31:06 <_ikke_> on dev container
2019-11-24 21:31:30 <mps> ok, if you need something I can test on armv7 and aarc64 lxc's
2019-11-24 21:31:46 <_ikke_> thansk
2019-11-24 21:43:29 <_ikke_> Hmm, I get a similar (but a different) error on my test build without patch
2019-11-24 21:44:46 <_ikke_> http://tpaste.us/qlgz
2019-11-24 21:45:54 <_ikke_> waiting for my other build with patch to finish
2019-11-24 21:48:16 <_ikke_> ah, the same error is also in the builder log
2019-11-24 21:51:05 <_ikke_> so at least we have a repro of the actual error
2019-11-24 21:51:16 <_ikke_> I wonder why it did not fail on CI
2019-11-24 21:52:24 <Cogitri> Same
2019-11-24 21:54:09 <_ikke_> Because I used the same docker image there that CI is using ...
2019-11-24 21:58:07 <_ikke_> seems like the patch works
2019-11-24 21:59:32 <Cogitri> Nice
2019-11-24 21:59:58 <_ikke_> heh, the 2nd job I started much later finished before the first job :D
2019-11-24 22:00:53 <_ikke_> pushed
2019-11-24 22:16:24 <_ikke_> :(
2019-11-24 22:16:54 <Cogitri> Failed? :c
2019-11-24 22:17:13 <_ikke_> yes, but not sure if it was due to the last push of mps
2019-11-24 22:17:15 <_ikke_> maxice8: *
2019-11-24 22:17:34 <Cogitri> Well, disabling rustdoc on armv7 would be easy enough too if it fails again
2019-11-24 22:18:10 <_ikke_> i restart the build to make sure it is building the version I pushed
2019-11-24 22:25:54 <mps> _ikke_: I didn't pushed anything today
2019-11-24 22:28:10 <_ikke_> no, I corrected it
2019-11-24 22:28:25 <_ikke_> wanted to autocomplete maxice, but accidentally tagged you
2019-11-24 22:28:34 <mps> ah, np
2019-11-24 23:07:34 <mps> got this 'linux-headers*: No arch specific binaries found so arch should probably be set to "noarch"'
2019-11-24 23:08:47 <mps> although later in APKBUILD there is check for arch
2019-11-25 04:33:14 <daveisfera> Hi, I'm new to Alpine packaging and I'm looking to get geos (currently in community) and gdal (currently in testing) to the main repo so they can be used in 3.10. What's the right way to do that? Submit a merge request to move them to that directory?
2019-11-25 05:28:43 <_ikke_> Cogitri: seems like rust has gone through now
2019-11-25 05:29:03 <_ikke_> It has indeed
2019-11-25 05:31:01 <_ikke_> ncopa: darktable requires a patch to gcc before it can compile on aarch64
2019-11-25 06:11:45 <ncopa> morning
2019-11-25 06:12:24 <ncopa> i suppose this is the fix for gcc? https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1551
2019-11-25 06:22:55 <_ikke_> yes
2019-11-25 06:44:23 <ncopa> seems like it does not fix building darktable on aarch64?
2019-11-25 06:46:52 <mps> ncopa: darktable 2.3.2 or 2.6.3
2019-11-25 06:47:10 <mps> s/2.3.2/2.6.2/
2019-11-25 06:47:10 <alpine-meetbot> mps meant to say: ncopa: darktable 2.6.2 or 2.6.3
2019-11-25 06:48:50 <mps> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/771
2019-11-25 06:49:05 <tmhoang> morning
2019-11-25 06:49:23 <mps> o/
2019-11-25 06:49:35 <tmhoang> mps early bird :D
2019-11-25 06:50:01 <tmhoang> daveisfera: your best bet is 3.12. You can't do it with 3.10, and 3.11 is on the way out already.
2019-11-25 06:50:36 <mps> tmhoang: good morning! and not to early, 7:50 is here
2019-11-25 06:50:50 <tmhoang> mps: same to me, but can't find the sun ...
2019-11-25 06:51:02 <tmhoang> err sun not found
2019-11-25 06:51:11 <mps> tmhoang: he left channel
2019-11-25 06:51:58 <mps> I thought to answer that proj will be moved to community in 3.11, already moved in edge
2019-11-25 06:52:35 <mps> geos, not proj, but they are related
2019-11-25 06:53:38 <mps> tmhoang: ofc, sun is here, and because that you can't find it there :P
2019-11-25 06:54:47 <mps> (during the night I stole it :D )
2019-11-25 07:41:10 <_ikke_> ncopa: thanks, now CI for darktable passes
2019-11-25 07:47:37 <ncopa> that darktable MR can be merged
2019-11-25 07:48:20 <tmhoang> ncopa: besides !1567 !1578, is there anything missing for s390x ?
2019-11-25 08:11:47 <_ikke_> ncopa: there is a curious case with apenwarr-redo on aarch64. When automatically built, it seems to still use cpio from busybox (which gives a usage warning). When I manually run abuild -r on the builder, it does work
2019-11-25 09:13:57 <ncopa> _ikke_: sounds like PATH issue and busybox symlink point to different location than GNU cpio
2019-11-25 09:15:03 <ncopa> hum. but it is not
2019-11-25 09:15:37 <ncopa> _ikke_: which builder? build-edge-aarch64 or build-3-11-aarch64?
2019-11-25 09:16:24 <_ikke_> ncopa: happened on both
2019-11-25 09:16:36 <_ikke_> edge was manually fixed (by just building it)
2019-11-25 09:21:10 <ncopa> there was a /bin/cpio symlink
2019-11-25 09:21:39 <_ikke_> hmm, but why does it work when I run it manually?
2019-11-25 09:22:20 <ncopa> probably due to /usr/bin:/bin vs /bin:/usr/bin order in PATH
2019-11-25 09:23:09 <_ikke_> ah ok, that makes sense then
2019-11-25 09:34:09 <ncopa> ls: /usr/sbin/sshd: No such file or directory
2019-11-25 09:34:18 <ncopa> something deletes that file
2019-11-25 09:34:35 <tmhoang> just quick bash script to check package failures, in case somebody needs it: https://tpaste.us/xk1l
2019-11-25 09:34:47 <tmhoang> 
ACTION forgive me for doing bash

2019-11-25 09:37:37 <ncopa> ok, i know what it is that deletes sshd
2019-11-25 09:37:44 <ncopa> it must be duo_unix
2019-11-25 09:38:00 <_ikke_> wow
2019-11-25 09:39:18 <_ikke_> Why only on one builder?
2019-11-25 09:40:27 <ncopa> i think it will happen to all of them when duo_unix is built
2019-11-25 09:40:34 <ncopa> im investigating
2019-11-25 09:40:41 <ncopa> it looks like what happens is
2019-11-25 09:40:57 <ncopa> openssh-server-pam is dependency of duo_unix
2019-11-25 09:41:02 <ncopa> it is installed during build time
2019-11-25 09:41:15 <ncopa> the openssh-server-pam replaces openssh-server
2019-11-25 09:41:29 <tmhoang> ouch
2019-11-25 09:41:34 <ncopa> so it will take over the ownership of /usr/sbin/sshd
2019-11-25 09:41:49 <_ikke_> and then it gets removed again I guess?
2019-11-25 09:41:50 <ncopa> when dependency is uninstalled, it will remove sshd
2019-11-25 09:41:55 <ncopa> yup
2019-11-25 09:42:52 <ncopa> im not sure what the proper fix is
2019-11-25 09:43:14 <ncopa> the workaround is to apk fix openssh-server on the builder
2019-11-25 09:43:38 <ncopa> i have done that on build-3-11-aarch64
2019-11-25 09:43:50 <tmhoang> iirc we don't have pinning/priority pinning packages in apk
2019-11-25 09:49:26 <ncopa> i think we should upgrade django
2019-11-25 09:59:09 <_ikke_> pcre2 is failing on armhf with a segfault
2019-11-25 11:39:19 <clandmeter> mps: i didn't see you mention linux 5.4?
2019-11-25 11:48:18 <_ikke_> ncopa: did you just remove /bin/cpio?
2019-11-25 12:32:27 <fredrigu> fabled: would you be able to take a look at https://gitlab.alpinelinux.org/alpine/apk-tools/merge_requests/5 ?
2019-11-25 12:43:53 <mps> clandmeter: Linus announced it but tar not made last 4 hours whne I looked last time, I was outside some time
2019-11-25 12:45:05 <mps> I hope I will have it in a few hours, now preparing linux-headers upgrade
2019-11-25 13:12:55 <clandmeter> mps: linux-5.4.tar.xz                                   25-Nov-2019 10:32    104M
2019-11-25 13:19:30 <ncopa> so linux 5.4 is released?
2019-11-25 13:25:02 <ncopa> seems like the librsvg upgrade needs some cleanup
2019-11-25 13:25:38 <ncopa> everything depending on librsvg needs to be disabled on s390x
2019-11-25 13:26:30 <mps> clandmeter: yes, I'm back and see it
2019-11-25 13:27:03 <mps> will make it this night and run on two arch'es
2019-11-25 13:27:14 <clandmeter> ncopa: yes
2019-11-25 13:27:40 <clandmeter> time to dive into .config :)
2019-11-25 13:27:45 <ncopa> yeah
2019-11-25 13:27:59 <ncopa> i wonder if we should rename it to -lts while at it?
2019-11-25 13:28:35 <mps> isn't too late for 3.11
2019-11-25 13:28:41 <ncopa> not really
2019-11-25 13:28:58 <ncopa> we dont have any rc1 so we havent started test booting and installer etc
2019-11-25 13:29:04 <mps> then, maybe you should
2019-11-25 13:29:09 <ncopa> and kernel does not influence how things are built
2019-11-25 13:29:16 <ncopa> with the exception of linux-headers
2019-11-25 13:29:36 <mps> yes, linux-headers should be 'stable' somehow
2019-11-25 13:30:20 <clandmeter> the rename will introduce another kernel?
2019-11-25 13:30:28 <ncopa> in theory yes
2019-11-25 13:30:38 <clandmeter> but currently just a provide?
2019-11-25 13:30:54 <ncopa> dunno that yet
2019-11-25 13:31:29 <ncopa> im also thinking that we should look over the way we do configs
2019-11-25 13:31:33 <clandmeter> i guess  you need that for upgrade?
2019-11-25 13:31:57 <clandmeter> i remember we renamed ones before which was kind of problematic?
2019-11-25 13:32:15 <ncopa> yeah renaming is a bit problematic
2019-11-25 13:32:31 <ncopa> or, will require some work
2019-11-25 13:32:46 <ncopa> simplest is to just upgrade as it currently is
2019-11-25 13:33:14 <ncopa> but i think it may be a good time to do a rename and refactoring the way we handle configs
2019-11-25 13:35:08 <ncopa> mps: we currently have the config for armv7 identical as armhf
2019-11-25 13:35:25 <ncopa> maybe its a good time to ecouple them?
2019-11-25 13:35:30 <ncopa> decouple*
2019-11-25 13:51:39 <mps> ncopa: I did for my use about two months ago, separated armv7 and armhf
2019-11-25 13:52:09 <mps> I made 4.19 armv7 multi platform
2019-11-25 13:52:27 <mps> enabled a lot more drivers and options
2019-11-25 13:52:45 <mps> some of users on #alpine-linux tested it
2019-11-25 15:13:04 <daveisfera> Hi, I'm new to packaging in Alpine and I'm hoping to get geos and proj from community and gdal from testing into main so they can be used with 3.10 and later. What's the right way to do that? Do I submit a Merge Request that moves them?
2019-11-25 15:13:29 <_ikke_> daveisfera: Welcome. Just having them in community is enough to get them in 3.11
2019-11-25 15:13:37 <maxice8> new packages can't be added to 3.10
2019-11-25 15:13:41 <_ikke_> ^
2019-11-25 15:13:48 <maxice8> community gets into stable versions but only for 6 months as far as i remember
2019-11-25 15:14:11 <daveisfera> ok, but how about for gdal that's in testing?
2019-11-25 15:14:34 <_ikke_> daveisfera: A merge request to move them (after it's confirmed it's working properly) is sufficient
2019-11-25 15:17:56 <daveisfera> we're only using a few of the features from those 3 packages but we've been using them for a while and they've all been working
2019-11-25 15:25:50 <mps> daveisfera: geos and proj are moved to community few days ago
2019-11-25 15:26:14 <daveisfera> oh ok, I knew it was fairly recent but didn't realize that it was that recent
2019-11-25 15:27:32 <_ikke_> daveisfera: That means the package at least is not obviously broken :)
2019-11-25 15:27:44 <daveisfera> Here's the merge request: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1620
2019-11-25 15:27:52 <daveisfera> Anything else that I need to do for that?
2019-11-25 15:28:20 <_ikke_> Nope
2019-11-25 15:28:35 <daveisfera> thanks
2019-11-25 15:46:19 <daveisfera> Is setting up syncing of a fork possible with the version of gitlab that Alpine is using? ( https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/ )
2019-11-25 15:48:53 <_ikke_> daveisfera: Yes, it should
2019-11-25 16:16:35 <telmich> The inkscape bug with a dependency on libgsl.so.23 - how does one fix this? I don't see an explicit dependency in the APKBUILD of inkscape on it
2019-11-25 16:16:47 <maxice8> telmich: i have an MR for it
2019-11-25 16:16:50 <telmich> (https://gitlab.alpinelinux.org/alpine/aports/issues/10984)
2019-11-25 16:16:51 <maxice8> just rebuild the package so it links to libgsl.so.25
2019-11-25 16:17:01 <telmich> maxice8: amazing, thanks!
2019-11-25 16:17:01 <maxice8> see !1622
2019-11-25 16:17:10 <telmich> damn... you are REALLY fast
2019-11-25 16:20:23 <_ikke_> He does this all day :)
2019-11-25 16:25:57 <_ikke_> telmich: fyi: setting a version constraint would not help, as the old version is no longer available
2019-11-25 16:27:00 <telmich> _ikke_: Ah, not what I meant -- I was actually wondering how the package depends on a library - is this resolved at build time / includes a list of all major so versions?
2019-11-25 16:27:15 <_ikke_> telmich: abuild traces the dependencies
2019-11-25 16:28:23 <_ikke_> https://tpaste.us/5EVx
2019-11-25 16:28:41 <maxice8> inkscape failed on x86_64 even though it passed on gitlab CI
2019-11-25 16:29:01 <telmich> Interesting, thanks for the pointer, _ikke_
2019-11-25 16:29:37 <_ikke_> Someone just pushed so it started building again
2019-11-25 16:31:06 <andypost[m]> all php extensions will fail to build on armhf, I'm trying to rebuild php locally in chroot for it but it fails for me
2019-11-25 16:54:33 <daveisfera> I just got a notification about a pipeline failure. I assume that this is from the merge request that I made, so is there anything I need to do about it?
2019-11-25 16:54:33 <daveisfera> https://gitlab.alpinelinux.org/daveisfera/aports/pipelines/2817
2019-11-25 16:55:05 <_ikke_> Hmmm, somehow seems to hang, let me restart it
2019-11-25 16:57:23 <ncopa> awesome! doas with persist!
2019-11-25 16:57:30 <ncopa> finally a sudo replacement
2019-11-25 16:57:43 <ncopa> i think i'd like to move doas to main
2019-11-25 17:00:07 <mps> also I wait to see how it works with abuild
2019-11-25 17:04:10 <maxice8> ncopa: not so quick
2019-11-25 17:04:51 <maxice8> upgrade forgot to include --with-timestamp
2019-11-25 17:14:27 <ncopa> maxice8: 2090e143369de22c64e69780bc51c9e0a717d8d6
2019-11-25 17:14:38 <maxice8> oh
2019-11-25 17:14:45 <maxice8> Yeah then it has persist :D
2019-11-25 17:14:55 <ncopa> and i have tested it
2019-11-25 17:17:45 <ncopa> with dynamic build it is only 36k
2019-11-25 17:18:11 <ncopa> sudo is > 1MB
2019-11-25 17:26:01 <_ikke_> Huge difference
2019-11-25 17:42:59 <daveisfera> I noticed the feature freeze email the other day ( https://lists.alpinelinux.org/~alpine/devel/%3C20191117211026.2504e5bc%40ncopa-desktop.copa.dup.pw%3E#%3C40a06eca-a3b8-e597-ad69-1f3702dafde9@schleiser.de%3E ), so will things being moved from testing to community today be included in 3.11?
2019-11-25 17:52:37 <telmich> ncopa: ahh, nice, then alpine kind of would be more bsd compatible
2019-11-25 17:55:53 <mps> ncopa: have a little time? want to ask you how you 'handle' kernel versions with two numbers, i.e. 4.19 (not 4.19.x)
2019-11-25 17:56:04 <mps> in APKBUILD, I mean
2019-11-25 17:56:33 <mps> (if you are still online, ofc)
2019-11-25 17:57:08 <daveisfera> _ikke_: looks like it failed again
2019-11-25 18:03:26 <maxice8> sddm is broken
2019-11-25 18:15:17 <_ikke_> daveisfera: very strange
2019-11-25 18:15:25 <_ikke_> Let me check the runner
2019-11-25 18:24:54 <maxice8> starting sddm or plasma stops my keyboard and input from working :D
2019-11-25 18:28:10 <daveisfera> _ikke_: died with a different error this time ( `error: index-pack died of signal 11` )
2019-11-25 18:29:54 <_ikke_> yes, noticed and restarted again :)
2019-11-25 18:35:56 <daveisfera> thanks
2019-11-25 19:41:28 <ddevault> is py3-requests in edge/main outdated?
2019-11-25 19:41:33 <ddevault> still py3.7 afaict
2019-11-25 19:42:13 <ddevault> no, it's outdated version-wise and my patch was never sent
2019-11-25 19:42:16 <ddevault> lemme fix that
2019-11-25 19:57:37 <ddevault> can someone put in a weechat rebuild? it needs to be rebuilt against new python versions
2019-11-25 19:58:58 <PureTryOut[m]> maxice8: Plasma on Wayland on Alpine breaks all hotkeys for some reason. Even KDE devs couldn't figure it out last Akademy lol
2019-11-25 19:59:41 <maxice8> PureTryOut: I mean it completely locks my keyboard and mouse off I have to reset by pwrbutton
2019-11-25 19:59:51 <_ikke_> "unable to load plugin "python": Error loading shared library python: No such file or directory"
2019-11-25 19:59:54 <_ikke_> ddevault: because of that?
2019-11-25 20:00:02 <ddevault> aye
2019-11-25 20:00:06 <ddevault> that might be something else, investigating
2019-11-25 20:00:24 <_ikke_> I did /plugin load python
2019-11-25 20:00:29 <_ikke_> not sure if that was the correct commadn
2019-11-25 20:00:44 <Cogitri> maxice8: You have the xorg drivers installed, right?
2019-11-25 20:01:05 <maxice8> Oh, no
2019-11-25 20:01:05 <ddevault> nable to load plugin "/usr/lib/weechat/plugins/python.so": Error relocating /usr/lib/weechat/plugins/python.so: PyDict_Next: symbol not found
2019-11-25 20:01:07 <Cogitri> That exact same thing happens when you start GDM in Xorg mode but don't have any of the xf86-input-* installed
2019-11-25 20:01:10 <ddevault> this is probably deeper than a rebuild
2019-11-25 20:01:11 <ddevault> working on it
2019-11-25 20:04:14 <PureTryOut[m]> maxice8: ok that is a first lol
2019-11-25 20:05:51 <Cogitri> I had that happen a few times to be by now, on another distro though and on GDM :P
2019-11-25 20:11:53 <ddevault> okay, I have an actual fix for weechat now
2019-11-25 20:12:14 <ddevault> sent
2019-11-25 20:18:10 <_ikke_> reviewing
2019-11-25 20:18:48 <ddevault> it's just a few choice commits cherry picked from master, rebased, and conflicts resolved
2019-11-25 20:23:11 <mps> _ikke_: do you have time to answer last question on !1582
2019-11-25 20:23:45 <mps> I don't know how to fix CI issue with log size
2019-11-25 20:24:19 <_ikke_> It's not the log sieze
2019-11-25 20:24:21 <_ikke_> size
2019-11-25 20:24:26 <_ikke_> ddevault: pushed btw
2019-11-25 20:24:47 <ddevault> cheers _ikke_
2019-11-25 20:24:50 <ddevault> thanks
2019-11-25 20:24:58 <mps> ah. exec time
2019-11-25 20:33:43 <_ikke_> That's a huge project btw to build
2019-11-25 20:34:15 <_ikke_> 11G     gcc-cross-embedded
2019-11-25 20:34:53 <mps> uh, small, simple, secure is fading away
2019-11-25 20:35:13 <ddevault> not if I can help it
2019-11-25 20:35:20 <ddevault> he said, while compiling grafana
2019-11-25 20:35:42 <_ikke_> Each build target is a couple of gigs
2019-11-25 20:36:09 <_ikke_> I noticed in when trying to find out what was taking so much space on the CI runner
2019-11-25 20:36:13 <_ikke_> s/in/it/
2019-11-25 20:36:13 <alpine-meetbot> _ikke_ meant to say: I noticed it when trying to find out what was taking so much space on the CI runner
2019-11-25 20:36:22 <mps> 11G for software pkg does not make any sense to me
2019-11-25 20:36:36 <_ikke_> not sure what the package ends up to be
2019-11-25 20:37:16 <mps> in my POV this is sign of 'not good' design
2019-11-25 20:37:43 <Cogitri> mps: Well, the GCC package contains a lot of stuff
2019-11-25 20:38:07 <Cogitri> And since you usually wouldn't install it on an embedded system but crosscompile to it I don't think size is that important to GCC devs
2019-11-25 20:38:45 <_ikke_> What is the final package size?
2019-11-25 20:39:37 <mps> gcc-cross-embedded-8.3.0-r1 installed size: 4096
2019-11-25 20:39:50 <mps> can't believe to my eyes
2019-11-25 20:39:58 <_ikke_> 4G?
2019-11-25 20:40:19 <mps> isn't size given in bytes
2019-11-25 20:40:25 <_ikke_> yes, I would imagine
2019-11-25 20:40:36 <mps> 'apk info -a gcc-cross-embedded'
2019-11-25 20:40:38 <_ikke_> But 4kb would not seem realistic
2019-11-25 20:40:51 <mps> could be bug in apk
2019-11-25 20:42:14 <mps> what is default llvm now, 8 or 9
2019-11-25 20:42:49 <_ikke_> maxice8: you replied to ddevault's request patch, but you only pushed alacritty
2019-11-25 20:43:11 <maxice8> oh i replied wrong
2019-11-25 20:43:19 <maxice8> i meant to reply to alacritty one
2019-11-25 20:43:24 <_ikke_> hehe
2019-11-25 20:43:49 <_ikke_> I track it because I try to keep lists.a.o up-to-date
2019-11-25 20:45:40 <_ikke_> maxice8: are you by chance now actually looking at the requests patch?
2019-11-25 20:45:59 <maxice8> no
2019-11-25 20:46:05 <_ikke_> ok, I will
2019-11-25 20:46:05 <maxice8> i am trying to get a game to run
2019-11-25 20:46:18 <_ikke_> didn't want to race with you :)
2019-11-25 20:47:34 <_ikke_> now it has been actually pushed :-)
2019-11-25 20:47:43 <ddevault> ^^
2019-11-25 21:45:38 <mps> in my test firefox fail to build with rust 1.39 on aarch64, trying to find 'casus'
2019-11-25 21:48:16 <Cogitri> Ah yes, Firefox and Thunderbird like to explode with every other Rust release
2019-11-25 21:50:27 <mps> 'explode', good term
2019-11-25 21:51:26 <mps> clandmeter: uname -a => Linux zarya 5.4.0-1-gru #1 SMP PREEMPT Mon Nov 25 22:04:49 CET 2019 aarch64 GNU/Linux
2019-11-25 21:51:37 <artok> whee
2019-11-25 21:51:59 <mps> and Alpine edge
2019-11-25 22:36:13 <mps> s390x CI is stuck? or something else is issue
2019-11-25 22:41:36 <Cogitri> The s390x CI seems to be pretty flaky
2019-11-25 22:41:37 <Cogitri> Had it randomly fail for me a few times too
2019-11-26 08:11:16 <ahmedbilal> How can we add rbd support in QEMU? The hurdle I know is that rbd requires CEPH as dependency which belongs to community repo while QEMU belongs to main repo.
2019-11-26 08:13:05 <clandmeter> does something in main depend on qemu?
2019-11-26 08:14:16 <ahmedbilal> clandmeter: Yep, some qemu packages like qemu-system-*
2019-11-26 08:14:37 <ahmedbilal> https://pkgs.alpinelinux.org/package/v3.10/main/x86_64/qemu
2019-11-26 08:14:46 <clandmeter> i dont think so
2019-11-26 08:15:09 <ahmedbilal> clandmeter: Then, I probably don't understand what you are trying to say.
2019-11-26 08:15:26 <clandmeter> if qemu is a dep of a package in main
2019-11-26 08:16:37 <ahmedbilal> clandmeter: doesn't this https://pkgs.alpinelinux.org/package/v3.10/main/x86_64/qemu-system-x86_64 have qemu as dependency?
2019-11-26 08:16:44 <_ikke_> it's a subpackage of qemu
2019-11-26 08:16:48 <clandmeter> thats qemu itself
2019-11-26 08:16:59 <ahmedbilal> ok. Then the answer is no
2019-11-26 08:17:00 <clandmeter> it does not ship headers
2019-11-26 08:17:10 <clandmeter> so probably not
2019-11-26 08:17:11 <_ikke_> So it would make more sense to move qemu to community
2019-11-26 08:17:20 <clandmeter> then the qeustion is if it makes sense to move it to community
2019-11-26 08:17:25 <_ikke_> :)
2019-11-26 08:17:35 <mps> makes sense
2019-11-26 08:17:47 <clandmeter> i think ncopa is the maintainer
2019-11-26 08:17:58 <clandmeter> so he needs to decide
2019-11-26 08:19:04 <telmich> Chiming in here for full disclosure: ahmedbilal and I work in the same team
2019-11-26 08:19:15 <ahmedbilal> :]
2019-11-26 08:19:26 <clandmeter> qemu is a bit special so im not 100% sure
2019-11-26 08:19:37 <clandmeter> you can also make a MR and ask his permission.
2019-11-26 08:19:44 <telmich> And you might remember that we are focussing on Alpine - so if something goes to community and needs a maintainer, we can probably also take the hat for that
2019-11-26 08:21:01 <clandmeter> write that in the MR please, or wait for ncopa to wake up :)
2019-11-26 08:21:17 <ahmedbilal> clandmeter: Github?
2019-11-26 08:21:25 <clandmeter> gitlab..ao
2019-11-26 08:21:30 <clandmeter> gitlab.a.o
2019-11-26 08:22:12 <ahmedbilal> clandmeter: Shouldn't I create an issue?
2019-11-26 08:22:34 <clandmeter> I think you make an merger request
2019-11-26 08:22:39 <clandmeter> merge...
2019-11-26 08:22:49 <clandmeter> man i miss my coffee
2019-11-26 08:23:19 <clandmeter> do all the changes in one merge request
2019-11-26 08:23:23 <telmich> clandmeter: early morning syndrome
2019-11-26 08:24:03 <ahmedbilal>  clandmeter: Sorry, I don't quit get it. Do I only have to move the qemu dir from aports/main to aports/community?
2019-11-26 08:24:06 <telmich> I'm with some Pu-Err tea at the moment, it's a bit easier to the body, comparad to coffee
2019-11-26 08:24:41 <clandmeter> ahmedbilal: yes and combine it with commit to add support for ceph
2019-11-26 08:25:12 <clandmeter> so you end up with 2 commits in the MR
2019-11-26 08:25:21 <ahmedbilal> clandmeter: aah. ok. Thanks (y)
2019-11-26 08:26:04 <clandmeter> if ncopa doesnt agree on moving qemu, then we need to find another solution.
2019-11-26 08:26:17 <ahmedbilal> clandmeter: yep
2019-11-26 08:32:51 <ncopa> morning
2019-11-26 08:33:29 <ahmedbilal> ncopa: morning
2019-11-26 08:37:30 <Cogitri> Morning
2019-11-26 08:42:36 <ahmedbilal> Just a small question, how to use all cores when using abuild/make?
2019-11-26 08:43:06 <_ikke_> ahmedbilal: in /etc/abuild.conf you can set the amount of jobs
2019-11-26 08:43:26 <ahmedbilal> _ikke_: Thanks. I forgot it.
2019-11-26 08:44:18 <mps> clandmeter: good morning :) 'uname -a' => Linux arya 5.4.0-0-vanilla #1-Alpine SMP Mon Nov 25 23:25:42 CET 2019 x86_64 GNU/Linux
2019-11-26 08:44:54 <clandmeter> mps: :)
2019-11-26 08:45:00 <mps> so, on both, aarch64 and x86_64
2019-11-26 08:45:18 <clandmeter> mps: do you use chromium?
2019-11-26 08:45:29 <mps> no, firefox
2019-11-26 08:45:35 <clandmeter> ok
2019-11-26 08:45:47 <mps> why, if I may ask
2019-11-26 08:45:54 <clandmeter> seems to be some improvements in chromium for aarch64
2019-11-26 08:46:26 <mps> aha, maybe should look at the end of week
2019-11-26 08:46:46 <mps> but firefox works quite fine
2019-11-26 08:47:37 <mps> it is quite responsive although I'm running system on external mmc card
2019-11-26 08:47:57 <clandmeter> responsive on a mmc card
2019-11-26 08:48:04 <clandmeter> does that even exist?
2019-11-26 08:48:59 <mps> root FS runs from mmc, I mean
2019-11-26 08:49:33 <clandmeter> i guess you never used nvme?
2019-11-26 08:49:50 <mps> I did, but on something else
2019-11-26 08:50:11 <mps> my arm boxes don't have nvme
2019-11-26 08:50:36 <mps> only emmc, mmc and ssd on usb ports
2019-11-26 08:50:51 <clandmeter> even ssd must be x time faster
2019-11-26 08:51:00 <mps> yes
2019-11-26 08:52:06 <mps> ssd on usb-c is about 10 times faster, not measured but that is my free estimate from experience
2019-11-26 08:53:13 <mps> I'm attaching ssd when building bigger packages
2019-11-26 08:53:47 <mps> for simple things mmc speed is acceptable, for me at least
2019-11-26 09:08:46 <Cogitri> Has someone dealt with elfutils before? I need eu-strip for flatpak-builder
2019-11-26 10:21:43 <telmich> which hardware do you use for testing aarch64?
2019-11-26 10:44:39 <ahmedbilal> How to print value of some variable in APKBUILD?
2019-11-26 10:44:55 <_ikke_> an APKBUILD is just a shell script
2019-11-26 10:45:18 <_ikke_> echo $foo works
2019-11-26 10:49:25 <ahmedbilal> _ikke_: I did but nothing get printed
2019-11-26 10:49:48 <clandmeter> ahmedbilal: apk add tpaste && tpaste < APKBUILD
2019-11-26 10:50:06 <_ikke_> ahmedbilal: maybe the variable is empty?
2019-11-26 10:50:11 <clandmeter> telmich: we use arm servers from packet.com
2019-11-26 10:51:52 <telmich> clandmeter: thanks, will check them out
2019-11-26 10:53:03 <clandmeter> ampere ones are nice
2019-11-26 10:53:17 <clandmeter> thunderx also but only for aarch64
2019-11-26 10:55:45 <ahmedbilal> Sorry, for noob question when I try to add rbd support into https://git.alpinelinux.org/aports/tree/main/qemu/APKBUILD it says install librbd/ceph devel. I install them and it still says that. I check in qemu repo ./configure https://github.com/qemu/qemu/blob/master/configure#L3971 which report this only if it can't find #include <rbd/librbd.h>.
2019-11-26 10:55:46 <ahmedbilal> So, I think probably the linker flag is missing `-lrbd -lrados` into qemu APKBUILD.
2019-11-26 10:56:17 <ahmedbilal> How can I add these linker flag to APKBUILD?
2019-11-26 10:57:29 <clandmeter> did you add ceph-dev to makedepends?
2019-11-26 10:57:41 <ahmedbilal> yes, librbd too
2019-11-26 10:57:56 <_ikke_> ahmedbilal: ./configure detects whether rbd is installed and adds those flags
2019-11-26 10:58:13 <clandmeter> do not add librdb
2019-11-26 10:58:27 <clandmeter> ceph-dev should be enough
2019-11-26 10:59:14 <ahmedbilal> ok.
2019-11-26 11:00:01 <clandmeter> my guess is thhats the only  think you need to add.
2019-11-26 11:00:30 <clandmeter> if it doesnt add it check the configure log
2019-11-26 11:00:30 <ahmedbilal> compiling again
2019-11-26 11:00:46 <clandmeter> you can just wait configure log if it works
2019-11-26 11:00:52 <clandmeter> s/wait/watch
2019-11-26 11:00:52 <alpine-meetbot> clandmeter meant to say: you can just watch configure log if it works
2019-11-26 11:01:16 <ahmedbilal> clandmeter: Where can I found configure log.
2019-11-26 11:01:29 <clandmeter> you can explicitly define to build with it i guess
2019-11-26 11:01:45 <clandmeter> --with-whatever-it-is
2019-11-26 11:02:38 <clandmeter> its always better to define it explicitly so you are sure the support is added.
2019-11-26 11:03:28 <ahmedbilal> where can I put this?
2019-11-26 11:03:43 <ahmedbilal> s/put/explicity define this
2019-11-26 11:03:43 <alpine-meetbot> ahmedbilal meant to say: where can I explicity define this this?
2019-11-26 11:04:09 <clandmeter> in the build section
2019-11-26 11:04:17 <clandmeter> --enable....
2019-11-26 11:04:35 <clandmeter> https://git.alpinelinux.org/aports/tree/main/qemu/APKBUILD#n227
2019-11-26 11:04:59 <clandmeter> find out the correct switch by ./configure --help
2019-11-26 11:05:54 <clandmeter> configure will show all detection and failures on stdout
2019-11-26 11:08:33 <ahmedbilal> clandmeter: This is diff https://tpaste.net/05cH53gvoZ
2019-11-26 11:09:53 <clandmeter> wtf
2019-11-26 11:10:44 <clandmeter> ahmedbilal: can you please use tpaste.us?
2019-11-26 11:10:53 <clandmeter> this add stuff makes my head spin round
2019-11-26 11:11:23 <clandmeter> i actually thought it was tpaste.us
2019-11-26 11:11:37 <clandmeter> seems somebody liked it so much they made an tpaste.net
2019-11-26 11:11:54 <clandmeter> tpaste.us is from alpine :)
2019-11-26 11:12:03 <ahmedbilal> It get stuck when I do cat APKBUILD | tpaste
2019-11-26 11:12:27 <clandmeter> its on alpine?
2019-11-26 11:12:38 <ahmedbilal> yep
2019-11-26 11:12:47 <clandmeter> weird
2019-11-26 11:12:57 <clandmeter> cat bin/ching | curl -F 'tpaste=<-' http://tpaste.us/
2019-11-26 11:13:19 <ahmedbilal> can't open bin/ching
2019-11-26 11:13:25 <clandmeter> heh
2019-11-26 11:13:34 <clandmeter> replace it with your apkbujild
2019-11-26 11:13:45 <clandmeter> cat ./APKBUILD |
2019-11-26 11:13:54 <clandmeter> or tpaste < ./APKBUILD
2019-11-26 11:14:27 <ahmedbilal> OOh. It is my vm that is having some issue. It is IPv6 only vm
2019-11-26 11:14:35 <clandmeter> ah ok
2019-11-26 11:15:32 <clandmeter> we dont have ipv6 for now
2019-11-26 11:15:35 <ahmedbilal> tpase is IPv4 only? X)
2019-11-26 11:15:35 <clandmeter> we plan to fix it
2019-11-26 11:16:08 <clandmeter> try http://sprunge.us/
2019-11-26 11:16:21 <clandmeter> anything that does not force these stupid adds
2019-11-26 11:17:07 <ahmedbilal> http://sprunge.us/vBQiMP
2019-11-26 11:17:18 <clandmeter> good
2019-11-26 11:17:22 <clandmeter> now a diff please :)
2019-11-26 11:18:02 <ahmedbilal> clandmeter: Sorry, http://sprunge.us/4C8eFH
2019-11-26 11:18:26 <clandmeter> what are those echos doing?
2019-11-26 11:18:56 <clandmeter> is --enable-rbd the official way to add it?
2019-11-26 11:19:12 <clandmeter> i mean its mentioned in configure --help
2019-11-26 11:19:33 <AinNero> nah, i wouldn't rely on that^^
2019-11-26 11:20:55 <ahmedbilal> yes
2019-11-26 11:21:14 <ahmedbilal> @clan
2019-11-26 11:21:20 <ahmedbilal> clandmeter:https://docs.ceph.com/docs/master/install/install-vm-cloud/#building-qemu
2019-11-26 11:22:24 <clandmeter> ok
2019-11-26 11:22:29 <clandmeter> so what happens if you build it?
2019-11-26 11:29:28 <ahmedbilal> @clandrados block device" "Install librbd/ceph devel
2019-11-26 11:29:35 <ahmedbilal> clandmeter: rados block device" "Install librbd/ceph devel
2019-11-26 11:35:16 <ahmedbilal> ERROR: User requested feature rados block device       configure was not able to find it.       Install librbd/ceph devel
2019-11-26 12:09:52 <ncopa> mps: do you have the 5.4 configs available somewhere?
2019-11-26 12:11:37 <mps> I can post WIP MR for x86_64 or to paste service
2019-11-26 12:12:10 <mps> btw, did you noticed linux-headers MR assigned to you
2019-11-26 12:13:32 <mps> later today I will work on aarch64 config changes
2019-11-26 12:17:52 <mps> ncopa: here is http://tpaste.us/QnWw
2019-11-26 12:18:28 <mps> this is WIP for x86_64 vanilla and virt
2019-11-26 12:25:47 <ahmedbilal> ncopa: Please guide me how can I add rbd support in qemu.
2019-11-26 13:09:32 <mps> can I disable MR to go to CI when creating one
2019-11-26 13:34:09 <ncopa> ahmedbilal: isnt there a compile time config option for that?
2019-11-26 13:34:26 <ncopa> mps: did you pick defaults when configuring it?
2019-11-26 13:35:10 <ahmedbilal> ncopa: There is and that is --enable-rbd. I put it but it says install librados/ceph devel. I install them but It couldn't be able to find their files.
2019-11-26 13:35:57 <ncopa> then you'd need to figure out exactly what the configure script is looking for
2019-11-26 13:36:02 <ncopa> and why it is not found
2019-11-26 13:36:44 <ahmedbilal> ncopa: Because, it isn't working
2019-11-26 13:37:30 <telmich> I am reading https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#depends to understand how to fix https://gitlab.alpinelinux.org/alpine/aports/issues/10985 but don't see any documentation on how to specify alternative dependencies
2019-11-26 13:37:40 <ncopa> unfortunately i dont have time to debug that right now
2019-11-26 13:37:41 <telmich> Does this not exist or is it documented elsewhere?
2019-11-26 13:37:58 <mps> ncopa: yes, mostly defaults to be able to build it, but I took whatever can from the current alpine configs
2019-11-26 13:38:19 <ncopa> telmich: we dont really support alternative deps
2019-11-26 13:38:35 <ncopa> telmich: but i think you can depend on cmd:emacs
2019-11-26 13:38:54 <mps> now I see it works quite fine, and will try to merge whatever can be merged from current configs
2019-11-26 13:39:23 <mps> and latter add new features, PSI, lockdown, pkcs8 etc
2019-11-26 13:39:24 <telmich> ncopa: ah, nice alternative, thanks!
2019-11-26 13:39:49 <ncopa> do we want PSI for virt kernel too?
2019-11-26 13:40:31 <mps> not sure, I wouldn't but if someone can tell reason for it I'm not against
2019-11-26 13:41:14 <mps> I think we have issue request or MR for it for virt
2019-11-26 13:41:58 <mps> now, I'm going to biz lunch so not have time to look
2019-11-26 13:43:02 <mps> and TSX should be considered, to not forget for it
2019-11-26 13:45:57 <ncopa> this is what listnewconfig gives: http://tpaste.us/Ky5B
2019-11-26 13:47:34 <mps> yes, not short list
2019-11-26 13:48:31 <ncopa> things like IO uring sounds interesting
2019-11-26 13:48:39 <mps> later today (at night) I will have time to look more, and tomorrow
2019-11-26 13:49:06 <mps> yes. io_uring is good and important addition
2019-11-26 13:50:23 <ncopa> exfat
2019-11-26 13:50:27 <telmich> Last time I tried to submit an MR, I forgot/did not know about the sha512sums string -- when does that need to be updated? On any any change to the APKBUILD or when the source files changes?
2019-11-26 13:50:52 <mps> exfat is not good candidate for inclusion, imo
2019-11-26 13:51:08 <ncopa> telmich: run abuild checksum before git commit
2019-11-26 13:51:39 <mps> we already have sdfat (which is better) and I read it will be included in a next (or next-next) kernel
2019-11-26 13:52:26 <qa3Txu0iak0F> how stable is py3.8 on edge, is it ok to upgrade a desktop?
2019-11-26 13:53:30 <telmich> ncopa: That seems to require root access for fetching the tar - is that correct?
2019-11-26 13:54:34 <telmich> no... I'm confused - running as a user, I get the error "mu: Fetching mu-1.2.tar.gz::https://github.com/djcb/mu/archive/1.2.tar.gz\n abuild-fetch: /var/cache/distfiles/mu-1.2.tar.gz.lock: Permission denied"
2019-11-26 13:54:50 <telmich> Running the same command as root gives the error ">>> ERROR: : Do not run abuild as root"
2019-11-26 13:55:13 <maxice8> qa3Txu0iak0F: it is working, i am using it here. There might be some packages that missed transition, would be nice if people reported those so they can be rebuilt
2019-11-26 13:55:19 <telmich> ok, I should probably be part of the abuild group
2019-11-26 14:02:20 <telmich> No sha512sum changes - submitting my 2nd merge request! *crossingfingers*
2019-11-26 15:01:40 <Cogitri> ncopa: Could you please also enable APPARMOR in the 5.4 kernel?
2019-11-26 15:01:49 <Cogitri> 
ACTION doesn't want to use the ML

2019-11-26 15:19:22 <ncopa> Cogitri: for both default kernel and virt?
2019-11-26 15:53:50 <ncopa> mps: do you have the generic armhf and armv7 configs?
2019-11-26 15:57:50 <maxice8> _ikke_: https://lists.alpinelinux.org/~alpine/aports/patches/3145 please set this one as applied
2019-11-26 15:58:13 <_ikke_> maxice8: done
2019-11-26 15:59:04 <maxice8> ty
2019-11-26 15:59:46 <Cogitri> ncopa: Dunno about virt, but defined for lts please
2019-11-26 16:26:22 <ddevault> having to be logged in as the alpine user to set patches as applied is dumb
2019-11-26 16:26:24 <ddevault> I'm gonna fix this
2019-11-26 16:30:31 <_ikke_> :)
2019-11-26 16:35:54 <ddevault> _ikke_: do you have a normal account?
2019-11-26 16:36:05 <_ikke_> I think so
2019-11-26 16:36:10 <ddevault> kdaudt?
2019-11-26 16:36:26 <_ikke_> yes
2019-11-26 16:36:29 <ddevault> cool
2019-11-26 16:36:43 <ddevault> you, me, clandmeter, and ncopa can now edit patchsets and remove spam when logged in as ourselves
2019-11-26 16:37:05 <ddevault> you can add more people by logging in as alpine and adding them to the ACL with moderate permissions
2019-11-26 16:37:12 <_ikke_> ok, sounds good
2019-11-26 16:40:35 <ncopa> question: does it makes sense to build an armv6 linux-lts kernel?
2019-11-26 16:40:44 <ncopa> i think the only supported armv6 is rpi1
2019-11-26 16:40:57 <clandmeter> i dont think it makes sense
2019-11-26 16:41:16 <ncopa> armv7 only for armhf then
2019-11-26 16:41:25 <ncopa> armv7 only for linux-lts then
2019-11-26 16:41:46 <ncopa> i think armv6 users build their own kernels
2019-11-26 16:42:55 <artok> I thought that pi1, zero, zero w, compute module would be armv6, rpi2, pi3, pi3+, pi4 would be armv7, and rpi3 and pi4 aarch64
2019-11-26 16:43:44 <clandmeter> pi needs pi kernel
2019-11-26 16:44:47 <artok> yeah, need to do that patch
2019-11-26 16:55:30 <ncopa> clandmeter: do we use any armv7/armhf qemu guests?
2019-11-26 16:55:39 <ncopa> 32 bit
2019-11-26 16:56:27 <qa3Txu0iak0F> maxice8: thx
2019-11-26 16:57:30 <maxice8> Not sure what for but you're welcome
2019-11-26 16:58:15 <qa3Txu0iak0F> answering my question.
2019-11-26 17:08:58 <PureTryOut[m]> Is Mitch Tishmack in this channel by any chance?
2019-11-26 17:15:08 <PureTryOut[m]> The s390x Gitlab runner is broken. It took 2 hours to pull in the proper Docker image https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/17596
2019-11-26 17:15:37 <_ikke_> PureTryOut[m]: Not sure if it's stuck on pulling the image
2019-11-26 17:15:42 <_ikke_> but not sure what is actually going on
2019-11-26 17:20:41 <_ikke_> PureTryOut[m]: can you try again?
2019-11-26 17:21:10 <rcampo> exit
2019-11-26 17:21:17 <_ikke_> /kick rcampo :)
2019-11-26 17:21:47 <rcampo> yup dont know how to use this yet
2019-11-26 17:21:58 <_ikke_> heh
2019-11-26 17:22:08 <_ikke_> /exit
2019-11-26 17:22:12 <PureTryOut[m]> Started it
2019-11-26 17:22:15 <_ikke_> k
2019-11-26 17:22:28 <rcampo> I cant kick myself
2019-11-26 17:22:45 <PureTryOut[m]> Type `/exit` into your client
2019-11-26 17:26:17 <_ikke_> PureTryOut[m]: I'm keeping an eye on the processes that are running
2019-11-26 17:26:57 <PureTryOut[m]> 👍️
2019-11-26 17:29:41 <_ikke_> running git clone on aports twice atm (for different jobs)
2019-11-26 17:31:08 <_ikke_> taking quite long ..
2019-11-26 17:32:40 <_ikke_> futex_wait
2019-11-26 17:33:10 <_ikke_> seems it's deadlocked
2019-11-26 17:46:08 <_ikke_> now index-pack segfaulted. I have the idea something fishing is going on on that server
2019-11-26 17:48:47 <_ikke_> tmhoang: if you have time, could you look at our gitlab ci s390x box? It seems git operations are flaky
2019-11-26 17:54:37 <tmhoang> _ikke_: how do you mean git operations ?
2019-11-26 17:54:58 <_ikke_> tmhoang: when a CI job tries to clone aports, it either seems to hang, or segfault
2019-11-26 17:55:06 <tmhoang> ok
2019-11-26 17:55:14 <_ikke_> if I do a strace on the busy process, it seems to hang on FUTEX_WAIT
2019-11-26 17:55:59 <_ikke_> futex(0x3ff9d8fdb60, FUTEX_WAIT_PRIVATE, 1, NULL
2019-11-26 18:02:04 <_ikke_> maxice8: I think your last commit for go-md2man contains an error, it complains about +r
2019-11-26 18:02:34 <maxice8> yes
2019-11-26 18:02:54 <maxice8> it is supposed to make the whole of src readable
2019-11-26 18:02:55 <maxice8> need chmod for that
2019-11-26 18:04:40 <_ikke_> shouldn't the go clean -modcache take care of that?
2019-11-26 18:05:18 <_ikke_> What I understood is that go on purpose makes the files read-only, but go clean -modcache should be able to handle that
2019-11-26 18:14:02 <maxice8> it doesn't
2019-11-26 18:34:57 <_ikke_> maxice8: https://git.alpinelinux.org/abuild/tree/abuild.in#n120
2019-11-26 18:39:41 <maxice8> _ikke_: Oh
2019-11-26 18:39:49 <maxice8> that is not documented
2019-11-26 18:40:01 <maxice8> or i don't remember it
2019-11-26 18:40:07 <_ikke_> It's 'fairly' new
2019-11-26 18:40:18 <_ikke_> couple of months
2019-11-26 18:40:44 <maxice8> Will be helpful on go packages
2019-11-26 18:45:45 <maxice8> documented
2019-11-26 18:47:53 <mps> ncopa: regarding armhf kernel, if we have armhf build we should keep armhf kernel, imo
2019-11-26 18:48:27 <mps> and we need to split armhf and armv7 kernels
2019-11-26 18:50:45 <mps> my main dilemma and what impedes me to work more on this is that I'm not sure do we want by default small kernels or we want to have feature-full ones
2019-11-26 18:52:54 <mps> personally I think alpine should make kernel with a lot of features by default, and let users to build specific tailored kernels for their use cases
2019-11-26 18:55:10 <mps> for arm32 kernels we should make multi platform kernels by default, one for armv6 SBC's and second for armv7 SBC's
2019-11-26 18:56:16 <ncopa> Linux localhost 5.4.0-0-lts #1-Alpine SMP Tue Nov 26 17:02:16 UTC 2019 x86_64 Linux
2019-11-26 18:56:24 <mps> ofc, these kernel couldn't work on all boards, but can on a lot popular of them
2019-11-26 18:56:39 <ncopa> what popular armv6 boards exists?
2019-11-26 18:56:42 <maxice8> ncopa: nice :D
2019-11-26 18:56:51 <ncopa> i thought that almost all popular are armv7
2019-11-26 18:57:03 <ncopa> and the only popular armv6 is rpi
2019-11-26 18:57:16 <mps> there are some user use around, maybe pmOS people can give better answer
2019-11-26 18:57:27 <ncopa> maxice8: i need update config for ppc64le and s390x
2019-11-26 18:57:52 <ncopa> mps: i have the impression that those users build their own kernel anyway
2019-11-26 18:57:58 <ncopa> to target their specific board
2019-11-26 18:58:04 <mps> yes
2019-11-26 18:58:55 <mps> but if we provide kernel for old boards we should try to have more of them supported by default
2019-11-26 18:59:26 <ncopa> im thinking that the only thing we need to support for armv6 is is rpi
2019-11-26 18:59:35 <ncopa> or let me put it this way
2019-11-26 18:59:51 <ncopa> lets build a more generic armv7 kernel first
2019-11-26 18:59:54 <mps> TBH, I don't have any armv6 board anymore
2019-11-26 19:00:12 <ncopa> and if someone asks for armv6 kernel we can reconsider
2019-11-26 19:00:16 <mps> I'm more for armv7 wide range support
2019-11-26 19:00:21 <ncopa> yeah
2019-11-26 19:00:28 <ncopa> thats what im saying
2019-11-26 19:00:36 <ncopa> lets build armv7 generic kernel
2019-11-26 19:00:42 <mps> at the and I'm not sure do we need armhf at all
2019-11-26 19:01:02 <ncopa> i dont think we need linux-lts for armv6
2019-11-26 19:01:10 <ncopa> rpi should be enough
2019-11-26 19:01:33 <mps> well, agree
2019-11-26 19:01:59 <ncopa> mps: do you have your kernel config for generic armv7?
2019-11-26 19:02:11 <ncopa> iirc you started look at it some time ago
2019-11-26 19:02:15 <mps> yes, for 4.19.x
2019-11-26 19:02:35 <mps> will post it to you in a half hour
2019-11-26 19:02:42 <ncopa> 👍
2019-11-26 19:02:56 <mps> I'm still outside home
2019-11-26 19:03:03 <ncopa> i'll config ppc64le and s390x meanwhile
2019-11-26 19:03:49 <mps> good, I don't know anything about these two 'specials'
2019-11-26 19:25:11 <mps> ncopa: here it is http://tpaste.us/vJZB
2019-11-26 19:25:23 <mps> this was for 3.10 alpine
2019-11-26 19:25:55 <mps> besides me some other users tested it, some give feedback but some didn't
2019-11-26 19:28:30 <ncopa> thanks!
2019-11-26 19:29:16 <mps> np
2019-11-26 19:30:05 <mps> tomorrow I will try to upgrade it to 5.4 and make aarch64 config multiplatform
2019-11-26 19:30:42 <ncopa> im gonna push testing/linux-lts today
2019-11-26 19:31:22 <ncopa> mps: do you have the raw config-vanilla.armv7 file?
2019-11-26 19:31:27 <ncopa> can you tpaste it?
2019-11-26 19:31:42 <ncopa> slightly easier than the patch
2019-11-26 19:31:45 <mps> one moment
2019-11-26 19:33:07 <mps> here http://tpaste.us/QnWO
2019-11-26 19:33:38 <maxice8> PureTryOut: is !1657 ok to merge ? it passed x86_64
2019-11-26 19:34:11 <mps> testing/linux-lts will be nice, base on which we can continue work :)
2019-11-26 19:34:31 <mps> waiting ....
2019-11-26 19:37:04 <mps> heh, someone asked in private mail to help him prepare presentation how to install alpine aarch64 under qemu
2019-11-26 19:37:38 <ncopa> testing/linux-lts is in the oven...
2019-11-26 19:48:50 <mps> ncopa: did you forgot 'abuild checksum'
2019-11-26 19:49:28 <maxice8> Can the docker image be regenerated every time abuild is updated ? it breaks dabuild
2019-11-26 19:50:25 <ncopa> mps: yup. indeed
2019-11-26 19:52:45 <mps> building armv7, impatient to test it on real SBC
2019-11-26 20:09:58 <oliv3r[m]> Hi, why and how are the /etc/apk keys generated with regards to the file name? THere is a unique component, (ssl key related), how is this used and how is this generated? abuild-sign for example doesn't appear to add this to the file ...
2019-11-26 20:12:09 <CICDC> Alpine deployments broke today, seem that "geos-dev" and "gdal-dev" packages were unexpectedly removed from the edge repo and into the community. This was not in any announcement that I received or can find, just _really_ annoying. How can this be prevented in the future?
2019-11-26 20:12:42 <_ikke_> oliv3r[m]: try tar tf <name>.apk | grep .SIGN
2019-11-26 20:12:47 <_ikke_> CICDC: packages are moved all the time
2019-11-26 20:12:58 <_ikke_> CICDC: edge is a branch, community a repo
2019-11-26 20:13:03 <_ikke_> CICDC: they are still in edge
2019-11-26 20:13:21 <CICDC> They are not in edge anymore
2019-11-26 20:13:27 <Cogitri> It was moved from testing to community so they're included in 3.12
2019-11-26 20:13:34 <_ikke_> 3.11 :)
2019-11-26 20:13:38 <ncopa> CICDC: the best thing to do is to get them out of testing
2019-11-26 20:13:56 <_ikke_> CICDC: https://pkgs.alpinelinux.org/package/edge/community/x86_64/geos-dev
2019-11-26 20:14:10 <_ikke_> Cogitri: how are you depending on them?
2019-11-26 20:14:13 <_ikke_> CICDC: *
2019-11-26 20:14:33 <oliv3r[m]> _ikke_: I know there's signature files inside of the apk files, and the filename of the signature relates to the public key to use to verify
2019-11-26 20:14:34 <Cogitri> s/3.12/3.11/
2019-11-26 20:14:34 <alpine-meetbot> Cogitri meant to say: It was moved from testing to community so they're included in 3.11
2019-11-26 20:14:34 <CICDC> right ok
2019-11-26 20:14:58 <oliv3r[m]> however, the signatures have a -<hash>.rsa.pub to them; so I'm curious where that came from
2019-11-26 20:15:08 <_ikke_> good question, I don't know myself
2019-11-26 20:15:58 <_ikke_> CICDC: so unless you are directly downloading it from the mirror, you should not even have been affected by this
2019-11-26 20:16:18 <ncopa> oliv3r[m]: the key is generated with abiuld-keygen
2019-11-26 20:16:40 <ncopa> _ikke_: it is not uncommon that people add a pinned repo @edge/testing
2019-11-26 20:16:46 <ncopa> and combine that with stable branch
2019-11-26 20:16:51 <_ikke_> nod
2019-11-26 20:17:01 <ncopa> that may or may not work
2019-11-26 20:17:12 <_ikke_> and may break at any time as well
2019-11-26 20:17:15 <CICDC> yes I was using edge/testing since this is where the version I needed was
2019-11-26 20:18:08 <_ikke_> CICDC: so them moving to community makes sure they are present in the next stable release
2019-11-26 20:18:13 <ncopa> edge is a rolling release and we reserve the right to break things there once in awhile
2019-11-26 20:18:13 <_ikke_> then you don't have to pin the repos anymore
2019-11-26 20:18:28 <ncopa> we probivide stable branches for thsoe who needs stability
2019-11-26 20:18:53 <CICDC> Yes, this is better. I'm updating our deployments, moving forward I will treat testing a more volatile than I had previously thought. Thanks!
2019-11-26 20:19:14 <ncopa> i think once 3.11 is available you can use that
2019-11-26 20:19:27 <ncopa> sorry for breaking your stuff...
2019-11-26 20:19:39 <oliv3r[m]> ncopa: ok i confused myself :) so we have keygen -> file-<hash>.rsa.pub; this is then used to generate the signature for packages and the APKINDEX.tar.gz file. However the APKINDEX.tar.gz gets renamed after being signed by abuild-sign at some point; I'm not seeing the rename
2019-11-26 20:21:07 <ncopa> oliv3r[m]: i think that happens in abuild, in the update_abuildrepo_index function
2019-11-26 20:22:18 <CICDC> I have tried latest-stable and 3.10 but these are only in edge. Will pin them there for now I guess.
2019-11-26 20:22:29 <_ikke_> yes, testing is only built for edge
2019-11-26 20:22:40 <_ikke_> so 3.11 will be the first stable release to contain them
2019-11-26 20:22:41 <oliv3r[m]> ok maybe some context is needed then; i want to create my own repo for a few packages, right now, I just use apk index <dir> to generate the index (and am adding the abuild-sign part to it. how should I involve abuild with this step?
2019-11-26 20:23:44 <oliv3r[m]> ncopa: btw update_abuildrepo_index function does just this:  mv APKINDEX.tar.gz.$$ APKINDEX.tar.gz
2019-11-26 20:26:18 <oliv3r[m]> (i did notice has an abuild index option as well, but that doesn't seem to do much more then apk index + abuild-sign)
2019-11-26 20:27:25 <CICDC> _ikke_, Thanks for the info! looking forward to that release!
2019-11-26 20:27:57 <oliv3r[m]> the only other thing I haven't figured out yet how abuild-tar fits into abuild-sign  and why that specifically is needed :) It looks like it's creating a tar.gz from the signature file, removes the header and then prepends it to the APKINDEX.tar.gz file (and I suppose the same goes for apk files)
2019-11-26 20:28:07 <_ikke_> CICDC: We're working hard atm to get that out the door
2019-11-26 20:31:03 <oliv3r[m]> ah! it's not some hash, it's printf "%x" $(date +%s)
2019-11-26 20:33:19 <oliv3r[m]> so I guess the only question I have left, is when/where APKINDEX.tar.gz gets renamed to APKINDEX-${hexdate}.tar.gz, as the date must be extracted from the key name
2019-11-26 21:13:01 <mps> heh, uname -a => 5.4.0-0-lts #1-Alpine SMP Tue, 26 Nov 2019 19:48:47 +0000 armv7l GNU/Linux
2019-11-26 21:13:19 <mps> on Allwinner A20 board
2019-11-26 21:13:24 <_ikke_> nice
2019-11-26 21:13:28 <maxice8> nice
2019-11-26 21:13:57 <mps> need some mkinitfs tweaks but works :)
2019-11-26 21:15:55 <mps> I think I can remove WIP from !1632
2019-11-26 21:16:33 <mps> but will left this to ncopa to decide
2019-11-26 21:23:56 <tmhoang> ncopa: are we upgrading to 5.x kernel for 3.11 ?
2019-11-26 21:24:03 <tmhoang> I doubt we want to do it
2019-11-26 21:25:22 <_ikke_> tmhoang: any reason not to? afaik the plans were there to do it
2019-11-26 21:25:42 <tmhoang> _ikke_ :( I thought we feature-freezed in Oct
2019-11-26 21:26:17 <tmhoang> I wanted to do the rust stuff but I was told we are already freezed
2019-11-26 21:27:44 <mps> tmhoang: I'm not sure, but think most things are 'frozen' but not kernel
2019-11-26 21:28:19 <tmhoang> reading the log, it seems it is in testing/linux-lts, not main/linux-vanilla
2019-11-26 21:28:36 <tmhoang> come on if kernel is not  the first one to be frozen, what else ?
2019-11-26 21:28:44 <mps> for long time we discussed to upgrade kernel and waited only for 5.4 LTS to be released
2019-11-26 21:29:07 <tmhoang> to my knowledge, kernel + musl + gcc are the first  3 things to be freezed
2019-11-26 21:29:17 <_ikke_> mostly the toolchain
2019-11-26 21:29:38 <_ikke_> ncopa said that before rc1 is released, the kernel can still be updated
2019-11-26 21:29:40 <mps> even we talked about kernel upgrade for 3.10 but didn't, because ncopa wants LTS
2019-11-26 21:30:04 <tmhoang> I'm not saying we should not upgrade main/linux-vanilla to 5.x because of the rust stuff, but because of common sense, just want to say it
2019-11-26 21:30:20 <mps> and, upgrading kernel will not break much things
2019-11-26 21:31:07 <tmhoang> I don't have a strong opinion about this, but I wouldn't say yes to. Be aware that 4.19 is also a LTS
2019-11-26 21:31:14 <mps> although agree, it's a pity not have rust on s390x
2019-11-26 21:31:32 <tmhoang> nah forget it, I don't have time neither :P
2019-11-26 21:32:08 <mps> heh
2019-11-26 21:42:01 <Cogitri> tmhoang: About that, I'll try to look into that soon, have been pretty busy lately, sorry about that
2019-11-26 21:42:35 <tmhoang> Cogitri: yeah me too ...
2019-11-26 21:42:38 <tmhoang> thanks
2019-11-26 21:45:13 <_ikke_> We are all busy :)
2019-11-26 21:45:20 <_ikke_> Any help is appreciated
2019-11-26 21:48:11 <Cogitri> Another thing, can we enable CONFIG_HIBERNATION in the new kernel?
2019-11-26 21:51:59 <mps> I'm for it
2019-11-26 21:52:17 <mps> for enable this*
2019-11-26 22:43:46 <maxice8> I'm getting total locks on 5.4 :D
2019-11-26 22:53:16 <mps> maxice8: x86_64?
2019-11-26 22:53:23 <maxice8> yeah
2019-11-26 22:54:52 <mps> hmm, just looked diff with my config for it and that which is in linux-lts and don't see much differences
2019-11-26 22:55:25 <maxice8> Just learned a lot of people grab stuff from edge and it breaks stuff :D
2019-11-26 22:56:02 <mps> hehe :)
2019-11-26 22:56:41 <mps> edge intentions is to break things
2019-11-26 22:58:00 <maxice8> sort of
2019-11-26 22:58:46 <maxice8> edge/main and edge/community i think it is nice to spend some effort to keep them from breaking gratuitously.
2019-11-26 22:59:08 <maxice8> the benefit is that once you get them branched for a new release they have a higher chance to be in a working state
2019-11-26 22:59:52 <maxice8> edge/testing yes, break as much as you need to get it in shape for community.
2019-11-26 23:00:04 <mps> yes, just upgrade one arm box and noticed it doesn't load modules
2019-11-26 23:00:14 <mps> upgraded*
2019-11-26 23:00:15 <maxice8> you mean
2019-11-26 23:00:19 <maxice8> you upgraded but didn't reboot ?
2019-11-26 23:00:48 <mps> it reboots but don't load kernel modules
2019-11-26 23:01:16 <mps> but I have serial console and 'rescue' kernel for such cases :)
2019-11-26 23:01:20 <maxice8> oh
2019-11-26 23:01:22 <maxice8> did you have your /boot partition mounted
2019-11-26 23:02:05 <mps> yes, manually restarting /etc/init.d/modules loaded them
2019-11-26 23:02:12 <maxice8> oh
2019-11-26 23:02:42 <mps> but not problem, will try again to reboot it
2019-11-26 23:06:14 <mps> fixed (by reboot it works fine)
2019-11-26 23:06:46 <mps> who told that windows advice about restarting is bad :D
2019-11-26 23:07:35 <maxice8> :D I used to have a much more annoying proglem
2019-11-26 23:07:41 <maxice8> Problem*
2019-11-26 23:07:47 <maxice8> I wouldn't have /boot mounted
2019-11-26 23:08:58 <mps> you don't keep rescue kernel?
2019-11-26 23:09:09 <maxice8> No
2019-11-26 23:09:21 <maxice8> I solved that but just always automounting /boot
2019-11-26 23:09:39 <mps> long time ago I learned this lecture
2019-11-26 23:37:07 <tmhoang> speaking of 5.x kernel I think https://build.alpinelinux.org/buildlogs/build-3-11-x86_64/community/stress-ng/stress-ng-0.10.06-r0.log should be fixed in 5.0+ . It seems this feature is not backported to 4.x
2019-11-26 23:38:19 <tmhoang> or we stick we stress-ng version 0.10.05 or so
2019-11-26 23:38:28 <tmhoang> *with
2019-11-27 07:12:02 <ncopa> morning
2019-11-27 07:13:20 <ncopa> tmhoang: we have discussed the 5.4 some time ago. we have not yet shipped any RC which means that we have not yet started to test the boot, install scripts etc
2019-11-27 07:13:38 <ncopa> but we are building the packages
2019-11-27 07:13:53 <ncopa> so if we do changes in compilers, we risk to need rebuild los of stuff
2019-11-27 07:18:12 <Cogitri> ncopa: Have you seen my message about CONFIG_HIBERNATE ?
2019-11-27 07:18:44 <Cogitri> s/NATE/NATION/
2019-11-27 07:18:44 <alpine-meetbot> Cogitri meant to say: ncopa: Have you seen my message about CONFIG_HIBERNATION ?
2019-11-27 07:21:25 <ncopa> Cogitri: i saw it but i'm skeptic
2019-11-27 07:21:38 <ncopa> what arches should have it nemabled?
2019-11-27 07:21:51 <ncopa> x86_64 and x86 only?
2019-11-27 07:22:53 <ncopa> i am also not that happy to store memory on disk. what happens with private keys in memory, etc?
2019-11-27 07:24:46 <Cogitri> If you care about that you have encrypted swap
2019-11-27 07:25:20 <Cogitri> I'd enable it on all arches - you can save some power by hibernation instead of "sleeping" in RAM
2019-11-27 07:25:37 <Cogitri> If you don't have enough swap/no swap you fall back to RAM anyway
2019-11-27 07:27:00 <ncopa> do we have time to test that it works before 3.11 release?
2019-11-27 07:27:24 <ncopa> i dont think it makes sense on s390x and maybe not on ppc64le
2019-11-27 07:27:34 <ncopa> to hibernate
2019-11-27 07:27:44 <ncopa> its a laptop thing
2019-11-27 07:31:31 <ncopa> if we were to chose: virtualbox kernel modules or hibernate, or generic arm kernel or rpi4 support?
2019-11-27 07:31:39 <ncopa> what is the priority order
2019-11-27 07:35:49 <ncopa> tmhoang: what is needed for getting rust work on s390x?
2019-11-27 07:42:08 <Cogitri> Well, it's not such a high priority, it's just something to take note of. I doubt it'll break anything since about every other distro has that enabled AFAICS, but I guess you nevwr know
2019-11-27 07:43:10 <Cogitri> About Rust on s390x:
2019-11-27 07:43:29 <Cogitri> 
ACTION uploaded an image: Screenshot_20191127-084254.jpg (684KB) < https://matrix.org/_matrix/media/r0/download/matrix.exqa.de/gQDNbfGBmxEyeKUBRUoMQqqD >

2019-11-27 07:43:42 <Cogitri> (Sorry for making it a screenshot, on phone)
2019-11-27 07:50:59 <tmhoang> ncopa: we need to bootstrap musl-rust-s390x from either musl-rust-x86 or glibc-rust-s390x
2019-11-27 07:51:28 <tmhoang> and yeah what's Cogitri said above
2019-11-27 07:52:17 <tmhoang> re: 5.x kernel, I don't have strong opinion, your call.
2019-11-27 08:20:23 <mps> enabling hibernation in kernel will not make any issue if it is not used, but could be useful for those who need it
2019-11-27 08:31:39 <mps> ncopa: 'generic arm kernel or rpi4 support?' are you ok with me making testing/linux-armv7-mp kernel?
2019-11-27 08:31:57 <maxice8> @ncopa can you take a look at !1662 ?
2019-11-27 08:40:40 <AinNero> huh
2019-11-27 10:13:56 <ncopa> mps: why not just update the armv7 config for linux-lts?
2019-11-27 10:22:56 <ncopa> mps: i ran a diff on the 4.19 kernel armhf and your armv7 config
2019-11-27 10:23:15 <ncopa> and tried to apply that patch on 5.4 kernel
2019-11-27 10:23:34 <ncopa> naturally there are various hunks that failed
2019-11-27 10:24:00 <ncopa> but there are still a few things that i dont understand
2019-11-27 10:24:21 <ncopa> for example:
2019-11-27 10:24:22 <ncopa> -CONFIG_CONSOLE_LOGLEVEL_QUIET=3
2019-11-27 10:24:22 <ncopa> +CONFIG_CONSOLE_LOGLEVEL_QUIET=4
2019-11-27 10:24:35 <ncopa> $ grep CONFIG_CONSOLE_LOGLEVEL_QUIET * | tpaste
2019-11-27 10:24:35 <ncopa> http://tpaste.us/onvM
2019-11-27 10:24:52 <ncopa> why should armv7 be different that all other architectures?
2019-11-27 10:26:06 <ncopa> $ grep CONFIG_STRIP_ASM_SYMS * | tpaste
2019-11-27 10:26:06 <ncopa> http://tpaste.us/jxNe
2019-11-27 10:26:26 <ncopa> why do we strip ASM syms on armv7 and not the other arches?
2019-11-27 10:47:24 <mps> on first question, I have impression that you are against multi platform kernel, which is big comparing to vanilla, about double size
2019-11-27 10:49:31 <mps> on different options enabled or changed, I took Arch and Debian armv7 mp kernel configs and tried to add/enable options from them to Alpine kernel
2019-11-27 10:51:09 <mps> and stripping ASM_SYMS doesn't made issue and I think kernels are smaller, maybe faster but didn't benchmarked (only have this 'feel' from working with them)
2019-11-27 10:55:46 <mps> current armv7 lts doesn't have reboot and powerdown enabled for most arch'es, usb doesn't work for sunxi/allwinner
2019-11-27 10:56:06 <mps> poweroff*
2019-11-27 10:56:59 <mps> didn't yet tried on exynos
2019-11-27 10:58:31 <ncopa> ok
2019-11-27 10:59:04 <mps> and yes, I know build multi platform kernel need time and testing a lot, not so easy and fast task
2019-11-27 10:59:14 <ncopa> this is what i ended up with when merging it: http://tpaste.us/Bjgo
2019-11-27 10:59:28 <ncopa> what platforms are we able to test?
2019-11-27 10:59:46 <ncopa> i have a wandboard
2019-11-27 10:59:54 <ncopa> so i can test that
2019-11-27 11:00:19 <mps> now I left only with allwinner A10 and A20 and exynos
2019-11-27 11:00:43 <ncopa> maybe pmOS ppl can help us test?
2019-11-27 11:01:05 <ncopa> where are the arch linux kernels for armv7?
2019-11-27 11:01:29 <mps> that would be nice, and we can ask on #alpine-linux if someone have other boards and willing to help
2019-11-27 11:01:41 <ncopa> this one seem to be x86_64 only: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux
2019-11-27 11:02:31 <mps> moment please
2019-11-27 11:03:17 <mps> git remote -v => origin  https://github.com/archlinuxarm/PKGBUILDs.git (fetch)
2019-11-27 11:03:48 <mps> there is core/linux-armv7
2019-11-27 11:03:58 <mps> and core/linux-armv7-rc
2019-11-27 11:06:25 <ncopa> yeah, i guess those are the ones we may be interested in
2019-11-27 11:06:28 <ncopa> and the aarch64
2019-11-27 11:07:15 <mps> yes, I'm looking on their aarch64 for some time
2019-11-27 11:07:18 <ncopa> ok, i think i'll push what i currently have, and we can start test
2019-11-27 11:07:56 <ncopa> i have a problem with the s390x kernel though
2019-11-27 11:08:05 <ncopa> ERROR: "xt_unregister_target" [/home/ncopa/aports/testing/xtables-addons-lts/src/xtables-addons-3.6/extensions/ACCOUNT/x
2019-11-27 11:08:05 <ncopa> t_ACCOUNT.ko] undefined!
2019-11-27 11:08:07 <mps> Arch aarch64 helped me to run flawlessly alpine on chromebooks
2019-11-27 11:09:40 <mps> push what you think is ok and I will test and after that make patches
2019-11-27 11:12:31 <kaey> there is a bug which affect go (and possibly other soft) in latest kernel https://bugzilla.kernel.org/show_bug.cgi?id=205663
2019-11-27 11:19:47 <clandmeter> 5.2+
2019-11-27 11:24:48 <mps> kaey: what is expected 'result' of this test.c
2019-11-27 11:25:09 <mps> crash or something else?
2019-11-27 11:25:36 <kaey> Expected result: No register corruption, in which case it will exit successfully after one minute.
2019-11-27 11:26:04 <mps> one minute, I was impatient then :)
2019-11-27 11:27:57 <mps> ok, not took full minute: time ./a.out => 0.000u 0.003s 1:00.01 0.0%      0+0k 0+0io 0pf+0w
2019-11-27 11:28:27 <mps> no issue on alpine, 5.4 kernel and gcc 9.2
2019-11-27 11:32:39 <kaey> was kernel compiled with gcc 9?
2019-11-27 11:32:47 <ncopa> yes
2019-11-27 11:33:01 <kaey> reproduced instantly on archlinux
2019-11-27 11:34:45 <ncopa> input  = 01 44 00 00 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
2019-11-27 11:34:45 <ncopa> output = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-11-27 11:34:45 <ncopa> mismatch
2019-11-27 11:34:45 <ncopa> child process failed
2019-11-27 11:35:30 <kaey> yeah thats it
2019-11-27 11:35:58 <kaey> also reproduces instantly in alpine edge chroot wit harch kernel 5.3.11
2019-11-27 11:38:27 <mps> libc related?
2019-11-27 11:39:07 <ncopa> unlikely libc related
2019-11-27 11:39:57 <mps> ask dalias
2019-11-27 11:39:59 <kaey> i tried in chroot to root out libc, it fails in both so it's not libc
2019-11-27 11:41:04 <mps> it must be something in userspace and not kernel
2019-11-27 11:41:55 <clandmeter> https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.2-Go-Register-Corrupt
2019-11-27 11:42:09 <clandmeter> maybe this link makes it more clear
2019-11-27 11:42:46 <mps> pthread implementation
2019-11-27 11:43:45 <mps> tested on '5.4.0-0-vanilla #1-Alpine SMP Mon Nov 25 23:25:42 CET 2019 x86_64 GNU/Linux'
2019-11-27 11:44:05 <mps> gcc (Alpine 9.2.0) 9.2.0
2019-11-27 12:16:03 <ncopa> Cogitri: I enabled hibernation. apparently we had it enabled on most of the other arches
2019-11-27 12:31:53 <maxice8> @mps don't you use lxd/lxc ?
2019-11-27 12:32:50 <mps> maxice8: I use lxc for containers
2019-11-27 12:32:56 <mps> not lxd
2019-11-27 12:34:35 <north1> but lxc
2019-11-27 12:36:30 <north1> @mps can you test the dropping of the xz dependency ? on !1679
2019-11-27 12:36:47 <_ikke_> north1: isn't this you old nick?
2019-11-27 12:37:07 <north1> yes north1 <-> maxice8 <-> leo
2019-11-27 12:37:14 <north1> my irc account is just so old it is north1
2019-11-27 12:37:21 <mps> oh, I wondered
2019-11-27 12:38:24 <mps> maxice8: north1: Leo: will test it later
2019-11-27 12:38:36 <north1> ty
2019-11-27 12:52:37 <ncopa> something is weird with Modules.symvers on the s390x kernel
2019-11-27 13:04:46 <ahmedbilal> Hi, I was able to build QEMU with rbd with this https://ilet.to/5DBv patch.
2019-11-27 13:05:22 <ahmedbilal> ncopa: Do you have anything against moving QEMU to `community` repo
2019-11-27 13:31:16 <mps> maxice8: build of lxc works
2019-11-27 13:31:44 <mps> you want test if it works without xz apk?
2019-11-27 13:32:11 <mps> (and wonder, btw, why lxc depends on linux-pam)
2019-11-27 13:33:09 <mps> if xz applet is added to busybox why busybox then doesn't provides 'xz'
2019-11-27 13:39:20 <ncopa> ahmedbilal: i guess it depends on if we want support it for 2 years or 6 months
2019-11-27 13:39:31 <ncopa> seems like there are nothing in main that depends on qemu now
2019-11-27 13:39:58 <ahmedbilal> ncopa: So, should I go ahead.
2019-11-27 13:40:15 <ncopa> maybe we should also move libvirt to 6 month support, since it makes no sense support libvirt without qemu
2019-11-27 13:40:38 <ncopa> or, well, maybe it does. we still have long term support for xen
2019-11-27 13:41:02 <ahmedbilal> ncopa: I am not sure about 6 month support vs 2 year. Is it related to repos somehow?
2019-11-27 13:41:06 <ncopa> yes
2019-11-27 13:41:18 <ncopa> we maintain main for two years and community only latest stable
2019-11-27 13:41:44 <ahmedbilal> By maintaining what do you mean?
2019-11-27 13:42:00 <ncopa> monitor, report and fix security issues
2019-11-27 13:42:09 <ahmedbilal> aah.
2019-11-27 13:42:43 <mps> I don't think that moving qemu,xen to community is good idea
2019-11-27 13:42:52 <ncopa> it saves us for work
2019-11-27 13:43:11 <mps> then we can move everything :)
2019-11-27 13:43:11 <ncopa> we dont need fix sec issues more than 6 months
2019-11-27 13:43:48 <ncopa> but yeah, the question is if qemu is a thing we want support long term or not
2019-11-27 13:43:56 <mps> we always have to balance how much have to work and LTS alpine
2019-11-27 13:44:35 <ncopa> qemu has not given us much maintenance work, so I dont mind keep it in main
2019-11-27 13:44:51 <mps> I'm more for moving less important pkgs from main, example weechat, irssi and similar
2019-11-27 13:45:14 <_ikke_> qemu has received 3 commits in total on stable branches since 3.7
2019-11-27 13:45:14 <ahmedbilal> My main purpose is to but support for rbd in QEMU package.
2019-11-27 13:45:23 <mps> bluez is good candidate for moving from main
2019-11-27 13:45:44 <_ikke_> https://tpaste.us/pKln
2019-11-27 13:46:09 <ahmedbilal> If we can put it another way, i will prefer that without moving things here and there
2019-11-27 13:47:25 <mps> _ikke_: is it possible to run nested lxc, lxc in lxc
2019-11-27 13:48:13 <_ikke_> I'm not certain, but I guess it would involve privileged containers
2019-11-27 13:48:39 <clandmeter> moving ceph in main is probably not what we want
2019-11-27 13:49:17 <clandmeter> s/in/to
2019-11-27 13:49:17 <alpine-meetbot> clandmeter meant to say: movtog ceph in main is probably not what we want
2019-11-27 13:49:35 <clandmeter> nice
2019-11-27 13:49:43 <mps> _ikke_: yes, or pass all needed devices to 'base' LC
2019-11-27 13:49:48 <mps> lxc*
2019-11-27 13:50:44 <ahmedbilal> clandmeter: So, we stuck building QEMU with patch to support rbd?
2019-11-27 13:53:10 <clandmeter> ncopa: you are the maintainer, can you decide?
2019-11-27 13:55:27 <ncopa> i guess the question is what we want prioritize: rbd support or long term support
2019-11-27 13:55:55 <_ikke_> qemu did not receive a lot of long term support
2019-11-27 13:55:58 <clandmeter> well qemu has multiple plugins we have not enabled
2019-11-27 13:56:12 <clandmeter> in main it will always be an issue\
2019-11-27 13:57:29 <mps> maxice8: I tested build of lxc with xz removed but don't have any box where I can test if it really works
2019-11-27 13:58:10 <mps> I could do that later at night, don't have time right now
2019-11-27 13:59:39 <north1> it is used in the lxc-download subpkg
2019-11-27 14:00:02 <ncopa> let me think what to do with qemu. i want fix this 5.4 kernel first
2019-11-27 14:00:49 <ncopa> weird. make modules_install messes up Module.symvers on s390x
2019-11-27 14:00:53 <ncopa> but only on s390x
2019-11-27 14:03:24 <mps> north1: yes, I saw it, but wanted to test does it really works with bb xz
2019-11-27 14:04:09 <mps> maybe lxc could work in chroot (: ?
2019-11-27 14:04:29 <mps> or fire qemu
2019-11-27 14:22:16 <mps> north1: started it in qemu, looks like it works :)
2019-11-27 15:25:10 <north1> ty
2019-11-27 15:32:47 <mps> linux-lts doesn't load usb to sata disk drivers
2019-11-27 15:33:03 <mps> north1: np
2019-11-27 15:54:45 <mps> !771 could be closed
2019-11-27 15:55:25 <mps> also, !1498
2019-11-27 15:57:31 <mps> !862, !863 and !822
2019-11-27 15:58:00 <mps> these three doesn't work
2019-11-27 16:13:57 <PureTryOut[m]> So `ghc` includes a lot of Haskell modules already. They can be packaged separately, but since they're built already anyway, wouldn't it be worth splitting them out of `ghc` instead? Things like `haskell-base`
2019-11-27 16:14:02 <PureTryOut[m]> I
2019-11-27 16:14:32 <PureTryOut[m]>  * I'm not sure if a subpackage can have a different version than the main package? That might be a problem otherwise with that approach
2019-11-27 16:14:54 <_ikke_> No, they can't afaik
2019-11-27 18:59:16 <kaniini> btw
2019-11-27 18:59:29 <kaniini> http://distfiles.dereferenced.org/alpine-mips64
2019-11-28 07:55:51 <north1> _ikke_ : doing the grafana update from ddevault
2019-11-28 07:56:22 <_ikke_> north1: (y)
2019-11-28 07:56:38 <_ikke_> I put the prometheus commits through gitlab-ci
2019-11-28 09:54:18 <clandmeter> ncopa: seems there is a patch for that kernel issue from yesterday: https://lkml.org/lkml/2019/11/27/304
2019-11-28 10:12:44 <mps> yes, saw it and read thread about it
2019-11-28 10:13:38 <mps> iiuc, it is related to CONFIG_PREEMPT option
2019-11-28 10:14:29 <mps> and current option in alpine is '# CONFIG_PREEMPT is not set'
2019-11-28 11:12:39 <ncopa> morning
2019-11-28 11:12:45 <ncopa> or good day
2019-11-28 11:13:06 <north1> Morning
2019-11-28 11:14:24 <Cogitri> Morning
2019-11-28 11:22:28 <_ikke_> hi
2019-11-28 11:25:16 <ncopa> im backporting that kernel fix
2019-11-28 11:25:53 <ncopa> i'd also like to have a look at a busybox regression: https://gitlab.alpinelinux.org/alpine/aports/issues/5703#note_55898
2019-11-28 11:26:50 <ncopa> all the 3.11 builders are "failed" are there any of those that you need me to take care of?
2019-11-28 11:28:17 <ncopa> i think i've fixed the s390x' wireguard issue
2019-11-28 11:28:29 <_ikke_> I can fix the apenwarr-redo failure
2019-11-28 11:28:36 <ncopa> thanks
2019-11-28 11:28:47 <_ikke_> llvm5 has failing tests
2019-11-28 11:29:24 <ncopa> do we still need llvm5?
2019-11-28 11:30:05 <ncopa> yeah, for ghc
2019-11-28 11:30:32 <_ikke_> ah, I don't see a direct dependency on it
2019-11-28 11:33:24 <mps> and for crystal, llvm5
2019-11-28 12:05:53 <ncopa> clandmeter: i think we have an issue with domoticz. i found an upstream patch for python 3.8, but it seems like it does not build against openzwave 1.6
2019-11-28 12:06:42 <ncopa> 57a020175603249ce882c82a1a48079cca391bb8
2019-11-28 12:10:34 <ncopa> ah, i found a patch
2019-11-28 12:10:52 <ncopa> which (almost) applies https://github.com/domoticz/domoticz/commit/56d3fa099d9c98222d6cf5043891c6ba2f1df6bf
2019-11-28 12:19:37 <clandmeter> ncopa: im not using it anymore so if its too much trouble..
2019-11-28 12:22:56 <mps> is 'Zlib' correct SPDX licence, i.e. not need to be added as text file to pkg
2019-11-28 12:23:14 <north1> yes
2019-11-28 12:23:25 <north1> https://spdx.org/licenses/Zlib.html
2019-11-28 12:23:37 <mps> north1: thanks
2019-11-28 13:12:32 <ncopa> meh... i forgot the push the linux-lts fix for  s390x
2019-11-28 13:12:54 <mps> north1: what you did with iproute2?
2019-11-28 13:13:16 <north1> updated
2019-11-28 13:13:48 <mps> uh, I put WIP because it needs to be built with linux-headers 5.4
2019-11-28 13:14:21 <ncopa> im not sure we want push linux-headers 5.4 at this point
2019-11-28 13:15:30 <mps> if you push linux 5.4 than you should push linux-headers also
2019-11-28 13:15:30 <ncopa> not necessarily
2019-11-28 13:15:30 <ncopa> linux is ABI backwards compatible
2019-11-28 13:15:39 <ncopa> to all binaries built with linux-headers 4.19 will run
2019-11-28 13:15:40 <mps> iproute, ethtool, iwd and some other pkgs use some API from new kernel headers
2019-11-28 13:16:13 <mps> yes, not necessarily but would be good, imo
2019-11-28 13:16:28 <mps> API/ABI
2019-11-28 13:16:44 <ncopa> im afraid it will break builds of packages with linux-headers in makedepends
2019-11-28 13:17:00 <ncopa> and i am not keen on rebuilding world again at this point
2019-11-28 13:17:33 <mps> ah, so main and community will not be rebuilt for 3.11 again?
2019-11-28 13:17:40 <ncopa> no
2019-11-28 13:17:45 <ncopa> the builders are up
2019-11-28 13:17:47 <mps> now understand
2019-11-28 13:18:12 <mps> ok, what we can do then /o\
2019-11-28 13:18:30 <ncopa> however, i dont mind that someone updates linux headers locally, and test build everythign with linux-headers in makedepends
2019-11-28 13:18:49 <mps> uhm :)
2019-11-28 13:19:47 <ncopa> ncopa-edge-x86 [~/aports/main]$ grep -w linux-headers */APKBUILD | wc -l
2019-11-28 13:19:47 <ncopa> 254
2019-11-28 13:20:30 <ncopa> community has 157
2019-11-28 13:20:45 <ncopa> so 300-400 packages
2019-11-28 13:20:54 <mps> not much in total: 592 in my coubt
2019-11-28 13:21:05 <mps> count*
2019-11-28 13:22:13 <ncopa> other option
2019-11-28 13:22:36 <ncopa> we add a new package named linux-headers5.4
2019-11-28 13:22:47 <mps> no, if it is late then it is late
2019-11-28 13:23:00 <ncopa> and rebuild only those packages that actually needs 5.4
2019-11-28 13:23:04 <mps> left it for next release
2019-11-28 13:23:12 <ncopa> yeah, i think thats better
2019-11-28 13:23:28 <ncopa> lets fix the current build issues insead
2019-11-28 13:23:32 <ncopa> like llvm5
2019-11-28 13:23:36 <mps> agree
2019-11-28 13:24:00 <_ikke_> patchwork is failing already for quite some time as well
2019-11-28 13:24:17 <mps> I wrongly thought that the 3.11 will be built again from the beginning
2019-11-28 13:24:58 <ncopa> i have a fix for domoticz
2019-11-28 13:25:06 <ncopa> which depend on the abuild fix i just pushed
2019-11-28 13:25:36 <mps> so, now concentrate on bugs not new things/features
2019-11-28 13:25:48 <_ikke_> yes, that's the idea
2019-11-28 13:25:54 <_ikke_> try to get 3.11 stable :)
2019-11-28 13:26:00 <ncopa> +1
2019-11-28 13:26:04 <mps> _ikke_: yes, Sr :)
2019-11-28 13:26:43 <ncopa> the sonner we get 3.11 out the sooner we can go back to add new features
2019-11-28 13:51:14 <mps> llvm5 segfaults few times durring check() on x86_64 builder
2019-11-28 15:08:40 <mps> PureTryOut[m]: forgot to tell you, I tried few days ago to build firefix with libpulse but it fails and I didn't had time to look can it be fixed now
2019-11-28 15:08:53 <mps> !1051
2019-11-28 15:10:44 <Cogitri> Hooray, does the matrix bridge work again?
2019-11-28 15:21:07 <ncopa> jirutka[m]: do you think you could have a look at postgresql-pglogical?
2019-11-28 15:21:26 <ncopa> needs porting to recent postgresql
2019-11-28 15:23:17 <PICCORO> hi all new CVE 2019-18276 for bash .
2019-11-28 15:24:00 <maxice8> Cogitri: Nope
2019-11-28 15:54:58 <PureTryOut[m]> mps: Which Firefox? -esr or normal?
2019-11-28 15:55:14 <mps> testing/firefox
2019-11-28 15:55:29 <mps> normal :D
2019-11-28 15:56:35 <ncopa> looks like python ecosystem is removing the setup.py
2019-11-28 15:56:40 <ncopa> requiring pip install
2019-11-28 15:56:43 <ncopa> https://www.python.org/dev/peps/pep-0517/
2019-11-28 15:57:28 <Cogitri> <ncopa "looks like python ecosystem is r"> Time to remove python :P
2019-11-28 15:58:26 <mps> Cogitri: +1
2019-11-28 15:58:29 <ncopa> ansible-lint already implemented it
2019-11-28 16:01:56 <Cogitri> Ugh, language package managers are such a pain
2019-11-28 16:02:10 <Cogitri> My main pain point with Rust too
2019-11-28 16:02:11 <ncopa> i wonder what the intention is
2019-11-28 16:02:32 <ncopa> it seems like they think the entire univers is only their language
2019-11-28 16:02:44 <ncopa> and if it isnt, they think it should be
2019-11-28 16:02:50 <mps> ncopa: you took my words
2019-11-28 16:03:06 <mps> just wanted to wrote this
2019-11-28 16:03:29 <ncopa> "you shouldn't use C! use <go/rust/python/ruby/whatever>"
2019-11-28 16:03:45 <mps> :)
2019-11-28 16:06:23 <TBB> now, there's an ultra cynical viewpoint and a cynical viewpoint to this
2019-11-28 16:08:16 <TBB> but I'm already out of office for the day so to Heck with cynicism...
2019-11-28 16:11:05 <mps> to late for tmux 3.0 to go to 3.11
2019-11-28 16:11:26 <Cogitri> ncopa: Their intention is making development nicer
2019-11-28 16:11:33 <Cogitri> Which I don't doubt this change does
2019-11-28 16:11:47 <Cogitri> But distro packaging is rarely a priority in these things
2019-11-28 16:12:52 <clandmeter> rm -rf aports/*/py*
2019-11-28 16:13:24 <Cogitri> Most devs aren't distro packagers :)
2019-11-28 16:13:44 <mps> Cogitri: I'm more with ncopa opinion, about people thinks that the universe is their
2019-11-28 16:14:19 <Cogitri> Heh
2019-11-28 16:14:24 <ncopa> and if it isnt, it should be
2019-11-28 16:14:36 <ncopa> i think its a general tendency in that directio
2019-11-28 16:15:36 <ncopa> mps: i dont mind to push tmux-3.0, but it needs fixing, and report upstream
2019-11-28 16:15:39 <Cogitri> Yeah :c
2019-11-28 16:15:45 <ncopa> regsub.c:83:39: error: 'REG_STARTEND' undeclared (first use in this function); did you mean 'TTY_STARTED'?
2019-11-28 16:15:45 <ncopa>    83 |   if (regexec(&r, text, nitems(m), m, REG_STARTEND) != 0) {
2019-11-28 16:15:50 <Cogitri> About your email: does `pip install --prefix=/usr` not work?
2019-11-28 16:16:06 <ncopa> we need to do it in two steps
2019-11-28 16:16:13 <ncopa> we need build as non-root
2019-11-28 16:16:22 <ncopa> and run install in fakeroot
2019-11-28 16:16:40 <ncopa> also, will pip install also install all the dependencies or not?
2019-11-28 16:16:44 <Cogitri> Err, I mean pip install --prefix=$pkgdir/usr
2019-11-28 16:16:53 <Cogitri> Dunno, I barely ever use python (luckily)
2019-11-28 16:18:04 <ncopa> i dont want fight python devs
2019-11-28 16:18:18 <ncopa> if they dont want us to package their stuff, we wont
2019-11-28 16:18:32 <Cogitri> Sounds good
2019-11-28 16:18:45 <ncopa> and we send user support in their direction
2019-11-28 16:21:11 <mps> OT, I've seen in last decade or two rise in popularity of theories about paralel/multiple worlds/universes. Could this be related to so much rise in langs and their pkg managers
2019-11-28 16:21:30 <Cogitri> Also, I talked to the conan (C/C++ package manager) guys about distro packaging on the Meeting C++ and they basically shrugged it off
2019-11-28 16:21:55 <Cogitri> So yea, let's hope that Conan won't be adopted for release tarballs :P
2019-11-28 16:24:32 <north1> pip has --no-dependencies from what i can find
2019-11-28 16:26:24 <north1> pip --root=$pkgdir --prefix=/usr --no-deps
2019-11-28 16:35:37 <ncopa> mps: re tmux 3.0 https://github.com/tmux/tmux/issues/1994
2019-11-28 16:37:18 <mps> thanks, I see
2019-11-28 16:37:55 <mps> would you do the job or ... I?
2019-11-28 16:39:33 <ncopa> im on it
2019-11-28 16:39:47 <mps> ok, thanks again
2019-11-28 16:43:42 <mps> I pushed iwd upgrade few minutes ago and it is already in edge mirrors, but did it go automatically also to 3.11 builders and mirrors
2019-11-28 16:44:49 <mps> sorry, am I lazy to look ;)
2019-11-28 16:46:12 <mps> ah, 3.11 only have main dir, http://dl-cdn.alpinelinux.org/alpine/v3.11/
2019-11-28 16:51:22 <_ikke_> community still needs to be uploaded
2019-11-28 16:51:36 <_ikke_> that happens only after the last package is succesfully built
2019-11-28 16:53:14 <mps> ok, good to know
2019-11-28 17:20:20 <mps> wiringpi fails because source is 'out', git.drogon.net is temporarily unavailable. Please look for alternatives for wiringPi, etc. -Gordon
2019-11-28 19:21:07 <_ikke_> anyone remotely has a clue why xmltv is failing? I see some tests are failing (and I can repro it), but I have no idea what/why
2019-11-28 19:21:28 <_ikke_> 1/14 blib/script/tv_imdb --quiet --imdbdir '/tmp/Ru4POJEfEb' --with-keywords --with-plot < t/data-tv_imdb/Movie1-case-insensitive.xml > '/tmp/Ru4POJEfEb/Movie1-case-insensitive.xml-output.xml' 2>&1 failed: 2, 0, 0
2019-11-28 19:26:31 <mps> I looked but didn't yet tried to look at test files
2019-11-28 19:27:00 <_ikke_> I looked at one of the files
2019-11-28 19:27:14 <mps> it moans about some old deps files
2019-11-28 19:27:30 <_ikke_> Not sure, but maybe this has to do with it as well: https://github.com/XMLTV/xmltv/issues/17
2019-11-28 19:27:48 <mps> but I was so tired sitting and wen out for some time
2019-11-28 19:28:07 <_ikke_> I can imagine
2019-11-28 19:28:11 <mps> s/wen/went/
2019-11-28 19:28:11 <alpine-meetbot> mps meant to say: but I was so tired sitting and went out for some time
2019-11-28 19:29:24 <mps> btw, for wiringpi we should find source url, original doesn't work
2019-11-28 19:33:36 <_ikke_> hmm, strange, cannot find it cached on the builders
2019-11-28 19:35:08 <mps> when I come back will look in debian archive
2019-11-28 19:35:29 <_ikke_> https://github.com/WiringPi/WiringPi ?
2019-11-28 19:35:29 <mps> they usually keep such thing for long time
2019-11-28 19:36:01 <mps> 0 releases
2019-11-28 19:36:11 <_ikke_> they don't have tags
2019-11-28 19:36:18 <_ikke_> but you can still get a tarball
2019-11-28 19:36:20 <mps> I mean, on their GH
2019-11-28 19:36:32 <_ikke_> yes
2019-11-28 19:36:34 <mps> yes, but not proper version
2019-11-28 19:36:42 <_ikke_> The original did not use one either
2019-11-28 19:36:45 <_ikke_> https://git.drogon.net/?p=wiringPi;a=snapshot;h=$_commitid;sf=tgz
2019-11-28 19:37:02 <mps> ah, true
2019-11-28 19:37:20 <mps> forgot about that :)
2019-11-28 19:38:04 <_ikke_> https://github.com/WiringPi/WiringPi/archive/8d188fa.zip
2019-11-28 19:38:09 <_ikke_> I think that would work
2019-11-28 19:39:23 <mps> I think it will
2019-11-28 19:39:41 <mps> but you can use tar.gz instead of zip, iirc
2019-11-28 19:39:45 <_ikke_> yes
2019-11-28 19:39:50 <_ikke_> I copied that from the gh interface
2019-11-28 19:40:32 <mps> I did _gitcommit for some things, but forgot which ones
2019-11-28 19:40:34 <_ikke_> +source="wiringpi-$pkgver.tar.gz::https://github.com/WiringPi/WiringPi/archive/$_commitid.tar.gz
2019-11-28 19:40:43 <_ikke_> :-)
2019-11-28 19:40:46 <mps> yes!
2019-11-28 19:41:07 <_ikke_> but it only builds on arm
2019-11-28 19:41:25 <mps> it is for arm only
2019-11-28 19:41:31 <_ikke_> understood :)(
2019-11-28 19:41:44 <mps> RPI3 and/or RPI2
2019-11-28 19:41:46 <_ikke_> I meant that it means I cannot build it locally
2019-11-28 19:41:59 <mps> RPI4 has new one
2019-11-28 19:42:30 <mps> post it to me and I will when come back to home
2019-11-28 19:42:42 <_ikke_> I'll push it to gitlab and let it handle it :)
2019-11-28 19:42:53 <mps> good
2019-11-28 19:43:55 <mps> btw, I made locally wiringBP for bananapi (leemaker) boards
2019-11-28 19:44:25 <_ikke_> anoying new sudo error: sudo: setrlimit(RLIMIT_CORE): Operation not permitted
2019-11-28 19:44:48 <mps> and there is wiringX which tries to be cross board wiring lib
2019-11-28 19:45:15 <mps> I've seen it two or three days ago
2019-11-28 19:45:33 <mps> sudo setrlimit, I mean
2019-11-28 19:45:49 <mps> on aarch64 and armv7 lxc
2019-11-28 19:48:34 <_ikke_> pushed it now
2019-11-28 19:50:20 <mps> unrecognized format
2019-11-28 19:50:30 <_ikke_> ugh, it built on ci :-/
2019-11-28 19:51:02 <_ikke_> interesting
2019-11-28 19:51:07 <_ikke_> it's pigz that has an issue
2019-11-28 19:51:37 <mps> no, not found
2019-11-28 19:51:53 <mps> wget https://distfiles.alpinelinux.org/distfiles/v3.11/wiringpi-2.46.tar.gz
2019-11-28 19:52:03 <_ikke_> hmm
2019-11-28 19:52:05 <mps>  ERROR 404: Not Found
2019-11-28 20:18:41 <_ikke_> vault apparently is depening on node v10 and we already have a newer version :(
2019-11-28 20:18:45 <_ikke_> depending*
2019-11-28 20:18:59 <_ikke_> 1.3.0 added a hard dependency check
2019-11-28 20:19:04 <_ikke_> https://github.com/hashicorp/vault/issues/7232
2019-11-28 20:22:09 <mps> so, using _commitid works for some pkgs but not for all
2019-11-28 20:22:52 <_ikke_> What do you mean?
2019-11-28 20:23:17 <mps> https://github.com/raspberrypi/userland/archive/ff2bd4552145e8dc190276d8fbdbadc7e8e0da78.tar.gz
2019-11-28 20:23:21 <mps> works
2019-11-28 20:23:54 <mps> wget https://github.com/WiringPi/WiringPi/commit/093e0a17a40e064260c1f3233b1ccdf7e4c66690.tar.gz
2019-11-28 20:24:00 <mps> does not
2019-11-28 20:24:10 <_ikke_> s/commit/archive/
2019-11-28 20:24:50 <mps> meh, yes
2019-11-28 20:25:16 <mps> november blindness
2019-11-28 20:26:39 <mps> your latest push for wiringpi works in lxc aarc64
2019-11-28 20:27:46 <mps> why it didn't worked 10 minutes ago I'll left to $deity to explain :)
2019-11-28 20:31:14 <mps> patchwork on ppc64le have ERROR: unsatisfiable constraints:
2019-11-28 20:31:22 <_ikke_> Yes, I noticed
2019-11-28 20:31:48 <mps> someone need to clean builder?
2019-11-28 20:32:39 <_ikke_> Yes, someone should
2019-11-28 20:33:42 <mps> anyone have idea how much packages left to fix for 3.11
2019-11-28 20:36:31 <_ikke_> x86_64 apparently 21 packages
2019-11-28 20:37:14 <_ikke_> http://tpaste.us/Obrw
2019-11-28 20:38:47 <_ikke_> aarch64 has 39 left
2019-11-28 20:39:05 <_ikke_> I'm afraid we have to disable vault for now..
2019-11-28 20:43:16 <mps> looks like only crystal depends on llvm5?
2019-11-28 20:44:05 <_ikke_> and ghc
2019-11-28 20:44:43 <mps> 'ap revdep' doesn't work for me or I don't know how to use it
2019-11-28 20:44:54 <_ikke_> you need to run it in the correct directory
2019-11-28 20:45:04 <_ikke_> for example, in the community directory
2019-11-28 20:45:23 <mps> cd community/llvm5 ; ap revdep
2019-11-28 20:45:35 <_ikke_> cd community; ap revdep llvm5
2019-11-28 20:46:17 <mps> it gives only ghc, not crystal
2019-11-28 20:46:21 <_ikke_> indeed
2019-11-28 20:46:53 <mps> understand. only explicit pkg name in makedepends
2019-11-28 20:46:54 <_ikke_> :q
2019-11-28 20:47:12 <_ikke_> ah, it works if you list llvm5-dev
2019-11-28 20:47:32 <_ikke_> ap revdep llvm5{,-dev}
2019-11-28 20:47:39 <mps> hah, true
2019-11-28 20:48:16 <_ikke_> What do you think we should do with vault?
2019-11-28 20:48:23 <mps> ok, for crystal we can disable check and rebuild with llvm8
2019-11-28 20:48:26 <_ikke_> it only supports nodejs 10 and we are already on 12
2019-11-28 20:48:52 <mps> I don't know much about nodejs pkgs, sorry have no idea
2019-11-28 20:49:05 <_ikke_> It's not a nodejs package itself
2019-11-28 20:49:11 <_ikke_> but it has a web interface
2019-11-28 20:49:30 <mps> hmm, will look then, later
2019-11-28 20:49:51 <_ikke_> I linked to an issue where they specified that, not a lot we can do about
2019-11-28 20:50:02 <_ikke_> so either we need to readd nodejs 10, or we disable vault
2019-11-28 20:50:16 <mps> return to crystal, we can also disable on aarch64 and build and check on x86_64
2019-11-28 20:51:25 <_ikke_> so it needs llvm5 to make the tests pass on aarch64?
2019-11-28 20:51:32 <mps> yes
2019-11-28 20:51:56 <mps> but can be built with llvm8 on both arch'es
2019-11-28 20:52:05 <_ikke_> https://www.haskell.org/ghc/download_ghc_8_6_5.html lists llvm6
2019-11-28 20:53:32 <mps> nice, so could be tried with that version
2019-11-28 20:53:50 <_ikke_> but llvm6 is in testing
2019-11-28 20:53:58 <_ikke_> so it would need to be moved to community
2019-11-28 20:54:29 <mps> it is not big issue, imo
2019-11-28 20:54:31 <_ikke_> and ghc 8.6, while we're on 8.4
2019-11-28 21:01:23 <_ikke_> building ghc 8.6.5 with llvm6 now
2019-11-28 21:01:38 <mps> :)
2019-11-28 21:04:26 <_ikke_> fails in linking fase
2019-11-28 21:04:41 <_ikke_> https://tpaste.us/wn1v
2019-11-28 21:07:50 <mps> uff
2019-11-28 21:08:18 <mps> looking in upx, check is disabled on s390x, but not on other arch's
2019-11-28 21:08:39 <_ikke_> upx?
2019-11-28 21:08:58 <mps> community/upx
2019-11-28 21:10:01 <mps> if remove check for  "-static -no-pie" it pass
2019-11-28 21:10:45 <mps> actually fail on "-no-pie" check
2019-11-28 21:13:32 <mps> I think it is safe to remove "-static -no-pie" test, who still uses static with no-pie
2019-11-28 21:47:51 <_ikke_> re vault: we can also disable the UI to get it to build I guess
2019-11-28 22:00:11 <_ikke_> This builds for me: https://tpaste.us/Jxq0
2019-11-28 22:25:27 <maxice8> Test
2019-11-28 22:25:47 <Cogitri[m]> Neat, seems the new matrix IRC bridge works
2019-11-28 22:30:28 <mps> looking patchwork build fail, looks like py3-django-rest-framework and py3-psycopg2 have conflicting deps
2019-11-28 22:41:54 <Cogitri[m]> Well, now that that works, do we have some place where we have all pkgs failing to build on 3.11 listed?
2019-11-28 22:42:39 <_ikke_> Just watch #alpine-commits..
2019-11-28 22:42:55 <_ikke_> failed to buidl patchwork
2019-11-28 22:42:59 <_ikke_> failed to build llvm5
2019-11-28 22:43:04 <_ikke_> and more
2019-11-28 22:43:08 <Cogitri[m]> Fair enough, that works too
2019-11-28 22:43:44 <_ikke_> That's what everybody is doing
2019-11-28 22:44:25 <Cogitri[m]> Yup, didn't consider that pkgs will be rebuilt if they've failed so they'll show up in #alpine-commits again
2019-11-28 23:24:53 <Cogitri[m]> Is someone else using gnome on Alpine? I think the gnome-session upgrade killed it
2019-11-29 00:57:46 <Cogitri[m]> 
ACTION doing a last test for matrix-appservice-irc

2019-11-29 00:57:56 <Cogitri[m]> Seems to work, nice.
2019-11-29 01:02:04 <maxice8[m]> @Cogitri seems to work
2019-11-29 01:02:16 <Cogitri[m]> Yup
2019-11-29 01:55:54 <north1> Can we get a github-deprecated bot :D ?
2019-11-29 07:30:32 <wowaname> has openrc-init been discussed at all for pid1?
2019-11-29 07:31:06 <wowaname> does it boil down to memory usage or maturity vs busybox's init?
2019-11-29 07:40:34 <_ikke_> morning. Patch for vault, but does mean the UI is disabled for the time being: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1734
2019-11-29 07:40:51 <_ikke_> The alternative is to add nodejs10 as a seperate package
2019-11-29 08:45:54 <Cogitri[m]> BTW, are we going to automatically upgrade users from linux-vanilla to linux-lts?
2019-11-29 08:50:12 <AinNero> how would we?
2019-11-29 08:50:56 <Cogitri[m]> Adding provides&replaces on linux-lts so that it replaces linux-vanilla
2019-11-29 08:51:13 <AinNero> i see
2019-11-29 08:56:34 <ncopa> Cogitri[m]: good question
2019-11-29 08:56:44 <ncopa> i dont think we need a replaces
2019-11-29 08:57:11 <ncopa> but maybe a provides would be good
2019-11-29 09:03:09 <mps> currently we can have both (vanilla and lts) installed at the same time, and select from boot menu which one to use
2019-11-29 09:06:46 <Cogitri[m]> Yup, but we aren't going to keep -vanilla, right?
2019-11-29 09:09:31 <Cogitri[m]> (Although haven't a 2nd kernel as fallback if the thing doesn't boot does sound nice)
2019-11-29 09:09:58 <mps> fcolista: looking patchwork build fail, looks like py3-django-rest-framework and py3-psycopg2 have conflicting deps
2019-11-29 09:10:39 <mps> if you have some time to look at this, you are maintainer :)
2019-11-29 09:12:55 <mps> ncopa: community/upx fails in check testing '-no-pie' in combo with '-static'
2019-11-29 09:13:48 <mps> removing '-no-pie' in test sample it pass build
2019-11-29 09:21:30 <fcolista> mps, thanks for the notice. I don't know how to fix this, since there are constraint related to the versions.
2019-11-29 09:21:40 <fcolista> I think we have two options
2019-11-29 09:21:51 <fcolista> 1. make it install with pip
2019-11-29 09:22:19 <fcolista> 2. Create a package specific for patchwork, like py3-psycopg2-patchwork
2019-11-29 09:22:31 <fcolista> and py3-django-rest-framework-patchwork
2019-11-29 09:22:44 <fcolista> but it's gonna be a nightmare due to the related dependencies..
2019-11-29 09:23:16 <fcolista> Any (other) ideas?
2019-11-29 09:23:25 <mps> yes, I looked and TBH don't understand how to fix this
2019-11-29 09:23:59 <mps> maybe someone with deep python knowledge could help
2019-11-29 09:24:50 <fcolista> mps, I choosed the option 1. with gnn3
2019-11-29 09:26:05 <mps> if it works it is good
2019-11-29 09:27:23 <fcolista> it works, but the maintainership is difficult tbh..
2019-11-29 09:27:34 <fcolista> would be better to handle the dependencies version with pip
2019-11-29 09:28:14 <mps> iirc, yesterday someone told that the python moving to pip for all pkgs
2019-11-29 09:28:54 <mps> if that is true then you solution looks right
2019-11-29 09:29:12 <fcolista> I read ncopa's message on ML re ansible-lint package
2019-11-29 09:29:22 <mps> decision, I mean
2019-11-29 09:29:53 <fcolista> having a different version of the same package would multiply the space used in the mirrors
2019-11-29 09:30:57 <mps> eh, modern langs eccosystem leads to this path
2019-11-29 09:31:03 <Cogitri[m]> It'd be best if the version restrictions weren't so tight :/
2019-11-29 09:31:13 <Cogitri[m]> mps: Yes, it's gonna get pretty painful
2019-11-29 09:31:31 <fcolista> we had a (similar) nightmare with ruby
2019-11-29 09:31:59 <fcolista> then we ended up in dropping all the ruby pacakges, having onle the basis to install the dependencies
2019-11-29 09:32:46 <fcolista> it smells to be the path for python too, if we don't have/find a proper way to have pip being used in APKBUILD for this purpose
2019-11-29 09:33:50 <clandmeter> fcolista: my suggestion is not to pack python apps in aports.
2019-11-29 09:34:00 <mps> don't want to be judge but think it will end in something similar for python like it was for ruby
2019-11-29 09:34:22 <Cogitri[m]> 
ACTION likes the approach of NixOS autogenerating python packages build recipes

2019-11-29 09:34:46 <fcolista> clandmeter, yes, this is (another) option..but this will reduce a lot the number of applications shipped with Alpine
2019-11-29 09:34:57 <fcolista> which does not make Alpine so appealing, IMHO
2019-11-29 09:35:33 <fcolista> sometimes, python packages are only part of the dependencies
2019-11-29 09:49:19 <ahmedbilal> fcolista: Hi, etcd is still not starting correctly with `service etcd start`. Are you applying some kind of patch on etcd.conf?
2019-11-29 09:49:55 <fcolista> ahmedbilal, no
2019-11-29 09:50:06 <fcolista>    $pkgname.yaml::https://raw.githubusercontent.com/etcd-io/etcd/release-${pkgver%.*}/etcd.conf.yml.sample
2019-11-29 09:50:13 <fcolista>   install -Dm644 $srcdir/$pkgname.yaml  "$pkgdir"/etc/etcd/conf.yml
2019-11-29 09:50:42 <ahmedbilal> fcolista: I diffed the version shipped with the package with the one at https://raw.githubusercontent.com/etcd-io/etcd/release-3.4/etcd.conf.yml.sample . There is changes
2019-11-29 09:51:34 <ahmedbilal> https://ilet.to/GVLP
2019-11-29 09:51:57 <fcolista> ERR_CONNECTION_RESET
2019-11-29 09:52:11 <fcolista> https://git.alpinelinux.org/aports/tree/testing/etcd/APKBUILD?id=19e77761e009f51b82e7ae4880b1eba56498e715
2019-11-29 09:52:19 <fcolista> this is the APKBUILD, ahmedbilal
2019-11-29 09:53:07 <fcolista> sorry, this: https://git.alpinelinux.org/aports/tree/testing/etcd/APKBUILD
2019-11-29 09:53:12 <ncopa> fcolista: re patchwork, it is about django?
2019-11-29 09:53:21 <ncopa> in any case, i think we should upgrade django
2019-11-29 09:53:37 <fcolista> patchwork wants an older version..
2019-11-29 09:54:00 <fcolista> not only for django, but for py3-psycopg2
2019-11-29 09:54:13 <ncopa> i think we should upgrade django anyways
2019-11-29 09:54:46 <fcolista> ahmedbilal, the https://ilet.to/GVLP link doesn't work
2019-11-29 09:58:37 <clandmeter> fcolista: im talking about python applications not packages.
2019-11-29 09:58:46 <fcolista> <afk for 1hour>
2019-11-29 09:58:58 <fcolista> clandmeter, ok
2019-11-29 09:59:04 <clandmeter> like patchwork
2019-11-29 09:59:07 <clandmeter> or similar
2019-11-29 09:59:27 <clandmeter> the tend to lock some dep to a specific version.
2019-11-29 09:59:37 <clandmeter> which will break another python app
2019-11-29 09:59:51 <clandmeter> this is the reason we removed most of the ruby stuff
2019-11-29 10:05:00 <ahmedbilal> @fcol
2019-11-29 10:05:39 <ahmedbilal> fcolista: The etcd package is still using the https://raw.githubusercontent.com/etcd-io/etcd/release-3.3/etcd.conf.yml.sample instead of 3.4
2019-11-29 10:06:54 <_ikke_> ncopa: what do you think we should do with vault? The UI (webinterface) only supports nodejs 10, while we already have nodejs 12 in the repos. The easiest / quickest solution is to disable the UI for now
2019-11-29 10:08:06 <_ikke_> The alternative would be to package nodejs10 seperately
2019-11-29 10:13:58 <ncopa> lets drop the ui
2019-11-29 10:14:12 <ncopa> maybe report upstream that we need node 12 support
2019-11-29 10:14:35 <_ikke_> Ok, I'll push the MR I have for that
2019-11-29 10:14:48 <Cogitri> About that: is there a way to check that all pkgs work with new nodejs versions? Do I just have to rebuild all packages? Curious since I don't know how to review nodejs bumps
2019-11-29 10:17:38 <clandmeter> are we now packaging nodejs applications?
2019-11-29 10:18:08 <ncopa> seems like vault also depends on python2
2019-11-29 10:18:36 <ncopa> my desktop ui is a bit sluggish after kernel upgrade
2019-11-29 10:18:55 <ncopa> mouse movements are not as fluid as it used to
2019-11-29 10:19:47 <Cogitri> Kernel upgrade to 5.4?
2019-11-29 10:21:27 <_ikke_> clandmeter: vault has a ui which depends on node
2019-11-29 10:21:38 <_ikke_> vault itself is a go application
2019-11-29 10:21:48 <clandmeter> im talking about 062d4606bc734c20f1b4e6110f2952c2f90e9b82
2019-11-29 10:21:53 <mps> my desktop is faster with kernel upgrade
2019-11-29 10:21:55 <_ikke_> ah ok
2019-11-29 10:22:11 <clandmeter> i would opt for not adding such things to aports.
2019-11-29 10:22:21 <mps> clandmeter: +1
2019-11-29 10:23:47 <_ikke_> Where do we draw the line then? We have lots of other language related projects as well (perl, lua for instance)
2019-11-29 10:24:01 <Cogitri> And the package does come with an init script and stuff
2019-11-29 10:24:04 <_ikke_> go/rust just require you to build the world
2019-11-29 10:24:22 <clandmeter> do we have lua related applications in aports?
2019-11-29 10:24:22 <Cogitri> But packaging nodejs stuff isn't exactly pretty, yes
2019-11-29 10:24:39 <clandmeter> we have libs/modules
2019-11-29 10:25:02 <clandmeter> cp -r "$builddir"/node_modules.. scares me
2019-11-29 10:25:13 <mps> _ikke_: I don't see any big ruby or perl app in aports
2019-11-29 10:26:00 <_ikke_> ruby has been removed alreayd like clandmeter says
2019-11-29 10:26:00 <mps> perl mojolicious only, but it is simple to build
2019-11-29 10:26:57 <clandmeter> a simple app like that matrix irc server already takes 32mb
2019-11-29 10:28:27 <clandmeter> i think we have 1 perl application, that ticket system iirc.
2019-11-29 10:31:33 <ncopa> Cogitri: yes, kernel upgrade to 5.4
2019-11-29 10:32:26 <_ikke_> software noways becomes harder and harder to package as a system
2019-11-29 10:32:55 <_ikke_> people don't care about backwards compatibility, so you get these dependency conflicts
2019-11-29 10:45:19 <clandmeter> ncopa: do you have root on zfs?
2019-11-29 10:45:27 <Cogitri> I have
2019-11-29 10:45:34 <Cogitri> But the upgrade shouldn't change something
2019-11-29 10:45:45 <Cogitri> SIMD wasn't available on 4.19 either
2019-11-29 10:45:46 <ncopa> clandmeter: not on my desktop machine
2019-11-29 10:45:53 <Cogitri> But hopefully ZFS 0.8.3 will change that.
2019-11-29 10:46:00 <ncopa> i have it on my laptop, which i havent yet updated kernel
2019-11-29 10:46:19 <clandmeter> i wonder if we should convert gbr1.a.o to zfs
2019-11-29 10:46:33 <clandmeter> but im not sure how to do so
2019-11-29 10:46:41 <clandmeter> it currently has hwraid
2019-11-29 10:47:31 <clandmeter> or maybe use lvm instead
2019-11-29 10:48:51 <Cogitri> ZFS offers datachecksumming, so that's nice
2019-11-29 10:49:01 <kaey> grafana broke with node upgrade as well, but it was trivial to fix
2019-11-29 10:49:02 <kaey> https://git.alpinelinux.org/aports/commit/testing/grafana/APKBUILD?id=16099f5bc39008876657c316f060c8f59dad7eb1
2019-11-29 10:49:51 <clandmeter> zfs is not as simple as lvm
2019-11-29 10:49:53 <_ikke_> kaey: but vault ui does not even build with node 12
2019-11-29 10:50:04 <_ikke_> they added the version constraint only later
2019-11-29 10:50:51 <mps> iiuc, zfs uses more memory than other FS
2019-11-29 10:51:01 <kaey> yea, I saw. I just mentioned that other packages can break as well and shipping multiple node version may be a requirement
2019-11-29 10:51:04 <Cogitri> clandmeter: I haven't yet setup LVM manually but setting up ZFS is easy enough
2019-11-29 10:51:11 <Cogitri> mps: It has a pretty nice cache
2019-11-29 10:51:25 <mps> big == nice
2019-11-29 10:51:25 <Cogitri> It frees the memory of the cache if you actually do need the RAM tho
2019-11-29 10:51:44 <clandmeter> the nice thing of lvm is i can just use our current installer without any additional steps
2019-11-29 10:51:54 <clandmeter> and the raid integration is nice too
2019-11-29 10:52:52 <mps> personally I will not use any FS which is not in mainline kernels
2019-11-29 10:53:06 <clandmeter> i think you can limit the memory usage of zfs, but its again an additional step with ZFS
2019-11-29 10:53:42 <Cogitri> As said, it only uses free memory when you don't use it for smth else
2019-11-29 10:54:45 <clandmeter> so you have whiole disk allocated to zfs?
2019-11-29 10:57:28 <Cogitri> I have my entire disk minus 500MiB for /boot allocated for my ZFS on my laptop and I have 2+6TB in my NAS with ZFS on Alpine too
2019-11-29 10:57:31 <Cogitri> Works super well
2019-11-29 10:57:42 <ncopa> my rootfs is on nvme ssd and my /home on mdadm+lvm. i'm considering switch to zfs for /home
2019-11-29 10:58:10 <Cogitri> I just have / on ZFS and have a subvolume for /home
2019-11-29 10:58:17 <clandmeter> i thought zfs explicitly mention to allocate the whole disk to it?
2019-11-29 11:03:00 <clandmeter> but i guess it will never work with EFI boot and ESP.
2019-11-29 11:05:09 <Cogitri> I use an USB flash drive w/ a FAT32 volume plugged into my NAS for that
2019-11-29 11:09:00 <Cogitri> (definitely because I wanted that setup and not because I forgot to make a /boot before it was too late :P)
2019-11-29 11:09:26 <clandmeter> yeah, except the server i need to install it on is 500km away :)
2019-11-29 11:33:59 <Cogitri> Yeah, that makes it more complicated, I suppose
2019-11-29 11:37:20 <mps> kernel 5.4.1 is out
2019-11-29 11:38:38 <Cogitri> Neat
2019-11-29 11:41:22 <north1> Cogitri: ping
2019-11-29 11:42:34 <mps> north1: sorry to jump in, !1743
2019-11-29 11:42:44 <mps> looks good
2019-11-29 11:42:56 <north1> alright i used it a bit
2019-11-29 11:43:02 <north1> feels too weird for me compared to fish
2019-11-29 11:43:10 <mps> especially your modernizations
2019-11-29 11:43:45 <Cogitri> maxice8: pong
2019-11-29 11:44:47 <mps> north1: if you want I can post my rc and customization, completion etc
2019-11-29 11:45:04 <north1> mps (IRC): I'm comfortably on fish
2019-11-29 11:45:11 <north1> Cogitri: Just testing that your bridge works
2019-11-29 11:45:14 <mps> 'tcsh git complete'
2019-11-29 11:45:27 <Cogitri> Apparently it does, thanks :)
2019-11-29 11:45:28 <mps> ok
2019-11-29 14:08:17 <kaey> grafana-image-renderer broke with latest node and I don't know how to fix it
2019-11-29 14:10:31 <Cogitri> Best to ask upstream, I suppose
2019-11-29 14:17:20 <kaey> it looks like grafanair depends on 2 year old grpc version and grpc breaks api in minor releases
2019-11-29 14:18:56 <Cogitri> Well that's fun
2019-11-29 14:22:47 <_ikke_> kaey: so you override their constraint on nodeversion and then you're suprised that things break? ;-)
2019-11-29 14:24:27 <kaey> there is no constraint
2019-11-29 14:24:51 <kaey> there is in grafana thought, but it works
2019-11-29 14:25:59 <kaey> i'm annoyed that yarn install runs arbitrary commands on my system and breaks between minor node upgrades
2019-11-29 14:26:34 <kaey> hello node-gyp, node-pre-gyp, husky and whatever other insanity there is
2019-11-29 14:26:59 <_ikke_> +1
2019-11-29 14:27:11 <_ikke_> husky >/dev/null
2019-11-29 14:31:13 <kaey> apk doesn't store downloaded packages somewhere in cache, right?
2019-11-29 14:31:24 <kaey> is there any way to make it do it?
2019-11-29 14:31:30 <north1> kaey (IRC): setup-apkcache
2019-11-29 14:32:03 <north1> it will default to /var/cache/apk but you can pick another path
2019-11-29 14:32:40 <kaey> thanks
2019-11-29 14:42:29 <Cogitri> Could someone look into !1529 ? Fixes some GNOME functionality
2019-11-29 14:42:48 <north1> I looked and tagged @ncopa, wanted him to look as well
2019-11-29 15:31:46 <clandmeter> ncopa: would be nice if we could include an EFI aarch64 iso.
2019-11-29 15:41:00 <Guest91> Just wanted to note that the netdata package available under edge/testing does not appear to have SSL support.
2019-11-29 15:43:38 <north1> Guest91 (IRC): Can you open an issue on gitlab.a.o/alpine/aports ?
2019-11-29 15:45:53 <_ikke_> just a matter of adding openssl-dev to makedepends
2019-11-29 15:46:11 <north1> _ikke_ (IRC): tagged you on a MR that conveniently does that and some stuff more :D
2019-11-29 15:46:20 <north1> What a coincidence
2019-11-29 15:46:30 <_ikke_> heh
2019-11-29 15:46:49 <_ikke_> I was looking at updating it yesterday, but there was a build failure
2019-11-29 15:48:25 <north1> It also does a few other nice things
2019-11-29 15:48:50 <north1> it installs /var/log/netdata /var/cache/netdata and /var/lib/netdata as 0750 netdata:netdata and the init.d file uses checkpath in start_pre() to check for them
2019-11-29 15:50:46 <_ikke_> https://gitlab.alpinelinux.org/alpine/aports/merge_requests/1758/diffs ?
2019-11-29 15:50:59 <north1> reload
2019-11-29 15:51:01 <_ikke_> I only see enabling https as significant change
2019-11-29 15:51:03 <_ikke_> ah
2019-11-29 15:51:49 <_ikke_> Would be nice to have something declarative for checkpath
2019-11-29 15:51:59 <north1> like systemd-tmpfiles :D
2019-11-29 15:52:42 <_ikke_> 
ACTION whistles

2019-11-29 15:53:23 <fcolista> :)
2019-11-29 16:01:49 <Guest91> Also important for master-slave configuration. I discovered the lack of SSL support when trying to encrypt the stream.
2019-11-29 16:02:33 <Guest91> I was in the middle of creating a issue on gitlab.a.o
2019-11-29 17:17:33 <north1> _ikke_ (IRC): can netdata go ?
2019-11-29 17:18:52 <_ikke_> Yes, I'll update it seperately
2019-11-29 17:18:58 <north1> aight
2019-11-29 17:24:42 <clandmeter> north1: why check again in initd for those paths in netdata when you create them in package already?
2019-11-29 17:25:05 <north1> Because they might change, we provide them by default but a fuckup can happen so we check before starting
2019-11-29 17:25:40 <clandmeter> seems unnecessary
2019-11-29 17:26:06 <north1> It kinda is
2019-11-29 17:26:08 <clandmeter> should we do that for all packages that have directories in /var?
2019-11-29 17:26:44 <clandmeter> we normally do that for things in /run
2019-11-29 17:27:36 <north1> googling what rfc is for the strength of should
2019-11-29 17:28:42 <north1> no
2019-11-29 17:28:45 <_ikke_> must we do that?
2019-11-29 17:28:51 <_ikke_> shall we do that?
2019-11-29 17:29:04 <clandmeter> im not following
2019-11-29 17:29:15 <_ikke_> https://tools.ietf.org/html/rfc2119
2019-11-29 17:31:58 <clandmeter> instead of adding more things to initd scrips i would vouch for adding less and make them as simple but functional as possible.
2019-11-29 17:41:53 <north1> Fair
2019-11-29 18:22:36 <filoozom> ncopa: Could you merge https://github.com/alpinelinux/aports/pull/10342 ? I just tested it on my RPi and it worked great!
2019-11-29 18:23:11 <filoozom> Hopefully it'll natively work starting on the next release
2019-11-29 18:23:33 <filoozom> Also, two questions:
2019-11-29 18:24:01 <filoozom> Where do the public keys (in /etc/apk/keys/) come from?
2019-11-29 18:24:12 <filoozom> And why can't I download a package for another arch?
2019-11-29 18:24:31 <filoozom> Basically I'm trying to patch the mkimage.sh script to be able to build a RPi release on x86
2019-11-29 18:24:34 <_ikke_> https://pkgs.alpinelinux.org/contents?file=&path=%2Fetc%2Fapk%2Fkeys&name=&branch=edge&arch=x86_64
2019-11-29 18:25:18 <filoozom> Thanks!
2019-11-29 18:26:50 <_ikke_> Not sure what you mean with the last question
2019-11-29 18:28:55 <filoozom> I get an error while running `apk fetch raspberrypi-bootloader` on x86. First the signature issue (which I can fix by manually adding `alpine-keys` I guess, maybe I can even install it from another arch?)
2019-11-29 18:29:09 <filoozom> Then "raspberrypi-bootloader: unable to select package (or its dependencies)"
2019-11-29 18:31:00 <filoozom> Same when passing `--arch aarch64`, although I just read I should use it with `--root`, so that might be the issue there
2019-11-29 18:33:19 <_ikke_> yes
2019-11-29 18:38:46 <filoozom> # apk fetch --arch aarch64 --root . raspberrypi-bootloaderraspberrypi-bootloader: unable to select package (or its dependencies)
2019-11-29 18:38:51 <filoozom> That doesn't work either though
2019-11-29 18:42:27 <mps> filoozom: --repositories paramaeter?
2019-11-29 18:42:53 <filoozom> That's what I'm currently testing, but it's technically the same as in /etc/apk/repositories, right?
2019-11-29 18:43:13 <mps> no, it is somewhere in your chroot
2019-11-29 18:43:22 <filoozom> Also, I get "WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/edge/main/aarch64/APKINDEX.tar.gz: UNTRUSTED signature" even after having copied "alpine-devel@lists.alpinelinux.org-58199dcc.rsa.pub" over manually
2019-11-29 18:43:24 <mps> I forgot exact
2019-11-29 18:43:54 <mps> i'm not on my workstation right now
2019-11-29 18:44:17 <filoozom> apk fetch --arch aarch64 --root . --no-cache --repository http://dl-cdn.alpinelinux.org/alpine/edge/main --keys-dir /etc/apk/keys raspberrypi-bootloader
2019-11-29 18:44:21 <filoozom> Apparently that did it :p
2019-11-29 18:44:34 <filoozom> No clue why I need to override everything though
2019-11-29 18:45:02 <mps> it is needed always if you use different arch
2019-11-29 18:45:11 <filoozom> And I'm not sure how to safely download the aarch64 keys automatically
2019-11-29 18:45:47 <filoozom> Or all ARM keys for that matter
2019-11-29 18:47:44 <mps> I wrote notes for me how to install different arch in chroot, can post when I come back to home
2019-11-29 18:48:55 <filoozom> Great, thanks!
2019-11-29 18:59:16 <tankf33der> o/
2019-11-29 19:01:31 <filoozom> Damn, of course `apk fetch --arch` doesn't work with `--stdout`
2019-11-29 19:19:49 <mps> filoozom: apk.static --arch aarch64 -X https://nl.alpinelinux.org/alpine/edge/main -U --allow-untrusted --root /mnt --initdb add alpine-base tcsh tmux vim
2019-11-29 19:20:32 <mps> this is just example how to create chroot for aarch64 on x86_64 box
2019-11-29 19:21:57 <mps> after this: cp /etc/resolv.conf /mnt/etc/
2019-11-29 19:22:20 <mps> and: cp /etc/apk/repositories /mnt/etc/apk/
2019-11-29 19:23:13 <mps> and you are ready to enter chroot, but it will not work without qemu-user-static for target arch add to chroot
2019-11-29 19:23:30 <mps> s/add/added/
2019-11-29 19:23:30 <alpine-meetbot> mps meant to say: and you are ready to enter chroot, but it will not work without qemu-user-static for target arch added to chroot
2019-11-29 20:13:57 <tankf33der> i've tried bootstrap sabotage linux on alpine and found patch from busybox cant fuzz inside patch but gnu patch can
2019-11-29 20:14:24 <tankf33der> example like is here:
2019-11-29 20:14:25 <tankf33der> https://pastebin.com/raw/VWgM4t9G
2019-11-29 20:14:41 <_ikke_> tankf33der: busybox tools are often simpler versions, they are not feature complete
2019-11-29 20:14:46 <_ikke_> so it does not surprise me
2019-11-29 20:14:56 <tankf33der> as is.
2019-11-29 20:55:26 <tankf33der> _ikke_: what you think to disable patch in busybox?
2019-11-29 20:56:00 <mps> oh?
2019-11-29 20:56:04 <_ikke_> why is that necessary?
2019-11-29 20:56:21 <_ikke_> tankf33der: you can just install patch
2019-11-29 20:56:29 <_ikke_> https://pkgs.alpinelinux.org/packages?name=patch&branch=edge
2019-11-29 20:57:13 <tankf33der> sure.
2019-11-29 20:57:39 <_ikke_> so there is no need to disable patch
2019-11-29 21:03:57 <sh4rm4^bnc> it would be a win. 10KB or so smaller busybox binary for all minimal docker installs, and if needed, a patch program that actually works...
2019-11-29 21:05:39 <_ikke_> sh4rm4^bnc: then you could better move most of the applets
2019-11-29 21:05:54 <_ikke_> a lot of the applets miss functions that the full commands has
2019-11-29 21:07:31 <sh4rm4^bnc> not really. the other applets are "good enough"
2019-11-29 21:07:35 <_ikke_> sh4rm4^bnc: remove 10kb on busybox and install a 60mb node project
2019-11-29 21:08:00 <sh4rm4^bnc> but busybox patch is not usable for anything but a single patch with zero fuzz
2019-11-29 21:08:53 <sh4rm4^bnc> $ du -h /opt/patch/bin/
2019-11-29 21:08:53 <sh4rm4^bnc> 116.0K  /opt/patch/bin/
2019-11-29 21:09:04 <sh4rm4^bnc> that's the GNU one ^
2019-11-29 21:09:18 <sh4rm4^bnc> written by larry wall, which actually works
2019-11-29 21:10:03 <_ikke_> so save 10kb in order to isntall a 116kb binary :)
2019-11-29 21:10:18 <_ikke_> Or just leave it in, and install patch when you need fuzzing
2019-11-29 21:10:32 <_ikke_> Note that it's better to just fix the patch than rely in fuzzing
2019-11-29 21:10:35 <sh4rm4^bnc> no, saving 10KB for everybody
2019-11-29 21:10:47 <_ikke_> It's not worth the effort
2019-11-29 21:10:48 <sh4rm4^bnc> because nobody actually will use the broken busybox patch
2019-11-29 21:10:58 <_ikke_> There is a lot more bandwidth wasted on other things
2019-11-29 21:11:04 <_ikke_> sh4rm4^bnc: it's not broken
2019-11-29 21:11:06 <sh4rm4^bnc> you can't "fix a patch"
2019-11-29 21:11:08 <_ikke_> it works perfectly fine
2019-11-29 21:11:24 <sh4rm4^bnc> as soon as you apply more than one patch to the same file, you naturally need a fuzz
2019-11-29 21:11:37 <_ikke_> Then install patch
2019-11-29 21:11:38 <_ikke_> if you need that
2019-11-29 21:11:41 <sh4rm4^bnc> or you gotta base your 2nd patch upon the 1st
2019-11-29 21:11:58 <_ikke_> as if patch was not installed on the base image
2019-11-29 21:12:21 <sh4rm4^bnc> i assume any serious patch user will require the real patch, indeed
2019-11-29 21:12:31 <_ikke_> and it's available and installed within seconds
2019-11-29 21:12:31 <sh4rm4^bnc> so the one built-in is just unneeded junk
2019-11-29 21:12:59 <sh4rm4^bnc> ncopa, fabled, your opinion on this matter? ^
2019-11-29 21:15:14 <_ikke_> There is enough bandwidth / storage wased, small applet part of busybox is peanuts compared to that
2019-11-29 21:16:01 <sh4rm4^bnc> uhm, isn't the main selling point of alpine minimal size of the base img ?
2019-11-29 21:16:47 <sh4rm4^bnc> it's certainly nicer to have it 1490KB than 1500
2019-11-29 21:17:00 <_ikke_> you hardly are going to notice that
2019-11-29 21:17:00 <sh4rm4^bnc> and patch isn't really "coreutils" like stuff
2019-11-29 21:17:12 <sh4rm4^bnc> it's like shipping busybox with a built-in yacc
2019-11-29 21:17:15 <_ikke_> especially because you are probably going to install megabytes on top of that anyway
2019-11-29 21:17:44 <sh4rm4^bnc> why not put tinycc into busybox too ?
2019-11-29 21:18:14 <mps> bb patch is nice to have for patching simple things
2019-11-29 21:18:22 <_ikke_> ^
2019-11-29 21:19:22 <mps> like bb grep and similar simple applets
2019-11-29 21:19:43 <sh4rm4^bnc> grep and sed is standard coreutils like stuff
2019-11-29 21:19:51 <sh4rm4^bnc> but patch is a developer tool
2019-11-29 21:19:58 <sh4rm4^bnc> not mandated by POSIX or anything
2019-11-29 21:20:07 <mps> if someone needs more featured it is simple to install them
2019-11-29 21:20:18 <sh4rm4^bnc> orly
2019-11-29 21:21:52 <sh4rm4^bnc> you know, my main point here is that i basically need to add a configure check like "checking whether patch works... no, fuzz unsupported" if alpine insists on having the broken version in its base install
2019-11-29 21:23:09 <mps> can you imagine how many sysadmins are quite fine with bb patch
2019-11-29 21:23:15 <sh4rm4^bnc> tankf33der was trying to build our product when he ran into this issue, some developers spent about an hour to find out what's wrong
2019-11-29 21:24:11 <sh4rm4^bnc> mps, no i can't imagine sysadmins happy with the need to constantly rebase their patches so they work with bb
2019-11-29 21:25:15 <sh4rm4^bnc> Q: do you ship busybox man ?
2019-11-29 21:25:19 <mps> oh?
2019-11-29 21:25:53 <_ikke_> sh4rm4^bnc: but you'd have to check for all kinds of busybox applets that miss all kinds of functions
2019-11-29 21:25:57 <_ikke_> not just patch
2019-11-29 21:26:22 <sh4rm4^bnc> no, all the coreutils-league standard tools work fine, exactly as mandated by POSIX
2019-11-29 21:26:25 <_ikke_> alpine-sdk does install patch btw
2019-11-29 21:26:52 <mps> patch is in deps for abuild
2019-11-29 21:32:04 <_ikke_> sh4rm4^bnc: I would say, open an issue on gitlab.alpinelinux.org
2019-11-29 21:32:24 <_ikke_> then someone can make a decission whether it makes sense to keep it or not
2019-11-29 21:33:23 <_ikke_> sh4rm4^bnc: I don't mind either way. Your first point to do it for the size did not make much sense to me, your latter point makes more sense
2019-11-30 00:31:20 <filoozom> Is there a way to install alpine-keys for another arch without breaking trust? i.e. I want to download aarch64 keys from x86 in order to build the RPi image (assuming it's feasible without qemu which I haven't entirely tested yet) without downloading untrusted packages. Preferably all automated if possible. If not, could we make an `alpine-keys-all` package or something?
2019-11-30 09:15:23 <Cogitri> fwiw linux-lts is running great on my system, thanks for doing that, ncopa
2019-11-30 09:17:16 <mps> also on my but still 5.4.0, I dislike to reboot often
2019-11-30 15:00:35 <filoozom> Ok, I think I'm mostly done with cross-building RPi images in !1774
2019-11-30 18:59:12 <codebam> I've followed the wiki to create a custom alpine ISO. how do I change things such as init scripts and add software that isn't in alpine repos?
2019-11-30 21:12:47 <mps> anyone know if Mitch Tishmack is on any of our channel, upx maintainer
2019-11-30 21:28:54 <Cogitri> ncopa: can you check #11000 ?
2019-11-30 21:31:49 <mps> Cogitri: should be disabled, I wrote already in this issue report
2019-11-30 23:28:52 <sh4rm4^bnc> Authorize Alpine Linux.org Gitlab to use your account?
2019-11-30 23:28:55 <sh4rm4^bnc>  This application will be able to:
2019-11-30 23:28:55 <sh4rm4^bnc>     Access the authenticated user's API
2019-11-30 23:28:55 <sh4rm4^bnc>     Grants complete read/write access to the API, including all groups and projects, the container registry, and the package registry.
2019-11-30 23:29:12 <sh4rm4^bnc> woot. that's a lot of permissions alpine gitlab wants there
2019-11-30 23:30:45 <sh4rm4^bnc> no idea why the bots congratulates, but hey, thanks!