2020-11-01 00:00:10 <Ariadne> and that didn't get it done
2020-11-01 01:35:02 <maxice8> Found out a pretty stupid oversight in my pyX MR
2020-11-01 01:35:11 <maxice8> was using xargs -0 but not find -print0
2020-11-01 01:44:43 <Hello71> I feel like this function could be drastically simplified by using globs and two for loops
2020-11-01 01:45:20 <Hello71> for f in usr/lib/python*/site-packages/*/__init__.py; do ...; done; for f in usr/lib/python*/site-packages/*.py; do ...; done
2020-11-01 01:45:39 <ix> python can have multiple levels of modules...
2020-11-01 01:45:53 <Hello71> well that's a question of what you want to have searchable
2020-11-01 01:46:10 <Hello71> because the objective is not (necessarily) "list everything you can put in import X"
2020-11-01 02:37:01 <maxice8> it can but we just give you the top module because that is what 99% of what people use, nobody puts i need foo.bar module, they just say the need the foo module and call foo.bar
2020-11-01 02:38:21 <maxice8> Hello71: It can be and the initial implementation was find with | while read -r
2020-11-01 07:52:16 <Cogitri> Ariadne: local-rebuild only removes one stage
2020-11-01 07:53:03 <Cogitri> Because when Void crosses it does that with $target_ver == $pkgver
2020-11-01 07:53:21 <Cogitri> So the stage0 is already the right version so there's no need for 3 stages
2020-11-01 10:03:20 <maxice8> morning
2020-11-01 16:03:19 <andypost[m]> Loooks ppc64le builder hanging
2020-11-01 16:04:23 <ikke> Hmm, openjdk
2020-11-01 16:05:49 <ikke> killed it
2020-11-01 16:07:35 <andypost[m]> Thank you
2020-11-01 16:15:08 <Ariadne> hmm, lets try --disable-optimize
2020-11-01 16:30:51 <Ariadne> ok that didnt do anything useful
2020-11-01 16:33:14 <ikke> heh
2020-11-01 16:37:17 <Ariadne> hmm
2020-11-01 16:37:28 <Ariadne> one thing i notice the rust CI scripts doing when crossing is enabling jemalloc
2020-11-01 16:52:10 <Cogitri> Huh
2020-11-01 17:03:59 <Ariadne> that also didn't do anything useful
2020-11-01 18:19:51 <dalias> would it be a good idea to have the builders configured with timeouts and just report failures rather than hanging?
2020-11-01 18:29:17 <ikke> It would need to be something that kills the entire process group, and the timeout should be long enough
2020-11-01 18:43:48 <andypost[m]> What's longest to build? Guess chromium and firefox... So 6-8 hours should be enough
2020-11-01 19:18:17 <dalias> do you have logs of how long they've taken in the past?
2020-11-01 19:18:44 <dalias> 2x last successful build time + epsilon (1 min?) should be a reasonable default limit
2020-11-01 19:19:07 <dalias> (epsilon to handle packages that build in a few seconds, where 2x doesn't really give any margin)
2020-11-01 19:19:26 <ikke> dalias: no, we don't keep track of time
2020-11-01 19:21:35 <dalias> seems like it'd be a useful thing to log
2020-11-01 19:21:45 <dalias> might uncover lots of things worth investigating
2020-11-01 19:21:57 <dalias> (weird build time regressions, etc.)
2020-11-01 21:02:29 <maxice8> https://www.cogitri.dev/posts/08-meet-apkbuild.vim/
2020-11-01 21:07:37 <ikke> nice
2020-11-01 21:09:11 <mps> maxice8: \o/
2020-11-01 21:09:20 <mps> looks nice
2020-11-01 21:10:24 <ikke> hmm, thunar, kfind, cervisia, kruler are failing to build
2020-11-01 21:13:00 <maxice8> working on it
2020-11-01 22:44:20 <ikke> New release for youtube-dl: https://youtube-dl.org/
2020-11-01 22:46:51 <mps> would be good to make archive
2020-11-01 22:48:25 <ikke> This is the last one we have before the github project got shut: https://distfiles.alpinelinux.org/distfiles/youtube-dlc-2020.10.09.tar.gz
2020-11-01 22:49:34 <mps> don't clean it, just in case
2020-11-01 22:50:14 <ikke> We have releases going back to 2017
2020-11-01 22:50:39 <ikke> https://distfiles.alpinelinux.org/distfiles/youtube-dl-2017.07.30.1.tar.gz
2020-11-01 22:50:51 <mps> very good
2020-11-01 22:51:23 <mps> debian also making archives
2020-11-02 07:04:16 <ncopa> morning
2020-11-02 07:05:44 <maxice8> morning
2020-11-02 07:09:43 <ncopa> is there a package for apkbuild.vim?
2020-11-02 07:13:19 <mps> AFAIK not yet, but installed it 'by hand', looks nice
2020-11-02 07:15:10 <mps> firefox 82.0.2 hangs with upgraded musl
2020-11-02 07:16:02 <mps> while 82.0 (without .2) works
2020-11-02 07:21:38 <mps> make in kernel 5.10 now have this warning 'ld: warning: -z norelro ignored'
2020-11-02 08:19:18 <craftyguy> oh what is apkbuild.vim? is it what it sounds like? (vim support for apkbuild syntax stuff?)
2020-11-02 08:19:41 <mps> this, and more
2020-11-02 08:19:59 <mps> https://www.cogitri.dev/posts/08-meet-apkbuild.vim/
2020-11-02 08:21:01 <craftyguy> that is awesome!
2020-11-02 08:21:37 <craftyguy> 
ACTION subscribes to Cogitri's rss feed

2020-11-02 08:49:29 <maxice8> ncopa: currently no and I recommend using a plugin manager as I push constantly with small fixes and other minor changes
2020-11-02 08:52:02 <maxice8> Maybe once it is mostly finished and just requires maintanance like adding new variables and removing old ones
2020-11-02 08:58:14 <maxice8> And the article is outdated already
2020-11-02 13:26:01 <ollieparanoid[m]> apkbuild.vim: nice!
2020-11-02 14:27:03 <mps> I look from time to time on repology.org (about weekly) but web interface is boring. there is short API doc and I made one simple perl script to get problems' pkgs
2020-11-02 14:28:00 <mps> but can't find docs what mean fields in returned json, so trying to guess from tag names
2020-11-02 14:28:39 <mps> anyone know is the API documented somewhere, except short one on repology.org
2020-11-02 14:41:35 <ikke> Maybe the github repo
2020-11-02 14:42:36 <mps> 'use source, Luke' :) thanks
2020-11-02 14:43:26 <ikke> :P
2020-11-02 14:43:38 <ikke> I was hoping there was a readme or something like that
2020-11-02 14:43:45 <ikke> https://github.com/repology/repology-webapp/blob/master/repologyapp/views/api.py
2020-11-02 14:47:00 <mps> easier to me is to guess results in json than read python code. anyway thanks
2020-11-03 05:20:24 <maxice8> Any known way to print column of a grep match ?
2020-11-03 05:42:07 <ikke> maxice8: not aware any
2020-11-03 05:59:36 <maxice8> oof
2020-11-03 05:59:50 <maxice8> guess atools will need a rewrite in a proper language to get better linting information and details
2020-11-03 06:00:56 <ikke> yes, I was getting the same idea
2020-11-03 06:02:04 <ikke> shellcheck has already done the heavy liftwork of parshing shell, but haskell is kind of a barrier
2020-11-03 06:40:07 <maxice8> doesn't go have shlex ?
2020-11-03 06:41:22 <ikke> https://github.com/anmitsu/go-shlex
2020-11-03 06:44:42 <maxice8> https://github.com/mvdan/sh
2020-11-03 06:45:03 <ikke> nice
2020-11-03 06:45:49 <insep_> https://code.dlang.org/packages/shlex
2020-11-03 06:45:51 <insep_> :^)
2020-11-03 06:55:45 <obarun> i have some trouble with the aarch64 img on a raspberry pi4 model. i did a classic install on sys mode, installed xfce4 on it. All good, the system boot correctly, xorg works correctly too. But it's impossible to get the second screen available. If i try to see it with /opt/vc/bin/tvservice -s , it's doesn't appear. The first screen work well but the second screen i get a rainbow screen. Any idea?
2020-11-03 07:32:43 <maxice8> @insep_: I sense enthusiasm :D
2020-11-03 11:46:25 <mps> 
ACTION trying to found why sndiod daemon couldn't start with openrc and wondering why alpine didn't switched to runit

2020-11-03 11:46:53 <mps> find*
2020-11-03 12:20:30 <insep_> maxice8: what's enthusiasm
2020-11-03 12:20:43 <insep_> never heard that word before
2020-11-03 12:29:59 <timlegge2> Are the builders for https://pkgs.alpinelinux.org/ still having issues?  I'm still waiting on perl-b-debug on s390x and mips64.  I have a few other packages to move
2020-11-03 12:31:14 <mps> timlegge2: you can check here https://build.alpinelinux.org/
2020-11-03 12:34:14 <timlegge2> webkit2gtk failed on  build-edge-s390x
2020-11-03 12:37:00 <Cogitri> `ERROR: unable to select packages:` Seems like something in its dep chain was disabled?
2020-11-03 12:47:27 <andypost[m]> Ppc builder hanging again on openjdk
2020-11-03 12:49:07 <ikke> ok, just killed the offending task, and it seems to continue..
2020-11-03 12:49:24 <ikke> Not ideal, but otherwise I guess it won't ever comntinue
2020-11-03 13:03:51 <andypost[m]> Wondering why log said that package(openjdk) already is build but  builder were hanging on it
2020-11-03 13:04:53 <andypost[m]> It's second time for this builder and the package
2020-11-03 13:07:45 <ikke> yes
2020-11-03 13:32:37 <timlegge2> kpmcore failed on s390 looks like it depends on kauth-dev and its arch includes !s390x
2020-11-03 13:33:50 <ikke> They are depending on polkit, which is waiting for rust
2020-11-03 13:34:37 <ikke> Ariadne is trying to get rust cross-compiled for s390x soon, so the idea was to not disable all these packages
2020-11-03 13:34:51 <ikke> just for them to be enabled again soon
2020-11-03 13:34:51 <timlegge2> ah, makes sense
2020-11-03 16:27:45 <ikke> fyi, 7pm CET I'm going to upgrade our gitlab instance (in ~1.5h)
2020-11-03 16:32:45 <ikke> maxice8: ping
2020-11-03 16:35:59 <ikke> maxice8: Are you already working on something for atools?
2020-11-03 17:55:40 <ikke> Reminder: in 5 minutes gitlab will be briefly down to upgrade it
2020-11-03 18:05:29 <ikke> All done
2020-11-03 18:08:55 <Cogitri> 🎉
2020-11-03 18:13:12 <ikke> ncopa: https://about.gitlab.com/releases/2020/07/22/gitlab-13-2-released/#create-releases-from-gitlab-ciyml
2020-11-03 18:14:41 <Cogitri> Oh neat
2020-11-03 18:14:50 <Cogitri> Do releases have stable URLs now?
2020-11-03 18:15:03 <Cogitri> Without that hash that always changes in the URL
2020-11-03 18:15:17 <ikke> hmm, not sure
2020-11-03 18:18:34 <Cogitri> Because that's what annoys me most about Gitlab, that I always have to edit the souce URL for every release :/
2020-11-03 18:45:10 <ikke> Cogitri: I don't see any  hash in releases?
2020-11-03 18:45:18 <ikke> https://gitlab.alpinelinux.org/Leo/atools/-/releases/18.1
2020-11-03 18:52:34 <Cogitri> There are no hashes for the automatically generated tarballs from tags, but if you want to add a custom tarball they always have a shasum in then
2020-11-03 18:53:03 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/apk-polkit-rs/-/tags
2020-11-03 18:53:30 <ikke> ah, right
2020-11-03 18:53:55 <ikke> I think they still need to officially add support for custom assets in releases
2020-11-03 18:54:57 <ikke> ah, 13.5
2020-11-03 18:55:04 <ikke> https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#attach-binary-assets-to-releases
2020-11-03 18:55:36 <Cogitri> Hooray
2020-11-03 18:55:37 <ikke> Not sure if that will provide stable urls, but I would assume so
2020-11-03 18:58:02 <ikke> 
ACTION needs to speed up upgrading gitlab

2020-11-03 20:21:22 <dne> I assume the gitlab email address confirmation messages are related to the upgrade?
2020-11-03 20:23:02 <ikke> ye
2020-11-03 20:23:05 <dne> sorry, I read them in the wrong order - the 1st email explained it :)
2020-11-03 21:28:38 <maxice8> ikke: no, I'm looking at the options
2020-11-03 21:30:53 <maxice8> But before any rewrites in a proper language I want to rework apkbuild-fixer and write an ALE fixer for it
2020-11-03 21:31:23 <ikke> maxice8: ok, I'm playing a bit with that sh package then
2020-11-03 21:31:25 <maxice8> so users of APKBUILD.vim can get violations automatically fixed like with flake8 and black for python.
2020-11-04 01:28:50 <maxice8>  Test
2020-11-04 01:32:10 <Hello71> test failed
2020-11-04 01:32:47 <maxice8> no
2020-11-04 01:32:53 <maxice8> it worke, I just wanted to know my nick
2020-11-04 02:38:38 <maxice8> Good news!
2020-11-04 02:39:27 <maxice8> apkbuild-fixer is now a fixer in Ale, so people that using APKBUILD.vim and dense-analysis/ale can now automatically use apkbuild-fixer to fix policy violations (not all of them, but lots)
2020-11-04 02:55:40 <maxice8> Also wrote 2 new articles on cogitri.dev
2020-11-04 05:15:00 <insep_> Ariadne: is there some guide on preparing packages for crosscompilation like you did with rust?
2020-11-04 05:15:39 <Ariadne> such a situation is undesirable in most cases
2020-11-04 05:17:26 <insep_> some people want to use haskell on aarch64, is this situation desirable?
2020-11-04 07:02:53 <maxice8> No objections to !13852 ?
2020-11-04 07:14:25 <mps> maxice8: no from me
2020-11-04 07:15:04 <mps> and good morning
2020-11-04 08:06:34 <maxice8> morning
2020-11-04 08:33:48 <fcolista>  @Cogitri if/when you have time, please take a look at MR #14248
2020-11-04 08:34:15 <ikke> !14248
2020-11-04 08:34:19 <mps> !14248
2020-11-04 08:34:26 <ikke> mps: :P
2020-11-04 08:34:29 <fcolista> :D
2020-11-04 08:34:34 <mps> uhm, again you are faster
2020-11-04 08:34:46 <fcolista> you, sorcerer of algitbot
2020-11-04 08:34:56 <ikke> it's gitlab syntax
2020-11-04 08:35:02 <ikke> # refers to issues, ! to MRs
2020-11-04 08:35:28 <fcolista> you, sorcere of algitbot AND gitlab
2020-11-04 08:35:34 <ikke> :D
2020-11-04 08:46:24 <Cogitri> fcolista: I think you forgot to actually remove the patch file
2020-11-04 08:46:45 <fcolista> ?
2020-11-04 08:47:10 <fcolista> ah ok you mean with git rm
2020-11-04 08:47:20 <fcolista> not as reference in the APKBUILD
2020-11-04 08:48:28 <Cogitri> Yup
2020-11-04 08:48:59 <fcolista> done
2020-11-04 09:56:01 <markand> hey guys
2020-11-04 09:56:16 <markand> taking maintainership from unmaintained/ should first go to testing/ or can go immediately to community/ ?
2020-11-04 09:58:46 <mps> idk for any rule, but I would move first to testing to see will it pass builders
2020-11-04 10:02:39 <Cogitri> Yup, testing first
2020-11-04 10:03:06 <Cogitri> You can move it to community immediately afterwards if it works on the builders
2020-11-04 10:07:47 <markand> okay
2020-11-04 10:42:29 <Cogitri> Do we allow things with `custom` as license in testing? Asking for !14008
2020-11-04 10:44:25 <ikke> Tough question. Depends on the actual license I guess
2020-11-04 10:45:23 <ikke> You can take 2 stances
2020-11-04 10:45:28 <ikke> a dogmatic and a pragmatic one
2020-11-04 10:48:07 <ikke> Hmm, I don't see any license at all..
2020-11-04 10:49:50 <ikke> https://gitlab.lrz.de/mmix/mmixware/-/blob/master/boilerplate.w
2020-11-04 10:50:21 <ikke> You may only distribute if you make no modifications
2020-11-04 10:52:53 <mps> this doesn't look as distributable by alpine, though ianal
2020-11-04 10:53:15 <ikke> We ditched mongodb for less :P
2020-11-04 10:53:26 <mps> yes
2020-11-04 11:17:45 <ikke> maxice8: I have a proof of concept: https://tpaste.us/nWa6
2020-11-04 11:18:02 <maxice8> very nice
2020-11-04 11:18:07 <maxice8> in which lang ?
2020-11-04 11:18:10 <ikke> go
2020-11-04 11:18:23 <maxice8> very nice
2020-11-04 11:18:51 <ikke> That sh module is quite nice. You do work with ASTs, so it's a bit more ellaborate to parse, but I think it can be done
2020-11-04 11:19:38 <maxice8> hopefully
2020-11-04 11:20:14 <ikke> https://tpaste.us/zxaw
2020-11-04 11:21:44 <maxice8> very elaborate
2020-11-04 11:22:38 <ikke> https://tpaste.us/zxaw?hl=true
2020-11-04 11:23:01 <ikke> I think it should be possible to create some helpers to make it easier
2020-11-04 11:23:07 <ikke> but just first want to get a feel what is required
2020-11-04 11:25:13 <ncopa> i like the idea of atools implemented in go
2020-11-04 11:26:02 <maxice8> hopefully it is the path forward
2020-11-04 11:26:49 <ncopa> i have been thinking of implementing an aports parser in go
2020-11-04 11:27:08 <mps> I would like that all base tools are in C, (and no, I will not do that)
2020-11-04 11:27:08 <ncopa> using multicores
2020-11-04 11:27:34 <Cogitri> ikke: Unrelated, but would it be possible to print the info about changed packages in CI at the end of the CI log?
2020-11-04 11:28:01 <Cogitri> It's a bit cumbersome having to Ctrl+F my way through the log to find out if files have changed when multiple packages have been changed
2020-11-04 11:28:21 <ncopa> benefit with go is that it is significantly faster to implement than C
2020-11-04 11:28:33 <mps> yes, I agree
2020-11-04 11:29:01 <mps> even thinkging to 'clean dust' from my golang memory
2020-11-04 11:29:44 <maxice8> ncopa: do it, it will give me an excuse to dust off go to re-implement adep
2020-11-04 11:30:26 <ncopa> i have been thinking of another tool, to parse the DESTDIR, to detect symlinks, shared lib dependens (provides/depends), bash/sh/perl/python dep and maybe even pkg-config deps. but this should probably be implemented in C, as it is supposed to be used by next gen abuild
2020-11-04 11:30:41 <ncopa> maxice8: adep?
2020-11-04 11:30:52 <mps> (it's a pity crystal development is so slow)
2020-11-04 11:31:09 <maxice8> ncopa: collection of lua scripts I have to help dealing with aports
2020-11-04 11:31:36 <ncopa> maxice8: i would like to have a look at those. to see how they are used
2020-11-04 11:31:43 <maxice8> poorly
2020-11-04 11:31:46 <maxice8> https://github.com/maxice8/aports-helpers
2020-11-04 11:32:19 <ncopa> im still in doubt how the user interface should be done
2020-11-04 11:32:32 <ncopa> eg what options, and how the output should be
2020-11-04 11:34:34 <ncopa> i think the major things we currently miss are detect circular deps, detect reverse deps when disabling an arch
2020-11-04 11:35:11 <maxice8> adep has circular
2020-11-04 11:51:57 <ikke> Cogitri: You mean the output of checkapk?
2020-11-04 12:01:39 <ikke> relevant: https://quii.gitbook.io/learn-go-with-tests/
2020-11-04 12:05:31 <Cogitri> ikke: If that outputs the size, so and file differences, yes
2020-11-04 12:06:28 <ikke> Indeed, it does
2020-11-04 12:06:45 <ikke> Maybe easiest is to collect that info in a file and then output it at the ned
2020-11-04 12:07:16 <Cogitri> Yup, that'd be nice
2020-11-04 12:08:56 <ikke> I wish gitlab had more extended support for reports (outside if the format they support)
2020-11-04 12:16:58 <Cogitri> Well, alternatively I could look into adding support for that in the Gitlab bot so it just posts a comment about changed files
2020-11-04 12:17:06 <Cogitri> probably best anyway since that gives nice visibility
2020-11-04 12:17:28 <Cogitri> I'll look into that soon-ish, gonna look into Go-ing the bot so it's finally ready for deploy
2020-11-04 12:18:31 <Cogitri> Somehow Go-ing doesn't have quite the same ring to it like Oxidizing for Rust :D
2020-11-04 12:18:43 <ikke> heh
2020-11-04 12:19:10 <ikke> Cogitri: Would it help to have have certain output as part of artifacts?
2020-11-04 12:20:14 <Cogitri> I think the current diff output is fine
2020-11-04 12:20:20 <Cogitri> Or do you mean something different?
2020-11-04 12:20:35 <ikke> Cogitri: Now it's all part of one big log file
2020-11-04 12:21:08 <ikke> but I think it should be possible to 'tee' that output into files, which you can expose as artifacts
2020-11-04 12:21:37 <ikke> So not one big file with everything, but for example the checkapk output in a file
2020-11-04 12:25:26 <Cogitri> Oh yes, that's help
2020-11-04 12:26:42 <Cogitri> s/'s/'d/
2020-11-04 12:26:42 <alpine-meetbot> Cogitri meant to say: Oh yes, that'd help
2020-11-04 17:08:21 <ikke> maxice8: How about something like this? https://tpaste.us/X1gB?hl=true :)
2020-11-04 19:31:47 <Cogitri> ikke: Can you make https://gitlab.alpinelinux.org/Cogitri/aports-qa-bot public?
2020-11-04 19:32:50 <Cogitri> Should be able to tick the "remove source branch" and "allow contributors to rebase" boxes already, gonna test a bit more tomorrow and would like to deploy it then
2020-11-04 20:45:36 <ikke> Cogitri: So you've rewritten it in go?
2020-11-04 20:45:55 <ikke> Cogitri: It's public now
2020-11-04 20:45:58 <Cogitri> Thanks
2020-11-04 20:46:05 <Cogitri> Yes, currently in the progress of rewriting it in Go
2020-11-04 20:46:09 <ikke> k, nice
2020-11-04 20:47:35 <ikke> I'm working on a proof of concent for atools in go, as you've noticed
2020-11-04 20:48:17 <Cogitri> Yup, started with Go due to that :D
2020-11-04 20:48:20 <ikke> heh
2020-11-04 20:48:29 <Cogitri> The "Learning Go with tests" thingie is pretty neat
2020-11-04 20:48:42 <ikke> Yeah, that's ncie
2020-11-04 20:48:43 <ikke> nice
2020-11-04 20:48:48 <Cogitri> I'm missing OOP more than I would've though though
2020-11-04 20:49:04 <Cogitri> It's scary what Java classes did to me :D
2020-11-04 20:49:05 <ikke> Yeah, it's a bit of shift in mindset
2020-11-04 20:49:09 <ikke> heh
2020-11-04 20:49:44 <ikke> I think the biggest lack for me is proper error handling
2020-11-04 20:50:05 <Cogitri> Yeah, the if err != nil thing gets old quickly
2020-11-04 20:50:14 <ikke> nod
2020-11-04 20:50:16 <Cogitri> I really, really like Rust's way of doing error handling
2020-11-04 20:50:40 <Cogitri> Just slap `?` everwhere to let errors bubble up and then handle them properly in a higher level function (e.g. main())
2020-11-04 20:51:46 <ikke> I like the documentation, where you can just do golang.org/pkg/<module>
2020-11-04 20:53:29 <Cogitri> Go's documentation is really, really confusing to me though
2020-11-04 20:53:37 <Cogitri> Not sure if that's just me not knowing Go that well yet
2020-11-04 20:53:44 <Cogitri> But Rust's docs are way more concise for me
2020-11-04 20:53:51 <Cogitri> And usually contain a lot more docs
2020-11-04 20:54:26 <ikke> golangs docs are mostly generated from source
2020-11-04 20:54:54 <mps> 
ACTION stopped golang because google and left ML because of CoC

2020-11-04 20:55:23 <ikke> so more focus on documenting the type / function / methods, and less general guidance
2020-11-04 20:55:33 <mps> not that I was rude or anything bad, but just disliked idea of CoC
2020-11-04 20:55:59 <ikke> AL has a CoC as well :P
2020-11-04 20:56:04 <Cogitri> Yeah, Rust's docs are also generated from source (rustdoc is kind of similar to godoc), but somehow Rust's docs are way easier to read for me
2020-11-04 20:56:13 <Cogitri> I don't mind a CoC much, as long as it doesn't go overboard
2020-11-04 20:56:21 <mps> ikke: you reminding me leave ;P
2020-11-04 20:56:29 <Cogitri> (Like FreeBSD's CoC did)
2020-11-04 20:57:03 <mps> Alpine CoC is not so bad, though I would feel better without it
2020-11-04 20:57:50 <insep_> 
ACTION screeches in dpldocs.info

2020-11-04 20:58:10 <insep_> and in https://doc.qt.io/
2020-11-04 20:58:20 <insep_> alpine has coc? :o
2020-11-04 20:58:22 <Cogitri> Heh, dpldocs is also not bad, although template params can be a bit confusing at times
2020-11-04 20:58:44 <Cogitri> https://alpinelinux.org/community/code-of-conduct.html
2020-11-04 20:58:55 <Cogitri> TL;DR don't be a dick and you're good
2020-11-04 20:59:41 <Cogitri> Which is the good kind of CoC, the one that gives moderators something to point to in case they do have to warn someone
2020-11-04 21:00:56 <mps> but of all langs in new millennium go is lang which I think is good, lets see what will happen with zig and crystal
2020-11-04 21:02:51 <ikke> This is how ncopa describes it: https://lists.alpinelinux.org/~alpine/devel/%3CCA+T2pCHT4AZPHXLCwJXp7_S9fLD47mCXZPA3vbav9Jbebh1%3DgQ%40mail.gmail.com%3E#%3C20171006153644.44ca7a93@ncopa-desktop.copa.dup.pw%3E
2020-11-04 21:02:56 <Cogitri> Zig seems neato, but no OOP is ouch
2020-11-04 21:03:35 <mps> no OOP is which is good in it, imo
2020-11-04 21:05:17 <mps> ikke: heh, looking on top on thread now I understand ;P
2020-11-04 21:06:09 <insep_> zig is pretty weirdd
2020-11-04 21:09:20 <insep_> front page describes it as a best language in the world and gives pretty convincing arguments, but then i see types after names, i8 types (int8 and uint8 are much more obvious and look cooler), no function overloading, order of declaration doesn't matter and it forces you to use 4 spaces and \n instead of \r\n line endings
2020-11-04 21:09:47 <insep_> and then i stick with c/c++/d :>
2020-11-04 21:12:10 <insep_> Cogitri: where else am i going to tell people that russia is the best country in the world and why governments hide ufo photos from us? ｡ﾟ(*´□`)ﾟ｡
2020-11-04 21:12:31 <Cogitri> No function overloading isn't fun indeed
2020-11-04 21:13:44 <insep_> i think you can get some sort of oop in zig if methods are all what you need
2020-11-04 21:13:52 <insep_> (and they are what you need most of the times)
2020-11-04 21:14:41 <Cogitri> But I want to chain up constructors and all of that fun stuff
2020-11-04 21:14:54 <Cogitri> Also, no good GLib bindings yet, so meh :D
2020-11-04 21:15:20 <insep_> ew glib
2020-11-04 21:16:04 <insep_> why do you need glib when you have and true qt? let's ignore the fact that qt uses glib for networking
2020-11-04 21:16:40 <Cogitri> Qt being C++ is one of the more important reasons I'm avoiding it :P
2020-11-04 21:17:22 <insep_> nothing wrong with c++ ^^
2020-11-04 21:19:21 <Cogitri> I guess other than the stdlib, STL and how much it slows down the compiler and how bad the error messages get it's kind of OK
2020-11-04 21:21:03 <insep_> nothing wrong with stdlib, not sure what's wrong with stl, agree on compile times, yet to encounter really obscure error messages
2020-11-04 21:21:19 <insep_> also most of the time with qt you won't be using stdlib :^)
2020-11-04 21:22:36 <insep_> you will be using it when you need sane input-output though, all that qt has afaik is debug messages for io
2020-11-04 21:22:42 <Cogitri> The stdlib preferring a tiny bit of speed in favour of being sane is a bit annoying
2020-11-04 21:23:23 <insep_> technically you can try to use qiodevice and use it for io to stdout though
2020-11-04 21:23:25 <Cogitri> Really obscure error messages start to appear with lots of STL sprinkled in, it's not fun fixing CI pipelines at work
2020-11-04 21:25:35 <mps> insep_: yes, forced 4 spaces is worst thing in zig
2020-11-04 21:26:00 <insep_> mps: not accepting \r\n is even worse :<
2020-11-04 21:26:26 <mps> I'm ok for that
2020-11-04 21:26:48 <insep_> i'm not okay
2020-11-04 21:27:10 <mps> and don't much care about 4 spaces
2020-11-04 21:28:00 <insep_> can't they just admit that windows is superior to linuх or at least add fricking ci checks for code formatting rather than enforcing your opinionated views on others?
2020-11-04 21:28:04 <mps> but I still don't use zig for anything, just made some small test programs to see how it works
2020-11-04 21:28:30 <insep_> language shouldn't enforce code style upon me
2020-11-04 21:28:33 <Cogitri> Isn't Windows going to switch to \n for lineendings too?
2020-11-04 21:28:47 <insep_> <Cogitri "Isn't Windows going to switch to"> dunno
2020-11-04 21:29:07 <Cogitri> ikke: fwiw I think we can deploy the aports-qa-bot already, tested in a dummy repo and it enables "Remove Source Branch" and allows rebasing for new MRs now
2020-11-04 21:29:16 <Cogitri> Updated the dockerfile and docker-compose repo too
2020-11-04 21:29:32 <mps> insep_: I agree with that the language shouldn't enforce style, but go-lang does same, tabs
2020-11-04 21:29:42 <Cogitri> Best to deploy it early so we don't have the same situation as last time where deploying could blow everything up because the bot does too much already
2020-11-04 21:30:06 <ikke> Cogitri: early in what sense?
2020-11-04 21:30:10 <insep_> mps: i don't regret stopping learning go then
2020-11-04 21:31:21 <Cogitri> ikke: early as in early in development when the bot doesn't do as much already
2020-11-04 21:31:47 <ikke> ah, like that
2020-11-04 21:31:54 <ikke> maxice8: https://gitlab.alpinelinux.org/kdaudt/atools-go/-/tree/implement
2020-11-04 21:32:11 <Cogitri> I mean no need to deploy the bot right now, but would be nice if you could look into it in the coming days
2020-11-04 21:32:25 <Cogitri> You only need to adjust the conf.json in the compose repo
2020-11-04 21:32:28 <ikke> yeah, please remind me around the end of the week
2020-11-04 21:32:35 <Cogitri> 👍
2020-11-04 21:38:55 <maxice8> ikke: amazing
2020-11-04 21:40:28 <ikke> That library you suggested does the heavy lifting ;P
2020-11-04 21:40:52 <maxice8> nice
2020-11-04 21:43:35 <ikke> I've added some code that does pre 'parsing' of the AST to make it simpler to use in linters
2020-11-04 21:52:27 <mps> c705: don't ask me now to make linux-edge 5.9.4, I'm tired and will do tomorrow :)
2020-11-04 21:53:18 <ikke> lol, inb4
2020-11-04 22:11:23 <mps> c705: I'm lying, pushed :)
2020-11-04 22:24:18 <c705> thanks, not currently using edge though
2020-11-04 22:24:29 <c705> unless seccomp was fixed, then maybe i'll give it a try
2020-11-05 07:51:44 <mps> \o/ (good morning)
2020-11-05 07:52:16 <mps> algitbot: you are most kind 'person' on this channel :)
2020-11-05 07:53:55 <insep_> [algitbot](https://matrix.to/#/@freenode_algitbot:matrix.org): can you pass turing test?
2020-11-05 08:17:14 <mps> eBPF libbpf can be built from kernel source. should we switch to this instead using out-of-tree source from github?
2020-11-05 08:20:33 <mps> Ariadne: ncopa: ^
2020-11-05 09:03:54 <nmeum> can anybody other then me look at the firefox musl 1.2.2 issue #12061? I can't reproduce it but have a patch which is linked in the issue. People claim that it fixes the issue but I honestly don't understand why it does and it still causes sandbox warnings to be emitted which should actually be fixed...
2020-11-05 09:05:27 <nmeum> my patch also only makes sense under the assumption that firefox calls tcgetwinsize/tcsetwinsize but I don't think that it actually does
2020-11-05 09:05:52 <nmeum> but the tcgetwinsize/tcsetwinsize functions are the only place where new ioctl syscalls where introduced with musl 1.2.2
2020-11-05 09:12:31 <maxice8> Is there a way to list all virtual packages ?
2020-11-05 09:36:57 <PureTryOut[m]2> nmeum: note that I had those warnings before the upgrade too. I just checked on my laptop where I didn't upgrade yet and am still running with the older Musl version, I get the warnings there too
2020-11-05 09:38:29 <nmeum> PureTryOut[m]: ooohhh that's very useful information too me
2020-11-05 09:39:01 <nmeum> can you "document" this in the MR by posting a comment? :)
2020-11-05 09:41:10 <PureTryOut[m]2> Sure
2020-11-05 09:41:13 <PureTryOut[m]2> Will do in a bit
2020-11-05 09:43:05 <nmeum> thanks!
2020-11-05 11:00:14 <ikke> maxice8: One issue is that this is mostly statically parsing the APKBUILD, but we have linters that work with dynamic values
2020-11-05 14:07:33 <Ariadne> mps: possibly
2020-11-05 16:42:09 <Cogitri> We're still not in feature freeze for 3.13 are we?
2020-11-05 16:42:22 <Cogitri> As in I can still cram in GStreamer 1.18? :)
2020-11-05 16:43:02 <ikke> I haven't heard about an official freeze yet
2020-11-05 16:43:35 <Cogitri> Neat
2020-11-05 16:54:11 <ikke> Cogitri: https://tpaste.us/MQb1
2020-11-05 16:55:03 <Cogitri> Ah okie, thanks 👍️
2020-11-05 16:55:56 <ikke> that was the 29th
2020-11-05 17:44:48 <mps> kernel development is fast nowadays, three releases in less than 24 hours :)
2020-11-05 17:52:40 <MY-R> mps: already 5.9.6 :D
2020-11-05 17:52:55 <MY-R> damn...
2020-11-05 17:54:35 <mps> 5.9.6 released with just one commit
2020-11-05 18:03:37 <nmeum> did anyone manage to look at the firefox fuckery from earlier today?
2020-11-05 18:03:42 <nmeum> otherwise I will just merge it I guess…
2020-11-05 18:15:58 <Cogitri> It still works for me, this is all so weird :D
2020-11-05 18:16:15 <ikke> I can try to test it in my VM
2020-11-05 18:16:58 <ikke> nmeum: so the version in edge should have issues right?
2020-11-05 18:17:13 <nmeum> so I am told
2020-11-05 18:17:16 <nmeum> it works for me as well
2020-11-05 18:17:29 <nmeum> but there are a lot of people complaining in the issue tracker (i.e. i get a lot of mails which annoy me)
2020-11-05 18:17:43 <nmeum> and some of these people claim my patch fixes it which I really doubt
2020-11-05 18:18:08 <nmeum> it's just weird
2020-11-05 18:32:59 <ikke> nmeum: when is the problem supposed to happen?
2020-11-05 18:33:36 <nmeum> on firefox-esr the problem just happend when I opened a tab and navigated to any website
2020-11-05 18:33:44 <ikke> ok, esd
2020-11-05 18:33:45 <ikke> esr
2020-11-05 18:33:55 <nmeum> that's where I was able to reproduce it
2020-11-05 18:34:14 <nmeum> but some also seem to have the issue on non-esr firefox
2020-11-05 18:34:17 <ikke> I don't even get the sandbox violations, at least on non-esr
2020-11-05 18:34:26 <nmeum> #12061
2020-11-05 18:34:38 <nmeum> I don't get it either
2020-11-05 18:35:01 <nmeum> but at least three different people have complained about it in the issue tracker
2020-11-05 18:35:03 <ikke> let me try esr
2020-11-05 18:36:06 <ikke> esr gives lots of issues
2020-11-05 18:37:10 <nmeum> does it crash?
2020-11-05 18:37:16 <ikke> tab crash, yes
2020-11-05 18:37:27 <nmeum> yep, that's also what I get with -esr
2020-11-05 18:37:38 <ikke> "Gah, your tab just crashed"
2020-11-05 18:37:39 <nmeum> but I can't fix this with esr as esr doesn't build atm due to rust issues
2020-11-05 18:38:04 <nmeum> I just saw that ioctl syscalls violation in esr and figured that might be the cause of the problem
2020-11-05 18:38:37 <nmeum> anyway: that tab crash is what some people seem to be getting with community/firefox too, but only since musl >= 1.2.2
2020-11-05 18:42:25 <ikke> nmeum: sorry, can't help you either then :)
2020-11-05 18:42:27 <mps> for me both sometimes crashes with 'tab crashed' msg, but not often
2020-11-05 18:42:42 <nmeum> ah!
2020-11-05 18:42:44 <nmeum> so it's racy
2020-11-05 18:43:06 <nmeum> I guess?
2020-11-05 18:43:15 <mps> usually with heavy JS
2020-11-05 18:43:26 <ikke> hmm
2020-11-05 18:43:33 <mps> but I'm not sure
2020-11-05 18:45:23 <nmeum> weird
2020-11-05 18:46:45 <mps> nmeum: I don't think that FF crashes sometimes are weird :)
2020-11-05 18:47:10 <mps> I'm surprised it doesn't crash more often
2020-11-05 18:47:19 <nmeum> I am suprised that it works at all
2020-11-05 18:49:13 <mps> :)
2020-11-05 18:51:09 <ikke> No issues here, after browsing for a while
2020-11-05 18:51:23 <nmeum> yeah, i've been browsing fine the entire week
2020-11-05 19:03:46 <c705> nmeum: i tried it again a few days ago but was still getting segfaults
2020-11-05 19:03:56 <c705> if you merge it, i can try it out tonight if no one gets to it before me?
2020-11-05 19:05:45 <nmeum> segfaults, not just tab crashes?
2020-11-05 19:05:50 <nmeum> that's news to me
2020-11-05 19:09:11 <c705> correct
2020-11-05 19:09:35 <c705> it could very well be my wacky kernel settings, but I was also getting tab crashes. I was assuming the segfault lead to the tab crashes
2020-11-05 19:09:42 <c705> anyways, merge it and i'll check it out tonight
2020-11-05 19:22:39 <nmeum> I prefer not to merge my own commits without anyone reviewing it when I am not 100% certain what I am doing
2020-11-05 19:30:08 <c705> i thought others had reviewed it at this point
2020-11-05 23:14:59 <c705> k, so i just pulled edge, and firefox issues persist
2020-11-05 23:15:27 <c705> Sandbox: seccomp sandbox violation: pid 7785, tid 7785, syscall 16, args 2 21523 140730782156328 0 1 0.
2020-11-05 23:15:37 <c705> also,   +2.694980] Web Content[7785]: segfault at 0 ip 00007f8ca9e19936 sp 00007ffe704782e0 error 6 in libxul.
2020-11-05 23:15:48 <c705> libxul.so rather
2020-11-05 23:18:33 <dalias> how hard would it be to fix that one? *sigh*
2020-11-05 23:19:15 <dalias> the seccomp one is TIOCGWINSZ
2020-11-05 23:19:40 <c705> musl 1.2 seems to be going well..........
2020-11-05 23:19:44 <dalias> ?
2020-11-05 23:19:50 <c705> I know it's upstreams fault, but doesn't make it any less annoying
2020-11-05 23:19:58 <c705> this is 1.2 related, 1.1 is fine
2020-11-05 23:20:19 <dalias> are you sure? i'm not aware of anything new that would cause the segfault in xul
2020-11-05 23:20:29 <dalias> do you have a bt for it?
2020-11-05 23:20:34 <c705> actually, no i'm not sure
2020-11-05 23:20:50 <dalias> the seccomp violation is old but seems harmless
2020-11-05 23:21:05 <c705> firefox in edge is broken, but in 3.12 it's fine, I just assumed it was 1.2 related since this stopped working for me in edge when that patch went out
2020-11-05 23:21:24 <c705> Oct 20 something I believe, but I could be wrong
2020-11-05 23:22:19 <c705> a backtrace? no, but I can get one..what do you need? strace output?
2020-11-05 23:24:20 <dalias> well backtrace at the crash would be a good start
2020-11-05 23:24:43 <c705> you need to let me know what to do so I can get information for you
2020-11-05 23:24:48 <c705> stdout/stderr?
2020-11-05 23:29:52 <dalias> do whatever causes the crash then see where it happened from
2020-11-05 23:30:12 <dalias> ok here's where the ioctl thing needs to be fixed: https://hg.mozilla.org/mozilla-central/file/tip/security/sandbox/linux/SandboxFilter.cpp#l1275
2020-11-05 23:30:57 <c705> turning off sandbox fixes the issue
2020-11-05 23:31:37 <dalias> hmm then just strace might show the cause
2020-11-05 23:31:56 <dalias> it's probably something stupid the sandbox is blocking
2020-11-05 23:32:13 <c705> https://termbin.com/d3kn
2020-11-05 23:32:23 <c705> crash as soon as any site is loaded, including static sites
2020-11-05 23:33:31 <c705> let me get you an strace
2020-11-05 23:34:46 <c705> firefox strace out: https://termbin.com/477s
2020-11-05 23:35:53 <dalias> it's truncated
2020-11-05 23:35:55 <dalias> the strace
2020-11-05 23:36:26 <c705> I SIGKILLed firefox after the tab crashed
2020-11-05 23:36:34 <dalias> oh ok
2020-11-05 23:36:49 <dalias> but there's no segfault in the trace
2020-11-05 23:37:04 <dalias> looks like you omitted -f so it only shows the parent process where nothing went wrong
2020-11-05 23:37:07 <c705> it spawns off several procs
2020-11-05 23:37:11 <c705> right, so i need f
2020-11-05 23:38:42 <c705> try this: https://termbin.com/c732p
2020-11-05 23:39:22 <c705> there's no segfault anymore oddly, but tab still crash
2020-11-05 23:43:07 <dalias> hmm hard to see anything since i dont see a crash
2020-11-05 23:43:36 <c705> right, the proc isn't crashing, the tab does
2020-11-05 23:43:54 <c705> setting sandbox = 0 workarounds the issue
2020-11-05 23:45:53 <dalias> but we should see a segfault for the tab
2020-11-05 23:46:27 <dalias> whichever process that was
2020-11-05 23:46:41 <c705> let me dump the conf and try again
2020-11-05 23:47:29 <dalias> prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, NULL) = -1 EFAULT (Bad address)
2020-11-05 23:47:30 <dalias> seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address)
2020-11-05 23:47:44 <dalias> instlaling the seccomp filter seems to have failed ..?
2020-11-05 23:47:53 <c705> it's not segfaulting anymore for unknown reasons
2020-11-05 23:47:58 <c705> what package, I can check
2020-11-05 23:48:58 <dalias> ?
2020-11-05 23:49:05 <dalias> thats in your strace
2020-11-05 23:49:12 <c705> dalias> instlaling the seccomp filter seems to have failed ..?
2020-11-05 23:49:26 <c705> what do you mean? I failed to install the seccomp filter?
2020-11-05 23:49:45 <c705> I'm not a low level programmer
2020-11-05 23:51:09 <dalias> no, firefox startup code installing it in the process
2020-11-05 23:53:48 <dalias> are you sure this strace isn't with sandbox disabled?
2020-11-05 23:55:17 <c705> well, now i'm suspicious because i'm not seeing the segfault
2020-11-05 23:55:28 <c705> I rm -rf ~/.mozilla
2020-11-05 23:55:38 <c705> killall -9 firefox
2020-11-05 23:55:48 <c705> I can go for a reboot and see if I can cause the segfault again
2020-11-05 23:58:23 <dalias> that should not change anything
2020-11-05 23:58:58 <c705> what should not change anything?
2020-11-05 23:59:04 <c705> the reboot, or the removal of .mozilla
2020-11-05 23:59:45 <dalias> reboot
2020-11-06 00:00:35 <c705> well, lets just see
2020-11-06 00:00:37 <c705> give me 5
2020-11-06 00:11:03 <Hello71> dalias: based on the man page I don't think it's valid to install a NULL filter
2020-11-06 00:11:41 <Hello71> so it would seem that *creating* the filter failed
2020-11-06 00:14:19 <dalias> yes looks likely
2020-11-06 00:14:33 <dalias> so now the question is why that failed...
2020-11-06 00:15:00 <dalias> it's like the first thing in main
2020-11-06 00:15:11 <dalias> but firefox has some shitty hg web ui that can't search
2020-11-06 00:15:20 <dalias> and i'm not cloning a 500GB repo to debug this :-p
2020-11-06 00:15:31 <c705> oops so much for 5 minutes
2020-11-06 00:15:36 <c705> give me a sec
2020-11-06 00:15:40 <dalias> k
2020-11-06 00:15:52 <dalias> hello71, is there a searchable clone of firefox source anywhere?
2020-11-06 00:16:39 <c705> it's not segfaulting anymore
2020-11-06 00:16:40 <c705> the hell
2020-11-06 00:16:48 <Hello71> it was mxr.mozilla.org, then it moved to dxr.mozilla.org, now apparently it's searchfox.org
2020-11-06 00:16:54 <c705> oh..
2020-11-06 00:16:57 <Hello71> but I think it should be on github?
2020-11-06 00:17:10 <c705> if i run firefox without strace, i get the segfault, with strace I don't
2020-11-06 00:17:31 <dalias> converting a repo that massive from rad-tool-toy-version-of-git to git would be a huge job i think..
2020-11-06 00:17:40 <Hello71> https://github.com/mozilla/gecko-dev
2020-11-06 00:17:41 <dalias> c705, ick
2020-11-06 00:18:05 <dalias> why would strace perturb it?
2020-11-06 00:18:24 <Hello71> http://web.archive.org/web/20140816030859/https://github.com/mozilla/gecko-dev it's been here since at least 2014
2020-11-06 00:18:52 <dalias> well name is non-obvious and google can't find it..
2020-11-06 00:19:49 <c705> dalias: https://termbin.com/axli
2020-11-06 00:19:52 <Hello71> googling "search firefox source code" brings me to https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Viewing_and_searching_Mozilla_source_code_online which tells you to go to searchfox
2020-11-06 00:20:14 <Hello71> even "firefox source code" works for me on google.com
2020-11-06 00:24:54 <dalias> ffs they do this as a probe and expect it to fail:
2020-11-06 00:24:56 <dalias> https://github.com/mozilla/gecko-dev/blob/eed1f33ab91291d94366a20995ae0b4165f49e02/security/sandbox/linux/SandboxInfo.cpp#L80
2020-11-06 00:27:02 <Hello71> it seems reasonable, since you can't remove filters
2020-11-06 00:27:12 <Hello71> otherwise you would have to fork a subprocess which is even worse
2020-11-06 00:27:31 <Hello71> or live with runtime overhead for the remainder of your process
2020-11-06 00:27:40 <dalias> yeah
2020-11-06 00:27:46 <Hello71> probably not very much, but still
2020-11-06 00:36:17 <c705> dalias: you want anything else from me? i'm going back to v3.12
2020-11-06 00:36:45 <dalias> i'd love to see a meaningful strace or bt but it looks like it's hard to get ..?
2020-11-06 00:37:13 <dalias> i see a lot of ENOMEM
2020-11-06 00:37:20 <dalias> is it possible you're just running out of memory
2020-11-06 00:37:35 <c705> i am most certianly not
2020-11-06 00:37:41 <c705> i have >60GB free
2020-11-06 00:38:22 <c705> i still don;t know what you mean by bt. I gave you stderr/out from the command after the tab crash
2020-11-06 00:38:33 <c705> if you specifically tell me what I need to do, I can get you output
2020-11-06 00:39:51 <dalias> backtrace, bt command in gdb
2020-11-06 00:40:28 <dalias> but that requires getting a process to crash under gdb (or getting a core file, maybe)
2020-11-06 00:40:33 <dalias> but i suspect it's just OOM'ing
2020-11-06 00:40:47 <c705> dalias: Mem[||||                           2.68G/62.7G]
2020-11-06 00:40:52 <dalias> the syslog is full of ENOMEM failures
2020-11-06 00:40:53 <c705> no idea why OOM would be doing anything
2020-11-06 00:41:00 <dalias> erm
2020-11-06 00:41:01 <dalias> strace
2020-11-06 00:41:05 <dalias> not syslog
2020-11-06 00:41:06 <dalias> sorry wrong word
2020-11-06 00:41:27 <dalias> maybe it's too many VMAs
2020-11-06 00:41:56 <c705> VMAs?
2020-11-06 00:42:31 <c705> look, someone's code changed after Oct 20 or so. I really don't think it's anything to do with my setup
2020-11-06 00:43:27 <Hello71> iirc there shouldn't be a hard limit on VMAs (on 64-bit)?
2020-11-06 00:43:56 <c705> i ran firefox under gdb, but I don't get a prompt as the code is still running when I hit tab crash
2020-11-06 00:44:02 <c705> let me step
2020-11-06 00:45:12 <c705> can't get a bt, as far as the debugger is concerned everything is fine
2020-11-06 00:45:30 <Hello71> regarding the ENOMEM, I'm pretty sure that's jemalloc or firefox weirdness. note that flags=0 and the addresses step down until EFAULT
2020-11-06 00:45:39 <dalias> hello71, default limit is 64k VMAs
2020-11-06 00:45:44 <Hello71> huh.
2020-11-06 00:46:12 <Hello71> isn't that a problem if you have a huge amount of memory
2020-11-06 00:46:19 <dalias> not really
2020-11-06 00:46:31 <dalias> amount of memory you have isn't really related
2020-11-06 00:48:26 <Hello71> well if you mmap all mallocs above 1 MB then isn't that only 64 GB of memory allocated
2020-11-06 00:48:59 <Hello71> assuming that for some reason your application uses very large amounts of memory but not its own object pool
2020-11-06 00:49:37 <Hello71> er, assuming you mmap all mallocs above 1 MB, and you only make allocations of exactly 1 MB
2020-11-06 00:50:18 <c705> like i said, i've used this machine since July and things were fine until musl 1.2 or in and around that time
2020-11-06 00:50:47 <dalias> hello71, no. only if you free in a really weird pattern to split them all up
2020-11-06 00:50:50 <dalias> otherwise it's only one vma
2020-11-06 00:51:36 <dalias> try increasing /proc/sys/vm/max_map_count  (what is it now?)
2020-11-06 00:51:49 <c705> is that for me?
2020-11-06 00:51:59 <Hello71> I don't follow
2020-11-06 00:51:59 <dalias> yes
2020-11-06 00:52:07 <c705> 65530
2020-11-06 00:52:17 <dalias> btw do you have a normal kernel? or some modified one?
2020-11-06 00:52:35 <c705> 5.9.4-1
2020-11-06 00:52:42 <c705> linux0edge from alpine
2020-11-06 00:53:03 <c705> I have a custom init that loads vfio
2020-11-06 00:53:44 <c705> my cmdline is a bit baudy but hasn't caused issues as of yet, and other people are running into this, so I'm hesitent to blame that
2020-11-06 00:53:53 <dalias> vfio?
2020-11-06 00:53:57 <Hello71> how can malloc merge mmaps post-facto? or does it expand any mmap already given out
2020-11-06 00:54:03 <dalias> look at /proc/{each pid of firefox}/maps
2020-11-06 00:54:06 <dalias> how many lines are they?
2020-11-06 00:54:19 <c705> vfio is a module
2020-11-06 00:54:20 <dalias> hello71, vmas always merge/split
2020-11-06 00:54:26 <c705> nothing to do with firefox
2020-11-06 00:54:37 <Hello71> oh, right, they're merged in the kernel
2020-11-06 00:54:41 <Hello71> totally forgot about that
2020-11-06 00:55:08 <Hello71> which I guess is why munmap takes a length argument
2020-11-06 00:55:15 <c705> parent: 1068 /proc/2903/maps
2020-11-06 00:55:35 <dalias> as long as it's well under 64k, hitting VMA limit shouldn't be the problem
2020-11-06 00:55:35 <c705> child (Web Content) (Tab): 541 /proc/3137/maps
2020-11-06 00:56:26 <dalias> could there me cgroup resource limits or ulimit (setrlimit) resource limits ?
2020-11-06 00:56:46 <dalias> because for some reason mremap is failing with ENOMEM
2020-11-06 00:57:19 <dalias> oddly, mmap is succeeding while mremap fails...
2020-11-06 00:57:25 <dalias> so maybe this is a kernel bug
2020-11-06 00:57:30 <c705> I doubt it
2020-11-06 00:57:35 <c705> Nothing that i'm aware of
2020-11-06 00:57:42 <c705> Just running /usr/bin/firefox dry
2020-11-06 00:58:05 <c705> my firejail profile is failing but that's a different issue. I am not running with seccomp or cgroups
2020-11-06 00:59:16 <Hello71> dalias: flags=0, so ~MREMAP_MAYMOVE
2020-11-06 00:59:18 <dalias> ahhh no these mremaps are checking stack size
2020-11-06 00:59:19 <dalias> never mind
2020-11-06 00:59:33 <Hello71> unless there's something not mremap that's failing (I didn't check)
2020-11-06 01:00:18 <dalias> so this isn't the problem
2020-11-06 01:00:25 <dalias> it's intending to get ENOMEM
2020-11-06 01:05:57 <dalias> sorry for that distraction
2020-11-06 05:15:32 <maxice8> x86, x86_64 and s390x CI seems to be out of space
2020-11-06 05:44:11 <ikke> hmm, I guess we forgot to place the cleanup crons there
2020-11-06 05:44:14 <ikke> cleaning up now
2020-11-06 05:54:54 <ikke> maxice8: those hosts should have plenty of space again
2020-11-06 06:12:23 <maxice8> thanks
2020-11-06 06:15:07 <craftyguy> any chance someone could review this please? if it's wrong I'd like to fix it / get it merge-able, since the problem it is solving is fairly annoying on mobile devices :)
2020-11-06 06:15:09 <craftyguy> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14201
2020-11-06 06:17:18 <craftyguy> (I just rebased it which is why CI is chewing on it)
2020-11-06 11:31:27 <Cogitri> Is there something we can do about things OOM'ing on CI?
2020-11-06 11:31:38 <Cogitri> Other than just limiting the amount of jobs in the APKBUILD
2020-11-06 11:33:49 <maxice8> https://www.cogitri.dev/posts/11-update-apkbuild/
2020-11-06 11:34:19 <ikke> Cogitri: I'm not aware of any other way
2020-11-06 11:35:30 <ikke> maxice8: Have some basic support now for tracking the run-time value of variables: https://gitlab.alpinelinux.org/kdaudt/atools-go/-/blob/implement/pkg/atools/parser.go#L14
2020-11-06 11:36:06 <maxice8> What does that mean exactly ?
2020-11-06 11:36:41 <ikke> for example, for AL1, we need to know the current value of builddir
2020-11-06 11:37:04 <ikke> statically, it would containl "$pkgdir-$pkgver"
2020-11-06 11:37:14 <ikke> the run-time value is "pkgname-1.2.3"
2020-11-06 11:37:26 <ikke> s/pkgdir/pkgname/
2020-11-06 11:37:26 <alpine-meetbot> ikke meant to say: statically, it would containl "$pkgname-$pkgver"
2020-11-06 11:38:58 <ikke> https://gitlab.alpinelinux.org/kdaudt/atools-go/-/blob/implement/pkg/atools/parser_test.go#L65
2020-11-06 11:40:28 <maxice8> but I think we can check that statically
2020-11-06 11:40:45 <maxice8> just check that the static string is builddir="$srcdir"/$pkgname-$pkgver
2020-11-06 11:41:16 <maxice8> I get the general idea though, we want to expand variables in some places
2020-11-06 11:43:50 <ikke> seems here you check for the run-time value: https://gitlab.alpinelinux.org/Leo/atools/-/blob/master/apkbuild-lint#L214 (though, probably the only way to do that)
2020-11-06 11:47:20 <maxice8> Yes but it is only natural that way
2020-11-06 11:47:33 <maxice8> otherwise i'd have to to do fancy regexes
2020-11-06 11:48:09 <ikke> But using the run-time value, it's more generic
2020-11-06 11:49:41 <maxice8> yes
2020-11-06 11:49:42 <maxice8> it is
2020-11-06 11:50:26 <ikke> But anyhow, it's not that hard to track the state of variables
2020-11-06 11:50:35 <ikke> as long as they don't rely on executing things
2020-11-06 11:53:59 <ikke> So now I wonder, do we want to go further with this for atools?
2020-11-06 11:56:17 <maxice8> You decide
2020-11-06 12:01:49 <ikke> Well, I want something that is acceptable for more than just me :)
2020-11-06 12:02:07 <ikke> and maintainable for more than just me
2020-11-06 12:02:15 <ikke> s/for/by
2020-11-06 12:02:16 <alpine-meetbot> ikke meant to say: and maintainable by more than just me
2020-11-06 12:03:07 <mps> ikke: write it in lua or perl
2020-11-06 12:03:46 <mps> we have miniperl at the end
2020-11-06 12:03:58 <ikke> I have little interest in learning perl atm
2020-11-06 12:05:06 <mps> heh, I understand you, but you miss a very good scripting tool
2020-11-06 12:05:30 <ikke> And ncopa showed interest in using go as an infra language
2020-11-06 12:05:45 <mps> meh
2020-11-06 12:05:58 <ikke> And having something statically compiled is compelling to me atm
2020-11-06 12:06:03 <ikke> I mean
2020-11-06 12:06:05 <ikke> statically typed
2020-11-06 12:06:08 <mps> better than rust, I can agree :)
2020-11-06 12:07:02 <ikke> And having a readily available complete shell parser is nice (though, they might be available as well in other languages)
2020-11-06 12:07:37 <mps> hmmm, unix admins must learn perl, imo
2020-11-06 12:08:04 <insep_> mps: s/unix/debian/g
2020-11-06 12:08:04 <alpine-meetbot> insep_ thinks mps meant to say: hmmm, debian admins must learn perl, imo
2020-11-06 12:08:05 <insep_> :D
2020-11-06 12:08:13 <mps> but ok, who am I to tell you what you will do
2020-11-06 12:09:29 <mps> 
ACTION doesn't talk with people over matrix gateways ;P

2020-11-06 12:10:17 <ikke> lol
2020-11-06 12:11:26 <mps> ikke: imo, go-lang have strange idea how regex works, though it works in go-lang
2020-11-06 12:12:13 <ikke> lua as well :P
2020-11-06 12:13:06 <mps> how long I wrestled with iso8601 go datetime to understand why it use constant, till asked on ML and Pike told secret :)
2020-11-06 12:13:25 <timlegge> I have some pkgs that I want to move from testing to community that are waiting on perl-b-debug on s390 bulds - should I simply submit the MRs now even though it will fail on s390?
2020-11-06 12:14:15 <mps> ikke: what is that constant in go '2006-01-02T15:04:05'
2020-11-06 12:14:30 <mps> timlegge: no need for new MRs
2020-11-06 12:14:45 <ikke> mps: I think that mr for perl-b-debug was already merged
2020-11-06 12:14:56 <ikke> mps: I think it's something like the first commit for golang?
2020-11-06 12:15:19 <mps> Pikes daughter birthday :)
2020-11-06 12:15:21 <ikke> aha
2020-11-06 12:15:49 <timlegge> yes, the trouble is the other pkgs I want to move have it as a dependency andy it is not in the s390 builds yet
2020-11-06 12:16:03 <timlegge> s/andy/and/
2020-11-06 12:16:03 <alpine-meetbot> timlegge meant to say: yes, the trouble is the other pkgs I want to move have it as a dependency and it is not in the s390 builds yet
2020-11-06 12:16:53 <timlegge> so the pipeline on the MRs will fail for S390
2020-11-06 12:18:54 <ikke> timlegge: I think it's ok to submit an MR for it, and mention it in the description that you expect it to fail. This is just moving the packages, right?
2020-11-06 12:19:02 <timlegge> yes
2020-11-06 12:19:06 <timlegge> thanks
2020-11-06 12:19:31 <ikke> So the risk of failure to build these packages on s390x is relatively low then
2020-11-06 12:20:45 <timlegge> yes, there are no real dependancies on anything strange :-) They have built previouslu on s390 and I expect them to again once the blockers on s390 are fixed
2020-11-06 12:21:00 <ikke> nod
2020-11-06 12:21:24 <mps> ah, timlegge didn't created MRs for move. sorry I misunderstood
2020-11-06 12:28:04 <timlegge> !14063 is an example of the issue
2020-11-06 12:38:59 <mps> timlegge: merged
2020-11-06 13:02:17 <timlegge> thanks mps
2020-11-06 13:02:31 <timlegge> I will have a few more like that later today
2020-11-06 13:17:36 <maxice8> huh
2020-11-06 13:17:40 <maxice8> can someone confirm a possible bug for me
2020-11-06 13:18:03 <maxice8> apk add --virtual .pkg cmd:column ; apk add util-linux-dev ; apk add del util-linux-dev
2020-11-06 13:19:40 <mps> timlegge: I have in local repo complete suite of https://metacpan.org/release/Mail-Box for some work on alpine infra. is it useful for wider alpine 'audience', what is your opinion
2020-11-06 13:20:36 <mps> maxice8: first time I see 'add' and 'del' at the same time for apk
2020-11-06 13:26:24 <timlegge> mps: it is being actively maintained with regular releases - I don't hane anything that uses it but certainly others might.  Comes down to whether it makes things easier for you if its a prebuilt package
2020-11-06 13:27:07 <timlegge> perl does not have the wide use it once had but it is still very useful
2020-11-06 13:29:10 <mps> ikke: ^ :)
2020-11-06 13:30:53 <mps> https://xkcd.com/224/
2020-11-06 13:30:53 <alpine-meetbot> https://xkcd.com/224 | Lisp | Alt-text: We lost the documentation on quantum mechanics.  You'll have to decode the regexes yourself.
2020-11-06 13:34:28 <ikke> mps: :)
2020-11-06 13:35:10 <timlegge> mps: nice
2020-11-06 13:49:48 <maxice8> @Cogitri I think I dealt with all the 30+ days MRs
2020-11-06 13:54:14 <maxice8> opinions ? !13852
2020-11-06 13:54:59 <Cogitri> maxice8: Neat
2020-11-06 13:55:10 <Cogitri> ikke: Wanna look into deploying the Gitlab bot already? :D
2020-11-06 13:55:43 <mps> maxice8: to repeat, do it
2020-11-06 13:56:42 <mps> but does then mesa have to be moved also
2020-11-06 13:56:58 <Cogitri> maxice8: The bot still finds 3 MRs: !10803
2020-11-06 13:57:09 <Cogitri> !10428
2020-11-06 13:57:12 <maxice8> oh yeah I forgot that one
2020-11-06 13:57:16 <Cogitri> And !869
2020-11-06 13:57:16 <ikke> Cogitri: tonight
2020-11-06 13:57:21 <Cogitri> But that might be good for testing things actually
2020-11-06 13:57:29 <Cogitri> Err !8569
2020-11-06 13:57:41 <maxice8> wait, the alpine-qa-bot can just tell the ones that are older than 30 days ?
2020-11-06 13:57:46 <maxice8> So all the sorting I did was in vain ?
2020-11-06 13:57:53 <ikke> lol
2020-11-06 13:57:56 <maxice8> I'm not touching !8569
2020-11-06 13:58:03 <Cogitri> Same here
2020-11-06 13:58:41 <Cogitri> maxice8: I think gitlab can sort by last updated, no?
2020-11-06 13:58:49 <maxice8> yes
2020-11-06 13:59:09 <ikke> I always view issues by last updated :P
2020-11-06 13:59:17 <ikke> and MRs as well
2020-11-06 13:59:41 <Cogitri> And the gitlab bot doesn't list the MRs itself, I just stepped through the part where it gets the MRs with the debugger
2020-11-06 13:59:46 <Cogitri> (Which is pretty amazing in Go btw :D)
2020-11-06 13:59:55 <mps> ikke: also I
2020-11-06 14:00:11 <Cogitri> Very weird to suddenly have a functional debugger after using gdb w/ C++ for so long
2020-11-06 14:00:36 <ikke> Cogitri: What do you use for debugging? delve?
2020-11-06 14:00:59 <Cogitri> Uhh, whatever VSCode uses by default 😅
2020-11-06 14:01:08 <ikke> oh, heh
2020-11-06 14:02:21 <mps> and we wonder why linux can't achieve goal to be 'one true desktop' :)
2020-11-06 14:43:18 <maxice8> There is a now approval mechanism in gitlab
2020-11-06 14:43:22 <maxice8> you can approve a merge request
2020-11-06 14:43:33 <ikke> yes
2020-11-06 14:43:35 <ikke> optionally
2020-11-06 14:43:37 <ikke> but yes
2020-11-06 14:43:48 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14369
2020-11-06 14:43:57 <ikke> Came with 13.2 :)
2020-11-06 14:46:11 <ikke> maxice8: lol
2020-11-06 16:55:37 <mps> ikke: !14370
2020-11-06 16:55:52 <mps> maybe can be useful on builders
2020-11-06 16:57:23 <ikke> From the description alone, I don't see how that helps?
2020-11-06 16:58:06 <mps> monitors stalled threads and can take actions
2020-11-06 16:58:27 <ikke> Doesn't being stalled mean that they are not being scheduled?
2020-11-06 16:58:38 <mps> yes
2020-11-06 16:58:48 <ikke> Do we have processes that are stalled?
2020-11-06 16:59:45 <mps> I don't know for builders but from different discussion I 'concluded' we have
2020-11-06 17:00:07 <ikke> I'm not sure that stuck build processes are necesarily considered stalled
2020-11-06 17:00:47 <mps> hmm, sorry then for annoyance
2020-11-06 17:00:55 <ikke> You are not anoying
2020-11-06 17:01:09 <ikke> https://www.phoronix.com/scan.php?page=news_item&px=New-Stalld-Releases
2020-11-06 17:01:42 <ikke> It affects the scheduler
2020-11-06 17:01:49 <ikke> which is not our issue
2020-11-06 17:02:04 <mps> aha, and already have 1.2 version
2020-11-06 17:02:07 <ikke> What we often have is deadlocks
2020-11-06 17:02:25 <ikke> Typically one process is in a busy loop
2020-11-06 17:02:33 <mps> heh, then we have find deadlockd somewhere
2020-11-06 17:04:04 <ikke> mps: and failedbuildd as well?
2020-11-06 17:04:14 <mps> or 'stuckd' :)
2020-11-06 17:04:17 <ikke> heh
2020-11-06 17:04:32 <ikke> fixbuildd
2020-11-06 17:05:56 <mps> these stuck processes could be found by 'ps' greping in loop with some timeout, and kill
2020-11-06 17:06:46 <mps> maybe
2020-11-06 17:06:58 <mps> didn't thought of that
2020-11-06 17:07:11 <ikke> until it kills the builder :P
2020-11-06 17:10:04 <mps> anyway, stalld looks as useful tool, I will not delete it, maybe even add -openrc and conf for it
2020-11-06 17:11:06 <mps> it is interesting to run it on 64 cpu machine and look :)
2020-11-06 18:16:46 <ikke> Cogitri: ping
2020-11-06 18:17:16 <Cogitri> ikke: Pong
2020-11-06 18:20:10 <ikke> Cogitri: You asked me to deploy aports-qa-bot
2020-11-06 18:21:08 <Cogitri> Yes
2020-11-06 18:21:27 <ikke> We didn't deploy it yet, right? Only on the test instance?
2020-11-06 18:21:53 <Cogitri> Yes, we tested it on the test instance once
2020-11-06 18:21:58 <Cogitri> But that was the old one
2020-11-06 18:22:31 <ikke> nod
2020-11-06 18:23:35 <ikke> So I should just be able to deploy https://gitlab.alpinelinux.org/alpine/infra/compose/aports-qa-bot, correct?
2020-11-06 18:24:38 <ikke> And what user do we use for this?
2020-11-06 18:24:51 <Cogitri> Yup. I'm not entirely sure how it'd integrate with traefik or something, right now it just listens on port 80, you probably want a HTTPS reverse proxy in front of it
2020-11-06 18:25:25 <Cogitri> Some user that has enough access to manipulate MRs (e.g. enable collaboration)
2020-11-06 18:25:50 <ikke> I guess algitbot then, like we have in the past
2020-11-06 18:25:54 <Cogitri> Yup
2020-11-06 18:26:46 <Cogitri> Right now it only ticks the "Remove source branch" and "Allow collaboration" (rebase) boxes and comments on MRs older than 30 days (and sets a stale label)
2020-11-06 18:26:47 <ikke> for traefik integration, we use labels
2020-11-06 18:28:37 <Cogitri> Okie dokie, I guess that's not something that has to be done in the aports-qa-bot docker-compose?
2020-11-06 18:29:18 <ikke> We typically have done so (ie, I did the same for appstream-generator), but I've read the other day that you can have a 'local' compose file as well, so I'm looking into that
2020-11-06 18:32:12 <Cogitri> Okie, I wouldn't mind adding it to the docker-compose, I just didn't know how to add it
2020-11-06 18:33:11 <ikke> yeah, but ideally it's not part of the main compose file, as it could be deployed multiple times in different settings
2020-11-06 18:33:54 <ikke> https://medium.com/it-dead-inside/making-sense-of-docker-compose-overrides-efb757460d64
2020-11-06 18:36:01 <ikke> Cogitri: https://tpaste.us/jnxq
2020-11-06 18:38:08 <Cogitri> Oh right
2020-11-06 18:39:18 <Cogitri> Actually, I guess I should rebuild the docker image
2020-11-06 18:40:02 <Cogitri> I guess I just restart the CI pipeline for infra/docker/aports-qa-bot ?
2020-11-06 18:40:31 <ikke> Why rebuild the docker image?
2020-11-06 18:40:41 <ikke> This is just an issue with the docker-compose file
2020-11-06 18:41:03 <Cogitri> Ah no, I mean I also did changes to the bot
2020-11-06 18:41:15 <ikke> ah
2020-11-06 18:41:34 <Cogitri> And the docker image still uses the old version
2020-11-06 18:42:11 <ikke> You can use "run pipeline" here
2020-11-06 18:42:15 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/aports-qa-bot/-/pipelines
2020-11-06 18:42:29 <Cogitri> Ah yes, did that, thanks
2020-11-06 18:43:00 <Cogitri> Would be nice if the Pipeline automatically rebuilt for tags in the bot repo
2020-11-06 18:43:09 <ikke> Ideally we do want a bit of versioning though, in case we want to revert
2020-11-06 18:43:17 <ikke> Cogitri: should be possible
2020-11-06 18:43:59 <ikke> https://docs.gitlab.com/ee/ci/parent_child_pipelines.html
2020-11-06 18:44:01 <Cogitri> Ah sure, I guess instead of just tagging :latest always we could tag :$version and make :latest point ot that
2020-11-06 18:45:18 <ikke> Cogitri: https://tpaste.us/DMDq this is the merged config (I've added a docker-compose.override.yml)
2020-11-06 18:45:36 <ikke> Well, without changing the domain yet :P
2020-11-06 18:46:02 <Cogitri> Ah yes, was a bit curious what the appstream stuff was for :D
2020-11-06 18:46:13 <Cogitri> lgtm otherwise
2020-11-06 18:46:31 <ikke> I copied the config from appstream
2020-11-06 18:46:49 <ikke> aports-qa-bot.alpinelinux.org?
2020-11-06 18:47:14 <Cogitri> Sounds good
2020-11-06 18:47:26 <ikke> I don't suppose there is some kind of dry-run we can do?
2020-11-06 18:47:51 <Cogitri> Well, either we deploy it to the test instance
2020-11-06 18:48:00 <Cogitri> Or I can add a switch for that to the bot
2020-11-06 18:48:03 <Cogitri> Let me do that
2020-11-06 18:48:50 <ikke> So is there a part that is actively checking things, and a part that reacts to webhooks?
2020-11-06 18:49:41 <ikke> added the domain name
2020-11-06 18:49:43 <Cogitri> There is a server, which listens for webhooks notifications and a poller that polls every $POLLERCRON
2020-11-06 18:50:07 <Cogitri> Both generate *Job objects and all of them have a Process method that actually does all the things
2020-11-06 18:51:14 <Cogitri> E.g. the bot receives a merge request webhook notification, so it generates a MergeRequestJob and then it calls MergeRequestJob.Process() which checks if the MR is open and new and then checks the allow rebase thingie
2020-11-06 18:51:29 <ikke> yes, understood
2020-11-06 18:51:44 <ikke> and the cronjob is to be able to close tasks that are too old (or to label them)
2020-11-06 18:52:13 <Cogitri> Yes, it labels them
2020-11-06 19:12:49 <Cogitri> OK, added `DryRun` toggle to the config, currently building new docker image
2020-11-06 19:13:16 <ikke> ok
2020-11-06 19:13:28 <ikke> I'm fighting seting up 2fa for algitbot :(
2020-11-06 19:13:48 <ikke> For some reason I keep getting invalid pin code
2020-11-06 19:14:34 <Cogitri> Huh, after scanning the QR-Code?
2020-11-06 19:14:40 <ikke> yes
2020-11-06 19:15:25 <Cogitri> Weird
2020-11-06 19:15:55 <ikke> Maybe because I'm impersonating algitbot?
2020-11-06 19:16:17 <Cogitri> Ah, not sure how it works in that case
2020-11-06 19:16:34 <Cogitri> OK, new docker image is pushed, added config switch to docker-compose repo (so make sure to pull both)
2020-11-06 19:17:17 <Cogitri> DryRun should be true by default now in the compose
2020-11-06 19:17:25 <ikke> ok
2020-11-06 19:18:22 <ikke> next feature request :P
2020-11-06 19:18:31 <ikke> local config file that's not tracked
2020-11-06 19:20:53 <Cogitri> Hm, not sure I what I would need to add for that, I just put it in the docker-compose repo so it's all in one place
2020-11-06 19:21:52 <ikke> The config.json
2020-11-06 19:22:06 <ikke> Now I need to adjust the FILLMEIN fields
2020-11-06 19:22:19 <ikke> if you update the conf file, I'd need to somehow merge that
2020-11-06 19:22:31 <Cogitri> Ah yes, but I don't see the alternative to that?
2020-11-06 19:22:36 <Cogitri> But I'm a bit slow today :)
2020-11-06 19:24:01 <ikke> https://pkg.go.dev/github.com/RaveNoX/go-jsonmerge ?
2020-11-06 19:24:46 <Cogitri> Ah, so a default JSON config and then a conf.json.override ?
2020-11-06 19:24:49 <Cogitri> Got it
2020-11-06 19:27:16 <ikke> nod
2020-11-06 19:27:23 <ikke> conf.override.json :)
2020-11-06 19:27:27 <Cogitri> Ah yes :)
2020-11-06 19:27:35 <Cogitri> Gonna look into that tomorrow, thanks for the idea
2020-11-06 19:27:40 <ikke> Sure, no problem
2020-11-06 19:29:58 <ikke> sigh
2020-11-06 19:37:51 <Cogitri> No luck on 2FA?
2020-11-06 19:38:12 <ikke> nope
2020-11-06 19:38:57 <Cogitri> :c
2020-11-06 19:47:51 <ikke> I went the evil route
2020-11-06 19:48:29 <yZ5vlALg86lP> you deleted the wiki?
2020-11-06 19:48:43 <ikke> You can verify that yourself
2020-11-06 19:51:29 <ikke> Ok, now I can properly setup 2FA as well
2020-11-06 19:53:26 <ikke> Cogitri: managed it :)
2020-11-06 19:55:23 <Cogitri> Nice 👌
2020-11-06 19:56:43 <ikke> ok, started the container
2020-11-06 19:56:51 <ikke> aports-qa-bot_1  | 2020/11/06 19:56:30 Polling for changes..
2020-11-06 19:57:21 <maxice8> :D
2020-11-06 19:58:02 <ikke> It's still in dry-run mode :P
2020-11-06 19:58:10 <ikke> Cogitri: should I see more output?
2020-11-06 20:00:32 <ikke> Another one
2020-11-06 20:02:42 <Cogitri> It only polls once an hour by default and you need to set-up the webhook for things to happen there
2020-11-06 20:02:52 <ikke> ah ok
2020-11-06 20:02:57 <Cogitri> You should see a log entry about new MRs
2020-11-06 20:03:02 <ikke> so the polling thing only looks for old MRs?
2020-11-06 20:03:56 <Cogitri> Yup
2020-11-06 20:03:59 <Cogitri> At least for now
2020-11-06 20:04:19 <ikke> ok
2020-11-06 20:04:34 <ikke> hmm, getting gateway timeout on aports-qa-bot.alpinelinux.org
2020-11-06 20:05:03 <Cogitri> /triage/system-hooks
2020-11-06 20:06:06 <ikke> same
2020-11-06 20:07:10 <Cogitri> Huh
2020-11-06 20:07:20 <Cogitri> That works for me locally 🤔
2020-11-06 20:07:29 <ikke> This is going through traefik
2020-11-06 20:08:43 <ikke> Oh, maybe I might have forgotten something
2020-11-06 20:10:22 <ikke> fixed
2020-11-06 20:10:56 <ikke> {"message":"FAIL"}
2020-11-06 20:11:46 <ikke> Cogitri: What should I put as the webhook url?
2020-11-06 20:15:55 <ikke> 2020/11/06 20:15:29 Got Hook-Notification with invalid Token: "...."
2020-11-06 20:16:13 <ikke> I've verified that's the token that I set as AuthenticationToken
2020-11-06 20:18:03 <Cogitri> Needs to be GitlabToken
2020-11-06 20:18:14 <ikke> ah, then I swapped them
2020-11-06 20:18:24 <Cogitri> authentication token is the API token
2020-11-06 20:18:32 <Cogitri> not amazing naming from my partthere I have to admit :)
2020-11-06 20:18:50 <ikke> :P
2020-11-06 20:19:44 <ikke> aports-qa-bot_1  | 2020/11/06 20:19:25 Labeling MR 10428 of project 1 as stale and pinging user 'Thermi'. Suggesting assignee 'alpine-developers' as contact person.
2020-11-06 20:20:13 <ikke> ok, so it's working now
2020-11-06 20:20:33 <Cogitri> Nice
2020-11-06 20:21:37 <ikke> So then I can set dry-run to false, correct?
2020-11-06 20:23:15 <Cogitri> Yup, should work then, I suppose
2020-11-06 20:25:08 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10428
2020-11-06 20:25:43 <ikke> Cogitri: The team you suggest is incorrect btw
2020-11-06 20:26:28 <ikke> it's just @developers
2020-11-06 20:29:37 <Cogitri> Oh
2020-11-06 20:29:57 <ikke> I'm trying to find where that comes from
2020-11-06 20:30:42 <ikke> It uses MergeRequestAssignee, but it seems no one is assigned
2020-11-06 20:31:01 <Cogitri> Ah no, that's the fallback if there's not asignee
2020-11-06 20:31:06 <ikke> ah
2020-11-06 20:31:08 <Cogitri> I just hardcoded that wrong
2020-11-06 20:31:39 <Cogitri> Thanks for noticing :)
2020-11-06 20:34:45 <ikke> I really like that override thing in compose
2020-11-06 20:34:57 <ikke> Allows for nice separation of concerns
2020-11-06 20:38:49 <Cogitri> Yup
2020-11-06 20:39:29 <ikke> so now I don't have to modify the docker-compose file you provide anymore
2020-11-06 20:52:15 <ikke> Cogitri: btw, you only need merge request hooks, right?
2020-11-06 20:54:01 <Cogitri> Yup
2020-11-06 20:55:11 <ikke> alright
2020-11-06 21:16:42 <Cogitri> Thanks for doing the deployment 👍
2020-11-06 21:17:44 <ikke> yw
2020-11-06 21:17:58 <ikke> thanks for building aports-qa-bot :)
2020-11-06 21:37:06 <Newbyte> 
ACTION uploaded an image: image.png (10KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/NmnqgLEfHFNSFYSoJRDXcvPN/image.png >

2020-11-06 21:37:15 <Newbyte> do you guys have an idea what this might be about?
2020-11-06 21:38:02 <Newbyte> trying to create a package for github.com/desktop-app/tg_owt as Telegram has it as dependency but it fails at 96% compilation with this error
2020-11-06 21:38:59 <ikke> "recompile with -fPIC"
2020-11-06 21:39:07 <Cogitri> The compiler suggests something :)
2020-11-06 21:40:03 <Newbyte> yes, but I'm not sure how I'd integrate that into the CMake build system
2020-11-06 21:40:04 <maxice8> Newbyte: isn't it included in the full tarball for telegram-desktop ?
2020-11-06 21:40:43 <Newbyte> good question! I noticed that it fails to build because it cannot find tg_owt but I'll look into that
2020-11-06 21:42:03 <Newbyte> I don't see it in there at least
2020-11-06 21:42:31 <Cogitri> export CFLAGS="$CFLAGS -fPIC"
2020-11-06 21:42:41 <Cogitri> Or CXXFLAGS if it's C++
2020-11-06 21:42:46 <Newbyte> oh, thank you!
2020-11-06 22:00:31 <Newbyte> that did it, thank you
2020-11-06 22:00:55 <Cogitri> 👍
2020-11-07 05:47:22 <maxice8> objections !13852 ?
2020-11-07 08:42:26 <Newbyte> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/QChvJFhtvZLYUSnRYewTWaiu/message.txt >

2020-11-07 08:42:46 <Newbyte> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/jfXIjYrwUQdaETmntvcSuDHN/message.txt >

2020-11-07 08:43:41 <Newbyte> !14384 btw
2020-11-07 08:44:08 <mps> Newbyte: it is IRC, please
2020-11-07 08:44:10 <maxice8> Please use a paste service
2020-11-07 08:44:36 <ikke> Newbyte: what mps is referring to is that irc does not support multiline messages, so your entire message is sent as a link
2020-11-07 08:44:47 <ikke> Newbyte sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/QChvJFhtvZLYUSnRYewTWaiu/message.txt >
2020-11-07 08:45:42 <Newbyte> didn't know about that, thanks for the heads-up
2020-11-07 08:45:47 <Newbyte> https://paste.centos.org/view/af779ed0
2020-11-07 08:46:28 <Newbyte> this is just an excerpt, I can send the entire thing if relevant (though you can also check the MR)
2020-11-07 08:47:27 <ikke> https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
2020-11-07 08:48:50 <Newbyte> thank you!
2020-11-07 09:25:48 <Newbyte> do I understand it right that it is a hard requirement for there to be no textrels in object code in Alpine packages?
2020-11-07 09:26:36 <ikke> Newbyte: if abuild errors out on it, then yes
2020-11-07 09:27:53 <Newbyte> would it be acceptable to tell it to not build for x86 as an interim solution?
2020-11-07 09:28:00 <ikke> yes, certainly
2020-11-07 09:28:09 <ikke> arch="all !x86"
2020-11-07 09:28:13 <ikke> with an explenation
2020-11-07 09:28:21 <Newbyte> 👍️
2020-11-07 09:28:23 <ikke> arch="all !x86" # x86: contains textrels
2020-11-07 09:30:22 <Newbyte> I'm starting to see why distributions are dropping x86
2020-11-07 09:30:37 <ikke> We still try to support it
2020-11-07 09:31:29 <ikke> Sometimes it's just a matter of notifying upstream
2020-11-07 09:33:24 <Newbyte> Yeah, I'll file an issue
2020-11-07 11:45:07 <maxice8> huh, gitlab has scoped labels
2020-11-07 11:45:20 <maxice8> foo::bar::baz
2020-11-07 11:45:49 <ikke> hmm
2020-11-07 11:46:01 <ikke> I've heard of scoped labels, but never looked into them
2020-11-07 11:46:05 <ikke> What does it allow/
2020-11-07 11:46:08 <ikke> ?
2020-11-07 11:46:31 <maxice8> Don't think much for us
2020-11-07 11:46:40 <maxice8> it allows mutually exclusive labels
2020-11-07 11:47:07 <ikke> Aha, doesn't that mean it *is* interesting for us?
2020-11-07 11:47:25 <maxice8> foo::bar and foo::baz can't exist at the same time
2020-11-07 11:47:28 <maxice8> so you can have
2020-11-07 11:47:46 <maxice8> review::waiting, review::feedback, review::ready
2020-11-07 11:47:47 <ikke> status::confirmed and status::unconfirmed
2020-11-07 11:47:48 <ikke> yes
2020-11-07 11:48:47 <insep_> difficulty::easy and difficulty::complex
2020-11-07 11:48:57 <insep_> de::gnome and de::kde
2020-11-07 11:48:58 <insep_> :D
2020-11-07 11:49:18 <maxice8> you're not thinking big enough
2020-11-07 11:49:34 <maxice8> you can have more than one ::
2020-11-07 11:50:50 <maxice8> @Cogitri there is a nice feature for alpine-qa-bot, automatically apply labels when the MR is created
2020-11-07 11:51:37 <insep_> de::gnome::gnome and de::gnome::phosh
2020-11-07 11:51:45 <insep_> oh dear god
2020-11-07 11:57:33 <Cogitri> maxice8: Mind creating an issue for that?
2020-11-07 11:57:41 <maxice8> yes
2020-11-07 11:57:44 <maxice8> which repo ?
2020-11-07 11:57:52 <Cogitri> Also, it's aports-qa-bot since it's only for aports
2020-11-07 11:57:59 <Cogitri> cogitri/aports-qa-bot
2020-11-07 12:00:58 <maxice8> done, ty
2020-11-07 12:01:33 <ikke> So I wonder whether we should switch to scoped labels
2020-11-07 12:02:04 <ikke> It's mostly adding another :
2020-11-07 12:06:17 <maxice8> not much reason for the current variables
2020-11-07 12:06:40 <maxice8> aports: are not mutually exclusive you can have a :move and :upgrade and :improve at the same time
2020-11-07 12:06:48 <ikke> sure, not for every label
2020-11-07 12:07:12 <ikke> Just where it makes sense, like status labels
2020-11-07 12:08:14 <ikke> On the other hand, we tend to use status labels more like tags
2020-11-07 12:10:08 <ikke> maxice8: https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels
2020-11-07 12:10:19 <ikke> Right, that's why we are not using them :|
2020-11-07 12:10:26 <ikke> :premium
2020-11-07 12:10:29 <ikke> silver"
2020-11-07 12:11:12 <mps> what will be gold then
2020-11-07 12:37:15 <ikke> :(
2020-11-07 12:37:18 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14374
2020-11-07 12:39:06 <Cogitri> :c
2020-11-07 12:39:16 <Cogitri> Well, at least the bot should set that for new MRs now
2020-11-07 12:40:10 <ikke> yup
2020-11-07 14:33:25 <timlegge> !14387 can be reviewed if anyone has time
2020-11-07 14:37:18 <mps_> !14387
2020-11-07 14:37:39 <mps_> what is slack?
2020-11-07 15:08:49 <Cogitri> I suppose it refers to Slack the messanger thingie for companies
2020-11-07 15:27:33 <mps> that's also my guess, but didn't checked (and will) not. why we promoting such things, I wonder
2020-11-07 15:28:13 <mps> displaced ')', obviously
2020-11-07 15:33:36 <Cogitri> Well, it's not like we're all out promoting slack itself, we just have the OSS packages which interact with their API
2020-11-07 15:33:49 <ikke> nod
2020-11-07 15:35:10 <mps> isn't that some kind of promotion (yes, I know how samba started)
2020-11-07 15:36:01 <Cogitri> I doubt anyone will see that package and will start using Slack due to it
2020-11-07 15:36:22 <Cogitri> Most people who use it are forced to use Slack for work and just want to use the API to automate something
2020-11-07 15:36:28 <ikke> (or stop using slack because alpine does not have some packages)
2020-11-07 15:36:50 <Cogitri> Yeah, they'll just use a different distro/install it themselves
2020-11-07 15:37:01 <Cogitri> And almost all OSS "promotes" proprietary software in a sense
2020-11-07 15:37:26 <Cogitri> E.g. Webbrowsers promote running proprietary JavaScript in them yet we don't install GNU JS everywhere
2020-11-07 15:37:28 <mps> ok ok, I know and understand all this, just somewhat grumpy now :)
2020-11-07 15:41:07 <ikke> I don't think this is significant enough to worry too much about
2020-11-07 15:41:16 <insep_> ikke: it's more likely that they will stop using alpine instead, plus you never know whether it's used to interact with proprietary server or its oss reimplantation
2020-11-07 15:41:22 <ikke> There are better places to spend your energy
2020-11-07 15:42:16 <ikke> insep_: yes, the first part was whyat I h
2020-11-07 15:42:18 <ikke> what I had in mind
2020-11-07 15:45:34 <mps> anyone ported alpine to mips32?
2020-11-07 15:46:23 <ikke> I think Ariadne had that in mind, but then Wave Technologies went backrupt
2020-11-07 15:46:34 <ikke> bankrupt*
2020-11-07 15:47:22 <mps> openwrt still support it, and it is on musl
2020-11-07 15:48:51 <mps> I have this one https://openwrt.org/toh/mikrotik/rb450g and I think it could work quite fine for few years in future
2020-11-07 15:49:19 <ikke> sure, but someone needs to do the legwork to port it, and we need hardware to build on
2020-11-07 15:50:33 <mps> well, I doubt we can got hardware, maybe try in qemu
2020-11-07 15:51:46 <mps> or play again with opewrt cross build sdk after 5 or more years
2020-11-07 15:52:18 <ikke> Al
2020-11-07 15:52:31 <ikke> Alpine always had the policy of building natively on bare-metal
2020-11-07 15:53:01 <mps> or lxc
2020-11-07 15:53:07 <ikke> lxc is bare-metal
2020-11-07 15:53:13 <mps> :)
2020-11-07 15:53:25 <ikke> But at least, not emulated
2020-11-07 15:53:43 <mps> but yes, it is nearly bare metal
2020-11-07 15:54:00 <ikke> it is completely bare-metal
2020-11-07 15:54:18 <ikke> there is no virtualization
2020-11-07 15:54:52 <mps> maybe I can 'fake' alpine by putting busybox from openwrt
2020-11-07 16:03:22 <ahills> hey, I was just trying to build elfutils with the programs, and it seems bits of GCC that it would like to link against are built without -fPIC—except I can't actually figure out how that's being accomplished in the gcc aport
2020-11-07 16:03:44 <ahills> specifically libargp, but I suspect there will be more
2020-11-07 16:03:50 <ahills> /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../lib/libargp.a(argp-help.o): relocation R_X86_64_PC32 against symbol `program_invocation_short_name' can not be used when making a shared object; recompile with -fPIC
2020-11-07 16:03:52 <ahills> any suggestions?
2020-11-07 16:04:22 <ikke> export CFLAGS="$CFLAGS -fPIC"
2020-11-07 16:04:42 <ahills> -fPIC is definitely set for all of the elfutils builds
2020-11-07 16:04:48 <ikke> hmm
2020-11-07 16:04:50 <ahills> or do you mean to rebuild GCC that way?
2020-11-07 16:04:53 <ikke> no
2020-11-07 16:05:15 <ahills> it's the GCC libargp.a that's referenced, as far as I can tell from the error
2020-11-07 16:06:03 <ikke> The path is /usr/lib/libargp.a(argp-help.o
2020-11-07 16:06:17 <ikke> w/usr/lib/libargp.a
2020-11-07 16:06:39 <ikke> so not necessarily belonging to gcc
2020-11-07 16:06:56 <ahills> you're right! it's owned by argp-standalone
2020-11-07 16:06:59 <ahills> so I can try rebuilding that
2020-11-07 16:07:00 <ahills> thanks
2020-11-07 17:27:02 <ahills> it worked! thanks again
2020-11-07 17:28:47 <ikke> ok, cool
2020-11-07 20:39:39 <timlegge> mps: as above WebService::Slack::WebApi is a perl wrapper to the slack api - the Foswiki project (my interest) uses it to allow integrations between a Foswiki installation and a company's Slack channel - from a free software point of view not ideal but it allows Foswiki to stay relevant with a company's propritary tools
2020-11-07 21:00:17 <mps> timlegge: I understand
2020-11-07 21:01:04 <mps> (that is how free software surrender to corporations)
2020-11-07 21:03:49 <ikke> That boat has long ago sailed :)
2020-11-07 21:06:32 <halosghost> 
ACTION is close to submitting pyinstaller to the repos

2020-11-07 21:06:50 <halosghost> will be cool for the possibility of -bin pythong packages :)
2020-11-07 21:08:16 <ikke> halosghost: what's the goal if it?
2020-11-07 21:08:38 <mps> hope that some thunders appears on these boats :)
2020-11-07 21:09:02 <halosghost> ikke: the goal of what?
2020-11-07 21:09:12 <ikke> -bin python packages
2020-11-07 21:09:22 <mps> to have compiled py programs?
2020-11-07 21:09:31 <halosghost> ikke: oh, essentially so that I can have the few python programs that I want without having to have python installed system-wide
2020-11-07 21:09:42 <halosghost> ikke: in fact, for me, there's really only one python program that I want
2020-11-07 21:09:44 <halosghost> :)
2020-11-07 21:10:20 <halosghost> ikke: I'm kind of not really expecting -bin python packages to ever be in the repos (unless people really latch onto the idea)
2020-11-07 21:10:36 <ikke> sounds almost like -static packages
2020-11-07 21:10:42 <halosghost> probably
2020-11-07 21:10:46 <halosghost> except for python :)
2020-11-07 21:11:28 <halosghost> it does incur a non-zero startup performance penalty, but the runtime of the program will otherwise be identical
2020-11-07 21:12:55 <mps> rewriting it in some compiled lang?
2020-11-07 21:13:27 <halosghost> mps: what? pyinstaller?
2020-11-07 21:14:01 <mps> no, program you need
2020-11-07 21:14:20 <halosghost> I guess I'm not following
2020-11-07 21:14:30 <halosghost> the only python program I want really is youtube-dl :)
2020-11-07 21:14:38 <halosghost> and its fate will be determined by the next week or so
2020-11-07 21:15:19 <mps> heh, by coincidence also I only need this one of all py programs
2020-11-07 21:15:43 <mps> though I'm looking for alternative
2020-11-07 21:15:54 <halosghost> what program is it, out of interest?
2020-11-07 21:16:50 <mps> I'm still searching
2020-11-07 21:17:09 <halosghost> mps: you're looking for alternatives to what?
2020-11-07 21:17:12 <mps> https://github.com/trizen/pipe-viewer
2020-11-07 21:17:20 <mps> for ytdl
2020-11-07 21:17:24 <halosghost> ah
2020-11-07 21:17:26 <halosghost> yeah
2020-11-07 21:17:29 <halosghost> nothing has its level of support
2020-11-07 21:17:34 <halosghost> I really wish quvi hadn't died
2020-11-07 21:17:48 <halosghost> ideally, I'd like the core of ytdl to be written in C with lua modules for the extractors
2020-11-07 21:17:57 <halosghost> then it'd be really easy to contribute but a really fast simple core
2020-11-07 21:18:13 <halosghost> but I already have a long enough to-do list :P
2020-11-07 21:18:22 <halosghost> so, till someone else writes one, ytdl it is for me
2020-11-07 21:18:26 <mps> I built 'tuitube' locally but didn't pushed to aports, waiting when someone request it
2020-11-07 21:18:55 <halosghost> mps: link to project?
2020-11-07 21:19:00 <halosghost> I'd love to evaluate it
2020-11-07 21:19:25 <mps> https://github.com/djt3/tuitube/
2020-11-07 21:20:04 <halosghost> ahh, cool
2020-11-07 21:20:17 <halosghost> I have aliases for searching with ytdl, so I don't feel much a need for a tui for it
2020-11-07 21:21:35 <mps> but tuitube depends on youtube-dl
2020-11-07 21:22:35 <halosghost> right
2020-11-07 21:22:49 <halosghost> I just meant that though I find such an interface cool, I don't really need it :)
2020-11-07 21:30:32 <mps> halosghost: to write such software ideas can be find here https://github.com/iv-org/invidious
2020-11-07 21:30:48 <mps> written in crystal lang, so compiled
2020-11-07 21:31:19 <halosghost> indeed
2020-11-07 21:31:26 <halosghost> I'm kind of a language snob :P
2020-11-07 21:33:44 <ikke> maxice8: https://gitlab.alpinelinux.org/kdaudt/atools-go/-/jobs/243095
2020-11-07 21:39:50 <maxice8> Ikke: sorry am out of town today
2020-11-07 21:40:19 <ikke> no problem
2020-11-07 21:42:13 <halosghost> maxice8: I wanted to thank you for your help and guidance on my submission of enlighten
2020-11-07 21:42:22 <halosghost> maxice8: still learning the ropes and I appreciate your time and effort
2020-11-07 21:44:21 <maxice8> You're welcome
2020-11-07 22:02:51 <halosghost> also, thank you to all the devs; the contribution system for alpine is second-to-none; I absolutely love it
2020-11-07 22:06:58 <halosghost> I started a WIP pyinstaller MR so I can leverage the CI system to figure out what all tests need to be disabled for all platforms
2020-11-07 22:10:15 <halosghost> oh hmm, does CI not run the APKBUILD check functions?
2020-11-07 22:15:31 <halosghost> oh, I see; it runs them for aarch64 at least
2020-11-07 22:15:33 <halosghost> good enough :)
2020-11-07 22:18:41 <ikke> It should run them for all arches
2020-11-07 22:19:34 <halosghost> hmm
2020-11-07 22:21:38 <ikke> >>> testing/pyinstaller: disabled for armv7
2020-11-07 22:21:48 <halosghost> I don't think I manually did that
2020-11-07 22:21:51 <ikke> >>> testing/pyinstaller: disabled for armv7
2020-11-07 22:21:57 <ikke> >>> testing/pyinstaller: disabled for x86_64
2020-11-07 22:22:34 <halosghost> ikke: any idea why that would have happened?
2020-11-07 22:22:34 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14430/diffs#9570a7abd0df8a6f5c656a06dcb59ce87326a71c_0_7
2020-11-07 22:22:42 <ikke> You only set aarch64 for arch
2020-11-07 22:22:46 <halosghost> …
2020-11-07 22:22:54 <halosghost> welp
2020-11-07 22:22:56 <halosghost> that'd do it
2020-11-07 22:22:58 <halosghost> 
ACTION fixes

2020-11-07 22:23:02 <halosghost> ikke: thank you :)
2020-11-07 22:23:05 <ikke> np
2020-11-07 22:24:03 <halosghost> this will take a while to finish testing :P
2020-11-07 22:24:53 <ikke> heh
2020-11-08 00:01:02 <halosghost> so, I think at least one of the test pipelines for pyinstaller failed because it took too long and the pipeline killed it
2020-11-08 00:01:07 <halosghost> so, that's a thing to deal with
2020-11-08 00:01:09 <halosghost> :)
2020-11-08 02:26:55 <Ariadne> [09:45] <mps> anyone ported alpine to mips32?
2020-11-08 02:27:17 <Ariadne> yes, we have one internally.  i haven’t integrated it upstream yet due to lack of interest
2020-11-08 02:27:35 <Ariadne> would also like to see a healthier mips ecosystem first
2020-11-08 02:27:44 <Ariadne> e.g. gcc 10
2020-11-08 07:56:48 <mps> Ariadne: yes, I remember that you worked on it
2020-11-08 07:58:22 <mps> and iirc you stopped on further work because 'mips' went out of luck
2020-11-08 08:01:07 <mps> Ariadne: but don't worry for me or my use cases, openwrt is enough for me
2020-11-08 08:02:27 <mps> yesterday I disassembled one huawei hg532e adsl/wifi router and noticed it is also mips32
2020-11-08 08:04:07 <mps> so I concluded there must be a lot of mips32 devices around
2020-11-08 08:32:11 <ikke> 9http://www.mutt.org/relnotes/2.0/
2020-11-08 08:35:51 <mps> ikke: I think I made MR
2020-11-08 08:40:41 <mps> !14435
2020-11-08 08:46:28 <mps> mutt got lisp as config lang
2020-11-08 08:59:45 <mps> interesting, postfix 3.5.8 is also released but not yet announced
2020-11-08 10:13:37 <maxice8> morning
2020-11-08 10:14:34 <ikke> o/
2020-11-08 10:14:37 <mps> good morning
2020-11-08 10:16:52 <maxice8> had lot of fun yesterday out in the "farm"
2020-11-08 10:17:03 <maxice8> :D played lot of table football
2020-11-08 10:17:57 <ikke> nice
2020-11-08 10:18:47 <mps> heh, when I was young also played that
2020-11-08 10:19:33 <maxice8> mps: it is a game for all ages :D
2020-11-08 10:20:33 <mps> I'm waiting my granddaughter to grow up and maybe I will play with she
2020-11-08 10:20:52 <ikke> her* :)
2020-11-08 10:21:03 <mps> ikke: thanks
2020-11-08 10:21:16 <mps> and playing is always good
2020-11-08 10:21:50 <mps> but in last years I forgot what is it :(
2020-11-08 12:34:04 <Retep> I am trying to compile pam_ssh_agent_auth but I keep getting 'Error reloacting * symbol not found' errors. I am fairly new to compiling and spcifically dealing with Musl. Can anyone give me any pointers?
2020-11-08 12:35:21 <ikke> 0x1213bca0
2020-11-08 12:35:23 <ikke> :P
2020-11-08 12:36:32 <Retep> Amazing, thank you ;)
2020-11-08 12:37:14 <ikke> When do you get this error?
2020-11-08 12:38:47 <Retep> I recompiled pam to include debugging, I see it in that output, in the /var/log/auth.log and when I exectute ldd /lib/security/pam_ssh_agent_auth. An example would be Error relocating /lib/security/pam_ssh_agent_auth.so: DSA_get0_pub_key: symbol not found
2020-11-08 12:40:13 <Retep> I am comipling for arm64 btw. Not sure that matters much.
2020-11-08 12:41:37 <Retep> I have most everything else working with my nitrokey/yubikey so it would be nice to have sudo/doas authenticate from my gpg or ssh key
2020-11-08 12:45:58 <ikke> That symbol is provided by iibssl apparently
2020-11-08 12:46:59 <Retep> Yes, when compiling I get a warning about a mismatch in openssl versions (despite the fact that it lists both in conflict and they are the same). Using libressl gets rid of that error
2020-11-08 12:47:20 <Retep> But then no joy when actually using the pam module
2020-11-08 12:48:56 <Retep> I also compiled poldi (https://github.com/gpg/poldi) and I have similar issues execpt it appears related to gnupg libraries
2020-11-08 12:49:48 <Retep> So it is likely this is an issue with how I am compiling I think. As I said, I am fairly new to it
2020-11-08 12:50:29 <ikke> sadly I'm not that experience in these things as well
2020-11-08 12:51:28 <Retep> No worries
2020-11-08 12:52:32 <Retep> I read that this can be an issue with Musl but also some mentioning mixing edge with other repositories so I am not sure where to look next
2020-11-08 12:56:28 <insep_> wait, are you miхing edge and stable?
2020-11-08 12:58:43 <Retep> I had been but I rebuilt everything and tried again with stable only, still no joy
2020-11-08 13:39:19 <ikke> maxice8: What are these supposed to match?
2020-11-08 13:39:22 <ikke> https://gitlab.alpinelinux.org/Leo/atools/-/blob/master/apkbuild-lint#L38
2020-11-08 13:39:48 <maxice8> I think they are mistakes
2020-11-08 13:39:58 <ikke> right
2020-11-08 13:40:14 <ikke> They would only be values for the install variable
2020-11-08 13:40:18 <maxice8> yes
2020-11-08 13:40:28 <ikke> alright
2020-11-08 14:09:14 <Newbyte> Should libraries always be prefixed with lib-?
2020-11-08 14:09:52 <Newbyte> Or is that only if the library calls itself lib<something>?
2020-11-08 14:16:42 <mps> Newbyte: you mean pkg name?
2020-11-08 14:17:38 <Newbyte> mps: yes
2020-11-08 14:18:44 <ikke> Then no, it doesn ot have to start with lib
2020-11-08 14:18:47 <mps> policy is to follow upstream naming scheme whenever possible
2020-11-08 14:18:52 <Newbyte> thank you!
2020-11-08 14:43:31 <ikke> Then no, it doesn ot have to start with lib
2020-11-08 14:43:47 <ikke> sry
2020-11-08 16:51:32 <Cogitri> ikke: fwiw I added override config support to aports-qa-bot (via conf.override.json) and also added per-repo config. You can get the new image once https://gitlab.alpinelinux.org/alpine/infra/docker/aports-qa-bot/-/pipelines/57583 is done building and and pull the compose repo once you have a clean conf.json and moved the overrides to conf.override.json
2020-11-08 16:52:01 <ikke> Ok, nice
2020-11-08 17:07:35 <ikke> https://gitlab.alpinelinux.org/kdaudt/atools-go/-/merge_requests/1/ :)
2020-11-08 17:20:16 <ikke> maxice8: ping
2020-11-08 17:23:14 <ikke> Cogitri: you forgot to mount the override json
2020-11-08 17:23:28 <Cogitri> Oh oops
2020-11-08 17:24:02 <ikke> aports-qa-bot_1  | 2020/11/08 17:23:50 Failed to get configuration for repo 1, using defaults.
2020-11-08 17:24:04 <ikke> is this normal?
2020-11-08 17:24:17 <ikke> probably because the MR is not merged yet, I guess
2020-11-08 17:28:04 <Cogitri> Yup
2020-11-08 17:51:04 <gavodavo> Ariadne: I think my gcc is ready since, according to --verbose, it scans /lib/$CHOST first
2020-11-08 17:51:25 <gavodavo> 
ACTION posted a file: APKBUILD (27KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/ezjajuCVaoYeKHhwgiRTqOBw >

2020-11-08 17:51:42 <gavodavo> What should I do next?
2020-11-08 18:14:43 <ikke> hmm, found one thing that's not easy to catch with an AST: tabs vs spaces
2020-11-08 18:15:50 <ikke> mcdan.cc/sh/syntax does not record whitespace
2020-11-08 18:38:11 <maxice8> Ikke: back from partying hard
2020-11-08 18:39:07 <ikke> o/
2020-11-08 18:43:24 <ikke> maxice8: do you care to review https://gitlab.alpinelinux.org/kdaudt/atools-go/-/merge_requests/1/ ?
2020-11-08 18:43:34 <maxice8> of course
2020-11-08 18:44:30 <ikke> https://gitlab.alpinelinux.org/kdaudt/atools-go/-/compare/implement...variable-linters is where the actual linting rules are added
2020-11-08 18:45:10 <maxice8> You're better at go than me
2020-11-08 18:59:13 <ikke> maxice8: I think I'm not following what you mean with that remark
2020-11-08 18:59:42 <maxice8> I don't have much to add in review
2020-11-08 18:59:52 <ikke> Understood
2020-11-08 19:00:00 <ikke> the variable-linters branch is more interesting in that regard
2020-11-08 19:00:14 <ikke> But at least a cursory glance helps
2020-11-08 19:01:48 <ikke> Locally I have added a command that prints the AST of a file. That helps you to understand the structure better (though, you'd need to be familiar with the go types to make sense of it)
2020-11-08 21:26:16 <ikke> mps: :D
2020-11-08 21:29:05 <mps> :)
2020-11-08 23:58:44 <craftyguy> Is there anything else this needs to have it merged? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14201
2020-11-09 05:43:27 <ikke> craftyguy: don't think so, ncopa agreed to this approach
2020-11-09 05:46:02 <craftyguy> ikke: great, thanks.
2020-11-09 05:48:41 <ikke> craftyguy: merged
2020-11-09 05:48:57 <craftyguy> thanks :)
2020-11-09 07:06:21 <ncopa> good morning!
2020-11-09 07:12:59 <mps> good morning
2020-11-09 07:25:33 <Cogitri> Morning
2020-11-09 07:46:27 <ncopa> i wil try bootstrap the 3.13 builder today/this week
2020-11-09 07:53:45 <mps> what to do about musl 1.2.1
2020-11-09 09:08:16 <ncopa> whats up with musl 1.2.1?
2020-11-09 09:12:58 <mps> dalias asked if we can test it more to release 1.2.2
2020-11-09 09:13:22 <ncopa> we have it in edge, right?
2020-11-09 09:13:46 <mps> no it is pre-release
2020-11-09 09:14:14 <mps> 1.2.2_pre0-r1
2020-11-09 09:14:30 <ncopa> i mean, we have 1.2.1, so we *are* testing it already
2020-11-09 09:14:47 <mps> current in edge is 1.2.2_pre0-r1
2020-11-09 09:14:52 <ncopa> or do you mean that we should wait with bootstrapping the 3.13 builders til we have tested musl more?
2020-11-09 09:15:27 <ncopa> looks like the 1.2.2_pre0 is a git snapshot of current musl git master
2020-11-09 09:15:29 <mps> I'm not sure, on my testing aarch64 1.2.2_pre0-r1 works
2020-11-09 09:15:51 <mps> yes, Ariadne made snapshot
2020-11-09 09:15:52 <ncopa> my point is that we are already testing it
2020-11-09 09:16:01 <ncopa> so i wonder what more we can do?
2020-11-09 09:16:28 <mps> ask dalias to make 'stable' (heh) release
2020-11-09 09:17:49 <mps> that is about musl
2020-11-09 09:18:27 <mps> and I would like to persuade you make linux-lts of the 5.10.0-rc ;)
2020-11-09 09:30:30 <ncopa> that would require some work, right? like drop linux-rpi etc
2020-11-09 09:32:09 <mps> yes
2020-11-09 09:32:30 <ncopa> i'd rather sped the time on setting up 3.13 builders
2020-11-09 09:32:45 <mps> ok, I don't insist
2020-11-09 09:36:06 <Ariadne> I wanted to sort rust on mips and s,eip
2020-11-09 09:36:10 <Ariadne> s390x
2020-11-09 09:36:12 <Ariadne> even
2020-11-09 09:36:19 <Ariadne> but
2020-11-09 09:36:32 <Ariadne> probably not going to make that for 3.13
2020-11-09 09:43:12 <Ariadne> ncopa: dalias is revising the mt fork patch a little I think
2020-11-09 10:36:06 <bob_bobbovski> Hi, I tried flagging a package out-of-date but all I get is a 404
2020-11-09 10:50:19 <ikke> bob_bobbovski: You can only flag packages on edge
2020-11-09 10:52:15 <bob_bobbovski> ikke: What do I do when there is a security update for a package in 3.12?
2020-11-09 10:52:41 <ikke> bob_bobbovski: file an issue on https://gitlab.alpinelinux.org/alpine/aports
2020-11-09 10:52:51 <bob_bobbovski> kthx
2020-11-09 10:55:11 <Cogitri> Would be nice if we showed a nicer error message or redirected to Gitlab
2020-11-09 15:13:06 <ncopa> Ariadne: whats the status of rust on s390x?
2020-11-09 15:13:30 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/testing/procs/procs-0.10.7-r0.log
2020-11-09 15:37:42 <Hello71> Ariadne: making it more comprehensive. afaict it is already a vast improvement (pragmatically) over 1.2.1, and imo it is good enough for 3.13, especially if the alternative is 1.2.1
2020-11-09 15:52:35 <Cogitri> ncopa: Fails to link in stage1 apparently
2020-11-09 16:24:21 <ncopa> there is a circular dep py3-attrs -> py3-setuptools -> .... -> py3-attrs
2020-11-09 16:25:00 <ikke> hmfp
2020-11-09 16:29:02 <ncopa> maxice8: any idea how to resolve the circular dep? ^^^
2020-11-09 16:29:10 <maxice8> I don't even know where it is
2020-11-09 16:29:31 <ncopa> py3-attrs needs py3-setuptools to build
2020-11-09 16:30:17 <maxice8> yes
2020-11-09 16:31:45 <maxice8> Where does py3-setuptools or any of its dependencies require py3-attrs is what I'm trying to find
2020-11-09 16:32:03 <ncopa> *nod*
2020-11-09 16:32:11 <ncopa> im trying to figure out the same
2020-11-09 16:34:04 <ncopa> ah
2020-11-09 16:34:10 <maxice8> I don't see where
2020-11-09 16:34:14 <ikke> py3-packaging
2020-11-09 16:34:24 <ncopa> py3-packaging -> py3pytest (checkdepends)
2020-11-09 16:34:30 <maxice8> there is !check
2020-11-09 16:34:58 <ikke> Doesn't matter for deps
2020-11-09 16:35:14 <ncopa> i dont think `ap` consider options when calculating deps
2020-11-09 16:35:32 <ncopa> simply commenting out checkdepends should solve it
2020-11-09 16:36:10 <ikke> That's where we need better tooling :)
2020-11-09 16:36:18 <ncopa> yup :-/
2020-11-09 16:36:37 <ikke> But tooling is hard if it's part of bootstrap
2020-11-09 16:39:11 <ncopa> i think the 3.13 builders might be online tomorrow, unless there are any unepxected big issues
2020-11-09 16:39:23 <ncopa> i have compiled toolchain for soem of the arches
2020-11-09 16:45:50 <ncopa> btw... i wonder if we should add a patch for gcc, from v10.3 -> current HEAD in the stable branch
2020-11-09 16:46:14 <ncopa> s/10.3/10.2/
2020-11-09 16:46:14 <alpine-meetbot> ncopa meant to say: btw... i wonder if we should add a patch for gcc, from v10.2 -> current HEAD in the stable branch
2020-11-09 16:46:26 <ncopa> there seems to be a lot fixes
2020-11-09 16:46:42 <ncopa> hopefully one of them fixes mips64
2020-11-09 16:47:04 <ncopa> and hopefully it also fixes the libreoffice build
2020-11-09 16:47:07 <artok> someone put money for mips64?
2020-11-09 16:47:47 <ncopa> nope
2020-11-09 16:47:58 <ncopa> well, i dont know
2020-11-09 16:49:30 <mps> ncopa: I'm for adding gcc patch
2020-11-09 16:50:04 <ncopa> ouch!  http://dl.2f30.org is gone
2020-11-09 16:50:11 <ncopa> fortify-headers site
2020-11-09 16:52:25 <minimal> ncopa, any chance at all of !14200 getting into 3.13? Its only a single module to build into RPI kernels
2020-11-09 16:54:14 <ncopa> yeah, i think we can include that for 3.13, but its not urgent. can look at it when next stable kernel arrives
2020-11-09 16:54:50 <artok> uhms.
2020-11-09 16:55:15 <minimal> ncopa: its to tidy up from a previous change that only did half the intended job
2020-11-09 16:55:49 <ncopa> i do feel a bit tricked though :)
2020-11-09 16:55:58 <artok> I thought that was already on the rtc patch
2020-11-09 16:56:21 <ncopa> last PR was "its only a single small thing to include in kernel", while in fact it was two
2020-11-09 16:56:40 <artok> and I was just going to do my breadboard connection of the RTC
2020-11-09 16:57:45 <minimal> ncopa: tricked? I thought the original fixed the issue but didn't test it as not setup to cross-compile RPI kernels on PC and so until spotted this issue once the revised kernel was out and could test in on a RPI
2020-11-09 16:58:21 <minimal> I need to get cross-compile working here to avoid such "fun" in the future
2020-11-09 17:00:48 <ncopa> what guarantee do we have that there will be N followup MRs saying "we only need this single thing too" and in the end there are 10 more things needed compiled in to the kernel
2020-11-09 17:05:00 <minimal> ncopa: with the current RPI kernel with ds1307 compiled in, doing an "modprobe i2c-bcm2835" gets the RTC working - just not early enough in boot to e useful. So that strongly points to this current PR addressing the issue. I should have raised this PR a couple of weeks ago but held off as intended to build a cross-compile env to be 100% sure but unfortunately real life got in the way. Up to you - would be nice to see it in 3.13 but not
2020-11-09 17:05:00 <minimal> the end of the world.
2020-11-09 17:06:26 <ncopa> np, i understand
2020-11-09 17:07:42 <mps> there are more devices which need such 'things'
2020-11-09 17:10:37 <minimal> and BTW that wasn't my Steve Jobs impression ("just one more thing...") ;-)
2020-11-09 17:12:52 <mps> every linux user should build own kernel
2020-11-09 17:13:26 <mps> distro kernels are just for bootstrap device
2020-11-09 17:17:48 <artok> is there good "I need these -> kernel config" type of config menu already? =)
2020-11-09 17:18:48 <minimal> mps: building kernels is fine, its the cross-compiling that's a little bit more of a hassle
2020-11-09 17:21:46 <mps> minimal: I create debian lxc when I need to cross build some things, and kernels among them
2020-11-09 17:21:54 <artok> oh.. I did basic dockerfile to build kernel cross compiling toolchain
2020-11-09 17:23:03 <mps> never tried kernels with mcm, maybe it could work
2020-11-09 17:24:32 <minimal> mps: Debian LXC to cross-compile Alpine kernels? I'm intending to setup an Alpine box to cross-compile Alpine packages (rather than the current QEMU inside an Alpine Docker container I use currently)
2020-11-09 17:25:23 <mps> minimal: yes, debian. why not
2020-11-09 17:27:28 <mps> I'm considering these days to build mips32 kernel and debian first comes to mind
2020-11-09 17:27:32 <minimal> mps: nothing against Debian at all, its my desktop here. I assume you're building kernel binaries for use with Alpine on Debian rather than building Alpine packages (directly) on Debian
2020-11-09 17:28:13 <mps> yes, long time I used debian to build arm kernels for alpine
2020-11-09 17:28:22 <artok> I'm using macOS
2020-11-09 17:28:26 <artok> ...gosh
2020-11-09 17:29:04 <mps> alpine can boot and work on macbooks ;)
2020-11-09 17:29:39 <artok> sure, I've got no use for it on this laptop =)
2020-11-09 20:51:07 <Ariadne> Hello71: yes but i would like to ship with a musl not called 1.2.2_pre0 :)
2020-11-09 20:52:30 <mps> Ariadne: also
2020-11-09 20:52:32 <Hello71> I think it's at least good enough to branch 3.13. seems to me like the remaining concerns are primarily theoretical, and more importantly, fixes for them are unlikely to cause additional breakage
2020-11-09 20:53:07 <Ariadne> dalias: when do you expect to release 1.2.2?
2020-11-09 20:53:40 <Ariadne> mps: if you run bootstrap.sh mips, you'll get full 32-bit cross-compiled alpine base system for mips32
2020-11-09 20:54:46 <mps> Ariadne: aha, will try on weekend. thanks
2020-11-09 20:56:13 <Ariadne> ncopa: i think gcc 10.3 will have mips64 fixes
2020-11-09 20:56:27 <Ariadne> the mips issues i am hitting with 10.2 also effect loongson
2020-11-09 20:57:19 <dalias> ariadne, it depends on how the outstanding issues with MT-fork are resolved
2020-11-09 21:00:31 <Ariadne> well, we are starting 3.13 release cycle... so it would be nice to have it sooner than later
2020-11-09 21:00:44 <Ariadne> we will be shipping musl git snapshot for now i guess
2020-11-09 21:00:45 <Ariadne> :)
2020-11-10 06:56:06 <ncopa> morning
2020-11-10 06:59:14 <mps> good morning
2020-11-10 07:04:09 <ncopa> disks are full and i found out that where the disk usage went
2020-11-10 07:04:17 <ncopa> apk-tools' help.h
2020-11-10 07:04:21 <ncopa> takes 70GB
2020-11-10 07:04:47 <ncopa> so don't come here and say that we have too little help text in apk-tools :)
2020-11-10 07:06:56 <mps> and I thought chromium and firefox are big pkgs :)
2020-11-10 07:10:52 <ncopa> heh
2020-11-10 07:11:01 <ncopa> i think i know whats wrong
2020-11-10 07:11:54 <ncopa> this broke it d8a51893723d2c17681c2c9fc457780197421d06
2020-11-10 07:12:01 <ncopa> make LUA=yes
2020-11-10 07:12:04 <insep_> ncopa: how
2020-11-10 07:12:20 <ncopa> $(LUA) genhelp.lua > help.lua
2020-11-10 07:12:44 <ncopa> so it executes: yes genhelp.lua ... > help.lua
2020-11-10 07:14:08 <insep_> oh god
2020-11-10 07:20:37 <ncopa> Ariadne: mips64 builders disappeared. seems like 3.13 build killed it
2020-11-10 07:20:47 <ncopa> I'm not able to recoonect to it
2020-11-10 07:21:04 <Ariadne> ok I'll look into it
2020-11-10 07:21:20 <Ariadne> I have a console server
2020-11-10 07:21:46 <ncopa> thanks
2020-11-10 07:23:27 <Ariadne> console server is also down
2020-11-10 07:23:36 <ncopa> so network is down?
2020-11-10 07:24:06 <Ariadne> either network or power is down.  i'll ask pyvpx to check on that
2020-11-10 07:27:28 <ncopa> maybe someone tripped over the cable https://xkcd.com/908/
2020-11-10 07:27:29 <alpine-meetbot> https://xkcd.com/908 | The Cloud | Alt-text: There's planned downtime every night when we turn on the Roomba and it runs over the cord.
2020-11-10 07:38:38 <mps> don't understand why base pkg as apk-tools have to use anything except C
2020-11-10 07:41:10 <Cogitri> mps: Because the C implementation for generating help would've taken way more time to implement and maintain and would probably be less reliable
2020-11-10 07:41:22 <Cogitri> it's only a buildtime dep anyway
2020-11-10 07:44:27 <mps> anyway, but I still thinks that doesn't make sense
2020-11-10 07:44:45 <mps> think*
2020-11-10 08:45:49 <ikke> ncopa: increase the amount of characters algitbot uses for hashes to 12
2020-11-10 08:45:55 <ikke> I increased*
2020-11-10 08:46:20 <ikke> strange, still get bad ids from cgit
2020-11-10 08:48:49 <ikke> seems like a caching issue
2020-11-10 08:49:12 <ikke> If I remove characters, it still works
2020-11-10 09:12:56 <fabled> ncopa, re: starting new builders/bootstrapping. seems java does not like gcc10. there's patches and MR about it, but need to investigate if it needs more work...
2020-11-10 09:16:06 <ikke> Is that also the reason libreoffice is failing, or different?
2020-11-10 09:16:42 <Ariadne> sorry about the lua thing
2020-11-10 09:16:54 <ncopa> fabled: ok. I was thining that we may want use a git snapshot of  gcc 10 stable HEAD
2020-11-10 09:17:10 <Ariadne> we could.
2020-11-10 09:17:14 <Ariadne> i can rebase our patchset
2020-11-10 09:17:21 <ncopa> Ariadne: np. it happens. the bug was kinda funny :)
2020-11-10 09:17:37 <fabled> oh, is there some important fixes in gcc10? one reason why java is failing is some of the changed default options
2020-11-10 09:18:00 <ncopa> there are lots of fixes in gcc 10 stable branch
2020-11-10 09:18:13 <ncopa> i had a look when investigating libreoffice build
2020-11-10 09:18:25 <ncopa> but i couldnt find anything
2020-11-10 09:18:38 <ncopa> also mips64 has issues with current gcc10
2020-11-10 09:18:57 <ncopa> i bumped into a changed default option recently in zstd
2020-11-10 09:19:25 <ncopa> i think -fstrict-aliasing is enabled by default now
2020-11-10 09:19:42 <ikke> and -fno-common
2020-11-10 09:20:19 <fabled> yes, -fno-common broke java
2020-11-10 09:20:41 <ncopa> Ariadne: thanks for following up gcc patches. please rebase
2020-11-10 09:21:21 <ikke> fabled: can't we disable -fno-common for now for java, then?
2020-11-10 09:21:36 <ncopa> -fno-no-common? :)
2020-11-10 09:21:49 <fabled> yes, with -fcommon. though, there's also patches around. need to investigate.
2020-11-10 09:51:31 <fabled> i'll just try if -fcommon fixes the build or not. if not, then gcc10 likely needs fixes (or java something more)
2020-11-10 10:22:01 <fabled> ncopa, so there's new icedtea release for openjdk8 that fixes gcc10
2020-11-10 10:22:02 <fabled> but
2020-11-10 10:22:08 <fabled> it fails with missing symbol _ZN14ArrayAllocatorImL10MemoryType7EE4freeEv from libstdc++
2020-11-10 10:22:19 <fabled> so something seems wrong in gcc10 libstdc++ build
2020-11-10 10:27:41 <fabled> actually no, it's not libstdc++.. it's libjvm
2020-11-10 10:29:29 <fabled> hum... it's inline c++ function
2020-11-10 10:32:41 <fabled> trying adding always_inline for that
2020-11-10 10:48:03 <mps> zig lang 0.7 is released, and it requires llvm11 which we don't have now
2020-11-10 10:48:39 <mps> imo, we don't need to hurry for this
2020-11-10 10:49:23 <ikke> Probably better after 3.13
2020-11-10 10:50:54 <mps> yes, this is also my opinion
2020-11-10 11:19:14 <Ariadne> [03:20] <ncopa> Ariadne: thanks for following up gcc patches. please rebase
2020-11-10 11:19:25 <Ariadne> ok will do it this week
2020-11-10 11:36:04 <ncopa> 👍
2020-11-10 11:41:47 <andypost[m]> Is 3.13 planned? Any forecasts?
2020-11-10 11:42:10 <ncopa> yes 3.13 is planned, the 3.13 builders are supposed to come up this week
2020-11-10 11:42:35 <ikke> https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2020-11-10 11:42:44 <andypost[m]> Great news! Thanks 👍
2020-11-10 11:43:19 <ncopa> hopefully we will get it out before end of november, but more realistic it will be in the beginning of december
2020-11-10 11:43:26 <mps> releasing would be better at equinox times, less new (and shiny) software released at that times
2020-11-10 11:45:45 <andypost[m]> In December I think to start mutate php7 and php8 packages, it looks both versions should be in community
2020-11-10 11:53:21 <ncopa> build 3.13 builders are almost ready to start build, except mips64 who disappeared :-/
2020-11-10 11:56:17 <ikke> I can still ssh into the box?
2020-11-10 11:56:24 <ikke> oh, wrong one
2020-11-10 12:17:14 <maxice8> atools 19.8.4 :D
2020-11-10 12:18:30 <ikke> something funny about it?
2020-11-10 12:19:18 <maxice8> no, just made apkbuild-fixer be able to automatically fix AL49
2020-11-10 12:19:52 <maxice8> so if you have invalid options set like, `check` it can be run over it (or use apkbuild-vim with the ALE Fixer) to automatically remove the invalid option
2020-11-10 12:20:10 <ikke> nice
2020-11-10 12:20:47 <maxice8> also there is a huge table on alint
2020-11-10 12:20:50 <maxice8> man 5 alint
2020-11-10 12:20:55 <ikke> yes, I noticed it
2020-11-10 12:21:01 <ikke> the unparsed form
2020-11-10 12:22:26 <maxice8> https://0x0.st/in9A.png
2020-11-10 14:01:57 <Hello71> why do we have so many java versions anyways? aren't these all EOL?
2020-11-10 14:03:17 <ikke> if there are still security updates coming
2020-11-10 14:03:23 <ikke> I guess it's not EOL
2020-11-10 14:06:05 <Hello71> everything except 8, 11, and 15 has no more (free) updates
2020-11-10 14:06:25 <ncopa> can you build openjdk11 from openjdk8?
2020-11-10 14:06:39 <ncopa> and can you build openjdk15 from openjdk11?
2020-11-10 14:07:08 <fabled> not necessarily. i think there is no such guarantee. iirc, only with one earlier major release
2020-11-10 14:07:10 <Hello71> don't think so but not 100%
2020-11-10 14:07:20 <Hello71> at least the latter i'm 99% sure is no
2020-11-10 14:07:45 <ncopa> if not, thats a reason to keep the intermediate versions
2020-11-10 14:08:32 <Hello71> optimally you are supposed to compile them with same version
2020-11-10 14:08:42 <Hello71> previous version is only for initial bootstrap
2020-11-10 14:09:18 <fabled> yes, icedtea does two builds. first bootstrap build with specified earlier version, and then full recompile with itself
2020-11-10 14:09:42 <ikke> and openjdk?
2020-11-10 14:10:05 <ncopa> uses previous version i think
2020-11-10 14:10:08 <fabled> https://hg.openjdk.java.net/jdk-updates/jdk9u/raw-file/tip/common/doc/building.html#boot-jdk-requirements
2020-11-10 14:10:17 <fabled> generally you need N-1 version to bootstrap
2020-11-10 14:10:43 <Hello71> i'm still confused about icedtea but pretty sure it's only relevant for jdk 7 and jdk 8
2020-11-10 14:10:58 <ncopa> yup
2020-11-10 14:14:46 <ncopa> iirc only openjdk7 can be built with gcc-java (gcc6)
2020-11-10 14:17:24 <Hello71> I don't understand why this matters
2020-11-10 14:18:02 <ikke> Hello71: bootstrap from scratch
2020-11-10 14:18:17 <ikke> If you want to bootstrap new arches
2020-11-10 14:18:22 <Hello71> for bootstrap you use same version java on host
2020-11-10 14:19:44 <Hello71> er, build
2020-11-10 14:22:22 <ikke> Hello71: what if it's a completly new arch?
2020-11-10 14:22:41 <ikke> so no jdk on the host arch
2020-11-10 14:23:14 <Hello71> I meant "build machine" in cross terms, "host" in virtualization terms
2020-11-10 14:23:25 <Hello71> https://hg.openjdk.java.net/jdk-updates/jdk15u/raw-file/tip/doc/building.html#cross-compiling
2020-11-10 14:23:26 <ikke> s/host/build/
2020-11-10 14:23:26 <alpine-meetbot> ikke meant to say: so no jdk on the build arch
2020-11-10 14:24:39 <Hello71> same as gcc: first you need a gcc that can compile gcc. then, you build a cross-gcc that runs on CBUILD and generates code for CHOST. then, you build target gcc
2020-11-10 14:24:55 <ncopa> i guess that is where we are heading
2020-11-10 14:24:57 <Hello71> but with openjdk, according to those instructions, the middle step is automatic
2020-11-10 14:25:22 <Hello71> probably ignore the part about devkits
2020-11-10 14:25:38 <Hello71> or read https://hg.openjdk.java.net/jdk-updates/jdk11u/raw-file/tip/doc/building.html#cross-compiling instead
2020-11-10 14:25:57 <ncopa> we wanted to keep the number of cross compile toolchains low, but i dont think there are any way without nowdays
2020-11-10 14:27:20 <Hello71> I think it is not a big problem because it is all integrated in openjdk build process and doesn't require any additional dependencies, unlike rust for example
2020-11-10 14:27:31 <ncopa> at least those needs cross compile to bootstrap: gcc, go (for some arches), rust, ghc, crystal
2020-11-10 14:27:46 <ncopa> it is a manual step for every stable release though
2020-11-10 14:28:21 <Hello71> yeah, I don't understand that part either
2020-11-10 14:28:39 <ncopa> so, for each new release, we build the world from scratch
2020-11-10 14:28:49 <ncopa> empty repository
2020-11-10 14:29:16 <ncopa> # cat /etc/apk/repositories
2020-11-10 14:29:17 <ncopa>  /home/buildozer/packages/main
2020-11-10 14:29:22 <ncopa> that directory is empty
2020-11-10 14:29:40 <Hello71> is it really easier to build ancient openjdk with ancient gcc and then go step by step through obsolete versions? I don't think anyone else does that
2020-11-10 14:29:48 <ncopa> the only thing installed is build-base, aports-build
2020-11-10 14:30:21 <ikke> those come from edge, right?
2020-11-10 14:30:40 <ncopa> um. i think from last stable
2020-11-10 14:30:45 <ikke> ok
2020-11-10 14:30:57 <ncopa> then i rebuild those at current git master
2020-11-10 14:31:06 <ncopa> and reinstall
2020-11-10 14:31:15 <ncopa> and then start aports-build
2020-11-10 14:31:24 <ncopa> which figures out how to build the rest
2020-11-10 14:31:40 <ncopa> except those packages that needs bootstrap, like rust, go (for some arches)
2020-11-10 14:32:24 <ncopa> those needs manual handling on each builder (8 arches)
2020-11-10 14:32:54 <ncopa> which is why we have tried to avoid depend on cross-compile to bootstrap when possible
2020-11-10 14:33:16 <ncopa> but as i said: i guess that is where we are heading
2020-11-10 14:35:08 <ncopa> i guess we should drop openjdk7, openjdk8?, openjdk9, openjdk10
2020-11-10 14:35:13 <ncopa> and gcc6
2020-11-10 14:35:27 <ncopa> and depend on cross compile to bootstrap those
2020-11-10 14:37:52 <mps> some older 'things' still need gcc6 (older kernel for example) and keeping it doesn't require much work
2020-11-10 14:38:04 <Hello71> what does void do?
2020-11-10 14:39:27 <Hello71> mps: at that rate shouldn't you keep gcc 4.8 or something
2020-11-10 14:40:06 <mps> Hello71: makes sense but for gcc 4.x is to late
2020-11-10 15:09:46 <fabled> ncopa, no. openjdk8 is still used in production for lots of things. migration from one JDK to another is not always trivial.
2020-11-10 15:11:51 <fabled> not really sure how absolute we should be on keeping the different major versions
2020-11-10 15:13:58 <ikke> openjdk8 still receives updates, according to Hello71?
2020-11-10 15:14:03 <m242> yes
2020-11-10 15:14:12 <m242> it's supported until 2036 I believe ?
2020-11-10 15:14:41 <m242> 2030, according to wikipedia
2020-11-10 15:14:54 <ikke> that's quite some time
2020-11-10 15:15:15 <m242> 16 years
2020-11-10 15:49:50 <ncopa> yeah, we should probably keep openjdk8...
2020-11-10 16:04:17 <ncopa> 3.13 builders are up (except mips64...)
2020-11-10 16:21:39 <Hello71> I think 2030 is only for oracle paid support? anyways, jdk8 is still for a few years at least
2020-11-10 16:32:29 <dne> 2026 for amazon corretto 8
2020-11-10 17:05:26 <wsinatra> ncopa: would you be bothered if I submitted a MR to enabled the omap API in libdrm?
2020-11-10 17:25:37 <ikke> hmm, anyone knows what this means? "checking if static linking is possible... no"
2020-11-10 17:25:42 <ikke> from autoncif
2020-11-10 17:25:46 <ikke> autoconfig*
2020-11-10 17:27:50 <dalias> ikke, look at config.log and see what the failing test was
2020-11-10 17:27:54 <dalias> or read configure.ac
2020-11-10 17:28:34 <ikke>     AC_LINK_IFELSE([AC_LANG_PROGRAM(,)],
2020-11-10 17:29:12 <ikke> ah
2020-11-10 17:29:20 <ikke> cannot find -lexecinfo
2020-11-10 17:29:28 <ikke> dalias: thanks
2020-11-10 17:31:20 <dalias> ...
2020-11-10 17:31:37 <ikke> ?
2020-11-10 17:33:15 <ikke> I forgot that was a config.log file that contained the results
2020-11-10 17:33:40 <dalias> i mean like wtf why are they doing a link test with a library they didn't test existence of
2020-11-10 17:33:53 <dalias> or did they only test dynamic linking it first and find it?
2020-11-10 17:34:10 <dalias> if you're going to static link you need to test that before testing libs, then use -static in all your lib tests
2020-11-10 17:34:22 <dalias> so you don't detect libs you don't have static versions of
2020-11-10 17:34:39 <ikke> aha, probably
2020-11-10 17:38:08 <ikke> I know too litle about autoconfig to tell
2020-11-10 17:39:20 <ikke> I only see a comment that libexecinfo is required for freebsd
2020-11-10 17:39:24 <mps> ikke: sorry for break your work, but what should go in commit msg when fixing issue report but not close it? fixes: #12072
2020-11-10 17:40:09 <mps> last time we worked on similar thing something with this didn't worked
2020-11-10 17:40:47 <ikke> mps: no, not fixes, that would close it
2020-11-10 17:40:51 <ikke> See #1234
2020-11-10 17:40:52 <mps> and because issue is strictly about linux-edge maybe 'closes: #12072' is appropriate
2020-11-10 17:41:01 <ikke> mps: well, then yes
2020-11-10 17:41:23 <mps> ok, thanks, will use 'closes:'
2020-11-10 17:43:35 <dalias> i like making links in the opposite direction
2020-11-10 17:44:13 <dalias> commenting in the tracker that commit $id did something relevant to the issue
2020-11-10 17:44:47 <dalias> but this is just part of my view of commits as the permanent authoritative document and issue trackers as something hosting-specific :-p
2020-11-10 17:44:51 <ikke> dalias: That automaticaly happens this way
2020-11-10 17:45:03 <ikke> The issue will contain a record back to the commit
2020-11-10 17:45:15 <dalias> i.e. putting the reference to the permanent thing in the ephemeral one rather than the reference to the ephemeral thing in the permanent one :)
2020-11-10 17:55:16 <mps> good, it worked
2020-11-10 18:04:03 <c705> dalias: so, firefox is still broken as of last night
2020-11-10 18:04:11 <c705> does this have an issue being tracked?
2020-11-10 18:06:57 <ikke> c705: this one? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12061
2020-11-10 18:09:25 <c705> ikke: yeah, thanks
2020-11-10 18:09:42 <c705> I thought !14152 was merged, but the pipeline failed
2020-11-10 18:09:45 <mps> I rebuilt FF without pulse, pipewire and 'wifi' things an it is quite stable on my aarch64 edge box
2020-11-10 18:10:18 <mps> and without dbus
2020-11-10 18:10:42 <c705> on edge?
2020-11-10 18:11:35 <afontain_> huh, we can't have pipewire on musl, right?
2020-11-10 18:11:40 <afontain_> did you disable that explicitely?
2020-11-10 18:11:50 <afontain_> *explicitly
2020-11-10 18:12:50 <mps> afontain_: no, removed it in makedepends
2020-11-10 18:13:10 <mps> didn't saw anywhere to disable it explicite
2020-11-10 18:13:18 <afontain_> oh, nevermind, I confused that with something else
2020-11-10 18:13:20 <mps> option to disable*
2020-11-10 18:15:15 <Cogitri> fwiw FF doesn't crash either for me with all of those enables
2020-11-10 18:15:30 <Cogitri> And we need them for Wayland screenshare and mic with pulseaudio
2020-11-10 18:20:58 <c705> Cogitri: under edge with linux-edge?
2020-11-10 18:21:39 <c705> fwiw, the process doesn't crash, but the forks segfault and tabs won;t work unless you flip the sandbox off
2020-11-10 18:22:00 <ikke> I only noticed that what -esr
2020-11-10 18:25:10 <Cogitri> I don't use esr
2020-11-10 18:26:09 <ikke> me neither, but I did test it
2020-11-10 18:28:27 <Cogitri> Ah yes, I should've said "I didn't test with ESR so dunno what's the situation there"
2020-11-10 18:29:06 <ikke> messy
2020-11-10 18:32:06 <mps> uhm, I'm wrong, sorry. sometimes FF (non -esr) freezes and only solution is to kill it and start again
2020-11-10 18:32:41 <mps> such things became normal working on edge and not only for FF, so I forgot about it
2020-11-10 18:40:55 <c705> yes, I have experienced that ff issue, this is different
2020-11-10 18:41:11 <c705> the seccomp filters are messed up
2020-11-10 18:41:42 <ikke> c705: strange thing is that nmeum had patch, where some people said they didn't saw tabs freezing anymore, but still got seccomp violations
2020-11-10 18:43:00 <c705> is the patch shipped to edge though?
2020-11-10 18:43:10 <c705> I see a MR but pipeline failed
2020-11-10 18:43:13 <ikke> no
2020-11-10 18:44:28 <c705> if that mr will be shipped, i can test
2020-11-10 18:50:31 <ikke> c705: the idea was to test it properly before it shipped
2020-11-10 18:50:47 <ikke> c705: moreso because nmeum does not really understand why this would fix it in the first place
2020-11-10 18:56:44 <dalias> c705, the MR was wrong. wrong ioctl
2020-11-10 18:56:53 <dalias> i commented on it now
2020-11-10 18:59:23 <c705> and how would one test the patch before it was shipped. I imagine I'd have to build a new package with the patch shipped in my local aports?
2020-11-10 18:59:42 <ikke> c705: the artifacts for a MR will contain the built package
2020-11-10 19:00:37 <c705> oh, cool. I can step through this tonight. it's a shame, you folks are all in bed when I finish work and I get some free time
2020-11-10 19:01:38 <ikke> hm, but not if the MR failed
2020-11-10 19:01:50 <nmeum> the MR is wrong anyhow
2020-11-10 19:07:32 <c705> if that could be fixed, i'd love to test it
2020-11-10 19:08:38 <dalias> right, the MR is wrong so don't expect it to fix anything
2020-11-10 19:08:48 <dalias> the author typo'd s/G/S/
2020-11-10 19:09:33 <dalias> so it's allowing a new ioctl thru, but the wrong one, and specifically one that should not be allowed unless you want runaway code exec in the content process changing your xterm size :-P
2020-11-10 19:10:43 <ikke> Sounds fun
2020-11-10 19:22:38 <c705> soo if the mr is wrong, can someone fix it?
2020-11-10 19:45:12 <wsinatra> just a heads up, it looks like the armv7/hf builders are stuck on openjdk7
2020-11-10 20:11:04 <ollieparanoid[m]> hey all! with the wlroots update in edge, phosh is crashing due to a new consistency check
2020-11-10 20:11:41 <ollieparanoid[m]> so please review this quickly: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14522
2020-11-10 20:34:54 <Cogitri> ollieparanoid[m]: Done
2020-11-10 20:35:32 <ollieparanoid[m]> Cogitri: thanks!
2020-11-11 01:40:20 <the6543> @ncopa hi
2020-11-11 02:41:49 <c705> Error relocating /usr/bin/dbus-daemon: _dbus_group_info_free_allocated: symbol not found
2020-11-11 02:42:10 <c705> is this not tested before it goes to edge? I'm getting pretty sick of this
2020-11-11 03:42:57 <maxice8> Can't reproduce it here
2020-11-11 03:45:03 <c705> what kernel?
2020-11-11 03:45:11 <maxice8> edge
2020-11-11 03:45:16 <c705> what version
2020-11-11 03:45:29 <maxice8> 5.9.6-0-edge
2020-11-11 03:45:39 <c705> isn't it 6.1 now
2020-11-11 03:45:43 <c705> 5.9.6-1
2020-11-11 03:46:10 <maxice8> it is 5.9.7 but I didn't reboot into it yet
2020-11-11 03:46:30 <c705> okay, i'll build mine and let's just see
2020-11-11 03:46:48 <c705> I had 6-1, and it was my mistake not to check, swear 6-1 was just released yesterday
2020-11-11 03:46:51 <maxice8> I doubt the kernel is the one causing that
2020-11-11 03:47:16 <c705> i know it is, I had v3.12 under both linux-lts and linux-edge and lts is fine
2020-11-11 03:59:21 <dalias> any ideas what this might be? https://stackoverflow.com/q/64779005/379897
2020-11-11 04:06:11 <c705> sorry, this was entirely my mistake
2020-11-11 04:06:23 <c705> my apoligies about my little meltdown too - it's been a rough day for me
2020-11-11 04:07:34 <maxice8> dalias: that might explains the loads of segfaults in 3.13 builders
2020-11-11 04:09:05 <dalias> i think it's just a hardware fault
2020-11-11 04:09:40 <dalias> we had someone in #musl earlier this year utterly convinced they had a bug in musl because the same thing worked on glibc but crashed erratically on musl
2020-11-11 04:09:49 <dalias> sure enough it went away when they turned off their overclocking
2020-11-11 04:09:59 <maxice8> oh
2020-11-11 04:10:23 <dalias> it baffles me that ppl still overclock
2020-11-11 04:10:53 <dalias> like, it's not the 90s where vendors are cautiously selling cpus rated for 80-90% of the speed they can actually do
2020-11-11 04:11:02 <dalias> modern cpus are already horribly overclocked out of the box
2020-11-11 04:11:10 <dalias> and of questionable reliability
2020-11-11 04:11:24 <dalias> if you want a working system without side channel leaks you have to massively underclock them
2020-11-11 04:12:19 <dalias> sorry for the rant :)
2020-11-11 04:12:35 <insep_> but muh games
2020-11-11 04:26:28 <dalias> :)
2020-11-11 07:28:07 <ncopa> good morning
2020-11-11 07:29:08 <m242> \o
2020-11-11 07:30:33 <ikke> o/
2020-11-11 07:31:59 <Cogitri> 👋
2020-11-11 07:33:49 <ncopa> Ariadne: any news on the mips64 machine?
2020-11-11 07:35:50 <ncopa> heh. kernel 5.4.76 is out, but looking at the git log, it may be worth waiting for 5.4.77... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.4.y
2020-11-11 07:39:39 <mps> last week there were 3 releases of 5.9 (stable? :) ) on less than 24 hours
2020-11-11 07:53:08 <insep_> dalias: :) because no non-free games work on musl? :D
2020-11-11 08:14:51 <mps> hmm, musl doesn't have reallocarray?
2020-11-11 08:18:38 <mps> do we have it in some 'extra' library/header on alpine
2020-11-11 08:25:34 <Ariadne> ncopa: working on it
2020-11-11 09:24:47 <mps> ncopa: 5.4.77 is already made, https://cdn.kernel.org/pub/linux/kernel/v5.x/patch-5.4.77.xz
2020-11-11 09:25:27 <mps> but not yet officially announced, GKH is probably in 'sleeping' TZ
2020-11-11 09:30:50 <mps> new intel microcode is released https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20201110
2020-11-11 09:31:41 <mps> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html
2020-11-11 09:45:21 <ncopa> 👍
2020-11-11 09:51:23 <ncopa> Ariadne: do you think we can use ifupdown as hard dependency for openrc now? or do we want keep busybox as fallback for 3.13?
2020-11-11 09:52:07 <Ariadne> i think we can
2020-11-11 09:54:11 <ncopa> due to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/10799
2020-11-11 09:54:27 <ncopa> then we can use ifquery so "source" works
2020-11-11 09:55:21 <ncopa> next question is if we want use it as hard dependency
2020-11-11 09:57:40 <mps> no, please
2020-11-11 10:04:17 <ncopa> ok
2020-11-11 10:10:42 <HRio> mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14537
2020-11-11 10:11:07 <mps> HRio: I see, just removed my prepared MR :)
2020-11-11 10:11:31 <HRio> did for 3.10, 3.11 and 3.12 as well
2020-11-11 10:12:10 <HRio> s/did/prepared/
2020-11-11 10:12:10 <alpine-meetbot> HRio meant to say: prepared for 3.10, 3.11 and 3.12 as well
2020-11-11 10:12:26 <mps> ofc, that 'must' be done
2020-11-11 10:19:55 <HRio> mps: Im testing the microcode from edge on a few intel boxes, before merging to stable
2020-11-11 10:23:11 <mps> good. I have only one intel box where I can test
2020-11-11 10:24:18 <mps> but ime this usually works out-of-the-box
2020-11-11 10:31:36 <Ariadne> ncopa: well
2020-11-11 10:33:09 <Ariadne> ncopa: if we depend on ifquery period, it must be hard dependency.  but i think we should be conservative for 3.13 :)
2020-11-11 10:33:33 <Ariadne> ncopa: if ifupdown-ng is installed, you will get networking openrc service that uses ifquery :)
2020-11-11 10:34:11 <Ariadne> ncopa: so i think we keep it the same, for now, and when we are ready to trim the fat on busybox, we revisit later :)
2020-11-11 10:34:29 <Ariadne> (and in almost all cases ifupdown-ng will be the default anyway)
2020-11-11 10:35:47 <Ariadne> my plan was for 3.13 to support busybox or debian ifupdown packages
2020-11-11 10:36:02 <Ariadne> so that if there is some unknown corner case
2020-11-11 10:36:06 <Ariadne> we can solve it for 3.14
2020-11-11 10:36:23 <Ariadne> repeat until all concerns are solved
2020-11-11 10:36:46 <mps> agree
2020-11-11 10:37:56 <Ariadne> re mips64: pyvpx should be on site today or tomorrow to reboot the console server.  we think that the modem in the console server is wedged and needs to be reset
2020-11-11 10:38:10 <Ariadne> (the console server provides the conneciton to the mips64 builder)
2020-11-11 10:42:09 <Ariadne> for example
2020-11-11 10:43:08 <Ariadne> somebody somewhere may have behavior that depends on some weird thing that legacy ifupdown does :P
2020-11-11 10:43:40 <mps> that is what I also 'fear'
2020-11-11 10:43:42 <Ariadne> we want to make sure that kind of user has time to fix his setup (or come complain to us to support his usecase)
2020-11-11 10:45:05 <ikke> Should add this to the draft release notes
2020-11-11 10:45:36 <Ariadne> however with that said, we've been testing with alpine and debian users in the field with very esoteric setups and so far so good.
2020-11-11 10:45:51 <Ariadne> but if i learned anything from pkgconf, there's always somebody doing something weird
2020-11-11 10:45:56 <Ariadne> i am sure it will come up (:
2020-11-11 10:46:17 <ikke> hostname $(hostname) :P
2020-11-11 10:46:34 <Ariadne> some people still come and demand bug-compatibility in pkgconf :)
2020-11-11 11:01:23 <mps> ncopa: https://lwn.net/Articles/836795/ 'I'm announcing the release of the 5.4.77 kernel'
2020-11-11 11:02:16 <mps> and this 'Hint, if you are using SGX, then upgrade.' from https://lwn.net/Articles/836794/
2020-11-11 11:02:16 <ikke> "Hint, if you are using SGX, then upgrade.  And then possibly reconsider
2020-11-11 11:02:19 <ikke> the decisions you have recently made that caused you to write special
2020-11-11 11:02:21 <ikke> code to use that crazy thing. "
2020-11-11 11:02:23 <ikke> :D
2020-11-11 11:03:12 <mps> I always thought that AI is not possible but 'someone' makes me doubtful :)
2020-11-11 11:04:03 <ikke> What is SGXA
2020-11-11 11:04:10 <ikke> SGX*
2020-11-11 11:04:46 <dne> https://en.wikipedia.org/wiki/Software_Guard_Extensions
2020-11-11 11:04:47 <alpine-meetbot> [WIKIPEDIA] Software Guard Extensions | "Intel Software Guard Extensions (SGX) is a set of security-related instruction codes that are built into some modern Intel central processing units (CPUs). They allow user-level as well as operating system code to define private regions of memory, called enclaves, whose contents are protected and unable..."
2020-11-11 11:05:49 <detha> s/protected/somewhat protected/
2020-11-11 11:06:28 <dne> 7 attacks listed on that page :)
2020-11-11 11:07:52 <HRio> mps: intel-ucode update now in 3.10, 3.11 and 3.12 as well
2020-11-11 11:08:21 <mps> HRio: yes, I see (I'm on #alpine-commits channel)
2020-11-11 11:08:49 <mps> HRio: well done :)
2020-11-11 11:08:53 <mps> and fast
2020-11-11 11:34:30 <HRio> tried it on 3 different Intel boxes, all I had that could be rebooted during office hours :-)
2020-11-11 12:08:15 <ikke> Lesson about how distros should be carefull with local patches: https://securitylab.github.com/research/Ubuntu-gdm3-accountsservice-LPE
2020-11-11 12:18:57 <insep_> > liking ubuntu
2020-11-11 12:19:04 <insep_> the bug is kinda fun though
2020-11-11 12:19:15 <insep_> i like it
2020-11-11 12:20:48 <mps> a lot of layers and services is less secure, nothing new
2020-11-11 12:21:33 <mps> every layer (abstraction) or service add insecurity and not linearly but exponentially
2020-11-11 12:21:57 <mps> and instabillity as a free bonus :)
2020-11-11 12:27:24 <ikke> In the HN thread, they also linked to the Debian issue where a maintainer patched out entropy to silence a valgrind warning
2020-11-11 12:27:39 <ikke> http://taint.org/2008/05/13/153959a.html
2020-11-11 12:27:51 <ikke> (in openssh)
2020-11-11 12:35:28 <mps> ikke: that is my biggest fear for any distro, especially alpine
2020-11-11 12:36:37 <mps> but some upstream are reluctant or even unpleasant so the distro must do these things from time to time
2020-11-11 12:37:33 <ikke> Yes, it's a fine balance, and a struggle
2020-11-11 12:37:58 <mps> but yes, lowering threshold to have more contributors always lead to bad things
2020-11-11 12:38:02 <ikke> But at least we need to be diligent in trying to upstream things first
2020-11-11 12:39:02 <mps> heh, I have some fixes posted to some upstream about year ago and no answer
2020-11-11 12:39:33 <mps> and bugs reported to kernel.org staying for months without answers
2020-11-11 12:49:27 <the6543> hi
2020-11-11 12:49:53 <maxice8> hi
2020-11-11 12:49:55 <the6543> I'm wondering why I can approve merge requests on aports now ...
2020-11-11 12:50:03 <ikke> new feature in gitlab
2020-11-11 12:50:26 <the6543> oho does it have some roules?
2020-11-11 12:50:42 <Ariadne> can we disable that on aports.git
2020-11-11 12:50:50 <Ariadne> i dont think it makes much sense there
2020-11-11 12:51:10 <ikke> It would make sense for maintainers to approve changes
2020-11-11 12:51:31 <Ariadne> that  part sure, but in the absence of being able to restrict the scope :P
2020-11-11 12:51:31 <the6543> I think it would make sence If ... for example I as maintainer can approve changes specific to packages I maintain
2020-11-11 12:51:42 <mps> to me it looks useless
2020-11-11 12:51:53 <ikke> But afaik there is no way to disable or restrict it
2020-11-11 12:52:11 <Ariadne> the development forge of the future
2020-11-11 12:52:21 <Ariadne> well, at least we didn't go with pagure
2020-11-11 12:52:26 <Ariadne> [insert pagure joke here]
2020-11-11 12:52:40 <the6543> ...
2020-11-11 12:52:53 <the6543> it looks already restricted to me
2020-11-11 12:53:07 <mps> gitolite is still 'the best'
2020-11-11 12:53:13 <the6543> for example I can not approve !14545
2020-11-11 12:53:15 <ikke> gitolite is just ACL
2020-11-11 12:53:44 <the6543> my own one (12065) I can...?
2020-11-11 12:53:51 <Ariadne> honestly pagure was the one i wanted to see win out
2020-11-11 12:54:10 <Ariadne> but with redhat killing it off
2020-11-11 12:54:14 <Ariadne> oh well :)
2020-11-11 12:54:26 <ikke> the6543: right, but we cannot add or remove any restrictions besides that
2020-11-11 12:54:30 <Ariadne> the6543: hooray! you can approve your own merge requests.  very useful, that
2020-11-11 12:54:45 <mps> ikke: yes, acl only and because this is best
2020-11-11 12:55:25 <the6543> ok so it's just nonesence ...
2020-11-11 12:55:30 <Ariadne> as i explained to drew devault numerous times, email-based workflow doesn't mesh well with the AOL generation
2020-11-11 12:57:14 <the6543> > pagure was the one i wanted to see win out
2020-11-11 12:57:23 <the6543> I like to see gitea rise up ;)
2020-11-11 12:57:42 <ikke> We experimented with gitea (and gogs)
2020-11-11 12:57:51 <ikke> but they could not handle aports at the time
2020-11-11 12:57:59 <HRio> running gitlab-ee but I have an option to disable self approval.
2020-11-11 12:58:01 <insep_> pagure uses bootstrap, that's enough for me to like it
2020-11-11 12:58:09 <HRio> can be set for author or all commiters in the MR
2020-11-11 12:58:12 <ikke> HRio: yea, ee has more options
2020-11-11 12:58:29 <ikke> also things like required approval
2020-11-11 12:58:47 <the6543> yes gitea still - sadly - has some majoir performance issues
2020-11-11 12:58:55 <the6543> it's getting better ...
2020-11-11 12:59:30 <ikke> does gitea / gogs have some kind of CI integration?
2020-11-11 12:59:39 <insep_> maybe they should do go => rust, that helped discord /s
2020-11-11 13:01:06 <HRio> and code owners can be setup for different parts of the code, in the approval restrictions. (via a CODEOWNERS file)
2020-11-11 13:01:25 <ikke> yes, all require ee, which we don't have (nor want)
2020-11-11 13:01:42 <HRio> yes I know, but lets hope it will come to core
2020-11-11 13:01:47 <ikke> \yup
2020-11-11 13:02:00 <HRio> every release have ee stuff beeing moved to core
2020-11-11 13:02:49 <ikke> We're behind a few releases, so I need to make some progress
2020-11-11 13:02:59 <the6543> does gitea have kind of CI ... yes but only external via drone, jenkins, ...
2020-11-11 13:03:15 <ikke> right
2020-11-11 13:03:21 <ikke> I was suspecting something like that
2020-11-11 13:03:23 <the6543> gite has no  approval restrictions by the way ...
2020-11-11 13:03:45 <the6543> gitlab is still not a bad choice
2020-11-11 13:26:50 <the6543> once it got cached ... you can look at it:
2020-11-11 13:26:53 <the6543> <https://try.gitea.io/abcKing/aports/src/branch/master/community>
2020-11-11 13:28:36 <ikke> Right, it taks a bit of time, but shows everything
2020-11-11 13:28:40 <ikke> gitlab limits to 1000 entries
2020-11-11 13:43:22 <the6543> by the way
2020-11-11 13:43:44 <the6543> should I rebase my pull always to latest until it got merged when it is ready?
2020-11-11 13:44:03 <ikke> the6543: usually the person that is merging will rebase
2020-11-11 13:44:10 <wsinatra> does anyone know why sha512sums might fail to match in the builders, but work otherwise? (whenever I abuild -r on any of my alpine systems things just seem to work)
2020-11-11 13:44:35 <the6543> ok
2020-11-11 13:44:43 <ikke> wsinatra: The builders cache the packages they downloaded
2020-11-11 13:44:55 <Hello71> more likely your system cached it
2020-11-11 13:45:01 <ikke> or that
2020-11-11 13:45:24 <ikke> /var/cache/distfiles
2020-11-11 13:46:40 <dalias> mps, reallocarray was approved just overlooked. i'll try to get it in this release cycle. but it's a pure library function you can just drop in to whatever program needs it
2020-11-11 13:48:08 <wsinatra> ahhh that explains a lot, hopefully a little rm and re-checksum will fix things :) thanks!
2020-11-11 13:49:42 <Hello71> also ensure that you have not named your distfiles "v5.0.tar.gz" or somesuch
2020-11-11 13:50:03 <ikke> abuild would warn about that though
2020-11-11 13:50:14 <ikke> at least, $pkver.tar.gz
2020-11-11 13:50:33 <Hello71> hm, I thought it was only in some lint
2020-11-11 13:52:27 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L260
2020-11-11 13:52:59 <Hello71> mm.
2020-11-11 13:53:01 <mps> dalias: ok, thanks
2020-11-11 13:53:47 <wsinatra> yeah I always make sure it's $pkgname-$pkgver at an absolute minimum. I'd go insane trying to sort tarballs if they were just $pkgver
2020-11-11 14:41:43 <the6543> I dont know If im allowed to ask ... just !12065 is ready :)
2020-11-11 14:42:09 <the6543> PS: thanks for the two :eyes: who found the typos
2020-11-11 14:45:14 <ikke> You're always allowed to ask / ping (in reasonability) :)
2020-11-11 14:56:49 <ikke> ncopa: openrc tests are failing (trying to find interfaces)
2020-11-11 16:26:00 <maxice8> ping Ikke, do we have aports:rename ?
2020-11-11 16:28:48 <ikke> maxice8: apparently not
2020-11-11 16:28:55 <maxice8> ok
2020-11-11 16:29:04 <maxice8> ty
2020-11-11 16:29:07 <ikke> I assume you are requesting it?
2020-11-11 16:29:30 <maxice8> Just to know, I'm working on autolabelling support for aports-qa-bot
2020-11-11 16:29:37 <ikke> right
2020-11-11 16:29:45 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/labels
2020-11-11 16:31:16 <maxice8> also any plans for using the `::` labels for tracking the state of the MR ?
2020-11-11 16:31:40 <ikke> maxice8: Right now, it would just look like foo::bar
2020-11-11 16:31:53 <ikke> scoped labels are EE only
2020-11-11 16:31:58 <maxice8> oh
2020-11-11 16:32:00 <maxice8> forgot that
2020-11-11 16:32:34 <ikke> I tried it when you mentioned it
2020-11-11 16:35:03 <maxice8> Currently autolabel only labels aports:{move,upgrade,new,remove}
2020-11-11 16:35:11 <maxice8> any other labels that might me nice to have autolabelling for ?
2020-11-11 16:35:36 <ikke> I can't think of anything
2020-11-11 16:49:19 <maxice8> Also seems like we can't run tests on aports-qa-bot
2020-11-11 16:49:32 <maxice8> https://gitlab.alpinelinux.org/Leo/aports-qa-bot/-/jobs/246046
2020-11-11 16:49:39 <maxice8>  This job is stuck because you don't have any active runners online or available with any of these tags assigned to them: docker-alpine
2020-11-11 16:49:40 <ikke> You need to enable shared runners
2020-11-11 16:49:46 <ikke> in CI/CD
2020-11-11 16:49:49 <ikke> settings
2020-11-11 17:09:32 <maxice8> ah ty, I'll see if Cogitri enabled that
2020-11-11 17:09:43 <ikke> You need to enable that on your projcet
2020-11-11 17:09:54 <ikke> CI jobs run in the project they are triggered from
2020-11-11 17:10:03 <ikke> maxice8: https://gitlab.alpinelinux.org/Leo/aports-qa-bot/-/settings/ci_cd
2020-11-11 17:11:03 <maxice8> oh
2020-11-11 17:12:13 <maxice8> ty
2020-11-11 18:03:53 <maxice8> openrc failing on master
2020-11-11 18:07:47 <mps> hm yes, Checking spacing style ...grep: bad regex '\){': Invalid contents of {}
2020-11-11 18:09:01 <mps> do it need gnu grep for this
2020-11-11 18:09:33 <mps> will look in 20 minutes
2020-11-11 18:14:54 <mps> hmm, it passed on my lxc
2020-11-11 18:16:37 <mps> maybe builders need to upgrade something
2020-11-11 18:22:23 <dalias> good news: i have a patch series that seems to be working for MT-fork without the lock order hell
2020-11-11 18:23:30 <mps> dalias: \o/
2020-11-11 19:29:51 <the6543> can someone set automerge to 12065 again - it was aborted because target branch updated
2020-11-11 19:29:53 <the6543> ?
2020-11-11 19:33:26 <maxice8> !12065
2020-11-11 19:40:02 <the6543> @maxice8 are you Leo on GL?
2020-11-11 19:40:08 <maxice8> yes
2020-11-11 19:40:17 <the6543> ah that explain some things ...
2020-11-11 19:40:25 <the6543> thanks :)
2020-11-11 19:40:59 <the6543> it's just not easy to match the two nics ...
2020-11-11 19:41:41 <maxice8> Leo is taken on IRC unfortunately
2020-11-11 19:42:08 <the6543> ok then there is no way around ...
2020-11-11 19:43:22 <insep_> 
ACTION has 4 nicknames at least

2020-11-11 20:57:44 <dalias> sent new mt-fork series to list
2020-11-11 21:11:48 <mps> just read it, last patch is big for me to understand it but I trust you
2020-11-11 21:52:56 <kpcyrd> I wrote up a basic proposal for abuild buildinfo files, feedback very welcome: https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10014
2020-11-11 22:57:59 <andypost> openrc blocked edge builders(
2020-11-11 23:13:43 <mps> andypost: yes, I tried in my lxc and it builds fine. so have no idea why it fails on builders
2020-11-11 23:17:58 <andypost> mps, locally it does not throw - Did not find eth0
2020-11-11 23:18:51 <mps> as I see in build logs it fails with this msg: Checking spacing style ...grep: bad regex '\){': Invalid contents of {}
2020-11-11 23:19:43 <andypost> ah yes, but on builders other error, which could be reason why it not fails locally
2020-11-11 23:20:31 <mps> and yes I see on builders that it can't find some eth{0,1,2)
2020-11-11 23:21:16 <mps> and I don't know what eth builders have
2020-11-11 23:22:01 <andypost[m]> locally I have no eth too - it is eno1)
2020-11-11 23:22:04 <mps> someone with builders access have to check this
2020-11-11 23:23:36 <mps> also, on my lxc I don't have eth0 but eth0@if112
2020-11-11 23:26:13 <Ariadne> why does openrc have tests that depend on what eth a box has
2020-11-11 23:26:36 <mps> who knows
2020-11-11 23:27:00 <andypost> that's custom test script https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/openrc/test-networking.sh
2020-11-11 23:28:06 <andypost> ah, that's last commit https://gitlab.alpinelinux.org/alpine/aports/-/commit/8c8f379f1069d874bb6481ded7bb671ced7b0128
2020-11-11 23:29:00 <mps> good, fixed :)
2020-11-11 23:29:23 <Ariadne> yeah these tests are bogus
2020-11-11 23:29:25 <Ariadne> i disabled them
2020-11-11 23:29:26 <Ariadne> :)
2020-11-11 23:29:36 <mps> I see, and good night all
2020-11-11 23:30:05 <Ariadne> and in 3.14 that initscript will probably be irrelevant anyway
2020-11-12 00:31:43 <qrvpzvb> Ariadne: If I may ask, why won't they be?
2020-11-12 00:47:08 <Ariadne> why won't what be
2020-11-12 00:47:28 <qrvpzvb> initscript relevant
2020-11-12 07:23:00 <ncopa> morning
2020-11-12 07:25:49 <ncopa> sorry about the broken openrc test. i did try set up a temp test interfaces file and state file
2020-11-12 07:27:05 <ncopa> I added the test because I think the init.d script had a bug on finding the current running interfaces
2020-11-12 07:27:27 <mps> but it worked in lxc, so I don't understand why it fails on builders
2020-11-12 07:27:32 <ncopa> does anyone have the exact error message?
2020-11-12 07:28:23 <mps> https://tpaste.us/PKKe
2020-11-12 07:31:11 <ncopa> oh
2020-11-12 07:32:18 <ncopa> what arch was it?
2020-11-12 07:33:20 <mps>  https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/openrc/openrc-0.42.1-r15.log
2020-11-12 07:33:22 <ncopa> i think the tests will fail if ifupdown-ng is *not* installed on the builder
2020-11-12 07:34:29 <ncopa> openrc does not depedn on ifupdown-ng, it depends on ifupdown-any
2020-11-12 07:34:48 <mps> ah, could be
2020-11-12 07:35:42 <mps> I have ifupdown-ng on lxc where it builds fine
2020-11-12 07:35:48 <ncopa> but test does use a temp interfaces and state file, and should not depend on the interfaces on the host
2020-11-12 07:36:08 <ncopa> ifupdown-ng is installed on build-edge-armhf too
2020-11-12 07:36:39 <mps> it failed on all arches on builders
2020-11-12 07:36:46 <ncopa> hum
2020-11-12 07:37:20 <ncopa> weird
2020-11-12 07:38:00 <ncopa> running the test manually passes on build-edge-armhf
2020-11-12 07:38:10 <mps> hmm, not 100% sure but from memory looking on #alpine-commits I think 'on all arches'
2020-11-12 08:41:52 <ncopa> seems like we have many bug reports on timezone related issues
2020-11-12 08:52:38 <Cogitri> Yup, lots of stuff doesn't like the new format of tzdata
2020-11-12 08:56:29 <Ariadne> ncopa: the init script won't be used on ifupdown-ng anyway
2020-11-12 09:24:08 <ncopa> ok?
2020-11-12 09:24:28 <ncopa> how does openrc start ifupdown-ng then?
2020-11-12 09:28:04 <ncopa> any opinions on adding zfs-rpi package for aarch64?
2020-11-12 09:29:38 <ikke> There seems to be interest in it
2020-11-12 09:30:09 <ncopa> its relatively easy for us to add it, but inconvenient to build it manually for end users
2020-11-12 09:30:29 <ikke> Then I would say, go for it
2020-11-12 09:31:25 <ncopa> ok
2020-11-12 09:34:51 <Ariadne> ncopa: ifupdown-ng-openrc has its own /etc/init.d/networking
2020-11-12 09:55:59 <PureTryOut[m]2> Uh, does `arch="all !x86"` not block a package for x86 anymore? The CI tried to build it on that arch anyway
2020-11-12 09:57:28 <ikke> PureTryOut[m]2: it should
2020-11-12 09:58:07 <PureTryOut[m]2> !14565 built it anyway...
2020-11-12 09:59:30 <ikke> https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/246263#L698
2020-11-12 09:59:35 <ikke> PureTryOut[m]2: it's failing on x86_64
2020-11-12 09:59:54 <PureTryOut[m]2> Oh lol what the actual fuck
2020-11-12 10:00:09 <PureTryOut[m]2> I guess I need to wakeup still
2020-11-12 10:00:19 <PureTryOut[m]2> Strange though, previous pipeline did succeed on x86_64 🤷‍♂️
2020-11-12 10:08:39 <ikke> Now it succeeded
2020-11-12 10:09:41 <ikke> I hope it's not flaky
2020-11-12 10:09:56 <ikke> "No rule to make target 'src/org.kde.kclockd.KClockSettings.xml', needed by 'src/kclock/kclocksettingsinterface.cpp'.  Stop.
2020-11-12 10:12:22 <PureTryOut[m]2> Yeah that failure is why I disabled it on x86
2020-11-12 10:46:00 <ncopa> build-3-13-mips64 is up, which means that all 3.13 builders are up now
2020-11-12 10:57:56 <Cogitri> Nice
2020-11-12 11:05:37 <PureTryOut[m]2> 🎉
2020-11-12 12:14:28 <PureTryOut[m]2> nmeum: you maintain android-tools right? Could you move it from testing to community? The APKBUILD could also use some modernization
2020-11-12 12:20:19 <nmeum> PureTryOut[m]2: I don't really want to move it to community as it is based on a custom cmake setup of mine and I really can't guarantee long-term support for this
2020-11-12 12:20:32 <nmeum> I am also working on an upgrade currently, so I will modernize the APKBUILD while at it
2020-11-12 12:21:14 <PureTryOut[m]2> Hmm, I quite want adb in a stable release though 😢
2020-11-12 12:21:41 <PureTryOut[m]2> I saw the cmake setup, looks nice
2020-11-12 12:22:07 <PureTryOut[m]2> I wonder how other distros handle it though
2020-11-12 12:22:18 <nmeum> some use my cmake setup (e.g. void)
2020-11-12 12:22:25 <nmeum> others have custom scripts (e.g. arch)
2020-11-12 12:22:48 <ikke> https://github.com/archlinux/svntogit-community/blob/packages/android-tools/trunk/PKGBUILD
2020-11-12 12:22:52 <PureTryOut[m]2> Yeah I was looking at Arch atm, they seem to use their makepkg git support
2020-11-12 12:23:17 <nmeum> it's a big mess and from my perspective google should get their stuff sorted out to allow downstream to package these tools properly
2020-11-12 12:23:28 <nmeum> atm the code doesn't even compile with g++ without a lot of patches
2020-11-12 12:23:33 <PureTryOut[m]2> Yes they should, but I doubt they will 😢
2020-11-12 12:23:37 <ikke> I don't think google care a lot about that
2020-11-12 12:23:43 <nmeum> I don't think so either
2020-11-12 12:24:26 <nmeum> but as it is currently I can't really guarantee 6 months support, especially when it comes to security fixes and such
2020-11-12 12:24:34 <nmeum> that's why it is still in testing
2020-11-12 12:25:23 <PureTryOut[m]2> Too bad
2020-11-12 12:27:00 <nmeum> yep, I am not happy with the current situation either
2020-11-12 12:27:40 <nmeum> especially because upgrading this stuff is annoying
2020-11-12 12:28:32 <PureTryOut[m]2> I was glad that we have things like pmOS now, until I learned that the modem on at least the PinePhone runs some form of Android internally and to upgrade the firmware we need adb 😒
2020-11-12 12:30:58 <PureTryOut[m]2> It seems that once you have the sources, it's mainly a matter of compiling the internal version of boringssl using cmake, and the tools itself using ninja? Of course only talking about compiling it, but maybe it's worth mirroring the sources and doing it that way?
2020-11-12 12:37:19 <insep_> PureTryOut (matrix.org): how about running pmos or alpine on modem
2020-11-12 12:37:36 <PureTryOut[m]2> That would need fastboot to install, which still means getting android-tools
2020-11-12 12:38:11 <nmeum> PureTryOut[m]2: that basically what my cmake setup does
2020-11-12 12:38:47 <nmeum> though I wasn't really able to use the existing build system to just build adb and fastboot
2020-11-12 12:39:43 <PureTryOut[m]2> ah I guess the cmake setup can be a little more selective in what you build?
2020-11-12 12:39:56 <nmeum> yeah
2020-11-12 12:40:30 <nmeum> if you figure out a better way to just build adb, fastboot, and the other tools I am all ears :)
2020-11-12 12:41:06 <PureTryOut[m]2> 😛 I doubt there is any
2020-11-12 12:41:10 <nmeum> independent of the build system the C code will also need quite a few patches to compile with musl and gcc though
2020-11-12 12:41:23 <PureTryOut[m]2> I think other distros just build everything and only install the stuff they need
2020-11-12 12:41:39 <nmeum> really? so far I only saw distros which supplied their own build system as well
2020-11-12 12:42:36 <PureTryOut[m]2> Oh woops, nvm. I saw ninja being used by both Gentoo and Arch and I just assumed that was the upstream build system
2020-11-12 12:42:55 <nmeum> nope, arch has a ruby script for generating ninja files
2020-11-12 12:42:57 <nmeum> no idea what gentoo does though
2020-11-12 12:54:21 <insep_> PureTryOut (matrix.org): i think you can somehow get into edl by other means and in edl you are basically god
2020-11-12 13:32:48 <mps> would we try to upgrade musl with latest patches dalias posted to musl ML
2020-11-12 13:34:19 <Hello71> mp
2020-11-12 13:34:26 <Hello71> mps: would or should?
2020-11-12 13:34:37 <mps> however :)
2020-11-12 13:35:01 <mps> should looks better term :)
2020-11-12 13:35:10 <Hello71> ikke, PureTryOut[m]: seems suspiciously like make -j issue
2020-11-12 13:35:44 <PureTryOut[m]2> Sorry, what are you talking about?
2020-11-12 13:35:48 <mps> Hello71: I'm self taught in english and I'm not good teacher in fields I didn't had previous experience
2020-11-12 13:35:48 <PureTryOut[m]2> I'm missing context
2020-11-12 13:36:09 <Hello71> for kclock
2020-11-12 13:36:33 <PureTryOut[m]2> Ah for it being flaky? Yeah might be
2020-11-12 13:36:40 <PureTryOut[m]2> I'll try changing it later
2020-11-12 13:42:38 <ollieparanoid[m]> hey all! I find parts of APKBUILD Reference#replaces confusing, can somebody help me clear this up? https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10724
2020-11-12 13:45:27 <m242> Hello. I just flagged a package as outdated (k9s), and I noticed that a lot of programs are monitored using https://release-monitoring.org, is there a way to add a package to watch without having an account ?
2020-11-12 13:45:27 <m242> Also, are merge requests on APKBUILD welcome from randoms like me ?
2020-11-12 13:46:36 <insep_> yes to second
2020-11-12 13:47:37 <m242> thanks ^^
2020-11-12 14:29:11 <wsinatra> anyone mind taking one last look at MR !14525 should be good to go
2020-11-12 15:45:16 <PureTryOut[m]2> Uh I just got a bunch of bad signatures warnings while upgrading, seemingly all from util-linux subpackages. Did something go wrong while building that?
2020-11-12 15:48:28 <maxice8> hopefully not, I merged a commit that splits partx binary
2020-11-12 15:50:16 <minimal> I'll tell you in a minute - I've been waiting to test with the new partx subpackage for x86_86 to roll out to the repos (the x86_86 builder was unrelatedly blocked for a while but its now clear)
2020-11-12 15:50:17 <PureTryOut[m]2> Ah seems something went wrong there, the pkgrel didn't get bumped
2020-11-12 15:50:40 <ikke> That would only result in the package not being rebuilt
2020-11-12 15:50:57 <PureTryOut[m]2> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/jxCribhZHxAFVMfXMSglatoV/message.txt >

2020-11-12 15:51:08 <minimal> it did get build for several archs about 1 hour ago so the pkgrel must have been bumped
2020-11-12 15:51:23 <ikke> It was updated before
2020-11-12 15:51:37 <PureTryOut[m]2> Well apk only says replacing and mentions the same version number twice
2020-11-12 15:51:47 <ikke> but that was more then a week ago
2020-11-12 15:51:52 <minimal> ikke: I mean the new partx subpackage was built/pushed out about 1 hour ago
2020-11-12 15:52:00 <ikke> hmm
2020-11-12 15:52:02 <ikke> interesting
2020-11-12 15:52:30 <minimal> I see it in my mirror repo for aarch86 for example.........x86_86 should be just about to appear any minute now
2020-11-12 15:52:49 <ikke> I get bad signatures in a x86_64 docker image
2020-11-12 15:54:01 <ikke> So yeah, seems like it was rebuilt somehow without pkgrel bump (no clue how)
2020-11-12 15:54:05 <ikke> and cdn still has the old package
2020-11-12 15:54:32 <ikke> I think best is to bump pkgrel for the partx change
2020-11-12 15:54:43 <PureTryOut[m]2> Yup
2020-11-12 15:54:53 <ikke> will do
2020-11-12 15:55:40 <maxice8> pushed a rebuild
2020-11-12 15:55:58 <ikke> maxice8: ah
2020-11-12 15:56:20 <minimal> ikke: you're right, !14558 didn't increment the pkgrel
2020-11-12 15:56:54 <maxice8> ikke: how do you handle multiline strings in go ?
2020-11-12 15:56:56 <ikke> minimal: normally that should not cause an issue though, it would just mean this change would not be effective until the next rebuild (pkgver / pkgrelbump)
2020-11-12 15:57:13 <minimal> ikke: yeah I know. BTW it wasn't my MR ;-)
2020-11-12 15:57:16 <ikke> maxice8: verbatim strings (``).
2020-11-12 15:57:32 <ikke> maxice8: I also use a heredoc package
2020-11-12 15:57:42 <maxice8> do following lines need to be at the start of the document ?
2020-11-12 15:57:54 <ikke> Not with that heredoc module :)
2020-11-12 15:58:09 <maxice8> heh
2020-11-12 15:58:10 <maxice8> ty
2020-11-12 15:58:37 <maxice8> Ikke: https://gitlab.alpinelinux.org/Cogitri/aports-qa-bot/-/merge_requests/5/diffs handling it with lots of +=
2020-11-12 15:59:17 <ikke> maxice8: https://gitlab.alpinelinux.org/kdaudt/atools-go/-/blob/variable-linters/pkg/atools/variables_test.go#L17
2020-11-12 16:08:28 <minimal> ikke: strange but despite the lack of pkgrel bump (-r1 was committed before the partx split) I've just installed partx-2.36-r1 on x86_86 fine
2020-11-12 16:08:54 <ikke> minimal: what mirror do you use?
2020-11-12 16:09:06 <ikke> This is typically only an issue on dl-cdn, which caches the pacakge
2020-11-12 16:09:30 <ikke> I switched to dl-2, and there it worked fine as well
2020-11-12 16:16:32 <minimal> maxice8: did you bump the pkgrel?
2020-11-12 16:17:20 <ikke> yes
2020-11-12 16:17:26 <ikke> http://dup.pw/alpine/aports/d3c42233be1f
2020-11-12 16:21:24 <ikke> ter
2020-11-12 16:22:53 <minimal> ok, for some reason that didn't appear when I searched all MRs in Gitlab for "util-linux"
2020-11-12 16:23:34 <maxice8> because I directly pushed
2020-11-12 18:17:45 <andypost[m]> Any idea why curl fails on builders? Locally it works for me https://build.alpinelinux.org/buildlogs/build-3-13-x86/main/tree/tree-1.8.0-r0.log
2020-11-12 18:18:35 <ikke> andypost[m]: noticed the same locally, haven't checked on the builders yet
2020-11-12 18:20:43 <andypost[m]> Looks like different dns servers
2020-11-12 18:29:24 <ikke> andypost[m]: now I cannot download it from anywhere
2020-11-12 18:33:01 <andypost[m]> I can but only from ovh servers
2020-11-12 18:33:31 <ikke> what does mama.indstate.edu resolve to?
2020-11-12 18:33:49 <andypost[m]> 139.102.70.201
2020-11-12 18:33:58 <ikke> ok, so that's not the issue then
2020-11-12 18:35:15 <andypost[m]> from scaleway-nl it also downloadable
2020-11-12 18:35:44 <ikke> routing isuse?
2020-11-12 18:35:58 <andypost[m]> looks like
2020-11-12 18:40:03 <andypost[m]> but it works from CI see !14574
2020-11-12 18:40:41 <ikke> strangeness
2020-11-12 18:42:51 <ikke> if I do an mtr from the CI host, it stops at 18 hops, from a server where it does not happen, it continues and times out after the 18th hop
2020-11-12 18:43:09 <ikke> (the 18th hop has the same IP)
2020-11-12 19:15:59 <sosodank> hey there everyone! i've been maintaining a few packages in edge:testing for some months now, and was wondering what the process is by which i might get them moved into community. i'm happy to commit to maintainership (i'm the upstream author)
2020-11-12 19:16:20 <ikke> sosodank: Hey, welcome
2020-11-12 19:16:22 <sosodank> i've seen a few pull requests to move stuff into community, but am unsure whether that would be welcome from someone not a part of the core alpine team
2020-11-12 19:16:26 <sosodank> hello ikke :)
2020-11-12 19:16:31 <ikke> sosodank: It's as easy as making an MR to move them
2020-11-12 19:16:41 <sosodank> my spirit soars; thanks for the info
2020-11-12 19:17:34 <ikke> no problem
2020-11-12 19:17:51 <sosodank> thanks also to leo and mps, who've been great about merging my PRs. very welcoming community here at alpine
2020-11-12 19:18:15 <ikke> Nice to hear
2020-11-12 19:21:46 <mps> hm, looks like s/he left, and I have no idea whom I helped :)
2020-11-12 19:22:05 <ikke> mps: heh
2020-11-12 19:22:19 <ikke> Seems like your smart join/part filter is working :)
2020-11-12 19:22:30 <mps> heh, looks like
2020-11-12 19:23:09 <mps> ikke: btw, link about go static build you posted yesterday, I read it just now
2020-11-12 19:23:30 <ikke> I think the person who wrote it has been active here
2020-11-12 19:23:40 <mps> and there is described what I did when I wanted to build fully static go programs :)
2020-11-12 19:23:59 <ikke> mps: It's something I want to use for $work
2020-11-12 19:24:01 <mps> I did that on debian
2020-11-12 19:24:12 <ikke> building some projects in alpine containers, but usable on other distros
2020-11-12 19:24:43 <ikke> So I don't have to build it for each distro
2020-11-12 19:25:16 <mps> also I'm thinking to refresh my go knowledge, which is not high, but enough for some tasks I need
2020-11-12 19:25:34 <ikke> I've just started with tour.golang.org, and continued from there
2020-11-12 19:26:29 <ikke> https://quii.gitbook.io/learn-go-with-tests/ is nice as well
2020-11-12 19:27:54 <mps> I don't like it is backed by google and not sure when (and will) it become 'walled garden'
2020-11-12 19:28:43 <mps> my hopes were on crystal as 'service' language, but development is slow
2020-11-12 19:29:07 <mps> didn't yet decided what 'road to take'
2020-11-12 19:31:30 <ikke> One deciding factor for me is that a lot of popular devops tools are using go (and tools that are used at $work)
2020-11-12 19:32:00 <ikke> And it's quite easy to get productive in
2020-11-12 19:35:45 <mps> well, yes 'vim and make' are devops tools :)
2020-11-12 19:36:36 <ikke> Talking about things like terraform
2020-11-12 19:37:54 <mps> I 'hear' about that but have no idea what is it, and don't send me url please ;)
2020-11-12 19:38:19 <ikke> State management for infrastrcture / apps
2020-11-12 19:38:50 <mps> that is why so good in infra management and setup
2020-11-12 19:38:58 <mps> why you are*
2020-11-12 19:39:18 <ikke> To be honest, I haven't used terraform yet :P
2020-11-12 19:39:30 <ikke> I do use Chef a lot at the moment
2020-11-12 19:49:21 <ikke> mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14577
2020-11-12 19:54:40 <mps> ah, nick black, now I know :)
2020-11-12 19:54:56 <mps> ikke: thanks
2020-11-12 21:08:31 <c705> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12061
2020-11-12 21:08:40 <c705> is this being looked into? firefox is still broken on edge
2020-11-12 21:09:13 <ikke> c705: Well, yes, but no concrese solution yet
2020-11-12 21:09:42 <ikke> concrete*
2020-11-12 21:10:01 <ikke> c705: note that I tried ff on edge and had no issues
2020-11-12 21:10:32 <c705> with sandboxing?
2020-11-12 21:10:35 <ikke> yes
2020-11-12 21:10:38 <ikke> vanilla
2020-11-12 21:10:38 <c705> with a blank profile rather
2020-11-12 21:10:42 <ikke> yes
2020-11-12 21:10:47 <c705> when?
2020-11-12 21:11:02 <ikke> last week
2020-11-12 21:11:21 <c705> I checked 5.7 last night, still broke. I'm using a blank profile as well
2020-11-12 21:11:29 <ikke> 5.7?
2020-11-12 21:11:33 <ikke> Linux 5.7?
2020-11-12 21:11:34 <c705> kernel 5.7
2020-11-12 21:11:36 <ikke> j
2020-11-12 21:11:36 <c705> yes
2020-11-12 22:31:09 <maxice8> apkbuild-fixer should be more reliable now
2020-11-12 22:32:20 <maxice8> turns out I forgot to tell `sort` that the separator was `:` and not whitespace
2020-11-12 22:33:04 <maxice8> Can ZSH users test !14571 ?
2020-11-12 22:39:27 <ikke> can test later
2020-11-12 22:43:12 <maxice8> ty
2020-11-12 23:29:16 <qrvpzvb> Hello everybody
2020-11-12 23:29:55 <maxice8> hi
2020-11-12 23:30:14 <qrvpzvb> So, I just noticed that the chrony package has a logrotate.  In fact, I was the last person to mess with.  It's totally useless though, chrony writes to syslog
2020-11-12 23:31:47 <qrvpzvb> So, I didn't just noticed the lograte.  I did just notice the lack of log files :P
2020-11-12 23:49:03 <qrvpzvb> So I guess my question is, should I send an MR to remove it?
2020-11-13 06:31:23 <Ariadne> ncopa: working on bump to gcc 10.3 prerelease
2020-11-13 06:40:09 <ncopa> morning!
2020-11-13 06:40:12 <ncopa> awesome! thanks!
2020-11-13 06:40:34 <ncopa> it would be soooooooo nice if it solves the mips64 problem and libreoffce build
2020-11-13 07:04:15 <Ariadne> latest loss with busybox:
2020-11-13 07:04:17 <Ariadne> treefort:~/alpine-gcc-patches$ xz gcc-10.2.1.tar
2020-11-13 07:04:17 <Ariadne> Usage: xz -d [-cfk] [FILE]...
2020-11-13 07:04:17 <Ariadne> BusyBox v1.32.0 () multi-call binary.
2020-11-13 07:04:27 <Ariadne> can we stop enabling crap that is useless?
2020-11-13 07:04:29 <Ariadne> thanks
2020-11-13 07:07:50 <ncopa> apk add xz?
2020-11-13 07:08:16 <Ariadne> yes, i know
2020-11-13 07:08:40 <Ariadne> but giving people an xz that only decompresses as xz and not `unxz` is not great
2020-11-13 07:09:36 <Ariadne> we should ship busybox *unxz*, but this busybox xz applet is beyond useless
2020-11-13 07:09:40 <Ariadne> and will just make people angry
2020-11-13 07:09:50 <Ariadne> i will look into defanging that
2020-11-13 07:13:05 <ncopa> introduced by a5806da1f0f1304a4330e42291b9e7d05741a4a8
2020-11-13 07:13:46 <Ariadne> presumably maxice8 did not know that the xz applet only decompresses
2020-11-13 07:13:58 <ncopa> maxice8: i think we should revert a5806da1f0f1304a4330e42291b9e7d05741a4a8, because busybox does not provide full xz, only unxz
2020-11-13 07:14:07 <ncopa> yeah, thats what i think too
2020-11-13 07:14:31 <ncopa> Ariadne: do yo uwant me to take care of it?
2020-11-13 07:14:39 <ncopa> so you can work on whatever you were working on
2020-11-13 07:14:42 <Ariadne> go for it, i'm still working on gcc 10.2.1 rebase
2020-11-13 07:15:13 <Ariadne> but i am 100% sure that if we ship that xz, people are going to be mad about it
2020-11-13 07:15:15 <Ariadne> :D
2020-11-13 07:16:02 <mps> alpine development becoming insane, imo
2020-11-13 07:16:10 <mps> and good morning
2020-11-13 07:16:23 <ikke> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#Switching_from_busybox_ifupdown_to_ifupdown-ng
2020-11-13 07:18:26 <ncopa> we may need follow up a0b2d475a95035b32305ef94083ea2d99be71b1a and similar too
2020-11-13 07:18:50 <ncopa> c9e8d8eb4953da454520ad29a41041e732bbecf1
2020-11-13 07:19:16 <ncopa> dcf1295dd9b83777c221e725bf095f49a00b27be
2020-11-13 07:20:14 <ncopa> c08b511b05262a5f38b413e476986e5b919cf279 ef181971ae543a794667ebbd04f882e10b5c6430 c336381eb35c0bcd385562f8ca44f79c76dddcd8
2020-11-13 07:20:24 <Ariadne> mps: there are sometimes a need for mad science
2020-11-13 07:21:09 <ncopa> mps: morning! how do you mean insane?
2020-11-13 07:21:23 <Ariadne> probably shipping gcc snapshot and musl snapshot
2020-11-13 07:21:46 <Ariadne> i mean, it does sound scary :)
2020-11-13 07:21:50 <ncopa> ikke: nice! gcc 10, should probably be mentioned too
2020-11-13 07:22:11 <mps> ncopa: too much freedom without rules/policy/reasoning leads to chaos
2020-11-13 07:22:32 <ncopa> ugh... yeah...
2020-11-13 07:22:52 <Ariadne> well, i do not think enabling this xz applet was malicious
2020-11-13 07:23:13 <Ariadne> however, i thnk it would be nice to be careful when enabling busybox stuff
2020-11-13 07:23:23 <Ariadne> because some things may not be as you think them to be
2020-11-13 07:23:33 <ncopa> and probably some of the packages were only using the `xz -d` anyway
2020-11-13 07:23:42 <Ariadne> CONFIG_XZ sounds like "full xz applet" to most people, but clearly it is not
2020-11-13 07:23:44 <mps> Ariadne: I'm not talking about xz, and I'm on maxice8 side here
2020-11-13 07:24:07 <mps> I speaking 'in general'
2020-11-13 07:24:11 <Ariadne> you would be on the side of shipping an xz applet that does not generate xz files?
2020-11-13 07:24:44 <ncopa> i think having xz that only supports `xz -d` makes no sense. better to patch the packages to use unxz
2020-11-13 07:24:48 <Ariadne> i mean, the only reason i find any problem with the xz applet is because it does not actually compress :P
2020-11-13 07:25:41 <Ariadne> and in fairness, i am doing the gcc 10.2.1 prerelease because i was asked to do so :P
2020-11-13 07:26:22 <Ariadne> rolling my own snapshot made more since than having 800 patches in aports
2020-11-13 07:30:05 <Ariadne> it is also how we've done it in the past when we've used gcc snapshots
2020-11-13 07:31:08 <mps> Ariadne: no, I'm on maxice8 side because he asked and talked about that change, iirc
2020-11-13 07:32:35 <mps> and he didn't that 'blindly' without asking
2020-11-13 07:32:46 <Ariadne> i did not imply he did :)
2020-11-13 07:33:07 <Ariadne> i'm just saying that perhaps it was not known that busybox xz only supported decompess
2020-11-13 07:33:10 <Ariadne> decompress*
2020-11-13 07:33:48 <mps> iirc, that was known
2020-11-13 07:34:12 <mps> but he can speak
2020-11-13 07:34:39 <Ariadne> dunno either way, just know if we ship busybox xz, people will try to use it to compress files and be surprised
2020-11-13 07:34:47 <Ariadne> and will complain about it
2020-11-13 07:35:09 <Ariadne> i certainly was surprised by it
2020-11-13 07:35:13 <mps> I don't remember where to look for discussion history but have impression we discused this
2020-11-13 07:35:51 <Ariadne> this damn dell laptop is starting to die on me
2020-11-13 07:36:22 <mps> people using alpine should know that we use busybox as base utility
2020-11-13 07:36:44 <Ariadne> yes, but we generally remove applets that are surprising
2020-11-13 07:36:46 <ncopa> looking at the git log, it may be due to gettext, who added xz as dep at some point
2020-11-13 07:36:59 <ncopa> we do provide unxz
2020-11-13 07:37:44 <Ariadne> unxz is not surprising :)
2020-11-13 07:37:44 <ncopa> im pretty sure that i enabled unxz but did not enable xz on purpose
2020-11-13 07:39:57 <ncopa> here: d0b4f9226bbaf7637310374382c21dea88d25a3a
2020-11-13 07:40:38 <ncopa> sorry no
2020-11-13 07:40:46 <ncopa> it was here: 89014f386bd15d3623811e3bb5e1ce8e5cf2b66d
2020-11-13 07:40:47 <ikke> unxz was already enabled, just got moved
2020-11-13 07:40:50 <Ariadne> perhaps CONFIG_XZ has a compress mode
2020-11-13 07:40:51 <ikke> right
2020-11-13 07:40:55 <Ariadne> that we can enable?
2020-11-13 07:41:03 <ncopa> i doubt
2020-11-13 07:42:42 <ncopa> nope. its just decompress
2020-11-13 07:43:12 <Ariadne> bummer
2020-11-13 07:43:23 <mps> idea that alpine could be small (really small) for containers and be as 'big' distros at the same time is 'strange'
2020-11-13 07:43:42 <Ariadne> mps: we already ship unxz
2020-11-13 07:44:20 <Ariadne> i'm not saying "lets replace busybox with coreutils"
2020-11-13 07:44:43 <Ariadne> i'm saying "lets not bloat our busybox with applets that end users will not find useful"
2020-11-13 07:44:43 <mps> eh :)
2020-11-13 07:45:23 <Ariadne> an xz which only decompresses is not an applet end users will find useful
2020-11-13 07:45:33 <ncopa> we should ship busybox unxz, yes
2020-11-13 07:45:50 <ncopa> mps: do you think we should ship 'xz' applet too?
2020-11-13 07:46:00 <mps> bloat is the trend in modern software and it is not easy 'to resist' but we should try imo
2020-11-13 07:46:12 <Ariadne> we are talking about resisting bloat
2020-11-13 07:46:20 <Ariadne> by not enabling applets which are bloat
2020-11-13 07:46:25 <mps> ncopa: I don't have strong opinion on that
2020-11-13 07:46:40 <Ariadne> an xz which has the exact same functionalitiy as unxz is bloat
2020-11-13 07:46:46 <Ariadne> the worst kind of bloat, really
2020-11-13 07:47:01 <ncopa> yeah, shiping an almost useless xz is just bloating things
2020-11-13 07:47:05 <Ariadne> it is bloat that will make somebody complain about "alpine is broken"
2020-11-13 07:48:01 <mps> I'm trying to 'explain' maxice8 intent, which was positive imo
2020-11-13 07:48:12 <Ariadne> yes, we understand the intent
2020-11-13 07:48:40 <Ariadne> however the correct way to solve that usecase is to fix the packages to use unxz instead of xz -d
2020-11-13 07:49:05 <mps> sure, I agree with both you
2020-11-13 07:49:08 <ncopa> i wonder what 43bb19fd10a07519cb1f6db2484149aa049cf6b9 was about though
2020-11-13 07:49:45 <ikke> That's my pet-peeve, commit messages without context
2020-11-13 07:50:00 <ncopa> yup
2020-11-13 07:50:07 <Ariadne> unpack error of what
2020-11-13 07:50:09 <Ariadne> :D
2020-11-13 07:50:23 <ncopa> maybe gettext unpack failed at some point, maybe it failed on ppc64le
2020-11-13 07:51:05 <Ariadne> but it was already a makedepend
2020-11-13 07:51:06 <Ariadne> this changed it to runtime depend
2020-11-13 07:52:57 <Ariadne> ncopa: what are your thoughts btw about reproducible builds
2020-11-13 07:53:25 <mps> ok, bad things happens, we should continue fixing things setting 'calm mode'
2020-11-13 07:53:30 <Ariadne> i know mort___8859 was doing some work on that stuff
2020-11-13 07:54:24 <mps> (and change 'patches welcome' to 'fixes welcome' :) )
2020-11-13 07:54:27 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10014
2020-11-13 07:55:56 <mps> btw, looks like iproute will have bpf soon, so we should enable it in linux-edge also, it is inevitable
2020-11-13 07:56:46 <Ariadne> gcc version 10.2.1 20201113 (Alpine 10.2.1_pre0)
2020-11-13 07:58:26 <ncopa> i think reproducible builds are a good thing that we should work for, but hopefully without slowing us down too much
2020-11-13 07:58:37 <ncopa> so its not the highest prio
2020-11-13 08:05:14 <ikke> Ariadne: No feedback yet about rust on s390x, I guess?
2020-11-13 08:05:22 <Ariadne> not yet
2020-11-13 08:05:44 <Ariadne> when i have some spare funds i might hire a rustc dev to figure it out
2020-11-13 08:06:12 <Ariadne> having rust everywhere is a high priority item for us at work
2020-11-13 08:44:26 <Ariadne> ncopa: it would be nice to retire quagga in favor of FRR in alpine 3.14
2020-11-13 08:45:07 <Ariadne> algitbot: retry master
2020-11-13 09:22:41 <ncopa> do we have nhrp stuff working with frr?
2020-11-13 09:34:34 <Ariadne> FRR has nhrp support, but i need to validate it
2020-11-13 09:34:40 <Ariadne> i can work on that in next few weeks
2020-11-13 10:01:03 <ncopa> um..
2020-11-13 10:01:32 <ncopa> why do you want replace quagga with FRR?
2020-11-13 10:01:54 <ncopa> if its a 3.14 goal, then I think we should wait til after 3.13 is out
2020-11-13 10:02:00 <Ariadne> yeah
2020-11-13 10:02:07 <Ariadne> i didn't mean replace it now
2020-11-13 10:02:13 <ncopa> maybe fabled has opinion about it
2020-11-13 10:02:18 <Ariadne> the reason why is, FRR is much better maintained than quagga
2020-11-13 10:02:31 <ncopa> i think fabled has contributed to quagga in the past
2020-11-13 10:02:59 <Ariadne> indeed
2020-11-13 10:03:15 <Ariadne> it is something to be discussed, not just implemented at any rate
2020-11-13 10:03:32 <Ariadne> the thing is, quagga website has been down for almost 3 months with a certificate error
2020-11-13 10:03:36 <ncopa> reminds me, i wonder if it would be possible to get nhrp (or something corresponding )working with wireguard
2020-11-13 10:03:37 <Ariadne> their git is down, etc
2020-11-13 10:03:41 <ncopa> ugh..
2020-11-13 10:03:44 <ncopa> not a good sign
2020-11-13 10:04:03 <Ariadne> so when i say "better maintained" what i really mean is "quagga is probably dead"
2020-11-13 10:04:09 <Ariadne> almost everyone went with the FRR fork
2020-11-13 10:04:12 <ncopa> :)
2020-11-13 10:04:31 <ncopa> lets bring that up again after 3.13 is out
2020-11-13 10:04:42 <ncopa> thanks for the gcc work
2020-11-13 10:05:27 <ncopa> Now im supercurious if gcc 10 works on mips64...
2020-11-13 10:05:45 <ncopa> i can test build it unless you are already doing it
2020-11-13 10:06:24 <Ariadne> the only commts to quagga in 2020 were from fabled
2020-11-13 10:06:27 <Ariadne> :D
2020-11-13 10:06:30 <Ariadne> and only 2 of them
2020-11-13 10:06:30 <ncopa> ha!
2020-11-13 10:08:00 <Ariadne> if you want to give gcc 10 a test on the builder, go for it
2020-11-13 10:08:06 <Ariadne> i have a bit of a headache atm
2020-11-13 10:08:09 <ncopa> im already on it :)
2020-11-13 10:08:24 <ncopa> oh.. :-/ i hope you get better
2020-11-13 10:09:06 <ncopa> might be better that you get some rest for now
2020-11-13 10:09:52 <mps> I tested build crystal with upgraded gcc
2020-11-13 10:53:05 <Ariadne> looks like ncopa's gcc build has not bombed out yet
2020-11-13 10:53:11 <Ariadne> so maybe it is fixed
2020-11-13 10:53:19 <Ariadne> of course my saying that has probably doomed it
2020-11-13 10:54:04 <Ariadne> hahaha
2020-11-13 10:54:08 <Ariadne> it bombed right as i said that
2020-11-13 10:54:31 <ncopa> In file included from /home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cp/method.c:3199:
2020-11-13 10:54:31 <ncopa>       |  ^
2020-11-13 10:54:31 <ncopa> ./gt-cp-method.h:36:2: internal compiler error: Segmentation fault
2020-11-13 10:54:31 <ncopa>    36 | };
2020-11-13 10:55:08 <Ariadne> yep
2020-11-13 10:55:32 <Ariadne> ii had an idea
2020-11-13 10:55:52 <Ariadne> deu4-dev1 [~]# swapon /swapfile
2020-11-13 10:55:53 <ncopa> is that running in threads?
2020-11-13 10:56:12 <Ariadne> i don't think so
2020-11-13 10:56:26 <Ariadne> as far as i know gcc does not use threads internally
2020-11-13 10:57:13 <ncopa> maybe libstdc++ does?
2020-11-13 10:57:24 <ncopa> let me see if i can get a core file
2020-11-13 10:59:13 <Ariadne> it is possible
2020-11-13 10:59:46 <Ariadne> one possible way of testing would be to -Wl,-stack-size=whatever
2020-11-13 10:59:53 <ncopa> im thinking that it.... exactly
2020-11-13 11:09:18 <ncopa> so the news is out. the k0s project i have been working on the last few months is open source now
2020-11-13 11:10:09 <ncopa> i think I'll try get k0s ready for 3.13 release, which should give us super simple kubernetes on alpine
2020-11-13 11:10:55 <Ariadne> hooray, we can have the kubler-ross model on alpine
2020-11-13 11:11:03 <Ariadne> so we can grieve while we grieve
2020-11-13 11:11:10 <ncopa> :D
2020-11-13 11:11:29 <ncopa> my impression of kubernetes is: flaky
2020-11-13 11:12:11 <ncopa> a co-worker explained it to me: the idea is eventually consistent system
2020-11-13 11:12:28 <ncopa> emphasis on "eventually"
2020-11-13 11:12:37 <Ariadne> in other words, never
2020-11-13 11:12:41 <ikke> :D
2020-11-13 11:13:15 <ncopa> like i often say: nothing is impossible, the impossible jsut takes a bit longer time...
2020-11-13 11:13:33 <ikke> I just quoted that the other day :D
2020-11-13 11:13:48 <Ariadne> all jokes aside, k0s looks like a great bookend to alpine 3.13
2020-11-13 11:14:03 <ikke> So what differentiates k0s?
2020-11-13 11:14:31 <Ariadne> looks to be basically kubernetes sans bloat
2020-11-13 11:14:37 <Ariadne> i don't know
2020-11-13 11:14:45 <Ariadne> i have a guy for this who explains all this crap to me
2020-11-13 11:14:49 <ncopa> eh... depends on how you define bloat...
2020-11-13 11:15:01 <Ariadne> ok, kubernetes itself is bloat
2020-11-13 11:15:03 <Ariadne> that is true ;)
2020-11-13 11:15:07 <ncopa> yup
2020-11-13 11:15:10 <ikke> https://www.mirantis.com/blog/congratulations-to-the-k0s-team-on-their-new-kubernetes-distribution/ ?
2020-11-13 11:15:26 <ncopa> https://medium.com/@adamparco/announcing-k0s-the-smallest-simplest-kubernetes-distribution-3626c86575d5
2020-11-13 11:15:29 <Ariadne> does look quite ncie
2020-11-13 11:15:31 <ncopa> yup
2020-11-13 11:15:54 <ncopa> it should be small enough to run on rpis
2020-11-13 11:15:55 <Ariadne> and given that its mirantis, its probably an alpine-first kubernetes distribution
2020-11-13 11:16:13 <ncopa> i have kinda tried to push for alpine-first yes :)
2020-11-13 11:16:39 <ncopa> k0s similar to k3s
2020-11-13 11:16:58 <ncopa> but with the difference that it uses upstream kubernetes
2020-11-13 11:17:02 <ncopa> rather than a fork
2020-11-13 11:17:24 <ikke> So it's a framework around kubernetes?
2020-11-13 11:17:28 <ncopa> the k0s binary itself is a selfextrackting archive, so you only need to deploy a single binary
2020-11-13 11:17:35 <ncopa> its a kubernetes distro
2020-11-13 11:17:38 <ikke> right
2020-11-13 11:17:55 <ncopa> its a tool that makes it easy to install, setup and run kuberenetes
2020-11-13 11:18:21 <ncopa> it is also a process supervisor that supervises the kubernetes processes
2020-11-13 11:18:37 <ikke> It it still using etcd?
2020-11-13 11:18:52 <ncopa> it can use either etcd  or kine
2020-11-13 11:19:00 <ncopa> it uses etcd by default
2020-11-13 11:19:02 <ikke> ok
2020-11-13 11:19:30 <ncopa> kine is etcd api with sqlite (or other sql server) backend
2020-11-13 11:19:41 <Ariadne> looks like this is mirantis's answer to microk8s
2020-11-13 11:19:44 <Ariadne> basically
2020-11-13 11:20:16 <ncopa> but what really differentiates it is that you can run controlplane completely separated
2020-11-13 11:20:32 <ncopa> you can run the control plane without any workers at all
2020-11-13 11:21:03 <ikke> https://k0sproject.io/
2020-11-13 11:21:08 <ncopa> yup
2020-11-13 11:21:25 <ikke> Certaintly something worth looking into
2020-11-13 11:21:41 <ncopa> if you are interested in running kuberentes, then yes
2020-11-13 11:21:45 <ikke> ncopa: Do you think it's perhaps something we might want to use internally?
2020-11-13 11:22:07 <ncopa> if we want run kubernetes, then yes
2020-11-13 11:22:13 <ncopa> im not sure we want :)
2020-11-13 11:22:21 <ikke> Me neither
2020-11-13 11:22:24 <ncopa> but its up to infra team
2020-11-13 11:22:38 <ikke> But I don't know kubernetes enough to make an informed decission
2020-11-13 11:23:08 <ncopa> we can have a call at some point, and I can explain what it does
2020-11-13 11:23:42 <Ariadne> like i said, looks like mirantis' answer to microk8s
2020-11-13 11:24:12 <ncopa> except that it can run on big iron in big clusters as well
2020-11-13 11:24:23 <Ariadne> yes
2020-11-13 11:25:20 <ncopa> kubernetes works similar to how i have envisioned the next gen alpine build infra
2020-11-13 11:25:50 <ncopa> and if it was not for the golang dep, i'd probably use it for our building infra
2020-11-13 11:25:57 <Ariadne> on the NSL side of things (Network Services Linux is $dayjob adapting Alpine to be a NOS), we've been thinking about container runtime for "smart edge"
2020-11-13 11:26:57 <ncopa> kubelet implemented in C/C++/Lua/python/(anythin non-go) and some container runtime, and i'd use it for our building infra
2020-11-13 11:27:50 <Ariadne> i was thinking about doing a container runtime with C and seccomp
2020-11-13 11:28:15 <Ariadne> seccomp can be used to intercept privileged ops and emulate them
2020-11-13 11:28:17 <ncopa> it'd be a killer if it can run OCI images
2020-11-13 11:28:27 <Ariadne> like how kvm does "trap + emulate" for privileged cpu instructions
2020-11-13 11:28:39 <ncopa> i mean, even if it run unshare(2), real containers
2020-11-13 11:29:07 <Ariadne> well yes, but you still need seccomp to support the privileged ops
2020-11-13 11:29:45 <Ariadne> probably will start working on that early next year
2020-11-13 11:29:57 <Ariadne> i'm neck deep in switchdev and SAI integration right now
2020-11-13 11:31:06 <ncopa> something that could connect to a kubernetes cluster and accept workloads, implemented in C, would be :exploading_head:
2020-11-13 11:31:55 <Ariadne> probably doable
2020-11-13 11:32:18 <ncopa> kubelet, containerd, runc, or parts of it
2020-11-13 11:34:13 <detha> like so many things, doable, just needs someone to sponsor doing it
2020-11-13 11:34:59 <Ariadne> yeah, for us immediately we're quite busy over here but next year it should be possible to work into pipeline
2020-11-13 11:35:12 <ncopa> yup
2020-11-13 11:36:04 <Ariadne> the end game is basically "use P4 to program the data plane, run containers on control plane for services"
2020-11-13 11:37:16 <ncopa> ho do i check elf header that stack-size was applied?
2020-11-13 11:38:36 <Ariadne> uhhh
2020-11-13 11:39:12 <Ariadne> that is a great question
2020-11-13 11:41:52 <ikke> ncopa: one thing that would be nice to address is to make others depend less on me and clandmeter for everyday infra work, like deploying new versions of containers / compose config
2020-11-13 11:42:07 <ikke> There are different ways to achieve that though
2020-11-13 11:43:39 <Ariadne> there is chelf in testing
2020-11-13 11:43:52 <Ariadne> treefort:~$ chelf ./moo
2020-11-13 11:43:53 <Ariadne> ./moo: INTERP=/lib/ld-musl-x86_64.so.1 STACKSIZE=8000000
2020-11-13 11:45:05 <ncopa> g++ -std=gnu++98 -no-pie   -g   -DIN_GCC     -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,--as-needed
2020-11-13 11:45:05 <ncopa> -Wl,-z,stack-size=1024000 -o xg++ \
2020-11-13 11:46:24 <ncopa> looks like it was added, based on the output
2020-11-13 11:46:43 <Ariadne> cc1plus i think is the one you need to know about
2020-11-13 11:46:57 <Ariadne>   GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
2020-11-13 11:46:58 <Ariadne>                  0x0000000000000000 0x00000000007a1200  RW     0x10
2020-11-13 11:47:28 <Ariadne> >>> '%d' % 0x00000000007a1200
2020-11-13 11:47:28 <Ariadne> '8000000'
2020-11-13 11:47:38 <Ariadne> so that GNU_STACK value 0x7a1200 before RW
2020-11-13 11:47:41 <Ariadne> is the stack size
2020-11-13 11:47:46 <Ariadne> in readelf -a output
2020-11-13 11:48:10 <ncopa> prev-gcc/xg++: INTERP=/lib/ld-musl-mips64-sf.so.1 STACKSIZE=1024000
2020-11-13 11:49:08 <Ariadne> what about cc1plus
2020-11-13 11:49:13 <ncopa> oh, right, cc1plus
2020-11-13 11:49:20 <ncopa> no i havent set that (yet)
2020-11-13 11:49:40 <ncopa> im waiting for xg++ to fail...
2020-11-13 11:49:51 <Ariadne> xg++ is the driver
2020-11-13 11:50:00 <Ariadne> cc1plus is the actual compiler
2020-11-13 11:50:15 <Ariadne> there should be a prev-gcc/cc1plus
2020-11-13 11:50:38 <ncopa> yeah, i will re-link it in a sec
2020-11-13 11:52:50 <ncopa> ok... lets
2020-11-13 11:52:54 <ncopa> ugh. :-(
2020-11-13 11:54:14 <ncopa> still crashes
2020-11-13 11:54:43 <Ariadne> my examination showed that a leaf pointer was null that shouldn't have been null
2020-11-13 11:54:52 <Ariadne> in the IPA-SSA optimizer
2020-11-13 11:55:37 <Ariadne> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96734
2020-11-13 11:55:41 <Ariadne> IPA-SRA
2020-11-13 11:55:41 <Ariadne> sorry
2020-11-13 11:56:35 <Ariadne> "I suspect the issue is because `caller` is null, which means to->check_calls_comdat_local_p() does a null dereference when trying to fetch the vtable.  But I could be wrong entirely.  :)"
2020-11-13 12:00:49 <Ariadne> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93347
2020-11-13 12:04:36 <ncopa> ugh... busybox' ash input buffer is too small
2020-11-13 12:06:01 <Ariadne> gcc 11
2020-11-13 12:06:12 <Ariadne> no longer has redirect_callee
2020-11-13 12:06:34 <Ariadne> https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/cgraph.c;h=72b3bc895f023bf451357659cfe96c966945bdf9
2020-11-13 12:06:39 <Ariadne> perhaps this commit is wrong
2020-11-13 12:07:16 <ncopa> you know what
2020-11-13 12:07:24 <ncopa> i made it build
2020-11-13 12:07:43 <ncopa> removing -02 made it build
2020-11-13 12:08:39 <ikke> So optimization bug?
2020-11-13 12:08:46 <Ariadne> ??
2020-11-13 12:09:06 <ncopa> yup, i can confirm, building without -O2 makes it build
2020-11-13 12:09:20 <Ariadne> are you building with xg++ or system g++ tho
2020-11-13 12:09:54 <ncopa> im using /home/ncopa/aports/main/gcc/src/build/./prev-gcc/xg++
2020-11-13 12:10:00 <Ariadne> hmm
2020-11-13 12:10:07 <Ariadne> try with -O1
2020-11-13 12:10:11 <ncopa> and i just verified, toggling -02 on and off makes it pass
2020-11-13 12:10:21 <Ariadne> i think we should be careful though
2020-11-13 12:10:35 <ncopa> im gonna do it again, there was a -Os in there that also got removed
2020-11-13 12:11:45 <ncopa> removing -02 but keeping -Os makes it fail, as expected
2020-11-13 12:11:52 <ncopa> they are very similar
2020-11-13 12:12:23 <ncopa> removing them both makes it build
2020-11-13 12:13:01 <ncopa> -O1 builds too
2020-11-13 12:14:00 <Ariadne> try
2020-11-13 12:14:12 <Ariadne> hmm
2020-11-13 12:14:16 <Ariadne> ths seems related to inlining
2020-11-13 12:14:19 <ncopa> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html im gonna try each option
2020-11-13 12:14:43 <Ariadne> its -fipa-sra i think
2020-11-13 12:16:50 <Ariadne> try -O2 -fno-ipa-sra
2020-11-13 12:17:48 <Ariadne> Perform interprocedural scalar replacement of aggregates, removal of unused parameters and replacement of parameters passed by reference by parameters passed by value.
2020-11-13 12:17:49 <Ariadne> yeah
2020-11-13 12:17:54 <Ariadne> this is related to inlining
2020-11-13 12:18:05 <Ariadne> i bet there's a bug in the inliner
2020-11-13 12:18:24 <Ariadne> and the code compiles to just the right inlined size to trigger it on mips
2020-11-13 12:18:50 <Ariadne> theory: inline fails, but inline_failed is false
2020-11-13 12:19:05 <Ariadne> or rather
2020-11-13 12:19:12 <Ariadne> inline succeeds
2020-11-13 12:19:18 <Ariadne> but inline_failed is true
2020-11-13 12:20:00 <ncopa> bingo
2020-11-13 12:20:15 <ncopa> -fno-ipa-sra works
2020-11-13 12:20:37 <ikke> \o/
2020-11-13 12:20:39 <Ariadne> lets put -fno-ipa-sra on CFLAGS for mips builder then
2020-11-13 12:21:20 <ncopa> so
2020-11-13 12:22:04 <ncopa> i tried to build with the half of the listed -O2 flags: -falign-functions  -falign-jumps -falign-labels  -falign-loops -fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps  -fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize  -fdevirtualize-speculatively -fexpensive-optimizations -ffinite-loops -fgcse  -fgcse-lm
2020-11-13 12:22:04 <ncopa> -fhoist-adjacent-loads -finline-functions -finline-small-functions -findirect-inlining -fipa-bit-cp  -fipa-cp  -fipa-icf -fipa-ra  -fipa-sra  -fipa-vrp -fisolate-erroneous-paths-dereference
2020-11-13 12:22:07 <ncopa> it passed
2020-11-13 12:22:22 <ncopa> then i tried the other half: -flra-remat -foptimize-sibling-calls -foptimize-strlen -fpartial-inlining -fpeephole2 -freorder-blocks-algorithm=stc -freorder-blocks-and-partition  -freorder-functions -frerun-cse-after-loop  -fschedule-insns  -fschedule-insns2 -fsched-interblock  -fsched-spec -fstore-merging -fstrict-aliasing -fthread-jumps
2020-11-13 12:22:22 <ncopa> -ftree-builtin-call-dce -ftree-pre -ftree-switch-conversion  -ftree-tail-merge -ftree-vrp
2020-11-13 12:22:35 <ncopa> and it passed to
2020-11-13 12:22:47 <Ariadne> try -fipa-sra on the second half
2020-11-13 12:24:03 <ncopa> seems like i lost connection :-/
2020-11-13 12:24:11 <ncopa> when it started to get excited
2020-11-13 12:24:20 <ncopa> s/excited/exciting/
2020-11-13 12:24:20 <alpine-meetbot> ncopa meant to say: when it started to get exciting
2020-11-13 12:24:54 <ikke> ncopa: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#GCC10
2020-11-13 12:25:11 <ncopa> this is gcc from latest gcc 10 branch?
2020-11-13 12:25:17 <Ariadne> yes
2020-11-13 12:25:20 <Ariadne> hang on
2020-11-13 12:25:56 <Ariadne> connection should be recovered
2020-11-13 12:26:13 <Ariadne> sometimes the networking just dies randomly
2020-11-13 12:26:26 <ncopa> yup its back
2020-11-13 12:26:41 <Ariadne> i plan to take over maintaining that builder personally once i get settled in NL
2020-11-13 12:26:42 <ncopa> ikke: very good. thanks!
2020-11-13 12:27:42 <ncopa> adding -fipa-sra to second half makes it fail
2020-11-13 12:27:49 <Ariadne> cool
2020-11-13 12:27:51 <Ariadne> that means
2020-11-13 12:27:58 <Ariadne> its actually something else fucking things up
2020-11-13 12:28:06 <Ariadne> and its in that second half :)
2020-11-13 12:28:35 <Ariadne> likely suspects: -foptimize-sibling-calls -foptimzie-strlen -fpartial-inlining
2020-11-13 12:29:35 <Ariadne> if i were to guess
2020-11-13 12:29:41 <Ariadne> -fpartial-inlining
2020-11-13 12:29:44 <Ariadne> is probably our suspect
2020-11-13 12:30:15 <ncopa> -01 -fipa-sra makes it pass
2020-11-13 12:30:22 <Ariadne> yeah
2020-11-13 12:30:24 <Ariadne> try
2020-11-13 12:30:30 <Ariadne> -O2 -fno-partial-inlining
2020-11-13 12:32:01 <ncopa> $second_half_without_fparitial-inlining -fipa-sra makes it pass
2020-11-13 12:33:21 <Ariadne> yep
2020-11-13 12:33:42 <Ariadne> try now, -O2 -fno-partial-inlining
2020-11-13 12:33:50 <ncopa> its running..
2020-11-13 12:33:51 <ncopa> ...and
2020-11-13 12:33:54 <ncopa> it passes
2020-11-13 12:34:00 <Ariadne> qualty
2020-11-13 12:34:20 <Ariadne> let me see about this -fpartial-inlining
2020-11-13 12:34:24 <Ariadne> i think it is new to gcc 10
2020-11-13 12:34:41 <Ariadne> if it is, then we should probably disable it distro-wide
2020-11-13 12:34:43 <ncopa> -01 -fpartial-linining passes
2020-11-13 12:34:52 <Ariadne> yeah it will pass on -O1
2020-11-13 12:34:58 <Ariadne> because all the IPA stuff is disabled
2020-11-13 12:35:12 <Ariadne> i think what is happenng is -fpartial-inlining generates a broken callgraph
2020-11-13 12:35:51 <ncopa> -O1 -fipa-sra -fpartial-inlining fails
2020-11-13 12:35:56 <ncopa> as expected
2020-11-13 12:36:00 <ncopa> this is great
2020-11-13 12:36:22 <ncopa> im gonna add comment on the gcc bug
2020-11-13 12:36:37 <ikke> nice dig work
2020-11-13 12:37:20 <Ariadne> -finline-functions is now enabled at -O2 and was retuned for better code size versus runtime performance trade-offs. Inliner heuristics was also significantly sped up to avoid negative impact to -flto -O2 compile times.
2020-11-13 12:37:21 <Ariadne> yes
2020-11-13 12:37:25 <Ariadne> new to gcc 10
2020-11-13 12:37:41 <Ariadne> for now, i think we should disable this in the gcc specs file
2020-11-13 12:37:54 <Ariadne> i suspect it is broken on all archs
2020-11-13 12:38:10 <Ariadne> just more broken on mips
2020-11-13 12:41:27 <ncopa> it passes with -fipa-sra -fpartial-inlining without -01
2020-11-13 12:42:32 <ncopa> so we need one of the -01 flags
2020-11-13 12:46:00 <Ariadne> -O1 turns on -finline-functions-called-once
2020-11-13 12:46:58 <Ariadne> which -fpartial-inlining won't do anything unless the inliner is turned on somehow
2020-11-13 12:47:00 <Ariadne> e.g. Inline parts of functions. This option has any effect only when inlining itself is turned on by the -finline-functions or -finline-small-functions options.
2020-11-13 12:47:10 <Ariadne> -finline-functions-called-once is not mentioned there explicitly, but...
2020-11-13 12:49:02 <Ariadne> try -O1 -fipa-sra -fpartial-inlining -finline-functions -fno-inline-functions-called-once
2020-11-13 12:55:10 <Ariadne> now i wonder if some of the weirdness i've been experiencing lately on alpine is due to gcc 10 generating broken code
2020-11-13 12:55:34 <ikke> What kind of weirdness?
2020-11-13 12:55:55 <Ariadne> KDE being unstable
2020-11-13 13:09:00 <ncopa> -O1 -fipa-sra -fpartial-inlining -finline-functions -fno-inline-functions-called-once fails
2020-11-13 13:09:29 <Ariadne> hmm
2020-11-13 13:09:43 <Ariadne> try remove -finline-functions
2020-11-13 13:09:59 <Ariadne> -O1 -fipa-sra -fpartial-inlining -fno-inline-functions-called-once
2020-11-13 13:11:18 <ncopa> fails
2020-11-13 13:11:29 <ncopa> i tried the half -O1
2020-11-13 13:11:43 <ncopa> with -fipa-sra -fpartial-inlining
2020-11-13 13:11:49 <ncopa> and it passes
2020-11-13 13:11:55 <ncopa> then i tried the other half
2020-11-13 13:11:59 <ncopa> and it passes too
2020-11-13 13:12:30 <ncopa> maybe the O1 list is old
2020-11-13 13:13:51 <ncopa> it complained about xg++: error: unrecognized command-line option '-fipa-modref'
2020-11-13 13:14:51 <ncopa> yup, the list is old
2020-11-13 13:15:12 <ncopa> adding all the listed -O1 options with -fipa-sra -fpartial-inlining makes it pass
2020-11-13 13:15:20 <Ariadne> let me see if i can get the actual list
2020-11-13 13:15:35 <ncopa> that would be great. thanks!
2020-11-13 13:17:28 <ncopa> gcc --help=optimizers
2020-11-13 13:18:32 <Ariadne> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/opts.c;h=731625289381c38162515745d217b3200504a0f9;hb=refs/heads/releases/gcc-10#l428
2020-11-13 13:18:37 <Ariadne> heres the -O1 options
2020-11-13 13:19:30 <Ariadne> try: -Og -fipa-sra -fpartial-inlining
2020-11-13 13:20:01 <Ariadne> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/opts.c;h=731625289381c38162515745d217b3200504a0f9;hb=refs/heads/releases/gcc-10#l428
2020-11-13 13:20:03 <Ariadne> er
2020-11-13 13:20:07 <Ariadne>  460 #if DELAY_SLOTS
2020-11-13 13:20:07 <Ariadne>  461     { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_fdelayed_branch, NULL, 1 },
2020-11-13 13:20:07 <Ariadne>  462 #endif
2020-11-13 13:20:09 <Ariadne> oh hello
2020-11-13 13:20:13 <Ariadne> mips uses a delay slot
2020-11-13 13:21:21 <ncopa> -Og -fipa-sra -fpartial-inlining  fails
2020-11-13 13:21:31 <Ariadne> ok
2020-11-13 13:21:37 <Ariadne> so its not -fdelayed-branch then
2020-11-13 13:22:07 <Ariadne> that leaves us with
2020-11-13 13:25:31 <Ariadne> -fcombine-stack-adjustments -fcombine-elim -fcprop-registers -fdefer-pop -fforward-propagate -fguess-branch-probability -fipa-profile -fipa-pure-const -fipa-reference -fipa-reference-addressable -fmerge-constants -fomit-frame-pointer -freorder-blocks -fshrink-wrap -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-fre -ftree-sink -ftree-slsr -ftree-ter
2020-11-13 13:26:26 <Ariadne> those are the optimizer flags -Og enables
2020-11-13 13:29:29 <ncopa> humpf
2020-11-13 13:29:43 <ncopa> i tried all the listed -Og options
2020-11-13 13:29:50 <ncopa> but it passes
2020-11-13 13:30:22 <ncopa> -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdefer-pop -fipa-profile -fipa-pure-const -fipa-reference -fipa-reference-addressable -fmerge-constants -fomit-frame-pointer -freorder-blocks -fshrink-wrap -fsplit-wide-types -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce
2020-11-13 13:30:22 <ncopa> -ftree-dominator-opts -ftree-fre -ftree-sink -ftree-slsr -ftree-ter -fipa-sra -fpartial-inlining
2020-11-13 13:34:52 <Ariadne> hmm
2020-11-13 13:38:58 <ncopa> -Og  -fipa-sra -fpartial-inlining -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-defer-pop -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-reference -fno-ipa-reference-addressable -fno-merge-constants -fno-omit-frame-pointer -fno-reorder-blocks -fno-shrink-wrap -fno-split-wide-types -fno-tree-builtin-call-dce -fno-tree-ccp
2020-11-13 13:38:58 <ncopa> -fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-dce -fno-tree-dominator-opts -fno-tree-fre -fno-tree-sink -fno-tree-slsr -fno-tree-ter
2020-11-13 13:39:03 <ncopa> fails to build
2020-11-13 13:43:42 <Ariadne> at this point i think we've gone as deep as we can go
2020-11-13 13:43:57 <Ariadne> -fno-partial-inlining in CFLAGS and call it a day i guess
2020-11-13 13:43:58 <Ariadne> :)
2020-11-13 13:50:13 <Ariadne> sending it
2020-11-13 13:51:39 <Hello71> Ariadne: this seems similar to gvisor
2020-11-13 13:53:02 <Ariadne> yes but not go
2020-11-13 13:53:03 <Ariadne> :)
2020-11-13 14:22:30 <ncopa> should we use -fno-partial-inlining for gcc on mips only?
2020-11-13 15:12:42 <maxice8> Where should I write a commitstyle ?
2020-11-13 15:13:31 <ikke> https://docs.alpinelinux.org/developer-handbook/0.1a/index.html? :P
2020-11-13 15:13:55 <maxice8> And where that is located ?
2020-11-13 15:14:41 <ikke> https://gitlab.alpinelinux.org/alpine/docs/developer-handbook
2020-11-13 15:15:05 <ikke> But I'm not sure how the deployment will work atm
2020-11-13 17:31:43 <maxice8> I see
2020-11-13 18:23:06 <maxice8> !14605
2020-11-13 18:39:52 <PureTryOut[m]2> Could anyone merge !14156 by any chance? I kinda need it for something I'm working on 😅
2020-11-13 18:45:51 <maxice8> Merging it
2020-11-13 18:45:59 <maxice8> done
2020-11-13 18:47:08 <PureTryOut[m]2> Awesome, thanks!
2020-11-13 20:15:15 <maxice81> !14605
2020-11-13 20:16:02 <ikke> maxice81: yes, was looking at it
2020-11-13 20:17:04 <maxice81> I rewrote it a few times
2020-11-13 20:33:41 <ikke> left some remarks
2020-11-13 20:37:37 <maxice81> Fixed and wrote some new things about reasoning
2020-11-13 21:15:53 <maxice8> Cogitri: Gnome TOUR keeps starting on every log-in
2020-11-13 21:15:57 <maxice8> how it detects you have already dealt with it
2020-11-13 21:16:00 <maxice8> ?
2020-11-13 21:19:38 <Cogitri> Dunno, I guess some file somewhere
2020-11-13 21:19:49 <Cogitri> probably due to you using a custom XDG* dir
2020-11-13 21:20:39 <dalias> uhg just looked at what it is and eew
2020-11-13 21:20:49 <dalias> "activities"? this isn't android *sigh*
2020-11-13 21:21:59 <dalias> is gnome a project to just perpetually chase the latest bad ideas from other platforms and finally get them out once they're already dated?
2020-11-13 21:28:05 <Cogitri> ?
2020-11-13 21:35:42 <dalias> Gnome TOUR
2020-11-13 21:37:18 <insep_> is flatpak dated yet
2020-11-13 21:37:55 <dalias> probably :-p
2020-11-13 21:38:15 <dalias> i forget which of the proposed solutions in that space are bad in which ways
2020-11-13 21:38:39 <ikke> flatpak is pretty bad
2020-11-13 21:38:41 <dalias> iirc most of them assume glibc-based host despite including their own library ecosystem in the package
2020-11-13 21:38:53 <insep_> user namespaces?
2020-11-13 21:39:06 <insep_> actually user namespaces are pretty cool
2020-11-13 21:39:24 <dalias> user namespaces are not part of the same problem space
2020-11-13 21:42:03 <insep_> the worst thing is flatpak-exclusive foss apps and being hostile to distro packaging
2020-11-13 21:42:57 <dalias> that too
2020-11-13 21:47:49 <Cogitri> Yes, that's pretty annoying
2020-11-13 21:47:52 <Ariadne> idk i gave up on gnome3
2020-11-13 21:48:01 <Cogitri> But on the other hand I sure wouldn't want to package anything in Debian
2020-11-13 21:48:15 <Ariadne> packaging stuff in debian is great
2020-11-13 21:48:19 <Ariadne> what are you talking about
2020-11-13 21:48:40 <Cogitri> Or deal with users having year old versions and not getting patches and then opening issues at my project
2020-11-13 21:48:45 <Cogitri> (see XScreenSaver)
2020-11-13 21:49:04 <Ariadne> i’m mostly kidding
2020-11-13 21:49:16 <Cogitri> Yeah, it's so much boilerplate and magic everywhere
2020-11-13 21:49:36 <Ariadne> after all LEAF was an emdebian distribution and alpine was started by people who thought that entire ecosystem could use a rewrite
2020-11-13 21:49:39 <Ariadne> :p
2020-11-13 21:49:41 <Cogitri> .deb has scarred me from the one time I tried to make a Project of mine available for Debian-based distros
2020-11-13 21:50:09 <Cogitri> that was such a pain that I'll only provide Flatpaks now, if users want it on their distro they'll have to package it themselves
2020-11-13 21:52:17 <Ariadne> that’s the plan for audacious
2020-11-13 21:54:39 <Ariadne> sometimes if you look deep in the murkiest parts of debian you’ll see some alpine devs names pop up to this day
2020-11-13 23:06:36 <maxice8> Opinions on !14605 ?
2020-11-14 03:32:30 <maxice8> Added new section and better clarification on !14605, ikke
2020-11-14 03:34:05 <hg> interesting
2020-11-14 03:35:22 <hg> maxice8: I love having the additional clarity
2020-11-14 04:09:13 <corysanin> ncopa: What's gcc 10.2.1? Is that just coming from git?
2020-11-14 04:11:15 <Ariadne> corysanin: yes
2020-11-14 04:11:40 <corysanin> Thanks. I was trying to figure out where that was coming from :P
2020-11-14 04:11:50 <Ariadne> corysanin: i generated it from git
2020-11-14 10:58:32 <maxice8> !14605
2020-11-14 11:00:42 <mps> maxice8: looks fine
2020-11-14 11:07:28 <Ariadne> this libffi thing is really annoying
2020-11-14 11:07:35 <Ariadne> i feel like it is a regression in binutils
2020-11-14 11:40:41 <Cogitri> Is someone running `dabuild` w/ podman? Can't build things right now due to https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10015
2020-11-14 11:41:24 <PureTryOut[m]2> Nope, since running Alpine myself I prefer using rootbld
2020-11-14 11:43:10 <Cogitri> Yeaah, I need a glibc distro for uni right now unfortunately (due to Zoom, the Zoom web thingie just doesn't cut it)
2020-11-14 11:45:57 <PureTryOut[m]2> Use Flatpak?
2020-11-14 11:46:12 <PureTryOut[m]2> Works for me with MS Teams which I sadly also need for school
2020-11-14 11:46:41 <Cogitri> The Zoom Flatpak doesn't work for me at all unfortunately
2020-11-14 11:46:56 <Cogitri> Just flat out doesn't start on Alpine for some reason
2020-11-14 11:47:22 <PureTryOut[m]2> Oh strange, did you report the issue?
2020-11-14 11:47:22 <Cogitri> And Zoom limits screensharing on certain distros for some reason, so I can't screenshare from the Flatpak
2020-11-14 11:48:00 <PureTryOut[m]2> For me the Steam Flatpak only runs on my laptop sadly, doesn't on my desktop even though both run Alpine Linux edge
2020-11-14 11:48:16 <Cogitri> https://github.com/flathub/us.zoom.Zoom/issues/57
2020-11-14 11:50:05 <PureTryOut[m]2> Ugh they closed that issue without verifying if that fix actually worked? How annoying
2020-11-14 11:50:36 <Cogitri> Well apparently it worked for some users, but I have no clue why it doesn't work for me (and apparently some others too)
2020-11-14 11:51:00 <Cogitri> And GNOME Xorg seems to crash on Alpine w/ AMDGPU and that looks like a massive pain to fix, so yeah :/
2020-11-14 11:52:45 <Ariadne> in other news, i've been working on a replacement implementation of widevine this evening
2020-11-14 11:53:00 <Ariadne> (the widevine L3 master key is compromised)
2020-11-14 11:53:48 <insep_> Cogitri: xwayland also doesn't work?
2020-11-14 11:55:59 <Cogitri> insep_: Zoom can only do X, so it only ever starts in XWayland mode on Wayland AFAICS
2020-11-14 19:17:09 <the6543> I have an issue with an old mariadb installation ...
2020-11-14 19:17:20 <the6543> it crashed and was updated ...
2020-11-14 19:17:41 <the6543> do somebody know how i can downgrade to 10.3.13-r0 ?
2020-11-14 19:19:41 <ikke> We only have 10.3.25
2020-11-14 19:19:45 <maxice8> if you have the apk you can do `apk add /path/to/archive.apk`
2020-11-14 19:19:58 <maxice8> If you set a cache you can check /var/cache/apk
2020-11-14 19:20:15 <ikke> if you enabled it
2020-11-14 19:20:32 <the6543> > ls rootfs/var/cache/apk/
2020-11-14 19:20:39 <the6543> APKINDEX.066df28d.tar.gz  APKINDEX.b53994b4.tar.gz
2020-11-14 19:20:42 <the6543> neh ...
2020-11-14 19:20:52 <the6543> is there realy no archive?!?
2020-11-14 19:20:53 <ikke> check /etc/apk/cache
2020-11-14 19:21:21 <ikke> the6543: we tried at some point, but it consumed the disk space we have available too quickly
2020-11-14 19:21:27 <the6543> no i dont have luck
2020-11-14 19:21:44 <the6543> hmm sad
2020-11-14 19:21:49 <ikke> What alpine version do you have?
2020-11-14 19:21:54 <the6543> edge :D
2020-11-14 19:22:16 <ikke> how were you running 10.3.13 on edge?
2020-11-14 19:22:27 <the6543> no upgrade since .... X
2020-11-14 19:22:39 <the6543> 2019-02-23
2020-11-14 19:23:02 <ikke> right, but even if yuo had the package, it would most likely not work
2020-11-14 19:23:10 <the6543> * ok there was an upgrade reacently ... witch caused this issue :D
2020-11-14 19:23:11 <ikke> all depedencies have been upgraded as well
2020-11-14 19:23:27 <ikke> so you need to build it yourself anyway
2020-11-14 19:23:37 <the6543> ok what I will try:
2020-11-14 19:23:52 <the6543> create temporary alpine 1.10 installation
2020-11-14 19:24:05 <the6543> build mariadb myselve and fix the install
2020-11-14 19:24:13 <the6543> and then upgrade
2020-11-14 19:24:18 <the6543> wish me luck!
2020-11-14 19:24:21 <ikke> success
2020-11-14 19:27:58 <dngray> anyway, i think i might go to bed, it's 6am, but yeah i can confirm, bumping lxc/lxc-libs to 4.0.5 solves it, and 4.0.2 is too old it would seem
2020-11-14 19:28:05 <dngray> (i recompiled them for 3.12.1)
2020-11-14 19:28:30 <dngray> https://github.com/lxc/go-lxc/blob/v2/lxc-binding.c#L79 does seem to be a difference
2020-11-14 19:30:11 <dngray> upstream i think wants it to work with 4.0.2 too so, they might be looking at a patch
2020-11-14 19:30:26 <ikke> ok
2020-11-14 19:36:32 <maxice8> !14605
2020-11-14 19:36:49 <maxice8> Just to confirm, Ikke, you read the new section I added at the bottom ?
2020-11-14 19:36:56 <ikke> I skimmed it
2020-11-14 19:40:06 <maxice8> ok, just wanted to know you were aware and there wasn't anything wrong with the wording
2020-11-14 19:49:10 <the6543> ok I had luck
2020-11-14 19:49:18 <the6543> 10.3.25 is able to start from crashed 1.3.13
2020-11-14 19:49:31 <the6543> PS: https://downloads.mariadb.org/interstitial/mariadb-10.3.13/source/mariadb-10.3.13.tar.gz is 404
2020-11-14 19:49:48 <the6543> so building from source is not an option ...
2020-11-14 19:49:58 <the6543> *was
2020-11-14 19:50:14 <the6543> mariadb works fine now again :tada:
2020-11-14 19:56:42 <ikke> https://distfiles.alpinelinux.org/distfiles/mariadb-10.3.13.tar.gz
2020-11-14 20:17:12 <c077ee> So Alpine is based on  musl libc and busybox. Are there any old docs on how that was setup?
2020-11-14 20:17:57 <the6543> @ikke how can i enable cache for packges
2020-11-14 20:18:25 <ikke> the6543: setup-apkcache /var/cache/apk
2020-11-14 20:19:47 <the6543> thanks :)
2020-11-14 20:23:26 <ikke> c077ee: I'm not aware of anything
2020-11-14 20:23:45 <ikke> the switch to musl is not that long ago (v3.0)
2020-11-14 20:26:18 <ikke> https://lists.alpinelinux.org/~alpine/devel/%3C20140409104437.2bc67a9e%40ncopa-desktop.alpinelinux.org%3E
2020-11-14 20:28:36 <c077ee> Awesome ty for the info
2020-11-14 20:28:45 <ikke> https://lists.alpinelinux.org/~alpine/devel/<20140324103226.37d73bc6%40ncopa-desktop.alpinelinux.org>
2020-11-14 21:13:54 <andypost[m]> Looks builders still affected by network split to build tree
2020-11-14 21:14:05 <ikke> yup
2020-11-14 21:25:14 <maxice8> @Cogitri pushed more changes to aports-qa-bot/commit-suggestions
2020-11-15 10:53:15 <PureTryOut[m]2> Did anyone get LibreOffice compiling yet? It has been disabled for ages now
2020-11-15 11:02:56 <ikke> I don't think so, but maybe it works with the latest gcc package
2020-11-15 12:13:59 <yZ5vlALg86lP> i asked a libreoffice dev, and he said the version that was disabled in alpine was really old, and there's a bunch of new versions out, so the guess it it might just work with a latest version.
2020-11-15 12:17:49 <ikke> yZ5vlALg86lP: aha, so maybe we should try to upgrade
2020-11-15 12:22:08 <yZ5vlALg86lP> btw may i ask what the goal is with: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/14605 ? for me it seems that every rule added increases the barrier of entry for new contributors. i mean i'm one of those that got discouraged to contribute pkgs to alpine because of such. i would guess i'm just the tip of the iceberg.
2020-11-15 12:24:18 <Ariadne> great, then don’t contribute
2020-11-15 12:25:04 <Ariadne> if the value to pain in the ass ratio doesn't work out for you, then don't worry about it
2020-11-15 12:25:41 <ikke> This should only make it easier for contributors so that they know in advance what is expected, instead of hearing that when they made their MR
2020-11-15 12:25:48 <insep_> not sure how is it different from regular coding style
2020-11-15 12:25:49 <ikke> Same with codingstyle
2020-11-15 12:25:53 <ikke> :)
2020-11-15 12:26:06 <Ariadne> all that MR does is document things we've generally been doing anyway.  if that's a problem for you, then it's a problem for you.  but things need to be documented.
2020-11-15 12:26:44 <yZ5vlALg86lP> it's ok if you have different priorities than attracting new contribs. i was just interested what those priorities are.
2020-11-15 12:26:58 <ikke> It should only make it easier for new contributors
2020-11-15 12:27:07 <Ariadne> the point of documenting this is to attract contributors who want to do things the right way
2020-11-15 12:27:20 <Ariadne> instead of having sponsoring developers scold them in code review
2020-11-15 12:27:28 <Ariadne> surely, that is an improvement as ikke said
2020-11-15 12:27:45 <yZ5vlALg86lP> yeah that scolding sucks. that was what also had a big impact on me
2020-11-15 12:28:01 <ikke> so now you know what is expected in advance
2020-11-15 12:28:22 <yZ5vlALg86lP> how would you? a new contributor does not start with reading these kind of docs.
2020-11-15 12:28:36 <yZ5vlALg86lP> i anew contributor starts with finding out how to build an apkbuild file
2020-11-15 12:28:48 <Ariadne> some do, some don't
2020-11-15 12:28:55 <yZ5vlALg86lP> and struggles, and when it finally works has his rush and pushes in extasy
2020-11-15 12:29:02 <Ariadne> but it is intended to be a useful reference for sponsoring developers to share with new contributors
2020-11-15 12:29:06 <Ariadne> that's all
2020-11-15 12:29:09 <ikke> We try to link to it in the appropriate places, and we are adding tools to our CI as well
2020-11-15 12:29:54 <Ariadne> because 90% of the time, when people submit things and they don't get included into alpine, they ask why
2020-11-15 12:30:02 <yZ5vlALg86lP> > some do, some don't exactly, and those who don't you might discourage
2020-11-15 12:30:06 <Ariadne> and once they find out why, they go "wow, it would be nice if this was more obvious"
2020-11-15 12:30:29 <Ariadne> well, if somebody is discouraged by the fact that policy is documented, we probably do not want their contributions anyway
2020-11-15 12:30:31 <Ariadne> soooo
2020-11-15 12:30:38 <Ariadne> sounds like feature to me
2020-11-15 12:31:05 <Ariadne> its not like upon installation of alpine, a gun pops out of your CD-ROM drive and a message "contribute or else" is displayed on the screen
2020-11-15 12:31:14 <yZ5vlALg86lP> well, maybe the thing is not to have policy documented, but to have it in the first place, without reason. although ikke hinted at automatization in ci which is a good reason.
2020-11-15 12:31:47 <ikke> The policy was implied already
2020-11-15 12:31:54 <yZ5vlALg86lP> yeah, but why?
2020-11-15 12:31:56 <ikke> by the people who review and accept MRs
2020-11-15 12:32:07 <ikke> Same with coding style guidelines
2020-11-15 12:32:11 <ikke> people like consistency
2020-11-15 12:32:14 <ikke> and people like quality
2020-11-15 12:32:20 <Ariadne> alpine is used all around the world on systems that are mission critical.  if you want a YOLO distribution, there's plenty of toys out there to play with.
2020-11-15 12:32:42 <ikke> So a little effort from contributors is expected
2020-11-15 12:33:46 <Ariadne> that document is also meant for reviewers who sponsor packages into alpine
2020-11-15 12:33:54 <Ariadne> to remind them of what they need to look for when reviewing
2020-11-15 12:34:08 <ikke> And also to provide a consistent experience to contributors
2020-11-15 12:34:18 <Ariadne> because sometimes, things have gotten accepted that were not fully up to standard
2020-11-15 12:35:14 <yZ5vlALg86lP> how much of those "not up to standard" had negative consequences because of misleading commit msg titles?
2020-11-15 12:35:31 <Ariadne> main/gettext is an example
2020-11-15 12:35:44 <yZ5vlALg86lP> i mean i get it' the title should not be "did foo" - that is obviously yolo
2020-11-15 12:36:05 <yZ5vlALg86lP> but writing "updated to v2.0" instead of "upgraded to v2.0" is a bit too strict
2020-11-15 12:36:19 <ikke> That's the 'people like consistency' part
2020-11-15 12:36:22 <Ariadne> such contributions would not be rejected
2020-11-15 12:36:33 <Ariadne> the key part is explaining *why* something was done
2020-11-15 12:36:45 <yZ5vlALg86lP> or even "bumped to v2.0"
2020-11-15 12:36:47 <ikke> Yes, totally agree
2020-11-15 12:36:50 <ikke> with Ariadne
2020-11-15 12:37:09 <Ariadne> (seriously, if someone rejects an MR for using bumped or updated instead of upgraded, feel free to let me know, i'll smack them with a cluebat)
2020-11-15 12:37:15 <ikke> yZ5vlALg86lP: tabs vs spaces is also completely subjective
2020-11-15 12:37:18 <yZ5vlALg86lP> i had that happen to me
2020-11-15 12:37:19 <ikke> but it's enforced
2020-11-15 12:37:24 <Ariadne> when?
2020-11-15 12:37:32 <ikke> Not rejected, asked to change
2020-11-15 12:37:58 <Ariadne> i don't do much reviewing anymore, but i've never even requested change for something so trivial
2020-11-15 12:38:11 <Ariadne> i just fix it myself and push by hand
2020-11-15 12:39:31 <yZ5vlALg86lP> hmmmm. others might not be so cool. anyway. i think we all made our points. time to move on, and do stuff ;)
2020-11-15 12:39:46 <Ariadne> and upgrades are fully automated with abump anyway
2020-11-15 12:39:58 <Ariadne> so you shouldn't even have to write a commit message in this case
2020-11-15 12:42:39 <ikke> someone like Leo (maxice8) is merging a lot of things, so he's kind of optimizing for that by doing less by hand
2020-11-15 12:46:05 <yZ5vlALg86lP> that is an argument in favor of this. still i say, this also increases the barriers of entry to new users. and this might be balanced, or might be solved differently. i remember when i started here long ago it was quite easy to jump in and join, this has become less so in recent years. but it's barely noticable if you're in it
2020-11-15 12:46:41 <yZ5vlALg86lP> anyway, we spent too much time on this already. let's do stuff instead.
2020-11-15 12:46:53 <ikke> I'm doing stuff, like getting libreoffice to compile
2020-11-15 12:47:35 <yZ5vlALg86lP> that's what i meant ;)
2020-11-15 12:52:33 <Ariadne> is it any surprise that over 15 years, as alpine (and derivatives) has been adopted by more and more users with increasingly mission critical requirements, that the belt has tightened?
2020-11-15 12:53:22 <Ariadne> things are naturally different when there's like 50 users and nobody really cares
2020-11-15 12:53:44 <Ariadne> now if alpine breaks, that can have substantial consequences
2020-11-15 13:01:26 <yZ5vlALg86lP> it won't break because of commitmessagetittle nor tabsvsspaces, and if, it will do so in edge, which is most of the time broken in one way or another anyway
2020-11-15 13:02:02 <ikke> yZ5vlALg86lP: consistent commit messages make it easier to grep them
2020-11-15 13:02:37 <ikke> especially because we often have these very mechanical commits
2020-11-15 13:07:46 <ikke> yZ5vlALg86lP: tried with 7.0.2.2, but we still get the same error
2020-11-15 13:07:53 <ikke> ucbstorage.cxx:(.text+0x645b): undefined reference to `non-virtual thunk to cppu::WeakImplHelper<com::sun::star::io::XInputStream>::acquire()'
2020-11-15 13:19:20 <mps> I use mostly upgrade and not update (if ever I used it) and seems most of commits use upgrade
2020-11-15 13:43:40 <ikke> yZ5vlALg86lP: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12109
2020-11-15 13:43:44 <ikke> Created an issue to track it
2020-11-15 13:56:55 <yZ5vlALg86lP> cool. i'll post it to my libreoffice contact.
2020-11-15 14:01:19 <ikke> yZ5vlALg86lP: thanks
2020-11-15 19:28:29 <maxice8> is COMMITSTYLE good to go ?
2020-11-15 19:28:45 <maxice8> Also aports-qa-bot can now auto-label merge requests based on the contents
2020-11-15 19:28:49 <maxice8> (not perfect, but pretty good)
2020-11-15 19:29:40 <Cogitri> Once the container is rebuilt and restarted that is
2020-11-15 19:31:34 <maxice8> Yes
2020-11-15 19:53:55 <mps> for me web interface is cumbersome to review such things
2020-11-15 19:58:07 <mps> it is pity GL don't have 'view raw' option for files
2020-11-15 19:58:36 <ix> it does...
2020-11-15 19:58:56 <ix> replace "blob" with "raw" in url
2020-11-15 19:59:01 <ix> there is a button for it somewhere as well
2020-11-15 20:04:19 <mps> this is two steps more
2020-11-15 20:04:33 <ix> ok
2020-11-15 20:06:20 <mps> maxice8: looks ok
2020-11-15 20:07:11 <mps> where we should put style guide for pkg description, in CODINGSTYLE.md?
2020-11-15 20:26:41 <maxice8> ABUILDSTYLE ?
2020-11-15 20:26:44 <maxice8> APKBUILDSTYLE*
2020-11-15 20:39:01 <mps> hmm, 'Policy for APKBUILDs' is title of CODINGSTYLE.md
2020-11-15 20:39:46 <mps> though your idea also looks ok
2020-11-15 20:40:42 <mps> so maybe rename CODINGSTYLE.md CODINGPOLICY.md and add APKBUILDSTYLE.md?
2020-11-15 20:47:01 <Cogitri> I think using CODINGSTYLE.md is a good idea since that's the standard name for that
2020-11-15 20:51:27 <mps> I don't have strong preference
2020-11-15 20:53:09 <mps> except that we should have documented some fields, pkgver, description, _gitcommitid (however it should be called), source, options etc
2020-11-15 20:54:18 <ikke> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
2020-11-15 20:58:03 <mps> huh, I forgot that
2020-11-15 20:58:44 <ikke> Everything starting with an _ is not official
2020-11-15 22:17:20 <yZ5vlALg86lP> ikke: contact says in fedora 6.4.7 compiles with gcc10 without any extra patches, and also 7.0.3 with only one missing include needing to be added. so this seems to be more alpine specific according to him.
2020-11-15 22:17:52 <yZ5vlALg86lP> sorry for not having a solution. :/
2020-11-15 22:50:14 <tbodt> greetings, is there an archive of previous versions of files such as http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86/APKINDEX.tar.gz?
2020-11-15 22:50:34 <tbodt> or just generally previous versions of alpine packags
2020-11-15 22:55:26 <tbodt> I guess, as a concrete question, does php7-7.3.23-r0.apk exist anywhere on the public internet?
2020-11-15 23:01:27 <Cogitri> Nope, we don't keep old package versions
2020-11-15 23:01:46 <Cogitri> You could checkout an aports version from before php was bumped and build php yourself though
2020-11-15 23:03:27 <tbodt> guess now would be a good time for me to start an archive
2020-11-15 23:03:51 <tbodt> I would prefer the official versions if available since they're signed
2020-11-15 23:04:14 <Cogitri> Yes, but we don't have the mirror space for that
2020-11-15 23:04:31 <Cogitri> and since we build directly from aports you should get the same result building it yourseld
2020-11-15 23:04:35 <Hello71> i think we also don't have fully reproducible builds
2020-11-15 23:04:41 <Hello71> at least i haven't heard of anyone working on it
2020-11-15 23:04:48 <tbodt> found this https://gitlab.alpinelinux.org/alpine/abuild/-/issues/9996#note_109817, ncopa said there are other organizations that have their own mirrors? anyone know where they are?
2020-11-15 23:05:16 <Cogitri> And provided you're trusting yourself building yourself shouldn't be any worse than using an Alpine signed binary
2020-11-15 23:06:08 <Cogitri> Hello71: I think we can do reproducible builds, we just don't really care a lot about right now (as in we don't really have checks in place to ensure that packages don't include time stamps in the build etc.)
2020-11-15 23:06:10 <tbodt> I should explain my use case: I work on iSH (https://ish.app) and would like to ship the entire alpine package repo inside the app because apple rejected the idea of downloading packages from alpine repos
2020-11-15 23:06:20 <tbodt> to keep my builds reproducible I'd want an archive of the packages I ship
2020-11-15 23:06:47 <Cogitri> You'd probably have to manually mirror it yourself then
2020-11-15 23:06:55 <tbodt> thought so, guess I'll do that
2020-11-15 23:07:06 <Cogitri> And sync up with Alpine when you're making a new archive to use in iSH
2020-11-15 23:07:58 <tbodt> can probably also make it public for anyone else who wants to install old versions
2020-11-15 23:11:04 <Cogitri> Sure, but be prepared to need loads of disk space for your endeavour
2020-11-15 23:11:23 <tbodt> I'll most likely use cloud storage
2020-11-15 23:11:43 <tbodt> according to an awk script I ran, the repos for the arch I care about are like 15gb
2020-11-15 23:11:52 <tbodt> which is $0.06/month on backblaze
2020-11-15 23:12:40 <Cogitri> Ah, if you only mirror one arch on one release it'll be somewhat limited :)
2020-11-15 23:13:12 <tbodt> yeah I don't need every arch
2020-11-15 23:13:16 <tbodt> I would want to mirror all releases though
2020-11-16 04:16:05 <tbodt> what character encoding is used for APKINDEX?
2020-11-16 04:21:26 <insep_> utf-8
2020-11-16 04:21:52 <insep_> at least that's a case for http://dl-2.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz
2020-11-16 04:32:45 <dalias> that really shouldnt be a question in 2020 :)
2020-11-16 05:26:15 <tbodt> +1 dalias, thought I'd check :)
2020-11-16 06:00:50 <halosghost> is there a trick to compiling against ncurses applications on alpine?
2020-11-16 06:01:19 <halosghost> I have ncurses-dev installed and I have my linker/compiler flags set as I would on any other system, but I just keep getting undefined-reference errors for all ncurses functions
2020-11-16 06:05:08 <ikke> halosghost: If I look at other APKBUILDs, I don't see anything special
2020-11-16 06:05:26 <halosghost> mm
2020-11-16 06:05:52 <halosghost> admittedly, I'm not running this in abuild, I'm just building it
2020-11-16 06:05:56 <halosghost> (e.g., running `make`
2020-11-16 06:05:59 <halosghost> )
2020-11-16 06:06:04 <ikke> sure, but that should not matter a lot
2020-11-16 06:06:21 <ikke> at most, you're missing some flags defined in /etc/abuild.conf
2020-11-16 06:08:53 <halosghost> mm
2020-11-16 07:43:59 <ikke> Morning
2020-11-16 07:45:10 <mps> good morning
2020-11-16 07:53:09 <ncopa> morning
2020-11-16 07:53:55 <ncopa> tbodt: the org(s) that I know that have their own mirrors does not expose their repos on public internet afaik
2020-11-16 07:57:13 <Ariadne> i've considered shoving the entire alpine repo in ipfs every day
2020-11-16 07:58:03 <Cogitri> Morning 👋
2020-11-16 08:47:35 <ikke> btw, fortify-headers source seems to be awol
2020-11-16 08:48:00 <ikke> domain name is NXDOMAIN
2020-11-16 08:48:17 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12108
2020-11-16 08:50:20 <insep_> they are back https://git.2f30.org/fortify-headers/log.html
2020-11-16 08:50:21 <insep_> \o/
2020-11-16 08:57:56 <Ariadne> http://dl.2f30.org/releases/fortify-headers-1.1.tar.gz is still NXDOMAIN.
2020-11-16 09:40:22 <Newbyte> "No such package: .makedepends-phoc" -- what would this mean?
2020-11-16 09:40:30 <Newbyte> this is when running abuild -r to build Phoc
2020-11-16 09:45:37 <ikke> Newbyte: I've mostly seen this when the dependencies could not be installed for some reason and abuild tries to remove the dependencies again afterwards
2020-11-16 09:46:37 <Newbyte> thanks, I'll continue investigating
2020-11-16 09:46:52 <ikke> Check the output of abuild -r
2020-11-16 09:47:48 <Newbyte> Oh, hold on, you're right, it says that when trying to uninstall them, not install them
2020-11-16 09:47:55 <Newbyte> Thanks
2020-11-16 09:57:39 <ikke> The package it tries to deinstall is a virtual package the abuild creates so that it can easily remove all dependencies again
2020-11-16 11:10:31 <Ariadne> ncopa: i think it is worthwhile to disable -fpartial-inlining for now in gcc
2020-11-16 11:10:49 <Ariadne> ncopa: because clang is not compatible with -fno-partial-inlining (and its probably more subtly broken outside MIPS)
2020-11-16 13:49:39 <wsinatra> anyone mind looking at MR !14613?
2020-11-16 15:05:46 <yZ5vlALg86lP> guess who's back?
2020-11-16 15:06:00 <ikke> back agai
2020-11-16 15:06:06 <ikke> n
2020-11-16 15:06:10 <yZ5vlALg86lP> https://github.com/ytdl-org/youtube-dl
2020-11-16 15:06:24 <ikke> yes, saw it
2020-11-16 15:06:44 <ikke> They removed the offending tests
2020-11-16 15:07:00 <ikke> But it's still in the history
2020-11-16 15:25:02 <dalias> halosghost, what undefined symbols?
2020-11-16 15:50:37 <the6543> I'm not sure if i should backport !14681 to 3.11 too ?
2020-11-16 15:50:47 <the6543> what do you think?
2020-11-16 15:52:09 <ikke> the6543: offically community is eol for 3.11
2020-11-16 15:52:32 <the6543> ok thanks :)
2020-11-16 15:53:13 <ikke> But if there are compelling reasons to upgrade it (within the default rules), then it should not be an issue
2020-11-16 15:53:41 <ikke> it's in 1.10
2020-11-16 15:53:53 <ikke> s/in/on/
2020-11-16 15:53:53 <alpine-meetbot> ikke meant to say: it's on 1.10
2020-11-16 15:54:10 <ikke> I don't think the security fix is backported to 1.10?
2020-11-16 15:55:53 <the6543> it's not
2020-11-16 15:57:31 <the6543> for some reason 1.12.6 build fail while 1.12.5 did not (~3 days ago) ... looks like I have to look at things again
2020-11-16 15:57:45 <the6543> I'll be off for ~1h see you soon
2020-11-16 16:01:42 <z3ntu> Is `install` in a subpackage supposed to work in an apkbuild? The sanity check is definitely faulty for that
2020-11-16 16:02:16 <z3ntu> (if it's supposed to work)
2020-11-16 16:03:11 <ikke> do you mean the `install` command?
2020-11-16 16:04:19 <z3ntu> I mean e..g `install="$subpkgname.post-install"`
2020-11-16 16:05:14 <z3ntu> I believe there's a sanity check that the scripts used in $install exist for the main package but in subpackages it just silently fails if the e.g. post-install script is missing
2020-11-16 16:06:48 <ikke> z3ntu: that's because the sanitycheck has no visibility in variables defined in functions
2020-11-16 16:06:55 <ikke> it does not do a static analasis
2020-11-16 16:07:08 <ikke> so it can only check global state
2020-11-16 16:44:52 <z3ntu> ikke: I've traced it back to https://github.com/alpinelinux/abuild/blob/master/abuild.in#L1129 which just ignores mismatching install files for some reason. Any idea why this isn't a fatal error there?
2020-11-16 16:45:47 <z3ntu> If this is a matter of parent packages "leaking" into the subpackages, maybe it needs to be explicitly cleared like in https://github.com/alpinelinux/abuild/blob/master/abuild.in#L847 ? Or am I missing some functionality of abuild?
2020-11-16 16:47:19 <ikke> I don't know why
2020-11-16 16:49:02 <ikke> z3ntu: are you running into some bug, or just surprised that abuild didn't error out on missing install files?
2020-11-16 16:50:15 <z3ntu> well I'd consider abuild ignoring typos in `install=` declarations a bug
2020-11-16 16:50:33 <z3ntu> but yes I've come across a package which has an invalid install= in a subpackage
2020-11-16 16:50:37 <ikke> nod
2020-11-16 16:51:33 <ikke> Probably something we want to add to our linter as well
2020-11-16 16:51:33 <z3ntu> but apparently declaring an `install` for a subpackage in the parent is valid as well
2020-11-16 16:54:52 <ollieparanoid[m]> hey all! can somebody look at: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14673
2020-11-16 16:59:41 <mps> !14673
2020-11-16 17:15:18 <ikke> the6543_: ping
2020-11-16 17:15:28 <ikke> the6543_: seems like gitea is failing on 2 arches
2020-11-16 17:25:14 <the6543_> yes - I have to figure it out
2020-11-16 17:25:42 <the6543_> oh thanks
2020-11-16 17:25:53 <the6543_> it passed somehow :O
2020-11-16 17:26:16 <ikke> but not on the builders
2020-11-16 17:26:29 <ikke> https://build.alpinelinux.org/buildlogs/build-3-12-ppc64le/community/gitea/gitea-1.12.6-r0.log
2020-11-16 17:26:34 <ikke> https://build.alpinelinux.org/buildlogs/build-3-12-armv7/community/gitea/gitea-1.12.6-r0.log
2020-11-16 17:26:39 <ikke> armv7: test failure
2020-11-16 17:26:47 <ikke> ppc64le: make error
2020-11-16 17:26:49 <the6543_> anoing
2020-11-16 17:27:08 <ikke> yes, very
2020-11-16 17:27:41 <the6543_> looks like webpack is reporting an issue somehow
2020-11-16 17:28:19 <the6543_> I'll make !14680 pass - witch should show us the issue
2020-11-16 17:29:06 <the6543_> I'll ping you if I'm ready :)
2020-11-16 17:29:16 <ikke> (y)
2020-11-16 17:44:20 <ikke> the6543_: ppc64le built the 2nd try
2020-11-16 17:44:39 <ikke> certainly something that should be looked at
2020-11-16 17:44:40 <ikke> seems flaky
2020-11-16 18:51:59 <the6543_> hmm it could be a temporary issue when one of npm repos or npm servers had maintinence
2020-11-16 18:52:22 <ikke> Or concurrency issues
2020-11-16 18:52:44 <the6543_> hmm this should not happen
2020-11-16 18:53:00 <the6543_> webpack and the frontend build process is realy stable
2020-11-16 18:53:18 <the6543_> I rarely saw issues on our CI tasks witch was caused by it
2020-11-16 18:53:55 <ikke> hmm
2020-11-16 18:54:01 <ikke> armv7 succeeded now as well
2020-11-16 18:55:22 <the6543_> rebased edge mr .. we will see
2020-11-16 18:56:30 <the6543_> for concurrency issues ... instead of "make build" we could do "make frontend; make backend"
2020-11-16 18:57:46 <the6543_> @ikke so all 3.12 packages are now build successfully?
2020-11-16 19:06:27 <ikke> the6543: yes
2020-11-16 19:06:45 <ikke> well, officially armhf has not been built yet
2020-11-16 19:06:57 <the6543> ok ...
2020-11-16 19:06:57 <ikke> it seems to be stuck on tor
2020-11-16 19:07:16 <the6543> I triggerd 3 builds at similar time
2020-11-16 19:07:17 <the6543> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14680/pipelines
2020-11-16 19:07:39 <the6543> if one of them fails it could be an "sometimes-happen" issue witch is bad
2020-11-16 19:08:05 <the6543> if not it was just temporary issue, likely caused by external dependencys
2020-11-16 19:09:32 <ikke> the test failure on armv7 does not seem to depend on external dependencies
2020-11-16 19:09:49 <the6543> tor?
2020-11-16 19:11:14 <ikke> https://build.alpinelinux.org/buildlogs/build-3-12-armhf/community/tor/tor-0.4.3.7-r0.log
2020-11-16 19:13:59 <the6543> hmm
2020-11-16 19:14:47 <ikke> bus error
2020-11-16 19:29:25 <ikke> maxice8: ping
2020-11-16 19:30:04 <maxice8> Pong
2020-11-16 19:30:24 <ikke> Would something like this work for APKBUILD.vim: MC[AL32]:braces.txt:1:10:unnecessary use of braces: def
2020-11-16 19:30:32 <ikke> so I added the :10 part as the column
2020-11-16 19:33:48 <the6543> ok back to topic one ...
2020-11-16 19:33:59 <the6543> should I backport gitea to 3.11 or not?
2020-11-16 19:35:35 <the6543> "I don't think the security fix is backported to 1.10?"
2020-11-16 19:35:36 <ikke> Unless you want to backport the fix to 1.10, the policy is not to
2020-11-16 19:36:04 <the6543> ah ok just make sure - I'm fine with NO backport
2020-11-16 19:36:10 <ikke> ok
2020-11-16 19:36:18 <the6543> it's not that criticall just i some edgecasses
2020-11-16 19:36:23 <ikke> nod
2020-11-16 19:36:27 <the6543> *in some edgecases
2020-11-16 19:36:36 <the6543> nod?
2020-11-16 19:36:39 <ikke> And because community is EOL, we don't guarantee any security fixes
2020-11-16 19:36:55 <ikke> like shaking head in agreement (nodding)
2020-11-16 19:37:07 <the6543> :+1:
2020-11-16 19:37:38 <the6543> and for the build issue I could not reproduce it a single time
2020-11-16 19:38:12 <the6543> !14680 <- pipelines
2020-11-16 19:38:36 <the6543> @ikke should i trigger CI some more times?
2020-11-16 19:39:37 <ikke> Let me try it in my lxc container
2020-11-16 19:59:22 <maxice8> @Ikke: That is one of the big reasons why I wanted a non-shell rewrite
2020-11-16 19:59:30 <maxice8> turns out it is really hard to get columns
2020-11-16 19:59:48 <ikke> yes
2020-11-16 19:59:51 <ikke> But I have that
2020-11-16 19:59:53 <ikke> that's an example
2020-11-16 20:00:07 <maxice8> when using shell, and It would make apkbuild-fixer much more reliable and allow a more accurate linting with ALE
2020-11-16 20:00:09 <ikke> that sh module includes line and column positions for every node
2020-11-16 20:00:34 <maxice8> Very good
2020-11-16 20:00:38 <ikke> maxice8: example of the AST: https://tpaste.us/YoEM
2020-11-16 20:00:52 <maxice8> fancy
2020-11-16 20:01:06 <ikke> You proposed that library :P
2020-11-16 20:01:24 <ikke> very happy with it so far
2020-11-16 20:01:35 <maxice8> Yeah but I didn't look far into it
2020-11-16 20:01:40 <ikke> understood
2020-11-16 20:01:48 <ikke> But I just wanted to sync that linter output with you
2020-11-16 20:03:21 <maxice8> ty
2020-11-16 20:03:28 <maxice8> do we move the docs into atools-go ?
2020-11-16 20:04:13 <ikke> maxice8: I was thinking maybe merging atools-go into atools
2020-11-16 20:05:04 <maxice8> https://0x0.st/i5uo.png
2020-11-16 20:06:25 <maxice8> Do you know a good go library for fancy output ?
2020-11-16 20:06:53 <ikke> No, not aware of anything
2020-11-16 20:40:31 <ikke> maxice8: How does AL36 work :D
2020-11-16 20:40:37 <ikke> https://gitlab.alpinelinux.org/Leo/atools/-/blob/master/apkbuild-lint#L425
2020-11-16 20:41:44 <maxice8> grep variable, remove trailing and leading spaces, grep for $FLAG
2020-11-16 20:42:01 <ikke> ah, I just now see the flag is passed as an argument
2020-11-16 20:42:03 <maxice8> or rather absence of it
2020-11-16 20:42:08 <maxice8> the real answer is
2020-11-16 20:42:09 <maxice8> poorly
2020-11-16 20:42:36 <ikke> Yeah, I understand it's difficult
2020-11-16 20:42:58 <ikke> Will be easier with a proper AST
2020-11-16 20:43:24 <ikke> though, right now I only check global variables
2020-11-16 20:54:14 <ikke> maxice8: https://gitlab.alpinelinux.org/kdaudt/atools-go/-/merge_requests/3/diffs
2020-11-16 20:58:51 <maxice8> fantastic
2020-11-16 20:59:33 <ikke> Still missing support to disable specific lints
2020-11-16 21:06:39 <maxice8> isn't that done via os.Getenv ?
2020-11-16 21:06:45 <ikke> yes
2020-11-16 21:06:51 <ikke> Just need to add that
2020-11-16 21:06:58 <ikke> But ignored that for now
2020-11-16 21:41:50 <hechos> hi guys
2020-11-16 21:42:47 <hechos> im facing with linux/soundcard.h No such file or directory
2020-11-16 21:42:54 <hechos> but all is in place.
2020-11-16 21:43:04 <hechos> somthing with musl?
2020-11-16 21:43:17 <ikke> so you have linux-headers?
2020-11-16 21:45:06 <hechos> fuuu
2020-11-16 21:45:11 <hechos> soryy
2020-11-16 21:45:41 <ikke> :)
2020-11-16 21:45:58 <hechos> its me.
2020-11-16 21:46:44 <hechos> well
2020-11-16 21:46:50 <hechos> im coming from void.
2020-11-16 21:47:05 <hechos> so apk work different.
2020-11-16 21:47:17 <hechos> but on musl like more alpine.
2020-11-16 21:48:00 <hechos> still looking for solution cannot get alsa work.
2020-11-16 21:48:13 <hechos> for now doesnt know why.
2020-11-16 21:58:56 <hechos> thanks ikke
2020-11-16 21:59:03 <ikke> np
2020-11-16 21:59:42 <hechos> may its qutebrowser
2020-11-16 22:23:26 <the6543> ok I think !14680 is ready for the automrege ;)
2020-11-16 22:26:09 <ikke> done
2020-11-16 22:26:55 <the6543> thanks
2020-11-16 22:27:09 <the6543> while I was chating with other (gitea-)maintainers ...
2020-11-16 22:27:15 <the6543> they wrote:
2020-11-16 22:27:21 <the6543> "make should not run with any parallelism as mentioned in README.md"
2020-11-16 22:27:38 <ikke> right, so you should probably add -j1 to the make invokation then
2020-11-16 22:27:41 <the6543> so I think next upgrade I have to add a -j 1 to it
2020-11-16 22:27:45 <ikke> yup
2020-11-16 22:28:07 <the6543> ok ... next time :)
2020-11-16 22:28:16 <the6543> v1.13.0 looks around the corne
2020-11-16 22:28:18 <the6543> r
2020-11-16 22:29:51 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/gitea/gitea-1.12.6-r0.log
2020-11-16 22:30:25 <ikke> hmm, strange, same error
2020-11-16 22:30:41 <the6543> saw it ..
2020-11-16 22:30:55 <the6543> can you just restart and hope it works the secnd time
2020-11-16 22:31:03 <ikke> yes, already on ity
2020-11-16 22:31:08 <the6543> thanks
2020-11-16 22:31:18 <the6543> we realy need -j1
2020-11-16 22:32:06 <the6543> but I'm not a fend of spaming the gitlog ... so if restart did it this time I'll wait until next release
2020-11-16 22:32:18 <ikke> yeah, fine with me
2020-11-16 22:32:55 <mps> the6543: add it now, if some rebuild it locally will be of help
2020-11-16 22:33:07 <the6543> ---
2020-11-16 22:33:46 <ikke> You can add it without bumping pkgrel
2020-11-16 22:33:46 <mps> if we know something need fix and we have fix don't wait
2020-11-16 22:34:06 <the6543> on my way to push
2020-11-16 22:35:03 <mps> look at some commits that have cosmetic space char removeal :)
2020-11-16 22:35:57 <the6543> and here it is
2020-11-16 22:35:58 <the6543> !14691
2020-11-16 23:41:26 <maxice8> turns out you can use emojis in Gitlab project names
2020-11-17 00:02:53 <maxice8> https://gitlab.alpinelinux.org/Leo/agl
2020-11-17 02:21:53 <dalias> is MT-fork patch still working fine in edge?
2020-11-17 03:33:44 <halosghost> ikke: I'm gonna try building this ncurses thing with abuild to see if that fixes it
2020-11-17 03:33:54 <halosghost> if it does, then clearly something is messed up with my local dev environment
2020-11-17 03:51:43 <dalias> halosghost, what is the missing symbol?
2020-11-17 03:54:34 <Ariadne> dalias: yes
2020-11-17 04:06:11 <halosghost> dalias: anything and everything from ncurses afaict
2020-11-17 04:06:17 <halosghost> also
2020-11-17 04:08:04 <dalias> which specific symbol errors?
2020-11-17 04:08:32 <dalias> without an exact error message there's nothing actionable
2020-11-17 04:08:42 <halosghost> sure, one sec
2020-11-17 04:13:23 <halosghost> dalias: https://0x0.st/i5ly.txt
2020-11-17 04:13:29 <halosghost> hmm
2020-11-17 04:13:31 <halosghost> no
2020-11-17 04:13:42 <halosghost> dalias: https://0x0.st/i51y.txt
2020-11-17 04:13:46 <halosghost> that one, sorry about that
2020-11-17 04:17:49 <halosghost> dalias: I'm happy to provide any logs or files you'd like (the build system I use it pretty much just make, so I can provide those files as well)
2020-11-17 04:26:59 <halosghost> dalias: thoughts? :P
2020-11-17 04:27:12 <halosghost> (this has been a very strange and frustrating problem)
2020-11-17 04:30:37 <halosghost> 
ACTION reboots to see if the new osk-sdl is nicer

2020-11-17 04:33:35 <halosghost> well, it's nicer
2020-11-17 04:34:07 <halosghost> I'll need to test to see if it still loses keystrokes
2020-11-17 04:40:29 <insep_> it should lose less not at least
2020-11-17 04:40:51 <insep_> s/not/now/g
2020-11-17 04:40:51 <alpine-meetbot> insep_ meant to say: it should lose less now at least
2020-11-17 04:41:35 <halosghost> insep_: that's the hope :)
2020-11-17 04:47:47 <halosghost> dalias: worth mentioning that I do have ncurses-dev installed
2020-11-17 06:38:15 <mps> dalias: MT-fork patch works, or I didn't noticed if it fails somewhere
2020-11-17 06:39:50 <mps> if you are making release please don't forget reallocarray, and maybe recallocarray
2020-11-17 09:31:09 <m242> Hello, on a merge request I suspect that a pipeline might be failing because of some sort of timeout, so I would like to relaunch it a few times, but I would prefer to avoid using cpu cycles that would be more useful elsewhere. Is there a policy on how to use pipelines that I didn't find ?
2020-11-17 09:31:24 <m242> If not, can I relaunch pipelines as much as I want ?
2020-11-17 09:32:41 <ikke> Well, within reasonability
2020-11-17 09:33:08 <ikke> We have limited capacity for jobs, so other jobs would need to wait
2020-11-17 09:34:31 <m242> I see, I will try to re run the failing build on a VM on my machine here first and then retry the pipelines if needed. Thanks :)
2020-11-17 09:44:28 <ncopa> dalias: I have not noticed any problems with the MT-fork patch on my work desktop yet. I just tested to remove the ugly work-around patch that we have for libvirt for and libvirt no longer deadlock
2020-11-17 10:16:59 <Cogitri> Nice
2020-11-17 10:29:10 <Ariadne> mps: we concluded recallocarray is a pointless interface
2020-11-17 10:38:56 <mps> Ariadne: aha, ok
2020-11-17 11:51:48 <Ariadne> ncopa: i moved ircservices from main to community since it is dead upstream
2020-11-17 12:42:06 <ncopa> sounds good. thanks!
2020-11-17 12:44:19 <mps> this reminds me to move perl-text-aspell to main, it is good to have for irssi spell check
2020-11-17 13:49:10 <ikke> nice, fabled seems to have fixed libreoffice
2020-11-17 13:49:19 <Cogitri> Hooray
2020-11-17 13:49:51 <ikke> https://git.alpinelinux.org/aports/commit/?id=8fac12716006
2020-11-17 13:49:53 <fabled> yeah, it was annoying. and it's a sort of ugly workaround. but should at least build again
2020-11-17 13:50:30 <fabled> it really feels g++ bug (not instantiating the templated class stubs)
2020-11-17 13:53:25 <ikke> I also tried upgrading libreoffice to 7.0.2.2, I still have the commit with the changes
2020-11-17 13:54:14 <fabled> maybe PR? i actually want libreoffice to build, so i can use it again. i have $-work pending where i need it...
2020-11-17 13:54:37 <ikke> Sure
2020-11-17 13:55:23 <fabled> the 1h timeout triggers for libreoffice for other arches than x86 and x86_64
2020-11-17 13:55:34 <fabled> ppc64le and aarch64 almost finish.. they got to packaging stage
2020-11-17 13:55:49 <ikke> You can increase the CI timeout in your project settings
2020-11-17 13:56:34 <ikke> https://gitlab.alpinelinux.org/fabled/aports/-/settings/ci_cd
2020-11-17 13:56:40 <ikke> Under general pipelines
2020-11-17 14:00:42 <fabled> thanks
2020-11-17 14:43:10 <Ariadne> fabled: by the way, i would like to start working on a plan to replace quagga with FRR.  your thoughts on that?  quagga seems to be very dead.
2020-11-17 14:43:47 <fabled> sounds good. yes Quagga seems dead.
2020-11-17 14:44:09 <mps> what about bird? in what state it is
2020-11-17 14:44:23 <Ariadne> still alive, well, and available in alpine
2020-11-17 14:44:41 <mps> I didn't looked last few years because don't need it now
2020-11-17 14:44:55 <mps> yes, I know it is in alpine
2020-11-17 14:45:19 <mps> I'm not proposing bird, just asking
2020-11-17 15:17:56 <ollieparanoid[m]> Ariadne: hi!
2020-11-17 15:17:56 <ollieparanoid[m]> how about using `git format-patch -N` for the patches in the gcc aport?
2020-11-17 15:18:06 <ollieparanoid[m]> that will remove the numbers from the subjects of the patches => cleaner diff
2020-11-17 15:19:08 <Ariadne> i will do so next time i refresh the patch set.  thanks
2020-11-17 15:58:06 <dalias> mps, thanks for reporting status on MT-fork and reminder about reallocarray. as ariadne noted recallocarray is useless & rejected
2020-11-17 16:05:00 <mps> dalias: it is my pleasure to help even with a such small 'things' :)
2020-11-17 19:10:26 <ikke> Hmm, xz: applet not found
2020-11-17 19:11:08 <ikke> seems like the symlink still exists, is that possible?
2020-11-17 19:12:57 <ikke> Yup: /usr/bin/xz -> /bin/busybox
2020-11-17 19:14:13 <ikke> I guess these symlinks are not cleaned up
2020-11-17 19:14:18 <ikke> after the applet is disabled
2020-11-17 19:17:42 <dalias> :/
2020-11-17 19:17:49 <dalias> why was applet disabled?
2020-11-17 19:18:05 <dalias> was it moved to -extras ?
2020-11-17 19:18:07 <ikke> because it was useless
2020-11-17 19:18:14 <ikke> it does nothing more than unxz
2020-11-17 19:18:18 <dalias> oh
2020-11-17 19:18:20 <dalias> :/
2020-11-17 19:20:08 <ikke> 7767013f47e21ddefbcff604572e2eb3105746b4
2020-11-17 20:46:27 <artok> does anyone use some gitlab cli tool ?
2020-11-17 20:46:43 <ikke> artok: not actively
2020-11-17 20:46:45 <artok> I'm just losing my nerves with that web ui
2020-11-17 20:46:47 <ikke> but `lab` exists
2020-11-17 20:47:02 <ikke> and for merge requests, maxice8 made some tools for that
2020-11-17 20:47:25 <ikke> https://pkgs.alpinelinux.org/package/edge/community/x86_64/mkmr
2020-11-17 20:48:25 <artok> thanks
2020-11-17 21:16:58 <maxice8> Ikke: ping
2020-11-17 21:17:03 <ikke> pong
2020-11-17 21:17:46 <maxice8> I need help with go
2020-11-17 21:18:06 <ikke> ok
2020-11-17 21:18:26 <ikke> (in the land of the blind, one-eye is king :P)
2020-11-17 21:19:49 <Cogitri> Heh
2020-11-17 21:20:19 <maxice8> nvm I found the problem
2020-11-17 21:22:09 <maxice8> Cogitri: turns out flatpaking your text editor has unintended consqueces
2020-11-17 21:28:33 <Cogitri> Ah yes
2020-11-17 21:29:03 <Cogitri> I currently use a Flatpak'ed VSCode and use the live remote extension to SSH into a podman container for development :D
2020-11-17 21:29:05 <ikke> maxice8: mkmr returned an error for me btw
2020-11-17 21:29:10 <ikke> possibly related to the branch name
2020-11-17 21:29:21 <Cogitri> Which sounds really hacky at first, but it's nice  having a reproducible dev env
2020-11-17 21:29:37 <maxice8> Also firefox 83 released :D
2020-11-17 21:30:05 <ikke> maxice8: https://tpaste.us/1JEB
2020-11-17 21:30:25 <mps> maxice8: yes, and it failed build for me :)
2020-11-17 21:30:42 <maxice8> mps: good luck with Firefox
2020-11-17 21:31:01 <mps> but we have Cogitri :)
2020-11-17 21:37:26 <maxice8> Ikke: what is your branch name ?
2020-11-17 21:37:27 <maxice8> does it have '/' ?
2020-11-17 21:37:31 <ikke> yes
2020-11-17 21:37:40 <maxice8> knew it
2020-11-17 21:37:48 <maxice8> more like deduced it but it was spot on
2020-11-17 21:37:49 <ikke> patch/3385-py3-faker-v1
2020-11-17 21:37:57 <maxice8> it stores the Internal ID of the merge request in cache
2020-11-17 21:38:08 <maxice8> so you don't need to do a network request to operate on the merge request
2020-11-17 21:38:37 <maxice8> but it only creates up to $XDG_CACHE_HOME/mkmr/$HOST/$USER/$REPO/branches
2020-11-17 21:38:55 <ikke> You need to normalize the branch name
2020-11-17 21:39:06 <ikke> s/\//_ or something like that :P
2020-11-17 21:39:06 <alpine-meetbot> ikke meant to say: patch_ or something like that :P3385-py3-faker-v1
2020-11-17 21:39:09 <ikke> lol
2020-11-17 21:42:04 <maxice8> yes I was thinking that
2020-11-17 21:44:46 <Cogitri> mps: Ah yes, I might be able to look into it at the weekend
2020-11-17 21:45:00 <ikke> 
ACTION just managed to get full go integration into emacs :P

2020-11-17 21:45:22 <Cogitri> I only have my laptop on me which has some defective sensor on the mainboard so  the CPU doesn't ever go over 800MHz :c
2020-11-17 21:45:36 <ikke> ugh
2020-11-17 21:45:44 <ikke> my o key is not working most of the time
2020-11-17 21:46:29 <ikke> (and by extension also the other keys on the same 'row'
2020-11-17 21:47:09 <ikke> anoying laptop issues
2020-11-17 21:47:16 <maxice8> @Cogitri isn't that related to BD_PROCHOT ?
2020-11-17 21:47:41 <Cogitri> Yes
2020-11-17 21:47:43 <maxice8> Once had an unrecognized charger for my DELL so DELL decided, f you let's set BD_PROCHOT and no CPU goes over 800mhz
2020-11-17 21:47:51 <maxice8> you can use wsmr  to change the bit
2020-11-17 21:47:54 <maxice8> modprobe msr
2020-11-17 21:48:01 <Cogitri> Yeah, but my HP does that for literally any charger
2020-11-17 21:48:03 <ikke> oof
2020-11-17 21:48:09 <Cogitri> And the workaround doesn't work :c
2020-11-17 21:48:12 <ikke> Haven't experienced that
2020-11-17 21:48:24 <maxice8> used wsmr -a ?
2020-11-17 21:48:43 <Cogitri> So I guess I'll just have to live with it until I can switch this thing out with a XPS 17 2021 edition :s
2020-11-17 21:49:27 <Cogitri> I use this script: https://github.com/yyearth/turnoff-BD-PROCHOT/blob/master/bdprochot_off.sh
2020-11-17 21:52:41 <maxice8> huh
2020-11-17 21:54:08 <maxice8> that script seems so complicated
2020-11-17 21:54:39 <maxice8> I just wrmsr -a 0x1FC 0
2020-11-18 00:25:37 <halosghost> dalias: any insight from that log?
2020-11-18 00:26:13 <dalias> halosghost, where is it?
2020-11-18 00:26:31 <halosghost> dalias: https://0x0.st/i51y.txt
2020-11-18 00:26:35 <dalias> oh found it
2020-11-18 00:27:38 <dalias> do you have the part leading up to it including the link command line?
2020-11-18 00:28:03 <halosghost> I can give you the full command if you'd like; give me a sec to boot up the pbp
2020-11-18 00:28:16 <dalias> looks like it's missing -lncursesw or whatever
2020-11-18 00:28:26 <halosghost> it's not missing the -l :)
2020-11-18 00:29:01 <halosghost> at least, it shouldn't be :)
2020-11-18 00:31:40 <dalias> is it possible that someone put the -lncursesw *before* $(OBJS) or whatever (wrong but happens to work with dynamic linking so some ppl do this...)
2020-11-18 00:32:19 <halosghost> dalias: I've made that mistake before, but I actually tried moving it to the end of the command before asking here :)
2020-11-18 00:32:34 <dalias> :-p
2020-11-18 00:33:37 <Hello71> "happens to work with dynamic linking" (unless --as-needed)?
2020-11-18 00:36:23 <halosghost> dalias: https://0x0.st/i5pF.txt
2020-11-18 00:36:47 <halosghost> WAIT
2020-11-18 00:36:50 <halosghost> ffs
2020-11-18 00:36:51 <halosghost> one sec
2020-11-18 00:37:05 <dalias> there's no -l
2020-11-18 00:37:47 <halosghost> WHY
2020-11-18 00:37:51 <halosghost> it's right there in my makefile ):
2020-11-18 00:37:54 <halosghost> 
ACTION digs in

2020-11-18 00:38:00 <halosghost> dalias: thank you for helping reveal my silly to me
2020-11-18 00:38:14 <dalias> :)
2020-11-18 00:38:48 <halosghost> hah
2020-11-18 00:38:50 <halosghost> got it
2020-11-18 00:38:52 <halosghost> fascinating
2020-11-18 00:39:31 <dalias> ?
2020-11-18 00:41:10 <halosghost> dalias: I'm used to bash as the interpreter for makefiles (even though I'm slowly moving my things to posix)
2020-11-18 00:41:22 <halosghost> dalias: I had $(pkg-config… instead of $(shell pkg-config…
2020-11-18 00:41:23 <halosghost> dalias: :)
2020-11-18 00:42:56 <Hello71> that's unrelated to bash
2020-11-18 00:44:18 <dalias> yeah $(foo is just a variable expansion of foo
2020-11-18 00:44:20 <dalias> in make
2020-11-18 00:44:43 <dalias> if you want to get the output of pkg-config for make to use, you need $(shell pkg-config ...)
2020-11-18 00:45:09 <dalias> if you just want it as part of a command, you can use $$(pkg-config ...) or (less confusing imo) `pkg-config ...`
2020-11-18 00:46:20 <halosghost> 🤷
2020-11-18 00:46:23 <halosghost> regardless, I have my fix
2020-11-18 00:46:25 <halosghost> dalias: thank you :)
2020-11-18 00:51:30 <Hello71> dalias: as long as you don't want any quotes
2020-11-18 00:56:30 <dalias> with pkg-config you certainly don't
2020-11-18 00:56:36 <dalias> the output needs to be word-expanded
2020-11-18 01:24:08 <maxice8> Oh fancy, vsc has a new python language server
2020-11-18 01:26:27 <Hello71> yeah
2020-11-18 01:26:49 <Hello71> i'm just saying good luck successfully escaping " in ` in shell in make
2020-11-18 01:27:11 <Hello71> hm, actually, make doesn't parse \ does it
2020-11-18 01:28:28 <Hello71> except at eol
2020-11-18 01:48:18 <halosghost> I just use $() anywa
2020-11-18 01:50:22 <halosghost> s/$/y/
2020-11-18 01:50:22 <alpine-meetbot> halosghost meant to say: I just use y() anywa
2020-11-18 01:50:36 <halosghost> alpine-meetbot: so, you don't understand anchors then, eh?
2020-11-18 02:07:37 <dalias> :-p
2020-11-18 04:09:50 <orbea> hypothetically if I was going to install alpine and then send patches, would this be a problem? https://github.com/gentoo/gentoo/pull/18307#event-4008388143
2020-11-18 04:10:39 <orbea> after that, I really rather know before I try...
2020-11-18 04:44:34 <insep_> no
2020-11-18 04:44:47 <orbea> cool, thanks
2020-11-18 04:46:38 <insep_> not sure what problem do you have with this, it's just "Signed-off-by: Name <email@ma.il>" in commit messages, besides real name requirement
2020-11-18 04:46:52 <insep_> same procedure for contributing to linux kernel
2020-11-18 04:47:05 <insep_> it's not like cla
2020-11-18 04:51:45 <orbea> privacy concerns basically
2020-11-18 04:53:29 <insep_> just insert fake name, nobody is going to check it anyways ;D
2020-11-18 04:53:42 <orbea> half tempted :P
2020-11-18 04:54:13 <dalias> exactly
2020-11-18 04:54:23 <dalias> the right approach to an idiotic policy like this is just making up a name
2020-11-18 04:55:42 <orbea> I think the basic problem is now that I discussed it with gentoo devs, it would be an obvious lie :P
2020-11-18 04:55:57 <dalias> :)
2020-11-18 04:56:30 <dalias> yeah if your goal is to contribute without gratuitous friction from their bad policy, arguing first kinda blows that
2020-11-18 04:56:49 <dalias> altho you could always just say fine and give them a name and challenge them to call your bluff
2020-11-18 04:57:04 <dalias> then challenge them to define what constitutes a "real" name
2020-11-18 04:57:14 <orbea> I have more or less
2020-11-18 04:57:15 <dalias> which will get them in some deep shit
2020-11-18 04:57:43 <orbea> there are also people who could be put in serious harm if they are effectively doxxed online
2020-11-18 04:57:48 <dalias> yes
2020-11-18 04:58:31 <orbea> my feeling is they are not completely opposed to changing it, but its not going to be an instant decision
2020-11-18 04:58:58 <dalias> any policy around real names is going to have personal safety issues, legal risk issues for people in jurisdictions where they shouldn't be contributing to software of a particular type, transphobic issues, etc
2020-11-18 04:59:23 <orbea> yea, I didnt even think of the last one...
2020-11-18 04:59:28 <orbea> but its a good point
2020-11-18 06:46:29 <fabled> ikke, seems the workaround patch did not apply cleanly for libreoffice 7.0.2 (as in some lines got added to wrong places). it needs rebasing
2020-11-18 06:48:39 <ikke> fabled: Right, I did run into 1 conflict, but did not verify the other results
2020-11-18 06:48:58 <ikke> note that J0WI already had an MR with more (and better) changes, so I closed my MR
2020-11-18 06:49:11 <ikke> including just disabling java for 32-bits arches
2020-11-18 08:24:33 <insep_> remember i said here that rc-status segfaults on armv7? it just happened again and gdb says that something passes 2147483647 as a third argument to memchr
2020-11-18 08:37:34 <ikke> insep_: do you have a backtrace?
2020-11-18 08:38:46 <insep_> hold on i need to set up all the wires again
2020-11-18 08:39:21 <ikke> Not that I'm able to fix / diagnose it, but I guess it would be good to open an issue with the details
2020-11-18 08:39:28 <ikke> and in most cases, a backtrace would be helpful
2020-11-18 08:39:47 <ikke> make sure to install relevant -dbg packages (for example, musl-dbg)
2020-11-18 08:40:32 <insep_> i have had musl-dbg and iirc 'where' outputed only musl and something about corrupted stack frame
2020-11-18 08:57:38 <insep_> it doesn't happen after reboot, i guess that has something to do with time jumps
2020-11-18 09:23:08 <ncopa> morning
2020-11-18 09:27:10 <Cogitri> Morning
2020-11-18 09:27:22 <m242> hello
2020-11-18 09:28:10 <ikke> Good day
2020-11-18 10:47:56 <Ariadne> insep_: a full backtrace would be helpful if you can recreate this.  2147483647 is -1 AFAIK when cast to signed int
2020-11-18 10:48:10 <Ariadne> (on ilp32 archs like armv7 anyway)
2020-11-18 10:49:39 <Ariadne> or perhaps it is not
2020-11-18 10:49:50 <Ariadne> well eithr way, it is probably an overflow
2020-11-18 10:59:01 <ikke> Ariadne: Any tips how to get a full backtrace?
2020-11-18 10:59:35 <Ariadne> threads apply all bt full
2020-11-18 12:29:36 <insep_> Ariadne: if my theory is correct, you can try to recreate this too. boot an armv7 machine with year set to 2000, let services start, set year to 2020 and run rc-status
2020-11-18 12:30:23 <Ariadne> that does not sound related to arm per se
2020-11-18 12:33:26 <insep_> i had it only on cubieboard :D
2020-11-18 12:38:33 <ikke> probably because it has no RTC?
2020-11-18 12:39:11 <insep_> yes
2020-11-18 14:01:45 <Ariadne> well anyway, bugs like that are one reason why "do something about openrc suckage" is on my eventual list of things to finally address
2020-11-18 14:02:27 <ikke> That list must be large by now :)
2020-11-18 14:02:27 <Ariadne> we got a good 12 years out of openrc, but we can do way better than openrc :P
2020-11-18 14:03:01 <Ariadne> my main hit list for 3.14 is basically
2020-11-18 14:03:03 <Ariadne> - FRR
2020-11-18 14:03:10 <Ariadne> - rust in the bootstrap path
2020-11-18 14:03:17 <Ariadne> - make sure ghc is bootstrapped everywhere too
2020-11-18 14:03:46 <Ariadne> - finish up the utmps work
2020-11-18 14:04:12 <Ariadne> but yes, "do something about openrc" is just a little bit down from there
2020-11-18 14:04:33 <Ariadne> and "do something about openrc" does not mean "systemd", don't worry about that
2020-11-18 14:04:34 <Ariadne> :P
2020-11-18 14:06:36 <mps> if it is runit I'm ready to help :)
2020-11-18 14:06:52 <wsinatra> what init system are you inclined to replace it with?
2020-11-18 14:07:52 <mps> though I know BDFL is not yet ready to accept runit as init 1
2020-11-18 14:08:10 <Ariadne> mps: likely something built around s6 with openrc compatibility
2020-11-18 14:08:31 <Ariadne> i'm not willing to accept runit as init 1 either (:
2020-11-18 14:08:39 <mps> I'm not sure is the s6 is good as init 1
2020-11-18 14:10:15 <Ariadne> the s6 can be made to be good as init 1 (:
2020-11-18 14:11:45 <Ariadne> but not quite ready to demo what i have in mind
2020-11-18 14:11:50 <mps> and runit is already ready for this
2020-11-18 14:12:31 <Ariadne> well, what i have in mind should be sufficiently modular to allow using either your choice of s6 or runit
2020-11-18 14:13:11 <Ariadne> basically a 'supervision tree compiler'
2020-11-18 14:13:31 <Ariadne> and some nice frontend programs to make it friendly
2020-11-18 14:13:51 <Ariadne> we want it, ideally, to feel similar to openrc
2020-11-18 14:14:06 <mps> I have a lot of 'good' ideas in mind but ... :)
2020-11-18 14:14:17 <insep_> will there be inittab compatibility?
2020-11-18 14:14:52 <Ariadne> yes, that is how we would provide openrc compatibility basically
2020-11-18 14:15:11 <insep_> \o/
2020-11-18 14:15:28 <insep_> not that much scripts will need to be rewritten then
2020-11-18 14:16:19 <Ariadne> anyway, s6 and runit consume the same style of supervision tree, so either can be supported easily enough
2020-11-18 14:16:33 <Ariadne> with that said, i can't speak for the quality of busybox runit
2020-11-18 14:17:06 <Ariadne> the quality of things in busybox varies from applet to applet, with some applets being the best available implementation, and others being complete shit
2020-11-18 14:17:12 <mps> well, no bb but runit apk
2020-11-18 14:18:04 <insep_> i thought you said busybox apk
2020-11-18 14:18:22 <insep_> considering that they implement dpkg and rpm, that's quite possible
2020-11-18 14:18:36 <Ariadne> terrifying
2020-11-18 14:20:31 <mps> I told earlier here that I made debian router with runit as init 1, on ro root fs, hacked it a little for this. nearly 20 years ago
2020-11-18 14:21:25 <Ariadne> anyway i have no objection to allowing the sysadmin to choose runit over s6
2020-11-18 14:21:25 <mps> router was used for wide area radio network and worked very well
2020-11-18 14:21:42 <Ariadne> as far as service management goes, it's six of one, half dozen of the other
2020-11-18 14:22:24 <mps> and I use runit about 20 years for different services which needs supervision
2020-11-18 14:22:43 <mps> ime, works fine
2020-11-18 14:23:03 <Ariadne> however there are features s6 can be convinced to provide.  i doubt we will have luck convincing runit developer to add seccomp support or VRFs etc
2020-11-18 14:23:32 <Ariadne> basically, s6 is forward-looking, while runit is in maintenance mode
2020-11-18 14:23:56 <Ariadne> much like openrc (no real activity in over a year)
2020-11-18 14:23:58 <mps> yes, that is main issue with runit, and missing poll(3)
2020-11-18 14:24:37 <Ariadne> trading one poorly maintained software that does not fully fit our needs for another poorly maintained software that does not fully fit our needs is not ideal
2020-11-18 14:25:48 <Ariadne> but no objection to a "runit mode"
2020-11-18 14:26:03 <Ariadne> with the caveat that anything runit doesn't support won't be supported there
2020-11-18 14:26:06 <Ariadne> :)
2020-11-18 14:27:29 <mps> ok
2020-11-18 14:29:42 <Ariadne> and openrc itself is primarily only interested in gentoo usecases
2020-11-18 14:31:14 <Ariadne> insep_: so, if we boot a system that is 32-bit, and set the openrc /run/openrc mtimes to 2000, it should crash on rc-status?
2020-11-18 14:31:18 <Cogitri> Ariadne: Isn't runit dead?
2020-11-18 14:31:23 <Ariadne> Cogitri: yes
2020-11-18 14:31:50 <Ariadne> Cogitri: but if mps likes retrocomputing and it is essentially zero effort to support, may as well let him retrocompute
2020-11-18 14:32:02 <Cogitri> Ah
2020-11-18 14:32:55 <Ariadne> i mean, that's a bit mean.  if you already are familiar with a supervisor, and it fits your needs already, why learn a new one
2020-11-18 14:33:11 <insep_> Ariadne: as long as you'll make system/openrc think that there's a huge time jump
2020-11-18 14:33:21 <Ariadne> insep_: yes
2020-11-18 14:33:34 <Ariadne> insep_: that's what setting the mtime to 2000 would do :)
2020-11-18 14:34:25 <Ariadne> nanabozho:~$ touch -t 200001010000.00 moo
2020-11-18 14:34:26 <Ariadne> -rwxr-xr-x 1 kaniini kaniini 19K Jan  1  2000 moo
2020-11-18 14:34:26 <Ariadne> nanabozho:~$ ls -alh moo
2020-11-18 14:34:30 <Ariadne> like so :)
2020-11-18 14:34:33 <insep_> not familiar with openrc internals
2020-11-18 14:35:25 <insep_> and i use windows as daily driver
2020-11-18 14:35:27 <Ariadne> anyway, find /run/openrc -exec 'touch -t 200001010000.00 \{};'
2020-11-18 14:35:28 <Ariadne> :)
2020-11-18 14:35:55 <Ariadne> i'll set up an alpine i386 in a moment
2020-11-18 14:40:45 <skarnet> mps: s6 can work as pid1 and it's as good a pid1 as you'll ever get, better than bb sysvinit (which can still wait for 1s before reaping zombies in some cases), and better than runit (which you have to adapt your shutdown sequence to, and if you happen to kill the scanner then your machine reboots no matter what)
2020-11-18 14:41:55 <skarnet> but in any case 'what pid1 to use' is, or *should be*, a completely orthogonal question to 'what service manager to use'
2020-11-18 14:42:11 <skarnet> (and changing pid1s is much simpler)
2020-11-18 14:50:07 <mps> skarnet: I'm talking from my experience and have to add that I never tried s6 as pid1 (init 1) so don't take my words as 'offensive' to your work
2020-11-18 14:57:25 <Ariadne> anyway, my basic idea is "read in a bunch of service descriptions from various sources, generate supervision tree"
2020-11-18 14:57:41 <Ariadne> skarnet is i think working on a similar concept
2020-11-18 14:57:43 <Ariadne> already
2020-11-18 15:01:42 <mps> Ariadne: forgot to tell: please do not waste your (or anyone else) time on runit if it is 'only for me'
2020-11-18 15:02:30 <mps> I can adapt to whatever is chosen (except systemd)
2020-11-18 15:03:36 <mps> but I think we should ask void linux people what was their reason to choose runit, and their experience
2020-11-18 15:04:37 <Ariadne> well a key thing here is
2020-11-18 15:04:44 <Ariadne> skarnet is already an alpine maintainer
2020-11-18 15:05:12 <Ariadne> xtraeme probably went with runit because he already knew it
2020-11-18 15:21:39 <skarnet> Ariadne: well s6-rc already works like "read in a bunch of service descriptions from various sources, generate supervision tree", the interface is the thing you don't like
2020-11-18 15:22:41 <skarnet> the mechanism is already there, just needs to be refined with additional requirements (and the next version, which I'm currently working on, will have hooks for external events, e.g. from a network manager or device manager)
2020-11-18 15:23:33 <skarnet> also, the utmps package for Alpine is ready, now yall just need to link stuff against -lutmps
2020-11-18 15:23:46 <skarnet> and it will dtrt
2020-11-18 15:25:19 <skarnet> (also patch software to #include <utmps/utmpx.h> instead of <utmpx.h> if the Alpine policy decision is really 'utmpx.h belongs to musl-dev and utmps should not overwrite it')
2020-11-18 15:28:44 <Ariadne> yes, that is what i plan to finish up on 3.14
2020-11-18 15:40:23 <dalias> shouldn't it just -L/usr/include/utmps rather than patching source ?
2020-11-18 15:40:42 <dalias> in the pkg-config or equivalent (likely just an apkbuild recipe) for utmps
2020-11-18 15:46:47 <skarnet> -I, but yeah, that works too
2020-11-18 15:52:57 <dalias> erm yeah sorry :)
2020-11-18 15:54:13 <dalias> i think it's a good idea to keep it in /usr/include/utmps for the sake of users compiling their own stuff
2020-11-18 15:55:03 <dalias> if they didn't -lutmps but got the utmps version of utmpx.h, then their binary would have mismatched ABI with the (stub) utmp functions in musl
2020-11-18 15:55:15 <dalias> and if they were ever changed in musl to do something, this would actually matter
2020-11-18 15:55:20 <skarnet> yeah
2020-11-18 15:56:05 <dalias> it's likely that users compiling their own stuff don't even care whether it does utmp and just want static linking or nothing-dynamic-but-musl so it's portable to other musl-based systems
2020-11-18 15:56:37 <dalias> so this seems like a common thing to happen for anything they build that happens to have utmp support in it
2020-11-18 15:56:53 <skarnet> well if they build against utmps and they run on a machine without the utmps daemon, then the utmp calls will do nothing, just like with regular musl :P
2020-11-18 15:57:10 <dalias> right, if they static link it
2020-11-18 15:57:26 <dalias> i was thinking about the dynamic linking case more
2020-11-18 15:57:41 <skarnet> dynamic linking was a mistake :P
2020-11-18 15:57:42 <dalias> the abi mismatch doesn't really matter with static linking as long as the version of musl at link-time has stubs
2020-11-18 15:57:51 <Ariadne> yes, we are using -I/usr/include/utmps
2020-11-18 15:58:05 <dalias> rcombs is going to have it more interesting :)
2020-11-18 15:58:29 <Ariadne> who?
2020-11-18 16:02:12 <dalias> on #musl
2020-11-18 16:04:22 <Ariadne> ah
2020-11-18 16:07:18 <insep_> skarnet: let's say you want to design a distro, would you keep absolutely everything statically linked, including libc and gui libs?
2020-11-18 16:10:14 <Ariadne> there's plenty of distros which do that (:
2020-11-18 16:18:26 <skarnet> insep_: you really don't need to use an obvious joke (even if it has, like all good jokes, a grain of truth) to try and summon an old, overdone, and useless discussion in which you're going to try and make me the bad guy. You really don't need to do this.
2020-11-18 16:20:21 <insep_> that was i serious question
2020-11-18 16:20:25 <insep_> s/i /a /g
2020-11-18 16:20:25 <alpine-meetbot> insep_ meant to say: that was a serious question
2020-11-18 16:20:51 <Ariadne> anyway static linked gui lib is architecturally impossible
2020-11-18 16:21:07 <Ariadne> qt uses opengl to draw
2020-11-18 16:21:11 <Ariadne> mesa uses dlopen
2020-11-18 16:26:23 <skarnet> my serious answer is: I don't want to design a distro, it's waaay too much work :P
2020-11-18 16:26:54 <dalias> :)
2020-11-18 16:27:02 <dalias> why does a gui lib need gl?
2020-11-18 16:27:04 <dalias> *ducks*
2020-11-18 16:27:19 <skarnet> gl stands for 'gui lib', obviously
2020-11-18 16:29:01 <dalias> IME you can do just fine with nothing but XImage, XPixmap, and a couple basic fill and line primitives
2020-11-18 16:29:58 <dalias> and you don't even need all those, they just make it more efficient
2020-11-18 16:31:31 <insep_> 1) there are cases where you have a lot of stuff on one screen and using software compositing slows down everything 2) muh animations
2020-11-18 16:34:38 <Ariadne> idk why Qt went that direction, considering QPainter was already a very fast software rasterizer
2020-11-18 16:35:02 <dalias> there's no technical motivation for going that way. it's just "everyone else is doing it"
2020-11-18 16:35:11 <Ariadne> yes, basically
2020-11-18 16:35:45 <insep_> i've heard that a lot of kirigami cards make app lag and i can confirm that :P
2020-11-18 16:36:02 <dalias> insep_, if "lots of stuff" means other apps, it's up to the display server/windowing system whether it wants to use compositing to move them. app doesn't have to care.
2020-11-18 16:39:34 <insep_> lots of stuff == lots of shapes drawn
2020-11-18 16:39:50 <dalias> if it's contents within the app window, they're just doing it wrong; my slowass laptop can do fullscreen video entirely in software with ~25% cpu
2020-11-18 16:39:50 <insep_> in the same app
2020-11-18 16:40:39 <dalias> yeah it makes sense to use gl *in a particular app* if its model is right for that application's *content*
2020-11-18 16:40:44 <dalias> it doesn't make sense to use it for ui elements
2020-11-18 16:43:53 <insep_> phones are even slower
2020-11-18 16:44:55 <dalias> the point is that video is orders of magnitude more demanding than ui elements
2020-11-18 16:47:23 <insep_> one could also say that contents of a video is precalculated, but that depends on a codec probably
2020-11-18 16:48:10 <dalias> the calculations for ui elements are trivial
2020-11-18 18:16:58 <maxice8> mkmr 0.0.34 should fix the issue, Ikke
2020-11-18 18:31:35 <maxice8> \/ are treated as -
2020-11-18 18:42:39 <ikke> Thanks, saw your response to the issue
2020-11-19 03:25:16 <craftyguy> gnome-disk-utility needs udisks2 in order for disks to show up (in my testing, on postmarketOS...), udisks2-dev is in makedepends, but it doesn't seem to show up as an implicit dependency
2020-11-19 03:25:57 <craftyguy> I guess something isn't happening to trigger abuild(?) to pick it up?
2020-11-19 03:32:43 <insep_> it does pull udisks2-libs which are just libs, but daemon itself won't get pulled
2020-11-19 03:33:11 <insep_> udisks2 gets pulled by gnome meta package though
2020-11-19 03:33:27 <insep_> (cc: Cogitri i guess)
2020-11-19 05:18:34 <maxice8> Seems like any udisks2 consumer that uses udisks_client requires the dbus /org/freedesktop/UDisks2/Manager service which calls usr/libexec/udisks2/udiskd
2020-11-19 05:22:13 <maxice8> !14745
2020-11-19 05:28:32 <wener[m]> ncopa: wow, I see you working in the k0s, is there any future plan about k0s? any integration for alpine ?
2020-11-19 05:47:38 <ikke> wener[m]: what kind of integration are you thinking of?
2020-11-19 05:48:38 <wener[m]> Is there any relationship between k0s and alpine ?
2020-11-19 05:50:16 <ikke> No direct relationship
2020-11-19 05:50:41 <ikke> But it would be just a package you could install
2020-11-19 05:51:42 <wener[m]> Dose this will affect the alpine's dev ? I thought the active alpine dev only several peoples.
2020-11-19 05:52:18 <wener[m]> I'm a heavy k3s user, but there is suse and rancher behind k3s.
2020-11-19 05:53:18 <ikke> This is backed by mirantis, ncopa's employer
2020-11-19 05:53:56 <wener[m]> Soga!!! 😄
2020-11-19 05:55:34 <ikke> ..?
2020-11-19 05:57:17 <wener[m]> I mean understand
2020-11-19 06:15:04 <ikke> strange, curl can fetch youtube-dl. but abuild fetch not
2020-11-19 06:21:02 <detha> Youtube must have rubbed off on it. You can only fetch it if you're in the right region, with the right User-Agent
2020-11-19 06:23:24 <ikke> abuild fetch uses curl, but probably with a custom user agent
2020-11-19 06:25:49 <ikke> Not even
2020-11-19 06:27:43 <detha> there's a redirect in there
2020-11-19 06:28:06 <detha> 2020.11.18 302 2020.11.19
2020-11-19 06:30:47 <ikke> execve("/usr/bin/curl", ["curl", "-L", "-f", "-o", "/var/cache/distfiles/youtube-dl-2020.11.18.tar.gz.part", "https://youtube-dl.org/downloads/latest/youtube-dl-2020.11.18.tar.gz"]
2020-11-19 06:31:00 <ikke> that's the curl invocation
2020-11-19 06:31:59 <detha> theory says that should work
2020-11-19 06:32:24 <ikke> If I run that exact command I get a 404 as well
2020-11-19 06:33:59 <ikke> hmm, strange
2020-11-19 06:34:04 <ikke> -f causes the 404
2020-11-19 06:34:22 <detha> le what? < Server: Apache/2.2.15 (CentOS)
2020-11-19 06:34:23 <detha> < Location: https://github.com/ytdl-org/youtube-dl/releases/download/2020.11.19/youtube-dl-2020.11.18.tar.gz
2020-11-19 06:35:38 <detha> anyway, latest appears to be 2020.11.19, which works
2020-11-19 06:36:17 <ikke> yes, I see
2020-11-19 06:38:24 <craftyguy> maxice8: I filed this right after my comment, but yours works too https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14743
2020-11-19 06:43:34 <maxice8> nice
2020-11-19 06:45:32 <craftyguy> Your patch has a better apkbuild comment :P
2020-11-19 06:47:55 <ikke> detha: heh, now I understand, the file returned is a text file with Not found
2020-11-19 06:48:04 <ikke> so -f just exposes that status code
2020-11-19 06:48:40 <detha> ikke: s/latest/$pkgver/ in the APKBUILD url
2020-11-19 06:48:40 <alpine-meetbot> detha thinks ikke meant to say: execve("/usr/bin/curl", ["curl", "-L", "-f", "-o", "/var/cache/distfiles/youtube-dl-2020.11.18.tar.gz.part", "https://youtube-dl.org/downloads/$pkgver/youtube-dl-2020.11.18.tar.gz"]
2020-11-19 06:49:24 <detha> but I see what happens yes
2020-11-19 06:51:20 <detha> 'latest' is a redirect on the server to whatever date, and combining hardcoded filename with latest leads to surprises
2020-11-19 06:51:37 <ikke> yes, that works indeed
2020-11-19 06:54:59 <ikke> detha: pushed a fix
2020-11-19 07:30:27 <ncopa> good morning!
2020-11-19 07:33:28 <m242> \o
2020-11-19 07:34:17 <ncopa> wener[m]: there is no relationship between alpine and k0s other than i work on both :)
2020-11-19 07:36:15 <m242> What is k0s ?
2020-11-19 07:36:27 <m242> https://github.com/k0sproject/k0s ?
2020-11-19 07:36:36 <ikke> yes
2020-11-19 07:37:16 <m242> ^-^
2020-11-19 07:37:24 <ikke> ncopa: are the provided binaries built fully static?
2020-11-19 07:39:00 <ncopa> yes
2020-11-19 07:39:36 <ikke> aha
2020-11-19 07:40:21 <ncopa> and the parts that requires CGO (like kine) uses musl libc
2020-11-19 07:41:10 <ncopa> i wonder how we should package it in alpine
2020-11-19 07:41:59 <ncopa> might be a better idea to instead of bundle all the binaries in k0s, add kube-* containerd and runc binaries as package dependencies
2020-11-19 07:42:59 <ncopa> that was my original idea at least
2020-11-19 07:43:29 <ikke> I think for an Alpine package that would make sense
2020-11-19 07:45:30 <ncopa> ok, I'll work on that. i think it does not currently work, due to a regression in k0s which hardcodes the path to embedded bins
2020-11-19 07:45:41 <ncopa> but it is easily fixed
2020-11-19 07:53:38 <ncopa> looks like zabbix fails to build on 32 bit arches on 3.12-stable
2020-11-19 07:53:43 <ikke> yes
2020-11-19 07:53:55 <ikke> I think edge had a patch for that
2020-11-19 07:54:44 <Newbyte> hi, I understand you might be busy with Alpine 3.13, but could someone take a look at !14447?
2020-11-19 07:54:48 <ikke> The patch was for 5.2.0, but seems like the same issue
2020-11-19 08:13:51 <fcolista> nice try to have a working k8s running on Alpine: https://t.co/X9qAWaSPCj?amp=1
2020-11-19 08:14:04 <fcolista> :)
2020-11-19 08:17:27 <wener[m]> ncopa: thanks for clarify, I use k3s a lot under alpine, hope there is a reason or compare between k0s and k3s. Looking forward the k0s package.
2020-11-19 08:18:59 <wener[m]> but containerd, emm, is hard to kill, so I use docker instead, also wonder why choose calico instead flannel
2020-11-19 08:25:51 <Ariadne> yes we will be happy to support k3s and even microk8s if somebody packages them
2020-11-19 09:13:17 <Newbyte> hey again, the automatic merge set for !14447 was cancelled due to changes in the target branch. I rebased, could you put auto merge on it again?
2020-11-19 09:14:00 <ikke> ncopa: zabbix on 3.12 should be fixed now
2020-11-19 09:14:35 <ikke> done
2020-11-19 09:14:39 <ikke> Newbyte: ^
2020-11-19 09:14:58 <Newbyte> thank you!
2020-11-19 09:19:13 <ncopa> wener[m]: k0s was inspired by k3s. I think one of the significant features of k0s is that it supports an isolated control plane, without any workers at all.
2020-11-19 09:19:23 <ncopa> re calico. i have no clue tbh :)
2020-11-19 10:05:42 <ncopa> wener[m]: I asked around. calico supports windows and it also supports network policies out of the box
2020-11-19 10:06:41 <ncopa> ugh
2020-11-19 10:07:02 <ncopa> those 3rd party modules, xtables-addons and rtpengine fails with 5.4.78
2020-11-19 10:46:11 <obarun> https://framagit.org/Obarun/66/-/commit/64a6ffe3ec555c2e8c9735d458320b400b9c0e06
2020-11-19 10:46:20 <obarun> oops, sorry wrong channel
2020-11-19 11:19:05 <andypost[m]> Looks oha !14737 fails on builders because like "tree" has networking issue
2020-11-19 12:04:05 <PureTryOut[m]2> Can some devs give their opinion on !14360 please? Preferably on the MR itself, I don't think the author is currently on IRC
2020-11-19 12:06:00 <ikke> No, they are not
2020-11-19 12:14:08 <mps> who is the author?
2020-11-19 12:16:59 <mps> ah, maribu (who is off-line)
2020-11-19 12:17:55 <mps> huh, looks like he copied contributors from Arch linux :)
2020-11-19 12:19:54 <ikke> 1heh
2020-11-19 12:48:08 <insep_> do new commits still get accepted to 3.13? if yes, would love to see this mr being in 3.13 :)
2020-11-19 12:48:21 <ikke> Yes
2020-11-19 12:48:52 <ikke> 3.13 is currently still following master
2020-11-19 12:54:37 <insep_> \o/
2020-11-19 13:04:48 <Ariadne> PureTryOut[m]2: NAK
2020-11-19 13:05:50 <PureTryOut[m]2> nak?
2020-11-19 13:07:05 <ikke> Not ACK
2020-11-19 13:07:33 <mps> NACK
2020-11-19 13:07:38 <Ariadne> i explained the rationale.  we do not use that cross-toolchain to build arm-trusted-firmware
2020-11-19 13:07:48 <PureTryOut[m]2> Not yet
2020-11-19 13:07:52 <Ariadne> we will never do so
2020-11-19 13:07:56 <PureTryOut[m]2> Check the related MR, !6677
2020-11-19 13:08:10 <ncopa> do we (alpine) need arm-trusted-firmware in main?
2020-11-19 13:08:28 <Ariadne> we do not need the cross toolchain to enable rk3399 support
2020-11-19 13:08:31 <PureTryOut[m]2> If we want RockChip devices to be able to run on just a main repository yes
2020-11-19 13:08:36 <Ariadne> why?
2020-11-19 13:08:44 <PureTryOut[m]2> Please explain why we don't need cross toolchain for rk3399?
2020-11-19 13:08:56 <Ariadne> please explain why you believe it is necessary
2020-11-19 13:09:29 <PureTryOut[m]2> Well try that MR without that dep, it won't work. It builds an arm32 firmware for an aarch64 devices
2020-11-19 13:09:44 <mps> to build some cortex-m code (arm32) on aarch64
2020-11-19 13:09:44 <Ariadne> the aarch64 gcc is capable of producing arm32 code
2020-11-19 13:10:32 <mps> imo, ATF should be fixed by removing arm32 code
2020-11-19 13:10:43 <PureTryOut[m]2> mps checked this at some point with some arm-trusted-firmware devs, a cross-compiler was/is necessary to produce the 32-bit code for some of the cores on that chip, seemingly the cortex-m ones
2020-11-19 13:11:02 <Ariadne> why do we care about the cortex-m cores?
2020-11-19 13:11:04 <PureTryOut[m]2> That would be preferable yes but I don't see that happening
2020-11-19 13:11:11 <Ariadne> they can't boot linux, they do not have an MMU
2020-11-19 13:11:43 <mps> cortex-m is included in some (most?) arm64 chips
2020-11-19 13:11:47 <Ariadne> if postmarketOS wish to support rk3399, they can do so out of tree.
2020-11-19 13:12:00 <Ariadne> or ATF can be fixed correctly.
2020-11-19 13:12:15 <PureTryOut[m]2> This is not about postmarketOS
2020-11-19 13:12:21 <MartijnBraam> the issue isn't ARM32
2020-11-19 13:12:31 <Ariadne> or we can generate cross toolchains using the main/gcc APKBUILD
2020-11-19 13:12:35 <MartijnBraam> the issue is that the rk3399 needs the cortex-m core to do bootloader stuffs
2020-11-19 13:12:41 <mps> right solution for alpine would be to rip out cortex-m code from ATF
2020-11-19 13:13:08 <Ariadne> i'm fundamentally against that testing/gcc-cross-embedded packaging
2020-11-19 13:13:24 <PureTryOut[m]2> I'll be honest, it's a bit out of my league, MartijnBraam knows more about it. But afaik any rk3399 device will not boot without the arm-trusted-firmware stuff
2020-11-19 13:13:36 <Ariadne> any arm cpu will not boot without ATF
2020-11-19 13:13:54 <Ariadne> ATF is literally the bootrom that is started by the service processor (kinda like the Intel ME but simpler)
2020-11-19 13:14:23 <MartijnBraam> and that service processor is cortex-m, not sure how you're planning to rip that out...
2020-11-19 13:14:35 <MartijnBraam> I don't particularly care about gcc-cross-embedded, I just need an arm-none-eabi toolchain
2020-11-19 13:14:37 <Ariadne> i have no plans to rip it out
2020-11-19 13:14:40 <PureTryOut[m]2> Well yes that
2020-11-19 13:15:06 <PureTryOut[m]2> I guess the ripping out bit was in response to mps
2020-11-19 13:15:23 <Ariadne> anyway, the solution is to generate an arm-none-eabi capable toolchain, not to use that testing/gcc-cross-embedded thing
2020-11-19 13:16:05 <MartijnBraam> I don't particularly care about gcc-cross-embedded, I just need the arm-none-eabi toolchain and that one existed
2020-11-19 13:16:39 <Ariadne> i would rather hold on rk3399 until we can do this correctly
2020-11-19 13:17:24 <Ariadne> the correct way would be to implement multiarch and install the armv7 toolchain
2020-11-19 13:17:39 <Ariadne> and use the armv7 toolchain to build the arm32 components
2020-11-19 13:17:54 <Ariadne> but usually the service processor ROM is burned into the service processor silicon
2020-11-19 13:17:58 <PureTryOut[m]2> I started about gcc-cross-embedded because that existed yes. If there is some other way to do it, that's fine with me as well
2020-11-19 13:18:01 <Ariadne> are you saying on rk3399 it is not?
2020-11-19 13:19:00 <Ariadne> i think what mps is saying is that providing firmware for the SP is out of our scope, the board vendor should provide that firmware
2020-11-19 13:19:47 <Ariadne> because the AP should already be running by the time alpine is to be booted
2020-11-19 13:20:01 <MartijnBraam> well u-boot loads it
2020-11-19 13:20:16 <PureTryOut[m]2> In this case arm-trusted-firmware is loaded by u-boot, and u-boot is provided by Alpine
2020-11-19 13:20:18 <Ariadne> yes, but u-boot should be running on the AP, not the SP
2020-11-19 13:20:36 <Ariadne> yes, alpine provides a u-boot, which runs on the AP
2020-11-19 13:20:38 <Ariadne> not the SP
2020-11-19 13:21:18 <Ariadne> the way this normally works is:
2020-11-19 13:21:44 <insep_> and u-boot loads stuff to sp, a lot of socs do that scheme of letting bootloader load trustzone
2020-11-19 13:21:56 <Ariadne> system powers on -> service processor starts up, runs whatever is in bootrom -> service processor as a result initializes the application provider
2020-11-19 13:22:02 <Ariadne> s/provider/processor/
2020-11-19 13:22:02 <alpine-meetbot> Ariadne meant to say: system powers on -> service processor starts up, runs whatever is in bootrom -> service processor as a result initializes the application processor
2020-11-19 13:22:08 <Ariadne> AP does start trustzone
2020-11-19 13:22:23 <Ariadne> however, trustzone is not required to boot once the AP is up
2020-11-19 13:22:32 <Ariadne> and nothing in alpine uses trustzone
2020-11-19 13:22:36 <mps> yes
2020-11-19 13:22:37 <MartijnBraam> I'm sorry the rk3399 doesn't meet your expectations, does that means we shouldn't boot it?
2020-11-19 13:22:56 <insep_> trustzone provides psci
2020-11-19 13:23:05 <Ariadne> no, what i am asking is if rk3399 really needs the service processor firmware
2020-11-19 13:23:06 <insep_> and psci provides code for initializing other cores
2020-11-19 13:23:11 <insep_> is it dumb? yes
2020-11-19 13:23:34 <insep_> does it apply to all arm64 socs? yes, mostly
2020-11-19 13:24:03 <Ariadne> all of my arm hardware uses EFI which has already done all of that shit
2020-11-19 13:24:16 <Ariadne> i think i will move to drop support for all non-EFI aarch64 devices :)
2020-11-19 13:24:38 <MartijnBraam> thanks, appreciate it
2020-11-19 13:25:40 <insep_> i don't think phones and other comsumer-friendly sbcs will be getting proper efi any time soon
2020-11-19 13:25:45 <Ariadne> cool
2020-11-19 13:25:48 <Ariadne> i don't care about them
2020-11-19 13:26:33 <Ariadne> or, really i should rephrase
2020-11-19 13:26:44 <Ariadne> i don't care about them enough to see urgency in supporting rk3399
2020-11-19 13:27:07 <Ariadne> the only rk3399 device i have, the board itself provides the firmware
2020-11-19 13:27:23 <Ariadne> it's not EFI, but its still provided with the board
2020-11-19 13:27:35 <Ariadne> and it runs alpine just fine
2020-11-19 13:28:04 <Ariadne> so, rk3399 will wait until multiarch is implemented
2020-11-19 13:28:37 <Ariadne> and then we will use multiarch dependency (say: build-base:armv7, for example) to build the ATF for those devices where we must also supply the bootloader too
2020-11-19 13:28:53 <Ariadne> but the devices i have, the system has its own u-boot, and then it chainloads into ours
2020-11-19 13:29:01 <Ariadne> this is sane
2020-11-19 13:29:30 <Ariadne> (or the system has EFI in case of honeycomb, which is not sane, but still capable of booting alpine)
2020-11-19 13:33:14 <MartijnBraam> which honeycomb?
2020-11-19 13:33:40 <Ariadne> https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/
2020-11-19 13:33:56 <Ariadne> thats not rk3399, but i have an rk3399 chromebook
2020-11-19 13:34:05 <Ariadne> and it runs alpine just fine
2020-11-19 13:34:09 <MartijnBraam> ah nice, I thought about getting one of those honeycombs
2020-11-19 13:34:31 <Ariadne> i do know it is frustrating that rk3399 support is missing from our u-boot
2020-11-19 13:34:42 <Ariadne> i just think that we should solve this the correct way
2020-11-19 13:35:14 <Ariadne> moving marian's cross-gcc package to main means it becomes a defacto burden for the toolchain maintainers, no longer just marien
2020-11-19 13:35:19 <Ariadne> marian?
2020-11-19 13:35:37 <ikke> Marian, yes
2020-11-19 13:35:39 <Ariadne> that's why i am against it, we already have our hands full with gcc, llvm, etc
2020-11-19 13:35:47 <PureTryOut[m]2> I get that, and I basically agree. I'm just afraid that multiarch will take ages to get implemented and thus it'll take ages for the board to be supported
2020-11-19 13:35:58 <PureTryOut[m]2> The MR has already been open for months
2020-11-19 13:36:07 <Ariadne> afaik somebody is already chomping at the bit to make multiarch a thing
2020-11-19 13:36:14 <Ariadne> and the apk work was already done by yocto
2020-11-19 13:36:34 <Ariadne> so i wouldn't worry too much :)
2020-11-19 13:37:02 <Ariadne> if it does not happen by end of 3.14 release cycle, we can grant an exception at that time
2020-11-19 13:37:12 <MartijnBraam> but you do all the aarch64 stuffs for alpine?
2020-11-19 13:37:33 <Ariadne> no, thankfully there are multiple people doing arm stuff on alpine
2020-11-19 13:37:53 <MartijnBraam> because I haven't been able to find documentation on which boards actually work with the aarch64 images on the alpine site
2020-11-19 13:38:05 <MartijnBraam> apparently lx2k works
2020-11-19 13:38:22 <Ariadne> lx2k mostly works.  the 10G support does not work yet
2020-11-19 13:38:31 <Ariadne> which is a real bummer
2020-11-19 13:38:40 <MartijnBraam> yeah but not a deal breaker
2020-11-19 13:38:47 <Ariadne> the 1G does not work either
2020-11-19 13:38:58 <MartijnBraam> eeeh
2020-11-19 13:38:59 <Ariadne> i use a USB NIC right now
2020-11-19 13:39:10 <MartijnBraam> that is a major issue
2020-11-19 13:39:36 <Ariadne> linux 5.10 is supposed to have the LX2K driver fixes
2020-11-19 13:39:45 <Ariadne> so we will see how it goes
2020-11-19 13:40:07 <Ariadne> aarch64 also runs fine on mediatek and rk3399 chromebooks
2020-11-19 13:40:10 <MartijnBraam> I don't like hanging usb nics on the back of servers in a rack :P
2020-11-19 13:40:16 <Ariadne> yeah me neither
2020-11-19 13:40:25 <Ariadne> i have 3 in colo with 10G DAC cables connected
2020-11-19 13:40:30 <Ariadne> cant use them yet
2020-11-19 13:40:31 <Ariadne> :(
2020-11-19 13:41:01 <Ariadne> i tell you guys what
2020-11-19 13:41:13 <Ariadne> if you isolate the arm-none-eabi toolchain into its own APKBUILD
2020-11-19 13:41:16 <Ariadne> we can put that in main
2020-11-19 13:41:28 <Ariadne> i would be fine with that for now
2020-11-19 13:42:01 <Ariadne> that gets you a toolchain without saddling us with a bunch of technical debt to get that toolchain
2020-11-19 13:42:10 <Ariadne> how does it sound?
2020-11-19 13:42:28 <MartijnBraam> yeah the gcc-cross-embedded package is a bit complicated and has a lot of stuff we don't care for
2020-11-19 13:42:48 <MartijnBraam> I guess having only the arm-none-eabi toolchain should be enough
2020-11-19 13:44:47 <Ariadne> marian says newlib and stuff are also needed?
2020-11-19 13:45:51 <MartijnBraam> hmm I don't think so
2020-11-19 13:46:00 <Ariadne> ok
2020-11-19 13:46:23 <MartijnBraam> nope, only the compiler
2020-11-19 13:46:28 <Ariadne> if you isolate the arm toolchain and make a new MR putting it directly in main, i'll merge it
2020-11-19 13:46:47 <Ariadne> lets leave the rest of that pandora's box alone please :)
2020-11-19 13:46:51 <MartijnBraam> https://gitlab.com/postmarketOS/pmaports/-/blob/master/temp/arm-trusted-firmware/APKBUILD
2020-11-19 13:47:03 <Ariadne> sound good?
2020-11-19 13:47:09 <MartijnBraam> sure
2020-11-19 13:47:50 <Ariadne> for the record however
2020-11-19 13:48:07 <Ariadne> the aarch64 port traditionally has targeted big iron aarch64 with EFI
2020-11-19 13:48:17 <Ariadne> it will basically run great on any board like that
2020-11-19 13:48:46 <Ariadne> raspberry pi 4 support was also added but i dont know much about it
2020-11-19 13:48:53 <MartijnBraam> so far we're running alpine aarch64 on a lot of low powered devices, it works great
2020-11-19 13:49:00 <Ariadne> yeah
2020-11-19 13:49:06 <Ariadne> pmOS work in that area is impressive
2020-11-19 13:49:29 <MartijnBraam> but in case of rk3399 it's also laptops and other boards that aren't specifically phones/tablets. so it would be great if alpine also works for that
2020-11-19 13:49:37 <Ariadne> and no objection to supporting that work where we can,as long as the ask isn't "please maintain this mess of toolchains for 2 years"
2020-11-19 13:49:53 <Ariadne> i am sure you can understand
2020-11-19 13:50:55 <MartijnBraam> ofcourse
2020-11-19 13:51:22 <PureTryOut[m]2> Just to be clear, I/we don't specifically want the gcc-cross-embedded stuff, just an arm-non-eabi toolchain that allows us to build the required stuff to get it booting 😛
2020-11-19 13:51:33 <Ariadne> sure
2020-11-19 13:52:50 <Ariadne> great
2020-11-19 13:53:11 <Ariadne> well, as i said, in the interim if you all isolate the arm-none-eabi-gcc toolchain
2020-11-19 13:53:13 <PureTryOut[m]2> I very much want to run straight Alpine stable on my RockPro64's rather than postmarketOS edge 😉
2020-11-19 13:53:17 <Ariadne> we can merge that :P
2020-11-19 13:53:21 <PureTryOut[m]2> Yeah we'll take a shot at that
2020-11-19 13:59:33 <Ariadne> sounds great, lets do that instead of this.
2020-11-19 14:00:09 <Ariadne> MartijnBraam: and i definitely recommend the honeycomb.  it's not as fast as an ampere altra but it's also like 1/8 the cost
2020-11-19 14:00:47 <MartijnBraam> yep, I've been looking for a while for a nice aarch64 buildbox, but documentation on the internet is very scarce
2020-11-19 14:01:06 <MartijnBraam> the amperas look very nice, but expensive
2020-11-19 14:01:52 <Ariadne> theres a discord channel on the ARM Developer Ecosystem discord server
2020-11-19 14:01:57 <Ariadne> i can give you an invite link if it would help
2020-11-19 14:02:52 <MartijnBraam> oh yes
2020-11-19 14:02:54 <PureTryOut[m]2> Ew Discord
2020-11-19 14:03:05 <MY-R> 
ACTION noticed that Alpine working great on rpi4 (aarch64) :D

2020-11-19 14:03:44 <Ariadne> yes, "ew discord" but it is helpful to be able to talk to the engineers who made the product when trying to boot it
2020-11-19 14:04:10 <PureTryOut[m]2> Yes definitely, just a shame they're doing it on Discord 😉
2020-11-19 14:04:14 <MartijnBraam> most information about lx2k I've found is some random engineers putting ubuntu on it and documenting it
2020-11-19 14:05:03 <MartijnBraam> and the lx2ks are slightly too expensive to just get one to guess if it boots as you think
2020-11-19 14:05:15 <Ariadne> alpine works great as long as you use a USB NIC
2020-11-19 14:05:29 <Ariadne> i am very happy with my honeycomb build
2020-11-19 14:05:30 <MartijnBraam> something about putting an efi bootloader on the SPI chip to make it able to boot a standard distro from nvme
2020-11-19 14:05:35 <Ariadne> anyway their discord is at https://discord.com/invite/H5ETM7C
2020-11-19 14:05:50 <Ariadne> i run the efi bootloader on an sdcard
2020-11-19 14:05:57 <Ariadne> and then boot alpine from nvme
2020-11-19 14:06:24 <MartijnBraam> yeah that works too, but I like my bootloaders on SPI because then they act like x86 boards
2020-11-19 14:07:21 <insep_> are there qcom people in that discord? :D
2020-11-19 14:08:33 <Ariadne> i don't know
2020-11-19 14:08:44 <Ariadne> it is run by ARM, so probably
2020-11-19 14:12:51 <mps> alpine aarch64 builder '[    0.279422] DMI: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.29 07/17/2017'
2020-11-19 14:13:10 <mps>  Linux version 5.4.34-0-lts (buildozer@build-3-11-aarch64) (gcc version 9.2.0 (Alpine 9.2.0)) #1-Alpine SMP Wed, 22 Apr 2020 19:26:07 UTC
2020-11-19 14:13:50 <MY-R> nice beast!
2020-11-19 14:14:21 <Ariadne> mps: also way more expensive than honeycomb :P
2020-11-19 14:16:21 <mps> afaik, alpine also run fine on ampere
2020-11-19 14:16:38 <Ariadne> thats even more expensive than the taishan 2280
2020-11-19 14:16:39 <Ariadne> :P
2020-11-19 14:16:57 <Ariadne> other places alpine runs fine: amazon graviton bare-metal
2020-11-19 14:17:04 <Ariadne> thunderx/thunderx2
2020-11-19 14:17:15 <mps> and yes, alpine runs fine on rk3399 chromebook nearly 3 years here
2020-11-19 14:17:21 <Ariadne> like i said, any big iron efi server it will run fine
2020-11-19 14:17:46 <mps> yes, also thunders
2020-11-19 14:18:30 <Ariadne> where alpine does not run is primarily crap that is binary blobbed to hell
2020-11-19 14:18:35 <Ariadne> like nvidia tegra
2020-11-19 14:19:10 <mps> right
2020-11-19 14:20:06 <insep_> depends on what tegra
2020-11-19 14:20:08 <mps> maybe soon apple macbook mini
2020-11-19 14:20:20 <insep_> https://wiki.postmarketos.org/wiki/Google_Nexus_7_2012_(asus-grouper)
2020-11-19 14:21:16 <mps> what is 'Discard' server :D
2020-11-19 14:21:24 <insep_> i wanted to port pmos to switch but i lost rcm jig :D
2020-11-19 14:23:59 <Ariadne> mps: i am concerned about graphics on the apple stuff
2020-11-19 14:24:21 <Ariadne> i don't want to buy an arm macbook to learn that its some proprietary apple gpu
2020-11-19 14:25:27 <mps> heh, also I don't think I will ever buy anything from apple
2020-11-19 14:26:04 <mps> but for my firm I had to buy one and probably soon will have to buy another one
2020-11-19 14:28:07 <MartijnBraam> Ariadne: well the ARM macbooks have a locked bootloader anyway
2020-11-19 14:28:11 <MartijnBraam> for your protection ofcourse
2020-11-19 14:28:46 <mps> ofc ;)
2020-11-19 14:31:06 <MartijnBraam> I wonder how much of the performance difference on macbooks is ARMv8.1 vs ARMv8.3
2020-11-19 14:36:11 <Ariadne> MartijnBraam: you can unlock it with kputil
2020-11-19 14:37:01 <MartijnBraam> can't find anything about kputil?
2020-11-19 14:40:33 <Ariadne> sorry, kmutil
2020-11-19 14:40:34 <Ariadne> https://twitter.com/never_released/status/1327394634272813057
2020-11-19 14:41:47 <MartijnBraam> interesting
2020-11-19 14:42:53 <Ariadne> i'm surprised that pmOS folks aren't on the ARM developer ecosystem discord
2020-11-19 14:43:08 <Ariadne> lots of free lowlevel information for the taking there, really
2020-11-19 14:43:59 <Ariadne> you can even talk to the windows on arm team
2020-11-19 14:44:00 <PureTryOut[m]2> I personally avoid anything on proprietary walled gardens like Discord and I'm not that much into low level stuff anyway. The other devs, idk
2020-11-19 14:44:14 <insep_> kernel isn't low enough
2020-11-19 14:44:25 <insep_> plus some people are against proprietary services
2020-11-19 14:45:54 <Ariadne> being able to talk to the people making the chips you are trying to do bringup on is helpful
2020-11-19 14:45:56 <Ariadne> but,  you do you
2020-11-19 14:50:05 <walbon> clandmeter: I have seen a couple of packages failing by a trying to install a dependency, I saw in the main branch these ones apcupsd, bcache-tools, d-feet, ghostscript, gstreamer, lua-ldbus, snort and testdisk. Could you see that either?
2020-11-19 14:52:16 <MartijnBraam> I just didn't know about that discord
2020-11-19 14:56:35 <insep_> Ariadne: there were only 2 soc bringups in #postmarketos-mainline, both qcom and qcom does qcom
2020-11-19 14:57:53 <insep_> and when someone really needs someone with deep knowledge of qcom stuff with potential to get stuff from qcom vault, ##linux-msm
2020-11-19 14:58:00 <Ariadne> insep_: so pmOS only runs on 2 SoCs?
2020-11-19 14:58:01 <Ariadne> :)
2020-11-19 14:58:47 <insep_> downstream is a thing, linaro is a thing, linux-sunxi is a thing :D
2020-11-19 14:59:52 <Ariadne> anyway the main bummer for my most powerful aarch64 laptop right now is that it uses a powervr gpu
2020-11-19 15:00:02 <insep_> also you don't need very deep knowledge of low-level stuff to port pmos, most phones don't allow replacing bootloaders anyways :(
2020-11-19 15:00:07 <Ariadne> so i am stuck to llvmpipe
2020-11-19 15:00:13 <insep_> oof
2020-11-19 15:00:19 <insep_> i think there's driver in the works
2020-11-19 15:00:23 <MartijnBraam> aarch64 laptop with powervr?
2020-11-19 15:00:31 <MartijnBraam> insep: I don't think so
2020-11-19 15:00:33 <Ariadne> yes, the mediatek mt8173c
2020-11-19 15:00:45 <Ariadne> its a common soc for chromebooks
2020-11-19 15:01:02 <MartijnBraam> oh right
2020-11-19 15:01:06 <Ariadne> mps has a mainline kernel for it, even
2020-11-19 15:01:12 <insep_> MartijnBraam: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1219167-imagination%E2%80%99s-powervr-gpu-driver-within-the-mesa-framework
2020-11-19 15:01:14 <Ariadne> maybe we will get that into alpine 3.13 :)
2020-11-19 15:02:05 <Ariadne> insep_: afaik imgtec's risc-v products use an entirely new gpu architecture
2020-11-19 15:02:13 <MartijnBraam> I'd be quite happy if imagination stays the fuck away from the risc-v ecosystem
2020-11-19 15:03:18 <insep_> there was one guy who tried to do kernel bringup for some mediatek soc
2020-11-19 15:03:22 <Ariadne> hmm but
2020-11-19 15:03:25 <Ariadne> This will include Imagination’s PowerVR GE7800 XE series GPU to enable developers to run graphics-intensive applications (such as web browsers).
2020-11-19 15:03:27 <insep_> now he hates mediatek
2020-11-19 15:03:32 <Ariadne> yes, mediatek is a nightmare
2020-11-19 15:03:50 <Ariadne> ge7800 is same gen gpu as what is in the mt8173c
2020-11-19 15:03:52 <Ariadne> so hmm :P
2020-11-19 15:03:54 <Ariadne> dunno :)
2020-11-19 15:04:21 <MartijnBraam> I'd be really happy already if imagination opened up SGX530
2020-11-19 15:04:24 <Ariadne> i am still waiting on a riscv builder that does not suck
2020-11-19 15:04:47 <MartijnBraam> hmm there was new hifive stuff released recently
2020-11-19 15:05:33 <Ariadne> yeah
2020-11-19 15:05:35 <Ariadne> 8gb of ram
2020-11-19 15:05:40 <Ariadne> soldered to motherboard
2020-11-19 15:05:43 <Ariadne> not really good :P
2020-11-19 15:06:04 <Ariadne> also only quadcore
2020-11-19 15:06:16 <Ariadne> i am considering setting up a builder running on qemu simulation
2020-11-19 15:06:32 <Ariadne> it is likely more productive for now than dealing with the board i already have
2020-11-19 15:06:42 <Ariadne> the board i have is slow
2020-11-19 15:06:44 <Ariadne> super slow
2020-11-19 15:08:18 <Ariadne> the simulator at least supports 8-way SMP
2020-11-19 15:08:23 <Ariadne> and 16gb of ram
2020-11-19 15:18:33 <mps> yes mediatek mt8173 oak-elm chromebook works fine even without powervr graphic driver
2020-11-19 15:19:16 <mps> ofc, I don't need any 3d gl things
2020-11-19 15:20:33 <mps> for everyday use cases it is ok, firefox, libreoffice, mpv etc (and st terms :) )
2020-11-19 15:36:32 <ikke> rust 1.48 is out
2020-11-19 15:37:55 <Ariadne> mps: sure but I rather run kde
2020-11-19 15:37:57 <ikke> https://blog.rust-lang.org/2020/11/19/Rust-1.48.html
2020-11-19 15:38:20 <mps> ah, kde :P
2020-11-19 16:26:52 <Ariadne> mps: anyway, it would be nice to get linux-oak APKBUILD into alpine :)
2020-11-19 16:27:51 <mps> Ariadne: it would be easy, I just have to copy my build script :)
2020-11-19 16:28:42 <mps> but maybe wait till 5.10 is released, now I use -rc series
2020-11-19 16:29:53 <mps> but if you like to see it 'asap' I can make it, i.e. 5.10-rc4
2020-11-19 16:34:15 <Ariadne> does it work from mainline itself or does it still need that git tree
2020-11-19 16:34:27 <Ariadne> i was thinking maybe we integrate it into linux-edge
2020-11-19 16:36:14 <mps> -rc4 mainline without any patch
2020-11-19 16:37:00 <mps> and it started to work on mainline from 5.10-rc1
2020-11-19 16:37:04 <Ariadne> neat
2020-11-19 16:37:14 <Ariadne> i wonder if we can integrate it into linux-edge APKBUILD
2020-11-19 16:37:18 <mps> even suspend2ram works now
2020-11-19 16:37:56 <mps> then we should add options to config-edge.aarch64
2020-11-19 16:38:24 <Ariadne> hmm
2020-11-19 16:38:27 <Ariadne> yes
2020-11-19 16:38:48 <mps> and build vmlinux for chromebook kernel partition
2020-11-19 16:38:49 <Ariadne> and then we can make a package that just updates the kernel partition
2020-11-19 16:38:51 <Ariadne> yes
2020-11-19 16:38:52 <Ariadne> :)
2020-11-19 16:39:38 <mps> though I prefer separate config with just needed things for particular box
2020-11-19 16:40:06 <Ariadne> sure, i'm just thinking this way is simpler for typical people
2020-11-19 16:40:17 <Ariadne> if we can make our generic kernels have all the stuff, that's a win
2020-11-19 16:41:35 <mps> well, yes
2020-11-19 16:41:55 <mps> but I always have dilemma about these two variants
2020-11-19 16:43:20 <mps> btw, I also have linux-rc branch in my local aports repo :)
2020-11-19 16:59:26 <wener[m]> ncopa: thanks, I'll take a trail when k0s in edge.
2020-11-19 17:33:26 <wsinatra> anyone have a spare moment to look at MR !14613?
2020-11-19 17:38:35 <mps> wsinatra: I looked at it few days ago and when saw license I stopped
2020-11-19 17:40:43 <wsinatra> Yeah, not entirely open source, though it's in the process of being made so. At least that's what the last statement from june 2019 was
2020-11-19 17:41:06 <wsinatra> either way it's about the only tool that exists if you want to make z-machine images for text adventures
2020-11-19 17:41:10 <wsinatra> at least that I'm aware of
2020-11-19 17:41:50 <mps> I'm not sure if alpine can distribute it, someone who understand that should look
2020-11-19 17:44:35 <wsinatra> I know in the past I've had a package for a free use but not open source package merged, of course it went into non-free and isn't really accessible to anyone
2020-11-19 17:44:51 <wsinatra> I'm curious though if someone knows
2020-11-19 17:45:06 <ikke> Someone knows what?
2020-11-19 17:45:13 <MY-R> doesnt sound so "bad": https://en.wikipedia.org/wiki/Artistic_License#Artistic_License_2.0
2020-11-19 17:45:13 <alpine-meetbot> [WIKIPEDIA] Artistic License#Artistic License 2.0 | "The Artistic License is a software license used for certain free and open-source software packages, most notably the standard implementation of the Perl programming language and most CPAN modules, which are dual-licensed under the Artistic License and the GNU General Public License (GPL)...."
2020-11-19 17:46:18 <ikke> "The i7 interface for Linux CLI is licensed under the GPLv3:"
2020-11-19 17:46:55 <wsinatra> well then there shouldn't be an issue with the licensing, even if it is a bit of an amalgamation of different licenses
2020-11-19 17:47:18 <ikke> Right, but then the license field should be adjusted
2020-11-19 17:47:41 <ikke> https://spdx.org/licenses/Artistic-1.0-Perl.html
2020-11-19 17:47:58 <ikke> https://spdx.org/licenses/
2020-11-19 17:48:08 <ikke> If it's multiple licenses, you can combine them with AND
2020-11-19 17:48:17 <ikke> or OR
2020-11-19 17:48:38 <mps> license="Artistic License 2.0"
2020-11-19 17:49:11 <ikke> You need to use the SDPX short identifier
2020-11-19 17:49:20 <ikke> Artistic-1.0
2020-11-19 17:49:30 <mps> ah
2020-11-19 17:49:53 <ikke> or Artistic-2.0
2020-11-19 17:50:25 <wsinatra> wiki shows Artistic-2.0 should I include or GPL 3 since the i7 interface is the primary thing being packaged?
2020-11-19 17:52:09 <mps> (nowadays schools have to first make lawyers of all pupils and just after that start to teach them to read and write)
2020-11-19 17:52:10 <ikke> I guess Artistic-2.0 AND GPL-3.0-(or-later|only)
2020-11-19 17:55:35 <wsinatra> Definitely the most confusing license in a package I've done yet :)
2020-11-19 17:57:36 <wsinatra> thanks mps & ikke! Learned something new today
2020-11-19 18:01:13 <mps> wsinatra: np :)
2020-11-19 18:01:51 <mps> also I learn something new everyday and the result is that I know less and less
2020-11-19 18:53:46 <ikke> wsinatra: sorry the (or-later|only) part mean that it's either one of those
2020-11-19 18:54:11 <ikke> https://spdx.org/licenses/GPL-3.0-only.html
2020-11-19 18:54:16 <ikke> https://spdx.org/licenses/GPL-3.0-or-later.html
2020-11-19 18:54:32 <wsinatra> OH that makes a little bit more sense, since only is kind of exclusive of later
2020-11-19 18:55:09 <ikke> But you need to figure out what's the case for that specific project
2020-11-19 18:55:35 <Ariadne>     License
2020-11-19 18:55:35 <Ariadne>         https://www.gnu.org/licenses/gpl-3.0.html
2020-11-19 18:55:35 <Ariadne>         The i7 interface for Linux CLI is licensed under the GPLv3:
2020-11-19 18:55:35 <ikke> "The license notice (as seen in the Standard License Header field below) states which of these applies the code in the file. The example in the exhibit to the license shows the license notice for the "or later" approach."
2020-11-19 18:55:43 <Ariadne> but the rest of this, is under what license?
2020-11-19 18:55:47 <Ariadne> and why is it binaries?
2020-11-19 18:57:23 <ikke> " wsinatra │ Yeah, not entirely open source, though it's in the process of being made so. At least that's what the last statement from june 2019 was"
2020-11-19 18:58:04 <ikke> but if it's GPL, you should already be able to request the source
2020-11-19 18:58:53 <Ariadne> when it is made GPL, we can discuss including it then.
2020-11-19 19:00:04 <wsinatra> fortunately the dev lists his email on his site, I'll reach out to him and ask about the licensing
2020-11-19 19:00:14 <ikke> (and the source :P)
2020-11-19 19:01:20 <wsinatra> hahah that too :)
2020-11-19 19:03:02 <Ariadne> i doubt any of the people or legal entities which take the legal risk of releasing alpine want to take the risk of dealing with this packaging
2020-11-19 19:03:15 <Ariadne> i certainly wouldn't sign off on this
2020-11-19 19:03:46 <Ariadne> if somebody is crazy enough to think that you can GPLv3 a binary and not ship source, who knows what else he thinks
2020-11-19 19:05:28 <ikke> Ariadne: officially it's enough if they provide the source on request, right?
2020-11-19 19:06:13 <Ariadne> yes, but thats still a can of worms i am not comfortable with personally
2020-11-19 19:07:02 <ikke> And we want to (be able to) build things from source
2020-11-19 19:09:26 <Ariadne> at any rate, this particular state i would not accept it as "GPL" without source
2020-11-19 19:10:05 <wsinatra> a fair enough argument. I can easily pull the MR for the time being so it isn't gumming up the works
2020-11-19 19:10:22 <wsinatra> and assuming that I get the source from the dev go forward from there
2020-11-19 19:21:00 <ikke> Cogitri: ping
2020-11-19 19:22:02 <Cogitri> Pong
2020-11-19 19:22:14 <ikke> Seems like cargo is acting up again on our builders
2020-11-19 19:22:29 <ikke> failed to read `/var/cache/distfiles/cargo/registry/src/github.com-1285ae84e5963aae/cfg-if-1.0.0/Cargo.toml`
2020-11-19 19:22:33 <ikke> for oha
2020-11-19 19:22:44 <Cogitri> Ugh
2020-11-19 19:23:04 <Cogitri> Does that file/folder that contains it exist?
2020-11-19 19:23:11 <wsinatra> ariadne ikke, thanks for taking the time to help me grok this one, I appreciate the help even if we can't merge the package
2020-11-19 19:24:14 <ikke> Cogitri: github.com-1285ae84e5963aae does not exist
2020-11-19 19:24:21 <ikke> github.com-1ecc6299db9ec823 does
2020-11-19 19:24:23 <Cogitri> Wut
2020-11-19 19:24:46 <Cogitri> Is that on a runner that shares distfiles?
2020-11-19 19:25:09 <ikke> aarch64 is dedicated
2020-11-19 19:25:14 <ikke> armv7 shares with armhf
2020-11-19 19:26:45 <ikke> (atm it fails on both aarch64 and armv7)
2020-11-19 19:29:54 <ikke> Cogitri: oh, I think that's my bad
2020-11-19 19:30:06 <ikke> I checked aarch64, but the log was for armv7
2020-11-19 19:31:11 <ikke> so on aarch64: /var/cache/distfiles/cargo/registry/src/github.com-1ecc6299db9ec823/byte-unit-4.0.9/Cargo.toml does not exist
2020-11-19 19:31:24 <ikke> /var/cache/distfiles/cargo/registry/src/github.com-1ecc6299db9ec823/byte-unit-4.0.9/src/ does
2020-11-19 19:34:10 <ikke> Cogitri: works if I delete the offending packages
2020-11-19 19:34:20 <Cogitri> Ah
2020-11-19 19:34:48 <ikke> Just wondering why Cargo.toml went awol
2020-11-19 19:35:35 <ikke> 2 packages for both archers
2020-11-19 19:36:03 <ikke> now to figure out why tree keeps failing to download
2020-11-19 22:02:53 <ikke> Cogitri: more weirdness of missing files on armhf
2020-11-19 22:03:10 <ikke> I need to remove the crates and then it works
2020-11-19 22:06:30 <Cogitri> Huuuhh
2020-11-19 22:07:21 <ikke> not just Cargo.toml, but also source files its eems
2020-11-19 22:07:35 <ikke> file not found for module `macros`
2020-11-19 22:07:49 <ikke> file not found for module `ident`
2020-11-19 22:07:54 <ikke> and more
2020-11-19 22:32:32 <hechos> hello guys
2020-11-19 22:32:50 <hechos> where can find information how get working chrony
2020-11-19 22:33:19 <ikke> chrony website?
2020-11-19 22:33:40 <hechos> chronyd
2020-11-19 22:34:06 <clandmeter> hechos: we have a support channel at #alpine-linux
2020-11-19 22:34:21 <hechos> nobody tell me how.
2020-11-19 22:34:37 <hechos> is for this ask here,. sorry about
2020-11-19 22:36:22 <ikke> hechos: it helps to ask concrete questions, mention what part you are strugling with
2020-11-19 22:36:28 <hechos> just find chrony and gpsd
2020-11-19 22:36:33 <hechos> on wiki
2020-11-19 22:37:07 <hechos> sync time setup with chrony
2020-11-19 22:37:26 <hechos> im trying setup like due on void but here is not same.
2020-11-19 22:37:56 <hechos> and how can search content inside packages, from apk?
2020-11-19 22:38:09 <ikke> rc-service chronyd start
2020-11-19 22:38:18 <ikke> rc-update add chronyd
2020-11-19 22:38:52 <hechos> how.
2020-11-19 22:39:01 <hechos> im reading /sbin/setup-timezone.
2020-11-19 22:40:25 <hechos> need to be installed tzdata right?
2020-11-19 22:42:34 <MY-R> hechos: run setup-timezone, configure your time zone, install chrony (if dont have it) and start it like ikke wrote above
2020-11-19 22:42:39 <MY-R> dont need tzdata
2020-11-19 22:43:15 <hechos> MY-R: i write my own script to automate deploy on my systems.
2020-11-19 22:45:52 <MY-R> hechos: join #alpine-linux and tell about your system and how/what you wanna do it, wait and maybe you will get your answers/help if not then try in different hours
2020-11-19 22:45:58 <hechos> timezone is defind on /etc/rc.conf?
2020-11-19 22:52:01 <MY-R> hechos: well, if you wanna do it without setup-timezone then need install tzdata and link "/etc/localtime" to your zone info (or just grab example how use it from "setup-timezone" script
2020-11-19 22:52:28 <hechos> MY-R: yeah i run setup-timezone and get /etc/timezone.
2020-11-19 22:52:40 <hechos> sorry /etc/zoneinfo/
2020-11-19 22:53:04 <MY-R> so now you can start chrony
2020-11-19 22:53:19 <mps> looks like clandmeter lost authority here
2020-11-19 22:53:22 <mps> :)
2020-11-19 22:54:12 <MY-R> 
ACTION hides and promise to be quiet! shhh!

2020-11-19 22:54:16 <hechos> im getting error trying to apk add tzdata-2020c-r0
2020-11-19 22:54:46 <MY-R> 
ACTION whispers: do app add tzdata

2020-11-19 22:54:55 <MY-R> apk*
2020-11-19 22:55:05 <mps> hechos: this is development channel
2020-11-19 22:55:33 <hechos> i know.
2020-11-19 22:56:22 <clandmeter> im getting an error with pdns and geoip
2020-11-19 22:56:31 <hechos> thanks any way. glad to meet you
2020-11-19 22:56:46 <clandmeter> Exiting because of STL error: basic_string::_M_construct null not valid
2020-11-19 22:58:07 <mps> clandmeter: it is C++ code?
2020-11-19 22:58:50 <clandmeter> yep
2020-11-19 22:59:23 <mps> I'm bad on C++
2020-11-19 22:59:53 <mps> if you are not in a hurry I can look tomorrow, to tired now
2020-11-19 23:00:20 <clandmeter> im not
2020-11-19 23:00:23 <clandmeter> its getting late
2020-11-19 23:00:31 <clandmeter> its already tomorrow here
2020-11-19 23:00:58 <mps> yes, I'm drinking last glass of wine today before bed
2020-11-19 23:01:11 <clandmeter> last glass or last bottle?
2020-11-19 23:01:25 <mps> glass :)
2020-11-19 23:01:45 <clandmeter> half full or half empty?
2020-11-19 23:02:00 <mps> optimists one ;0
2020-11-19 23:02:05 <mps> ;)
2020-11-19 23:02:14 <mps> half full
2020-11-19 23:02:32 <clandmeter> :)
2020-11-19 23:41:09 <hechos> mps: red wine!
2020-11-19 23:42:08 <mps> hechos: yes, of course :)
2020-11-19 23:42:41 <hechos> mps: here in argentina have a nice wines
2020-11-19 23:43:08 <hechos> mps: you have to drink metexa
2020-11-19 23:43:51 <hechos> metaxa
2020-11-19 23:44:20 <hechos>  sorry one friend on ships drink own metaxa of course is greek captain.
2020-11-19 23:47:12 <mps> hechos: we have also #alpine-offtopic channel (and I have metaxa in cellar, Greece is near to me :) )
2020-11-20 00:00:53 <craftyguy> hmm, python gtk3 bindings are in alpine somewhere, right? I see py3-gobject3 has a 'Gtk.py', is that it?
2020-11-20 00:01:08 <craftyguy> 
ACTION pretty sure this is there, has run a python gtk3 thing in the past..

2020-11-20 00:05:58 <craftyguy> ah nevermind
2020-11-20 01:58:33 <halo> mps: lol, you weren't kidding baout apk-file having some… odd output :)
2020-11-20 02:20:41 <halo> pro-tip: apk-file <package> | awk '/\// { print $1 }'
2020-11-20 02:20:45 <halo> much more pleasant output :)
2020-11-20 02:21:03 <halo> even better:
2020-11-20 02:21:08 <halo> pro-tip: apk-file <package> | awk '/\// { print $1 }' | sort -u
2020-11-20 02:21:20 <halo> actually seems to give a reasonable package contents summary
2020-11-20 02:21:46 <halo> 
ACTION adds this to $HOME/bin/functions

2020-11-20 02:24:30 <halo> oh wait
2020-11-20 02:24:38 <halo> apk-file includes a bunch of other stuff…
2020-11-20 02:26:48 <halo> pro-tip: apk-file <package> | awk '$2~/<package>/ { print $1 }' | sort -u
2020-11-20 02:27:55 <halo> pro-tip: apk-file <package> | awk '$2~/^<package>$/ { print $1 }' | sort -u
2020-11-20 02:27:58 <halo> sorry about that
2020-11-20 02:30:01 <halo> oh… it's meant to search for a file, not a package?
2020-11-20 02:30:16 <halo> mk
2020-11-20 02:30:24 <halo> that's definitely not what I was hoping for :P
2020-11-20 02:36:46 <halo> still, cool to have a remote `apk info -W`
2020-11-20 02:43:11 <halo> okay, so, with that information, here's a better function: function whoprovides() { apk-file "$1" | awk '/\// { print $2 ":", $1 }' | sort -u }
2020-11-20 02:43:17 <halo> it ignored arch and repo
2020-11-20 02:43:29 <halo> (but I kind of don't care about that)
2020-11-20 03:39:56 <halo> so, I'm working on a youtube-dl-git-bin (-git because pulled from latest HEAD on build, -bin because built with pyinstaller) for my own local use
2020-11-20 03:42:00 <halo> but, when I go to build it, I get: ERROR: no such package: .makedepends-youtube-dl-git-bin
2020-11-20 03:42:10 <halo> which I don't really understand…
2020-11-20 03:43:57 <halo> https://0x0.st/i50A.txt ← the WIP APKBUILD
2020-11-20 03:44:11 <halo> (it obviously depends on packages that aren't in the repos yet)
2020-11-20 07:25:17 <ikke> halo: usually that means something went wrong with installing the dependencies
2020-11-20 07:56:53 <maxice8> Ikke: agl can now open Merge Requests :D
2020-11-20 07:57:38 <ikke> agl?
2020-11-20 08:11:42 <maxice8> gitlab alpinelinux.org/Leo/agl
2020-11-20 08:12:20 <ikke> nice
2020-11-20 08:12:31 <ikke> sudden explosion of go apps :P
2020-11-20 08:13:19 <Ariadne> i wish go worked on mips :P
2020-11-20 08:14:03 <ikke> Ariadne: It was the old kernel that was the issue, right?
2020-11-20 09:17:28 <ncopa> morning. my interent is back
2020-11-20 09:17:40 <ncopa> s/interent/internet/
2020-11-20 09:17:40 <alpine-meetbot> ncopa meant to say: morning. my internet is back
2020-11-20 09:17:49 <ncopa> Ariadne: thank you for fixing the musl CVE
2020-11-20 09:18:13 <Cogitri> Morning 👋
2020-11-20 09:18:22 <Ariadne> np
2020-11-20 09:19:02 <ncopa> it made my otherwise relatively good Friday morning significantly better :)
2020-11-20 09:20:02 <ikke> ncopa: I can imagine :)
2020-11-20 09:20:13 <ncopa> I need to figure out how to send encrypted email with the pub key i got from mips64 gcc dev
2020-11-20 09:21:04 <ncopa> +1 on "i wish go worked on mips"
2020-11-20 09:21:11 <ncopa> go is a pretty nice language
2020-11-20 09:22:34 <ikke> ncopa: I was thinking a bit about how go works with modules and that you refer to them by domain
2020-11-20 09:23:03 <ikke> (usually the domain + path to the git repo where they were hosted)
2020-11-20 09:23:47 <ncopa> go ... modules ... not sure i want start that discussion on an otherwise excellent Friday :)
2020-11-20 09:28:08 <ncopa> sorry, didnt mean to cut you off. go modules in general are the challenging parts of go.
2020-11-20 09:28:29 <ncopa> ikke: what was your thoughts about go modules and domains?
2020-11-20 09:31:28 <mps> go lang is nice but go ecosystem is not
2020-11-20 09:32:47 <ikke> ncopa: I saw someone doing this: https://github.com/mvdan/sh/blob/master/go.mod#L1
2020-11-20 09:33:08 <ikke> That turns out to be just a redirect
2020-11-20 09:33:16 <ikke> mvdan.cc/sh
2020-11-20 09:33:42 <ikke> So basically creating your own namespace regardless of where it's hosted
2020-11-20 09:36:58 <ikke> I did something similar
2020-11-20 09:37:01 <ikke> https://gitlab.alpinelinux.org/kdaudt/atools-go/-/blob/master/go.mod
2020-11-20 09:37:08 <ikke> (but used a replace statement)
2020-11-20 09:48:01 <ncopa> ah, nice!
2020-11-20 09:57:30 <ikke> So your references in your packages can remain stable (and sensicle), and you only have to either modify your go.mod file, or change the redirect
2020-11-20 12:21:56 <maxice8> nice
2020-11-20 12:38:24 <Newbyte> is there any way of checking what went wrong when makedepends fail?
2020-11-20 12:38:36 <Newbyte>  * is there any way of checking what went wrong when builddeps fail?
2020-11-20 12:40:25 <ikke> apk fix
2020-11-20 12:41:03 <Newbyte> that worked, thank you
2020-11-20 12:46:39 <Newbyte> How do you usually deal with programs that want git submodules?
2020-11-20 12:46:59 <ikke> fetch the submodules as separate source files
2020-11-20 12:50:21 <Newbyte> how do you get the submodule files in the location expected by the code though? mv command?
2020-11-20 12:51:50 <ikke> yes
2020-11-20 12:51:59 <ikke> you can do that in the prepare() phase
2020-11-20 12:52:51 <Newbyte> 👍️
2020-11-20 13:22:17 <Newbyte> https://github.com/matthiask/html-sanitizer/blob/master/LICENSE
2020-11-20 13:22:23 <Newbyte> this doesn't sound like a free software licence, does it?
2020-11-20 13:22:42 <Newbyte> trying to package something that depends on this but I don't know if this can be packaged
2020-11-20 13:26:43 <Cogitri> Looks like BSD-3-Clause
2020-11-20 13:28:15 <Newbyte> now that I'm looking it up, definitely does
2020-11-20 13:28:59 <Newbyte> thank you
2020-11-20 14:19:29 <andypost> looks only armv7 edge builder works
2020-11-20 14:20:52 <ikke> Hmm, see
2020-11-20 14:21:24 <ikke> error: Unable to create '/home/buildozer/aports/.git/index.lock': File exists.
2020-11-20 14:21:30 <Newbyte> Yeah
2020-11-20 14:21:35 <Newbyte> I've been having a bunch of git segfaults
2020-11-20 14:22:03 <ikke> You as wlel
2020-11-20 14:22:05 <Newbyte> I thought I had messed up my VM somehow
2020-11-20 14:22:13 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12124
2020-11-20 14:22:31 <Newbyte> The segfaults are very random though
2020-11-20 14:22:37 <Newbyte> If I keep repeating the same command it usually works eventually
2020-11-20 14:22:42 <Newbyte> Rebasing is very hard
2020-11-20 14:22:58 <Newbyte> And, I updated and rebooted latest earlier today
2020-11-20 14:23:08 <ikke> last update has been >14 days ago
2020-11-20 14:23:48 <Newbyte> git dependency updated?
2020-11-20 14:24:59 <ikke> just 131 dependencies to check :P
2020-11-20 14:25:31 <andypost> maybe musl cve upgrade?
2020-11-20 14:25:53 <andypost> 9e3ec61a9b2ecdbd4a4107230d865c215fb912d3
2020-11-20 14:27:28 <ikke> Sounds plausible
2020-11-20 14:29:21 <ikke> Ariadne: ping
2020-11-20 14:30:56 <Ariadne> ping dalias?
2020-11-20 14:31:07 <Ariadne> the only thing 'new' is the CVE fix
2020-11-20 14:31:21 <Ariadne> i find it unlikely
2020-11-20 14:31:25 <Ariadne> that it is related though
2020-11-20 14:32:37 <Ariadne> algitbot: retry master
2020-11-20 14:32:48 <ikke> I just removed all .git/index.lock files
2020-11-20 14:32:57 <ikke> except for ppc64le and mips
2020-11-20 14:33:07 <ikke> s/ppc64le/s390x
2020-11-20 14:33:07 <alpine-meetbot> ikke meant to say: except for s390x and mips
2020-11-20 14:33:14 <Ariadne> not sure whats going on
2020-11-20 14:33:24 <Ariadne> this is some dalias-level stuff
2020-11-20 14:34:23 <dalias> hm?
2020-11-20 14:34:43 <Ariadne> since applying CVE-2020-28928 patch, git randomly is crashing
2020-11-20 14:35:00 <ikke> dalias: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12124 for example
2020-11-20 14:36:40 <dalias> ariadne, doesnt sound plausibly related
2020-11-20 14:36:49 <Ariadne> well
2020-11-20 14:37:01 <Ariadne> i'm telling you, that's the only thing 'new' with musl in edge :)
2020-11-20 14:37:02 <ikke> time-wise
2020-11-20 14:37:05 <dalias> are you sure nothing else chsnged?
2020-11-20 14:37:10 <ikke> checking
2020-11-20 14:37:20 <dalias> grep -r wcsnrtombs in git
2020-11-20 14:38:09 <ikke> nothing
2020-11-20 14:39:25 <ikke> https://tpaste.us/9jPV
2020-11-20 14:39:28 <ikke> this was upgraded in main today
2020-11-20 14:40:34 <andypost> I confirm that after Upgrading musl (1.2.2_pre1-r0 -> 1.2.2_pre2-r0) I getting segf on "git status"
2020-11-20 14:41:21 <ikke> 
ACTION pins musl on his build container

2020-11-20 14:46:03 <ikke> cannot reproduce it
2020-11-20 14:46:13 <ikke> trying it on a fresh aports clone
2020-11-20 14:48:01 <Newbyte> I can reproduce it very often so if that's useful in any way let me know how I can help
2020-11-20 14:50:43 <ikke> Newbyte: would be nice if you could produce a stacktrace
2020-11-20 14:50:48 <ikke> apk add musl-dbg git-dbg
2020-11-20 14:53:41 <ikke> apk add gdb
2020-11-20 14:53:50 <ikke> gdb --args git status
2020-11-20 14:54:19 <Newbyte> bingo, it crashed the first time
2020-11-20 14:54:59 <andypost> segf depends on path, I can reproduce in docker when mounted aports to /mnt, it ok in /mnt/community but sefg after cd to php7
2020-11-20 14:55:15 <Newbyte> Backtrace stopped: Cannot access memory at address 0x7ffff7d9a9f8
2020-11-20 14:55:20 <Ariadne> look
2020-11-20 14:55:21 <Newbyte> Not sure what to make of this
2020-11-20 14:55:25 <Ariadne> threads apply all bt full
2020-11-20 14:55:37 <Ariadne> put it in a paste bin
2020-11-20 14:55:39 <Ariadne> the entire thing
2020-11-20 14:55:42 <ikke> ah, I have a segfault now too
2020-11-20 14:55:48 <Newbyte> nice
2020-11-20 14:56:28 <Newbyte> <Ariadne "threads apply all bt full"> is this a gdb command?
2020-11-20 14:56:35 <ikke> yes
2020-11-20 14:56:35 <Ariadne> yes
2020-11-20 14:56:51 <Newbyte> Undefined command: "threads"
2020-11-20 14:57:07 <Ariadne> thread apply all bt full
2020-11-20 14:57:31 <Newbyte> can I redirect this to a file or something like that?
2020-11-20 14:57:40 <ikke> tpaste
2020-11-20 14:57:45 <ikke> hmm
2020-11-20 14:57:49 <ikke> from gdb you mean
2020-11-20 14:57:53 <Newbyte> yes
2020-11-20 14:58:10 <mps> set logging on
2020-11-20 14:58:28 <mps> set logging file filename
2020-11-20 14:59:06 <Newbyte> https://paste.centos.org/view/086a0cb6
2020-11-20 14:59:09 <Newbyte>  * https://paste.centos.org/view/086a0cb5
2020-11-20 14:59:29 <Newbyte> Did the edit get through to IRC?
2020-11-20 14:59:47 <Ariadne> dalias: ping
2020-11-20 14:59:51 <ikke> Newbyte: just as a new message
2020-11-20 15:00:09 <Newbyte> good enough
2020-11-20 15:02:17 <andypost> I did as well https://tpaste.us/zxlv
2020-11-20 15:09:03 <Newbyte> btw, if I'm submitting a new aport which has unpackaged dependencies, is it preferable to let those dependencies be separate MRs or put it all in one MR (but keep separate commits still)?
2020-11-20 15:09:33 <Hello71> same mr, then they can ci together
2020-11-20 15:09:47 <Newbyte> thanks, I'll keep that in mind in the future
2020-11-20 15:28:51 <dalias> ariadne, pong
2020-11-20 15:33:37 <dalias> *sigh* it would have helped if you said you upgraded musl to master rather than applying cve patch
2020-11-20 15:33:42 <dalias> there are other changes
2020-11-20 15:33:55 <dalias> and presumably one of these was broken
2020-11-20 15:35:17 <dalias> which thread crashed?
2020-11-20 15:35:49 <ikke> Thread 14 "git" received signal SIGSEGV, Segmentation fault.
2020-11-20 15:36:57 <dalias> ohhh i did something bad *sigh*
2020-11-20 15:39:51 <andypost> as I got from backreace it reads index, accessing cache and fails waiting this thread
2020-11-20 15:41:57 <dalias> 1 sec i'll have a patch
2020-11-20 15:43:17 <dalias> try this: http://ix.io/2EOF
2020-11-20 15:44:12 <andypost> looks promissing!
2020-11-20 15:46:57 <z3ntu> SpaceToast: could you move testing/bat to community?
2020-11-20 15:47:47 <ikke> z3ntu: SpaceToast on multiple occasions indicated not being interested in moving things to community due to the support implications
2020-11-20 15:48:43 <Newbyte> just curious, what are the support implications of moving something to community?
2020-11-20 15:49:53 <andypost> dalias, after patching I can't get segfalt! thanks!
2020-11-20 15:50:14 <ikke> Newbyte: half year of support in the last stable release
2020-11-20 15:50:23 <ikke> meaning sometimes having to backport fixes
2020-11-20 15:50:40 <Newbyte> got it, thanks
2020-11-20 15:51:16 <ikke> But officially testing should be an alternative to that
2020-11-20 15:51:22 <dalias> andypost, thanks, will push
2020-11-20 16:20:49 <ncopa> ugh. circular dep. libfm -> menu-cache -> libfm. why oh why....
2020-11-20 16:22:25 <ncopa> the "fix" is to add a separate libfm-extra package, which is built --with-extra-only
2020-11-20 16:25:44 <ncopa> dalias: thank you for fixing it so quick
2020-11-20 16:36:39 <SpaceToast> ikke: the secondary issue is I've also mostly moved to just maintaining out-of-band HEAD compiles of static bins, which coincidentally matches the definition of 90% of my packages
2020-11-20 16:37:03 <SpaceToast> I do still have a couple left (such as the lightweight mail spam thing in perl), but yeah
2020-11-20 19:59:13 <Ariadne> ikke: i prepared fixed musl package.  the git index.locks will likely need to be purged again
2020-11-20 20:09:22 <ikke> Ariadne: sure
2020-11-20 20:09:24 <ikke> let me know when
2020-11-20 20:09:33 <ikke> ah, already pushed
2020-11-20 20:12:22 <ikke> algitbot: retry master
2020-11-21 00:12:41 <maxice8> Ikke: ping
2020-11-21 00:23:16 <halo> ikke: hmm, well, I kind of figured that much, but as far as I know the deps are all fine… I'll give it a shot here again tonight if I have the energy :)
2020-11-21 02:15:20 <hechos> hi guys
2020-11-21 02:15:56 <hechos> im facing problem with r8169 is problem from kernel or need to add to initramfs?
2020-11-21 02:18:35 <dalias> ?
2020-11-21 02:20:36 <hechos> dalias: yes realtek r8169 need to rmmod and modprobe.
2020-11-21 02:20:41 <hechos> to work.
2020-11-21 06:46:02 <ikke> maxice8: pong
2020-11-21 07:20:40 <maxice8> Ikke: you know if switch in golang can match an empty string with "" ?
2020-11-21 07:23:45 <ikke> in a case statement?
2020-11-21 07:24:50 <ikke> https://play.golang.org/p/YW83GOjIRhN
2020-11-21 07:36:29 <maxice8> nice
2020-11-21 07:36:29 <maxice8> thank you
2020-11-21 07:47:29 <andypost[m]> As I see armv7 3.13 builder hangs on perl server longer then 1day, maybe restart it?
2020-11-21 07:58:24 <ikke> andypost[m]: killed the job
2020-11-21 08:01:49 <maxice8> 
ACTION uploaded an image: image.png (20KiB) < https://synapse.cogitri.dev/_matrix/media/r0/download/cogitri.dev/LiTUGFCvPDMWacwSCtMzalmf/image.png >

2020-11-21 08:01:51 <maxice8> Ikke: check this out ^
2020-11-21 08:04:55 <ikke> nice
2020-11-21 08:16:02 <Newbyte> Any idea why mistune isn't available for s390x? py3-mistune built fine for s390x on the CI when I made the aport
2020-11-21 08:16:21 <ikke> s390x is a bit behind
2020-11-21 08:17:27 <Newbyte> got it. a new aport I'm making depends on py3-mistune so it fails - should I exclude s390x from its arches due to this?
2020-11-21 08:18:06 <Newbyte> I mean, I think it should work once s390x catches up
2020-11-21 08:18:29 <ikke> nod
2020-11-21 08:19:06 <ikke> You don't have to disable it
2020-11-21 08:19:55 <Newbyte> should I note in the MR that this is why the CI fails and as such the failures can be ignored or something like that?
2020-11-21 08:22:16 <ikke> Most reviewers know already
2020-11-21 08:23:45 <Newbyte> 👍️
2020-11-21 08:28:46 <maxice8> Ikke: https://gitlab.alpinelinux.org/Leo/agl/-/commit/6df60cc87ba6298c1ea8d82ca3c316ba104541ea should be usefufl
2020-11-21 08:28:49 <maxice8> useful*
2020-11-21 08:31:55 <Ariadne> sorry, yesterday I had to find a new WISP.  my previous solution discontinued their services.
2020-11-21 08:33:33 <ikke> ouch
2020-11-21 08:35:43 <Ariadne> it's ok.  the writing was on the wall.  they quit selling plans in January :)
2020-11-21 09:23:21 <andypost> clandmeter: please approve !14796
2020-11-21 09:47:30 <clandmeter> heh first time ive seen that button
2020-11-21 09:50:19 <ikke> Because it's new in 13.2
2020-11-22 01:12:40 <maxice8> Ikke: please make this public https://gitlab.alpinelinux.org/Leo/agl
2020-11-22 01:35:27 <clandmeter> maxice8: done
2020-11-22 01:35:41 <maxice8> Ty!
2020-11-22 01:55:20 <sh4rm4^bnc> can alpine build logs be looked at online? i'm interested in seeing whether your openssh package also throws a bunch of implicit declaration warnings
2020-11-22 01:57:40 <ix> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/openssh/
2020-11-22 01:58:17 <sh4rm4^bnc> thanks
2020-11-22 01:58:20 <sh4rm4^bnc> and indeed it does
2020-11-22 01:58:22 <sh4rm4^bnc> md5crypt.c:112:2: warning: implicit declaration of function 'snprintf' [-Wimplicit-function-declaration]
2020-11-22 01:59:07 <sh4rm4^bnc> though you don't have those about arc4random
2020-11-22 02:01:09 <dalias> ...
2020-11-22 02:01:30 <dalias> calling a variadic function without a prototype is UB
2020-11-22 02:01:49 <dalias> they should really fix that
2020-11-22 02:06:51 <sh4rm4^bnc> if i had a "security-focused" distro, if any build log contained "implicit declaration" i'd make it raise an error
2020-11-22 02:07:49 <sh4rm4^bnc> unfortunately -Werror-implicit... can't be added to configure, due to gazillions of bogus configure checks
2020-11-22 02:09:14 <halo> dalias: UB is the spice of life
2020-11-22 02:09:23 <halo> dalias: you've never lived till you've called gets()
2020-11-22 02:09:25 <halo> :)
2020-11-22 02:09:40 <halo> (though, to be fair, that's not really only for UB reasons :P)
2020-11-22 02:11:08 <ix> sh4rm4^bnc: it could be added to cflags after configure, no?
2020-11-22 02:11:17 <dalias> sh4rm4^bnc, right
2020-11-22 02:11:42 <dalias> ix, i think so, but that's hard in general because of projects that do recursive-configure (invokign subdir configure from make)
2020-11-22 02:11:49 <sh4rm4^bnc> ix: that's a bit problematic, if you run e.g. make CFLAGS=... then you'll likely overwrite build-system set flags
2020-11-22 02:12:16 <ix> export CFLAGS="$CFLAGS -Werror-implicit"; make
2020-11-22 02:12:17 <ix> :)
2020-11-22 02:12:25 <ix> dalias: eww yeah
2020-11-22 02:15:40 <dalias> ix, env does not override make vars
2020-11-22 02:16:55 <ix> ah right, and env is baked in during configure step. but you get the idea
2020-11-22 02:17:02 <ix> it is certainly possible, just would be annoying as fuck
2020-11-22 02:17:14 <dalias> make CFLAGS="..." works however
2020-11-22 02:17:18 <dalias> that will replace not extend
2020-11-22 02:17:31 <ix> then we're back to what sh4rm4^bnc said
2020-11-22 02:38:10 <maxice8> !14815
2020-11-22 09:17:50 <mps> do we have 'policy' (heh) for pkgs which contains and installs bash (or other) completion files by default?
2020-11-22 09:19:05 <ikke> mps: we have default functions to create subpackages for them
2020-11-22 09:19:36 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1961
2020-11-22 09:19:47 <mps> ikke: thanks, yes I looked at some pkgs, drbd-utils for example
2020-11-22 09:20:50 <mps> I wanted to ask about "policy to remove them" :)
2020-11-22 09:21:53 <mps> or, seriously, is it ok to remove them if the upstream have it in source and even install them by default
2020-11-22 09:23:10 <ikke> Sorry, not really following you
2020-11-22 09:25:23 <mps> is it 'polite' to remove bash completion when we build apk
2020-11-22 09:25:59 <ikke> I think users expect them to be available
2020-11-22 09:26:14 <mps> (and don't worry, even I sometimes can't follow me)
2020-11-22 09:26:37 <ikke> So we put them in subpackages, so that they are only installed when bash is installed
2020-11-22 09:26:42 <ikke> same for other shells
2020-11-22 09:27:00 <mps> I understand that
2020-11-22 09:27:47 <mps> but not sure is it ok to simply not package it, i.e. remove from final pkg
2020-11-22 09:28:39 <mps> (and some users expect that distro should make coffee for them in the morning)
2020-11-22 09:29:19 <ikke> ttps://gitlab.alpinelinux.org/alpine/aports/-/issues/9929
2020-11-22 09:29:24 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/9929
2020-11-22 09:34:42 <mps> I don't know how to make subpkg, will put bash complete to main pkg
2020-11-22 09:36:29 <mps> here is my (failed) try: https://tpaste.us/d5PJ
2020-11-22 09:38:55 <ikke> mps: You don't need to define it yourself
2020-11-22 09:39:00 <ikke> You just need to declare the subpackage
2020-11-22 09:39:57 <ikke> Unless the default does not what you expect
2020-11-22 09:41:36 <mps> yes, and it doesn't do by default, probably because I don't know how to use bashcomp() (I dislike these helpers in abuild)
2020-11-22 09:48:03 <mps> rnalrd: !14832
2020-11-22 10:03:41 <mps> ikke: if you want to split bashcomp in !14832 please feel free :)
2020-11-22 10:25:02 <mps> maxice8: also you are free (and will be welcomed) to add bashcomp to !14832 :)
2020-11-22 10:25:31 <mps> I tried but it didn't worked and I don't know how to make it work
2020-11-22 10:26:27 <maxice8> I need the error message to know what didn't work
2020-11-22 10:27:54 <mps> let me make it again
2020-11-22 10:30:12 <mps> here it is https://tpaste.us/MQz8
2020-11-22 13:24:13 <mps> new kernels with fixes for powerpc9 (5.9.10 announce https://lore.kernel.org/lkml/1606041227172154@kroah.com/)
2020-11-22 13:25:05 <mps> is this powerpc9 on which we run ppc64le?
2020-11-22 13:25:50 <Ariadne> ppc64le builder is power8 afaik, but i run on power9
2020-11-22 13:26:56 <mps> this fron git log 'powerpc/64s: flush L1D after user accesses'
2020-11-22 13:27:31 <mps> looks serious 'issue'
2020-11-22 13:47:20 <Hello71> CVE-2020-4788
2020-11-22 13:51:10 <Ariadne> yes, that sounds bad
2020-11-22 13:51:44 <Ariadne> if i were to guess, the concern is that you can speculative read into kernel memory upon return from syscall
2020-11-22 13:52:01 <Ariadne> we made the sand too 'smart'
2020-11-22 13:52:33 <skarnet> I hate smart sand, it goes smart everywhere
2020-11-22 13:57:40 <detha> Wait until we get self-learning sand. There was an article from a few Intel fellows who want to start using ML for branch prediction
2020-11-22 13:58:01 <mps> we have to remove perl-db_file deps from spamassasin and amavis
2020-11-22 14:05:49 <Hello71> Ariadne: i don't think that's right. there's only two commits here: flush on entry, and flush after user access. i think here they are only worried about speculative kernel execution based on user controlled cache contents
2020-11-22 14:06:09 <Ariadne> oh, i did not look at the email
2020-11-22 14:06:15 <Ariadne> just the one commit mps mentioned
2020-11-22 14:07:29 <mps> both are suspicious but one I mentioned looks worse to me, though not sure how this works on ppc
2020-11-22 14:08:48 <Hello71> really they're the same vuln, but if you insist on ranking them, "flush on entry" is obviously more important
2020-11-22 14:10:06 <Hello71> I guess unless some kernel thread does user accesses? seems unlikely
2020-11-22 14:10:47 <Ariadne> either way, smart sand is bad sand
2020-11-22 14:11:31 <Hello71> Ariadne: just disable speculation then? :p
2020-11-22 14:11:44 <Ariadne> not possible ;/
2020-11-22 14:37:48 <Ariadne> i did the fat tzdata workaround for now
2020-11-22 14:38:00 <Ariadne> we should figure out why non-fat tzdata fails on musl though
2020-11-22 14:46:33 <ikke> Ariadne: Ah, I see you just switch tzdata to the fat format
2020-11-22 14:46:40 <Ariadne> yes
2020-11-22 14:46:46 <Ariadne> i made an executive decision :P
2020-11-22 14:46:48 <ikke> Heh
2020-11-22 14:46:54 <ikke> I noticed because I had an MR open that did the same :P
2020-11-22 14:46:57 <Ariadne> because tons of people were getting hit by this bug
2020-11-22 14:47:03 <ikke> yes
2020-11-22 14:47:08 <Ariadne> and complaining about it on like everything
2020-11-22 14:48:27 <ikke> But is this a bug in musl we are hitting, or why is the slim format causing issues?
2020-11-22 14:51:46 <ikke> hmm, xlat/inet_protocols.h:239:1: error: static assertion failed: "IPPROTO_MAX != 256" on strace
2020-11-22 14:53:55 <ikke> (on aarch64)
2020-11-22 14:54:19 <Ariadne> either the slim format is wrong, or musl is wrong
2020-11-22 14:54:24 <Ariadne> who knows for sure :)
2020-11-22 14:55:32 <Ariadne> i just read things like "tons of people with home assistant are broken" and decided perhaps we should enable these projects to push OTA updates to their devices to fix these issues caused by tzdata
2020-11-22 15:12:35 <ikke> xlat/inet_protocols.h:241:9: note: '#pragma message: IPPROTO_MAX: 263'
2020-11-22 15:12:41 <ikke> hmm
2020-11-22 15:12:59 <ikke> xlat/inet_protocols.h:241:9: note: '#pragma message: IPPROTO_MAX: 263'
2020-11-22 15:13:02 <ikke> oops
2020-11-22 15:13:13 <ikke> IPPROTO_MPTCP           262
2020-11-22 15:32:07 <dalias> what is this fat thing?
2020-11-22 15:32:44 <ikke> dalias: tzdata switched from a 'fat' format to a 'thin' format to reduce space
2020-11-22 15:33:05 <dalias> *sigh*
2020-11-22 15:33:24 <ikke> which is causing issues in all kinds of situations apparently
2020-11-22 15:33:24 <dalias> well thats obviously not supported automagically
2020-11-22 15:33:47 <ikke> dalias: it is (not verified) apparently working in edge
2020-11-22 15:33:59 <dalias> ?
2020-11-22 15:34:15 <dalias> link for info?
2020-11-22 15:34:29 <ikke> was looking into it
2020-11-22 15:36:08 <ikke> dalias: this seems to have a lot of context: https://stackoverflow.com/a/64477052/20261
2020-11-22 15:36:27 <dalias> oh its go..
2020-11-22 15:36:33 <ikke> Not only go
2020-11-22 15:36:37 <ikke> date is affected as well
2020-11-22 15:36:44 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12057
2020-11-22 15:37:21 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12090
2020-11-22 15:37:26 <ikke> (that one is go)
2020-11-22 15:39:21 <dalias> how is date affected? doesnt it use libc??
2020-11-22 15:39:51 <ikke> with the slim format, date shows an incorrect time for certain timezones
2020-11-22 15:39:59 <ikke> (probably DST related)
2020-11-22 15:40:34 <ikke> Before:
2020-11-22 15:40:37 <ikke> / # TZ=Europe/Berlin date
2020-11-22 15:40:39 <ikke> Fri Nov 20 17:41:26  2020
2020-11-22 15:40:44 <ikke> After:
2020-11-22 15:40:47 <ikke> / # TZ=Europe/Berlin date
2020-11-22 15:40:49 <ikke> Fri Nov 20 18:44:09 CET 2020
2020-11-22 15:40:58 <ikke> Where after is the correct time
2020-11-22 15:41:17 <dalias> is this coreutils?
2020-11-22 15:41:23 <dalias> or bb?
2020-11-22 15:41:25 <ikke> bb date
2020-11-22 15:41:53 <dalias> weird it def doesnt use zi manually
2020-11-22 15:42:02 <dalias> so is there a libc bug?
2020-11-22 15:42:06 <ikke> I have no clue
2020-11-22 15:42:33 <dalias> i wish stuff like this got reported :p
2020-11-22 15:43:07 <ikke> I was not sure whether this was even related to musl
2020-11-22 15:44:20 <dalias> do you have a clear idea what thin means?
2020-11-22 15:44:30 <ikke> I read it somewhere
2020-11-22 15:44:33 <ikke> trying to find it again
2020-11-22 15:44:48 <dalias> my best guess is omitting future dst trsnsitions
2020-11-22 15:45:07 <dalias> and letting the posix form fsllback rule govern them
2020-11-22 15:45:55 <ikke> https://mm.icann.org/pipermail/tz-announce/2019-July/000056.html
2020-11-22 15:45:58 <ikke> "Changes to code"
2020-11-22 15:47:02 <ikke> "Fat format attempts to work around bugs or incompatibilities in older software, notably software that mishandles 64-bit TZif data or uses obsolete TZ strings like "EET-2EEST" that lack DST rules. Slim format is more efficient and does not work around 64-bit bugs or obsolete TZ strings."
2020-11-22 15:50:10 <dalias> *sigh* no clear technical def
2020-11-22 16:18:59 <mps> why git can't '--follow' moves from repos in aports
2020-11-22 16:20:47 <ikke> It can
2020-11-22 16:20:55 <ikke> I use that from time to time
2020-11-22 16:21:15 <ikke> (Unless the file is changed significantly at the same time)
2020-11-22 16:22:50 <mps> yes, I forgot it is only to follow files
2020-11-22 17:25:15 <Hello71> dalias: apparently it means a number of things
2020-11-22 17:25:57 <Hello71> roughly seven things
2020-11-22 17:26:45 <Hello71> https://github.com/eggert/tz/blob/master/zic.c "want_bloat"
2020-11-22 17:39:21 <dalias> ikke, do you have the slim version of the Berlin zoneinfo known to break for me to test with?
2020-11-22 17:41:32 <ikke> dalias: let me check
2020-11-22 17:48:51 <ikke> sadly not anymore
2020-11-22 17:49:06 <ikke> I can recompile it with slim again
2020-11-22 17:49:27 <dalias> ok
2020-11-22 17:49:36 <dalias> if you can send me the zone binary i can debug it
2020-11-22 17:52:00 <ikke> dalias: in the mean time, could you check if this makes sense? https://tpaste.us/qgPB
2020-11-22 18:02:24 <dalias> hmm, that's a good question. why was it 256 before?
2020-11-22 18:02:42 <dalias> if the field were only 8 bit we couldnt have a new one, but also 255 would be the max not 256
2020-11-22 18:03:16 <ikke> dalias: I think because the previous max protocol value was 255, and it seems to be last +1
2020-11-22 18:03:40 <ikke> in the strace source, I see they added the new proto but didn't update the max
2020-11-22 18:03:49 <ikke> but in musl, it is updated, so the build fails
2020-11-22 18:04:08 <dalias> indeed the iphdr on the wire is 8bit proto
2020-11-22 18:04:14 <dalias> so i dont understand how there's a new one >255
2020-11-22 18:04:29 <dalias> but changing the macro is wrong when they assert == with libc header
2020-11-22 18:04:42 <dalias> if this max isn't actually something that needs to be 0 the assert should just be removed
2020-11-22 18:05:03 <ikke> Apparently they auto generate these assertions
2020-11-22 18:06:56 <dalias> well max should be removed from the generation
2020-11-22 18:07:00 <dalias> if it can vary
2020-11-22 18:07:08 <dalias> otherwise the patch makes it not build with older musl or glibc
2020-11-22 18:07:21 <dalias> also maybe we should not have changed max
2020-11-22 18:07:26 <ikke> yes, understood, it would only make sense on edge
2020-11-22 18:07:36 <ikke> ie, not something that could be upstreamed
2020-11-22 18:07:39 <dalias> if it's supposed to be the wire-level one and not whatever weird thing linux added
2020-11-22 18:08:04 <dalias> i would raise it with strace in context that you're not sure if the musl change is right or wrong and see what they say
2020-11-22 18:08:09 <dalias> they might have more insight
2020-11-22 18:08:12 <ikke> ok, will do
2020-11-22 18:08:22 <ikke> right now it's failing to build on our 3.13 builders
2020-11-22 18:10:14 <ikke> dalias: regarding the tzdata thing, it might even matter what arch it's run on
2020-11-22 18:12:01 <dalias> oh?
2020-11-22 18:12:11 <dalias> is there a reason you think that?
2020-11-22 18:12:56 <ikke> I just tried it on x86_64 and it was working
2020-11-22 18:13:05 <ikke> now trying it again on armv7, and it shows the incorrect time
2020-11-22 18:14:31 <ikke> trying it on x86 now
2020-11-22 18:16:24 <Ariadne> likely related to ilp32 then
2020-11-22 18:16:27 <dalias> i dont see any plausible cause for it to be arch dependent. but mayeb 32-/64 bit
2020-11-22 18:16:35 <ikke> yes, 32-bits
2020-11-22 18:16:39 <ikke> x86 shows the error as well
2020-11-22 18:17:30 <Ariadne> anyway theres no rush on it we have a workaround pushed out already
2020-11-22 18:18:08 <dalias> ariadne, that's really not a good take
2020-11-22 18:18:25 <ikke> dalias: How should I provide the binary file?
2020-11-22 18:18:53 <dalias> this is indicative of a zoneinfo parse bug and you're just papering over it
2020-11-22 18:19:12 <Ariadne> dalias: i agree, i am just saying, there are probably more urgent issues
2020-11-22 18:20:19 <dalias> ikke, dcc, email, temp web link, whatever
2020-11-22 18:20:45 <ikke> ah, have an idea
2020-11-22 18:25:03 <dalias> ?
2020-11-22 18:25:11 <ikke> dalias: https://dev.alpinelinux.org/archive/Berlin
2020-11-22 18:29:04 <dalias> maybe it's not musl but a zic bug? this file is only 705 bytes and file(1) says:
2020-11-22 18:29:07 <dalias> Berlin: timezone data, version 2, no gmt time flags, no std time flags, no leap seconds, no transition times, 1 abbreviation char
2020-11-22 18:29:28 <dalias> is that correct?
2020-11-22 18:29:42 <dalias> is there a reverse-zic to dump the contents of the binary file?
2020-11-22 18:30:40 <dalias> it seems to work tho
2020-11-22 18:30:44 <dalias> whats your testcase?
2020-11-22 18:30:50 <ikke> dalias: zdump?
2020-11-22 18:31:04 <ikke> TZ=Europe/Berlin date
2020-11-22 18:31:14 <ikke> in a docker container
2020-11-22 18:31:19 <ikke> but on 3.12
2020-11-22 18:31:43 <ikke> let me test edge
2020-11-22 18:32:02 <dalias> what's expected output? i dont have alpne 32bit but this is on my own system
2020-11-22 18:32:26 <ikke> The time should match CET
2020-11-22 18:32:33 <ikke> When it's wrong, it's one hour off for me
2020-11-22 18:32:56 <ikke> so now, 18:32 would be wrong, 19:32 would be right
2020-11-22 18:33:16 <dalias> $ TZ=./Berlin date
2020-11-22 18:33:16 <dalias> Sun Nov 22 19:33:12 CET 2020
2020-11-22 18:33:42 <Ariadne> yes, it is wrong on 32-bit
2020-11-22 18:33:52 <dalias> this is 32-bit
2020-11-22 18:34:32 <Ariadne> people are reporting this against 3.12 (which is musl 1.1 still)
2020-11-22 18:34:36 <ikke> dalias: on edge it seems to work for me
2020-11-22 18:34:38 <ikke> yes
2020-11-22 18:34:45 <Ariadne> perhaps musl 1.2 fixed it
2020-11-22 18:35:46 <dalias> could it be the overlong name parsing thing? that was the only fix afaik
2020-11-22 18:36:16 <ikke> I tried 2 tz related patches on musl, but they didn't seem to have fixed it
2020-11-22 18:36:37 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14763/diffs
2020-11-22 18:40:24 <dalias> hmm so what could be going wrong where i can't see it?
2020-11-22 18:40:41 <dalias> i guess i can try building with old musl
2020-11-22 18:41:41 <dalias> since it's pre-time64 i cant just run with it, need to rebuild with time32 headers
2020-11-22 18:44:01 <dalias> ok indeed 1.1.24 is broken
2020-11-22 18:48:10 <ikke> dalias: "MPTCP does not have a protocol number allocated because MPTCP packets use the TCP protocol number. Use private number not used OTA."
2020-11-22 18:48:28 <ikke> So seems like IPPROTO_MAX should not have been increased
2020-11-22 18:48:42 <ikke> https://lore.kernel.org/netdev/20191213230022.28144-4-mathew.j.martineau@linux.intel.com/
2020-11-22 18:51:23 <ikke> dalias: hmm, but IPPROTO_MAX follows IPPROTO_MTCP, so it should be 263 then, right?
2020-11-22 18:59:05 <dalias> i dunno
2020-11-22 18:59:17 <ikke> In an enum
2020-11-22 18:59:50 <ikke> https://github.com/torvalds/linux/blob/master/tools/include/uapi/linux/in.h#L81
2020-11-22 19:03:25 <dalias> ikke, zdump on this zi file looks bogus
2020-11-22 19:03:38 <dalias> but it somehow works on current musl and 64-bit ..?
2020-11-22 19:09:18 <ikke> yup
2020-11-22 19:18:10 <dalias> ok this is weird, zi file is getting loaded wrong in old musl
2020-11-22 19:18:12 <dalias> but i dont know why
2020-11-22 19:18:27 <dalias> lol
2020-11-22 19:18:42 <dalias> if (sizeof(time_t) > 4 && map[4]=='2')
2020-11-22 19:18:48 <dalias> this gets used now :)
2020-11-22 19:19:33 <ikke> due to timet_64
2020-11-22 19:19:38 <dalias> ok this is incredibly stupid and they did not document this right in the zi update
2020-11-22 19:19:52 <dalias> zi files have 2 versions of the table, a 32-bit one and a 64-bit one
2020-11-22 19:20:27 <dalias> and on 32-bit systems we used the 32-bit one because it's presumably more efficient or something
2020-11-22 19:20:37 <dalias> but zi just removed the 32-bit copy of the table
2020-11-22 19:20:47 <dalias> so it's empty if processed as 32-bit
2020-11-22 19:20:51 <ikke> ugh
2020-11-22 19:21:17 <dalias> by my reading this is an invalid zone file
2020-11-22 19:21:33 <dalias> as specified in the format, the 32-bit part must agree with the 64-bit copy for the time range it covers
2020-11-22 19:21:38 <Ariadne> alpine uses its own six
2020-11-22 19:21:41 <Ariadne> zic
2020-11-22 19:21:42 <Ariadne> even
2020-11-22 19:22:14 <dalias> i.e. there's a contract that you can use the 32-bit table for speed if the  value fits in 32 bits
2020-11-22 19:22:22 <dalias> even if your time_t is 64-bit
2020-11-22 19:22:29 <dalias> not that it really matters
2020-11-22 19:22:38 <dalias> anyway to patch old musl:
2020-11-22 19:22:40 <dalias> - if (sizeof(time_t) > 4 && map[4]=='2')
2020-11-22 19:22:45 <dalias> + if (map[4]=='2')
2020-11-22 19:22:48 <dalias> hopefully fixes it
2020-11-22 19:23:00 <hg> well, Atkinson Hyperlegible has a license officially published for it now
2020-11-22 19:23:03 <hg> … it's gross
2020-11-22 19:23:10 <hg> but it's at least packageable
2020-11-22 19:25:05 <dalias> ?
2020-11-22 19:25:12 <dalias> the license is gross?
2020-11-22 19:25:52 <hg> dalias: it's very custom, surprisingly permissive and restrictive at the same time, and provided only as a PDF
2020-11-22 19:25:56 <hg> so yeah, pretty gross :)
2020-11-22 19:26:10 <dalias> neat, this font is very close in glyph forms to my ytty
2020-11-22 19:27:00 <hg> dalias: it looks like a phenomenal font for accessibility
2020-11-22 19:27:05 <dalias> yes
2020-11-22 19:27:07 <hg> (one of the reasons I want to package it)
2020-11-22 19:27:33 <dalias> :)
2020-11-22 19:29:11 <dalias> ariadne, so i'd recommend that patch for old musl -- always use new 64-bit table if present
2020-11-22 19:35:39 <Ariadne> hg: please link to the license pdf
2020-11-22 19:35:56 <Ariadne> dalias: ok i’ll backport it tomorrow
2020-11-22 19:38:04 <Ariadne> looks like the license is fine
2020-11-22 19:38:44 <hg> Ariadne: https://www.brailleinstitute.org/wp-content/uploads/2020/11/Atkinson-Hyperlegible-Font-License-2020-1104.pdf
2020-11-22 19:38:59 <hg> I mean, it's fine to package
2020-11-22 19:39:18 <hg> ikke: so, it seems I get that error on trying to build any package now…
2020-11-22 19:39:31 <hg> ikke: so, I think I did something to mess up my env, though I'm not sure what…
2020-11-22 19:40:01 <Ariadne> yes the license seems fine
2020-11-22 19:40:09 <hg> (to package) :)
2020-11-22 19:40:13 <hg> it's still gross, imo :)
2020-11-22 19:40:31 <Ariadne> i don’t see any legal problems with the license
2020-11-22 19:40:52 <ikke> sorry, what error?
2020-11-22 19:40:59 <Ariadne> it basically says you can do whatever you want as long as modified fonts are named something else
2020-11-22 19:41:23 <Ariadne> seems like a pretty standard font license really
2020-11-22 19:41:25 <hg> Ariadne: yeah, I'm just really wary of hand-written licenses
2020-11-22 19:41:36 <hg> like, why not just the OFL?
2020-11-22 19:41:46 <hg> ikke: one sec
2020-11-22 19:42:23 <hg> ikke: ERROR: no such package: .makedepends-<whatever the name of the package is I'm trying to build>
2020-11-22 19:42:33 <Ariadne> maybe you should write to them and propose they relicense under OFL
2020-11-22 19:45:03 <ikke> hg: You need to check the entire build output
2020-11-22 19:46:03 <hg> Ariadne: they don't have a place to write to them as far as I know (just phone call; which makes some sense given the institution); but I gave them a call a while back asking them to provide a license in the first place
2020-11-22 19:46:12 <hg> they never returned my call, but did add the license
2020-11-22 19:46:18 <hg> so, that's something
2020-11-22 19:46:40 <hg> I may well call and leave another message
2020-11-22 19:46:48 <hg> I'd love it if it would just be OFL
2020-11-22 19:46:52 <hg> way less concerning to me
2020-11-22 19:47:02 <hg> ikke: here, I'll paste it; one sec
2020-11-22 19:49:03 <hg> https://tpaste.us/5VkE
2020-11-22 19:49:07 <hg> ikke: ^
2020-11-22 19:50:32 <ikke> >>> ERROR: otf-atkinson-hyperlegible: builddeps failed
2020-11-22 19:51:40 <hg> it doesn't have any makedeps
2020-11-22 19:51:44 <hg> I'm not familiar with builddeps
2020-11-22 19:52:12 <ikke> How does your apkbuild look like?
2020-11-22 19:52:42 <hg> ikke: https://tpaste.us/vZyZ
2020-11-22 19:53:05 <hg> ikke: worth noting that this now happens for all packages I try to build
2020-11-22 19:53:18 <hg> so, probably not something to do with the specific APKBUILD
2020-11-22 19:55:00 <ikke> ok
2020-11-22 19:55:02 <ikke> run apk fix
2020-11-22 19:55:56 <hg> huh
2020-11-22 19:56:09 <hg> okay, I think that helped me figure it out
2020-11-22 19:56:18 <hg> I'll investigate more in a minute
2020-11-22 19:57:15 <hg> cool
2020-11-22 19:57:16 <hg> yeah
2020-11-22 19:57:44 <Hello71> dalias: IPPROTO_MPTCP > IPPROTO_MAX because it's not really a wire protocol number, since that's still IPPROTO_TCP. MPTCP is signalled on the wire by TCP options
2020-11-22 19:58:02 <Hello71> now, as to why they shoehorned it in there instead of using IPPROTO_TCP and setsockopt, i dunno
2020-11-22 19:58:05 <dalias> *nod*
2020-11-22 19:58:31 <dalias> at the OS API level you probably want it to look like a protocol
2020-11-22 19:58:43 <ikke> Hello71: that commit message gave some background
2020-11-22 19:58:46 <ikke> (patch)
2020-11-22 19:58:53 <ikke> https://lore.kernel.org/netdev/20191213230022.28144-4-mathew.j.martineau@linux.intel.com/
2020-11-22 19:59:24 <Hello71> well, it explains why there's a new number, and it sort of explains why it's more than 8 bits
2020-11-22 19:59:31 <hg> hooray, otf-atkinson-hyperlegible submitted
2020-11-22 19:59:39 <Hello71> but it doesn't explain why they didn't use setsockopt or some other interface
2020-11-22 19:59:44 <hg> ikke: is there a general process to move something from testing into community?
2020-11-22 20:00:05 <ikke> Well, the custom license might be an issue
2020-11-22 20:00:26 <ikke> hmm, Ariadne said the license is fine
2020-11-22 20:01:15 <Hello71> what does "The Font and derivatives, however, cannot be released under any other type of license." mean
2020-11-22 20:02:16 <hg> ikke: I was specifically asking about that process generally
2020-11-22 20:02:32 <hg> ikke: and, if the package isn't accepted into aports, that's fine (the license really is rather strange imo)
2020-11-22 20:02:48 <hg> ikke: figured I'd still propose it (if accessibility can be improved for anyone, I'd like to)
2020-11-22 20:04:33 <dalias> hello71, rather meaningless i think; not being able to sublicense under a different license is the norm/default
2020-11-22 20:04:49 <ikke> hg: moving it to community is generally just a matter of making a new merge request to move it
2020-11-22 20:04:56 <dalias> i suspect whoever wrote the license doesnt know what they're doing tho :-p
2020-11-22 20:05:17 <hg> ikke: is there an expected time to wait or anything?
2020-11-22 20:05:30 <hg> dalias: yeah… that's one of the reasons hand-written licenses worry me
2020-11-22 20:05:33 <Hello71> oh, they copied that from the OFL
2020-11-22 20:05:59 <hg> Hello71: that wording, or the whole text?
2020-11-22 20:06:05 <hg> I'd be really surprised if the whole text
2020-11-22 20:07:08 <Hello71> well, most of it
2020-11-22 20:07:28 <hg> but it's not the whole text of the OFL
2020-11-22 20:08:12 <hg> oh wait
2020-11-22 20:08:13 <hg> is it?
2020-11-22 20:08:16 <hg> hold on
2020-11-22 20:08:36 <Hello71> eh, they took it and modified it slightly
2020-11-22 20:08:59 <Hello71> (ironically i think it might count as plagiarism, but meh)
2020-11-22 20:09:50 <hg> yeah, explicitly not
2020-11-22 20:09:58 <hg> Hello71: yeah…
2020-11-22 20:10:02 <hg> definitely bad form
2020-11-22 20:10:43 <dalias> heh
2020-11-22 20:26:12 <Ariadne> Hello71: it means you cannot change the license of it.  in the same way that you can't change a GPL program's license to Apache 2.0 for example.
2020-11-22 20:59:16 <hg> yeah, I'm gonna request that not be merged
2020-11-22 20:59:29 <Ariadne> ?
2020-11-22 20:59:32 <Ariadne> why
2020-11-22 20:59:33 <hg> I'll give them a call and ask them to instead license under the OFL the way they should have
2020-11-22 20:59:37 <Ariadne> the license is OK
2020-11-22 21:00:07 <Ariadne> i mean, that is even better, but alpine can accept under current license
2020-11-22 21:00:24 <hg> Ariadne: it's nearly a copy of the OFL with a few things removed/reworded
2020-11-22 21:00:30 <hg> that's really bad form
2020-11-22 21:00:36 <hg> like, I'll leave it, I suppose
2020-11-22 21:00:44 <hg> but I'd really prefer they license it correctly
2020-11-22 21:01:14 <Ariadne> yes it would be nice to be able to just mark it OFL
2020-11-22 21:04:01 <hg> lol
2020-11-22 21:06:42 <hg> Ariadne: formatting fix pushed
2020-11-22 21:10:19 <hg> excellent, I now have my own local copy of youtube-dl-git-bin
2020-11-22 21:10:22 <hg> 😀
2020-11-22 21:12:51 <ikke> it's merged
2020-11-22 21:13:29 <hg> I saw that
2020-11-22 21:13:35 <hg> thank you, Ariadne
2020-11-22 21:44:40 <Ariadne> i guess tomorrow or next day, i will need to make a blitz
2020-11-22 21:44:56 <Ariadne> and mask KDE on s390x and mips
2020-11-22 21:45:00 <Ariadne> due to lack of rust bootstrap
2020-11-22 21:48:27 <dalias> :(
2020-11-22 21:48:34 <dalias> kde now needs rust?
2020-11-22 21:52:41 <Hello71> at a guess, kde -> polkit -> spidermonkey -> rust
2020-11-22 21:53:32 <hg> anyone packaged polkit-noscript yet?
2020-11-22 21:53:37 <hg> 
ACTION searches

2020-11-22 21:55:29 <dalias> lol
2020-11-22 21:55:32 <hg> doesn't look like it
2020-11-22 21:55:37 <hg> dalias: you laugh, but it is a thing
2020-11-22 21:55:53 <hg> I have it on my arch machines
2020-11-22 21:56:02 <dalias> no i mean the dep getting pulled in because polkit is running a fucking javascript engine to manage who can access its backdoors
2020-11-22 21:56:05 <hg> because the concept of having a globally-installed js interpreter makes my skin crawl
2020-11-22 21:56:14 <dalias> just rip out polkit and make kde work without backdoors to root
2020-11-22 21:56:33 <hg> dalias: I think that is a better (though more difficult) solution
2020-11-22 21:56:39 <hg> polkit-noscript is a nice interim though
2020-11-22 21:56:55 <dalias> can't it just be built --without-polkit or something ?
2020-11-22 21:57:10 <dalias> surely non-linux systems kde can run on dont use polkit
2020-11-22 21:57:25 <dalias> what does polkit-noscript do?
2020-11-22 21:57:33 <dalias> presumably it's just a stubbed out polkit
2020-11-22 21:57:41 <dalias> since you need the js interpreter to actually do anything
2020-11-22 21:57:52 <dalias> but i have no idea why they run spidermonkey there to begin with
2020-11-22 21:58:04 <dalias> ducktape should work just as well for polkit's purposes
2020-11-22 21:58:14 <dalias> at 0.00001% of the size and complete portability
2020-11-22 22:00:15 <hg> dalias: polkit-noscript allows you to define rules in a different way
2020-11-22 22:02:01 <hg> don't really know how
2020-11-22 22:02:05 <hg> some magical systemd thing
2020-11-22 22:02:24 <hg> https://github.com/getsolus/polkit-no-script
2020-11-22 22:02:27 <dalias> but i mean it wont work with existing policy files
2020-11-22 22:02:44 <dalias> so unless you add your own, presumably it's non-functional and closes off the backdoors
2020-11-22 22:02:57 <dalias> which is a *good thing*
2020-11-22 22:03:35 <hg> not sure, I'm afraid
2020-11-22 22:03:42 <hg> it won't load the js ones, for sure
2020-11-22 22:03:45 <dalias> :)
2020-11-22 22:03:46 <Hello71> fwiw I don't actually know for sure that kde requires polkit
2020-11-22 22:03:59 <Hello71> I heard that gnome does and am speculating that kde might too
2020-11-22 22:04:31 <ikke> well, lots of things don't built atm on s390x due to lack of polkit
2020-11-22 22:04:34 <ikke> (kde related)
2020-11-22 22:04:36 <hg> Hello71: still, we should tear down all things that are trying to put js in the core system
2020-11-22 22:04:42 <hg> 😀
2020-11-22 22:05:14 <hg> I wonder if any distro installs js setuid
2020-11-22 22:05:26 <hg> the thought makes me want to vomit
2020-11-22 22:07:32 <dalias> ?
2020-11-22 22:07:53 <dalias> ikke, i like hg's idea of packaging polkit-noscript
2020-11-22 22:08:10 <dalias> ideally it should be the default dep pulled in for stuff that wants polkit
2020-11-22 22:08:21 <ikke> doesn't sound like a bad idea
2020-11-22 22:08:25 <dalias> and real polkit should be an alternate "provides" for it that you can install manually
2020-11-22 22:08:42 <hg> I agree
2020-11-22 22:08:42 <dalias> this would avoid getting the unwanted rootkit pulled in for users who don't want a backdoored system
2020-11-22 22:08:47 <hg> haha
2020-11-22 22:09:22 <dalias> seriously, i was angry when i found that shit installed and purged stuff til it was gone
2020-11-22 22:09:35 <dalias> xfce-power-monitor or something was what pulled it in
2020-11-22 22:10:13 <dalias> there is utterly no way the presence of polkit is not equivalent to local root
2020-11-22 22:10:17 <ikke> but is polkit-noscript a drop-in replacement?
2020-11-22 22:10:39 <dalias> i would assume it provides the equivalent dbus service interface
2020-11-22 22:10:55 <Hello71> seems unmaintained
2020-11-22 22:11:03 <dalias> :/
2020-11-22 22:11:21 <dalias> since its a dbus service i dont understand how it's actually a dep anyway
2020-11-22 22:11:47 <dalias> shouldn't it just be more like "we expect this service to be installed and running and try to contact it, but if we can't, run anyway" ?
2020-11-22 22:11:59 <dalias> in which case packaging it as a dep is just wrong
2020-11-22 22:12:05 <dalias> it's more like a debian suggests or recommends
2020-11-22 22:12:22 <dalias> it should only be a dep if ldso errors out when it's not installed
2020-11-22 22:12:40 <hg> Hello71: indeed, I'm afraid
2020-11-22 22:13:21 <dalias> anyway it's probably real polkit forked from before they switched from their xml-based dsl to javascript
2020-11-22 22:13:25 <dalias> which is still horrible
2020-11-22 22:13:32 <dalias> the right replacement would be a polkit-stub
2020-11-22 22:13:45 <dalias> that listens on the dbus service address and just says "fuck no" to every request
2020-11-22 22:13:51 <Ariadne> i agree with dalias and hg there
2020-11-22 22:13:53 <hg> its format is similar to other systemd-style rules
2020-11-22 22:13:56 <hg> 🤷
2020-11-22 22:14:03 <Ariadne> lets shoot polkit in the head
2020-11-22 22:14:04 <hg> no idea when it came about or if it was added custom replacing the js interface
2020-11-22 22:14:07 <hg> Ariadne: lol
2020-11-22 22:14:09 <Ariadne> and use this alternative implementation
2020-11-22 22:14:21 <dalias> is it really an alt implementation?
2020-11-22 22:14:28 <dalias> or just a fork of an old version?
2020-11-22 22:14:41 <Ariadne> probably a fork
2020-11-22 22:14:41 <dalias> because the latter, especially if unmaintained, sounds like a deadend
2020-11-22 22:14:49 <dalias> it will have unpatched vulns
2020-11-22 22:14:55 <dalias> because polkit is full of vulns
2020-11-22 22:15:00 <Ariadne> maybe i should just write a new implementation
2020-11-22 22:15:06 <dalias> ariadne, see what i just said
2020-11-22 22:15:18 <dalias> ideal behavior is just listening on the dbus service address
2020-11-22 22:15:23 <dalias> and saying "no" for every requesst
2020-11-22 22:15:37 <dalias> you don't even need to be able to parse the requests afaik
2020-11-22 22:15:53 <Ariadne> is that really feasible these days?
2020-11-22 22:15:56 <dalias> just respond with "no"
2020-11-22 22:15:59 <Ariadne> i thought udisks and shit needed working polkit
2020-11-22 22:16:00 <dalias> sure
2020-11-22 22:16:06 <Ariadne> to work as expected
2020-11-22 22:16:24 <Ariadne> because i do value the fact that i can plug an SD card in and it "just works"
2020-11-22 22:16:24 <dalias> well if you want that functionality you install the real polkit
2020-11-22 22:16:46 <dalias> the way i plug in sd card and have it just work is a tiny udev script
2020-11-22 22:16:53 <Ariadne> anyway
2020-11-22 22:16:55 <dalias> no polkit involved
2020-11-22 22:16:58 <Ariadne> the problem there is
2020-11-22 22:17:01 <Ariadne> you still need polkit-dev
2020-11-22 22:17:17 <dalias> :/
2020-11-22 22:17:33 <dalias> well isn't the problem that the package isn't factored right?
2020-11-22 22:17:42 <Ariadne> no
2020-11-22 22:17:46 <dalias> there's nothing wrong with having the client lib or whatever the dev files are
2020-11-22 22:17:56 <dalias> the problem is having the dbus service side of it installed
2020-11-22 22:17:58 <Ariadne> i dont think it is possible ot just build "the client lib"
2020-11-22 22:18:08 <dalias> it should be..
2020-11-22 22:18:15 <dalias> the build system might make it hard
2020-11-22 22:18:34 <dalias> but i think it can be done. there's probably even a separate make (or meson or whatever) target for it
2020-11-22 22:18:51 <dalias> problem might be the configure stage
2020-11-22 22:18:54 <Ariadne> i'll look into it
2020-11-22 22:19:07 <dalias> where they look for spidermonkey etc
2020-11-22 22:19:21 <dalias> bypassing that is probably the hard part
2020-11-22 22:19:21 <Ariadne> but i think we could just make polkit work against duktape
2020-11-22 22:19:29 <dalias> after that, building client lib should be easy
2020-11-22 22:19:38 <dalias> well these are two separate issues
2020-11-22 22:19:50 <dalias> one is debloating and making it portable to non-x86+arm archs
2020-11-22 22:20:03 <dalias> the other is getting rid of the auto-installed rootkit
2020-11-22 22:20:28 <Ariadne> yes, agree
2020-11-22 22:21:17 <Ariadne> https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35.patch
2020-11-22 22:21:27 <Ariadne> this seems to be everything needed
2020-11-22 22:21:44 <dalias> :)
2020-11-22 22:22:33 <dalias> hmm found another thing in zoneinfo parser: i don't think it's future-proof
2020-11-22 22:22:34 <Ariadne> we will investigate that for 3.14
2020-11-22 22:22:40 <dalias> it looks for =='2'
2020-11-22 22:22:52 <dalias> but probably needs to be >='2' or such
2020-11-22 22:23:03 <dalias> otherwise if v3 ever happens it'll start processing it like v1
2020-11-22 22:23:17 <dalias> and using the empty 32-bit table
2020-11-22 22:23:19 <Ariadne> ncopa: we're talking about that microkubelet stuff btw, LKL looks promising as a starting place for it
2020-11-22 22:23:48 <ikke> LKL?
2020-11-22 22:23:58 <Ariadne> linux kernel as unikernel library
2020-11-22 22:24:06 <Ariadne> essentially UML done right
2020-11-22 22:25:50 <ikke> https://github.com/lkl/linux
2020-11-22 22:26:15 <Ariadne> you get a liblkl.so, that you can link your application against
2020-11-22 22:26:20 <Ariadne> its really neat
2020-11-22 22:28:59 <mps> wsl on other OSes?
2020-11-22 22:30:08 <dalias> what does it do tho?
2020-11-22 22:31:47 <dalias> i have a feeling signal api doesn't work right :-p
2020-11-22 22:32:10 <mps> fake kernel
2020-11-22 22:32:15 <Ariadne> not fake kernel
2020-11-22 22:32:17 <Ariadne> real kernel
2020-11-22 22:32:40 <Ariadne> you can do things like use the linux filesystem drivers in userspace
2020-11-22 22:32:43 <mps> Ariadne: lib is real kernel?
2020-11-22 22:32:43 <dalias> seems to depend on what your definition of kernel is
2020-11-22 22:32:47 <Ariadne> with FUSE
2020-11-22 22:32:55 <dalias> ariadne, so now link fuse to it? lol
2020-11-22 22:32:56 <dalias> :)
2020-11-22 22:32:59 <Ariadne> yes
2020-11-22 22:33:09 <dalias> that's actually useful
2020-11-22 22:33:11 <Ariadne> or, you can say, pass through a PCI device
2020-11-22 22:33:17 <dalias> now with fuse+user-ns, i can loop-mount
2020-11-22 22:33:20 <Ariadne> and drive a PCI device in userspace
2020-11-22 22:33:24 <dalias> ooh nice
2020-11-22 22:33:30 <dalias> assuming you have iommu...
2020-11-22 22:33:41 <Ariadne> yes, assuming the prerequisites are there
2020-11-22 22:33:57 <Ariadne> point is you have access to all the kernel drivers, syscalls, etc
2020-11-22 22:34:00 <Ariadne> but its in userspace
2020-11-22 22:34:02 <dalias> it seems like a big hammer for this tho
2020-11-22 22:34:06 <dalias> however
2020-11-22 22:34:14 <dalias> it sounds amazing for my kernel :-)
2020-11-22 22:34:41 <Ariadne> another thing you can do is
2020-11-22 22:34:41 <dalias> my proposal for hardware drivers already was "stub out enough of the linux kernel-internal apis that you can run the linux drivers in user processes"
2020-11-22 22:34:55 <Ariadne> bundle your app and LKL together and deploy on hypervisor
2020-11-22 22:34:55 <dalias> but this lets me do that in a way i don't have to maintain :)
2020-11-22 22:35:11 <Ariadne> (e.g. traditional unikernel stuff)
2020-11-22 22:36:05 <Ariadne> and inside the kernel environment, you can have processes, threads, etc
2020-11-22 22:36:18 <Ariadne> so, that gives you everything you need to do something like gVisor
2020-11-22 22:36:42 <Ariadne> except instead of it being a reimplementation, its the actual kernel source
2020-11-22 22:37:02 <dalias> for most of this i'd prefer a reimpl
2020-11-22 22:37:24 <dalias> just the hardware drivers are gigantic O(n) space not practical for reimpl
2020-11-22 22:38:20 <Ariadne> its basically just netbsd rump kernel, but linux instead
2020-11-22 22:38:30 <Ariadne> anything rumpkernel can do, LKL can do
2020-11-22 22:38:32 <dalias> *nod*
2020-11-22 22:39:30 <Ariadne> (and yes, our original usecase was "run linux drivers in userspace on a microkernel", but that's handwavy future stuff)
2020-11-22 22:39:56 <dalias> :)
2020-11-22 22:41:34 <Ariadne> LKL + fuse is an interesting idea though
2020-11-22 22:41:49 <Ariadne> because then you can have userspace filesystem server
2020-11-22 22:42:21 <Ariadne> on top of a slim linux kernel
2020-11-22 22:42:37 <Ariadne> that only has enough to boot
2020-11-22 22:42:55 <Ariadne> you c an also move the networking into userspace with LKL, but that one is a little trickier
2020-11-22 22:43:37 <dalias> main motivation here for userspace fs driver is loop mounts
2020-11-22 22:44:04 <dalias> it's ridiculous that you can't mount ~/foo.ext4 to image it or extract stuff off it
2020-11-22 22:44:21 <mps> (time machine invented, do I read famous Tanenbaum/Torvalds mail from '91 (or it was '90))
2020-11-22 22:44:29 <dalias> of course the reason is sound -- the kernel fs drivers are shit and are huge attack surface if you give them corrupted data structures
2020-11-22 22:44:46 <dalias> but this is awful ux
2020-11-22 22:45:30 <Ariadne> anyway there is already lklfuse
2020-11-22 22:45:38 <dalias> excellent
2020-11-22 22:47:20 <Ariadne> https://github.com/lkl/linux/blob/master/tools/lkl/lklfuse.c :)
2020-11-22 22:48:21 <Hello71> fwiw ext4 finally got an official fuse driver
2020-11-22 22:48:28 <Hello71> in e2fsprogs
2020-11-22 22:49:11 <Ariadne> did reiserfs?
2020-11-22 22:49:11 <Ariadne> :P
2020-11-22 22:49:20 <Hello71> honestly I'm not sure why it took so long, given that debugfs already has all the needed components
2020-11-22 22:49:47 <Ariadne> lklfuse is interesting because you can just compile in all the FS drivers
2020-11-22 22:49:58 <Ariadne> and you have a single fuse server that can handle it
2020-11-22 22:50:00 <Ariadne> :)
2020-11-22 22:51:47 <Ariadne> other usecases for LKL: sound server that drives the soundcard directly
2020-11-22 22:51:56 <Ariadne> e.g. no more ALSA bullshit
2020-11-22 22:52:32 <dalias> :-p
2020-11-22 22:52:55 <dalias> soundserver that writes to a usb raw device directly :-p
2020-11-22 22:53:18 <dalias> folks will probably hate this but my logical device architecture is usb :)
2020-11-22 22:54:26 <dalias> 'driver' for non-usb hardware = translation layer that translates its interface to the standard protocol for its device class
2020-11-22 22:55:17 <dalias> HID, CDC-ACM, CDC-ECM, etc.
2020-11-22 22:56:36 <Ariadne> and what if i want to drive a mellanox 100gb nic on your kernel
2020-11-22 22:56:37 <Ariadne> :)
2020-11-22 22:57:11 <dalias> then you run linux
2020-11-22 22:57:46 <dalias> goal is that you don't need to run huge-attack-surface massively-complex stuff like linux on an embedded system or a personal device
2020-11-22 22:58:31 <dalias> jokes aside there's no reason you *can't* do something different
2020-11-22 22:59:27 <dalias> but the stock network-stack daemon would be built around this principle. you could use a different one (eg running lkl for network stack) if you like
2020-11-22 23:01:26 <Ariadne> interesting.  our end game is to provide a more hardened kernel environment in our downstream product by isolating kernel subsystems into userspace
2020-11-22 23:06:18 <Cogitri> Ariadne: fwiw it is possible to build polkit without polkitd (and as such without the spidermonkey dep), but then you have a libpolkit without a daemon to actually do anything
2020-11-22 23:06:45 <Cogitri> Duktape would certainly be interesting but should probably be another package so we don't pull in two JS engines for GNOME
2020-11-22 23:07:20 <Ariadne> Cogitri: yes i was thinking {polkit-stub, polkit-duktape, polkit-spidermonkey}
2020-11-22 23:07:30 <Cogitri> And a stubbed polkit certainly won't work unless everything that uses it is supposed to break at which point I'd just advise to not install that application?
2020-11-22 23:08:01 <Ariadne> some applications will work without polkit
2020-11-22 23:08:06 <Ariadne> they just wont do privileged things
2020-11-22 23:08:09 <Ariadne> :)
2020-11-22 23:09:16 <Cogitri> So they'll just be semi-broken :/
2020-11-22 23:09:49 <Cogitri> I'm a bit afraid of folks having polkit-stub installed and not being aware of it and then blaming us or even worse upstream on it
2020-11-22 23:10:00 <Ariadne> arguably depending on a javascript-powered rootkit to not be broken is broken in a different way
2020-11-22 23:10:25 <Ariadne> freedesktop.org: not even once
2020-11-22 23:10:56 <Ariadne> but yes i get your point
2020-11-22 23:11:56 <Ariadne> solution there is likely to default to polkit-duktape, then polkit-stub, then polkit-spidermonkey in order of preference
2020-11-22 23:13:49 <Ariadne> Cogitri: ultimately i would like to create an alternative polkit implementation that does not require a javascript engine, instead using something reasonable like config files
2020-11-22 23:18:25 <dalias> cogitri, it's not semi-broken for a non-privileged user's applications not to do privileged things
2020-11-22 23:18:39 <dalias> it's unix working as designed
2020-11-22 23:23:32 <mps> 
ACTION wonders why not allow users to have root rights by default, all problems solved

2020-11-22 23:25:23 <dalias> ...
2020-11-22 23:25:36 <dalias> that's what polkit does :-p
2020-11-22 23:25:54 <mps> :D
2020-11-22 23:44:12 <Cogitri> Ariadne: Sounds like kind of a pain to maintain that alternative implementation unless upstreams switch to it
2020-11-22 23:44:22 <Cogitri> And DEs support it
2020-11-22 23:55:59 <[[sroracle]]> given Ariadne's success in steamrolling pkg-config with pkgconf i would not be worried about that
2020-11-22 23:58:08 <Cogitri> pkgconf is mostly a drop-in replacement though
2020-11-22 23:59:42 <Cogitri> I mean of course I won't (and can't) stop anyone from making a new polkit and polkit certainly isn't too big to fail or something like that
2020-11-23 00:00:26 <Cogitri> But upstreams probably won't adopt a new format and having those files downstream seems a bit risky to me when that can lead to accidental giving root access
2020-11-23 01:13:20 <Hello71> you know, now that I think about it, pkla -> js is basically the opposite of init scripts -> unit files
2020-11-23 01:52:34 <dalias> yeah
2020-11-23 01:52:53 <dalias> the only reason it flew was because the old thing was built on xml and xml is universally hated
2020-11-23 01:53:11 <dalias> i cant believe fontconfig's xml dsl hasn't been nuked yet
2020-11-23 02:35:02 <Hello71> to use javascript instead? :p
2020-11-23 02:35:19 <hg> oooh, good idea
2020-11-23 02:35:23 <hg> 
ACTION vomits

2020-11-23 02:39:17 <insep_> pam seems to be fine with loadable modules, don't see why polkit wouldn't :^)
2020-11-23 02:40:27 <dalias> ...
2020-11-23 03:17:36 <Hello71> programmed in rust of course, for modernization
2020-11-23 03:18:02 <maxice8> fearless concurrent actions as root
2020-11-23 03:18:48 <Hello71> I wonder... polkit implemented as an ebpf filter on setuid(2)...
2020-11-23 03:20:03 <Hello71> i think that's the new hotness
2020-11-23 03:23:54 <dalias> hello71, isn't that already what it is? the null filter...
2020-11-23 03:26:09 <Hello71> i mean that instead of running suid programs or calling a dbus service, you would escalate privileges by calling setuid(2) after preparing some magic dust
2020-11-23 03:45:16 <Hello71> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/8 anyone concerned about xorg ddxs can comment i guess
2020-11-23 03:46:33 <Hello71> new MR: "setup-xorg-base: don't install video DDX"
2020-11-23 07:34:28 <ncopa> good morning
2020-11-23 07:34:31 <ikke> o/
2020-11-23 07:36:39 <ikke> ncopa: what should we doo with tree
2020-11-23 07:36:51 <ikke> For some reason, the builders cannot fetch the source
2020-11-23 07:39:33 <ncopa> whyat cant they fetch the source?
2020-11-23 07:39:57 <mps> rnalrd: ping
2020-11-23 07:40:19 <ikke> ncopa: I have no clue. From some locations you can, from others you can't
2020-11-23 07:42:45 <ikke> ncopa: from nld5 for example I'm able to download it
2020-11-23 07:45:48 <ncopa> but not from nld8
2020-11-23 07:46:11 <ikke> indeed
2020-11-23 07:46:36 <ncopa> wild guess: path mtu iis broken or something?
2020-11-23 07:46:41 <rnalrd> mps hi
2020-11-23 07:46:45 <rnalrd> checking on it
2020-11-23 07:47:40 <ncopa> ikke: i suppose we can upload it manually to distfiles for now
2020-11-23 07:47:50 <ikke> ncopa: nod
2020-11-23 07:48:31 <mps> rnalrd: could you look at !14840
2020-11-23 07:49:27 <mps> we should try to remove all bdb deps for 3.13 release
2020-11-23 07:50:38 <rnalrd> i'm not up-to-date: reason? problems with dbd?
2020-11-23 07:51:08 <ikke> ncopa: mtu is 1472, so sounds plausible
2020-11-23 07:51:51 <ncopa> ikke: maybe we havent configured clamp mss?
2020-11-23 07:52:30 <ikke> ncopa: I also have issues on my local systems
2020-11-23 07:52:39 <mps> rnalrd: bdb can't be upgraded because of license, and in current version it doesn't work with upgraded musl
2020-11-23 07:52:57 <ncopa> rnalrd: berkley db is problematic. oracle bought it, changed license from version 6 (to alicense we cannot really use IIRC), and db-5 is no longer supported
2020-11-23 07:53:28 <ikke> ncopa: I cannot even ping from nld9
2020-11-23 07:53:39 <ncopa> traceroute?
2020-11-23 07:54:04 <ncopa> sounds like internet is broken :)
2020-11-23 07:54:56 <rnalrd> got it thanks
2020-11-23 07:55:04 <ikke> https://tpaste.us/DMBO
2020-11-23 07:56:52 <ikke> working: https://tpaste.us/BEkW
2020-11-23 07:57:10 <ikke> so something on their side
2020-11-23 08:01:52 <ikke> ncopa: copied tree to the v3.13 dir on distfiles
2020-11-23 08:06:00 <ikke> a\
2020-11-23 10:07:47 <ikke> ncopa: mliska replied
2020-11-23 10:12:24 <ncopa> replied. thanks!
2020-11-23 11:05:51 <Ariadne> Cogitri: if you want the JS stuff, it could be done with plugin or something :P
2020-11-23 11:06:43 <Ariadne> [20:17:34] <Hello71> programmed in rust of course, for modernization
2020-11-23 11:07:02 <Ariadne> Hello71: i would like to use rust, but want to finish solving the bootstrap first.
2020-11-23 11:09:12 <tpanmajia> when I use https://github.com/sgerrand/alpine-pkg-glibc/releases to run typora I got segfaults
2020-11-23 11:09:19 <tpanmajia> https://tpaste.us/x15Q
2020-11-23 11:09:27 <tpanmajia> is this compat layer experimental?
2020-11-23 11:10:04 <Ariadne> use gcompat
2020-11-23 11:10:11 <Ariadne> that thing is not something made by us
2020-11-23 11:10:13 <Ariadne> (:
2020-11-23 11:11:01 <tpanmajia> Ariadne: does your "us" mean the Alpine dev team?
2020-11-23 11:11:06 <Ariadne> yes
2020-11-23 11:11:22 <tpanmajia> Ariadne: where could I get gcompat? there're a few similarly named packages
2020-11-23 11:11:22 <Ariadne> gcompat is the preferred way of achieving glibc compatibility on musl
2020-11-23 11:11:29 <Ariadne> apk add gcompat
2020-11-23 11:11:29 <Ariadne> :)
2020-11-23 11:11:45 <tpanmajia> Ariadne: thx. the canonical way, if i understand correctly?
2020-11-23 11:11:54 <Ariadne> sure
2020-11-23 11:12:35 <tpanmajia> bash: ./Typora: No such file or directory
2020-11-23 11:12:41 <tpanmajia> do I have to install libc6-compat?
2020-11-23 11:12:55 <tpanmajia> IIRC this fills in the correct path of glibc linker
2020-11-23 11:13:22 <tpanmajia> installed, symbol not found :(
2020-11-23 11:13:44 <tpanmajia> https://tpaste.us/yNv8
2020-11-23 11:14:17 <Ariadne> what did you 'install'
2020-11-23 11:14:40 <tpanmajia> apk install gcompat libc6-compat
2020-11-23 11:14:52 <Ariadne> no
2020-11-23 11:15:06 <Ariadne> you do not install libc6-compat when you install gcompat
2020-11-23 11:15:13 <Ariadne> i should just get rid of libc6-compat
2020-11-23 11:15:15 <Ariadne> its obsolete
2020-11-23 11:15:27 <tpanmajia> Ariadne: got it, but why don't delete it from the official repo?
2020-11-23 11:15:44 <Cogitri> Ariadne: Ah yes, a plugin would be neato with Ducktape or smth
2020-11-23 11:16:06 <Cogitri> If you do end up doing it in not C I'd be interested in the project too :)
2020-11-23 11:16:48 <tpanmajia> bash: ./Typora: No such file or directory
2020-11-23 11:16:53 <tpanmajia>       [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
2020-11-23 11:17:07 <tpanmajia> Ariadne: it's likely that the linker could not be found
2020-11-23 11:17:44 <tpanmajia> however there is /lib/ld-linux-x86-64.so.2, which disallows me from running it directly
2020-11-23 11:17:50 <Ariadne> tpanmajia: what alpine version are you running?
2020-11-23 11:17:54 <mps> tpanmajia: this is unsupported. if work ok, if not work ok
2020-11-23 11:18:23 <tpanmajia> Ariadne: 3.12.1
2020-11-23 11:18:31 <tpanmajia> mps: got it, but i'd like to try
2020-11-23 11:18:46 <Ariadne> tpanmajia: `apk fix gcompat` to fix the braindamage you did with `apk add libc6-compat`
2020-11-23 11:19:09 <tpanmajia> Ariadne: done
2020-11-23 11:19:16 <Ariadne> i think libc6-compat should go, in favor of providing those symlinks in gcompat package
2020-11-23 11:19:23 <tpanmajia> bash: ./Typora: No such file or directory
2020-11-23 11:19:28 <tpanmajia> the error message persists
2020-11-23 11:19:31 <Ariadne> cool
2020-11-23 11:20:16 <tpanmajia> Ariadne: the interpreter is [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] but i can't find it
2020-11-23 11:20:35 <Ariadne> hmm
2020-11-23 11:20:46 <Ariadne> gcompat in 3.12 doesnt have lib64
2020-11-23 11:20:50 <Ariadne> thats why
2020-11-23 11:20:57 <Ariadne> i get
2020-11-23 11:20:58 <Ariadne> nanabozho:~/bin/Typora-linux-x64$ ./Typora
2020-11-23 11:20:58 <Ariadne> Error relocating /home/kaniini/bin/Typora-linux-x64/Typora: initstate_r: symbol not found
2020-11-23 11:20:58 <Ariadne> Error relocating /home/kaniini/bin/Typora-linux-x64/Typora: random_r: symbol not found
2020-11-23 11:21:26 <tpanmajia> Ariadne: so how could I use 64-bit programs? may I upgrade to edge?
2020-11-23 11:21:35 <Ariadne> yes
2020-11-23 11:21:39 <tpanmajia> got it
2020-11-23 11:21:49 <tpanmajia> are 32-bit programs doing fine?
2020-11-23 11:22:07 <ikke> Ariadne: Ah, my bad, I suggested libc6-compat
2020-11-23 11:23:10 <tpanmajia> Ariadne: could I download the apk from edge directly and ...?
2020-11-23 11:23:30 <tpanmajia> Ariadne: I could not foresee any compat problems and this might not work fine
2020-11-23 11:23:41 <Ariadne> you shouldn't mix edge and release
2020-11-23 11:23:51 <tpanmajia> Ariadne: why?
2020-11-23 11:24:08 <ikke> dependency issues
2020-11-23 11:24:10 <mps> (hmm, maybe leave also this channel, not sure is it dev or help channel)
2020-11-23 11:24:29 <ikke> help for developers :)
2020-11-23 11:24:45 <mps> ikke: you are kidding with me ;P
2020-11-23 11:24:54 <tpanmajia> eh, actually I found this channel in IRC logs
2020-11-23 11:25:15 <tpanmajia> and some months ago someone is discussing about glibc compat in this channel
2020-11-23 11:26:11 <tpanmajia> and this might not be help on regular users anyway
2020-11-23 13:44:27 <ikke> ncopa: another reply from mliska
2020-11-23 15:08:27 <maxice8> hexdump from util-linux  and perl-data-hexdump conflict over /usr/bin/hexdump
2020-11-23 15:58:04 <Newbyte> Is it expected MRs may take longer to be merged for the time being?
2020-11-23 15:58:51 <ikke> Lots of MRs coming in atm I guess
2020-11-23 15:58:59 <ikke> and the release of 3.13 is taking time as well
2020-11-23 15:59:37 <Newbyte> 👍️
2020-11-23 16:19:18 <maxice8> I am also spending much more time writing agl rather than policing so it helps a bit in increasing the numbers
2020-11-23 16:20:35 <Cogitri> Also busy with uni and other projects :/
2020-11-23 16:21:38 <mps> some of my MRs waiting months
2020-11-23 16:22:57 <Cogitri> Ah, but you can merge yourself, can't you?
2020-11-23 16:24:43 <mps> ofc I can, but I don't want before all issues are settled (usually ofc :) )
2020-11-23 17:42:58 <walbon> maxice8: as you said, hexdump have conflicted and avoid the installation of the hexdump in many packages, I saw in the builder log
2020-11-23 18:38:31 <ikke> maxice8: does apkbuild.vim depend on ALE?
2020-11-23 18:40:04 <ikke> "E117: Unknown function: ale#fix#registry#Add"
2020-11-23 19:38:16 <maxice8> It shouldn't
2020-11-23 19:38:34 <maxice8> heh, guess I forgot to add checks to see if ALE was actually installed
2020-11-23 19:39:01 <ikke> maxice8: I also notice it runs plain shellcheck (without the wrapper) is that correct?
2020-11-23 19:39:13 <ikke> It gives all kinds of warnigns on unused variables
2020-11-23 19:39:35 <maxice8> it has its own wrapper in scripts/
2020-11-23 19:40:28 <ikke> Then I don't know why it says that things like source are unused
2020-11-23 19:42:37 <insep_> 
ACTION still would like apkbuild.vim to integrate with nvim 0.5 lsp :>

2020-11-23 19:42:43 <insep_> or with completion.nvim
2020-11-23 19:43:05 <insep_> that's what i use for autocomplete and it's also able to complain about stuff
2020-11-23 19:45:10 <maxice8> I only use ALE so I have no clue how to support hose
2020-11-23 19:45:11 <maxice8> those*
2020-11-23 19:46:43 <insep_> completion.nvim has support for external sources like https://github.com/kristijanhusak/vim-dadbod-completion and lsp requires to write s part of lsp :D
2020-11-23 20:10:27 <ikke> maxice8: https://gitlab.alpinelinux.org/Leo/apkbuild.vim/-/issues/1
2020-11-23 20:15:44 <ikke> maxice8: ok, apparently apkbuild was not being used (had to set filetype to apkbuild
2020-11-23 20:31:22 <maxice8> weird
2020-11-23 20:31:38 <maxice8> Are you setting ft=sh anywhere for APKBUILD ?
2020-11-23 20:34:27 <ikke> This is my vimrc: https://tpaste.us/oPOE
2020-11-23 20:34:35 <ikke> I have this: autocmd FileType sh set sw=8 sts=8 noet
2020-11-23 20:35:10 <ikke> But I don't think that's thie issue
2020-11-23 20:54:29 <ikke> dalias: https://lists.strace.io/pipermail/strace-devel/2020-October/010255.html Seems like strace is changing it as well
2020-11-23 20:54:57 <ikke> Or maybe I'm reading it wrong :)
2020-11-23 20:58:46 <dalias> ok so they're aware
2020-11-23 20:59:05 <ikke> yes
2020-11-23 20:59:23 <ikke> They labeled the issue I opened as 'bug', so I assume it's something that should be fixed in strace
2020-11-23 21:01:28 <dalias> i think they're just mistaken in considering the _MAX part of the uapi
2020-11-23 21:01:33 <dalias> it's just informative of the current max
2020-11-23 21:03:15 <ikke> right
2020-11-23 21:13:09 <mps> just added linux-edge-virt to linux-edge aport, now only for x86_64 arch
2020-11-23 21:15:17 <ikke> !12132
2020-11-23 21:15:20 <ikke> hmm
2020-11-23 21:15:29 <ikke> !14903
2020-11-23 21:38:34 <c705> !12061
2020-11-23 21:39:18 <ikke> what about it?
2020-11-23 21:39:30 <c705> was looking for the issue, just wanted the link
2020-11-23 21:39:43 <ikke> ah, you linked to a MR
2020-11-23 21:39:46 <c705> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12061
2020-11-23 21:39:51 <ikke> #12061
2020-11-23 21:39:58 <c705> taggend with MR avaliable, no MR is avaliable
2020-11-23 21:40:13 <ikke>  Kevin Daudt @kdaudt removed
2020-11-23 21:40:16 <ikke> tag:mr-available
2020-11-23 21:40:18 <ikke> label 1 week ago
2020-11-23 21:40:25 <c705> ah
2020-11-23 22:22:46 <ikke> maxice8: would it be possible to automatically cancel the pipeline after merging with mgmr?
2020-11-24 08:02:10 <maxice8> It would but the real problem is that somewhere in the chain of mgmr <-> python3-gitlab <-> gitlab
2020-11-24 08:02:31 <maxice8> the skip_ci we send from mgmr whenever we rebase is lost
2020-11-24 08:21:05 <ikke> I think skip_ci only works for non_mr pipelines
2020-11-24 08:21:18 <ikke> (ie, attached pipelines)
2020-11-24 08:21:47 <ikke> It didn't even work when I directly invoked the API
2020-11-24 08:25:39 <ikke> rip maxice8/cogitri
2020-11-24 08:27:23 <ikke> maxice8: https://gitlab.com/gitlab-org/gitlab/-/issues/27955
2020-11-24 09:11:13 <ikke> So until that's fixed, I guess canceling the running pipeline after rebase could work
2020-11-24 12:06:25 <maxice8> I see, rebases are done async (for some reason)
2020-11-24 12:08:16 <ikke> Probably to not delay showing the page until the rebase is done
2020-11-24 12:10:21 <maxice8> Also no clue why they don't have rebase_and_merge like GitHub does
2020-11-24 12:10:58 <ikke> https://gitlab.com/gitlab-org/gitlab/-/issues/895
2020-11-24 12:13:36 <maxice8> They mention merge trains? Isn't that only for EE ?
2020-11-24 12:20:55 <ikke> yes
2020-11-24 12:24:29 <maxice8> Let me check a few things
2020-11-24 12:27:08 <ikke> There is also a push option to skip ci, but I figured it suffers the same limitations
2020-11-24 12:39:43 <maxice8> They return a pipeline in the response to the accept merge request but dealing with pipelines is hell
2020-11-24 12:40:08 <maxice8> @Cogitri did some magic in alpine-qa-bot to deal with it iirc
2020-11-24 12:49:21 <Newbyte> Should I notify the maintainer in the MR if all I'm doing is disabling a package for a specific arch due to dependency failures?
2020-11-24 12:56:30 <ikke> Generally not
2020-11-24 12:56:44 <ikke> You could ping them as an FYI
2020-11-24 13:03:50 <PureTryOut[m]2> Well sometimes people disable packages on all arches in which case it would be nice to get notified
2020-11-24 13:03:59 <PureTryOut[m]2> I sometimes find packages of mine are disabled a month or so after it happened and I had no clue
2020-11-24 13:06:00 <PureTryOut[m]2> But for individual arches, especially s390x and mips*, I don't mind not being notified
2020-11-24 13:11:06 <Newbyte> Thanks!
2020-11-24 13:11:14 <mps> ikke: I don't agree, always notify or ask maintainer if in doubt (even if not in doubt), or ask some of active developers if maintainer don't respond
2020-11-24 13:19:36 <mps> Marian[m]: hi :)
2020-11-24 13:19:57 <Newbyte> btw, why does Alpine use samurai instead of ninja?
2020-11-24 13:20:05 <Cogitri> maxice8: Yes, pipelines aren't fun since in some contexts gitlab views pipelines as belonging to the source project and in some contexts they belong to the fork :/
2020-11-24 13:20:10 <Marian[m]> Hi :-) Finally it worked :-)
2020-11-24 13:20:27 <Cogitri> Newbyte: https://lists.alpinelinux.org/~alpine/devel/%3CBYZDB5LH4OVY.9FDVF5I3J954%40homura%3E#%3C20191207183917.74342cbb@Impreza%3E
2020-11-24 13:20:35 <skarnet> Newbyte: because samurais > ninjas, obviously
2020-11-24 13:21:00 <mps> Newbyte: because samurais are honest warriors while ninjas are dishonest :)
2020-11-24 13:21:03 <PureTryOut[m]2> Marian: welcome in the _correct_ channel 😜
2020-11-24 13:22:06 <Newbyte> Makes sense, thanks
2020-11-24 13:22:18 <Newbyte> Now I'm curious where Marian ended up initially
2020-11-24 13:22:52 <PureTryOut[m]2> On OFTC somehow 🤔
2020-11-24 13:22:59 <ikke> heh
2020-11-24 13:32:43 <maxice8> @Cogitri I think pipelines attached to merge requests are purely from the forked repo's perspective
2020-11-24 13:33:05 <ikke> yes
2020-11-24 13:33:14 <ikke> For merge requests
2020-11-24 13:33:53 <maxice8> It would be nice if aports-qa-bot had its own merge train, we have auto-labelling support (just need to restart aports-qa-bot to support it)
2020-11-24 13:34:24 <ikke> RIght, I didn't hear that was ready yet
2020-11-24 13:34:47 <Cogitri> I think we should tag a release soon and get the auto building for the docker image ready before that
2020-11-24 13:35:01 <Cogitri> I'm a bit afraid of the bot merging things since we need some form of access control for that
2020-11-24 13:35:50 <maxice8> the control would be someone with access to merge saying
2020-11-24 13:35:53 <maxice8> @bot :shipit:
2020-11-24 13:36:29 <ikke> but we don't want to circumvent the existing access controls
2020-11-24 13:36:43 <ikke> We for example allow only certain users to merge to master through a git hook
2020-11-24 13:36:54 <ikke> But if all merges are done by the bot, you loose that
2020-11-24 13:37:17 <ikke> And I guess the bot would become committer for the rebased commits
2020-11-24 13:38:46 <Cogitri> You could set the author manually I guess, but yes, I don't really want the bot to do stuff like that
2020-11-24 13:38:50 <Cogitri> That's best handled by Gitlab itself
2020-11-24 13:39:25 <maxice8> Isn't there an impersonation API ?
2020-11-24 13:39:38 <ikke> There is (sudo)
2020-11-24 13:57:47 <Cogitri> ikke: I think Gitlab doesn't see my updates to a branch in a MR
2020-11-24 13:57:53 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14931/diffs here's the diff for the branch 3.12-webkit
2020-11-24 13:57:55 <Cogitri> 2gtk
2020-11-24 13:58:11 <Cogitri> Here's the commit that's at the tip of the branch: https://gitlab.alpinelinux.org/Cogitri/aports/-/commit/eccb01807fee7efd72df7b70bf8379e51f5dff88
2020-11-24 13:58:38 <Cogitri> The MR still has `use-versioned-libwpe.patch` in the APKBUILD when the branch doesnt
2020-11-24 14:00:45 <ikke> interesting, I see
2020-11-24 14:00:49 <ikke> not sure what's going on
2020-11-24 14:13:53 <Cogitri> I think I already had that a few times, usually amending the commit and force pushing a few times "fixed" it
2020-11-24 14:22:09 <Cogitri> ikke: Also, can you make Cogitri/abuild public? Currently trying to build a fork of abuild in docker to test some things and I don't have my SSH key in the docker build context :)
2020-11-24 14:23:34 <ikke> done
2020-11-24 14:25:43 <Cogitri> Thanks 👍️
2020-11-24 15:27:55 <hechos> hello guys im dealing with r8169 from realtek for couple days now.
2020-11-24 15:28:21 <hechos> so one solution is compile kernel with option CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
2020-11-24 15:28:48 <hechos> already test kernels, from edge/testing/lastest-stable and happen the same.
2020-11-24 15:29:17 <hechos> or manually unload and load module, rmmod r8169 and modprobe r8169
2020-11-24 15:29:59 <mps> hechos: uname -a
2020-11-24 15:30:13 <hechos> Linux alpine-desktop 5.4.79-0-lts #1-Alpine SMP Mon, 23 Nov 2020 09:37:22 UTC x86_64 Linux
2020-11-24 15:30:57 <hechos> right now boot to edge kernel. and mannualy load modules.
2020-11-24 15:31:03 <mps> aha, what is issue
2020-11-24 15:31:23 <hechos> eth0 doesnt appear
2020-11-24 15:31:38 <mps> kernel doesn't load module on boot?
2020-11-24 15:31:51 <hechos> when done rmmod r8169 and modprobe r8169 work, but need to be done manually.
2020-11-24 15:31:59 <hechos> mps: yes
2020-11-24 15:32:33 <mps> don't understand then why you use 'rmmod r8169'
2020-11-24 15:33:04 <mps> and again, this is for #linux-alpine
2020-11-24 15:33:15 <hechos> because if dont use rmmod module dont load.
2020-11-24 15:33:27 <hechos> hoo.
2020-11-24 15:33:35 <hechos> sorry
2020-11-24 15:33:54 <mps> but if it isn't loaded why is rmmod used
2020-11-24 15:34:13 <ikke> I think the module is loaded?
2020-11-24 15:34:14 <hechos> is what im asking for.
2020-11-24 15:34:23 <hechos> but?
2020-11-24 15:34:28 <mps> hmm, strange
2020-11-24 15:34:31 <ikke> Sounds like some kind of timing inssue
2020-11-24 15:34:42 <ikke> firmware that is still being loaded or something
2020-11-24 15:34:59 <clandmeter> check dmesg
2020-11-24 15:35:16 <clandmeter> but this really should go to #alpine-linux
2020-11-24 15:35:27 <hechos> r8169 0000:03:00.0: realtek.ko not loaded, maybe it needs to be added to initramfs?
2020-11-24 15:36:01 <clandmeter> hechos: we are also in #alpine-linux, please that instead.
2020-11-24 15:36:06 <mps> on linux-edge 'CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y' is set already
2020-11-24 15:36:06 <clandmeter> use*
2020-11-24 17:59:21 <artok> mps: did you have mainline 5.9 tested on rpi4?
2020-11-24 18:04:13 <mps> artok: no, I don't have RPi4 so can't test
2020-11-24 18:05:06 <artok> ..and nobody has reported anything, right
2020-11-24 18:05:43 <mps> right
2020-11-24 18:07:24 <mps> I enabled some options for RPi but not sure if all what is needed
2020-11-24 18:08:12 <artok> I'll hit now 3.12 -> edge, take backup of the usb stick and then install the 5.9
2020-11-24 18:08:27 <artok> oh there was update 1hr ago
2020-11-24 18:08:41 <mps> :)
2020-11-24 18:08:46 <mps> I'm so fast
2020-11-24 18:09:38 <mps> but 5.10 will not go in 3.13 as next -lts
2020-11-24 18:10:43 <artok> should check when the packages are updated on testing then
2020-11-24 18:11:40 <mps> artok: I made mainline 5.9 for RPi zero and it works fine
2020-11-24 18:17:08 <artok> nice
2020-11-24 18:17:37 <artok> ok so who put noauto to my /boot fstab line...
2020-11-24 18:18:11 <mps> artok: I thought to test with qemu for raspi4 target but not sure if that is correct test
2020-11-24 18:18:48 <artok> nah, good to test i2c thingies and so on
2020-11-24 18:19:43 <artok> build kernel module for i2c display that is, and test out gpio buttons etc
2020-11-24 18:20:01 <mps> yes
2020-11-24 19:01:15 <andypost[m]> CI hit docker rate limit https://gitlab.alpinelinux.org/andypost/aports/-/jobs/254412
2020-11-24 19:02:17 <ikke> hmm, ugh
2020-11-24 19:12:45 <artok> ehh
2020-11-24 19:13:08 <artok> might be ok to ask for sponsored access without rate limit
2020-11-24 19:16:32 <ikke> I can temporarily work around it by using the cached images
2020-11-24 19:20:49 <andypost[m]> I think gitlab runner's pull policy is better, because proxy setup is tricky
2020-11-24 19:21:05 <ikke> yes, that's what I'm doing
2020-11-24 19:33:19 <artok> upgraded to edge and busybox udhcpc can't get ip addr..
2020-11-24 19:36:19 <ikke> I have no issues getting ip addresses on edge systems
2020-11-24 19:42:15 <ikke> oof: https://www.openwall.com/lists/oss-security/2020/11/24/3
2020-11-24 19:42:39 <ikke> (pam auth bypass)
2020-11-24 19:49:54 <ikke> clandmeter: choose is failing due to cargo issues again :(
2020-11-24 19:49:58 <ikke> Cogitri: *
2020-11-24 19:52:35 <Cogitri> Hmm, on arm again?
2020-11-24 19:52:51 <ikke> yes
2020-11-24 19:53:00 <ikke> armv7 and aarch64
2020-11-24 19:53:12 <ikke> well, armv7 seems to be something different
2020-11-24 19:53:20 <ikke> error[E0432]: unresolved import `structopt`
2020-11-24 19:53:30 <ikke> which I saw on other projects as well. Does this ring a bell?
2020-11-24 19:54:09 <Cogitri> Hmm, not really
2020-11-24 19:54:13 <ikke> k
2020-11-24 19:54:19 <Cogitri> armv7 and aarch64 share distfiles, right?
2020-11-24 19:54:36 <ikke> no
2020-11-24 19:54:40 <ikke> armv7 and armhf
2020-11-24 19:54:56 <ikke> but I see even on armv7 and armhf they have a different path
2020-11-24 19:55:19 <ikke> github.com-1285ae84e5963aae  github.com-1ecc6299db9ec823
2020-11-24 19:56:13 <Cogitri> Hum, that's weird
2020-11-24 19:57:00 <artok> weird.. after really long wait, dhcp client got the ip
2020-11-24 19:57:51 <Cogitri> ikke: I'll try to ask the rust devs about it, but if that doesn't work we could disable cargo's caching
2020-11-24 19:58:06 <Cogitri> Shouldn't be too much of an advantage on the builders anyway
2020-11-24 23:14:05 <dalias> uhg wtf something keeps turning off accept_ra for wlan0
2020-11-24 23:17:41 <dalias> uhg is dhcpcd doing something stupid?
2020-11-25 00:09:18 <Ariadne> probably
2020-11-25 00:18:48 <dalias> ariadne, it turned out it is turning off accept_ra, because it handles them itself
2020-11-25 00:19:00 <dalias> but that's probably ok
2020-11-25 00:19:13 <dalias> (not sure if there's a reason to prefer having it do it)
2020-11-25 00:20:39 <dalias> i had screwed up something else i forgot about on my radvd trying to fix it
2020-11-25 00:21:24 <dalias> (broken netmask)
2020-11-25 00:21:32 <dalias> the original problem was default route constantly disappearing
2020-11-25 00:21:38 <dalias> for some reason the route lifetime is ignored and AdvDefaultLifetime is used instead
2020-11-25 00:21:55 <dalias> and AdvDefaultLifetime is just a few seconds by default so any wifi blip makes it go down
2020-11-25 00:22:26 <dalias> now with that set to 9000 (max allowed, stupid, should allow infinite) i'm not getting any loss of route
2020-11-25 00:23:48 <dalias> (seriously, this address has outlived like 3+ acquisitions of the carrier, it's not going away in 9000 seconds :-p)
2020-11-25 08:37:47 <Marian[m]> Hi. Could someone run the snapshot function on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14127 for me?
2020-11-25 08:38:12 <mps> 0edec8192adc9e4ed5e2ffad54d53ae0ca90efce
2020-11-25 08:38:32 <mps>  main/librtlsdr
2020-11-25 08:39:22 <mps> Marian[m]: maxice8: ^
2020-11-25 08:39:32 <Marian[m]> Oha. I should have searched without the dash as well :-/
2020-11-25 08:40:40 <maxice8> mps: fixed, thanks for noticing
2020-11-25 08:40:58 <mps> np :)
2020-11-25 08:41:03 <Marian[m]> @mps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14956
2020-11-25 08:41:19 <ikke> Have we asked upstream already for tagged releases?
2020-11-25 08:42:38 <mps> Marian[m]: maxice8 already fixed by removing it
2020-11-25 08:50:53 <Marian[m]> @ikke: No, I only asked whether they could create reproducable archives from the same commit. They were aware of the issue and there was already an issue / feature request open to add this to sr.ht - but this wasn't added at that time. I could check again.
2020-11-25 08:51:16 <ikke> Marian[m]: ok, yes, that would be certainly desirable
2020-11-25 08:51:55 <ikke> (mostly referring to sr.ht providing stable archives)
2020-11-25 08:53:59 <Marian[m]> Just downladed the same archieve three times and got three different checksums :-/
2020-11-25 08:54:26 <ikke> I wonder if there is an issue tracking this
2020-11-25 08:56:06 <ikke> https://todo.sr.ht/~sircmpwn/hg.sr.ht/33
2020-11-25 08:57:17 <Marian[m]> Regarding releases, I found this issue: https://todo.sr.ht/~scoopta/wlrobs/15
2020-11-25 08:58:59 <ikke> They didn't mention anything about tagging releases though
2020-11-25 09:14:09 <ncopa> morning
2020-11-25 09:14:45 <ikke> morning
2020-11-25 09:15:01 <ncopa> im making some tweaks on busybox config
2020-11-25 09:15:18 <ncopa> disabling a couple of applets that i dont think anyone uses nowdays
2020-11-25 09:15:24 <ncopa> conspy and hdparm
2020-11-25 09:15:35 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14713
2020-11-25 09:16:45 <ncopa> im increasing buffer size for cp/mv etc
2020-11-25 09:17:11 <ncopa> what is the exact path for xz links
2020-11-25 09:17:31 <ikke> /usr/bin/xz
2020-11-25 09:19:23 <ikke> On docker alpine:edge, after apk upgrade -U, this error appears
2020-11-25 09:19:36 <ncopa> understand
2020-11-25 09:19:47 <mps> ncopa: are you sure no one use bb hdparm
2020-11-25 09:19:54 <ncopa> nope
2020-11-25 09:20:32 <mps> few days ago I used it
2020-11-25 09:20:44 <ncopa> however, i think people who actually use hdparm will most likely be more interested in using the "real" hdparm
2020-11-25 09:20:57 <mps> though after few minutes add 'real' hdparm
2020-11-25 09:21:06 <ikke> case in point :P
2020-11-25 09:21:11 <mps> added*
2020-11-25 09:21:17 <ncopa> ah, thats good feedback :)
2020-11-25 09:21:54 <ncopa> i also think its a tool that is only ocationallly used, to speed test block devices etc
2020-11-25 09:22:00 <ikke> ncopa: what I was confused about earlier, but cannot seem to reproduce, is that I got the same error again after installing xz and removing it again
2020-11-25 09:22:01 <ncopa> but that is normally not needed
2020-11-25 09:22:10 <mps> but still, bb hdparm is usable to some degree
2020-11-25 09:22:42 <ncopa> its relatively big, so i think the prize for the benefit is too high
2020-11-25 09:22:53 <ncopa> thats the reasoning
2020-11-25 09:22:59 <ncopa> anyone every used conspy?
2020-11-25 09:23:07 <ikke> I don't even know what it does :P
2020-11-25 09:23:11 <ncopa> exactly.... :)
2020-11-25 09:23:46 <mps> vnc for consoles
2020-11-25 09:24:33 <mps> some kind of that
2020-11-25 09:24:39 <ncopa> i think its better to remove never  used applets
2020-11-25 09:25:03 <ncopa> if someone uses it we can ask them to do apk add ...
2020-11-25 09:25:17 <ikke> is there something providing conspy?
2020-11-25 09:25:18 <mps> but we don't know are they used
2020-11-25 09:25:36 <ncopa> hum...
2020-11-25 09:25:46 <ncopa> seems like there is no cmd:conspy
2020-11-25 09:26:11 <ncopa> i thikn we can remove them and add them back if someone complains and have good arguments for add it back
2020-11-25 09:26:25 <ikke> I'll add it to the draft release notes
2020-11-25 09:26:34 <ncopa> awesome!
2020-11-25 09:26:36 <ncopa> thanks
2020-11-25 09:26:44 <mps> I wouldn't remove them until known to be buggy or have unfixable sec issues
2020-11-25 09:26:55 <ncopa> mps: I am trying to de-bloat a bit
2020-11-25 09:27:09 <ikke> mps: what happened to small and fast? :P\
2020-11-25 09:27:13 <ikke> or small and secure
2020-11-25 09:27:38 <mps> ikke: remove rust and we will one step closer :)
2020-11-25 09:28:16 <ikke> Let's remove perl as well :P
2020-11-25 09:28:29 <ncopa> the idea is to remove things that are likely not used.  if someone complains we can consider add them back. if nobody complains we all win
2020-11-25 09:28:46 <ikke> mps: sorry, that was a bit provocative
2020-11-25 09:28:48 <maxice8> Ikke: yes please
2020-11-25 09:28:54 <mps> ikke: but how then God recreate world if we remove perl :P
2020-11-25 09:29:04 <maxice8> mps: Rewrite God in Rust
2020-11-25 09:29:35 <mps> maxice8: you want God to be owned by mozilla ;)
2020-11-25 09:30:12 <mps> and later by google (main mozilla sponsor)
2020-11-25 09:30:32 <maxice8> doesn't make any sense but ok
2020-11-25 09:31:00 <ncopa> what do you think about third status line for dd?
2020-11-25 09:31:03 <ncopa>  CONFIG_FEATURE_DD_THIRD_STATUS_LINE:                                                       │
2020-11-25 09:31:04 <ncopa>   │                                                                                            │
2020-11-25 09:31:04 <ncopa>   │ Displays a coreutils-like third status line with transferred bytes,                        │
2020-11-25 09:31:04 <ncopa>   │ elapsed time and speed.
2020-11-25 09:31:15 <ncopa> 7.5k
2020-11-25 09:31:18 <mps> ikke: maybe it is good idea to remove perl but we have to start with python first :)
2020-11-25 09:31:20 <ikke> ncopa: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#Removed_applets
2020-11-25 09:31:34 <insep_> mps: s)owned)borrowed)g
2020-11-25 09:32:34 <mps> ncopa: does CONFIG_FEATURE_DD_THIRD_STATUS_LINE have option to be enabled/disabled on invocation?
2020-11-25 09:32:50 <ikke> status=none afaik
2020-11-25 09:33:22 <ncopa> i dont know
2020-11-25 09:33:34 <ncopa> i thikn we leave it off til someone asks for it
2020-11-25 09:33:39 <mps>  status=none is now
2020-11-25 09:33:40 <ikke> coreutils dd only prints it afterwards
2020-11-25 09:33:51 <ikke> not during
2020-11-25 09:34:04 <ikke> (unless you add status=progress
2020-11-25 09:35:37 <ncopa> can i remove fdformat?
2020-11-25 09:36:04 <mps> yes, all 'dd' are quiet till instructed to do otherwise
2020-11-25 09:36:36 <ncopa> im removing fdformat. if there are anyone still using floppies they can apk add util-linux
2020-11-25 09:38:07 <mps> no one boot alpine from floppies (: where this world go ;-\ :)
2020-11-25 09:39:42 <ncopa> im also dropping readprofile
2020-11-25 09:40:43 <ncopa> i am considering add hexedit though
2020-11-25 09:41:37 <ncopa> i miss a hexeditor once in a while
2020-11-25 09:41:39 <ncopa> hum
2020-11-25 09:42:04 <ncopa> i suppose "once in a while" says it all. (sorry for thinking out loud)
2020-11-25 09:42:31 <ikke> no problem :)
2020-11-25 09:42:59 <ncopa> what about lspci and lsusb?
2020-11-25 09:43:15 <ncopa> i think those tools are pretty useless without the hw databases
2020-11-25 09:44:19 <ikke> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#Removed_applets
2020-11-25 09:47:19 <detha> lspci and lsusb are pretty often needed for 'what is this thing?' -> put the device:id in google
2020-11-25 09:47:59 <mps> also bb fdisk and blkid are useless nowadays
2020-11-25 09:48:09 <detha> (or 'which of the machines did they plug it into? for remote sites)
2020-11-25 09:48:53 <ncopa> detha: you can still apk add lspci lsusb if you need those, and you'll get the hw database with it
2020-11-25 09:49:24 <ncopa> bb fdisk is not completely useless
2020-11-25 09:49:25 <ncopa> i think
2020-11-25 09:49:32 <detha> true. but a simple lsusb is something I would expect in base
2020-11-25 09:49:45 <ncopa> detha: what about lspci?
2020-11-25 09:49:50 <mps> worse than useless, misleading
2020-11-25 09:49:59 <ncopa> can i remove lspci?
2020-11-25 09:50:47 <ncopa> i can keep lsusb if you feel strong about it
2020-11-25 09:50:57 <mps> why, current bb is less than 1MB
2020-11-25 09:51:32 <mps> why remove anything? seriously now
2020-11-25 09:51:34 <ikke> ncopa: both might be usefull in a base system if you don't get a network connection for some reason
2020-11-25 09:51:43 <ikke> to find out what kind of network card you have
2020-11-25 09:51:44 <detha> ncopa: lspci has two uses for me, detail on own machines, and 'what is this thing, what is in it' when given access to something remote
2020-11-25 09:52:19 <detha> In the second case, I may not have sufficient privs to just 'apk add'
2020-11-25 09:52:19 <ncopa> busybox lspci does not give any details other than device ids
2020-11-25 09:52:49 <detha> But the same info can be found in dmesg with some more effort, so I'd say lspci can go
2020-11-25 09:53:17 <ncopa> you also find the info in /sys/bus/pci/devices
2020-11-25 09:53:25 <detha> Or that.
2020-11-25 09:53:27 <mps> busybox lspci -k
2020-11-25 09:54:14 <ncopa> however, the info in /sys/bus/usb/devices is not as easy to parse
2020-11-25 09:55:01 <ncopa> yup can get the idvendors using cat /sys/bus/usb/devices/*/idVendor
2020-11-25 09:55:34 <ncopa> but ok, lets keep lsusb
2020-11-25 09:56:28 <ncopa> what about sendmail
2020-11-25 09:56:36 <ncopa> i think busybox sendmail is more or less useless
2020-11-25 09:56:54 <detha>  
2020-11-25 09:57:00 <detha> yes
2020-11-25 09:57:25 <mps> when you install pci-utils it pulls hwids-pci and maybe something else
2020-11-25 09:57:31 <ncopa> yup
2020-11-25 09:57:45 <ncopa> it install all you need to make it useful
2020-11-25 09:58:13 <mps> bb lscpi can be used for quick looks for some simple things
2020-11-25 09:58:17 <ncopa> imho, bb lspci is useless. you get the ame info with ls /sys/bus/pci/devices
2020-11-25 09:58:27 <ncopa> s/ame/same/
2020-11-25 09:58:27 <alpine-meetbot> ncopa meant to say: imho, bb lspci is useless. you get the same info with ls /sys/bus/pci/devices
2020-11-25 10:00:25 <mps> bb lspci | grep something is more usable that 'find -type (d|f) | grep xargs ...' (or other find params)
2020-11-25 10:00:53 <ncopa> how often have you used it?
2020-11-25 10:01:04 <ncopa> i have never used bb lspci, ever
2020-11-25 10:01:19 <ncopa> i have often used lspci, but never busybox lspci
2020-11-25 10:01:49 <ncopa> >>> Size difference for busybox: 944 KiB -> 924 KiB
2020-11-25 10:01:53 <mps> I used bb  lspci (and lsusb) on testing machines
2020-11-25 10:02:03 <ncopa> bb lspci?
2020-11-25 10:02:14 <mps> yes
2020-11-25 10:02:34 <ncopa> do you tink you will survive without it?
2020-11-25 10:03:22 <mps> I will survive without all computers in world :)
2020-11-25 10:04:23 <mps> actually i don't need these applets you mentioned this morning, I'm trying to be our 'unpredictable' users advocate
2020-11-25 10:04:33 <ncopa> yeah, i understand
2020-11-25 10:04:54 <ncopa> i think we can consider re-add them if users complain
2020-11-25 10:05:06 <ncopa> its always harder to remove. you never know what may break for who
2020-11-25 10:05:21 <mps> and personally I'm for removing all bb applets for which we have 'full blown' apps
2020-11-25 10:05:30 <ncopa> i think those applets are low risk
2020-11-25 10:05:46 <ncopa> i have also been thinking of things like blkid and mount, modprobe etc
2020-11-25 10:05:51 <ncopa> but i think those are higher risk
2020-11-25 10:06:18 <ncopa> we risk unbootable systems
2020-11-25 10:06:41 <ncopa> those applets i propose here are low risk i think
2020-11-25 10:07:36 <ikke> Aren't most of those commands used by alpine-conf?
2020-11-25 10:08:33 <ncopa> blkid mount modprobe? yes they are
2020-11-25 10:09:17 <ikke> so they would need to be added as dependencies then
2020-11-25 10:09:29 <ncopa> if we go there yes
2020-11-25 10:09:35 <ncopa> but i think not for now
2020-11-25 10:20:12 <maxice8> alpine-ipxe needs fixes, lots of them
2020-11-25 10:21:08 <maxice8> http://ix.io/2FpA
2020-11-25 10:22:18 <ncopa> i wonder if we should add a busybox-clean-symlinks applet
2020-11-25 10:22:43 <ncopa> we can implement it in shell but its goind to be slow
2020-11-25 10:34:32 <maxice8> cutter is getting 503'd
2020-11-25 10:34:48 <maxice8> It is also part of mkimgstandard
2020-11-25 10:37:02 <ikke> I can copy cutter from distfiles
2020-11-25 10:46:42 <maxice8> Please
2020-11-25 10:53:57 <ncopa> maxice8: can you please create an issue for alpine-ipxe with the details, so we dont forget it?
2020-11-25 10:54:24 <maxice8> Sure
2020-11-25 10:55:22 <ncopa> ikke: i have a better solution for !14713
2020-11-25 10:55:33 <ikke> ncopa: by all means :)
2020-11-25 10:55:48 <ikke> I can just close that MR
2020-11-25 10:56:38 <maxice8> #12136
2020-11-25 10:56:46 <maxice8> :D created with agl
2020-11-25 10:57:17 <ikke> cool
2020-11-25 10:58:35 <maxice8> https://build.alpinelinux.org/buildlogs/build-3-13-x86_64/main/lua-luaxml/lua-luaxml-130610-r5.log
2020-11-25 10:58:38 <maxice8> lua-luaxml needs distfiles
2020-11-25 10:59:03 <maxice8> also what to do with perl-data-hexdump and hexdump both claiming /usr/bin/hexdump ?
2020-11-25 10:59:21 <ikke> oof
2020-11-25 10:59:27 <ikke> that entire project is 404
2020-11-25 10:59:57 <ikke> rename the hexdump from perl-data-hexdump?
2020-11-25 11:00:23 <ikke> I don't know how that one is used
2020-11-25 11:01:37 <ikke> maxice8: we need to see what we should to with luaxml
2020-11-25 11:01:45 <maxice8> it is part of some acf- stuff
2020-11-25 11:02:28 <ikke> Maybe create an issue and assign to ttrask01
2020-11-25 11:02:56 <ikke> I've copied it to v3.13 distfiles now
2020-11-25 11:04:23 <Ariadne> ncopa: +1 on remove lspci from busybox
2020-11-25 11:05:57 <ncopa> im pushing busybox fixes now. please look out for breakages
2020-11-25 11:06:36 <ncopa> have a look at 1d6090d74744eb7a8df680ea1f8b8bdca96887ff
2020-11-25 11:53:41 <maxice8> Ikke: The big question is what in the builders brings in perl-data-hexdump
2020-11-25 11:53:48 <maxice8> only smokeping and perl-authen-radius depend on it
2020-11-25 11:56:18 <ikke> Where is it failing?
2020-11-25 11:56:22 <ikke> or causing issues?
2020-11-25 11:57:29 <maxice8> https://build.alpinelinux.org/buildlogs/build-3-13-ppc64le/main/ldapvi/ldapvi-1.7-r11.log
2020-11-25 12:00:46 <ikke> .makedepends-smokeping is still installed
2020-11-25 12:02:23 <ikke> seems like it was abruptly stopped
2020-11-25 12:02:46 <ikke> should be fixed now
2020-11-25 12:03:32 <mps> rnalrd: after you took over MR for removal of perl-db_file from spamassassin and amavis you can now remove perl-db_file-lock and perl-db_file, they are not needed now
2020-11-25 12:05:56 <paulf> Does alpine amd64 have a 32bit x86 subsystem?
2020-11-25 12:06:10 <paulf> (newbie alert btw)
2020-11-25 12:06:33 <ikke> paulf: we don't have multilib or something like that
2020-11-25 12:07:14 <PureTryOut[m]2> (not yet)
2020-11-25 12:10:13 <m242> PureTryOut[m]2: is it planned ?
2020-11-25 12:10:51 <PureTryOut[m]2> It's planned yes, no actual ETA yet though
2020-11-25 12:11:09 <m242> oh nice, I didn't know tha
2020-11-25 12:11:10 <m242> t
2020-11-25 12:11:11 <paulf> su
2020-11-25 12:11:47 <paulf> argh
2020-11-25 12:13:58 <paulf> I'm trying to test building Valgrind on a MUSL system
2020-11-25 12:14:12 <paulf> And I'm getting
2020-11-25 12:14:59 <paulf>  /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-dispatch-amd64-linux.o): relocation R_X86_64_32S against symbol `vgPlain_stats__n_xIndirs_32' can not be used when making a PIE object; recompile with -fPIE
2020-11-25 12:15:50 <paulf> But I already configured with -fPIE
2020-11-25 12:16:02 <ikke> how?
2020-11-25 12:16:29 <paulf> CFLAGS=-fPIE LDFLAGS=-fPIE ./configure --enable-only64bit
2020-11-25 12:17:19 <ikke> It's make flag
2020-11-25 12:17:37 <ikke> iirc
2020-11-25 12:17:37 <Ariadne> valgrind is already packaged
2020-11-25 12:17:48 <Ariadne> which includes coregrind
2020-11-25 12:18:01 <paulf> Err configure picks up env vars like CFLAGS and LDFLAGS
2020-11-25 12:18:19 <ikke> export CFLAGS="$CFLAGS -fno-stack-protector -no-pie"
2020-11-25 12:18:27 <ikke> so wie disable pie
2020-11-25 12:18:30 <ikke> we*
2020-11-25 12:19:16 <Ariadne> well, anyway
2020-11-25 12:19:43 <Ariadne> you dnt need to waste your time building valgrind
2020-11-25 12:20:12 <Ariadne> valgrind, cachegrind, coregrind
2020-11-25 12:20:14 <Ariadne> its all there
2020-11-25 12:20:25 <Ariadne> i use it a lot, on aarch64 and x86_64
2020-11-25 12:21:26 <paulf> Well since I'm a Valgrind dev it does help if I build it occasionally
2020-11-25 12:22:00 <Ariadne> hmm, yes in that case
2020-11-25 12:22:16 <Ariadne> i would look at the APKBUILD for valgrind
2020-11-25 12:22:59 <Ariadne> https://git.alpinelinux.org/aports/tree/main/valgrind
2020-11-25 12:26:13 <paulf> Thanks for the link. I may be able to upstream some of the patches. Do you know if they are generic to MUSL or specific to Alpine?
2020-11-25 12:26:32 <Ariadne> nothing alpine-specific there
2020-11-25 12:32:59 <afontain_> about the somewhat useless busybox applets, how about powertop?
2020-11-25 12:33:16 <afontain_> I've started it the other day and wondered why it was broken.
2020-11-25 12:33:29 <afontain_> turned out it was the busybox powertop
2020-11-25 12:33:59 <Ariadne> oh lord, this applet is ghastly
2020-11-25 12:34:14 <Ariadne> yeah that one should go
2020-11-25 12:34:47 <Ariadne> we should just set aside some day
2020-11-25 12:34:55 <Ariadne> and go through every single busybox applet we have enabled
2020-11-25 12:34:59 <Ariadne> and see if they are worth using
2020-11-25 12:38:11 <Ariadne> for example, busybox has stuff like "chat - simple chat utility" enabled
2020-11-25 12:41:57 <Ariadne> oh sorry
2020-11-25 12:42:01 <Ariadne> i forgot to run make oldconfig
2020-11-25 12:42:41 <ncopa> i did set aside this morning to clean up busybox config a bit
2020-11-25 12:42:52 <ncopa> i suppose powertop could go as well if its useless
2020-11-25 12:46:11 <ncopa> paulf: hi! nice to have you here, and thanks for working on upstreaming the patches we use
2020-11-25 12:47:30 <paulf> ATM I'm mainly testing that a patch for Fedora doesn't break MUSL systems, but I'll continue testing and will upstream if poss
2020-11-25 12:52:47 <Ariadne> ncopa: i think lsusb should go too.  its pretty useless without usbids
2020-11-25 12:53:42 <Ariadne> it also does not support lsusb -v, which is likely the most common use of lsusb
2020-11-25 12:54:25 <afontain_> oh, TIL about lsusb -v
2020-11-25 12:59:21 <ncopa> Ariadne: we discussed lsusb earlier today and the compromise was to keep lsusb but let lspci go
2020-11-25 12:59:34 <Ariadne> but why
2020-11-25 12:59:50 <mps> uh, remove busybox :(
2020-11-25 13:00:01 <ikke> mps: eventually :P
2020-11-25 13:00:12 <Ariadne> i'm fine with busybox applets that are actually good
2020-11-25 13:00:41 <mps> no one forces anyone to use applets
2020-11-25 13:01:01 <ikke> mps: if they are present by default, they can be confusing
2020-11-25 13:01:16 <ikke> patch being one example
2020-11-25 13:01:28 <mps> confusing for who?
2020-11-25 13:01:43 <ncopa> "but a simple lsusb is something I would expect in base"
2020-11-25 13:01:53 <ncopa> apparently people used lsusb
2020-11-25 13:02:39 <ncopa> the lspci output can relatively easy be foudn in /sys/bus/pci/devices
2020-11-25 13:03:01 <ncopa> but the format of /sys/bus/usb/devices is not as handy
2020-11-25 13:03:40 <ncopa> so i let lsusb stay, even if i originally intended to remove it
2020-11-25 13:04:16 <Ariadne> i have plans to finish the half-baked iproute2 plugin interface
2020-11-25 13:04:52 <mps> -rwxr-xr-x 1 root root 662K Jun 16 13:05 /bin/busybox
2020-11-25 13:04:55 <Ariadne> that should slim real iproute2 down to about 40kb, which means we can just ship that instead of the busybox ones which are not compatible
2020-11-25 13:04:58 <mps> armv7
2020-11-25 13:05:11 <Ariadne> yes, and the ideal size of busybox is more like 300kb
2020-11-25 13:05:50 <Ariadne> theres no point in shipping applets that people try to use, discover don't work as expected and then wind up installing the full package anyway
2020-11-25 13:06:22 <ncopa> but it makes sense i they are usable for a number of users
2020-11-25 13:06:43 <ncopa> like busybox ip route works for simple network setups
2020-11-25 13:08:08 <Ariadne> yes, but discovering busybox iproute does not work for more complex setups is usually a surprising experience
2020-11-25 13:08:17 <mps> at the end of discussion I have to say I'm not so excited with all these removals
2020-11-25 13:09:22 <ncopa> im ok to remove stuff that does not create problems, like fdformat. who uses that nowdays...
2020-11-25 13:09:37 <ncopa> its just meaningless
2020-11-25 13:10:08 <Ariadne> i also think it is surprising to download alpine live cd and then not have real iproute2, even though alpine is a networking-strong distribution
2020-11-25 13:10:53 <Ariadne> at the very least, we should have a livecd variant with iproute2 pre-installd
2020-11-25 13:13:04 <ncopa> i think its on the extended iso?
2020-11-25 13:13:16 <Ariadne> yes, but you still have to apk add it
2020-11-25 13:14:10 <Ariadne> in my opinion, you should be able to download the extended ISO and do everything alpine is capable of networking-wise out of the box
2020-11-25 13:14:39 <Ariadne> and probably some other niceties too
2020-11-25 13:15:17 <Ariadne> because then you can say, legitimately, that alpine-minimal is minimal, and alpine-extended is extended, and people get what they expect without having to mess with package manager
2020-11-25 13:15:33 <Ariadne> don't get me wrong, i think it is great to show off how fast apk is but :)
2020-11-25 13:43:08 <ncopa> i want to keep it minimal. add what you need rather than delete what you dont need
2020-11-25 13:43:48 <ncopa> however, we could have some setup script or unattended install thingy that makes it easy for a few common setups
2020-11-25 13:50:51 <Ariadne> sure, and in practice, if you install the ifupdown-ng components that actually need iproute2 to function, you will get iproute2 already.  but people tend to use iproute2 directly when mocking up a test environment
2020-11-25 13:51:49 <Ariadne> so i think asking if you want busybox iproute2 or real iproute2 in setup script is a good compromise
2020-11-25 13:51:56 <Ariadne> at least for now
2020-11-25 13:52:04 <rnalrd> mps: done
2020-11-25 13:52:10 <Ariadne> my dream is still to slim iproute2 down to the point where this is a pointless discussion ;)
2020-11-25 13:54:50 <mps> rnalrd: I see, thanks
2020-11-25 13:55:58 <detha> Is there a thing to just pull in _everything_ that replaces any busybox applet? So on something where space isn't an issue, apk add no-busybox instead of going 'what pulls in the proper X again' every couple of days for a month
2020-11-25 13:56:37 <ikke> no, there is no meta package or anything
2020-11-25 13:56:52 <Ariadne> well thats something i would not use personally.  i prefer some busybox applets over other implementations, actually.
2020-11-25 13:57:00 <Ariadne> busybox top is my preference for top, for example
2020-11-25 13:57:04 <Ariadne> and i prefer busybox ash
2020-11-25 13:58:17 <skarnet> I also prefer bb for some functionality, but not all of it, which is why I don't much like bb as a concept beyond "all-in-one toolbox for embedded stuff"
2020-11-25 13:59:22 <skarnet> ideally I need to configure my own bb just for the applets I want and use it as an applicative tool, not as something that stands in for coreutils and the like
2020-11-25 14:07:57 <Ariadne> on another topic, new features coming to ifupdown-ng include LTE management and hostapd management
2020-11-25 14:11:34 <Ariadne> i need to add support for native static route configuration still but this otherwise manages my LAN fine
2020-11-25 15:01:10 <dne> would someone like to merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14814 ?
2020-11-25 15:01:32 <dne> (security fixes that have already been made on the other branches)
2020-11-25 15:01:53 <ikke> xen is failing btw on armhf atm
2020-11-25 15:02:09 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/xen/xen-4.14.0-r3.log
2020-11-25 15:03:06 <ikke> mv: can't rename '/home/buildozer/aports/main/xen/pkg/xen/usr/lib/efi': No such file or directory
2020-11-25 15:03:28 <dne> ah, my fault then
2020-11-25 15:04:22 <dne> hmm, but why did it pass for the MR…
2020-11-25 15:05:10 <ikke> we don't have CI for armhf sadly
2020-11-25 15:05:22 <dne> ok that explains it
2020-11-25 15:09:24 <dne> will try to fix later tonight
2020-11-25 15:09:47 <ikke> Would this also affect that merge request?
2020-11-25 15:10:05 <dne> no this was something new on edge
2020-11-25 15:10:10 <ikke> ok
2020-11-25 15:11:09 <dne> caused by https://gitlab.alpinelinux.org/alpine/aports/-/commit/0f2ce00b7046c468976d907ef346efbe73450ffe
2020-11-25 18:11:49 <Newbyte> The CI failures for s390x on !14770 shouldn't be blockers for having s390x enabled, rgiht?
2020-11-25 18:16:16 <ikke> Newbyte: did you verify these packages will be built for s390x?
2020-11-25 18:18:37 <Newbyte> ikke: 2 are noarch, one is arch all with no exceptions
2020-11-25 18:18:42 <Newbyte> is there any other way to tell?
2020-11-25 18:19:02 <Newbyte> I'm looking at the APKBUILDs for them
2020-11-25 18:19:07 <ikke> No, that should be enough
2020-11-25 18:19:18 <ikke> Just mention that in the MR
2020-11-25 18:20:05 <Newbyte> Thanks
2020-11-25 18:33:48 <ikke> maxice8: appears that ffmpeg was not rebuilt properly against libdav1d on aarch64
2020-11-25 18:34:56 <Newbyte> If I'm just updating the project URL of a package, should I increment the pkgrel?
2020-11-25 18:36:31 <ikke> Newbyte: the url on pkgs.a.o will not be updated until it's rebuilt
2020-11-25 18:37:00 <Newbyte> sounds reasonable to bump it then
2020-11-25 18:39:09 <ikke> maxice8:
2020-11-25 18:39:12 <ikke> so:libdav1d.so.4 (no such package):
2020-11-25 18:39:14 <ikke>   required by: ffmpeg-libs-4.3.1-r2[so:libdav1d.so.4]
2020-11-25 18:48:58 <maxice8> @Ikke weird
2020-11-25 18:49:27 <maxice8> it wasn't rebuilt at all
2020-11-25 18:49:31 <maxice8> since I bumped it recently to -r3
2020-11-25 18:49:49 <maxice8> algitbot: retry master
2020-11-25 18:50:03 <maxice8> and get the ordering right
2020-11-25 18:50:22 <ikke> there are no packages in main or community that will be built
2020-11-25 18:51:49 <ikke> now it's building ffmpeg
2020-11-25 19:00:37 <maxice8> algitbot: good boy
2020-11-25 19:01:55 <maxice8> heh, vlc is affected by -fno-common
2020-11-25 19:21:26 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/255029#L78
2020-11-25 19:21:51 <mps> uograde ?
2020-11-25 19:22:43 <ikke> gumbo-parser is in testing
2020-11-25 19:22:53 <ikke> mupdf is in community
2020-11-25 19:23:54 <mps> hm, how it worked in my lxc then
2020-11-25 19:25:44 <ikke> because you have the testing repo enabled probably (same happened to me the other day)
2020-11-25 19:26:22 <mps> yes, I have it
2020-11-25 19:27:09 <ikke> so that's why it works in your container
2020-11-25 19:27:11 <mps> and I thought abuild care for this. every other day I learn something
2020-11-25 19:27:17 <ikke> No, it doesn't
2020-11-25 19:27:50 <ikke> abuild just tries to install packages, it does not care where they come from
2020-11-25 19:28:12 <ikke> In CI, we explicitly only install the repo the package is in and higher repos
2020-11-25 19:28:46 <mps> so we have to move gumbo-parser to community
2020-11-25 19:29:39 <ikke> yes
2020-11-25 19:31:58 <mps> lets first try with 'USE_SYSTEM_GUMBO=no'
2020-11-25 19:33:21 <mps> build works, good for now
2020-11-25 19:34:06 <ikke> I guess that means it uses an embedded gumbo?
2020-11-25 19:35:32 <mps> also I guess same
2020-11-25 20:36:00 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/255176#L29, 'error: index-pack died of signal 11', x86 CI
2020-11-25 20:38:10 <ikke> hmmf
2020-11-25 20:38:53 <mps> restarted job and it passed now
2020-11-25 20:39:43 <ikke> git[71313]: segfault at f7d34d98 ip 00000000f7f22119 sp 00000000f7b65c90 error 6 in ld-musl-i386.so.1[f7ee0000+4e000]
2020-11-25 20:40:13 <mps> uhm
2020-11-25 20:42:52 <c705> firefox is still completely fucked in edge. Is anyone looking into this
2020-11-25 20:43:22 <ikke> different people have looked into this, without much result
2020-11-25 20:43:29 <ikke> and not everyone seems to be affected
2020-11-25 20:43:54 <ikke> So we need better triage I guess
2020-11-25 20:46:30 <c705> i've tried to work with people but no one seems interested
2020-11-25 20:46:59 <c705> it's pretty fursterating. i am willing to help QA this and debug but I can't do all the work. I am not a low level developer
2020-11-25 20:47:13 <c705> if it's not going to be fixed, then i will likely be looking for a new distro
2020-11-25 20:49:34 <ikke> c705: do you know how others can reproduce these issues? I only saw it with the firefox-esr package
2020-11-25 20:50:46 <c705> add edge in repo, apk add firefox-esr, start firefox
2020-11-25 20:51:03 <c705> no profile and profile both result in tab crashes
2020-11-25 20:51:11 <ikke> ok, so esr
2020-11-25 20:51:23 <ikke> Do you have these issues with plain firefox as well?
2020-11-25 20:52:01 <c705> what is plain firefox
2020-11-25 20:52:05 <c705> apk add firefox?
2020-11-25 20:52:15 <ikke> yes
2020-11-25 20:53:42 <c705> i believe yes, at least a month ago
2020-11-25 20:53:55 <c705> I'm on lts, so i'll have to reboot to edge to confirm
2020-11-25 20:54:04 <c705> I see someone rebuilt it a week ago
2020-11-25 20:54:13 <c705> let me reboot and i'll check
2020-11-25 21:01:47 <c705> shit, I forgot I flipped my vpn
2020-11-25 21:02:04 <c705> so, firefox-esr is shit, firefox is actually functional on edge now
2020-11-25 21:02:50 <c705> hello?
2020-11-25 21:04:04 <ikke> hi
2020-11-25 21:04:14 <c705> I guess my connection flapped
2020-11-25 21:04:20 <ikke> yeah
2020-11-25 21:04:25 <c705> firefox-esr is broken still, firefox is fine now in edge
2020-11-25 21:04:35 <c705> at least from first glance
2020-11-25 21:04:47 <ikke> yeah, ok, so that's good to know
2020-11-25 21:05:45 <c705> so whatever patches were done to firefox over the last while robably need propegated to firefox-esr as well
2020-11-25 21:07:44 <ikke> I don't see related patches being added recently
2020-11-25 21:08:06 <ikke> one related to sandboxing
2020-11-25 21:09:22 <c705> yeah, that'll be the one
2020-11-25 21:09:29 <ikke> Not sure
2020-11-25 21:09:31 <ikke> https://bugzilla.mozilla.org/show_bug.cgi?id=1657849
2020-11-25 21:09:35 <ikke> seems to be related to audio playback
2020-11-25 21:11:38 <ikke> and that patch is in ESR as well
2020-11-25 21:12:20 <ikke> So more likely that upstream changes fixed it
2020-11-25 21:12:27 <Ariadne> c705: i can try to look into mozilla a bit this weekend, i've been busy with $dayjob stuff and ducking calls from my grandmother who dislikes that she is now in a memory care facility
2020-11-25 21:13:17 <c705> Ariadne: if firefox is functional, that's sufficient for myself, I can understand how frustrating someone would feel that firefox-esr is broke
2020-11-25 21:13:33 <Ariadne> i gave up on firefox on alpine some time ago and use chromium now
2020-11-25 21:13:53 <Ariadne> perhaps these gemini people have a point afterall
2020-11-25 21:13:54 <Ariadne> ;)
2020-11-25 21:15:06 <c705> maybe I should folow your lead
2020-11-25 21:15:20 <Ariadne> on which?  chromium or gemini?
2020-11-25 21:15:27 <Ariadne> because i think gemini is kinda pointless :P
2020-11-25 21:15:30 <c705> chromium
2020-11-25 21:15:41 <c705> it's all front ends for chromium engine anyways
2020-11-25 21:16:47 <Ariadne> gemini has nothing to do with the web
2020-11-25 21:16:57 <Ariadne> its basically "gopher reboot of the week, now with markdown"
2020-11-25 21:17:55 <c705> i will never understand the new fascination with gopher
2020-11-25 21:18:02 <c705> I thought we were over that 20 years ago
2020-11-25 21:27:31 <tehcloud> put your hipster glasses on and take another look, then you will understand
2020-11-25 21:27:50 <c705> they called me a hipster until I got old, now i'm just old
2020-11-25 21:30:31 <mps> gemini is on sr.ht?
2020-11-25 21:44:12 <dne> ikke: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14994
2020-11-25 21:45:14 <ikke> dne: is it still WIP?
2020-11-25 21:45:45 <dne> well, until the CI is done
2020-11-25 21:45:50 <ikke> ah ok
2020-11-25 21:46:26 <dne> aarch64 succeeded, so probably didn't break more things
2020-11-25 21:47:58 <dne> removed the WIP
2020-11-25 22:14:04 <ikke> merged
2020-11-25 23:29:56 <maxice8> Ikke: released agl v6 which can list|search merge requests in a project
2020-11-26 07:27:44 <craftyguy> I think the zbar package needs to get rebuilt against the newer imagemagick-dev in edge. it fails to install with:
2020-11-26 07:27:47 <craftyguy>   so:libMagickWand-7.Q16HDRI.so.7 (no such package):
2020-11-26 07:27:48 <craftyguy>     required by: zbar-0.23.1-r0[so:libMagickWand-7.Q16HDRI.so.7]
2020-11-26 07:28:08 <craftyguy> is the best way to do that to bump the pkgrel for the package?
2020-11-26 07:28:28 <ikke> hmm, strange soname
2020-11-26 07:28:42 <craftyguy> yeah, imagemagick has lots of them :/
2020-11-26 07:28:50 <craftyguy> https://pkgs.alpinelinux.org/contents?file=libMagickWand*&path=&name=&branch=edge
2020-11-26 07:28:53 <ikke> ok
2020-11-26 07:29:55 <craftyguy> looks like it's .8 now, at least for aarch64
2020-11-26 07:31:21 <ikke> so:libMagickWand-7.Q16HDRI.so.8=8.0.0
2020-11-26 07:31:24 <ikke> yes
2020-11-26 07:31:28 <ikke> thats in x86_64
2020-11-26 07:31:40 <ikke> so yes, pkgrel bump should fix that
2020-11-26 07:33:08 <craftyguy> great, thanks. I just built it locally to confirm. MR on the way :)
2020-11-26 07:33:58 <ikke> Maybe we should check other packages depending on imagemagick as well
2020-11-26 07:34:35 <ikke> 6 in total
2020-11-26 07:35:03 <craftyguy> testing/mgba community/tango-icon-theme community/zbar community/php7-pecl-imagick testing/octave testing/jbigkit
2020-11-26 07:35:10 <craftyguy> (just from grepping aports repo)
2020-11-26 07:35:49 <craftyguy> mgba is broken
2020-11-26 07:36:03 <ikke> yes
2020-11-26 07:36:04 <craftyguy> tango-icon-theme installs
2020-11-26 07:36:37 <craftyguy> jbigkit and octave install
2020-11-26 07:37:07 <craftyguy> php7-pecl-imagick installs too. so just zbar (MR submitted) and mgba
2020-11-26 07:38:50 <craftyguy> ikke: I submitted patches for both of those
2020-11-26 07:39:05 <ikke> zbar merged
2020-11-26 07:39:25 <Cogitri> ikke: Did you have time to look into CI making the output of checkapk available as artifacts so the bot can warn on soname changes?
2020-11-26 07:40:01 <ikke> Cogitri: not yet, but I did think about doing that soon
2020-11-26 07:40:25 <craftyguy> bah, I forgot to rebase the mgba one, sorry
2020-11-26 07:40:33 <ikke> You coldn't have
2020-11-26 07:40:34 <Cogitri> ikke: okie, thanks! :)
2020-11-26 07:40:39 <ikke> I just merged zbar
2020-11-26 07:41:28 <mps> what is 'agl'?
2020-11-26 07:41:29 <craftyguy> oh, gitlab is flippin out, it said the branch was 358 commits behind. then I reloaded and it was fine
2020-11-26 07:45:22 <ikke> Cogitri: now cargo-c is failing on aarch64 :-/
2020-11-26 07:45:45 <ikke> for some reason, these crates are left in an inconsistent state
2020-11-26 07:45:56 <ikke> Would be nice if we could somehow figure out the reason
2020-11-26 07:46:23 <ikke> "failed to read `/var/cache/distfiles/cargo/registry/src/github.com-1ecc6299db9ec823/winapi-0.3.9/Cargo.toml`"
2020-11-26 07:47:49 <Cogitri> I'll try to look into it at the weekend
2020-11-26 08:24:23 <ikke> Cogitri: cargo-c is now failing with: attempting to make an HTTP request, but --frozen was specified
2020-11-26 08:24:28 <ikke> is that something that should be fixed in the package?
2020-11-26 08:25:32 <Cogitri> Ah yes, `--frozen` means cargo will only use vendored deps and won't download anything
2020-11-26 08:25:53 <Cogitri> If the deps aren't vendored `--locked` is the right thing to do, it'll also make reproducible builds but allows fetching dependencies from crates.io
2020-11-26 08:29:11 <dne> ikke: morning, looks like xen is ok on armhf now
2020-11-26 08:34:01 <mps> how can we 'sell' alpine as secure and have such insecure thing as pulseaudio linked to a lot of pkgs
2020-11-26 08:35:58 <ikke> dne: yes, it is
2020-11-26 08:37:23 <ikke> mps: it's only in community, so it does not affect main
2020-11-26 08:37:51 <mps> what about '$package-udev' subpkgs which install udev rules only when e/udev is installed, similar how -openrc subpkgs works
2020-11-26 08:38:36 <mps> ikke: ah, so only main is 'small, simple, secure' :)
2020-11-26 08:38:54 <ikke> smaller, simpler and more secure :P
2020-11-26 08:39:24 <mps> yes
2020-11-26 08:45:48 <Cogitri> mps: There aren't as many packages installing udev files though
2020-11-26 08:45:53 <Cogitri> And they're usually only a few KB big
2020-11-26 08:46:03 <Cogitri> So IMHO not worth adding subpackages for that
2020-11-26 08:46:45 <mps> Cogitri: -openrc subpkgs are also small
2020-11-26 08:47:57 <Cogitri> Yes, but there are loads of packages installing -openrc packages
2020-11-26 08:51:23 <mps> that doesn't mean we shouldn't do same for -udev
2020-11-26 08:52:44 <ikke> https://pkgs.alpinelinux.org/contents?file=&path=%2Fetc%2Fudev*&name=&branch=edge&arch=x86_64
2020-11-26 08:52:47 <ikke> not a lot of packages
2020-11-26 08:52:55 <ikke> or am I missing somethign?
2020-11-26 08:53:19 <Cogitri> https://pkgs.alpinelinux.org/contents?file=&path=*rules.d*&name=&branch=edge&repo=community&arch=x86_64
2020-11-26 08:53:20 <ikke> 4 packages that install something to /etc/udev/rules.d
2020-11-26 08:53:35 <Cogitri> (They should install to /usr/lib/udev)
2020-11-26 08:53:46 <ikke> ah
2020-11-26 08:54:21 <maxice8> /usr/lib/udev is where we install stuff, eudev will override /usr/lib with /etc
2020-11-26 08:54:58 <Cogitri> And users override things in /etc too
2020-11-26 08:56:08 <mps> yes, /lib/udev, /usr/lib/udev and /etc/udev
2020-11-26 08:57:22 <mps> so /lib/udev is for system important rules, /usr/lib/udev is for userspace things and /etc/udev is for local (admin/user) added rules
2020-11-26 12:30:16 <maxice8> ncopa: thanks for taking care of alpine-ipxe
2020-11-26 14:40:11 <ncopa> np
2020-11-26 14:41:32 <ncopa> dalias: i think i have found a bug in either gnu make or mus libc. make segfaults when compiling bc on s390x
2020-11-26 14:43:02 <ncopa> im building gnu make with debugging symbols now and will try reproduce it so I get a proper bt
2020-11-26 14:50:53 <ncopa> gnu make's teste suite fails now
2020-11-26 15:14:06 <mps> arcan apk is finished, https://github.com/letoram/arcan \o/
2020-11-26 16:09:54 <dalias> ncopa, any further info?
2020-11-26 16:49:26 <dalias> ncopa, just strace leading up to the crash may show it
2020-11-26 16:50:36 <ncopa> im looking at the makefile
2020-11-26 16:50:41 <ncopa> makefile is nasty
2020-11-26 16:51:10 <ncopa> i dont think its related musl tbh, i tried to revert to musl 1.2.1 and it made no difference
2020-11-26 16:52:49 <ncopa> https://github.com/fivepiece/gnu-bc/blob/1.07.1-fix_arrays/bc/Makefile.am
2020-11-26 16:53:51 <ncopa> global.o depends on libmath.h, but the rules for building libmath.h runs `$(MAKE) global.o`
2020-11-26 16:54:03 <ncopa> so when running this in parallel things goes bad
2020-11-26 16:54:13 <dalias> still shouldnt crash
2020-11-26 16:54:19 <ncopa> true
2020-11-26 16:55:11 <ncopa> let me create an issue on our gitlab
2020-11-26 16:55:16 <ncopa> to document the details
2020-11-26 16:58:23 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12143
2020-11-26 17:00:04 <ncopa> i added strace there too
2020-11-26 17:00:47 <ncopa> might be that it run out of stack space?
2020-11-26 17:01:11 <Cogitri> Could try building with -Wl,stack-size,someval
2020-11-26 17:01:30 <ncopa> i don tthink that is the problem, but i will test it tomorrow
2020-11-26 17:02:14 <ncopa> i find it interesting that faccessat2 is not implemented
2020-11-26 17:05:17 <ncopa> have a nice evening
2020-11-26 17:06:09 <Cogitri> 👋
2020-11-26 17:06:12 <ikke> o/
2020-11-26 17:44:03 <mps> hmm, #include <emmintrin.h> not found on aarch64 but found on x86_64
2020-11-26 17:44:18 <Hello71> sure
2020-11-26 17:44:23 <ikke> What is providing it on x86_64?
2020-11-26 17:44:45 <mps> looking and searching now
2020-11-26 17:45:55 <mps> hmm, not exist on x86_64 also
2020-11-26 17:46:23 <mps> here is error line: /work/aports/testing/arcan/src/arcan-0.6.0/build/CMakeFiles/CMakeTmp/src.cxx:2:12: fatal error: emmintrin.h: No such file or directory
2020-11-26 17:47:10 <mps> it exists in some packages but not in /usr/include
2020-11-26 17:47:18 <Newbyte> If something just has the GPL 3.0 licence as a file put in their repository without any further specification, would that be or-later or only?
2020-11-26 17:47:33 <ikke> Newbyte: So no file headers?
2020-11-26 17:47:45 <Newbyte> Nope
2020-11-26 17:47:54 <ikke> I would assume -only then
2020-11-26 17:48:20 <mps> heh, /usr/lib/gcc/x86_64-alpine-linux-musl/10.2.1/include/emmintrin.h
2020-11-26 17:48:30 <mps> but not on aarch64
2020-11-26 17:48:34 <Hello71> yes
2020-11-26 17:50:43 <Newbyte> according to some random guy on GitHub GPL licences are "or-later" unless otherwise specified, which was my understanding as well
2020-11-26 17:50:44 <ikke> Hello71: so you seem to know why, care to explain?
2020-11-26 17:51:22 <Hello71> well how are you going to run sse2 on not-x86
2020-11-26 17:51:24 <mps> probably doesn't exist on aarch64
2020-11-26 17:51:32 <Hello71> it wouldn't run
2020-11-26 17:52:09 <mps> yes, it sse2 related
2020-11-26 18:13:21 <Newbyte> any idea why abuild suddenly is taking ages to unpack archives? used to be almost instant, now it's seemingly stuck
2020-11-26 18:13:52 <ikke> unpack or upload?
2020-11-26 18:14:00 <Newbyte> unpack
2020-11-26 18:14:04 <ikke> where?
2020-11-26 18:14:13 <Newbyte> what do you mean by where?
2020-11-26 18:14:29 <ikke> "unpacking archives" is kind of generic
2020-11-26 18:14:36 <Newbyte> however, something interesting: looking in htop it seems like it has started compiling the package
2020-11-26 18:14:38 <ikke> what kind of archives are you referring to?
2020-11-26 18:15:01 <Newbyte> I put a link to an archive in the sources of an APKBUILD and did abuild -r
2020-11-26 18:15:06 <ikke> ok
2020-11-26 18:15:13 <Newbyte> first few build attempts it unpacked almost instantly
2020-11-26 18:15:16 <Newbyte> now it seems to be stuck
2020-11-26 18:15:35 <Newbyte> but I'll try using X instead of the fb termiinal
2020-11-26 18:15:44 <ikke> storage issue?
2020-11-26 18:16:59 <Newbyte> it seems more like for some reason it quits printing stuff as I can see it starting up gcc and go
2020-11-26 18:17:05 <Newbyte> by looking at htop
2020-11-26 18:17:16 <Newbyte>  very strange
2020-11-26 18:27:49 <Newbyte> ohhhh I see what happened. go didn't print anything while building so it looked like it was unpacking forever while it just was printing nothing.
2020-11-26 18:27:59 <ikke> heh
2020-11-26 18:28:07 <ikke> you can add -v to go to have it output things
2020-11-26 18:30:52 <Newbyte> thanks!
2020-11-26 18:33:41 <Newbyte> Do you know any example go packages I might look at?
2020-11-26 18:34:43 <Newbyte> (and by example I just mean any given package built from go source code)
2020-11-26 18:35:43 <ikke> there are numerous packages
2020-11-26 18:36:39 <Newbyte> I found one. Thanks
2020-11-26 18:36:44 <ikke> https://tpaste.us/kk6b
2020-11-26 18:37:11 <Newbyte> hey is a very good package name
2020-11-26 18:52:54 <Newbyte> if I add <packagename>-dev to the makedepends of a package, is the non-dev variant of said package implicitly added to the runtime dependencies of the package?
2020-11-26 18:54:10 <Newbyte> I didn't put gtk+3.0 in the depends in a package (but I did put gtk+3.0 in the makedepends) and now it's saying that it won't remove gtk+3.0 due to this package being installed
2020-11-26 18:54:42 <Newbyte> Now, this is what I want in this situation, but I'm wondering whether to add gtk+3.0 to the depends
2020-11-26 19:02:03 <ikke> abuild automatically traces soname dependencies
2020-11-26 19:04:18 <dalias> ncopa, well it's an invalid pointer passed to free
2020-11-26 19:04:31 <dalias> possibly a double free bug
2020-11-26 19:04:45 <dalias> and there's a bunch of vfork going on around it which is disturbing
2020-11-26 19:06:50 <Newbyte> <ikke "abuild automatically traces sona"> nice
2020-11-26 19:07:11 <dalias> oh no maybe it's posix_spawn
2020-11-26 19:07:16 <dalias> yes looks like it
2020-11-26 19:07:19 <dalias> so no issue there
2020-11-27 00:42:34 <dalias> ncopa, no bt?
2020-11-27 06:36:26 <ncopa> morning! I pasted a bt at the top
2020-11-27 06:40:39 <ncopa> I wonder if we should switch to https://github.com/gavinhoward/bc
2020-11-27 06:45:02 <mps> makes sense to me
2020-11-27 06:54:56 <[[sroracle]]> we've been using it on adelie with no problems so far
2020-11-27 06:55:10 <[[sroracle]]> since he first released it, whenever that was
2020-11-27 06:56:12 <[[sroracle]]> we are a little behind on upgrades though, we're on 3.1.5 rn
2020-11-27 06:58:29 <ncopa> would still be nice to fix the bug in make first..
2020-11-27 08:37:55 <ncopa> i would like to tag releases early next week. would be nice if the builders compleeted the builds
2020-11-27 08:38:06 <ncopa> (exception 3.13)
2020-11-27 08:39:55 <ikke> so edge and stable builders?
2020-11-27 09:06:06 <maxice8> ncopa: if we should then it is best to wait for 3.13 to be released then switch as early as possible
2020-11-27 09:12:28 <ncopa> ikke: yes
2020-11-27 09:12:56 <ikke> Maybe we should do a tiny feature freeze then
2020-11-27 09:13:00 <ncopa> maxice8?
2020-11-27 09:13:15 <maxice8> my nickname is wrong again ?
2020-11-27 09:13:19 <ikke> no
2020-11-27 09:13:25 <ncopa> no, i just didn not understand what you said
2020-11-27 09:13:42 <maxice8> about switching to bc
2020-11-27 09:13:50 <ncopa> ah, ok
2020-11-27 09:14:25 <ncopa> i think bc is a relatively small/simple tool so i'd guess its low-risk
2020-11-27 09:14:27 <ncopa> but yeah
2020-11-27 09:14:31 <ncopa> lets wait til post 3.13
2020-11-27 09:16:39 <ncopa> ugh
2020-11-27 09:16:47 <ncopa> those rust dependencies are problematic
2020-11-27 09:17:00 <ncopa> for s390x
2020-11-27 09:17:05 <ncopa> polkit depends on rust
2020-11-27 09:17:15 <ikke> Anyone knows what this structopt issue on armhf for choose is about? I have seen this more on rust projects on arm/aarch
2020-11-27 09:17:23 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/choose/choose-1.3.1-r1.log
2020-11-27 09:18:01 <ncopa> i saw that earlier today, seems like it happens during install (why do they need to compile during install?) maybe because make install runs as fakeroot?
2020-11-27 09:18:26 <ncopa> seems like its difficult to port things on rust
2020-11-27 09:18:50 <ikke> ah yes, I see, that is strnage
2020-11-27 09:19:03 <ikke> ncopa: Maybe related to other issues I see regularly
2020-11-27 09:19:27 <ikke> where crates in the local rust cache registry are incomplete
2020-11-27 09:20:05 <ncopa> rust in general seems flaky
2020-11-27 09:23:12 <ncopa> does anyone know what status for rust on s390x is?
2020-11-27 09:23:16 <detha> any language with a built-in ecosystem will get flaky </rant>
2020-11-27 09:25:45 <insep_> safety is a lie
2020-11-27 09:25:52 <insep_> and so is functional
2020-11-27 09:28:38 <Cogitri> ncopa: I think Ariadne still has linker errors on stage 0
2020-11-27 09:29:50 <Cogitri> And apparently rust devs seem to not know why that happens either (?)
2020-11-27 09:32:36 <ncopa> im building geoclue without modem manager on s390x
2020-11-27 09:32:49 <ncopa> dunno if we should disable modem manager for allarches or not
2020-11-27 09:34:05 <Cogitri> modem manager on all arches would probably break geolocation on loads of devices w/ geoclue
2020-11-27 09:35:31 <ncopa> Cogitri: ok with you? https://tpaste.us/8jbk
2020-11-27 09:36:59 <Cogitri> ncopa: Yup 👌
2020-11-27 09:37:16 <ncopa> i think we need a tool to list all reverse buildtime deps, so we can see the consequence of disabling an arch
2020-11-27 09:42:48 <Cogitri> maxice8 created that
2020-11-27 09:44:52 <Cogitri> https://github.com/maxice8/aports-helpers
2020-11-27 09:50:32 <ncopa> ah, awesome
2020-11-27 09:52:07 <ncopa> no apk for it yet?
2020-11-27 09:53:02 <maxice8> No plans to
2020-11-27 09:56:47 <ncopa> how do i install or use it?
2020-11-27 09:56:56 <ncopa> ncopa-edge-s390x:~/src/aports-helpers$ lua5.2 adep.lua
2020-11-27 09:56:56 <ncopa> lua5.2: adep.lua:9: attempt to concatenate a nil value
2020-11-27 10:37:56 <ikke> Hope the s390x builder gets green now soon again
2020-11-27 10:38:37 <maxice8> apk add --virtual .depends-aports-helpers lua5.2 lua5.2-filesystem lua5.2-lyaml lua-aports
2020-11-27 10:38:40 <maxice8> it is in the README
2020-11-27 10:39:54 <Cogitri> ncopa: ^
2020-11-27 10:41:54 <mps> detha: you will not be famous if you don't make a mess (re: rust)
2020-11-27 10:42:25 <mps> detha: if you make perfect thing no one will notice your work
2020-11-27 10:45:31 <ncopa> yeah, i figured that part, but i figured it out
2020-11-27 10:45:42 <ncopa> i need to specify full path to adep.lua
2020-11-27 10:46:02 <ncopa> i will disable entire kde on s390x
2020-11-27 10:47:01 <ncopa> i think we need some tooling to help users easily see the the implication of introducing new dependency
2020-11-27 10:47:38 <ncopa> if a new dependency is disable on arch it may result in disabling hundreds of packages for that arch
2020-11-27 10:47:50 <ncopa> like  4cc2e4e9cc082586684d0d3b5272335f4f0582b9
2020-11-27 10:48:35 <detha> mps: true. You will just be scolded 20 years later, when someone finds the machine in the corner of the DC that has been humming along quietly for all those years, and people go 'Where is the source for this? The forge it was on disappeared 10 years ago'
2020-11-27 10:48:35 <ncopa> heh
2020-11-27 10:48:39 <ncopa> +arch="all !armh !s390 !s390 !s390 !s390x" # Blocked by extra-cmake-modules
2020-11-27 10:48:39 <ncopa> +arch="$arch !mips !mips6 !s390 !s390 !s390 !s390x" # Blocked by qt5-qtwebkit
2020-11-27 10:49:04 <ncopa> those sed scripts does not detect arch="$arch ..."
2020-11-27 11:10:34 <ncopa> i am starting to get annoyed of rust
2020-11-27 11:10:38 <ncopa> really annoyed
2020-11-27 11:10:53 <ncopa>  Downloading crates ...
2020-11-27 11:10:53 <ncopa> error: failed to download `dtoa v0.4.5`
2020-11-27 11:11:10 <ncopa> how do we deal with that?
2020-11-27 11:12:14 <ikke> Does it complain about missing files?
2020-11-27 11:12:33 <ikke> What arch?
2020-11-27 11:12:46 <ncopa> i think it happens on alrches
2020-11-27 11:12:51 <ncopa> all arches
2020-11-27 11:13:05 <ncopa> this is problematic, i think a dependency got removed
2020-11-27 11:13:25 <ncopa> dtoa v0.4.5 is no longer available to download
2020-11-27 11:13:28 <ikke> ugh
2020-11-27 11:13:36 <ikke> sounds like leftpad
2020-11-27 11:13:39 <mps> I'm already annoyed with rust about year ago and stopped to look at it
2020-11-27 11:13:45 <ncopa> we normally cache our source tarballs so we can rebuild things in stable branches
2020-11-27 11:13:57 <ikke> we also have a cache
2020-11-27 11:14:04 <ncopa> but how do we cache cargo stuff?
2020-11-27 11:14:04 <ikke> /var/cache/distfiles/rust
2020-11-27 11:14:07 <ikke> /var/cache/distfiles/cargo
2020-11-27 11:14:28 <ncopa> who do we clean that up?
2020-11-27 11:14:42 <ikke> ¯\_(ツ)_/¯
2020-11-27 11:14:52 <ncopa> we already have problems with disk usage
2020-11-27 11:15:00 <ikke> Cogitri: ideas?
2020-11-27 11:15:06 <ncopa> i am really annoyed about rust and cargo
2020-11-27 11:15:19 <ikke> We have the same issue with go btw
2020-11-27 11:15:38 <ncopa> how do we make sure that we can rebuild a package 2 years in the future?
2020-11-27 11:16:15 <mps> their corporations don't like this idea
2020-11-27 11:16:55 <mps> only solution is to archive everyting we build
2020-11-27 11:17:15 <mps> only sane solution
2020-11-27 11:17:17 <ikke> go does cache things by default
2020-11-27 11:17:29 <ikke> but then you get the other question, how do we clean it up
2020-11-27 11:17:31 <ncopa> my feeling now is: if rusts package manager is so great, why not let end users use it? can we nuke rust from our repos and let end user use cargo for anything that touches rust?
2020-11-27 11:18:48 <ncopa> rust is not designed for stable branches/releases
2020-11-27 11:18:52 <ikke> nope
2020-11-27 11:18:56 <mps> if we have replace for FF, I would vote for rust removal
2020-11-27 11:19:00 <ikke> And I have a feeling we will run into that more and more
2020-11-27 11:19:16 <ikke> most new langaguages seem to come with a package manager built-in
2020-11-27 11:19:21 <ncopa> thats why we only had firefox-esr in community in the past
2020-11-27 11:19:21 <ikke> others are converging to there
2020-11-27 11:19:33 <mps> ikke: yes, that is trend
2020-11-27 11:20:19 <ncopa> they dont want wayt 6months for the distromakers ship their product in new release. they want end users get the latest and greatest *now*
2020-11-27 11:20:36 <ncopa> its the eternal combat stable vs fresh
2020-11-27 11:20:46 <mps> aha, brave new computer world
2020-11-27 11:20:49 <ikke> they don't want to backport fixes
2020-11-27 11:20:56 <ikke> if you want a bug fixed, use the latest version
2020-11-27 11:21:05 <ikke> (no matter what other breaking changes it introduced)
2020-11-27 11:21:22 <ncopa> so its not suitable for LTS releases
2020-11-27 11:21:35 <ikke> ncopa: but how is go different?
2020-11-27 11:21:48 <ikke> and haskell for that matter
2020-11-27 11:22:04 <mps> go is little better, you can lock versions
2020-11-27 11:22:12 <ikke> you can with rust as well
2020-11-27 11:22:13 <mps> lib versions*
2020-11-27 11:22:26 <ncopa> they are different because they somehow manage avoid us to constantly trip over them
2020-11-27 11:23:17 <ncopa> i dont know how they do it, but somehow it seems like go normally "just works"
2020-11-27 11:23:36 <ncopa> we have go for s390x
2020-11-27 11:23:40 <mps> anyway, rust will 'die' in not so distant future
2020-11-27 11:23:40 <ncopa> but we dont have for rust
2020-11-27 11:23:46 <ikke> right
2020-11-27 11:23:49 <ncopa> i doubt rust will die
2020-11-27 11:23:57 <ikke> But dependencies can still disappear for go I guess
2020-11-27 11:24:02 <ncopa> thye probably can
2020-11-27 11:24:04 <ikke> not sure if goproxy caches it
2020-11-27 11:24:14 <ncopa> but i havent seen it happen so far
2020-11-27 11:24:35 <mps> ikke: yes, they can but they can cached
2020-11-27 11:25:02 <mps> can be cached*
2020-11-27 11:26:35 <ikke> We at least are not consistently caching go modules
2020-11-27 11:28:35 <ncopa> rust again: https://build.alpinelinux.org/buildlogs/build-edge-armhf/community/squeekboard/squeekboard-1.11.1-r0.log
2020-11-27 11:40:04 <Cogitri> Yes, somehow it doesn't like our caching
2020-11-27 11:40:41 <ncopa> it only happens on armv7 and armhf?
2020-11-27 11:41:50 <ikke> aarch64 as well
2020-11-27 11:41:59 <ncopa> hum
2020-11-27 11:42:04 <ncopa> it builds in my dev env
2020-11-27 11:42:08 <ncopa> so its the cache
2020-11-27 11:42:26 <ncopa> how do we solve a problem like that? we simply purge the cache?
2020-11-27 11:42:39 <ikke> I have removed the offending crates
2020-11-27 11:42:44 <ikke> in the past
2020-11-27 11:43:39 <ncopa> is cargo cache safe for multi processing? so different process can touch the cache in parallel?
2020-11-27 11:44:03 <ncopa> how can I remove an offending crate?
2020-11-27 11:44:56 <ikke> maybe we should try to purge the entire cache
2020-11-27 11:45:07 <ikke> as these structopt issues seem to be happening as well
2020-11-27 11:45:43 <Cogitri> As a workaround we could disable the cache
2020-11-27 11:45:49 <Cogitri> Just remove CARGO_HOME from /etc/abuild.conf
2020-11-27 11:45:55 <Cogitri> Then it won't happen again
2020-11-27 11:46:19 <Cogitri> Cargo re-downloading crates for every build probably isn't a problem on the builders anyway
2020-11-27 11:48:13 <ncopa> there are no CARGO_HOME in/etc/abuild.conf
2020-11-27 11:48:16 <ncopa> on build-edge-armhf
2020-11-27 11:48:37 <ikke> ~/.abuild/abuild.conf?
2020-11-27 11:49:06 <ncopa> nope
2020-11-27 11:49:51 <ikke> It needs to be defined _somewhere+
2020-11-27 11:50:05 <ncopa> i dont know where
2020-11-27 11:51:42 <Cogitri> Oh, maybe I added that into abuild itself?
2020-11-27 11:51:52 <Cogitri> Ah yes :/
2020-11-27 11:52:04 <Cogitri> abuild defines `CARGO_HOME=$SRCDEST/cargo`
2020-11-27 11:52:13 <ikke> oof
2020-11-27 11:52:22 <Cogitri> Maybe we should just revert abuild af0c88e6abbb1e49224759f5c51b3068e6eab28b
2020-11-27 12:09:57 <ikke> nb, I do have the changes for the reports ready, just need to test and deploy them
2020-11-27 12:10:05 <ikke> Cogitri: ^
2020-11-27 12:29:43 <Cogitri> You mean for CI? Nice
2020-11-27 12:30:30 <ikke> Yes
2020-11-27 14:08:16 <dne> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14814
2020-11-27 14:08:29 <dne> (6 unpatched XSAs on 3.10 currently)
2020-11-27 15:21:27 <ncopa> seems like it is a good idea to revert abuild af0c88e6abbb1e49224759f5c51b3068e6eab28b
2020-11-27 15:23:07 <Cogitri> 👍️
2020-11-28 00:41:26 <craftyguy> if I want to pass -Dbuildtype=debug to meson, will the abuild-meson wrapper use that if I pass it as an option or so I need to override it some other way?
2020-11-28 00:43:58 <craftyguy> hmm, seems like it just conflicts with the -buildtype that the wrapper sets
2020-11-28 00:49:57 <craftyguy> 
ACTION will just replace the wrapper (since I just want to build this for debugging an app)

2020-11-28 07:49:59 <Newbyte> I remember there being mips64 builders on the build status page, but I don't see any when I'm checking. Am I crazy?
2020-11-28 07:51:02 <ikke> Newbyte: the builder is awol :P
2020-11-28 07:55:50 <Newbyte> then I'm not crazy. thanks
2020-11-28 13:58:24 <andypost> looks armhf builder has issue with FS https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/neomutt/neomutt-20201120-r0.log
2020-11-28 13:59:50 <ikke> andypost: Hmm, I thought I fixed that
2020-11-28 14:00:28 <andypost> checked locally and can reproduce - symlink -> ../maildir
2020-11-28 14:00:39 <ikke> 53749dcd244124bcf6a3ce1fb1a163db0e2ae4e9
2020-11-28 14:00:52 <ikke> hmm
2020-11-28 14:02:04 <ikke> oops, I made a mistake in the function name
2020-11-28 14:03:05 <andypost> strange... symlink makes circular link to parent dir
2020-11-28 14:03:48 <ikke> andypost: that's not the issue that armhf is havving
2020-11-28 14:04:17 <ikke> d-w-------    5 buildoze buildoze      4096 Jun 18 15:49 damson
2020-11-28 14:04:33 <ikke> it lacks +x on that dir, so rm cannot recurse into it
2020-11-28 14:05:03 <ikke> the question is why that happens in the first place
2020-11-28 14:05:07 <andypost> I see now, there was option like root-clean
2020-11-28 14:05:15 <ikke> yes
2020-11-28 14:05:28 <ikke> but that does not work either, it only sets +w
2020-11-28 14:05:38 <ikke> (I've added that option ;-))
2020-11-28 14:05:54 <andypost> )) I bet for go lang
2020-11-28 14:05:57 <ikke> yes
2020-11-28 14:06:43 <andypost> btw how find will pass this symlink?
2020-11-28 14:07:31 <ikke> I don't see a symlink
2020-11-28 14:07:38 <ikke> (possibly because it has already been removed)
2020-11-28 14:08:26 <ikke> ugh
2020-11-28 14:08:32 <ikke> I should have test built before I pushed :P
2020-11-28 14:15:33 <andypost> great! so only one package left to fix for armhf
2020-11-28 14:16:59 <ikke> Which one
2020-11-28 14:25:41 <andypost> https://build.alpinelinux.org/buildlogs/build-edge-armhf/testing/py3-zstandard/py3-zstandard-0.14.0-r0.log
2020-11-28 14:25:49 <andypost> but I can't reproduce locally
2020-11-28 14:27:00 <ikke> hmm, bus error
2020-11-28 21:01:40 <Thalheim> when sshd is upgraded, should it be restarted? if not, it causes key exchange errors upon (re)connection
2020-11-28 21:02:15 <ikke> Thalheim: There has been a specific upgrade where that was necessary
2020-11-28 21:02:26 <ikke> in general it should not be necessary
2020-11-28 21:06:08 <Thalheim> ikke: thanks; have noticed it twice (and needed to find another way into these machines)
2020-11-28 21:16:16 <mps> 'KexAlgorithms +diffie-hellman-group1-sha1'?
2020-11-28 21:20:24 <Hello71> i think it was between 3.11 and 3.12?
2020-11-28 21:20:39 <Hello71> "After upgrading to OpenSSH >= 8.2_p1, the server will not accept new connections until it is restarted"
2020-11-28 21:20:57 <mps> that, but I forgot date
2020-11-28 21:29:42 <aparcar[m]> hey, who is managing the lists.alpinelinux instance? is it much work?
2020-11-28 21:30:05 <Hello71> sha1 is loooong obsolete
2020-11-28 21:30:38 <mps> yes, but some 'servers' are stuck on old ssh
2020-11-29 07:24:45 <tbodt> a question about apk: how does it decide whether to overwrite existing files (makes sense for binaries) or leave them alone (makes sense for config files)?
2020-11-29 07:25:06 <tbodt> does it check whether they've been changed since the package was last installed?
2020-11-29 07:26:12 <ikke> tbodt: files in /etc are not touched if they have changed, other else they are
2020-11-29 07:27:12 <tbodt> how does it check whether the file has been changed? does it store a hash of each file at install time or something?
2020-11-29 07:27:35 <tbodt> ikke: ^
2020-11-29 07:59:10 <ikke> I'm not entirely sure, but I assume something like that
2020-11-29 08:07:53 <mps> look /lib/apk/db/installed, Z: field
2020-11-29 08:13:24 <tbodt> ahh I see now
2020-11-29 08:13:48 <tbodt> wondering how this interacts with replace, will it only replace files in /etc that haven't changed?
2020-11-29 08:22:53 <[[sroracle]]> not always. in my experience it seemed to want to replace files even if they didn't change, probably for convenience sake
2020-11-29 08:23:26 <[[sroracle]]> it just took care to not overwrite local changes
2020-11-29 08:24:25 <[[sroracle]]> i had problems for example where i had /etc/hosts bind mounted read only in the container, and it had no changes from the stock one on a particular machine. but apk would try to overwrite it anyway
2020-11-29 08:36:48 <tbodt> I mean with https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#replaces
2020-11-29 08:57:49 <[[sroracle]]> replaces means that the new package basically takes ownership of the old package's files. all of the other file replacement rules still apply
2020-11-29 08:59:08 <tbodt> so if I add a package that supplies /etc/motd and replaces alpine-baselayout, and /etc/motd is modified from the original, the new package won't overwrite /etc/motd?
2020-11-29 08:59:51 <[[sroracle]]> i believe that is correct. would warrant a test to be sure though
2020-11-29 09:00:06 <mps> 'replaces' replace complete package
2020-11-29 09:00:28 <mps> but don't remove modified files
2020-11-29 09:00:41 <[[sroracle]]> i think the interesting corner case would be to see if it creates .apk-new if the modification matches what the new package would provide
2020-11-29 09:00:56 <[[sroracle]]> but certainly it should create one if it doesn't match
2020-11-29 09:01:15 <tbodt> I should test this but sounds like it will do what I want
2020-11-29 09:12:02 <bratkartoffel> hi folks. anyone got time to review and merge my PRs to fix openjdk9+ builds? I've finished the patches and filed the MRs. Thanks! https://gitlab.alpinelinux.org/alpine/aports/-/issues/12144
2020-11-29 11:57:37 <mps> #12144
2020-11-29 12:00:30 <mps> bratkartoffel: so !14518 can be merged?
2020-11-29 12:09:02 <bratkartoffel> @mps all of these MR can be merged now
2020-11-29 12:09:48 <mps> is the order important somehow
2020-11-29 12:19:50 <bratkartoffel> i dont think
2020-11-29 12:20:25 <bratkartoffel> but merging them in order is an additional check that everything works fine (each version requires the previous version to compile)
2020-11-29 12:23:33 <mps> lets try, first !14518
2020-11-29 12:25:29 <bratkartoffel> thanks @mps
2020-11-29 12:25:32 <mps> bratkartoffel: https://build.alpinelinux.org/buildlogs/build-edge-s390x/community/openjdk8/openjdk8-8.272.10-r2.log
2020-11-29 12:26:03 <bratkartoffel> tar (child): xz: Cannot exec: No such file or directory
2020-11-29 12:26:15 <bratkartoffel> it seems xz is missing on the builder?
2020-11-29 12:26:52 <bratkartoffel> but only on s390x, the other arches look fine
2020-11-29 12:26:55 <mps> yes, latest changes in busybox, probably s390x builder should be upgraded
2020-11-29 12:27:55 <mps> bratkartoffel: pleasure is my :) I see and appreaciate your big and good work for alpine
2020-11-29 12:49:34 <Hello71> we can't drop jdk9 yet because it's not cross, right?
2020-11-29 12:58:22 <bratkartoffel> not cross? we need it to build jdk10, which we need in turn to build 11 and 12 and...
2020-11-29 13:02:19 <Hello71> or just cross compile the supported versions
2020-11-29 13:02:29 <Hello71> compile 11 with 11
2020-11-29 13:20:57 <bratkartoffel> should be possible, but I think aports don't support cross-compilation on the builders?
2020-11-29 13:21:20 <bratkartoffel> haven't tried though
2020-11-29 16:36:26 <dohpaz42> Hi! I'm new to Alpine, and I'm trying to set up a framebuffer so I can use DirectFB and friends for some embedded projects. Right now I'm using Alpine virtual under VirtualBox, and I'm having a heck of a time getting the framebuffer set up for a particular resolution. I could be going about this the wrong way, but I went through the instructions
2020-11-29 16:36:27 <dohpaz42> for uvesafb and that seemed to go well. I'm stuck trying to get my resolution (600x480-32) working. I was looking at using fbset, but there isn't an /etc/fb.modes file, and that's what led me here to ask you all. Thank you!
2020-11-29 16:53:43 <insep_> do your embedded projects absolutely have to use directfb? :P
2020-11-29 16:56:32 <dohpaz42> insep_ Not particularly. I'm just beginning in the world of embedded, and I'm still trying to find my way around. I've seen a multitude of recommendations on using DirectFB, but I also see it's been abandoned years ago. Is there a better, more modern, way I should look into? I'd like to stick with Alpine because of it's small footprint, and
2020-11-29 16:56:33 <dohpaz42> customizability.
2020-11-29 17:03:42 <insep_> fbdev in general is kinda abandoned and being superseded by drm
2020-11-29 17:03:58 <insep_> if you want to use drm, sdl and lvgl know how to use it
2020-11-29 17:05:52 <dohpaz42> I did want to go the route of using lvgl, but I don't see any support for it in main/community Alpine. I presume then I'd have to compile it myself?
2020-11-29 20:22:35 <Hello71> dohpaz42: sure, you can
2020-11-29 20:23:00 <Hello71> interesting, https://github.com/mhx/dwarfs reduces x86_64 standard modloop from 95064064 to 68783844
2020-11-29 20:31:32 <Hello71> ah, wait, that's with 16 MB block size
2020-11-29 20:31:48 <Hello71> with same block size it's 94829985 which is much less impressive
2020-11-29 20:35:17 <Hello71> on that note can someone review https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/6
2020-11-30 08:56:54 <mps> reading yesterday mandoc ML I see that mandoc author plans to remove gzip support
2020-11-30 08:57:29 <ikke> hmm..
2020-11-30 08:57:52 <ikke> Is a sigh waranted here?
2020-11-30 08:59:55 <mps> well
2020-11-30 09:00:09 <mps> we have to be prepared for this chnage
2020-11-30 10:09:52 <Marian[m]> wlrobs now has tagged release, as suggested. I updated the APKBUILD. The issue that source hut creates archives on the fly with changing timestamps (and so changing checksums for every download) is sadly still present. Could, hence, anyone run the snapshot function on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14127 for me?
2020-11-30 10:20:45 <ikke> sadface
2020-11-30 10:20:47 <ikke> will do
2020-11-30 10:28:48 <ikke> Marian[m]: done
2020-11-30 10:29:38 <ikke> Marian[m]: fyi, can you incorporate this change? https://tpaste.us/QWR8
2020-11-30 10:30:04 <ikke> hmm, oh, maybe that's not necessary
2020-11-30 10:30:31 <ikke> right, n/m
2020-11-30 12:17:43 <maxice8> !13852 any final objections ?
2020-11-30 12:26:51 <ikke> maybe good to export HUSKY_SKIP_HOOKS=1 on the builders?
2020-11-30 12:27:22 <Cogitri> Yes, so we don't accidentally install those
2020-11-30 14:08:52 <indy> hi all, how to get attention on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15083 :)
2020-11-30 14:11:58 <ikke> indy: it's barely 5 minutes old
2020-11-30 14:12:08 <ikke> and someone already responded
2020-11-30 14:14:08 <mps> !15083
2020-11-30 14:18:19 <Hello71> also it doesn't even work
2020-11-30 14:18:58 <Hello71> hoo boy
2020-11-30 14:25:27 <ikke> dalias: strace removed the IPPROTO_MAX constant :https://github.com/strace/strace/commit/2c949e0d82049234f31cd595c6d2097bc9c241de
2020-11-30 14:28:33 <ncopa> maxice8: !13852 looks good to me. I assume there are no packages shipped on iso images that depends on any of those
2020-11-30 14:29:42 <maxice8> Is there a way to check without manually looking at every dependency installed in scripts.*?
2020-11-30 14:29:51 <mps> 
ACTION wonder is time to replace apk with apt come </grin>

2020-11-30 14:30:31 <maxice8> mps: working on replacing apk with rpm-ostree with systemd integration
2020-11-30 14:30:40 <mps> :)
2020-11-30 14:31:22 <mps> I can't remember that I saw any pkg on isos that depends on Xorg
2020-11-30 14:41:18 <dalias> ikke, ok thanks for the update
2020-11-30 14:57:53 <indy> Hello71, it weird, i just got working cherrypy based app in my container using packages build using those APKBUILD files
2020-11-30 14:58:18 <Hello71> only if you ignore all the errors...
2020-11-30 15:00:04 <indy> that build.sh is doing what? where i can find that script?
2020-11-30 15:16:38 <ikke> maxice8: did you try your apkbuild.vim plugin on alpine itself?
2020-11-30 15:17:16 <ikke> I tried a very minimal setup, that seems to be working for someone else, but it keeps using sh instead of apkbuild as filetype
2020-11-30 15:24:24 <bratkartoffel> mps: openjdk9 looking good, can you please merge the next one? !15039
2020-11-30 15:38:09 <Hello71> I am getting the impression that upstream doesn't support this arrangement... i don't think alpine should be maintaining these patches indefinitely without upstream support
2020-11-30 15:46:52 <maxice8> Ikke: what you mean alpine itself?
2020-11-30 15:47:29 <ikke> On an alpinelinux system
2020-11-30 15:47:34 <ikke> I've commented on the issue
2020-11-30 15:47:46 <maxice8> Yes, I use a alpine Linux
2020-11-30 15:47:56 <ikke> I wonder how this works for you then
2020-11-30 15:48:03 <maxice8> Even though someone tempts me to try fedora silverblue
2020-11-30 15:48:31 <ikke> setfiletype will only set filetype when it was not detected yet (which you acknowledge in the issue)
2020-11-30 15:48:47 <ikke> But it's already set in /etc/vim/vimrc on Alpine Linux
2020-11-30 15:49:01 <maxice8> Huh
2020-11-30 15:49:05 <maxice8> I use neovim
2020-11-30 15:49:08 <ikke> aha!
2020-11-30 15:49:12 <ikke> that explains
2020-11-30 15:50:07 <PureTryOut[m]2> What is the reason for installing Java 8 to a folder called `java-1.8-openjdk` rather than java-8-openjdk`? https://git.alpinelinux.org/aports/tree/community/openjdk8/APKBUILD#n70
2020-11-30 15:50:32 <ikke> PureTryOut[m]2: not sure, but it does not happen anymore for version 9
2020-11-30 15:50:35 <ikke> bratkartoffel: ^
2020-11-30 15:51:32 <PureTryOut[m]2> I currently actually have a CMake application failing to find OpenJDK8 because of it
2020-11-30 15:51:45 <maxice8> <ikke "that explains"> I'm going to get groceries ill take a look at alpine vim later
2020-11-30 15:51:57 <ikke> maxice8: sure
2020-11-30 15:52:00 <ikke> I made an MR
2020-11-30 16:24:53 <bratkartoffel> PureTryOut[m]2: compatibility. java < 8 is / was better known as 1.x
2020-11-30 16:25:19 <bratkartoffel> afaik debian / ubuntu installs it at the same path
2020-11-30 16:28:25 <bratkartoffel> hmm, guess i was wrong. ubuntu 20.04 installs it at /usr/lib/jvm/java-8-openjdk-amd64 and only has a symlink named java-1.8.0-openjdk-amd64
2020-11-30 16:32:18 <mps> bratkartoffel: merged it, but again s390x cannot find 'xz'
2020-11-30 16:34:27 <bratkartoffel> jdk10 should not use xz
2020-11-30 16:34:33 <PureTryOut[m]2> Yeah I think Alpine is the only distro that has it as 1.8.0 only
2020-11-30 16:34:54 <bratkartoffel> i'll prepare a MR for this, should be easy to "fix" :)
2020-11-30 16:35:45 <mps> bratkartoffel: some source files are xz-ipped
2020-11-30 16:36:08 <mps> and this is not bug, bug is on s390x builder
2020-11-30 16:36:47 <mps> someone should install xz on s390x
2020-11-30 16:38:15 <bratkartoffel> shouldn't we put xz into makedepends instead?
2020-11-30 16:40:13 <mps> we could, but I think 'xz' should be added to alpine-sdk or abuild deps
2020-11-30 16:41:32 <mps> but probably everything is ok, only s390x builder need upgrade (I guess)
2020-11-30 16:43:45 <mps> we need here proper solution and fixes or workarounds
2020-11-30 16:43:57 <mps> and not*
2020-11-30 16:44:34 <mps> s/and fixes/and not fixes/
2020-11-30 16:44:34 <alpine-meetbot> mps meant to say: we need here proper solution and not fixes or workarounds
2020-11-30 16:47:54 <ikke> mps: what is the issue on s390x?
2020-11-30 16:48:18 <ikke> I mean, why specifically s390x
2020-11-30 16:48:59 <mps> can't find xz to unpack tar archive
2020-11-30 16:49:13 <mps> on other arches it works
2020-11-30 16:50:09 <ikke> strange
2020-11-30 16:50:16 <ikke> because other builders don't have 'xz' installled either
2020-11-30 16:50:31 <mps> also on my local aarch64 edge xz doesn't exist because I didn't upgraded fully
2020-11-30 16:51:01 <ikke> on x86_64: tar (child): xz: Cannot exec: No such file or directory
2020-11-30 16:51:05 <ikke> so it happens on all hosts
2020-11-30 16:51:05 <mps> then on other busybox is not upgraded, which have xz
2020-11-30 16:51:54 <ikke> I think it should be an abuild dependency
2020-11-30 16:52:09 <mps> I agree
2020-11-30 16:52:13 <bratkartoffel> my local alpine distribution (latest edge) also has no xz
2020-11-30 16:52:18 <bratkartoffel> had to install it too
2020-11-30 16:52:44 <bratkartoffel> but yes, declaring it a general abuild dep sounds fine
2020-11-30 16:52:49 <ikke> xz was recently removed from bb, as it could only unpack (for which unxz already existed)
2020-11-30 16:53:06 <mps> ikke: please could you add it as deps for abuild and push
2020-11-30 16:54:40 <mps> I just went out
2020-11-30 16:55:44 <mps> what happens when people make such changes just before release ;P
2020-11-30 16:56:08 <ikke> I'm kind of wary to just do that, because it affects the bootstrap path
2020-11-30 16:56:52 <mps> (and that is people who want to destroy old good world and make 'brave now world')
2020-11-30 16:57:49 <mps> proper solution would be revert xz removal from bb, imo
2020-11-30 16:58:22 <ikke> there is unxz
2020-11-30 16:58:35 <ikke> so if we could convince tar to use unxz, it would work as well
2020-11-30 16:58:51 <mps> yes, but it is not named xz what tar expects
2020-11-30 16:58:57 <ikke> ^
2020-11-30 16:59:58 <mps> till we don't find something else needing 'xz'
2020-11-30 16:59:58 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L513
2020-11-30 17:00:42 <ikke> abuild should already use unxz
2020-11-30 17:01:47 <mps> it is bb tar I think
2020-11-30 17:01:50 <ikke> it works on my lxc container, where I don't have xz
2020-11-30 17:02:00 <ikke> mps: It explicitly calls unxz
2020-11-30 17:02:17 <ikke> maybe newest version of abuild?
2020-11-30 17:02:28 <mps> hmm, I can't check now but I trust you
2020-11-30 17:03:07 <ikke> hmm, no
2020-11-30 17:03:18 <ikke> `unxz $threads_opt -c "$s" | tar -C "$srcdir" -x || return 1;;`
2020-11-30 17:04:42 <mps> (why I merge anything just before leaving working place)
2020-11-30 17:06:57 <ikke> Hmm, in my container it didn't even unpack
2020-11-30 17:07:19 <ikke> I needed to wait longer
2020-11-30 17:07:47 <ikke> aha
2020-11-30 17:08:01 <ikke> the APKBUILD overrides unpack
2020-11-30 17:08:25 <ikke> bratkartoffel: any reason why unpack is overridden?
2020-11-30 17:09:47 <ikke> seems to be there already quite some time
2020-11-30 17:09:55 <bratkartoffel> nope, no idea
2020-11-30 17:10:16 <ikke> now it works
2020-11-30 17:10:21 <ikke> I just removed it
2020-11-30 17:10:35 <bratkartoffel> ah, it should only unpack one archive
2020-11-30 17:10:41 <bratkartoffel> the others will be extracted at custom locations
2020-11-30 17:10:43 <mps> ah, it openjdk8 not 11
2020-11-30 17:10:51 <ikke> bratkartoffel: aha
2020-11-30 17:13:06 <ikke> bratkartoffel: https://tpaste.us/wPxK
2020-11-30 17:13:34 <ikke> agree?
2020-11-30 17:13:40 <ikke> (copied from abuild)
2020-11-30 17:14:09 <bratkartoffel> looking good, gimme one minute to check this
2020-11-30 17:14:12 <ikke> (y)
2020-11-30 17:14:27 <ikke> Maybe a better approach is to let abuild unpack them, and move them in prepare?
2020-11-30 17:15:35 <bratkartoffel> your paste looks good, it works as it should
2020-11-30 17:16:15 <ikke> alright, will push that out
2020-11-30 17:17:27 <bratkartoffel> thanks! the custom unpack only extracts what it needs. the other archives are extracted by the build itself (see https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/openjdk8/APKBUILD#L263 )
2020-11-30 17:17:45 <bratkartoffel> i think we should just leave it be for now
2020-11-30 17:18:09 <ikke> ok
2020-11-30 17:19:04 <ikke> pushed
2020-11-30 17:22:11 <bratkartoffel> in the meantime i've created the MR to change the install location and create a symlink to openjdk8 !15085
2020-11-30 17:23:05 <bratkartoffel> ikke: the fix is not working
2020-11-30 17:23:21 <bratkartoffel> i'll look into this
2020-11-30 17:23:38 <ikke> bratkartoffel: why not?
2020-11-30 17:24:30 <bratkartoffel> as i thought, the build itself uses tar again to unpack the souces
2020-11-30 17:24:41 <bratkartoffel> https://gitlab.alpinelinux.org/bratkartoffel/aports/-/jobs/257691
2020-11-30 17:24:54 <ikke> maybe then just add xz as makedepend?
2020-11-30 17:25:43 <bratkartoffel> yeah, i think thats the easiest solution
2020-11-30 17:26:11 <ikke> For most packages, it's not an issue, but here the build system requires xz itself, so it would warant adding it as makedepend
2020-11-30 17:27:20 <bratkartoffel> fyi: the gitlab linter is also currently not working https://gitlab.alpinelinux.org/bratkartoffel/aports/-/jobs/257697
2020-11-30 17:28:59 <andypost[m]> And restart did not help
2020-11-30 17:29:48 <bratkartoffel> no, i've seen this error the whole day now
2020-11-30 17:30:23 <ikke> checking
2020-11-30 17:30:28 <bratkartoffel> strange, in other MRs it works fine
2020-11-30 17:31:41 <ikke> now it goes
2020-11-30 17:32:17 <bratkartoffel> working again, thanks
2020-11-30 17:45:25 <bratkartoffel> mps: jdk10 build look fine, can you please merge the next one? !15040
2020-11-30 17:46:02 <bratkartoffel> ah, wait a sec please
2020-11-30 17:47:06 <bratkartoffel> forgot to remove a not needed patch with the latest commit; MR is fine now
2020-11-30 17:50:24 <mps> iiuc, 10 is needed to build 11?
2020-11-30 17:50:39 <ikke> to bootstrap it
2020-11-30 17:50:43 <bratkartoffel> y
2020-11-30 17:51:40 <mps> then we should wait till 10 is finished and uploaded to the mirrors?
2020-11-30 17:52:00 <mps> about one hour
2020-11-30 17:52:21 <bratkartoffel> ok, i just checkt at pkgs.alpinelinux.org and there the new versions are already listed
2020-11-30 17:52:44 <bratkartoffel> except aarch64 and s390x, but these builders are currenctly stuck?
2020-11-30 17:53:17 <ikke> bratkartoffel: what I understood is that officially, the each jdk version should be ultimately built by itself, correct?
2020-11-30 17:53:20 <mps> ikke: what you think?
2020-11-30 17:54:01 <ikke> I don't think these are significant changes that would affect the next build, do they?
2020-11-30 17:54:33 <bratkartoffel> don't think so, no
2020-11-30 17:54:56 <bratkartoffel> there are 2 bugs fixed in 9/10/12/13/14, but mainly it fixes bulding mit gcc10 and changed flags
2020-11-30 17:55:01 <mps> ok
2020-11-30 17:55:24 <ikke> bratkartoffel: heh, your german is leaking through :P
2020-11-30 17:56:23 <mps> heh, even didn't noticed that, though long time didn't used german
2020-11-30 17:56:39 <bratkartoffel> s/mit/with/
2020-11-30 17:56:40 <alpine-meetbot> bratkartoffel meant to say: there are 2 bugs fixed in 9/10/12/13/14, but mainly it fixes bulding with gcc10 and changed flags
2020-11-30 17:57:04 <bratkartoffel> yes, been a long monday
2020-11-30 17:57:36 <mps> bratkartoffel: what about !15085
2020-11-30 17:58:17 <bratkartoffel> i think it can be merged now, just wanted to wait for one build to finish
2020-11-30 17:58:39 <bratkartoffel> this includes the symlink that PureTryOut[m]2 talked about
2020-11-30 17:59:02 <bratkartoffel> about an hour ago
2020-11-30 17:59:10 <PureTryOut[m]2> Oh nice, thanks!
2020-11-30 17:59:18 <mps> I'm risky today :)
2020-11-30 17:59:22 <ikke> :)
2020-11-30 17:59:48 <mps> bratkartoffel: merged it
2020-11-30 18:00:54 <bratkartoffel> thanks, insane speed with merging MRs today
2020-11-30 18:01:28 <ikke> short lines help
2020-11-30 18:17:33 <maxice8> Ikke, merged the APKBUILD.vim fix
2020-11-30 18:18:25 <maxice8> Vim users should be able to use it now
2020-11-30 18:19:36 <ikke> thanks, saw it
2020-11-30 18:55:53 <PureTryOut[m]2> bratkartoffel: btw OpenJDK8 doesn't cleanly upgrade now
2020-11-30 18:56:01 <PureTryOut[m]2> `failed to rename usr/lib/jvm/.apk.4966e0d55fa17780ab0e360d6da0105a3252b75a55888894 to usr/lib/jvm/java-1.8-openjdk.`
2020-11-30 18:56:07 <PureTryOut[m]2> I have to run `apk fix` to resolve it
2020-11-30 19:08:52 <bratkartoffel> meh, haven't thought / tested the upgrade case
2020-11-30 19:08:56 <bratkartoffel> i'll fix this
2020-11-30 19:13:21 <bratkartoffel> i've restored the original install location and added a symlink for the "new" name; this should fix the upgrade !15088
2020-11-30 19:13:57 <ikke> bratkartoffel: wouldn't that now mess up things again for PureTryOut[m]2 :)
2020-11-30 19:14:11 <bratkartoffel> oh my...
2020-11-30 19:14:26 <bratkartoffel> hopefully only for him and not the others running apk upgrade and flooding the bugtracker ;)
2020-11-30 19:14:30 <ikke> heh
2020-11-30 19:20:56 <PureTryOut[m]2> Yeah I doubt many people have got this in between upgrade haha
2020-11-30 20:30:09 <bratkartoffel> ikke can you please merge this MR?
2020-11-30 20:31:13 <ikke> sorry, was afk